One document matched: draft-ietf-sip-domain-certs-06.xml

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc comments='yes' ?>
<?rfc inline='no' ?>

<rfc docName="draft-ietf-sip-domain-certs-06"
     category="std" 
     updates="RFC3261" 
     ipr="pre5378Trust200902" 
>
<front>

<title abbrev="Domain Certs">
Domain Certificates in the Session Initiation Protocol (SIP)</title>

<author initials="V.K." surname="Gurbani" fullname="Vijay K. Gurbani">
 <organization>Bell Laboratories, Alcatel-Lucent</organization>
 <address>
  <postal>
   <street>1960 Lucent Lane</street>
   <street>Room 9C-533</street>
   <city>Naperville</city>
   <region>IL</region>
   <code>60566</code>
   <country>USA</country>
  </postal>
  <phone>+1 630 224-0216</phone>
  <email>vkg@alcatel-lucent.com</email>
 </address>
</author>

<author initials= "S." surname="Lawrence" fullname="Scott Lawrence">
  <organization>Avaya, Inc.</organization>
  <address>
   <postal>
    <street>600 Technology Park</street>
    <city>Billerica</city>
    <region>MA</region> <code>01821</code>
    <country>USA</country>
   </postal>
   <phone>+1 978 288 5508</phone>
   <email>xmlscott@gmail.com</email>
  </address>
</author>

<author initials="A." surname="Jeffrey" fullname="Alan S.A. Jeffrey">
 <organization>Bell Laboratories, Alcatel-Lucent</organization>
 <address>
  <postal>
   <street>1960 Lucent Lane</street>
   <street>Room 9C-533</street>
   <city>Naperville</city>
   <region>IL</region>
   <code>60566</code>
   <country>USA</country>
  </postal>
  <email>ajeffrey@alcatel-lucent.com</email>
 </address>
</author>

<date year="2010" month="March" day="22"/>

<area>Realtime Applications and Infrastructure</area>
<workgroup>SIP</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>

<abstract>
<t>This document describes how to construct and interpret certain information in a 
X.509 PKIX-compliant certificate for use in a Session Initiation Protocol 
(SIP) over Transport Layer Security (TLS) connection.  More specifically, 
this document describes how to encode and extract the identity of a SIP domain in a 
certificate and how to use that identity for SIP domain authentication.
As such, this document is relevant both to implementors of SIP and to issuers of certificates.
</t>
</abstract> 

</front>

<middle>

<section title="Terminology" >
<section title="Key Words">
<t>
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 <xref target="RFC2119">RFC 2119</xref>. </t>

<t>Additional definition(s):

 <list style="hanging">
  <t hangText="SIP domain identity:">An identity (e.g., "sip:example.com")
  contained in an X.509 certificate bound to a subject that identifies 
  the subject as an authoritative SIP server for a domain.</t>
 </list>
</t>

</section>

</section>

<section title="Introduction">

<t><xref target="RFC5246">RFC 5246</xref> Transport Layer Security (TLS) is available in an increasing number of Session Initiation Protocol (SIP) <xref
target="RFC3261">RFC 3261</xref> implementations.  In order to use the authentication
capabilities of TLS, certificates as defined by the Internet X.509 Public
Key Infrastructure <xref target="RFC5280">RFC 5280</xref> are required.</t>

<t>Existing SIP specifications do not sufficiently specify how to use
certificates for domain (as opposed to host) authentication.  This document
provides guidance to ensure interoperability and uniform conventions for the 
construction and interpretation of certificates used to identify their
holders as being authoritative for the domain.</t>

<t>The discussion in this document is pertinent to an X.509 PKIX-compliant
certificate used for a TLS connection; this document does not define use of such
certificates for any other purpose (such as S/MIME).  </t>

</section> <!-- Introduction -->

<section title="Problem statement" anchor="problem">

<t>TLS uses <xref target="RFC5280">RFC 5280</xref> X.509 Public Key 
Infrastructure to bind an identity or a set of identities, to the subject 
of a X.509 certificate.  While RFC3261 provides adequate guidance 
on the use of X.509 certificates used for S/MIME, it is relatively silent 
on the use of such certificates for TLS.  With respect to certificates 
for TLS, RFC3261 (Section 26.3.1) says:</t>

<t><list style="empty">
 <t>"Proxy servers, redirect servers and registrars SHOULD possess a
 site certificate whose subject corresponds to their canonical
 hostname."</t>
</list></t>

