Internet DRAFT - draft-srivastava-sip-e2e-ciphersuites
draft-srivastava-sip-e2e-ciphersuites
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]
