Re: Last Call: draft-ietf-sasl-scram

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



John C Klensin <john-ietf@xxxxxxx> writes:

>> Vulgar Fraction One Half (U+00BD)
>> Acute Accent (U+00B4)
>> Diaeresis (U+00A8)
>
> That is important data.  It seems to me that it implies:
>
> 	* if entropy in passwords and/or properly reflecting
> 	keyboards is more important than password
> 	interoperability (whatever that means), then we should
> 	be moving away from NFKC and, hence, from the current
> 	version of SASLprep.

I believe NFKC is sub-optimal for password processing.  It reduces
entropy for many non-ambigious characters.  For example NFKC('ª') = 'a'
which seems like a clear example of an unwanted conversion.

> 	* if entropy in passwords is less important than
> 	interoperability with any Latin-based (or
> 	Latin-character-containing) keyboard one happens to
> 	encounter, then NFKC should be mandatory.  However, one
> 	needs to think about how far to carry that argument
> 	because, if it is taken very far, there is a strong case
> 	for restricting passwords to the basic, undecorated,
> 	Latin letters that appear on all such keyboards.  

I don't believe there is a good case for this.  Improving entropy in
passwords is important.  There shouldn't be any _technical_ reason in
authentication protocols why users cannot use 'ª' in a password to
provide more entropy to the system than using 'a'.

There are many environments where non-ascii characters are a bad idea
from technical or social reasons, but those environments should not
restrict less limited environments.  It is fine for a system to validate
passwords against [A-Za-z0-9] if that is required, and that system will
be able to use SCRAM too.

> And, of course, it would be possible to decide that we are stuck
> with the decisions made in SASLprep.  If so, it pretty strongly
> suggests to me that we had better get a lot more careful and
> conservative about whatever coding decisions we make in the
> future.

For SCRAM I believe we are stuck with SASLprep because there are no
drafts to provide a replacement that are close to being mature.

/Simon
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]