Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)
draft-ietf-sip-identity-06

There was some difficulty with the examples - Russ's asn1 tools did
not work with the base64 and had to be tested on der.  He has now
calibrated his tool.  There may still be a typo inside the appendix,
but we are going to approve -06 and clean that typo in a final
recheck at publication (this is not the same thing as AUTH48
author changes).

Cullen discovered the typo that makes the examples not decode - waiting
since mid-December for Jon to re-issue the spec so Russ will clear -
Cullen is wondering if the clear text of the cert has any problems also -
all the other issues were cleared - I sent a detailed response about
six weeks after the rev - the detailed response should be put into the
log.  My delay was IETF and then family, job wind-down.

Get this document out of the pipe - others waiting for it!!

[Ballot comment]
typo on page 4, one but last para:
  order to provide a 'return address' identity to recipients.  From an
  authorization perspective, if you are can prove you are eligible to
s/if you are can/if you can/

A typo I guess: top of page 17
          INVITE sip:bob@biloxi.exmple.org SIP/2.0
s/exmple/example/

[Ballot comment]
The document contains some lines in examples that greatly exceed the
  margin.  A convention is needed to display such lines, yet keep them
  within the RFC margin constraints.

  Question: Can an addr-spec ever contain a vertical bar (|)?  If so, it
  may be possible for one digest-string to represent more than one
  message.  If so, some form of quoting will be necessary when vertical
  bar appears in an addr-spec used to construct a digest-string.

  Section 3 says:
  >
  > ... it is obviously preferable for end users to hold their own
  > certificates ...
  >
  and
  >
  > ... synchronizing certificates across multiple devices ...
  >
  I think you mean that it is preferable for end user to have their
  own private key.  Of course, the corresponding public key is placed
  in a certificate to bind the public key to a useful identity.  The
  sync of certificates is pretty easy since they contain only public
  data.  The sync of the private key is the hard part.  In fact, it is
  the problem that the SACRED WG is trying to solve.

  In step 3 of section 6, should the authentication service also confirm
  that the date is within the validity period of its certificate?  This
  check also seem appropriate in step 4 of section 7.
 
  In section 10: s/ result in placed int the / result is placed in the /

  Section 10 says:
  >
  > ... or 1200 RSA 512 bits signs ...
  >
  Since 1024 bits (or larger are required), this is not helpful info.

[Ballot discuss]
Step 1 in section 7 ought to reference RFC 3280 for the steps in
  certificate validation.  RFC 3280 should be a normative reference.

  Section 4 says:
  >
  > o  User agents that receive identity assurances must be able to
  >    validate these assurances without performing any network lookup.
  >
  I do not believe that this goal is achieved.  I am not suggesting that
  the mechanism should be changed; rather, I am advocating "truth in
  advertising."  The recipient must fetch the certificate pointed to
  by the Identity-Info header, and then fetch any relevant revocation
  information (such as a CRL).

  Section 10 says:
  >
  > It is MANDATORY for all implementations of this specification
  > to support 'rsa-sha1'.
  >
  The word MANDATORY is not an RFC2119 requirements keyword.  Consider:
  >
  > All implementations of this specification MUST support 'rsa-sha1'.

  The certificate provided in section 11.1 makes use of TeletexString
  in the distinguished name.  RFC 3280 states that UTF8String is the
  preferred encoding, and PrintableString is also acceptable.  Please
  use a certificate that makes use of only UTF8String and
  PrintableString.

  The certificates provided in sections 11.1 and 11.2 are signed with
  the md5withRSAEncryption algorithm.  Please use sha1withRSAEncryption.
  RFC 3853 requires SIP support for SHA-1, as does section 10 of this
  document.

  The example in section 11.1 includes:
  >
  > Identity-Info: ;alg=rsa-sha1
  >
  And, the example in section 11.2 includes:
  >
  > Identity-Info: ;alg=rsa-sha1
  >
  These URLs do not follow the conventions specified in RFC 2585, which
  is required by section 10 of this document.

  Section 14.4 (or some other place in the security considerations)
  should point out that the security considerations in RFC 3280 apply
  to this document as well.

  Reference [11] should be normative as it is used in a MUST statement.

[Ballot comment]
If an editing pass is needed, there are some useful comments in this review
by Lakshminath Dondeti:

