rfc2695.txt

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

   conversation being initiated.  These 128 bits of data are then
   encrypted in the DES CBC mode, using the conversation key, and with
   an initialization vector of 0.  This yields:

      +---------------------------------------------------------------+
      |               T               |               |               |
      |     T1               T2       |      W1       |     W2        |
      |   32 bits     |    32 bits    |    32 bits    |   32 bits     |
      +---------------------------------------------------------------+
      0              31              63              95             127

   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 authkerb4_fullname {
      opaque ticket<>;         /* kerberos ticket for the server */
      opaque w1[4];            /* W1                             */
   };

   The verifier is represented as follows:

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

   Note that all of the client-encrypted quantities (w1, w2, timestamp)
   in the above structures are opaque.  The client does not encrypt the
   Kerberos ticket for the server.

   The fullname credential and its associated verifier together contain
   the Kerberos ticket (which contains the client name and the
   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.



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


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

3.2.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 authkerb4_nickname {
      unsigned int nickname;       /* nickname returned by server   */
   };

   The nickname verifier is represented as follows using XDR notation:

   struct authkerb4_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





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


   request using the fullname credential.  AUTH_TIMEEXPIRE indicates
   that the session's Kerberos ticket has expired.  The client should
   initiate a new session by obtaining a new Kerberos ticket.

3.2.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 authkerb4_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).

3.2.4 Kerberos-specific Authentication Status Values

   The server may return to the client one of the following errors in
   the authentication status field:

  enum auth_stat {
      ...
      /*
       * kerberos errors
       */
      AUTH_KERB_GENERIC = 8,  /* Any Kerberos-specific error other
                                 than the following                   */
      AUTH_TIMEEXPIRE = 9,    /* The client's ticket has expired      */
      AUTH_TKT_FILE = 10,     /* The server was unable to find the
                                 ticket file.  The client should
                                 create a new session by obtaining a
                                 new ticket                           */
      AUTH_DECODE = 11,       /* The server is unable to decode the
                                 authenticator of the client's ticket */
      AUTH_NET_ADDR = 12      /* The network address of the client
                                 does not match the address contained
                                 in the ticket                        */

      /* and more to be defined */
  };





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


4. Security Considerations

   The DH authentication mechanism and the Kerberos V4 authentication
   mechanism are described in this document only for informational
   purposes.

   In addition to the weakness pointed out earlier in this document (see
   WARNING on page 1), the two security mechanisms described herein lack
   the support for integrity and privacy data protection. It is strongly
   recommended that new applications use more secure mechanisms, and
   that existing applications migrate to more robust mechanisms.

   The RPCSEC_GSS ONC RPC security flavor, specified in RFC 2203, allows
   applications built on top of RPC to access security mechanisms that
   adhere to the GSS-API specification.  It provides a GSS-API based
   security framework that allows for strong security mechanisms.  RFC
   1964 describes the Kerberos Version 5 GSS-API security mechanism
   which provides integrity and privacy, in addition to authentication.
   RFC 2623 [14] describes how Kerberos V5 is pluggued into RPCSEC_GSS,
   and how the Version 2 and Version 3 of the NFS protocol use Kerberos
   V5 via RPCSEC_GSS. The RPCSEC_GSS/GSS-API/Kerberos-V5 stack provides
   a robust security mechanism for applications that require strong
   protection.

5. REFERENCES

   [1]  Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC
        1831, August 1995.

   [2]  Srinivasan, R., "XDR: External Data Representation Standard",
        RFC 1832, August 1995.

   [3]  Diffie & Hellman, "New Directions in Cryptography", IEEE
        Transactions on Information Theory IT-22, November 1976.

   [4]  Mills, D., "Network Time Protocol (Version 3)", RFC 1305, March
        1992.

   [5]  National Bureau of Standards, "Data Encryption Standard",
        Federal Information Processing Standards Publication 46, January
        1977.

   [6]  Miller, S., Neuman, C., Schiller, J. and  J. Saltzer, "Section
        E.2.1: Kerberos Authentication and Authorization System",
        December 1987.






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


   [7]  Steiner, J., Neuman, C. and J. Schiller, "Kerberos: An
        Authentication Service for Open Network Systems", pp. 191-202 in
        Usenix Conference Proceedings, Dallas, Texas, February, 1988.

   [8]  Kohl, J. and C. Neuman, "The Kerberos Network Authentication
        Service (V5)", RFC 1510, September 1993.

   [9]  La Macchia, B.A., and Odlyzko, A.M., "Computation of Discrete
        Logarithms in Prime Fields", pp. 47-62 in "Designs, Codes and
        Cryptography", Kluwer Academic Publishers, 1991.

   [10] Cheswick, W.R., and Bellovin, S.M., "Firewalls and Internet
        Security," Addison-Wesley, 1995.

   [11] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
        June 1996.

   [12] Linn, J., "Generic Security Service Application Program
        Interface, Version 2", RFC 2078, January 1997.

   [13] Eisler, M., Chiu, A., and Ling, L., "RPCSEC_GSS Protocol
        Specification", RFC 2203, September 1997.

   [14] Eisler, M., "NFS Version 2 and Version 3 Security Issues and the
        NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623,
        June 1999.

6. AUTHOR'S ADDRESS

   Alex Chiu
   Sun Microsystems, Inc.
   901 San Antonio Road
   Palo Alto, CA 94303

   Phone: [phone]
   EMail: [e-mail]















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


7.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Chiu                         Informational                     [Page 18]