draft-ietf-httpauth-basicauth-update-04.txt   draft-ietf-httpauth-basicauth-update-05.txt 
HTTPAuth Working Group J. Reschke HTTPAuth Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Obsoletes: 2617 (if approved) December 19, 2014 Obsoletes: 2617 (if approved) January 16, 2015
Intended status: Standards Track Intended status: Standards Track
Expires: June 22, 2015 Expires: July 20, 2015
The 'Basic' HTTP Authentication Scheme The 'Basic' HTTP Authentication Scheme
draft-ietf-httpauth-basicauth-update-04 draft-ietf-httpauth-basicauth-update-05
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
mailing list (http-auth@ietf.org), which is archived at <http:// mailing list (http-auth@ietf.org), which is archived at <http://
www.ietf.org/mail-archive/web/http-auth/current/maillist.html>. www.ietf.org/mail-archive/web/http-auth/current/maillist.html>.
XML versions, latest edits and the issues list for this document are XML versions, latest edits and the issues list for this document are
available from <http://greenbytes.de/tech/ available from <http://greenbytes.de/tech/
webdav/#draft-ietf-httpauth-basicauth-update>. webdav/#draft-ietf-httpauth-basicauth-update>.
The changes in this draft are summarized in Appendix C.5. The changes in this draft are summarized in Appendix C.6.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 22, 2015. This Internet-Draft will expire on July 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 4 skipping to change at page 3, line 33
B.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 12 B.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 12
B.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 13 B.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 13
B.3. Why not simply switch the default encoding to UTF-8? . . . 13 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) . . . . . . . . . . . . . . . . . . . . 13 publication) . . . . . . . . . . . . . . . . . . . . 13
C.1. Since RFC 2617 . . . . . . . . . . . . . . . . . . . . . . 13 C.1. Since RFC 2617 . . . . . . . . . . . . . . . . . . . . . . 13
C.2. Since draft-ietf-httpauth-basicauth-update-00 . . . . . . 13 C.2. Since draft-ietf-httpauth-basicauth-update-00 . . . . . . 13
C.3. Since draft-ietf-httpauth-basicauth-update-01 . . . . . . 14 C.3. Since draft-ietf-httpauth-basicauth-update-01 . . . . . . 14
C.4. Since draft-ietf-httpauth-basicauth-update-02 . . . . . . 14 C.4. Since draft-ietf-httpauth-basicauth-update-02 . . . . . . 14
C.5. Since draft-ietf-httpauth-basicauth-update-03 . . . . . . 14 C.5. Since draft-ietf-httpauth-basicauth-update-03 . . . . . . 14
C.6. Since draft-ietf-httpauth-basicauth-update-04 . . . . . . 14
1. Introduction 1. Introduction
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 (HTTP authentication pairs, obfuscated by the use of Base64 encoding (HTTP authentication
schemes are defined in [RFC7235]). schemes are defined in [RFC7235]).
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
skipping to change at page 8, line 9 skipping to change at page 8, line 9
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
Given the absolute URI ([RFC3986], Section 4.3) of an authenticated Given the absolute URI ([RFC3986], Section 4.3) of an authenticated
request, the authentication scope of that request is obtained by request, the authentication scope of that request is obtained by
removing all characters after the last slash ("/") character. A removing all characters after the last slash ("/") character of the
client SHOULD assume that resources identified by URIs with a prefix- path component ("hier_part", see [RFC3986], Section 3). A client
match of the authentication scope are also within the protection SHOULD assume that resources identified by URIs with a prefix-match
space specified by the realm value of the that authenticated request. 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: For example, given an authenticated request to:
skipping to change at page 10, line 45 skipping to change at page 10, line 46
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 and other We also thank the members of the HTTPAuth Working Group and other
reviewers, namely Stephen Farrell, Bjoern Hoehrmann, Kari Hurtta, reviewers, namely Stephen Farrell, Bjoern Hoehrmann, Kari Hurtta,
Amos Jeffries, Benjamin Kaduk, James Manger, Kathleen Moriarty, Yaron Amos Jeffries, Benjamin Kaduk, Michael Koeller, 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
[PRECIS] Saint-Andre, P. and A. Melnikov, "Preparation, [PRECIS] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Enforcement, and Comparison of Internationalized
Strings Representing Usernames and Passwords", Strings Representing Usernames and Passwords",
draft-ietf-precis-saslprepbis-12 (work in progress), draft-ietf-precis-saslprepbis-12 (work in progress),
December 2014. December 2014.
skipping to change at page 11, line 50 skipping to change at page 11, line 50
September 2011. September 2011.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", Transfer Protocol (HTTP/1.1): Authentication",
RFC 7235, June 2014. RFC 7235, June 2014.
7.2. Informative References 7.2. Informative 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-09 (work in progress), draft-ietf-httpauth-digest-10 (work in progress),
December 2014. January 2015.
[ISO-8859-1] International Organization for Standardization, [ISO-8859-1] International Organization for Standardization,
"Information technology -- 8-bit single-byte coded "Information technology -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. graphic character sets -- Part 1: Latin alphabet No.
1", ISO/IEC 8859-1:1998, 1998. 1", ISO/IEC 8859-1:1998, 1998.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
S., Leach, P., Luotonen, A., and L. Stewart, "HTTP S., Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999. Authentication", RFC 2617, June 1999.
skipping to change at page 15, line 5 skipping to change at page 14, line 48
Update reference for draft-ietf-precis-saslprepbis (which renames Update reference for draft-ietf-precis-saslprepbis (which renames
"Password" to "OpaqueString"). "Password" to "OpaqueString").
Mention HTTPS as enhancement for securing the transmission of Mention HTTPS as enhancement for securing the transmission of
credentials. credentials.
Update DIGEST reference and change it to informative. Update DIGEST reference and change it to informative.
Use RFC 20 as reference for ASCII. Use RFC 20 as reference for ASCII.
C.6. Since draft-ietf-httpauth-basicauth-update-04
Fixed definition of authentication scope. Updated DIGEST reference.
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
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 11 change blocks. 
15 lines changed or deleted 21 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/