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

Yaron Sheffer yaronf.ietf at gmail.com
Fri Jan 20 10:34:11 UTC 2017


Hi Paul, please see in-line.

Thanks,
	Yaron

On 20/01/17 01:00, Paul Wouters wrote:
> On Fri, 20 Jan 2017, Yaron Sheffer wrote:
>
>> - 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.
>
> Yes, we agree there. It is a strongswan bug.
>
>> - 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.
>
> Then what would be the point of the responder adding an AUTH payload in
> the response that 5998 tells us to do? That was supposed to be the
> "fallback" as far as I understood?

The AUTH payload in message #4 is exactly what the responder should send 
in a standard IKEv2+EAP exchange (IKEv2 sec. 2.16).
>
>> Given this assumption, I don't think that the paragraph you're quoting
>> is in error.
>
> It seems that the RFC got stuck between two ideas:
>
> 1) Include an AUTH payload and send v2N_EAP_ONLY_AUTHENTICATION
>
> The responder supporting v2N_EAP_ONLY_AUTHENTICATION would ignore the
> sender's AUTH and do 5998 stuff. The responder not supporting
> v2N_EAP_ONLY_AUTHENTICATION would ignore it and process the AUTH and
> reply with an AUTH. The initiator then determines if this fallback is
> within local policy and either accepts it or rejects it.

No, the document never mentions sending an AUTH payload in message #3. 
The RFC is NOT about fallback from cert- or PSK-based to EAP-only 
authentication. Whether such fallback makes sense at all is arguable, 
but RFC 5998 doesn't even consider it.

It may be possible to augment the RFC with language that allows 
PSK-to-5998 fallback, but I think that would go beyond the scope of an 
erratum.

>
> 2) Don't include an AUTH payload and send v2N_EAP_ONLY_AUTHENTICATION
>
> The responder supporting v2N_EAP_ONLY_AUTHENTICATION can do 5998 stuff.
> The responder not supporting it, would ignore the notify but see the
> missing AUTH and send a failure back. No "fallback" is possible for
> the initiator other then starting a new IKE_INIT from scratch or a
> new IKE_AUTH without v2N_EAP_ONLY_AUTHENTICATION and with AUTH.

Nope, the missing AUTH in message #3 is not a failure, it is plain old 
IKEv2 EAP authentication.
>
>
> The RFC however shows in the diagrams no AUTH payload in IKE_AUTH on
> the sender, so 1) cannot be true. The RFC also talks about responder
> doing a fallback with sending an IKE_AUTH reply with AUTH payload
> which cannot be true if there was no AUTH payload in the IKE_AUTH
> request.
>
> So, I don't understand how 5998 is supported to work when the initiator
> attempts 5998 and the responder does not support it.

As I mentioned before, the document assumes that the responder supports 
IKEv2+EAP, which is specified in the original protocol.

>
> Paul
>
>> 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
>>


More information about the Swan mailing list