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

From: [email-masked]
Date: Thu, 16 May 2013 12:18:11 -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-00.txt
	Pages           : 10
	Date            : 2013-05-16

Abstract:
   The "Basic" authentication scheme defined in RFC 2617 does not
   properly define how to treat non-ASCII characters.  This has lead 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 set, and even less interoperability for any
   characters beyond that.

   This document defines a backwards-compatible extension to "Basic",
   specifying the server's character encoding 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-00

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

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 16 May 2013 22:54:41 +0300

Hi, this draft is short and useful, but can still be improved :-)

- Nit: the word "lead" in the abstract and in the intro should be "led".

- Although this is clear from the example, please say explicitly that 
the explicit encoding is used for both the username and the password.

- It's funny that the example only uses ASCII. I will be happy to 
provide a non-ASCII example in Hebrew (although the author's city name 
would do just as well).

- In Sec. A.1.1, why is 8859-1 singled out? Seems to me the strategy 
should use the locally reasonable locale, e.g. ISO 8859-8 for the he_IL 
locale.

Thanks,
	Yaron

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 May 2013 16:27:28 -0400

For Digest there are two separate changes that are frequently suggested

1) Character set internationalization
2) Algorithm agility

Seems to me that if we make any changes we should fix both.

Applications are required to accept additional parameters on
www-authenticate

   auth-param
     This directive allows for future extensions. Any unrecognized
     directive MUST be ignored.

Since we can use www-authenticate I propose that we solve the character set
issue by having the server add a flag to the response saying which charsets
it accepts. If the client understands the extension and sees the flag then
it MUST use one of the offered charsets (same registry as for BASIC) and
include the flag. Otherwise it does what it does today...

Note that with this approach we don't affect any existing code path so we
don't need to investigate. If people have found a way to make Digest work
internaltionalized that is not going to be affected. I really doubt that is
the case though.

Algorithm agility is really unnecessary from a security point of view. The
double MD5 construction is more than sufficient to prevent attack and an
attacker can perform a brute force dictionary attack in any case.

Algorithm agility is still desirable however as MD5 is an algorithm we want
to eradicate from code bases and move to SHA256 or SHA3. So I suggest we
add in an algorithm using HMAC-SHAn where n is a single value TBS by the
crypto folk.

I would also like to clean up the construction so that the password
component is clearly being used to derive the HMAC key.

On Thu, May 16, 2013 at 3:54 PM, Yaron Sheffer <[email-masked]>wrote:

> - Although this is clear from the example, please say explicitly that the
> explicit encoding is used for both the username and the password.
>
> - It's funny that the example only uses ASCII. I will be happy to provide
> a non-ASCII example in Hebrew (although the author's city name would do
> just as well).
>
> ______________________________**_________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/http-auth<https://www.ietf.org/mailman/listinfo/http-auth>
>

-- 
Website: http://hallambaker.com/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 May 2013 10:11:02 +0200

> - Nit: the word "lead" in the abstract and in the intro should be "led".

Fixed in <http://trac.tools.ietf.org/wg/httpauth/trac/changeset/4>.

> the explicit encoding is used for both the username and the password.

Will do.

> provide a non-ASCII example in Hebrew (although the author's city name

The example uses the POUND sign, which is not ASCII.

> ...

Because that's what RFC2617 could be read to say, and some UAs actually 
do that.

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 May 2013 10:20:31 +0100

Nice. This looks pretty baked to me. Some nitty comments
below, nothing major at all.

Cheers,
S.

- What's the story on updating/obsoleting 2617? I don't much
care but this'd be a good thing to work out before IETF LC as
otherwise we might end up doing multiple LC's to get it right.
Seems like httpbis-p7 doesn't obsolete 2617 and nor does this
and presumably nor would an updated digest. Somehow that seems
wrong;-) I can't recall if 3 RFCs can all obsolete 2617 or
not but maybe that'd be worth checking out with someone who
cares. I can find someone who cares and ask if that's what
the wg want - the chairs can tell me if so, or that might be
better as a thing the httpbis wg think about, or perhaps its
all been thought about already.

- An additional example or two would be good, maybe with
a username and password with asian characters or something.
If sticking with one Example, maybe change the title of
section 4:-)

- section 5: I wondered if there are any potential bad effects
if a UA sends an Authorization header like this to a server
that only supports ASCII. Is it worth adding a warning that
servers that assume that they get ASCII after base64 decoding
Authorization headers might get a surprise? Yes, it'd have
to be pretty crappy server code for that to cause a security
problem, but I guess it could happen.

- A.1: do we know that current UAs will actually ignore the
new parameter? I think I recall someone saying that is the
case, but I forget. Ah - you have it in B.3 - I think it'd
be better to merge those bits. The links from B.3 are great
btw, thanks for doing that work.

- A.1.1: trying twice made me wonder if there's any way to
leverage that for some kind of side-channel/oracle attack.
Can't think of one but has someone thought about that?

- A.2: "as well as before" - is that being disingenuous? If
so I think it'd be better not to do that since many people
reading this won't get it. I'd suggest replacing that with
"as well or as badly as before."

- B.2: "this scheme" - I think the "this" here refers to
Digest, but its ambiguous as written.

- D.2: I don't understand this but then I never did and
probably never will, so you could add anything and that'd
work for me:-)

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 May 2013 12:37:31 +0200

> - What's the story on updating/obsoleting 2617? I don't much

HTTPbis P7 obsoletes the framework part of RFC 2617. We'll need two 
additional specs defining Basic and Digest to get rid of RFC 2617 
completely.

*This* draft just addresses the I18N issue of Basic. The reason why I 
don't want to do it in a new Basic spec is that this *really* is 
experimental. There's no point putting it into something that's 
replacing 2617 if we don't have any evidence that it works.

> If sticking with one Example, maybe change the title of

Ok.

> problem, but I guess it could happen.

Clients already send non-ASCII; the issue here is making the encoding 
reliable.

> btw, thanks for doing that work.

I can do that.

> Can't think of one but has someone thought about that?

Feedback appreciated :-)

> "as well or as badly as before."

Ack.

> Digest, but its ambiguous as written.

Also, this WG actually is chartered to update Digest, so this needs work.

> probably never will, so you could add anything and that'd

Thanks for the feedback!

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 May 2013 11:48:32 +0100

> additional specs defining Basic and Digest to get rid of RFC 2617

Ok so the plan is something like, this, p7 and then a new
basic and a new digest all become RFCs that update 2617.
When those are all done, the we can do a no-I-D IETF LC
to obsolete 2617 and just get the RFC editor to change the
metadata. (Updates and obsoletes relationships are not part
of the RFC, but part of the metadata, and that latter can
change.)

I think that works. Doubtless someone'll have a problem
with it somewhere along the line, but we can worry about
that then:-)

Ta,
S.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 17 May 2013 20:05:33 +0900

> with it somewhere along the line, but we can worry about

I don't have a problem. A slight alternative (and the way I seem to 
remember it having been done in a past case) is to have the first few 
new RFCs use the 'update' label, and the last one use the 'obsoletes' 
label. That allows to get rid of one IETF Last Call.

Regards,   Martin.