Re: Authentication in OpenIKED

On Wed, Mar 01, 2023 at 09:24:50AM -0000, Stuart Henderson wrote:
> 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.

We should probably remove that comment.

I think there is actually no reason to avoid PSK in IKEv2 if both endpoints
are trusted. Of course it doesn't scale well and all security considerations
for shared WiFi passwords apply here as well, but there isn't an obvious
weakeness like the plain text passphrase being sent over the network.
Expecting people to generate X509 certificates for simple peer-to-peer setups
seems a lot worse.

>
> > 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.
>