On Thu, 2 Feb 2023, at 18:31, Alan DeKok wrote: > On Feb 2, 2023, at 2:22 AM, Eliot Lear <[email protected]> wrote: >> 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. > > I'm not clear how that would happen. Nothing in the doc discusses > how a client may choose authentication methods.
The documentation does not but I did see Appendix C.9 lets the client state what it wants to do: https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-03#name-c9-peer-requests-inner-meth >> 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. > > That does work, but it adds another round of packets, which is less > than optimal. Smells like the fun seen with EAP methods and NAK. Using the Identity-Hint TLV to steer the server so at least it knows if it is machine or a user authentication coming its way is useful. Some if not most sites should find this good enough for them. Though if you are proposing this to be optional, why not define another new TLV the client MAY send with Identity-Hint TLV that takes the place of the EAP-Identity response for only when it wants to go and do Basic-Password-Auth. To trim a round trip, you could add language on for servers supporting this MAY wish to treat this as a username if the server would only send a Basic-Password-Auth-Req asking for the same information anyway...to trim a round trip. I'm unable to think of a time why you would respond to a username request differently for an inner method, so it should be safe...mostly. Cheers _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
