idnits 2.17.1 draft-ietf-mmusic-sip-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-26) 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 22 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 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.) ** There are 40 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** 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 176: '..., REGISTER and UNREGISTER is OPTIONAL....' RFC 2119 keyword, line 202: '...hancements detailed in this paper MUST...' RFC 2119 keyword, line 287: '... SIP request, it MUST add itself to th...' RFC 2119 keyword, line 295: '... server MUST check that it does not g...' RFC 2119 keyword, line 409: '...n. As detailed later implementers MUST...' (60 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 23 has weird spacing: '...ctories on f...' == Line 798 has weird spacing: '...type of prote...' -- 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 1049 looks like a reference -- Missing reference section? '2' on line 1052 looks like a reference -- Missing reference section? '28' on line 1159 looks like a reference -- Missing reference section? '16' on line 1099 looks like a reference -- Missing reference section? '17' on line 1102 looks like a reference -- Missing reference section? '18' on line 1105 looks like a reference -- Missing reference section? '19' on line 1108 looks like a reference -- Missing reference section? '3' on line 1056 looks like a reference -- Missing reference section? '4' on line 1059 looks like a reference -- Missing reference section? '5' on line 1062 looks like a reference -- Missing reference section? '6' on line 1066 looks like a reference -- Missing reference section? '7' on line 1069 looks like a reference -- Missing reference section? '8' on line 1077 looks like a reference -- Missing reference section? '9' on line 1079 looks like a reference -- Missing reference section? '10' on line 1080 looks like a reference -- Missing reference section? '11' on line 1085 looks like a reference -- Missing reference section? '20' on line 1111 looks like a reference -- Missing reference section? '21' on line 1131 looks like a reference -- Missing reference section? 'PAGE 11' on line 576 looks like a reference -- Missing reference section? 'PAGE 12' on line 632 looks like a reference -- Missing reference section? 'PAGE 13' on line 685 looks like a reference -- Missing reference section? 'PAGE 14' on line 741 looks like a reference -- Missing reference section? '23' on line 1136 looks like a reference -- Missing reference section? '24' on line 1140 looks like a reference -- Missing reference section? '26' on line 1152 looks like a reference -- Missing reference section? '14' on line 1094 looks like a reference -- Missing reference section? '15' on line 1098 looks like a reference -- Missing reference section? '12' on line 1088 looks like a reference -- Missing reference section? '13' on line 1091 looks like a reference -- Missing reference section? '0' on line 793 looks like a reference -- Missing reference section? 'PAGE 15' on line 797 looks like a reference -- Missing reference section? 'PAGE 16' on line 853 looks like a reference -- Missing reference section? 'PAGE 17' on line 909 looks like a reference -- Missing reference section? 'PAGE 18' on line 965 looks like a reference -- Missing reference section? '22' on line 1134 looks like a reference -- Missing reference section? 'PAGE 19' on line 1018 looks like a reference -- Missing reference section? '25' on line 1148 looks like a reference -- Missing reference section? '27' on line 1156 looks like a reference -- Missing reference section? 'PAGE 20' on line 1046 looks like a reference -- Missing reference section? 'PAGE 21' on line 1097 looks like a reference -- Missing reference section? 'PAGE 23' on line 1151 looks like a reference -- Missing reference section? 'PAGE 24' on line 1183 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 44 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-sip-sec-00.txt G. Montasser-Kohsari 4 March 12th 1998 E. Whelan 5 Expires: September 12th 1998 University College London 7 SIP Security 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, 13 and its working groups. Note that other groups may also distribute 14 working 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 Initiation Protocol (SIP) is a simple protocol designed 32 to enable the invitation of users to multimedia sessions. This 33 document is a companion draft to draft-ietf-mmusic-sip-04.txt, which 34 defines SIP but doesn't specify any security mechanisms other than 35 possible protection by lower-level security mechanisms such as SSL. 36 This leaves SIP transactions vulnerable to attack and this document 37 aims to extend the SIP protocol to address such security 38 considerations. This document is a product of the Multiparty 39 Multimedia Session Control (MMUSIC) working group of the Internet 40 Engineering Task Force Comments are solicited and should be addressed 41 to the working group's mailing list at confctrl@isi.edu and/or the 42 authors. 44 Kirstein et al. [PAGE 1] 45 TABLE OF CONTENTS 47 1. Introduction .................................................. 3 48 1.1 Overview of SIP Functionality .............................. 3 49 1.2 Terminology ................................................ 3 50 1.3 SIP Message Overview ....................................... 3 51 1.3.1 Request ................................................ 4 52 1.3.2 Response ............................................... 4 53 1.3.3 SIP Version ............................................ 5 54 1.4 SIP Transaction ............................................ 5 55 1.4.1 Example of a SIP Invitation ............................ 5 56 1.5 Transport-Protocol ......................................... 7 57 2. Security Considerations ....................................... 7 58 2.1 Symmetric and Asymmetric Encryption ........................ 8 59 3. SIP Security With PGP and MIME ................................ 9 60 3.1 PGP Data Formats ........................................... 9 61 3.2 MIME Encapsulation ......................................... 9 62 3.3 PGP Encrypted Data ......................................... 10 63 3.4 PGP Signed Data ............................................ 12 64 3.5 PGP Encrypted and Signed Data .............................. 13 65 3.5.1 RFC 1847 Encapsulation ................................. 13 66 3.5.2 Combined Encryption and Signing ........................ 15 67 3.6 PGP Supported Algorithms ................................... 15 68 4. SIP Security with S/MIME ...................................... 15 69 4.1 The application/pkcs7-mime Type ............................ 16 70 4.2 Encryption Only with S/MIME ................................ 16 71 4.3 Signing Only with S/MIME ................................... 16 72 4.3.1 Signing Using application/pkcs7-mime and SignedData .... 17 73 4.3.2 Signing Using the multipart/signed Format .............. 17 74 4.4 Signing and Encrypting ..................................... 19 75 4.5 S/MIME Supported Algorithms ................................ 19 77 References ....................................................... 21 78 Authors' Addresses ............................................... 24 79 Acknowledgements ................................................. 24 81 Kirstein et al. [PAGE 2] 82 1. Introduction 84 1.1 Overview of SIP Functionality 86 The Session Initiation Protocol (SIP) is an application-layer protocol 87 that can establish and control multimedia sessions or calls. These 88 multimedia sessions include multimedia conferences, distance learning, 89 Internet telephony and similar applications. SIP can invite a person 90 to both unicast and multicast sessions; the initiator does not 91 necessarily have to be a member of the session it is inviting to. 92 Media and participants can be added to an existing session. SIP can be 93 used to "call" both persons and "robots", for example, to invite a 94 media storage device to record an ongoing conference or to invite a 95 video-on-demand server to play a video into a conference. SIP can be 96 used to initiate sessions as well as invite members to sessions that 97 have been advertised and established by other means such as SAP [1], 98 electronic mail, news groups, web pages and directories (LDAP). SIP is 99 fully defined in [2] and, as this is a companion draft aiming to 100 extend the basic functionality of SIP to address security 101 considerations, familiarity with [2] is assumed. Consequently, only a 102 brief introduction to SIP itself is included here. 104 1.2 Terminology 106 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 107 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 108 and "OPTIONAL" are to be interpreted as described in RFC 2119 [28] 109 and indicate requirement levels for compliant SIP implementations. 111 1.3 SIP Message Overview 113 As much of the message syntax is identical to HTTP/1.1 the notation 114 [HX.Y] is used to refer to section X.Y of the current HTTP/1.1 [16] 115 specification. In addition an augmented Backus-Naur form (BNF) [17] 116 [H2.1] is used. All SIP messages are text-based and use HTTP/1.1 117 conventions [H4.1], except for the additional ability of SIP to use 118 UDP. When sent over TCP or UDP, multiple SIP transactions can be 119 carried in a single TCP connection or UDP datagram. UDP datagrams, 120 including all headers, should not normally be larger than the path 121 maximum transmission unit (MTU) if the MTU is known or 1500 bytes if 122 the MTU is unknown. The 1400 bytes accommodates lower-layer packet 123 headers within the "typical" MTU of around 1500 bytes. There are few 124 MTU values around 1 kB; the next value is 1006 bytes for SLIP and 296 125 for low-delay PPP [18]. Recent studies [19] indicate that an MTU of 126 1500 bytes is a reasonable assumption. Thus, another reasonable value 127 would be a message size of 950 bytes, to accommodate packet headers 128 within the SLIP MTU without fragmentation. 130 A SIP message is either a request from a client to a server, or a 131 response from a server to a client. 133 SIP-message = Request | Response ; SIP messages 135 Kirstein et al. [PAGE 3] 136 Both Request and Response messages use the generic RFC822 [3] message 137 format for transferring entities (the payload of the message). Both 138 types of message consist of a start-line, one or more header fields, 139 an empty line indicating the end of the header fields and an optional 140 message body. 142 Generic message = start-line 143 *(general header | request header | entity header) 144 CRLF 145 [message body] 147 start-line = Request Line | Status Line 149 1.3.1 Request 151 The Request message format is shown below: 153 Request = Request Line 154 *(general header | request header | entity header) 155 CRLF 156 [message body] 158 The Request Line begins with a method token, followed by the 159 Request-URI, the protocol version and ending with a CRLF. SP 160 characters separate each element. 162 Request Line = Method SP Request-URI SP SIP-Version CRLF 164 Method = "INVITE" | "ACK" | "OPTIONS" | 165 "BYE" | "REGISTER" | "UNREGISTER" 167 INVITE indicates that the user or service is being invited to 168 participate and the message body contains a description of the 169 relevant session. ACK confirms that the client has received a final 170 response to an INVITE request. OPTIONS is used to query a client 171 about its capabilities. The client uses BYE to indicate to the server 172 that it wishes to abort the call attempt. REGISTER is used by the 173 client to register the address listed in the request line to a SIP 174 server and UNREGISTER is used to cancel an existing registration. 175 Support for INVITE and ACK is mandatory in the SIP specification 176 whereas support for OPTIONS, BYE, REGISTER and UNREGISTER is OPTIONAL. 178 1.3.2 Response 180 Once a recipient has received and interpreted a request message they 181 respond with a SIP response message. The format of the response is 182 shown below: 184 Response = Status Line 185 *(general header | request header | entity header) 186 CRLF 187 [message body] 189 The Status Line is similar to the Request Line. It consists of the SIP 191 Kirstein et al. [PAGE 4] 192 Version, a numeric Status Code and its associated textual phrase. SP 193 characters separate each element and the line ends with a CRLF 194 sequence. 196 Status Line = SIP Version SP Status Code SP Reason Phrase CRLF 198 1.3.3 SIP Version 200 Both request and response messages include the version of SIP in use 201 and this follows [H3.1], with HTTP replaced by SIP. Applications 202 making use of the security enhancements detailed in this paper MUST 203 include a SIP-Version of "SIP/2.1". 205 1.4 SIP Transaction 207 When making a SIP call a caller first locates the appropriate sever 208 and then sends a SIP request. The most common SIP operation is the 209 invitation. Instead of directly reaching the intended callee, a SIP 210 request may be redirected or trigger a new chain of requests by 211 proxies. 213 1.4.1 Example of a SIP Invitation 215 A successful SIP invitation consists of two requests, INVITE followed 216 by ACK. The INVITE request asks the callee to join a particular 217 conference or establish a two-party conversation. After the callee has 218 agreed to participate in the call, the caller confirms that it has 219 received that response by sending an ACK request. If the call is 220 rejected, or otherwise unsuccessful, the caller sends a BYE request 221 instead of an ACK. 223 The INVITE request typically contains a session description, for 224 example written in SDP format [4], that provides the called party with 225 enough in formation to join the session. For multicast sessions, the 226 session description enumerates the media types and formats that may be 227 distributed to that session. For unicast sessions, the session 228 description enumerates the media types and formats that the caller is 229 willing to receive and where it wishes the media data to be sent. In 230 either case, if the callee wishes to accept the call, it responds to 231 the invitation by returning a similar description listing the media it 232 wishes to receive. For a multicast session, the callee should only 233 return a session description if it is unable to receive the media 234 indicated in the caller's description. The caller may ignore the 235 session description returned or use it to change the global session 236 description. 238 The protocol exchanges for the INVITE method are shown in Fig. 1 for a 239 proxy server and in Fig. 2 for a redirect server. The proxy server 240 accepts the INVITE request (1), contacts the location service with all 241 or parts of the address (2) and obtains a more precise location (3). 242 The proxy server then issues a SIP INVITE request to the address(es) 243 returned by the location service (4). The user agent server alerts the 244 user (5) and returns a success indication to the proxy server (6). The 245 proxy server then returns the success result to the original caller 247 Kirstein et al. [PAGE 5] 248 (7). The receipt of this message is confirmed by the caller using an 249 ACK message, which is forwarded to the callee (8,9), with a response 250 returned (10,11). All requests have the same Call-ID. 252 +....... cs.columbia.edu .......+ 253 : : 254 : (~~~~~~~~~~) : 255 : ( location ) : 256 : ( service ) : 257 : (~~~~~~~~~~) : 258 : ^ | : 259 : | hgs@play : 260 : 2| 3| : 261 : | | : 262 : henning | : 263 +.. cs.tu-berlin.de ..+ 1: INVITE : | | : 264 : : henning@cs.col: | | 4: INVITE 5: ring : 265 : cz@cs.tu-berlin.de ========================> tune =========> play : 266 : <........................ <......... : 267 : : 7: 200 OK : 6: 200 OK : 268 +.....................+ +...............................+ 270 ====> SIP request 271 ----> non-SIP protocols 273 Figure 1: Example of SIP proxy server 275 The redirect server accepts the INVITE request (1), contacts the 276 location service as before (2,3) and, instead of contacting the newly 277 found address itself, returns the address to the caller (4). The 278 caller issues a new request, with a new call-ID, to the address 279 returned by the first server (6). In the example, the call succeeds 280 (7). The caller and callee complete the handshake with an ACK (8,9). 282 The action taken on receiving a list of locations varies with the type 283 of SIP server. A SIP redirect server simply returns the list to the 284 client sending the request as Location headers. A SIP proxy server can 285 sequentially or in parallel try the addresses. 287 If a proxy server forwards a SIP request, it MUST add itself to the 288 end of the list of forwarders noted in the Via headers. The Via trace 289 ensures that replies can take the same path back, thus ensuring 290 correct operation through compliant firewalls and loop-free requests. 291 On the reply path, each host most remove its Via, so that routing 292 internal information is hidden from the callee and outside networks. 293 When a multicast request is made, first the host making the request, 294 then the multicast address itself are added to the path. A proxy 295 server MUST check that it does not generate a request to a host listed 296 in the Via list. (Note: If a host has several names or network 297 addresses, this may not always work. Thus, each host also checks if it 298 is part of the Via list.) 300 Kirstein et al. [PAGE 6] 301 +....... cs.columbia.edu .......+ 302 : : 303 : (~~~~~~~~~~) : 304 : ( location ) : 305 : ( service ) : 306 : (~~~~~~~~~~) : 307 : ^ | : 308 : | hgs@play : 309 : 2| 3| : 310 : | | : 311 : henning | : 312 +.. cs.tu-berlin.de ..+ 1: INVITE : | | : 313 : : henning@cs.col: | | : 314 : cz@cs.tu-berlin.de =======================> tune : 315 : ^ | <....................... : 316 : . | : 4: 302 Moved : : 317 +...........|.........+ hgs@play : : 318 . | : : 319 . | 5: INVITE hgs@play.cs.columbia.edu 6: ring : 320 . ==================================================> play : 321 ..................................................... : 322 7: 200 OK : : 323 +...............................+ 325 ====> SIP request 326 ----> non-SIP protocols 328 Figure 2: Example of SIP redirect server 330 1.5 Transport-Protocol 332 SIP is able to utilise both UDP and TCP as transport protocols. UDP 333 allows the application to more carefully control the timing of 334 messages and their retransmission, to perform parallel searches 335 without requiring TCP connection state for each outstanding request, 336 and to use multicast. Routers can more readily snoop SIP UDP packets. 337 TCP allows easier passage through existing firewalls, and given the 338 similar protocol design, allows common servers for SIP, HTTP and the 339 RTSP [5]. 341 2. Security Considerations 343 The basic SIP Draft [2] does not deal with security considerations 344 other than to specify a reliance on lower-layer security mechanisms 345 such as SSL [6] when this is required. However, a number of issues 346 need to be addressed. These include the following: 348 - Authentication and Integrity of the SIP Communications 350 Here it is necessary, for example, to ensure that if a callee 351 receives an invitation they can be confident that the invitation 352 did indeed originate from the claimed initiator and has not been 353 changed en route. SIP messages can also modify details of future 354 conferences and so it would also be possible for a denial of 356 Kirstein et al. [PAGE 7] 357 service attack to be successful if messages cannot be 358 authenticated. 360 - Confidentiality of Conference Details 362 Here it is at least necessary to hide the details of the addresses 363 and media formats used. However, some proxies need to read certain 364 SIP header fields. 366 In order to facilitate the widespread implementation and use of SIP 367 security it was considered important to re-use existing security 368 implementations as much as possible. As much of this document is 369 concerned with security it should not be considered authoritative in 370 this area until the process of peer review has been completed. 372 2.1 Symmetric and Asymmetric Encryption 374 The simplest versions of encryption are symmetric ones; here the 375 encryption key can be calculated from the decryption key and vice 376 versa. In most cases the encryption key and decryption key are the 377 same. This means that, if E{a,M} is the operation of encrypting the 378 message M with the key a and algorithm E, then the decryption 379 operation D{a, E{a, M}} reproduces the original message M. If several 380 people know the key then symmetric encryption cannot be used for 381 authentication. 383 An alternative form of encryption is with the use of asymmetric 384 algorithms (also known as Public Key algorithms). Here the key used 385 for encryption is different to that used for decryption and it is not 386 feasible to calculate one from the other. Consequently the encryption 387 key can be made public and is known as the Public Key. Encrypting a 388 message with the recipient's Public Key ensures confidentiality as 389 only the recipient with the corresponding decryption key (known as the 390 Private Key) can decrypt the message. Encrypting a message with the 391 Private Key of the sender ensures authentication as only the sender 392 could have sent the message whereas anybody having access to the 393 Public Key can verify that it was indeed sent by the person holding 394 the corresponding Private Key. Some Public Key algorithms (e.g.RSA[7]) 395 can be used for both digital signatures and encryption whereas others 396 (e.g. DSA) can only be used for digital signatures. 398 Most practical implementations of public key cryptography use a 399 combination of symmetric and asymmetric algorithms. This is largely 400 due to the fact that symmetric algorithms are generally much faster 401 than asymmetric ones as well as the fact that public key cryptosystems 402 are vulnerable to chosen-plaintext attacks. Consequently, the messages 403 are generally secured using a symmetric algorithm and a different 404 session key each time. This session key is then encrypted and 405 distributed using public key algorithms. 407 The two public key algorithm formats which we make use of in this 408 document are PGP [8] and S/MIME [9]. These can be used for both 409 encryption and authentication. As detailed later implementers MUST 410 support PGP formats with support for S/MIME being OPTIONAL. 412 Kirstein et al. [PAGE 8] 413 3. SIP Security With PGP and MIME 415 The method specified here to secure SIP with PGP and MIME draws on 416 RFC 1847 [10] and RFC 2015 [11]. 418 3.1 PGP Data Formats 420 PGP can generate either ASCII armour [8] or 8-bit binary output when 421 encrypting data, generating a digital signature or extracting a 422 public key. With SIP an 8-bit clear channel is available and so ASCII 423 armour is not necessary. However, for interoperability issues 424 receiving agents SHOULD support the receipt of both armoured and 425 unarmoured data. Receiving and sending agents MUST support unarmoured 426 data. 428 3.2 MIME Encapsulation 430 Prior to any security procedures the SIP message MUST be converted 431 into MIME canonical format. The procedure for creating a MIME entity 432 is given in [20] where the reader is referred for fuller details than 433 are provided here. As SIP messages are text-based the MIME 434 canonicalization for the type text/plain should be followed. In brief 435 the line ending must be the sequence and the charset should 436 be a registered charset [21]. The details are specified in [20] and 437 the chosen charset SHOULD be named in the charset parameter so the 438 receiving agent can unambiguously determine the charset used. 440 As SIP has an 8-bit clear channel available then no transfer encoding 441 is necessary. However this should be supported in order to 442 interoperate more easily and allow messages created with mail tools 443 etc to be used without change. If a multipart/signed entity is being 444 used it SHOULD have transfer encoding applied so that it is 445 represented as 7-bit text. This would allow the signature on the data 446 to be identical if it had been sent via email or via SIP which 447 enhances flexibility. 449 An example of a MIME prepared SIP message, with no security 450 enhancements added, follows: 452 Content-Type: text/plain; charset=iso-8859-1 453 Content-Transfer-Encoding: quoted-printable 455 INVITE j.doe@acme.com SIP/2.1 456 To: J.Doe 457 From: Michael Elkins 458 Subject: Videoconference on security issues 459 CALL-ID: 786598 460 Content-Type: application/sdp 462 v=0 463 o=anybody 3098086191 3098086197 IN IP4 anycomputer.anywhere.com 464 s=general conference 465 i=This is a general conference 466 e=A. Nyone 468 Kirstein et al. [PAGE 9] 469 p=A. Nyone +44 171 123 4567 470 c=IN IP4 239.255.140.52/15 471 t=3098084400 3098091600 472 a=tool:sdr v2.5a0 473 a=type:test 474 m=audio 19274 RTP/AVP 0 475 c=IN IP4 239.255.140.52/15 476 a=ptime:40 478 Outside the MIME body the only SIP headers used are those dealing with 479 routing information which the proxies need access to. These include 480 the From, To and Call-ID fields. In addition, if any other fields such 481 as Proxy-Authenticate or Proxy-Authorization are present in the SIP 482 message these SHOULD also appear outside the MIME body if the SIP 483 message is only signed and MUST be present when the message is 484 encrypted. This allows sensitive fields such as the Subject field to 485 be present only in the MIME body which, when encrypted, makes these 486 unreadable by the proxies. The SIP-header Content-Type MUST NOT appear 487 with the headers outside the MIME body as this header field name is 488 used by MIME. 490 A "MIME-Version" header field [20] is then appended to the top-level 491 SIP headers and this must include the following text: 493 MIME-Version: 1.0 495 This indicates that the SIP Messages have been produced in accordance 496 with [20]. Note that all header fields in this document follow the 497 general syntactic rules defined in RFC 822 and in particular comments 498 are allowed. This means that the following are equivalent. 500 MIME-Version: 1.0 501 MIME-Version: 1.0 (Generated by SIP Server 3.4) 503 3.3 PGP Encrypted Data 505 PGP encrypted data is denoted by the "multipart/encrypted" content 506 type, as in RFC 1847, and MUST have a protocol parameter value of 507 "application/pgp-encrypted" including the quotes. The 508 multipart/encrypted message MUST consist of exactly two parts. The 509 first MIME body part MUST have a content-type of 510 "application/pgp-encrypted" and contain the control information. The 511 PGP message itself contains all the relevant control information so a 512 message complying with this standard MUST contain a "Version: 1" field 513 in this body. The second MIME body part MUST contain the actual 514 encrypted data and be labelled "application/octet-stream". The PGP 515 message is the complete, original SIP message converted into MIME 516 canonical format as in Section 3.2 and encrypted with the recipient's 517 public key. An example of an invitation where the payload of the SIP 518 message is in SDP format and ASCII armour has been used follows: 520 Kirstein et al. [PAGE 10] 521 INVITE j.doe@acme.com SIP/2.1 522 From: John Smith 523 To: J.Doe 524 Call-ID: 554565 525 MIME-Version: 1.0 526 Content-Type: multipart/encrypted; boundary=foo; 527 protocol="application/pgp-encrypted" 529 --foo 530 Content-Type: application/pgp-encrypted 531 Version: 1 533 --foo 534 Content-Type: application/octet-stream 536 -----BEGIN PGP MESSAGE----- 537 Version: 2.6.3i 538 hIwDjHVjzUcPoL0BA/0TlaOlL9qyUoEqP+jvSBKZLkQD9vU14O4WWf9h0EPUnHwQ 539 6f8r+9YaxPvU7a25Oct2QE2oOIr+smDr+Z/NKld58ueFqvNQ+kXac9vRAzv403vt 540 YYrh4ug1eetpe8znskWHiJv+3LHQBsNyWwLwoC78rIM2KQomhNUC6nvD9BP03qYA 541 AADXS6iYIRljShpEtc137hBhx4Q9sXAh2ki2OnEPom+q0Pqwy2C5SgZfHfotg9Pt 542 3HWRSJ64Se0VN2SQl9jFZ0oAkKtY79sCvkyhRGIjteLlufNbGBbLnbghN7uUBQi/ 543 URhXSWybyVMc2NoQaivRQxyHcXvhs8/687qPG2tGParPro2dbk8HiUN88lcdUCuL 544 +aD8qDllVhESVkdXfUHvL28fHhdM2ERaFCKQVOt9/7mnF3LB6SSbJKZuZJ+BYg/3 545 zuBVqDZo49yfURsgZ/iU2HWMXUydYEvxOR8= 546 =1I+h 547 -----END PGP MESSAGE----- 549 --foo-- 551 Upon receipt of a multipart/encrypted body part the following is done. 552 The second body part is prepared for decryption according to the value 553 of the protocol parameter The prepared body part is made available to 554 the decryption process and this makes available the result of the 555 decryption and the decrypted form of the encrypted body part. The SIP 556 implementation then continues processing with the decrypted body part. 557 The unencrypted headers outside the MIME body SHOULD be discarded to 558 avoid unwanted additions apart from the Via headers, added by the 559 intermediate proxies, which are needed for routing any replies. 561 The specification of a new SEALED method whereby the entire contents 562 of the SIP message, including the From, To and Call-ID fields, are 563 encrypted with the public key of the server at the next hop was 564 considered. This has the advantage that all sensitive information is 565 encrypted during transit from server to server but has the 566 disadvantage that each server can gain access to the full conference 567 details etc. This is clearly undesirable and the possibility of 568 encrypting a message as above with the recipient's public key and then 569 re-encrypting it with the public key of the server at the next hop 570 would be more secure. This allows each server access only to the 571 information needed. However, this gives rise to a considerable 572 overhead in both message size and processing time and is considered to 573 give minimal benefit. Traffic analysis could gain access to 574 information similar to that contained in the From and To fields and 576 Kirstein et al. [PAGE 11] 577 the other sensitive fields such as Subject are already encrypted with 578 the method detailed above. 580 3.4 PGP Signed Data 582 PGP signed messages are denoted by the "multipart/signed" content 583 type as in RFC 1847 with a protocol parameter which MUST have a value 584 of "application/pgp-signature". The "micalg" parameter MUST have a 585 value of "pgp-" where identifies the 586 message integrity check used to generate the signature. The currently 587 defined values for are "md5" for the MD5 checksum and 588 "sha1" for the SHA.1 algorithm. 590 The multipart/signed message MUST consist of exactly two parts, with 591 the first part containing the data to be signed, in MIME canonical 592 format, including a set of appropriate content headers describing the 593 data. The second body part MUST contain the PGP digital signature and 594 MUST be labelled with a content-type of "application/pgp-signature". 595 The message is created in the same way as above in that only the 596 information relevant to the proxies is outside the PGP signed message. 597 As described in [10], the digital signature MUST be calculated over 598 both the data to be signed and the set of content headers belonging to 599 the body part to be signed. Also the signature MUST be generated 600 detatched from the signed data so that the process does not alter the 601 signed data in any way. 603 An example of a PGP signed SIP message would be: 605 INVITE j.doe@acme.com SIP/2.1 606 From: Michael Elkins 607 To: Michael Elkins 608 CALL-ID: 786598 609 Mime-Version: 1.0 610 Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; 611 protocol="application/pgp-signature" 613 --bar 614 > Content-Type: text/plain; charset=iso-8859-1 615 > Content-Transfer-Encoding: quoted-printable 616 > 617 > INVITE j.doe@acme.com SIP/2.1 618 > To: J.Doe 619 > From: Michael Elkins 620 > Subject: Videoconference on security issues 621 > CALL-ID: 786598 622 > 623 > Content-Type: application/sdp 624 > 625 > v=0 626 > o=anybody 3098086191 3098086197 IN IP4 anycomputer.anywhere.com 627 > s=general conference 628 > i=This is a general conference 629 > e=A. Nyone 630 > p=A. Nyone +44 171 123 4567 632 Kirstein et al. [PAGE 12] 633 > c=IN IP4 239.255.140.52/15 634 > t=3098084400 3098091600 635 > a=tool:sdr v2.5a0 636 > a=type:test 637 > m=audio 19274 RTP/AVP 0 638 > c=IN IP4 239.255.140.52/15 639 > a=ptime:40 640 > 641 --bar 642 Content-Type: application/pgp-signature 644 -----BEGIN PGP MESSAGE----- 645 Version: 2.6.3i 647 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// 648 jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq 649 uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn 650 HOxEa44b+EI= 651 =ndaj 652 -----END PGP MESSAGE----- 654 --bar-- 656 The ">"s in the previous example indicate the portion of the data over 657 which the signature was calculated. Upon receipt of a signed message, 658 an application MUST pass both the signed data and its associated 659 content headers along with the PGP signature to the signature 660 verification service. 662 3.5 PGP Encrypted and Signed Data 664 With SIP messages it is often desirable to digitally sign and then 665 encrypt the messages. There are two methods for accomplishing this 666 [11]. The data can be both encrypted and then signed or can undergo a 667 joint "encryption and signing" process. Sending agents MUST support 668 the joint process. Receiving agents SHOULD support both types of 669 encryption and signing. 671 3.5.1 RFC 1847 Encapsulation 673 Here, the data (SIP Message) should first be signed as a 674 multipart/signed body as before and then encrypted to form the final 675 multipart/encrypted body as below. 677 INVITE j.doe@acme.com SIP/2.1 678 From: John Smith 679 To: J.Doe 680 Call-ID: 554565 681 MIME-Version: 1.0 682 Content-Type: multipart/encrypted; 683 protocol="application/pgp-encrypted"; boundary=foo 685 Kirstein et al. [PAGE 13] 686 --foo 687 Content-Type: application/pgp-encrypted 689 Version: 1 691 --foo 692 Content-Type: application/octet-stream 694 -----BEGIN PGP MESSAGE----- 695 > Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; 696 > protocol="application/pgp-signature" 697 > 698 > --bar 699 > Content-Type: text/plain; charset=iso-8859-1 700 > 701 > INVITE j.doe@acme.com SIP/2.1 702 > From: Michael Elkins 703 > To: J.Doe 704 > CALL-ID: 786598 705 > Content-Type: application/sdp 706 > 707 > v=0 708 > o=anybody 3098086191 3098086197 IN IP4 anycomputer.anywhere.com 709 > s=general conference 710 > i=This is a general conference 711 > e=A. Nyone 712 > p=A. Nyone +44 171 123 4567 713 > c=IN IP4 239.255.140.52/15 714 > t=3098084400 3098091600 715 > a=tool:sdr v2.5a0 716 > a=type:test 717 > c=IN IP4 239.255.140.52/15 718 > a=ptime:40 719 > 720 > --bar 721 > Content-Type: application/pgp-signature 722 > 723 > -----BEGIN PGP MESSAGE----- 724 > Version: 2.6.3i 725 > 726 > iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// 727 > jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq 728 > uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn 729 > HOxEa44b+EI= 730 > =ndaj 731 > -----END PGP MESSAGE----- 732 > 733 > --bar-- 734 -----END PGP MESSAGE----- 736 --foo-- 738 The text preceded by '>' indicates that it is really encrypted, but 739 presented as text for clarity. 741 Kirstein et al. [PAGE 14] 742 3.5.2 Combined Encryption and Signing 744 PGP also allows data to be signed and encrypted in one operation. As 745 mentioned above both sending and receiving agents MUST support this 746 format and this joint method has less overhead in terms of both data 747 length and processing time. The resulting data should be formed as a 748 "multipart/encrypted" object as described in Section 2.3. Messages, 749 which are encrypted and signed in this combined fashion, are REQUIRED 750 to follow the same canonicalization rules as for multipart/signed 751 objects. 753 Although only INVITE SIP messages have been used as examples in this 754 document the format is applied in exactly the same way for the other 755 method tokens mentioned above. This allows signature of ACK, BYE etc 756 SIP messages. 758 3.6 PGP Supported Algorithms 760 In order to maintain wide interoperability the algorithms supported 761 here follow [8] where fuller details can be found. 763 1. Public Key Algorithms - Implementations MUST implement DSA [23] 764 for signatures and Elgamal for encryption. Implementations 765 SHOULD implement RSA encryption [7]. 767 2. Symmetric Key Algorithm - Implementations MUST implement 768 Triple-DES [24]. Implementations SHOULD implement IDEA and 769 CAST5. Implementations MAY implement any other algorithm. 771 3. Compression Algorithms - Implementations MUST implement 772 uncompressed data. Implementations SHOULD implement ZIP. 774 4. Hash Algorithms - Implementations MUST implement SHA-1 [26]. 775 Implementations SHOULD implement MD5. 777 4. SIP Security with S/MIME 779 Support for the use of the S/MIME message format is OPTIONAL in this 780 specification. 782 The Cryptographic Message Syntax (CMS) is derived from PKCS#7 [14] and 783 is fully defined in [15]. This syntax is used here to digitally sign 784 or encrypt SIP messages and describes an encapsulation syntax for data 785 protection. The CMS values are generated using ASN.1 [12] using BER 786 encoding [13] and values are generally represented as octet strings. 788 CMS associates a protection content type with a protection content and 789 has ASN.1 type ContentInfo: 791 ContentInfo ::= SEQUENCE { 792 ContentType ContentType, 793 Content[0] EXPLICIT ANY DEFINED BY contentType } 795 ContentType ::= OBJECT IDENTIFIER 797 Kirstein et al. [PAGE 15] 798 ContentType indicates the type of protection content and is an Object 799 Identifier. Six are defined in [15] but only Data, SignedData and 800 EnvelopedData are of relevance to this document. Content is the actual 801 protected content. Sending agents MUST use the "data" content type as 802 the content within other content types to indicate the message content 803 which has had security services applied to it. In addition sending 804 agents MUST use the signedData content type to apply a digital 805 signature to a message and an envelopedData type to encrypt a message. 806 Further details of the specific requirements can be found in [9]. 808 Prior to any security enhancements the SIP message is converted into 809 MIME canonical format exactly as described in [20] and discussed in 810 Section 3.2. When S/MIME formats are used then these are as defined in 811 [9,15] where more complete details can be found. These documents are, 812 in turn, based on RFC 1847 [10] and PKCS#7 [14]. 814 4.1 The application/pkcs7-mime Type 816 The application/pkcs-7-mime type is used to carry CMS objects. This 817 always carries a single CMS object which is the BER encoding of the 818 ASN.1 syntax describing the object. The MIME headers of all 819 application/pkcs-7-mime objects SHOULD include the optional 820 "smime-type" parameters as described in [9]. 822 4.2 Encryption Only with S/MIME 824 The SIP message, which has been converted to MIME canonical format, 825 is processed into a CMS [15] object of type envelopedData. This is 826 then inserted into an applicaton/pkcs7-mime entity. The smime-type 827 parameter for enveloped-only messages is "enveloped-data" and the 828 file extension for this type of message is ".p7m". 830 A sample message would be: 832 INVITE j.doe@acme.com SIP/2.1 833 From: John Smith 834 To: J.Doe 835 Call-ID: 554565 836 MIME-Version: 1.0 837 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 838 name=smime.p7m 839 Content-Transfer-Encoding: base64 840 Content-Disposition: attachment; filename=smime.p7m 842 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 843 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 844 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 845 0GhIGfHfQbnj756YT64V 847 4.3 Signing Only With S/MIME 849 There are two possible formats for signed messages. One can either use 850 application/pkcs7-mime and SignedData or multipart/signed. In general, 851 the multipart/signed form is preferable for sending, and receiving 853 Kirstein et al. [PAGE 16] 854 agents SHOULD be able to handle both. The receiver can always view 855 messages signed using the multipart/signed format whether they have 856 S/MIME software or not. A recipient cannot view messages signed 857 using the signedData format unless they have S/MIME facilities. 859 4.3.1 Signing Using application/pkcs7-mime and SignedData 861 This signing format uses the application/pkcs7-mime MIME type as above 862 but now the MIME entity and other required data is processed into a 863 CMS object of type signedData. This is then inserted into an 864 application/pkcs7-mime MIME entity. The smime-type parameter for 865 messages using application/pkcs7-mime and SignedData is "signed-data" 866 and the file extension for this type of message is ".p7m". 868 A sample message would be: 870 INVITE j.doe@acme.com SIP/2.1 871 From: John Smith 872 To: J.Doe 873 Call-ID: 554565 874 MIME-Version: 1.0 875 Content-Type: application/pkcs7-mime; smime-type=signed-data; 876 name=smime.p7m 877 Content-Transfer-Encoding: base64 878 Content-Disposition: attachment; filename=smime.p7m 880 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 881 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH 882 HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 883 6YT64V0GhIGfHfQbnj75 885 4.3.2 Signing Using the multipart/signed Format 887 This format is a clear-signing format and recipients with no S/MIME or 888 PKCS processing facilities are able to view the message. It makes use 889 of the multipart/signed MIME type described in RFC 1847 and the format 890 is similar to the PGP signed-only SIP messages earlier. The 891 multipart/signed MIME type has two parts. The first part contains the 892 MIME entity that is to be signed; the second part contains the 893 signature, which is a CMS detached signature. 895 In order to create this type of message the SIP message is again 896 converted to MIME canonical format as discussed in Section 3.2. This 897 MIME entity is then processed to obtain a CMS object of type 898 signedData with an empty contentInfo field. The MIME entity is then 899 inserted into the first part of a multipart/signed message. Following 900 this, transfer-encoding can, if desired, be applied to the detached 901 signature and this is inserted into a MIME entity of type 902 application/pkcs7-signature. This MIME entity is then inserted into 903 the second part of the multipart/signed entity. 905 The application/pkcs7-signature MIME type always contains a single CMS 906 object of type signedData. The contentInfo field of the CMS object 907 must be empty. The signerInfos field contains the signatures for the 909 Kirstein et al. [PAGE 17] 910 MIME entity and the file extension for signed-only messages using 911 application/pkcs7-signature is ".p7s". 913 The multipart/signed content-type has two required parameters: the 914 protocol parameter and the micalg parameter. The protocol parameter 915 MUST be "application/pkcs7-signature". Note that quotation marks are 916 required around the protocol parameter because MIME requires that the 917 "/" character in the parameter value MUST be quoted. The micalg 918 parameter allows for one-pass processing when the signature is being 919 verified. The value of the micalg parameter is dependent on the 920 message digest algorithm used in the calculation of the Message 921 Integrity Check. The value of the micalg parameter SHOULD be one of 922 the following: 924 Algorithm: MD5 SHA-1 925 Value: md5 sha1 927 An example of a multipart/signed SIP Invitation would be: 929 INVITE j.doe@acme.com SIP/2.1 930 From: Michael Elkins 931 To: Michael Elkins 932 CALL-ID: 786598 933 Mime-Version: 1.0 934 Content-Type: multipart/signed; 935 protocol="application/pkcs7-signature"; 936 micalg=sha1; boundary=boundary42 938 --boundary42 939 > Content-Type: text/plain; charset=iso-8859-1 940 > Content-Transfer-Encoding: quoted-printable 941 > 942 > INVITE j.doe@acme.com SIP/2.1 943 > To: J.Doe 944 > From: Michael Elkins 945 > Subject: Videoconference on security issues 946 > CALL-ID: 786598 947 > 948 > Content-Type: application/sdp 949 > 950 > v=0 951 > o=anybody 3098086191 3098086197 IN IP4 anycomputer.anywhere.com 952 > s=general conference 953 > i=This is a general conference 954 > e=A. Nyone 955 > p=A. Nyone +44 171 123 4567 956 > c=IN IP4 239.255.140.52/15 957 > t=3098084400 3098091600 958 > a=tool:sdr v2.5a0 959 > a=type:test 960 > m=audio 19274 RTP/AVP 0 961 > c=IN IP4 239.255.140.52/15 962 > a=ptime:40 963 > 965 Kirstein et al. [PAGE 18] 966 --boundary42 967 Content-Type: application/pkcs7-signature; name=smime.p7s 968 Content-Transfer-Encoding: base64 969 Content-Disposition: attachment; filename=smime.p7s 971 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 972 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 973 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 974 7GhIGfHfYT64VQbnj756 976 --boundary42-- 978 The ">" indicate the data included in the signature. 980 4.4 Signing and Encrypting 982 To achieve signing and encrypting, any of the signed-only and 983 encrypted-only formats may be nested. This is allowed because the 984 above formats are all MIME entities, and because they all secure MIME 985 entities. A secure SIP implementation MUST be able to receive and 986 process arbitrarily nested S/MIME within reasonable resource limits of 987 the recipient computer. 989 It is possible to either sign a message first, or to envelope the 990 message first. It is up to the implementor and the user to choose. 991 When signing first, the enveloping then securely obscures the 992 signatories. When enveloping first the signatories are exposed, but it 993 is possible to verify signatures without removing the enveloping. This 994 may be useful in an environment where automatic signature verification 995 is desired, as no private key material is required to verify a 996 signature. 998 4.5 S/MIME Supported Algorithms 1000 In order to maintain wide interoperability the algorithms supported 1001 here follow [9] where fuller details can be found. 1003 1. KeyEncryptionAlgorithmIdentifier 1005 Sending and receiving agents MUST support Diffie-Hellman defined 1006 in [22]. 1008 Receiving agents SHOULD support rsaEncryption [7]. Incoming 1009 encrypted messages contain symmetric keys which are to be 1010 decrypted with a user's private key. The size of the private key 1011 is determined during key generation. 1013 Sending agents SHOULD support rsaEncryption. Sending agents 1014 SHOULD support rsaEncryption encryption. If an agent supports 1015 rsaEncryption then it MUST support encryption of symmetric keys 1016 with RSA public keys at key sizes from 512 bits to 1024 bits. 1018 Kirstein et al. [PAGE 19] 1019 2. SignatureAlgorithmIdentifier 1021 Sending and receiving agents MUST support id-dsa defined in 1022 [23]. The algorithm parameters MUST be absent (not encoded as 1023 NULL). 1025 Receiving agents SHOULD support rsaEncryption, defined in [7]. 1026 Receiving agents SHOULD support verification of signatures using 1027 RSA public key sizes from 512 bits to 1024 bits. 1029 Sending agents SHOULD support rsaEncryption. Outgoing messages 1030 are signed with a user's private key. 1032 3. ContentEncryptionAlgorithmIdentifier 1034 Receiving agents MUST support encryption and decryption with 1035 DES EDE3 CBC [24]. Receiving agents SHOULD support encryption 1036 and decryption using the RC2 [25] or a compatible algorithm at 1037 a key size of 40 bits. 1039 4. DigestAlgorithmIdentifier 1041 Receiving agents MUST support SHA-1 [26]. Receiving agents 1042 SHOULD support MD5 [27]. 1044 Sending agents SHOULD use SHA-1. 1046 Kirstein et al. [PAGE 20] 1047 References 1049 [1] M.Handley "SAP: Session Announcement Protocol" 1050 Internet Draft: draft-ietf-mmusic-sap-00.txt, 27/Nov/96 1052 [2] M. Handley, H. Schulzrinne and E. Schooler 1053 "SIP: Session Initiation Protocol" 1054 Internet Draft: draft-ietf-mmusic-sip-04.txt, Nov 97 1056 [3] D. Crocker "Standard for the Format of ARPA Internet Text Messages" 1057 STD 11, RFC 822, University of Delaware, August 1982 1059 [4] M. Handley and V. Jacobson "SDP: Session Description Protocol" 1060 Internet Draft: draft-ietf-mmusic-sdp-06.txt, Jan 97 1062 [5] H. Schulzrinne, A. Rao and R. Lanphier 1063 "Real Time Streaming Protocol (RTSP)" 1064 IETF, Internet Draft, July 97 Work In Progress 1066 [6] A. Freier, P. Karlton and P. Kocher "The SSL Protocol: Version 3.0" 1067 Internet Draft: draft-ietf-tls-ssl-version3-00.txt, Nov 96 1069 [7] R.L. Rivest, A. Shamir and L.M. Adleman 1070 "A Method for Obtaining Digital Signatures and Public Key 1071 Cryptosystems", 1072 Communications of the ACM, v. 21, n. 2, Feb 1978, pp 120-126 1074 PKCS#1 "RSA Encryption Standard" 1075 RSA Laboratories, Version 1.5, Nov 1993 1077 [8] J. Callas "OpenPGP Message Formats" 1079 [9] B. Ramsdell "S/MIME Version 3 Message Specification" 1080 [10] J. Galvin et al 1081 "Security Multiparts for MIME: Multipart/Signed and 1082 Multipart/Encrypted" 1083 Technical Report RFC 1847, IETF, Oct 1995 1085 [11] M. Elkins "MIME Security With Pretty Good Privacy" 1086 Technical Report RFC 2015, IETF, Oct 1996 1088 [12] X.208 "Specification of Abstract Syntax Notation One (ASN.1)" 1089 ITU-T Recommendations, 1988 1091 [13] X.209 "BER: Basic Encoding Rules for ASN.1" 1092 ITU-T Recommendations, 1988 1094 [14] PKCS#7 "Cryptographic Message Syntax Standard" 1095 RSA Laboratories, Version 1.5, Nov 1993 1097 Kirstein et al. [PAGE 21] 1098 [15] R. Housley "Cryptographic Message Syntax" 1099 [16] Fielding et al "Hypetext transfer Protocol - HTTP/1.1" 1100 Technical Report RFC 2068, IETF, Jan 1997 1102 [17] D. Crocker "Augmented BNF for Syntax Specifications: ABNF" 1103 IETF, Internet Draft, Oct 1996, Work In Progress 1105 [18] J. C. Mogul and S. E. Deering "Path MTU Discovery" 1106 Technical Report RFC 1191, IETF, Nov 1990 1108 [19] W. R. Stevens "TCP/IP Illustrated: The Protocols" 1109 Vol 1, Reading, Massachusetts. Pub: Addison-Wesley, 1994 1111 [20] N. Freed and N. Borenstein 1112 "MIME: Part One. Format of internet Message Bodies" 1113 Technical Report RFC 2045, IETF, Nov 1996 1115 N. Freed and N. Borenstein 1116 "MIME: Part Two. Media Types" 1117 Technical Report RFC 2046, IETF, Nov 1996 1119 K. Moore 1120 "MIME: Part Three. Message header Extensions for Non-ASCII Text" 1121 Technical Report RFC 2047, IETF, Nov 1996 1123 N. Freed et al 1124 "MIME: Part Four. Registration Procedures" 1125 Technical Report RFC 2048, IETF, Nov 1996 1127 N. Freed and N. Borenstein 1128 "MIME: Part Five. Conformance Criteria and Examples" 1129 Technical Report RFC 2049, IETF, Nov 1996 1131 [21] Character sets assigned by IANA. 1132 See 1134 [22] ANSI X9.42 1136 [23] ANSI X9.57-1997x, 1137 "Public Key Cryptography for the Financial Services Industry: 1138 Certificate Management". Working Draft, June 1996 1140 [24] ANSI X3.106 1141 "American National Standards for Information Systems - Data Link 1142 Encryption" 1143 American National Standards Institute, 1983 (DES) 1145 W. Tuchman "Hellman Presents No Shortcuts Solutions to DES" 1146 IEEE Spectrum, v16, n7, pp40-41, July 1979 1148 [25] R.L. Rivest et al "Description of the RC2 Encryption Algorithm" 1149 Internet Draft: draft-rivest-rc2desc-01.txt 1151 Kirstein et al. [PAGE 23] 1152 [26] NIST FIPS PUB 180-1 "Secure Hash Standard" 1153 National Institute of Standards and Technology, 1154 U.S. Dept. of Commerce, DRAFT, May 1994 1156 [27] R. L. Rivest "The MD5 Message Digest Algorithm" 1157 Technical Report RFC 1321, IETF, April 1992 1159 [28] Bradner "Key words for use in RFCs to indicate Requirement Level" 1160 Technical Report RFC 2119, IETF, March 1997 1162 Authors' Addresses 1164 Peter Kirstein, Goli Montasser Kohsari and Edmund Whelan are at 1165 University College London and their contact details are: 1167 P.Kirstein@cs.ucl.ac.uk Tel: +44 171 380 7286 1168 G.Montasser-Kohsari@cs.ucl.ac.uk Tel: +44 171 380 7215 1169 E.Whelan@cs.ucl.ac.uk Tel: +44 171 419 3688 1171 Dept of Computer Science Fax: +44 171 387 1397 1172 University College London 1173 Gower Street 1174 London WC1E 6BT England 1176 Acknowledgements 1178 The European Commission, under the Telematics 1007 "MERCI" project and 1179 the Telematics 1005 "ICE-TEL" project, funded the design of SIP 1180 Security. Mark Handely, Henning Schulzrinne and Eve Schooler developed 1181 the original SIP draft. 1183 Kirstein et al. [PAGE 24]