From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5922.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc5922.txt (limited to 'doc/rfc/rfc5922.txt') diff --git a/doc/rfc/rfc5922.txt b/doc/rfc/rfc5922.txt new file mode 100644 index 0000000..c78360c --- /dev/null +++ b/doc/rfc/rfc5922.txt @@ -0,0 +1,955 @@ + + + + + + +Internet Engineering Task Force (IETF) V. Gurbani +Request for Comments: 5922 Bell Laboratories, Alcatel-Lucent +Updates: 3261 S. Lawrence +Category: Standards Track +ISSN: 2070-1721 A. Jeffrey + Bell Laboratories, Alcatel-Lucent + June 2010 + + + Domain Certificates in the Session Initiation Protocol (SIP) + +Abstract + + This document describes how to construct and interpret certain + information in a PKIX-compliant (Public Key Infrastructure using + X.509) certificate for use in a Session Initiation Protocol (SIP) + over Transport Layer Security (TLS) connection. More specifically, + this document describes how to encode and extract the identity of a + SIP domain in a certificate and how to use that identity for SIP + domain authentication. As such, this document is relevant both to + implementors of SIP and to issuers of certificates. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5922. + + + + + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 1] + +RFC 5922 Domain Certs June 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................3 + 2.1. Key Words ..................................................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 ........................................8 + 7.1. Finding SIP Identities in a Certificate ....................8 + 7.2. Comparing SIP Identities ...................................9 + 7.3. Client Behavior ...........................................10 + 7.4. Server Behavior ...........................................11 + 7.5. Proxy Behavior ............................................12 + 7.6. Registrar Behavior ........................................12 + 7.7. Redirect Server Behavior ..................................12 + 7.8. Virtual SIP Servers and Certificate Content ...............12 + 8. Security Considerations ........................................13 + 8.1. Connection Authentication Using Digest ....................13 + 9. Acknowledgments ................................................14 + 10. References ....................................................14 + 10.1. Normative References .....................................14 + 10.2. Informative References ...................................15 + Appendix A. Editorial Guidance (Non-Normative) ...................16 + A.1. Additions .................................................16 + A.2. Changes ...................................................16 + A.2.1. Changes to Section 26.3.1 .............................16 + + + + + + + + +Gurbani, et al. Standards Track [Page 2] + +RFC 5922 Domain Certs June 2010 + + +1. Introduction + + RFC 5246 [5] Transport Layer Security (TLS) is available 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, see RFC 5280 [6], 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 + Secure/Multipurpose Internet Mail Extensions (S/MIME)). + +2. Terminology + +2.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. + +3. Problem Statement + + TLS uses RFC 5280 [6] X.509 Public Key Infrastructure to bind an + identity or a set of identities, to the subject of an X.509 + certificate. While RFC 3261 provides adequate guidance on the use of + X.509 certificates for S/MIME, it is relatively silent on the use of + such certificates for TLS. With respect to certificates for TLS, RFC + 3261 (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. Standards Track [Page 3] + +RFC 5922 Domain Certs June 2010 + + + 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 RFC 3261 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 RFC 3261 on exactly where to put identities -- in the + subjectAltName field or carried as a Common Name (CN) in the Subject + field -- of an X.509 certificate 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 RFC + 3261 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. Standards Track [Page 4] + +RFC 5922 Domain Certs June 2010 + + +4. SIP Domain to Host Resolution + + Routing in SIP is performed by having the client execute RFC 3263 [8] + procedures on a URI, called the "Application Unique String (AUS)" + (c.f. Section 8 of RFC 3263 [8]). These procedures take as input a + SIP AUS (the SIP URI), extract the domain portion of that URI for use + as a lookup key, and query the Domain Name Service (DNS) to obtain an + ordered set of one or more IP addresses with a port number and + transport corresponding to each IP address in the set (the "Expected + Output"). If the transport indicates the use of TLS, then a TLS + connection is opened to the server on a specific IP address and port. + The server presents an X.509 certificate to the client for + verification as part of the initial TLS handshake. + + The client extracts identifiers from the Subject and any + subjectAltName extension in the certificate (see Section 7.1) and + compares these values to the domain part extracted from the original + SIP URI (the AUS). If any identifier match is found, the server is + considered to be authenticated and subsequent signaling can now + proceed over the TLS connection. Matching rules for X.509 + certificates and the normative behavior for clients is specified in + 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" (the 'sips' scheme + mandates a secure connection). Through a series of DNS + manipulations, the domain name is mapped to a set of host addresses + and transports. The entity attempting to create the connection + selects an address appropriate for use with TLS from this set. When + the connection is established to that server, the server presents a + certificate asserting the identity "sip:example.com". Since the + domain part of the SIP AUS matches the subject of the certificate, + the server is authenticated (see Section 7.2 for the normative rules + that govern this comparison). + + Session Initiation Protocol Secure (SIPS) borrows this pattern of + server certificate matching from HTTPS. However, RFC 2818 [7] + 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. Sections 6 and 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 + + + +Gurbani, et al. Standards Track [Page 5] + +RFC 5922 Domain Certs June 2010 + + + 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. + + Proxy-A.example.com Proxy-B.example.net + +-------+ +-------+ + | Proxy |--------------------| Proxy | + +----+--+ +---+---+ + | | + | | + | | + | +---+ + 0---0 | | + /-\ |___| + +---+ / / + +----+ + alice@example.com bob@example.net + + Figure 1: SIP Trapezoid + + A 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 [8] 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, RFC 3261 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. + + + + + + + + +Gurbani, et al. Standards Track [Page 6] + +RFC 5922 Domain Certs June 2010 + + + The authentication problem for Proxy-A is straightforward: in the + certificate Proxy-A receives from Proxy-B, Proxy-A looks for an + identity that is a SIP URI ("sip:example.net") or a DNS name + ("example.net") that asserts Proxy-B's authority over the example.net + domain. Normative behavior for a TLS client like Proxy-A is + specified in Section 7.3. + + The problem for Proxy-B is slightly more complex since it accepts 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 + + It is possible for service providers to continue the practice of + using existing certificates for SIP usage with the identity conveyed + only in the Subject field, but they should carefully consider the + following advantages of conveying identity in the subjectAltName + extension field: + + o The subjectAltName extension can hold multiple values, so the same + certificate can identify multiple servers or sip domains. + + o There is no fixed syntax specified for the Subject field, so + issuers vary in how the field content is set. This forces a + recipient to use heuristics to extract the identity, again + increasing opportunities for misinterpretation. + + Because of these advantages, service providers are strongly + encouraged to obtain certificates that 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 domain used to reach the server + appears as an identity in the subjectAltName field, or for + compatibility with existing certificates, the Subject field of the + certificate. In practice, this means that a service provider + + + +Gurbani, et al. Standards Track [Page 7] + +RFC 5922 Domain Certs June 2010 + + + 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. + + The first two subsections apply to all SIP implementations that use + TLS to authenticate the peer: Section 7.1 describes how to extract a + set of SIP identities from the certificate obtained from a TLS peer, + and Section 7.2 specifies how to compare SIP identities. The + remaining subsections provide context for how and when these rules + are to be applied by entities in different SIP roles. + +7.1. Finding SIP Identities in a Certificate + + Implementations (both clients and server) MUST determine the validity + of a certificate by following the procedures described in RFC 5280 + [6]. + + As specified by RFC 5280 [6], Section 4.2.1.12, implementations MUST + check for restrictions on certificate usage declared by any + extendedKeyUsage extensions in the certificate. The SIP Extended Key + Usage (EKU) document [12] 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 might contain identities not acceptable as SIP, domain + identities and/or might contain one or more identities that are + acceptable for use as SIP domain identities. + + 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 [6]. 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 + implementation MUST NOT accept the value as a SIP domain + identity. + + + + + +Gurbani, et al. Standards Track [Page 8] + +RFC 5922 Domain Certs June 2010 + + + If the scheme of the URI value is "sip", and the URI value + that contains a userpart (there is an '@'), the + implementation MUST NOT accept the value as a SIP domain + identity (a value with a userpart identifies an individual + user, not a domain). + + If the scheme of the URI value is "sip", and there is no + userinfo component in the URI (there is no '@'), then the + implementation MUST accept the hostpart as a SIP domain + identity. + + Note: URI scheme tokens are always case insensitive. + + DNS An implementation MUST accept a domain name system + identifier as a SIP domain identity if and only if no other + identity is found that matches the "sip" URI type described + above. + + 2. If and only if the subjectAltName does not appear in the + certificate, the implementation MAY examine the CN field of the + certificate. If a valid DNS name is found there, the + implementation MAY accept this value as a SIP domain identity. + Accepting a DNS name in the CN value is allowed for backward + compatibility, but when constructing new certificates, consider + the advantages of using the subjectAltName extension field (see + 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 an implementation (either client or server) compares two values + as SIP domain identities: + + Implementations MUST compare only the DNS name component of each + SIP domain identifier; an implementation MUST NOT use any scheme + or parameters in the comparison. + + Implementations MUST compare the values as DNS names, which means + that the comparison is case insensitive as specified by RFC 4343 + [3]. Implementations MUST handle Internationalized Domain Names + (IDNs) in accordance with Section 7.2 of RFC 5280 [6]. + + + + + + +Gurbani, et al. Standards Track [Page 9] + +RFC 5922 Domain Certs June 2010 + + + Implementations MUST match the values in their entirety: + + Implementations MUST NOT match suffixes. For example, + "foo.example.com" does not match "example.com". + + Implementations MUST NOT match any form of wildcard, such as a + leading "." or "*." with any other DNS label or sequence of + labels. For example, "*.example.com" matches only + "*.example.com" but not "foo.example.com". Similarly, + ".example.com" matches only ".example.com", and does not match + "foo.example.com". + + RFC 2818 [7] (HTTP over TLS) allows the dNSName component to + contain a wildcard; e.g., "DNS:*.example.com". RFC 5280 + [6], 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. + +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 + [8] 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 domain extracted from the AUS matches any SIP domain + identity obtained from the certificate when compared as described + in Section 7.2, the server is authenticated for the domain. + + If the server is not authenticated, the client MUST close the + connection immediately. + + + + + + +Gurbani, et al. Standards Track [Page 10] + +RFC 5922 Domain Certs June 2010 + + +7.4. Server Behavior + + When a server accepts a TLS connection, the server presents its own + X.509 certificate to the client. Servers that wish to authenticate + the client will ask the client for a certificate. If the client + possesses a certificate, that certificate is presented to the server. + If the client does not present a certificate, the client MUST NOT be + considered authenticated. + + 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 local server policy requires client authentication for some + local purpose, then one element of such a local policy might be to + allow the connection only if the client is authenticated. For + example, if the server is an inbound proxy that has peering + relationships with the outbound proxies of other specific domains, + the server might allow only connections authenticated as coming + from those domains. + + When authenticating 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 an X.509 + certificate and validate the certificate using the procedures in RFC + 5280 [6]. 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. + + + + + + + + +Gurbani, et al. Standards Track [Page 11] + +RFC 5922 Domain Certs June 2010 + + + 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 [10] document 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. + +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 [9]. 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 "server_name" extension as + defined in RFC 4366 [4] is supported, the client SHOULD use that + extension to request a certificate corresponding to the specific + domain (from the SIP AUS) with which the client is seeking to + establish a connection. + + + +Gurbani, et al. Standards Track [Page 12] + +RFC 5922 Domain Certs June 2010 + + +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, and has no provision for binding the + authentication to any attribute of the transport. Many existing SIP + deployments have chosen to use the Digest authentication of one or + + + +Gurbani, et al. Standards Track [Page 13] + +RFC 5922 Domain Certs June 2010 + + + more messages on a particular transport connection as a way to + authenticate the connection itself -- by implication, authenticating + other (unauthenticated) messages on that connection. Some even + choose to similarly authenticate a UDP source address and port based + on the digest authentication of another message received from that + address and port. This use of digest goes beyond the assurances that + the Digest Authentication mechanism was designed to provide. A SIP + implementation SHOULD NOT use the Digest Authentication of one + message on a TCP connection or from a UDP peer to infer any + authentication of any other messages on that connection or from that + peer. Authentication of the domain at the other end of a connection + SHOULD be accomplished using TLS and the certificate validation rules + described by this specification instead. + +9. 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, and Russ Housley. Special acknowledgement goes + to Stephen Kent for extensively reviewing document versions and + suggesting invaluable feedback, edits, and comments. + + Paul Hoffman, Eric Rescorla, and Robert Sparks provided many valuable + WGLC comments. + +10. References + +10.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, 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] Eastlake, D., "Domain Name System (DNS) Case Insensitivity + Clarification", RFC 4343, January 2006. + + [4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and + T. Wright, "Transport Layer Security (TLS) Extensions", + RFC 4366, April 2006. + + [5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) + Protocol Version 1.2", RFC 5246, August 2008. + + + + + +Gurbani, et al. Standards Track [Page 14] + +RFC 5922 Domain Certs June 2010 + + + [6] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, + R., and W. Polk, "Internet X.509 Public Key Infrastructure + Certificate and Certificate Revocation List (CRL) Profile", + RFC 5280, May 2008. + +10.2. Informative References + + [7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [8] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol + (SIP): Locating SIP Servers", RFC 3263, June 2002. + + [9] Peterson, J. and C. Jennings, "Enhancements for Authenticated + Identity Management in the Session Initiation Protocol (SIP)", + RFC 4474, August 2006. + + [10] Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in the + Session Initiation Protocol", RFC 5923, June 2010. + + [11] Drage, K., "A Process for Handling Essential Corrections to the + Session Initiation Protocol (SIP)", Work in Progress, + July 2008. + + [12] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU) + for Session Initiation Protocol (SIP) X.509 Certificates", + RFC 5924, June 2010. + + + + + + + + + + + + + + + + + + + + + + + + + +Gurbani, et al. Standards Track [Page 15] + +RFC 5922 Domain Certs June 2010 + + +Appendix A. Editorial Guidance (Non-Normative) + + This document is intended to update RFC 3261 in accordance with the + SIP Working Group procedures described in [11] 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 4 through 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 + its successor. + +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 is a reference to the + section added as described in Appendix A.1. + +A.2.1. Changes to Section 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 subjects include the name of + that SIP domain. + + + + + + + + +Gurbani, et al. Standards Track [Page 16] + +RFC 5922 Domain Certs June 2010 + + +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 + + EMail: scott-ietf@skrb.org + + + 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. Standards Track [Page 17] + -- cgit v1.2.3