<t>The security properties of TLS and S/MIME as used in SIP are different:
X.509 certificates for S/MIME are generally used for end-to-end 
authentication and encryption, thus they serve to bind the identity
of a user to the certificate and RFC3261 is sufficiently clear that
in certificates used for S/MIME, the subjectAltName field will contain 
the appropriate identity.  On the other hand, X.509 certificates used for 
TLS serve to bind the identities of the per-hop domain sending or 
receiving the SIP messages.  However, the lack of guidelines in RFC3261
on exactly where to put identities -- in the subjectAltName field or 
carried as a Common Name (CN) in the Subject field -- of a X.509 certificates 
created ambiguities.  Following the accepted practice of the time, 
legacy X.509 certificates were allowed to store the identity in the 
CN field of the certificate 
instead of the currently specified subjectAltName extension.  Lack of
further guidelines on how to interpret the identities, which identity
to choose if more than one identity is present in the certificate, 
the behavior when multiple identities with different schemes were 
present in the certificate, etc. lead to ambiguities when attempting to 
interpret the certificate in a uniform manner for TLS use.</t>

<t>This document shows how the certificates are to be used for mutual
authentication when both the client and server possess appropriate
certificates, and normative behavior for matching the 
DNS query string with an identity stored in the X.509 certificate.
Furthermore, a certificate can contain multiple 
identities for the subject in the subjectAltName extension (the "subject"
of a certificate identifies the entity associated with the public
key stored in the public key field.)  As such, this document specifies 
appropriate matching rules to encompass various subject identity 
representation options.  And finally, this document also provides 
guidelines to service providers for assigning certificates to SIP 
servers.</t>

<t>The rest of this document is organized as follows: the next section
provides an overview of the most primitive case of a client using DNS
to access a SIP server and the resulting authentication steps.  
<xref target="problem-mutual"/> looks at the reason why mutual inter-domain 
authentication is desired in SIP, and the lack of normative text and 
behavior in RFC3261 for doing so. <xref target="sp"/> outlines normative
guidelines for a service provider assigning certificates to
SIP servers.  <xref target="SIP-considerations"/> provides
normative behavior on the SIP entities (user agent clients, user agent
servers, registrars, redirect servers, and proxies) that need perform
authentication based on X.509 certificates.   
<xref target="sec-cons"/> includes the security considerations.</t>

</section> <!-- problem -->

<section title="SIP domain to host resolution" anchor="domain-to-host">

<t>Routing in SIP is performed by having the client execute <xref
target="RFC3263">RFC 3263</xref> procedures on a URI, called the
"Application Unique String (AUS) (c.f. Section 8 of <xref
target="RFC3263">RFC 3263</xref>).  These procedures take as input a SIP
AUS (the SIP URI), extract the domain portion of that URI for use as a
lookup key, and query the Domain Name Service (DNS) to obtain an ordered
set of one or more IP addresses with a port number and transport
corresponding to each IP address in the set (the "Expected Output").  If
the transport indicates the use of TLS, then a TLS connection is opened to
the server on a specific IP address and port.  The server presents an X.509
certificate to the client for verification as part of the initial TLS
handshake.</t>

<t>The client extracts identifiers from the Subject and any subjectAltName
extension in the certificate (see <xref target='cert-subject' />) and compares 
these values to the domain part extracted from the original sip URI (the AUS).  If any identifier match is found, the server is 
considered to be authenticated and subsequent signaling can now proceed 
over the TLS connection.  Matching rules for X.509 certificates and the 
normative behavior for clients is specified in <xref target="uac"/>.</t>

<t>As an example, consider a request that is to be routed to the SIP address
"sips:alice@example.com".  This address requires a secure connection to 
the SIP domain "example.com" (the 'sips' scheme mandates a secure connection).  
Through a series of DNS manipulations, the domain name is mapped to a set of host
addresses and transports.  The entity attempting to create the connection
selects an address appropriate for use with TLS from this set.  When the connection is established to that server, 
the server presents a certificate asserting the identity "sip:example.com".  
Since the domain part of the SIP AUS matches the subject of the 
certificate, the server is authenticated (see <xref target='id-compare'/> for the normative rules that govern this comparison)</t>

<t><list>
 <t>SIPS borrows this pattern of server certificate matching from HTTPS.  However,
 <xref target="RFC2818">RFC 2818 </xref> prefers that the identity 
 be conveyed as a subjectAltName extension of type dNSName rather than 
 the common practice of conveying the identity in the CN 
 field of the Subject field.  Similarly, this document recommends
 that the SIP domain identity be conveyed as a subjectAltName extension of
 type uniformResourceIdentifier (c.f. <xref target="sp"/>, <xref 
 target="cert-subject"/>).</t>
 
 <t>A domain name in an X.509 certificates is properly interpreted
 only as a sequence of octets to be compared to the URI used to reach the
 host.  No inference can be made based on the DNS name hierarchy.  For example, 
 a valid certificate for "example.com" does not imply that the owner of that
 certificate has any relationship at all to "subname.example.com".</t>
</list></t>

</section> <!-- domain-to-host -->

<section title="The need for mutual interdomain authentication" 
         anchor="problem-mutual">

