[strongSwan] Authentication against Linux Users

[Tobias Brunner]

Hi Christian,

> but what if the server stored the password in a sha256(md4(password))
> hash and then when it received the md4 hash from the client, hashed that
> with sha256 to compare to?

It doesn't receive the MD4 hash, which is only a part of the calculation
of EAP-MSCHAPv2 (the NT password hash).  The actual value that's
transmitted (ChallengeResponse) and has to be verified (by doing the
same calculation) also incorporates random challenges (see RFC 2759 [1]
for details).  Which is why the only thing you can store instead of the
plainttext password is the NT hash (ntlm secrets in swanctl.conf).

> The Server can send any fake md4 hash across the network to the client
> (unless the client does its own check of the hash)...

It does, the server sends its an AuthenticatorResponse, which
incorporates the client's response and the random challenges (including
one provided by the client) to prove it knows the password.  So the EAP
method does provide mutual authentication, however, a weak version
because the server is authenticated after the client.  Which means a
MITM could attack a weak client password, which is why the server should
be authenticated via IKEv2 pubkey authentication first (i.e. EAP-only
authentication is not allowed for EAP-MSCHAPv2).  EAP-MSCHAPv2 can also
be tunneled in another EAP method (e.g. EAP-TTLS or EAP-PEAP) to
authenticate the AAA server first.

There are, of course, several other EAP methods based on passwords, with
much stronger algorithms and some of them don't require plaintext
passwords.  The problem is that common clients (as those built-in
Windows and Apple OSes) don't support them (and neither does strongSwan
actually).

Regards,
Tobias