Question: Radius over DTLS

[zbalkan]

I saw that most -if not all- RADIUS clients ignore TLS part, saying this should be handled by a third party tool like stunnel. But it sounds simpler with dtlspipe as there's no UDP<->TCP conversion is needed. Has anyone tried dtlspipe for RADIUS authentication? For instance, pam_radius -> dtlspipe -> network -> dtlspipe -> FreeRADIUS traffic looks promising but I just want to ask before creating a whole lab environment for this.

[Snawoot]

I haven't tried it with RADIUS, but I think it should work. In worst case you'll probably need to increase -idle-time to few minutes and set -stale-mode to both. But better start with defaults.

[zbalkan]

Umm. Well, that's a good case. In client side, we either need to initiate the dtlspipe by pam module or keep it running infinitely. On server side it should be running all the time. So, do I need to set the idle time option to maximum possible value or do I have another option?

[Snawoot]

Idle time is how long individual UDP conversation (and corresponding DTLS session) can be silent (not passing any traffic) before it will be considered dead. It's not lifetime of entire dtlspipe client or server application. Some sane timeouts are required for practical deployments, otherwise DTLS sessions will "leak", waiting packet from endpoint which contacted it long time ago. Even if such conversation will become active again, dtlspipe will just create new DTLS session transparently.

Default value for idle time is 30s, which is the same timeout used on NAT middleboxes on Linux for transit UDP packets. Probably such value is good for auth, and for accounting port you can set it to accounting interval multiplied by 2 or 3.

[zbalkan]

Thank you for correcting my misunderstanding. It looks like defaults would suffice as you have told earlier. And I will follow your other suggestions. Thanks!

[alexandervlpl]

Sorry if this is off-topic, but I'm sure other people will end up here considering this exact setup (UDP RADIUS over dtlspipe). I'm wondering if it's needed. To be clear, I'm aware of newer, more secure RADIUS implementations but upgrading isn't possible in my environment and sounds like that's a common situation.

My understanding is that RADIUS shared key entropy makes all the difference. Cracking a weak key is trivial, but with a long enough key we're talking 20-25 years GPU time. So a plain UDP setup on the public Internet is not ideal, but still reasonably secure for most organizations without resorting to extra layers/tunnels. Or am I missing something?

[Snawoot]

@alexandervlpl As far as I know RADIUS still doesn't provide confidentiality of data in packets. FreeRADIUS has an option to use TLS, but it requires client to support RadSec too and shifts protocol semantics from datagram-oriented to stream-oriented.

So, yes, it makes some sense and such need is recognized.

[alexandervlpl]

Yes, options are there but sadly many clients still can't be easily upgraded to TLS/Radsec.

RADIUS does provide "confidentiality", but using shared key MD5 crypto from 1991. :fearful: And I just learned there's a very fresh attack called Blast-RADIUS. Increasing key entropy like I first suggested doesn't help:

However, as our attack does not try to brute force the shared secret, choosing a strong shared secret does not affect the runtime of our attack.

So looks like you're right, this is a good use case for dtlspipe!