<t>Consider the SIP trapezoid shown in <xref target="sip-trapezoid"/>.</t>

<figure anchor="sip-trapezoid" title="SIP Trapezoid">
 <artwork><![CDATA[

  Proxy-A.example.com           Proxy-B.example.net
     +-------+                    +-------+
     | Proxy |--------------------| Proxy |
     +----+--+                    +---+---+
          |                           |
          |                           |
          |                           |
          |                         +---+
        0---0                       |   |
         /-\                        |___|
        +---+                      /    /
                                  +----+
   alice@example.com          bob@example.net

 ]]></artwork>
</figure>

<t>An user, alice@example.com, invites bob@example.net for a multimedia
communication session.  Alice's outbound proxy, Proxy-A.example.com,
uses normal <xref target="RFC3263">RFC 3263</xref> resolution rules
to find a proxy -- Proxy-B.example.net -- in the example.net domain that 
uses TLS.  Proxy-A actively establishes an interdomain TLS connection 
with Proxy-B and each presents a certificate to authenticate that 
connection.</t>

<t><xref target="RFC3261">RFC 3261</xref> section 26.3.2.2 
"Interdomain Requests" states that when a TLS connection is 
created between two proxies:

 <list style="empty">
  <t>"Each side of the connection SHOULD verify and inspect
   the certificate of the other, noting the domain name that appears in
   the certificate for comparison with the header fields of SIP
   messages."</t>
 </list>

However, RFC3261 is silent on whether to use the subjectAltName or CN of the certificate to obtain the domain name, and which takes precedence 
when there are multiple names identifying the holder of the certificate.</t>

<t>The authentication problem for Proxy-A is straightforward: in the 
certificate Proxy-A receives from Proxy-B, Proxy-A looks for an identity
that is a SIP URI 
("sip:example.net") or a DNS name ("example.net") that asserts Proxy-B's authority over the example.net
domain.  Normative behavior for a TLS client like Proxy-A is specified
in <xref target="uac"/>.</t>

<t>The problem for Proxy-B is slightly more complex since it accepted
the TLS request passively.  Thus, Proxy-B does not possess an equivalent
AUS that it can use as an anchor in matching identities from Proxy-A's
certificate.

 <list style="empty">
  <t><xref target="RFC3261">RFC 3261</xref> section 26.3.2.2 only tells
  Proxy-B to "compare the domain asserted by the certificate with the
  'domainname' portion of the From header field in the INVITE request."
  The difficulty with that instruction is that the domainname in the From 
  header field is not always that of the domain from which the
  request is received.</t>
 </list>

The normative behavior for a TLS server like Proxy-B that passively 
accepts a TLS connection and requires authentication of the sending 
peer domain is provided in <xref target="uas"/>.</t>

</section> <!-- problem-mutual -->

<section title="Certificate usage by a SIP service provider" anchor="sp">

<t>It is possible for service providers to continue the practice of using
existing certificates for SIP usage with the identity conveyed only in the
Subject field, but should carefully consider the following advantages of
conveying identity in the subjectAltName extension field:

<list style='symbols'>

<t>The subjectAltName extension can hold multiple values, so the same
certificate can identify multiple servers or sip domains.</t> 

<t>There is no fixed syntax specified for the Subject field, so issuers vary in
how the field content is set.  This forces a recipient to use heuristics to
extract the identity, again increasing opportunities for misinterpretation.</t>

</list>

Because of these advantages, service providers are strongly encouraged to
obtain certificates which contain the identity or identities in the
subjectAltName extension field.</t> 

<t>When assigning certificates to authoritative servers, 
a SIP service provider MUST ensure that the SIP domain
used to reach the server appears as an identity in the subjectAltName field, 
or for compatibility with existing certificates, the Subject field of 
the certificate.  In practice, this means that a service provider distributes 
to its users SIP URIs whose domain portion corresponds to an identity for 
which the service provider has been issued a certificate.</t>

</section> <!-- sp -->

<section title="Behavior of SIP entities" 
         anchor="SIP-considerations">

<t>This section normatively specifies the behavior of SIP entities
when using X.509 certificates to determine an authenticated SIP domain
identity.</t>

<t>The first two subsections apply to all SIP implementations that use TLS
to authenticate the peer: <xref target='cert-subject'/> describes how to extract a set of SIP
identities from the certificate obtained from a TLS peer, and <xref
target="id-compare"/> specifies how to compare SIP identities.  The
remaining subsections provide context for how and when these rules are to
be applied by entities in different SIP roles.</t>

<section title="Finding SIP Identities in a Certificate" anchor="cert-subject">

<t>Implementations (both clients and server) MUST determine the validity of
a certificate by following the procedures described in <xref
target="RFC5280">RFC 5280</xref>.</t> 

