Draft: draft-ietf-mmusic-securityprecondition-02.txt Reviewer: Black_David@emc.com Review Date: Monday 7/24/2006 6:44 PM IETF LC Date: 8/02/2006 Summary: 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.