idnits 2.17.1 draft-ietf-mmusic-sap-sec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 6) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 17 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 881: '... authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL,...' RFC 2119 keyword, line 884: '... unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL }...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 23 has weird spacing: '...ctories on f...' == Line 392 has weird spacing: '...rovides a gl...' == Line 394 has weird spacing: '...ription is...' == Line 401 has weird spacing: '...s to be zero ...' == Line 403 has weird spacing: '...o. This is in...' == (12 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 26, 1997) is 9702 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'PAGE 1' on line 44 -- Looks like a reference, but probably isn't: 'PAGE 2' on line 71 -- Looks like a reference, but probably isn't: 'PAGE 3' on line 123 -- Looks like a reference, but probably isn't: 'PAGE 4' on line 177 -- Looks like a reference, but probably isn't: 'PAGE 5' on line 230 -- Looks like a reference, but probably isn't: 'PAGE 6' on line 288 == Missing Reference: '15' is mentioned on line 328, but not defined -- Looks like a reference, but probably isn't: 'PAGE 7' on line 337 -- Looks like a reference, but probably isn't: 'PAGE 8' on line 388 -- Looks like a reference, but probably isn't: 'PAGE 9' on line 444 -- Looks like a reference, but probably isn't: 'PAGE 10' on line 500 -- Looks like a reference, but probably isn't: 'PAGE 11' on line 554 -- Looks like a reference, but probably isn't: 'PAGE 12' on line 607 -- Looks like a reference, but probably isn't: 'PAGE 13' on line 658 -- Looks like a reference, but probably isn't: 'PAGE 14' on line 707 -- Looks like a reference, but probably isn't: 'PAGE 15' on line 756 -- Looks like a reference, but probably isn't: 'PAGE 16' on line 811 -- Looks like a reference, but probably isn't: 'PAGE 17' on line 826 -- Looks like a reference, but probably isn't: 'PAGE 18' on line 858 == Missing Reference: '0' is mentioned on line 911, but not defined -- Looks like a reference, but probably isn't: 'PAGE 19' on line 913 -- Looks like a reference, but probably isn't: 'PAGE 20' on line 965 == Unused Reference: '10' is defined on line 949, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 952, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 1991 (ref. '2') (Obsoleted by RFC 4880) -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-06) exists of draft-ietf-mmusic-sdp-02 == Outdated reference: A later version (-11) exists of draft-ietf-pkix-ipki-part1-03 -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 1952 (ref. '7') ** Obsolete normative reference: RFC 1119 (ref. '8') (Obsoleted by RFC 1305) -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 1890 (ref. '11') (Obsoleted by RFC 3551) ** Obsolete normative reference: RFC 850 (ref. '12') (Obsoleted by RFC 1036) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' Summary: 19 errors (**), 0 flaws (~~), 14 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Peter Kirstein 2 IETF MMUSIC WG Goli Montasser-Kohsari 3 March 26, 1997 Edmund Whelan 4 5 Expires September 26, 1997 7 Specification of Security in SAP Using Public Key Algorithms 9 Status of this Memo 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. 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.'' 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). 27 Distribution of this document is unlimited. 29 Abstract 31 The Session Announcement Protocol (SAP) is specified in such a way that 32 authentication and privacy can be assured. However but the algorithms 33 and mechanisms to achieve such security are not prescribed in the 34 current draft. This document extends the SAP protocol, by describing 35 specific algorithms and formats of authentication and encryption 36 formats based on the PGP and PKCS#7 standards. It is a companion 37 document to draft-ietf-mmusic-sap. 39 This document is a product of the Multiparty Multimedia Session Control 40 (MMUSIC) working group of the Internet Engineering Task Force Comments 41 are solicited and should be addressed to the working group's mailing 42 list at confctrl@isi.edu and/or the authors. 44 Kirstein et al. Document Expiration 26 September 1997 [PAGE 1] 45 Glossary 47 ASN Abstract Syntax Notation 48 CT Content Type 49 CTB Cipher Type Byte 50 DA Digest Algorithm 51 DEA Digest Encryption Algorithm 52 DES Data Encryption Standards 53 EAID Encryption Algorithm Identifier 54 EKID Encryption Key Identifier 55 ID Identifier 56 IETF Internet Engineering Task Force 57 MD Message Digest 58 MMUSIC Multiparty Multimedia Session Control 59 PEM Privacy Enhanced Mail 60 PGK Public Group Key 61 PGKID Public Group Key Identifier 62 PGP Pretty Good Privacy 63 PH Privacy Header 64 PKCS Public Key Cryptographic System 65 SAP Session Announcement Protocol 66 SDP Session Descriptor Protocol 67 SEK Session Encryption Key 68 SGK Secret Group Key 69 SHA Secure Hash Algorithm 71 Kirstein et al. Document Expiration 26 September 1997 [PAGE 2] 72 1. Introduction 74 An Mbone session directory is used to advertise multimedia conferences, 75 and to communicate the session addresses (whether multicast or unicast) 76 and conference-tool- specific information necessary for participation. 77 Such sessions can be announced using the Session Announcement Protocol 78 (SAP) described in a companion draft [1]. The SAP protocol [1] allows 79 for the incorporation of authentication of the announcement originator, 80 and for privacy of the session details; however neither the choice of 81 authentication algorithms used, nor the mechanisms for encrypting the 82 SAP Session Description, are detailed in the draft. 84 This document describes the format of the authentication header for 85 SAP data packets that use security services based on PGP [2] orPKCS#7 86 [3]. The format based loosely on PKCS#7 is referred to as Simple 87 Public Key Format. Appendix C contains further details of PKCS#7 88 format security and possible future implementation plans. The SAP 89 document also provides the confidentiality services required for the 90 SAP payload [4], which describes the conference set-up parameters. This 91 document describes how hybrid symmetric and public key encryption 92 algorithms should be used to provide private announcements. 94 Much of this document is concerned with security considerations; these 95 security considerations have not yet been subject to suitable 96 peer-review, and this document should not be considered authoritative 97 in this area. 99 2. Authentication and Encryption of Session Announcement 101 2.1 Introduction 103 It is necessary to provide authentication and integrity of the Session 104 Announcement to ensure that only authorised persons modify Session 105 Announcements and to provide facilities for announcing securely 106 encrypted sessions - providing the relevant proposed conferees with the 107 means to decrypt the data streams. The Session Announcements are made 108 to announce to all potential conferees the existence of a conference. 109 It has, however, another function - to try to minimise conflicts for 110 Mbone resources by spreading out the number of simultaneous 111 conferences. Thus there are a number of threats which we must try to 112 address in the securing of the Session Announcement, and some 113 constraints. These include the following: 115 - Authentication and Integrity of Session Announcement 117 Here it is necessary to ensure that the Session Announcement comes 118 from the person claimed, and is indeed an authorised announcement. 119 Since subsequent announcements will modify caches of future 120 conferences, it is possible otherwise to spoof an original 121 announcement, and thereby at least cause a Denial of Service attack; 123 Kirstein et al. Document Expiration 26 September 1997 [PAGE 3] 124 - Confidentiality of Conference Details for Session Announcement 126 Here it is at least necessary to hide the details of the tools 127 used. Because of the desire to minimise schedule conflicts, it is 128 desirable to keep at least the time of a conference known, even if 129 all other details are concealed. 131 Three types of announcement will be supported: unsecured, 132 authenticated, authenticated and encrypted. The authenticated and the 133 authenticated and encrypted types are described below. The exact 134 formats depend on whether the PGP [2] or Simple Public Key mechanisms 135 are used, but this detail is elaborated in Section 3.2 and 3.3. 137 2.2 Authenticated Announcements 139 A message digest of the announcement is calculated by the announcement 140 originator. The originators secret key is used to encrypt the message 141 digest and an electronic timestamp, thus forming a digital signature, 142 or signature certificate. The originator sends the digital signature 143 along with the message; the receiver receives the message and the 144 digital signature, and recovers the original message digest from the 145 digital signature by decrypting it with the sender's public key. The 146 receiver computes a new message digest from the message, and checks to 147 see if it matches the one recovered from the digital signature. If it 148 matches, then that proves the message was not altered, and that it came 149 from the originator who owns the public key used to check the 150 signature. 152 The digital signature service involves the use of a hash code, or 153 message digest, algorithm, a public-key encryption algorithm, and the 154 private component of a public key pair and a timestamp. The sequence is 155 as follows: 157 - the originator creates a payload 158 - the originator generates a hash of the payload and timestamp 159 - the originator encrypts the hash code using his own or the 160 conference groups private key 161 - the encrypted hash code and the public key are pre-pended to the 162 payload the receiver decrypts the hash code using the public key 163 received. 164 - the receiver generates a new hash code for the received payload 165 and timestamp and compares it to the decrypted hash code. If the 166 two match, the payload is accepted as authentic. 168 To save space in the announcement message, optionally only a public key 169 identifier need be included; it is then assumed that the public key 170 identifier, and the public key, have been distributed previously, or 171 can be retrieved from a cache or directory. Provided the Public Key 172 already exists in such a form, or is distributed with the announcement, 173 one can be sure that the same originator sent the announcement. Only if 174 the full public key information, and a Certificate Authority 175 infrastructure, are accessible [5], can the originator be identified. 177 Kirstein et al. Document Expiration 26 September 1997 [PAGE 4] 178 2.3 Encrypted Announcements 180 2.3.1 Use of Symmetric Encryption 182 Algorithms Announcements may be encrypted using a symmetric encryption 183 stage to provide security. If this mechanism is used, a random Session 184 Encryption Key (SEK) must be generated and conveyed in advance to the 185 intended participants of a conference group. This process takes place 187 out-of-band and is not described in this draft. Session announcements 188 may then be made to the appropriate session announcement address, 189 encrypted so that they can be decrypted only by recipients previously 190 authorised by being provided with the SEK. Many symmetric encryption 191 algorithms, e.g. DES [6], are known to be easy to break. For this 192 reason, and to improve security, a set of SEKs may be distributed 193 out-of-band, and the recipients may then try to decrypt the 194 announcement by trying each of the set of SEKs. To improve the 195 efficiency of this process, an Encryption Key Identifier (EKID), and an 196 Encryption Algorithm Identifier (EAID) are normally distributed with 197 the SEK. This (EKID, EAID, SEK) triplet uniquely identifies the 198 mechanism and parameters required to decrypt the Session Announcement. 199 Use of Key Identifiers is undesirable if different sessions are to be 200 announced using the same DES key. 202 2.3.2 Use of Hybrid Encryption Public Key Algorithms Together With 203 Symmetric Ones 205 The (EKID, EAID, SEK) triplet must be received, and possibly cached by 206 all the authorised parties prior to the reception of the SAP 207 announcement. The process of ensuring the receipt, managing the cache, 208 and trying several keys can be relatively complex and expensive; for 209 this reason the number of such triplet that must be distributed should 210 be minimised. One mechanism for minimising the number of triplet 211 required is to use Public Key Cryptography as in the Authenticated 212 Announcements of Section 2.2. It would be possible to use these 213 encryption algorithms on the whole announcement message; this would, 214 however, be inefficient because the asymmetric encryption algorithms 215 normally use much longer encryption keys, and are much more 216 resource-intensive, than the symmetric ones. For this reason it is more 217 efficient to use a combination of symmetric and Public Key algorithms. 218 Now a random Session Encryption Key (SEK) is generated as in Section 219 2.3.1. A Privacy Header (PH) is constructed containing the SEK, which 220 is encrypted with the asymmetric encryption algorithm. It is now 221 necessary to distribute a quadruplet of {Encryption Key Identifier 222 (EKID), Encryption Algorithm Identifier (EAID), Secret Group Key (SGK) 223 and Public Group Key (PGK)} i.e. {EKID,EAID,SGK,PGK} to identify 224 uniquely the mechanism and parameters required to decrypt the SEK. 225 However, this quadruplet needs to be distributed only once as long as 226 the group membership does not change; it is possible to re-use the same 227 group keys for many sessions, with different SEKs. This minimises the 228 number of times the prior key distribution sequence must be followed. 230 Kirstein et al. Document Expiration 26 September 1997 [PAGE 5] 231 It should be noted that because a Group Key is used in the above, it is 232 not possible to use the same Header to authenticate the sender 233 uniquely; though it is authenticated automatically that the sender is 234 one of the group which has reserved the asymmetric encryption key 235 pair. By using a different Authentication Key for the authentication 236 of Section 2.2 from the Encryption Keys of this section, it is possible 237 to still authenticate the identity of the sender. 239 2.3.3 Encrypting Announcements 241 We will now provide some more detail. If the payload is to be 242 compressed, this is performed prior to encryption . 244 When an announcement is to be encrypted, the payload is encrypted using 245 symmetric encryption. In this case each such encryption key is used 246 only once; a new Session Encryption Key (SEK) is generated as a random 247 number for each announcement. Since it is to be used only once, the SEK 248 is bound to the message and transmitted with it in a Privacy Header. 249 The sequence is as follows: The Privacy Header contains the SEK, 250 encrypted with the groups Public Group Key, together with the groups 251 Public Key Identifier (PGKID). This is followed by the encrypted 252 Payload. 254 2.3.4 Decrypting Announcements 256 Upon receiving a new announcement with the encryption bit set, a 257 receiver should attempt to decrypt the announcement with its group 258 private key or its own private key - as indicated by the PGKID. 260 The sequence is as follows: 262 - The receiving participants derive the Secret Group Key (SGK) and the 263 group key algorithm from the Public Group Key Identifier and its 264 related information which has been distributed previously. 266 - They then decrypt the Session Encryption Key (SEK) with the SGK and 267 obtain the Encryption Algorithm Identifier (EAID) from the Privacy 268 Header. 270 - The authorised receivers extract the text payload by using the SEK 271 and the relevant symmetric decryption algorithm to decrypt the 272 encrypted text payload. 274 Note that if an encrypted announcement is being announced via a proxy, 275 then there may be no way for the proxy to discover that the 276 announcement has been superseded, and so it may continue to relay the 277 old announcement in addition to the new announcement. SAP provides no 278 mechanism to chain modified encrypted announcements, so it is advisable 279 to announce the unmodified session as deleted for a short time after 280 the modification has occurred. This does not guarantee that all proxies 281 have deleted the session, and so receivers of encrypted sessions should 282 be prepared to discard old versions of session announcements that they 283 may receive (as identified by the SDP version field). In most cases 284 however, the only stateful proxy will be local to (and known to) the 285 sender, and an additional (local-area) protocol involving a handshake 286 for such session modifications can be used to avoid this problem. 288 Kirstein et al. Document Expiration 26 September 1997 [PAGE 6] 289 2.3.5 Encryption Algorithm Identifier (EAID) 291 This is an 8-bit integer which is mentioned in Sections 2.3.1 and 292 2.3.2. It is distributed with the Key ID in the form of: {Encryption 293 Key ID, Encryption Algorithm ID, Encryption Key(s)} 295 It is used for three purposes: to determine whether symmetric or 296 asymmetric encryption is used, to specifiy the encryption algorithm, 297 and to specify the encryption key length. For this reason, its format 298 is given below: 300 BIT 0 1 2 3 4 5 6 7 301 TYPE ALGORITHM LENGTH 303 TYPE (1 bit) can take the values 0 or 1; the former is symmetric, the 304 latter Public Key 306 ALGORITHM (3 bits) denotes the encryption Algorithm, further details 307 are given in Section 3.3.6. 309 LENGTH (4 bits) denotes the key length; further details are given in 310 Section 3.3.6 312 3. Secured SAP Packet Formats 314 Both Authentication and Confidentiality can be achieved using PGP [2] 315 or Simple Public Key format packets. These formats are explained in 316 greater detail below. In Section 3.1 we discuss the generic packet 317 format defined in [1]; this is still only at the draft stage, so any 318 changes in it will have to be tracked in future versions of this 319 document. In Section 3.2 we consider the formats of the Authentication 320 Header, and in Section 3.3 that of the Text Payload. 322 It would be possible to define our own versions of the packets 323 completely for this application. In that case the formats would be 324 simpler, but all the implementations would have to be coded using the 325 basic encryption libraries, and a new infrastructure would have to be 326 defined. Both PGP and PKCS#7 already have complete implementations; by 327 using their formats, several application tool kits are already 328 available (e.g. ENTRUST [14], SECUDE [15]). In addition, these formats 329 also have complete infrastructures defined around them. For these 330 reasons, we have chosen to retain enough compatibility to ease the 331 eventual implementation, while simplifying the formats as far as 332 possible within such a constraint. There is an additional advantage in 333 this approach; it will be possible to send session announcements by the 334 encrypted Session Invitation Protocol or by electronic mail using PGP 335 or S-MIME, and re-use much of the same code as with SAP. 337 Kirstein et al. Document Expiration 26 September 1997 [PAGE 7] 338 3.1 SAP Packet Format 340 The SAP data packets as defined in [1] is of the following format: 342 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | V=2 | MT |E|C| Header Length | 16 bit Message ID Hash | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Originating Source | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 349 | Authentication Header (Optional) | 350 | ... | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Encryption Key id (Optional) | 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | 32 bit Time-Out Field (Optional) | 356 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Text Payload (Possibly Encrypted) | 358 | .................. | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Notes: 363 V: Version Number (3 bits). This is 2 for SAP [1] 365 MT: Message Type 366 The value being either: 368 0. Session description announcement packet. The text payload is 369 an SDP session description, as described in [4]. 371 1. Session description deletion packet. The text payload is a 372 single SDP line consisting of the origin field of the announcement 373 to be deleted 375 E: Encryption Bit -.If the encryption bit is set, the text payload of 376 the SAP is encrypted 378 C: Compressed bit - This bit indicates that the payload was compressed 379 using the gzip compression utility [7] 381 Header length 383 This is an 8 bit unsigned quantity giving the number of 32 bit 384 words following the main SAP header that contains the 385 authentication data . If this is non-zero, the payload is 386 authenticated, and an Authentication Header is present. 388 Kirstein et al. Document Expiration 26 September 1997 [PAGE 8] 389 Message Identifier Hash 391 A 16 bit quantity that, when used in combination with the 392 originating source, provides a globally unique id identifying 393 the precise version of this announcement. The message id hash 394 should be changed if any field of the session description is 395 changed. A value of zero means that the hash should be ignored and 396 the message should always be parsed. 398 Originating Source 400 This 32 bit field gives the IP address of the original source of 401 the message. It is permissible for this to be zero if the 402 message has not passed through a proxy relay and if the message id 403 hash is also zero. This is intended for backwards compatibility 404 with SAPv0 clients only. 406 Authentication Header 408 The authentication Header can be used for two purposes: 410 - Verification that changes to a session description or deletion 411 of a session are permitted. 413 - Authentication of the identity of the session creator. 415 In some circumstances only verification is possible because a 416 certificate signed by a mutually trusted person or authority is not 417 available. However, under such circumstances, the session 418 originator can still be authenticated to be the same as the 419 session originator of previous sessions claiming to be from the 420 same person. This may or may not be sufficient, depending on the 421 purpose of the session and the people involved. The format of the 422 Authentication Header is discussed in Section 3.2 424 Encryption Key Identifier 426 This is a 32 bit network byte integer which can be used to identify 427 the triplet or quadruplet described Section 2.3.1 and 2.3.2 of 428 {Encryption Key Identifier, Encryption Algorithm Identifier, 429 Encryption Key(s)}. PGP uses a 64-bit Key Identifier in its 430 Software. [ It would be more consistent if we used 64-bit Key 431 Identifiers throughout. However, this would require a corresponding 432 change in the SAP document [1] ]. 434 If the Encryption Algorithm Identifier Type is 0, then the 435 encryption is symmetric. A triplet is distributed out-of-band with 436 a singe symmetric key, and the methods of Section 2.3.1 are 437 applied. 439 If the Encryption Algorithm Identifier Type is 1, then the 440 encryption is hybrid. A quadruplet is distributed out-of-band with 441 a secret/public key pair, and the methods of Section 2.3.2 are 442 applied. 444 Kirstein et al. Document Expiration 26 September 1997 [PAGE 9] 445 Key IDs are generated when a new key or key pair is chosen. For 446 Symmetric Encryption Keys, the Key IDs should be randomly 447 distributed. For Asymmetric Encryption Keys, the Key ID is related 448 algorithmically to the Public Group Key; further details are given 449 in Sections 3.2.2 and 3.2.3. 451 Use of the Encryption Key Identifier is not recommended if 452 different sessions are to be announced with the same DES key. 454 Time-out 456 When the session payload is encrypted, and the session description 457 is being relayed or announced via a proxy, the detailed timing 458 fields in the SDP description are not available to the proxy. 459 This is because these fields are encrypted and the proxy is not 460 trusted with the decryption key. Under such circumstances, SAP 461 includes an additional 32-bit timestamp field stating when the 462 session should be timed out. The digital signature in the 463 authentication header encompasses the time-out so that a session 464 cannot be maliciously deleted by modifying its time-out in an 465 announcing proxy. The value is an unsigned quantity giving the NTP 466 time [8] in seconds at which time the session is timed out. It is 467 in network byte order 469 Text Payload 471 When there is no encryption, the encryption bit is not set and 472 this format is as defined in the SDP [4] draft. 474 Encrypted Text Payload 476 This is present when the text payload has been encrypted. The 477 format is discussed in Section 3.3. 479 3.2 Authentication Header 481 3.2.1 Generic Format 483 The generic format of the Authentication Header is given below. We have 484 defined it both using the PGP and the Simple Public Key mechanisms. 486 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | V=1 |P| Auth| | 490 |+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Format Specific Authentication Subheader | 492 | .. | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 V: Version number 497 The SAP Authentication Header version number is 1 for this 498 release.(3 bits) 500 Kirstein et al. Document Expiration 26 September 1997 [PAGE 10] 501 P: Padding Bit 503 If necessary the data in the Authentication Header is padded to be 504 a multiple of 32 bits and the Padding bit is set. In this case the 505 last byte of the Authentication Header contains the number of 506 padding bytes (including the last byte) that must be discarded. 508 Auth 510 The Authentication Type is a 4 bit encoded field that denotes the 511 authentication infrastructure the sender expects the recipients to 512 use to check the authenticity and integrity of the information. 513 This defines the format of the Authentication Subheader and can 514 take the values: 516 1 PGP including the public key identifier 517 2 Simple Public Key Format including the public key 518 identifier 519 3 PGP with the public key included 520 4 Simple Public Key Format with the public key included 521 5 PGP with the certificate included 522 6 Simple Public Key Format with the certificate included 524 The specific formats for the PGP and Simple Public Key variants of the 525 Header are discussed in Sections 3.2.2 and 3.2.3. 527 3.2.2 PGP Format 529 The generic description of the PGP packets is presented in [2]. For PGP 530 the basic Authentication Subheader comprises a digital signature packet 531 as below. This involves the use of a hash code, or message digest 532 algorithm, and a public key encryption algorithm. The format for 533 applying PGP to the payload for authentication purposes is discussed 534 below. For case 1 the Authentication Subheader contains a Digital 535 Signature Packet only. For cases 3 and 5 a Public Key Packet or a 536 Certificate Packet are also contained respectively. These are defined 537 in Appendix B and [2]. 539 Digital Signature Packet: 541 a) packet structure field (2, 3, or 5 bytes); 10001000(1 byte plf) 542 10001001 (2 byte plf) 10001010(4 byte plf) plf packet length field 544 b) version number = 2 or 3 (1 byte); (3) 546 c) length of following material included in MD calculation (1 547 byte, always value 5); (5) 549 d) (d1) signature classification (1 byte); (hex value 00 document) 550 (d2) signature time stamp (4 bytes); (time of signing) 552 e) key ID for key used for signing (8 bytes); 554 Kirstein et al. Document Expiration 26 September 1997 [PAGE 11] 555 f) public-key-cryptosystem (PKC) type (1 byte); (1 RSA) 557 g) message digest algorithm type (1 byte); (1 MD5) 559 h) first two bytes of the MD output, used as a checksum (2 bytes); 561 i) a byte string of encrypted data holding the RSA-signed digest. 563 The length of field (a) depends on the size of the key used for 564 signing. If 512, 768 or 1024 then the length will be 2 ,3 or 5 565 respectively. The first byte is Cipher Type Byte (CTB) and its 566 value is 10001000 for key size 512, 10001001 for key size 768 and 567 10001010 for key size 1024. The remaining 1,2 or 4 bytes of the 568 packet structure field gives the length of the packet. 570 The length of RSA signed digest of (i) also depends on the size of 571 the key used. For keys 512, 768 or 1024 the size is 64, 96 or 128 572 bytes respectively 574 3.2.3 Simple Public Key Format 576 The generic description of the PKCS#7 packets is presented in [3]. For 577 the Simple Public Key format the basic Authentication Subheader is as 578 follows: 580 1 2 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | DA | E A I D | | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | 64 bit key identifier | 586 | .. | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | 128 bit payload digest | 589 | .. | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Time Stamp | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Encrypted block | 594 | .. | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Notes 599 DA, the Digest Algorithm Identifier (5 bits), specifies the 600 algorithm used to digest the data. This can currently have the 601 following values: 603 1 - RSA's MD2 algorithm as defined in RFC 1319. 604 2 - RSA's MD5 algorithm as defined in RFC 1321 605 3 - The SHA Secure Hash Algorithm 607 Kirstein et al. Document Expiration 26 September 1997 [PAGE 12] 608 EAID, the Encryption Algorithm Identifier(1 byte), specifies the 609 algorithm used to encrypt the digest with the originator's secret 610 key. Strictly speaking this field is optional as it is already 611 uniquely specified by the Key Identifier which points to a 612 quadruplet which has already been distributed out-of-band. It is 613 repeated here solely for compatibility reasons. 615 Key Identifier (EKID) is the 64 least significant bits of the 616 public key of the originator. In the PKCS#7 standard the key is 617 identified by specifying the "issuerAndSerialNumber" of the 618 certificate containing the public key. This has two fields namely 619 the Distinguished Name of the Certificate Issuer and the serial 620 Number of the Certificate. The Distinguished Name can be 621 arbitrarily long, being a sequence of Relative Distinguished Names, 622 and the Serial Number is simply an integer. This was considered to 623 be too long and the 64-bit key identifier, as used in PGP, was 624 thought to provide the necessary information. 626 Payload Digest is the 128 bit output from digesting the payload 627 with the DA. 629 Time Stamp is in NTP Time Format as specified in RFC1119 [8]. 631 Encrypted Block: The input to the digest encryption process starts 632 at the beginning of the Authentication Subheader and continues 633 until the end of the UTCTime field. If the Digest Encryption 634 Algorithm is rsaEncryption the block type is 01 as specified for 635 PEM message digest encryption in RFC1423. 637 If the Authentication Type is 4 or 6 then either a public key or a 638 certificate is included after the basic Subheader. 640 3.3 Encrypted Payload Format 642 3.3.1 Generic Format 644 The format of the Encrypted Payload depends on the type of encryption 645 used to encrypt the SDP text payload [4]. If no encryption has been 646 used only the Text payload is present. If encryption has been used then 647 the Encryption Key Identifier field points to either a triplet for 648 symmetric encryption or a quadruplet for asymmetric encryption. 650 3.3.2 Symmetric Encryption 652 If the Encryption Algorithm Identifier indicates use of symmetric 653 encryption, ie the first bit is zero, then the payload has been 654 encrypted symmetrically with no use of asymmetric encryption. In 655 addition the encrypted payload has a random field added prior to 656 encryption as below: 658 Kirstein et al. Document Expiration 26 September 1997 [PAGE 13] 659 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | P| 31 bit random field | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | text payload | 665 | ....... | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Notes 670 Random Field 672 This field is only present when payload is encrypted using 673 symmetric encryption and is used to perform the randomisation task 674 normally performed by an initialisation vector in algorithms such 675 as DES. This 31 bit field should contain a genuinely random 676 number. 678 P: Encryption Padding Bit 680 This bit indicates that the payload was padded prior to encryption. 681 The last byte of the encrypted payload indicates how many padding 682 bytes were added. 684 The data following the Timeout field is decrypted using the algorithm 685 specified above. Further details on the encryption algorithms are 686 given in [6, 12, 13]. 688 3.3.3 Hybrid Encryption 690 If the value of the first bit of the Encryption Algorithm Identifier is 691 set to 1, then hybrid encryption is used; currently only those based on 692 PGP or Simple Public Key formats are defined for the asymmetric 693 portions. In these cases a Privacy Header (PH) is placed in front of 694 SDP stream, which contains a Session Encryption Key (SEK). 696 In the PGP case there is no need for the Symmetric Encryption Algorithm 697 to be specified as this is always IDEA. The formats for the PGP and 698 Simple Public Key type privacy headers are as below. 700 3.3.4 PGP Format Privacy Header 702 If the value of the Encryption Algorithm Identifier Algorithm is 1 then 703 the PGP format is used. In this case the Privacy Header is composed of 704 a Public Key Encrypted Packet. The purpose of this packet is to convey 705 the one-time session key used to encrypt the message to the recipient 707 Kirstein et al. Document Expiration 26 September 1997 [PAGE 14] 708 in a secure manner. This is done by encrypting the session key with 709 the group public key so that only a member of the group can recover the 710 session key. (Note that plf is the packet length field) 712 Public Key Encrypted Packet: 714 76543210 715 a) a packet structure field; (2,3,5 bytes)) 10000100 716 (1 byte plf) 10000101(2 byte plf) 10000110 (4 byte plf) 718 b) a byte, giving the version number, 2 or 3; (1byte) 3 720 c) a number ID field, giving the ID of a key; (8bytes) 722 d) a byte, giving a PKC number; (1byte) (1 RSA) 724 e) a byte string of encrypted data (DEK). (64, 96 or 128 bytes) 726 3.3.5 Simple Public Key Format Privacy Header 728 If the value of the Encryption Algorithm Identifier Algorithm is 2 then 729 the Simple Public Key Format is used. In this case the Privacy Header 730 is as follows: 732 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | NGTH | E A I D 1 | E A I D 2 | | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Encrypted Session Encryption Key | 738 | ............ | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 Notes 743 LENGTH, (1 byte) this specifies the length of the Privacy Header 745 EAID1, the (asymmetric) Encryption Algorithm Identifier (1 byte) 746 identifies the asymmetric algorithm used to encrypt the Session 747 Encryption Key (SEK). The values this can take are specified in 748 Section 3.3.6. Strictly speaking this is not necessary as it has 749 already been completely specified by the Key Identifier in the main 750 SAP header. It is duplicated here for compatibility reasons. 752 EAID2, the (symmetric)Encryption Algorithm Identifier (1 byte) 753 identifies the symmetric algorithm used to encrypt the content. The 754 values this can take are specified in Section 3.3.6. 756 Kirstein et al. Document Expiration 26 September 1997 [PAGE 15] 757 Encrypted Session Encryption Key: This field contains the encrypted 758 SEK. When the Key Encryption Algorithm is rsaEncryption the block 759 type is specified to be 2. 761 3.3.6 Supported Algorithms 763 For the authentication the following Message Digest Algorithms are 764 defined. Simple Public Key Format packets can use any of the specified 765 types but PGP always uses MD5. 767 Message Digest Type Algorithm 769 1 MD5 770 2 MD2 771 3 SHA 773 For the Encryption Algorithm Identifier there are several Algorithms 774 supported for both Symmetric and Asymmetric Encryption. For Symmetric 775 Encryption the first bit is set to 0 and for Asymmetric Encryption it 776 is set to 1. The next 3 bits specify the Algorithm and the final four 777 bits denote the key size used. The following Algorithm Identifiers are 778 currently defined: 780 EAID Algorithm ALG Key Length 781 00010010 DES 1 56 bits 782 00100011 Tiple DES 2 112 bits 783 00110100 IDEA 3 128 bits 784 01000100 RC2 4 128 bits 785 01010100 RC4 5 128 bits 787 10010101 RSA/PGP 1 256 bits 788 10010110 RSA/PGP 1 512 bits 789 10010111 RSA/PGP 1 768 bits 790 10011000 RSA/PGP 1 1024 bits 791 10011001 RSA/PGP 1 2048 bits 792 10100101 RSA/SPK 2 256 bits 793 10100110 RSA/SPK 2 512 bits 794 10100111 RSA/SPK 2 768 bits 795 10101000 RSA/SPK 2 1024 bits 796 10101001 RSA/SPK 2 2048 bits 798 The general format of the Encrypted Payload is given below. Here the 799 format of the Privacy Header depends on whether PGP or Simple Public 800 Key (SPK) format is used. The Encrypted Text Payload is the result of 801 encrypting the SDP text payload with the Symmetric Encryption Key 802 specified in the Privacy Header 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Privacy Header | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Encrypted SDP Payload | 808 | .... .. | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 Kirstein et al. Document Expiration 26 September 1997 [PAGE 16] 812 Appendix A: Authors Addresses 814 Peter Kirstein, Goli Montasser Kohsari and Edmund Whelan are at 815 University College London and their email-ids are: 817 P.Kirstein@cs.ucl.ac.uk 818 G.Montasser-Kohsari@cs.ucl.ac.uk 819 E.Whelan@cs.ucl.ac.uk 821 Dept of Computer Science 822 University College London 823 Gower Street 824 London WC1E 6BT England 826 Kirstein et al. Document Expiration 26 September 1997 [PAGE 17] 827 Appendix B: PGP format 829 Public key Packet 831 a) Packet structure field (2 3 5 bytes) 100110 (As 832 defined in 1) 834 b) version number = 2 or 3 (1byte) (3) 836 c) time stamp of key creation (4bytes) 838 d) validity period in days (2 bytes) (0 means forever) 840 e) public key cryptosystem (PKC) type (1 byte) (1 RSA) 842 f) Multi-precision integer (MPI) of RSA public modulus n; 844 g) MPI of RSA public encryption exponent e 846 User ID Packet 848 a) packet structure field (2 bytes) 01110101 849 b) User Id String (users name and email id 850 enclosed in <>) 852 Certificate 854 a) one public key packet (defined above) 855 b) one or more user ID packets (defined above) 856 c) Zero or more signature packets (defined in Section 3.2.2) 858 Kirstein et al. Document Expiration 26 September 1997 [PAGE 18] 859 Appendix C: PKCS#7 format 861 It is expected that an Authentication Subheader which adheres to the 862 PKCS#7 standard will be implemented in a later version of the SAP 863 header protocol. This would enable compatibility between information 864 contained in the Authentication Subheader and S/MIME MUAs for example. 865 In this version of the standard it was considered that, although we 866 wanted to follow the PKCS standards fairly closely, we did not want to 867 force developers to implement full ASN.1 typing and BER encoding. The 868 header detailed in the main document follows PKCS#7 in principle as it 869 contains similar fields. One difference is the use of a Key Identifier 870 rather than "issuerAndSerialNumber" as detailed above. Also, Object 871 Identifiers were not used here. 873 In a PKCS#7 compliant SAP protocol it would be expected that the 874 Authentication Subheader would consist of an ASN.1 SignerInfo type as 875 below: 877 SignerInfo ::= SEQUENCE { 878 version Version, 879 IssuerAndSerialNumber IssuerAndSerialNumber, 880 digestAlgorithm DigestAlgorithmIdentifier, 881 authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL, 882 digestEncryptionAlgorithm DigestEncryptionAlgorithmIdentifier, 883 encryptedDigest EncryptedDigest, 884 unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL } 886 If the Authentication Type is "4" (PKCS#7 + public key) the public key 887 would be appended to the Authentication Subheader. This is in a form 888 equivalent to that defined in PKCS#1 as: 890 RSAPublicKey ::= SEQUENCE { 891 modulus INTEGER 892 publicExponent INTEGER } 894 If the Authentication Type is "6" (PKCS#7 + certificate) the 895 certificate would be appended to the Authentication Subheader. This 896 Certificate is an ASN.1 type as defined in X.509. 898 If asymmetric encryption is used a PKCS#7 compliant Privacy Header 899 would consist of an ASN.1 RecipientInfo and EncryptedContentInfo type 900 as below: 902 RecipientInfo ::= SEQUENCE { 903 version Version, 904 issuerAndSerialNumber IssuerAndSerialNumber, 905 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 906 encryptedKey EncryptedKey } 908 EncryptedContentInfo ::= SEQUENCE { 909 contentType ContentType, 910 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 911 encryptedContent [0] IMPLICIT EncryptedContent OPT } 913 Kirstein et al. Document Expiration 26 September 1997 [PAGE 19] 914 Acknowledgements 916 SAP and SDP were originally based on the protocol used by the sd 917 session directory from Van Jacobson at LBNL. The design of SAP was 918 funded by the European Commission under the Esprit 7602 "MICE" project, 919 and the Telematics 1007 "MERCI" project. 921 References 922 [1] M.Handley `SAP: Session Announcement Protocol'' INTERNET-DRAFT, 923 draft-ietf-mmusic-sap-00.txt, 11/27/1996. 925 [2] D.Atkins, '' PGP Message Exchange Formats'' , RFC 1991, August 926 1996. 928 [3] PKCS#7, Cryptographic Message Syntax Standard, RSA Laboratories, 929 Version 1.5, November 1993 931 [4] M.Handley, V. Jacobson, ``SDP: Session Description Protocol'', 932 INTERNET-DRAFT, draft-ietf-mmusic-sdp-02.txt, 11/27/1996. 934 [5] R. Housley , W. Ford , T. Polk Internet public Key Infrastructure 935 INETRNET- DRAFT, draft-ietf-pkix-ipki-part1-03.txt December 1996. 937 [6] National Bureau of Standards, Data Encryption Standard, Federal 938 Information Processing Standards Publication 46, January 1977 940 [7] P. Deutsch, ``GZIP file format specification version 4.3'', RFC 941 1952, May 1996. 943 [8] D. Mills, ``Network Time Protocol version 2 specification and 944 implementation", RFC1119, 1st Sept 1989. 946 [9]X.208 Specification of 947 Abstract Syntax Notation One (ASN.1) ITU-T Recommendations 1988 949 [10] PKCS #1 RSA Encryption Standard RSA Laboratories, Version 1.5, 950 November 1993 952 [11] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with 953 Minimal Control'', RFC 1890, January 1996 955 [12] P. Metzger, P. Karn, W. Simpson, The ESP Information Triple 956 DES-CBC Transformation, 10/02/1995 RFC850 958 [13] ANSI X3.92-1981. American National Standards Data Encryption 959 Algorithm. American National Standards Institute, Approved 30 960 December 19990 962 [14] For details of ENTRUST see http://www.entrust.com/ [15] For 963 details of SECUDE see http://www.darmstadt.gmd.de/secude/ 965 Kirstein et al. Document Expiration: 26 September 1997 [PAGE 20]