<t>As specified by <xref target="RFC5280">RFC 5280</xref> section 4.2.1.12, implementations 
MUST check for restrictions on certificate usage declared by any extendedKeyUsage 
extensions in the certificate.  The <xref target="I-D.sip-eku">SIP Extended Key Usage (EKU) document</xref> 
defines an extendedKeyUsage for SIP.</t>

<t>Given an X.509 certificate that the above checks have found to be
acceptable, the following describes how to determine what SIP domain identity 
or identities the certificate contains.   A single certificate can serve more than
one purpose - that is, the certificate might contain identities not acceptable as SIP,
domain identities and/or might contain one or more identities that are acceptable for 
use as SIP domain identities.

<list style='numbers'>

<t>Examine each value in the subjectAltName field.  The
subjectAltName field and the constraints on its values
are defined in Section 4.2.1.6 of <xref target="RFC5280">RFC 5280</xref>.  
The subjectAltName field can be absent or can contain one or
more values.  Each value in the subjectAltName has a type; the only types
acceptable for encoding a SIP domain identity SHALL be:

<list style="hanging">
  <t hangText="URI">
    If the scheme of the URI is not "sip", then the implementation
    MUST NOT accept the value as a SIP domain identity.
  </t>
  <t>
    If the scheme of the URI value is "sip", and the URI value that contains 
    a userpart (there is an '@'), the implementation MUST NOT accept the value as a SIP domain 
    identity (a value with a userpart identifies an individual user, not a 
    domain).
  </t> 
  <t>
    If the scheme of the URI value is "sip", and there is no userinfo component 
    in the URI (there is no '@'), then the implementation MUST accept the hostpart as a SIP domain identity.  
  </t> 
  <t>Note: URI scheme tokens are always case insensitive</t>

  <t hangText="DNS">An implementation MUST accept a domain name system identifier as a
  SIP domain identity if and only if no other identity is found that 
  matches the "sip" URI type described above.</t>
</list>
</t>

<t>If and only if the subjectAltName does not appear in the certificate, the
implementation MAY examine the CN field of the certificate.  If a valid DNS name 
is found there, the implementation MAY accept this value as a SIP domain 
identity.  Accepting a DNS name in the CN value is allowed for backward
compatibility, but when constructing new certificates, consider the
advantages of using the subjectAltName extension field (see <xref
target="sp"/>).</t> 

</list>
</t>

<t>The above procedure yields a set containing zero or more 
identities from the certificate.  A client uses these identities
to authenticate a server (see <xref target="uac"/>) and a server uses 
them to authenticate a client (see <xref target="uas"/>). </t>

</section>

<section title="Comparing SIP Identities" anchor="id-compare">

<t>When an implementation (either client or server) compares two values as SIP domain identities:

<list style='empty'>

<t>Implementations MUST compare only the DNS name component of each SIP domain identifier; 
an implementation MUST NOT use any scheme or parameters in the
comparison.</t>

<t>Implementations MUST compare the values as DNS names, which means that the
comparison is case insensitive as specified by <xref target="RFC4343">RFC 4343</xref>.  
Implementations MUST handle Internationalized Domain Names (IDNs)
in accordance with Section 7.2 of <xref target="RFC5280">RFC 5280</xref>
.</t>

<t>Implementations MUST match the values in their entirety:
<list>
<t>Implementations MUST NOT match suffixes.  For example,
"foo.example.com" does not match "example.com".</t>

<t>Implemenations MUST NOT match any form of wildcard, such as a leading "." or "*." with any other DNS label or sequence of labels.  For example, "*.example.com" matches only "*.example.com" but not "foo.example.com".   Similarly, ".example.com" matches only ".example.com", and does not match "foo.example.com."

 <list style="empty">
  <t><xref target="RFC2818">RFC 2818</xref> (HTTP over TLS)  allows the dNSName 
  component to contain a wildcard; e.g., "DNS:*.example.com".  
  <xref target="RFC5280">RFC 5280</xref>, while not disallowing this 
  explicitly, leaves the interpretation of wildcards to the individual 
  specification.  <xref target="RFC3261">RFC 3261</xref>  does not provide any 
  guidelines on the presence of wildcards in certificates.  Through the rule above, this document
  prohibits such wildcards in certificates for SIP domains.</t>
 </list>
</t>
</list>
</t>
</list>
</t>
</section>

<section title="Client behavior" anchor="uac">

<t>A client uses the domain portion of the SIP AUS to query a (possibly
untrusted) DNS to obtain a result set, which is one or more SRV and A records
identifying the server for the domain (see <xref
target="domain-to-host"/> for an overview.)</t>

<t>The SIP server, when establishing a TLS connection, presents its
certificate to the client for authentication.  The client MUST determine
the SIP domain identities in the server certificate using the procedure in
<xref target="cert-subject"/>.  Then, the client MUST compare the original
domain portion of the SIP AUS used as input to the <xref target="RFC3263">RFC 3263</xref> server location 
procedures to the SIP domain identities obtained 
from the certificate.

