Last Call Review of draft-ietf-sipping-cc-framework-
review-ietf-sipping-cc-framework-secdir-lc-nystrom-2009-06-16-00

Request Review of draft-ietf-sipping-cc-framework
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-06-16
Requested 2009-05-28
Authors Dan Petrie, Jonathan Rosenberg, Alan Johnston, Robert Sparks, Rohan Mahy
Draft last updated 2009-06-16
Completed reviews Secdir Last Call review of -?? by Magnus Nystrom
Assignment Reviewer Magnus Nystrom
State Completed
Review review-ietf-sipping-cc-framework-secdir-lc-nystrom-2009-06-16
Review completed: 2009-06-16

Review
review-ietf-sipping-cc-framework-secdir-lc-nystrom-2009-06-16

I have reviewed this document as part of the security directorate's 


ongoing effort to review all IETF documents being processed by the IESG. 


These comments were written primarily for the benefit of the security area 


directors.  Document editors and WG chairs should treat these comments 


just like any other last call comments.




Background
----------


This document describes a framework for call control and multi-party usage 


of SIP (while the abstract also talks about requirements, I did not see 


any strong requirements - at least there are no normative statements in 


the RFC 2119 sense in the document).




Comments
--------



Although brief, the Security Considerations section reads well (a more 


comprehensive trust/threat model analysis for the proposed framework would 


have been nice though). It could be useful to add a sentence or two on 


anonymity aspects in the context of the proposed framework. The body of 


the text mentions this aspect in passing once (2.6.4) but there is no 


mentioning in the Security Considerations section.






In the sixth paragraph, an explicit method for replay attack prevention is 


recommended (lower-case "should"). I am not sure about the reason for this 


and could potentially see other ways to mitigate such attacks. Hence, one 


suggestion could be to replace the current "In the case of features 


initiated by a former participant, these should be protected against 


replay attacks by using a unique name or identifier per invocation" with:


"In the case of features initiated by a former participant, these should 


be protected against replay attacks, e.g. by using a unique name or 


identifier per invocation."






For clarity, I also suggest changing this section's last sentence to: 


"These credentials may for example need to be passed transitively or 


fetched in an event body."






A question: The third paragraph in the Security Considerations section 


refers to Section 3.2 - might this be Section 2.3?




General/editorial:



- Abstract states "This framework also describes other goals that embody 


the spirit of SIP applications as used on the Internet" - it would have 


been useful if this sentence at least had identified a few of these goals.






- Section 2.3: "peers can take advantage of end-to-end message integrity 


or encryption" - I would say this applies only when certain conditions are 


met and hence perhaps something like "peers may take advantage..." or 


similar would be better.






- Section 2.6.7.2: Acronym "IVR" introduced without explanation. An early 


"Acronyms" section would be useful.






- Section 3: The sentence "One means of accomplishing this is through the 


ability to define and obtain URIs for these actions as described in 


section ." seems to be missing the final section reference.




-- Magnus