> -----Original Message----- > From: regext <regext-boun...@ietf.org> On Behalf Of Gould, James > Sent: Friday, January 11, 2019 1:21 PM > To: p...@dotandco.com; regext@ietf.org > Subject: [EXTERNAL] Re: [regext] Minor comment on draft-gould-regext- > login-security-02 > > Patrick, > > Thank you for implementing draft-gould-regext-login-security and the > feedback. I provide responses to your feedback below prefixed with "JG - ". > > — > > JG > > > > James Gould > Distinguished Engineer > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > On 1/11/19, 2:12 AM, "regext on behalf of Patrick Mevzek" <regext- > boun...@ietf.org on behalf of p...@dotandco.com> wrote: > > Dear James and Matthew, > > A minor point while implementing it (finished, will announce it soon). > > If a new "long" password is presented, it is exchanged in the <newPW> > node. > > However for events, among the list of possible values for type you have: > newPw > > I see no reason for the different casing. > > I recommend that the type value is also newPW or, to be more in line with > other > values to just spell it out in full, hence "newPassword". > > In fact I have found out one instance of > <loginSec:newPw> > for the XML node, so maybe a leftover of a previous change. > You may want to double check all examples/quotes of the node name to > have the proper casing. > > JG - Thank you for finding the inconsistency to the case of the > <loginSec:newPW> element in the extension. The goal is to match the case > of the <newPW> element in RFC 5730, so I'll be sure to consistently > reference "newPW" throughout in the next version of the draft. > > Also since all 3 nodes are optional under loginSec you may wish to specify > that the extension should be sent only if at least one of the node is present > beneath it. > Or what the server should reply if it gets only an empty root node. > > JG - I agree some text would be helpful here. I would anticipate that even if > there was an empty <loginSec:loginSec> element, the server would only > process the elements passed, so the server would do nothing with the > empty element. I'll take a shot with some text in the next version of the > draft. > > (and on a more philosophical level, I feel userAgent should not be defined > in this extension because it has nothing to do with passwords and could be > useful just be itself; it is useless however to create an extension just for > it so > I can understand why putting it there, but it is still bundling things > together > that are not related) > > JG - The Login Security Extension goes beyond passwords and relates to > security in general. The userAgent helps identify current and future security > events that can be included in the login response. > > And maybe provide some advice about downgrade, what about the > following chain of events: > - change of password using loginsec:newPW for a long password > - but then change back to short password using pure newPW without the > loginSec part. > > Allowed? Recommended? > > JG - Yes, it would be allowed by the extension, but may not be allowed by > server policy. The <loginSec:newPW> element is only required if the new > password is longer than the RFC 5730 maximum of 16 characters. The same > holds true for the <loginSec:pw> element. I recommend that the client > increase instead of decrease the strength of the passwords, but there is > nothing in the extension that would disallow it.
Jim, that sounds like it's worth addressing in the Security Considerations section of the document. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
