Subject: [sipcore] Review of sipcore-sec-flows-01

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 22 Dec 2009 14:28:30 -0600

First off, sorry for the delay in getting this review out.  I had
promised to send it shortly after Thanksgiving, but ...

Second, I believe that this work is of importance to the development
community that can use an additional resource to get a TLS-capable
SIP entity tested and running.

That said, here are the rest of my comments from my review.

1) S1, paragraph 2:

  OLD:
  Furthermore, testing at the events is often hampered by trying
  to get certificates signed by some common test root into the
  appropriate format for various clients.

  NEW:
  Furthermore, testing at the events is often hindered due to the
  lack of a commonly trusted certificate authority to sign the
  certificates used in the events.

2) S1, paragraph 2: The following text

    In addition, this document provides a common certificate and
    private key that can be used for a Certificate Authority (CA)
    to reduce the time it takes to set up a test at an
    interoperability event.

  makes the reader believe that the common certificate and private
  key can be used by any CA in the world.  This is, of course,
  not the intent.  The document is providing a common certificate
  and the associated private key for the express purpose of creating
  a mock CA to sign the certificates for the interoperability events.

  Thus, I would suggest the following paragraph as a substitute for
  the above one (please feel free to edit as needed):

    In addition, this document provides a common certificate and
    private key that can be used to set up a CA --- a mock CA ---
    during the SIP interoperability events.  Certificate requests from
    the users will be signed by the private key of the mock CA.

3) S1, paragraph 4, last sentence:
  s/the same CA certificate/the same mock CA private key/

4) S1, paragraph 5:
  s/list of things implementers/list of items that implementers/

5) S1, paragraph 6:
  s/A way to make/Scripts and instructions to make/
  s/is presented/are presented/

6) S3.2, note that the DNS label in the certificate under the SAN
  extension is wrong.  It should be "DNS:example.com" and not
  "DNS:com".

  Also, the example.net certificate suffers from the same problem,
  it also contains "DNS:net" in the SAN instead of "DNS:example.net".

7) S3.3, the sentence "The message could be coming from a host
  called atlanta.example.com, and the AOR in the user certificate would
  still be the same." adds ambiguity to the text without contributing
  much information.  Unless there is a specific reason why the reader
  needs to know that the SIP message sent over a TLS channel established
  by this certificate originated from the host atlanta.example.com, I
  would suggest to remove the offending sentence completely.

8) S4.1, paragraph 1:
  s/TLSRFC/TLS RFC/
  s/set to example.net/contains example.net

9) S4.1, the ssldump output: should not the second endpoint be
  identified as "www.example.net (5061)"?  See the very first line
  of the ssldump output.

10) S4.2: The first paragraph says that the <allOneLine> convention
  from rfc4475 is used, however, I do not see the <allOneLine>
  element in the subsequent example.

11) S4.2, first open issue: If Contact is not allowed in a MESSAGE
  and its corresponding 2xx, simply take it out, no?  Taking the
  Contact out does not result in any loss of generalization, nor
  does it detract from the point the example is trying to make.

12) S4.2, second open issue: If you take Contact out of the 200 OK,
  then you do not have this problem.  The Contact in the 200 OK
  contains an IP address that is the same as the one in the top-most
  Via header (which is what leads to the confusion in the first
  place, I believe.  The To and From contain URIs with domain names.)

13) S4.2, third open issue: I am not sure what you are trying to
  point out by referencing rfc3263 or connect-reuse here.  IMHO, the
  section looks fine without referencing rfc3263 or connect-reuse.

14) S5.1: I would advise being consistent and using <allOneLine>
  convention everywhere in this draft.

15) S5.1, this is a nit, but to be orthogonal to S4.2, it will help
  if the message body in S5.1 contained the same message as in
  S4.2 (i.e., "Hello!" instead of "hello").

15) S5.3: I would advise being consistent and using <allOneLine>
  convention everywhere in this draft.

16) S6: First open issue: Cullen has already stated that he and
  Kumiko has observed these.  In addition, here is a table that contains
  the number of TLS implementations since SIPit 16:

    SIPit   Unique          Number of TLS
    No.     Implementations implementations   Percentage
    ----------------------------------------------------
    16       57                  25               44%
    18       73                  30               41%
    19       90                  41               45%
    20       90                  42               46%
    21       70                  34               49%
    22       80                  50               63%
    23       50                  24               48%
    24       43                  22               52%
    25       42                  16               38%

    Note: (1) 16th SIPit was held in April 2005, 23 SIPit was held in
              October 2008.
          (2) Data for 16th SIPit is form my private archive
              and is not reflected in [1].
          (3) I don't have data for 17th SIPit.
          (4) Rest of the table created from data at [1].

    [1] Robert J. Sparks, SIPit Summaries, archived at
     https://www.sipit.net/SIPitSummaries

  In the last 3-4 bakeoffs, there weren't any implementations of
  S/MIME.  In the earlier bakeoffs, there were very few implementations
  of S/MIME.  If you want me to compile these for a summary, I can
  do so.

17) S6, second open issue: Does it matter?  What is gained by further
  categorizing the SIP clients into UAS, UAC, or a proxy?

18) S7, general comment -- some "folklore" is specified in the
  domain-certs document
  (http://tools.ietf.org/html/draft-ietf-sip-domain-certs-04), which
  is with the IESG right now.  The domain-certs document should
  be cited here as well.

18) S7, second bullet item is normatively specified in domain-certs.
  Suggest that a reference to domain-certs be included here for
  further reading.

19) S7, third open issue: I believe that IP addresses can appear in the
  SAN (rfc5280 says so.)  Their handling is specified in domain-certs (I
  believe they will appear as "DNS:192.168.0.1"; we need to have someone
  -- from pkix? -- ascertain this.  If this is the case, then their
  handling is specified in S7.1 of domain-certs.)

20) S7: For the test cases in S7, I wonder if it is worth creating test
  certificates issued by the mock CA and including these in the
  draft?  That way, implementers can simply download the certificates
  and use them for their testing.  If people think this is a good
  idea, I can spend some time doing this.

21) S7: last open issue: I think that the case of having one or more
  certificates in a path not provided or not available is a good one.
  Question is should we provide a certificate signed by a subordinate CA
  for testing to implementers or simply discuss this case?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/