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

[Alan Johnston <[e-mail]>]

Magnus,

Thanks for your review of the document.  See my comments below.

Thanks,
Alan


Magnus Nyström wrote:
> 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.

We could add a statement like:

"Standard SIP privacy and anonymity mechanisms such as [RFC3323] and 
[RFC3325] used during SIP session establishment apply equally well to 
SIP call control operations.  SIP call control mechanisms should address 
privacy and anonymity issues associated with that operation.  For 
example, privacy during a transfer operation using REFER is discussed in 
Section 7.2 of [draft-ietf-sipping-cc-transfer]."

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

This is a good suggestion - I'm fine with this text.

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

I'm fine with this change as well.

>
> A question: The third paragraph in the Security Considerations section 
> refers to Section 3.2 - might this be Section 2.3?

Yes - we will fix this.

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

We can list some like this:

"This framework also describes other goals that embody the spirit of SIP 
applications as used on the Internet such as: definition of primitives, 
not services; invoker and participant oriented; signaling and mixing 
model independence, and others."

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

I'm fine with changing it to:

"peers may take advantage of end-to-end message integrity or encryption"

>
> - Section 2.6.7.2: Acronym "IVR" introduced without explanation. An 
> early "Acronyms" section would be useful.

We will expand IVR, and also 3PCC, URI, JTAPI, CSTA, B2BUA, UA, GSM, 
HTTP, RTSP, PSTN,  W3C, and SDP when they are first mentioned in the 
text.  I'd prefer not to introduce an Acronyms section as most of these 
acronyms are only used once or twice in the text, but I can if others 
feel strongly about it.


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

We will change it to:

"One means of accomplishing this is through the ability to define and 
obtain URIs for these actions as described in Section 2.7.2."


> -- Magnus
>