Subject: [saag] internationalized passwords

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Sep 2011 14:29:29 -0600

During a discussion related to SASLprep (RFC 4013) on the KITTEN WG
list, Nico Williams pointed out that during standardization of the SCRAM
SASL mechanism there would not have been consensus to say that passwords
must be ASCII (and therefore must not contain Unicode code points
outside the traditional ASCII-7 range):

http://www.ietf.org/mail-archive/web/kitten/current/msg02741.html

This issue has also come up in the PRECIS WG, which is working on a
generic replacement for stringprep and therefore will (we hope) provide
a framework that can be used to replace SASLprep as the recommended way
to prepare and compare Unicode code points in passwords. In particular,
see Sections 3.2 and 10.4 of draft-ietf-precis-framework-00, which
define and provide some security considerations regarding a string class
we're calling the "SecretClass":

http://tools.ietf.org/html/draft-ietf-precis-framework-00#section-3.2

http://tools.ietf.org/html/draft-ietf-precis-framework-00#section-10.4

As document editor of draft-ietf-precis-framework, I would appreciate
feedback from folks in the Security Area about the proposed "SecretClass".

I will forward this message to the PRECIS WG and ask participants in
that WG to pay attention on the SAAG list if they're interested in the
discussion.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 07 Sep 2011 00:04:37 +0300

Hi Peter,

it's quite obvious to me that Unicode must be supported.

As a data point, this is our relevant text from RFC 6124 (EAP-EKE 
password authentication):

    This protocol supports internationalized, non-ASCII passwords.  The
    input password string SHOULD be processed according to the rules of
    the [RFC4013  <http://tools.ietf.org/html/rfc4013>] profile of [RFC3454  <http://tools.ietf.org/html/rfc3454>].  A password SHOULD be considered
    a "stored string" per [RFC3454  <http://tools.ietf.org/html/rfc3454>], and unassigned code points are
    therefore prohibited.  The output is the binary representation of the
    processed UTF-8 [RFC3629  <http://tools.ietf.org/html/rfc3629>] character string.  Prohibited output and
    unassigned code points encountered in SASLprep preprocessing SHOULD
    cause a preprocessing failure and the output SHOULD NOT be used.

And one feedback (I am not an I18N expert by any means, although I can 
write both LTR and RTL :-): how can you disallow space characters 
(presumably including ASCII SPACE) from the Secret Class?

Thanks,
     Yaron

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Sep 2011 15:25:22 -0600

> it's quite obvious to me that Unicode must be supported.

I'm happy to hear it. :)

>    cause a preprocessing failure and the output SHOULD NOT be used.

Right. What we're trying to do in the PRECIS WG is define a way to
perform such processing without a dependency on RFC 3454 (since
stringprep is hardcoded to use Unicode 3.2). The intent is to make each
new PRECIS string class as backward-compatible as possible with the
relevant stringprep profile. So we're hoping that the SecretClass will
produce output close to what SASLprep currently produces. At least, that
is the goal...

> (presumably including ASCII SPACE) from the Secret Class?

That was one point of contention. You're probably right that spaces are
needed to suppose pass phrases instead of just pass *words*.

---

From: Mouse <[email-masked]>
Date: Wed, 7 Sep 2011 00:45:22 -0400 (EDT)

>> it's quite obvious to me that Unicode must be supported.

I'm not entirely clear what the context here is, but you might want to
at least consider that you'd be repeating the ssh mistake if you make
this a MUST.  (ssh, as specified, is unimplementable on some Unix
variants, and quite possibly other OSes, because some things which the
RFCs say MUST be in UTF-8, such as usernames or passwords, exist in the
system as octet strings rather than character strings and thus
inherently cannot be recoded.  That ssh comes as close to working as it
does is a testament to ASCII's ubiquity.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B