On Jan 25, 2023, at 9:06 AM, Eliot Lear <l...@lear.ch> wrote: > > First, I agree that this is a nit.
Except for the inability to get identities before choosing an authentication method. > On 25.01.23 14:54, Alan DeKok wrote: > Sure, but 7170 doesn't say you can't have a null password. So it can finish > the current method and then decide to add another by sending a request-action > TLV (a corner case to be sure). Or it can reject the null password. 7170 is missing a whole lot of discussion on authentication flow and processes. I'm still not clear on how the peer would know to send an empty password. > We could also say, “don't try that or we'll send the protocol police after > you” ;-) Right now, I can't implement your workflow of: * users matching X get basic password auth * all other users get EAP The only way to do this is: * all users get Basic-Password-Auth-Req TLV * all users send Basic-Password-Auth-Resp TLV with ???? for passwords * for users matching X, the server checks that password * for all other users, the server ignores the password, and sends another authentication method of EAP I think a better workflow is: * peer sends Identity-Hint TLV in the first packet with TLS Finished * server chooses to do password for identities matching X * server chooses to do EAP for all other identities This reduces the number of round trips for users doing EAP. It's a little easier to understand, too. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
