[strongSwan] Enforcing multiple-authentication locally when the remote does not

Martin Willi martin at strongswan.org
Tue Feb 26 13:37:35 CET 2013


Hi Graham,

> I've configured the local machine to expect to perform certs authentication
> followed by EAP-AKA.

How did you configure this? I assume the configuration on the initiator
looks something like:

  rightauth=pubkey
  leftauth=pubkey
  leftauth2=eap
  
> If I then configure the remote to expect certs authentication only *and* to
> not advertise that it supports multiple-authentication exchanges (by
> setting charon.multiple_authentication to "no" in strongswan.conf), then
> the tunnel comes up. Not as expected. Not good.

When defining a leftauth, this defines the rule for authenticating
ourselves to right. It does not imply an constraints for the remote
side. Beside public key and PSK authentication, this makes sense for
many EAP methods, where only the client is actually authenticated.

With EAP-AKA (and other mutual EAP methods, such as EAP-SIM or EAP-TLS),
both peers get actually authenticated with EAP. But just defining
leftauth does not define such a constraint, and the initiator does not
insist on the EAP exchange.

> Is there any way to configure the local end to demand that
> multiple-authentication exchanges take place and to reject the tunnel if
> the remote does not ?

To strictly require the authentication of right with EAP, you can define
a rightauth2, something like:

  rightauth=pubkey
  rightauth2=eap
  leftauth=pubkey
  leftauth2=eap

This will set up the constraint that the responder first authenticates
itself with a public key, and then with EAP. If it does not (or a
non-mutual EAP method is used), the connection attempt fails.

Unfortunately it seems that defining such requirements is currently
broken and can never be fulfilled. I've pushed a few changes to [1] that
should fix this issue. With these patches applied, this scenario works
as expected.

Best regards
Martin

[1]http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/multi-eap





More information about the Users mailing list