Subject: [http-auth] Allowed Characters in usernames and passwords

From: Yoav Nir <[email-masked]>
Date: Fri, 14 Nov 2014 15:59:00 -1000

Hi

An issue that has been discussed on the list has been what characters are allowed for usernames and passwords in the Basic and Digest documents (this probably also applies to other specification, specifically MutualAuth, but that is not the issue in this message).

So the precis working group is creating the saslprepbis ([1]) document that should be published soon (as soon as the end of this year). That contains a profile for characters that are and aren’t recommended for use in username and passwords.

So the proposal that reflects the consensus of the people in today’s session is as follows:

Both the Basic and Digest drafts will mandate that supporting servers MUST support usernames and passwords that conform to the saslprepbis specification, and MAY support non-conforming ones. The rationale is that we have to have a MAY there, because we can’t prohibit stuff that works today. Both documents will add text with these MUST and MAY.

The room was unanimous in supporting this direction. If you disagree, please comment to the list by Monday 24-Nov-2014. Since we had a strong hum for in the room, we will take silence as consensus

Thanks

Matt & Yoav

[1] https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-09

---

From: Yoav Nir <[email-masked]>
Date: Fri, 14 Nov 2014 16:01:10 -1000

So of course I forgot something.

Additionally, the Basic and Digest documents will refer to the precis document, and not specify acceptable characters themselves, except where there is a unique requirement, such as the requirements around colons in usernames or passwords in Basic. In all other cases, saslprepbis will be our normative reference.

Yoav

> On Nov 14, 2014, at 3:59 PM, Yoav Nir <[email-masked]> wrote:
> 
> Hi
>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 16 Nov 2014 14:02:27 +0200

> On Nov 15, 2014, at 7:03 AM, John C Klensin <[email-masked]> wrote:
> 
> 
> --On Friday, November 14, 2014 19:00 -0700 Peter Saint-Andre -
> &yet <[email-masked]> wrote:
> 
>> FYI.
>> 
>> 
>> -------- Original Message --------
>> Subject: [http-auth] Allowed Characters in usernames and
>> passwords
>> Date: Fri, 14 Nov 2014 15:59:00 -1000
>> From: Yoav Nir <[email-masked]>
>> To: IETF HTTP Auth <[email-masked]>
>> 
>> Hi
>> 
>> An issue that has been discussed on the list has been what
>> characters are allowed for usernames and passwords in the
>> Basic and Digest documents (this probably also applies to
>> other specification, specifically MutualAuth, but that is not
>> the issue in this message).
>> 
>> So the precis working group is creating the saslprepbis ([1])
>> document that should be published soon (as soon as the end of
>> this year). That contains a profile for characters that are
>> and aren't recommended for use in username and passwords.
>> 
>> So the proposal that reflects the consensus of the people in
>> today's session is as follows:
>> 
>> Both the Basic and Digest drafts will mandate that supporting
>> servers MUST support usernames and passwords that conform to
>> the saslprepbis specification, and MAY support non-conforming
>> ones. The rationale is that we have to have a MAY there,
>> because we can't prohibit stuff that works today. Both
>> documents will add text with these MUST and MAY.
>> 
>> The room was unanimous in supporting this direction. If you
>> disagree, please comment to the list by Monday 24-Nov-2014.
>> Since we had a strong hum for in the room, we will take
>> silence as consensus
> 
> Peter, Yoav,
> 
> Given my ongoing mini-campaign to reduce the number of profiles
> and sets of rules to an absolute minimum because users won't be
> able to keep track of different ones and will only be astonished
> and confused, this is exceptionally good news.    Two comments:
> 
> (1) While the assertion that you "can't prohibit stuff that
> works" is probably true, you are not thereby limited to MAY.  It
> would be entirely consistent with IETF practices in the past to
> say "MUST support ... that conform and SHOULD avoid
> non-conforming ones except when the latter are justified by
> compatibility with existing implementations".  That still
> doesn't _prohibit_ the existing practices, but makes the desired
> compatibility norm somewhat more clear.
> 
> (2) I assume there are recommendations coming out of WHATWG
> and/or W3C that might interact with whatever HTTP-AUTH has to
> say.  If that is the case, I expect that the HTTP-AUTH
> recommendation will either be consistent with them or will
> identify and explain the differences.
> 
> It would be reasonable for you to assume that both comments
> above will, if necessary, be repeated during IETF Last Call.
> 
> best,
>    john

---

