rfc2695.txt

<VC++网络游戏建摸与实现>源代码


RFC 2695         Authentication Mechanisms for ONC RPC    September 1999


   where T1, T2, W1, and W2 are all 32-bit quantities, and have some
   correspondence to the original quantities occupying their positions,
   but are now interdependent on each other for proper decryption.  The
   64 bit sequence comprising T1 and T2 is denoted by T.

   The full network name credential is represented as follows using XDR
   notation:

   struct authdh_fullname {
      string name<MAXNETNAMELEN>;  /* netname of client             */
      des_block key;               /* encrypted conversation key    */
      opaque w1[4];                /* W1                            */
   };

   The conversation key is encrypted using the "common key" using the
   ECB mode.  The common key is a DES key that is derived from the
   Diffie-Hellman public and private keys, and is described later.

   The verifier is represented as follows:

   struct authdh_fullname_verf {
      des_block timestamp;         /* T (the 64 bits of T1 and T2) */
      opaque w2[4];                /* W2                           */
   };

   Note that all of the encrypted quantities (key, w1, w2, timestamp) in
   the above structures are opaque.

   The fullname credential and its associated verifier together contain
   the network name of the client, an encrypted conversation key, the
   ttl, a timestamp, and a ttl verifier that is one less than the ttl.
   The ttl is actually the lifetime for the credential.  The server will
   accept the credential if the current server time is "within" the time
   indicated in the timestamp plus the ttl.  Otherwise, the server
   rejects the credential with an authentication status of AUTH_BADCRED.
   One way to insure that requests are not replayed would be for the
   server to insist that timestamps are greater than the previous one
   seen, unless it is the first transaction.  If the timestamp is
   earlier than the previous one seen, the server returns an
   authentication status of AUTH_REJECTEDCRED.

   The server returns a authdh_server_verf structure, which is described
   in detail below.  This structure contains a "nickname", which may be
   used for subsequent requests in the current conversation.







Chiu                         Informational                      [Page 7]

RFC 2695         Authentication Mechanisms for ONC RPC    September 1999


2.4.2 The Nickname Credential and Verifier (Client)

   In transactions following the first, the client may use the shorter
   nickname credential and verifier for efficiency.  First, the client
   fills out the following structure:

      +-------------------------------+
      |   timestamp   |  timestamp    |
      |   seconds     | micro seconds |
      |   32 bits     |    32 bits    |
      +-------------------------------+
      0              31              63

   The fields are stored in XDR (external data representation) format.
   These 64 bits of data are then encrypted in the DES ECB mode, using
   the conversation key for the session.  This yields:

      +-------------------------------+
      |     (T1)      |      (T2)     |
      |               T               |
      |             64 bits           |
      +-------------------------------+
      0              31              63

   The nickname credential is represented as follows using XDR notation:

   struct authdh_nickname {
      unsigned int nickname;       /* nickname returned by server   */
   };

   The nickname verifier is represented as follows using XDR notation:

   struct authdh_nickname_verf {
      des_block timestamp;         /* T (the 64 bits of T1 and T2) */
      opaque w[4];                 /* Set to zero                  */
   };

   The nickname credential may be reject by the server for several
   reasons.  An authentication status of AUTH_BADCRED indicates that the
   nickname is no longer valid. The client should retry the request
   using the fullname credential.  AUTH_REJECTEDVERF indicates that the
   nickname verifier is not valid.  Again, the client should retry the
   request using the fullname credential.








Chiu                         Informational                      [Page 8]

RFC 2695         Authentication Mechanisms for ONC RPC    September 1999


2.4.3 The Nickname Verifier (Server)

   The server never returns a credential.  It returns only one kind of
   verifier, i.e., the nickname verifier.  This has the following XDR
   representation:

   struct authdh_server_verf {
      des_block timestamp_verf; /* timestamp verifier (encrypted)    */
      unsigned int nickname;    /* new client nickname (unencrypted) */
   };

   The timestamp verifier is constructed in exactly the same way as the
   client nickname credential.  The server sets the timestamp value to
   the value the client sent minus one second and encrypts it in DES ECB
   mode using the conversation key.  The server also sends the client a
   nickname to be used in future transactions (unencrypted).

2.5 Diffie-Hellman Encryption

   In this scheme, there are two constants "BASE" and "MODULUS" [3].
   The particular values Sun has chosen for these for the DH
   authentication protocol are:

      const BASE = 3;
      const MODULUS = "d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b";

   Note that the modulus is represented above as a hexadecimal string.

   The way this scheme works is best explained by an example.  Suppose
   there are two people "A" and "B" who want to send encrypted messages
   to each other.  So, A and B both generate "secret" keys at random
   which they do not reveal to anyone.  Let these keys be represented as
   SK(A) and SK(B).  They also publish in a public directory their
   "public" keys. These keys are computed as follows:

      PK(A) = ( BASE ** SK(A) ) mod MODULUS
      PK(B) = ( BASE ** SK(B) ) mod MODULUS

   The "**" notation is used here to represent exponentiation. Now, both
   A and B can arrive at the "common" key between them, represented here
   as CK(A, B), without revealing their secret keys.










Chiu                         Informational                      [Page 9]

