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

[Bernard Aboba <[e-mail]>]

Paul said:

“ This means (and this is what people concluded in the past) is that
wrapping Radius in TLS, where the TLS layer only uses approved algorithms,
is not good enough for FIPS. The inner radius packets are still used to
make authentication decisions based on security methods that uses MD5,
which is not allowed for FIPS.”

[BA] In “FIPS mode” the RADIUS server cannot execute user authentication
mechanisms that depend on MD5, such as EAP-MD5 (for 802.1X) or CHAP. So
typically we see users being required to authenticate with EAP-TLSv2.  This
requires no change to the RADIUS protocol, just appropriate configuration
of user authentication methods.

With respect to MD5 usage within RADIUS over (D)TLS, the specifications
already require mutual authentication and encryption between RADIUS peers
using (D)TLS, so that security decisions such as peer authorization or the
protection of hidden attributes need not depend on legacy RADIUS MD5
mechanisms (e.g. no need to check that the “default” shared secret is in
use).  SRADIUS goes further by removing the dependencies on MD5 entirely,
which allows it to function in “FIPS mode” environments where MD5 is not
available.

Since deployments typically know whether they are required to operate in
“FIPS mode” or not and configure their equipment accordingly, there are few
scenarios where interop is required between a “non-FIPS mode” NAS and a
“FIPS mode” server.  Rather, installations that require FIPS compliance
will require support on both network devices as well as servers, and will
ensure that the devices and servers are configured so they can talk to each
other.

FIPS compliance for network access is not new - I recall shipping 802.11
support for FIPS circa 2008.