rfc2695.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                           A. Chiu
Request for Comments: 2695                             Sun Microsystems
Category: Informational                                  September 1999


                 Authentication Mechanisms for ONC RPC

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

ABSTRACT

   This document describes two authentication mechanisms created by Sun
   Microsystems that are commonly used in conjunction with the ONC
   Remote Procedure Call (ONC RPC Version 2) protocol.

WARNING

   The DH authentication as defined in Section 2 in this document refers
   to the authentication mechanism with flavor AUTH_DH currently
   implemented in ONC RPC.  It uses the underlying Diffie-Hellman
   algorithm for key exchange.  The DH authentication defined in this
   document is flawed due to the selection of a small prime for the BASE
   field (Section 2.5). To avoid the flaw a new DH authentication
   mechanism could be defined with a larger prime.  However, the new DH
   authentication would not be interoperable with the existing DH
   authentication.

   As illustrated in [10], a large number of attacks are possible on ONC
   RPC system services that use non-secure authentication mechanisms.
   Other secure authentication mechanisms need to be developed for ONC
   RPC.  RFC 2203 describes the RPCSEC_GSS ONC RPC security flavor, a
   secure authentication mechanism that enables RPC protocols to use
   Generic Security Service Application Program Interface (RFC 2078) to
   provide security services, integrity and privacy, that are
   independent of the underlying security mechanisms.








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


Table of Contents

      1. Introduction ............................................... 2
      2. Diffie-Hellman Authentication .............................. 2
      2.1 Naming .................................................... 3
      2.2 DH Authentication Verifiers ............................... 3
      2.3 Nicknames and Clock Synchronization ....................... 5
      2.4 DH Authentication Protocol Specification .................. 5
      2.4.1 The Full Network Name Credential and Verifier (Client) .. 6
      2.4.2 The Nickname Credential and Verifier (Client) ........... 8
      2.4.3 The Nickname Verifier (Server) .......................... 9
      2.5 Diffie-Hellman Encryption ................................. 9
      3. Kerberos-based Authentication ............................. 10
      3.1 Naming ................................................... 11
      3.2 Kerberos-based Authentication Protocol Specification ..... 11
      3.2.1 The Full Network Name Credential and Verifier (Client) . 12
      3.2.2 The Nickname Credential and Verifier (Client) .......... 14
      3.2.3 The Nickname Verifier (Server) ......................... 15
      3.2.4 Kerberos-specific Authentication Status Values ......... 15
      4. Security Considerations ................................... 16
      5. REFERENCES ................................................ 16
      6. AUTHOR'S ADDRESS .......................................... 17
      7. FULL COPYRIGHT STATEMENT ...................................18

1. Introduction

   The ONC RPC protocol provides the fields necessary for a client to
   identify itself to a service, and vice-versa, in each call and reply
   message.  Security and access control mechanisms can be built on top
   of this message authentication.  Several different authentication
   protocols can be supported.

   This document specifies two authentication protocols created by Sun
   Microsystems that are commonly used: Diffie-Hellman (DH)
   authentication and Kerberos (Version 4) based authentication.

   As a prerequisite to reading this document, the reader is expected to
   be familiar with [1] and [2].  This document uses terminology and
   definitions from [1] and [2].

2. Diffie-Hellman Authentication

   System authentication (defined in [1]) suffers from some problems.
   It is very UNIX oriented, and can be easily faked (there is no
   attempt to provide cryptographically secure authentication).






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


   DH authentication was created to address these problems.  However, it
   has been compromised [9] due to the selection of a small length for
   the prime in the ONC RPC implementation.  While the information
   provided here will be useful for implementors to ensure
   interoperability with existing applications that use DH
   authentication, it is strongly recommended that new applications use
   more secure authentication, and that existing applications that
   currently use DH authentication migrate to more robust authentication
   mechanisms.

2.1 Naming

   The client is addressed by a simple string of characters instead of
   by an operating system specific integer.  This string of characters
   is known as the "netname" or network name of the client. The server
   is not allowed to interpret the contents of the client's name in any
   other way except to identify the client.  Thus, netnames should be
   unique for every client in the Internet.

   It is up to each operating system's implementation of DH
   authentication to generate netnames for its users that insure this
   uniqueness when they call upon remote servers.  Operating systems
   already know how to distinguish users local to their systems. It is
   usually a simple matter to extend this mechanism to the network.  For
   example, a UNIX(tm) user at Sun with a user ID of 515 might be
   assigned the following netname: "[e-mail]".  This netname
   contains three items that serve to insure it is unique.  Going
   backwards, there is only one naming domain called "sun.com" in the
   Internet.  Within this domain, there is only one UNIX(tm) user with
   user ID 515.  However, there may be another user on another operating
   system, for example VMS, within the same naming domain that, by
   coincidence, happens to have the same user ID. To insure that these
   two users can be distinguished we add the operating system name. So
   one user is "[e-mail]" and the other is "[e-mail]".
   The first field is actually a naming method rather than an operating
   system name.  It happens that today there is almost a one-to-one
   correspondence between naming methods and operating systems.  If the
   world could agree on a naming standard, the first field could be the
   name of that standard, instead of an operating system name.

