SIP WG                                                        V. Gurbani
Internet-Draft                         Bell Laboratories, Alcatel-Lucent
Updates:  rfc3261                                            S. Lawrence
(if approved)                                            Bluesocket Inc.
Intended status:  Standards Track                             A. Jeffrey
Expires:  January 15, 2009             Bell Laboratories, Alcatel-Lucent
                                                           July 14, 2008

      Domain Certificates in the Session Initiation Protocol (SIP)

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 15, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).


   This document describes how to interpret certain information in a
   X.509 PKIX-compliant certificate used in a Session Initiation
   Protocol (SIP) over Transport Layer Security (TLS) connection.  More
   specifically, it describes how to find the right identity for
   authentication in such certificates and how to use it for SIP domain

Gurbani, et al.         Expires January 15, 2009                [Page 1]

Internet-Draft                Domain Certs                     July 2008


Table of Contents

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

Gurbani, et al.         Expires January 15, 2009                [Page 2]

Internet-Draft                Domain Certs                     July 2008

1.  Terminology

1.1.  Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [1].

   Additional definition(s):

   SIP domain identity:  An identity (e.g., "") contained
      in an X.509 certificate bound to a subject that identifies the
      subject as an authoritative SIP server for a domain.

2.  Introduction

   Transport Layer Security (TLS) [3] has started to appear in an
   increasing number of Session Initiation Protocol (SIP) [2]
   implementations.  In order to use the authentication capabilities of
   TLS, certificates as defined by the Internet X.509 Public Key
   Infrastructure RFC 5280 [4] are required.

   Existing SIP specifications do not sufficiently specify how to use
   certificates for domain (as opposed to host) authentication.  This
   document provides guidance to ensure interoperability and uniform
   conventions for the construction and interpretation of certificates
   used to identify their holders as being authoritative for the domain.

   The discussion in this document is pertinent to an X.509 PKIX-
   compliant certificate used for a TLS connection; it may not apply to
   use of such certificates with S/MIME, for instance.

3.  Problem statement

   TLS uses X.509 Public Key Infrastructure [4] to bind an identity or a
   set of identities, to the subject of a X.509 certificate.
   Accordingly, the recommendations of the SIP working group have been
   to populate the X.509v3 Subject Alternative Names (subjectAltName, or
   SAN) extension with an identity.  While RFC3261 provides adequate
   guidance on the use of X.509 certificates used for S/MIME, it is
   relatively silent on the use of such certificates for TLS.  The
   concept of what should be contained in a site (or domain) certificate
   in RFC3261 is quoted below (Section 26.3.1):

Gurbani, et al.         Expires January 15, 2009                [Page 3]

Internet-Draft                Domain Certs                     July 2008

      Proxy servers, redirect servers and registrars SHOULD possess a
      site certificate whose subject corresponds to their canonical

   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.  It also contains normative behavior for matching the
   DNS query string with an identity stored in the X.509 certificate.
   Furthermore, it is permissible for a certificate to contain multiple
   identities for the subject in the subjectAltName extension (the
   "subject" of a certificate identifies the entity associated with the
   public key stored in the public key field.)  As such, this document
   specifies appropriate matching rules to encompass various subject
   identity representation options.  And finally, this document also
   provides guidelines to service providers for assigning certificates
   to SIP servers.

   The rest of this document is organized as follows:  the next section
   provides an overview of the most primitive case of a client using DNS
   to access a SIP server and the resulting authentication steps.
   Section 5 looks at the reason why mutual inter-domain authentication
   is desired in SIP, and the lack of normative text and behavior in
   RFC3261 for doing so.  Section 6 outlines normative guidelines for a
   service provider when it is assigning certificates to SIP servers.
   Section 7 provides normative behavior on the SIP entities (user agent
   clients, user agent servers, registrars, redirect servers, and
   proxies) that need perform authentication based on X.509
   certificates.  Section 8 includes the security considerations.

Gurbani, et al.         Expires January 15, 2009                [Page 4]

Internet-Draft                Domain Certs                     July 2008

