The 'Basic' HTTP Authentication Scheme
draft-ietf-httpauth-basicauth-update-07

[Ballot comment]
Thank you to the HTTPAuth working group and the editor of this draft, Julian, for your work on this update.

A number of good suggestions were made in the SecDir review, however some would be better in a separate draft.  As a result, this draft incorporates several of the suggestions and there is an opportunity for future work to cover the additional security considerations.
http://www.ietf.org/mail-archive/web/secdir/current/msg05460.html

[Ballot discuss]
I'd like to make sure a few comments get addressed and text gets updated from the SecDir review.  This should get resolved quickly, but I wanted to make sure there was a placeholder so the comments don't go unaddressed.

The author has been very responsive, so I don't think that is an issue.
http://www.ietf.org/mail-archive/web/secdir/current/msg05460.html

[Ballot comment]
I support Pete's No Objection, and have found the responses unconvincing.  I would support this being raised as a DISCUSS rather than a comment, but I'll leave that to Pete.

[Ballot comment]
2: I'd at least like to hear an explanation about why this is unreasonable (if it is):

OLD
  Furthermore, a user-id containing a colon character is invalid, as
  recipients will split the user-pass at the first occurrence of a
  colon character.  Note that many user agents however will accept a
  colon in user-id, thereby producing a user-pass string that
  recipients will likely treat in a way not intended by the user.
NEW
  Furthermore, a user-id MUST NOT contain a colon character, as
  recipients will split the user-pass at the first occurrence of a
  colon character.  Many user agents will accept a colon in user-id,
  but this produces a user-pass string that recipients will likely
  treat in a way not intended by the user.
END

MUST NOT means that not using a colon is required for interoperation. Which is true. So I don't see why you don't come out and say that.

[Ballot comment]
The current text on the use of TLS is an OK start, but I would prefer if it were refactored so that the recommendation against Basic were general to HTTP and HTTPS.  Suggested:

"Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used except over a secure channel such as HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic authentication SHOULD NOT be used to protect sensitive or valuable information."

Likewise, it would be good to comment in the Security Considerations on the risk of leakage caused by sending an Authorization or Proxy-Authorization preemptively.  Something like:

"As discussed in Section [TODO] above, it is possible for a client to preemptively send a Basic authentication value in an Authorization or Proxy-Authorization header without first having received a challenge.  In such cases, the client does not know whether the resource to which it is sending the Basic authentication value is part of the realm that should receive that value, or even whether the resource requires authentication at all.  This mismatch can cause leakage of client passwords to unauthorized parties, so it is RECOMMENDED that preemptive transmission of Basic authentication values be disabled by default."

[Ballot discuss]
Section 2.2 seems like a significant departure from RFC 2617, which says nothing about the scope of authentication. 

(1) Did the WG discuss the compatibility impact of this change?  Although clients might send the Authorization header preemptively, they should still be prepared to get a 401 response back.

(2) Did the WG discuss the possibilities for leakage of credentials due to this change?  It's not hard to imagine scenarios where, say, "http://example.com/~user1" and "http://example.com/~user2" are controlled by different entities, and leakage between them would be harmful.

(3) At the very least, there needs to be (a) a mention of this change in Appendix A, and (b) a discussion of leakage through unsolicited Authorization headers in the Security Considerations.

[Ballot comment]
The current text on the use of TLS is an OK start, but I would prefer if it were refactored so that the recommendation against Basic were general to HTTP and HTTPS.

"Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used except over a secure channel such as HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic authentication SHOULD NOT be used to protect sensitive or valuable information."

[Ballot comment]
-- Section 1.1.1 --

  This specification uses the Augmented Backus-Naur Form (ABNF)
  notation of [RFC5234].

Where?
You do use 5234 as a reference to define CTL characters, so you need the reference.  But that sentence can go.

-- Section 5 --

  The entry for the "Basic" Authentication Scheme shall be updated with
  a pointer to this specification.

IANA might think this means that they should add this spec to the existing reference.  It'd be clearer to say it this way, and less likely to result in an error by IANA:

NEW
  The entry for the "Basic" Authentication Scheme shall be updated by
  replacing the reference with a pointer to this specification.
END

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpauth-basicauth-update-05.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has a question about this document:

We understand that, upon approval of this document, there is a single action which IANA must complete.

In the HTTP Authentication Schemes registry located at:

http://www.iana.org/assignments/http-authschemes/

The current reference for the "Basic" Authentication Scheme shall be updated with a pointer to this specification.

QUESTION: Are we replacing the current reference, or making this document an additional reference?

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

[Ballot comment]

This is a pretty crappy auth scheme, but this is a pretty
good update and fills a need, thanks for the latter:-)

- section 2: is it worth saying somewhere that you can't
really have >1 proxy-auth happening even if you transit >1
proxy?

- section 2, last para: I assume this is because client
and/or server behaviour varies for this? If so, maybe it'd
be good to give some guidance or add a reference (if a
good one exists). If there's some other reason, it'd be
good to say too.

- section 4: would it be worth adding some guidance that
re-use of e.g. entreprise login/SSO passwords for
proxy-auth is particularly dodgy as is not protected via
TLS?

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The 'Basic' HTTP Authentication Scheme) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol
Authentication WG (httpauth) to consider the following document:
- 'The 'Basic' HTTP Authentication Scheme'
  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
ietf@ietf.org mailing lists by 2015-02-19. Exceptionally, comments may be
sent to iesg@ietf.org 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.

Author is Julian Reschke. Kathleen Moriarty is the responsible Area
Director. Yoav Nir is the document shepherd.

Summary
  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.
 
Review and Consensus
  This document is (along with Digest) part of a set of documents that
  will collectively replace RFC 2617.  As such, for the most part it
  describes existing practice, with the addition of support for
  internationalization:
    o A new charset parameter with UTF-8 as the only valid value.
    o A normative reference to the precis draft for valid characters.
    o Appendix B with deployment considerations for co-existing with
      legacy implementations.
 
  With version -07 it is the consensus of the HTTP-Auth working group
  that this document is fit to be published as a standards-track RFC.
 
  There are a few implementations of this specification, and they have
  been tested and shown to interoperate with the large install base of
  web browsers and web servers.
     
Intellectual Property
  All authors have confirmed that they are not aware of any undisclosed
  IPR associated with this document. There have been no IPR disclosures.
 
Other Issues
  None