[RTW] STUN and Offer/Answer for media authorization

[Harald Alvestrand]

On 02/16/11 18:02, Bernard Aboba wrote:
> The "Architectural Framework" document
> (http://tools.ietf.org/html/draft-rosenberg-rtcweb-framework) states in
> Section 4:
>
>     To avoid this attack [voice hammer], a simple handshake can be utilized.
> The
>     browser should support a simple STUN-based [RFC5389] connection
>     handshake.  The exchange of the STUN transaction ID prior to
>     transmission of media prevents the attack.
>
> While the exchange of the STUN transaction ID demonstrates that the target
> supports STUN, and therefore might be argued to be a necessary condition for
> transmission of media, is it sufficient condition?
>
> For example, if the STUN transaction ID is all that is needed to authorize
> transmission of media (e.g. no offer/answer required), then couldn't
> malicious Javascript be used to DoS a STUN server?  If offer/answer is also
> required, how is this handled?
Clarification: What do you mean exactly by "STUN server" in "DoS a STUN 
server"?

If it's the respondent to STUN messages used to establish connections 
(for instance by emulating ICE), I believe the mountable attack is to 
send a lot of STUN BIND-requests. There's not a lot of work involved in 
dropping those, but a rate limit might be a Good Thing.

As to offer/answer and establishing credentials:

I believe what's usefully exchanged (in the short-term credentials 
mechanism, which I think is the most appropriate one) is actually an 
username and a message-integrity value, which is computed based on a 
password (RFC 5389 section 10.1).

ICE (RFC 5245 section 7.1.2.3) creates an username consisting of one 
fragment generated by each end, which seems to set out to prove that 
communication between the endpoints has taken place prior to connection 
establishment.

Offer/answer using SIP and the ICE mechanism is one way of agreeing on 
credentials. At the moment, I don't see a powerful argument for why it 
has to be the only one; any mechanism that allows the respondent to 
rate-limit the generation of passwords that it's willing to accept would 
work.

But I may have missed something....