SIP WG V. Gurbani
Internet-Draft Bell Laboratories, Alcatel-Lucent
Updates: RFC3261 S. Lawrence
(if approved) Nortel Networks, Inc.
Intended status: Standards Track A. Jeffrey
Expires: April 9, 2009 Bell Laboratories, Alcatel-Lucent
October 06, 2008
Domain Certificates in the Session Initiation Protocol (SIP)
draft-ietf-sip-domain-certs-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 9, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
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, this document describes how to find the right identity
for authentication in such certificates and how to use that identity
Gurbani, et al. Expires April 9, 2009 [Page 1]
Internet-Draft Domain Certs October 2008
for SIP domain authentication.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3
4. SIP domain to host resolution . . . . . . . . . . . . . . . . 5
5. The need for mutual interdomain authentication . . . . . . . . 6
6. Certificate usage by a SIP service provider . . . . . . . . . 7
7. Behavior of SIP entities . . . . . . . . . . . . . . . . . . . 7
7.1. Finding SIP Identities in a Certificate . . . . . . . . . 7
7.2. Comparing SIP Identities . . . . . . . . . . . . . . . . . 9
7.3. Client behavior . . . . . . . . . . . . . . . . . . . . . 10
7.4. Server behavior . . . . . . . . . . . . . . . . . . . . . 10
7.5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . 11
7.6. Registrar behavior . . . . . . . . . . . . . . . . . . . . 11
7.7. Redirect server behavior . . . . . . . . . . . . . . . . . 12
7.8. Virtual SIP Servers and Certificate Content . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Connection authentication using Digest . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Editorial guidance (non-normative) . . . . . . . . . 15
A.1. Additions . . . . . . . . . . . . . . . . . . . . . . . . 15
A.2. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 15
A.2.1. 26.3.1 . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Gurbani, et al. Expires April 9, 2009 [Page 2]
Internet-Draft Domain Certs October 2008
1. Terminology
1.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Additional definition(s):
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.
2. Introduction
RFC 4346 [3] Transport Layer Security (TLS) has started to appear in
an increasing number of Session Initiation Protocol (SIP) RFC 3261
[2] implementations. In order to use the authentication capabilities
of TLS, certificates as defined by the Internet X.509 Public Key
Infrastructure RFC 5280 [4] are required.
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.
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).
3. Problem statement
TLS uses RFC 5280 [4] 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:
"Proxy servers, redirect servers and registrars SHOULD possess a
site certificate whose subject corresponds to their canonical
hostname."
Gurbani, et al. Expires April 9, 2009 [Page 3]
Internet-Draft Domain Certs October 2008
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.
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.
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.
Section 5 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. Section 6 outlines normative guidelines for a
service provider assigning certificates to SIP servers. Section 7
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. Section 8
includes the security considerations.
Gurbani, et al. Expires April 9, 2009 [Page 4]
Internet-Draft Domain Certs October 2008
4. SIP domain to host resolution
Routing in SIP is performed by having the client execute RFC 3263 [7]
procedures on a URI, called the "Application Unique String (AUS)
(c.f. Section 8 of RFC 3263 [7]). 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.
The client extracts identifiers from the Subject and any
subjectAltName extension in the certificate (see Section 7.1) and
compares 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
Section 7.3.
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 becomes the SIP AUS
value. Through a series of DNS manipulations, the AUS 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
Section 7.2 for the normative rules that govern this comparison)
SIPS borrows this pattern of server certificate matching from
HTTPS. However, RFC 2818 [8] 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. Section 6, Section 7.1).
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".
Gurbani, et al. Expires April 9, 2009 [Page 5]
Internet-Draft Domain Certs October 2008
5. The need for mutual interdomain authentication
Consider the SIP trapezoid shown in Figure 1.
Proxy-A.example.com Proxy-B.example.net
+-------+ +-------+
| Proxy |--------------------| Proxy |
+----+--+ +---+---+
| |
| |
| |
| +---+
0---0 | |
/-\ |___|
+---+ / /
+----+
alice@example.com bob@example.net
Figure 1: SIP Trapezoid
An user, alice@example.com, invites bob@example.net for a multimedia
communication session. Alice's outbound proxy, Proxy-A.example.com,
uses normal RFC 3263 [7] 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.
RFC 3261 [2] section 26.3.2.2 "Interdomain Requests" states that when
a TLS connection is created between two proxies:
"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."
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.
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 Proxy-A receives from Proxy-B, Proxy-A looks
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
Gurbani, et al. Expires April 9, 2009 [Page 6]
Internet-Draft Domain Certs October 2008
over the example.net domain. Normative behavior for a TLS client
like Proxy-A is specified in Section 7.3.
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.
RFC 3261 [2] 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.
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 Section 7.4.
6. Certificate usage by a SIP service provider
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.
When assigning certificates to authoritative 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.
7. Behavior of SIP entities
This section normatively specifies the behavior of SIP entities when
using X.509 certificates to determine an authenticated SIP domain
identity.
7.1. Finding SIP Identities in a Certificate
Implementations MUST determine the validity of a certificate by
following the procedures for constructing a certificate path and
Gurbani, et al. Expires April 9, 2009 [Page 7]
Internet-Draft Domain Certs October 2008
checking revocation status described in RFC 5280 [4]. This document
adds additional rules for interpreting an X.509 certificate for use
in SIP.
As specified by RFC 5280 [4] section 4.2.1.12, implementations MUST
check for restrictions on certificate usage declared by any
extendedKeyUsage extentions in the certificate. The SIP Extended Key
Usage (EKU) document [5] defines an extendedKeyUsage for SIP.
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 MAY contain identities not acceptable as SIP, domain
identities and/or MAY contain one or more identities that are
acceptable for use as SIP domain identities.
1. 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 RFC 5280 [4]. 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:
URI If the scheme of the URI is not "sip", then the value MUST
NOT be accepted as a SIP domain identity.
If the scheme of the URI value is "sip", and the URI value
that contains a userpart (there is an '@'), the value MUST NOT
be accpeted as a SIP domain identity (a value with a userpart
identifies an individual user, not a domain).
If the scheme of the URI value is "sip", and there is no
userinfo component in the URI (there is no '@'), then the
hostpart MUST be accepted as a SIP domain identity.
Note: URI scheme tokens are always case insensitive
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.
2. 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 accept this value as a SIP domain identity.
Gurbani, et al. Expires April 9, 2009 [Page 8]
Internet-Draft Domain Certs October 2008
3. Accepting a DNS name in the CN value is allowed for backward
compatibility, but constructing new certificates with the
identity as a DNS name in the CN value is NOT RECOMMENDED; see
Section 6.
The above procedure yields a set containing zero or more identities
from the certificate. A client uses these identities to authenticate
a server (see Section 7.3) and a server uses them to authenticate a
client (see Section 7.4).
7.2. Comparing SIP Identities
When comparing two values as SIP domain identities:
Implementations MUST compare only the DNS name component of each
SIP domain identifier; any scheme or parameters in an identifier
MUST NOT be used in the comparison.
The values MUST be compared as DNS names, which means that the
comparison is case insensitive as specified by RFC 4343 [6].
Internationalized Domain Names (IDNs) MUST be handled in
accordance with Section 7.2 of RFC 5280 [4] .
The values being compared MUST match in their entirety:
A suffix match is not a match. For example, "foo.example.com"
does not match "example.com".
Any form of wildcard, such as a leading "." or "*.", MUST NOT
be considered a match for 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."
RFC 2818 [8] (HTTP over TLS) allows the dNSName component to
contain a wildcard; e.g., "DNS:*.example.com". RFC 5280
[4], while not disallowing this explicitly, leaves the
interpretation of wildcards to the individual specification.
RFC 3261 [2] 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.
Gurbani, et al. Expires April 9, 2009 [Page 9]
Internet-Draft Domain Certs October 2008
7.3. Client behavior
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 Section 4 for an
overview.)
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 Section 7.1. Then, the client MUST compare the
original domain portion of the SIP AUS used as input to the RFC 3263
[7] server location procedures to the SIP domain identities obtained
from the certificate.
o If there were no identities found in the server certificate, the
server is not authenticated.
o If the AUS matches any SIP domain identity obtained from the
certificate when compared as described in section Section 7.2, the
server is authenticated for the domain.
If the server is not authenticated, the client MUST close the
connection immediately.
7.4. Server behavior
When a server accepts a TLS connection, the server 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, that certificate is presented to the server. If the
client does not present a certificate, the client MUST NOT be
considered authenticated.
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 Section 8.1).
If the server requires client authentication for some local
purpose, then the server 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, the server might
allow only connections authenticated as coming from those domains.
Gurbani, et al. Expires April 9, 2009 [Page 10]
Internet-Draft Domain Certs October 2008
To authenticate the client, the server MUST obtain the set of SIP
domain identities from the client certificate as described in
Section 7.1. 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 Section 7.1 to
make authorization decisions.
For example, a very open policy could be to accept a X.509
certificate and validate the certificate using the procedures in RFC
5280 [4] . If the certificate is valid, the identity set is logged.
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.
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 connect-reuse [11] draft discusses this aspect in
more detail.
7.5. Proxy behavior
A proxy MUST use the procedures defined for a User Agent Server (UAS)
in Section 7.4 when authenticating a connection from a client.
A proxy MUST use the procedures defined for a User Agent Client (UAC)
in Section 7.3 when requesting an authenticated connection to a UAS.
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.
7.6. Registrar behavior
A SIP registrar, acting as a server, follows the normative behavior
of Section 7.4. 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.
Gurbani, et al. Expires April 9, 2009 [Page 11]
Internet-Draft Domain Certs October 2008
7.7. Redirect server behavior
A SIP redirect server follows the normative behavior of a UAS as
specified in Section 7.4.
7.8. Virtual SIP Servers and Certificate Content
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 RFC 4474 [10]. Clients seeking to authenticate a server on such a
virtual host can still follow the directions in Section 7.3 to find
the identity matching the SIP AUS used to query DNS.
Alternatively, if the TLS client hello extension as defined in RFC
4366 [9] is supported, the client SHOULD use that extension to
request a certificate corresponding to the specific domain (the SIP
AUS) that the client is seeking to establish a connection with.
8. Security Considerations
The goals of TLS (when used with X.509 certificates) include the
following security guarantees at the transport layer:
Confidentiality: packets tunneled through TLS can be read only by
the sender and receiver.
Integrity: packets tunneled through TLS cannot be undetectably
modified on the connection between the sender and receiver.
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.
We expect appropriate processing of domain certificates to provide
the following security guarantees at the application level:
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.
Gurbani, et al. Expires April 9, 2009 [Page 12]
Internet-Draft Domain Certs October 2008
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.
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).
8.1. Connection authentication using Digest
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. 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 that digest authentication 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.
9. IANA Considerations
This memo does not contain any considerations for IANA.
10. Acknowledgments
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.
Paul Hoffman, Eric Rescorla and Robert Sparks provided much valuable
Gurbani, et al. Expires April 9, 2009 [Page 13]
Internet-Draft Domain Certs October 2008
WGLC comments.
11. References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
RFC 4346, April 2006.
[4] Cooper, D., Santesson, S., Farrell, S., Boyen, S., Housley, R.,
and W. Polk, "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile",
RFC 5280, May 2008.
[5] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU)
for Session Initiation Protocol (SIP) X.509 Certificates",
draft-ietf-sip-eku-01.txt (work in progress), February 2008.
[6] Eastlake, D., "Domain Name System (DNS) Case Insensitivity
Clarification", RFC 4343, January 2006.
11.2. Informative References
[7] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Location SIP Servers", RFC 3263, June 2002.
[8] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[9] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions",
RFC 4366, April 2006.
[10] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[11] Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in the
Session Initiation Protocol",
draft-ietf-sip-connect-reuse-08.txt (work in progress),
October 2007.
Gurbani, et al. Expires April 9, 2009 [Page 14]
Internet-Draft Domain Certs October 2008
[12] Drage, K., "A Process for Handling Essential Corrections to the
Session Initiation Protocol (SIP)",
draft-drage-sip-essential-correction-02.txt (work in progress),
November 2007.
Appendix A. Editorial guidance (non-normative)
This document is intended to update RFC 3261 in accordance with the
SIP Working Group procedures described in [12] or its successor.
This appendix provides guidance to the editor of the next
comprehensive update to RFC 3261 [2] on how to incorporate the
changes provided by this document.
A.1. Additions
The content of sections Section 4 through Section 7 inclusive can be
incorporated as subsections within a section that describes SIP
domain authentication.
The contents of Section 8.1 can be incorporated into the Security
Considerations section of the new document.
All normative references from this document can be carried forward to
the successor document.
A.2. Changes
The following subsections describe changes in specific sections of
RFC 3261 [2] 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 Appendix A.1.
A.2.1. 26.3.1
The current text says:
Proxy servers, redirect servers and registrars SHOULD possess a
site certificate whose subject corresponds to their canonical
hostname.
The suggested replacement for the above is:
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 a SIP domain as
Gurbani, et al. Expires April 9, 2009 [Page 15]
Internet-Draft Domain Certs October 2008
described in <domain-authentication>.
Authors' Addresses
Vijay K. Gurbani
Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane
Room 9C-533
Naperville, IL 60566
USA
Phone: +1 630 224-0216
Email: vkg@alcatel-lucent.com
Scott Lawrence
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821
USA
Phone: +1 978 248 5508
Email: scott.lawrence@nortel.com
Alan S.A. Jeffrey
Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane
Room 9C-533
Naperville, IL 60566
USA
Email: ajeffrey@alcatel-lucent.com
Gurbani, et al. Expires April 9, 2009 [Page 16]
Internet-Draft Domain Certs October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Gurbani, et al. Expires April 9, 2009 [Page 17]