On Jan 25, 2023, at 7:55 AM, Eliot Lear <[email protected]> wrote: > If you want to add some implementation guidance I think that's fine, but this > isn't really a protocol consideration. I could envision the following > circumstance, by the way: a username triggers the server to initiate a new > inner method, and the password is not sent, knowing this. Or the password is > ignored.
The auth flow is: server requests password auth via Basic-Password-Auth-Req TLV, which contains nothing other than a prompt supplicant sends a password auth via Basic-Password-Auth-Resp TLV, which contains a username && password. The server can choose to reject (or ignore) the password, of course. What I'm not clear on is how they would negotiate a special username which triggers a new auth, but without doing a password check. That seems odd to me. If the supplicant doesn't want to do password auth, it can just reject the Basic-Password-Auth-Req TLV, and return a NAK TLV. It shouldn't send a username && empty password. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
