Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms
draft-ietf-sipcore-sec-flows-09

[Ballot comment]
Appendix A: Add an informative reference to PKCS#8 [RFC5958].

ASN.1 dumps: The "hority" wraps around the line oddly.

Section 5: Is it worth noting that the SHA2 algs also say don't include the parameters according to [RFC5754].

[Ballot discuss]
#1) The AKIs seems to include all three possibilities.  RFC 5280 says:

  The identification MAY be based on either the
  key identifier (the subject key identifier in the issuer's
  certificate) or the issuer name and serial number.

It also goes on to recommend using the keyIdentifier choice.  I'd remove the other two (authorityCertIssuer and authorityCertSerialNumber) they're just making the certificates bigger than they need to be.

#2) User certificate subject names: look a lot like email addresses.  RFC 5280 requires that new implementations put the email address in the SAN extension with the rfc822Name choice.  Shouldn't the last component of the user's common name be Cullen Jennings, Kumiko, etc and then put the email addresss in SAN:rfc822Name?

[Ballot comment]
6.  Additional Test Scenarios

      *  assure that the most specific CommonName in the Subject field
        matches if there are no dNSName entries in the subjectAltName
        at all (which is not the same as there being no matching
        dNSName entries).  This match can be either exact, or against
        an entry that uses the wildcard matching character '*'

Anywhere in the domain pattern or only in the leftmost position?


Nits: The usual (many acronyms are not spelled out on first use, etc.)

[Ballot comment]
This is a fine document. My only nits are:

1. Some of the acronyms are not expanded on first use.

2. There are some trifling typos (e.g., "particulary").

3. Some of the terms are used inconsistently or casually (e.g., "subjAltName" when "subjectAltName" is meant; it might be even better to re-use the terminology from draft-saintandre-tls-server-id-check).

4. No rules are provided regarding the process of matching IP addresses (e.g., matching of IPv4 addresses vs. IPv6 addresses); however, because use of IP addresses is deemed inadvisable, the lack of rules probably does not have implications for interoperability.

[Ballot comment]
The 'Observed Interoperability Issues' section includes a number of example of implementation problems detected during the SIPit events. I can guess that this information canges in time, as interoperability problems due to implementation bugs or lack of clarity in documents are in the majority of the cases being fixed in the coming releases of the implementations. For this purpose it would be useful I think to mention what is the time reference (may be the indication of the SIPit event) when the problems were detected.

[Ballot discuss]
I generally support publication of this document. I have one minor issue I would like to see addressed before I can recommend approval of this document:

----------------------------------------------
From Apps Area review by Kurt Zeilenga:

I see some inconsistencies in how Distinguished Names (DNs) are presented in the RFC.

For instance (from 2.1):
  Issuer: C=US, ST=California, L=San Jose, O=sipit,
          OU=Sipit Test Certificate Authority

vs. (also from 2.1)
  DirName:/C=US/ST=California/L=San Jose/O=sipit/
          OU=Sipit Test Certificate Authority

The former kind of looks like the LDAP DN format but, if that's what was intended, the RDNs appear in the incorrect order.  Note that in the LDAP DN format, the most specific element appears first (the reverse of how they appear in the BER/DER encoding of a DN).  Also, there should be no spaces after the RDN separators (the commas).

The latter appears to be DCE format.

I would think it appropriate to use a single format for all DNs and, if one chooses to use the LDAP DN format, that values ought to be constructed per RFC 4514.  I note that Appendix A of RFC 4514 discusses presentation issues of Distinguished Names.
----------------------------------------------

My concern with examples in the document is that a naive reader can decide that the "Issuer" field values are LDAP DNs (which per RFC 4514 are in most-specific-first RDN order), which could result in certificates with inverse ordered RDNs. This might cause interoperability issues with verification of such certificates.

Because the document is using output of OpenSSL tools, in order to address this issue I would like to suggest addition of a sentence somewhere early in the document saying that values of the "Issuer:" field displayed in the document is NOT in the LDAP DN format, but an application-specific least-specific-first RDN order format.

[Ballot discuss]
I am sorry that my preliminary DISCUSS caused some agitation to the authors and WG chairs.
This version was updated to clarify the issue:

----------------------------------------------
From Apps Area review by Kurt Zeilenga:

I see some inconsistencies in how Distinguished Names (DNs) are presented in the RFC.

For instance (from 2.1):
  Issuer: C=US, ST=California, L=San Jose, O=sipit,
          OU=Sipit Test Certificate Authority

vs. (also from 2.1)
  DirName:/C=US/ST=California/L=San Jose/O=sipit/
          OU=Sipit Test Certificate Authority

The former kind of looks like the LDAP DN format but, if that's what was intended, the RDNs appear in the incorrect order.  Note that in the LDAP DN format, the most specific element appears first (the reverse of how they appear in the BER/DER encoding of a DN).  Also, there should be no spaces after the RDN separators (the commas).

The latter appears to be DCE format.

I would think it appropriate to use a single format for all DNs and, if one chooses to use the LDAP DN format, that values ought to be constructed per RFC 4514.  I note that Appendix A of RFC 4514 discusses presentation issues of Distinguished Names.
----------------------------------------------

My concern with examples in the document is that a naive reader can decide that the "Issuer" field values are LDAP DNs (which per RFC 4514 are in most-specific-first RDN order), which could result in certificates with inverse ordered RDNs. This might cause interoperability issues with verification of such certificates.

