Re: [rtcweb] STUN for keep-alive

[Magnus Westerlund <[e-mail]>]

On 2011-09-19 19:36, Randell Jesup wrote:
> On 9/19/2011 10:39 AM, Magnus Westerlund wrote:
>> Hi,
>>
>> As an individual I like to provide some analyze of the entropy in
>> RTP/RTCP. Please consider, comment and provide opinion about the number
>> of bits.
> Thanks for the excellent analysis, Magnus.
> 
>> On 2011-09-16 20:30, Eric Rescorla wrote:
>>>> The RTCP receiver reports should be adequate for 'consent freshness', no?
>>>> If I still like receiving the traffic, I'll report that I'm receiving it.
>>>> If I have crashed or disconnected or am not listening on that port, I won't.
>>> I believe so, though I'd have to make sure there's enough entropy. And of course
>>> some implementations may not do RTCP...
>>>
>> So one case of attack is the one when the webserver S uses the connected
>> clients to attack target T by instructing client C to send to target T.
>> So the Server or some server controlled entity A needs to send RTCP to C
>> that makes C believe T is responding, i.e. spoofed source address that
>> are T's plus the content of the RTCP RR. Please note that SRTP will not
>> provide any protection if the webserver knows the key. Thus if security
>> description is allowed, which appear reasonable if supporting legacy is
>> the goal, which is the reason for this whole proposal.
> 
> I would disagree with one aspect of that: I don't know that we need to
> support SDES, and if we do, we only need to support it for "legacy"
> connections, not true webrtc browser-to-browser connections, which I
> assert should always be DTLS.  Of course, non-encrypted RTP to a legacy
> device would have no protection against spoofing of return RTCP at all.

I think this analyze is valid for several different proposals that has
been raised.

1) Consent Freshness, i.e. the verification that a previous verified
destination continues to be present

2) Use RTCP instead of ICE for delivery consent, especially against
legacy which likely doesn't support ICE nor SRTP.

And I would also observe that we have no WG consensus on the security
mechanism. We have no WG document containing an assumption, nor have we
made a consensus call about what mechanism to support. I agree that DTLS
seems to have strong support as default keying mechanism, but also their
has been a fair amount of voices that thinks Security Descriptions
should be supported also to make keying towards legacy SRTP systems much
simpler.

Yes, it is likely time to do the consensus calls on the media security
mechanisms so that will be settled.

> 
> Note that we need to complete a valid ICE exchange with the target
> per the current spec, so T can only be attacked to begin with if the ICE
> exchange can be spoofed.  The original scenario from Eric was about "how
> do I determine if the recipient wants to *continue* to receive data
> after a valid exchange (for example after ending the call or
> rebooting/crashing).  I haven't checked the properties of ICE and the
> ability to spoof it, but before analyzing the entropy required to attack
> the return RTCP 'freshness' state, we need to show that the attack could
> be begun, or state that ICE is not mandatory for some connections.

But, if we want to look at not using ICE with legacy and still establish
consent to receive then RTCP has been discussed and I did want to
provide some indication of how strong this is.

Which I agree is fairly week, that considering that one appear to need
several RRs in sequence that are consistent combined with the reporter
having received SRs to be reasonably sure, which implies 10-30 seconds
before consent is being established as a less than working idea.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------