4.  SIP domain to host resolution

   Routing in SIP is performed by having the client execute RFC 3263 [6]
   procedures on a URI, called the "Application Unique String (AUS)
   (c.f.  Section 8 of RFC 3263 [6]).  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 should extract identifiers from the Subject and
   subjectAltName extension in the certificate (see Section 7.1) and
   compare these values to the AUS.  If any identifier match is found,
   the server is considered to be authenticated and subsequent signaling
   can now proceed over the TLS connection.  Matching rules for X.509
   certificates and the normative behavior for clients is specified in
   Section 7.3.

   As an example, consider a request that is to be routed to the SIP
   address "".  This address requires a secure
   connection to the SIP domain "", which is taken to be the
   SIP AUS value.  Through a series of DNS manipulations, the AUS is
   mapped to a set of host addresses and transports.  From this set, an
   address appropriate for use with TLS is selected.  A connection is
   subsequently established to that server, which presents a certificate
   asserting an identity of "".  Since the host portion
   of the SIP AUS matches the subject of the certificate, the server is
   considered to be authenticated.

      SIPS borrows this behavior from HTTPS.  However, to be pedantic,
      RFC 2818 [7] prefers that the identity be conveyed as a
      subjectAltName extension of type dNSName instead of the commonly
      used practice of conveying the identity in the CN field of the
      Subject field.  Similarly, this document RECOMMENDS that the SIP
      domain identity be conveyed as a subjectAltName extension of type
      uniformResourceIdentifier (c.f.  Section 6, Section 7.1).

      A domain name in an X.509 certificates is properly interpreted
      only as a sequence of octets to be compared to the URI used to
      reach the host.  No inference should be made based on the DNS name

Gurbani, et al.         Expires January 15, 2009                [Page 5]

Internet-Draft                Domain Certs                     July 2008

5.  The need for mutual interdomain authentication

   Consider the SIP trapezoid shown in Figure 1. 
        +-------+                    +-------+
        | Proxy |--------------------| Proxy |
        +----+--+                    +---+---+
             |                           |
             |                           |
             |                           |
             |                         +---+
           0---0                       |   |
            /-\                        |___|
           +---+                      /    /

                          Figure 1: SIP Trapezoid

   An user,, invites for a multimedia
   communication session.  Alice's outbound proxy,,
   uses normal RFC 3263 [6] resolution rules to find a proxy -- Proxy- -- in the 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 "Interdomain Requests" states that when
   a TLS connection is created between two proxies, mutual TLS
   authentication should follow whereby

      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

   However, RFC3261 is silent on where in the certificate should the
   domain name be retrieved from (SAN or CN?) and which name takes
   precedence when there are multiple names identifying the holder of
   the certificate.

   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 domain.
   Thus, in the certificate it receives from Proxy-B, Proxy-A should
   look for the host name ("") or an identity

Gurbani, et al.         Expires January 15, 2009                [Page 6]

Internet-Draft                Domain Certs                     July 2008

   consisting of a SIP URI ("") that asserts Proxy-B's
   authority over the domain.  Normative behavior for a TLS
   client like Proxy-A is specified in Section 7.3.

   The problem for Proxy-B is slightly more complex since it accepted
   the TLS request passively.  Thus, it 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 only exhorts Proxy-B to "compare the
      domain asserted by the certificate with the 'domainname' portion
      of the From header field in the INVITE request."  The difficulty
      with this approach is that it is not always the case that the
      domainname in From corresponds to the domain from which the
      request is being received.

   The normative behavior for a TLS server like Proxy-B that passively
   accept TLS connections and requires authentication of the sending
   peer is provided in Section 7.4.

6.  Guidelines for 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 proxy servers, registrars, and
   redirect servers, a SIP service provider MUST ensure that the SIP AUS
   used to reach the server appears as an identity in the subjectAltName
   field, or for compatibility with existing certificates, the Subject
   field of the certificate.  In practice, this means that a service
   provider distributes to its users SIP URIs whose domain portion
   corresponds to an identity for which the service provider has been
   issued a certificate.

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

