Subject: Re: [Gen-art] Gen-art review of draft-ietf-sip-media-security-requirements-07

From: "Dan Wing" <[email-masked]>
Date: Thu, 8 Jan 2009 10:08:14 -0800

> -----Original Message-----
> From: Elwyn Davies [mailto:[email-masked]] 
> Sent: Friday, October 10, 2008 3:28 PM
> To: General Area Review Team
> Cc: Mary Barnes; [email-masked]; 
> [email-masked]; 
> [email-masked]
> Subject: Gen-art review of 
> draft-ietf-sip-media-security-requirements-07
> 
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> _http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).

Thanks for your review.

> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-sip-media-security-requirements-07.txt
> Reviewer: Elwyn Davies
> Review Date:  10 October 2008
> IETF LC End Date: 13 October 2008
> IESG Telechat date: (if known) -
> 
> Summary:
> This document is almost ready for the IESG.  I have a couple 
> of comments 
> and queries about the reasoning in a few of the requirements.  
> Meta-comment:  To a non-SIPper the problems to be solved and the 
> requirements look very challenging!  And to think S in SIP might once 
> have meant...
> Disclaimer: Whilst the requirements appear sensible and internally 
> consistent, I have no idea if the set is complete or really 
> appropriate. 
> The explanations in s4 are very helpful and clear for a naive reader 
> like me. Likewise, I do not have the necessary knowledge to 
> verify the 
> statements in the various appendices relating to existing proposals.  
> Again they look reasonable sensible.
> 
> Comments:
> s5.1, Requirement R-RTP-VALID:  I think some explanation of  
> why '...the key
>          negotiation packets MUST NOT pass the RTP validity check
>          defined in Appendix A.1 of [RFC3550].' would help.  
> This looks 
> like a magic incantation to me at present!

Added "so that SRTP negotiation packets can be differentiated 
from RTP packets".  Due to another comment we also renamed this
requirement from R-RTP-VALID to R-RTP-CHECK.

> s5.1, Requirement R-NEGOTIATE:  'The media security key management 
> protocol MUST allow a SIP
>          User Agent to negotiate media security parameters for each
>          individual session.'   Does this imply that the protocol MAY 
> allow the SIP UA to use the same parameters for several 
> sessiosn if it 
> wants to? Might be wise to be explicit.. but I may not understand the 
> situation.

Added "Such negotiation MUST NOT cause a two-time pad (Section 9.1 of
[RFC3711])."

> s5.2, Requirement R-FIPS:  Whilst I know that the FIPS 
> process is often 
> cited other than in the US, this requirement appears very US 
> centric.  
> Are there other similar requirements from other countries 
> that ought to be considered?

Added "or similar country-specific certification (e.g., [AISITSEC])."

   [AISITSEC]
              "Anwendungshinweise und Interpretationen (AIS) zu ITSEC",
              January 2002,
              <http://www.bsi.de/zertifiz/zert/interpr/aisitsec.htm>.

> s5.2, Requirement R-DOS:  Whilst I know that it is probably 
> impossible 
> to guarantee that a given solution will not introduce some arcane DOS 
> opportunity that no one has thought of, it seems to me that 'MUST NOT 
> introduce any foreseeable (or, maybe, significant) new DoS 
> vulnerabilities' would be better than SHOULD NOT, which allows for 
> possible weaseling.

Ok.  It now reads:

   R-DOS:
         The media security key management protocol MUST NOT introduce
         any new significant denial of service vulnerabilities (e.g.,
         the protocol should not request the endpoint to perform CPU-
         intensive operations without the client being able to validate
         or authorize the request).

> Nits:
> 
> s4.2, last line on p.9: s/ares/are/
> sA.5.4, MIKEY-NULL bullet: s/computaional/computational/
> idnits reports:
> draft-ietf-sip-media-security-requirements-07.txt(1166): Line 
> has weird 
> spacing: '...ication  along...'
> Several references are now at later versions and 
> draft-ietf-msec-mikey-applicability has been published as RFC 5197.

Fixed all those nits (except idnits whining about spacing, which
is due to spacing within a bibxml title; RFC editor will have
to fix that one).

We are close to publishing the changes.  In the meantime they
are available at 
http://www.tschofenig.priv.at/svn/draft-wing-media-security-requirements/draft
-ietf-sip-media-security-requirements-09.txt

Sorry for the delay in integrating these changes.

-d

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