On Tue, 17 Jan 2017, John Crisp wrote: [ Re-added the list as it might be interesting for others as well ]
[ John gave me a big log file to look at ] [ Added Yaron Sheffer because he is the author of RFC 5998 so he can tell me if I should file an ERRATA or not ]
This is a connection from Opnsense using FreeBSD strongSwan U5.51/K10.3-RELEASE-p14
So it looks like that strongswan connection is trying to use an EAP-only authentication message. So no certificates and no preshared key. libreswan does not support EAP or EAP-only authentication. So this connection will fail or it will fallback to regular IKE_AUTH. This is defined in https://tools.ietf.org/html/rfc5998 We can see this because we receive: Jan 17 01:11:18: | Notify Message Type: v2N_EAP_ONLY_AUTHENTICATION (0x4021) However, the RFC states: If the responder does not support the EAP_ONLY_AUTHENTICATION notification or does not wish to use it, it ignores the notification payload, and includes the AUTH payload in message 4. In this case, the initiator MUST verify that payload and any associated certificates, as per [RFC4306]. When receiving message 4, the initiator MUST verify that the proposed EAP method is allowed by this specification, and MUST abort the protocol immediately otherwise. However, for this fallback to work, libreswan should send a regular AUTH payload ignoring the EAP_ONLY_AUTHENTICATION. It did not do that. We can see why it did not do this: Jan 17 01:11:18: "TestToWorkMain"[2] 213.123.128.243 #5: payload(s) (ISAKMP_NEXT_v2KE) unexpected. Message dropped. If you look at section 3 of RFC-5998, you can see that even with EAP_ONLY_AUTHENTICATION, the only Exchange where KE payloads are exchanged is in IKE_INIT (message 1 and 2, see the KEi and KEr payloads) It is rejecting IKE_AUTH exchange packets with a KE payload in it. So libreswan is still correct that finding a KE payload in an IKE_AUTH Exchange is wrong and the packet should be rejected. But I am still confused. Let's for a second assume the bad KE payload is not there or we would just ignore it. It still would not be able to do the fallback described in the RFC. What is supposed to happen if libreswan (responder) wants to do the fallback to normal AUTH. Since the initiator's IKE_AUTH packet is not supposed to contain an AUTH payload, libreswan can never authenticate it, so it will always send an IKE_AUTH error response at best. So one might assume RFC-5998 is wrong. And that this is why strongswan still sends an AUTH payload in the IKE_AUTH exchange, even if it is configured with EAP_ONLY_AUTHENTICATION. To allow the fallback to succeed. Jan 17 01:11:18: | Now let's proceed with payload (ISAKMP_NEXT_v2AUTH) The AUTH payload sent by strongswan is for PSK. It would have matched the libreswan configuration for authentication (which John also send me) Paul _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
