[radext] Re: Review: draft-dekok-radext-review-radius-00 — Cipher Suite and EKU Considerations

["Premanand Seralathan (pseralat)" <[e-mail]>]

Thank you, Alan, for the detailed response.
The TLSbis document's approach to cipher suite requirements and certificate trust makes sense as the normative home for these recommendations. I agree that separating the review document's scope from the standards-track TLSbis avoids conflicting guidance.
The point about private CAs reducing EKU risk is well taken — in practice, organizations that deploy dedicated private CAs for their RADIUS infrastructure do have much tighter control over certificate purpose. The concern is more acute in environments where a shared enterprise CA issues certificates for multiple services, but as you note, the TLSbis recommendation to start with an empty CA trust base and require explicit administrator configuration addresses this at the root.
I'll review the TLSbis document and provide any additional feedback there if appropriate.
Regards,
Premanand Seralathan


On 3/12/26, 12:10 PM, "Alan DeKok" <alan.dekok=[e-mail]> wrote:

On Mar 12, 2026, at 11:51 AM, Premanand Seralathan (pseralat) <pseralat=[e-mail]<mailto:[e-mail]>> wrote:
> I've reviewed draft-dekok-radext-review-radius-00 and would like to raise two additional security considerations that I believe warrant discussion in this document.

  Thanks for the review.

> 1. Cipher Suite Enforcement for RADIUS/TLS Deployments
> Section 1.4 correctly notes that "simply using IPsec or TLS is not enough," but the discussion focuses on forward secrecy and proxy trust. The document does not address the risk of weak cipher suite negotiation in RADIUS/TLS deployments.
> In large-scale enterprise NAC deployments, it is common to encounter legacy NAS devices (switches, wireless controllers) that still support or prefer weak TLS cipher suites — CBC-mode ciphers without AEAD, RSA key exchange without Perfect Forward Secrecy, or even export-grade ciphers. If the RADIUS server does not enforce a strict cipher suite policy, TLS negotiation may silently downgrade to a weaker cipher, undermining the security guarantees that the migration to RADIUS/TLS is intended to provide.

  Much of the discussion around RADIUS/TLS security and cipher suites is in the TLSbis document:

https://datatracker.ietf.org/doc/html/draft-ietf-radext-radiusdtls-bis-15#name-dtls-requirements

  i.e. we don't want this draft to conflict with the normative / standards-track document which specifies RADIUS/TLS.

> I would suggest that Section 1.4 (or a new subsection) include a recommendation that RADIUS/TLS implementations SHOULD enforce minimum cipher suite requirements — specifically preferring AEAD ciphers (AES-GCM, ChaCha20-Poly1305) and key exchange methods providing forward secrecy (ECDHE). This aligns with the recommendations in RFC 9325 (formerly BCP 195).

  I think it's better to just have this document point to the TLSbis document.  I'll do some updates.

> >From practical experience implementing FIPS 140-2/140-3 compliance and TLS hardening in a production NAC platform, the transition from MD5-based RADIUS/UDP to RADIUS/TLS only achieves its security objectives when cipher suite selection is also controlled.

  Agreed.

> 2. Extended Key Usage (EKU) Validation for RADIUS/TLS Client Certificates
> The document references certificate validation issues in Section 1.3, noting that implementations have "historically often skipped certificate validation." However, it does not discuss the specific risk of missing or unenforced Extended Key Usage (EKU) constraints on RADIUS client certificates.

  I think this text is again best dealt with in the TLSbis document.

> When RADIUS/TLS is used, the RADIUS client (NAS) authenticates to the server using a TLS client certificate. If the server does not enforce the presence of the id-kp-clientAuth EKU in the client certificate, then any certificate issued by a trusted CA — including certificates intended for web servers (id-kp-serverAuth), email signing, or other purposes — could potentially be used to impersonate a legitimate RADIUS client.

  There are a whole bunch of issues related to EKU usage and validation.  But the most important one is to not use public CAs.  The TLSbis document discusses this:

https://datatracker.ietf.org/doc/html/draft-ietf-radext-radiusdtls-bis-15#name-authentication-using-x509-c

...
RadSec endpoints SHOULD NOT be pre-configured with a set of trusted CAs by the vendor or manufacturer that are enabled by default. Instead, the endpoints SHOULD start off with an empty CA set as the trust base. The addition of a CA SHOULD be done only when manually configured by the administrator. This does not preclude vendors or manufacturers including their set of trusted CAs in their products, but the enabling of those lists should require an explicit act by an administrator.
...

  There main reason for that requirement is that the public CAs are used to trust _servers_.  i.e.  I want to know that I'm accessing the right "google.com <http://google.com/>".  But the clients are (pretty much) entirely unauthenticated.

  The RADIUS trust model is different.  Both parties have to trust each other.  There are vanishingly few reasons for a RADIUS server to trust random client certificates.

  In general, it's best for organizations to use a private CA.  That way they can control the issuance of client and server certificates.  They can also control the EKUs in the certs.

  If both parties are using a private CA, then the issue of EKUs becomes much less relevant.

> This risk is amplified in enterprise environments where a single CA infrastructure issues certificates for multiple purposes. Without strict EKU enforcement, the security boundary between RADIUS client authentication and other certificate uses is effectively absent.
> I would suggest that the document include a recommendation that RADIUS/TLS server implementations SHOULD validate the EKU of client certificates and reject connections from certificates lacking the appropriate EKU for client authentication.

  Text about EKUs should be in the TLSbis document.  I'll update the "review" document to minimize any possible conflict between the two documents.

  Alan DeKok.