Hi John, Paul,
I'm not clear about several points in your mail below.
- As far as I can see, RFC 5998 doesn't mention KE payloads at all. So
it's legitimate for a responder to choke upon receiving message #3 with
this payload.
- RFC 5998 does assume, perhaps implicitly, that the responder speaks
EAP. What it is adding is a transition into certificate-less
authentication for cases where EAP performs mutual authentication. In
fact, a responder that doesn't do normal IKE+EAP (RFC 7296, Sec. 2.16)
would reject a normal EAP-based exchange because of the missing AUTH
payload, regardless of RFC 5998.
Given this assumption, I don't think that the paragraph you're quoting
is in error.
Thanks,
Yaron
On 19/01/17 08:44, Paul Wouters wrote:
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
