Last Call Review of draft-ietf-sipping-cc-framework-

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


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.


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


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?


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