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

["Patrick Mevzek" <[e-mail]>]

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
  [e-mail]