<list style='symbols'>
<t>If there were no identities found in the server certificate, the server
is not authenticated.</t>
<t>If the domain extracted from the AUS matches any SIP domain identity obtained from the certificate
when compared as described in section <xref target='id-compare' />, the
server is authenticated for the domain.</t>
</list>
</t>

<t>If the server is not authenticated, the client MUST close the connection
immediately.</t>

</section> <!-- uac -->

<section title="Server behavior" anchor="uas">

<t>When a server accepts a TLS connection, the server presents its own X.509
certificate to the client.  Servers that wish to authenticate the client will ask the client for a certificate.  If the client possesses a certificate, that certificate is
presented to the server.  If the client does not present a certificate, the client
MUST NOT be considered authenticated.

<list style="empty">
  
  <t>Whether or not to close a connection if the client does not present a
  certificate is a matter of local policy, and depends on the authentication
  needs of the server for the connection.  Some currently deployed servers
  use Digest authentication to authenticate individual requests on the
  connection, and choose to treat the connection as authenticated by those
  requests for some purposes (but see <xref target='digest-connection'/>).</t>
  
  <t>If the local server policy requires client authentication for some local purpose,
  then one element of such a local policy might be to allow the connection only if the
  client is authenticated.  For example, if the server is an inbound proxy
  that has peering relationships with the outbound proxies of other specific
  domains, the server might allow only connections authenticated as coming from
  those domains.</t>
</list>
</t>

<t>When authenticating the client, the server MUST obtain the set of SIP domain identities from the client
certificate as described in <xref target='cert-subject'/>.
Because the server accepted the TLS connection passively, unlike a
client, the server does not possess an AUS for comparison.  Nonetheless, server
policies can use the set of SIP domain identities gathered from the
certificate in <xref target="cert-subject"/> to make authorization
decisions.</t>

<t>For example, a very open policy could be to accept a X.509
certificate and validate the certificate using the procedures in <xref
target="RFC5280">RFC 5280</xref> .  If the certificate is valid, the identity set
is logged.</t>
<t>Alternatively, the server could have a list of all SIP 
domains the server is allowed to accept connections from; when a client presents 
its certificate, for each identity in the client certificate, the 
server searches for the identity in the list of acceptable domains to decide 
whether or not to accept the connection.  Other policies that make 
finer distinctions are possible.</t>

<t>The decision of whether or not the authenticated connection to
the client is appropriate for use to route new requests to the client
domain is independent of whether or not the connection is authenticated;
the <xref target="I-D.connect-reuse">connect-reuse</xref> draft discusses
this aspect in more detail.</t>

</section> <!-- uas -->

<section title="Proxy behavior" anchor="proxy">

<t>A proxy MUST use the procedures defined for a User Agent Server (UAS) in 
<xref target="uas"/> when authenticating a connection from a client.</t> 

<t>A proxy MUST use the procedures defined for a User Agent Client (UAC) in 
<xref target="uac" /> when requesting an authenticated connection to a UAS.</t>

<t>If a proxy adds a Record-Route when forwarding a request with the
expectation that the route is to use secure connections, the proxy MUST insert
into the Record-Route header a URI that corresponds to an identity for
which the proxy has a certificate; if the proxy does not insert such a URI, then creation of a secure connection using the value from the Record-Route as the
AUS will be impossible.</t> 

</section> <!-- proxy -->

<section title="Registrar behavior" anchor="registrar">

<t>A SIP registrar, acting as a server, follows the normative behavior
of <xref target="uas"/>.  When the SIP registrar accepts a TLS connection from the client,
the SIP registrar presents its certificate.  Depending on the registrar policies, the SIP registrar can
challenge the client with HTTP Digest.</t>

</section> <!-- registrar -->

<section title="Redirect server behavior" anchor="redirect">

<t>A SIP redirect server follows the normative behavior of a UAS as specified in <xref target="uas"/>.
</t>

</section> <!-- redirect -->

<section title="Virtual SIP Servers and Certificate Content"
 anchor="virtual-servers">

<t>In the "virtual hosting" cases where multiple domains are managed by a
single application, a certificate can contain multiple subjects by 
having distinct identities in the subjectAltName field
as specified in <xref target="RFC4474">RFC 4474</xref>.  Clients seeking to authenticate a server
on such a virtual host can still follow the directions in 
<xref target="uac"/> to find the identity matching the SIP AUS used
to query DNS.</t>

<t>Alternatively, if the TLS client hello "server_name" extension as defined in <xref target="RFC4366">RFC 4366</xref>
is supported, the client SHOULD use that extension to request a certificate corresponding
to the specific domain (from the SIP AUS) that the client is seeking to 
establish a connection with.</t>

</section> <!-- virtual-servers -->

</section> <!-- SIP-considerations -->

