Last Call Review of draft-ietf-sipping-cc-framework-
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 184.108.40.206: 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.