idnits 2.17.1 draft-ietf-mmusic-sap-sec-03.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-20) 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 16 longer pages, the longest (page 1) being 60 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 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 8 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 685: '...(DES EDE3 CBC) [17] MUST be supported....' RFC 2119 keyword, line 692: '... length of 128 bits MUST be supported....' RFC 2119 keyword, line 694: '... - Digest Algorithm - the MD5 [18] Message Digest Algorithm MUST be...' RFC 2119 keyword, line 698: '... [10] MUST be supported with key sizes from 512 bits to 1024 bits....' RFC 2119 keyword, line 701: '... [10] MUST be supported with key sizes from 512 bits to 1024 bits....' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 23 has weird spacing: '...ctories on f...' == Line 574 has weird spacing: '... is set and t...' == Line 610 has weird spacing: '...padding bytes...' == Line 792 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 750 looks like a reference -- Missing reference section? '2' on line 753 looks like a reference -- Missing reference section? '3' on line 756 looks like a reference -- Missing reference section? '4' on line 759 looks like a reference -- Missing reference section? '5' on line 762 looks like a reference -- Missing reference section? '6' on line 765 looks like a reference -- Missing reference section? '10' on line 777 looks like a reference -- Missing reference section? '14' on line 790 looks like a reference -- Missing reference section? '15' on line 792 looks like a reference -- Missing reference section? '7' on line 768 looks like a reference -- Missing reference section? '8' on line 771 looks like a reference -- Missing reference section? 'PAGE 10' on line 516 looks like a reference -- Missing reference section? '16' on line 794 looks like a reference -- Missing reference section? 'PAGE 11' on line 572 looks like a reference -- Missing reference section? '12' on line 783 looks like a reference -- Missing reference section? '13' on line 786 looks like a reference -- Missing reference section? 'PAGE 12' on line 626 looks like a reference -- Missing reference section? 'PAGE 13' on line 681 looks like a reference -- Missing reference section? '17' on line 797 looks like a reference -- Missing reference section? '18' on line 801 looks like a reference -- Missing reference section? '20' on line 807 looks like a reference -- Missing reference section? '19' on line 803 looks like a reference -- Missing reference section? 'PAGE 14' on line 724 looks like a reference -- Missing reference section? 'PAGE 15' on line 747 looks like a reference -- Missing reference section? '9' on line 774 looks like a reference -- Missing reference section? '11' on line 780 looks like a reference -- Missing reference section? 'PAGE 16' on line 800 looks like a reference -- Missing reference section? 'PAGE 17' on line 810 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 30 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-03.txt G. Montasser-Kohsari 4 November 1st 1997 E. Whelan 5 Expires: May 1st 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 PGP and PKCS#7 standards. It is a companion document to 37 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. This 94 document is currently in the process of peer review and, until the 95 process has been completed, should not be considered authoritative in 96 this area. 98 2. Authentication and Encryption of Announcements 100 2.1 Introduction 102 It is necessary to provide authentication and integrity of the Session 103 Announcement to ensure that only authorised persons modify Session 104 Announcements and to provide facilities for announcing securely 105 encrypted sessions - providing the relevant proposed conferees with the 106 means to decrypt the data streams. The Session Announcements are made to 107 announce to all potential conferees the existence of a conference. It 108 has, however, another function - to try to minimise conflicts for Mbone 109 resources by spreading out the number of simultaneous conferences. Thus 110 there are a number of threats which we must try to address in the 111 securing of the Session Announcement, and some constraints. These 112 include the following: 114 - Authentication and Integrity of Session Announcement 116 Here it is necessary to ensure that the Session Announcement comes from 117 the person claimed, and is indeed an authorised announcement. Since 118 subsequent announcements will modify caches of future conferences, it is 119 possible otherwise to spoof an original announcement, and thereby at 120 least cause a Denial of Service attack 122 - Confidentiality of Conference Details for Session Announcement 124 Here it is at least necessary to hide the details of the addresses and 125 media formats used. In order to minimise schedule conflicts; it is 126 desirable to keep at least the time of a conference known, even if all 128 Kirstein et al. [PAGE 3] 129 other details are concealed. 131 Three types of announcement are supported: 'unsecured', 'authenticated' 132 and 'authenticated and encrypted'. The 'unsecured' type is described in 133 the SAP specification [1] and so only the latter two types are described 134 below. 136 2.2 Symmetric and Asymmetric Encryption 138 The simplest versions of encryption used are symmetric ones; here the 139 same encryption key 'a' is used to encrypt and decrypt a message. This 140 means that, if E{a,M) is the operation of encrypting the message M with 141 the key a and algorithm E, then the operation E{a, E{a, M}} reproduces 142 the original message M. Because this form of encryption relies on the 143 sender and receiver having the same key, it cannot be used for 144 authentication. An alternative form of encryption is asymmetric 145 encryption. Here two keys, a and b, are used. When these are used one 146 after the other to encrypt a message the original message is obtained. 147 Mathematically, these keys and the encryption algorithm E have the 148 property that E{a, E{b, M}} and E{b, E{a, M}} both produce the original 149 message M - but given a, it should be impractical to deduce b and 150 vice versa. 152 With an asymmetric encryption algorithm, a Public Key Cryptographic 153 System (PKCS) can be derived in which one of the keys, say the Public 154 Key (PK), is published in some way while the other, the Secret Key (SK), 155 is kept secret. Using such a PKCS, it is possible to achieve both 156 confidentiality and authentication. Encrypting a message with the 157 recipient's Public Key ensures confidentiality as only the recipient 158 with the corresponding SK can decrypt the message. Encrypting a message 159 with the SK of the sender ensures authentication as only the sender 160 could have sent the message initially whereas anybody having access to 161 the Public Key can verify that it was indeed sent by the person holding 162 the corresponding Secret Key. 164 Two complete systems, which can achieve both authentication and 165 confidentiality using particular PKCS systems, are PGP [2] and PKCS#7 166 [3]; similar mechanisms are used, but different encryption algorithms 167 and formats are used. The differences between the algorithm and format 168 details for these two systems are elaborated in Sections 3.2 and 3.3. 170 2.3 Authenticated Announcements 172 In order to send authenticated announcements it is possible to use the 173 algorithms of either PGP [2] or the PKCS#7 [3] systems. The resulting 174 format will be substantially different; the exact details are given in 175 Sections 3.2 and 3.3. For each format, the announcement originator 176 calculates a message digest of the announcement. The originator's 177 secret key is used to encrypt the message digest, together with an 178 electronic timestamp, thus forming a digital signature. The originator 179 sends the digital signature along with the message; the receiver 180 receives the message and the digital signature, and recovers the 181 original message digest from the digital signature by decrypting it 182 with the sender's public key. The receiver computes a new message 184 Kirstein et al. [PAGE 4] 185 digest from the message, and checks to see if it matches the one 186 recovered from the digital signature. If it matches, then this is 187 considered adequate proof that the message was not altered, and that it 188 came from the originator who owns the public key used to check the 189 signature. 191 Each Session announcement contains a message ID hash [4]. The 192 specifications for SAP announcements [1] states that such announcements 193 may be repeated frequently, but that if any change is made in the 194 announcement, a different message ID must be used; as a result, a 195 different message ID hash will be appended to the message. As a result, 196 it is only necessary to authenticate an announcement the first time it 197 is received. 199 To save space in the announcement message, only a public key identifier 200 is generally included. It is then assumed that the public key itself 201 has either been distributed previously or can be retrieved from a cache 202 or directory. Optionally the Public Key itself can be included in the 203 announcement removing the need for prior distribution. Consequently, 204 providing that the Public Key is already available in a local cache or 205 Directory, or is distributed with the announcement, one can be sure that 206 the same originator sent the announcement. Only if the full public key 207 information, and a Certificate Authority infrastructure, are accessible 208 [5], can the originator be identified. 210 2.4 Authenticated and Encrypted Announcements 212 2.4.1 Introduction 214 When it is desired to make private announcements, it is necessary to 215 encrypt the set-up details of the conference. The normal way of 216 providing such encryption is to use only a symmetric encryption 217 algorithm such as the Data Encryption Standard (DES [6]) to encrypt 218 such a session using a Session Encryption Key (SEK); this algorithm is 219 used because other systems, such as the asymmetric RSA system [10], are 220 too computation-intensive for large amounts of data - though they are 221 economic for smaller amounts. For symmetric encryption systems, the SEK 222 must be securely distributed to all authorised recipients. 224 2.4.2 Distribution of Session Encryption Keys 226 There are various ways that the SEK could be distributed; all rely on 227 distributing some shared secret in advance to the intended participants 228 in the conference group. When this process takes place out of band, it 229 is not described further in this document. 231 Many symmetric encryption algorithms, e.g. DES [6] are known to be easy 232 to break; with such algorithms, it is undesirable to re-use the SEK many 233 times. For this reason, and to improve security, a set of SEKs may be 234 distributed out-of-band; the recipients may then try to decrypt the 235 announcement by trying each of these SEKs in turn. 237 As in Section 2.3, one may use the fact that if any change is made in 238 the announcement, a different message ID, and hence message ID hash is 240 Kirstein et al. [PAGE 5] 241 used; it is only necessary to attempt to decrypt an announcement message 242 the first time it is received. The basic symmetric system is contained 243 in SAP [1]. To improve efficiency, it would be possible to use 244 symmetric encryption with a pre-distributed Key Identifier (KeyID). 245 However, because of the potential weakening of the security by the use 246 of KeyIDs, and the consequent need to use more secure symmetric 247 algorithms, we do not recommend this technique. Moreover, by adopting 248 the use of asymmetric Public Key technology for such SEK distribution as 249 discussed below, we gain both efficiency and have a better integrated 250 approach to authentication. 252 2.4.3 Use of Public Key Algorithms 254 Public Key Cryptography is one mechanism for minimising the need for 255 secure transmission of shared secrets; this was already used in the 256 Authenticated Announcements of Section 2.2. It would be possible to use 257 these encryption algorithms on the whole announcement message but this 258 would be inefficient because the asymmetric encryption algorithms 259 normally use much longer encryption keys, and are much more resource 260 intensive, than the symmetric ones. For this reason it is more efficient 261 to use a combination of symmetric and Public Key algorithms. Now a 262 random Session Encryption Key (SEK) is generated as in Section 2.4.1. A 263 Privacy Header (PH) is constructed containing the SEK, which is 264 encrypted with the asymmetric encryption algorithm. It is now only 265 necessary to distribute a Secret Group Key (SGK) and Public Group Key 266 (PGK) i.e. {SGK, PGK} to decrypt the SEK. However, this pair needs to be 267 distributed only once as long as the group membership does not change; 268 it is possible to re-use the same group keys for many sessions, with 269 different SEKs. This minimises the number of times the prior key 270 distribution sequence must be followed. 272 It should be noted that because a Group Key is used in the above, it is 273 not possible to use the same Header to authenticate the sender uniquely, 274 though it is authenticated automatically that the sender is one of the 275 group which has reserved the asymmetric encryption key pair. It is 276 still possible to authenticate the identity of the sender by using a 277 different Authentication Key for the Authentication Header as described 278 in Section 2.3. 280 It would be possible to use a similar technique using symmetric 281 encryption with a strong encryption algorithm and an encryption key 282 Identifier instead of the Public Key Group Key, However, we believe the 283 Public Key method to be superior so this variant is not pursued. 285 2.4.4 Encrypting Announcements 287 We will now provide some more detail. If the payload is to be 288 compressed, this is performed prior to encryption. 290 When an announcement is to be encrypted, the payload is encrypted using 291 symmetric encryption. In this case each such encryption key is used only 292 once; a new Session Encryption Key (SEK) is generated as a random number 293 for each announcement. Since it is to be used only once, the SEK is 294 bound to the message and transmitted with it in a Privacy Header. The 296 Kirstein et al. [PAGE 6] 297 sequence is as follows: The Privacy Header contains the SEK, encrypted 298 with the group's Public Group Key, together with information identifying 299 the Group Key which has been used. The encrypted Payload is appended to 300 the Privacy Header. 302 2.4.5 Decrypting Announcements 304 Upon receiving a new announcement with the encryption bit set, a 305 receiver should attempt to decrypt the announcement with the relevant 306 group private key or their own private key as indicated in the Privacy 307 Header. The sequence is as follows: 309 1. Prior to the announcement, the group's Public/Secret Group Key 310 pair is distributed securely. 312 2. From the announcement, the receiving participants determine 313 which Public Group Key has been used by looking at the 314 information contained in the Privacy Header. 316 3. They then decrypt the Session Encryption Key (SEK) with the SGK 317 corresponding to the PGK identified in Step 2 and obtain other 318 necessary information such as the content encryption algorithm 319 from the Privacy Header. 321 4. The authorised receivers decrypt the encrypted text payload using 322 the SEK and the relevant symmetric content encryption algorithm, 323 which was used to encrypt the payload. 325 Note that if an encrypted announcement is being announced via a proxy, 326 then there may be no way for the proxy to discover that the announcement 327 has been superseded, and so it may continue to relay the old 328 announcement in addition to the new announcement. SAP provides no 329 mechanism to chain modified encrypted announcements, so it is advisable 330 to announce the unmodified session as deleted for a short time after 331 the modification has occurred. This does not guarantee that all proxies 332 have deleted the session, and so receivers of encrypted sessions should 333 be prepared to discard old versions of session announcements that they 334 may receive (as identified by the SDP version field). In most cases 335 however, the only stateful proxy will be local to (and known to) the 336 sender, and an additional (local-area) protocol involving a handshake 337 for such session modifications can be used to avoid this problem. 339 3. Secured SAP Packet Formats 341 Both Authentication and Privacy can be achieved using PGP [2] or PKCS#7 342 [3] format packets. In Section 3.1 we discuss the generic packet format 343 defined in SAP [1]. In Section 3.2 we consider the formats of the 344 Authentication Header, and in Section 3.3 that of the encrypted payload. 346 It would be possible to define our own versions of the packets for this 347 application. In that case the formats would be simpler, but all the 348 implementations would have to be coded using the basic encryption 349 libraries, and a new infrastructure would have to be defined. Both PGP 350 and PKCS#7 already have complete implementations and, by using their 352 Kirstein et al. [PAGE 7] 353 formats, several application tool kits are already available (e.g. 354 Entrust [14], Secude [15]). In addition, these formats also have 355 complete infrastructures defined around them. For these reasons, we have 356 chosen to retain enough compatibility to ease the eventual 357 implementation, while simplifying the formats as far as possible within 358 such a constraint. There is an additional advantage in this approach; it 359 will be possible to send session announcements by the encrypted Session 360 Invitation Protocol or by electronic mail using PGP or S-MIME, and 361 re-use much of the same code as with SAP. 363 3.1 Secured SAP Packet Format 365 The SAP data packets as defined in [1] has the following format: 367 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | V=2 | MT |E|C| Header Length | 16 bit Message ID Hash | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Originating Source | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 374 | Authentication Header (Optional) | 375 | .................. | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | 32 bit Time-Out Field (Optional) | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Privacy Header (Optional) | 380 | .................. | 381 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Text Payload (Possibly Encrypted) | 383 | .................. | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Notes: 388 Version Number, V: This is a 3-bit field and has the value 2 for this 389 version of SAP [1] 391 Message Type, MT: This defines the contents of the payload and can be 393 0. Session Descriptor Announcement Packet in which case the 394 payload is an SDP session description as described in [4] 396 1. Session Description Deletion Packet in which case the payload 397 is a singleSDP line containing the origin field of the 398 announcement to be deleted 400 Encryption Bit, E: -. If this is set, the text payload has been 401 encrypted 403 Compression Bit, C: If this is set the payload has been compressed using 404 the gzip compression utility [7] 406 Kirstein et al. [PAGE 8] 407 Header length: This is an 8 bit unsigned quantity giving the number of 408 32 bit words following the main SAP header that contains the 409 authentication data. If this is non-zero, the payload is 410 authenticated, and an Authentication Header is present 412 Message Identifier Hash: This is a 16 bit quantity that, when used in 413 combination with the originating source, provides a globally unique 414 id identifying the precise version of this announcement. The message 415 id hash should be changed if any field of the session description is 416 changed. A value of zero means that the hash should be ignored and 417 the message should always be parsed. 419 Originating Source: This 32-bit field gives the IP address of the 420 original source of the message. It is permissible for this to be zero 421 if the message has not passed through a proxy relay and if the message 422 id hash is also zero. This is intended for backward compatibility with 423 SAPv0 clients only. 425 Authentication Header: This can be used for two purposes: 427 1. Verification that changes to a session description or deletion 428 of a session are permitted 430 2. Authentication of the identity of the session creator. 432 In some circumstances only verification is possible because a 433 certificate signed by a mutually trusted person or authority is not 434 available. However, under such circumstances, the session originator 435 can still be authenticated to be the same as the session originator of 436 previous sessions claiming to be from the same person. This may or may 437 not be sufficient, depending on the purpose of the session and the 438 people involved. The precise format of the Authentication Header is 439 discussed in Section 3.2. 441 Timeout: When the session payload is encrypted, and the session 442 description is being relayed or announced via a proxy, the detailed 443 timing fields in the SDP description are not available to the proxy. 444 This is because these fields are encrypted and the proxy is not 445 trusted with the decryption key. Under such circumstances, SAP 446 includes an additional 32-bit timestamp field stating when the session 447 should be timed out. The digital signature in the authentication 448 header encompasses the time-out so that a session cannot be 449 maliciously deleted by modifying its time-out in an announcing proxy. 450 The value is an unsigned quantity giving the NTP time [8] in seconds 451 at which time the session is timed out. It is in network byte order 453 Privacy Header: This is present when the text payload has been encrypted 454 using hybrid encryption. 456 Text Payload: When there is no encryption, the encryption bit is not set 457 and this format is as defined in the SDP [4] draft. However, when 458 encryption has been used the payload is encrypted and the format is 459 discussed in Section 3.3. 461 Kirstein et al. [PAGE 9] 462 3.2 Authentication Header 464 3.2.1 Generic Format 466 The generic format of the Authentication Header is given below. The 467 structure of the Format Specific Authentication Subheader, using both 468 the PGP and the PKCS#7 formats, is discussed in Sections 3.2.2 and 3.2.3 469 respectively. 471 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | V=1 |P| Auth | Header Length | | 475 |+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+ | 476 | Format Specific Authentication Subheader | 477 | .................. | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 Notes: 482 Version Number, V: For this release the version number is 1 (3 bits) 484 Padding Bit, P: If necessary the data in the Authentication Header is 485 padded to be a multiple of 32 bits and the Padding bit is set. In this 486 case the last byte of the Authentication Header contains the number of 487 padding bytes (including the last byte) that must be discarded. 489 Authentication Type, Auth: The Authentication Type is a 4 bit encoded 490 field that denotes the authentication infrastructure the sender 491 expects the recipients to use to check the authenticity and integrity 492 of the information. This defines the format of the Authentication 493 Subheader and can take the values: 495 1. PGP Format 496 2. PKCS#7 Format 497 3. PGP Format with the 'Certificate' included 498 4. PKCS#7 with the Certificate included 500 Header Length: This gives the length of the Authentication Header. 502 3.2.2 PGP Format 504 The generic description of the PGP packets is presented in [2]. For PGP 505 the basic Format Specific Authentication Subheader comprises a digital 506 signature packet as described in [2]. This involves the use of a hash 507 code, or message digest algorithm, and a public key encryption algorithm. 508 The hash is taken of the text payload together with the signature 509 classification (1 byte) and signature time stamp (4 bytes) fields as 510 described in [2]. For the case when the Authentication type is 1 the 511 Subheader contains a Digital Signature Packet only with the hexadecimal 512 signature classification being <00> or <01>. The only Message Digest 513 Algorithm is 1 (MD5) and the Public Key Cryptosystem (PKC) is 1, this 514 being the RSA system. If the type is 3 then a Certificate Packet is also 516 Kirstein et al. [PAGE 10] 517 appended to the previous Signature Packet. A certificate packet is 518 composed of the following individual packets: 520 (a) A Public Key Packet which defines the RSA public key 521 (b) A UserID packet 522 (c) A Signature Packet 524 The Public Key packet again has the Public Key Cryptosystem 1. In the 525 case of Signature Packet (c) the signature classification now takes the 526 hexadecimal values <10> to <13>. These packets are all detailed in [2]. 528 3.2.3 PKCS#7 Format 530 The Format Specific Authentication Subheader will, in the PKCS#7 case, 531 have an ASN.1 ContentInfo type with the ContentType being signedData. 532 Use is made of the option available in PKCS#7 to leave the content 533 itself blank as the content which is signed is, in this application, 534 already present as the text payload, whether this is encrypted or not. 535 Thus inclusion of it within the SignedData type would be duplication and 536 increase the packet length unnecessarily. The full specification for 537 this ASN.1 type is available in [3]. 539 There will only be one signerInfo and related fields corresponding to 540 the originator of the SAP announcement. Although it would be possible 541 to transfer the relevant information is a single signerInfo type rather 542 than the complete ContentInfo it is considered preferable to use the 543 latter for two reasons. Firstly, this is compatible with a wider range 544 of applications and security toolkits and secondly, that the certificate 545 can be included in a standard way. If the Authentication Type is 2 there 546 are no certificates or certificate revocation lists whereas if the 547 authentication type is 4 the originator's X.509 certificate is added in 548 the certificate field of this type. 550 In addition, for both type 2 and 4, use is made of the ability in PKCS#7 551 to authenticate various attributes as specified in PKCS#9 [16]. The 552 authenticatedAttributes field of the SignerInfo type is used and the 553 attribute which is authenticated is the SigningTime. This is a 554 mandatory field in this specification. Consequently, the initial input to 555 the message digesting process is the contents octets of the DER encoding 556 of the content field of the ContentInfo value (not including the 557 identifier octets or the length octets). Moreover, the signing time is an 558 authenticated attribute. Thus, the result of the message digest is the 559 complete DER encoding of the Attributes value contained in the 560 AuthenticatedAttributes field. This contains the SigningTime in addition 561 to the content type and message digest of the payload, which are included 562 automatically. 564 3.3 Encrypted Payload Format 566 3.3.1 Generic Format 568 The format of the Encrypted Payload depends on the type of encryption 569 used to encrypt the SDP text payload [4]. If no encryption has been used 570 only the Text payload is present. 572 Kirstein et al. [PAGE 11] 573 If encryption has been used then the encryption bit in the main SAP 574 header is set and the payload is encrypted either symmetrically or 575 using hybrid encryption. For symmetric encryption the format is detailed 576 in Section 3.3.2 whereas hybrid encryption is detailed in Section 3.3.3. 577 For hybrid encryption there are two possibilities - PGP and PKCS#7 578 Formats. The application is expected to test whether the fields 579 immediately following the timeout field in the main SAP header is 580 compatible with the use of symmetric encryption; in that case it will be 581 a padding bit followed by a 31-bit random field, or whether it is 582 compatible with the use of hybrid encryption. In this case there is a 583 very specific format to the first byte of the Privacy header, which 584 follows other time-out field in this case. 586 3.3.2 Symmetric Encryption 588 If symmetric encryption alone has been used then the encrypted payload 589 has a random field added prior to encryption as below. 591 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 |P| 31 bit random field | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Text Payload | 597 | . . . | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Notes 602 Random Field: This field is only present when payload is encrypted 603 using symmetric encryption and is used to perform the randomisation 604 tasks normally performed by an initialisation vector in algorithms 605 such as DES. This 31-bit field should contain a genuinely random 606 number. 608 Padding Bit, P: This bit indicates that the payload was padded prior to 609 encryption. The last byte of the encrypted payload indicates how many 610 padding bytes were added. 612 The data following the Time-out field is decrypted using the algorithm 613 specified above. Further details on the encryption algorithms are given 614 in [6, 12, 13]. 616 3.3.3 Hybrid Encryption 618 If a combination of asymmetric and symmetric encryption has been used 619 then the part of the SAP packet following the time-out field has the 620 following structure. This effectively takes the form of a Privacy header 621 followed by the encrypted SDP payload, the precise format depending on 622 whether PGP or PKCS#7 formats have been used. The specific details for 623 each of these formats are described in Sections 3.3.3.1 and 3.3.3.2 624 respectively. 626 Kirstein et al. [PAGE 12] 627 Privacy Header: 629 1 2 3 630 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 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | V=1 |P| Type | Header Length | | 633 |+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+ | 634 | Format Specific Privacy Subheader | 635 | .................. | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Notes 640 Version, V: In this version the Version of the privacy Header is 1 642 Padding Bit, P: If necessary the data in the Privacy Header is padded to 643 be a multiple of 32 bits and the Padding bit is set. In this case the 644 last byte of the Privacy Header contains the number of padding bytes 645 (including the last byte) that must be discarded. 647 Format Type, Type: This can be either 1 for PGP or 2 for PKCS#7 format. 649 Header Length: This gives the length of the Privacy Header. 651 3.3.3.1 PGP Format Privacy Header 653 For the case when the Format Type is 1 the Format Specific Privacy 654 Subheader is composed of a PGP Public Key encrypted packet and the text 655 payload is a PGP Conventional Key Encrypted Packet. These are detailed 656 in [2]. The Public Key Cryptosystem is 1, this being defined as the RSA 657 system, and the only supported symmetric encryption algorithm is the 658 IDEA algorithm, corresponding to the Conventional encryption type byte 659 value of 1. 661 3.3.3.2 PKCS#7 Format Privacy Header 663 If the Type is 2 then the Format Specific Privacy Header is composed of 664 a PKCS#7 ContentInfo type with the ContentType being envelopedData. 665 These are detailed in [2]. In this case the Text Payload, which has been 666 symmetrically encrypted with the algorithm specified in the 667 contentEncryptionAlgorithm field, is effectively the encryptedContent 668 part of the structure. There will be only one recipientInfo structure 669 corresponding to the group certificate, which has been previously 670 distributed. The contentType in the EncryptedContentInfo structure is 671 "Data". 673 3.3.4 Supported Algorithms 675 It is the policy of the IESG that unencumbered algorithms should be used 676 wherever possible. The only encumbered algorithm mandatory in the section 677 below is RSA; we understand that arrangements are being made to avoid 678 licence fees on this algorithm. At present implementations of suitable 679 unencumbered algorithms are not readily available. 681 Kirstein et al. [PAGE 13] 682 3.3.4.1 Symmetric Encryption 684 If symmetric encryption alone is used then DES [6] and Triple-DES 685 (DES EDE3 CBC) [17] MUST be supported. 687 3.3.4.2 Hybrid Encryption 689 3.3.4.2.1 PGP Format 691 - Content Encryption - the IDEA symmetric encryption algorithm with 692 a key length of 128 bits MUST be supported. 694 - Digest Algorithm - the MD5 [18] Message Digest Algorithm MUST be 695 supported. 697 - Digest Encryption Algorithm - the asymmetric rsaEncryption algorithm 698 [10] MUST be supported with key sizes from 512 bits to 1024 bits. 700 - Key encryption Algorithm - the asymmetric rsaEncryption algorithm 701 [10] MUST be supported with key sizes from 512 bits to 1024 bits. 703 3.3.4.2.2 PKCS#7 Format 705 - Content Encryption - Receiving agents SHOULD support decryption using 706 the RC2 algorithm [20] at a key size of 40 bits (RC2/40). 707 Receiving agents MUST support decryption using Triple-DES [17]. 708 Sending agents SHOULD support encryption with RC2/40 and 709 Triple-DES. 711 - Digest Algorithm - Receiving agents MUST support SHA-1 [19] and MD5 712 [18]. Sending agents should use SHA-1. 714 - Digest Encryption Algorithm - Receiving agents and sending agents 715 MUST support rsaEncryption [10]. Receiving agents MUST support 716 verification of signatures using RSA public key sizes from 512 717 bits to 1024 bits. 719 - Key encryption Algorithm - Receiving agents MUST support 720 rsaEncryption [10]. Sending agents MUST support rsaEncryption and 721 encryption of symmetric keys with RSA public keys at key sizes 722 from 512 bits to 1024 bits. 724 Kirstein et al. [PAGE 14] 725 Appendix A: Authors' Addresses 727 Peter Kirstein, Goli Montasser Kohsari and Edmund Whelan are at 728 University College London and their contact details are: 730 P.Kirstein@cs.ucl.ac.uk Tel: +44 171 380 7286 731 G.Montasser-Kohsari@cs.ucl.ac.uk Tel: +44 171 380 7215 732 E.Whelan@cs.ucl.ac.uk Tel: +44 171 419 3688 734 Dept of Computer Science Fax: +44 171 387 1397 735 University College London 736 Gower Street 737 London WC1E 6BT England 739 Acknowledgements 741 SAP and SDP were originally based on the protocol used by the sd session 742 directory from Van Jacobson at LBNL. The European Commission under the 743 Esprit 7602 "MICE" project, the Telematics 1007 "MERCI" project and the 744 Telematics 1005 "ICE-TEL" project funded the design of SAP and SAP 745 Security. 747 Kirstein et al. [PAGE 15] 748 References 750 [1] M.Handley `SAP: Session Announcement Protocol'' INTERNET-DRAFT, 751 draft-ietf-mmusic-sap-00.txt, 11/27/1996. 753 [2] D.Atkins, '' PGP Message Exchange Formats'' , 754 RFC 1991, August 1996. 756 [3] PKCS#7, Cryptographic Message Syntax Standard, RSA Laboratories, 757 Version 1.5, November 1993 759 [4] M.Handley, V. Jacobson, ``SDP: Session Description Protocol'', 760 INTERNET-DRAFT, draft-ietf-mmusic-sdp-02.txt, 11/27/1996. 762 [5] R. Housley , W. Ford , T. Polk Internet Public Key Infrastructure 763 INTERNET- DRAFT, draft-ietf-pkix-ipki-part1-03.txt December 1996. 765 [6] National Bureau of Standards, Data Encryption Standard, Federal 766 Information Processing Standards Publication 46, January 1977 768 [7] P. Deutsch, ``GZIP file format specification version 4.3'', 769 RFC 1952, May 1996. 771 [8] D. Mills, ``Network Time Protocol version 2 specification and 772 implementation", RFC1119, 1st Sept 1989. 774 [9] X.208 Specification of Abstract Syntax Notation One (ASN.1) 775 ITU-T Recommendations 1988 777 [10] PKCS #1 RSA Encryption Standard RSA Laboratories, Version 1.5, 778 November 1993 780 [11] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with 781 Minimal Control'', RFC 1890, January 1996 783 [12] P. Metzger, P. Karn, W. Simpson, The ESP Information Triple 784 DES-CBC Transformation, 10/02/1995 RFC850 786 [13] ANSI X3.92-1981. American National Standards Data Encryption 787 Algorithm. American National Standards Institute, 788 Approved 30 December 1990 790 [14] For details of ENTRUST see http://www.entrust.com/ 792 [15] For details of SECUDE see http://www.darmstadt.gmd.de/secude/ 794 [16] PKCS#9 Selected Attribute Types, 795 RSA Laboratories, Version 1.1, November 1993 797 [17] W. Tuchman, "Hellman Presents No Shortcut Solutions to DES" 798 IEEE Spectrum, v. 16, n. 7, July 1979, pp 40-41 800 Kirstein et al. [PAGE 16] 801 [18] "The MD5 Message Digest Algorithm" RFC 1321 803 [19] NIST FIPS PUB 180-1 "Secure Hash Standard" 804 National Institute of Standards and Technology, 805 U.S. Department of Commerce, DRAFT, 31 807 [20] "Description of the RC2 Encryption Algorithm", 808 Internet Draft draft-rivest-rc2desc. 810 Kirstein et al. [PAGE 17]