Subject: [regext] Roman Danyliw's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 22 Jan 2020 09:51:59 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-regext-login-security-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 3.1.  When @type=”stat” and the name of the stat is set in @name,
how does a client know the semantics of this stat?  Is that negotiated out of
band?

** Section 4.1.  Per  <loginSec:userAgent>, how are the clients supposed to
generate the app, tech or os strings in a way that the server will understand?
If this is out of scope, please just say so.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Alissa Cooper’s DISCUSS position.

** Section 3.1.  Is a @value required when @type=”cipher” or
@type=”tlsProtocol”? The examples in Section 4 show the use of @value.  Also,
what format should be used to express the cipher or tlsProtocol?

** Section 3.1.  Per the description of event@lang, please cite the language
format as coming from Section 3.4.3[W3C.REC-xmlschema-2-20041028]

** Section 4.1.  Per the children of <loginSec:userAgent>, would supporting a
more formal approach also be useful -- using SWID (ISO/IEC 19770-2:2015) or
COSWID (draft-ietf-sacm-coswid)?

** Section 4.1. Per pw and newPW’s descriptions of “all internal continuous
whitepaces … is replaced with a single #x20” – is this intentionally precluding
a password with a double space?

** Section 4.1. Per “If non-ASCII characters are supported with the plain text
password, then use a standard for passwords with international characters, such
as the OpaqueString PRECIS profile in [RFC8265].”, if non-ASCII characters are
supported, how does a client know which approach to take with a given server in
an interoperable.  RFC8265 is a helpful reference but the current text seems to
provide no guidance.

** Section 5.  Please note in the Section 5 introduction that the blob between
the BEGIN and END tags in Section 5.1 are formally specified by XML Schema.

** Section 8.  Please note that the Security Considerations of RFC5730 apply
and that this document enhances these security services.

** Editorial Nits
-- Section 1.  Typo.  s/pssword/password/

---

From: "Gould, James" <[email-masked]>
Date: Wed, 22 Jan 2020 21:42:03 +0000

Roman,

Thank you for your review and feedback.  I include my comments embedded below.

--

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

On 1/22/20, 12:52 PM, "Roman Danyliw via Datatracker" <[email-masked]> wrote:

    DISCUSS:

    band?

JG - The possible set of "stat" type security event "name" values can be discovered / negotiated out of band or in band via a separate policy EPP extension, such as draft-gould-regext-login-security-policy.

JG - Yes, that is out of scope, but there is a concrete example available in the Verisign EPP SDK, which is referenced in section 7.1 of draft-ietf-regext-login-security.

    COMMENT:

JG – There is no normative language that requires the “value” for @type=”cipher” or @type=”tlsProtocol”.  It is reasonable to expect an implementer to populate the “value” attribute based on:

  *   the description of the “cipher” and “tlsProtocol” types with “Identifies…”;
  *   the description of the “value” attribute with “Identifies the value that resulted in the login security event”;
  *   the example EPP response where there is a set of login security events.

JG – The format of the “cipher” or “tlsProtocol” is dependent on the server-side TLS library, where the server would return the “cipher” or “tlsProtocol” value provided by the TLS library upon a successful TLS handshake.  The format is left free-form based on this dependency.

JG – Yes, I can add the reference to section 3.3.3[W3C.REC-xmlschema-2-20041028] for the “lang” attribute.  I believe that section 3.3.3 is the correct section.

JG – I’ll review SWID and COSWID, but I believe the <loginSec:userAgent> children currently meet the needs.

JG – The intention is to describe how the XML schema “token” type is handled.  The XML schema “token” type is used in EPP RFC 5730, which draft-ietf-regext-login-security is extending to remove the 16 character constraint.  There is no intention to implicitly or explicitly change the handling of whitespace from what is defined in EPP RFC5730.

    provide no guidance.

JG – This language was added based on a discussion with the Area Director to address a concern raised on the mailing list.  The server policy can be communicated out of band or in band using a policy extension such as draft-gould-regext-login-security-policy.

JG – I can add “XML” prior to each “schema” reference in the introduction of section 5.

JG – I can add a leading sentence to section 8 stating that, “The Security Considerations of [RFC5730] apply in this document, and this document enhances these considerations.”

    ** Editorial Nits

JG – I believe the nit is s/pasword/password/ in section 1, which will be fixed.

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 23 Jan 2020 13:35:21 +0000

Hi JG!

Thanks for the quick response.  See details inline …

From: iesg <[email-masked]> On Behalf Of Gould, James
Sent: Wednesday, January 22, 2020 4:42 PM
To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; Joseph Yee <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Roman Danyliw's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)

Roman,

--

JG

James Gould

Distinguished Engineer

[email-masked]<mailto:[email-masked]> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 1/22/20, 12:52 PM, "Roman Danyliw via Datatracker" <[email-masked]<mailto:[email-masked]>> wrote:

    DISCUSS:

    band?

[Roman] Understood.  Can you include a sentence to that effect.

[Roman] Understood.  Can you add a sentence to that effect here too.  These would address my concerns.

    COMMENT:

[Roman]  No problem.  Thanks for the clarification.

[Roman]  Thanks.

[Roman] No problem.  I wanted to ensure there was awareness of related work on an XML approach to what seemed like the same approach.

[Roman] I understand the thinking – just read it as a token type (which it would be anyway per the schema).  Thanks for clarifying.

    provide no guidance.

[Roman] Understood.  IMO, noting that this kind of policy should/could be communicated out of band would be a helpful clarification.

[Roman]  Thanks.  This is really a reference nit – if you use a formal language, just cite it.

[Roman]  Thanks.  Works for me.

    ** Editorial Nits

[Roman] Right – with some irony, that’s the typo I was referencing with my own typo.  Thanks.

Thanks,

Roman