responding to BlastRadius

[Alexander Bokovoy]

On Срд, 10 ліп 2024, Alexander Bokovoy wrote:
>On Аўт, 09 ліп 2024, Sam Hartman wrote:
>>
>>So, I'e always been uncomfortable with the decision to  have a KDC
>>talking to a RADIUS server.
>>But it looks like another round of attention is being focused on RADIUS
>>vulnerabilities: https://www.blastradius.fail/
>>
>>I tend to agree with the title of the paper: RADIUS over UDP considered
>>harmful.
>>
>>I've always been confused why Kerberos started its journey into RADIUS
>>land with a library that did not support TLS.
>>I guess the argument was that the proprietary RADIUS servers for some
>>OTP applications didn't support anything better.
>>And perhaps that's still true.
>>So perhaps there's nothing we can do.
>>But it at least seems like a good time to revisit the use of RADIUS and
>>ask ourselves whether there are changes or recommendations we should be
>>making.
>
>In the default configuration we talk to a UNIX domain socket over
>RADIUS, not to some UDP/TCP-backed server. This is what FreeIPA KDC does
>use to implement all (except PKINIT) passwordless pre-authentication
>methods. When talking locally over UNIX domain socket, we inheretly
>trust the other side and being on the same system, we control its setup.
>
>It would be good to have RFC 6613 (RADIUS over TCP), RFC 6614 (RADIUS
>over TLS), and RFC 7930 (Large packets for RADIUS over TCP) supported.
>But I feel the support for them can be moved away to that UNIX domain
>socket responder part as well and handled there.

A small update. Julien implemented Message-Authenticator support as
FreeRADIUS and other RADIUS servers use it on UDP/TCP connections now.
This is available in https://github.com/krb5/krb5/pull/1370


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland