Subject: Re: [regext] AD review for draft-ietf-regext-login-security-04

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 04 Nov 2019 11:24:03 -0500

On Tue, Oct 29, 2019, at 14:20, Barry Leiba wrote:
> Jim, thanks for accepting most of my edits and for addressing my 
> question about the password characters. It just seems odd to me that 
> you can't use << my#x20#x20#x20pw >> as a password, but you can use, 
> say, << my#x20#xA0#x20pw >> (or any of a number of other variations 
> with other Unicode space characters. But the reason sounds... 
> reasonable, so: post a rev and I'll last-call it.

As a data point, the current NIST recommendations on passwords:
https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver

Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well. To make allowances for likely mistyping, verifiers MAY replace multiple consecutive space characters with a single space character prior to verification, provided that the result is at least 8 characters in length. Truncation of the secret SHALL NOT be performed. For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.
</quote>

Note the "MAY replace multiple consecutive space characters".

Also, as I hinted in the past during discussion on this extension, the whole area of "internationalized" identifiers,
such as usernames and passwords has been explored in the PRECIS ("Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols") set of RFCs,
and specifically RFC 8265 "Preparation, Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords".
In short it defines an "OpaqueString" profile, to be applied for passwords.
Among other things it has this:
.  Additional Mapping Rule: Any instances of non-ASCII space MUST be
       mapped to SPACE (U+0020); a non-ASCII space is any Unicode code
       point having a Unicode general category of "Zs", with the
       exception of SPACE (U+0020).  As was the case in RFC 4013, the
       inclusion of only SPACE (U+0020) prevents confusion with various
       non-ASCII space code points, many of which are difficult to
       reproduce across different input methods.

(note also RFC8264 §5.3 for a discussion about spaces)

I am still of the opinion that we should have used/referenced that work more.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Tue, 5 Nov 2019 21:37:58 +0000

Patrick,

The trimming and collapsing of whitespace in draft-ietf-regext-login-security is a feature of the XML schema “token” type that exists today based on what’s defined in RFC 5730.  There is no issue with complying with the NIST recommendation, where the use of the trimming and collapsing of the XML schema "token" type is needed to address XML formatting issues (e.g., XML pretty printing).  Multiple consecutive space characters will be replaced with a single character by the XML parser.  I don't see the applicability of PRECIS for draft-ietf-regext-login-security.  

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

On 11/4/19, 11:26 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    -- 
      Patrick Mevzek
      [email-masked]
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 05 Nov 2019 16:48:23 -0500

On Tue, Nov 5, 2019, at 16:37, Gould, James wrote:
> The trimming and collapsing of whitespace in 
> draft-ietf-regext-login-security is a feature of the XML schema “token” 
> type that exists today based on what’s defined in RFC 5730.  

I know.

I was just going into Barry's way, as it makes no sense to me as well to not allow two multiple U+0020 spaces, but we allow U+00A0 U+0020, which is a variation of the same thing.

We are "mostly" safe because all of those are typically not user handled passwords,
as they are used for machine to machine connections, so "mostly" safe from display
and human handling issue. But just "mostly", not completely.

> There is 
> no issue with complying with the NIST recommendation, where the use of 
> the trimming and collapsing of the XML schema "token" type is needed to 
> address XML formatting issues (e.g., XML pretty printing).

I did not say that there is an issue there, nor that following this recommendation is good
or bad.
Note however it remains vague as saying "*THE* space character" (emphasis mine) and
"UNICODE characters should be accepted as well" and these 2 sentences do not mix well
as Unicode defines more than one "space" character...

> I don't see the applicability of PRECIS for 
> draft-ietf-regext-login-security.  

I am sorry if I failed to show its applicability, but for me it is absolutely applicable to it. It gives both a framework and examples.
The framework allows each application (that is each protocol) to properly define
"classes" of strings, such as the one for usernames or the one for passwords,
and to define the rules in it.
This is completely orthogonal to the final schema used to encode the stuff
in some framing protocol, such as XML here.

But we had this debate before as I brought the issue, you already said it
is not relevant in your opinion, and the draft is now near standardization,
so too late and useless to discuss it again I think. I didn't want to bring the
issue again, I was just leaning towards Barry's opinion that the constraints are
"strange" (yes they come from the XML schema datatypes, but that does not define
the semantic of the field, which is not just an XML token, but really a password,
which is all the discussion of PRECIS in fact).

-- 
  Patrick Mevzek
  [email-masked]