draft-ietf-httpauth-basicauth-update-01.txt   draft-ietf-httpauth-basicauth-update-02.txt 
HTTPAuth Working Group J. Reschke HTTPAuth Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Obsoletes: 2617 (if approved) July 4, 2014 Obsoletes: 2617 (if approved) October 27, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: January 5, 2015 Expires: April 30, 2015
The 'Basic' HTTP Authentication Scheme The 'Basic' HTTP Authentication Scheme
draft-ietf-httpauth-basicauth-update-01 draft-ietf-httpauth-basicauth-update-02
Abstract Abstract
This document defines the "Basic" Hypertext Transfer Protocol (HTTP) This document defines the "Basic" Hypertext Transfer Protocol (HTTP)
Authentication Scheme, which transmits credentials as userid/password Authentication Scheme, which transmits credentials as userid/password
pairs, obfuscated by the use of Base64 encoding. pairs, obfuscated by the use of Base64 encoding.
Editorial Note (To be removed by RFC Editor before publication) Editorial Note (To be removed by RFC Editor before publication)
Discussion of this draft takes place on the HTTPAuth working group Discussion of this draft takes place on the HTTPAuth working group
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 13 skipping to change at page 2, line 36
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
1.1.1. Syntax Notation . . . . . . . . . . . . . . . . . . . 4 1.1.1. Syntax Notation . . . . . . . . . . . . . . . . . . . 4
2. The 'Basic' Authentication Scheme . . . . . . . . . . . . . . 4 2. The 'Basic' Authentication Scheme . . . . . . . . . . . . . . 4
2.1. The 'charset' auth-param . . . . . . . . . . . . . . . . . 6 2.1. The 'charset' auth-param . . . . . . . . . . . . . . . . . 6
2.2. Re-using Credentials . . . . . . . . . . . . . . . . . . . 7 2.2. Re-using Credentials . . . . . . . . . . . . . . . . . . . 7
3. Internationalization Considerations . . . . . . . . . . . . . 7 3. Internationalization Considerations . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Changes from RFC 2617 . . . . . . . . . . . . . . . . 11 Appendix A. Changes from RFC 2617 . . . . . . . . . . . . . . . . 12
Appendix B. Deployment Considerations for the 'charset' Appendix B. Deployment Considerations for the 'charset'
Parameter . . . . . . . . . . . . . . . . . . . . . . 11 Parameter . . . . . . . . . . . . . . . . . . . . . . 12
B.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 11 B.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 12
B.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 11 B.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 12
B.3. Why not simply switch the default encoding to UTF-8? . . . 12 B.3. Why not simply switch the default encoding to UTF-8? . . . 13
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 12
C.1. Since RFC 2617 . . . . . . . . . . . . . . . . . . . . . . 12
C.2. Since draft-ietf-httpauth-basicauth-update-00 . . . . . . 12
Appendix D. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . 13 publication) . . . . . . . . . . . . . . . . . . . . 13
D.1. colon . . . . . . . . . . . . . . . . . . . . . . . . . . 13 C.1. Since RFC 2617 . . . . . . . . . . . . . . . . . . . . . . 13
D.2. depth . . . . . . . . . . . . . . . . . . . . . . . . . . 13 C.2. Since draft-ietf-httpauth-basicauth-update-00 . . . . . . 13
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 C.3. Since draft-ietf-httpauth-basicauth-update-01 . . . . . . 13
1. Introduction 1. Introduction
This document defines the "Basic" Hypertext Transfer Protocol (HTTP) This document defines the "Basic" Hypertext Transfer Protocol (HTTP)
Authentication Scheme ([RFC7235]), which transmits credentials as Authentication Scheme ([RFC7235]), which transmits credentials as
userid/password pairs, obfuscated by the use of Base64 encoding. userid/password pairs, obfuscated by the use of Base64 encoding.
This scheme is not considered to be a secure method of user This scheme is not considered to be a secure method of user
authentication unless used in conjunction with some external secure authentication unless used in conjunction with some external secure
system such as TLS (Transport Layer Security, [RFC5246]), as the user system such as TLS (Transport Layer Security, [RFC5246]), as the user
skipping to change at page 5, line 47 skipping to change at page 5, line 47
Date: Mon, 04 Feb 2014 16:50:53 GMT Date: Mon, 04 Feb 2014 16:50:53 GMT
WWW-Authenticate: Basic realm="WallyWorld" WWW-Authenticate: Basic realm="WallyWorld"
...where "WallyWorld" is the string assigned by the server to ...where "WallyWorld" is the string assigned by the server to
identify the protection space. identify the protection space.
A proxy can respond with a similar challenge using the 407 (Proxy A proxy can respond with a similar challenge using the 407 (Proxy
Authentication Required) status code ([RFC7235], Section 3.2) and the Authentication Required) status code ([RFC7235], Section 3.2) and the
Proxy-Authenticate header field ([RFC7235], Section 4.3). Proxy-Authenticate header field ([RFC7235], Section 4.3).
To receive authorization, the client sends the userid and password, To receive authorization, the client
separated by a single colon (":") character, within a base64 encoded
string as the credentials value ([RFC4648], Section 4).
basic-credentials = base64-user-pass 1. obtains userid and password from the user,
base64-user-pass = <base64 encoded user-pass> 2. constructs the user-pass by concatenating userid, a single colon
; [RFC4648] encoding of user-pass, (":") character, and the password,
; except not limited to 76 char/line
user-pass = userid ":" password 3. encodes the user-pass into an octet sequence (see below for a
userid = *<TEXT excluding ":"> discussion of character encoding schemes),
password = *TEXT
In this definition, userid and password represent sequences of 4. and obtains the basic-credentials by encoding this octet sequence
octets, not characters. The original definition of this using base64 ([RFC4648], Section 4) into a sequence of US-ASCII
authentication scheme did not define which character encoding scheme characters ([USASCII]).
is used to convert from characters (such as obtained from a user
interface), resulting in interoperability problems for all characters The original definition of this authentication scheme failed to
outside the US-ASCII character repertoire ([USASCII]). Section 2.1 specify the character encoding scheme used to convert the user-pass
defines a new authentication parameter that can be used by servers to into an octet sequence. In practice, most implementations chose
indicate the encoding scheme they expect to be used. either a local-specific encoding such as ISO-8859-1 ([ISO-8859-1]),
or UTF-8 ([RFC3629]). For backwards compatibility reasons, this
specification continues to leave the default encoding undefined, as
long as it is compatible to US-ASCII (mapping any US-ASCII character
to a single octet matching the US-ASCII character code).
Userid and password MUST NOT contain any control characters (see
"CTL" in Appendix B.1 of [RFC5234]).
Furthermore, a userid containing a colon character is invalid, as
recipients will split the user-pass at the first occurence of a colon
character. Note that many user agents however will accept a colon in
userid, thereby producing a user-pass string that recipients will
likely treat in a way not intended by the user.
If the user agent wishes to send the userid "Aladdin" and password If the user agent wishes to send the userid "Aladdin" and password
"open sesame", it would use the following header field: "open sesame", it would use the following header field:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
2.1. The 'charset' auth-param 2.1. The 'charset' auth-param
In challenges, servers can use the "charset" authentication parameter In challenges, servers can use the "charset" authentication parameter
to indicate the character encoding scheme they expect the user agent to indicate the character encoding scheme they expect the user agent
skipping to change at page 7, line 9 skipping to change at page 7, line 18
Note: The name 'charset' has been chosen for consistency with Note: The name 'charset' has been chosen for consistency with
Section 2.1.1 of [RFC2831]. A better name would have been Section 2.1.1 of [RFC2831]. A better name would have been
'accept-charset', as it is not about the message it appears in, 'accept-charset', as it is not about the message it appears in,
but the server's expectation. but the server's expectation.
In the example below, the server prompts for authentication in the In the example below, the server prompts for authentication in the
"foo" realm, using Basic authentication, with a preference for the "foo" realm, using Basic authentication, with a preference for the
UTF-8 character encoding scheme: UTF-8 character encoding scheme:
WWW-Authenticate: Basic realm="foo", charset="UTF-8" WWW-Authenticate: Basic realm="foo", charset="UTF-8"
Note that the parameter value can be either a token or a quoted Note that the parameter value can be either a token or a quoted
string; in this case the server chose to use the quoted-string string; in this case the server chose to use the quoted-string
notation. notation.
The user's name is "test", and the password is the string "123" The user's name is "test", and the password is the string "123"
followed by the Unicode character U+00A3 (POUND SIGN). Using the followed by the Unicode character U+00A3 (POUND SIGN). Using the
character encoding scheme UTF-8, the user-pass becomes: character encoding scheme UTF-8, the user-pass becomes:
't' 'e' 's' 't' ':' '1' '2' '3' pound 't' 'e' 's' 't' ':' '1' '2' '3' pound
74 65 73 74 3A 31 32 33 C2 A3 74 65 73 74 3A 31 32 33 C2 A3
Encoding this octet sequence in Base64 ([RFC4648], Section 4) yields: Encoding this octet sequence in Base64 ([RFC4648], Section 4) yields:
dGVzdDoxMjPCow== dGVzdDoxMjPCow==
Thus the Authorization header field would be: Thus the Authorization header field would be:
Authorization: Basic dGVzdDoxMjPCow== Authorization: Basic dGVzdDoxMjPCow==
Or, for proxy authentication: Or, for proxy authentication:
Proxy-Authorization: Basic dGVzdDoxMjPCow== Proxy-Authorization: Basic dGVzdDoxMjPCow==
2.2. Re-using Credentials 2.2. Re-using Credentials
A client SHOULD assume that all paths at or deeper than the depth of Given the absolute URI ([RFC3986], Section 4.3) of an authenticated
the last symbolic element in the path field of the Request-URI also request, the authentication scope of that request is obtained by
are within the protection space specified by the realm value of the removing all characters after the last slash ("/") character. A
current challenge. client SHOULD assume that resources identified by URIs with a prefix-
match of the authentication scope are also within the protection
space specified by the realm value of the that authenticated request.
A client MAY preemptively send the corresponding Authorization header A client MAY preemptively send the corresponding Authorization header
field with requests for resources in that space without receipt of field with requests for resources in that space without receipt of
another challenge from the server. Similarly, when a client sends a another challenge from the server. Similarly, when a client sends a
request to a proxy, it may reuse a userid and password in the Proxy- request to a proxy, it may reuse a userid and password in the Proxy-
Authorization header field without receiving another challenge from Authorization header field without receiving another challenge from
the proxy server. the proxy server.
For example, given an authenticated request to:
http://example.com/docs/index.html
...requests to the URIs below could use the known credentials:
http://example.com/docs/
http://example.com/docs/test.doc
http://example.com/docs/?page=1
...while the URIs
http://example.com/other/
https://example.com/docs/
would be considered to be outside the authentication scope.
Note that a URI can be part of multiple authentication scopes (such
as "http://example.com/" and "http://example.com/docs/"). This
specification does not define which of these should be treated with
higher priority.
3. Internationalization Considerations 3. Internationalization Considerations
User names or passwords containing characters outside the US-ASCII User names or passwords containing characters outside the US-ASCII
character repertoire will cause interoperability issues, unless both character repertoire will cause interoperability issues, unless both
communication partners agree on what character encoding scheme is to communication partners agree on what character encoding scheme is to
be used. Senders can use the new 'charset' parameter (Section 2.1) be used. Senders can use the new 'charset' parameter (Section 2.1)
to indicate a preference of "UTF-8", increasing the probability that to indicate a preference of "UTF-8", increasing the probability that
clients will switch to that encoding. clients will switch to that encoding.
The "realm" parameter carries data that can be considered textual, The "realm" parameter carries data that can be considered textual,
skipping to change at page 8, line 49 skipping to change at page 9, line 34
password to avoid the task of maintaining multiple passwords. password to avoid the task of maintaining multiple passwords.
If a server permits users to select their own passwords, then the If a server permits users to select their own passwords, then the
threat is not only unauthorized access to documents on the server but threat is not only unauthorized access to documents on the server but
also unauthorized access to any other resources on other systems that also unauthorized access to any other resources on other systems that
the user protects with the same password. Furthermore, in the the user protects with the same password. Furthermore, in the
server's password database, many of the passwords may also be users' server's password database, many of the passwords may also be users'
passwords for other sites. The owner or administrator of such a passwords for other sites. The owner or administrator of such a
system could therefore expose all users of the system to the risk of system could therefore expose all users of the system to the risk of
unauthorized access to all those sites if this information is not unauthorized access to all those sites if this information is not
maintained in a secure fashion. maintained in a secure fashion. This raises both security and
privacy concerns ([RFC6973]). If the same username and password
combination is in use to access other accounts, such as an email or
health portal account, personal information could be exposed.
Basic Authentication is also vulnerable to spoofing by counterfeit Basic Authentication is also vulnerable to spoofing by counterfeit
servers. If a user can be led to believe that he is connecting to a servers. If a user can be led to believe that he is connecting to a
host containing information protected by Basic authentication when, host containing information protected by Basic authentication when,
in fact, he is connecting to a hostile server or gateway, then the in fact, he is connecting to a hostile server or gateway, then the
attacker can request a password, store it for later use, and feign an attacker can request a password, store it for later use, and feign an
error. This type of attack is not possible with Digest error. This type of attack is not possible with Digest
Authentication. Server implementers SHOULD guard against the Authentication. Server implementers SHOULD guard against the
possibility of this sort of counterfeiting by gateways or CGI possibility of this sort of counterfeiting by gateways or CGI
scripts. In particular it is very dangerous for a server to simply scripts. In particular it is very dangerous for a server to simply
skipping to change at page 9, line 47 skipping to change at page 10, line 35
acknowledgements. acknowledgements.
The internationalization problem with respect to the character The internationalization problem with respect to the character
encoding scheme used for user-pass has been reported as a Mozilla bug encoding scheme used for user-pass has been reported as a Mozilla bug
back in the year 2000 (see back in the year 2000 (see
<https://bugzilla.mozilla.org/show_bug.cgi?id=41489> and also the <https://bugzilla.mozilla.org/show_bug.cgi?id=41489> and also the
more recent <https://bugzilla.mozilla.org/show_bug.cgi?id=656213>). more recent <https://bugzilla.mozilla.org/show_bug.cgi?id=656213>).
It was Andrew Clover's idea to address it using a new auth-param. It was Andrew Clover's idea to address it using a new auth-param.
We also thank the members of the HTTPAuth Working Group, namely We also thank the members of the HTTPAuth Working Group, namely
Stephen Farrell, Bjoern Hoehrmann, Amos Jeffries, James Manger, Yaron Stephen Farrell, Bjoern Hoehrmann, Amos Jeffries, James Manger,
Sheffer, Michael Sweet, and Martin Thomson for feedback on this Kathleen Moriarty, Yaron Sheffer, Michael Sweet, and Martin Thomson
revision. for feedback on this revision.
7. References 7. References
7.1. Normative References 7.1. Normative References
[DIGEST] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP [DIGEST] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", Digest Access Authentication",
draft-ietf-httpauth-digest-07 (work in progress), draft-ietf-httpauth-digest-08 (work in progress),
April 2014. August 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000. Procedures", BCP 19, RFC 2978, October 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for
Network Interchange", RFC 5198, March 2008. Network Interchange", RFC 5198, March 2008.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008. January 2008.
skipping to change at page 11, line 13 skipping to change at page 12, line 5
Authentication: Basic and Digest Access Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999. Authentication", RFC 2617, June 1999.
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication
as a SASL Mechanism", RFC 2831, May 2000. as a SASL Mechanism", RFC 2831, May 2000.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246, Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008. August 2008.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
July 2013.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content", Transfer Protocol (HTTP/1.1): Semantics and Content",
RFC 7231, June 2014. RFC 7231, June 2014.
Appendix A. Changes from RFC 2617 Appendix A. Changes from RFC 2617
The scheme definition has been rewritten to be consistent with newer The scheme definition has been rewritten to be consistent with newer
specifications such as [RFC7235]. specifications such as [RFC7235].
The new authentication parameter "charset" has been added. It is The new authentication parameter "charset" has been added. It is
skipping to change at page 13, line 5 skipping to change at page 13, line 49
Rewrote text about authentication parameters and their extensibility. Rewrote text about authentication parameters and their extensibility.
Pulled in the definition of the "charset" parameter. Pulled in the definition of the "charset" parameter.
Removed a misleading statement about userids potentially being case- Removed a misleading statement about userids potentially being case-
sensitive, as the same is true for passwords. sensitive, as the same is true for passwords.
Added TODOs with respect to path matching, and colons in userids. Added TODOs with respect to path matching, and colons in userids.
Appendix D. Open issues (to be removed by RFC Editor prior to C.3. Since draft-ietf-httpauth-basicauth-update-01
publication)
D.1. colon
In Section 2:
Type: change
julian.reschke@greenbytes.de (2014-07-03): Clients happily accept
colons in userids and just go on with the concatentation. Do we need
to say something about this?
D.2. depth
In Section 2.2:
Type: change
julian.reschke@greenbytes.de (2014-07-03): This needs to be rewritten Minor improvements on Security Considerations.
in terms of effective request URI and terminology from RFC 3986.
Index Update Digest reference.
B Rewrite scheme definition as algorithm rather than pseudo-ABNF.
base64-user-pass 6
basic-credentials 6
P Add a note about colons in userid.
password 6
U Attempt to explain authentication scopes.
user-pass 6
userid 6
Author's Address Author's Address
Julian F. Reschke Julian F. Reschke
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
 End of changes. 33 change blocks. 
83 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/