One document matched: draft-gurbani-sip-tls-use-00.txt
SIP WG V. Gurbani
Internet-Draft A. Jeffrey
Expires: August 30, 2006 Lucent Technologies, Inc./Bell
Laboratories
February 26, 2006
The Use of Transport Layer Security (TLS) in the Session Initiation
Protocol (SIP)
draft-gurbani-sip-tls-use-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 August 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document explores the use of the Transport Layer Security (TLS)
in the Session Initiation Protocol (SIP). We do so by outlining the
goals and the non-goals for the use of TLS and SIP. In doing so, a
number of open questions are encountered regarding the contents of
certificates and the behavior of SIP entities using such
certificates. We hope to foster discussion in the SIP working group
Gurbani & Jeffrey Expires August 30, 2006 [Page 1]
Internet-Draft TLS use in SIP February 2006
on these issues.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Goals and non-goals of TLS use in SIP . . . . . . . . . . . . 4
4. Security Analysis . . . . . . . . . . . . . . . . . . . . . . 5
5. Open questions . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 An Authoritative Proxy . . . . . . . . . . . . . . . . . . 6
5.2 Mutual Authentication . . . . . . . . . . . . . . . . . . 6
5.3 URI Promotion . . . . . . . . . . . . . . . . . . . . . . 6
5.4 TLS Site Certificates and RFC3263 . . . . . . . . . . . . 7
5.5 Leveraging the Via Trail . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1 Normative References . . . . . . . . . . . . . . . . . . . 9
8.2 Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
A. TLS in SIP Test Cases . . . . . . . . . . . . . . . . . . . . 10
A.1 Tests for valid certificates . . . . . . . . . . . . . . . 11
A.1.1 Good certificate, Case 1 . . . . . . . . . . . . . . . 11
A.1.2 Good certificate, Case 2 . . . . . . . . . . . . . . . 11
A.2 Tests for invalid certificates . . . . . . . . . . . . . . 11
A.2.1 Invalid certificate, Case 1 . . . . . . . . . . . . . 11
A.2.2 Invalid certificate, Case 2 . . . . . . . . . . . . . 11
A.2.3 Invalid certificate, Case 3 . . . . . . . . . . . . . 12
A.2.4 Invalid certificate, Case 4 . . . . . . . . . . . . . 12
A.2.5 Invalid certificate, Case 5 . . . . . . . . . . . . . 12
A.3 Certificate depth test . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13
Gurbani & Jeffrey Expires August 30, 2006 [Page 2]
Internet-Draft TLS use in SIP February 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. Introduction
TLS [3] has started to appear in increasing number of SIP
implementations. In order to aid in the interoperability and the
uniform implementation of TLS in SIP, this document explores the use
of TLS in SIP. In doing so, a number of open questions are
encountered regarding the contents of certificates and the behavior
of SIP entities using such certificates. This document catalogues
these issues to open a discussion on them in the SIP Working Group.
In addition, based on our experience with implementing TLS in a SIP
stack, we have derived a list of test cases. These are documented in
Appendix A. These test cases may be of interest to the SIP
Interoperability team and to developers who are currently adding
support TLS in SIP.
For the discussion that follows, we assume the standard SIP trapezoid
shown in Figure 1:
P1 ---------------------------- P2
(proxy.example.com) (proxy.example.net)
V V
/ \
/ \
/ \
/ \
User Agent User Agent
(sip:alice@example.com) (sip:bob@example.net)
Figure 1: Traditional SIP Trapezoid.
alice@example.com registers with her proxy (sip:proxy.example.com).
Unless otherwise stated, we will assume that end points do not posses
certificates, and that proxies, registrars and redirect servers do.
Thus, Alice uses a sip scheme in her registration (as opposed to a
sips scheme). Likewise, Bob registers a contact using a sip scheme
with his proxy (sip:proxy.example.net). Both P1 and P2 posses X.509
certificates and support TLS.
Alice sends a request to Bob through her proxy. Based on either the
presence of a pre-loaded sips URI in the Route header corresponding
Gurbani & Jeffrey Expires August 30, 2006 [Page 3]
Internet-Draft TLS use in SIP February 2006
to Bob's proxy, or because of a DNS NAPTR lookup that resulted in the
choice of TLS as the transport, Alice's proxy (P1) opens up a TLS
session with Bob's proxy (P2). Thus communications between P1 and P2
are deemed secure.
In this document, we are concerned solely with the security of SIP
signaling traffic. For a complete solution, media traffic must be
secured as well; however, that is out of scope of the current
discussion.
3. Goals and non-goals of TLS use in SIP
A detailed analysis of a threat model in SIP is also available in
[2]. The threat model deals with the following possible attacks:
1. Outsider attack: An attacker mounts an attack without any
certificates.
2. Insider attack: An attacker mounts an attack with a valid
certificate for a domain.
3. Eavesdropping attack: All messages between two entities are
routed correctly, but may be read by the attacker.
4. Man-in-the-Middle (MiTM) attack: Messages may be modified by the
attacker.
The goals, then, of using TLS in SIP are such that security is
assumed across the following dimensions:
1. Confidentiality: SIP message confidentiality should be protected
from outsider MiTM attack, and from insider eavesdropping attack.
2. Integrity: SIP message integrity should be protected from MiTM
attack.
3. Authenticity: Mutual authentication should occur between two
proxies communicating over TLS; i.e., with respect to Figure 1,
P1 must rely that it has indeed established connection with P2,
and vice-versa.
4. Non-repudiation: Mutual non-repudiation of proxies that are part
of a TLS connection must be assured; i.e., P1 cannot later
plausibly deny contacting P2.
The specific non-goals of using TLS in SIP are:
1. Confidentiality and integrity in the presence of insider MiTM
attack is not ensured.
2. Authenticity and non-repudiation at the SIP application layer is
not ensured.
3. Access controls, privacy, availability or communication security
are explicit non-goals when using TLS.
Gurbani & Jeffrey Expires August 30, 2006 [Page 4]
Internet-Draft TLS use in SIP February 2006
4. Security Analysis
The use of TLS to achieve the goals outlined above is standard. It
requires that for proxy.example.net to be trusted by
proxy.example.com, proxy.example.net must have been issued a
certificate containing the canonical host name as Distinguished Name
(DN) of the Subject field, or a DNS field entry in subjectAltName
X.509v3 extension. Furthermore, the certificate for
proxy.example.net must be backed by a certificate chain with a trust
anchor trusted by proxy.example.com as well. When proxy.example.com
checks proxy.example.net's certificate for validity, besides the
normal checks (certificate date validation, and if possible,
revocation) it also ensures that proxy.example.net's trust anchor is
trusted by proxy.example.com and that proxy.example.net is the DN of
the Subject field or one of the URIs in the subjectAltName X.509v3
extension.
Symmetric conditions are required for proxy.example.net to trust
proxy.example.com. Once the trust chain is established, the goals --
confidentiality, integrity, authenticity, and non-repudiation -- are
met by the use of TLS in SIP.
However, establishing a TLS trust chain does nothing to mitigate the
non-goals. Confidentiality and integrity can be violated by an
insider MiTM attack. Consider, for instance, an attacker with a
valid certificate for example.com that poisons DNS such that requests
for example.net end up at the attacker's node in the example.com
domain. Furthermore, if an attacker in example.com somehow gains
access to the private key of an unsuspecting victim, then the
attacker can masquerade as the victim for at least the length of time
it takes the victim to find out that his key has been compromised.
Establishing a TLS link also does nothing to mitigate authenticity
and non-repudiation at the SIP application layer. A TLS link
authenticates both the end points at each end of of the link,
however, it does not authenticate or provide non-repudiation of
discrete SIP messages flowing through the link. Consider for example
the case that a TLS link between two proxies may carry traffic for
more than one transaction (or dialog) between the proxies. Thus a
malicious host in one domain may well inject suspect SIP traffic in
the other domain, and this sort of attack cannot be detected or
prevented by the endpoints at either end of the TLS link. When
endpoints use TLS, there aren't any checks at the SIP layer
correlating the contents of the TLS certificate with the SIP headers.
In the presence of normal redirection, a receiving TLS entity cannot
even enforce that the domain of the URI in the From header correspond
to that of the sender's domain as asserted by the sender's
certificate.
Gurbani & Jeffrey Expires August 30, 2006 [Page 5]
Internet-Draft TLS use in SIP February 2006
Access control, privacy, availability and communication security are
out of scope of TLS.
5. Open questions
In this section, we catalogue some open questions on the use of TLS
in SIP.
5.1 An Authoritative Proxy
When TLS is used, RFC3261 [2] instructs that proxy servers,
registrars, and redirect server should possess a site certificate
whose subject corresponds to the canonical name of the host.
However, no provision is made to ensure that the host is indeed
authoritatively authorized to act as a proxy for that domain. Is the
dissemination of this trait considered of interest to the WG? If so,
are there provisions in X.509 that allow the conveyance of this
information? Or would an alternate mechanism like Attribute
Certificates [4] or SAML be more appropriate here?
5.2 Mutual Authentication
With reference to Figure 1, when P1 establishes a TLS link with P2,
mutual authentication should occur. P1 should ensure that P2's
certificate contains P2's canonical hostname. At P1, matching the
canonical hostname in the presented certificate to the intended
destination is trivial since P1 obtained the intended destination
possibly through a DNS query following the procedures in [5].
However, P2 accepted the connection as a passive listener. Thus, it
cannot depend on accepting, in a blind fashion, the contents of P1's
certificate that contains P1's canonical hostname. For all P2 knows,
P1 may have usurped someone else's legitimate certificate and is now
trying to establish a connection and present a stolen certificate.
Thus, to be certain, P2 should do a reverse DNS lookup of the source
address of the incoming TCP packet and match the result to the
contents of the certificate that contain P1's canonical hostname.
Even this is not entirely foolproof since P1 could have forged the
source IP address to match the contents of the certificate.
The rules for mutual authentication should be better specified in the
standard. Is what is detailed above enough? Or do we need more?
5.3 URI Promotion
Should a sip URI be promoted to a sips URI based on the NAPTR/SRV
lookups that resulted in the choice of TLS as the preferred
Gurbani & Jeffrey Expires August 30, 2006 [Page 6]
Internet-Draft TLS use in SIP February 2006
transport? If this is not done, it is possible for a request
received over TLS at the recipient to be sent out over a non-TLS
link. As an example, consider the trapezoid of Figure 1. Assume
that Alice sends a request to "sip:bob@example.net". P1 gets the
request and runs RFC3263 server resolution on it to derive a TLS as a
preferred transport. P1 sends the request to P2, albeit with a R-URI
of "sip:bob@example.net". Bob has his forwarding on so that all
incoming requests are forwarded to "sip:bob@example.org". When P2
attempts to contact Bob, it will do so by proxying the request over a
possibly non-secure link.
Ostensibly, if Bob was paranoid, he could have registered a sips
URI as his forwarding address. Then the right thing would happen.
Also, example.org domain may have DNS resolution set up in a
manner such that TLS is the preferred transport. However, the
security in this case depends on either Bob to do the right thing,
or the domain to give priority to TLS DNS registrations. On the
other hand, if from the onset a sip URI is promoted to a sips URI,
the security of the signaling is made much more explicit.
5.4 TLS Site Certificates and RFC3263
Section 4.1 in [5] states that,
For NAPTR records with SIPS protocol fields, (if the server is
using a site certificate), the domain name in the query and the
domain name in the replacement field MUST both be valid based on
the site certificate handed out by the server in the TLS exchange.
Similarly, the domain name in the SRV query and the domain name in
the target in the SRV record MUST both be valid based on the same
site certificate.
There has been a question raised on the SIP implementors mailing list
(see https://lists.cs.columbia.edu/pipermail/sip-implementors/
2005-October/010547.html) as to what is the intent of this section?
Is the intent that the NAPTR replacement field values be part of the
certificate as well? Or that if there are multiple SRV RRs, then all
of these should be part of the certificate? Or is the intent that a
single high-level domain name (i.e., example.com) be in the site
certificate instead of discrete servers in that domain (i.e.,
server1.example.com, server2.example.com, and so on).
This brings up a related question: what constitutes a site
certificate? RFC3261 states that, "Proxy servers, redirect servers,
and registrars SHOULD possess a site certificate whose subject
corresponds to their canonical hostname." However, what does this
mean when a SRV lookup on example.com returns multiple SIP servers:
does each server have a unique certificate with its canonical
Gurbani & Jeffrey Expires August 30, 2006 [Page 7]
Internet-Draft TLS use in SIP February 2006
hostname embedded in the certificate? Or does each server have a
high level FQDN (i.e., example.com) in the certificate and the
verifier must somehow trust that the server they are establishing a
connection with (server1.example.com) is indeed aptly represented by
a certificate whose DN (or subjectAltName) contains "example.com"?
In the latter case, it seems to be assumed that the site certificate
is shared among the many servers. This implies that the private key
is shared as well, which means that a compromise of the private key
at any one of the hosts would render the entire site to be insecure.
Current drafts seem to support the notion that a collection of
hosts that make up a SRV RR set share a certificate; certainly,
[6] assumes this behavior.
5.5 Leveraging the Via Trail
In Section 4, we discussed how the authentication and non-repudiation
non-goals mitigate the use of TLS. Unlike HTTPS [9], which uses TLS
to secure the transport layer and translate this directly to
application layer security (e.g., the "padlock" icon in most
browsers), the use of SIPS does not quite do the same. HTTPS has a
simple end-to-end model compared to SIP's hop-by-hop proxy model,
thus in HTTP, when the padlock is indeed locked, the user can be
assured that the traffic is flowing in a secure fashion from the
browser to the server. In SIP, by contrast, the use of TLS can be
assured only between hops. A proxy in a chain far removed from
another proxy much later in the chain cannot authoritatively
determine whether the later proxy is indeed using TLS. All it can
state with any certainty is that its neighbors have used TLS.
Furthermore, the use of TLS itself has no bearing on the traffic
flowing through the TLS link. Suspect SIP messages may well be
carried over this link, and as long as they are well-formed, the two
endpoints at each end of the TLS link do not, and typically cannot
enforce any rules that prohibit the passage of these messages. Thus
it is quite possible for a cracker to compromise a host in one
domain, and use the TLS link between that domain and a peer domain to
transfer suspect SIP messages.
A comparison with SMTP [8] is instructive here. A much abused
feature of SMTP is the "open relay" problem that is used to send
email with a forged "From" header field. The same problem can occur
in SIP as well. Consider that proxy.example.com establishes a TLS
link with proxy.example.net. A cracker in the example.com domain
sends a forged SIPS invitation to "sips:bob@example.net" claiming to
be from "sip:alice@example.org". This message will make it
successfully to the example.net domain, but clearly it has been
forged and the UAS processing this should be able to notice the
Gurbani & Jeffrey Expires August 30, 2006 [Page 8]
Internet-Draft TLS use in SIP February 2006
discrepancy.
In SMTP, a common diagnostic tool is the "Received" field that
contains an audit trail of the Mail Transfer Agents (MTA) that have
handled the request thus far. The equivalent in SIP terms is the
"Via" field. If the request actually originated in the example.org
domain (remember, the message claimed to be from
"sip:alice@example.org") then there should be a Via header
corresponding to that domain. The absence of such a Via header is a
hint that the message may have been compromised.
Thus, it seems appropriate to add a processing requirement to SIPS,
which states that when a proxy at example.net receives a request
claiming to be from proxy.example.com, then it should verify that
proxy.example.com is the topmost Via entry in the Via header list.
In addition, proxy.example.com should be the identity contained in
the TLS certificate for the connection. Conversely, when
proxy.example.net sends a SIPS message to example.com, the FQDN it
adds in the sent-by production rule of the topmost Via header must be
the same as the identity contained in the certificate it sent to
example.com.
6. Security Considerations
This document is entirely concerned with security (more to be added).
7. Acknowledgments
The open issue in Section 5.4 was first documented by Klaus Darilion.
Thanks to Cullen Jennings for graciously volunteering his time
answering questions on the use of TLS in reSIProcate.
8. References
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", 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.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
Gurbani & Jeffrey Expires August 30, 2006 [Page 9]
Internet-Draft TLS use in SIP February 2006
8.2 Informative References
[4] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002.
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Location SIP Servers", RFC 3263, June 2002.
[6] Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in the
Session Initiation Protocol",
draft-ietf-sip-connect-reuse-05.txt (work in progress),
February 2006.
[7] Fieldings, 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., Ed., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[9] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
Authors' Addresses
Vijay K. Gurbani
Lucent Technologies, Inc./Bell Laboratories
2701 Lucent Lane
Room 9F-546
Lisle, IL 60532
USA
Phone: +1 630 224-0216
Email: vkg at aCm dot OrG
Alan S. Jeffrey
Lucent Technologies, Inc./Bell Laboratories
2701 Lucent Lane
Room 9F-534
Lisle, IL 60532
USA
Email: ajeffrey@lucent.com
Appendix A. TLS in SIP Test Cases
Gurbani & Jeffrey Expires August 30, 2006 [Page 10]
Internet-Draft TLS use in SIP February 2006
A.1 Tests for valid certificates
A.1.1 Good certificate, Case 1
Input: The server presents a certificate that is signed by a trusted
certificate authority. The certificate has the canonical name of the
host in the Distinguished Name (DN) of the Subject field. The
subjectAltName X.509v3 extension is empty.
Expected behavior: Continue with the TLS session.
A.1.2 Good certificate, Case 2
Input: The server presents a certificate that is signed by a trusted
certificate authority. The certificate has the canonical name of the
host in the subjectAltName X.509v3 extension. The DN of the Subject
field contains other identifying information besides a canonical
name.
Expected behavior: Continue with the TLS session.
A.2 Tests for invalid certificates
A.2.1 Invalid certificate, Case 1
Input: The server presents a certificate that has expired.
Expected behavior: The client must immediately close the connection
to the server.
Some frameworks, such as OpenSSL, automatically run default checks
on certificates. One test among these default tests is the test
for expiration. The OpenSSL framework informs the programmer that
a certificate failed the default checks. The programmer must then
close the connection opened with that server.
A.2.2 Invalid certificate, Case 2
Input: The server presents a certificate that is signed by a trusted
certificate authority. However, there isn't any canonical name in
either the DN of the Subject field, or in the subjectAltName X.509v3
extension.
Expected behavior: Depends on the implementation. A paranoid
implementation may want to terminate the TLS session immediately. A
more lenient implementation may continue with the session with the
expectation that, at the very least, the traffic is encrypted.
Gurbani & Jeffrey Expires August 30, 2006 [Page 11]
Internet-Draft TLS use in SIP February 2006
A.2.3 Invalid certificate, Case 3
Input: The server presents a certificate that is signed by a trusted
certificate authority. However, The certificate has the wrong
canonical name of the host in the Distinguished Name (DN) of the
Subject field. The subjectAltName X.509v3 extension is empty.
Expected behavior: It is recommended that the TLS session be
terminated.
A.2.4 Invalid certificate, Case 4
Input: The server presents a certificate that is signed by a trusted
certificate authority. However, The certificate has the wrong
canonical name of the host in the subjectAltName X.509v3 extension.
The Distinguished Name (DN) of the Subject field contains other
identifying information besides a canonical name.
Expected behavior: It is recommended that the TLS session be
terminated.
A.2.5 Invalid certificate, Case 5
Input: The server presents a certificate that is signed by an
unknown certificate authority.
Expected behavior: It is recommended that the TLS session be
terminated.
A.3 Certificate depth test
Open question: How deep do we want to allow certificate chains to
go?
Gurbani & Jeffrey Expires August 30, 2006 [Page 12]
Internet-Draft TLS use in SIP February 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 & Jeffrey Expires August 30, 2006 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 04:22:19 |