RFC 2695         Authentication Mechanisms for ONC RPC    September 1999


   A computes:

      CK(A, B) = ( PK(B) ** SK(A)) mod MODULUS

   while B computes:

      CK(A, B) = ( PK(A) ** SK(B)) mod MODULUS

   These two can be shown to be equivalent:

      (PK(B) ** SK(A)) mod MODULUS = (PK(A) ** SK(B)) mod MODULUS

   We drop the "mod MODULUS" parts and assume modulo arithmetic to simplify
   things:

      PK(B) ** SK(A) = PK(A) ** SK(B)

   Then, replace PK(B) by what B computed earlier and likewise for PK(A).

      (BASE ** SK(B)) ** SK(A) = (BASE ** SK(A)) ** SK(B)

   which leads to:

      BASE ** (SK(A) * SK(B)) = BASE ** (SK(A) * SK(B))

   This common key CK(A, B) is not used to encrypt the timestamps used
   in the protocol. Rather, it is used only to encrypt a conversation
   key which is then used to encrypt the timestamps.  The reason for
   doing this is to use the common key as little as possible, for fear
   that it could be broken.  Breaking the conversation key is a far less
   damaging, since conversations are relatively short-lived.

   The conversation key is encrypted using 56-bit DES keys, yet the
   common key is 192 bits.  To reduce the number of bits, 56 bits are
   selected from the common key as follows. The middle-most 8-bytes are
   selected from the common key, and then parity is added to the lower
   order bit of each byte, producing a 56-bit key with 8 bits of parity.

   Only 48 bits of the 8-byte conversation key are used in the DH
   Authentication scheme.  The least and most significant bits of each
   byte of the conversation key are unused.

3. Kerberos-based Authentication

   Conceptually, Kerberos-based authentication is very similar to DH
   authentication.  The major difference is, Kerberos-based
   authentication takes advantage of the fact that Kerberos tickets have




Chiu                         Informational                     [Page 10]

RFC 2695         Authentication Mechanisms for ONC RPC    September 1999


   encoded in them the client name and the conversation key.  This RFC
   does not describe Kerberos name syntax, protocols and ticket formats.
   The reader is referred to [6], [7], and [8].

3.1 Naming

   A Kerberos name contains three parts.  The first is the principal
   name, which is usually a user's or service's name.  The second is the
   instance, which in the case of a user is usually NULL.  Some users
   may have privileged instances, however, such as root or admin.  In
   the case of a service, the instance is the name of the machine on
   which it runs; that is, there can be an NFS service running on the
   machine ABC, which is different from the NFS service running on the
   machine XYZ.  The third part of a Kerberos name is the realm.  The
   realm corresponds to the Kerberos service providing authentication
   for the principal.  When writing a Kerberos name, the principal name
   is separated from the instance (if not NULL) by a period, and the
   realm (if not the local realm) follows, preceded by an "@" sign.  The
   following are examples of valid Kerberos names:

      billb
      jis.admin
      [e-mail]
      [e-mail]

3.2 Kerberos-based Authentication Protocol Specification

   The Kerberos-based authentication protocol described is based on
   Kerberos version 4.

   There are two kinds of credentials: one in which the client uses its
   full network name, and one in which it uses its "nickname" (just an
   unsigned integer) given to it by the server.  The client must use its
   fullname in its first transaction with the server, in which the
   server will return to the client its nickname.  The client may use
   its nickname in all further transactions with the server. There is no
   requirement to use the nickname, but it is wise to use it for
   performance reasons.

   The following definitions are used for describing the protocol:

      enum authkerb4_namekind {
         AKN_FULLNAME = 0,
         AKN_NICKNAME = 1
      };






Chiu                         Informational                     [Page 11]

RFC 2695         Authentication Mechanisms for ONC RPC    September 1999


   The flavor used for all Kerberos-based authentication credentials and
   verifiers is "AUTH_KERB4", with numerical value 4.  The opaque data
   constituting the client credential encodes the following structure:

   union authkerb4_cred switch (authkerb4_namekind namekind) {
   case AKN_FULLNAME:
      authkerb4_fullname fullname;
   case AKN_NICKNAME:
      authkerb4_nickname nickname;
   };

   The opaque data constituting a verifier that accompanies a client
   credential encodes the following structure:

   union authkerb4_verf switch (authkerb4_namekind namekind) {
   case AKN_FULLNAME:
      authkerb4_fullname_verf fullname_verf;
   case AKN_NICKNAME:
      authkerb4_nickname_verf nickname_verf;
   };

   The opaque data constituting a verifier returned by a server in
   response to a client request encodes the following structure:

   struct authkerb4_server_verf;

   These structures are described in detail below.

3.2.1 The Full Network Name Credential and Verifier (Client)

   First, the client must obtain a Kerberos ticket from the Kerberos
   Server.  The ticket contains a Kerberos session key, which will
   become the conversation key.  Next, the client fills out the
   following structure:

      +---------------------------------------------------------------+
      |   timestamp   |  timestamp    |               |               |
      |   seconds     | micro seconds |      ttl      |   ttl - 1     |
      |   32 bits     |    32 bits    |    32 bits    |   32 bits     |
      +---------------------------------------------------------------+
      0              31              63              95             127

   The fields are stored in XDR (external data representation) format.
   The timestamp encodes the time since midnight, January 1, 1970.
   "ttl" is identical in meaning to the corresponding field in Diffie-
   Hellman authentication: the credential "time-to-live" for the





Chiu                         Informational                     [Page 12]

RFC 2695         Authentication Mechanisms for ONC RPC    September 1999