On Jan 25, 2023, at 8:27 AM, Eliot Lear <l...@lear.ch> wrote: > No negotiation required. It gets the username as part of basic auth, sees > the name and then makes a decision to initiate a new inner method.
It has to finish the current method first. i.e. the server only gets the username after sending a Basic-Password-Auth-Req TLV. The response contains a username && password. There's no way to negotiate "the server wants you to send your name, but doesn't care about the password". So the supplicant has to send some value for the password. I think this is mostly nits. The server is free to ignore (or not verify) the password. But it's bad practice to allow zero-length passwords in authentication protocols. > Imagine two groups of usernames on a server: one that use basic auth and > another that has 2FA, where the 2FA is invoked in an EAP method. This may > not be the BEST method (you could probably think of better), but TEAP doesn't > say you can't do it (perhaps we're here because TEAP doesn't forbid enough > stuff ;-) Except that the server has to make the decision of which kind of auth to do *before* it has access to any username information. * server sends EAP and the supplicant responds with an identity * server sends Basic-Password-Auth-Req and the supplicant responds with an identity There is no way to decide which path to take based on identity. The server has to choose a method, then get the identity, then perhaps NAK the method, and continue with another method? But how do you NAK an EAP exchange? i.e. "Oops, now that you sent me your identity, it looks like I don't want to do EAP. So I've got to stop the entire EAP state machine, and pick something else". This seems like an oversight in the protocol. Your desired workflow looks to be impossible. It's a little late to do major protocol changes. But hopefully not too late. Perhaps it would be useful to add a TLV indicating inner identity. It could be sent by the peer as soon as the inner tunnel is established. i.e. as soon as the peer sends TLS Finished, it could include application data of one TLV, which would be any identity hint. The server could then use that identity hint to choose what kind of authentication to select. And then we have issues where the identities should agree... but perhaps we can ignore that, and just hope for the best. So in conclusion, it looks like your workflow is impossible without the addition of an Identity-Hint TLV which is sent by the peer, as soon as the tunnel is established. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
