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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
