.el .DS L.ft CWconst BASE = 3;const MODULUS =         "d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b"; /* \fIhex \fP*/.DE.ft RThe way this scheme works is best explained by an example.  Supposethere are two people "A" and "B" who want to send encryptedmessages to each other.  So, A and B both generate "secret" keys atrandom which they do not reveal to anyone.  Let these keys berepresented as SK(A) and SK(B).  They also publish in a publicdirectory their "public" keys.  These keys are computed as follows:.ie t .DS.el .DS L.ft CWPK(A) = ( BASE ** SK(A) ) mod MODULUSPK(B) = ( BASE ** SK(B) ) mod MODULUS.DE.ft RThe "**" 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..LPA computes:.ie t .DS.el .DS L.ft CWCK(A, B) = ( PK(B) ** SK(A)) mod MODULUS.DE.ft Rwhile B computes:.ie t .DS.el .DS L.ft CWCK(A, B) = ( PK(A) ** SK(B)) mod MODULUS.DE.ft RThese two can be shown to be equivalent:.ie t .DS.el .DS L.ft CW(PK(B) ** SK(A)) mod MODULUS = (PK(A) ** SK(B)) mod MODULUS.DE.ft RWe drop the "mod MODULUS" parts and assume modulo arithmetic tosimplify things:.ie t .DS.el .DS L.ft CWPK(B) ** SK(A) = PK(A) ** SK(B).DE.ft RThen, replace PK(B) by what B computed earlier and likewise forPK(A)..ie t .DS.el .DS L.ft CW((BASE ** SK(B)) ** SK(A) = (BASE ** SK(A)) ** SK(B).DE.ft Rwhich leads to:.ie t .DS.el .DS L.ft CWBASE ** (SK(A) * SK(B)) = BASE ** (SK(A) * SK(B)).DE.ft RThis common key CK(A, B) is not used to encrypt the timestamps usedin the protocol.  Rather, it is used only to encrypt a conversationkey which is then used to encrypt the timestamps.  The reason fordoing this is to use the common key as little as possible, for fearthat it could be broken.  Breaking the conversation key is a farless serious offense, since conversations are relativelyshort-lived..LPThe conversation key is encrypted using 56-bit DES keys, yet thecommon key is 192 bits.  To reduce the number of bits, 56 bits areselected from the common key as follows.  The middle-most 8-bytesare selected from the common key, and then parity is added to thelower order bit of each byte, producing a 56-bit key with 8 bits ofparity..KS.NH 1\&Record Marking Standard.LPWhen RPC messages are passed on top of a byte stream protocol (likeTCP/IP), it is necessary, or at least desirable, to delimit onemessage from another in order to detect and possibly recover fromuser protocol errors.  This is called record marking (RM).  Sun usesthis RM/TCP/IP transport for passing RPC messages on TCP streams.One RPC message fits into one RM record..LPA record is composed of one or more record fragments.  A recordfragment is a four-byte header followed by 0 to (2**31) - 1 bytes offragment data.  The bytes encode an unsigned binary number; as withXDR integers, the byte order is from highest to lowest.  The numberencodes two values\(ema boolean which indicates whether the fragmentis the last fragment of the record (bit value 1 implies the fragmentis the last fragment) and a 31-bit unsigned binary value which is thelength in bytes of the fragment's data.  The boolean value is thehighest-order bit of the header; the length is the 31 low-order bits.(Note that this record specification is NOT in XDR standard form!).KE.KS.NH 1\&The RPC Language.LPJust as there was a need to describe the XDR data-types in a formallanguage, there is also need to describe the procedures that operateon these XDR data-types in a formal language as well.  We use the RPCLanguage for this purpose.  It is an extension to the XDR language.The following example is used to describe the essence of thelanguage..NH 2\&An Example Service Described in the RPC Language.LPHere is an example of the specification of a simple ping program..ie t .DS.el .DS L.vs 11.ft I/** Simple ping program*/.ft CWprogram PING_PROG {	/* \fILatest and greatest version\fP */	version PING_VERS_PINGBACK {	void 	PINGPROC_NULL(void) = 0;.ft I	/*	* Ping the caller, return the round-trip time	* (in microseconds). Returns -1 if the operation	* timed out.	*/.ft CW	int	PINGPROC_PINGBACK(void) = 1;        } = 2;     .ft I/** Original version*/.ft CWversion PING_VERS_ORIG {	void 	PINGPROC_NULL(void) = 0;	} = 1;} = 1;const PING_VERS = 2;      /* \fIlatest version \fP*/.vs.DE.KE.LPThe first version described is.I PING_VERS_PINGBACKwith  two procedures,   .I PINGPROC_NULL and .I PINGPROC_PINGBACK ..I PINGPROC_NULL takes no arguments and returns no results, but it is useful forcomputing round-trip times from the client to the server and backagain.  By convention, procedure 0 of any RPC protocol should havethe same semantics, and never require any kind of authentication.The second procedure is used for the client to have the server do areverse ping operation back to the client, and it returns the amountof time (in microseconds) that the operation used.  The next version,.I PING_VERS_ORIG ,is the original version of the protocoland it does not contain.I PINGPROC_PINGBACKprocedure. It  is usefulfor compatibility  with old client  programs,  and as  this programmatures it may be dropped from the protocol entirely..KS.NH 2\&The RPC Language Specification.LPThe  RPC language is identical to  the XDR language, except for theadded definition of a.I program-def described below..DS.ft CWprogram-def:	"program" identifier "{"		version-def 		version-def *	"}" "=" constant ";"version-def:	"version" identifier "{"		procedure-def		procedure-def *	"}" "=" constant ";"procedure-def:	type-specifier identifier "(" type-specifier ")"	"=" constant ";".DE.KE.NH 2\&Syntax Notes.IP  1.The following keywords  are  added  and   cannot  be used   asidentifiers: "program" and "version";.IP  2.A version name cannot occur more than once within the  scope ofa program definition. Nor can a version number occur more than oncewithin the scope of a program definition..IP  3.A procedure name cannot occur  more than once within  the scopeof a version definition. Nor can a procedure number occur more thanonce within the scope of version definition..IP  4.Program identifiers are in the same name space as  constant andtype identifiers..IP  5.Only unsigned constants can  be assigned to programs, versionsand procedures..NH 1\&Port Mapper Program Protocol.LPThe port mapper program maps RPC program and version numbers totransport-specific port numbers.  This program makes dynamic bindingof remote programs possible..LPThis is desirable because the range of reserved port numbers is verysmall and the number of potential remote programs is very large.  Byrunning only the port mapper on a reserved port, the port numbers ofother remote programs can be ascertained by querying the port mapper..LPThe port mapper also aids in broadcast RPC.  A given RPC program willusually have different port number bindings on different machines, sothere is no way to directly broadcast to all of these programs.  Theport mapper, however, does have a fixed port number.  So, tobroadcast to a given program, the client actually sends its messageto the port mapper located at the broadcast address.  Each portmapper that picks up the broadcast then calls the local servicespecified by the client.  When the port mapper gets the reply fromthe local service, it sends the reply on back to the client..KS.NH 2\&Port Mapper Protocol Specification (in RPC Language).ie t .DS.el .DS L.ft CW.vs 11const PMAP_PORT = 111;      /* \fIportmapper port number \fP*/.ft I/** A mapping of (program, version, protocol) to port number*/.ft CWstruct mapping {	unsigned int prog;	unsigned int vers;	unsigned int prot;	unsigned int port;};.ft I/* * Supported values for the "prot" field*/.ft CWconst IPPROTO_TCP = 6;      /* \fIprotocol number for TCP/IP \fP*/const IPPROTO_UDP = 17;     /* \fIprotocol number for UDP/IP \fP*/.ft I/** A list of mappings*/.ft CWstruct *pmaplist {	mapping map;	pmaplist next;};.vs.DE.ie t .DS.el .DS L.vs 11.ft I/** Arguments to callit*/.ft CWstruct call_args {	unsigned int prog;	unsigned int vers;	unsigned int proc;	opaque args<>;};  .ft I/** Results of callit*/.ft CWstruct call_result {	unsigned int port;	opaque res<>;};.vs.DE.KE.ie t .DS.el .DS L.vs 11.ft I/** Port mapper procedures*/.ft CWprogram PMAP_PROG {	version PMAP_VERS {		void 		PMAPPROC_NULL(void)         = 0;		bool		PMAPPROC_SET(mapping)       = 1;		bool		PMAPPROC_UNSET(mapping)     = 2;		unsigned int		PMAPPROC_GETPORT(mapping)   = 3;		pmaplist		PMAPPROC_DUMP(void)         = 4;		call_result		PMAPPROC_CALLIT(call_args)  = 5;	} = 2;} = 100000;.vs.DE.NH 2\&Port Mapper Operation.LPThe portmapper program currently supports two protocols (UDP/IP andTCP/IP).  The portmapper is contacted by talking to it on assignedport number 111 (SUNRPC [8]) on either of these protocols.  Thefollowing is a description of each of the portmapper procedures:.IP \fBPMAPPROC_NULL:\fPThis procedure does no work.  By convention, procedure zero of anyprotocol takes no parameters and returns no results..IP \fBPMAPPROC_SET:\fPWhen a program first becomes available on a machine, it registersitself with the port mapper program on the same machine.  The programpasses its program number "prog", version number "vers", transportprotocol number "prot", and the port "port" on which it awaitsservice request.  The procedure returns a boolean response whosevalue is.I TRUEif the procedure successfully established the mapping and .I FALSE otherwise.  The procedure refuses to establisha mapping if one already exists for the tuple "(prog, vers, prot)"..IP \fBPMAPPROC_UNSET:\fPWhen a program becomes unavailable, it should unregister itself withthe port mapper program on the same machine.  The parameters andresults have meanings identical to those of.I PMAPPROC_SET .The protocol and port number fields of the argument are ignored..IP \fBPMAPPROC_GETPORT:\fPGiven a program number "prog", version number "vers", and transportprotocol number "prot", this procedure returns the port number onwhich the program is awaiting call requests.  A port value of zerosmeans the program has not been registered.  The "port" field of theargument is ignored..IP \fBPMAPPROC_DUMP:\fPThis procedure enumerates all entries in the port mapper's database.The procedure takes no parameters and returns a list of program,version, protocol, and port values..IP \fBPMAPPROC_CALLIT:\fPThis procedure allows a caller to call another remote procedure onthe same machine without knowing the remote procedure's port number.It is intended for supporting broadcasts to arbitrary remote programsvia the well-known port mapper's port.  The parameters "prog","vers", "proc", and the bytes of "args" are the program number,version number, procedure number, and parameters of the remoteprocedure..LP.B Note:.RS.IP  1.This procedure only sends a response if the procedure wassuccessfully executed and is silent (no response) otherwise..IP  2.The port mapper communicates with the remote program using UDP/IPonly..RE.LPThe procedure returns the remote program's port number, and the bytesof results are the results of the remote procedure..bp.NH 1\&References.LP[1]  Birrell, Andrew D. & Nelson, Bruce Jay; "Implementing RemoteProcedure Calls"; XEROX CSL-83-7, October 1983..LP[2]  Cheriton, D.; "VMTP:  Versatile Message Transaction Protocol",Preliminary Version 0.3; Stanford University, January 1987..LP[3]  Diffie & Hellman; "New Directions in Cryptography"; IEEETransactions on Information Theory IT-22, November 1976..LP[4]  Harrenstien, K.; "Time Server", RFC 738; Information SciencesInstitute, October 1977..LP[5]  National Bureau of Standards; "Data Encryption Standard"; FederalInformation Processing Standards Publication 46, January 1977..LP[6]  Postel, J.; "Transmission Control Protocol - DARPA InternetProgram Protocol Specification", RFC 793; Information SciencesInstitute, September 1981..LP[7]  Postel, J.; "User Datagram Protocol", RFC 768; Information SciencesInstitute, August 1980..LP[8]  Reynolds, J.  & Postel, J.; "Assigned Numbers", RFC 923; InformationSciences Institute, October 1984.