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: [email protected]; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> 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
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> [EMAIL PROTECTED] Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
