I am wondering if we should close this issue. At the end of the day, if
the client knows it's doing something like 2FA that requires an EAP
method, *it* can initiate. If it doesn't and the server decides it
needs it based on the Basic-Password-Auth-Resp, then the server can
insist, using a Request-Action TLV that requests EAP.
I could be convinced otherwise, tho.
Eliot
On 01.02.23 21:42, Alan DeKok wrote:
I've opened an issue:https://github.com/emu-wg/rfc7170bis/issues/14 ,
summarized as:
When using normal EAP, the server sees the EAP Identity before it selects which
EAP type is being used.
However, with TEAP, the inner tunnel method (EAP or basic password) has to be
chosen by the server before it sees any user identity. This limitation means
that it is impossible for the server to divide users into groups, as with:
• users matching X get basic password auth
• all other users get EAP
Perhaps we have to define an Identity-Hint TLV which is sent by the peer as
soon as the inner tunnel is established? The server can then use this hint to
select which authentication method to use.
i.e .when the EAP authenticator receives TEAP, it has no idea whether to pick EAP or
basic password. It just has to pick one randomly, and hope for the best. If it picks
the wrong one, then there are "extra" rounds of authentication, or users might
not get authenticated.
In practice, this likely means that TEAP implementations will either do
password authentication all of the time, or EAP authentication all of the time.
But not both on the same server.
At the minimum, this issue should be discussed in the document, with a warning of
"here be dragons".
If we're willing to extend TEAP, I don't think we need to rev the protocol.
We could just add an optional Identity-Hint TLV which is sent by the supplicant
as soon as the inner tunnel is established.
If the server sees the TLV, it can use it. Otherwise, it's an optional TLV,
and the server is free to ignore it.
I think this is almost the last open issue. It would help to get feedback
from people currently using TEAP, to see if (a) this is a real problem, or (b)
it's fine and we can ignore it.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
