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

From: [email-masked]
Date: Tue, 02 Dec 2014 03:16:08 -0800

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           : The 'Basic' HTTP Authentication Scheme
        Author          : Julian F. Reschke
	Filename        : draft-ietf-httpauth-basicauth-update-03.txt
	Pages           : 14
	Date            : 2014-12-02

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/

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

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

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 2 Dec 2014 13:19:39 +0200

Thank you, Julian

This begins a 2-week WGLC for this document.

Please take the time to read through and post any comments to the list.

Cheers

Matt & Yoav

> On Dec 2, 2014, at 1:16 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

---

From: Michael Sweet <[email-masked]>
Date: Wed, 03 Dec 2014 11:14:58 -0500

My comments:

- Section 2 makes the "charset" parameter OPTIONAL. I'm wondering if this should be RECOMMENDED in order to encourage adoption of UTF-8 usernames and passwords since that solves common deployment and interop issues.

- Section 2.1 uses "can" (servers can use the "charset" authentication parameter...) If "charset" is OPTIONAL in section 2, I think this should be "MAY" (servers MAY use ...), and if RECOMMENDED this should be "SHOULD" (servers SHOULD use ...), although then you'd want to clarify that it is a SHOULD when using UTF-8...

- Section 4 doesn't talk about using TLS/HTTPS, which is a common method for providing some level of protection for the cleartext password in transit.  It might be sufficient to simply expand on "enhancements", e.g.:

   Because Basic authentication involves the cleartext transmission of
   passwords it SHOULD NOT be used (without enhancements such as HTTPS [RFC2818])
   to protect sensitive or valuable information.

  with a corresponding informative reference to RFC 2818 in section 7.2.  That at least provides a pointer without endorsing Basic + HTTPS as a "secure" combination...

> On Dec 2, 2014, at 6:19 AM, Yoav Nir <[email-masked]> wrote:
> 
> Thank you, Julian
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Dec 2014 17:24:56 +0100

> - Section 2 makes the "charset" parameter OPTIONAL. I'm wondering if this should be RECOMMENDED in order to encourage adoption of UTF-8 usernames and passwords since that solves common deployment a…

This being an optional feature has been the intention since we started.

If a server has a use for non-ASCII characters, it has sufficient 
motivation to use it. In the other case, no amount of spec language will 
affect what it does.

> - Section 2.1 uses "can" (servers can use the "charset" authentication parameter...) If "charset" is OPTIONAL in section 2, I think this should be "MAY" (servers MAY use ...), and if RECOMMENDED th…

How is "MAY" better than "can"? This is a statement of fact, not an 
interoperability requirement.

>    with a corresponding informative reference to RFC 2818 in section 7.2.  That at least provides a pointer without endorsing Basic + HTTPS as a "secure" combination...

That sounds like a good addition.

Best regards, Julian

---

From: Michael Sweet <[email-masked]>
Date: Wed, 03 Dec 2014 12:12:31 -0500

Julian,

> On Dec 3, 2014, at 11:24 AM, Julian Reschke <[email-masked]> wrote:
> 
> If a server has a use for non-ASCII characters, it has sufficient motivation to use it. In the other case, no amount of spec language will affect what it does.

OK, I was under the impression that one of the motivations for updating RFC 2617 was to address I18N issues.

> How is "MAY" better than "can"? This is a statement of fact, not an interoperability requirement.

Typically MAY is used in conjunction with OPTIONAL; from RFC 2119:

   5. MAY  This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

Since the purpose is to indicate that servers will include the "charset" parameter to tell the client about the expected character encoding, something that is present specifically for interoperability with Unicode user IDs and passwords, I think that "MAY" is the right word to use here instead of its non-conformance synonym "can".

Alternately just drop "can" with no replacement, e.g.:

   In challenges, servers use the "charset" authentication parameter
   to indicate the character encoding scheme they expect the user agent
   to use when generating "user-pass" (a sequence of octets).  This
   information is purely advisory.

