idnits 2.17.1 draft-ietf-mmusic-sap-sec-01.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-23) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 1) being 59 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 a Security Considerations 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. ** There are 8 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 23 has weird spacing: '...ctories on f...' == Line 555 has weird spacing: '... is set and t...' == Line 593 has weird spacing: '...padding bytes...' == Line 733 has weird spacing: '...15] For detai...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 691 looks like a reference -- Missing reference section? '2' on line 694 looks like a reference -- Missing reference section? '3' on line 697 looks like a reference -- Missing reference section? '4' on line 700 looks like a reference -- Missing reference section? '5' on line 703 looks like a reference -- Missing reference section? '6' on line 706 looks like a reference -- Missing reference section? '10' on line 718 looks like a reference -- Missing reference section? '14' on line 731 looks like a reference -- Missing reference section? '15' on line 733 looks like a reference -- Missing reference section? '7' on line 709 looks like a reference -- Missing reference section? '8' on line 712 looks like a reference -- Missing reference section? 'PAGE 10' on line 456 looks like a reference -- Missing reference section? 'PAGE 11' on line 509 looks like a reference -- Missing reference section? '16' on line 735 looks like a reference -- Missing reference section? 'PAGE 12' on line 565 looks like a reference -- Missing reference section? '12' on line 724 looks like a reference -- Missing reference section? '13' on line 727 looks like a reference -- Missing reference section? 'PAGE 13' on line 620 looks like a reference -- Missing reference section? 'PAGE 14' on line 666 looks like a reference -- Missing reference section? 'PAGE 15' on line 688 looks like a reference -- Missing reference section? '9' on line 715 looks like a reference -- Missing reference section? '11' on line 721 looks like a reference -- Missing reference section? 'PAGE 16' on line 738 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 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 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), ftp.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) has been specified in such a way 32 that authentication and privacy can be assured. However 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 formats 36 based on the DES, PGP and PKCS#7 standards. It is a companion document 37 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. [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 EK Encryption Key 55 EKID Encryption Key Identifier 56 IETF Internet Engineering Task Force 57 MD Message Digest 58 MMUSIC Multiparty Multimedia Session Control 59 PEM Privacy Enhanced Mail 60 PGP Pretty Good Privacy 61 PH Privacy Header 62 PK Public Key 63 PKCS Public Key Cryptographic System 64 PKCS Public Key Cryptography Standard (as in PKCS#7) 65 SAP Session Announcement Protocol 66 SDP Session Descriptor Protocol 67 SEK Session Encryption Key 68 SK Secret Key 69 SGK Group Key 70 SHA Hash Algorithm 72 Kirstein et al. [PAGE 2] 73 1. Introduction 75 An Mbone session directory is used to advertise multimedia conferences, 76 and to communicate the session addresses (whether multicast or unicast) 77 and conference-tool- specific information necessary for participation. 78 Such sessions are be announced using the Session Announcement Protocol 79 (SAP) described in a companion draft [1]. The SAP protocol allows for 80 the incorporation of authentication of the announcement originator, and 81 for privacy of the session details; however neither the choice of 82 authentication algorithms used, nor the mechanisms for encrypting the 83 SAP Session Description, are detailed in the draft. 85 This document describes the format of the authentication header for SAP 86 data packets that use security services based on PGP [2] or PKCS#7 [3]. 87 The SAP document also provides for the confidentiality services required 88 for the SDP payload [4], which describes the conference set-up 89 parameters. This document describes how both symmetric and hybrid 90 symmetric/public key encryption algorithms should be used to provide 91 private announcements. 93 Much of this document is concerned with security considerations which 94 have not yet been subject to suitable peer-review, and this document 95 should not be considered authoritative in this area. 97 2. Authentication and Encryption of Announcements 99 2.1 Introduction 101 It is necessary to provide authentication and integrity of the Session 102 Announcement to ensure that only authorised persons modify Session 103 Announcements and to provide facilities for announcing securely 104 encrypted sessions - providing the relevant proposed conferees with the 105 means to decrypt the data streams. The Session Announcements are made to 106 announce to all potential conferees the existence of a conference. It 107 has, however, another function - to try to minimise conflicts for Mbone 108 resources by spreading out the number of simultaneous conferences. Thus 109 there are a number of threats which we must try to address in the 110 securing of the Session Announcement, and some constraints. These 111 include the following: 113 - Authentication and Integrity of Session Announcement 115 Here it is necessary to ensure that the Session Announcement comes from 116 the person claimed, and is indeed an authorised announcement. Since 117 subsequent announcements will modify caches of future conferences, it is 118 possible otherwise to spoof an original announcement, and thereby at 119 least cause a Denial of Service attack 121 - Confidentiality of Conference Details for Session Announcement 123 Here it is at least necessary to hide the details of the addresses and 124 media formats used. In order to minimise schedule conflicts; it is 125 desirable to keep at least the time of a conference known, even if all 126 other details are concealed. 128 Kirstein et al. [PAGE 3] 129 Three types of announcement are supported: 'unsecured', 'authenticated' 130 and 'authenticated and encrypted'. The 'unsecured' type is described in 131 the SAP specification [1] and so only the latter two types are described 132 below. 134 2.2 Symmetric and Asymmetric Encryption 136 The simplest versions of encryption used are symmetric ones; here the 137 same encryption key 'a' is used to encrypt and decrypt a message. This 138 means that, if E{a,M) is the operation of encrypting the message M with 139 the key a and algorithm E, then the operation E{a, E{a, M}} reproduces 140 the original message M. Because this form of encryption relies on the 141 sender and receiver having the same key, it cannot be used for 142 authentication. An alternative form of encryption is asymmetric 143 encryption. Here two keys, a and b, are used. When these are used one 144 after the other to encrypt a message the original message is obtained. 145 Mathematically, these keys and the encryption algorithm E have the 146 property that E{a, E{b, M}} and E{b, E{a, M}} both produce the original 147 message M - but given a, it should be impractical to deduce b and 148 vice versa. 150 With an asymmetric encryption algorithm, a Public Key Cryptographic 151 System (PKCS) can be derived in which one of the keys, say the Public 152 Key (PK), is published in some way while the other, the Secret Key (SK), 153 is kept secret. Using such a PKCS, it is possible to achieve both 154 confidentiality and authentication. Encrypting a message with the 155 recipient's Public Key ensures confidentiality as only the recipient 156 with the corresponding SK can decrypt the message. Encrypting a message 157 with the SK of the sender ensures authentication as only the sender 158 could have sent the message initially whereas anybody having access to 159 the Public Key can verify that it was indeed sent by the person holding 160 the corresponding Secret Key. 162 Two complete systems, which can achieve both authentication and 163 confidentiality using particular PKCS systems, are PGP [2] and PKCS#7 164 [3]; similar mechanisms are used, but different encryption algorithms 165 and formats are used. The differences between the algorithm and format 166 details for these two systems are elaborated in Sections 3.2 and 3.3. 168 2.3 Authenticated Announcements 170 In order to send authenticated announcements it is possible to use the 171 algorithms of either PGP [2] or the PKCS#7 [3] systems. The resulting 172 format will be substantially different; the exact details are given in 173 Sections 3.2 and 3.3. For each format, the announcement originator 174 calculates a message digest of the announcement. The originator's 175 secret key is used to encrypt the message digest, together with an 176 electronic timestamp, thus forming a digital signature. The originator 177 sends the digital signature along with the message; the receiver 178 receives the message and the digital signature, and recovers the 179 original message digest from the digital signature by decrypting it 180 with the sender's public key. The receiver computes a new message 181 digest from the message, and checks to see if it matches the one 182 recovered from the digital signature. If it matches, then this is 184 Kirstein et al. [PAGE 4] 185 considered adequate proof that the message was not altered, and that it 186 came from the originator who owns the public key used to check the 187 signature. 189 Each Session announcement contains a message ID hash [4]. The 190 specifications for SAP announcements [1] states that such announcements 191 may be repeated frequently, but that if any change is made in the 192 announcement, a different message ID must be used; as a result, a 193 different message ID hash will be appended to the message. As a result, 194 it is only necessary to authenticate an announcement the first time it 195 is received. 197 To save space in the announcement message, only a public key identifier 198 is generally included. It is then assumed that the public key itself 199 has either been distributed previously or can be retrieved from a cache 200 or directory. Optionally the Public Key itself can be included in the 201 announcement removing the need for prior distribution. Consequently, 202 providing that the Public Key is already available in a local cache or 203 Directory, or is distributed with the announcement, one can be sure that 204 the same originator sent the announcement. Only if the full public key 205 information, and a Certificate Authority infrastructure, are accessible 206 [5], can the originator be identified. 208 2.4 Authenticated and Encrypted Announcements 210 2.4.1 Introduction 212 When it is desired to make private announcements, it is necessary to 213 encrypt the set-up details of the conference. The normal way of 214 providing such encryption is to use only a symmetric encryption 215 algorithm such as the Data Encryption Standard (DES [6]) to encrypt 216 such a session using a Session Encryption Key (SEK); this algorithm is 217 used because other systems, such as the asymmetric RSA system [10], are 218 too computation-intensive for large amounts of data - though they are 219 economic for smaller amounts. For symmetric encryption systems, the SEK 220 must be securely distributed to all authorised recipients. 222 2.4.2 Distribution of Session Encryption Keys 224 There are various ways that the SEK could be distributed; all rely on 225 distributing some shared secret in advance to the intended participants 226 in the conference group. When this process takes place out of band, it 227 is not described further in this document. 229 Many symmetric encryption algorithms, e.g. DES [6] are known to be easy 230 to break; with such algorithms, it is undesirable to re-use the SEK many 231 times. For this reason, and to improve security, a set of SEKs may be 232 distributed out-of-band; the recipients may then try to decrypt the 233 announcement by trying each of these SEKs in turn. 235 As in Section 2.3, one may use the fact that if any change is made in 236 the announcement, a different message ID, and hence message ID hash is 237 used; it is only necessary to attempt to decrypt an announcement message 238 the first time it is received. The basic symmetric system is contained 240 Kirstein et al. [PAGE 5] 241 in SAP [1]. To improve efficiency, it would be possible to use 242 symmetric encryption with a pre-distributed Key Identifier (KeyID). 243 However, because of the potential weakening of the security by the use 244 of KeyIDs, and the consequent need to use more secure symmetric 245 algorithms, we do not recommend this technique. Moreover, by adopting 246 the use of asymmetric Public Key technology for such SEK distribution as 247 discussed below, we gain both efficiency and have a better integrated 248 approach to authentication. 250 2.4.3 Use of Public Key Algorithms 252 Public Key Cryptography is one mechanism for minimising the need for 253 secure transmission of shared secrets; this was already used in the 254 Authenticated Announcements of Section 2.2. It would be possible to use 255 these encryption algorithms on the whole announcement message but this 256 would be inefficient because the asymmetric encryption algorithms 257 normally use much longer encryption keys, and are much more resource 258 intensive, than the symmetric ones. For this reason it is more efficient 259 to use a combination of symmetric and Public Key algorithms. Now a 260 random Session Encryption Key (SEK) is generated as in Section 2.4.1. A 261 Privacy Header (PH) is constructed containing the SEK, which is 262 encrypted with the asymmetric encryption algorithm. It is now only 263 necessary to distribute a Secret Group Key (SGK) and Public Group Key 264 (PGK) i.e. {SGK, PGK} to decrypt the SEK. However, this pair needs to be 265 distributed only once as long as the group membership does not change; 266 it is possible to re-use the same group keys for many sessions, with 267 different SEKs. This minimises the number of times the prior key 268 distribution sequence must be followed. 270 It should be noted that because a Group Key is used in the above, it is 271 not possible to use the same Header to authenticate the sender uniquely, 272 though it is authenticated automatically that the sender is one of the 273 group which has reserved the asymmetric encryption key pair. It is 274 still possible to authenticate the identity of the sender by using a 275 different Authentication Key for the Authentication Header as described 276 in Section 2.3. 278 It would be possible to use a similar technique using symmetric 279 encryption with a strong encryption algorithm and an encryption key 280 Identifier instead of the Public Key Group Key, However, we believe the 281 Public Key method to be superior so this variant is not pursued. 283 2.4.4 Encrypting Announcements 285 We will now provide some more detail. If the payload is to be 286 compressed, this is performed prior to encryption. 288 When an announcement is to be encrypted, the payload is encrypted using 289 symmetric encryption. In this case each such encryption key is used only 290 once; a new Session Encryption Key (SEK) is generated as a random number 291 for each announcement. Since it is to be used only once, the SEK is 292 bound to the message and transmitted with it in a Privacy Header. The 293 sequence is as follows: The Privacy Header contains the SEK, encrypted 294 with the group's Public Group Key, together with information identifying 296 Kirstein et al. [PAGE 6] 297 the Group Key which has been used. The encrypted Payload is appended to 298 the Privacy Header. 300 2.4.5 Decrypting Announcements 302 Upon receiving a new announcement with the encryption bit set, a 303 receiver should attempt to decrypt the announcement with the relevant 304 group private key or their own private key as indicated in the Privacy 305 Header. The sequence is as follows: 307 1. Prior to the announcement, the group's Public/Secret Group Key 308 pair is distributed securely. 310 2. From the announcement, the receiving participants determine 311 which Public Group Key has been used by looking at the 312 information contained in the Privacy Header. 314 3. They then decrypt the Session Encryption Key (SEK) with the SGK 315 corresponding to the PGK identified in Step 2 and obtain other 316 necessary information such as the content encryption algorithm 317 from the Privacy Header. 319 4. The authorised receivers decrypt the encrypted text payload using 320 the SEK and the relevant symmetric content encryption algorithm, 321 which was used to encrypt the payload. 323 Note that if an encrypted announcement is being announced via a proxy, 324 then there may be no way for the proxy to discover that the announcement 325 has been superseded, and so it may continue to relay the old 326 announcement in addition to the new announcement. SAP provides no 327 mechanism to chain modified encrypted announcements, so it is advisable 328 to announce the unmodified session as deleted for a short time after 329 the modification has occurred. This does not guarantee that all proxies 330 have deleted the session, and so receivers of encrypted sessions should 331 be prepared to discard old versions of session announcements that they 332 may receive (as identified by the SDP version field). In most cases 333 however, the only stateful proxy will be local to (and known to) the 334 sender, and an additional (local-area) protocol involving a handshake 335 for such session modifications can be used to avoid this problem. 337 3. Secured SAP Packet Formats 339 Both Authentication and Privacy can be achieved using PGP [2] or PKCS#7 340 [3] format packets. In Section 3.1 we discuss the generic packet format 341 defined in SAP [1]. In Section 3.2 we consider the formats of the 342 Authentication Header, and in Section 3.3 that of the encrypted payload. 344 It would be possible to define our own versions of the packets for this 345 application. In that case the formats would be simpler, but all the 346 implementations would have to be coded using the basic encryption 347 libraries, and a new infrastructure would have to be defined. Both PGP 348 and PKCS#7 already have complete implementations and, by using their 349 formats, several application tool kits are already available (e.g. 350 Entrust [14], Secude [15]). In addition, these formats also have 352 Kirstein et al. [PAGE 7] 353 complete infrastructures defined around them. For these reasons, we have 354 chosen to retain enough compatibility to ease the eventual 355 implementation, while simplifying the formats as far as possible within 356 such a constraint. There is an additional advantage in this approach; it 357 will be possible to send session announcements by the encrypted Session 358 Invitation Protocol or by electronic mail using PGP or S-MIME, and 359 re-use much of the same code as with SAP. 361 3.1 Secured SAP Packet Format 363 The SAP data packets as defined in [1] has the following format: 365 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | V=2 | MT |E|C| Header Length | 16 bit Message ID Hash | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Originating Source | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 372 | Authentication Header (Optional) | 373 | .................. | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | 32 bit Time-Out Field (Optional) | 376 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Text Payload (Possibly Encrypted) | 378 | .................. | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Notes: 383 Version Number, V: This is a 3-bit field and has the value 2 for this 384 version of SAP [1] 386 Message Type, MT: This defines the contents of the payload and can be 388 0. Session Descriptor Announcement Packet in which case the 389 payload is an SDP session description as described in [4] 391 1. Session Description Deletion Packet in which case the payload 392 is a singleSDP line containing the origin field of the 393 announcement to be deleted 395 Encryption Bit, E: -. If this is set, the text payload has been 396 encrypted 398 Compression Bit, C: If this is set the payload has been compressed using 399 the gzip compression utility [7] 401 Header length: This is an 8 bit unsigned quantity giving the number of 402 32 bit words following the main SAP header that contains the 403 authentication data. If this is non-zero, the payload is 404 authenticated, and an Authentication Header is present 406 Kirstein et al. [PAGE 8] 407 Message Identifier Hash: This is a 16 bit quantity that, when used in 408 combination with the originating source, provides a globally unique 409 id identifying the precise version of this announcement. The message 410 id hash should be changed if any field of the session description is 411 changed. A value of zero means that the hash should be ignored and 412 the message should always be parsed. 414 Originating Source: This 32-bit field gives the IP address of the 415 original source of the message. It is permissible for this to be zero 416 if the message has not passed through a proxy relay and if the message 417 id hash is also zero. This is intended for backward compatibility with 418 SAPv0 clients only. 420 Authentication Header: This can be used for two purposes: 422 1. Verification that changes to a session description or deletion 423 of a session are permitted 425 2. Authentication of the identity of the session creator. 427 In some circumstances only verification is possible because a 428 certificate signed by a mutually trusted person or authority is not 429 available. However, under such circumstances, the session originator 430 can still be authenticated to be the same as the session originator of 431 previous sessions claiming to be from the same person. This may or may 432 not be sufficient, depending on the purpose of the session and the 433 people involved. The precise format of the Authentication Header is 434 discussed in Section 3.2. 436 Timeout: When the session payload is encrypted, and the session 437 description is being relayed or announced via a proxy, the detailed 438 timing fields in the SDP description are not available to the proxy. 439 This is because these fields are encrypted and the proxy is not 440 trusted with the decryption key. Under such circumstances, SAP 441 includes an additional 32-bit timestamp field stating when the session 442 should be timed out. The digital signature in the authentication 443 header encompasses the time-out so that a session cannot be 444 maliciously deleted by modifying its time-out in an announcing proxy. 445 The value is an unsigned quantity giving the NTP time [8] in seconds 446 at which time the session is timed out. It is in network byte order 448 Privacy Header: This is present when the text payload has been encrypted 449 using hybrid encryption. 451 Text Payload: When there is no encryption, the encryption bit is not set 452 and this format is as defined in the SDP [4] draft. However, when 453 encryption has been used the payload is encrypted and the format is 454 discussed in Section 3.3. 456 Kirstein et al. [PAGE 10] 457 3.2 Authentication Header 459 3.2.1 Generic Format 461 The generic format of the Authentication Header is given below. The 462 structure of the Format Specific Authentication Subheader, using both 463 the PGP and the PKCS#7 formats, is discussed in Sections 3.2.2 and 3.2.3 464 respectively. 466 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | V=1 |P| Auth | Header Length | | 470 |+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+ | 471 | Format Specific Authentication Subheader | 472 | .................. | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Notes: 477 Version Number, V: For this release the version number is 1 (3 bits) 479 Padding Bit, P: If necessary the data in the Authentication Header is 480 padded to be a multiple of 32 bits and the Padding bit is set. In this 481 case the last byte of the Authentication Header contains the number of 482 padding bytes (including the last byte) that must be discarded. 484 Authentication Type, Auth: The Authentication Type is a 4 bit encoded 485 field that denotes the authentication infrastructure the sender 486 expects the recipients to use to check the authenticity and integrity 487 of the information. This defines the format of the Authentication 488 Subheader and can take the values: 490 1. PGP Format 491 2. PKCS#7 Format 492 3. PGP Format with the 'Certificate' included 493 4. PKCS#7 with the Certificate included 495 3.2.2 PGP Format 497 The generic description of the PGP packets is presented in [2]. For PGP 498 the basic Format Specific Authentication Subheader comprises a digital 499 signature packet as described in [2]. This involves the use of a hash 500 code, or message digest algorithm, and a public key encryption 501 algorithm. For the case when the Authentication type is 1 the Subheader 502 contains a Digital Signature Packet only with the hexadecimal signature 503 classification being <00> or <01>. The only Message Digest Algorithm is 504 1 (MD5) and the Public Key Cryptosystem (PKC) is 1, this being the RSA 505 system. If the type is 3 then a Certificate Packet is also appended to 506 the previous Signature Packet. A certificate packet is composed of the 507 following individual packets: 509 Kirstein et al. [PAGE 11] 510 (a) A Public Key Packet which defines the RSA public key 511 (b) A UserID packet 512 (c) A Signature Packet 514 The Public Key packet again has the Public Key Cryptosystem 1. In the 515 case of Signature Packet (c) the signature classification now takes the 516 hexadecimal values <10> to <13>. These packets are all detailed in [2]. 518 3.2.3 PKCS#7 Format 520 The Format Specific Authentication Subheader will, in the PKCS#7 case, 521 have an ASN.1 ContentInfo type with the ContentType being signedData. 522 Use is made of the option available in PKCS#7 to leave the content 523 itself blank as the content which is signed is, in this application, 524 already present as the text payload, whether this is encrypted or not. 525 Thus inclusion of it within the SignedData type would be duplication and 526 increase the packet length unnecessarily. The full specification for 527 this ASN.1 type is available in [3]. 529 There will only be one signerInfo and related fields corresponding to 530 the originator of the SAP announcement. Although it would be possible 531 to transfer the relevant information is a single signerInfo type rather 532 than the complete ContentInfo it is considered preferable to use the 533 latter for two reasons. Firstly, this is compatible with a wider range 534 of applications and security toolkits and secondly, that the certificate 535 can be included in a standard way. If the Authentication Type is 2 there 536 are no certificates or certificate revocation lists whereas if the 537 authentication type is 4 the originator's X.509 certificate is added in 538 the certificate field of this type. 540 In addition, for both type 2 and 4, use is made of the ability in PKCS#7 541 to authenticate various attributes as specified in PKCS#9 [16]. The 542 authenticatedAttributes field of the SignerInfo type is used and the 543 attribute which is authenticated is the SigningTime. This is a 544 mandatory field in this specification. 546 3.3 Encrypted Payload Format 548 3.3.1 Generic Format 550 The format of the Encrypted Payload depends on the type of encryption 551 used to encrypt the SDP text payload [4]. If no encryption has been used 552 only the Text payload is present. 554 If encryption has been used then the encryption bit in the main SAP 555 header is set and the payload is encrypted either symmetrically or 556 using hybrid encryption. For symmetric encryption the format is detailed 557 in Section 3.3.2 whereas hybrid encryption is detailed in Section 3.3.3. 558 For hybrid encryption there are two possibilities - PGP and PKCS#7 559 Formats. The application is expected to test whether the fields 560 immediately following the timeout field in the main SAP header is 561 compatible with the use of symmetric encryption; in that case it will be 562 a padding bit followed by a 31-bit random field, or whether it is 563 compatible with the use of hybrid encryption. In this case there is a 565 Kirstein et al. [PAGE 12] 566 very specific format to the first byte of the Privacy header, which 567 follows other time-out field in this case. 569 3.3.2 Symmetric Encryption 571 If symmetric encryption alone has been used then the encrypted payload 572 has a random field added prior to encryption as below. 574 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |P| 31 bit random field | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Text Payload | 580 | . . . | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Notes 585 Random Field: This field is only present when payload is encrypted 586 using symmetric encryption and is used to perform the randomisation 587 tasks normally performed by an initialisation vector in algorithms 588 such as DES. This 31-bit field should contain a genuinely random 589 number. 591 Padding Bit, P: This bit indicates that the payload was padded prior to 592 encryption. The last byte of the encrypted payload indicates how many 593 padding bytes were added. 595 The data following the Time-out field is decrypted using the algorithm 596 specified above. Further details on the encryption algorithms are given 597 in [6, 12, 13]. 599 3.3.3 Hybrid Encryption 601 If a combination of asymmetric and symmetric encryption has been used 602 then the part of the SAP packet following the time-out field has the 603 following structure. This effectively takes the form of a Privacy header 604 followed by the encrypted SDP payload, the precise format depending on 605 whether PGP or PKCS#7 formats have been used. The specific details for 606 each of these formats are described in Sections 3.3.3.1 and 3.3.3.2 607 respectively. 609 Privacy Header: 611 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | V=1 |P| Type | Header Length | | 615 |+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+ | 616 | Format Specific Privacy Subheader | 617 | .................. | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Kirstein et al. [PAGE 13] 621 Notes 623 Version, V: In this version the Version of the privacy Header is 1 625 Padding Bit, P: If necessary the data in the Privacy Header is padded to 626 be a multiple of 32 bits and the Padding bit is set. In this case the 627 last byte of the Privacy Header contains the number of padding bytes 628 (including the last byte) that must be discarded. 630 Format Type, Type: This can be either 1 for PGP or 2 for PKCS#7 format. 632 3.3.3.1 PGP Format Privacy Header 634 For the case when the Format Type is 1 the Format Specific Privacy 635 Subheader is composed of a PGP Public Key encrypted packet and the text 636 payload is a PGP Conventional Key Encrypted Packet. These are detailed 637 in [2]. The Public Key Cryptosystem is 1, this being defined as the RSA 638 system, and the only supported symmetric encryption algorithm is the 639 IDEA algorithm, corresponding to the Conventional encryption type byte 640 value of 1. 642 3.3.3.2 PKCS#7 Format Privacy Header 644 If the Type is 2 then the Format Specific Privacy Header is composed of 645 a PKCS#7 ContentInfo type with the ContentType being envelopedData. 646 These are detailed in [2]. In this case the Text Payload, which has been 647 symmetrically encrypted with the algorithm specified in the 648 contentEncryptionAlgorithm field, is effectively the encryptedContent 649 part of the structure. There will be only one recipientInfo structure 650 corresponding to the group certificate, which has been previously 651 distributed. The contentType in the EncryptedContentInfo structure is 652 "Data". 654 3.3.4 Supported Algorithms 656 In the case of the hybrid encryption the algorithms supported are 657 defined in [2,3] for PGP and PKCS#7 respectively. The details of the 658 algorithms used are an inherent part of the information sent in the 659 Privacy Header and Authentication Header and so it is not necessary to 660 specify in advance which are supported; this is open to change as new 661 algorithms arise and older ones are shown to insecure. 663 For the purely symmetric encryption case then currently only DES is 664 supported with a 56-bit Key length. 666 Kirstein et al. [PAGE 14] 667 Appendix A: Authors' Addresses 669 Peter Kirstein, Goli Montasser Kohsari and Edmund Whelan are at 670 University College London and their contact details are: 672 P.Kirstein@cs.ucl.ac.uk Tel: +44 71 380 7286 673 G.Montasser-Kohsari@cs.ucl.ac.uk Tel: +44 71 380 7215 674 E.Whelan@cs.ucl.ac.uk Tel: +44 71 419 3688 676 Dept of Computer Science Fax: +44 71 387 1397 677 University College London 678 Gower Street 679 London WC1E 6BT England 681 Acknowledgements 683 SAP and SDP were originally based on the protocol used by the sd session 684 directory from Van Jacobson at LBNL. The European Commission under the 685 Esprit 7602 "MICE" project, and the Telematics 1007 "MERCI" project 686 funded the design of SAP. 688 Kirstein et al. [PAGE 15] 689 References 691 [1] M.Handley `SAP: Session Announcement Protocol'' INTERNET-DRAFT, 692 draft-ietf-mmusic-sap-00.txt, 11/27/1996. 694 [2] D.Atkins, '' PGP Message Exchange Formats'' , 695 RFC 1991, August 1996. 697 [3] PKCS#7, Cryptographic Message Syntax Standard, RSA Laboratories, 698 Version 1.5, November 1993 700 [4] M.Handley, V. Jacobson, ``SDP: Session Description Protocol'', 701 INTERNET-DRAFT, draft-ietf-mmusic-sdp-02.txt, 11/27/1996. 703 [5] R. Housley , W. Ford , T. Polk Internet Public Key Infrastructure 704 INTERNET- DRAFT, draft-ietf-pkix-ipki-part1-03.txt December 1996. 706 [6] National Bureau of Standards, Data Encryption Standard, Federal 707 Information Processing Standards Publication 46, January 1977 709 [7] P. Deutsch, ``GZIP file format specification version 4.3'', 710 RFC 1952, May 1996. 712 [8] D. Mills, ``Network Time Protocol version 2 specification and 713 implementation", RFC1119, 1st Sept 1989. 715 [9] X.208 Specification of Abstract Syntax Notation One (ASN.1) 716 ITU-T Recommendations 1988 718 [10] PKCS #1 RSA Encryption Standard RSA Laboratories, Version 1.5, 719 November 1993 721 [11] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with 722 Minimal Control'', RFC 1890, January 1996 724 [12] P. Metzger, P. Karn, W. Simpson, The ESP Information Triple 725 DES-CBC Transformation, 10/02/1995 RFC850 727 [13] ANSI X3.92-1981. American National Standards Data Encryption 728 Algorithm. American National Standards Institute, 729 Approved 30 December 1990 731 [14] For details of ENTRUST see http://www.entrust.com/ 733 [15] For details of SECUDE see http://www.darmstadt.gmd.de/secude/ 735 [16] PKCS#9 Selected Attribute Types, 736 RSA Laboratories, Version 1.1, November 1993 738 Kirstein et al. [PAGE 16]