draft-ietf-httpauth-basicauth-update-02.txt   draft-ietf-httpauth-basicauth-update-03.txt 
HTTPAuth Working Group J. Reschke HTTPAuth Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Obsoletes: 2617 (if approved) October 27, 2014 Obsoletes: 2617 (if approved) December 2, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: April 30, 2015 Expires: June 5, 2015
The 'Basic' HTTP Authentication Scheme The 'Basic' HTTP Authentication Scheme
draft-ietf-httpauth-basicauth-update-02 draft-ietf-httpauth-basicauth-update-03
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.2. The changes in this draft are summarized in Appendix C.4.
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 April 30, 2015. This Internet-Draft will expire on June 5, 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 2, line 35 skipping to change at page 3, line 12
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
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 . . . . . . . . . . . . . . . . . . . 8
3. Internationalization Considerations . . . . . . . . . . . . . 8 3. Internationalization Considerations . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from RFC 2617 . . . . . . . . . . . . . . . . 12 Appendix A. Changes from RFC 2617 . . . . . . . . . . . . . . . . 12
Appendix B. Deployment Considerations for the 'charset' Appendix B. Deployment Considerations for the 'charset'
Parameter . . . . . . . . . . . . . . . . . . . . . . 12 Parameter . . . . . . . . . . . . . . . . . . . . . . 12
B.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 12 B.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 12
B.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . 13 C.3. Since draft-ietf-httpauth-basicauth-update-01 . . . . . . 14
C.4. Since draft-ietf-httpauth-basicauth-update-02 . . . . . . 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 ([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 6, line 50 skipping to change at page 6, line 50
to indicate the character encoding scheme they expect the user agent to indicate the character encoding scheme they expect the user agent
to use when generating "user-pass" (a sequence of octets). This to use when generating "user-pass" (a sequence of octets). This
information is purely advisory. information is purely advisory.
The only allowed value is "UTF-8", to be matched case-insensitively The only allowed value is "UTF-8", to be matched case-insensitively
(see [RFC2978], Section 2.3). It indicates that the server expects (see [RFC2978], Section 2.3). It indicates that the server expects
character data to be converted to Unicode Normalization Form C character data to be converted to Unicode Normalization Form C
("NFC", see Section 3 of [RFC5198]) and to be encoded into octets ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets
using the UTF-8 character encoding scheme ([RFC3629]). using the UTF-8 character encoding scheme ([RFC3629]).
For the userid, recipients MUST support all characters defined in the
"UsernameCasePreserved" profile defined in in Section 3.3 of
[PRECIS], with the exception of the colon (":") character.
For the password, recipients MUST support all characters defined in
the "Password" profile defined in in Section 4.2 of [PRECIS].
Other values are reserved for future use. Other values are reserved for future use.
Note: The 'charset' is only defined on challenges, as "Basic" uses Note: The 'charset' is only defined on challenges, as "Basic" uses
a single token for credentials ('token68' syntax), thus the a single token for credentials ('token68' syntax), thus the
credentials syntax isn't extensible. credentials syntax isn't extensible.
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.
skipping to change at page 10, line 40 skipping to change at page 11, line 4
<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, Stephen Farrell, Bjoern Hoehrmann, Amos Jeffries, James Manger,
Kathleen Moriarty, Yaron Sheffer, Michael Sweet, and Martin Thomson Kathleen Moriarty, Yaron Sheffer, Michael Sweet, and Martin Thomson
for feedback on this 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-08 (work in progress), draft-ietf-httpauth-digest-08 (work in progress),
August 2014. August 2014.
[PRECIS] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized
Strings Representing Usernames and Passwords",
draft-ietf-precis-saslprepbis-11 (work in progress),
November 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, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
skipping to change at page 14, line 13 skipping to change at page 14, line 31
Minor improvements on Security Considerations. Minor improvements on Security Considerations.
Update Digest reference. Update Digest reference.
Rewrite scheme definition as algorithm rather than pseudo-ABNF. Rewrite scheme definition as algorithm rather than pseudo-ABNF.
Add a note about colons in userid. Add a note about colons in userid.
Attempt to explain authentication scopes. Attempt to explain authentication scopes.
C.4. Since draft-ietf-httpauth-basicauth-update-02
Reference draft-ietf-precis-saslprepbis for the set of characters
that need to be supported in userids and passwords.
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. 14 change blocks. 
13 lines changed or deleted 32 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/