On Aug 19, 2020, at 8:39 PM, Terry Burton <[email protected]> wrote:
> I'm unable to find the authoritative source that state exactly how the
> following conversation continues (TL;DR; the peer NAKs the original
> method and the AAA doesn't support any of the peer's proposals):
> ...
> 8. AAA: Now what?
Run around screaming? It's at least not forbidden by the RFCs. :(
> I've reviewed RFC 3748 (EAP) and RFC 3579 (RADIUS Support For EAP) and
> neither seems to be explicit about what the AAA should do in response
> to a NAK in the event of no overlapping methods.
Those specs were written 15+ years ago, when the IETF reviews were a lot less
stringent about corner cases.
RFC 3579 Section 2.1 says:
Where the initial EAP-Request sent by the NAS is for an
authentication Type (4 or greater), the peer MAY respond with a Nak
indicating that it would prefer another authentication method that is
not implemented locally.
I suspect the "not" here is wrong, and the text should say:
... it would prefer another authentication method that is implemented
locally.
The text finishes with:
... is possible for the RADIUS server to choose
an unacceptable method, and for the peer to respond with another Nak.
And... what then? There's no suggestion that this NAK exchange should stop
after N rounds, and there's no suggestion for how to handle no overlapping
methods.
In short, "here be dragons".
> In practise:
>
> * FreeRADIUS sends RADIUS Access-Reject / EAP-Message / EAP-Failure.
We treat "no overlapping methods" as similar to other protocol errors. For
example:
* NAK Type-Data with no contents (forbidden by RFC 3748 Section 5.3.1)
* NAK Type-Data of 0, which indicates "no proposed alternative". We'll not
that RFC 3748 Section 5.3.1 doesn't say what to do here.
* NAK Type-data of 1..3, which is also forbidden by Section 5.3.1
All of these situations result in RADIUS Access-Reject / EAP-Message /
EAP-Failure.
One reason for choosing this response is that it is a *positive*
acknowledgement that the EAP session has failed. This behaviour seems better
than dropping the packet on the floor. If that happened, the NAS would be
unable to distinguish "RADIUS server down" from "EAP protocol failure".
RFC 3579 Section 2.2. "Invalid Packets" would seem to be applicable here:
Since EAP method fields (Type, Type-Data) are typically not validated
by a NAS operating as a pass-through, despite these checks it is
possible for a NAS to forward an invalid EAP packet to or from the
RADIUS server. A RADIUS server receiving EAP-Message attribute(s) it
does not understand SHOULD make the determination of whether the
error is fatal or non-fatal based on the EAP Type. A RADIUS server
determining that a fatal error has occurred MUST send an
Access-Reject containing an EAP-Message attribute encapsulating
EAP-Failure.
I would suggest that protocol failures are "fatal errors" as per this text,
and MUST therefore result in Access-Reject / EAP-Message / EAP-Failure. At
least, where RADIUS is concerned.
> * hostapd's RADIUS server sends RADIUS Access-Reject / EAP-Message /
> EAP-Failure.
I haven't delved into hostap's implementation, but I suspect that they made
the same choices we did in FreeRADIUS, for similar reasons.
> * A commercial RADIUS server implementation sends nothing.
That seems bad.
> It seems right to indicate an EAP-Failure to the peer in the case of
> no overlapping methods (as well as to terminate the NAS's outstanding
> RADIUS Access-Request with an Access-Reject), as is the case for a
> number of other failure conditions, e.g. authentication failure
> *within* an EAP method (Appendix A by way of example), invalid packets
> leading to a fatal error within an EAP method (section 2.2).
Yes. I would argue that inability to agree on what to do is a protocol
failure, and should result in an explicit failure signal.
> RFC 3748 section 4.2 on Success and Failure introduces these messages
> within the context of finalising an ongoing EAP method:
>
> The Success packet is sent by the authenticator to the peer after
> completion of an EAP authentication method (Type 4 or greater) to
> indicate that the peer has authenticated successfully to the
> authenticator. The authenticator MUST transmit an EAP packet with
> the Code field set to 3 (Success). If the authenticator cannot
> authenticate the peer (unacceptable Responses to one or more
> Requests), then after unsuccessful completion of the EAP method in
> progress, the implementation MUST transmit an EAP packet with the
> Code field set to 4 (Failure).
>
> Perhaps one can argue that a NAK is an unacceptable response to an
> ongoing method and therefore the method is unsuccessfully completed so
> a Failure should be generated? That's not entirely clear, if that is
> the case.
NAK is a reasonable response to the *first* packet coming from a server.
RFC 3748 Section 2.1 forbids NAKs which occur later in the authentication
sequence:
A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request
after an initial non-Nak Response has been sent. Since spoofed EAP
Request packets may be sent by an attacker, an authenticator
receiving an unexpected Nak SHOULD discard it and log the event.
I would argue that discarding packets is wrong in the context of AAA. The NAS
needs a positive acknowledgement that the EAP session has been torn down, and
that the RADIUS server is still alive.
So the correct response would be Access-Reject / EAP-Message / EAP-Failure
> RFC 3748 section 5.3.1 throws in some more doubt, having the following
> text that deals explicitly with the peer sending a NAK containing "no
> desired alternative" method:
>
> Type zero (0) is used to indicate that the sender has
> no viable alternatives, and therefore the authenticator SHOULD NOT
> send another Request after receiving a Nak Response containing a
> zero value.
>
> That's specific to one case for which a strict reading would indicate
> that the EAP server should remain quiet and consider the EAP
> conversation to be complete.
I would argue that it's OK to send EAP-Failure here. EAP-Failure is Code 4,
whereas Request is Code 1.
The above text reads as forbidding *ongoing* EAP conversations after a
failure to negotiate a mutually acceptable method. But sending Success or
Failure would seem to be OK.
I would then suggest that the text SHOULD say:
Type zero (0) is used to indicate that the sender has
no viable alternatives, and therefore the authenticator MUST
send a Failure packet after receiving a Nak Response containing a
zero value.
> It's tempting to think that the same
> response (i,e. no response!) should apply more broadly as none of the
> AAA implementations I've tested actually differentiate between a NAK
> with no desired alternative method vs a NAK with an incompatible list
> of alternative methods. (A subtle difference might be relevant: In the
> case of NAK / method = [] the peer knows that the EAP conversion can
> go no further, whereas in the case that it sends a list of methods
> that the AAA happens to not support it does not know this unless it is
> subsequently told.)
I agree. Protocol failures or negotiation failures MUST result in EAP
Failure being sent.
> If I've not missed something then this looks an omission (or lack of
> clarity) and the intended AAA response to no overlapping methods (and
> indeed "no desired alternative") should be decided and codified.
Implementations have largely decided on a mutually acceptable set of
behaviour. This works in practice.
That point is not to be taken lightly. A different set of behaviours may
cause network instabilities, etc. And a response of "our implementation is
compatible with the RFCs" is not appropriate when that behaviour is causing
problems for others.
I would agree with at the minimum technical errata being reported for RFC
3748 and/or RFC 3579. I'm not sure that updated documents are required, though.
Alan DeKok.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
