Re: [radext] Proposed charter text based on IETF-115 BoF

[Alan DeKok <[e-mail]>]

On Nov 21, 2022, at 11:07 PM, Bernard Aboba <[e-mail]> wrote:
> >  Until RADIUS over (D)TLS can meet the requirements for publication as a Proposed Standard, it would not be appropriate to deprecate the RADIUS protocol, and the Charter should not lower the bar established in RFC 6421. 

  That is a good point on document ordering. 

> "- Defining a secure variant of RADIUS which can be used in a FIPS-140 compliant environment"
> 
> [BA] As was discussed at the BOF, RADIUS over IPsec, defined in RFC 3579, has been deployed for more than 20 years in environments requiring FIPS-140 compliance.  To enforce FIPS-140 compliance, RADIUS servers are configured in "FIPS mode", which leaves them capable of using only FIPS-compliant cryptographic primitives.  As a result, attempts to utilize MD5 in transport security such as IPsec or (D)TLS, EAP methods, or within the RADIUS authenticator will fail. Rather than "defining a secure variant of RADIUS",  it is only necessary for the RADIUS over (D)TLS documents to describe how implementations should behave in the absence of MD5 or other FIPS-prohibited cryptographic primitives. For example, this would preclude negotiation of (D)TLS ciphersuites utilizing MD5 or other prohibited cryptographic operations. 

  Avoiding MD5 at the TLS layer won't help.  MD5 is baked into RADIUS.  The Request Authenticator, Reply Authenticator, and Message-Authenticator require the use of MD5.

  In order for RADIUS to work in a FIPS -140 environment, the RADIUS protocol has to be purged of dependencies on MD5.

  The SRADIUS draft essentially says "don't use Message-Authenticator, and don't sign packets with MD5".  That allows it to be used in a FIPS-140 environment.

  Alan DeKok.