[Gen-art] Gen-ART review of draft-ietf-mmusic-securityprecondition-03.txt

[[e-mail]]

Brian,

There was follow-up email, but neither you nor Gen-ART were included
it.  Here's the extract from that email that should be considered
to be the Gen-ART review of -03 (plus a header for Mary).

Document: draft-ietf-mmusic-securityprecondition-03.txt
Reviewer: David L. Black
Review Date: 9 December 2006
IESG Telechat date: 14 December 2006 

Summary:

This draft is basically ready for publication, but has nits
that should be fixed before publication.

Comments: 

  I checked the -03 vs. -02 diff and the major issues have been
resolved.

  In the new security considerations section, I didn't see any mention
  of downgrade attacks (man-in-the-middle removes secure alternative
  from negotiation, causing use of non-secure streams when secure
streams
  would have been used in his absence) - this mention is ok to omit, as
  the important point that the offerer's security policy allows
non-secure
  streams in this situation has been added.  Similarly, the security
  considerations section doesn't say how to avoid the "malicious
malicious
  media stream packets until the answer (indicating the chosen secure
  alternative) is received" vulnerability, but it's reasonably clear
from
  context that the only obvious way to avoid it is to not offer the
  non-secure alternative.

  I saw this typo in the new text in Section 3:
	
     At that moment, we furthermore require that ser agents MUST start
                                                 ^^^

  That's an editorial nit that the RFC Editor will have no difficulty
  in correcting.