That avoids the whole consistency issues and makes it clear that the "charset" parameter is the one and only way of specifying the character encoding of the userid and password.

(I realize I'm being anal about this, but having spent the better part of 20 years writing/editing/reviewing technical documents and standards, I have seen a number of truly shocking misinterpretations of otherwise clear text...  "Weasel words" like "can" are often problematic...)

---

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Dec 2014 18:21:14 +0100

> OK, I was under the impression that one of the motivations for updating RFC 2617 was to address I18N issues.

It is. But we can't make new normative requirements that will break 
existing implementations.

> Since the purpose is to indicate that servers will include the "charset" parameter to tell the client about the expected character encoding, something that is present specifically for interoperabil…

I disagree.

> That avoids the whole consistency issues and makes it clear that the "charset" parameter is the one and only way of specifying the character encoding of the userid and password.

But that makes it sound as if servers have to use the parameter, which 
is not true.

> ...

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Dec 2014 21:05:17 +0200

> On Dec 3, 2014, at 7:21 PM, Julian Reschke <[email-masked]> wrote:
> 
> It is. But we can't make new normative requirements that will break existing implementations.

[no hats]

Sure we can. This is a new specification. Some implementations will keep implementing the old, obsolete spec. This is no different from clients and servers continuing to use TLS 1.0 and 1.1 now that 1.2 has obsoleted them.

The charset parameter can be an indicator that the server is implementing the new spec rather than the old. Why not go all the way to MUST?

Yoav

---

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Dec 2014 20:17:07 +0100

> Sure we can. This is a new specification. Some implementations will keep implementing the old, obsolete spec. This is no different from clients and servers continuing to use TLS 1.0 and 1.1 now tha…

It's certainly very different from the way httpbis has revised RFC 2616, 
and my assumption was that we're doing the same thing here.

> The charset parameter can be an indicator that the server is implementing the new spec rather than the old. Why not go all the way to MUST?

Because it doesn't make any sense and will not be implemented?

Can we please stick to a realistic plan instead of coming up with 
something people will ignore? Do you remember RFC 2965?

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Dec 2014 21:43:11 +0200

> On Dec 3, 2014, at 9:17 PM, Julian Reschke <[email-masked]> wrote:
> 
> It's certainly very different from the way httpbis has revised RFC 2616, and my assumption was that we're doing the same thing here.

So for those servers that don’t send the charset parameter, what is changed from RFC 2616?

---

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Dec 2014 21:40:45 +0100

> So for those servers that don’t send the charset parameter, what is changed from RFC 2616?

Nothing. But I heard you say to require to send the charset parameter.

Best regards, Julian

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 5 Dec 2014 12:21:57 -0500 (EST)

> Please take the time to read through and post any comments to the list.

My apologies if this has already been covered, but the abstract includes
the phrase "obfuscated by the use of Base64 encoding" (the introduction
includes similar content).  It looks like this was introduced in the -01,
and the on-list discussion of the -00 didn't really talk about it -- there
was a note from Bjoern that the abstract "could use another sentence
stating what the `Basic` scheme is", but the word "obfuscate" did not
appear.  As such, I thought I would mention it now -- it's not really
clear that Base64 encoding counts as obfuscation in this context, where
the HTTP headers make it very clear that the userid/password are being
conveyed.

I think the submission checklist wants the abstract (and introduction?) to
explicitly mention when an RFC is being updated or obsoleted.  Relatedly,
the first clause of the introduction says that this document defines
"basic", but the citation to RFC 7235 could be read as if it is a citation
for "basic" (as opposed to HTTP Authentication); perhaps this is better:

% This document defines "Basic" as a Hypertext Transfer Protocol (HTTP)
% Authentication Scheme ([RFC7235]), which transmits credentials as
% Base64-encoded userid/password pairs.

Section 3 says that "Senders can use the new 'charset' parameter", but it
seems that only servers can do so.  Was this intended to say "Servers"
instead of "Senders"?

Section for says that the transmission of the password is "essentially
cleartext", whereas section 1 just says that it is "cleartext".  Which is
it?

Grammar nits:

In section 2:

% 1.  obtains userid and password from the user,

I would add the definite article "the" before "userid" to match the other
items.

In the paragraph following that list, I would s/compatible to/compatible
with/.

In the paragraph following that paragraph, you could add "The" at the
beginning to avoid starting the sentence with the identifier "userid" (and
the ensuing debate about whether to capitalize the initial letter).

-Ben

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 05 Dec 2014 10:25:32 -0700

> the HTTP headers make it very clear that the userid/password are being

That struck me as odd, too. I'd suggest "encoded in Base 64" instead.

Peter

---

From: Julian Reschke <[email-masked]>
Date: Fri, 05 Dec 2014 19:52:17 +0100

> the HTTP headers make it very clear that the userid/password are being

I think that "obfuscate" pretty much nails it.

> explicitly mention when an RFC is being updated or obsoleted.  Relatedly,

I've heart that before, but I also heard the opposite at some other 
point. I'll wait for the IESG feedback on this.

> % Base64-encoded userid/password pairs.

Concern understood, but now the "which" applies to the wrong term.

I'll try to address this differently.

> seems that only servers can do so.  Was this intended to say "Servers"

I believe my intent was to include proxies, but then, "server" includes 
proxies too.

> cleartext", whereas section 1 just says that it is "cleartext".  Which is

I'll remove the "essentially" from the Security Considerations.

> I would add the definite article "the" before "userid" to match the other

ack.

> In the paragraph following that list, I would s/compatible to/compatible

ack.

> the ensuing debate about whether to capitalize the initial letter).