Gurbani, et al.         Expires January 15, 2009                [Page 7]

Internet-Draft                Domain Certs                     July 2008

7.1.  Finding SIP Identities in a Certificate

   Procedures for constructing a certificate path and checking
   revocation status to determine the validity of a certificate are
   described in RFC 5280 [4]; implementations MUST follow checks as
   prescribed therein.  This document adds additional rules for
   interpreting an X.509 certificate for use in SIP.

   The SIP Extended Key Usage (EKU) document [5] describes the method to
   validate EKU values found in the certificate used for SIP.  If a
   certificate has a SIP EKU value specified, implementations MUST
   perform the checks prescribed by that specification.

   Given an X.509 certificate that the above checks have found to be
   acceptable, the following describes how to determine what SIP domain
   identity or identities it contains.  Note that a single certificate
   MAY serve more than one purpose - that is, it MAY contain identities
   not valid for use in SIP, and/or MAY contain one or more identities
   that are valid for use in SIP.

   1.  Examine the values in the subjectAltName field.  The contents of
       subjectAltName field and the constraints that may be imposed on
       them are defined in Section of RFC 5280 [4].  The
       subjectAltName field may not be present or it may contain one or
       more identities.  Each value in the subjectAltName has a type;
       the only types acceptable for encoding a SIP domain identity are:

       URI  If the scheme of the URI value is "sip" (URI scheme tokens
          are always case insensitive), and there is no userinfo
          component in the URI (there is no '@'), then the hostpart is a
          SIP domain identity.  A URI value that does contain a userpart
          MUST NOT be used as a domain identity (such a certificate
          identifies an individual user, not a server for the domain).

          If the scheme of the URI is not "sip", then the identity
          corresponding to that scheme MUST NOT be used as a SIP domain

       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 use this value as a SIP domain identity.  The
       use of the CN value is allowed for backward compatibility, but is
       NOT RECOMMENDED.  Service providers who are applying for new

Gurbani, et al.         Expires January 15, 2009                [Page 8]

Internet-Draft                Domain Certs                     July 2008

       X.509 certificates to be used with SIP SHOULD follow the
       guidelines of Section 6.

   The above procedure yields a set containing zero or more identities
   from the certificate.  A client uses these identities to authenticate
   a server (see Section 7.3) and a server uses them to authenticate a
   client (see Section 7.4).

7.2.  Comparing SIP Identities

   When comparing two values as SIP domain identities:

      Implementations MUST compare only that part of each identifier
      (from the procedure defined in Section 7.1) that is a DNS name.
      Any scheme or parameters extracted from an identifier MUST NOT be
      used in the comparison procedure described below.

      The values MUST be compared as DNS names, which means that the
      comparison is case insensitive.  Internationalized Domain Names
      (IDNs) must be handled in accordance with Section 7.2 of RFC 5280

      The match MUST be exact:

         A suffix match MUST NOT be considered a match.  For example,
         "" does not match "".

         Any form of wildcard, such as a leading "." or "*.", MUST NOT
         be considered a match.  For example, "" does not
         match "" or "*".

            RFC 2818 (HTTP over TLS) [7] allows the dNSName component to
            contain a wildcard; e.g., "DNS:*".  RFC 5280
            [4], while not disallowing this explicitly, leaves the
            interpretation of wildcards to the individual specification.
            RFC 3261 [2] does not provide any guidelines on the presence
            of wildcards in certificates.  This document reflects the
            consensus from the working group to not allow such

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

   The SIP server, when establishing a TLS connection, presents its

Gurbani, et al.         Expires January 15, 2009                [Page 9]

Internet-Draft                Domain Certs                     July 2008

   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 server
   location procedures [6] to the SIP domain identities obtained from
   the certificate.

   o  If there were no identities found in the server certificate, the
      server is not authenticated.

   o  If the AUS matches any SIP domain identity obtained from the
      certificate when compared as described in section Section 7.2, the
      server is authenticated for the domain.

   If the server is not authenticated, the client MUST close the
   connection immediately.

