SIP Working Group V. Gurbani Internet-Draft Bell Laboratories, Alcatel-Lucent Intended status: Standards Track F. Audet Expires: December 15, 2007 Nortel Networks D. Willis June 13, 2007 The SIPSEC Uniform Resource Identifier (URI) draft-gurbani-sip-sipsec-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 15, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Currently, in the Session Initiation Protocol (SIP), there does not exist any means for a user agent client (UAC) to signal to the destination user agent server (UAS) that an end-to-end secure channel is to be established. Instead, what is prevalent today in the protocol is a hop-by-hop security model, wherein intermediaries forward a request towards the destination without the UAC knowing Gurbani, et al. Expires December 15, 2007 [Page 1] Internet-Draft The SIPSEC URI June 2007 whether or not the intermediary behaved in a trusted manner (i.e., it did not, unknown to the UAC, downgrade the security of the downstream channel from the intermediary onwards). This document discusses the security properties of a hop-by-hop model; and in doing so, formulates requirements an for an end-to-end security model and a solution that satisfies these requirements. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Current SIP Security Model . . . . . . . . . . . . . . . . 4 4. Requirements for End-to-End Security . . . . . . . . . . . . . 5 5. Lessons Learned from Other Protocols . . . . . . . . . . . . . 6 6. Securing SIP signaling End to End . . . . . . . . . . . . . . 6 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. URI Format . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. The CONNECT method . . . . . . . . . . . . . . . . . . . . 10 6.4. UAC behavior . . . . . . . . . . . . . . . . . . . . . . . 11 6.5. UAS behavior . . . . . . . . . . . . . . . . . . . . . . . 11 6.6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . 12 6.7. Example call flow . . . . . . . . . . . . . . . . . . . . 12 6.8. Adherence to requirements . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 8.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. CONNECT request . . . . . . . . . . . . . . . . . . . . . 16 8.3. Option tag . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informational References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Gurbani, et al. Expires December 15, 2007 [Page 2] Internet-Draft The SIPSEC URI June 2007 1. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. 2. Introduction Intermediaries (proxy servers) play a big role in the routing of SIP requests [2]. Often times this is due to the network realities of today: in many deployments, firewalls and network address translators (NAT) prevent two endpoints from communicating directly with one other. At other times, intermediaries are mandatory due to the underlying characteristic of the network that requires a request to traverse through a set of intermediaries as it is routed towards its destination. Traditionally, proxies have been trusted in SIP. User agents trust their proxies to provide the rendezvous service with the recipient, but this trust does not extend to include proxies being privy to sensitive information contained in the signaling messages. Since there may be a number of proxies between a UAC and a UAS, if the signaling information was to travel in the clear across this proxy mesh, then sensitive information in signaling (user identities, master keys for media encryption, etc.) is available to all the intermediaries that aid in the routing of that request. In fact, if the signaling session consisted entirely of, say, text messages for the Instant Message service (IM) in SIP [14], the intermediary proxies will have full access to the contents of the IM session, possibly violating the privacy of the users. While the endpoints may trust the proxies responsible for their domain, this trust may not extend to other proxies, and in fact, the endpoints trust the proxies in their domain and in other domains just enough to route the request towards the recipient. The question of trust is most relevant in P2PSIP [18], where there is very limited recourse, if any, against a malicious node that betrays this trust. From the viewpoint of the user agent client, two security properties are essential when establishing a session: one, it should be able to authenticate the recipient directly, and two, it should be assured of the privacy of communications across all the intermediaries that participate in getting the request to the destination. However, these are violated when proxies are used. Since direct communication with the recipient may not be possible due to NATs, proxies must be Gurbani, et al. Expires December 15, 2007 [Page 3] Internet-Draft The SIPSEC URI June 2007 used. Hence, a client cannot authenticate the recipient directly, and furthermore, it has to trust that the proxy does not violate privacy by snooping into and saving information from the signaling headers traversing through it. This document explores how to provide end-to-end security outlined in the above paragraph in SIP. We start by first by deriving a list of requirements and then tracking these towards a possible solution. 3. The Current SIP Security Model To be sure, SIP has the notion of providing confidentiality, integrity, and peer authentication to the signaling data flowing through the intermediaries. Four techniques exist to provide these properties, though not all of the techniques provide all of the properties simultaneously. The first mechanism is the use of the SIPS scheme. This mechanism provides confidentiality, message integrity, although authentication is not end-to-end, but rather hop-by-hop. SIPS uses Transport Layer Security (TLS [5] [6]) on each hop from the UAC to the proxy serving the domain of the UAS (from then onwards, the protocol leaves the protection of the "last hop" up to the proxy responsible for that hop. The understanding is that the proxy should provide at least the same level of security to this traffic as was accorded to it over the link that deposited the traffic to the proxy.) There are a number of areas in RFC3261 where the use of the SIPS scheme is left ambiguous. Audet [17] catalogues these areas and provides clarifications and normative changes to [2] wherever appropriate. The ambiguities in RFC3261 on SIPS notwithstanding, recent SIP interoperability events have witnessed a surge of TLS implementations (at the 18th SIP interoperability event held in April 2006, 30 out of 73 implementations supported TLS). A rather insidious characteristic of SIPS is that the entire system depends on the proper functioning of intermediaries. It is not end- to-end, but rather, hop-by-hop and implies transitive trust. Furthermore, even if a proxy chain accords TLS protection on its every hop, all proxies in that chain have access to the plaintext signaling information as it traverses through that proxy. For some uses of SIP, this may preclude sending keying information for Secure Real-Time Protocol (SRTP [3]) in signaling, even if the signaling is protected by TLS across every hop. A second mechanism to provide confidentiality and peer verification in SIP is the use of Secure/Multipurpose Internet Mail Extensions Gurbani, et al. Expires December 15, 2007 [Page 4] Internet-Draft The SIPSEC URI June 2007 (S/MIME [11]). S/MIME provides confidentiality, end-to-end peer verification, and integrity of the S/MIME body only. However, operationally S/MIME has proved to be quite hard to deploy (not all users possess certificates rooted in a trusted certificate authority), and programmatically, it has proved equally hard to implement (at the same SIP interoperability event, there weren't any S/MIME implementations). Another drawback of S/MIME has also been that it sends some of the headers in cleartext. Unfortunately, this is unavoidable as the intermediaries need these headers to perform routing functions. A third mechanism, Authenticated Identity Body (AIB [13]), provides integrity and authentication properties to the endpoints (it can optionally provide confidentiality as well). AIB suffers from much the same drawbacks as S/MIME, however. And finally, SIP Identity [15] exists to provide authentication of the sender of the request and integrity of portions of the message body. Because SIP Identity relies on domain certificates instead of end-user certificates, it does not suffer from the same drawbacks as S/MIME does. 4. Requirements for End-to-End Security We now list the requirements that an end-to-end SIP security mechanism should provide. The first requirement is rather tongue in cheek, but was widely discussed on the SIP mailing list as the infamous "hopping bunny with a lock in its mouth" requirement. This requirement allegorically depicts the state of security in SIP today with SIPS scheme, namely that SIPS provides hop-by-hop security and even then, there is no privacy or guards against eavesdropping since the intermediaries have access to the cleartext signaling. It appears that the Hypertext Transfer Protocol (HTTP [7]) has trained the users of the technology to associate a locked padlock with a secure connection. While this may be appropriate for HTTP, it is not appropriate for SIP since the SIPS scheme depends on the intermediaries to not behave maliciously (surreptitiously save the data flowing through them), and the characteristics of SIP are such that both the signaling layer, and the media layer established by that signaling must be confidential. o REQ 1 - Stop the bunny from hopping :-) o REQ 2 - Signaling must be confidential from intermediaries, even if the intermediaries are used to route the request towards the destination. Gurbani, et al. Expires December 15, 2007 [Page 5] Internet-Draft The SIPSEC URI June 2007 o REQ 3 - A new URI scheme may be proposed that has the properties of confidentiality of signaling and media in an end to end manner. User agents using this new scheme, and intermediaries handling this new scheme will then have the adequate expectations of the session being set up. These expectations are that the caller is connected to the intended party and the confidentiality of the signaling and media is assured as well. 5. Lessons Learned from Other Protocols The IETF has successfully added security to other protocols such as HTTP and Simple Mail Transport Protocol (SMTP [8]) after the protocol was specified. It helps to look at these cases to determine whether we can use the same or similar ideas in applying end to end security in SIP. RFC 2818 [9] secures HTTP through the use of a new URI scheme - HTTPS. The analogous scheme in SIP is SIPS. RFC 2817 [10], on the other hand, secures HTTP in a manner that can be used a model to secure SIP data end-to-end, with intermediaries aiding in routing the request. In HTTP, there may be one or more proxy between the browser and the origin server. When end-to-end security is desired, the browser establishes a TCP tunnel between itself and the origin server, through the proxies. Once the TCP tunnel is established, the browser and the origin server perform a TLS handshake to exchange X.509 certificates, agree on a set of algorithms, and establish a set of cryptographic keys. Subsequent data between them is encrypted and carried over the tunnel established by the proxies. Even though the proxies transport the data, they cannot decrypt it or perform any analysis on it. RFC 3207 [12] specifies the STARTTLS service, which negotiates a TLS connection once a TCP connection has been set up between a SMTP client and an SMTP server. 6. Securing SIP signaling End to End This document proposes a mechanism similar to the HTTP-tunneling mechanism to establish an end-to-end secure overlay transport path across a set of SIP proxies. We first explain the mechanism itself, including the SIP extensions that are needed to realize it, and then look at how the mechanism fulfills the requirements listed in Section 4. Gurbani, et al. Expires December 15, 2007 [Page 6] Internet-Draft The SIPSEC URI June 2007 6.1. Overview This subsection contains an example flow of an end-to-end secure session using the "sipsec" URI scheme (see Section 6.2). Figure 1 shows an overall time-line diagram of using the "sipsec" URI scheme to establish a communication with the destination UAS through a mesh of intermediaries. UAC Proxy 1 Proxy 2 UAS | | | | +-----------+ | | |TCP hand- | | | |shake | | | +-----------+ | | | | | | |CONNECT | | | +-----------> | | | +------------+ | | |TCP hand- | | | |shake | | | +------------+ | | | | | | |CONNECT | | | +----------->| | | | | | | | +------------+ | | |TCP hand- | | | |shake | | | +------------+ | | | | | | |CONNECT | | | +----------->| | | | 200 OK | | | 200 OK |<-----------+ | 200 OK |<-----------+ | |<----------+ | | ... ... ... ... Figure 1: Initial rendezvous The UAC, on being presented with a sipsec URI, creates a request with a method of CONNECT. This request has a R-URI of the destination UAS. The request is routed downstream as specified in [2]. The transport used for the request on each hop must be a connection- oriented, congestion-controlled transport; in this example, it is TCP. When the UAS receives the request, it denotes its desire to establish a session with the sender using a 200-class response to the CONNECT request. This response is sent back over the same transport Gurbani, et al. Expires December 15, 2007 [Page 7] Internet-Draft The SIPSEC URI June 2007 that the request arrives on. This specification does not prohibit nor does it explicitly mandate a set of headers to appear in the CONNECT request. Thus, the sender can add any legal SIP header (such as a From) to the request. The desire for privacy may drive the inclusion (or exclusion) of certain headers when the UAC creates a request. Similarly, intermediaries can challenge the CONNECT request or add any header pertinent to their operation if it is permitted by SIP. Section 6.3 contains normative text on the use of the CONNECT request. Once this rendezvous has been made, the intermediaries put themselves into a "transparent" mode. While in this mode, any data they receive from their upstream neighbor will be sent to the downstream neighbor, and any data received from the downstream neighbor will be sent to the upstream neighbor. Figure 2 depicts the situation after the rendezvous is complete. Here, the UAC and the UAS upgrade the connection to use TLS; X.509 certificates are exchanged and encryption keys are derived. The certificates enable both the end points to identify themselves to other and the encryption keys allow the subsequent application data to be rendered opaque to the intermediaries. Gurbani, et al. Expires December 15, 2007 [Page 8] Internet-Draft The SIPSEC URI June 2007 UAC Proxy 1 Proxy 2 UAS | | | | +-----------+------------+------------+ | TLS exchange (client hello, server | | hello, certificate exchange, cipher | | negotiation) | +-----------+------------+------------+ | | | | +-----------+------------+------------+ | Session setup signaling data | +-----------+------------+------------+ | | | | +-----------+------------+------------+ | Session-specific data | +-----------+------------+------------+ ... ... ... ... +-----------+------------+------------+ | TLS shutdown | +-----------+------------+------------+ | | | | +-----------+ | | | TCP shut- | | | | down | | | +-----------+------------+ | | | TCP shut- | | | | down | | | +------------+------------+ | | | TCP shut- | | | | down | | | +------------+ | | | | V V V V Figure 2: Upgrading to a secure connection When the connection is no longer needed, either of the end points can issue a TLS shutdown. This shutdown will be followed by a per- hop TCP disconnect. 6.2. URI Format End to end secure SIP is differentiated from hop-by-hop secure SIP (SIPS URI) by using the "sipsec" protocol scheme identifier in place of the "sips" protocol scheme identifier. An example URI specifying the need for an end-to-end secure SIP is: Gurbani, et al. Expires December 15, 2007 [Page 9] Internet-Draft The SIPSEC URI June 2007 sipsec:vkg@example.com However, it is not expected that the sipsec URI scheme will be serialized on the wire; instead, the semantics accorded to it are in the same vein as a mailto URI wherein a browser, on seeing the mailto URI presents a mail client to the user. Similarly, a SIP user agent on being presented a sipsec URI MUST formulate a SIP CONNECT request Section 6.3 with a SIP or SIPS URI scheme. The SIP user agent MUST also insert the "sipsec" option tag in the Proxy-Require and Require header. The normative behavior of intermediaries, user agent clients and user agent servers on encountering this option tag is presented in subsequent sections of this document. 6.3. The CONNECT method This document requests the IANA to register a new SIP request method called CONNECT. The CONNECT method and its corresponding 200-class response is used by user agents to indicate the desire of an end-to- end secure session. Tables 1 and 2 below extend Tables 2 and 3, respectively, from [2]. TO DO: Provide Tables 1 and 2. At the minimum, this specification requires a request with a CONNECT method MUST contain the Request-Line, Proxy-Require header, Require header and CRLF as defined in the ABNF of [2]. The Proxy-Require and Require headers MUST contain the option tag "sipsec". Any other SIP headers or body types are permissible if they are allowed by the protocol and if the UAC sending the request wishes to use them. Under some circumstances, a UAC may not wish to divulge any other information about itself beyond the fact that a CONNECT request was made to a certain UAS. If the request is successfully answered, the rest of the signaling messages will be encrypted end to end. Thus, an intermediary will know that a CONNECT request was established, but what transpired after that remains private. The CONNECT request, like any other SIP request, may be challenged by a proxy upon which the user will have to provide appropriate credentials. Similarly, if the user already possesses a X.509 certificate, it may use TLS to establish a connection with the proxy. At the minimum, this specification requires that a response to a CONNECT request MUST contain the Status-Line and CRLF as defined in the ABNF of [2]. Any other SIP headers or body types are permissible if they are allowed by the protocol and if the UAS sending the response wishes to use them. Privacy concerns outlined above to requests apply to responses as well. Gurbani, et al. Expires December 15, 2007 [Page 10] Internet-Draft The SIPSEC URI June 2007 6.4. UAC behavior A UAC that wishes to use end-to-end encryption MUST first formulate a new request with the method name CONNECT. The Request-URI (R-URI) scheme MAY be left as a SIP URI or it may be a SIPS URI. Regardless, no other information is required for the CONNECT request. The CONNECT request SHOULD NOT contain a payload. For some communications, the caller may not want to reveal any private information at all. The CONNECT request may travel in the clear across a list of proxies until it arrives at the intended destination identified in the R-URI. Thus, limiting the amount of information available to intermediaries is a good strategy. Of course, if a UAC has no compunctions on revealing private information, then it may add any kind of information that it wants to make available to the receiving endpoint, and by extension, to each of the intermediaries fielding this request. The UAC MUST include a Proxy-Require and a Require header in the CONNECT request with an option tag value of "sipsec". When a corresponding 200-class response arrives for the CONNECT request, the UAC can start the TLS handshake, and once the handshake is done, actual data can follow. The handshake and data will traverse over the overlay TCP network established by the intermediaries, however, since the encryption keys were exchanged end-to-end, the intermediaries will not be able to eavesdrop on the communications. The data in this case consists of another SIP request that sets up the actual communication channel between the UAC and the UAS. However, before sending this new SIP request, the UAC MUST examine the X.509 certificate presented to it during the handshake to determine the veracity of the UAS. If the UAC does not trust the identity of the UAS based on the information contained in the certificate, it MUST present this information to the user associated with the UAC and allow it to make a decision on whether to continue with the connection or to abort the attempt. 6.5. UAS behavior A UAS that wishes to use end-to-end encryption should inspect an incoming CONNECT request for a Require header field containing an option value of "sipsec". If such a header is found, and the UAS is willing to enter a communication session with the sender (at this point, the UAS may not know who the sender is), it MUST send a 200- class response to the CONNECT and prepare to accept a TLS handshake from the sender. Gurbani, et al. Expires December 15, 2007 [Page 11] Internet-Draft The SIPSEC URI June 2007 To ascertain the identity of the sender of the request, the UAS MUST configure its TLS library such that it asks for an X.509 certificate from the sender during the TLS handshake. All commonly used TLS libraries allow the server to ask the client of its certificate during the initial handshake (for example, in the OpenSSL library, the SSL_VERIFY_PEER flag can be set for for the server SSL context; when this flag is set, the server will ask the client for its certificate.) If the UAS does not trust the sender of the CONNECT request based on the identity contained in the certificate, it MUST present this information to the user associated with the UAS and allow it to make a decision on whether to continue with the connection or to abort the attempt. If the connection setup continues, the UAS MUST be prepared to receive a SIP request that will indicate the type of communications the sender wishes to set up. 6.6. Proxy behavior A proxy, on the receipt of a new CONNECT request must inspect the Proxy-Require header field and if it contains the option tag "sipsec" then the proxy MUST route the request downstream as specified in [2]. Upon receiving a corresponding 200-class response to the request, the proxy MUST send the response upstream as specified in [2]. Then, it MUST leave the TCP connection over which the request and response traversed open, and prepare to enter into a mode where it forwards the data arriving on this connection from the sender to the receiver. Because the data arriving on this connection after the 200 OK has been sent upstream may be encrypted, the proxy will not be able to interpret it. However, it MUST keep the TCP connection open until the connection is explicitly torn down by either of the endpoints. In extreme conditions, if the proxy has not observed any data on this connection for some time period (configurable per proxy with a minimum default value of 1800s MUST be used), it MAY actively shut down the TCP connection. TODO: Clarify interaction with SIP Session Timer [16]. 6.7. Example call flow A representative call flow diagram is provided in Figure 3 below. Gurbani, et al. Expires December 15, 2007 [Page 12] Internet-Draft The SIPSEC URI June 2007 UAC P1 P2 UAS | | | | | | | | | | | | |(1) CONNECT | | | |-------------->| | | | |(2) CONNECT | | | |-------------->| | | | |(3) CONNECT | | | |-------------->| | | |(4) 200 OK | | | |<--------------| | |(5) 200 OK | | | |<--------------| | | |(6) goes transparent | | | | | |(7) 200 OK | | | |<--------------| | | | |(8) goes transparent | | | | | |(9) Tunnel established spanning P1 and P2 | |...............................................| |(10) TLS Handshake | | |---------------------------------------------->| |(11) TLS handshake | | |<----------------------------------------------| |(12) evaluates cert | | | | | | |(13) makes trust decisions | | | | | | | | | |(14) evaluates | | | | cert | | | |(15) makes trust | | | | decision |(16) INVITE | | | |---------------------------------------------->| | | | |(17) more trust | | | | decision |(18) 200 OK | | | |<----------------------------------------------| |(19) ACK | | | |---------------------------------------------->| | | | | | | | | Figure 3: Example call flow In this call flow, the UAC negotiates a path to the UAS through two Gurbani, et al. Expires December 15, 2007 [Page 13] Internet-Draft The SIPSEC URI June 2007 proxies, P1 and P2 (steps 1 - 3). After the UAS has been contacted and has acquiesced to communication (step 4), the intervening proxies put themselves in cryptographically transparent mode (steps 6 and 8) and essentially establish a virtual transport path (a tunnel) from the UAC to the UAS going through the proxies (step 9). The proxies, while in this mode, will receive data -- which to them is simply an opaque sequence of bytes -- on one side of the transport connection and send it to the other side. On the establishment of this tunnel, the UAC initiates a TLS handshake directly to the UAS (step 10). The UAS responds with its certificate and the keying material for confidentiality is derived, and the endpoints are authenticated as per the properties of the certificates exchanged (i.e., a self- signed certificate may be validated through a fingerprint exchanged between the UAS and the UAC some time before, or a certificate signed by a trusted third party is verified by following the trust chain.) For mutual authentication, both sides of the virtual connection must provide X.509 certificates (steps 11-15). After the tunnel has been authenticated and keying material derived to secure the confidentiality, application layer messaging follows between the UAC and UAS (steps 16, 18, 19.) In Figure 3, the application layer messaging is composed of the INVITE transaction. Note that once the request has been sent to the UAS, the UAS may have to undertake more trust decision based on the nature of signaling (for example, a user associated with the UAC may want to subscribe to some resource of a user associated with a UAS, but the user of the UAS does not want information for that resource disseminated to the UAC despite the fact that the user associated with the UAC has been authenticated. In other words, once the identities of the endpoints have been asserted and the confidentiality of the channel protected, application-specific trust decision may still be made.) 6.8. Adherence to requirements In this section, we evaluate the sipsec URI scheme to the requirements we captured in Section 4. o REQ 1 - Stop the bunny from hopping :-) 'Nuff said. o REQ 2 - Signaling must be confidential from intermediaries, even if the intermediaries are used to route the request towards the destination. This requirement is met as depicted in Figure 2. o REQ 3 - A new URI scheme may be proposed that has the properties of confidentiality of signaling and media in an end to end manner. User agents using this new scheme, and intermediaries handling this new scheme will then have the adequate expectations of the session being set up. These expectations are that the caller is Gurbani, et al. Expires December 15, 2007 [Page 14] Internet-Draft The SIPSEC URI June 2007 connected to the intended party and the confidentiality of the signaling and media is assured as well. This requirement has been met with the introduction of the "sipsec" URI scheme (see Section 6.2). 7. Security Considerations Even though this entire draft pertains to security in general, the manner by which certain components are employed to provide the end- to-end security bears some more scrutiny. The initial request to establish an end-to-end tunnel -- the CONNECT request -- requires the R-URI of the recipient to be provided for routing purposes. Thus, at the very least, the identity (or one of the identities) of the recipient is conceivably divulged. The scheme described in this document does depend on X.509 certificates. In not all of the instances will user agents have such a certificate rooted in a trusted hierarchy and issued by a trusted certificate authority. In some cases, user agents may use self- signed certificates. However, even the use of self-signed certificates provides confidentiality for endpoint communication across a set of proxies that would not otherwise exist. A self- signed certificate cannot possibly be used for authoritative authentication unless both parties have exchanged certificate fingerprints a-priori over another channel (face-to-face meeting, postal service, email, etc.) 8. IANA considerations IANA considerations for registering a new URI scheme, a new SIP method, and a new SIP option tag are provided in the subsequent subsections, respectively. 8.1. URI Scheme Following the directions of [4], the following template is provided to register the URI scheme: URI scheme name: sipsec Status: permanent Gurbani, et al. Expires December 15, 2007 [Page 15] Internet-Draft The SIPSEC URI June 2007 URI scheme syntax: SIPSEC-URI = "sipsec:" [ userinfo ] hostport uri-parameters [ headers ] userinfo, hostport, uri-parameters, and headers production rules are defined in [2]. URI scheme semantics: See Section 6.2. Encoding considerations: There are no special encoding considerations. Applications/protocols that use this URI scheme name: SIP Interoperability considerations: A SIP user agent client, when presented with this scheme, will process it as described in this document; if it does not support the scheme, will display a "416 Unsupported URI scheme" to its user. Intermediary and endpoint support is indicated by the presence of a new option tag being registered by this document. Security considerations: See Section 7 Contact: Vijay K. Gurbani, vkg at acm.org Author/Change controller: The IESG. References: None beyond what are specified in this document. 8.2. CONNECT request This document requests IANA to register the new SIP method CONNECT at the SIP Registry (http://www.iana.org/assignments/sip-parameters) as follows Methods Reference --------- --------- CONNECT [RFCXXXX] RFC Editor: Please replace RFCXXXX with the number assigned to this document. Gurbani, et al. Expires December 15, 2007 [Page 16] Internet-Draft The SIPSEC URI June 2007 8.3. Option tag This document requests IANA to register the option tag "sipsec" at the SIP Registry (http://www.iana.org/assignments/sip-parameters) as follows Name Description Reference ---------------------------------------------------- sipsec This option tag is for indicating [RFCXXXX] support for an end-to-end X.509 certificate exchange in SIP to provide confidentiality and authentication. RFC Editor: Please replace RFCXXXX with the number assigned to this document. An example of the use of this tag is below: Proxy-Require: sipsec or Require: sipsec This tag is used in the Require and Proxy-Require headers. 9. Acknowledgments The following people contributed immensely to the discussion on the SIP working group mailing list: Jeroen van Bemmel (suggested using "SIPSEC" as the name for the URI scheme as opposed to the originally envisoned name of "SIPSS"), Michael Hammer (suggested the "hopping bunny" allegory), Juha Heinanen, Christer Holmberg, Alan Jeffrey, Cullen Jennings, Paul Kyzivat, Rohan Mahy, Frank Miller, Aki Niemi, Brian Rosen, Jonathan Rosenberg, Michael Thomas, and Dale Worley. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Gurbani, et al. Expires December 15, 2007 [Page 17] Internet-Draft The SIPSEC URI June 2007 [3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [4] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 115, RFC 4395, February 2006. 10.2. Informational References [5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [6] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [8] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [9] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [10] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. [11] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [12] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. [13] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004. [14] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [15] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [16] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005. Gurbani, et al. Expires December 15, 2007 [Page 18] Internet-Draft The SIPSEC URI June 2007 [17] Audet, F., "The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", draft-ietf-sip-sips-04 (work in progress), May 2007. [18] Willis, D., "Concepts and Terminology for Peer to Peer SIP", draft-willis-p2psip-concepts-04 (work in progress), March 2007. Authors' Addresses Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane Rm 9F-546 Lisle, IL 60532 USA Phone: +1 630 224 0216 Email: vkg@alcatel-lucent.com Francois Audet Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 408 495 2456 Email: audet@nortel.com Dean Willis Email: dean.willis@softarmor.com Gurbani, et al. Expires December 15, 2007 [Page 19] Internet-Draft The SIPSEC URI June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Gurbani, et al. Expires December 15, 2007 [Page 20]