Martin,<div><br><div class="gmail_quote">On 26 February 2013 12:37, Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org" target="_blank">martin@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Graham,<br>
<div class="im"><br>
> I've configured the local machine to expect to perform certs authentication<br>
> followed by EAP-AKA.<br>
<br>
</div>How did you configure this? I assume the configuration on the initiator<br>
looks something like:<br>
<br>
  rightauth=pubkey<br>
  leftauth=pubkey<br>
  leftauth2=eap<br>
<div class="im"><br></div></blockquote><div><br></div><div>Yes, exactly that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> If I then configure the remote to expect certs authentication only *and* to<br>
> not advertise that it supports multiple-authentication exchanges (by<br>
> setting charon.multiple_authentication to "no" in strongswan.conf), then<br>
> the tunnel comes up. Not as expected. Not good.<br>
<br>
</div>When defining a leftauth, this defines the rule for authenticating<br>
ourselves to right. It does not imply an constraints for the remote<br>
side. Beside public key and PSK authentication, this makes sense for<br>
many EAP methods, where only the client is actually authenticated.<br>
<br>
With EAP-AKA (and other mutual EAP methods, such as EAP-SIM or EAP-TLS),<br>
both peers get actually authenticated with EAP. But just defining<br>
leftauth does not define such a constraint, and the initiator does not<br>
insist on the EAP exchange.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Understood. I think of it as the local (initiator) offering to perform certs plus additional (eap) authentication and if the remote (i.e. the SeGW) is happy with just certs only then this is no skin off the local's nose and the local will happily bring up the tunnel as well. The offer of an additional authentication round involving eap is only of benefit to the remote and if the remote chooses to forego that, then who is the local to argue ?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Is there any way to configure the local end to demand that<br>
> multiple-authentication exchanges take place and to reject the tunnel if<br>
> the remote does not ?<br>
<br>
</div>To strictly require the authentication of right with EAP, you can define<br>
a rightauth2, something like:<br>
<br>
  rightauth=pubkey<br>
  rightauth2=eap<br>
  leftauth=pubkey<br>
  leftauth2=eap<br>
<br>
This will set up the constraint that the responder first authenticates<br>
itself with a public key, and then with EAP. If it does not (or a<br>
non-mutual EAP method is used), the connection attempt fails.<br>
<br></blockquote><div><br></div><div>Hmm, not sure I understand this. What I want is to configure the local to demand that the remote issue an eap challenge to the local. What I think you have implemented is that both sides issue eap challenges to each other ?</div>
</div></div><div><div class="gmail_quote"><div><br></div><div>Graham.</div><div> </div></div></div>