Patrick and Pieter, Thanks for your review of the extension and your feedback. I include comments to the feedback below. — JG
James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/5/18, 9:30 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Tue, Jun 5, 2018, at 09:26, Pieter Vandepitte wrote: > I follow the concerns of Patrick, > > I'm neither a fan of the [LOGIN-SECURITY]. Isn't it enough to specify > that a server MUST ignore the value of <pw> if the loginSec extension is > used? That could be a solution too, and would work for further versions. JG - I included the basis for the use of the '[LOGIN-SECURITY]' constant value in my original response, which I copied below for quick reference: The reason for a '[LOGIN-SECURITY]' constant value in RFC 5730 <pw> is because the <pw> element is required and must be between 6 and 16 characters, so it must be populated with something. On the server-side, the <loginSec:pw> value is looked at only if the '[LOGIN-SECURITY]' constant value is specified in the <pw> element. This means that the existing <pw> element is never ignored but simply used to explicitly refer to the <loginSec:pw> element with the use of a pre-defined constant value. There may be a better constant value to use or another mechanism that is compliant with RFC 5730, while allowing for overriding the password value in the extension. The same approach is used for the RFC 5730 <newPw> element, and the related <loginSec:newPw> element. Use of the constant password value and the login security extension maintains backward compatibility, maintains compliance with RFC 5730, and enables an incremental switch to use longer passwords with the login security extension (e.g., short password with <pw> element and long new password via the <loginSec:newPw> element). The server would need to disallow the password to be set to '[LOGIN-SECURITY]' to avoid conflict; otherwise the client would need to use the '[LOGIN-SECURITY]' value with the RFC 5730 <pw> element and with the <loginSec:pw> element to authenticate. Any ideas with a better constant value or mechanism is greatly appreciated. > I don't know if I overlooked it, but it seems that there's only support > for password based login and provisioning. Do you plan to support other > things like digest authentication? I agree that it could be useful and I forgot about that, it could be a good idea to make something more generic at the same time, to handle other kind of authentications. There is already a VeriSign EPP extension for 2 factors auth, I do not find it online anymore but I implemented it and it was for namespaces: http://www.verisign.com/epp/authExt-1.0 'http://www.verisign.com/epp/authSession-1.0 but it was more for domain:update operations. JG - The 2 factor auth extensions (authSession and authExt) were not targeted for registrar login, but meant to be used to protect objects (e.g., domains) using a registrant second factor (OTP). These extensions were never published. -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
