.el .DS L.ft I/** Body of an RPC request call: * In version 2 of the  RPC protocol specification, rpcvers must* be equal to 2.  The  fields prog,  vers, and proc specify the* remote program, its version number, and the  procedure within* the remote program to be called.  After these  fields are two* authentication  parameters: cred (authentication credentials)* and verf  (authentication verifier).  The  two authentication* parameters are   followed by  the  parameters  to  the remote* procedure,  which  are specified  by  the  specific   program* protocol.*/.ft CWstruct call_body {	unsigned int rpcvers;  /* \fImust be equal to two (2) \fP*/	unsigned int prog;	unsigned int vers;	unsigned int proc;	opaque_auth cred;	opaque_auth verf;	/* \fIprocedure specific parameters start here \fP*/};.DE.ie t .DS.el .DS L.ft I/** Body of a reply to an RPC request:* The call message was either accepted or rejected.*/.ft CWunion reply_body switch (reply_stat stat) {	case MSG_ACCEPTED:  		accepted_reply areply;	case MSG_DENIED:  		rejected_reply rreply;} reply;.DE.ie t .DS.el .DS L.ft I/** Reply to   an RPC request  that  was accepted  by the server:* there could be an error even though the request was accepted.* The first field is an authentication verifier that the server* generates in order to  validate itself  to the caller.  It is* followed by    a  union whose     discriminant  is   an  enum* accept_stat.  The  \fISUCCESS\fP  arm of    the union  is  protocol* specific.  The \fIPROG_UNAVAIL\fP, \fIPROC_UNAVAIL\fP, and \fIGARBAGE_ARGP\fP* arms of the union are void.   The \fIPROG_MISMATCH\fP arm specifies* the lowest and highest version numbers of the  remote program* supported by the server.*/.ft CWstruct accepted_reply {	opaque_auth verf;	union switch (accept_stat stat) {		case SUCCESS:			opaque results[0];			/* \fIprocedure-specific results start here\fP */		case PROG_MISMATCH:			struct {				unsigned int low;				unsigned int high;			} mismatch_info;		default:.ft I			/*			* Void.  Cases include \fIPROG_UNAVAIL, PROC_UNAVAIL\fP,			* and \fIGARBAGE_ARGS\fP.			*/.ft CW			void;	} reply_data;};.DE.ie t .DS.el .DS L.ft I/** Reply to an RPC request that was rejected by the server: * The request  can   be rejected for   two reasons:  either the* server   is not  running a   compatible  version  of the  RPC* protocol    (\fIRPC_MISMATCH\fP), or    the  server   refuses    to* authenticate the  caller  (\fIAUTH_ERROR\fP).  In  case of  an  RPC* version mismatch,  the server returns the  lowest and highest* supported    RPC  version    numbers.  In   case   of refused* authentication, failure status is returned.*/.ft CWunion rejected_reply switch (reject_stat stat) {	case RPC_MISMATCH:		struct {			unsigned int low;			unsigned int high;		} mismatch_info;	case AUTH_ERROR: 		auth_stat stat;};.DE.NH 1\&Authentication Protocols.LPAs previously stated, authentication parameters are opaque, butopen-ended to the rest of the RPC protocol.  This section definessome "flavors" of authentication implemented at (and supported by)Sun.  Other sites are free to invent new authentication types, withthe same rules of flavor number assignment as there is for programnumber assignment..NH 2\&Null Authentication.LPOften calls must be made where the caller does not know who he is orthe server does not care who the caller is.  In this case, the flavorvalue (the discriminant of the \fIopaque_auth\fP's union) of the RPCmessage's credentials, verifier, and response verifier is.I AUTH_NULL .The  bytes of the opaque_auth's body  are undefined.It is recommended that the opaque length be zero..NH 2\&UNIX Authentication.LPThe caller of a remote procedure may wish to identify himself as heis identified on a UNIX system.  The  value of the credential'sdiscriminant of an RPC call  message is  .I AUTH_UNIX .The bytes ofthe credential's opaque body encode the following structure:.DS.ft CWstruct auth_unix {	unsigned int stamp;	string machinename<255>;	unsigned int uid;	unsigned int gid;	unsigned int gids<10>;};.DEThe .I stamp is an  arbitrary    ID which the  caller machine   maygenerate.  The .I machinename is the  name of the  caller's machine (like  "krypton").  The .I uid is  the caller's effective user  ID.  The  .I gid is  the caller's effective  group  ID.  The .I gids is  acounted array of groups which contain the caller as  a member.  Theverifier accompanying the  credentials  should  be  of  .I AUTH_NULL(defined above)..LPThe value of the discriminant of  the response verifier received inthe  reply  message  from  the    server  may   be   .I AUTH_NULL or.I AUTH_SHORT .In  the  case  of .I AUTH_SHORT ,the bytes of the response verifier's string encode an opaquestructure.  This new opaque structure may now be passed to the serverinstead of the original.I AUTH_UNIXflavor credentials.  The server keeps a cache which maps shorthandopaque structures (passed back by way of an.I AUTH_SHORTstyle response verifier) to the original credentials of the caller.The caller can save network bandwidth and server cpu cycles by usingthe new credentials..LPThe server may flush the shorthand opaque structure at any time.  Ifthis happens, the remote procedure call message will be rejected dueto an authentication error.  The reason for the failure will be.I AUTH_REJECTEDCRED .At this point, the caller may wish to try the original.I AUTH_UNIXstyle of credentials..KS.NH 2\&DES Authentication.LPUNIX authentication suffers from two major problems:.IP  1.The naming is too UNIX-system oriented..IP  2.There is no verifier, so credentials can easily be faked..LPDES authentication attempts to fix these two problems..KE.NH 3\&Naming.LPThe first problem is handled by addressing the caller by a simplestring of characters instead of by an operating system specificinteger.  This string of characters is known as the "netname" ornetwork name of the caller.  The server is not allowed to interpretthe contents of the caller's name in any other way except toidentify the caller.  Thus, netnames should be unique for everycaller in the internet..LPIt is up to each operating system's implementation of DESauthentication to generate netnames for its users that insure thisuniqueness when they call upon remote servers.  Operating systemsalready know how to distinguish users local to their systems.  It isusually a simple matter to extend this mechanism to the network.For example, a UNIX user at Sun with a user ID of 515 might beassigned the following netname: "unix.515@sun.com".  This netnamecontains three items that serve to insure it is unique.  Goingbackwards, there is only one naming domain called "sun.com" in theinternet.  Within this domain, there is only one UNIX user withuser ID 515.  However, there may be another user on anotheroperating system, for example VMS, within the same naming domainthat, by coincidence, happens to have the same user ID.  To insurethat these two users can be distinguished we add the operatingsystem name.  So one user is "unix.515@sun.com" and the other is"vms.515@sun.com"..LPThe first field is actually a naming method rather than anoperating system name.  It just happens that today there is almosta one-to-one correspondence between naming methods and operatingsystems.  If the world could agree on a naming standard, the firstfield could be the name of that standard, instead of an operatingsystem name..LP.NH 3\&DES Authentication Verifiers.LPUnlike UNIX authentication, DES authentication does have a verifierso the server can validate the client's credential (andvice-versa).  The contents of this verifier is primarily anencrypted timestamp.  The server can decrypt this timestamp, and ifit is close to what the real time is, then the client must haveencrypted it correctly.  The only way the client could encrypt itcorrectly is to know the "conversation key" of the RPC session.  Andif the client knows the conversation key, then it must be the realclient..LPThe conversation key is a DES [5] key which the client generatesand notifies the server of in its first RPC call.  The conversationkey is encrypted using a public key scheme in this firsttransaction.  The particular public key scheme used in DESauthentication is Diffie-Hellman [3] with 192-bit keys.  Thedetails of this encryption method are described later..LPThe client and the server need the same notion of the current timein order for all of this to work.  If network time synchronizationcannot be guaranteed, then client can synchronize with the serverbefore beginning the conversation, perhaps by consulting theInternet Time Server (TIME[4])..LPThe way a server determines if a client timestamp is valid issomewhat complicated.  For any other transaction but the first, theserver just checks for two things:.IP  1.the timestamp is greater than the one previously seen from thesame client..IP  2.the timestamp has not expired..LPA timestamp is expired if the server's time is later than the sumof 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 alifetime for the credential..LPThis explains everything but the first transaction.  In the firsttransaction, the server checks only that the timestamp has notexpired.  If this was all that was done though, then it would bequite easy for the client to send random data in place of thetimestamp with a fairly good chance of succeeding.  As an addedcheck, the client sends an encrypted item in the first transactionknown as the "window verifier" which must be equal to the windowminus 1, or the server will reject the credential..LPThe client too must check the verifier returned from the server tobe sure it is legitimate.  The server sends back to the client theencrypted timestamp it received from the client, minus one second.If the client gets anything different than this, it will reject it..LP.NH 3\&Nicknames and Clock Synchronization.LPAfter the first transaction, the server's DES authenticationsubsystem returns in its verifier to the client an integer"nickname" which the client may use in its further transactionsinstead of passing its netname, encrypted DES key and window everytime.  The nickname is most likely an index into a table on theserver which stores for each client its netname, decrypted DES keyand window..LPThough they originally were synchronized, the client's and server'sclocks can get out of sync again.  When this happens the client RPCsubsystem most likely will get back.I RPC_AUTHERROR at which point it should resynchronize..LPA client may still get the.I RPC_AUTHERROR error even though it issynchronized with the server.  The reason is that the server'snickname table is a limited size, and it may flush entries wheneverit wants.  A client should resend its original credential in thiscase and the server will give it a new nickname.  If a servercrashes, the entire nickname table gets flushed, and all clientswill have to resend their original credentials..KS.NH 3\&DES Authentication Protocol (in XDR language).ie t .DS.el .DS L.ft I/** 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.*/.ft CWenum authdes_namekind {	ADN_FULLNAME = 0,	ADN_NICKNAME = 1};.ft I/** A 64-bit block of encrypted DES data*/.ft CWtypedef opaque des_block[8];.ft I/** Maximum length of a network user's name*/.ft CWconst MAXNETNAMELEN = 255;.ft I/** 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.*/.ft CWstruct authdes_fullname {string name<MAXNETNAMELEN>;  /* \fIname of client \f(CW*/des_block key;               /* \fIPK encrypted conversation key \f(CW*/unsigned int window;         /* \fIencrypted window \f(CW*/};.ft I/** A credential is either a fullname or a nickname*/.ft CWunion authdes_cred switch (authdes_namekind adc_namekind) {	case ADN_FULLNAME:		authdes_fullname adc_fullname;	case ADN_NICKNAME:		unsigned int adc_nickname;};.ft I/** A timestamp encodes the time since midnight, January 1, 1970.*/.ft CWstruct timestamp {	unsigned int seconds;    /* \fIseconds \fP*/	unsigned int useconds;   /* \fIand microseconds \fP*/};.ft I/** 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:** \f(CWstruct {\fP*     \f(CWadv_timestamp;            \fP-- one DES block*     \f(CWadc_fullname.window;      \fP-- one half DES block*     \f(CWadv_winverf;              \fP-- one half DES block* \f(CW}\fP* This structure is encrypted using CBC mode encryption with an* input vector of zero.  All other encryptions of timestamps use* ECB mode encryption.*/.ft CWstruct authdes_verf_clnt {	timestamp adv_timestamp;    /* \fIencrypted timestamp       \fP*/	unsigned int adv_winverf;   /* \fIencrypted window verifier \fP*/};.ft I/** 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).*/.ft CWstruct authdes_verf_svr {timestamp adv_timeverf;     /* \fIencrypted verifier      \fP*/unsigned int adv_nickname;  /* \fInew nickname for client \fP*/};.DE.KE.NH 3\&Diffie-Hellman Encryption.LPIn this scheme, there are two constants,.I BASE and.I MODULUS .Theparticular values Sun has chosen for these for the DESauthentication protocol are:.ie t .DS