Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)
Note: This ballot was opened for revision 06 and is now closed.
(Allison Mankin) Yes
(Brian Carpenter) No Objection
Comment (2005-06-23 for -)
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, , after the phrase RFC 3261 :-)
(Margaret Cullen) No Objection
(Bill Fenner) (was Discuss) No Objection
(Ted Hardie) No Objection
Comment (2005-06-22 for -)
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?
(Sam Hartman) No Objection
(Scott Hollenbeck) No Objection
Comment (2005-06-20 for -)
The intro could be clearer about RFC 3261 being reference , perhaps by changing "(SIP )" to "(SIP, RFC 3261 )".
(Russ Housley) (was Discuss) No Objection
(David Kessens) No Objection
(Bert Wijnen) No Objection
Comment (2005-07-06 for -)
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:email@example.com SIP/2.0 s/exmple/example/