Joseph,
Thank you for the review and feedback. Below are my responses to your feedback. I’ll incorporate the WGLC feedback and bump the XML namespace to “urn:ietf:params:xml:ns:epp:loginSec-1.0” in draft-ietf-regext-login-security-03. Thanks, -- JG [cid:image001.png@01D255E2.EB933A30] James Gould Distinguished Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org> on behalf of Joseph Yee <j...@afilias.info> Date: Friday, August 2, 2019 at 11:48 AM To: Maurizio Martinelli <maurizio.martine...@iit.cnr.it> Cc: Registration Protocols Extensions WG <regext@ietf.org>, James Galvin <gal...@elistx.com> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-login-security I support to move this draft forward. On review, I found few things the draft needs to address: Section 3.1 Event "name": Used to define a sub-type or the type name when the "type" attribute is "custom" But the line "stat" in the same section also state that "name" must set. So for "name" it should say: .... when "type" attribute is "custom" or "stat" JG – Actually the “name” is used to define the sub-type for any of the “type” values including “stat”, and the “name” is used to define a new type when the “type” value is “custom”. In the case of the “stat” type, the “name” attribute is required to formally define what statistic it is. I will update the definition to read ‘Used to define a sub-type when the "type" attribute is not "custom" or the full type name when the "type" attribute is "custom".’. I will also revise the description of the “stat” type to read ‘Provides a login security statistical warning that MUST set the "name" attribute to the name of the statistic.’. [LOGIN-SECURITY] I think using "[LOGIN-SECURITY]" as indicator is fine, but I think the draft needs to expand to cover the rationale (Jim's response in separate thread is good, IMO). Also, the draft should cover edge case scenario like what should the server do if client's password is "[LOGIN-SECURITY]". Should server review and force all clients to change their password if they use '[LOGIN-SECURITY]'? It is edge case, but I think it is better to cover here rather than covering it in BCP. JG – There should be no method for the server to review the passwords, since they should be hashed. I believe the best method to address this corner case is to handle it going forward by adding the sentence ‘The server MUST NOT allow the client to set the password to the value “[LOGIN-SECURITY]”.’. Section 4.1 <loginSec:loginSec> "A <loginSec:loginSec> element is sent along with the [RFC5730] <login> command and MUST contain at least one of the following child elements" But every element is defined optional. Is it intentional that if the password conforms RFC5730, then the whole <loginSec> can be skipped, but client can still utilize it if they intend to pass information in <loginSec:userAgent>? JG – Yes, the <loginSec:loginSec> extension is only needed if the client has a password longer than what RFC 5730 supports, the client has a new password that is longer than what RFC 5730 supports, or the client intends to pass the user agent information. More than one purpose can apply, but at a minimum the extension must not be passed unless there is at least one condition. This is why the language states that at least one child element must be passed and each of the child elements is defined as optional. Also, every elements under <loginSec:userAgent> are optional. I believed that authors would want at least one field defined if the client created <loginSec:userAgent>. JG – I’ll use the <loginSec:loginSec> element pattern for the <loginSec:userAgent> element, where it will state ‘The <loginSec:userAgent> element MUST contain at least one of the following child elements:’ with each of the child elements being optional. This means that there must not be an empty element and any of the sub-elements can be used. I believed that I understand what Section 4.1 wants, but I think we need to work on the wording more. Best, Joseph On Mon, Jul 29, 2019 at 5:45 AM Maurizio Martinelli <maurizio.martine...@iit.cnr.it<mailto:maurizio.martine...@iit.cnr.it>> wrote: +1 Maurizio > Il giorno 27 lug 2019, alle ore 17:29, James Galvin > <gal...@elistx.com<mailto:gal...@elistx.com>> ha scritto: > > This is a reminder to please indicate your support or concerns regarding this > document. > > We do need expressions of support to advance this document. > > Thanks, > > Antoin and Jim > > > > > On 12 Jul 2019, at 15:13, James Galvin wrote: > >> The following working group document is believed to be ready for submission >> to the IESG for publication as a Proposed Standard: >> >> https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/ >> >> A WG last call would normally be two weeks long. However, because the IETF >> meeting is in two weeks this last call will be extended 1 week and will end >> at close of business, Friday, 2 August 2019. >> >> Please review this document and indicate your support (a simple “+1” is >> sufficient) or concerns with the publication of this document by replying to >> this message on the list. >> >> As you review the document, please take note of a message from Patrick >> Mevzek on 2 July 2019 where he indicated he would not block the advancement >> of the document but he did have some disagreement about a few points: >> >> https://mailarchive..ietf.org/arch/msg/regext/Y2nYOQ7JbhUIfPb80tXQL0neTNc<https://mailarchive.ietf.org/arch/msg/regext/Y2nYOQ7JbhUIfPb80tXQL0neTNc> >> >> Although Patrick was not looking to open the debate on these concerns with >> his message, the Chairs do want to make sure that other working group >> members have had a chance to consider them. The Chairs believe the >> consensus is to move forward at this time. >> >> Finally, we need a document shepherd for this document. If you are >> interested in being the document shepherd please let the Chairs know.. >> >> Thanks! >> >> Antoin and Jim > > _______________________________________________ > regext mailing list > regext@ietf.org<mailto:regext@ietf.org> > https://www.ietf.org/mailman/listinfo/regext -- Dr. Maurizio Martinelli Responsabile Servizi Internet e Sviluppo Tecnologico CNR - Istituto di Informatica e Telematica via G. Moruzzi 1, 56124 PISA, Italy E-Mail: maurizio.martine...@iit.cnr.it<mailto:maurizio.martine...@iit.cnr.it> Phone: +39 050 3152087 Fax: +39 050 3152207 Web: http://www.iit.cnr.it/maurizio.martinelli _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
