Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Quoting Wikipedia:

It offers minimal security; the MD5 hash function is vulnerable to dictionary attacks, and does not support key generation, which makes it unsuitable for use with dynamic WEP, or WPA/WPA2 enterprise

However, Wikipedia discusses EAP-MD5 in the context of wireless authentication. If I understand correctly this is not a security risk in strongSwan since the authentication between the client and the server is encrypted. I'm I correct?

share|improve this question

1 Answer 1

up vote 2 down vote accepted

Yes, in the context of strongSwan, or more generally IKEv2, the EAP messages are transmitted encrypted in the IKE_AUTH exchanges. Man-in-the-middle attacks are averted by first authenticating the server with certificates using standard IKEv2 authentication. The security considerations in the IKEv2 RFC actually say:

An implementation using EAP MUST also use a public-key-based authentication of the server to the client before the EAP authentication begins...

That's the case unless an EAP method with mutual authentication (e.g. EAP-TLS, but not EAP-MD5) is used and the client supports EAP-only authentication.

If the EAP authentication is not terminated on the VPN server but e.g. a separate RADIUS server, one has to consider that the communication between these two is generally not encrypted. To not leak any information there it is also possible to use EAP-MD5 within other EAP methods (e.g. EAP-TTLS or EAP-PEAP), which provide a TLS tunnel within which the EAP-MD5 messages are transported to the authentication server. This also allows the client to authenticate that server, which is not possible with EAP-MD5 alone, as it does not provide mutual authentication. Combining such tunneling EAP methods with simple user authentication is also quite common for the WiFi use case (e.g. EAP-PEAP/EAP-MSCHAPv2).

share|improve this answer
You mean in the context of strongSwan, right=eap-md5 does not expose the possibility of a man-in-the-middle attack as long as left=pubkey is used, right? (Compared to using eap-md5 on both sides, for example.) – This raises one question: who guarantees that the authentication of “left” comes before “right”? – Robert Siemer Aug 7 at 17:57
EAP-MD5 on both sides is not possible as this EAP method does not provide mutual authentication (unlike e.g. EAP-TLS). Edited my answer to clarify that IKEv2 ensures the server is authenticated first. – ecdsa Aug 10 at 9:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.