SIP S. Srivastava Internet-Draft Nortel Networks Expires: December 19, 2006 June 17, 2006 Ensuring End to End Cipher Suites in SIP draft-srivastava-sip-e2e-ciphersuites-00 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 19, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The security mechanism currently offered by SIP is essentially hop- by-hop and not end-to-end. The current SIP specification doesn't guarantee that a specific level of security (encryption, digest etc) is employed at each hop. This version of the draft outlines the solution broadly. As the solution progresses, it will have exact details in the subsequent versions. Srivastava Expires December 19, 2006 [Page 1] Internet-Draft Cipher Suites in SIP June 2006 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informational References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Srivastava Expires December 19, 2006 [Page 2] Internet-Draft Cipher Suites in SIP June 2006 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 2. Problem Statement According to RFC 3261 [2] section 26.2.1 "The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at a minimum by implementers when TLS is used in a SIP application. For purposes of backwards compatibility, proxy servers, redirect servers, and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other ciphersuite." An obvious inference of this statement is that SIP allows use of different cipher suites at each hop along the path. At the worst, SIP doesn't forbid the use of TLS_NULL_WITH_NULL_NULL ciphersuite for the SIPS URI scheme also. The current SIP specification doesn't provide the UAS a comprehensive view of security levels employed at the previous hops. While the UAS can derive some basic security related information from the Via header trail (for instance, the UAS can ensure that SIP/2.0/TLS was used all along the path before accepting the call), more detailed information regarding security protocol versions, ciphersuites used at each hop etc. is missing. As attackers will break the Protocols/cipher suites, it will be desirable to know what level of security is provided for the entire end-to-end communication. In addition, this needs to be done in a way that SIP will accommodate future secure protocol extensions seamlessly. I-D.gurbani-sip-tls-use [6] and I-D.audet-sip-sips-guidelines [7] do not address this issue. 3. Solution At a high level this draft proposes following extensions. It will be having the exact details in the subsequent versions. A) A New Header (Security-Level) will be defined, which will list the ciphersuites, protocols with version numbers desired/required by the UAC. The header MAY contain an optional "q" value for each security- Srivastava Expires December 19, 2006 [Page 3] Internet-Draft Cipher Suites in SIP June 2006 level tuple to indicate an order of preference among the tuples. The standards-track ciphersuites defined in RFC 4346 [4] will be carried in this header. This header MAY also contain TLS extensions B) A new option tag (cipher) will be defined for Proxy-Require/ Require headers. When this tag is present in the Require header the UAS MUST use one of the ciphersuites specified in the Security-Level header for this request and further requests within the dialog. In order to ensure e2e guarantee, it is RECOMMENDED that the UAC send "cipher" tag in both Proxy-Require and Require headers. Renegotiation of ciphersuites etc. is not considered in this early stage of the draft. C) Via header field will be extended for including cipher-suite and Secure Protocol version / extension. D) UAS can inspect the complete via header set, and find out the least preferred (qValued) ciphersuite used while setting the call. This can be indicated back to UAC in the response by overloading the Security-Level header defined in A). The boundary cases of same preference for two cipher suites is not considered at this stage. E) UA can indicate the support for this extension in Supported Header. OPEN ISSUE : Should we extend this mechanism for IPSec tunnels ? The proposed solution will be future proof for carrying any ciphersuites to be developed in future and vulnerabilities fixes in the transport protocol causing to the version changes of transports or addition of new extensions. Currently TLS has 1.0 Version as per RFC 2246 [3]and 1.1 version as per RFC 4346 [4] . Use of Proxy-Require / Require extension insures that if desired level of security is not provided at any hop, Request will be rejected by the proxy which is reached by desired level of security. It does not cover the case when there is compromised hop between two proxies i.e. both adjacent proxies lie in the collaboration. This is due to underlying transitive trust model of SIP. The proposed mechanism is extendable for DTLS RFC 4347 [5] . This solution is not dependent on underlying transport for TLS, which is the case with SIPS. The solution abstracts the Secure Transport Properties in a header for extendibility in future. The proposed solution addresses the issues with SIPS and SIP over TLS as described in I-D.gurbani-sip-tls-use [6] and I-D.audet-sip-sips-guidelines [7] with clear defintion of security. Srivastava Expires December 19, 2006 [Page 4] Internet-Draft Cipher Suites in SIP June 2006 4. Backward Compatibility TBD 5. Security Considerations TBD 6. IANA Considerations TBD. 7. Acknowledgments The author would like to thank Rajnish Jain for contributing with the text and providing the valuable feedback. The author would like to thank David Oran who raised the question on the email list. The author would like to thank Francois Audet for his valuable comments. 8. References 8.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. 8.2. Informational References [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [6] Gurbani, V. and A. Jeffrey, "The Use of Transport Layer Security (TLS) in the Session Initiation Protocol (SIP)", draft-gurbani-sip-tls-use-00 (work in progress), February 2006. Srivastava Expires December 19, 2006 [Page 5] Internet-Draft Cipher Suites in SIP June 2006 [7] Audet, F., "Guidelines for the use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", draft-audet-sip-sips-guidelines-01 (work in progress), May 2006. Srivastava Expires December 19, 2006 [Page 6] Internet-Draft Cipher Suites in SIP June 2006 Author's Address Samir Srivastava Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 US Phone: +1 408 495 5143 Email: samirsr@nortel.com Srivastava Expires December 19, 2006 [Page 7] Internet-Draft Cipher Suites in SIP 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. Srivastava Expires December 19, 2006 [Page 8]