Internet Engineering Task Force MMUSIC WG Internet Draft P. Kirstein draft-ietf-mmusic-sip-sec-00.txt G. Montasser-Kohsari March 12th 1998 E. Whelan Expires: September 12th 1998 University College London SIP Security Using Public Key Algorithms STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. ABSTRACT The Session Initiation Protocol (SIP) is a simple protocol designed to enable the invitation of users to multimedia sessions. This document is a companion draft to draft-ietf-mmusic-sip-04.txt, which defines SIP but doesn't specify any security mechanisms other than possible protection by lower-level security mechanisms such as SSL. This leaves SIP transactions vulnerable to attack and this document aims to extend the SIP protocol to address such security considerations. This document is a product of the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. Kirstein et al. [PAGE 1] Internet Draft SIP Security March 12, 1998 TABLE OF CONTENTS 1. Introduction .................................................. 3 1.1 Overview of SIP Functionality .............................. 3 1.2 Terminology ................................................ 3 1.3 SIP Message Overview ....................................... 3 1.3.1 Request ................................................ 4 1.3.2 Response ............................................... 4 1.3.3 SIP Version ............................................ 5 1.4 SIP Transaction ............................................ 5 1.4.1 Example of a SIP Invitation ............................ 5 1.5 Transport-Protocol ......................................... 7 2. Security Considerations ....................................... 7 2.1 Symmetric and Asymmetric Encryption ........................ 8 3. SIP Security With PGP and MIME ................................ 9 3.1 PGP Data Formats ........................................... 9 3.2 MIME Encapsulation ......................................... 9 3.3 PGP Encrypted Data ......................................... 10 3.4 PGP Signed Data ............................................ 12 3.5 PGP Encrypted and Signed Data .............................. 13 3.5.1 RFC 1847 Encapsulation ................................. 13 3.5.2 Combined Encryption and Signing ........................ 15 3.6 PGP Supported Algorithms ................................... 15 4. SIP Security with S/MIME ...................................... 15 4.1 The application/pkcs7-mime Type ............................ 16 4.2 Encryption Only with S/MIME ................................ 16 4.3 Signing Only with S/MIME ................................... 16 4.3.1 Signing Using application/pkcs7-mime and SignedData .... 17 4.3.2 Signing Using the multipart/signed Format .............. 17 4.4 Signing and Encrypting ..................................... 19 4.5 S/MIME Supported Algorithms ................................ 19 References ....................................................... 21 Authors' Addresses ............................................... 24 Acknowledgements ................................................. 24 Kirstein et al. [PAGE 2] Internet Draft SIP Security March 12, 1998 1. Introduction 1.1 Overview of SIP Functionality The Session Initiation Protocol (SIP) is an application-layer protocol that can establish and control multimedia sessions or calls. These multimedia sessions include multimedia conferences, distance learning, Internet telephony and similar applications. SIP can invite a person to both unicast and multicast sessions; the initiator does not necessarily have to be a member of the session it is inviting to. Media and participants can be added to an existing session. SIP can be used to "call" both persons and "robots", for example, to invite a media storage device to record an ongoing conference or to invite a video-on-demand server to play a video into a conference. SIP can be used to initiate sessions as well as invite members to sessions that have been advertised and established by other means such as SAP [1], electronic mail, news groups, web pages and directories (LDAP). SIP is fully defined in [2] and, as this is a companion draft aiming to extend the basic functionality of SIP to address security considerations, familiarity with [2] is assumed. Consequently, only a brief introduction to SIP itself is included here. 1.2 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [28] and indicate requirement levels for compliant SIP implementations. 1.3 SIP Message Overview As much of the message syntax is identical to HTTP/1.1 the notation [HX.Y] is used to refer to section X.Y of the current HTTP/1.1 [16] specification. In addition an augmented Backus-Naur form (BNF) [17] [H2.1] is used. All SIP messages are text-based and use HTTP/1.1 conventions [H4.1], except for the additional ability of SIP to use UDP. When sent over TCP or UDP, multiple SIP transactions can be carried in a single TCP connection or UDP datagram. UDP datagrams, including all headers, should not normally be larger than the path maximum transmission unit (MTU) if the MTU is known or 1500 bytes if the MTU is unknown. The 1400 bytes accommodates lower-layer packet headers within the "typical" MTU of around 1500 bytes. There are few MTU values around 1 kB; the next value is 1006 bytes for SLIP and 296 for low-delay PPP [18]. Recent studies [19] indicate that an MTU of 1500 bytes is a reasonable assumption. Thus, another reasonable value would be a message size of 950 bytes, to accommodate packet headers within the SLIP MTU without fragmentation. A SIP message is either a request from a client to a server, or a response from a server to a client. SIP-message = Request | Response ; SIP messages Kirstein et al. [PAGE 3] Internet Draft SIP Security March 12, 1998 Both Request and Response messages use the generic RFC822 [3] message format for transferring entities (the payload of the message). Both types of message consist of a start-line, one or more header fields, an empty line indicating the end of the header fields and an optional message body. Generic message = start-line *(general header | request header | entity header) CRLF [message body] start-line = Request Line | Status Line 1.3.1 Request The Request message format is shown below: Request = Request Line *(general header | request header | entity header) CRLF [message body] The Request Line begins with a method token, followed by the Request-URI, the protocol version and ending with a CRLF. SP characters separate each element. Request Line = Method SP Request-URI SP SIP-Version CRLF Method = "INVITE" | "ACK" | "OPTIONS" | "BYE" | "REGISTER" | "UNREGISTER" INVITE indicates that the user or service is being invited to participate and the message body contains a description of the relevant session. ACK confirms that the client has received a final response to an INVITE request. OPTIONS is used to query a client about its capabilities. The client uses BYE to indicate to the server that it wishes to abort the call attempt. REGISTER is used by the client to register the address listed in the request line to a SIP server and UNREGISTER is used to cancel an existing registration. Support for INVITE and ACK is mandatory in the SIP specification whereas support for OPTIONS, BYE, REGISTER and UNREGISTER is OPTIONAL. 1.3.2 Response Once a recipient has received and interpreted a request message they respond with a SIP response message. The format of the response is shown below: Response = Status Line *(general header | request header | entity header) CRLF [message body] The Status Line is similar to the Request Line. It consists of the SIP Kirstein et al. [PAGE 4] Internet Draft SIP Security March 12, 1998 Version, a numeric Status Code and its associated textual phrase. SP characters separate each element and the line ends with a CRLF sequence. Status Line = SIP Version SP Status Code SP Reason Phrase CRLF 1.3.3 SIP Version Both request and response messages include the version of SIP in use and this follows [H3.1], with HTTP replaced by SIP. Applications making use of the security enhancements detailed in this paper MUST include a SIP-Version of "SIP/2.1". 1.4 SIP Transaction When making a SIP call a caller first locates the appropriate sever and then sends a SIP request. The most common SIP operation is the invitation. Instead of directly reaching the intended callee, a SIP request may be redirected or trigger a new chain of requests by proxies. 1.4.1 Example of a SIP Invitation A successful SIP invitation consists of two requests, INVITE followed by ACK. The INVITE request asks the callee to join a particular conference or establish a two-party conversation. After the callee has agreed to participate in the call, the caller confirms that it has received that response by sending an ACK request. If the call is rejected, or otherwise unsuccessful, the caller sends a BYE request instead of an ACK. The INVITE request typically contains a session description, for example written in SDP format [4], that provides the called party with enough in formation to join the session. For multicast sessions, the session description enumerates the media types and formats that may be distributed to that session. For unicast sessions, the session description enumerates the media types and formats that the caller is willing to receive and where it wishes the media data to be sent. In either case, if the callee wishes to accept the call, it responds to the invitation by returning a similar description listing the media it wishes to receive. For a multicast session, the callee should only return a session description if it is unable to receive the media indicated in the caller's description. The caller may ignore the session description returned or use it to change the global session description. The protocol exchanges for the INVITE method are shown in Fig. 1 for a proxy server and in Fig. 2 for a redirect server. The proxy server accepts the INVITE request (1), contacts the location service with all or parts of the address (2) and obtains a more precise location (3). The proxy server then issues a SIP INVITE request to the address(es) returned by the location service (4). The user agent server alerts the user (5) and returns a success indication to the proxy server (6). The proxy server then returns the success result to the original caller Kirstein et al. [PAGE 5] Internet Draft SIP Security March 12, 1998 (7). The receipt of this message is confirmed by the caller using an ACK message, which is forwarded to the callee (8,9), with a response returned (10,11). All requests have the same Call-ID. +....... cs.columbia.edu .......+ : : : (~~~~~~~~~~) : : ( location ) : : ( service ) : : (~~~~~~~~~~) : : ^ | : : | hgs@play : : 2| 3| : : | | : : henning | : +.. cs.tu-berlin.de ..+ 1: INVITE : | | : : : henning@cs.col: | | 4: INVITE 5: ring : : cz@cs.tu-berlin.de ========================> tune =========> play : : <........................ <......... : : : 7: 200 OK : 6: 200 OK : +.....................+ +...............................+ ====> SIP request ----> non-SIP protocols Figure 1: Example of SIP proxy server The redirect server accepts the INVITE request (1), contacts the location service as before (2,3) and, instead of contacting the newly found address itself, returns the address to the caller (4). The caller issues a new request, with a new call-ID, to the address returned by the first server (6). In the example, the call succeeds (7). The caller and callee complete the handshake with an ACK (8,9). The action taken on receiving a list of locations varies with the type of SIP server. A SIP redirect server simply returns the list to the client sending the request as Location headers. A SIP proxy server can sequentially or in parallel try the addresses. If a proxy server forwards a SIP request, it MUST add itself to the end of the list of forwarders noted in the Via headers. The Via trace ensures that replies can take the same path back, thus ensuring correct operation through compliant firewalls and loop-free requests. On the reply path, each host most remove its Via, so that routing internal information is hidden from the callee and outside networks. When a multicast request is made, first the host making the request, then the multicast address itself are added to the path. A proxy server MUST check that it does not generate a request to a host listed in the Via list. (Note: If a host has several names or network addresses, this may not always work. Thus, each host also checks if it is part of the Via list.) Kirstein et al. [PAGE 6] Internet Draft SIP Security March 12, 1998 +....... cs.columbia.edu .......+ : : : (~~~~~~~~~~) : : ( location ) : : ( service ) : : (~~~~~~~~~~) : : ^ | : : | hgs@play : : 2| 3| : : | | : : henning | : +.. cs.tu-berlin.de ..+ 1: INVITE : | | : : : henning@cs.col: | | : : cz@cs.tu-berlin.de =======================> tune : : ^ | <....................... : : . | : 4: 302 Moved : : +...........|.........+ hgs@play : : . | : : . | 5: INVITE hgs@play.cs.columbia.edu 6: ring : . ==================================================> play : ..................................................... : 7: 200 OK : : +...............................+ ====> SIP request ----> non-SIP protocols Figure 2: Example of SIP redirect server 1.5 Transport-Protocol SIP is able to utilise both UDP and TCP as transport protocols. UDP allows the application to more carefully control the timing of messages and their retransmission, to perform parallel searches without requiring TCP connection state for each outstanding request, and to use multicast. Routers can more readily snoop SIP UDP packets. TCP allows easier passage through existing firewalls, and given the similar protocol design, allows common servers for SIP, HTTP and the RTSP [5]. 2. Security Considerations The basic SIP Draft [2] does not deal with security considerations other than to specify a reliance on lower-layer security mechanisms such as SSL [6] when this is required. However, a number of issues need to be addressed. These include the following: - Authentication and Integrity of the SIP Communications Here it is necessary, for example, to ensure that if a callee receives an invitation they can be confident that the invitation did indeed originate from the claimed initiator and has not been changed en route. SIP messages can also modify details of future conferences and so it would also be possible for a denial of Kirstein et al. [PAGE 7] Internet Draft SIP Security March 12, 1998 service attack to be successful if messages cannot be authenticated. - Confidentiality of Conference Details Here it is at least necessary to hide the details of the addresses and media formats used. However, some proxies need to read certain SIP header fields. In order to facilitate the widespread implementation and use of SIP security it was considered important to re-use existing security implementations as much as possible. As much of this document is concerned with security it should not be considered authoritative in this area until the process of peer review has been completed. 2.1 Symmetric and Asymmetric Encryption The simplest versions of encryption are symmetric ones; here the encryption key can be calculated from the decryption key and vice versa. In most cases the encryption key and decryption key are the same. This means that, if E{a,M} is the operation of encrypting the message M with the key a and algorithm E, then the decryption operation D{a, E{a, M}} reproduces the original message M. If several people know the key then symmetric encryption cannot be used for authentication. An alternative form of encryption is with the use of asymmetric algorithms (also known as Public Key algorithms). Here the key used for encryption is different to that used for decryption and it is not feasible to calculate one from the other. Consequently the encryption key can be made public and is known as the Public Key. Encrypting a message with the recipient's Public Key ensures confidentiality as only the recipient with the corresponding decryption key (known as the Private Key) can decrypt the message. Encrypting a message with the Private Key of the sender ensures authentication as only the sender could have sent the message whereas anybody having access to the Public Key can verify that it was indeed sent by the person holding the corresponding Private Key. Some Public Key algorithms (e.g.RSA[7]) can be used for both digital signatures and encryption whereas others (e.g. DSA) can only be used for digital signatures. Most practical implementations of public key cryptography use a combination of symmetric and asymmetric algorithms. This is largely due to the fact that symmetric algorithms are generally much faster than asymmetric ones as well as the fact that public key cryptosystems are vulnerable to chosen-plaintext attacks. Consequently, the messages are generally secured using a symmetric algorithm and a different session key each time. This session key is then encrypted and distributed using public key algorithms. The two public key algorithm formats which we make use of in this document are PGP [8] and S/MIME [9]. These can be used for both encryption and authentication. As detailed later implementers MUST support PGP formats with support for S/MIME being OPTIONAL. Kirstein et al. [PAGE 8] Internet Draft SIP Security March 12, 1998 3. SIP Security With PGP and MIME The method specified here to secure SIP with PGP and MIME draws on RFC 1847 [10] and RFC 2015 [11]. 3.1 PGP Data Formats PGP can generate either ASCII armour [8] or 8-bit binary output when encrypting data, generating a digital signature or extracting a public key. With SIP an 8-bit clear channel is available and so ASCII armour is not necessary. However, for interoperability issues receiving agents SHOULD support the receipt of both armoured and unarmoured data. Receiving and sending agents MUST support unarmoured data. 3.2 MIME Encapsulation Prior to any security procedures the SIP message MUST be converted into MIME canonical format. The procedure for creating a MIME entity is given in [20] where the reader is referred for fuller details than are provided here. As SIP messages are text-based the MIME canonicalization for the type text/plain should be followed. In brief the line ending must be the sequence and the charset should be a registered charset [21]. The details are specified in [20] and the chosen charset SHOULD be named in the charset parameter so the receiving agent can unambiguously determine the charset used. As SIP has an 8-bit clear channel available then no transfer encoding is necessary. However this should be supported in order to interoperate more easily and allow messages created with mail tools etc to be used without change. If a multipart/signed entity is being used it SHOULD have transfer encoding applied so that it is represented as 7-bit text. This would allow the signature on the data to be identical if it had been sent via email or via SIP which enhances flexibility. An example of a MIME prepared SIP message, with no security enhancements added, follows: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable INVITE j.doe@acme.com SIP/2.1 To: J.Doe From: Michael Elkins Subject: Videoconference on security issues CALL-ID: 786598 Content-Type: application/sdp v=0 o=anybody 3098086191 3098086197 IN IP4 anycomputer.anywhere.com s=general conference i=This is a general conference e=A. Nyone Kirstein et al. [PAGE 9] Internet Draft SIP Security March 12, 1998 p=A. Nyone +44 171 123 4567 c=IN IP4 239.255.140.52/15 t=3098084400 3098091600 a=tool:sdr v2.5a0 a=type:test m=audio 19274 RTP/AVP 0 c=IN IP4 239.255.140.52/15 a=ptime:40 Outside the MIME body the only SIP headers used are those dealing with routing information which the proxies need access to. These include the From, To and Call-ID fields. In addition, if any other fields such as Proxy-Authenticate or Proxy-Authorization are present in the SIP message these SHOULD also appear outside the MIME body if the SIP message is only signed and MUST be present when the message is encrypted. This allows sensitive fields such as the Subject field to be present only in the MIME body which, when encrypted, makes these unreadable by the proxies. The SIP-header Content-Type MUST NOT appear with the headers outside the MIME body as this header field name is used by MIME. A "MIME-Version" header field [20] is then appended to the top-level SIP headers and this must include the following text: MIME-Version: 1.0 This indicates that the SIP Messages have been produced in accordance with [20]. Note that all header fields in this document follow the general syntactic rules defined in RFC 822 and in particular comments are allowed. This means that the following are equivalent. MIME-Version: 1.0 MIME-Version: 1.0 (Generated by SIP Server 3.4) 3.3 PGP Encrypted Data PGP encrypted data is denoted by the "multipart/encrypted" content type, as in RFC 1847, and MUST have a protocol parameter value of "application/pgp-encrypted" including the quotes. The multipart/encrypted message MUST consist of exactly two parts. The first MIME body part MUST have a content-type of "application/pgp-encrypted" and contain the control information. The PGP message itself contains all the relevant control information so a message complying with this standard MUST contain a "Version: 1" field in this body. The second MIME body part MUST contain the actual encrypted data and be labelled "application/octet-stream". The PGP message is the complete, original SIP message converted into MIME canonical format as in Section 3.2 and encrypted with the recipient's public key. An example of an invitation where the payload of the SIP message is in SDP format and ASCII armour has been used follows: Kirstein et al. [PAGE 10] Internet Draft SIP Security March 12, 1998 INVITE j.doe@acme.com SIP/2.1 From: John Smith To: J.Doe Call-ID: 554565 MIME-Version: 1.0 Content-Type: multipart/encrypted; boundary=foo; protocol="application/pgp-encrypted" --foo Content-Type: application/pgp-encrypted Version: 1 --foo Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- Version: 2.6.3i hIwDjHVjzUcPoL0BA/0TlaOlL9qyUoEqP+jvSBKZLkQD9vU14O4WWf9h0EPUnHwQ 6f8r+9YaxPvU7a25Oct2QE2oOIr+smDr+Z/NKld58ueFqvNQ+kXac9vRAzv403vt YYrh4ug1eetpe8znskWHiJv+3LHQBsNyWwLwoC78rIM2KQomhNUC6nvD9BP03qYA AADXS6iYIRljShpEtc137hBhx4Q9sXAh2ki2OnEPom+q0Pqwy2C5SgZfHfotg9Pt 3HWRSJ64Se0VN2SQl9jFZ0oAkKtY79sCvkyhRGIjteLlufNbGBbLnbghN7uUBQi/ URhXSWybyVMc2NoQaivRQxyHcXvhs8/687qPG2tGParPro2dbk8HiUN88lcdUCuL +aD8qDllVhESVkdXfUHvL28fHhdM2ERaFCKQVOt9/7mnF3LB6SSbJKZuZJ+BYg/3 zuBVqDZo49yfURsgZ/iU2HWMXUydYEvxOR8= =1I+h -----END PGP MESSAGE----- --foo-- Upon receipt of a multipart/encrypted body part the following is done. The second body part is prepared for decryption according to the value of the protocol parameter The prepared body part is made available to the decryption process and this makes available the result of the decryption and the decrypted form of the encrypted body part. The SIP implementation then continues processing with the decrypted body part. The unencrypted headers outside the MIME body SHOULD be discarded to avoid unwanted additions apart from the Via headers, added by the intermediate proxies, which are needed for routing any replies. The specification of a new SEALED method whereby the entire contents of the SIP message, including the From, To and Call-ID fields, are encrypted with the public key of the server at the next hop was considered. This has the advantage that all sensitive information is encrypted during transit from server to server but has the disadvantage that each server can gain access to the full conference details etc. This is clearly undesirable and the possibility of encrypting a message as above with the recipient's public key and then re-encrypting it with the public key of the server at the next hop would be more secure. This allows each server access only to the information needed. However, this gives rise to a considerable overhead in both message size and processing time and is considered to give minimal benefit. Traffic analysis could gain access to information similar to that contained in the From and To fields and Kirstein et al. [PAGE 11] Internet Draft SIP Security March 12, 1998 the other sensitive fields such as Subject are already encrypted with the method detailed above. 3.4 PGP Signed Data PGP signed messages are denoted by the "multipart/signed" content type as in RFC 1847 with a protocol parameter which MUST have a value of "application/pgp-signature". The "micalg" parameter MUST have a value of "pgp-" where identifies the message integrity check used to generate the signature. The currently defined values for are "md5" for the MD5 checksum and "sha1" for the SHA.1 algorithm. The multipart/signed message MUST consist of exactly two parts, with the first part containing the data to be signed, in MIME canonical format, including a set of appropriate content headers describing the data. The second body part MUST contain the PGP digital signature and MUST be labelled with a content-type of "application/pgp-signature". The message is created in the same way as above in that only the information relevant to the proxies is outside the PGP signed message. As described in [10], the digital signature MUST be calculated over both the data to be signed and the set of content headers belonging to the body part to be signed. Also the signature MUST be generated detatched from the signed data so that the process does not alter the signed data in any way. An example of a PGP signed SIP message would be: INVITE j.doe@acme.com SIP/2.1 From: Michael Elkins To: Michael Elkins CALL-ID: 786598 Mime-Version: 1.0 Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; protocol="application/pgp-signature" --bar > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: quoted-printable > > INVITE j.doe@acme.com SIP/2.1 > To: J.Doe > From: Michael Elkins > Subject: Videoconference on security issues > CALL-ID: 786598 > > Content-Type: application/sdp > > v=0 > o=anybody 3098086191 3098086197 IN IP4 anycomputer.anywhere.com > s=general conference > i=This is a general conference > e=A. Nyone > p=A. Nyone +44 171 123 4567 Kirstein et al. [PAGE 12] Internet Draft SIP Security March 12, 1998 > c=IN IP4 239.255.140.52/15 > t=3098084400 3098091600 > a=tool:sdr v2.5a0 > a=type:test > m=audio 19274 RTP/AVP 0 > c=IN IP4 239.255.140.52/15 > a=ptime:40 > --bar Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3i iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b+EI= =ndaj -----END PGP MESSAGE----- --bar-- The ">"s in the previous example indicate the portion of the data over which the signature was calculated. Upon receipt of a signed message, an application MUST pass both the signed data and its associated content headers along with the PGP signature to the signature verification service. 3.5 PGP Encrypted and Signed Data With SIP messages it is often desirable to digitally sign and then encrypt the messages. There are two methods for accomplishing this [11]. The data can be both encrypted and then signed or can undergo a joint "encryption and signing" process. Sending agents MUST support the joint process. Receiving agents SHOULD support both types of encryption and signing. 3.5.1 RFC 1847 Encapsulation Here, the data (SIP Message) should first be signed as a multipart/signed body as before and then encrypted to form the final multipart/encrypted body as below. INVITE j.doe@acme.com SIP/2.1 From: John Smith To: J.Doe Call-ID: 554565 MIME-Version: 1.0 Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; boundary=foo Kirstein et al. [PAGE 13] Internet Draft SIP Security March 12, 1998 --foo Content-Type: application/pgp-encrypted Version: 1 --foo Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- > Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; > protocol="application/pgp-signature" > > --bar > Content-Type: text/plain; charset=iso-8859-1 > > INVITE j.doe@acme.com SIP/2.1 > From: Michael Elkins > To: J.Doe > CALL-ID: 786598 > Content-Type: application/sdp > > v=0 > o=anybody 3098086191 3098086197 IN IP4 anycomputer.anywhere.com > s=general conference > i=This is a general conference > e=A. Nyone > p=A. Nyone +44 171 123 4567 > c=IN IP4 239.255.140.52/15 > t=3098084400 3098091600 > a=tool:sdr v2.5a0 > a=type:test > c=IN IP4 239.255.140.52/15 > a=ptime:40 > > --bar > Content-Type: application/pgp-signature > > -----BEGIN PGP MESSAGE----- > Version: 2.6.3i > > iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// > jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq > uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn > HOxEa44b+EI= > =ndaj > -----END PGP MESSAGE----- > > --bar-- -----END PGP MESSAGE----- --foo-- The text preceded by '>' indicates that it is really encrypted, but presented as text for clarity. Kirstein et al. [PAGE 14] Internet Draft SIP Security March 12, 1998 3.5.2 Combined Encryption and Signing PGP also allows data to be signed and encrypted in one operation. As mentioned above both sending and receiving agents MUST support this format and this joint method has less overhead in terms of both data length and processing time. The resulting data should be formed as a "multipart/encrypted" object as described in Section 2.3. Messages, which are encrypted and signed in this combined fashion, are REQUIRED to follow the same canonicalization rules as for multipart/signed objects. Although only INVITE SIP messages have been used as examples in this document the format is applied in exactly the same way for the other method tokens mentioned above. This allows signature of ACK, BYE etc SIP messages. 3.6 PGP Supported Algorithms In order to maintain wide interoperability the algorithms supported here follow [8] where fuller details can be found. 1. Public Key Algorithms - Implementations MUST implement DSA [23] for signatures and Elgamal for encryption. Implementations SHOULD implement RSA encryption [7]. 2. Symmetric Key Algorithm - Implementations MUST implement Triple-DES [24]. Implementations SHOULD implement IDEA and CAST5. Implementations MAY implement any other algorithm. 3. Compression Algorithms - Implementations MUST implement uncompressed data. Implementations SHOULD implement ZIP. 4. Hash Algorithms - Implementations MUST implement SHA-1 [26]. Implementations SHOULD implement MD5. 4. SIP Security with S/MIME Support for the use of the S/MIME message format is OPTIONAL in this specification. The Cryptographic Message Syntax (CMS) is derived from PKCS#7 [14] and is fully defined in [15]. This syntax is used here to digitally sign or encrypt SIP messages and describes an encapsulation syntax for data protection. The CMS values are generated using ASN.1 [12] using BER encoding [13] and values are generally represented as octet strings. CMS associates a protection content type with a protection content and has ASN.1 type ContentInfo: ContentInfo ::= SEQUENCE { ContentType ContentType, Content[0] EXPLICIT ANY DEFINED BY contentType } ContentType ::= OBJECT IDENTIFIER Kirstein et al. [PAGE 15] Internet Draft SIP Security March 12, 1998 ContentType indicates the type of protection content and is an Object Identifier. Six are defined in [15] but only Data, SignedData and EnvelopedData are of relevance to this document. Content is the actual protected content. Sending agents MUST use the "data" content type as the content within other content types to indicate the message content which has had security services applied to it. In addition sending agents MUST use the signedData content type to apply a digital signature to a message and an envelopedData type to encrypt a message. Further details of the specific requirements can be found in [9]. Prior to any security enhancements the SIP message is converted into MIME canonical format exactly as described in [20] and discussed in Section 3.2. When S/MIME formats are used then these are as defined in [9,15] where more complete details can be found. These documents are, in turn, based on RFC 1847 [10] and PKCS#7 [14]. 4.1 The application/pkcs7-mime Type The application/pkcs-7-mime type is used to carry CMS objects. This always carries a single CMS object which is the BER encoding of the ASN.1 syntax describing the object. The MIME headers of all application/pkcs-7-mime objects SHOULD include the optional "smime-type" parameters as described in [9]. 4.2 Encryption Only with S/MIME The SIP message, which has been converted to MIME canonical format, is processed into a CMS [15] object of type envelopedData. This is then inserted into an applicaton/pkcs7-mime entity. The smime-type parameter for enveloped-only messages is "enveloped-data" and the file extension for this type of message is ".p7m". A sample message would be: INVITE j.doe@acme.com SIP/2.1 From: John Smith To: J.Doe Call-ID: 554565 MIME-Version: 1.0 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V 4.3 Signing Only With S/MIME There are two possible formats for signed messages. One can either use application/pkcs7-mime and SignedData or multipart/signed. In general, the multipart/signed form is preferable for sending, and receiving Kirstein et al. [PAGE 16] Internet Draft SIP Security March 12, 1998 agents SHOULD be able to handle both. The receiver can always view messages signed using the multipart/signed format whether they have S/MIME software or not. A recipient cannot view messages signed using the signedData format unless they have S/MIME facilities. 4.3.1 Signing Using application/pkcs7-mime and SignedData This signing format uses the application/pkcs7-mime MIME type as above but now the MIME entity and other required data is processed into a CMS object of type signedData. This is then inserted into an application/pkcs7-mime MIME entity. The smime-type parameter for messages using application/pkcs7-mime and SignedData is "signed-data" and the file extension for this type of message is ".p7m". A sample message would be: INVITE j.doe@acme.com SIP/2.1 From: John Smith To: J.Doe Call-ID: 554565 MIME-Version: 1.0 Content-Type: application/pkcs7-mime; smime-type=signed-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 6YT64V0GhIGfHfQbnj75 4.3.2 Signing Using the multipart/signed Format This format is a clear-signing format and recipients with no S/MIME or PKCS processing facilities are able to view the message. It makes use of the multipart/signed MIME type described in RFC 1847 and the format is similar to the PGP signed-only SIP messages earlier. The multipart/signed MIME type has two parts. The first part contains the MIME entity that is to be signed; the second part contains the signature, which is a CMS detached signature. In order to create this type of message the SIP message is again converted to MIME canonical format as discussed in Section 3.2. This MIME entity is then processed to obtain a CMS object of type signedData with an empty contentInfo field. The MIME entity is then inserted into the first part of a multipart/signed message. Following this, transfer-encoding can, if desired, be applied to the detached signature and this is inserted into a MIME entity of type application/pkcs7-signature. This MIME entity is then inserted into the second part of the multipart/signed entity. The application/pkcs7-signature MIME type always contains a single CMS object of type signedData. The contentInfo field of the CMS object must be empty. The signerInfos field contains the signatures for the Kirstein et al. [PAGE 17] Internet Draft SIP Security March 12, 1998 MIME entity and the file extension for signed-only messages using application/pkcs7-signature is ".p7s". The multipart/signed content-type has two required parameters: the protocol parameter and the micalg parameter. The protocol parameter MUST be "application/pkcs7-signature". Note that quotation marks are required around the protocol parameter because MIME requires that the "/" character in the parameter value MUST be quoted. The micalg parameter allows for one-pass processing when the signature is being verified. The value of the micalg parameter is dependent on the message digest algorithm used in the calculation of the Message Integrity Check. The value of the micalg parameter SHOULD be one of the following: Algorithm: MD5 SHA-1 Value: md5 sha1 An example of a multipart/signed SIP Invitation would be: INVITE j.doe@acme.com SIP/2.1 From: Michael Elkins To: Michael Elkins CALL-ID: 786598 Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 --boundary42 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: quoted-printable > > INVITE j.doe@acme.com SIP/2.1 > To: J.Doe > From: Michael Elkins > Subject: Videoconference on security issues > CALL-ID: 786598 > > Content-Type: application/sdp > > v=0 > o=anybody 3098086191 3098086197 IN IP4 anycomputer.anywhere.com > s=general conference > i=This is a general conference > e=A. Nyone > p=A. Nyone +44 171 123 4567 > c=IN IP4 239.255.140.52/15 > t=3098084400 3098091600 > a=tool:sdr v2.5a0 > a=type:test > m=audio 19274 RTP/AVP 0 > c=IN IP4 239.255.140.52/15 > a=ptime:40 > Kirstein et al. [PAGE 18] Internet Draft SIP Security March 12, 1998 --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42-- The ">" indicate the data included in the signature. 4.4 Signing and Encrypting To achieve signing and encrypting, any of the signed-only and encrypted-only formats may be nested. This is allowed because the above formats are all MIME entities, and because they all secure MIME entities. A secure SIP implementation MUST be able to receive and process arbitrarily nested S/MIME within reasonable resource limits of the recipient computer. It is possible to either sign a message first, or to envelope the message first. It is up to the implementor and the user to choose. When signing first, the enveloping then securely obscures the signatories. When enveloping first the signatories are exposed, but it is possible to verify signatures without removing the enveloping. This may be useful in an environment where automatic signature verification is desired, as no private key material is required to verify a signature. 4.5 S/MIME Supported Algorithms In order to maintain wide interoperability the algorithms supported here follow [9] where fuller details can be found. 1. KeyEncryptionAlgorithmIdentifier Sending and receiving agents MUST support Diffie-Hellman defined in [22]. Receiving agents SHOULD support rsaEncryption [7]. Incoming encrypted messages contain symmetric keys which are to be decrypted with a user's private key. The size of the private key is determined during key generation. Sending agents SHOULD support rsaEncryption. Sending agents SHOULD support rsaEncryption encryption. If an agent supports rsaEncryption then it MUST support encryption of symmetric keys with RSA public keys at key sizes from 512 bits to 1024 bits. Kirstein et al. [PAGE 19] Internet Draft SIP Security March 12, 1998 2. SignatureAlgorithmIdentifier Sending and receiving agents MUST support id-dsa defined in [23]. The algorithm parameters MUST be absent (not encoded as NULL). Receiving agents SHOULD support rsaEncryption, defined in [7]. Receiving agents SHOULD support verification of signatures using RSA public key sizes from 512 bits to 1024 bits. Sending agents SHOULD support rsaEncryption. Outgoing messages are signed with a user's private key. 3. ContentEncryptionAlgorithmIdentifier Receiving agents MUST support encryption and decryption with DES EDE3 CBC [24]. Receiving agents SHOULD support encryption and decryption using the RC2 [25] or a compatible algorithm at a key size of 40 bits. 4. DigestAlgorithmIdentifier Receiving agents MUST support SHA-1 [26]. Receiving agents SHOULD support MD5 [27]. Sending agents SHOULD use SHA-1. Kirstein et al. [PAGE 20] Internet Draft SIP Security March 12, 1998 References [1] M.Handley "SAP: Session Announcement Protocol" Internet Draft: draft-ietf-mmusic-sap-00.txt, 27/Nov/96 [2] M. Handley, H. Schulzrinne and E. Schooler "SIP: Session Initiation Protocol" Internet Draft: draft-ietf-mmusic-sip-04.txt, Nov 97 [3] D. Crocker "Standard for the Format of ARPA Internet Text Messages" STD 11, RFC 822, University of Delaware, August 1982 [4] M. Handley and V. Jacobson "SDP: Session Description Protocol" Internet Draft: draft-ietf-mmusic-sdp-06.txt, Jan 97 [5] H. Schulzrinne, A. Rao and R. Lanphier "Real Time Streaming Protocol (RTSP)" IETF, Internet Draft, July 97 Work In Progress [6] A. Freier, P. Karlton and P. Kocher "The SSL Protocol: Version 3.0" Internet Draft: draft-ietf-tls-ssl-version3-00.txt, Nov 96 [7] R.L. Rivest, A. Shamir and L.M. Adleman "A Method for Obtaining Digital Signatures and Public Key Cryptosystems", Communications of the ACM, v. 21, n. 2, Feb 1978, pp 120-126 PKCS#1 "RSA Encryption Standard" RSA Laboratories, Version 1.5, Nov 1993 [8] J. Callas "OpenPGP Message Formats" Internet Draft: draft-ietf-openpgp-formats-00.txt, Nov 1998 [9] B. Ramsdell "S/MIME Version 3 Message Specification" Internet Draft: draft-ietf-smime-msg-01.txt, Jan 1998 [10] J. Galvin et al "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted" Technical Report RFC 1847, IETF, Oct 1995 [11] M. Elkins "MIME Security With Pretty Good Privacy" Technical Report RFC 2015, IETF, Oct 1996 [12] X.208 "Specification of Abstract Syntax Notation One (ASN.1)" ITU-T Recommendations, 1988 [13] X.209 "BER: Basic Encoding Rules for ASN.1" ITU-T Recommendations, 1988 [14] PKCS#7 "Cryptographic Message Syntax Standard" RSA Laboratories, Version 1.5, Nov 1993 Kirstein et al. [PAGE 21] Internet Draft SIP Security March 12, 1998 [15] R. Housley "Cryptographic Message Syntax" Internet Draft: draft-ietf-smime-cms-03.txt, Jan 1998 [16] Fielding et al "Hypetext transfer Protocol - HTTP/1.1" Technical Report RFC 2068, IETF, Jan 1997 [17] D. Crocker "Augmented BNF for Syntax Specifications: ABNF" IETF, Internet Draft, Oct 1996, Work In Progress [18] J. C. Mogul and S. E. Deering "Path MTU Discovery" Technical Report RFC 1191, IETF, Nov 1990 [19] W. R. Stevens "TCP/IP Illustrated: The Protocols" Vol 1, Reading, Massachusetts. Pub: Addison-Wesley, 1994 [20] N. Freed and N. Borenstein "MIME: Part One. Format of internet Message Bodies" Technical Report RFC 2045, IETF, Nov 1996 N. Freed and N. Borenstein "MIME: Part Two. Media Types" Technical Report RFC 2046, IETF, Nov 1996 K. Moore "MIME: Part Three. Message header Extensions for Non-ASCII Text" Technical Report RFC 2047, IETF, Nov 1996 N. Freed et al "MIME: Part Four. Registration Procedures" Technical Report RFC 2048, IETF, Nov 1996 N. Freed and N. Borenstein "MIME: Part Five. Conformance Criteria and Examples" Technical Report RFC 2049, IETF, Nov 1996 [21] Character sets assigned by IANA. See [22] ANSI X9.42 [23] ANSI X9.57-1997x, "Public Key Cryptography for the Financial Services Industry: Certificate Management". Working Draft, June 1996 [24] ANSI X3.106 "American National Standards for Information Systems - Data Link Encryption" American National Standards Institute, 1983 (DES) W. Tuchman "Hellman Presents No Shortcuts Solutions to DES" IEEE Spectrum, v16, n7, pp40-41, July 1979 [25] R.L. Rivest et al "Description of the RC2 Encryption Algorithm" Internet Draft: draft-rivest-rc2desc-01.txt Kirstein et al. [PAGE 23] Internet Draft SIP Security March 12, 1998 [26] NIST FIPS PUB 180-1 "Secure Hash Standard" National Institute of Standards and Technology, U.S. Dept. of Commerce, DRAFT, May 1994 [27] R. L. Rivest "The MD5 Message Digest Algorithm" Technical Report RFC 1321, IETF, April 1992 [28] Bradner "Key words for use in RFCs to indicate Requirement Level" Technical Report RFC 2119, IETF, March 1997 Authors' Addresses Peter Kirstein, Goli Montasser Kohsari and Edmund Whelan are at University College London and their contact details are: P.Kirstein@cs.ucl.ac.uk Tel: +44 171 380 7286 G.Montasser-Kohsari@cs.ucl.ac.uk Tel: +44 171 380 7215 E.Whelan@cs.ucl.ac.uk Tel: +44 171 419 3688 Dept of Computer Science Fax: +44 171 387 1397 University College London Gower Street London WC1E 6BT England Acknowledgements The European Commission, under the Telematics 1007 "MERCI" project and the Telematics 1005 "ICE-TEL" project, funded the design of SIP Security. Mark Handely, Henning Schulzrinne and Eve Schooler developed the original SIP draft. Kirstein et al. [PAGE 24]