The 'Basic' HTTP Authentication Scheme
RFC 7617

Note: This ballot was opened for revision 06 and is now closed.

(Stephen Farrell) Yes

Comment (2015-02-16 for -06)
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

- 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

(Barry Leiba) Yes

Comment (2015-02-17 for -06)
-- Section 1.1.1 --

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

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:

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

(Kathleen Moriarty) (was Discuss, Yes) Yes

Comment (2015-03-03)
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.

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Richard Barnes) (was Discuss) No Objection

Comment (2015-02-18 for -06)
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."

(Benoit Claise) No Objection

Alissa Cooper No Objection

Spencer Dawkins No Objection

Comment (2015-02-17 for -06)
Nice job on a specification that is better than the technology it describes (echoing Stephen's ballot)!

(Adrian Farrel) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Ted Lemon) No Objection

Comment (2015-02-19 for -06)
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.

(Pete Resnick) No Objection

Comment (2015-02-18 for -06)
2: I'd at least like to hear an explanation about why this is unreasonable (if it is):

   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.
   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.

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.

(Martin Stiemerling) No Objection