Re: [saag] RADIUS is deprecating MD5

[Alan DeKok <[e-mail]>]

On Apr 1, 2024, at 3:04 AM, Peter Gutmann <[e-mail]> wrote:
> It depends on whether RADIUS is being used for authentication or as a
> transport layer.  As I've already pointed out, with RADIUS-for-transport
> there's nothing to fix because RADIUS isn't doing anything that matters.

  I see I need to explain in more detail why this statement is factually incorrect.

  EAP transports user authentication credentials between unknown, and untrusted parties.  As part of the EAP conversation, they may determine that they can trust each other.

  RADIUS transports user authentication methods such as EAP between trusted, and known parties.  It also transports authorization and accounting data.

  EAP allows someone desiring network access to prove who they are to an authenticator.

  RADIUS clients act as a gatekeeper, and transport that EAP data (or PAP / CHAP / etc) to the authentication server.  The RADIUS server and EAP authenticator are usually co-located.

  When the authenticator determines that the user has been authenticated, it tells the RADIUS client to allow the user onto the network.  And gives the user specific authorization.  e.g. time-based limits, VLANs, etc.  The user is then allowed onto the network.  Summaries of their traffic (time, data transferred, etc.) is sent in RADIUS accounting packets.  This accounting data is used for billing, among other purposes.

  The use-case you keep mentioning of "RADIUS is useless. EAP-*TLS transports well-known passwords" is so rare as to be non-existent.  I've been doing RADIUS since 1996, and I can't recall ever seeing people do that.  I have to question the experience and knowledge of anyone who would build such a system.


  The usual analogy I give is that RADIUS is like a security guard for a secured campus.  The security guard won't let anyone in until they supply credentials.  The guard can check the credentials against the secure system inside of the campus.  However, the security guard does not issue credentials.

  The credentials are issued by the central site to the user, who keeps them, and then presents them to get access to the secured site.

  RADIUS + EAP follows the same design.  None of this has anything to do with UDP, fragmentation, reliability, etc.

  Saying "RADIUS isn't doing anything that matters" is completely misunderstanding what RADIUS does.  In the analogy above, the security guard is much more than a simple "transport for credentials".  The security guard is the gatekeeper.  If the credentials fail to be validated, the user is refused access.  If the credentials are revoked, the security guard ensures that the user leaves the campus.

  It is completely impossible for the "security guard" role to be performed solely with EAP.  RADIUS performs a critical role in closing the circle of trust.

  The user trusts the issuer of credentials.  The security guard trusts the issuer of credentials.  The user and security don't trust each other, until the issuer of credentials says to do so.

  RADIUS is not just a transport later for EAP.  I have no idea where you got that idea from, but it's completely wrong.  It misses about 99% of what RADIUS.

  I can only hope that this explanation helps clarify your understanding of what RADIUS does.  Because the other comments you've made are simply incorrect.  You have been misled severely as to what the protocols do.

  Alan DeKok.