On Wed, 25 Jan 2023 at 03:14, Alan DeKok <al...@deployingradius.com> wrote: > > Section 4.2.14 (Basic-Password-Auth-Resp TLV) defines the length of the > password "PassLen" as "Length of Password field in octets'. However, there > is no requirement that the length be greater than zero. > > The same issue goes for the UserLen field.
Mandating non-zero UserLen would be good. Furthermore, let's consider multi-round inner password authentication, such as example flow C1 with "housekeeping": https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis#name-c1-successful-authenticatio Is there a reason why we couldn't prohibit changing the username after the first Basic-Password-Auth-Resp TLV is sent by the peer? That is, after the first Basic-Password-Auth-Resp TLV, the subsequent TLVs for the same sequence must have the same Username. At minimum I would like the updated RFC to say that: - peers are expected to prompt for a username only once, at the beginning, for each password authentication sequence; and - server should ignore Username after the first Basic-Password-Auth-Resp TLV for a sequence and the server is allowed to reject the sequence if Username changes The server must be careful to, for example, use the Username from the first Basic-Password-Auth-Resp TLV for authentication, authorisation, logging and other functionality. This is to avoid, for example, to prevent a peer to log in as Alice and then using Bob with the last Basic-Password-Auth-Resp TLV. If the server isn't careful, Bob may end up in authentication and other logs and any possible authorisation may be done as Bob. -- Heikki Vatiainen h...@radiatorsoftware.com _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
