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

[Paul Wouters]

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