One document matched: draft-gurbani-sip-tls-use-00.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>The Use of Transport Layer Security (TLS) in the Session Initiation
Protocol (SIP)</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="The Use of Transport Layer Security (TLS) in the Session Initiation
Protocol (SIP)">
<meta name="keywords" content="I-D, Internet-Draft">
<meta name="generator" content="xml2rfc v1.29 (http://xml.resource.org/)">
<style type='text/css'>
<!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
margin: 2em;
font-size: small ; color: #000000 ; background-color: #ffffff ; }
.title { color: #990000; font-size: x-large ;
font-weight: bold; text-align: right;
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
background-color: transparent; }
.filename { color: #666666; font-size: 18px; line-height: 28px;
font-weight: bold; text-align: right;
font-family: helvetica, arial, sans-serif;
background-color: transparent; }
td.rfcbug { background-color: #000000 ; width: 30px ; height: 30px ;
text-align: justify; vertical-align: middle ; padding-top: 2px ; }
td.rfcbug span.RFC { color: #666666; font-weight: bold; text-decoration: none;
background-color: #000000 ;
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-size: x-small ; }
td.rfcbug span.hotText { color: #ffffff; font-weight: normal; text-decoration: none;
text-align: center ;
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-size: x-small ; background-color: #000000; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
div#counter{margin-top: 100px}
a.info{
position:relative; /*this is the key*/
z-index:24;
text-decoration:none}
a.info:hover{z-index:25; background-color:#990000 ; color: #ffffff ;}
a.info span{display: none}
a.info:hover span.info{ /*the span will display just on :hover state*/
display:block;
position:absolute;
font-size: smaller ;
top:2em; left:2em; width:15em;
padding: 2px ;
border:1px solid #333333;
background-color:#eeeeee; color:#990000;
text-align: left ;}
A { font-weight: bold; }
A:link { color: #990000; background-color: transparent ; }
A:visited { color: #333333; background-color: transparent ; }
A:active { color: #333333; background-color: transparent ; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small ; }
p.toc { font-size: small ; font-weight: bold ; margin-left: 3em ;}
span.emph { font-style: italic; }
span.strong { font-weight: bold; }
span.verb, span.vbare { font-family: "Courier New", Courier, monospace ; }
span.vemph { font-style: italic; font-family: "Courier New", Courier, monospace ; }
span.vstrong { font-weight: bold; font-family: "Courier New", Courier, monospace ; }
span.vdeluxe { font-weight: bold; font-style: italic; font-family: "Courier New", Courier, monospace ; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
pre { margin-left: 3em; color: #333333; background-color: transparent;
font-family: "Courier New", Courier, monospace ; font-size: small ;
text-align: left;
}
h3 { color: #333333; font-size: medium ;
font-family: helvetica, arial, sans-serif ;
background-color: transparent; }
h4 { font-size: small; font-family: helvetica, arial, sans-serif ; }
table.bug { width: 30px ; height: 15px ; }
td.bug { color: #ffffff ; background-color: #990000 ;
text-align: center ; width: 30px ; height: 15px ;
}
td.bug A.link2 { color: #ffffff ; font-weight: bold;
text-decoration: none;
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-size: x-small ; background-color: transparent }
td.header { color: #ffffff; font-size: x-small ;
font-family: arial, helvetica, sans-serif; vertical-align: top;
background-color: #666666 ; width: 33% ; }
td.author { font-weight: bold; margin-left: 4em; font-size: x-small ; }
td.author-text { font-size: x-small; }
table.data { vertical-align: top ; border-collapse: collapse ;
border-style: solid solid solid solid ;
border-color: black black black black ;
font-size: small ; text-align: center ; }
table.data th { font-weight: bold ;
border-style: solid solid solid solid ;
border-color: black black black black ; }
table.data td {
border-style: solid solid solid solid ;
border-color: #333333 #333333 #333333 #333333 ; }
hr { height: 1px }
-->
</style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">SIP WG</td><td class="header">V. Gurbani</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">A. Jeffrey</td></tr>
<tr><td class="header">Expires: August 30, 2006</td><td class="header">Lucent Technologies, Inc./Bell</td></tr>
<tr><td class="header"> </td><td class="header">Laboratories</td></tr>
<tr><td class="header"> </td><td class="header">February 26, 2006</td></tr>
</table></td></tr></table>
<div align="right"><span class="title"><br />The Use of Transport Layer Security (TLS) in the Session Initiation
Protocol (SIP)</span></div>
<div align="right"><span class="title"><br />draft-gurbani-sip-tls-use-00</span></div>
<h3>Status of this Memo</h3>
<p>
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.</p>
<p>
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.</p>
<p>
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.”</p>
<p>
The list of current Internet-Drafts can be accessed at
<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
<p>
This Internet-Draft will expire on August 30, 2006.</p>
<h3>Copyright Notice</h3>
<p>
Copyright © The Internet Society (2006).</p>
<h3>Abstract</h3>
<p>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 on these issues.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
Terminology<br />
<a href="#anchor2">2.</a>
Introduction<br />
<a href="#anchor3">3.</a>
Goals and non-goals of TLS use in SIP<br />
<a href="#sec-ana">4.</a>
Security Analysis<br />
<a href="#anchor4">5.</a>
Open questions<br />
<a href="#anchor5">5.1</a>
An Authoritative Proxy<br />
<a href="#anchor6">5.2</a>
Mutual Authentication<br />
<a href="#anchor7">5.3</a>
URI Promotion<br />
<a href="#tls-3263">5.4</a>
TLS Site Certificates and RFC3263<br />
<a href="#anchor8">5.5</a>
Leveraging the Via Trail<br />
<a href="#anchor9">6.</a>
Security Considerations<br />
<a href="#anchor10">7.</a>
Acknowledgments<br />
<a href="#rfc.references1">8.</a>
References<br />
<a href="#rfc.references1">8.1</a>
Normative References<br />
<a href="#rfc.references2">8.2</a>
Informative References<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
<a href="#appendix-a">A.</a>
TLS in SIP Test Cases<br />
<a href="#anchor13">A.1</a>
Tests for valid certificates<br />
<a href="#anchor14">A.1.1</a>
Good certificate, Case 1<br />
<a href="#anchor15">A.1.2</a>
Good certificate, Case 2<br />
<a href="#anchor16">A.2</a>
Tests for invalid certificates<br />
<a href="#anchor17">A.2.1</a>
Invalid certificate, Case 1<br />
<a href="#anchor18">A.2.2</a>
Invalid certificate, Case 2<br />
<a href="#anchor19">A.2.3</a>
Invalid certificate, Case 3<br />
<a href="#anchor20">A.2.4</a>
Invalid certificate, Case 4<br />
<a href="#anchor21">A.2.5</a>
Invalid certificate, Case 5<br />
<a href="#anchor22">A.3</a>
Certificate depth test<br />
<a href="#rfc.copyright">§</a>
Intellectual Property and Copyright Statements<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1. Terminology</h3>
<p>
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 <a class="info" href="#RFC2119">RFC 2119<span> (</span><span class="info">Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a>[1].
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2. Introduction</h3>
<p>TLS <a class="info" href="#RFC2246">[3]<span> (</span><span class="info">Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.</span><span>)</span></a> 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.
</p>
<p>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
<a class="info" href="#appendix-a">Appendix A<span> (</span><span class="info">TLS in SIP Test Cases</span><span>)</span></a>. These test cases may be of interest to the
SIP Interoperability team and to developers who are currently adding
support TLS in SIP.
</p>
<p>For the discussion that follows, we assume the standard SIP trapezoid
shown in Figure 1:
</p><pre>
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.
</pre>
<p>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.
</p>
<p>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 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.
</p>
<p>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.
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3. Goals and non-goals of TLS use in SIP</h3>
<p>A detailed analysis of a threat model in SIP is also available in
<a class="info" href="#RFC3261">[2]<span> (</span><span class="info">Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.</span><span>)</span></a>. The threat model deals with the following
possible attacks:
</p>
<p></p>
<ol class="text">
<li>Outsider attack: An attacker mounts an attack without any certificates.
</li>
<li>Insider attack: An attacker mounts an attack with a valid certificate
for a domain.
</li>
<li>Eavesdropping attack: All messages between two entities are routed
correctly, but may be read by the attacker.
</li>
<li>Man-in-the-Middle (MiTM) attack: Messages may be modified by the
attacker.
</li>
</ol>
<p>The goals, then, of using TLS in SIP are such that security is assumed
across the following dimensions:
</p>
<p></p>
<ol class="text">
<li>Confidentiality: SIP message confidentiality should be protected from
outsider MiTM attack, and from insider eavesdropping attack.
</li>
<li>Integrity: SIP message integrity should be protected from MiTM attack.
</li>
<li>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.
</li>
<li>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.
</li>
</ol>
<p>The specific non-goals of using TLS in SIP are:
</p>
<p></p>
<ol class="text">
<li>Confidentiality and integrity in the presence of insider MiTM attack is
not ensured.
</li>
<li>Authenticity and non-repudiation at the SIP application layer is not
ensured.
</li>
<li>Access controls, privacy, availability or communication security are
explicit non-goals when using TLS.
</li>
</ol>
<a name="sec-ana"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4. Security Analysis</h3>
<p>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.
</p>
<p>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.
</p>
<p>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.
</p>
<p>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.
</p>
<p>Access control, privacy, availability and communication security
are out of scope of TLS.
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5. Open questions</h3>
<p>In this section, we catalogue some open questions on the use of
TLS in SIP.
</p>
<a name="rfc.section.5.1"></a><h4><a name="anchor5">5.1</a> An Authoritative Proxy</h4>
<p>When TLS is used, RFC3261 <a class="info" href="#RFC3261">[2]<span> (</span><span class="info">Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.</span><span>)</span></a> 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 <a class="info" href="#RFC3281">[4]<span> (</span><span class="info">Farrell, S. and R. Housley, “An Internet Attribute Certificate Profile for Authorization,” April 2002.</span><span>)</span></a> or SAML be more appropriate here?
</p>
<a name="rfc.section.5.2"></a><h4><a name="anchor6">5.2</a> Mutual Authentication</h4>
<p>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 <a class="info" href="#RFC3263">[5]<span> (</span><span class="info">Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Location SIP Servers,” June 2002.</span><span>)</span></a>.
</p>
<p>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.
</p>
<p></p>
<blockquote class="text">
<p>Even this is not entirely foolproof since P1 could have forged the
source IP address to match the contents of the certificate.
</p>
</blockquote>
<p>The rules for mutual authentication should be better specified in the
standard. Is what is detailed above enough? Or do we need more?
</p>
<a name="rfc.section.5.3"></a><h4><a name="anchor7">5.3</a> URI Promotion</h4>
<p>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 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.
</p>
<p></p>
<blockquote class="text">
<p>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.
</p>
</blockquote>
<a name="rfc.section.5.4"></a><h4><a name="tls-3263">5.4</a> TLS Site Certificates and RFC3263</h4>
<p>Section 4.1 in <a class="info" href="#RFC3263">[5]<span> (</span><span class="info">Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Location SIP Servers,” June 2002.</span><span>)</span></a> states that,
</p>
<p></p>
<blockquote class="text">
<p>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.
</p>
</blockquote>
<p>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).
</p>
<p>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 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"?
</p>
<p>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.
</p>
<p></p>
<blockquote class="text">
<p>Current drafts seem to support the notion that a collection of hosts
that make up a SRV RR set share a certificate; certainly,
<a class="info" href="#connect-reuse">[6]<span> (</span><span class="info">Mahy, R., Gurbani, V., and B. Tate, “Connection Reuse in the Session Initiation Protocol,” February 2006.</span><span>)</span></a> assumes this behavior.
</p>
</blockquote>
<a name="rfc.section.5.5"></a><h4><a name="anchor8">5.5</a> Leveraging the Via Trail</h4>
<p>In <a class="info" href="#sec-ana">Section 4<span> (</span><span class="info">Security Analysis</span><span>)</span></a>, we discussed how the authentication and
non-repudiation non-goals mitigate the use of TLS. Unlike HTTPS
<a class="info" href="#RFC2818">[9]<span> (</span><span class="info">Rescorla, E., “HTTP Over TLS,” May 2000.</span><span>)</span></a>, 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.
</p>
<p>A comparison with SMTP <a class="info" href="#RFC2821">[8]<span> (</span><span class="info">Klensin, J., Ed., “Simple Mail Transfer Protocol,” April 2001.</span><span>)</span></a> 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 discrepancy.
</p>
<p>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.
</p>
<p>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.
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6. Security Considerations</h3>
<p>This document is entirely concerned with security (more to be added).
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7. Acknowledgments</h3>
<p>The open issue in <a class="info" href="#tls-3263">Section 5.4<span> (</span><span class="info">TLS Site Certificates and RFC3263</span><span>)</span></a> was first documented by Klaus
Darilion. Thanks to Cullen Jennings for graciously volunteering his time
answering questions on the use of TLS in reSIProcate.
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8. References</h3>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>8.1 Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="RFC2119">[1]</a></td>
<td class="author-text">Bradner, S., “<a href="http://www.ietf.org/rfc/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>,” RFC 2119, March 1997.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3261">[2]</a></td>
<td class="author-text">Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “<a href="http://www.ietf.org/rfc/rfc3261.txt">SIP: Session Initiation Protocol</a>,” RFC 3261, June 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2246">[3]</a></td>
<td class="author-text">Dierks, T. and C. Allen, “<a href="http://www.ietf.org/rfc/rfc2246.txt">The TLS Protocol Version 1.0</a>,” RFC 2246, January 1999.</td></tr>
</table>
<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>8.2 Informative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="RFC3281">[4]</a></td>
<td class="author-text">Farrell, S. and R. Housley, “<a href="http://www.ietf.org/rfc/rfc3281.txt">An Internet Attribute Certificate Profile for Authorization</a>,” RFC 3281, April 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3263">[5]</a></td>
<td class="author-text">Rosenberg, J. and H. Schulzrinne, “<a href="http://www.ietf.org/rfc/rfc3263.txt">Session Initiation Protocol (SIP): Location SIP Servers</a>,” RFC 3263, June 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="connect-reuse">[6]</a></td>
<td class="author-text">Mahy, R., Gurbani, V., and B. Tate, “<a href="http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-05.txt">Connection Reuse in the Session Initiation Protocol</a>,” draft-ietf-sip-connect-reuse-05.txt (work in progress), February 2006.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2616">[7]</a></td>
<td class="author-text">Fieldings, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “<a href="http://www.ietf.org/rfc/rfc2616.txt">HyperText Transfer Protocol -- HTTP/1.1</a>,” RFC 2616, June 1999.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2821">[8]</a></td>
<td class="author-text">Klensin, J., Ed., “<a href="http://www.ietf.org/rfc/rfc2821.txt">Simple Mail Transfer Protocol</a>,” RFC 2821, April 2001.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2818">[9]</a></td>
<td class="author-text">Rescorla, E., “<a href="http://www.ietf.org/rfc/rfc2818.txt">HTTP Over TLS</a>,” RFC 2818, May 2000.</td></tr>
</table>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Vijay K. Gurbani</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Lucent Technologies, Inc./Bell Laboratories</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">2701 Lucent Lane</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Room 9F-546</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Lisle, IL 60532</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Phone: </td>
<td class="author-text">+1 630 224-0216</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:vkg at aCm dot OrG">vkg at aCm dot OrG</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Alan S. Jeffrey</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Lucent Technologies, Inc./Bell Laboratories</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">2701 Lucent Lane</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Room 9F-534</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Lisle, IL 60532</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:ajeffrey@lucent.com">ajeffrey@lucent.com</a></td></tr>
</table>
<a name="appendix-a"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A. TLS in SIP Test Cases</h3>
<a name="rfc.section.A.1"></a><h4><a name="anchor13">A.1</a> Tests for valid certificates</h4>
<a name="rfc.section.A.1.1"></a><h4><a name="anchor14">A.1.1</a> Good certificate, Case 1</h4>
<p>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.
</p>
<p>Expected behavior: Continue with the TLS session.
</p>
<a name="rfc.section.A.1.2"></a><h4><a name="anchor15">A.1.2</a> Good certificate, Case 2</h4>
<p>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.
</p>
<p>Expected behavior: Continue with the TLS session.
</p>
<a name="rfc.section.A.2"></a><h4><a name="anchor16">A.2</a> Tests for invalid certificates</h4>
<a name="rfc.section.A.2.1"></a><h4><a name="anchor17">A.2.1</a> Invalid certificate, Case 1</h4>
<p>Input: The server presents a certificate that has expired.
</p>
<p>Expected behavior: The client must immediately close the connection to
the server.
</p>
<p></p>
<blockquote class="text">
<p>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.
</p>
</blockquote>
<a name="rfc.section.A.2.2"></a><h4><a name="anchor18">A.2.2</a> Invalid certificate, Case 2</h4>
<p>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.
</p>
<p>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.
</p>
<a name="rfc.section.A.2.3"></a><h4><a name="anchor19">A.2.3</a> Invalid certificate, Case 3</h4>
<p>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.
</p>
<p>Expected behavior: It is recommended that the TLS session be terminated.
</p>
<a name="rfc.section.A.2.4"></a><h4><a name="anchor20">A.2.4</a> Invalid certificate, Case 4</h4>
<p>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.
</p>
<p>Expected behavior: It is recommended that the TLS session be terminated.
</p>
<a name="rfc.section.A.2.5"></a><h4><a name="anchor21">A.2.5</a> Invalid certificate, Case 5</h4>
<p>Input: The server presents a certificate that is signed by an unknown
certificate authority.
</p>
<p>Expected behavior: It is recommended that the TLS session be terminated.
</p>
<a name="rfc.section.A.3"></a><h4><a name="anchor22">A.3</a> Certificate depth test</h4>
<p>Open question: How deep do we want to allow certificate chains to go?
</p><a name="rfc.copyright"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table>
<h3>Intellectual Property Statement</h3>
<p class='copyright'>
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.</p>
<p class='copyright'>
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 <a href='http://www.ietf.org/ipr'>http://www.ietf.org/ipr</a>.</p>
<p class='copyright'>
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 <a href='mailto:ietf-ipr@ietf.org'>ietf-ipr@ietf.org</a>.</p>
<h3>Disclaimer of Validity</h3>
<p class='copyright'>
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.</p>
<h3>Copyright Statement</h3>
<p class='copyright'>
Copyright © 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.</p>
<h3>Acknowledgment</h3>
<p class='copyright'>
Funding for the RFC Editor function is currently provided by the
Internet Society.</p>
</body></html>
| PAFTECH AB 2003-2026 | 2026-04-24 01:23:39 |