[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 draft-ietf-sip-domain-certs

SIP WG                                                        V. Gurbani
Internet-Draft                                                A. Jeffrey
Updates:  3261 (if approved)              Lucent Technologies, Inc./Bell
Expires:  February 3, 2007                                  Laboratories
                                                             S. Lawrence
                                                           Pingtel Corp.
                                                         August 02, 2006


      Domain Certificates in the Session Initiation Protocol (SIP)
                   draft-gurbani-sip-domain-certs-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 3, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document attempts to clarify the use of domain certificates in
   the Session Initiation Protocol (SIP).  Currently, there is much
   ambiguity surrounding domain -- or site -- certificates.





Gurbani, et al.         Expires February 3, 2007                [Page 1]


Internet-Draft                Domain Certs                   August 2006


Table of Contents

   1.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   Problem Statement  . . . . . . . . . . . . . . . . . . . . .   3
   4.   Conveying Identity in Certificates . . . . . . . . . . . . .   5
   5.   UAC Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.   UAS Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.   Proxy Considerations . . . . . . . . . . . . . . . . . . . .   6
   8.   Guidelines for CA  . . . . . . . . . . . . . . . . . . . . .   6
   9.   Virtual SIP Servers and Certificate Content  . . . . . . . .   7
   10.  Wildcards in dNSName Type  . . . . . . . . . . . . . . . . .   7
   11.  Security Considerations  . . . . . . . . . . . . . . . . . .   7
   12.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .   8
   13.  References . . . . . . . . . . . . . . . . . . . . . . . . .   8
     13.1   Normative References . . . . . . . . . . . . . . . . . .   8
     13.2   Informative References . . . . . . . . . . . . . . . . .   9
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .   9
        Intellectual Property and Copyright Statements . . . . . . .  11
































Gurbani, et al.         Expires February 3, 2007                [Page 2]


Internet-Draft                Domain Certs                   August 2006


1.  Terminology

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

2.  Introduction

   Transport Layer Security (TLS) [3] has started to appear in an
   increasing number of Session Initiation Protocol (SIP) [2]
   implementations.  TLS depends on the Internet X.509 Public Key
   Infrastructure [4] for its proper use and function.

   Despite the appearance of TLS in SIP implementations, an enduring
   question has remained regarding the contents of the certificates for
   domain verification.  We hope that the discussion in this document
   provides clarity in this area.  Moreover, TLS by itself only provides
   security guarantees for the transport layer.  In this document, we
   also discuss the requirements of SIPS message processing to ensure
   that these security guarantees are also provided at the application
   layer.

   The discussion in this document is pertinent to a certificate used
   for a TLS connection.  It may not apply in its entirety to a
   certificate used in S/MIME, for instance.

3.  Problem Statement

   The use of TLS in SIP addresses two concerns:  first, it provides a
   guarantee at the transport layer that the peer with whom a TLS
   connection is being established is indeed who they purport to be; and
   second, it identifies a SIP resource in the form of a domain over
   which the certificate is asserting its authority.  The former deals
   with identifying hosts at the transport layer for a secure TLS
   connection, and the latter identifies a SIP domain for the
   application using the TLS connection to perform any authorization,
   should such a need arise.

   TLS uses X.509 Public Key Infrastructure [4] to bind an identity, or
   a set of identities, to the holder of a X.509 v3 certificate.
   Accordingly, the recommendations of the SIP working group have been
   to populate the X.509v3 subjectAltName extension with an identity.
   However, this is under-specified in RFC 3261, which mentions
   subjectAltName in conjunction with S/MIME only and not TLS.  For
   S/MIME certificates, the subjectAltName provides additional
   identities of the certificate holder, some in the form of a SIP
   Uniform Resource Identifier (URI).  RFC 3261 does not provide any
   guidelines on the identity (or identities) to be populated in



Gurbani, et al.         Expires February 3, 2007                [Page 3]


Internet-Draft                Domain Certs                   August 2006


   subjectAltName for TLS certificates.  This leads to problems when
   attempting to interpret the certificate contents in a uniform manner.

   Compounding the identification problem further is the manner by which
   SIP uses URIs to route certain requests.  We first take the most
   simplest of cases:  a request is to be routed based on a generic URI
   (sips:alice@example.com.  Through a series of untrusted Domain Name
   Service (DNS) manipulations, a connection is established to a server
   that presents a certificate with an identity of "DNS:example.com".
   Here, since the host portion of the URI (example.com) matches the
   identity stored in the certificate, the connection is deemed to be
   authenticated (to be sure, other checks must be done on the received
   certificate, for example, ensuring that the certificated is rooted in
   a trusted hierarchy, and ensuring that the certificate is in its
   validity period).

      This is the way HTTPS operates, and SIPS simply borrows this
      behavior from HTTP.

   The more complicated case in SIP occurs when the URI that is used to
   route a request does not correspond to the identity in the presented
   certificate.  For instance, what is the expected behavior if the URI
   used for routing is "sips:downtown.example.com" and the certificate
   presented contains an identity of "DNS:example.com"?  Here,
   "downtown" could be a specific host in the "example.com" domain, or
   it could be a subordinate domain.

      Note that a domain name in an X.509 certificates should be
      interpreted only as a sequence of octets that should match the URI
      used to reach the host.  No inference should be made based on the
      DNS name hierarchy.

   In such cases, the general recommendation has been that the host that
   is contacted using a specific URI should present a certificate that
   contains exactly that same URI.  In terms of SIP, this generally
   implies that a proxy that wants to remain on the path of subsequent
   signaling must insert into the Record-Route header an URI that it is
   guaranteed to possess credentials for.  If the proxy wanted to insert
   a fully qualified domain name (FQDN) in the Record-Route header, it
   should have a certificate that states this credential, otherwise, it
   should insert a domain URI into the Record-Route header (i.e., "sips:
   example.com" instead of "sips:downtown.example.com").

   A potential problem in inserting a domain URI is that RFC 3263 [5]
   resolution on that URI may result in a different proxy than the one
   that originally inserted the URI.  While this is not a concern when
   choosing any proxy from a server farm, it is a problem when the
   choice of a proxy needs to be deterministic.  One way to combat this



Gurbani, et al.         Expires February 3, 2007                [Page 4]


Internet-Draft                Domain Certs                   August 2006


   is to arrange for the proxy to possess two certificates -- one
   corresponding to "sips:example.com" and the other corresponding to
   "sips:downtown.example.com" -- and have it present the right one when
   contacted.  While technically this is feasible through the use of TLS
   extensions [7], administratively it requires the proxy vendor to
   acquire two distinct certificates.  In this document, we propose the
   use of one certificate with two identities as a possible way to
   counter this particular problem.

   The rest of the document is organized as follows:  Section 4 contains
   a solution to using one domain certificate in SIP that has two
   identities.  Section 5 and Section 6 contain considerations for user
   agent clients (UACs) and user agent servers (UAS), respectively, and
   Section 7 discusses the effect on proxies.  Section 8 outlines the
   guidelines for a certificate authority (CA) when it issues
   certificates for SIP use.  Section 9, Section 10 and Section 11
   discusses aspects related to contents of certificates for virtual SIP
   servers, the presence of wildcards in domain certificates, and
   security considerations, respectively.

4.  Conveying Identity in Certificates

   As a possible answer to the problem of conveying identity described
   above, it seems appropriate that TLS certificates contain two
   identities in subjectAltName X.509v3 extensions.  The first identity
   is a SIP URI for the domain.  This URI asserts that the system is
   authoritative for the SIP domain that it names (e.g., "URI:sip:
   example.com").  The second identity is a domain name system label,
   more specifically, the canonical name of the host (e.g., "DNS:
   downtown.example.com"); this second name asserts that the system is
   authoritative for the name used for the transport address.

   Including both identities solves the problem identified in Section
   5.1 of [8], as well as satisfying the RFC 3261 concept of what should
   be contained in a site (or domain) certificate (Section 26.3.1 of RFC
   3261, quoted below).

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

   As an example, consider that the autonomous domain example.com is
   applying for a certificate from an authority.  As part of the
   certificate request, it will ask the following two identities be
   bound to the generated certificate:  "URI:sips:example.com", and
   "DNS:downtown.example.com".  The latter DNS label provides assurance
   at the transport layer that the the certificate corresponds to a host
   that was the target of the TLS connection, while the former SIPS URI



Gurbani, et al.         Expires February 3, 2007                [Page 5]


Internet-Draft                Domain Certs                   August 2006


   binds the holder of the certificate with a domain URI for which it is
   authoritatively responsible.  This information may be subsequently
   used by the application to make authorization decisions of the form
   outlined in Section 26.3.2.2 of RFC3261.

5.  UAC Considerations

   When a UAC receives a certificate from a server, it MUST ensure that
   the certificate asserts one of the two identities that the UAC used
   to reach the server:  If the UAC performed RFC3263 resolution on the
   URI to reach the server, the SIPS identity stored in the certificate
   MUST be matched.  Otherwise, if RFC3263 resolution on the URI failed,
   the UAC MUST match the DNS label in the certificate with the name of
   the server that it opened a TLS connection to.

6.  UAS Considerations

   When a UAS accepts a TLS connection, it presents its X.509
   certificate to the client.  A UAS may optionally ask the upstream
   client for a certificate.  If the client is in possession of one, it
   will be presented to the UAS for mutual authentication.  If the UAS
   has a policy to only accept TLS connections from trusted peers, it
   MAY inspect the domain in the SIPS URI of the certificate.  If the
   domain is one that is allowed by such a policy, the TLS connection
   can be considered to be authenticated.

      The specifics of creating such a policy and of providing it to the
      UAS are outside the scope of standardization and are not discussed
      in this document.

7.  Proxy Considerations

   A proxy acts as a UAS for requests arriving to it, and as a UAC when
   it proxies request downstream.  As a UAS, it MUST follow the behavior
   of Section 6; and as a UAC, it MUST follow the behavior specified in
   Section 5.

8.  Guidelines for CA

   When issuing a certificate with two identities as described in this
   recommendation, a certificate authority should validate the authority
   for both usages; that the party to whom the certificate is
   authoritative for both names.

   Note that the two names may not have any relationship at all in the
   DNS.  For example, if a service provider (example.net) is hosting SIP
   services for a customer (example.com), then each proxy in the
   example.net farm may need to be able to present certificates with the



Gurbani, et al.         Expires February 3, 2007                [Page 6]


Internet-Draft                Domain Certs                   August 2006


   SIP identity URI:sip:example.com and the transport layer identity
   DNS:proxy1.example.net.

9.  Virtual SIP Servers and Certificate Content

   The closest guidance in SIP today regarding certificates and virtual
   SIP servers occurs in SIP Identity ([9], Section 13.4).  The quoted
   section states that, "... certificates have varying ways of
   describing their subjects, and may indeed have multiple subjects,
   especially in the 'virtual hosting' cases where multiple domains are
   managed by a single application."

   This appears to imply that one certificate will have multiple SANs
   (or Subject) fields, each such field corresponding to a discrete
   virtual server that represents a single domain?  Since only one
   certificate is needed for multiple domains, the keying material
   management is simpler, but what happens if one of the domains no
   longer wants to continue the business relationship with the hosting
   service?  Is the entire certificate to be revoked?

   Is it conceivable that each domain have a distinct certificate that
   is provided to the hosting service?  Certainly, this means that the
   domain must share the domain's private key with the hosting service.
   TLS extensions [7] like the extended client hello allow TLS clients
   to provide to the TLS server the name of the server they are
   contacting.  Thus, the server can present the correct certificate to
   establish the TLS connection.

   TODO:  Need some more discussion on the mailing list around this
   issue.  What is the recommended procedure here?

10.  Wildcards in dNSName Type

   RFC 2818 (HTTP over TLS) [6] allows the dNSName component to contain
   a wildcard; e.g., "DNS:*.example.com".  RFC 3280 [4], while not
   disallowing this explicitly, leaves the interpretation of wildcards
   to the individual specification.

   RFC 3261 does not provide any guidelines on the presence of wildcards
   in certificates.  The consensus from the working group discussion
   leans in the favor of not using them in SIP.

11.  Security Considerations

   The goals of TLS include the following security guarantees at the
   transport layer:





Gurbani, et al.         Expires February 3, 2007                [Page 7]


Internet-Draft                Domain Certs                   August 2006


   Confidentiality: packets tunneled through TLS can only be read by the
      sender and receiver.
   Integrity: packets tunneled through TLS can only be modified by the
      sender and receiver.
   Authenticity: each principal is authenticated to the other as
      posessing a private key for which a certificate has been issued.
      Moreover, this certificate has not been revoked, and is backed by
      a certificate chain leading to a mutually trusted trust anchor.

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

   Confidentiality: SIPS messages from alice@example.com to
      bob@example.edu can only be read by alice@example.com,
      bob@example.edu, and SIP proxies issued with domain certificates
      for example.com or example.edu.
   Integrity: SIPS messages from alice@example.com to bob@example.edu
      can only be modified by alice@example.com, bob@example.edu, and
      SIP proxies issued with domain certificates for example.com or
      example.edu.
   Authenticity: alice@example.com and proxy.example.com are mutually
      authenticated, and 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.edu and between
      proxy.example.edu and bob@example.edu.  As a result,
      alice@example.com is transitively mutually authenticated to
      bob@example.edu (assuming trust in the authoritative proxies for
      example.com and example.edu).

12.  Acknowledgments

   The following working group members provided substantive input to
   this document:  Jeroen van Bemmel, Michael Hammer, Cullen Jennings,
   Paul Kyzivat, Derek MacDonald, Dave Oran, Jon Peterson, Eric
   Rescorla, and Jonathan Rosenberg.

13.  References

13.1  Normative References

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

   [2]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.



Gurbani, et al.         Expires February 3, 2007                [Page 8]


Internet-Draft                Domain Certs                   August 2006


   [3]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
        RFC 2246, January 1999.

   [4]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
        Public Key Infrastructure Certificate and Certificate Revocation
        List (CRL) Profile", RFC 3280.

13.2  Informative References

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

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

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

   [8]  Gurbani, V. and A. Jeffrey, "The Use of Transport Layer Security
        (TLS) in the Session Initiation Protocol (SIP)",
        draft-gurbani-sip-tls-use-00.txt (work in progress),
        February 2006.

   [9]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
        Identity Management in the Session Initiation Protocol (SIP)",
        draft-ietf-sip-identity-06.txt (work in progress), October 2005.


Authors' Addresses

   Vijay K. Gurbani
   Lucent Technologies, Inc./Bell Laboratories
   2701 Lucent Lane
   Room 9F-546
   Lisle, IL  60532
   USA

   Phone:  +1 630 224-0216
   Email:  vkg at bell hyphen labs dot com












Gurbani, et al.         Expires February 3, 2007                [Page 9]


Internet-Draft                Domain Certs                   August 2006


   Alan S.A. Jeffrey
   Lucent Technologies, Inc./Bell Laboratories
   2701 Lucent Lane
   Room 9F-534
   Lisle, IL  60532
   USA

   Email:  ajeffrey at bell hyphen labs dot com


   Scott Lawrence
   Pingtel Corp.
   400 West Cummings Park
   Suite 2200
   Woburn, MA  01801
   USA

   Phone:  +1 781 938 5306
   Email:  slawrence@pingtel.com
































Gurbani, et al.         Expires February 3, 2007               [Page 10]


Internet-Draft                Domain Certs                   August 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Gurbani, et al.         Expires February 3, 2007               [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/