Subject: [http-auth] Last Call: <draft-ietf-httpauth-basicauth-update-05.txt> (The 'Basic' HTTP Authentication Scheme) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 05 Feb 2015 08:10:49 -0800

The IESG has received a request from the Hypertext Transfer Protocol
Authentication WG (httpauth) to consider the following document:
- 'The 'Basic' HTTP Authentication Scheme'
  <draft-ietf-httpauth-basicauth-update-05.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2015-02-19. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines the "Basic" Hypertext Transfer Protocol (HTTP)
   Authentication Scheme, which transmits credentials as userid/password
   pairs, obfuscated by the use of Base64 encoding.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 05 Feb 2015 23:49:04 +0100

>   pairs, obfuscated by the use of Base64 encoding.

I do not think the use of Base64 is intended as obfuscation and it seems
misleading to me to describe it as such. (The Introduction has the same
problem).

In the Introduction:

   The "Basic" scheme previously was defined in Section 2 of [RFC2617].
   This document updates the definition, and also addresses
   internationalization issues by introducing the "charset"
   authentication parameter (Section 2.1).

I think "updates" is the wrong word considering the document is intended
to "obsolete" RFC 2617.

In section 2:

   The "Basic" authentication scheme is based on the model that the
   client needs to authenticate itself with a user-ID [...]

The document switches between "user name", "username", "userid", and
"user-ID". I think the "user-ID" forms should be replaced by one of the
"name" forms.

   The realm value is an opaque string
   which can only be compared for equality with other realms on that
   server.

RFC 7235 says "The realm value is a string, generally assigned by the
origin server, that can have additional semantics specific to the
authentication scheme." This seems contradictory (perhaps the intent is
to say that for the particular case of Basic, the realm value is opaque
in contrast to other schemes where it might not be opaque, but that is
not clear from the text) and misleading (users make decisions based on
the string, which often contains human readable text, so it's not really
opaque to them).

   The original definition of this authentication scheme failed to
   specify the character encoding scheme used to convert the user-pass
   into an octet sequence.

I think it would be more appropriate to say that it did not do so. That
wasn't a particular "failure", sending unlabeled 8bit (and 7bit) content
was normal at the time, in part because other system parts also did not
know or care about character encodings.

There should be an example for "no other authentication parameters are
defined -- unknown parameters MUST be ignored by recipients", otherwise
such extension points are too easily missed by implementers.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 06 Feb 2015 07:43:50 +0100