<section title="Security Considerations" anchor="sec-cons">

<t>The goals of TLS (when used with X.509 certificates) include the 
following security guarantees at the transport layer:

<list style="hanging">

<t hangText="Confidentiality:">packets tunneled through TLS can be read only
  by the sender and receiver.</t>

<t hangText="Integrity:">packets tunneled through TLS cannot be undetectably 
  modified on the connection between the sender and receiver.</t>

<t hangText="Authentication:">each principal is authenticated to the other as
  possessing a private key for which a certificate has been issued.
  Moreover, this certificate has not been revoked, and is verifiable by a
  certificate chain leading to a (locally configured) trust anchor.</t>

</list></t>

<t>We expect appropriate processing of domain
certificates to provide the following security guarantees at the
application level:

<list style="hanging">

<t hangText="Confidentiality:">SIPS messages from alice@example.com to 
  bob@example.net can be read only by alice@example.com, bob@example.net, and 
  SIP proxies issued with domain certificates for example.com or 
  example.net.</t>

<t hangText="Integrity:">SIPS messages from alice@example.com to 
  bob@example.net cannot be undetectably modified on the links between 
  alice@example.com, bob@example.net, and SIP proxies issued with domain 
  certificates for example.com or example.net.</t>

<t hangText="Authentication:">alice@example.com and proxy.example.com 
  are mutually authenticated; moreover proxy.example.com is authenticated to
  alice@example.com as an authoritative proxy for domain example.com.
  Similar mutual authentication guarantees are given between
  proxy.example.com and proxy.example.net and between proxy.example.net
  and bob@example.net.  As a result, alice@example.com is transitively
  mutually authenticated to bob@example.net (assuming trust in the
  authoritative proxies for example.com and example.net).</t>

</list></t>

<section title='Connection authentication using Digest' 
         anchor='digest-connection'>

  <t>Digest authentication in SIP provides for authentication of the
  message sender to the challenging UAS.  As commonly deployed, digest authentication provides
  only very limited integrity protection of the authenticated message, and
  has no provision for binding the authentication to any attribute of the transport.
  Many existing SIP deployments have chosen to use the Digest authentication of
  one or more messages on a particular transport connection as a way to authenticate
  the connection itself - by implication, authenticating other
  (unauthenticated) messages on that connection.  Some even choose to
  similarly authenticate a UDP source address and port based on the digest
  authentication of another message received from that address and port.  
  This use of digest goes beyond the assurances that the Digest
  Authentication mechanism
  was designed to provide.  A SIP implementation SHOULD NOT use the Digest
  Authentication of one message on a TCP connection or from a UDP peer to
  infer any authentication of any other messages on that connection or from
  that peer.  Authentication of the
  domain at the other end of a connection SHOULD be accomplished using TLS
  and the certificate validation rules described by this specification
  instead.</t>

</section> <!-- Connection authentication using Digest -->

</section> <!-- Security Considerations -->

<section title="IANA Considerations" anchor="iana-cons">

<t>This memo does not contain any considerations for IANA.</t>

</section> <!-- iana-cons -->

<section title="Acknowledgments">

<t>The following IETF contributors provided substantive input to this
document: Jeroen van Bemmel, Michael Hammer, Cullen Jennings, Paul Kyzivat,
Derek MacDonald, Dave Oran, Jon Peterson, Eric Rescorla, Jonathan
Rosenberg, Russ Housley.  Special acknowledgement goes to Stephen Kent 
for extensively reviewing draft versions and suggesting invaluable 
feedback, edits, and comments.</t>

<t>Paul Hoffman, Eric Rescorla and Robert Sparks provided much valuable
WGLC comments.</t>

</section>

</middle>  

<back>


<references title= "Normative References" >

<reference anchor="RFC2119">
 <front>
  <title>Key words for use in RFCs to Indicate Requirement Levels</title>
  <author initials="S." surname="Bradner">
    <organization/></author>
  <date month="March" year="1997"/>
 </front>
 <seriesInfo name="RFC" value="2119"/>
 <format type="TXT" target="http://www.ietf.org/rfc/rfc2119.txt"/>
</reference>

<reference anchor="RFC3261">
 <front>
  <title>SIP: Session Initiation Protocol</title>
  <author initials="J." surname="Rosenberg">
   <organization></organization>
  </author>
  <author initials="H." surname="Schulzrinne">
   <organization></organization>
  </author>
  <author initials='G.' surname='Camarillo'>
   <organization></organization>
  </author>
  <author initials='A.' surname='Johnston'>
   <organization></organization>
  </author>
  <author initials='J.' surname='Peterson'>
   <organization></organization>
  </author>
  <author initials='R.' surname='Sparks'>
   <organization></organization>
  </author>
  <author initials='M.' surname='Handley'>
   <organization></organization>
  </author>
  <author initials='E.' surname='Schooler'>
   <organization></organization>
  </author>
  <date month="June"  year="2002"/>
 </front>
 <seriesInfo name="RFC" value="3261"/>
 <format type="TXT" target="http://www.ietf.org/rfc/rfc3261.txt"/>
