Subject: Re: [secdir] Review of draft-ietf-sip-media-security-requirements-07.txt

From: Dean Willis <[email-masked]>
Date: Fri, 7 Nov 2008 08:52:01 -0600

Steffen, can you please respond more directly to the points? Perhaps  
you could point to specific sections of the document and explain what  
it said before the change and what it says after the change?

Thanks!

--
Dean

On Nov 7, 2008, at 8:44 AM, Fries, Steffen wrote:

> Hi Tero,
>
> thnk you for the review, in version 08 we  addressed the points you
> raised, except the numbering of the requirements. Nevertheless, we  
> have
> included references in section 3 that show, were the requirements are
> explained  (section 5).
>
> Reagards
> 	Steffen
>
>> -----Original Message-----
>> From: Tero Kivinen [mailto:[email-masked]]
>> Sent: Wednesday, October 29, 2008 1:37 PM
>> To:
>> [email-masked];
>> [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: Review of draft-ietf-sip-media-security-requirements-07.txt
>> Importance: High
>>
>> 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 draft talks about security requirements of the SIP
>> media. As such the whole document talks about security. I do
>> not have any security comments for it, but I have some other
>> comments and notes about it.
>>
>> The biggest problem I had when I was reading the document,
>> was that section 3, suddenly starts listing different
>> requirements like R-PASS-MEDIA, R-PASS-SIG etc, and there is
>> no indication where those are described. I tried to look for
>> them in the table of contents, but couldn't find them listed there.
>>
>> Reading forward I finally found those in the section 5, but
>> as they are not as separate sections there, they were not
>> listed in the table of contents. It would be better to move
>> each of those requirement to separate subsection, i.e. make
>> "5.1.1 R-FORK-RETARGET" and so on, so those references
>> earlier could point to section 5.1.1 and those would also be
>> listed in the table of contents.
>>
>> There is also unexpanded acronym of UAC in section 4.2, and I
>> do not what it means and it is not expanded or described in
>> any way. There seemed to be also quite a lot of other
>> acronyms, so it would be useful to check out if those are
>> really described (or expanded) somewhere in the document.
>>
>> Also it would be useful to expand HERFP also in the section
>> 5.1 when describing R-HERFP, not only section 4.2. Now the
>> description of R-HERFP does not tell that much: "The media
>> security key management protocol MUST function securely even
>> in the presence of HERFP behavior." especially if reader
>> doesn't remember what HERFP stands for...
>>
>> The description of R-RTP-VALID seems bit odd. It says that
>> "...key negotiation packets MUST NOT pass the RTP validity
>> check...". That seems bit odd considering that the name is
>> R-RTP-VALID and it says MUST NOT pass validity check. Is that
>> description really correct?
>>
>> Some nits:
>>
>> Section 8. Acknowledgements has Richard Barnes twice.
>>
>> Section A.4.3. SSRC and ROC has typo in word binding:
>> "Another, used by Security Descriptions, is to use "late
>> bindng" -- ...
>> --
>> [email-masked]
>>
>

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 7 Nov 2008 15:44:22 +0100

Hi Tero,

thnk you for the review, in version 08 we  addressed the points you
raised, except the numbering of the requirements. Nevertheless, we have
included references in section 3 that show, were the requirements are
explained  (section 5).

Reagards
	Steffen

---

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 7 Nov 2008 16:25:58 +0100

Hi,

please find the changes I made in the 08 version addressing the comments
from Tero Kivinen.
I put the changes inline with Tero's comments. 

> 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 draft talks about security requirements of the SIP media. As such

> the whole document talks about security. I do not have any security 
> comments for it, but I have some other comments and notes about it.
> 
> The biggest problem I had when I was reading the document, was that 
> section 3, suddenly starts listing different requirements like 
> R-PASS-MEDIA, R-PASS-SIG etc, and there is no indication where those 
> are described. I tried to look for them in the table of contents, but 
> couldn't find them listed there.
[stf] I added a sentence at the beginning of section 4, which start
using the requirement abbreviations.
	Throughout the subsections requirements are stated by using the
	nomenclature R- to state an explicit requirement. All of the
stated 
	requirements are explanied in detail in section 5. The
requirements 
	in section 5 are listed according their association to the key 
	management protocol, to attack scenarios, and requirements 	
	which can be met inside the key management protocol or outside
of the 
	key management protocol.

> Reading forward I finally found those in the section 5, but as they 
> are not as separate sections there, they were not listed in the table 
> of contents. It would be better to move each of those requirement to 
> separate subsection, i.e. make
> "5.1.1 R-FORK-RETARGET" and so on, so those references earlier could 
> point to section 5.1.1 and those would also be listed in the table of 
> contents.
[stf] I think it is sufficient to include the above sentence instead of
numbering the requirements in sections.

> really described (or expanded) somewhere in the document.
[stf] I included the following statement at the beginning of the
terminology section:
      Furthermore, the terminology described in SIP 
      (<xref target="RFC3261"></xref>) regarding functions and
components 
      are used throughout the document 

> doesn't remember what HERFP stands for...
[stf] I added the following subsentence to the R-HERFP:
	i.e., the rejection of key information does not reach the
sender.

> description really correct?
[stf] I did nothing here, as the stated requirements is correct.

> Section 8. Acknowledgements has Richard Barnes twice.
[stf] removed the double Richard and myself from the acknowledgement
list 

> "Another, used by Security Descriptions, is to use "late 
[stf] changed to
	Another, used by Security Descriptions, is to apply "late 
	bindng ...

Ciao
	Steffen 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Friday, November 07, 2008 3:52 PM
> To: Fries, Steffen
> Cc: Tero Kivinen; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Review of 
> draft-ietf-sip-media-security-requirements-07.txt
> 
> Steffen, can you please respond more directly to the points? 
> Perhaps you could point to specific sections of the document 
> and explain what it said before the change and what it says 
> after the change?
> 
> Thanks!
> 
> --
> Dean
> 
> 
> > have included references in section 3 that show, were the 
> requirements 
> > are explained  (section 5).
> >
> > Reagards
> > 	Steffen
> >
> >> Subject: Review of 
> draft-ietf-sip-media-security-requirements-07.txt
> >> Importance: High
> >>
> 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.
> >> This draft talks about security requirements of the SIP media. As 
> >> such the whole document talks about security. I do not have any 
> >> security comments for it, but I have some other comments and notes 
> >> about it.
> >>
> was that 
> >> section 3, suddenly starts listing different requirements like 
> >> R-PASS-MEDIA, R-PASS-SIG etc, and there is no indication 
> where those 
> >> are described. I tried to look for them in the table of 
> contents, but 
> >> couldn't find them listed there.
> >>
> >> Reading forward I finally found those in the section 5, 
> but as they 
> >> are not as separate sections there, they were not listed 
> in the table 
> >> of contents. It would be better to move each of those 
> requirement to 
> >> separate subsection, i.e. make
> earlier could 
> >> point to section 5.1.1 and those would also be listed in 
> the table of 
> >> contents.
> >>
> >> There is also unexpanded acronym of UAC in section 4.2, 
> and I do not 
> >> what it means and it is not expanded or described in any 
> way. There 
> >> seemed to be also quite a lot of other acronyms, so it would be 
> >> useful to check out if those are really described (or expanded) 
> >> somewhere in the document.
> >>
> security 
> >> key management protocol MUST function securely even in the 
> presence 
> >> of HERFP behavior." especially if reader doesn't remember 
> what HERFP 
> >> stands for...
> >>
> >> The description of R-RTP-VALID seems bit odd. It says that "...key 
> >> negotiation packets MUST NOT pass the RTP validity check...". That 
> >> seems bit odd considering that the name is R-RTP-VALID and it says 
> >> MUST NOT pass validity check. Is that description really correct?
> >>
> >> Some nits:
> >>
> bindng" -- 
> >> ...

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 10 Nov 2008 17:56:28 +0200

> 	which can be met inside the key management protocol or outside

As section 3 already refers to those R-* requirements, I think it
would be better to move the paragarph to section 2. Terminology or at
least also in the beginning of section 3. 

> numbering the requirements in sections.

It would be nice to be able to find the requirements from the document
by simply looking at the table contents. Requirements section is now 5
pages long, so bit more specific pointers would be useful in the table
of contents. 

>       are used throughout the document

Unfortunately at least I didn't want to read 269 pages to just get all
the terminology about SIP when reading this document. I would still
suggest replacing it with "User agent client (UAC)" in that one place
where it is used in this document. 

> [stf] I did nothing here, as the stated requirements is correct.

Why is there requirement that key negotiation packets MUST fail the
validity check? Or is this trying to say that they are not processed
at all by the validity check operations, i.e. they bypass them. This
requirement sound really wierd, and I do not really have any idea why
it is here and what it is trying to say, but as I do not know that
much about SIP, it might be that I just do not understand something. 

> 	Another, used by Security Descriptions, is to apply "late 

But it is still saying "late bindng" there, and "late binding" in
other places. I would guess the "bindng" should be "binding" here too. 
-- 
[email-masked]
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir