Re: Authentication in OpenIKED

On 2023-03-01, J Doe <general@nativemethods.com> wrote:
> Hello,
>
> I have a question regarding authentication options in OpenIKED on
> OpenBSD 7.2
>
> On my test lab I have one OpenBSD 7.2 machine with OpenIKED configured
> to use PSK and a macOS 13.2.1 client that can connect to it.
>
> I read in: man iked.conf that PSK should not be used, so I am now

I don't see that in the iked.conf manual. There is some reference to not
using psk in /etc/examples/iked.conf but it's not clear whether that's
because of the need to share a single psk with all endpoints connecting
via the same iked.conf configuration line (certainly a problem when
you have multiple users from unknown IPs but perhaps not if used for
separately-configured lan-to-lan tunnels with strong randomly generated
psks) or whether it's something else.

> investigating EAP with MSCHAP-V2 and X.509 certificate authentication,
> but I am confused as to which is more secure.
>
> It seems to me that if I use EAP with MSCHAP-V2, I need a certificate on
> the OpenBSD machine, but I can connect from the macOS client with a user
> name and password, whereas X.509 authentication requires an X.509
> certificate on *BOTH* client and server - is that correct ?

Yes.

> If it is, is the reason that X.509 authentication is more secure because
> of the two certificates required, whereas authentication with EAP with
> MSCHAP-V2 is less secure because only one certificate is required ?

One problem is that MSCHAPv2 requires that the password is stored
in cleartext rather than some kind of hash, so someone with access
to the server config is able to connect (as any user), whereas with
certificates this can't be done.

Another is that it's a password which must often be typed by a user,
so in that case there's some disincentive to having a more secure
but hard to type password.

(There are other long documented problems with MSCHAPv2 but my
understanding is that those are not so important when used with in
conjunction with protocols like IKEv2 and PEAP where the auth is done
over a channel which is already secure - however that does require that
the initiator actually checks the certificate sent by the responder
otherwise MITM is a problem - and in most implementations it's all too
easy to disable checking this i.e. on the client side).

--
Please keep replies on the mailing list.