7.4.  Server behavior

   When a server accepts a TLS connection, it presents its own X.509
   certificate to the client.  To authenticate the client, the server
   asks the client for a certificate.  If the client possesses a
   certificate, it is presented to the server.  If the client does not
   present a certificate, it MUST NOT be considered authenticated.

      Whether or not to close a connection if the client cannot present
      a certificate is a matter of local policy, and depends on the
      authentication needs of the server for the connection.  Some
      currently deployed servers use Digest authentication to
      authenticate individual requests on the connection, and choose to
      treat the connection as authenticated by those requests for some
      purposes (but see Section 8.1).

      If the server requires client authentication for some local
      purpose, then it MAY implement a policy of allowing the connection
      only if the client is authenticated.  For example, if the server
      is an inbound proxy that has peering relationships with the
      outbound proxies of other specific domains, it might only allow
      connections authenticated as coming from those domains.

   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, it does not
   possess an AUS for comparison.  Nonetheless, server policies can use
   the set of SIP domain identities gathered from the certificate in
   Section 7.1 to make authorization decisions.

   For example, a very open policy could be to accept a X.509

Gurbani, et al.         Expires January 15, 2009               [Page 10]

Internet-Draft                Domain Certs                     July 2008

   certificate and validate it using the procedures in RFC 5280 [4].  If
   the certificate is valid, the identity set is logged.  Alternatively,
   the server could have a list of all SIP domains it is allowed to
   accept connections from; when a client presents its certificate, for
   each identity in the client certificate, the server searches for it
   in the list of acceptable domains to decide whether or not to accept
   the connection.  Other policies that make finer distinctions are

   Note that the decision of whether or not the authenticated connection
   to the client is appropriate for use to route new requests to the
   client domain is independent of whether or not the connection is
   authenticated; the connect-reuse [10] draft discusses this aspect in
   more detail.

7.5.  Proxy behavior

   A proxy MUST use the procedures defined for a User Agent Server (UAS)
   in Section 7.4 when authenticating a connection from a client.

   A proxy MUST use the procedures defined for a User Agent Client (UAC)
   in Section 7.3 when requesting an authenticated connection to a UAS.

   If a proxy adds a Record-Route when forwarding a request with the
   expectation that the route is to use secure connections, it MUST
   insert into the Record-Route header a URI that corresponds to an
   identity for which it has a certificate; if it does not, then it will
   not be possible to create a secure connection using the value from
   the Record-Route as the AUS.

7.6.  Registrar behavior

   A SIP registrar, acting as a server, follows the normative behavior
   of Section 7.4.  When it accepts a TLS connection from the client, it
   present its certificate.  Depending on the registrar policies, it may
   challenge the client with HTTP Digest.

7.7.  Redirect server behavior

   A SIP redirect server follows the normative behavior of Section 7.4.
   When it accepts a TLS connection from the client, it present its
   certificate.  Depending on the server policies, it may challenge the
   client with HTTP Digest.

7.8.  Virtual SIP Servers and Certificate Content

   In the "virtual hosting" cases where multiple domains are managed by
   a single application, a certificate may contain multiple subjects by

Gurbani, et al.         Expires January 15, 2009               [Page 11]

