[Swan] RFC-5998 confusion, was Re: Failed to match authenticator

[Yaron Sheffer]

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