Hi Terry,
I surely must be missing something here:
Packet 6 is an EAP-Response from the peer. Packet 7 contains another
EAP-Response inside a RADIUS Access-Request? That doesn't make sense. EAP is
lock-step request-response protocol. The conversation you describe is incorrect.
My reading of RFC 3748 is clear that after receiving a NAK from the peer, the
server should send another EAP-Request with a different EAP method if its
policy allows or then send a failure. The server should also send a failure if
the peer NAK Type-Data was 0 (indicating no proposed alternative).
FYI: RFC 4137 says:
o Sending a NAK to the authenticator after the authenticator first
proposes an EAP authentication method to the peer. When the
methodState variable has the value PROPOSED, the authenticator is
obliged to process a NAK that is received in response to its first
packet of an EAP authentication method.
so the commercial RADIUS server is in violation if it doesn't respond to a NAK
from the peer with either another EAP-Request or failure.
--Mohit
On 8/20/20 3:39 AM, Terry Burton wrote:
Hi,
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):
1. NAS --> Peer : EAP-Request / Identity
2. Peer --> NAS : EAP-Response / Identity ( ID )
3. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response /
Identity ( ID )
4. AAA --> NAS: RADIUS Access-Challenge / EAP-Message / EAP-Request /
Method Foo
5. NAS --> Peer: EAP-Request / Method Foo
6. Peer --> NAK: EAP-Response / EAP-Type=NAK (Methods [Bar])
7. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response /
NAK ( Methods [ Bar ] )
(* Let's assume that the AAA does not support Method Bar so we have
derived that there are no overlapping methods.)
8. AAA: Now what?
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.
In practise:
* FreeRADIUS sends RADIUS Access-Reject / EAP-Message / EAP-Failure.
* hostapd's RADIUS server sends RADIUS Access-Reject / EAP-Message /
EAP-Failure.
* A commercial RADIUS server implementation sends nothing.
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).
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.
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. 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.)
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.
Thanks,
Terry
_______________________________________________
Emu mailing list
Emu@ietf.org<mailto:Emu@ietf.org>
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
