One potential use case is when you have some devices that support individual users and some that do not. In this case, the server might request an inner EAP method such as MSCHAPv2. This would work fine for a laptop but not so well for a lightbulb. The server may yet wish to make a policy decision to allow the lightbulb onto the network, even though it made use of no inner method. RFC 7170 ponders this use case in Section 3.3.1:
The result of failure of an EAP method does not always imply a failure of the overall authentication. If one authentication method fails, the server may attempt to authenticate the peer with a different method.What is less clear is what to do when no EAP method is available. There are three choices:
1. Send a NAK TLV 2. Send an Error TLV 3. Send an intermediate result TLV with status = failure.A NAK TLV seems to contemplate TLVs that are simply *not* implemented. I don't think that's the correct answer, but so long as the server understands that the peer means "don't send me no stinking EAP TLVs" and can intelligently apply policy, no big deal. Still, I think that's not a good general answer. It's possible that both the peer and the server could implement something like EAP-AKA, but that the server doesn't have access to the necessary credential information of the client, and may still want to allow the client online.
Section 3.6.3 states the following about using an Error TLV with an inner method:
If there is a non-fatal error handling the inner method, instead of silently dropping the inner method request or response and not responding, the receiving side SHOULD use an Error TLV with error code Inner Method Error to indicate an error processing the current inner method. The side receiving the Error TLV MAY decide to start a new inner method instead or send back a Result TLV to terminate the TEAP authentication session.But this seems to be applicable when the inner method is already started. Also, this seems to stretch the definition of what an "Error" is. That militates against the SHOULD above, right?
Finally, the peer could simply respond with an Intermediate-Result-TLV with Status=Failure. This seems to be the most straightforward way of responding, and it seems to be what was intended with the text I quoted from Section 3.3.1. One might want to provide the EAP TLV as an optional TLV in the Intermediate-Result, but one seemingly cannot because because the Intermediate-TLV text reads the following in Section 4.2.11:
The TLVs in
this field MUST NOT have the mandatory bit set.
I don't understand this, but there it is. It spares me having to
determine whether one is supposed to include just the TLV code in that
space or the T, L, and V. And this same question recurs with
Request-Action TLVs. Fortunately, in that context it makes more sense
that only the type code is necessary, and this is indeed the practice
that wpa_supplicant has followed.
If it seems to you like we're building up a little bit of an issue list for a TEAP update.... you'd be right ;-)
Eliot
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