> misleading to me to describe it as such. (The Introduction has the same

I think it was.

> I think "updates" is the wrong word considering the document is intended

It does update the definition, no? Also: "Other documents updating RFC 
2617 are "Hypertext Transfer Protocol (HTTP/1.1): Authentication" 
([RFC7235], defining the authentication framework) and "HTTP Digest 
Access Authentication" ([DIGEST], updating the definition of the 
'"Digest" authentication scheme). Taken together, these three documents 
obsolete RFC 2617."

> "user-ID". I think the "user-ID" forms should be replaced by one of the

Good point. I'll have a look.

> in contrast to other schemes where it might not be opaque, but that is

It *is* the definition of the "Basic" scheme.

> the string, which often contains human readable text, so it's not really

That is true.

> know or care about character encodings.

It's a defect in that specification, no matter when it was written.

> such extension points are too easily missed by implementers.

<http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam2> shows that 
UAs seem to get at least this correct. I'll think about it.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 06 Feb 2015 08:58:37 +0100

>> misleading to me to describe it as such. (The Introduction has the same

I would take it to mean, in this context, "make difficult to decode",
while it's more likely used to "deal with special characters". In any
case, if the idea is to note that Base64 is easily reversible, say that
instead of "obfuscated".

>'"Digest" authentication scheme). Taken together, these three documents 

A better word would be "replaces".

>It's a defect in that specification, no matter when it was written.

Regardless, I think "did not" would be better than "failed to".
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 06 Feb 2015 15:23:20 +0000

Hi Bjoern,

On 05/02/2015 22:49, Bjoern Hoehrmann wrote:
  [snip]
> the string, which often contains human readable text, so it's not really
I think it is opaque to clients and servers, so they shouldn't try to 
parse it.
> know or care about character encodings.
I think the current text as specified is accurate, but I don't have a 
strong opinion.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 06 Feb 2015 16:35:21 +0100

>I think it is opaque to clients and servers, so they shouldn't try to 

A better phrase would be something like "free-form text".
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 06 Feb 2015 15:44:49 +0000

> A better phrase would be something like "free-form text".
Maybe something like "free-form text that MUST NOT be interpreted by 
clients"?
I would also like to keep "which can only be compared for equality with 
other realms on that server", as this is the important part.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 6 Feb 2015 11:41:57 -0500

> case, if the idea is to note that Base64 is easily reversible, say that

Obfuscation doesn't have to be hard to decode.  The point is that one
reason base64 was used was to make it so usernames and passwords don't
appear clearly in datastreams and log files.  If you know where to
find them, they're trivial to decode, of course.  But you can't just
scan the data and say, "Ah, look, there's a username and password."

Barry

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Feb 2015 18:33:16 +0100

> other realms on that server", as this is the important part.

Clarifying: the descriptions of "realm" in RFC 7235 and in this draft 
are exactly what RFC 2617 said. That being said, I'm ok with replacing 
"opaque string" by "free-form text" if that makes the participants over 
here happy.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Feb 2015 18:38:45 +0100

On 2015-02-06 07:43, Julian Reschke wrote:
> ...

OK. In my tests I don't see anybody getting *that* wrong, and the new 
text already is much clearer than RFC 2617 ever was.

Thus I don't think we need an example here. Also note that the real 
challenge (pun intended) is to parse multiple challenges properly; this 
is something many UAs *do* get wrong despite the prose in both RFC 2617 
and RFC 7235.

Best regards, Julian

---

From: Tony Hansen <[email-masked]>
Date: Tue, 10 Feb 2015 14:57:02 -0500

>> misleading to me to describe it as such. (The Introduction has the same

I thought the primary reason was so that the credentials would be able 
to contain arbitrary characters, potentially not otherwise representable 
within the surrounding protocol. It's an encoding scheme, not an 
obfuscation scheme.

     Tony Hansen

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 10 Feb 2015 22:00:44 +0100

>is something many UAs *do* get wrong despite the prose in both RFC 2617 

You cannot really test future implementations. I will survive without an
example, but I think it is a bad practise to omit examples demonstrating
extension mechanisms like this one.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Feb 2015 22:18:46 +0100

> within the surrounding protocol. It's an encoding scheme, not an

How is the intent actually relevant here?

Best regards, Julian

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 10 Feb 2015 16:36:18 -0500 (EST)

>    pairs, obfuscated by the use of Base64 encoding.

I forget if this was already mentioned, but "local-specific encoding" in
section 2 should probably use "locale" instead of "local".

-Ben

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 10 Feb 2015 22:46:19 +0100

>How is the intent actually relevant here?

According to the Abstract the intent is obfuscation. If the intent is
not relevant, then the Abstract should not draw attention to it. That
is pretty much why I brought this up.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 10 Feb 2015 22:54:30 +0100

>section 2 should probably use "locale" instead of "local".

The text in question is "In practice, most implementations chose either
a local-specific encoding such as ISO-8859-1 ([ISO-8859-1]), or UTF-8
([RFC3629])." Now ISO-8859-1 is not really specific to any "locale" and
I would rather not suggest that implementations typically derive the
encoding from `LC_CTYPE` or some such setting. 
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 10 Feb 2015 16:55:49 -0500 (EST)

> encoding from `LC_CTYPE` or some such setting.

Can you tell me then what exactly a "local-specific encoding" is?
Because the phrase is currently meaningless to me.

-Ben

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Feb 2015 22:59:33 +0100

> is pretty much why I brought this up.

I don't see anything about intent here. It's simply a statement of facts.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Feb 2015 23:03:37 +0100

> section 2 should probably use "locale" instead of "local".

No, it wasn't. Thanks!

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Feb 2015 23:06:13 +0100

> Because the phrase is currently meaningless to me.

An encoding that depends on the locale of the UA. I really don't know 
how to say it differently :-)

Best regards, Julian

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 12 Feb 2015 15:11:40 -0500

> I don't see anything about intent here. It's simply a statement of facts.

With no hat on -
I wouldn't call an encoding obfuscation either.  It looks like this text is
specific to this draft and was not in RFC2617.  It doesn't really help
anything IMO, could you instead just state that Base64 encoding is used?

Thanks,
Kathleen

>
> Best regards, Julian
>
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

-- 

Best regards,
Kathleen