home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-mmusic-sap-sec-00.txt < prev    next >
Text File  |  1997-03-27  |  46KB  |  1,053 lines
  1. Internet Draft                        Peter Kirstein 
  2. IETF MMUSIC WG                    Goli Montasser-Kohsari 
  3. March 26, 1997                                     Edmund Whelan 
  4. <draft-ietf-mmusic-sap-sec-00.txt> 
  5. Expires September 26, 1997
  6.  
  7.     Specification of Security in SAP Using Public Key Algorithms
  8.  
  9. Status of this Memo
  10.  
  11. This document is an Internet-Draft. Internet-Drafts are working
  12. documents of the Internet Engineering Task Force (IETF), its areas, and
  13. its working groups. Note that other groups may also distribute working
  14. documents as Internet-Drafts.
  15.  
  16. Internet-Drafts are draft documents valid for a maximum of six months
  17. and may be updated, replaced, or obsoleted by other documents at any
  18. time. It is inappropriate to use Internet-Drafts as reference material
  19. or to cite them other than as ``work in progress.''
  20.  
  21. To learn the current status of any Internet-Draft, please check the
  22. ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  23. Directories  on  ftp.is.co.za (Africa), nic.nordu.net (Europe),
  24. munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  25. ftp.isi.edu (US West Coast).
  26.  
  27. Distribution of this document is unlimited.
  28.  
  29.  
  30.  
  31.                 Abstract
  32.  
  33. The Session Announcement Protocol (SAP) is specified in such a way that
  34. authentication and privacy can be assured. However but the algorithms
  35. and mechanisms to achieve such security are not prescribed in the
  36. current draft. This document extends the SAP protocol, by describing
  37. specific algorithms and formats of authentication and encryption
  38. formats based on the PGP and PKCS#7 standards. It is a companion
  39. document to draft-ietf-mmusic-sap.
  40.  
  41. This document is a product of the Multiparty Multimedia Session Control
  42. (MMUSIC) working group of the Internet Engineering Task Force Comments
  43. are solicited and should be addressed to the working group's mailing
  44. list at confctrl@isi.edu and/or the authors.
  45.  
  46. Kirstein et al.    Document Expiration 26 September 1997       [PAGE 1]
  47.  
  48. INTERNET-DRAFT                                               March 26 1997
  49.  
  50. Glossary
  51.  
  52. ASN             Abstract Syntax Notation 
  53. CT              Content Type
  54. CTB             Cipher Type Byte 
  55. DA              Digest Algorithm
  56. DEA             Digest Encryption Algorithm 
  57. DES             Data Encryption Standards 
  58. EAID        Encryption Algorithm Identifier 
  59. EKID        Encryption Key Identifier 
  60. ID              Identifier 
  61. IETF        Internet Engineering Task Force 
  62. MD              Message Digest 
  63. MMUSIC        Multiparty Multimedia Session Control 
  64. PEM             Privacy Enhanced Mail 
  65. PGK             Public Group Key 
  66. PGKID       Public Group Key Identifier 
  67. PGP             Pretty Good Privacy 
  68. PH              Privacy Header 
  69. PKCS        Public Key Cryptographic System 
  70. SAP             Session Announcement Protocol 
  71. SDP             Session Descriptor Protocol
  72. SEK             Session Encryption Key 
  73. SGK             Secret Group Key
  74. SHA             Secure Hash Algorithm
  75.  
  76. Kirstein et al.       Document Expiration 26 September 1997  [PAGE 2]
  77.  
  78. INTERNET-DRAFT                                          March 26 1997
  79.  
  80. 1. Introduction 
  81.  
  82. An Mbone session directory is used to advertise multimedia conferences,
  83. and to communicate the session addresses (whether multicast or unicast)
  84. and conference-tool- specific information necessary for participation.
  85. Such sessions can be announced using the Session Announcement Protocol
  86. (SAP) described in a companion draft [1]. The SAP protocol [1] allows
  87. for the incorporation of authentication of the announcement originator,
  88. and for privacy of the session details; however neither the choice of
  89. authentication algorithms used, nor the mechanisms for encrypting the
  90. SAP Session Description, are detailed in the draft.  
  91.  
  92. This document describes the format of the authentication header for
  93. SAP data packets that use security services based on PGP [2] orPKCS#7
  94. [3].  The format based loosely on PKCS#7 is referred to as Simple
  95. Public Key Format.  Appendix C contains further details of PKCS#7
  96. format security and possible future implementation plans. The SAP
  97. document also provides the confidentiality services required for the
  98. SAP payload [4], which describes the conference set-up parameters. This
  99. document describes how hybrid symmetric and public key encryption
  100. algorithms should be used to provide private announcements.  
  101.  
  102. Much of this document is concerned with security considerations; these
  103. security considerations have not yet been subject to suitable
  104. peer-review, and this document should not be considered authoritative
  105. in this area.
  106.  
  107. 2. Authentication and Encryption of Session Announcement 
  108.  
  109. 2.1 Introduction 
  110.  
  111. It is necessary to provide authentication and integrity of the Session
  112. Announcement to ensure that only authorised persons modify Session
  113. Announcements and to provide facilities for announcing securely
  114. encrypted sessions - providing the relevant proposed conferees with the
  115. means to decrypt the data streams. The Session Announcements are made
  116. to announce to all potential conferees the existence of a conference.
  117. It has, however, another function - to try to minimise conflicts for
  118. Mbone resources by spreading out the number of simultaneous
  119. conferences. Thus there are a number of threats which we must try to
  120. address in the securing of the Session Announcement, and some
  121. constraints. These include the following:
  122.  
  123.   - Authentication and Integrity of Session Announcement 
  124.   
  125.    Here it is necessary to ensure that the Session Announcement comes
  126.    from the person claimed, and is indeed an authorised announcement.
  127.    Since subsequent announcements will modify caches of future
  128.    conferences, it is possible otherwise to spoof an original
  129.    announcement, and thereby at least cause a Denial of Service attack;
  130.  
  131.  
  132. Kirstein et al.    Document Expiration 26 September 1997     [PAGE 3]
  133.  
  134. INTERNET-DRAFT                                            March 26 1997
  135.  
  136.   - Confidentiality of Conference Details for Session Announcement 
  137.  
  138.     Here it is at least necessary to hide the details of the tools
  139.     used.  Because of the desire to minimise schedule conflicts, it is
  140.     desirable to keep at least the time of a conference known, even if
  141.     all other details are concealed.
  142.  
  143. Three types of announcement will be supported:  unsecured,
  144. authenticated, authenticated and encrypted. The authenticated and the
  145. authenticated and encrypted types are described below. The exact
  146. formats depend on whether the PGP [2] or Simple Public Key mechanisms
  147. are used, but this detail is elaborated in Section 3.2 and 3.3.
  148.  
  149. 2.2 Authenticated Announcements 
  150.  
  151. A message digest of the announcement is calculated by the announcement
  152. originator.  The originators secret key is used to encrypt the message
  153. digest and an electronic timestamp, thus forming a digital signature,
  154. or signature certificate. The originator sends the digital signature
  155. along with the message; the receiver receives the message and the
  156. digital signature, and recovers the original message digest from the
  157. digital signature by decrypting it with the sender's public key. The
  158. receiver computes a new message digest from the message, and checks to
  159. see if it matches the one recovered from the digital signature. If it
  160. matches, then that proves the message was not altered, and that it came
  161. from the originator who owns the public key used to check the
  162. signature.
  163.  
  164. The digital signature service involves the use of a hash code, or
  165. message digest, algorithm, a public-key encryption algorithm, and the
  166. private component of a public key pair and a timestamp. The sequence is
  167. as follows:
  168.  
  169.  -  the originator creates a payload 
  170.  -  the originator generates a hash of the payload and timestamp 
  171.  -  the originator encrypts the hash code using his own or the
  172.     conference groups private key
  173.  -  the encrypted hash code and the public key are pre-pended to the
  174.     payload the receiver decrypts the hash code using the public key
  175.     received.  
  176.  -  the receiver generates a new hash code for the received payload
  177.     and timestamp and compares it to the decrypted hash code. If the
  178.     two match, the payload is accepted as authentic.
  179.  
  180. To save space in the announcement message, optionally only a public key
  181. identifier need be included; it is then assumed that the public key
  182. identifier, and the public key, have been distributed previously, or
  183. can be retrieved from a cache or directory.  Provided the Public Key
  184. already exists in such a form, or is distributed with the announcement,
  185. one can be sure that the same originator sent the announcement. Only if
  186. the full public key information, and a Certificate Authority
  187. infrastructure, are accessible [5], can the originator be identified.
  188.  
  189. Kirstein et al.    Document Expiration 26 September 1997    [PAGE 4]
  190.  
  191. INTERNET-DRAFT                                           March 26 1997
  192.  
  193. 2.3  Encrypted Announcements 
  194.  
  195. 2.3.1 Use of Symmetric Encryption
  196.  
  197. Algorithms Announcements may be encrypted using a symmetric encryption
  198. stage to provide security. If this mechanism is used, a random Session
  199. Encryption Key (SEK) must be generated and conveyed in advance to the
  200. intended participants of a conference group.  This process takes place
  201.  
  202. out-of-band and is not described in this draft. Session announcements
  203. may then be made to the appropriate session announcement address,
  204. encrypted so that they can be decrypted only by recipients previously
  205. authorised by being provided with the SEK. Many symmetric encryption
  206. algorithms, e.g. DES [6], are known to be easy to break. For this
  207. reason, and to improve security, a set of SEKs may be distributed
  208. out-of-band, and the recipients may then try to decrypt the
  209. announcement by trying each of the set of SEKs. To improve the
  210. efficiency of this process, an Encryption Key Identifier (EKID), and an
  211. Encryption Algorithm Identifier (EAID) are normally distributed with
  212. the SEK. This (EKID, EAID, SEK) triplet uniquely identifies the
  213. mechanism and parameters required to decrypt the Session Announcement.
  214. Use of Key Identifiers is undesirable if different sessions are to be
  215. announced using the same DES key.
  216.  
  217. 2.3.2 Use of Hybrid Encryption Public Key Algorithms Together With
  218. Symmetric Ones 
  219.  
  220. The (EKID, EAID, SEK) triplet must be received, and possibly cached by
  221. all the authorised parties prior to the reception of the SAP
  222. announcement. The process of ensuring the receipt, managing the cache,
  223. and trying several keys can be relatively complex and expensive; for
  224. this reason the number of such triplet that must be distributed should
  225. be minimised. One mechanism for minimising the number of triplet
  226. required is to use Public Key Cryptography as in the Authenticated
  227. Announcements of Section 2.2. It would be possible to use these
  228. encryption algorithms on the whole announcement message; this would,
  229. however, be inefficient because the asymmetric encryption algorithms
  230. normally use much longer encryption keys, and are much more
  231. resource-intensive, than the symmetric ones. For this reason it is more
  232. efficient to use a combination of symmetric and Public Key algorithms.
  233. Now a random Session Encryption Key (SEK) is generated as in Section
  234. 2.3.1. A Privacy Header (PH) is constructed containing the SEK, which
  235. is encrypted with the asymmetric encryption algorithm. It is now
  236. necessary to distribute a quadruplet of {Encryption Key Identifier
  237. (EKID), Encryption Algorithm Identifier (EAID), Secret Group Key (SGK)
  238. and Public Group Key (PGK)} i.e. {EKID,EAID,SGK,PGK} to identify
  239. uniquely the mechanism and parameters required to decrypt the SEK.
  240. However, this quadruplet needs to be distributed only once as long as
  241. the group membership does not change; it is possible to re-use the same
  242. group keys for many sessions, with different SEKs. This minimises the
  243. number of times the prior key distribution sequence must be followed.
  244.  
  245.  
  246. Kirstein et al.    Document Expiration 26 September 1997    [PAGE 5]
  247.  
  248. INTERNET-DRAFT                                           March 26 1997
  249.  
  250. It should be noted that because a Group Key is used in the above, it is
  251. not possible to use the same Header to authenticate the sender
  252. uniquely; though it is authenticated automatically that the sender is
  253. one of the group which has reserved the asymmetric encryption key
  254. pair.  By using a different Authentication Key for the authentication
  255. of Section 2.2 from the Encryption Keys of this section, it is possible
  256. to still authenticate the identity of the sender.
  257.  
  258. 2.3.3  Encrypting Announcements 
  259.  
  260. We will now provide some more detail.  If the payload is to be
  261. compressed, this is performed prior to encryption .
  262.  
  263. When an announcement is to be encrypted, the payload is encrypted using
  264. symmetric encryption. In this case each such encryption key is used
  265. only once; a new Session Encryption Key (SEK) is generated as a random
  266. number for each announcement. Since it is to be used only once, the SEK
  267. is bound to the message and transmitted with it in a Privacy Header.
  268. The sequence is as follows:  The Privacy Header contains the SEK,
  269. encrypted with the groups Public Group Key, together with the groups
  270. Public Key Identifier (PGKID).  This is followed by the encrypted
  271. Payload.
  272.  
  273. 2.3.4  Decrypting Announcements 
  274.  
  275. Upon receiving a new announcement with the encryption bit set, a
  276. receiver should attempt to decrypt the announcement with its group
  277. private key or its own private key - as indicated by the PGKID.  
  278.  
  279. The sequence is as follows:
  280.  
  281.   - The receiving participants derive the Secret Group Key (SGK) and the
  282.     group key algorithm from the Public Group Key Identifier and its
  283.     related information which has been distributed previously.
  284.  
  285.   - They then decrypt the Session Encryption Key (SEK) with the SGK and
  286.     obtain the Encryption Algorithm Identifier (EAID) from the Privacy
  287.     Header.
  288.  
  289.   - The authorised receivers extract the text payload by using the SEK
  290.     and the relevant symmetric decryption algorithm to decrypt the
  291.     encrypted text payload.
  292.  
  293. Note that if an encrypted announcement is being announced via a proxy,
  294. then there may be no way for the proxy to discover that the
  295. announcement has been superseded, and so it may continue to relay the
  296. old announcement in addition to the new announcement. SAP provides no
  297. mechanism to chain modified encrypted announcements, so it is advisable
  298. to announce the unmodified session as deleted for a short time after
  299. the modification has occurred. This does not guarantee that all proxies
  300. have deleted the session, and so receivers of encrypted sessions should
  301. be prepared to discard old versions of session announcements that they
  302. may receive (as identified by the SDP version field). In most cases
  303. however, the only stateful proxy will be local to (and known to) the
  304. sender, and an additional (local-area) protocol involving a handshake
  305. for such session modifications can be used to avoid this problem.
  306.  
  307. Kirstein et al.    Document Expiration 26 September 1997    [PAGE 6]
  308.  
  309. INTERNET-DRAFT                                           March 26 1997
  310.  
  311. 2.3.5 Encryption Algorithm Identifier (EAID)
  312.  
  313. This is an 8-bit integer which is mentioned in Sections 2.3.1 and
  314. 2.3.2. It is distributed with the Key ID in the form of: {Encryption
  315. Key ID, Encryption Algorithm ID, Encryption Key(s)}
  316.  
  317. It is used for three purposes: to determine whether symmetric or
  318. asymmetric encryption is used, to specifiy the encryption algorithm,
  319. and to specify the encryption key length. For this reason, its format
  320. is given below:
  321.  
  322. BIT   0     1      2      3      4      5       6        7
  323.     TYPE       ALGORITHM                   LENGTH
  324.  
  325.  
  326. TYPE (1 bit) can take the values 0 or 1; the former is symmetric, the
  327. latter Public Key
  328.  
  329. ALGORITHM (3 bits) denotes the encryption Algorithm, further details
  330. are given in Section 3.3.6.
  331.  
  332. LENGTH (4 bits) denotes the key length; further details are given in
  333. Section 3.3.6
  334.  
  335. 3. Secured SAP Packet Formats 
  336.  
  337. Both Authentication and Confidentiality can be achieved using PGP [2]
  338. or Simple Public Key format packets.  These formats are explained in
  339. greater detail below. In Section 3.1 we discuss the generic packet
  340. format defined in [1]; this is still only at the draft stage, so any
  341. changes in it will have to be tracked in future versions of this
  342. document. In Section 3.2 we consider the formats of the Authentication
  343. Header, and in Section 3.3 that of the Text Payload.
  344.  
  345. It would be possible to define our own versions of the packets
  346. completely for this application. In that case the formats would be
  347. simpler, but all the implementations would have to be coded using the
  348. basic encryption libraries, and a new infrastructure would have to be
  349. defined. Both PGP and PKCS#7 already have complete implementations; by
  350. using their formats, several application tool kits are already
  351. available (e.g. ENTRUST [14], SECUDE [15]). In addition, these formats
  352. also have complete infrastructures defined around them. For these
  353. reasons, we have chosen to retain enough compatibility to ease the
  354. eventual implementation, while simplifying the formats as far as
  355. possible within such a constraint. There is an additional advantage in
  356. this approach; it will be possible to send session announcements by the
  357. encrypted Session Invitation Protocol or by electronic mail using PGP
  358. or S-MIME, and re-use much of the same code as with SAP.
  359.  
  360. Kirstein et al.    Document Expiration 26 September 1997    [PAGE 7]
  361.  
  362. INTERNET-DRAFT                                           March 26 1997
  363.  
  364. 3.1 SAP Packet Format 
  365.  
  366. The SAP data packets as defined in [1] is of the following format:
  367.  
  368.                          1                   2                   3
  369. BIT  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  370.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  371.     | V=2 | MT  |E|C| Header Length |       16 bit Message ID Hash  |
  372.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  373.     |                     Originating Source                        | 
  374.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
  375.     |              Authentication Header (Optional)                 | 
  376.     |                       ...                                     |
  377.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  378.     |                       Encryption Key id (Optional)            |
  379.     |                                                               |
  380.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  381.     |                       32 bit Time-Out Field (Optional)        |
  382.     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  383.     |                       Text Payload (Possibly Encrypted)       |
  384.     |                    ..................                         |
  385.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  386.  
  387. Notes:  
  388.  
  389. V: Version Number (3 bits). This is 2 for  SAP [1] 
  390.  
  391. MT: Message Type
  392.  The value being either:  
  393.  
  394.      0. Session description announcement packet.  The text payload is
  395.      an SDP session description, as described in [4].
  396.  
  397.      1. Session description deletion packet. The text payload is a
  398.      single SDP line consisting of the origin field of the announcement
  399. to be deleted
  400.  
  401. E: Encryption Bit -.If the encryption bit is set, the text payload of
  402.    the SAP is encrypted
  403.  
  404. C: Compressed bit - This bit indicates that the payload was compressed
  405.    using the gzip compression utility [7]
  406.  
  407. Header length 
  408.  
  409.     This is an 8 bit unsigned quantity giving the number of 32 bit
  410.     words following the main SAP header that contains the
  411.     authentication data . If this is non-zero, the payload is
  412.     authenticated, and an Authentication Header is present.
  413.  
  414. Kirstein et al.    Document Expiration 26 September 1997    [PAGE 8]
  415.  
  416. INTERNET-DRAFT                                           March 26 1997
  417.  
  418. Message Identifier Hash 
  419.  
  420.     A 16 bit quantity that, when used in combination with the
  421.     originating source, provides  a  globally  unique id identifying
  422.     the precise version of this announcement.  The message id hash
  423.     should be changed if any field of the session description  is
  424.     changed.  A value of zero means that the hash should be ignored and
  425.     the message should always be parsed.
  426.  
  427. Originating Source 
  428.  
  429.     This 32 bit field gives the IP address of the original source of
  430.     the message.  It is permissible for this to be  zero  if the
  431.     message has not passed through a proxy relay and if the message id
  432.     hash is also zero. This  is intended for backwards compatibility
  433.     with SAPv0 clients only.
  434.  
  435. Authentication Header 
  436.  
  437.     The authentication Header can be used for two purposes:
  438.  
  439.       - Verification that changes to a session description or deletion
  440.         of  a session are permitted.
  441.  
  442.       - Authentication of the identity of the session creator.  
  443.  
  444.     In some circumstances only verification is possible because  a
  445.     certificate signed by a mutually trusted person or authority is not
  446.     available.  However, under such circumstances, the session
  447.     originator can still  be authenticated  to be the same as the
  448.     session originator of previous sessions claiming to be from the
  449.     same person.  This may or may not be sufficient, depending on the
  450.     purpose of the session and the people involved. The format of the
  451.     Authentication Header is discussed in Section 3.2
  452.  
  453. Encryption Key Identifier
  454.  
  455.     This is a 32 bit network byte integer which can be used to identify
  456.     the triplet or quadruplet described Section 2.3.1 and 2.3.2 of
  457.     {Encryption Key Identifier, Encryption Algorithm Identifier,
  458.     Encryption Key(s)}.  PGP uses a 64-bit Key Identifier in its
  459.     Software. [ It would be more consistent if we used 64-bit Key
  460.     Identifiers throughout. However, this would require a corresponding
  461.     change in the SAP document [1] ].
  462.  
  463.     If  the Encryption Algorithm Identifier Type is 0, then the
  464.     encryption is symmetric. A triplet is distributed out-of-band with
  465.     a singe symmetric key, and the methods of Section 2.3.1 are
  466.     applied.
  467.  
  468.     If  the Encryption Algorithm Identifier Type is 1, then the
  469.     encryption is hybrid. A quadruplet is distributed out-of-band with
  470.     a secret/public key pair, and the methods of Section 2.3.2 are
  471.     applied.
  472.  
  473. Kirstein et al.    Document Expiration 26 September 1997    [PAGE 9]
  474.  
  475. INTERNET-DRAFT                                           March 26 1997
  476.  
  477.     Key IDs are generated when a new key or key pair is chosen. For
  478.     Symmetric Encryption Keys, the Key IDs should be randomly
  479.     distributed.  For Asymmetric Encryption Keys, the Key ID is related
  480.     algorithmically to the Public Group Key; further details are given
  481.     in Sections 3.2.2 and 3.2.3.
  482.  
  483.     Use of the Encryption Key Identifier is not recommended if
  484.     different sessions are to be announced with the same DES key.
  485.  
  486. Time-out 
  487.  
  488.      When the session payload is encrypted, and the session description
  489.      is being relayed or announced via a proxy, the detailed timing
  490.      fields in the SDP description are not available to the proxy.
  491.      This is because these fields are encrypted and  the  proxy is not
  492.      trusted with the decryption key. Under such circumstances, SAP
  493.      includes an additional 32-bit timestamp field stating when the
  494.      session should be timed out. The digital signature in the
  495.      authentication header encompasses the time-out so that a session
  496.      cannot be maliciously deleted by modifying its time-out in an
  497.      announcing proxy. The value is an unsigned quantity giving the NTP
  498.      time [8] in seconds at which time the session is timed out.  It is
  499.      in network byte order
  500.  
  501. Text Payload 
  502.  
  503.      When there is no encryption, the encryption bit is not set and
  504.      this format is as defined in the SDP [4] draft.
  505.  
  506. Encrypted Text Payload 
  507.  
  508.     This is present when the text payload has been encrypted. The
  509.     format is discussed in Section 3.3.
  510.  
  511. 3.2 Authentication Header 
  512.  
  513. 3.2.1 Generic Format 
  514.  
  515. The generic format of the Authentication Header is given below. We have
  516. defined it both using the PGP and the Simple Public Key mechanisms.
  517.  
  518.                          1                   2                   3
  519. BIT 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  520.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  521.     | V=1 |P| Auth|                                                 |
  522.     |+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  523.     |           Format Specific Authentication Subheader            |
  524.     |                    ..                                         |
  525.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  526.  
  527. V: Version number 
  528.  
  529.     The SAP Authentication Header version number is 1 for this
  530.     release.(3 bits)
  531.  
  532. Kirstein et al.    Document Expiration 26 September 1997   [PAGE 10]
  533.  
  534. INTERNET-DRAFT                                           March 26 1997
  535.  
  536. P: Padding Bit 
  537.  
  538.     If necessary the data in the Authentication Header is padded to be
  539.     a multiple of 32 bits and the Padding bit is set. In this case the
  540.     last byte of the Authentication Header contains the number of
  541.     padding bytes (including the last byte) that must be discarded.
  542.  
  543. Auth 
  544.  
  545.     The Authentication Type is a 4 bit encoded field that denotes the
  546.     authentication infrastructure the sender expects the recipients to
  547.     use to check the authenticity and integrity of the information.
  548.     This defines the format of the Authentication Subheader and can
  549.     take the values:
  550.  
  551.     1       PGP including the public key identifier 
  552.     2       Simple Public Key Format including the public key
  553.             identifier
  554.         3       PGP with the public key included 
  555.     4       Simple Public Key Format with the public key included
  556.         5       PGP with the certificate included 
  557.         6       Simple Public Key Format with the certificate included
  558.  
  559. The specific formats for the PGP and Simple Public Key variants of the
  560. Header are discussed in Sections 3.2.2 and 3.2.3.  
  561.  
  562. 3.2.2 PGP Format 
  563.  
  564. The generic description of the PGP packets is presented in [2]. For PGP
  565. the basic Authentication Subheader comprises a digital signature packet
  566. as below.  This involves the use of a hash code, or message digest
  567. algorithm, and a public key encryption algorithm.  The format for
  568. applying PGP to the payload for authentication purposes is discussed
  569. below. For case 1 the Authentication Subheader contains a Digital
  570. Signature Packet only. For cases 3 and 5 a Public Key Packet or a
  571. Certificate Packet are also contained respectively. These are defined
  572. in Appendix B and [2].
  573.  
  574. Digital Signature Packet:
  575.  
  576.      a) packet structure field (2, 3, or 5 bytes); 10001000(1 byte plf)
  577.      10001001 (2 byte plf) 10001010(4 byte plf) plf packet length field
  578.  
  579.      b) version number = 2 or 3 (1 byte);          (3) 
  580.  
  581.      c) length of following material included in MD calculation (1
  582.         byte, always value 5);                     (5)
  583.  
  584.      d) (d1) signature classification (1 byte); (hex value 00 document)
  585.     (d2) signature time stamp (4 bytes);    (time of signing)
  586.  
  587.      e) key ID for key used for signing (8 bytes); 
  588.  
  589. Kirstein et al.    Document Expiration 26 September 1997   [PAGE 11]
  590.  
  591. INTERNET-DRAFT                                           March 26 1997
  592.  
  593.      f) public-key-cryptosystem (PKC) type (1 byte);  (1      RSA) 
  594.  
  595.      g) message digest algorithm type (1 byte);       (1      MD5) 
  596.  
  597.      h) first two bytes of the MD output, used as a checksum (2 bytes);
  598.  
  599.      i) a byte string of encrypted data holding the RSA-signed digest.
  600.  
  601.  
  602.      The length of field (a) depends on the size of the key used for
  603.      signing. If 512, 768 or 1024 then the length will be 2 ,3 or 5
  604.      respectively. The first byte is Cipher Type Byte (CTB) and its
  605.      value is 10001000 for key size 512, 10001001 for key size 768 and
  606.      10001010 for key size 1024. The remaining 1,2 or 4 bytes of the
  607.      packet structure field gives the length of the packet.  
  608.  
  609.      The length of RSA signed digest of (i) also depends on the size of
  610.      the key used. For keys 512, 768 or 1024 the size is 64, 96 or 128
  611.      bytes respectively
  612.  
  613. 3.2.3 Simple Public Key Format
  614.  
  615. The generic description of the PKCS#7 packets is presented in [3]. For
  616. the Simple Public Key format the basic Authentication Subheader is as
  617. follows:
  618.  
  619.                          1                   2                   3
  620. BIT 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  621.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  622.     | DA    | E A I D   |                                           |
  623.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  624.     |                   64 bit key identifier                       |
  625.     |                    ..                                         |
  626.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  627.     |                    128 bit payload digest                     |
  628.     |                    ..                                         |
  629.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  630.     |                     Time Stamp                                | 
  631.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  632.     |                     Encrypted block                           |
  633.     |                    ..                                         |
  634.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  635.  
  636. Notes
  637.  
  638. DA, the Digest Algorithm Identifier (5 bits), specifies the
  639.     algorithm used to digest the data. This can currently have the
  640.     following values:
  641.  
  642.         1 - RSA's MD2 algorithm as defined in RFC 1319.
  643.     2 - RSA's MD5 algorithm as defined in RFC 1321 
  644.         3 - The SHA Secure Hash Algorithm
  645.  
  646. Kirstein et al.    Document Expiration 26 September 1997   [PAGE 12]
  647.  
  648. INTERNET-DRAFT                                           March 26 1997
  649.  
  650. EAID, the Encryption Algorithm Identifier(1 byte), specifies the
  651.     algorithm used to encrypt the digest with the originator's secret
  652.     key.  Strictly speaking this field is optional as it is already
  653.     uniquely specified by the Key Identifier which points to a
  654.     quadruplet which has already been distributed out-of-band. It is
  655.     repeated here solely for compatibility reasons.
  656.  
  657.     Key Identifier (EKID) is the 64 least significant bits of the
  658.     public key of the originator. In the PKCS#7 standard the key is
  659.     identified by specifying the "issuerAndSerialNumber" of the
  660.     certificate containing the public key. This has two fields namely
  661.     the Distinguished Name of the Certificate Issuer and the serial
  662.     Number of the Certificate. The Distinguished Name can be
  663.     arbitrarily long, being a sequence of Relative Distinguished Names,
  664.     and the Serial Number is simply an integer. This was considered to
  665.     be too long and the 64-bit key identifier, as used in PGP, was
  666.     thought to provide the necessary information.
  667.  
  668. Payload Digest is the 128 bit output from digesting the payload
  669.     with the DA.
  670.  
  671. Time Stamp is in NTP Time Format as specified in RFC1119 [8].
  672.  
  673. Encrypted Block: The input to the digest encryption process starts
  674.     at the beginning of the Authentication Subheader and continues
  675.     until the end of the UTCTime field.  If the Digest Encryption
  676.     Algorithm is rsaEncryption the block type is 01 as specified for
  677.     PEM message digest encryption in RFC1423.
  678.  
  679. If the Authentication Type is 4 or 6 then either a public key or a
  680. certificate is included after the basic Subheader.
  681.  
  682. 3.3 Encrypted Payload Format 
  683.  
  684. 3.3.1 Generic Format
  685.  
  686. The format of the Encrypted Payload depends on the type of encryption
  687. used to encrypt the SDP text payload [4]. If no encryption has been
  688. used only the Text payload is present. If encryption has been used then
  689. the Encryption Key Identifier field points to either a triplet for
  690. symmetric encryption or a quadruplet for asymmetric encryption.
  691.  
  692.  
  693. 3.3.2 Symmetric Encryption
  694.  
  695.  
  696. If the Encryption Algorithm Identifier indicates use of symmetric
  697. encryption, ie the first bit is zero, then the payload has  been
  698. encrypted symmetrically with no use of asymmetric encryption. In
  699. addition  the encrypted payload has a random field added prior to
  700. encryption as below:
  701.  
  702. Kirstein et al.    Document Expiration 26 September 1997  [PAGE 13]
  703.  
  704. INTERNET-DRAFT                                           March 26 1997
  705.  
  706.  
  707.                          1                   2                   3
  708. BIT 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  709.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  710.     | P|                    31 bit random field                     |
  711.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  712.     |                        text payload                           |
  713.     |                            .......                            |
  714.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  715.  
  716.  
  717.  
  718. Notes 
  719.  
  720. Random Field 
  721.  
  722.     This field is only present when payload is encrypted using
  723.     symmetric encryption and is used to perform the randomisation task
  724.     normally performed by an initialisation vector in algorithms such
  725.     as DES. This 31 bit field should contain a genuinely random
  726.     number.  
  727.  
  728. P: Encryption Padding Bit 
  729.  
  730.     This bit indicates that the payload was padded prior to encryption.
  731.     The last byte of the encrypted payload indicates how many padding
  732.     bytes were added.
  733.  
  734. The data following the Timeout field is decrypted using the algorithm
  735. specified above.  Further details on the encryption algorithms are
  736. given in [6, 12, 13].
  737.  
  738. 3.3.3 Hybrid Encryption
  739.  
  740. If the value of the first bit of the Encryption Algorithm Identifier is
  741. set to 1, then hybrid encryption is used; currently only those based on
  742. PGP or Simple Public Key formats are defined for the asymmetric
  743. portions. In these cases a Privacy Header (PH) is placed in front of
  744. SDP stream, which contains a Session Encryption Key (SEK).
  745.  
  746. In the PGP case there is no need for the Symmetric Encryption Algorithm
  747. to be specified as this is always IDEA. The formats for the PGP and
  748. Simple Public Key type privacy headers are as below.
  749.  
  750.  
  751. 3.3.4 PGP Format Privacy Header
  752.  
  753. If the value of the Encryption Algorithm Identifier Algorithm is 1 then
  754. the PGP format is used. In this case the Privacy Header is composed of
  755. a Public Key Encrypted Packet. The purpose of this packet is to convey
  756. the one-time session key used to encrypt the message to the recipient
  757.  
  758. Kirstein et al.    Document Expiration 26 September 1997   [PAGE 14]
  759.  
  760. INTERNET-DRAFT                                           March 26 1997
  761.  
  762. in a secure manner. This is done by encrypting the session key  with
  763. the group public key so that only a member of the group can recover the
  764. session key. (Note that plf is the packet length field)
  765.  
  766. Public Key Encrypted Packet:
  767.  
  768.                                                              76543210
  769.      a) a packet structure field;  (2,3,5 bytes))            10000100
  770.      (1 byte plf) 10000101(2 byte plf) 10000110 (4 byte plf)
  771.  
  772.      b) a byte, giving the version number, 2 or 3; (1byte)           3 
  773.  
  774.      c) a number ID field, giving the ID of a key; (8bytes) 
  775.  
  776.      d) a byte, giving a PKC number; (1byte)         (1      RSA) 
  777.  
  778.      e) a byte string of encrypted data (DEK).  (64, 96 or 128 bytes)
  779.  
  780.  
  781. 3.3.5 Simple Public Key Format Privacy Header 
  782.  
  783. If the value of the Encryption Algorithm Identifier Algorithm is 2 then
  784. the Simple Public Key Format is used. In this case the Privacy Header
  785. is as follows:
  786.  
  787.  
  788.  
  789.                          1                   2                   3
  790. BIT 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  791.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  792.     |   NGTH      |  E A I D 1    | E A I D 2   |                   | 
  793.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  794.     |         Encrypted Session Encryption Key                      |
  795.     |              ............                                     |
  796.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  797.  
  798. Notes
  799.  
  800. LENGTH, (1 byte) this specifies the length of the Privacy Header
  801.  
  802. EAID1, the (asymmetric) Encryption Algorithm Identifier (1 byte)
  803.    identifies the asymmetric algorithm used to encrypt the Session
  804.    Encryption Key (SEK). The values this can take are specified in
  805.    Section 3.3.6. Strictly speaking this is not necessary as it has
  806.    already been completely specified by the Key Identifier in the main
  807.    SAP header. It is duplicated here for compatibility reasons.
  808.  
  809. EAID2, the (symmetric)Encryption Algorithm Identifier (1 byte)
  810.    identifies the symmetric algorithm used to encrypt the content. The
  811.    values this can take are specified in Section 3.3.6.
  812.  
  813. Kirstein et al.    Document Expiration 26 September 1997  [PAGE 15]
  814.  
  815. INTERNET-DRAFT                                           March 26 1997
  816.  
  817. Encrypted Session Encryption Key: This field contains the encrypted
  818.    SEK. When the Key Encryption Algorithm is rsaEncryption the block
  819.    type is specified to be 2.
  820.  
  821. 3.3.6 Supported Algorithms
  822.  
  823. For the authentication the following Message Digest Algorithms are
  824. defined.  Simple Public Key Format packets can use any of the specified
  825. types but PGP always uses MD5.
  826.  
  827.         
  828.         Message Digest Type             Algorithm
  829.         
  830.                 1                          MD5
  831.                 2                          MD2
  832.                 3                          SHA
  833.  
  834. For the Encryption Algorithm Identifier there are several Algorithms
  835. supported for both Symmetric and Asymmetric Encryption. For Symmetric
  836. Encryption the first bit is set to 0 and for Asymmetric Encryption it
  837. is set to 1. The next 3 bits specify the Algorithm and the final four
  838. bits denote the key size used. The following Algorithm Identifiers  are
  839. currently defined:
  840.  
  841.     EAID                Algorithm               ALG        Key Length
  842.     00010010               DES                   1            56 bits
  843.     00100011            Tiple DES                2            112 bits 
  844.     00110100              IDEA                   3            128 bits 
  845.     01000100               RC2                   4            128 bits
  846.     01010100               RC4                   5            128 bits
  847.  
  848.  
  849.     10010101              RSA/PGP                1            256 bits 
  850.     10010110              RSA/PGP                1            512 bits 
  851.     10010111              RSA/PGP                1            768 bits 
  852.     10011000              RSA/PGP                1            1024 bits
  853.     10011001              RSA/PGP                1            2048 bits
  854.     10100101              RSA/SPK                2            256 bits 
  855.     10100110              RSA/SPK                2            512 bits 
  856.     10100111              RSA/SPK                2            768 bits 
  857.     10101000              RSA/SPK                2            1024 bits
  858.     10101001              RSA/SPK                2            2048 bits
  859.  
  860. The general format of the Encrypted Payload is given below. Here the
  861. format of the Privacy Header depends on whether PGP or Simple Public
  862. Key (SPK) format is used.  The Encrypted Text Payload is the result of
  863. encrypting the SDP text payload with the Symmetric Encryption Key
  864. specified in the Privacy Header
  865.  
  866.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  867.     |                       Privacy Header                          |
  868.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  869.     |                       Encrypted SDP Payload                   |
  870.     |                          .... ..                              |
  871.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  872.  
  873.  
  874. Kirstein et al.    Document Expiration 26 September 1997  [PAGE 16]
  875.  
  876. INTERNET-DRAFT                                           March 26 1997
  877.  
  878. Appendix A: Authors Addresses
  879.  
  880. Peter Kirstein, Goli Montasser Kohsari and Edmund Whelan are at
  881. University College London and their email-ids are:
  882.  
  883.         P.Kirstein@cs.ucl.ac.uk 
  884.         G.Montasser-Kohsari@cs.ucl.ac.uk
  885.         E.Whelan@cs.ucl.ac.uk
  886.  
  887.     Dept of Computer Science 
  888.         University College London 
  889.         Gower Street
  890.         London WC1E 6BT England
  891.  
  892.  
  893.  
  894.  
  895. Kirstein et al.    Document Expiration 26 September 1997  [PAGE 17]
  896.  
  897. INTERNET-DRAFT                                           March 26 1997
  898.  
  899.  
  900. Appendix B: PGP format
  901.  
  902.  
  903. Public key Packet
  904.  
  905.     a) Packet structure field (2 3 5 bytes)                 100110 (As
  906.     defined in 1)
  907.  
  908.     b) version number = 2 or 3 (1byte)                      (3) 
  909.  
  910.     c) time stamp of key creation (4bytes) 
  911.  
  912.     d) validity period in days (2 bytes)                (0 means forever) 
  913.  
  914.     e) public key cryptosystem (PKC) type (1 byte)          (1      RSA) 
  915.  
  916.     f) Multi-precision integer (MPI) of RSA public modulus n; 
  917.  
  918.     g) MPI of RSA public encryption exponent e
  919.  
  920. User ID Packet
  921.  
  922.     a) packet structure field (2 bytes)             01110101 
  923.     b) User Id String                   (users name and email id
  924.     enclosed in <>)
  925.  
  926. Certificate
  927.  
  928.     a) one public key packet                (defined above) 
  929.     b) one or more user ID packets          (defined above) 
  930.     c) Zero or more signature packets       (defined in Section 3.2.2)
  931.  
  932.  
  933.  
  934. Kirstein et al.    Document Expiration 26 September 1997   [PAGE 18]
  935.  
  936. INTERNET-DRAFT                                           March 26 1997
  937.  
  938. Appendix C: PKCS#7 format
  939.  
  940. It is expected that an Authentication Subheader which adheres to the
  941. PKCS#7 standard will be implemented in a later version of the SAP
  942. header protocol.  This would enable compatibility between information
  943. contained in the  Authentication Subheader and S/MIME MUAs for example.
  944. In this version of the  standard it was considered that, although we
  945. wanted to follow the PKCS  standards fairly closely, we did not want to
  946. force developers to implement  full ASN.1 typing and BER encoding.  The
  947. header detailed in the main document follows PKCS#7  in principle as it
  948. contains similar fields. One difference is the use of a Key Identifier
  949. rather than "issuerAndSerialNumber" as detailed above. Also, Object
  950. Identifiers were not used here.
  951.  
  952. In a PKCS#7 compliant SAP protocol it would be expected that the
  953. Authentication Subheader would consist of an ASN.1 SignerInfo type as
  954. below:
  955.  
  956. SignerInfo ::= SEQUENCE { 
  957.       version                         Version,
  958.       IssuerAndSerialNumber           IssuerAndSerialNumber,
  959.       digestAlgorithm                 DigestAlgorithmIdentifier,
  960.       authenticatedAttributes         [0] IMPLICIT Attributes OPTIONAL,
  961.       digestEncryptionAlgorithm       DigestEncryptionAlgorithmIdentifier,
  962.       encryptedDigest                 EncryptedDigest,
  963.       unauthenticatedAttributes       [1] IMPLICIT Attributes OPTIONAL  }
  964.  
  965. If the Authentication Type is "4"  (PKCS#7 + public key) the public key
  966. would be appended to the Authentication Subheader. This is in a form
  967. equivalent to that defined in PKCS#1 as:
  968.  
  969. RSAPublicKey ::= SEQUENCE { 
  970.        modulus         INTEGER 
  971.        publicExponent INTEGER }
  972.  
  973. If the Authentication Type is "6" (PKCS#7 + certificate) the
  974. certificate would be appended to the Authentication Subheader. This
  975. Certificate is an ASN.1 type as defined in X.509.
  976.  
  977. If asymmetric encryption is used a PKCS#7 compliant Privacy Header
  978. would consist of an ASN.1 RecipientInfo and EncryptedContentInfo type
  979. as below:
  980.  
  981. RecipientInfo ::= SEQUENCE { 
  982.      version                         Version,
  983.      issuerAndSerialNumber           IssuerAndSerialNumber, 
  984.      keyEncryptionAlgorithm          KeyEncryptionAlgorithmIdentifier, 
  985.      encryptedKey                    EncryptedKey }
  986.  
  987. EncryptedContentInfo ::= SEQUENCE { 
  988.      contentType                     ContentType, 
  989.      contentEncryptionAlgorithm    ContentEncryptionAlgorithmIdentifier, 
  990.      encryptedContent              [0] IMPLICIT EncryptedContent OPT }
  991.  
  992.  
  993.  
  994. Kirstein et al.    Document Expiration 26 September 1997  [PAGE 19]
  995.  
  996. INTERNET-DRAFT                                           March 26 1997
  997.  
  998. Acknowledgements
  999.  
  1000. SAP and SDP were originally based on the protocol used by the sd
  1001. session directory from Van Jacobson at LBNL. The design of SAP was
  1002. funded by the European Commission under the Esprit 7602 "MICE" project,
  1003. and the Telematics 1007 "MERCI" project.
  1004.  
  1005. References 
  1006. [1] M.Handley  `SAP: Session Announcement Protocol'' INTERNET-DRAFT,
  1007.     draft-ietf-mmusic-sap-00.txt, 11/27/1996.
  1008.  
  1009. [2] D.Atkins, '' PGP Message Exchange Formats'' , RFC 1991, August
  1010.     1996.
  1011.  
  1012. [3] PKCS#7, Cryptographic Message Syntax Standard, RSA Laboratories,
  1013.     Version 1.5, November 1993
  1014.  
  1015. [4] M.Handley, V. Jacobson, ``SDP: Session Description Protocol'',
  1016.     INTERNET-DRAFT, draft-ietf-mmusic-sdp-02.txt, 11/27/1996.
  1017.  
  1018. [5] R. Housley , W. Ford , T. Polk Internet public Key  Infrastructure
  1019.     INETRNET- DRAFT, draft-ietf-pkix-ipki-part1-03.txt December 1996.  
  1020.  
  1021. [6] National Bureau of Standards, Data Encryption Standard, Federal
  1022.     Information Processing Standards Publication 46, January 1977 
  1023.  
  1024. [7] P.  Deutsch, ``GZIP file format specification version 4.3'', RFC
  1025.     1952, May 1996.
  1026.  
  1027. [8] D. Mills, ``Network Time Protocol version 2 specification and
  1028.     implementation", RFC1119, 1st Sept 1989.
  1029.  
  1030. [9]X.208 Specification of
  1031.     Abstract Syntax Notation One (ASN.1) ITU-T Recommendations 1988 
  1032.  
  1033. [10] PKCS #1    RSA Encryption Standard RSA Laboratories, Version 1.5,
  1034.     November 1993 
  1035.  
  1036. [11] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with
  1037.     Minimal Control'', RFC 1890, January 1996 
  1038.  
  1039. [12] P.  Metzger, P. Karn, W.  Simpson,  The ESP Information Triple
  1040.     DES-CBC Transformation, 10/02/1995 RFC850 
  1041.  
  1042. [13] ANSI X3.92-1981.  American National Standards Data Encryption
  1043.     Algorithm.  American National Standards Institute, Approved 30
  1044.     December 19990
  1045.  
  1046. [14] For details of ENTRUST see http://www.entrust.com/ [15] For
  1047.     details of SECUDE see http://www.darmstadt.gmd.de/secude/
  1048.  
  1049.  
  1050.  Kirstein et al.   Document Expiration:  26 September 1997   [PAGE 20]
  1051.  
  1052.  
  1053.