Are RADIUS and TACACS+ Ever Allowed in FIPS 140-2 Compliant Scenarios?

Question

Are RADIUS and TACACS+ Ever Allowed in FIPS 140-2 Compliant Scenarios?

I understand that RADIUS uses the MD5 hashing algorithm and I'm pretty sure TACACS+ does too, and I do not believe there is any implementation of either RADIUS or TACACS+ that does not use the MD5 hashing algorithm. Please correct me if I'm wrong.

And MD5 is forbidden in the FIPS 140-2 standard.

However, I found this Cisco doc which mentions something called "RADIUS Keywrap," and it seems to imply that you will be able to use RADIUS if you enable the keywrapping, and you will still be FIPS-compliant.

So... what is RADIUS Keywrapping? Does it mean that the MD5 algorithm is no longer used at all? Or is it that FIPS compliance can still be maintained if you "wrap" an insecure algorithm inside of a secure one?

Edit: Found in the doc that mfinni linked:

RADIUS Keywrap

RADIUS keywrap support is an extension of the RADIUS protocol. It provides a FIPS-certifiable means for the Cisco Access Control Server (ACS) to authenticate RADIUS messages and distribute session keys.

RADIUS keywrap increases RADIUS protocol security by using the Advanced Encryption Standard (AES) keywrap algorithm to transfer keys while an HMAC-SHA1 algorithm is used to protect packet integrity. It specifies that the key encryption key (KEK) and the hash key must be different from each other, should not be based on a password, and must be cryptographically independent of the RADIUS shared secret used in calculating the response authenticator.

OK... that answers that.

Answer 1

Given that NIST has a copy of a Cisco document calling this out specifically, I'm going to think the answer is Yes. IANASA (i am not a security auditor)

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp948.pdf

Answer 2

Are RADIUS and TACACS+ Ever Allowed in FIPS 140-2 Compliant Scenarios?

RADIUS:

Microsoft has FIPS-certified crypto modules for their recent operating systems (search for "Microsoft").

Enabling FIPS mode via Group Policy will force use of that crypto module. However, as one answer pointed out, most RADIUS protocols are not allowable under FIPS. PAP, CHAP, MS-CHAP, MS-CHAPv2 all use no/limited encryption or some form of MD hash (not allowed under FIPS). There are some protocols that use FIPS-level encryption: EAP methods (PEAP, EAP-TLS).

TACACS+:

Cisco has taken their AAA servers through FIPS. However, from the doc linked in one of the answers, it is only for 802.11i (wireless security using RADIUS), not for the TACACS+ piece.

One issue with TACACS+ (which is hard to find) is that it apparently uses MD5 to protect TACACS+ traffic. Search "TACACS+ MD5" and you should come up with a SANS Institute document that makes this statement. Cisco does not say on its website what TACACS+ uses for encryption.

Bottom line: TACACS+ in FIPS mode? No, unless someone can show that the TACACS+ traffic is using 3DES or higher encryption. RADIUS in FIPS mode? Yes, as long as you are using an EAP-method.

Answer 3

For posterity: The TACACS+ "encryption" is document in https://datatracker.ietf.org/doc/html/draft-grant-tacacs-02

Relevant text:

In this case [ed: encryption is used], the packet body is encrypted by XOR-ing it byte-wise with a pseudo random pad.

ENCRYPTED {data} == data ^ pseudo_pad

The pad is generated by concatenating a series of MD5 hashes (each 16 bytes long) and truncating it to the length of the input data.

Whenever used in this document, MD5 refers to the "RSA Data Security, Inc. MD5 Message-Digest Algorithm" as specified in [3].

pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data)

The first MD5 hash is generated by concatenating the session_id, the secret key, the version number and the sequence number and then run- ning MD5 over that stream. All of those input values are available in the packet header, except for the secret key which is a shared secret between the TACACS+ client and daemon.

The version number is the one byte combination of the major and minor version numbers.

The session id is used in the byte order in which it appears in the TACACS+ header. (i.e. in network byte order, not host byte order).

Subsequent hashes are generated by using the same input stream, but concatenating the previous hash value at the end of the input stream.

MD5_1 = MD5{session_id, key, version, seq_no}

MD5_2 = MD5{session_id, key, version, seq_no, MD5_1}

....

MD5_n = MD5{session_id, key, version, seq_no, MD5_n-1}