Re: [clue] Eric Rescorla's No Objection on draft-ietf-clue-signaling-14: (with COMMENT)

[Christer Holmberg <[e-mail]>]

Hi,

Would requiring SRTP be an option? Note that CLUE has been adopted (many years ago) in environments where usage of DTLS-SRTP is not defined.

Regards,

Christer

From: clue <[e-mail]> on behalf of Eric Rescorla <[e-mail]>
Date: Tuesday, 27 November 2018 at 17.12
To: Robert Hansen <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Roni Even <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [clue] Eric Rescorla's No Objection on draft-ietf-clue-signaling-14: (with COMMENT)


On Tue, Nov 27, 2018 at 1:55 AM Rob Hanton (rohanse2) <[e-mail]<mailto:[e-mail]>> wrote:
We did have specific protections as mandantory to use in earlier drafts. From version 05:

   ... discussion of video hammer attack ...
   This attack can be prevented by ensuring that the media recipient
   intends to receive the media packets.  Because of the way that CLUE
   can increase the severity of this attack, as well as because of the
   general increased awareness of the need to secure critical payloads,
   a CLUE-capable device MUST secure all CLUE-controlled RTP "m" lines
   using SRTP [RFC3711], and MUST support and use key negotiation and
   receiver intent assurance via DTLS [RFC5763] on these "m" lines.  For
   backwards compatibility, this is not a mandatory requirement for non-
   CLUE-controlled "m" lines.

https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/05/?include_text=1

This was then changed in version 06 and onwards following the discussion at IETF 92 and later where there was opposition to making the use of DTLS/SRTP mandatory to use. If I recall the two major concerns people had were:
1) This prevents implementations using a superior mechanism should one be developed

I don't think this is a real objection, If a new mechanism should be developed, then presumably it would also be documented in an RFC and we could update this one.

2) This prevents two devices from the same vendor using some alternate means of authentication (potentially proprietary) that would reduce the need for DTLS/SRTP
(Minutes: https://datatracker.ietf.org/doc/minutes-92-clue/ )

It's not a matter of authentication. It's a matter of path validation. For instance, if you were to have a situation where you had a cryptographic key but it did not have an interactive handshake, that would not provide the correct function. By contrast, ICE would.


So while everyone agreed that DTLS/SRTP should be mandatory to implement so it was always available, consensus ended up being removing the requirement to use DTLS/SRTP and instead having more generic language:

   This attack can be prevented by ensuring that the media recipient
   intends to receive the media packets.  As such all CLUE-capable
   devices MUST support key negotiation and receiver intent assurance
   via DTLS-SRTP [RFC5763] on CLUE-controlled RTP "m=" lines.  All CLUE-
   controlled RTP "m" lines must be secured and implemented using
   mechanisms such as SRTP [RFC3711].  CLUE implementations MAY choose
   not to require the use of SRTP to secure legacy (non-CLUE-controlled)
   media for backwards compatibility with older SIP clients that are
   incapable of supporting it.

https://datatracker.ietf..org/doc/draft-ietf-clue-signaling/?include_text=1<https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/?include_text=1>

Yes, but the problem is that this doesn't require any kind of consent validation at all, which creates an unacceptable amplification risk.

It seems to me that there are a number of options here:

1. Require DTLS-SRTP
2. Require ICE
3. Require *some* path-validating consent mechanism

However, just leaving the amplification attack does not seem OK.

-Ekr



All drafts have always had an exception for non-CLUE-controlled lines for backwards compatibility.

Rob

-----Original Message-----
From: Paul Kyzivat <[e-mail]<mailto:[e-mail]>>
Sent: 26 November 2018 19:49
To: Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Cc: Roni Even <[e-mail]<mailto:[e-mail]>>; IESG <[e-mail]<mailto:[e-mail]>>; Daniel Burnett <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Eric Rescorla's No Objection on draft-ietf-clue-signaling-14: (with COMMENT)

On 11/25/18 2:29 PM, Eric Rescorla wrote:
>
>
> On Sun, Nov 25, 2018 at 9:35 AM Paul Kyzivat <[e-mail]<mailto:[e-mail]>
> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>
>     On 11/25/18 8:14 AM, Eric Rescorla wrote:
>      >
>      >
>      > On Sat, Nov 24, 2018 at 9:41 PM Roni Even (A)
>     <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>      > <mailto:[e-mail]<mailto:roni.even@huawei..com> <mailto:[e-mail]<mailto:[e-mail]>>>> wrote:
>      >
>      >     Hi,____
>      >
>      >     The point that is made that in general CLUE is similar to no CLUE
>      >     RTP media calls. The difference is that since the EP may open
>     more
>      >     than one RTP video channel there is a greater risk of sending
>     more
>      >     media to the victim.
>      >
>      >
>      > Yes, but in order to have a useful countermeasure, that needs to be
>      > mandatory, and yours is not.
>
>     But one of the goals of clue is to be backward compatible with regular
>     sip calls. If we impose constraints on the media over and above those
>     required for regular sip calls then we lose that.
>
>
> ISTM that that's already not true for these media flows, because 4..4.1
> requires them to be inactive and you need to use an SCTP/DTLS control
> channel to negotiate them.
> What I'm saying is that those other flows should also have a consent
> check

I was more concerned with the basic audio and/or video in the initial invite, before it is known whether the answerer supports clue. I don't have a particular problem with putting further restrictions on the clue controlled media.

        Thanks,
        Paul