On Wed, 25 Jan 2023 at 10:21, John Mattsson <[email protected]> wrote: > > That sounds good. Would be good to have text stating that passwords of length > 255 characters (the current max) shall be allowed. Requiring a minimum length > of 8 or a least 6 characters would be good.
Basic-Password-Auth-Resp TLV is used for non-password purposes too. The RFC and draft call these "housekeeping" functions. Because the TLV is used for both password authentication and housekeeping functions, I wouldn't say much about minimum length. 4 digit PINs are still used and various OTP systems may use a dialogue where the password field is used to transport a response that directs how the OTP protocol proceeds. For example, an OTP system could do this: - Start authentication with username + static password; if ok then - Server prompts for the next method: Choose 1 for push to mobile app, 2 for telephone callback, 3 for emergency use pre-printed code. Leave password empty for the default method (not mandatory: can always choose one of 1-3). - The next server response then depends on what was chosen by the user The above may need to run as one exchange without any Intermediate-Result TLV between static password and OTP dialogue because it gets proxied as Radius PAP to "Inner Method server" as described in section 2.1 of the draft. The RADIUS, and Diameter, RFC appears not to say empty passwords are not supported, therefore rejecting zero length Password field in Basic-Password-Auth-Resp TLV may be problematic with interoperability. I wouldn't mind being able to mandate non-zero length passwords, but I'm not sure if this is the right place to do it. Regarding interoperability, the Radius and Diameter RFCs restrict User-Password, and therefore unencrypted password, length to less than 253, the maximum User-Password attribute payload length for Radius [1] and [2]. Should we consider Radius and Diameter interoperability if we give guidance for Basic-Password-Auth-Resp TLV password length? [1] https://www.rfc-editor.org/rfc/rfc2865#section-5.2 [2] https://www.rfc-editor.org/rfc/rfc7155.html#section-4.3.1 -- Heikki Vatiainen [email protected] _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
