[Gen-art] RE: Gen-ART review of draft-ietf-mmusic-securityprecondition-02.txt

[[e-mail]]

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