Subject: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-01.txt

From: [email-masked]
Date: Sun, 30 Jun 2013 07:28:38 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF.

	Title           : An Encoding Parameter for HTTP Basic Authentication
	Author(s)       : Julian F. Reschke
	Filename        : draft-ietf-httpauth-basicauth-enc-01.txt
	Pages           : 11
	Date            : 2013-06-30

Abstract:
   The "Basic" authentication scheme defined in RFC 2617 does not
   properly define how to treat non-ASCII characters.  This has led to a
   situation where user agent implementations disagree, and servers make
   different assumptions based on the locales they are running in.
   There is little interoperability for the non-ASCII characters in the
   ISO-8859-1 character repertoire, and even less interoperability for
   any characters beyond that.

   This document defines a backwards-compatible extension to "Basic",
   specifying the server's character encoding scheme expectation, using
   a new authentication scheme parameter.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-enc

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-enc-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-enc-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Jun 2013 16:39:34 +0200

On 2013-06-30 16:28, [email-masked] wrote:
> ...

Diffs: 
http://trac.tools.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-enc-01.txt

This draft addresses most (all?) of the feedback I received so far.

It also switches to RFC 6365 compliant terminology, and changes the 
parameter name to "charset" for consistency with RFC 2831 (Digest in SASL).

For now, there's one open issue left: we currently do not say anything 
about Unicode normalization forms, but we probably should.

Do we want to go to WGLC with that issue still open?

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 30 Jun 2013 11:22:16 -0700

On Jun 30, 2013, at 7:39 AM, Julian Reschke <[email-masked]> wrote:

> For now, there's one open issue left: we currently do not say anything about Unicode normalization forms, but we probably should.

-1. This has made other protocols less interoperable with little perceptable benefit.

Normalization is useful for preventing false negatives (where you want an unnormalized string to match a normalized string because they are "equivalent"), at the expense of one or both parties needing to have a normalization engine that is kept up to date, covers all scripts, and so on.

At most, the spec might say "the server might want to do some normalization if a password does not exactly match with the server's expected value in case the client used a different set of characters to indicate the same password", but no more.

--Paul Hoffman

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 30 Jun 2013 20:47:55 +0200

>-1. This has made other protocols less interoperable with little perceptable benefit.

Being able to reliably use user names and passwords with non-ASCII
characters in them seems rather important to me, and considering the
strings here typically come from direct human input, people will run
into problems without suitable normalisation. Since the whole point
of the specification is to enable reliable use of non-ASCII, I think
it would be quite appropriate to put in something about that. Since
servers receive all the input data, they can normalize and compare
however they want, so some informative text pointing out problems to
expect and possible solutions should be enough.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 01 Jul 2013 00:14:00 +0300

Paul, your proposed text doesn't make sense to me, because with Basic 
auth, the server might keep a hash of the password instead of the raw 
password (to reduce the damage if the entire database gets stolen). In 
which case I would expect the server to normalize the password before it 
is being hashed without any check of the "expected value".

Thanks,
	Yaron

On 2013-06-30 21:22, Paul Hoffman wrote:
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 30 Jun 2013 14:35:43 -0700

On Jun 30, 2013, at 2:14 PM, Yaron Sheffer <[email-masked]> wrote:

> Paul, your proposed text doesn't make sense to me, because with Basic auth, the server might keep a hash of the password instead of the raw password (to reduce the damage if the entire database gets stolen). In which case I would expect the server to normalize the password before it is being hashed without any check of the "expected value".

The process that is checking for equivalence is not necessarily the process that stored the (possibly normalized) password, and the two processes might have different views of what normalization to use. Normalizing takes time. Thus, I would expect that the server would do a straight check first, and only fall back to one or more forms of string conversion (normalization, fixing of various i18n digit forms, removing points in Hebrew, etc.) if the first test failed.

This isn't to say that your assumption is wrong, but it is not the only one. Thus, my particularly wavy wording.

--Paul Hoffman

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 01 Jul 2013 14:45:00 +0900

On 2013/07/01 6:35, Paul Hoffman wrote:
> On Jun 30, 2013, at 2:14 PM, Yaron Sheffer<[email-masked]>  wrote:
>
> The process that is checking for equivalence is not necessarily the process that stored the (possibly normalized) password, and the two processes might have different views of what normalization to use.

That's definitely an important aspect of the problem, and should be 
called out. In particular, it's important to say that if you don't 
normalize when creating a password hash, then in the odd case that you 
get something half-baked (e.g. half in NFC and half in NFD,...), then 
it's going to be very hard to get back to the original form.

> Normalizing takes time.

Well, that's often brought up but not really very true or relevant.

First, it's easily possible to make normalization fast. In particular, 
it is possible to make normalization very fast for the frequent cases. 
(It's also possible to make it slow, but that's true of any kind of 
processing.)

Second, security-related calculations (hashes,...) are regularly 
designed so as to not be too fast. So normalization shouldn't be the 
bottleneck.

Regards,   Martin.

> Thus, I would expect that the server would do a straight check first, and only fall back to one or more forms of string conversion (normalization, fixing of various i18n digit forms, removing points in Hebrew, etc.) if the first test failed.
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 01 Jul 2013 07:59:48 +0200

On 2013-07-01 07:45, "Martin J. Dürst" wrote:
>>> password (to reduce the damage if the entire database gets stolen).
>>> In which case I would expect the server to normalize the password
>>> before it is being hashed without any check of the "expected value".
>>
>> The process that is checking for equivalence is not necessarily the
>> process that stored the (possibly normalized) password, and the two
>> processes might have different views of what normalization to use.
>

So what if we mandated normalization to happen on the client?

Best regards, Julian