rfc1057.txt

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

   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 DES
   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 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 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]".




Sun Microsystems                                               [Page 13]

RFC 1057            Remote Procedure Call, Version 2           June 1988


   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.

9.3.2 DES Authentication Verifiers

   Unlike UNIX authentication, DES authentication does have a verifier
   so the server can validate the client's credential (and vice-versa).
   The contents of this verifier is primarily an encrypted timestamp.
   The server can decrypt this timestamp, and if it is close to the real
   time, then the client must have encrypted it correctly.  The only way
   the client could encrypt 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 its first RPC call.  The conversation key is
   encrypted using a public key scheme in this first transaction.  The
   particular public key scheme used in DES 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 simpler 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 "window".
   The "window" is a number the client passes (encrypted) to the server
   in its first transaction.  You can think of it as a lifetime for the
   credential.

   This explains everything but the first transaction.  In the first
   transaction, the server checks only that the timestamp has not
   expired.  If this was all that was done though, then it would be
   quite easy for the client to send random data in place of the



Sun Microsystems                                               [Page 14]

RFC 1057            Remote Procedure Call, Version 2           June 1988


   timestamp with a fairly good chance of succeeding.  As an added
   check, the client sends an encrypted item in the first transaction
   known as the "window verifier" which must be equal to the window
   minus 1, or the server will reject the credential.

   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
   encrypted timestamp it received from the client, minus one second.
   If the client gets anything different than this, it will reject it.

9.3.3 Nicknames and Clock Synchronization

   After the first transaction, the server's DES 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, encrypted DES key and window every time. The
   nickname is most likely an index into a table on the server which
   stores for each client its netname, decrypted DES key and window.

   Though they originally were synchronized, the client's and server's
   clocks can get out of sync again.  When this happens the client RPC
   subsystem most likely will get back "RPC_AUTHERROR" at which point it
   should resynchronize.

   A client may still get the "RPC_AUTHERROR" error even though it is
   synchronized with the server.  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 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.

9.3.4 DES 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.

      enum authdes_namekind {
         ADN_FULLNAME = 0,
         ADN_NICKNAME = 1
      };




Sun Microsystems                                               [Page 15]

RFC 1057            Remote Procedure Call, Version 2           June 1988


   A 64-bit block of encrypted DES data:

   typedef opaque des_block[8];

   Maximum length of a network user's name:

   const MAXNETNAMELEN = 255;

   A fullname contains the network name of the client, an encrypted
   conversation key and the window. The window is actually a lifetime
   for the credential.  If the time indicated in the verifier timestamp
   plus the window has past, then the server should expire the request
   and not grant it.  To insure that requests are not replayed, the
   server should insist that timestamps are greater than the previous
   one seen, unless it is the first transaction.  In the first
   transaction, the server checks instead that the window verifier is
   one less than the window.

   struct authdes_fullname {
      string name<MAXNETNAMELEN>;  /* name of client                */
      des_block key;               /* PK encrypted conversation key */
      opaque window[4];            /* encrypted window              */
   };

   A credential is either a fullname or a nickname:

   union authdes_cred switch (authdes_namekind adc_namekind) {
   case ADN_FULLNAME:
      authdes_fullname adc_fullname;
   case ADN_NICKNAME:
      int adc_nickname;
   };

   A timestamp encodes the time since midnight,   March 1, 1970.

   struct timestamp {
      unsigned int seconds;    /* seconds          */
      unsigned int useconds;   /* and microseconds */
   };

   Verifier: client variety.

   The window verifier is only used in the first transaction.  In
   conjunction with a fullname credential, these items are packed into
   the following structure before being encrypted:






Sun Microsystems                                               [Page 16]

RFC 1057            Remote Procedure Call, Version 2           June 1988


   struct {
       adv_timestamp;        -- one DES block
       adc_fullname.window;  -- one half DES block
       adv_winverf;          -- one half DES block
   }

   This structure is encrypted using CBC mode encryption with an input
   vector of zero.  All other encryptions of timestamps use ECB mode
   encryption.

   struct authdes_verf_clnt {
      des_block adv_timestamp;    /* encrypted timestamp       */
      opaque adv_winverf[4];      /* encrypted window verifier */
   };

      Verifier: server variety.

   The server returns (encrypted) the same timestamp the client gave it
   minus one second.  It also tells the client its nickname to be used
   in future transactions (unencrypted).

   struct authdes_verf_svr {
      des_block adv_timeverf;     /* encrypted verifier      */
      int adv_nickname;      /* new nickname for client */
   };

9.3.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 DES
   authentication protocol are:

   const BASE = 3;
   const MODULUS = "d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b"

   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.



Sun Microsystems                                               [Page 17]

RFC 1057            Remote Procedure Call, Version 2           June 1988


   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
   serious offense, 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.

10. RECORD MARKING STANDARD

   When RPC messages are passed on top of a byte stream transport
   protocol (like TCP), it is necessary to delimit one message from
   another in order to detect and possibly recover from protocol errors.
   This is called record marking (RM).  Sun uses this RM/TCP/IP
   transport for passing RPC messages on TCP streams.  One RPC message
   fits into one RM record.

   A record is composed of one or more record fragments.  A record



Sun Microsystems                                               [Page 18]

RFC 1057            Remote Procedure Call, Version 2           June 1988


   fragment is a four-byte header followed by 0 to (2**31) - 1 bytes of
   fragment data.  The bytes encode an unsigned binary number; as with
   XDR integers, the byte order is from highest to lowest.  The number
   encodes two values -- a boolean which indicates whether the fragment
   is the last fragment of the record (bit value 1 implies the fragment
   is the last fragment) and a 31-bit unsigned binary value which is the
   length in bytes of the fragment's data.  The boolean value is the
   highest-order bit of the header; the length is the 31 low-order bits.
   (Note that this record specification is NOT in XDR standard form!)

11. THE RPC LANGUAGE

   Just as there was a need to describe the XDR data-types in a formal
   language, there is also need to describe the procedures that operate
   on these XDR data-types in a formal language as well.  The RPC
   Language is an extension to the XDR language, with the addition of
   "program", "procedure", and "version" declarations.  The following
   example is used to describe the essence of the language.