doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc2695.txt b/doc/rfc/rfc2695.txt
new file mode 100644
index 0000000..7bdd76d
--- /dev/null
+++ b/doc/rfc/rfc2695.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+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: "unix.515@sun.com".  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 "unix.515@sun.com" and the other is "vms.515@sun.com".
+   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]
+
+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
+      srz@lcs.mit.edu
+      treese.root@athena.mit.edu
+
+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
+
+
+   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: +1 (650) 786-6465
+   EMail: alex.chiu@Eng.sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+