[secdir] SecDir review of draft-ietf-sipping-cc-framework

[Magnus Nyström <[e-mail]>]

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