Subject: Review of draft-ietf-sip-domain-certs-06

From: Bernard Aboba <[email-masked]>
Date: Sat, 10 Apr 2010 15:30:16 -0700

I reviewed the document draft-ietf-sip-domain-certs-06 in general
and for its operational impact.
 
--
 
Review Summary: 
Intended status:  Proposed Standard

   This document describes how to construct and interpret certain
   information in a X.509 PKIX-compliant 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.
 
Is the document readable?

Yes. 
 
Does it contain nits?

idnits 2.12.02 

tmp/draft-ietf-sip-domain-certs-06.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  == You're using the IETF Trust Provisions' Section 6.b License Notice from
     12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
     http://trustee.ietf.org/license-info/)

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == The 'Updates: ' line in the draft header should list only the _numbers_
     of the RFCs which will be updated by this document (if approved); it
     should not include the word 'RFC' in the list.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document date (March 22, 2010) is 19 days in the past.  Is this
     intentional?

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  ** Obsolete normative reference: RFC 4366 (ref. '4') (Obsoleted by RFC 5246)

  == Outdated reference: A later version (-04) exists of
     draft-drage-sip-essential-correction-03

     Summary: 1 error (**), 4 warnings (==), 0 comments (--).

Is the document class appropriate?

Yes. 

Is the problem well stated?

Yes.  Section 3 describes what the extent of guidance provided in RFC 3261 with respect to identity placement, as well as issues that have been encountered, not just within SIP, but also within other usages:

   With respect to certificates for TLS, RFC3261 (Section 26.3.1) says:

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

   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.

Is the problem really a problem?

Yes.  

Does the document consider existing solutions?

Not sufficiently.

RFC 3261 was published in June 2002, and RFC 3280 was published in April 2002, nearly eight years ago.  

In the meantime, thousands of SIP proxies and servers have been deployed utilizing TLS along with certificate authentication.

Given the extensive existing deployment, backward compatibility is a major issue.  Since RFC 3261 did not provide much guidance, implementers typically followed the general guidance in RFC 3280.  

The best advice for interoperability is "be liberal in what you accept, conservative in what you send."  The document
does not always follow this advice.  For example, Section 6 of the document allows SSPs to place the identity in either 
the subjectAltName or Subject fields (e.g. liberal in what you send): 

   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.
 
Yet at the same time, Section 7.1 makes acceptance of identities in the CN field optional (e.g. conservative in what you accept):

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

IMHO, a better prescription would be to require that implementations be capable of accepting identities in any of the permitted formats (though a given deployment might choose to further constrain identity placement by policy).  

Does the solution break existing technology?
 
Yes.  The prescriptions in this document could result in certificates whose formats are acceptable for issuance not being accepted by other implementations.  Given the scope of existing deployments, this is problematic.  Also, there are also a number of other backward compatibility issues. 

Within Section 4: 

   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.

[BA] Where an SRV or NAPTR RR is used, it is possible for a domain to be delegated
so that the matching process described above would fail, yet the delegation
would still be legitimate (e.g. the SRV/NAPTR RRs could be signed via DNSSEC,
and might point to an FQDN that matches the identifier extracted from the
certificate, rather than the FQDN in the SIP URI. 

Within Section 7.2:

         Implemenations MUST NOT match any form of wildcard, such as a

[BA] Implemenations -> Implementations

         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.

[BA] At this point, 8 years after the issuance of RFC 3261, wildcards are widely
deployed within SIP certificates.  It is therefore not appropriate to prohibit them. 

Does the solution preclude future activity?
 
No. 
 
Is the solution sufficiently configurable?

No.  I believe that the specification should make a distinction between what implementers need to support and the policies that a given deployment chooses to implement.  It is one thing, for a deployment to decide that to implement a given policy with respect to identity placement;  it is another things for an implementation to be incapable of accepting identities in formats that are permitted by the specification.   
 
Can performance be measured? How?

This document is primarily about certificate formats not performance.  However, performance of TLS implementations can presumably be measured utilizing procedures developed for this purpose.  
 
Does the solution scale well?

Yes.  
 
Is Security Management discussed? 

No.  That topic is outside the scope of this document.