Subject: [MMUSIC] ICE issue 4: p2p STUN authentication and sips

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Jul 2005 11:31:17 -0400

The draft is somewhat vague on whether or not the p2p stun connectivity 
checks need to be authenticated, and furthermore whether or not the 
signaling used to carry the offers and answers needs to be protected 
(via something like sips).

This vagueness is largely because, I'm not sure.

No doubt, using sips and authenticating the p2p connectivity checks 
provides better security than not doing it. However, the ICE mechanism 
itself prevents numerous attacks that would otherwise be possible 
without ICE, and as such I am not certain what strength to recommend for 
this.

As an example, consider an attacker that injects a fake STUN request 
towards one of the endpoints, with the source IP and port of a target of 
a dos attack. The endpoint adds the source IP and port as a candidate, 
and begins connectivity checks to it. However, the target of the dos 
attack won't respond, so the address is never used. Even if the target 
was a voip endpoint, it won't have the transport ID (tid) and so can't 
generate a valid STUN response. So, dos attack avoided - with no crypo.

Now, other attacks are not so easily thwarted. Consider the same attack, 
but the source IP and port are that of the attacker, who wishes to 
insert himself as a middleman in the media stream. Here, the 
connectivity check from the endpoint to the attacker will work if sips 
is not used to protect the tid. However, even if it DOES work, the 
endpoint won't send media to the attacker unless the other endpoint 
includes that IP address and port in the m/c line of its offer/answer. 
To get the other endpoint to do that, it has to inject a fake STUN 
response towards the STUN connectivity checks from that other endpoint. 
As such, this is now a much more complicated attack to launch, requiring 
fairly coordinated messaging and prevention of valid packets from being 
sent. Admittedly, the attack is foiled completely by sips and stun 
authentication. Does this mean that sips/stun auth is a MUST, MAY or SHOULD?

Why not just make it MUST? Reality, I think. We saw this with STUN 
itself. STUN's security is complicated - more complicated than the rest 
of STUN. As a result, it has seen pretty much zero usage AFAIK. 
Mandating sips and stun authentication with ICE at MUST strength is not 
likely to be followed. So, I'd rather figure out what level of security 
and protection ICE affords without those tools, and make realistic 
recommendations accordingly.

Thoughts?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic