Re: [secdir] review of draft-ietf-mmusic-connectivity-precon-06

[Gonzalo Camarillo <[e-mail]>]

Hi Stephen,

thanks for your review. You are right that the current text is too 
vague. I have taken a stab at expanding it so that the threats and 
possible solutions are clearer. Let us know if this new text would 
address your comments.

The old text can be found at:

http://tools.ietf.org/html/draft-ietf-mmusic-connectivity-precon-06#section-7

The following is the new text:

7. Security Considerations

    General security considerations for preconditions are discussed in
    [RFC3312] and [RFC4032]. As discussed in [RFC4032], it is strongly
    RECOMMENDED that integrity protection be applied to the SDP session
    descriptions.  S/MIME [RFC3853] provides such end- to-end integrity
    protection, as described in [RFC3261]. Additionally, the following
    security issues relate specifically to connectivity preconditions.

    Connectivity preconditions rely on mechanisms beyond SDP such as
    TCP [RFC0793] connection establishment, or ICE connectivity checks
    [I-D.ietf-mmusic-ice] to establish and verify connectivity between
    an offerer and an answerer.  An attacker that prevents those
    mechanism from succeeding (e.g., by keeping ICE connectivity checks
    from arriving to their destination) can prevent media sessions from
    being established. While this attack relates to connectivity
    preconditions, it is actually an attack against the connection
    establishment mechanisms used by the endpoints. This attack can be
    performed in the presence or in the absence of connectivity
    preconditions. In their presence, the whole session setup will be
    disrupted. In their absence, only the establishment of the
    particular stream under attack will be disrupted. This
    specification does not provide any mechanism against attackers able
    to block traffic between the endpoints involved in the session
    because such an attacker will always be able to launch DoS (Denial
    of Service) attacks.

    Instead of blocking the connectivity checks, the attacker can
    generate forged connectivity checks that would cause the endpoints
    to assume that there was connectivity when there was actually no
    connectivity. This attack would result in a poor user's experience
    because the session would be established without all the media
    streams being ready. The same attack can be used, regardless of
    whether or not connectivity preconditions are used, to attempt to
    hijack a connection. The forged connectivity checks would trick the
    endpoints into sending media to the wrong direction. To prevent
    these attacks, it is RECOMMENDED that the mechanisms used to check
    connectivity are adequately secured by message authentication and
    integrity protection. For example, Section 2.5 of
    [I-D.ietf-mmusic-ice] discusses how message integrity and data
    origin authentication are implemented in ICE connectivity checks.



Thanks,

Gonzalo


Stephen Kent wrote:
> I reviewed this document as part of the security directorate's ongoing 
> effort to review all IETF documents being processed by the IESG.  These 
> comments were written primarily for the benefit of the security area 
> directors.  Document editors and WG chairs should treat these comments 
> just like any other last call comments.
> The document "draft-ietf-mmusic-connectivity-precon-06" defines "a new 
> connectivity precondition for the Session Description Protocol (SDP) 
> precondition framework." Connectivity preconditions are used to delay 
> session establishment (or modification) until media stream connectivity 
> has been verified. The use of preconditions represents an interesting 
> twist on the original SDP model, where the assumption was that an SDP 
> session would be established before media streams were established! The 
> use of preconditions is motivated in large part by the need for media 
> streams to traverse firewalls and NATs.
> 
> The Security Considerations section here starts by citing the Security 
> Considerations section from the base preconditions RFC (3312). It also 
> adds two paragraphs to discuss new considerations relevant to the 
> precondition types defined in this document. This is an appropriate way 
> to address new security issues that arise for extensions to 
> previously-defined functions. RFC 3312 has a two-paragraph Security 
> Considerations section, which identifies concerns, but make no 
> recommendations about security mechanisms to employ! This document has a 
> paragraph that RECOMMENDS use of integrity for the SDP traffic, e.g., 
> via RFC 3261, to counter attacks against this portion of the system. 
> This is a concrete recommendation that is appropriate for this aspect of 
> the security concerns cited, and is applicable to the 3312 security 
> concerns as well.
> 
> The new security concerns that arise here result from reliance on other 
> protocols to detect successful media stream establishment. This 
> motivates concerns about two classes of DoS attacks: transient attacks 
> that cause session establishment to fail (when the media streams could 
> have been created) and transient attacks that make it appear that media 
> streams have been established, when in fact they have not.
> 
> TCP and ICE are the protocols cited specifically as one of interest. The 
> text RECOMMDNDS making use of suitable authentication and integrity 
> mechanisms for the relevant protocols to counter both forms of attacks. 
> The text also says that "the mechanisms SHOULD consider how to prevent 
> denial of service attacks."
> 
> I find this text to be too vague to be useful. It ought to cite specific 
> mechanisms in RFCs, at least as examples, preferably as recommendations. 
> The lack of specific, cited mechanisms makes this section almost 
> vacuous. I suggest that the authors revise the text here to cite 
> appropriate mechanisms.