Thanks,
--David

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]] 
> Sent: Friday, December 08, 2006 10:52 AM
> To: Black, David
> Cc: Mary Barnes
> Subject: Re: [Gen-art] RE: Gen-ART review of 
> draft-ietf-mmusic-securityprecondition-02.txt
> 
> The -03 draft has popped up on the 12/14 IESG agenda as a
> slightly late addition, which I think was too late for Mary's
> sweep.
> 
> Was there any follow-up email? If so, I didn't see it.
> 
> I'd appreciate it if you could have a quick glance at the
> -03, to see if they fixed the more serious points.
> 
>      Brian
> 
> [e-mail] wrote:
> > Oops, serious typo ...
> > 
> > 
> >>That handles one of the two concerns, when it is safe to begin using
> >>the old parameters.  The other concern of when it is safe to cease
> > 
> >       ^^^
> >       new
> > 
> > Sorry,
> > --David
> > 
> > 
> >>-----Original Message-----
> >>From: Black, David 
> >>Sent: Monday, July 24, 2006 7:44 PM
> >>To: [e-mail]; '[e-mail]'; '[e-mail]'
> >>Cc: Black, David; 'Joerg Ott'; 'Colin Perkins'; 
> >>'Jean-Francois Mule'; 'Peterson, Jon'
> >>Subject: Gen-ART review of 
> >>draft-ietf-mmusic-securityprecondition-02.txt
> >>
> >>Flemming and Dan,
> >>
> >>I am the assigned Gen-ART reviewer for
> >>draft-ietf-mmusic-securityprecondition-02.txt .
> >>
> >>For background on Gen-ART, please see the FAQ at
> >><http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
> >>
> >>Please resolve these comments along with any other
> >>Last Call comments you may receive.
> >>
> >>This draft is on the right track but has open issues,
> >>described in the review.
> >>
> >>The draft does a good job describing the precondition mechanism
> >>and giving examples of its usage, but has several security
> >>issues that need attention:
> >>
> >>(1) Section 3, near end:
> >>
> >>   Offers with security preconditions in re-INVITEs or 
> UPDATEs follow 
> >>   the rules given in Section 6 of RFC 3312, i.e.: 
> >>    
> >>     "Both user agents SHOULD continue using the old session
> > 
> > parameters  
> > 
> >>     until all the mandatory preconditions are met.  At that moment,
> > 
> > 
> >>     the user agents can begin using the new session parameters."
> >>
> >>That handles one of the two concerns, when it is safe to begin using
> >>the old parameters.  The other concern of when it is safe to cease
> >>using the old parameters also needs to be covered.  This is
> > 
> > particularly
> > 
> >>important for security, as when encryption parameters are removed,
> >>they are typically destroyed making it impossible to process
> > 
> > subsequent
> > 
> >>traffic that uses them.  One could easily follow the rule cited here
> >>and still insert a glitch in an ongoing call by retiring the old
> >>receive security parameters too early for in-flight traffic.
> >>
> >>(2) Section 4.1
> >>
> >>   SDP2: When B receives the offer and generates an answer, B knows
> > 
> > the 
> > 
> >>   (send and recv) security parameters of both A and B.  However, A 
> >>   does not know B's security parameters, so the current 
> status of B's
> > 
> > 
> >>   "send" security precondition (which equal A's "recv" security 
> >>   precondition) is "no".  Similarly, A does not know any 
> of B's SDP 
> >>   information, so B's "send" security precondition is also "no". 
> >>
> >>The latter sentence above should refer to B's "recv" security
> >>precondition.  Even with that change, it does not appear to be
> > 
> > correct,
> > 
> >>as based on the reasoning given, B now knows how to decrypt traffic
> >>from A, even though A can't send traffic yet.  Either B's "recv
> >>security precondition becomes "yes" at this point, or a longer
> >>discussion is needed of B's behavior with respect to the "recv"
> >>precondition.  The former is preferable, as one would like to ensure
> >>that the ability to receive is established before the counterparty
> >>tries to send.
> >>
> >>Section 4.2 has an analogous issue (when does B's "recv" 
> become "yes")
> >>at SDP2, but without the "send" vs. "recv" confusion:
> >>
> >>   Similarly, A does not know any of B's SDP information, so B's
> > 
> > "recv" 
> > 
> >>   security precondition is also "no"
> >>
> >>It needs the same treatment (either B's "recv" becomes "yes" at this
> >>stage, or a longer explanation is provided).
> >>
> >>In both 4.1 and 4.2, if B's "recv" does not become "yes" until SDP4,
> >>an explanation needs to be added about why A will not send traffic
> >>using B's security parameters until A receives the PRACK and/or the
> >>180 (Ringing) Response, or alternatively why it is ok to discard any
> >>such traffic at B.
> >>
> >>(3) Section 5, Security Considerations
> >>
> >>The discussion of offering both a secure and non-secure stream
> >>alternative is confusing, and missing some important points.
> >>It should be cleaned up and address the following three points:
> >>
> >>a) Since support does not exist to combine secure and non-secure
> >>alternatives in an offer, this draft should say that such 
> combinations
> >>SHOULD NOT be used until the work to specify them is complete.
> >>Alternatively, the draft should explain how [SDPCN] supports this
> >>combination and include [SDPCN] as a normative reference.
> >>
> >>b) When secure and non-secure streams are offered as alternatives,
> >>the offerer's security policy includes "no security is acceptable".
> >>This needs to be stated.  In addition, the "downgrade" attack where
> >>a man-in-the-middle removes the secure alternative(s) needs to be
> >>discussed.  I believe that signaling integrity (as discussed earlier
> >>in the section) is the countermeasure for this "downgrade" attack,
> >>but end-to-end authentication (or hop-by-hop authentication of all
> >>hops) is necessary to achieve this result - that should also 
> >>be stated.
> >>
> >>c) The end of the next-to-last paragraph says (wrt an 
> active attacker
> >>injecting unsecured packets):
> >>
> >>   Use of security preconditions would not address this 
> >>   vulnerability since security preconditions do not 
> guarantee that a 
> >>   media stream established is secure, even if the strength-tag is 
> >>   "mandatory".
> >>
> >>It should be the case that security preconditions + a 
> policy requiring
> >>secure connections + signaling integrity is sufficient to address
> >>this vulnerability, and that needs to be stated.  The last sentence
> >>in the last paragraph of Section 5 has a similar issue.
> >>
> >>--- Nits
> >>
> >>The header of the draft needs to say that it Updates: RFC 3312 (and
> >>RFC 4032 if that is also affected).
> >>
> >>Section 3, near beginning:
> >>
> >>     Note 
> >>     though, that use of SRTP without authentication is 
> discouraged.  
> >>
> >>Due to the use of "integrity" elsewhere in this draft,
> > 
> > "authentication"
> > 
> >>will be interpreted by default as per-session entity authentication.
> >>If per-packet authentication (i.e., keyed message integrity check)
> >>was intended, language including the word "integrity" should be used
> >>for consistency with the rest of the draft.
> >>
> >>Thanks,
> >>--David
> >>----------------------------------------------------
> >>David L. Black, Senior Technologist
> >>EMC Corporation, 176 South St., Hopkinton, MA  01748
> >>[phone]             FAX: [phone]
> >>[e-mail]        Mobile: [phone]
> >>----------------------------------------------------
> >>
> > 
> > 
> > _______________________________________________
> > Gen-art mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/gen-art
> > 
> 
> 

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art