Internet-Draft                Domain Certs                     July 2008

   having distinct identities in the subjectAltName field [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 extension [8] is supported,
   the client SHOULD use it to request a certificate corresponding to
   the specific domain (the SIP AUS) that the client is seeking to
   establish a connection with.

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

   We expect appropriate processing of domain certificates to provide
   the following security guarantees at the application level:

   Confidentiality:  SIPS messages from to can be read only by,, and SIP proxies issued with domain certificates
      for or

   Integrity:  SIPS messages from to
      cannot be undetectably modified on the links between,, and SIP proxies issued with
      domain certificates for or

   Authentication: and are mutually
      authenticated; moreover is authenticated to as an authoritative proxy for domain  Similar mutual authentication guarantees are given
      between and and between and  As a result, is transitively mutually authenticated to

Gurbani, et al.         Expires January 15, 2009               [Page 12]

Internet-Draft                Domain Certs                     July 2008 (assuming trust in the authoritative proxies for and

8.1.  Connection authentication using Digest

   Digest authentication in SIP provides for authentication of the
   message sender to the challenging UAS.  As commonly deployed, it
   provides only very limited integrity protection of the authenticated
   message.  Many existing deployments have chosen to use the Digest
   authentication of one or more messages on a particular connection as
   a way to authenticate the connection itself - and by implication,
   authenticating other (unchallenged) messages on that connection.
   Some even choose to similarly authenticate a UDP source address and
   port based on the Digest authentication of a message received from
   that address and port.  This use of Digest goes beyond the assurances
   it was designed to provide, and is NOT RECOMMENDED.  Authentication
   of the domain at the other end of a connection SHOULD be accomplished
   using TLS and the certificate validation rules described by this
   specification instead.

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

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, March 1997.

   [2]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:

Gurbani, et al.         Expires January 15, 2009               [Page 13]

Internet-Draft                Domain Certs                     July 2008

         Session Initiation Protocol", RFC 3261, June 2002.

   [3]   Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
         RFC 4346, April 2006.

   [4]   Cooper, D., Santesson, S., Farrell, S., Boyen, S., Housley, R.,
         and W. Polk, "Internet X.509 Public Key Infrastructure
         Certificate and Certificate Revocation List (CRL) Profile",
         RFC 5280, May 2008.

   [5]   Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU)
         for Session Initiation Protocol (SIP) X.509 Certificates",
         draft-ietf-sip-eku-01.txt (work in progress), February 2008.

11.2.  Informative References

   [6]   Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
         (SIP): Location SIP Servers", RFC 3263, June 2002.

   [7]   Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [8]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
         T. Wright, "Transport Layer Security (TLS) Extensions",
         RFC 4366, April 2006.

   [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",
         draft-ietf-sip-connect-reuse-08.txt (work in progress),
         October 2007.

   [11]  Drage, K., "A Process for Handling Essential Corrections to the
         Session Initiation  Protocol (SIP)",
         draft-drage-sip-essential-correction-02.txt (work in progress),
         November 2007.

Appendix A.  Editorial guidance (non-normative)

   This document is intended to update RFC 3261 in accordance with the
   SIP Working Group procedures described in [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.

Gurbani, et al.         Expires January 15, 2009               [Page 14]

Internet-Draft                Domain Certs                     July 2008

A.1.  Additions

   The content of sections Section 4 through Section 7 inclusive can be
   incorporated as subsections within a section that describes SIP
   domain authentication.

   Any normative references from this document should be carried forward
   to the successor document.

A.2.  Changes

   The following subsections describe changes in specific sections of
   RFC 3261 [2] that need to be modified in the successor document to
   align them with the content of this document.  In each of the
   following, the token <domain-authentication> is a reference to the
   section added as described in Appendix A.1.

A.2.1.  26.3.1

   The current text says:

      Proxy servers, redirect servers and registrars SHOULD possess a
      site certificate whose subject corresponds to their canonical

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

Authors' Addresses

   Vijay K. Gurbani
   Bell Laboratories, Alcatel-Lucent
   2701 Lucent Lane
   Room 9F-546
   Lisle, IL  60532

   Phone:  +1 630 224-0216

Gurbani, et al.         Expires January 15, 2009               [Page 15]

Internet-Draft                Domain Certs                     July 2008

   Scott Lawrence
   Bluesocket Inc.
   10 North Ave.
   Burlington, MA  01803

   Phone:  +1 781 229 0533

   Alan S.A. Jeffrey
   Bell Laboratories, Alcatel-Lucent
   2701 Lucent Lane
   Room 9F-534
   Lisle, IL  60532


Gurbani, et al.         Expires January 15, 2009               [Page 16]

Internet-Draft                Domain Certs                     July 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Gurbani, et al.         Expires January 15, 2009               [Page 17]