> -----Original Message-----
> From: Elwyn Davies [mailto:[email protected]]
> Sent: Friday, October 10, 2008 3:28 PM
> To: General Area Review Team
> Cc: Mary Barnes; [email protected];
> [email protected];
> [email protected]
> 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 protected]
https://www.ietf.org/mailman/listinfo/gen-art
