Subject: [precis] passwords as octet strings

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 18 Oct 2011 11:53:43 -0600

On the SAAG list, Mike Parker expressed concerns about mandating that
passwords MUST be Unicode, because some systems store passwords as octet
strings...

http://www.ietf.org/mail-archive/web/saag/current/msg03479.html

As I see it, the PRECIS WG is not mandating, and could not mandate, that
any given application technology MUST support non-ASCII passwords.
Instead, it's giving protocol designers a common tool for preparing and
comparing passwords (and other strings) containing Unicode characters,
if they choose to support such things.

However, we might want to provide some text in the security
considerations about the desirability (or not) of full-Unicode passwords.

Peter

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 18 Oct 2011 14:11:59 -0400

> passwords MUST be Unicode, because some systems store passwords as octet

Right.  Precis can hardly dictate what programs not implementing its
specifications do, any more than precis can go back in time and cause
applications to do this.  (Compare this with the IDNA2008 MUSTs: every
non-compliant fake A-label is still a perfectly good DNS label.
Indeed, the string "can't" is not a legal IDNA2008 label, but it's a
valid DNS label anyway.)

> if they choose to support such things.

Exactly: if you want to do precis, then it MUST be Unicode.  Behaviour
for strings that are not Unicode, including binary blobs and any other
character encoding, is undefined.

> considerations about the desirability (or not) of full-Unicode passwords.

I'm slow, but what's the security consideration?  There are
interoperability considerations: if two applications want to
co-operate in authentication, then they're going to need to use
Unicode or make up their own protocol.  

A

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 18 Oct 2011 12:15:31 -0600

> character encoding, is undefined.

Agreed with all that.

> Unicode or make up their own protocol.  

Right, it's text about interoperability. Where exactly that belongs is
another matter. I'm happy to add a section about interoperability.

Peter

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

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 18 Oct 2011 21:20:02 +0200

> another matter. I'm happy to add a section about interoperability.

Please separate the question on what charset (including encoding) is used in the protocol with how comparisons (etc) is done. What is the responsibility on the "client" and "server", etc.

   Patrik

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 Oct 2011 14:43:01 -0600

> Please separate the question on what charset (including encoding) is used in the protocol with how comparisons (etc) is done. What is the responsibility on the "client" and "server", etc.

Here is proposed text.

###

   Although strings that are consumed in PRECIS-based application
   protocols are often encoded using UTF-8 [RFC3629], the exact encoding
   is a matter for the using protocol, not the PRECIS framework.

   It is known that some existing systems are unable to support the full
   Unicode character set, or even any characters outside the US-ASCII
   range.  If two (or more) applications need to interoperate when
   exchanging data (e.g., for the purpose of authenticating a username
   or password), they will naturally need have in common at least one
   coded character set (as defined by [RFC6365]).  Establishing such a
   baseline is a matter for the using protocol, not the PRECIS
   framework.

###

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 31 Oct 2011 16:15:51 +0900

>>>>> considerations about the desirability (or not) of full-Unicode passwords.

For the record, there are other issues which make using full Unicode 
passwords a problem. They mainly stem from the fact that you can't see a 
password when you type it. This for example makes it very difficult to 
e.g. use passwords with Han characters, because they are usually input 
by using a phonetic method and then verifying/tweaking the converted result.

[I don't think there's a need for this fact to go into the document.]

Regards,    Martin.

> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: JFC Morfin <[email-masked]>
Date: Mon, 31 Oct 2011 11:48:19 +0100

This is why I would prefer an open list of criteria rather than a few
classes gathering rigidly a few of them. Special needs would be more
easily addressed.
jfc

2011/10/31, "Martin J. Dürst" <[email-masked]>:
>>> Please separate the question on what charset (including encoding) is used
>>> in the protocol with how comparisons (etc) is done. What is the
>>> responsibility on the "client" and "server", etc.
>>
>> Here is proposed text.
>>
>> ###
>>