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

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/

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

The intro could be clearer about RFC 3261 being reference [1], perhaps by changing "(SIP [1])" to "(SIP, RFC 3261 [1])".

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?