Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations

[Oleg Moskalenko <[e-mail]>]

On Mon, Sep 23, 2013 at 10:02 PM, Melinda Shore <[e-mail]>wrote:

> I think you really need to be clearer about the distinction
> between NAT and firewall, and that firewalls are policy
> enforcement devices.


this distinction is a sort of academic exercise. I am not sure that
concentrating on that theoretical distinction has much of practical value
in the real world.


>
> I can give you a long, long list of reasons I don't like
> STUN (and, to a lesser extent, TURN),


For a person who does not "like" STUN and TURN you are dedicating too much
efforts to discussing them.


> but prominent among
> them is that without some sort of application-layer
> authentication it is trivially easy to use it to hijack media
> streams.  All you have to do is send a bogus STUN or
> TURN response with an address of your choosing, since the
> answer is unauthenticated.


TURN responses are always authenticated, if any security mechanism is
chosen. The client must check the integrity-field to authenticate the
response. Only the entity who knows the user password can construct a valid
response.

The only unauthenticated response (usually) is STUN "binding" response.
This is just an implementation convention that it is usually
unauthenticated. Nothing in RFC requires it to be unauthenticated. That's
only a common practice to leave it unauthenticated. For secure
environments, we can always enforce authentication of the BINDING response.



> Using TCP as the TURN
> transport makes an attack more challenging but it doesn't
> eliminate it entirely.  In VoIP scenarios, what they typically
> do is accept the response but then authenticate the
> application traffic, so if they get a bogus response
> the media streams can't be established, anyway.
> So, either think about how to protect against an insertion
> attack, or make it clear that you've got protection
> available at the application layer.
>

In very secure environments, the short-term authentication TURN mechanism
can be used. Each TURN Send and Data indications are authenticated in that
case. Then no application level authentication is necessary.

TURN is really a neat and clever tool, when you do understand how it works.