One document matched: draft-ietf-sip-domain-certs-01.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="DOCNAME"
category="std"
updates="rfc3261"
ipr="full3978"
>
<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>2701 Lucent Lane</street>
<street>Room 9F-546</street>
<city>Lisle</city>
<region>IL</region>
<code>60532</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>Bluesocket Inc.</organization>
<address>
<postal>
<street>10 North Ave.</street>
<city>Burlington</city>
<region>MA</region> <code>01803</code>
<country>USA</country>
</postal>
<phone>+1 781 229 0533</phone>
<email>slawrence@bluesocket.com</email>
</address>
</author>
<author initials="A." surname="Jeffrey" fullname="Alan S.A. Jeffrey">
<organization>Bell Laboratories, Alcatel-Lucent</organization>
<address>
<postal>
<street>2701 Lucent Lane</street>
<street>Room 9F-534</street>
<city>Lisle</city>
<region>IL</region>
<code>60532</code>
<country>USA</country>
</postal>
<email>ajeffrey@alcatel-lucent.com</email>
</address>
</author>
<date year="YEAR" month="MONTH" day="DAY"/>
<area>Realtime Applications and Infrastructure</area>
<workgroup>SIP WG</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes how to interpret certain information in a
X.509 PKIX-compliant certificate used in a Session Initiation Protocol
(SIP) over Transport Layer Security (TLS) connection. More specifically,
it describes how to find the right identity for authentication in such
certificates and how to use it for SIP domain authentication.</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>Transport Layer Security (TLS) <xref target="RFC4346"/> has started to
appear in an increasing number of Session Initiation Protocol (SIP) <xref
target="RFC3261"/> 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; it may not apply to use of such
certificates with S/MIME, for instance. </t>
</section> <!-- Introduction -->
<section title="Problem statement" anchor="problem">
<t>TLS uses X.509 Public Key Infrastructure <xref target="RFC5280"/> to
bind an identity or a set of identities, to the subject of a X.509
certificate. Accordingly, the recommendations of the SIP working group
have been to populate the X.509v3 Subject Alternative Names (subjectAltName,
or SAN) extension with an identity. 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. The concept of what should
be contained in a site (or domain) certificate in RFC3261 is quoted below
(Section 26.3.1):</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
<!--
<cref source="Stephen Kent">
PKIX standards made an exception for RFC 822 names in legacy
certificates, but not for DNS names or URIs! There is a private
extension, developed by Netscape for representing a DNS name in a
certificate prior to the advent of SAN. I think it's rather late to be
accomodating certificates that are not compliant with RFC 5280, a spec
that is 5 years old.
</cref>
-->
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. It also contains normative behavior for matching the
DNS query string with an identity stored in the X.509 certificate.
Furthermore, it is permissible for a certificate to 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 when it is 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 domain) and
return an ordered set containing one or more IP addresses, and a port number
and transport corresponding to each IP address in the set (the "Expected
Output") by querying an Domain Name Service (DNS). 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 should extract identifiers from the Subject and subjectAltName
extension in the certificate (see <xref target='cert-subject' />) and compare
these values to 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", which is taken to be the SIP AUS value.
Through a series of DNS manipulations, the AUS is mapped to a set of host
addresses and transports. From this set, an address appropriate for use with
TLS is selected. A connection is subsequently established to that server,
which presents a certificate asserting an identity of "sip:example.com".
Since the host portion of the SIP AUS matches the subject of the
certificate, the server is considered to be authenticated.</t>
<t><list>
<t>SIPS borrows this behavior from HTTPS. However, to be pedantic,
<xref target="RFC2818">RFC 2818 </xref> prefers that the identity
be conveyed as a subjectAltName extension of type dNSName instead
of the commonly used 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 should be made based on the DNS name hierarchy.</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, mutual TLS authentication should follow
whereby
<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 where in the certificate should the
domain name be retrieved from (SAN or CN?) and which name takes precedence
when there are multiple names identifying the holder of the certificate.</t>
<t>The authentication problem for Proxy-A is straightforward: assuming
a secure DNS infrastructure and no routing attacks, Proxy-A already knows
that Proxy-B is a valid proxy for the example.net domain. Thus, in the
certificate it receives from Proxy-B, Proxy-A should look for the host name
("Proxy-B.example.net") or an identity consisting of a SIP URI
("sip: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, it 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 exhorts
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 this approach is that it is not always the case
that the domainname in From corresponds to the domain from which the
request is being received.</t>
</list>
The normative behavior for a TLS server like Proxy-B that passively
accept TLS connections and requires authentication of the sending
peer is provided in <xref target="uas"/>.</t>
</section> <!-- problem-mutual -->
<section title="Guidelines for a SIP service provider" anchor="sp">
<t>Service providers MAY continue the practice of using existing
certificates for SIP usage with the identity conveyed in the Subject
field; however, such usage is NOT RECOMMENDED for new certificates,
which MUST contain the identity or identities in the subjectAltName
extension field.</t>
<t>When assigning certificates to proxy servers, registrars, and
redirect servers, a SIP service provider MUST ensure that the SIP AUS
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>
<section title="Finding SIP Identities in a Certificate" anchor="cert-subject">
<t>Procedures for constructing a certificate path and checking revocation
status to determine the validity of a certificate are described in
<xref target="RFC5280">RFC 5280</xref>; implementations MUST follow checks
as prescribed therein. This document adds additional rules for interpreting
an X.509 certificate for use in SIP.</t>
<t>The <xref target="I-D.sip-eku">SIP Extended Key Usage (EKU) document</xref>
describes the method to validate EKU values found in the certificate used
for SIP. If a certificate has a SIP EKU value specified, implementations
MUST perform the checks prescribed by that specification.</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 it contains. Note that a single certificate MAY serve more than
one purpose - that is, it MAY contain identities not valid for use in SIP,
and/or MAY contain one or more identities that are valid for use in SIP.
<list style='numbers'>
<t>Examine the values in the subjectAltName field. The contents of
subjectAltName field and the constraints that may be imposed on them
are defined in Section 4.2.1.6 of <xref target="RFC5280">RFC 5280</xref>.
The subjectAltName field may not be present or it may contain one or
more identities. Each value in the subjectAltName has a type; the only types
acceptable for encoding a SIP domain identity are:
<list style="hanging">
<t hangText="URI">If the scheme of the URI value is "sip" (URI scheme
tokens are always case insensitive), and there is no userinfo component
in the URI (there is no '@'), then the hostpart is a SIP domain identity.
A URI value that does contain a userpart MUST NOT be used as a domain
identity (such a certificate identifies an individual user, not a server
for the domain).</t>
<t>If the scheme of the URI is not "sip", then the identity corresponding
to that scheme MUST NOT be used as a SIP domain identity.</t>
<t hangText="DNS">A domain name system identifier MUST be accepted 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
client MAY examine the CN field of the certificate. If a valid DNS name
is found there, the implementation MAY use this value as a SIP domain
identity. The use of the CN value is allowed for backward compatibility, but
is NOT RECOMMENDED. Service providers who are applying for new X.509
certificates to be used with SIP SHOULD follow the guidelines of
<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 comparing two values as SIP domain identities:
<list style='empty'>
<t>Implementations MUST compare only that part of each identifier (from the
procedure defined in <xref target="cert-subject"/>) that is a DNS name. Any
scheme or parameters extracted from an identifier MUST NOT be used in the
comparison procedure described below.</t>
<t>The values MUST be compared as DNS names, which means that the
comparison is case insensitive. Internationalized Domain Names (IDNs)
must be handled in accordance with Section 7.2 of RFC 5280
<xref target="RFC5280"/>.</t>
<t>The match MUST be exact:
<list>
<t>A suffix match MUST NOT be considered a match. For example,
"foo.example.com" does not match "example.com".</t>
<t>Any form of wildcard, such as a leading "." or "*.", MUST NOT be considered
a match. For example, "foo.example.com" does not match ".example.com" or
"*.example.com".
<list style="empty">
<t>RFC 2818 (HTTP over TLS) <xref target="RFC2818"/> allows the dNSName
component to contain a wildcard; e.g., "DNS:*.example.com".
RFC 5280 <xref target="RFC5280"/>, while not disallowing this
explicitly, leaves the interpretation of wildcards to the individual
specification. RFC 3261 <xref target="RFC3261"/> does not provide any
guidelines on the presence of wildcards in certificates. This document
reflects the consensus from the working group to not allow such wildcards.</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 server location
procedures <xref target="RFC3263"/> 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 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, it presents its own X.509
certificate to the client. To authenticate the client, the server asks the
client for a certificate. If the client possesses a certificate, it is
presented to the server. If the client does not present a certificate, it
MUST NOT be considered authenticated.
<list style="empty">
<t>Whether or not to close a connection if the client cannot 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 server requires client authentication for some local purpose,
then it MAY implement a policy of allowing 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, it might only allow connections authenticated as coming from
those domains.</t>
</list>
</t>
<t>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, it 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 it using the procedures in RFC 5280 <xref
target="RFC5280"/>. If the certificate is valid, the identity set
is logged. Alternatively, the server could have a list of all SIP
domains it is allowed to accept connections from; when a client presents
its certificate, for each identity in the client certificate, the
server searches for it 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>Note that 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, it MUST insert
into the Record-Route header a URI that corresponds to an identity for
which it has a certificate; if it does not, then it will not be possible
to create a secure connection using the value from the Record-Route as the
AUS.</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 it accepts a TLS connection from the client,
it present its certificate. Depending on the registrar policies, it may
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 <xref target="uas"/>.
When it accepts a TLS connection from the client, it present its certificate.
Depending on the server policies, it may challenge the client with
HTTP Digest.</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 may contain multiple subjects by
having distinct identities in the subjectAltName field
<xref target="RFC4474"/>. 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 extension <xref target="RFC4366"/>
is supported, the client SHOULD use it to request a certificate corresponding
to the specific domain (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, it provides
only very limited integrity protection of the authenticated message.
Many existing deployments have chosen to use the Digest authentication of
one or more messages on a particular connection as a way to authenticate
the connection itself - and by implication, authenticating other
(unchallenged) messages on that connection. Some even choose to
similarly authenticate a UDP source address and port based on the Digest
authentication of a message received from that address and port. This
use of Digest goes beyond the assurances it was designed to provide, and
is NOT RECOMMENDED. 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="RFC4346">
<front>
<title>The TLS Protocol Version 1.1</title>
<author initials="T." surname="Dierks">
<organization></organization>
</author>
<author initials="E." surname="Rescorla">
<organization></organization>
</author>
<date month="April" year="2006"/>
</front>
<seriesInfo name="RFC" value="4346"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc4346.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>
<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>Bluesocket Inc.</organization>
</author>
<author initials="V.K." surname="Gurbani" fullname="Vijay K. Gurbani">
<organization>Bell Laboratories, Alcatel-Lucent</organization>
</author>
<date year="2008" month="February"/>
<area>Realtime Applications and Infrastructure</area>
<workgroup>SIP WG</workgroup>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sip-eku-01.txt"/>
<format type="TXT"
target=
"http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-01.txt"/>
</reference>
</references>
<references title= "Informative References" >
<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="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="RFC4366">
<front>
<title>Transport Layer Security (TLS) Extensions</title>
<author initials="S." surname="Blake-Wilson"><organization/></author>
<author initials="M." surname="Nystrom"><organization/></author>
<author initials="D." surname="Hopwood"><organization/></author>
<author initials="J." surname="Mikkelsen"><organization/></author>
<author initials="T." surname="Wright"><organization/></author>
<date month="April" year="2006"/>
</front>
<seriesInfo name="RFC" value="4366"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc4366.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="October" year="2007"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sip-connect-reuse-08.txt"/>
<format type="TXT"
target=
"http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-08.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="November" year="2007"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-drage-sip-essential-correction-02.txt"/>
<format type="TXT"
target=
"http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correction-02.txt"/>
</reference>
<!--
<reference anchor="RFC3281">
<front>
<title>An Internet Attribute Certificate Profile for Authorization</title>
<author initials="S." surname="Farrell">
<organization></organization>
</author>
<author initials="R." surname="Housley">
<organization></organization>
</author>
<date month="April" year="2002"/>
</front>
<seriesInfo name="RFC" value="3281"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc3281.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="RFC2616">
<front>
<title>HyperText Transfer Protocol - HTTP/1.1</title>
<author initials="R." surname="Fieldings"><organization/></author>
<author initials="J." surname="Gettys"><organization/></author>
<author initials="J." surname="Mogul"><organization/></author>
<author initials="H." surname="Frystyk"><organization/></author>
<author initials="L." surname="Masinter"><organization/></author>
<author initials="P." surname="Leach"><organization/></author>
<author initials="T." surname="Berners-Lee"><organization/></author>
<date month="June" year="1999"/>
</front>
<seriesInfo name="RFC" value="2616"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc2616.txt"/>
</reference>
<reference anchor="RFC2821">
<front>
<title>Simple Mail Transfer Protocol</title>
<author initials="J." surname="Klensin" role="editor"><organization/></author>
<date month="April" year="2001"/>
</front>
<seriesInfo name="RFC" value="2821"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc2821.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>
Any normative references from this document should 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 subject is expressed
as described in <domain-authentication>.
</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
-->
| PAFTECH AB 2003-2026 | 2026-04-23 10:57:59 |