W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2018

Re: Ban ICE-LITE? webRTC and Content Security Policy connect-src

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Fri, 12 Jan 2018 15:01:33 +0100
Message-ID: <CALiegf=JvXx7fP9FjSbzzXNHiyiDMowbs=6BRbUfy68GGp9GKA@mail.gmail.com>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: Harald Alvestrand <harald@alvestrand.no>, T H Panton <thp@westhawk.co.uk>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Cullen Jennings <fluffy@iii.ca>
On 12 January 2018 at 14:46, Sergio Garcia Murillo
<sergio.garcia.murillo@gmail.com> wrote:
> Disclaimer: I did my ICE lite implementation 5 years ago, so I maybe
> completely wrong.
>
> We are assuming that ICE lite is less secure that full ICE because in full
> ICE you need to know the remote ufrag in order to create the request, right?

Yes. In Full ICE both endpoint need to send STUN requests (including
remote credentials) *before* media can be sent by any of them. Not
true in ICE Lite (obviously).



> But that information will be available at the full ice endpoint as soon as
> the first incoming stun binding request is received. So wouldn't this mean
> that both full ice and ice lite are equally insecure?

Why? The STUN Binding Request does not include the sender's
credentials, but the remote ones.



> As Iñaki is pointing out what would be needed is to use the remote pwd
> (which is not exchanged in stun request) in order to authenticate also the
> remote peer. This is something I have never understood about ICE, why it
> requires both ufrags to form the username, but only uses the local password
> for fingerprinting (I assume is to speed up setup up times not having to
> wait for remote peer info before starting ICE). Using local_pwd:remote_pwd
> for fingerprinting would solve this issue altogether for both ice and
> ice-lite.

Agreed.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>
Received on Friday, 12 January 2018 14:02:22 UTC

This archive was generated by hypermail 2.3.1 : Friday, 12 January 2018 14:02:22 UTC