Domain Certificates in the Session Initiation Protocol (SIP)
DOCNAME

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.

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 for SIP domain authentication.

Table of Contents

1.  Terminology
    1.1.  Key Words
2.  Introduction
3.  Problem statement
4.  SIP domain to host resolution
5.  The need for mutual interdomain authentication
6.  Certificate usage by a SIP service provider
7.  Behavior of SIP entities
    7.1.  Finding SIP Identities in a Certificate
    7.2.  Comparing SIP Identities
    7.3.  Client behavior
    7.4.  Server behavior
    7.5.  Proxy behavior
    7.6.  Registrar behavior
    7.7.  Redirect server behavior
    7.8.  Virtual SIP Servers and Certificate Content
8.  Security Considerations
    8.1.  Connection authentication using Digest
9.  IANA Considerations
10.  Acknowledgments
11.  References
    11.1.  Normative References
    11.2.  Informative References
Appendix A.  Editorial guidance (non-normative)
    A.1.  Additions
    A.2.  Changes
        A.2.1.  26.3.1
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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 (Dierks, T. and E. Rescorla, “The TLS Protocol Version 1.1,” April 2006.) [3] Transport Layer Security (TLS) has started to appear in an increasing number of Session Initiation Protocol (SIP) RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [2] implementations. In order to use the authentication capabilities of TLS, certificates as defined by the Internet X.509 Public Key Infrastructure RFC 5280 (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,” May 2008.) [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 (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,” May 2008.) [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."

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 (The need for mutual interdomain authentication) 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 (Certificate usage by a SIP service provider) outlines normative guidelines for a service provider assigning certificates to SIP servers. Section 7 (Behavior of SIP entities) 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 (Security Considerations) includes the security considerations.

4.  SIP domain to host resolution

Routing in SIP is performed by having the client execute RFC 3263 (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Location SIP Servers,” June 2002.) [7] procedures on a URI, called the "Application Unique String (AUS) (c.f. Section 8 of RFC 3263 (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Location SIP Servers,” June 2002.) [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 (Finding SIP Identities in a Certificate)) 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 (Client behavior).

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 (Comparing SIP Identities) for the normative rules that govern this comparison)

SIPS borrows this pattern of server certificate matching from HTTPS. However, RFC 2818 (Rescorla, E., “HTTP Over TLS,” May 2000.) [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 (Certificate usage by a SIP service provider), Section 7.1 (Finding SIP Identities in a Certificate)).

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".

5.  The need for mutual interdomain authentication

Consider the SIP trapezoid shown in Figure 1 (SIP Trapezoid).

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

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 (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Location SIP Servers,” June 2002.) [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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [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 over the example.net domain. Normative behavior for a TLS client like Proxy-A is specified in Section 7.3 (Client behavior).

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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [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 (Server behavior).

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 checking revocation status described in RFC 5280 (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,” May 2008.) [4]. This document adds additional rules for interpreting an X.509 certificate for use in SIP.

As specified by RFC 5280 (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,” May 2008.) [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 (Lawrence, S. and V. Gurbani, “Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates,” February 2008.) [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 (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,” May 2008.) [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.
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 (Certificate usage by a SIP service provider).

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 (Client behavior)) and a server uses them to authenticate a client (see Section 7.4 (Server behavior)).

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 (Eastlake, D., “Domain Name System (DNS) Case Insensitivity Clarification,” January 2006.) [6]. Internationalized Domain Names (IDNs) MUST be handled in accordance with Section 7.2 of RFC 5280 (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,” May 2008.) [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 (Rescorla, E., “HTTP Over TLS,” May 2000.) [8] (HTTP over TLS) allows the dNSName component to contain a wildcard; e.g., "DNS:*.example.com". RFC 5280 (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,” May 2008.) [4], while not disallowing this explicitly, leaves the interpretation of wildcards to the individual specification. RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [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.

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 (SIP domain to host resolution) 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 (Finding SIP Identities in a Certificate). Then, the client MUST compare the original domain portion of the SIP AUS used as input to the RFC 3263 (Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Location SIP Servers,” June 2002.) [7] server location procedures to the SIP domain identities obtained from the certificate.

• If there were no identities found in the server certificate, the server is not authenticated.
• If the AUS matches any SIP domain identity obtained from the certificate when compared as described in section Section 7.2 (Comparing SIP Identities), 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 (Connection authentication using Digest)).

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.

To authenticate the client, the server MUST obtain the set of SIP domain identities from the client certificate as described in Section 7.1 (Finding SIP Identities in a Certificate). 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 (Finding SIP Identities in a Certificate) 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 (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,” May 2008.) [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 (Mahy, R., Gurbani, V., and B. Tate, “Connection Reuse in the Session Initiation Protocol,” October 2007.) [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 (Server behavior) when authenticating a connection from a client.

A proxy MUST use the procedures defined for a User Agent Client (UAC) in Section 7.3 (Client behavior) 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 (Server behavior). 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.

7.7.  Redirect server behavior

A SIP redirect server follows the normative behavior of a UAS as specified in Section 7.4 (Server behavior).

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 (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) [10]. Clients seeking to authenticate a server on such a virtual host can still follow the directions in Section 7.3 (Client behavior) to find the identity matching the SIP AUS used to query DNS.

Alternatively, if the TLS client hello extension as defined in RFC 4366 (Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, “Transport Layer Security (TLS) Extensions,” April 2006.) [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.

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 WGLC comments.

11.  References

11.1. Normative References

11.2. Informative References

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] (Drage, K., “A Process for Handling Essential Corrections to the Session Initiation Protocol (SIP),” November 2007.) or its successor.

This appendix provides guidance to the editor of the next comprehensive update to RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [2] on how to incorporate the changes provided by this document.

A.1.  Additions

The content of sections Section 4 (SIP domain to host resolution) through Section 7 (Behavior of SIP entities) inclusive can be incorporated as subsections within a section that describes SIP domain authentication.

The contents of Section 8.1 (Connection authentication using Digest) 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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [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 (Additions).

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 described in <domain-authentication>.

Authors' Addresses

Full Copyright Statement

Copyright © 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.