Subject: [http-auth] Consensus call about normalization

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

Hi

There was a discussion in the room about normalization.

Here’s a proposal. Please respond to the list if it’s acceptable:

Clients MUST normalize input (both userid and passwords) to NFC

Server MAY normalize with old clients (clients that don’t send the charset attribute)

Question to the group: what should a server do with a non-normalized userid/password, where the client is new (i.e. sends “charset”) - this is a broken client.

Please respond to the list within the next two weeks.

Thanks

Matt & Yoav

---

From: Yutaka OIWA <[email-masked]>
Date: Sat, 15 Nov 2014 13:25:34 +0900

> Server MAY normalize with old clients (clients that don’t send the charset attribute)

For Basic, yes +1.
For other schema, I prefer dropping it or
append something like "if applicable/possible/reasonable".
I personally don't like specs to say
"you MAY do what you can't actually do"
unless it was an April-fool RFC.

> Question to the group: what should a server do with a non-normalized userid/password, where the client is new (i.e. sends “charset”) - this is a broken client.

Servers MAY do almost whatever they want:
1) it MAY reject the clients as an invalid attempt, or
2) it MAY normalize the input (only when plaintext username
and passwords are available, like Basic), or
3) it MAY process it without normalization.
(Verbosely written: the text can be simpler than this.)

The rationale is that
the specification should not require servers to understand
complex Unicode NFC rules (both checking and processing),
i.e. it should not require servers to reject such an input.

Also note that Digest with userhash option can do
nothing but processing it as-is, even when charset is specified.

The clause 2) can be dropped, but I personally think that
we have no reason to disallow this, if we allow it for legacy inputs.

-- 
Yutaka OIWA, Ph.D.
           Senior Researcher, Research Institute for Secure Systems (RISEC)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

2014-11-15 11:04 GMT+09:00 Yoav Nir <[email-masked]>:
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

---

From: Julian Reschke <[email-masked]>
Date: Sat, 15 Nov 2014 20:54:41 +0100

> Clients MUST normalize input (both userid and passwords) to NFC

When charset is "UTF8", right?

> Server MAY normalize with old clients (clients that don’t send the charset attribute)

I don't think we need to state this.

> Question to the group: what should a server do with a non-normalized userid/password, where the client is new (i.e. sends “charset”) - this is a broken client.

In HTTPbis, we usually did not make any normative requirements for 
broken messages, unless there was a security concern connected to it. So 
I would leave this unspecified.

> Please respond to the list within the next two weeks.

I still think that this is something implementers just won't do. Unless 
I'm missing something here there is potential pain, but little gain.

Bets regards, Julian

---

From: Michael Sweet <[email-masked]>
Date: Mon, 17 Nov 2014 12:29:11 -0500

Yoav,

I'm OK with a Client requirement when using UTF-8.

For the server any normalization is an implementation detail, for both UTF-8 and legacy stuff, so I don't think we want to say anything there.

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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Nov 2014 11:53:51 -0600

> Question to the group: what should a server do with a non-normalized userid/password, where the client is new (i.e. sends “charset”) - this is a broken client.

Whenever possible it's best to use normalization-insensitive string
comparison.  Whenever a password has to get fed through a PBKDF or
similar transformation, of course, it has to be in canonical form; for
Basic auth there's no such need, while for DIGEST there is.

Regardless, some node has to have Unicode normalization support of
some sort, and since clients tend to have to have it (see above), it
might as well be the client that normalizes.

But I prefer the normalization-insensitivity formulation because
sometimes decomposed forms leak, mostly courtesy of HFS+ decomposing
filenames on create.  That should mostly not be a problem here, so on
the whole I'm OK with the proposal.

Note though that when there's a need to digest a password then the
canonical form has to specify at least normalization, and as much as
stringprep profiles commonly do (e.g., additional mappings,
prohibitions, ...).

Nico
--

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 17 Nov 2014 12:50:54 -0800

No. Normalization added to older auth mechanisms will not work.

What currently works is consistency: users tend to use the same character composition mechanism when they access an account as they did when they created the account. IOW, the characters match by habit rather than normalization.

Normalization defined for new not yet deployed auth mechanisms is fine.

....Roy

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

---

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

> No. Normalization added to older auth mechanisms will not work.

Asking that clients that don't normalize start to is asking for trouble, yes.

Asking that servers do normalization-insensitive matching of usernames
is asking for much less trouble (since presumably there shouldn't be
very many existing and semantically distinct usernames that alias each
other under normalization-insensitive string comparison!).

For Basic that also works for passwords.

For Digest things get tricky.

> What currently works is consistency: users tend to use the same character composition mechanism when they access an account as they did when they created the account. IOW, the characters match by h…

Yes.

> Normalization defined for new not yet deployed auth mechanisms is fine.

Or for old ones when there is an indication that the new thing is expected.

Nico
--