</reference>

<reference anchor='RFC4343'>

  <front>
    <title>Domain Name System (DNS) Case Insensitivity Clarification</title>
    <author initials='D.' surname='Eastlake' fullname='D. Eastlake'>
    <organization /></author>
    <date year='2006' month='January' />
    <abstract>
  <t>Domain Name System (DNS) names are "case insensitive".  This document explains exactly what that means and provides a clear specification of the rules.  This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS TRACK]</t></abstract></front>

  <seriesInfo name='RFC' value='4343' />
  <format type='TXT' octets='22899' target='ftp://ftp.isi.edu/in-notes/rfc4343.txt' />
</reference>

<reference anchor='RFC4366'>

  <front>
    <title>Transport Layer Security (TLS) Extensions</title>
    <author initials='S.' surname='Blake-Wilson' fullname='S. Blake-Wilson'>
    <organization /></author>
    <author initials='M.' surname='Nystrom' fullname='M. Nystrom'>
    <organization /></author>
    <author initials='D.' surname='Hopwood' fullname='D. Hopwood'>
    <organization /></author>
    <author initials='J.' surname='Mikkelsen' fullname='J. Mikkelsen'>
    <organization /></author>
    <author initials='T.' surname='Wright' fullname='T. Wright'>
    <organization /></author>
    <date year='2006' month='April' />
    <abstract>
  <t>This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.</t><t> The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. [STANDARDS TRACK]</t></abstract></front>

  <seriesInfo name='RFC' value='4366' />
  <format type='TXT' octets='66344' target='ftp://ftp.isi.edu/in-notes/rfc4366.txt' />
</reference>

<reference anchor='RFC5246'>

<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'>
<organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2008' month='August' />
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='5246' />
<format type='TXT' octets='222395' target='ftp://ftp.isi.edu/in-notes/rfc5246.txt' />
</reference>

<reference anchor="RFC5280">
 <front>
  <title>Internet X.509 Public Key Infrastructure Certificate and
  Certificate Revocation List (CRL) Profile</title>
  <author initials="D." surname="Cooper">
   <organization></organization>
  </author>
  <author initials="S." surname="Santesson">
   <organization></organization>
  </author>
  <author initials="S." surname="Farrell">
   <organization></organization>
  </author>
  <author initials="S." surname="Boyen">
   <organization></organization>
  </author>
  <author initials="R." surname="Housley">
   <organization></organization>
  </author>
  <author initials="W." surname="Polk">
   <organization></organization>
  </author>
  <date year='2008' month='May' />
</front>
 <seriesInfo name="RFC" value="5280"/>
 <format type="TXT" target="http://www.ietf.org/rfc/rfc5280.txt"/>
</reference>



</references>

<references title= "Informative References" >

<reference anchor="RFC2818">
 <front>
  <title>HTTP Over TLS</title>
  <author initials="E." surname="Rescorla"><organization/></author>
  <date month="May" year="2000"/>
 </front>
 <seriesInfo name="RFC" value="2818"/>
 <format type="TXT" target="http://www.ietf.org/rfc/rfc2818.txt"/>
</reference>

<reference anchor="RFC3263">
 <front>
  <title>Session Initiation Protocol (SIP): Location SIP Servers</title>
  <author initials="J." surname="Rosenberg">
   <organization></organization>
  </author>
  <author initials="H." surname="Schulzrinne">
   <organization></organization>
  </author>
  <date month="June" year="2002"/>
 </front>
 <seriesInfo name="RFC" value="3263"/>
 <format type="TXT" target="http://www.ietf.org/rfc/rfc3263.txt"/>
</reference>

<reference anchor="RFC4474">
 <front>
  <title>Enhancements for Authenticated Identity Management in the Session
         Initiation Protocol (SIP)</title>
  <author initials="J." surname="Peterson"><organization/></author>
  <author initials="C." surname="Jennings"><organization/></author>
  <date month="August" year="2006"/>
 </front>
 <seriesInfo name="RFC" value="4474"/>
 <format type="TXT"
   target="http://www.ietf.org/rfc/rfc4474.txt"/>
</reference>

<reference anchor="I-D.connect-reuse">
 <front>
  <title>Connection Reuse in the Session Initiation Protocol</title>
  <author initials="R." surname="Mahy"><organization/></author>
  <author initials="V." surname="Gurbani"><organization/></author>
  <author initials="B." surname="Tate"><organization/></author>
  <date month="August" year="2009"/>
 </front>
 <seriesInfo name="Internet-Draft" value="draft-ietf-sip-connect-reuse-14.txt"/>
 <format type="TXT"
   target=
    "http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-14.txt"/>
