doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

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 <domain-authentication> 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]
+