Review:  Ready with some questions, comments and nits

First, I will say that I like the security considerations section very much.  It is quite
detailed and thorough!  Thanks.

That said, I expected to see some of the explanations etc., to be part of the main text
(in Sections 6 and 7), along the lines of "A MUST/SHOULD/MAY do this," and "that
provides the blahblah property/protection."

Questions and comments:

1. Caller-ID security in POTS:  Caller-ID security in POTS is not all that it is made out
to be (you can spoofing devices on the Internet).  So, the question is whether the last
sentence in the Introduction can be stronger.  I understand that the SIP-identity work
doesn't provide end-to-end security, so it is not exactly "perfect" either, but surely better
than whatever POTS does (or may be not).

2. In Section 6, Page 9, Step 3:  The purpose of verifying the Date header should be more clearly
specified.  Currently the text says what a user agent might be able to do, and what is not intended
etc.  After the first sentence, please include a sentence on why the authentication service SHOULD
ensure that any preexisting Date header is accurate.

3. Page 11 has two references to "428" with a different "reason phrase".  I think the second occurrence
"Invalid Identity Header" is incorrect.  Please fix it.

4. Page 14: Please include a reference to 3852 along with 3370. (and perhaps to PKCS #1 v1.5 as well).

Why is there a reference to RSA 512 bits in the first paragraph of Page 15 ? :-)

5. On Section 14.

It looks like the definition of replay attacks used is different from what I am used to seeing.  Perhaps
the term cut-and-paste attack is sufficient.  (as defined in Paragraph 2 of the section; the rest of the references to replay attacks are fine)

> From the third paragraph, it appears that the integrity protected Date field is to provide replay protection

(in the traditional sense).  It might be worthwhile to mention this earlier in the text (say in Sec 6, Page 9,
Step 3).

Normally a hash of the message is stored and compared against for replay protection in addition to things
like integrity protected timestamps (Date).  Does the Call-ID provide the same capability (uniqueness)?
It looks replay protection is provided through a combination of techniques.  It might be worthwhile to tie
them all together and point out to the reader that the protection works only if all of them are tied together.

I think this information is there in the draft, but not immediately clear.  I am worried if implementers might
do this piece-meal and assume they got it right!


Some nits:
------------
* Please expand AoR in the first paragraph (Section 1).
* The second to last paragraph in Page 4 contains several instances of address-of-record (other instances in pages 5 and 6) that could be written as AoR to improve readability.

* Page 14: Please rewrite the second to last sentence as follows: The result is placed in the Identity header

field (it is a typo that the RFC Ed might not catch).

* Page 17: When the authentication service receives the INVITE, in authenticates
                                                                                          ^^
replace with    it authenticates

* Page 26: last line:  s/difficult term/difficult time/              ?
* Section 14, third paragraph: please cite RFC3261, [1], after the phrase RFC 3261 :-)

[Ballot comment]
IN 14.4, the document says :

  It is strongly RECOMMENDED that self-signed domain certificates should
  not be trusted by verifiers, unless some pre-existing key exchange
  has justified such trust.

Is there not a use case here for using self-signed domain certificates in cases
where you are not trying to establish identity, but are trying to establish the
consistency of identity?

[Ballot discuss]
[on the Identity-Info change that Allison mentioned in email:

Identity-Info = "Identity-Info" HCOLON ident-info (* SEMI identi-info-params )

|
V

Identity-Info = "Identity-Info" HCOLON ident-info (* SEMI ident-info-params

]

That line needs another correction - to change "(*" to "*(".  (And
to keep the closing parenthesis, but I assume that was just an email
formatting error that made it appear to be dropped).
Also, "ident-info-extension" doesn't appear to be defined but it's
used a couple of lines down.

It probably makes sense to move the reference to 3261's ABNF
further up, since Identity and Identity-Info use pieces of it.
digest-string uses 3261's "Method" as "method", which is legal but
confusing.  Similarly, 3261's "SIP-date" is referred to as "SIP-Date".

IANA Last Call Comments:
Upon approval of this document the IANA will register 2 new header fields,
3 new response-codes, and will create 2 new registries for  Identity-Info Parameters and Identity-Info Algorithm Parameter Values.

Will these 2 new registries be nested within http://www.iana.org/assignments/sip-parameters or will these need to be placed in a separate registry?