Re: [rtcweb] Security analysis of RTCWEB

[Eric Rescorla <[e-mail]>]

On Mon, Jan 16, 2012 at 8:51 AM, Bernard Aboba
<[e-mail]> wrote:
> This discussion illustrates some of the issues that arise in analyzing the
> security of SIP-based functionality re-purposed for RTCWEB.  If we assume
> that signaling is not implemented natively, then we cannot depend on
> functionality provided within signalling in our security analysis.   This
> implies that the security properties of ICE, DTLS/SRTP, etc. can be
> different in RTCWEB than they would be within SIP.   In contrast, the
> security properties of media-only approaches such as ZRTP are the same
> regardless of the signalling approach (e.g. SIP, Jingle, etc.).
>
> Within DTLS/SRTP as used in SIP, RFC 4474 is utilized to provide end-to-end
> integrity of the SDP and address the man-in-the-middle attack you refer to
> below.   In a scenario where an RTCWEB application needed to interoperate
> with a DTLS/SRTP implementation utilizing SIP, presumably RFC 4474 would be
> supported.
>
> However, if SIP is not implemented natively, then an alternative mechanism
> is needed.  As you point out below, the identity provider approach described
> in the security draft does not address all of the potential attacks that are
> handled by RFC 4474 (e.g. ICE mangling).

I'm not tracking this argument at all:

1. If you have end-to-end integrity for the keying material, then providing
end-to-end security for the ICE candidates only offers modest additional
value, since all it does is prevent rerouting of the ciphertext.

2. There's no technical reason why the IdP-based approach detailed in
Appendix A can't cover the ICE candidates as well. Indeed, it's natural
to have it cover as much of the message as possible. However,
since we haven't yet settled on the signaling protocol, it's also not
possible to settle on the exact inputs to the signature. However, the
minimum necessary is the public key of the side.

3. In the RTCWEB setting, since the STUN and TURN servers are likely
to be supplied by the signaling site, it's probably not that difficult for a
malicious signaling server to simply provide STUN and TURN responses
which reroute the traffic through it without tampering with the ICE
candidates at all. E.g., it provides a bogus server-reflexive address, thus
forcing ICE to converge on its TURN server.

-Ekr

>> Sorry, yes it should be the other way around.
>>
>> I agree that eavesdropping on a DTLS-SRTP call is harder and would require
>> a greater (initial) coding effort. But the difference is not huge as some
>> emails seem to suggest.
>>
>> 1. Search for 'a=fingerprint:' in the offer/answer SDP string and replace
>> what comes after with your own public key fingerprint (a single, statically
>> configured public key would probably do if synching with the TURN server is
>> hard)
>>
>> 2. Force the media to go through the TURN server by deleting all ICE
>> candidates except the relayed one (if deleting is not possible another
>> option is to replace the candidates with bogus ones)
>>
>> 3. Modify an existing TURN server implementation so that it decrypts and
>> re-encrypts the DTLS traffic
>>
>> Regards,
>>
>> Oscar Ohlsson
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>