Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04

[Arran Cudbard-Bell <[e-mail]>]

On 8 Apr 2013, at 13:32, Sam Hartman <[e-mail]> wrote:

>>>>>> "Arran" == Arran Cudbard-Bell <[e-mail]> writes:
> 
>    Arran> On 8 Apr 2013, at 13:21, Sam Hartman <[e-mail]> wrote:
> 
>>>>>>> "Alan" == Alan DeKok <[e-mail]> writes:
>>> 
>    Alan> Or... we can delete all of the text around upgrade paths, and
>    Alan> just use a different port.
>>> 
>>> Well, I'm actually not sure about the security of this.  Even if
>>> you use a different port, don't you still have all the bid-down
>>> issues?  I mean what stops an attacker from sending you UDP
>>> traffic that's from a client that should be using DTLS.
> 
>    Arran> Presumably you would make this a dedicated DTLS port and
>    Arran> discard non-DTLS traffic.
> 
> Attackers have been known to choose the port that makes their attack
> work.
> The attacker will send you udp on the udp port and dtls on the dtls
> port.
> Ports aren't magic.

True. But a atching mechanism feasible eveywhere. I'd suggest that such a mechanism MUST be implemented, but suggest that it be SHOULD be configurable with high enough granularity to dictate behaviour for individual clients.

What having a dedicated DTLS port gets you, is the ability to mandate that between network boundaries only encrypted RADIUS traffic may pass. This would otherwise be difficult to enforce without DPI. 

> From a security standpoint, what the upgrade logic does is reduce the
> number of senders who are permitted to send you UDP.

It also requires that the RADIUS server be able to persistently store this latching state for this to be effective. This is a new and potentially problematic issue for a RADIUS server which up to now had not had to dynamically modify its own configuration.

Allowing a daemon to modify any part of its configuration is generally considered bad practice, and where systems operate in a 'deep freeze' state provisions would have to be made for storing this information off box.

Whilst this is an implementation issue it may hinder uptake in some cases, which is why the latching should be optional.

> That's most effective if you use a different secret for each UDP sender.

Indeed.

> Each time you reduce the number of secrets that you accept for UDP
> traffic you increase security.

Agreed. Reducing the number of IP addresses unencrypted traffic is accepted from reduces the range of IPs that can be used for a brute force attack, reducing the number of secrets also makes it less likely that such an attack would be successful. 

As an aside, were still working under the assumption that it's non-trivial to recover the shared secret from unecrypted RADIUS packets, correct?

-Arran