SIPPING Working Group V. Gurbani, Ed. Internet-Draft Lucent Technologies, Inc./Bell Expires: December 20, 2006 Laboratories F. Audet Nortel Networks D. Willis Cisco Systems June 18, 2006 The SIPSEC Uniform Resource Identifier (URI) draft-gurbani-sip-sipsec-00.txt 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 20, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 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 prevelant today in the Gurbani, et al. Expires December 20, 2006 [Page 1] Internet-Draft The SIPSEC URI June 2006 protocol is a hop-by-hop security model, wherein intermediaries forward a request towards the destination without the UAC knowing 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 some requirements an for an end-to-end model to help drive a solution. 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. A Possible Solution? . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1 Normative References . . . . . . . . . . . . . . . . . . 8 10.2 Informational References . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . 11 Gurbani, et al. Expires December 20, 2006 [Page 2] Internet-Draft The SIPSEC URI June 2006 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. 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, intermediaries have been trusted in SIP. They do provide important services to the endpoints -- location lookup, forking, aggregating responses, transport conversion, to name a few. However, under certain circumstances, a UAC may want to use the services of the intermediaries to rendezvous with a UAS, but once that is done, the UAC would like to directly authenticate the UAS (and vice versa) to establish a secure channel between them over the overlay network created by the intermediaries. The data flowing through the overlay network is opaque to the intermediaries themselves, and can only be decrypted and understood by the endpoints. This is currently not possible with SIP. This document explores whether it is feasible to provide the type of security outlined in the above paragraph in SIP. The security thus provided must be applicable to both the signaling layer as well as the media layer. We start by first by enunciating a list of requirements and then tracking these towards a possible solution. It is important to keep in mind that certain constructs used in security protocols today -- X.509 certificates, for instance -- are a challenge to apply in acheiving endpoint security in SIP since more often than not, endpoints do not possess a X.509 certificate signed by a well-known certificate authority (proxy servers may have one). For that matter, the use of dynamic IP address assignment to endpoints make it harder for the endpoint to maintain a single long- lived certificate with a fixed subjectAltName (SAN) issued by a well known certificate authority. Gurbani, et al. Expires December 20, 2006 [Page 3] Internet-Draft The SIPSEC URI June 2006 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 [6] [7]) 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" upto 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). The drawbacks to the use of the SIPS scheme are quite a few and are documented in [15]. Despite these, recent SIP interoperability events have witnessed a surge of TLS implementations, thus it seems that some aspects of TLS in SIP are well understood by the development community (at the 18th SIP interoperability event held in April 2006, 30 out of 73 implementations supported TLS). A rather insidious drawback of SIPS is that the entire system depends on the proper functioning of intermediaries. That is, there isn't any feedback provided to the UAC if the intermediary decides -- maliciously or otherwise -- to downgrade the SIPS scheme to a SIP scheme. Alternatively, just because a UAS receives a request with a SIPS scheme in the Request URI (R-URI), it cannot assume that the request was handled using TLS at every hop; some intermediary may have upgraded the request to SIPS, thus only enabling confidentiality from that intermediary onwards. Furthermore, even if a proxy chain accords TLS protection on its every hop, all proxies in that chain are capable of eavesdropping on the information being sent across the chain. For some uses of SIP, this may preclude sending keying information for Secure Real-Time Protocol (SRTP [4]) 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 (S/MIME [12]). 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 Gurbani, et al. Expires December 20, 2006 [Page 4] Internet-Draft The SIPSEC URI June 2006 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 [14]), 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 [16] 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 [8]) has trained the users of the technology to associate a locked padlock with a secure connection. While this works for HTTP (we will see later why), it is not a good substitue 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. o REQ 3 - Keying material exchanged during signaling must be confidential from intermediaries as well. o REQ 4 - 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. Gurbani, et al. Expires December 20, 2006 [Page 5] Internet-Draft The SIPSEC URI June 2006 5. Lessons Learned from Other Protocols The IETF has successfully added security to other protocols such as HTTP and Simple Mail Transport Protocol (SMTP [9]) 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 [10] secures HTTP through the use of a new URI scheme - HTTPS. The analogous scheme in SIP is SIPS, but we have already witnessed the drawbacks associated with this scheme. RFC 2817 [11], on the other hand, secures HTTP in a manner that is much more amenable to how SIP operates today with intermediaries aiding in routing the request. In HTTP, cryptotransparency across intermediaries is obtained by upgrading a normal TCP connection from browser to origin server through proxies to use TLS once a tunnel is set up. After the the tunnel is established, an upgrade is requested and the X.509 certificates are exchanged and ciphers negotiated directly between the browser and the origin server. RFC 3207 [13] 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. A Possible Solution? So, it seems that a mechanism analogous to the two described above may be of help in providing end-to-end confidentiality despite the use of intermediaries. An option is to use a new scheme, call it the SIPSEC URI scheme, to create a confidential channel on top of the overlay network established in the form of TCP connections across a set of intermediaries in SIP. Using the SIPSEC scheme, once a destination UAS is reached through the web of intermediaries, the TCP connection is upgraded and certificates exchanged end-to-end to validate the peers and negotiate ciphers for encryption. Once the secure channel is established, sensitive information such as SIP messages may be freely exchanged over this channel to aid in securing the media as well. However, no solution is perfect. There will remain a core set of issues that must be addressed with the SIPSEC URI scheme. These are: 1. As suggested by the experience with S/MIME, not all most endpoints (and in fact, most users) do not possess X.509 certificates. If a certificate that is rooted in a mutually shared certificate authority does not exist, how can the identity of the endpoint (or user) be established? A particular Gurbani, et al. Expires December 20, 2006 [Page 6] Internet-Draft The SIPSEC URI June 2006 solution may involve using domain certificates to assert the identity [16] of the request originator, and then use self- signed certificates for the subsequent exchange. 2. In HTTP, RFC 2817 works because HTTP clients (browsers) are typically not expected to have certificates. In most HTTP transactions, the browser attempts to verify the authenticity of the server; in some cases where the browser authenticity needs to be established, HTTP Digest is used. However, real-time multimedia communication is much different than accessing content on the Internet. Both sides of the session must know that they are conversing with the right party -- or alternatively, be sure that they are not conversing with a malicious party -- for the session to be successfully established. As before, using SIP Identity [16] and self-signed certificates may be a solution to this problem. 3. How does the SIPSEC URI work when services such as forking are triggered (mandate that SIPSEC URIs do not fork?) 4. How does retargetting affect the SIPSEC URI? The answer to this seems simple: send back a 302, allowing the UAC to set up a new SIPSEC session with the destination UAS. But on the other hand, sending back a 302 may cause the heterogeneous error response forking problem (HERFP [17]). 5. Would SIPSEC apply to DTLS? TLS over SCTP? 6. Need to understand the behavior of REFER, GRUU and other extensions? 7. Need to sort out the upgrade mechanism. The choices are UPDATE (existing SIP request, less demanding on current implementations that already support it), CONNECT (a new SIP request), re-INVITE (probably not due to the rather heavy-weight handling of the INVITE transaction), or retargetting. 8. What about end-to-middle things? 9. Are TLS accelerators a problem? What if a SIPSEC URI was assigned to an external TLS accelerator, and the link between the accelerator and the endpoint using that accelerator was not protected? 10. Would intermediaries be willing to allow encrypted traffic to flow over the confidential tunnel thus created, all the while maintaining the session? Especially for sessions that they do not have visibility into (except for the initial setup)? What are the security implications of doing this from the viewpoint of the proxy? Clearly, this sort of an arrangement benefits P2PSIP session setup, preserving the confidentiality of the information across a mesh of intermediaries that are not trusted. Also clearly, this sort of an arrangement has worked in HTTP where endpoints behind NATs and firewalls routinely use the services of HTTP proxies to get to an https:// resource. Gurbani, et al. Expires December 20, 2006 [Page 7] Internet-Draft The SIPSEC URI June 2006 7. Security Considerations This document is concerned entirely with the issues of end to end security in SIP. 8. IANA Considerations To do: Register the SIPSEC URI scheme. 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", RFC 2119, March 1997. [2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [3] 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. [4] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol", RFC 3711, March 2004. 10.2 Informational References [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol: Version 1.1", RFC 4346, April 2006. [7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", Gurbani, et al. Expires December 20, 2006 [Page 8] Internet-Draft The SIPSEC URI June 2006 RFC 3546, June 2003. [8] 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. [9] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [10] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000. [11] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. [12] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [13] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. [14] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004. [15] Audet, F., "Guidelines for the use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", draft-audet-sip-sips-guidelines-01.txt (work in progress), May 2006. [16] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-06 (work in progress), October 2005. [17] Mahy, R., "A Solution to the Heterogeneous Error Response Forking Problem (HERFP) in the Session Initiation Protocol (SIP)", draft-mahy-sipping-herfp-fix-01 (work in progress), March 2006. Gurbani, et al. Expires December 20, 2006 [Page 9] Internet-Draft The SIPSEC URI June 2006 Authors' Addresses Vijay K. Gurbani (editor) Lucent Technologies, Inc./Bell Laboratories 2701 Lucent Lane Rm 9F-546 Lisle, IL 60532 USA Phone: +1 630 224 0216 Email: vkg@lucent.com Francois Audet Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 408 495 3756 Email: audet@nortel.com Dean Willis Cisco Systems 3100 Independence Parkway #311-164 Plano, TX 75075 USA Email: dean.willis@softarmor.com Gurbani, et al. Expires December 20, 2006 [Page 10] Internet-Draft The SIPSEC URI June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Gurbani, et al. Expires December 20, 2006 [Page 11]