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

From: Magnus Nyström <[email-masked]>
Date: Sun, 14 Jun 2009 23:37:10 +0200 (W. Europe Daylight Time)

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

---

From: Alan Johnston <[email-masked]>
Date: Wed, 24 Jun 2009 11:38:22 -0500

Magnus,

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

Thanks,
Alan

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

> fetched in an event body."

I'm fine with this change as well.

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