Project

General

Profile

Issue #1217

Radius messages in FIPS mode

Added by Philippe Racette almost 5 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.3.5
Resolution:
No change required

Description

Hello,

My understanding is that strongswan can authenticate using an external Radius authenticator BUT in fips mode that is impossible since the passwords in radius exchanges are MD5.
Whereas MD5 is unavailable in FIPS.

What method would you suggest as an alternative to authentication against an inside network resource such as Active directory or OCSP ?

Are there any plans of implementation an alternative ?

Best regards

History

#1 Updated by Tobias Brunner almost 5 years ago

  • Status changed from New to Feedback

My understanding is that strongswan can authenticate using an external Radius authenticator BUT in fips mode that is impossible since the passwords in radius exchanges are MD5.
Whereas MD5 is unavailable in FIPS.

Yes, I guess that makes RADIUS with authentication/encryption inherently incompatible with FIPS certification. However, I don't know how FIPS certification works exactly and if perhaps a module like the eap-radius plugin could use MD5 for this purpose and this could then be separated enough from the certified parts to be valid (strongSwan itself is not certified anyway).

What method would you suggest as an alternative to authentication against an inside network resource such as Active directory or OCSP ?

Obviously, you could use IPsec between the VPN gateway and the RADIUS server.

Are there any plans of implementation an alternative ?

There is none. RADIUS currently only specifies HMAC-MD5 to be used for authentication and MSKs are sent encrypted with MPPE, which according to RFC 2548 uses MD5 to produce a key stream. However, if you can modify the RADIUS server implementation then you could change the code in source:src/libradius/radius_socket.c and source:src/libradius/radius_message.c to use different algorithms. But I guess using IPsec to secure the RADIUS traffic is easier.

#2 Updated by Tobias Brunner almost 5 years ago

What method would you suggest as an alternative to authentication against an inside network resource such as Active directory or OCSP ?

Obviously, you could use IPsec between the VPN gateway and the RADIUS server.

Hm, for some reason I thought authentication in RADIUS is optional. That's not the case and the MSK will also always be transmitted in MPPE encrypted attributes. So putting RADIUS in IPsec does not really help. One could use zero-length passwords in that case but I haven't found an RFC that describes the use of RADIUS with the Authenticator field completely unused. And with EAP the Message-Authenticator attribute is mandatory, which contains an HMAC-MD5 value of the message. This really makes RADIUS incompatible with FIPS validation. Diameter might be an alternative as it explicitly relies upon IPsec or TLS for security. strongSwan does currently not support it, though.

#3 Updated by Philippe Racette almost 5 years ago

Yeah i had come to the same conclusion, even encasing it in ipsec does not change the fact that MD5 would probably be used or at least loaded by the plugin.

In the end, my goal was to use a method to authenticate with an IPhone user, be FIPS and avoid keeping authentication credentials on the same host as the strongswan server. Radius was a good choice due to the fact that we could hook up with freeRadius and authenticate with an active directory inside a corporate environment. But the design of Radius is first hand not compliant with FIPS.

I guess this leaves me with the possibility of using an OCSP responder to validate a user certificate deployed on the Iphone.

I appreciate the suggestions concerning Diameter.

Concerning MD5, the eap-radius socket when created needs md5 to be available but when FIPS_MODE_SET is called in the openssl module and enabled, it prevents any non-fips algorithms to be initialized (i.e. MD5 for instance). The socket will thus fail to work.

#4 Updated by Tobias Brunner over 4 years ago

I recently found that Cisco actually defined some vendor-specific attributes that allow the use of stronger algorithms to authenticate RADIUS messages and transmit keying material (i.e. they defined replacements for the Message-Authenticator and MS-MPPE-*-Key attributes to make their RADIUS implementation FIPS compliant), see RFC 6218. However, neither strongSwan nor FreeRADIUS supports this.

#5 Updated by Philippe Racette over 4 years ago

Yes, I do remember stumbling on the same articles you refer to. As they are vendor specific it becomes less interesting. I decided to go look at other options than using Radius when fips is required. (e.g. OCSP)

#6 Updated by Noel Kuntze over 3 years ago

  • Status changed from Feedback to Closed
  • Resolution set to No change required

Also available in: Atom PDF