Thanks a lot for the feedback!

-> <http://trac.tools.ietf.org/wg/httpauth/trac/changeset/89>

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 05 Dec 2014 19:55:28 +0100

> That struck me as odd, too. I'd suggest "encoded in Base 64" instead.

What do others think?

Would saying "slightly obfuscated" make things more bearable?

(If we change it in the abstract we'll need to change the 2nd occurence 
as well, no)

Best regards, Julian

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 5 Dec 2014 17:08:37 -0500 (EST)

> I think that "obfuscate" pretty much nails it.

I would hope you think so, given that you wrote it :)

I do not have strong feelings, myself, but it does seem like something
that should at least be discussed on the list, since there is some reason
to believe that people with strong opinions do exist.

> I've heart that before, but I also heard the opposite at some other point.
> I'll wait for the IESG feedback on this.

Sure, no particular hurry.

> I'll try to address this differently.

Thanks -- I was not super-happy with my new text, either.

-Ben

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 Dec 2014 23:08:14 +0100

> Please take the time to read through and post any comments to the list.

...and the WGLC ended yesterday.

My current edits are over here:

<http://greenbytes.de/tech/webdav/draft-ietf-httpauth-basicauth-update-latest-from-previous.diff.html>

Those are all editorial, mostly based on WGLC feedback (thanks).

In the LC, there were also requests to change prose to use more BCP14 
terms, and also to make the use of the charset parameter required; I did 
not make any changes with respect to this, because:

- I believe our use of BCP14 terms is consistent with the HTTP specs, and

- The whole premise of introducing the charset parameter was to leave 
existing conforming implementations conforming; thus it was always meant 
to be truly OPTIONAL.

Finally, while reviewing DIGEST, I noticed that there are security 
considerations in RFC 2617 that should have been in RFC 7235, namely:

  <http://greenbytes.de/tech/webdav/rfc2617.html#rfc.section.4.6>

and

  <http://greenbytes.de/tech/webdav/rfc2617.html#rfc.section.4.8>

I believe the best way to address this is to track this as a TODO for 
RFC7235bis (which I intend to get to in due time).

Chairs: should I submit what I currently have, or are more changes needed?

Best regards, Julian