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? 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? 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. Best regards Sergio On 12/01/2018 14:19, Harald Alvestrand wrote: > To me, it sounds like we should ban ICE-LITE altogether. > > We've got a lot of security story resting on the idea that the ICE > request/response requires both ends to have seen the SDP. > If that isn't true for ICE-LITE, then ICE-LITE is not safe for WebRTC. > > On 01/12/2018 01:20 PM, Sergio Garcia Murillo wrote: >> Missed it, that will prevent it, right. >> >> On 12/01/2018 13:11, T H Panton wrote: >>> >>> That's covered in my proposal: >>> >>>> add a CSP turn-servers whitelist (to prevent leakage via the >>>> credentials) >>> >> >
Received on Friday, 12 January 2018 13:46:24 UTC