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