</reference>

<reference anchor="I-D.essential-corrections">
 <front>
  <title>A Process for Handling Essential Corrections to the
         Session Initiation  Protocol (SIP)</title>
  <author initials="K." surname="Drage"><organization/></author>
  <date month="July" year="2008"/>
 </front>
 <seriesInfo name="Internet-Draft" value="draft-drage-sip-essential-correction-03.txt"/>
 <format type="TXT"
   target=
    "http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correction-03.txt"/>
</reference>

<reference anchor="I-D.sip-eku">
  <front>
    <title abbrev="SIP EKU">
    Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP)
    X.509 Certificates</title>
    <author initials= "S." surname="Lawrence" fullname="Scott Lawrence">
      <organization>Nortel Networks Inc.</organization>
    </author>

    <author initials="V.K." surname="Gurbani" fullname="Vijay K. Gurbani">
      <organization>Bell Laboratories, Alcatel-Lucent</organization>
    </author>

    <date year="2009" month="October"/>

    <area>Realtime Applications and Infrastructure</area>
    <workgroup>SIP WG</workgroup>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-sip-eku-08.txt"/>
  <format type="TXT"
          target=
          "http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-08.txt"/>
</reference>

</references>

<section title="Editorial guidance (non-normative)">

  <t>
    This document is intended to update RFC 3261 in accordance with the SIP
    Working Group procedures described in <xref
    target="I-D.essential-corrections"/> or its successor.
  </t>

  <t>
    This appendix provides guidance to the editor of the next comprehensive
    update to <xref target="RFC3261">RFC 3261</xref> on how to incorporate
    the changes provided by this document.
  </t>

  <section title="Additions" anchor="additions">
    <t>
      The content of sections <xref target="domain-to-host"/> through <xref
      target="SIP-considerations"/> inclusive can be incorporated as
      subsections within a section that describes SIP domain authentication.
    </t>

    <t>
      The contents of <xref target='digest-connection'/> can be incorporated into 
      the Security Considerations section of the new document.
    </t>

    <t>
      All normative references from this document can be carried forward
      to the successor document.
    </t>
  </section>

  <section title="Changes">
    <t>
      The following subsections describe changes in specific sections of
      <xref target="RFC3261">RFC 3261</xref> that need to be modified in
      the successor document to align them with the content of this
      document.  In each of the following, the token
      <domain-authentication> is a reference to the section added as
      described in <xref target="additions"/>.
    </t>

    <section title="26.3.1">
      <t>
        The current text says:
        <list style="empty">
          <t>
            Proxy servers, redirect servers and registrars SHOULD possess a
            site certificate whose subject corresponds to their canonical
            hostname.
          </t>
        </list>
        The suggested replacement for the above is:
        <list style="empty">
          <t>
            Proxy servers, redirect servers, registrars, and any other
            server that is authoritative for some SIP purpose in a given
            domain SHOULD possess a certificate whose subjects include the
            name of that SIP domain.
          </t>
        </list>
      </t>
    </section>

  </section>
</section>

</back>
</rfc>

<!--  LocalWords:  xml UTF DOCTYPE rfc dtd stylesheet xsl href xslt toc symrefs
 -->
<!--  LocalWords:  iprnotified subcompact sortrefs colonspace inline docName WG
 -->
<!--  LocalWords:  DOCNAME bcp ipr abbrev Certs Gurbani fullname Vijay Alcatel
 -->
<!--  LocalWords:  vkg com Bluesocket ajeffrey Realtime workgroup PKIX xref TLS
 -->
<!--  LocalWords:  interoperability subjectAltName hostname DNS CN cref URIs IP
 -->
<!--  LocalWords:  Netscape accomodating drilldown AUS cert uac HTTPS dNSName
 -->
<!--  LocalWords:  uniformResourceIdentifier sp octets interdomain CDATA quot
 -->
<!--  LocalWords:  outbound proxyA proxyB DNSSEC uas eku hangText userinfo HTTP
 -->
<!--  LocalWords:  hostpart userpart wildcard wildcards SRV inbound edu UDP TXT
 -->
<!--  LocalWords:  undetectably IANA iana IETF Jeroen Bemmel Cullen Kyzivat CRL
 -->
<!--  LocalWords:  Oran Rescorla Housley acknowledgement RFCs Bradner Camarillo
 -->
<!--  LocalWords:  seriesInfo Schulzrinne Handley Dierks Nystrom Hopwood ietf
 -->
<!--  LocalWords:  Mikkelsen txt Mahy HyperText Fieldings Gettys Mogul Frystyk
 -->
<!--  LocalWords:  Masinter Berners Klensin std Alice's domainname IDNs WGLC lt
 -->
<!--  LocalWords:  Santesson Boyen Drage drage gt
 -->