Because the document is using output of OpenSSL tools, in order to address this issue I would like to suggest addition of a sentence somewhere early in the document saying that values of the "Issuer:" field displayed in the document is NOT in the LDAP DN format, but an application-specific least-specific-first RDN order format.

[Ballot discuss]
I am sorry that my preliminary DISCUSS caused some agitation to the authors and WG chairs.
This version was updated to clarify the issue:

----------------------------------------------
From Apps Area review by Kurt Zeilenga:

I see some inconsistencies in how Distinguished Names (DNs) are presented in the RFC.

For instance (from 2.1):
  Issuer: C=US, ST=California, L=San Jose, O=sipit,
          OU=Sipit Test Certificate Authority

vs. (also from 2.1)
  DirName:/C=US/ST=California/L=San Jose/O=sipit/
          OU=Sipit Test Certificate Authority

The former kind of looks like the LDAP DN format but, if that's what was intended, the RDNs appear in the incorrect order.  Note that in the LDAP DN format, the most specific element appears first (the reverse of how they appear in the BER/DER encoding of a DN).  Also, there should be no spaces after the RDN separators (the commas).

The latter appears to be DCE format.

I would think it appropriate to use a single format for all DNs and, if one chooses to use the LDAP DN format, that values ought to be constructed per RFC 4514.  I note that Appendix A of RFC 4514 discusses presentation issues of Distinguished Names.
----------------------------------------------

My concern with examples in the document is that a naive reader can decide that the "Issuer" field values are LDAP DNs (as required according to X.509), which will result in generation of invalid certificates. This might cause interoperability issues with verification of such certificates.

Because the document is using output of OpenSSL tools, in order to address this issue I would like to suggest addition of a sentence somewhere early in the document saying that values of the "Issuer:" field displayed in the document is NOT in the LDAP DN format typically used by X.509 certificates.

[Ballot discuss]
From Apps Area review by Kurt Zeilenga:

I see some inconsistencies in how Distinguished Names (DNs) are presented in the RFC.

For instance (from 2.1):
  Issuer: C=US, ST=California, L=San Jose, O=sipit,
          OU=Sipit Test Certificate Authority

vs. (also from 2.1)
  DirName:/C=US/ST=California/L=San Jose/O=sipit/
          OU=Sipit Test Certificate Authority

The former kind of looks like the LDAP DN format but, if that's what was intended, the RDNs appear in the incorrect order.  Note that in the LDAP DN format, the most specific element appears first (the reverse of how they appear in the BER/DER encoding of a DN).  Also, there should be no spaces after the RDN separators (the commas).

The latter appears to be DCE format.

I would think it appropriate to use a single format for all DNs and, if one chooses to use the LDAP DN format, that values ought to be constructed per RFC 4514.  I note that Appendix A of RFC 4514 discusses presentation issues of Distinguished Names.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Example call flows using Session Initiation Protocol (SIP) security mechanisms) to Informational RFC


The IESG has received a request from the Session Initiation Protocol Core
WG (sipcore) to consider the following document:
- 'Example call flows using Session Initiation Protocol (SIP) security
  mechanisms'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-12-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sipcore-sec-flows/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sipcore-sec-flows/

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Adam Roach is the document shepherd. He has reviewed the current
version of the document and believes that it is ready for publication.

Note that the majority of the document is machine-generated and
machine-readable. The shepherd has not performed a detailed validation
of these portions of the draft, as doing so would be an effort
tantamount to creating the document in the first place. Note also
that the shepherd has only a passing familiarity with specific
details of TLS and S/MIME certificates, and is relying on the
authors and reviewers to have caught any errors in their construction.
(The shepherd is, however, personally familiar with the certificate
expertise of three of the document authors, and beleives that they
have the skills necessary to get this right).


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

By its nature as a security examples document, this work has a
fairly limited number of people qualified to comment on it.
Reviewers require a moderately detailed understanding of SIP,
TLS, and S/MIME. As a result, the majority of substantive feedback
(at least, during the document's tenure in SIPCORE) has been
from dedicated reviewers.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

The shepherd believes that the combination of authors and existing
reviewers have the proper expertise for this document.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

The shepherd has no concerns regarding the document. No IPR disclosures
have been filed on this document.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Due to the specialized nature of security, the document has been
created and reviewed by a relatively small number of working group
participants.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The document passes a NITs review. The NITs tool turns up quite a few
false positives. All remaining NITs reported by the tool have been
pursued and determined to be bogus.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The draft is informational. All normative references are RFCs.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The document correctly states that no IANA actions are necessary.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The document contains two shell scripts for generation of SSL
certificates. They both execute and produce certificates on the
shepherd's laptop. So, they are valid in at least certain
circumstances.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This document shows example call flows demonstrating the
use of Transport Layer Security (TLS), and Secure/Multipurpose
Internet Mail Extensions (S/MIME) in Session Initiation
Protocol (SIP). It also provides information that helps
implementers build interoperable SIP software.


Working Group Summary
This work traces its roots back to 2003, when it was first
introduced into the SIP working group. For much of its
lifetime, it existed quietly alongside the document
"Certificate Management Service for The Session Initiation
Protocol," which is currently in the RFC Editors' queue.
After moving into SIPCORE, repeated requests by the chairs
for review yielded a small number of in-depth reviews.


Document Quality
According to one of the document authors, he has received
"many emails from implementors that use this draft." Using
this as our data point, the document's utility as a sanity
check for the security aspects of SIP implementations would
seem to be very high. Ole Johansson brought back practical
feedback from SIPit interoperabilty testing events regarding
some of the practical aspects of what needs to appear in
TLS certificates.