From: Julian Reschke <[email-masked]>
Date: Sun, 16 Nov 2014 15:44:00 +0100

On 2014-11-16 13:02, Yoav Nir wrote:
 > ...

HTTP Authentication Schemes deal with getting credentials over the wire, 
not with the way they are generated or stored. The set of allowable 
characters thus is sort of out-of-scope for a scheme definition, in 
particular when it has been in use for over a decade already.

I'm ok with "MUST support" (for the case when we're talking about the 
new charset=UTF8 world). However the "SHOULD avoid" doesn't make any 
sense to me. No real-world implementation will do this if there's a slim 
chance that it will prevent a user from logging into an existing system.

>> identify and explain the differences.

Concrete pointers, please.

>> above will, if necessary, be repeated during IETF Last Call.

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Tue, 25 Nov 2014 21:56:24 +0200

Hi Julian and Rifaat.

To re-summarize, the proposal was that servers MUST support usernames and passwords compliant with saslprepbis, and MAY support non-compliant characters (except for specialized requirements such as those around colon).
The room was unanimous on this, and confirming on the list yielded one objection to the “MAY” preferring “SHOULD NOT” for non-compliant characters. However, there was no support for this and as Julian said, we have no control over existing (or future!) user/password databases, and no sane implementation will block a valid user name just because it doesn’t comply with saslprepbis.

Please add text to your drafts reflecting this, and reference saslprepbis as a normative reference.

Julian: once you do that and publish a revision we can go to WGLC.

Matt & Yoav

> On Nov 15, 2014, at 4:01 AM, Yoav Nir <[email-masked]> wrote:
>

---

From: Nico Williams <[email-masked]>
Date: Tue, 25 Nov 2014 14:02:04 -0600

> To re-summarize, the proposal was that servers MUST support usernames and passwords compliant with saslprepbis, and MAY support non-compliant characters (except for specialized requirements such as…

What does this mean?  That the client MAY/SHOULD/MUST prep the thing?
How would the server know if the thing is prep'ed with saslprepbis (if
not by applying the prep itself)?  What would it mean for the server
to not "support usernames and passwords compliant with saslprepbis"?

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Tue, 25 Nov 2014 22:08:36 +0200

> On Nov 25, 2014, at 10:02 PM, Nico Williams <[email-masked]> wrote:
> 
> to not "support usernames and passwords compliant with saslprepbis”?

The discussion was about the profiles for usernames and passwords in sections 3.2 and 4.2 respectively of https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-10 .

We are not talking about the prep process (which the client should do), only about the result. We are saying that the server MUST support usernames and passwords that conform to those rules.

Yoav

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Nov 2014 23:26:52 +0100

> The discussion was about the profiles for usernames and passwords in sections 3.2 and 4.2 respectively of https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-10 .

In draft-11, there's a choice of "UsernameCaseMapped" and 
"UsernameCasePreserved" - I assume we'll choose the latter...

Best regards, Julian

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Sun, 30 Nov 2014 15:32:00 -0700

On 11/30/14, 3:26 PM, Julian Reschke wrote:
>>>> To re-summarize, the proposal was that servers MUST support
>>>> usernames and passwords compliant with saslprepbis, and MAY support
>>>> non-compliant characters (except for specialized requirements such
>>>> as those around colon).
>>>
>> The discussion was about the profiles for usernames and passwords in
>> sections 3.2 and 4.2 respectively of
>> https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-10 .
>
> "UsernameCasePreserved"

Yes, I added the options so that we'd all have definitive options (and 
so that UsernameCaseMapped wasn't defined in an XMPP specification).

> - I assume we'll choose the latter...

Probably.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 01 Dec 2014 00:00:43 +0100

>> - I assume we'll choose the latter...

OK, for now I have this change 
<http://trac.tools.ietf.org/wg/httpauth/trac/changeset/83#file1> - note 
that it only applies for the case where the server has advertised UTF-8 
support using the charset parameter.

Are we ok with this -- that is, can I submit a new draft and declare 
victory?

Best regards, Julian

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Sun, 30 Nov 2014 16:23:57 -0700

> support using the charset parameter.

Yes, I had always assumed so.

> Are we ok with this -- that is, can I submit a new draft and declare

I think so. [1]

Thanks for your patience and persistence!

Peter

[1] It is possible that we might try to consolidate or harmonize some of 
the profiles of the PRECIS FreeformClass, as we have done for profiles 
of the IdentifierClass. However, I expect that won't change the 
substance of the Password profile.