2.2 DH Authentication Verifiers

   Unlike System authentication, DH authentication does have a verifier
   so the server can validate the client's credential (and vice-versa).
   The contents of this verifier are primarily an encrypted timestamp.
   The server can decrypt this timestamp, and if it is within an
   accepted range relative to the current time, then the client must
   have encrypted it correctly.  The only way the client could encrypt



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


   it correctly is to know the "conversation key" of the RPC session,
   and if the client knows the conversation key, then it must be the
   real client.

   The conversation key is a DES [5] key which the client generates and
   passes to the server in the first RPC call of a session.  The
   conversation key is encrypted using a public key scheme in this first
   transaction.  The particular public key scheme used in DH
   authentication is Diffie-Hellman [3] with 192-bit keys.  The details
   of this encryption method are described later.

   The client and the server need the same notion of the current time in
   order for all of this to work, perhaps by using the Network Time
   Protocol [4].  If network time synchronization cannot be guaranteed,
   then the client can determine the server's time before beginning the
   conversation using a time request protocol.

   The way a server determines if a client timestamp is valid is
   somewhat complicated. For any other transaction but the first, the
   server just checks for two things:

   (1) the timestamp is greater than the one previously seen from the
   same client.  (2) the timestamp has not expired.

   A timestamp is expired if the server's time is later than the sum of
   the client's timestamp plus what is known as the client's "ttl"
   (standing for "time-to-live" - you can think of this as the lifetime
   for the client's credential).  The "ttl" is a number the client
   passes (encrypted) to the server in its first transaction.

   In the first transaction, the server checks only that the timestamp
   has not expired.  Also, as an added check, the client sends an
   encrypted item in the first transaction known as the "ttl verifier"
   which must be equal to the time-to-live minus 1, or the server will
   reject the credential.  If either check fails, the server rejects the
   credential with an authentication status of AUTH_BADCRED, however if
   the timestamp is earlier than the previous one seen, the server
   returns an authentication status of AUTH_REJECTEDCRED.

   The client too must check the verifier returned from the server to be
   sure it is legitimate.  The server sends back to the client the
   timestamp it received from the client, minus one second, encrypted
   with the conversation key.  If the client gets anything different
   than this, it will reject it, returning an AUTH_INVALIDRESP
   authentication status to the user.






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


2.3 Nicknames and Clock Synchronization

   After the first transaction, the server's DH authentication subsystem
   returns in its verifier to the client an integer "nickname" which the
   client may use in its further transactions instead of passing its
   netname. The nickname could be an index into a table on the server
   which stores for each client its netname, decrypted conversation key
   and ttl.

   Though they originally were synchronized, the client's and server's
   clocks can get out of synchronization again.  When this happens the
   server returns to the client an authentication status of
   AUTH_REJECTEDVERF at which point the client should attempt to
   resynchronize.

   A client may also get an AUTH_BADCRED error when using a nickname
   that was previously valid.  The reason is that the server's nickname
   table is a limited size, and it may flush entries whenever it wants.
   A client should resend its original full name credential in this case
   and the server will give it a new nickname.  If a server crashes, the
   entire nickname table gets flushed, and all clients will have to
   resend their original credentials.

2.4 DH Authentication Protocol Specification

   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 authdh_namekind {
         ADN_FULLNAME = 0,
         ADN_NICKNAME = 1
      };

      typedef opaque des_block[8]; /* 64-bit block of encrypted data */

      const MAXNETNAMELEN = 255;   /* maximum length of a netname */

   The flavor used for all DH authentication credentials and verifiers
   is "AUTH_DH", with the numerical value 3.  The opaque data
   constituting the client credential encodes the following structure:



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


   union authdh_cred switch (authdh_namekind namekind) {
   case ADN_FULLNAME:
      authdh_fullname fullname;
   case ADN_NICKNAME:
      authdh_nickname nickname;
   };

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

   union authdh_verf switch (authdh_namekind namekind) {
   case ADN_FULLNAME:
      authdh_fullname_verf fullname_verf;
   case ADN_NICKNAME:
      authdh_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 authdh_server_verf;

   These structures are described in detail below.

2.4.1 The Full Network Name Credential and Verifier (Client)

   First, the client creates a conversation key for the session. 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. These
   128 bits of data are then encrypted in the DES CBC mode, using the
   conversation key for the session, 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



Chiu                         Informational                      [Page 6]