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

[[e-mail]]

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