[Emu] TEAP no EAP: which "error" for EAP methods that are not available?

[Eliot Lear <[e-mail]>]

&TL;DR what to do when peer doesn't want to do an inner EAP method, but 
you still want to allow peer on the network?  My answer: 
intermediate-result TLV with status=failure.

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