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

From: Stephen Kent <[email-masked]>
Date: Thu, 8 Oct 2009 06:40:31 -0400

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.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Oct 2009 11:10:01 -0400

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:
    Stephen> I find this text to be too vague to be useful. It ought
    Stephen> to cite specific mechanisms in RFCs, at least as
    Stephen> examples, preferably as recommendations. The lack of
    Stephen> specific, cited mechanisms makes this section almost
    Stephen> vacuous. I suggest that the authors revise the text here
    Stephen> to cite appropriate mechanisms.

Arje there any?  Last time I looked at ICE, it didn't have integrity
mechanisms.  Also, let's say that you added an integrity mechanism to
ICE.  How would it help against attacks that prevented media streams
from  being established?

You could defend against attacks that caused media streams to appear
to be established.  For example in the DTLS SRTP case, if you wait for
the DTLS negotiation to conclude, and if you exchanged a fingerprint
in SDP, you have fairly high confidence that you did in fact establish
the media stream.  I don't know how that interacts with everything
else going on in this draft.

One question I'd ask is how important are these attacks?  The first
category in particular--DOS attacks that prevent media streams from
appearing to establish--seems quite difficult to defend against.
Perhaps documenting it as a residual threat would be appropriate.

How much detail we go into to the second class of attack seems to
depend on how important of a threat it is.  If it is relatively
unimportant, perhaps it is sufficient to point out that integrity at
the media layer bound to an integrity protected exchange at the SDP
layer could be sufficient to defeat the attack.  I agree with Steve
that specific citations to such mechanisms should be included.
However if the attack is more important, then perhaps we need to
develop this into specific recommendations for common media stream
classes.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 8 Oct 2009 11:23:23 -0400

>ICE.  How would it help against attacks that prevented media streams

I didn't have anything in mind, but if there are no suitable 
references, then the RECOMMENDATION is disingenuous and definitely 
not acceptable, IMHO.

>...

I was not making a value judgement about the relative importance of 
such attacks, just stating what the authors chose to cite as security 
issues. An alternative would be for the authors to make an argument 
about why these DoS issues are not significant and thus that these 
new preconditions introduce no new security considerations. But, 
that's not what they chose to do.

See comment above.

Steve

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Oct 2009 12:02:43 -0400

>> 
    >> 
    >> Arje there any?  Last time I looked at ICE, it didn't have
    >> integrity mechanisms.  Also, let's say that you added an
    >> integrity mechanism to ICE.  How would it help against attacks
    >> that prevented media streams from being established?

    Stephen> I didn't have anything in mind, but if there are no
    Stephen> suitable references, then the RECOMMENDATION is
    Stephen> disingenuous and definitely not acceptable, IMHO.

You and I are in complete agreement here.

    >> ...  One question I'd ask is how important are these attacks?
    >> The first category in particular--DOS attacks that prevent
    >> media streams from appearing to establish--seems quite
    >> difficult to defend against.  Perhaps documenting it as a
    >> residual threat would be appropriate.

    Stephen> I was not making a value judgement about the relative
    Stephen> importance of such attacks, just stating what the authors
    Stephen> chose to cite as security issues. An alternative would be
    Stephen> for the authors to make an argument about why these DoS
    Stephen> issues are not significant and thus that these new
    Stephen> preconditions introduce no new security
    Stephen> considerations. But, that's not what they chose to do.

    Stephen> See comment above.

    Stephen> Steve _______________________________________________
    Stephen> secdir mailing list [email-masked]
    Stephen> https://www.ietf.org/mailman/listinfo/secdir

We're also in agreement here.  However it's my opinion that the
authors may want to engage in some thought about their threat model.
The primary point of my message was to encourage them to do that.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 16 Oct 2009 14:17:24 +0300

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.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 19 Oct 2009 12:06:26 -0400

>>>>> "Gonzalo" == Gonzalo Camarillo <[email-masked]> writes:

    Gonzalo> [RFC4032], it is strongly RECOMMENDED that integrity
    Gonzalo> protection be applied to the SDP session descriptions.
    Gonzalo> S/MIME [RFC3853] provides such end- to-end integrity
    Gonzalo> protection, as described in [RFC3261]. Additionally, the

I'm surprised you're referencing S/MIME here rather than something
like identity.
I understand none of the above  have huge deployment, but I thought we had a fairly strong understanding that S/MIME was not the direction we were moving towards.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 19 Oct 2009 09:11:38 -0700

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Monday, October 19, 2009 9:06 AM
> To: Gonzalo Camarillo
> Cc: Stephen Kent; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [secdir] review of 
> draft-ietf-mmusic-connectivity-precon-06
> 
> I understand none of the above  have huge deployment, but I 
> thought we had a fairly strong understanding that S/MIME was 
> not the direction we were moving towards.

You're right.  S/MIME doesn't work and and isn't used.  The 
suggestion for integrity protection should be RFC4474 ("SIP 
Identity").

-d