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-01.txt < prev    next >
Text File  |  1997-07-30  |  37KB  |  885 lines
  1. Internet Engineering Task Force                                MMUSIC WG
  2. Internet Draft                                               P. Kirstein
  3. draft-ietf-mmusic-sap-sec-01.txt                    G. Montasser-Kohsari
  4. July 29th 1997                                                 E. Whelan
  5. Expires: January 29th 1998                     University College London
  6.  
  7.  
  8.     Specification of Security in SAP Using Public Key Algorithms
  9.  
  10.  
  11.                          STATUS OF THIS MEMO
  12.  
  13. This document is an Internet-Draft. Internet-Drafts are working 
  14. documents of the Internet Engineering Task Force (IETF), its areas, and
  15. its working groups. Note that other groups may also distribute working
  16. documents as Internet-Drafts.
  17.  
  18. Internet-Drafts are draft documents valid for a maximum of six months 
  19. and may be updated, replaced, or obsoleted by other documents at any 
  20. time. It is inappropriate to use Internet-Drafts as reference material 
  21. or to cite them other than as ``work in progress.''
  22.  
  23. To learn the current status of any Internet-Draft, please check the 
  24. ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 
  25. Directories  on  ftp.is.co.za (Africa), ftp.nordu.net (Europe), 
  26. munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 
  27. ftp.isi.edu (US West Coast).
  28.  
  29. Distribution of this document is unlimited.
  30.  
  31.  
  32.                 ABSTRACT
  33.  
  34.  
  35. The Session Announcement Protocol (SAP) has been specified in such a way
  36. that authentication and privacy can be assured. However the algorithms 
  37. and mechanisms to achieve such security are not prescribed in the 
  38. current draft. This document extends the SAP protocol, by describing 
  39. specific algorithms and formats of authentication and encryption formats
  40. based on the DES, PGP and PKCS#7 standards. It is a companion document 
  41. to draft-ietf-mmusic-sap.
  42.  
  43. This document is a product of the Multiparty Multimedia Session Control
  44. (MMUSIC) working group of the Internet Engineering Task Force Comments 
  45. are solicited and should be addressed to the working group's mailing 
  46. list at confctrl@isi.edu and/or the authors.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Kirstein et al.                                                [PAGE  1]
  59.  
  60. Internet Draft      Specification of SAP Security          July 29, 1997
  61.  
  62.  
  63.                              GLOSSARY
  64.  
  65.  
  66.    ASN      Abstract Syntax Notation 
  67.    CT       Content Type
  68.    CTB      Cipher Type Byte 
  69.    DA       Digest Algorithm
  70.    DEA      Digest Encryption Algorithm 
  71.    DES      Data Encryption Standards 
  72.    EAID     Encryption Algorithm Identifier
  73.    EK       Encryption Key
  74.    EKID     Encryption Key Identifier
  75.    IETF     Internet Engineering Task Force 
  76.    MD       Message Digest 
  77.    MMUSIC   Multiparty Multimedia Session Control 
  78.    PEM      Privacy Enhanced Mail 
  79.    PGP      Pretty Good Privacy 
  80.    PH       Privacy Header 
  81.    PK       Public Key
  82.    PKCS     Public Key Cryptographic System 
  83.    PKCS     Public Key Cryptography Standard (as in PKCS#7)
  84.    SAP      Session Announcement Protocol 
  85.    SDP      Session Descriptor Protocol
  86.    SEK      Session Encryption Key 
  87.    SK       Secret Key
  88.    SGK      Group Key
  89.    SHA      Hash Algorithm
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117. Kirstein et al.                                                [PAGE  2]
  118.  
  119. Internet Draft      Specification of SAP Security          July 29, 1997
  120.  
  121. 1.  Introduction
  122.  
  123. An Mbone session directory is used to advertise multimedia conferences,
  124. and to communicate the session addresses (whether multicast or unicast)
  125. and conference-tool- specific information necessary for participation. 
  126. Such sessions are be announced using the Session Announcement Protocol 
  127. (SAP) described in a companion draft [1]. The SAP protocol allows for 
  128. the incorporation of authentication of the announcement originator, and 
  129. for privacy of the session details; however neither the choice of 
  130. authentication algorithms used, nor the mechanisms for encrypting the 
  131. SAP Session Description, are detailed in the draft.
  132.  
  133. This document describes the format of the authentication header for SAP 
  134. data packets that use security services based on PGP [2] or PKCS#7 [3].
  135. The SAP document also provides for the confidentiality services required
  136. for the SDP payload [4], which describes the conference set-up 
  137. parameters. This document describes how both symmetric and hybrid 
  138. symmetric/public key encryption algorithms should be used to provide 
  139. private announcements.
  140.  
  141. Much of this document is concerned with security considerations which
  142. have not yet been subject to suitable peer-review, and this document 
  143. should not be considered authoritative in this area.
  144.  
  145. 2.  Authentication and Encryption of Announcements
  146.  
  147. 2.1  Introduction 
  148.  
  149. It is necessary to provide authentication and integrity of the Session 
  150. Announcement to ensure that only authorised persons modify Session 
  151. Announcements and to provide facilities for announcing securely 
  152. encrypted sessions - providing the relevant proposed conferees with the 
  153. means to decrypt the data streams. The Session Announcements are made to
  154. announce to all potential conferees the existence of a conference. It 
  155. has, however, another function - to try to minimise conflicts for Mbone 
  156. resources by spreading out the number of simultaneous conferences. Thus 
  157. there are a number of threats which we must try to address in the 
  158. securing of the Session Announcement, and some constraints. These 
  159. include the following:
  160.  
  161.   - Authentication and Integrity of Session Announcement 
  162.  
  163. Here it is necessary to ensure that the Session Announcement comes from 
  164. the person claimed, and is indeed an authorised announcement. Since 
  165. subsequent announcements will modify caches of future conferences, it is
  166. possible otherwise to spoof an original announcement, and thereby at 
  167. least cause a Denial of Service attack
  168.  
  169.   - Confidentiality of Conference Details for Session Announcement 
  170.  
  171. Here it is at least necessary to hide the details of the addresses and 
  172. media formats used. In order to minimise schedule conflicts; it is 
  173. desirable to keep at least the time of a conference known, even if all 
  174. other details are concealed.
  175.  
  176. Kirstein et al.                                                [PAGE  3]
  177.  
  178. Internet Draft      Specification of SAP Security          July 29, 1997
  179.  
  180. Three types of announcement are supported: 'unsecured', 'authenticated' 
  181. and 'authenticated and encrypted'. The 'unsecured' type is described in 
  182. the SAP specification [1] and so only the latter two types are described
  183. below.
  184.  
  185. 2.2  Symmetric and Asymmetric Encryption
  186.  
  187. The simplest versions of encryption used are symmetric ones; here the 
  188. same encryption key 'a' is used to encrypt and decrypt a message. This 
  189. means that, if E{a,M) is the operation of encrypting the message M with 
  190. the key a and algorithm E, then the operation E{a, E{a, M}} reproduces 
  191. the original message M. Because this form of encryption relies on the 
  192. sender and receiver having the same key, it cannot be used for 
  193. authentication. An alternative form of encryption is asymmetric 
  194. encryption. Here two keys, a and b, are used. When these are used one 
  195. after the other to encrypt a message the original message is obtained.  
  196. Mathematically, these keys and the encryption algorithm E have the 
  197. property that E{a, E{b, M}} and E{b, E{a, M}} both produce the original 
  198. message  M - but given a, it should be impractical to deduce b and 
  199. vice versa.  
  200.  
  201. With an asymmetric encryption algorithm, a Public Key Cryptographic 
  202. System (PKCS) can be derived in which one of the keys, say the Public 
  203. Key (PK), is published in some way while the other, the Secret Key (SK),
  204. is kept secret.  Using such a PKCS, it is possible to achieve both 
  205. confidentiality and authentication. Encrypting a message with the 
  206. recipient's Public Key ensures confidentiality as only the recipient 
  207. with the corresponding SK can decrypt the message. Encrypting a message 
  208. with the SK of the sender ensures authentication as only the sender 
  209. could have sent the message initially whereas anybody having access to 
  210. the Public Key can verify that it was indeed sent by the person holding 
  211. the corresponding Secret Key.
  212.  
  213. Two complete systems, which can achieve both authentication and 
  214. confidentiality using particular PKCS systems, are PGP [2] and PKCS#7 
  215. [3]; similar mechanisms are used, but different encryption algorithms 
  216. and formats are used. The differences between the algorithm and format 
  217. details for these two systems are elaborated in Sections 3.2 and 3.3.
  218.  
  219. 2.3  Authenticated Announcements
  220.  
  221. In order to send authenticated announcements it is possible to use the 
  222. algorithms of either PGP [2] or the PKCS#7 [3] systems.  The resulting 
  223. format will be substantially different; the exact details are given in 
  224. Sections 3.2 and 3.3. For each format, the announcement originator 
  225. calculates a message digest of the announcement.  The originator's 
  226. secret key is used to encrypt the message digest, together with an 
  227. electronic timestamp, thus forming a digital signature. The originator 
  228. sends the digital signature along with the message; the receiver 
  229. receives the message and the digital signature, and recovers the 
  230. original message digest from the digital signature by decrypting it 
  231. with the sender's public key. The receiver computes a new message 
  232. digest from the message, and checks to see if it matches the one 
  233. recovered from the digital signature. If it matches, then this is 
  234.  
  235. Kirstein et al.                                                [PAGE  4]
  236.  
  237. Internet Draft      Specification of SAP Security          July 29, 1997
  238.  
  239. considered adequate proof that the message was not altered, and that it 
  240. came from the originator who owns the public key used to check the 
  241. signature.
  242.  
  243. Each Session announcement contains a message ID hash [4]. The 
  244. specifications for SAP announcements [1] states that such announcements 
  245. may be repeated frequently, but that if any change is made in the 
  246. announcement, a different message ID must be used; as a result, a 
  247. different message ID hash will be appended to the message. As a result, 
  248. it is only necessary to authenticate an announcement the first time it 
  249. is received. 
  250.  
  251. To save space in the announcement message, only a public key identifier 
  252. is generally included. It is then assumed that the public key itself 
  253. has either been distributed previously or can be retrieved from a cache 
  254. or directory. Optionally the Public Key itself can be included in the 
  255. announcement removing the need for prior distribution.  Consequently, 
  256. providing that the Public Key is already available in a local cache or 
  257. Directory, or is distributed with the announcement, one can be sure that
  258. the same originator sent the announcement. Only if the full public key 
  259. information, and a Certificate Authority infrastructure, are accessible 
  260. [5], can the originator be identified.
  261.  
  262. 2.4  Authenticated and Encrypted Announcements
  263.  
  264. 2.4.1  Introduction
  265.  
  266. When it is desired to make private announcements, it is necessary to 
  267. encrypt the set-up details of the conference. The normal way of 
  268. providing such encryption is to use only a symmetric encryption 
  269. algorithm such as the Data Encryption Standard (DES [6]) to encrypt 
  270. such a session using a Session Encryption Key (SEK); this algorithm is 
  271. used because other systems, such as the asymmetric RSA system [10], are 
  272. too computation-intensive for large amounts of data - though they are 
  273. economic for smaller amounts. For symmetric encryption systems, the SEK 
  274. must be securely distributed to all authorised recipients.
  275.  
  276. 2.4.2  Distribution of Session Encryption Keys
  277.  
  278. There are various ways that the SEK could be distributed; all rely on 
  279. distributing some shared secret in advance to the intended participants 
  280. in the conference group.  When this process takes place out of band, it 
  281. is not described further in this document. 
  282.  
  283. Many symmetric encryption algorithms, e.g. DES [6] are known to be easy 
  284. to break; with such algorithms, it is undesirable to re-use the SEK many
  285. times. For this reason, and to improve security, a set of SEKs may be 
  286. distributed out-of-band; the recipients may then try to decrypt the 
  287. announcement by trying each of these SEKs in turn. 
  288.  
  289. As in Section 2.3, one may use the fact that if any change is made in 
  290. the announcement, a different message ID, and hence message ID hash is 
  291. used; it is only necessary to attempt to decrypt an announcement message
  292. the first time it is received. The basic symmetric system is contained 
  293.  
  294. Kirstein et al.                                                [PAGE  5]
  295.  
  296. Internet Draft      Specification of SAP Security          July 29, 1997
  297.  
  298. in SAP [1].  To improve efficiency, it would be possible to use 
  299. symmetric encryption with a pre-distributed Key Identifier (KeyID). 
  300. However,  because of the potential weakening of the security by the use 
  301. of KeyIDs, and the consequent need to use more secure symmetric 
  302. algorithms, we do not recommend this technique. Moreover, by adopting 
  303. the use of asymmetric Public Key technology for such SEK distribution as
  304. discussed below, we gain both efficiency and have a better integrated 
  305. approach to authentication.
  306.  
  307. 2.4.3 Use of Public Key Algorithms 
  308.  
  309. Public Key Cryptography is one mechanism for minimising the need for 
  310. secure transmission of shared secrets; this was already used in the 
  311. Authenticated Announcements of Section 2.2. It would be possible to use 
  312. these encryption algorithms on the whole announcement message but this 
  313. would be inefficient because the asymmetric encryption algorithms 
  314. normally use much longer encryption keys, and are much more resource 
  315. intensive, than the symmetric ones. For this reason it is more efficient
  316. to use a combination of symmetric and Public Key algorithms. Now a 
  317. random Session Encryption Key (SEK) is generated as in Section 2.4.1. A 
  318. Privacy Header (PH) is constructed containing the SEK, which is 
  319. encrypted with the asymmetric encryption algorithm. It is now only 
  320. necessary to distribute a Secret Group Key (SGK) and Public Group Key 
  321. (PGK) i.e. {SGK, PGK} to decrypt the SEK. However, this pair needs to be
  322. distributed only once as long as the group membership does not change; 
  323. it is possible to re-use the same group keys for many sessions, with 
  324. different SEKs. This minimises the number of times the prior key 
  325. distribution sequence must be followed.
  326.  
  327. It should be noted that because a Group Key is used in the above, it is 
  328. not possible to use the same Header to authenticate the sender uniquely,
  329. though it is authenticated automatically that the sender is one of the 
  330. group which has reserved the asymmetric encryption key pair.  It is 
  331. still possible to authenticate the identity of the sender by using a 
  332. different Authentication Key for the Authentication Header as described 
  333. in Section 2.3.
  334.  
  335. It would be possible to use a similar technique using symmetric 
  336. encryption with a strong encryption algorithm and an encryption key 
  337. Identifier instead of the Public Key Group Key, However, we believe the 
  338. Public Key method to be superior so this variant is not pursued.
  339.  
  340. 2.4.4  Encrypting Announcements 
  341.  
  342. We will now provide some more detail.  If the payload is to be 
  343. compressed, this is performed prior to encryption.
  344.  
  345. When an announcement is to be encrypted, the payload is encrypted using 
  346. symmetric encryption. In this case each such encryption key is used only
  347. once; a new Session Encryption Key (SEK) is generated as a random number
  348. for each announcement. Since it is to be used only once, the SEK is 
  349. bound to the message and transmitted with it in a Privacy Header. The 
  350. sequence is as follows: The Privacy Header contains the SEK, encrypted 
  351. with the group's Public Group Key, together with information identifying
  352.  
  353. Kirstein et al.                                                [PAGE  6]
  354.  
  355. Internet Draft      Specification of SAP Security          July 29, 1997
  356.  
  357. the Group Key which has been used. The encrypted Payload is appended to
  358. the Privacy Header.
  359.  
  360. 2.4.5  Decrypting Announcements 
  361.  
  362. Upon receiving a new announcement with the encryption bit set, a 
  363. receiver should attempt to decrypt the announcement with the relevant 
  364. group private key or their own private key as indicated in the Privacy 
  365. Header.  The sequence is as follows:
  366.  
  367.     1. Prior to the announcement, the group's Public/Secret Group Key
  368.        pair is distributed securely.
  369.  
  370.     2. From the announcement, the receiving participants determine 
  371.        which Public Group Key has been used by looking at the 
  372.        information contained in the Privacy Header. 
  373.  
  374.     3. They then decrypt the Session Encryption Key (SEK) with the SGK 
  375.        corresponding to the PGK identified in Step 2 and obtain other 
  376.        necessary information such as the content encryption algorithm 
  377.        from the Privacy Header.
  378.  
  379.     4. The authorised receivers decrypt the encrypted text payload using
  380.        the SEK and the relevant symmetric content encryption algorithm,
  381.        which was used to encrypt the payload. 
  382.  
  383. Note that if an encrypted announcement is being announced via a proxy, 
  384. then there may be no way for the proxy to discover that the announcement
  385. has been superseded, and so it may continue to relay the old 
  386. announcement in addition to the new announcement. SAP provides no 
  387. mechanism to chain modified encrypted announcements, so it is advisable 
  388. to announce the unmodified session as deleted for a short time after 
  389. the modification has occurred. This does not guarantee that all proxies 
  390. have deleted the session, and so receivers of encrypted sessions should 
  391. be prepared to discard old versions of session announcements that they 
  392. may receive (as identified by the SDP version field). In most cases 
  393. however, the only stateful proxy will be local to (and known to) the 
  394. sender, and an additional (local-area) protocol involving a handshake 
  395. for such session modifications can be used to avoid this problem.
  396.  
  397. 3.  Secured SAP Packet Formats 
  398.  
  399. Both Authentication and Privacy can be achieved using PGP [2] or PKCS#7 
  400. [3] format packets. In Section 3.1 we discuss the generic packet format 
  401. defined in SAP [1]. In Section 3.2 we consider the formats of the 
  402. Authentication Header, and in Section 3.3 that of the encrypted payload.
  403.  
  404. It would be possible to define our own versions of the packets for this 
  405. application. In that case the formats would be simpler, but all the 
  406. implementations would have to be coded using the basic encryption 
  407. libraries, and a new infrastructure would have to be defined. Both PGP 
  408. and PKCS#7 already have complete implementations and, by using their 
  409. formats, several application tool kits are already available (e.g. 
  410. Entrust [14], Secude [15]). In addition, these formats also have 
  411.  
  412. Kirstein et al.                                                [PAGE  7]
  413.  
  414. Internet Draft      Specification of SAP Security          July 29, 1997
  415.  
  416. complete infrastructures defined around them. For these reasons, we have
  417. chosen to retain enough compatibility to ease the eventual 
  418. implementation, while simplifying the formats as far as possible within 
  419. such a constraint. There is an additional advantage in this approach; it
  420. will be possible to send session announcements by the encrypted Session 
  421. Invitation Protocol or by electronic mail using PGP or S-MIME, and 
  422. re-use much of the same code as with SAP.
  423.  
  424. 3.1  Secured SAP Packet Format 
  425.  
  426. The SAP data packets as defined in [1] has the following format:
  427.  
  428.  
  429.                          1                   2                   3
  430.      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
  431.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  432.     | V=2 | MT  |E|C| Header Length |       16 bit Message ID Hash  |
  433.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  434.     |                     Originating Source                        |
  435.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
  436.     |              Authentication Header (Optional)                 |
  437.     |                    ..................                         |
  438.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  439.     |               32 bit Time-Out Field (Optional)                |
  440.     |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  441.     |              Text Payload (Possibly Encrypted)                |
  442.     |                    ..................                         |
  443.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  444.  
  445. Notes:  
  446.  
  447. Version Number, V: This is a 3-bit field and has the value 2 for this 
  448.   version of SAP [1] 
  449.  
  450. Message Type, MT: This defines the contents of the payload and can be  
  451.  
  452.       0. Session Descriptor Announcement Packet in which case the 
  453.          payload is an SDP session description as described in [4]
  454.  
  455.       1. Session Description Deletion Packet in which case the payload 
  456.          is a singleSDP line containing the origin field of the 
  457.          announcement to be deleted
  458.  
  459. Encryption Bit, E: -. If this is set, the text payload has been 
  460.   encrypted
  461.  
  462. Compression Bit, C: If this is set the payload has been compressed using
  463.   the gzip compression utility [7]
  464.  
  465. Header length: This is an 8 bit unsigned quantity giving the number of 
  466.   32 bit words following the main SAP header that contains the 
  467.   authentication data. If this is non-zero, the payload is 
  468.   authenticated, and an Authentication Header is present
  469.  
  470.  
  471. Kirstein et al.                                                [PAGE  8]
  472.  
  473. Internet Draft      Specification of SAP Security          July 29, 1997
  474.  
  475. Message Identifier Hash: This is a 16 bit quantity that, when used in 
  476.   combination with the originating source, provides a globally unique 
  477.   id identifying the precise version of this announcement.  The message 
  478.   id hash should be changed if any field of the session description is 
  479.   changed.  A value of zero means that the hash should be ignored and 
  480.   the message should always be parsed.
  481.  
  482. Originating Source: This 32-bit field gives the IP address of the 
  483.   original source of the message.  It is permissible for this to be zero
  484.   if the message has not passed through a proxy relay and if the message
  485.   id hash is also zero. This is intended for backward compatibility with
  486.   SAPv0 clients only.
  487.  
  488. Authentication Header: This can be used for two purposes:
  489.  
  490.       1. Verification that changes to a session description or deletion 
  491.          of a session are permitted
  492.  
  493.       2. Authentication of the identity of the session creator.
  494.  
  495. In some circumstances only verification is possible because a 
  496. certificate signed by a mutually trusted person or authority is not 
  497. available.  However, under such circumstances, the session originator 
  498. can still be authenticated to be the same as the session originator of 
  499. previous sessions claiming to be from the same person.  This may or may 
  500. not be sufficient, depending on the purpose of the session and the 
  501. people involved. The precise format of the Authentication Header is 
  502. discussed in Section 3.2.
  503.  
  504. Timeout: When the session payload is encrypted, and the session 
  505.   description is being relayed or announced via a proxy, the detailed 
  506.   timing fields in the SDP description are not available to the proxy. 
  507.   This is because these fields are encrypted and the proxy is not 
  508.   trusted with the decryption key. Under such circumstances, SAP 
  509.   includes an additional 32-bit timestamp field stating when the session
  510.   should be timed out. The digital signature in the authentication 
  511.   header encompasses the time-out so that a session cannot be 
  512.   maliciously deleted by modifying its time-out in an announcing proxy. 
  513.   The value is an unsigned quantity giving the NTP time [8] in seconds 
  514.   at which time the session is timed out.  It is in network byte order
  515.  
  516. Privacy Header: This is present when the text payload has been encrypted
  517.   using hybrid encryption. 
  518.  
  519. Text Payload: When there is no encryption, the encryption bit is not set
  520.   and this format is as defined in the SDP [4] draft. However, when 
  521.   encryption has been used the payload is encrypted and the format is 
  522.   discussed in Section 3.3.
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530. Kirstein et al.                                                [PAGE 10]
  531.  
  532. Internet Draft      Specification of SAP Security          July 29, 1997
  533.  
  534. 3.2  Authentication Header 
  535.  
  536. 3.2.1  Generic Format 
  537.  
  538. The generic format of the Authentication Header is given below. The 
  539. structure of the Format Specific Authentication Subheader, using both 
  540. the PGP and the PKCS#7 formats, is discussed in Sections 3.2.2 and 3.2.3
  541. respectively.
  542.  
  543.                          1                   2                   3
  544.      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
  545.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  546.     | V=1 |P| Auth  | Header Length |                               |
  547.     |+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+                               |
  548.     |              Format Specific Authentication Subheader         |
  549.     |                       ..................                      |
  550.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  551.  
  552. Notes:
  553.  
  554. Version Number, V: For this release the version number is 1 (3 bits)
  555.  
  556. Padding Bit, P: If necessary the data in the Authentication Header is 
  557.   padded to be a multiple of 32 bits and the Padding bit is set. In this
  558.   case the last byte of the Authentication Header contains the number of
  559.   padding bytes (including the last byte) that must be discarded.
  560.  
  561. Authentication Type, Auth: The Authentication Type is a 4 bit encoded 
  562.   field that denotes the authentication infrastructure the sender 
  563.   expects the recipients to use to check the authenticity and integrity 
  564.   of the information. This defines the format of the Authentication 
  565.   Subheader and can take the values: 
  566.  
  567.       1. PGP Format
  568.       2. PKCS#7 Format
  569.       3. PGP Format with the 'Certificate' included
  570.       4. PKCS#7 with the Certificate included 
  571.  
  572.  
  573. 3.2.2   PGP Format
  574.  
  575. The generic description of the PGP packets is presented in [2]. For PGP 
  576. the basic Format Specific Authentication Subheader comprises a digital 
  577. signature packet as described in [2]. This involves the use of a hash 
  578. code, or message digest algorithm, and a public key encryption 
  579. algorithm. For the case when the Authentication type is 1 the Subheader 
  580. contains a Digital Signature Packet only with the hexadecimal signature 
  581. classification being <00> or <01>. The only Message Digest Algorithm is 
  582. 1 (MD5) and the Public Key Cryptosystem (PKC) is 1, this being the RSA 
  583. system. If the type is 3 then a Certificate Packet is also appended to 
  584. the previous Signature Packet. A certificate packet is composed of the 
  585. following individual packets:
  586.  
  587.  
  588.  
  589. Kirstein et al.                                                [PAGE 11]
  590.  
  591. Internet Draft      Specification of SAP Security          July 29, 1997
  592.  
  593.       (a)  A Public Key Packet which defines the RSA public key
  594.       (b)  A UserID packet
  595.       (c)  A Signature Packet
  596.  
  597. The Public Key packet again has the Public Key Cryptosystem 1. In the 
  598. case of Signature Packet (c) the signature classification now takes the 
  599. hexadecimal values <10> to <13>. These packets are all detailed in [2].
  600.  
  601. 3.2.3 PKCS#7 Format 
  602.  
  603. The Format Specific Authentication Subheader will, in the PKCS#7 case, 
  604. have an ASN.1 ContentInfo type with the ContentType being signedData. 
  605. Use is made of the option available in PKCS#7 to leave the content 
  606. itself blank as the content which is signed is, in this application, 
  607. already present as the text payload, whether this is encrypted or not. 
  608. Thus inclusion of it within the SignedData type would be duplication and
  609. increase the packet length unnecessarily. The full specification for 
  610. this ASN.1 type is available in [3].
  611.  
  612.  There will only be one signerInfo and related fields corresponding to 
  613. the originator of the SAP announcement.  Although it would be possible 
  614. to transfer the relevant information is a single signerInfo type rather 
  615. than the complete ContentInfo it is considered preferable to use the 
  616. latter for two reasons. Firstly, this is compatible with a wider range 
  617. of applications and security toolkits and secondly, that the certificate
  618. can be included in a standard way. If the Authentication Type is 2 there
  619. are no certificates or certificate revocation lists whereas if the 
  620. authentication type is 4 the originator's X.509 certificate is added in 
  621. the certificate field of this type.
  622.  
  623. In addition, for both type 2 and 4, use is made of the ability in PKCS#7
  624. to authenticate various attributes as specified in PKCS#9 [16]. The 
  625. authenticatedAttributes field of the SignerInfo type is used and the 
  626. attribute which is authenticated is the SigningTime.  This is a 
  627. mandatory field in this specification.
  628.  
  629. 3.3    Encrypted Payload Format 
  630.  
  631. 3.3.1    Generic Format
  632.  
  633. The format of the Encrypted Payload depends on the type of encryption 
  634. used to encrypt the SDP text payload [4]. If no encryption has been used
  635. only the Text payload is present.
  636.  
  637. If encryption has been used then the encryption bit in the main SAP 
  638. header is set  and the payload is encrypted either symmetrically or 
  639. using hybrid encryption. For symmetric encryption the format is detailed
  640. in Section 3.3.2 whereas hybrid encryption is detailed in Section 3.3.3.
  641. For hybrid encryption there are two possibilities - PGP and PKCS#7 
  642. Formats. The application is expected to test whether the fields 
  643. immediately following the timeout field in the main SAP header is 
  644. compatible with the use of symmetric encryption; in that case it will be
  645. a padding bit followed by a 31-bit random field, or whether it is 
  646. compatible with the use of hybrid encryption. In this case there is a 
  647.  
  648. Kirstein et al.                                                [PAGE 12]
  649.  
  650. Internet Draft      Specification of SAP Security          July 29, 1997
  651.  
  652. very specific format to the first byte of the Privacy header, which 
  653. follows other time-out field in this case.
  654.  
  655. 3.3.2    Symmetric Encryption
  656.  
  657. If symmetric encryption alone has been used then the encrypted payload 
  658. has a random field added prior to encryption as below.
  659.  
  660.                          1                   2                   3
  661.      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
  662.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  663.     |P|                    31 bit random field                      |
  664.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  665.     |                         Text Payload                          |
  666.     |                            . . .                              |
  667.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  668.  
  669.  
  670. Notes 
  671.  
  672. Random Field: This field is only present when payload is encrypted 
  673.   using symmetric encryption and is used to perform the randomisation 
  674.   tasks normally performed by an initialisation vector in algorithms 
  675.   such as DES. This 31-bit field should contain a genuinely random 
  676.   number.  
  677.  
  678. Padding Bit, P: This bit indicates that the payload was padded prior to 
  679.   encryption. The last byte of the encrypted payload indicates how many 
  680.   padding  bytes were added.
  681.  
  682. The data following the Time-out field is decrypted using the algorithm 
  683. specified above. Further details on the encryption algorithms are given 
  684. in [6, 12, 13].
  685.  
  686. 3.3.3    Hybrid Encryption
  687.  
  688. If a combination of asymmetric and symmetric encryption has been used 
  689. then the part of the SAP packet following the time-out field has the 
  690. following structure. This effectively takes the form of a Privacy header
  691. followed by the encrypted SDP payload, the precise format depending on 
  692. whether PGP or PKCS#7 formats have been used. The specific details for 
  693. each of these formats are described in Sections 3.3.3.1 and 3.3.3.2 
  694. respectively.
  695.  
  696. Privacy Header:
  697.  
  698.                          1                   2                   3
  699.      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
  700.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  701.     | V=1 |P| Type  | Header Length |                               |
  702.     |+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+                               |
  703.     |                  Format Specific Privacy Subheader            |
  704.     |                       ..................                      |
  705.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  706.                                
  707. Kirstein et al.                                                [PAGE 13]
  708.  
  709. Internet Draft      Specification of SAP Security          July 29, 1997
  710.  
  711. Notes
  712.  
  713. Version, V: In this version the Version of the privacy Header is 1
  714.  
  715. Padding Bit, P: If necessary the data in the Privacy Header is padded to
  716.   be a multiple of 32 bits and the Padding bit is set. In this case the 
  717.   last byte of the Privacy Header contains the number of padding bytes 
  718.   (including the last byte) that must be discarded.
  719.  
  720. Format Type, Type: This can be either 1 for PGP or 2 for PKCS#7 format.
  721.  
  722. 3.3.3.1  PGP Format Privacy Header
  723.  
  724. For the case when the Format Type is 1 the Format Specific Privacy 
  725. Subheader is composed of a PGP Public Key encrypted packet and the text 
  726. payload is a PGP  Conventional Key Encrypted Packet. These are detailed 
  727. in [2]. The Public Key Cryptosystem is 1, this being defined as the RSA 
  728. system, and the only supported symmetric encryption algorithm is the 
  729. IDEA algorithm, corresponding to the Conventional encryption type byte 
  730. value of 1.
  731.  
  732. 3.3.3.2    PKCS#7 Format Privacy Header
  733.  
  734. If the  Type is 2 then the Format Specific Privacy Header is composed of
  735. a PKCS#7 ContentInfo type with the ContentType being envelopedData. 
  736. These are detailed in [2]. In this case the Text Payload, which has been
  737. symmetrically encrypted with the algorithm specified in the 
  738. contentEncryptionAlgorithm field, is effectively the encryptedContent  
  739. part of the structure. There will be only one recipientInfo structure 
  740. corresponding to the group certificate, which has been previously 
  741. distributed. The contentType in the EncryptedContentInfo structure is 
  742. "Data".
  743.  
  744.  
  745. 3.3.4    Supported Algorithms
  746.  
  747. In the case of the hybrid encryption the algorithms supported are 
  748. defined in [2,3] for PGP and PKCS#7 respectively. The details of the 
  749. algorithms used are an inherent part of the information sent in the 
  750. Privacy Header and Authentication Header and so it is not necessary to 
  751. specify in advance which are supported; this is open to change as new 
  752. algorithms arise and older ones are shown to insecure.
  753.  
  754. For the purely symmetric encryption case then currently only DES is 
  755. supported with a 56-bit Key length.
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766. Kirstein et al.                                                [PAGE 14]
  767.  
  768. Internet Draft      Specification of SAP Security          July 29, 1997
  769.  
  770.  
  771.  
  772.  
  773.                    Appendix A: Authors' Addresses
  774.  
  775.  
  776.   Peter Kirstein, Goli Montasser Kohsari and Edmund Whelan are at 
  777.   University College London and their contact details are:
  778.  
  779.         P.Kirstein@cs.ucl.ac.uk            Tel: +44 71 380 7286
  780.         G.Montasser-Kohsari@cs.ucl.ac.uk   Tel: +44 71 380 7215
  781.         E.Whelan@cs.ucl.ac.uk              Tel: +44 71 419 3688
  782.  
  783.     Dept of Computer Science           Fax: +44 71 387 1397
  784.         University College London 
  785.         Gower Street
  786.         London WC1E 6BT England
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.                          Acknowledgements
  794.  
  795.  
  796. SAP and SDP were originally based on the protocol used by the sd session
  797. directory from Van Jacobson at LBNL. The European Commission under the 
  798. Esprit 7602 "MICE" project, and the Telematics 1007 "MERCI" project 
  799. funded the design of SAP.
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825. Kirstein et al.                                                [PAGE 15]
  826.  
  827. Internet Draft      Specification of SAP Security          July 29, 1997
  828.  
  829.  
  830.                             References 
  831.  
  832.  
  833. [1] M.Handley  `SAP: Session Announcement Protocol'' INTERNET-DRAFT,
  834.     draft-ietf-mmusic-sap-00.txt, 11/27/1996.
  835.  
  836. [2] D.Atkins, '' PGP Message Exchange Formats'' , 
  837.     RFC 1991, August  1996.
  838.  
  839. [3] PKCS#7, Cryptographic Message Syntax Standard, RSA Laboratories,  
  840.     Version 1.5, November 1993
  841.  
  842. [4] M.Handley, V. Jacobson, ``SDP: Session Description Protocol'', 
  843.     INTERNET-DRAFT, draft-ietf-mmusic-sdp-02.txt, 11/27/1996.
  844.  
  845. [5] R. Housley , W. Ford , T. Polk Internet Public Key  Infrastructure  
  846.     INTERNET- DRAFT, draft-ietf-pkix-ipki-part1-03.txt December 1996.  
  847.  
  848. [6] National Bureau of Standards, Data Encryption Standard, Federal 
  849.     Information Processing Standards Publication 46, January 1977 
  850.  
  851. [7] P.  Deutsch, ``GZIP file format specification version 4.3'', 
  852.     RFC 1952, May 1996.
  853.  
  854. [8] D. Mills, ``Network Time Protocol version 2 specification and 
  855.     implementation", RFC1119, 1st Sept 1989.
  856.  
  857. [9] X.208 Specification of Abstract Syntax Notation One (ASN.1) 
  858.     ITU-T Recommendations 1988 
  859.  
  860. [10] PKCS #1    RSA Encryption Standard RSA Laboratories, Version 1.5, 
  861.      November 1993 
  862.  
  863. [11] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with 
  864.      Minimal Control'', RFC 1890, January 1996 
  865.  
  866. [12] P.  Metzger, P. Karn, W.  Simpson,  The ESP Information Triple 
  867.      DES-CBC Transformation, 10/02/1995 RFC850 
  868.  
  869. [13] ANSI X3.92-1981.  American National Standards Data Encryption 
  870.      Algorithm.  American National Standards Institute, 
  871.      Approved 30 December 1990
  872.  
  873. [14] For details of ENTRUST see http://www.entrust.com/ 
  874.  
  875. [15] For  details of SECUDE see http://www.darmstadt.gmd.de/secude/
  876.  
  877. [16] PKCS#9 Selected Attribute Types,  
  878.      RSA Laboratories, Version 1.1, November 1993
  879.  
  880.  
  881.  
  882.  
  883.  
  884. Kirstein et al.                                                [PAGE 16]
  885.