[radext] Review: draft-ietf-radext-radiusdtls-bis-15 — Implementation Observations

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

Hi all,
I've reviewed draft-ietf-radext-radiusdtls-bis-15 and have observations from implementing RADIUS/TLS in a production NAC platform.

1. Cipher Suite Minimum Requirements
Section 3.2 references RFC 9325 for TLS recommendations, which is appropriate. However, the draft only states that "negotiation of a cipher suite providing for confidentiality as well as integrity protection is REQUIRED" without explicitly recommending AEAD cipher suites (AES-GCM, ChaCha20-Poly1305) or discouraging non-AEAD suites (e.g., CBC-mode without encrypt-then-MAC). In practice, legacy NAS devices still attempt to negotiate weaker suites during the TLS handshake.
A brief note to prefer AEAD-based cipher suites, consistent with RFC 9325 Section 4.2, would strengthen the guidance for implementers who may not read RFC 9325 in full.

2. EKU Validation for Client Certificates
Section 3.3.1 covers certificate validation thoroughly but does not mention Extended Key Usage (EKU). In environments where a shared enterprise CA issues certificates for multiple purposes, a certificate intended for a web server could authenticate as a RADIUS client without EKU enforcement.
The recommendation to start with an empty CA trust base (Section 3.3.1) significantly mitigates this for private CA deployments. For shared CA environments, a recommendation that servers SHOULD validate id-kp-clientAuth in client certificates would provide defense-in-depth.

3. Migration Guidance (Section 7.7)
The guidance against reusing RADIUS/UDP shared secrets as TLS-PSK and the recommendation for separate configuration fields to prevent accidental reuse is practical and well-articulated — this will help avoid real-world misconfiguration.

4. TLS Key Rotation (Section 7.5)
Given that some RADIUS deployments maintain connections for days or weeks, it might be useful to include an informative guideline on maximum data volume or time before a key update or connection re-establishment is recommended.
Overall, this is a well-structured specification. The merge of RADIUS/TLS and RADIUS/DTLS into a single document is a significant improvement over the previous experimental RFCs.

Best regards,
Premanand Seralathan
Cisco Systems