Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-login-security

From: Joseph Yee <[email-masked]>
Date: Fri, 2 Aug 2019 11:47:46 -0400

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"

[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.

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>?

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>.

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 <
[email-masked]> wrote:

> +1
>
> Maurizio
>
>
> > Il giorno 27 lug 2019, alle ore 17:29, James Galvin <[email-masked]>
> 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
> >>
> >> 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
> > [email-masked]
> > 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: [email-masked]
> Phone: +39 050 3152087
> Fax: +39 050 3152207
> Web: http://www.iit.cnr.it/maurizio.martinelli
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>

---

From: "Gould, James" <[email-masked]>
Date: Mon, 5 Aug 2019 13:47:14 +0000

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

James Gould
Distinguished Engineer
[email-masked]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <[email-masked]> on behalf of Joseph Yee <[email-masked]>
Date: Friday, August 2, 2019 at 11:48 AM
To: Maurizio Martinelli <[email-masked]>
Cc: Registration Protocols Extensions WG <[email-masked]>, James Galvin <[email-masked]>
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"

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 <[email-masked]<mailto:[email-masked]>> wrote:
+1

Maurizio

> Il giorno 27 lug 2019, alle ore 17:29, James Galvin <[email-masked]<mailto:[email-masked]>> ha scritto:
>
> This is a reminder to please indicate your support or concerns regarding this document.
>
>> The following working group document is believed to be ready for submission to the IESG for publication as a Proposed Standard:
>>
>> 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
>
> [email-masked]<mailto:[email-masked]>

E-Mail: [email-masked]<mailto:[email-masked]>

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext

---

From: "James Galvin" <[email-masked]>
Date: Fri, 23 Aug 2019 09:13:50 -0400

Thanks to all who reviewed this document and responded to the LAST CALL. 
  Five people indicated their support and there were no objections.

We consider this LAST CALL closed and the document is to be revised and 
submitted to the IESG for consideration as a Proposed Standard.

The Chairs note that the authors have already submitted a revised 
document according to the comments received during the LAST CALL.

We are still looking for volunteers to be the document shepherd to 
submit this document the IESG.

This could be you!

Please let us know if you are interested.

Antoin and Jim

On 12 Jul 2019, at 15:13, James Galvin wrote:

> 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.
>
> 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:
>
> 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.
>