Draft:  draft-ietf-sip-identity-05
Reviewer: Lakshminath Dondeti [ldondeti@qualcomm.com]
Date: Wednesday 6/22/2005 10:31 AM CST

Summary: Ready with some questions, comments and nits

Review:

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

Idnits:
--------
Oh, and I just ran idnits on this and apparently the IPR statement is 
not compliant:

Checking nits according to http://www.ietf.org/ID-Checklist.html:
    Checking conformance with RFC 3978/3979 boilerplate...
  * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
    Acknowledgment. 

  (Expected a match on the following text:
    "By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.")

    (The document uses RFC 3667 boilerplate or RFC 3978-like
    boilerplate instead of verbatim RFC 3978 boilerplate.  After 6 May 2005,
    submission of drafts without verbatim RFC 3978 boilerplate is not



thanks and regards,
Lakshminath