draft-ietf-httpauth-basicauth-update-05.txt | draft-ietf-httpauth-basicauth-update-latest.txt | |||
---|---|---|---|---|
HTTPAuth Working Group J. Reschke | HTTPAuth Working Group J. Reschke | |||
Internet-Draft greenbytes | Internet-Draft greenbytes | |||
Obsoletes: 2617 (if approved) January 16, 2015 | Obsoletes: 2617 (if approved) February 7, 2024 | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: July 20, 2015 | Expires: August 10, 2024 | |||
The 'Basic' HTTP Authentication Scheme | The 'Basic' HTTP Authentication Scheme | |||
draft-ietf-httpauth-basicauth-update-05 | draft-ietf-httpauth-basicauth-update-latest | |||
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 user-id/ | |||
pairs, obfuscated by the use of Base64 encoding. | password pairs, encoded using Base64. | |||
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 | |||
www.ietf.org/mail-archive/web/http-auth/current/maillist.html>. | <http://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- | |||
webdav/#draft-ietf-httpauth-basicauth-update>. | httpauth-basicauth-update>. | |||
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 https://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 July 20, 2015. | This Internet-Draft will expire on August 10, 2024. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2024 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 | (https://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 | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
This document may contain material from IETF Documents or IETF | This document may contain material from IETF Documents or IETF | |||
Contributions published or made publicly available before November | Contributions published or made publicly available before November | |||
10, 2008. The person(s) controlling the copyright in some of this | 10, 2008. The person(s) controlling the copyright in some of this | |||
skipping to change at page 3, line 7 ¶ | skipping to change at page 2, line 34 ¶ | |||
modifications of such material outside the IETF Standards Process. | modifications of such material outside the IETF Standards Process. | |||
Without obtaining an adequate license from the person(s) controlling | Without obtaining an adequate license from the person(s) controlling | |||
the copyright in such materials, this document may not be modified | the copyright in such materials, this document may not be modified | |||
outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 | 1.1. Terminology and Notation . . . . . . . . . . . . . . . . 3 | |||
1.1.1. Syntax Notation . . . . . . . . . . . . . . . . . . . 4 | 2. The 'Basic' Authentication Scheme . . . . . . . . . . . . . . 3 | |||
2. The 'Basic' Authentication Scheme . . . . . . . . . . . . . . 4 | 2.1. The 'charset' auth-param . . . . . . . . . . . . . . . . 5 | |||
2.1. The 'charset' auth-param . . . . . . . . . . . . . . . . . 6 | 2.2. Reusing Credentials . . . . . . . . . . . . . . . . . . . 7 | |||
2.2. Re-using Credentials . . . . . . . . . . . . . . . . . . . 8 | 3. Internationalization Considerations . . . . . . . . . . . . . 7 | |||
3. Internationalization Considerations . . . . . . . . . . . . . 8 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 6.2. Informative References . . . . . . . . . . . . . . . . . 11 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | Appendix A. Changes from RFC 2617 . . . . . . . . . . . . . . . 13 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . . 11 | ||||
Appendix A. Changes from RFC 2617 . . . . . . . . . . . . . . . . 12 | ||||
Appendix B. Deployment Considerations for the 'charset' | Appendix B. Deployment Considerations for the 'charset' | |||
Parameter . . . . . . . . . . . . . . . . . . . . . . 12 | Parameter . . . . . . . . . . . . . . . . . . . . . 13 | |||
B.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 12 | B.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
B.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 13 | B.2. 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? . . 14 | |||
Appendix C. Change Log (to be removed by RFC Editor before | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
publication) . . . . . . . . . . . . . . . . . . . . 13 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
C.1. Since RFC 2617 . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
C.2. Since draft-ietf-httpauth-basicauth-update-00 . . . . . . 13 | ||||
C.3. Since draft-ietf-httpauth-basicauth-update-01 . . . . . . 14 | ||||
C.4. Since draft-ietf-httpauth-basicauth-update-02 . . . . . . 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 user-id/ | |||
pairs, obfuscated by the use of Base64 encoding (HTTP authentication | password pairs, encoded using Base64 (HTTP authentication schemes are | |||
schemes are defined in [RFC7235]). | 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 | |||
system such as TLS (Transport Layer Security, [RFC5246]), as the user | system such as TLS (Transport Layer Security, [RFC5246]), as the | |||
name and password are passed over the network as cleartext. | user-id and password are passed over the network as cleartext. | |||
The "Basic" scheme previously was defined in Section 2 of [RFC2617]. | The "Basic" scheme previously was defined in Section 2 of [RFC2617]. | |||
This document updates the definition, and also addresses | This document updates the definition, and also addresses | |||
internationalization issues by introducing the "charset" | internationalization issues by introducing the 'charset' | |||
authentication parameter (Section 2.1). | authentication parameter (Section 2.1). | |||
Other documents updating RFC 2617 are "Hypertext Transfer Protocol | Other documents updating RFC 2617 are "Hypertext Transfer Protocol | |||
(HTTP/1.1): Authentication" ([RFC7235], defining the authentication | (HTTP/1.1): Authentication" ([RFC7235], defining the authentication | |||
framework) and "HTTP Digest Access Authentication" ([DIGEST], | framework), "HTTP Digest Access Authentication" ([RFC7616], updating | |||
updating the definition of the '"Digest" authentication scheme). | the definition of the "Digest" authentication scheme), and "HTTP | |||
Taken together, these three documents obsolete RFC 2617. | Authentication-Info and Proxy-Authentication-Info Response Header | |||
Fields" ([RFC7615]). Taken together, these four documents obsolete | ||||
RFC 2617. | ||||
1.1. Notational Conventions | 1.1. Terminology and Notation | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
1.1.1. Syntax Notation | The terms ""protection space"" and ""realm"" are defined in | |||
Section 2.2 of [RFC7235]. | ||||
This specification uses the Augmented Backus-Naur Form (ABNF) | ||||
notation of [RFC5234]. | ||||
The terms "protection space" and "realm" are defined in Section 2.2 | ||||
of [RFC7235]. | ||||
The terms (character) "repertoire" and "character encoding scheme" | The terms ""(character) repertoire"" and ""character encoding | |||
are defined in Section 2 of [RFC6365]. | scheme"" are defined in Section 2 of [RFC6365]. | |||
2. The 'Basic' Authentication Scheme | 2. The 'Basic' Authentication Scheme | |||
The "Basic" authentication scheme is based on the model that the | The Basic authentication scheme is based on the model that the client | |||
client needs to authenticate itself with a user-ID and a password for | needs to authenticate itself with a user-id and a password for each | |||
each protection space ("realm"). The realm value is an opaque string | protection space ("realm"). The realm value is a free-form string | |||
which can only be compared for equality with other realms on that | that can only be compared for equality with other realms on that | |||
server. The server will service the request only if it can validate | server. The server will service the request only if it can validate | |||
the user-ID and password for the protection space applying to the | the user-id and password for the protection space applying to the | |||
requested resource. | requested resource. | |||
The "Basic" authentication scheme utilizes the Authentication | The Basic authentication scheme utilizes the Authentication Framework | |||
Framework as follows: | as follows. | |||
In challenges: | In challenges: | |||
o the scheme name is "Basic" | o The scheme name is "Basic". | |||
o the authentication parameter "realm" is REQUIRED ([RFC7235], | o The authentication parameter 'realm' is REQUIRED ([RFC7235], | |||
Section 2.2) | Section 2.2). | |||
o the authentication parameter "charset" is OPTIONAL (see | o The authentication parameter 'charset' is OPTIONAL (see | |||
Section 2.1) | Section 2.1). | |||
o no other authentication parameters are defined -- unknown | o No other authentication parameters are defined -- unknown | |||
parameters MUST be ignored by recipients, and new parameters can | parameters MUST be ignored by recipients, and new parameters can | |||
only be defined by revising this specification | only be defined by revising this specification. | |||
See also Section 4.1 of [RFC7235], which discusses the complexity of | ||||
parsing challenges properly. | ||||
Note that both scheme and parameter names are matched case- | Note that both scheme and parameter names are matched case- | |||
insensitively. | insensitively. | |||
For credentials, the "token68" syntax defined in Section 2.1 of | For credentials, the "token68" syntax defined in Section 2.1 of | |||
[RFC7235] is used. The value is computed based on user-id and | [RFC7235] is used. The value is computed based on user-id and | |||
password as defined below. | password as defined below. | |||
Upon receipt of a request for a URI within the protection space that | Upon receipt of a request for a URI within the protection space that | |||
lacks credentials, the server can reply with a challenge using the | lacks credentials, the server can reply with a challenge using the | |||
401 (Unauthorized) status code ([RFC7235], Section 3.1) and the WWW- | 401 (Unauthorized) status code ([RFC7235], Section 3.1) and the WWW- | |||
Authenticate header field ([RFC7235], Section 4.1). | Authenticate header field ([RFC7235], Section 4.1). | |||
For instance: | For instance: | |||
HTTP/1.1 401 Unauthorized | HTTP/1.1 401 Unauthorized | |||
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 | |||
identify the protection space. | 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 | To receive authorization, the client | |||
1. obtains the userid and password from the user, | 1. obtains the user-id and password from the user, | |||
2. constructs the user-pass by concatenating userid, a single colon | 2. constructs the user-pass by concatenating the user-id, a single | |||
(":") character, and the password, | colon (":") character, and the password, | |||
3. encodes the user-pass into an octet sequence (see below for a | 3. encodes the user-pass into an octet sequence (see below for a | |||
discussion of character encoding schemes), | discussion of character encoding schemes), | |||
4. and obtains the basic-credentials by encoding this octet sequence | 4. and obtains the basic-credentials by encoding this octet sequence | |||
using base64 ([RFC4648], Section 4) into a sequence of US-ASCII | using Base64 ([RFC4648], Section 4) into a sequence of US-ASCII | |||
characters ([RFC0020]). | characters ([RFC0020]). | |||
The original definition of this authentication scheme failed to | The original definition of this authentication scheme failed to | |||
specify the character encoding scheme used to convert the user-pass | specify the character encoding scheme used to convert the user-pass | |||
into an octet sequence. In practice, most implementations chose | into an octet sequence. In practice, most implementations chose | |||
either a local-specific encoding such as ISO-8859-1 ([ISO-8859-1]), | either a locale-specific encoding such as ISO-8859-1 ([ISO-8859-1]), | |||
or UTF-8 ([RFC3629]). For backwards compatibility reasons, this | or UTF-8 ([RFC3629]). For backwards compatibility reasons, this | |||
specification continues to leave the default encoding undefined, as | specification continues to leave the default encoding undefined, as | |||
long as it is compatible with US-ASCII (mapping any US-ASCII | long as it is compatible with US-ASCII (mapping any US-ASCII | |||
character to a single octet matching the US-ASCII character code). | character to a single octet matching the US-ASCII character code). | |||
The userid and password MUST NOT contain any control characters (see | The user-id and password MUST NOT contain any control characters (see | |||
"CTL" in Appendix B.1 of [RFC5234]). | "CTL" in Appendix B.1 of [RFC5234]). | |||
Furthermore, a userid containing a colon character is invalid, as | Furthermore, a user-id containing a colon character is invalid, as | |||
recipients will split the user-pass at the first occurence of a colon | the first colon in a user-pass string separates user-id and password | |||
character. Note that many user agents however will accept a colon in | from one another; text after the first colon is part of the password. | |||
userid, thereby producing a user-pass string that recipients will | User-ids containing colons cannot be encoded in user-pass strings. | |||
likely treat in a way not intended by the user. | ||||
If the user agent wishes to send the userid "Aladdin" and password | Note that many user agents produce user-pass strings without checking | |||
that user-ids supplied by users do not contain colons; recipients | ||||
will then treat part of the username input as part of the password. | ||||
If the user agent wishes to send the user-id "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 | |||
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"; it is to be matched case- | |||
(see [RFC2978], Section 2.3). It indicates that the server expects | insensitively (see [RFC2978], Section 2.3). It indicates that the | |||
character data to be converted to Unicode Normalization Form C | server expects character data to be converted to Unicode | |||
("NFC", see Section 3 of [RFC5198]) and to be encoded into octets | Normalization Form C ("NFC"; see Section 3 of [RFC5198]) and to be | |||
using the UTF-8 character encoding scheme ([RFC3629]). | encoded into octets using the UTF-8 character encoding scheme | |||
([RFC3629]). | ||||
For the userid, recipients MUST support all characters defined in the | For the user-id, recipients MUST support all characters defined in | |||
"UsernameCasePreserved" profile defined in in Section 3.3 of | the "UsernameCasePreserved" profile defined in Section 3.3 of | |||
[PRECIS], with the exception of the colon (":") character. | [RFC7613], with the exception of the colon (":") character. | |||
For the password, recipients MUST support all characters defined in | For the password, recipients MUST support all characters defined in | |||
the "OpaqueString" profile defined in in Section 4.2 of [PRECIS]. | the "OpaqueString" profile defined in Section 4.2 of [RFC7613]. | |||
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 | |||
a single token for credentials ('token68' syntax), thus the | authentication uses a single token for credentials ('token68' | |||
credentials syntax isn't extensible. | syntax); thus, the 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. | |||
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. Reusing 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 of the | removing all characters after the last slash ("/") character of the | |||
path component ("hier_part", see [RFC3986], Section 3). A client | path component ("hier_part"; see [RFC3986], Section 3). A client | |||
SHOULD assume that resources identified by URIs with a prefix-match | SHOULD assume that resources identified by URIs with a prefix-match | |||
of the authentication scope are also within the protection space | of the authentication scope are also within the protection space | |||
specified by the realm value of the that authenticated request. | specified by the realm value of 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 user-id 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: | |||
http://example.com/docs/index.html | http://example.com/docs/index.html | |||
...requests to the URIs below could use the known credentials: | requests to the URIs below could use the known credentials: | |||
http://example.com/docs/ | http://example.com/docs/ | |||
http://example.com/docs/test.doc | http://example.com/docs/test.doc | |||
http://example.com/docs/?page=1 | http://example.com/docs/?page=1 | |||
...while the URIs | while the URIs | |||
http://example.com/other/ | http://example.com/other/ | |||
https://example.com/docs/ | https://example.com/docs/ | |||
would be considered to be outside the authentication scope. | would be considered to be outside the authentication scope. | |||
Note that a URI can be part of multiple authentication scopes (such | Note that a URI can be part of multiple authentication scopes (such | |||
as "http://example.com/" and "http://example.com/docs/"). This | as "http://example.com/" and "http://example.com/docs/"). This | |||
specification does not define which of these should be treated with | specification does not define which of these should be treated with | |||
higher priority. | higher priority. | |||
3. Internationalization Considerations | 3. Internationalization Considerations | |||
User names or passwords containing characters outside the US-ASCII | User-ids 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. Servers can use the new 'charset' parameter (Section 2.1) | be used. Servers 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; | |||
however [RFC7235] does not define a way to reliably transport non-US- | however, [RFC7235] does not define a way to reliably transport non- | |||
ASCII characters. This is a known issue that would need to be | US-ASCII characters. This is a known issue that would need to be | |||
addressed in that specification. | addressed in a revision to that specification. | |||
4. Security Considerations | 4. Security Considerations | |||
The Basic authentication scheme is not a secure method of user | The Basic authentication scheme is not a secure method of user | |||
authentication, nor does it in any way protect the entity, which is | authentication, nor does it in any way protect the entity, which is | |||
transmitted in cleartext across the physical network used as the | transmitted in cleartext across the physical network used as the | |||
carrier. HTTP does not prevent the addition of enhancements (such as | carrier. HTTP does not prevent the addition of enhancements (such as | |||
schemes to use one-time passwords) to Basic authentication. | schemes to use one-time passwords) to Basic authentication. | |||
The most serious flaw in Basic authentication is that it results in | The most serious flaw of Basic authentication is that it results in | |||
the cleartext transmission of the user's password over the physical | the cleartext transmission of the user's password over the physical | |||
network. Many other authentication schemes address this problem. | network. Many other authentication schemes address this problem. | |||
Because Basic authentication involves the cleartext transmission of | Because Basic authentication involves the cleartext transmission of | |||
passwords it SHOULD NOT be used (without enhancements such as HTTPS | passwords, it SHOULD NOT be used (without enhancements such as HTTPS | |||
[RFC2818]) to protect sensitive or valuable information. | [RFC2818]) to protect sensitive or valuable information. | |||
A common use of Basic authentication is for identification purposes | A common use of Basic authentication is for identification purposes | |||
-- requiring the user to provide a user name and password as a means | -- requiring the user to provide a user-id and password as a means of | |||
of identification, for example, for purposes of gathering accurate | identification, for example, for purposes of gathering accurate usage | |||
usage statistics on a server. When used in this way it is tempting | statistics on a server. When used in this way it is tempting to | |||
to think that there is no danger in its use if illicit access to the | think that there is no danger in its use if illicit access to the | |||
protected documents is not a major concern. This is only correct if | protected documents is not a major concern. This is only correct if | |||
the server issues both user name and password to the users and in | the server issues both user-id and password to the users and, in | |||
particular does not allow the user to choose his or her own password. | particular, does not allow the user to choose his or her own | |||
The danger arises because naive users frequently reuse a single | password. The danger arises because naive users frequently reuse a | |||
password to avoid the task of maintaining multiple passwords. | single 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 other sites if this information is | |||
maintained in a secure fashion. This raises both security and | not maintained in a secure fashion. This raises both security and | |||
privacy concerns ([RFC6973]). If the same username and password | privacy concerns ([RFC6973]). If the same user-id and password | |||
combination is in use to access other accounts, such as an email or | combination is in use to access other accounts, such as an email or | |||
health portal account, personal information could be exposed. | 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 she 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, she 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. Server implementers ought to guard against this sort of | |||
Authentication. Server implementers SHOULD guard against the | counterfeiting; in particular, software components that can take over | |||
possibility of this sort of counterfeiting by gateways or CGI | control over the message framing on an existing connection need to be | |||
scripts. In particular it is very dangerous for a server to simply | used carefully or not at all (for instance: NPH ("Non-Parsed Header") | |||
turn over a connection to a gateway. That gateway can then use the | scripts as described in Section 5 of [RFC3875]). | |||
persistent connection mechanism to engage in multiple transactions | ||||
with the client while impersonating the original server in a way that | ||||
is not detectable by the client. | ||||
The use of the UTF-8 character encoding scheme introduces additional | Servers and proxies implementing Basic authentication need to store | |||
security considerations; see Section 10 of [RFC3629] for more | user passwords in some form in order to authenticate a request. | |||
information. | These passwords ought to be stored in such a way that a leak of the | |||
password data doesn't make them trivially recoverable. This is | ||||
especially important when users are allowed to set their own | ||||
passwords, since users are known to choose weak passwords and to | ||||
reuse them across authentication realms. While a full discussion of | ||||
good password hashing techniques is beyond the scope of this | ||||
document, server operators ought to make an effort to minimize risks | ||||
to their users in the event of a password data leak. For example, | ||||
servers ought to avoid storing user passwords in plaintext or as | ||||
unsalted digests. For more discussion about modern password hashing | ||||
techniques, see the "Password Hashing Competition" | ||||
(<https://password-hashing.net>). | ||||
5. IANA Considerations | The use of the UTF-8 character encoding scheme and of normalization | |||
introduces additional security considerations; see Section 10 of | ||||
[RFC3629] and Section 6 of [RFC5198] for more information. | ||||
IANA maintains the registry of HTTP Authentication Schemes | 5. IANA Considerations | |||
([RFC7235]) at <http://www.iana.org/assignments/http-authschemes>. | ||||
The entry for the "Basic" Authentication Scheme shall be updated with | IANA maintains the "Hypertext Transfer Protocol (HTTP) Authentication | |||
a pointer to this specification. | Scheme Registry" ([RFC7235]) at <http://www.iana.org/assignments/ | |||
http-authschemes>. | ||||
6. Acknowledgements | The entry for the "Basic" authentication scheme has been updated to | |||
reference this specification. | ||||
This specification takes over the definition of the "Basic" HTTP | 6. References | |||
Authentication Scheme, previously defined in RFC 2617. We thank John | ||||
Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. | ||||
Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for | ||||
their work on that specification, from which significant amounts of | ||||
text were borrowed. See Section 6 of [RFC2617] for further | ||||
acknowledgements. | ||||
The internationalization problem with respect to the character | 6.1. Normative References | |||
encoding scheme used for user-pass has been reported as a Mozilla bug | ||||
back in the year 2000 (see | ||||
<https://bugzilla.mozilla.org/show_bug.cgi?id=41489> and also the | ||||
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. | ||||
We also thank the members of the HTTPAuth Working Group and other | [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, | |||
reviewers, namely Stephen Farrell, Bjoern Hoehrmann, Kari Hurtta, | RFC 20, DOI 10.17487/RFC0020, October 1969, | |||
Amos Jeffries, Benjamin Kaduk, Michael Koeller, James Manger, | <https://www.rfc-editor.org/info/rfc20>. | |||
Kathleen Moriarty, Yaron Sheffer, Michael Sweet, and Martin Thomson | ||||
for feedback on this revision. | ||||
7. References | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
7.1. Normative References | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | ||||
<https://www.rfc-editor.org/info/rfc2119>. | ||||
[PRECIS] Saint-Andre, P. and A. Melnikov, "Preparation, | [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration | |||
Enforcement, and Comparison of Internationalized | Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, | |||
Strings Representing Usernames and Passwords", | October 2000, <https://www.rfc-editor.org/info/rfc2978>. | |||
draft-ietf-precis-saslprepbis-12 (work in progress), | ||||
December 2014. | ||||
[RFC0020] Cerf, V., "ASCII format for network interchange", | [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | |||
RFC 20, October 1969. | 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November | |||
2003, <https://www.rfc-editor.org/info/rfc3629>. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Resource Identifier (URI): Generic Syntax", STD 66, | |||
RFC 3986, DOI 10.17487/RFC3986, January 2005, | ||||
<https://www.rfc-editor.org/info/rfc3986>. | ||||
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration | [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data | |||
Procedures", BCP 19, RFC 2978, October 2000. | Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, | |||
<https://www.rfc-editor.org/info/rfc4648>. | ||||
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network | |||
10646", STD 63, RFC 3629, November 2003. | Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, | |||
<https://www.rfc-editor.org/info/rfc5198>. | ||||
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
"Uniform Resource Identifier (URI): Generic Syntax", | Specifications: ABNF", STD 68, RFC 5234, | |||
STD 66, RFC 3986, January 2005. | DOI 10.17487/RFC5234, January 2008, | |||
<https://www.rfc-editor.org/info/rfc5234>. | ||||
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data | [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in | |||
Encodings", RFC 4648, October 2006. | Internationalization in the IETF", BCP 166, RFC 6365, | |||
DOI 10.17487/RFC6365, September 2011, | ||||
<https://www.rfc-editor.org/info/rfc6365>. | ||||
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for | [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Network Interchange", RFC 5198, March 2008. | Protocol (HTTP/1.1): Authentication", RFC 7235, | |||
DOI 10.17487/RFC7235, June 2014, | ||||
<https://www.rfc-editor.org/info/rfc7235>. | ||||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for | [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, | |||
Syntax Specifications: ABNF", STD 68, RFC 5234, | Enforcement, and Comparison of Internationalized Strings | |||
January 2008. | Representing Usernames and Passwords", RFC 7613, | |||
DOI 10.17487/RFC7613, August 2015, | ||||
<https://www.rfc-editor.org/info/rfc7613>. | ||||
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in | 6.2. Informative References | |||
Internationalization in the IETF", BCP 166, RFC 6365, | ||||
September 2011. | ||||
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext | [ISO-8859-1] | |||
Transfer Protocol (HTTP/1.1): Authentication", | International Organization for Standardization, | |||
RFC 7235, June 2014. | "Information technology -- 8-bit single-byte coded graphic | |||
character sets -- Part 1: Latin alphabet No. 1", ISO/ | ||||
IEC 8859-1:1998, 1998. | ||||
7.2. Informative References | [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., | |||
Leach, P., Luotonen, A., and L. Stewart, "HTTP | ||||
Authentication: Basic and Digest Access Authentication", | ||||
RFC 2617, DOI 10.17487/RFC2617, June 1999, | ||||
<https://www.rfc-editor.org/info/rfc2617>. | ||||
[DIGEST] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, | |||
Digest Access Authentication", | DOI 10.17487/RFC2818, May 2000, | |||
draft-ietf-httpauth-digest-10 (work in progress), | <https://www.rfc-editor.org/info/rfc2818>. | |||
January 2015. | ||||
[ISO-8859-1] International Organization for Standardization, | [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a | |||
"Information technology -- 8-bit single-byte coded | SASL Mechanism", RFC 2831, DOI 10.17487/RFC2831, May 2000, | |||
graphic character sets -- Part 1: Latin alphabet No. | <https://www.rfc-editor.org/info/rfc2831>. | |||
1", ISO/IEC 8859-1:1998, 1998. | ||||
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, | [RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface | |||
S., Leach, P., Luotonen, A., and L. Stewart, "HTTP | (CGI) Version 1.1", RFC 3875, October 2004, | |||
Authentication: Basic and Digest Access | <http://www.rfc-editor.org/info/rfc3875>. | |||
Authentication", RFC 2617, June 1999. | ||||
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
(TLS) Protocol Version 1.2", RFC 5246, | ||||
DOI 10.17487/RFC5246, August 2008, | ||||
<https://www.rfc-editor.org/info/rfc5246>. | ||||
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication | [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., | |||
as a SASL Mechanism", RFC 2831, May 2000. | Morris, J., Hansen, M., and R. Smith, "Privacy | |||
Considerations for Internet Protocols", RFC 6973, | ||||
DOI 10.17487/RFC6973, July 2013, | ||||
<https://www.rfc-editor.org/info/rfc6973>. | ||||
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer | [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Security (TLS) Protocol Version 1.2", RFC 5246, | Protocol (HTTP/1.1): Semantics and Content", RFC 7231, | |||
August 2008. | DOI 10.17487/RFC7231, June 2014, | |||
<https://www.rfc-editor.org/info/rfc7231>. | ||||
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., | [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- | |||
Morris, J., Hansen, M., and R. Smith, "Privacy | Authentication-Info Response Header Fields", RFC 7615, | |||
Considerations for Internet Protocols", RFC 6973, | DOI 10.17487/RFC7615, September 2015, | |||
July 2013. | <https://www.rfc-editor.org/info/rfc7615>. | |||
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext | [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP | |||
Transfer Protocol (HTTP/1.1): Semantics and Content", | Digest Access Authentication", RFC 7616, | |||
RFC 7231, June 2014. | DOI 10.17487/RFC7616, September 2015, | |||
<https://www.rfc-editor.org/info/rfc7616>. | ||||
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 | |||
purely advisory, so existing implementations do not need to change, | purely advisory, so existing implementations do not need to change, | |||
unless they want to take advantage of the additional information | unless they want to take advantage of the additional information that | |||
which previously wasn't available. | previously wasn't available. | |||
Appendix B. Deployment Considerations for the 'charset' Parameter | Appendix B. Deployment Considerations for the 'charset' Parameter | |||
B.1. User Agents | B.1. User Agents | |||
User agents not implementing 'charset' will continue to work as | User agents not implementing 'charset' will continue to work as | |||
before, ignoring the new parameter. | before, ignoring the new parameter. | |||
User agents which already default to the UTF-8 encoding implement | User agents that already default to the UTF-8 encoding implement | |||
'charset' by definition. | 'charset' by definition. | |||
Other user agents can keep their default behavior, and switch to | Other user agents can keep their default behavior and switch to UTF-8 | |||
UTF-8 when seeing the new parameter. | when seeing the new parameter. | |||
B.2. Origin Servers | B.2. Servers | |||
Origin servers that do not support non-US-ASCII characters in | Servers that do not support non-US-ASCII characters in credentials do | |||
credentials do not require any changes to support 'charset'. | not require any changes to support 'charset'. | |||
Origin servers that need to support non-US-ASCII characters, but | Servers that need to support non-US-ASCII characters, but cannot use | |||
cannot use the UTF-8 character encoding scheme will not be affected; | the UTF-8 character encoding scheme will not be affected; they will | |||
they will continue to function as well or as badly as before. | continue to function as well or as badly as before. | |||
Finally, origin servers that need to support non-US-ASCII characters | Finally, servers that need to support non-US-ASCII characters and can | |||
and can use the UTF-8 character encoding scheme can opt in as | use the UTF-8 character encoding scheme can opt in by specifying the | |||
described above. In the worst case, they'll continue to see either | 'charset' parameter in the authentication challenge. Clients that do | |||
broken credentials or no credentials at all (depending on how legacy | understand the 'charset' parameter will then start to use UTF-8, | |||
clients handle characters they can not encode). | while other clients will continue to send credentials in their | |||
default encoding, broken credentials, or no credentials at all. | ||||
Until all clients are upgraded to support UTF-8, servers are likely | ||||
to see both UTF-8 and "legacy" encodings in requests. When | ||||
processing as UTF-8 fails (due to a failure to decode as UTF-8 or a | ||||
mismatch of user-id/password), a server might try a fallback to the | ||||
previously supported legacy encoding in order to accommodate these | ||||
legacy clients. Note that implicit retries need to be done | ||||
carefully; for instance, some subsystems might detect repeated login | ||||
failures and treat them as a potential credentials-guessing attack. | ||||
B.3. Why not simply switch the default encoding to UTF-8? | B.3. Why not simply switch the default encoding to UTF-8? | |||
There are sites in use today that default to a local character | There are sites in use today that default to a local character | |||
encoding scheme, such as ISO-8859-1 ([ISO-8859-1]), and expect user | encoding scheme, such as ISO-8859-1 ([ISO-8859-1]), and expect user | |||
agents to use that encoding. Authentication on these sites will stop | agents to use that encoding. Authentication on these sites will stop | |||
to work if the user agent switches to a different encoding, such as | working if the user agent switches to a different encoding, such as | |||
UTF-8. | UTF-8. | |||
Note that sites might even inspect the User-Agent header field | Note that sites might even inspect the User-Agent header field | |||
([RFC7231], Section 5.5.3) to decide what character encoding scheme | ([RFC7231], Section 5.5.3) to decide which character encoding scheme | |||
to expect from the client. Therefore they might support UTF-8 for | to expect from the client. Therefore, they might support UTF-8 for | |||
some user agents, but default to something else for others. User | some user agents, but default to something else for others. User | |||
agents in the latter group will have to continue to do what they do | agents in the latter group will have to continue to do what they do | |||
today until the majority of these servers have been upgraded to | today until the majority of these servers have been upgraded to | |||
always use UTF-8. | always use UTF-8. | |||
Appendix C. Change Log (to be removed by RFC Editor before publication) | Acknowledgements | |||
C.1. Since RFC 2617 | ||||
This draft acts as a baseline for tracking subsequent changes to the | ||||
specification. As such, it extracts the definition of "Basic", plus | ||||
the related Security Considerations, and also adds the IANA | ||||
registration of the scheme. Changes to the actual definition will be | ||||
made in subsequent drafts. | ||||
C.2. Since draft-ietf-httpauth-basicauth-update-00 | ||||
Fixed Base64 reference to point to an actual definition of Base64. | ||||
Update HTTPbis and Digest references. | ||||
Note that this spec, together with HTTPbis P7 and the Digest update, | ||||
obsoletes RFC 2617. | ||||
Rewrote text about authentication parameters and their extensibility. | ||||
Pulled in the definition of the "charset" parameter. | ||||
Removed a misleading statement about userids potentially being case- | ||||
sensitive, as the same is true for passwords. | ||||
Added TODOs with respect to path matching, and colons in userids. | ||||
C.3. Since draft-ietf-httpauth-basicauth-update-01 | ||||
Minor improvements on Security Considerations. | ||||
Update Digest reference. | ||||
Rewrite scheme definition as algorithm rather than pseudo-ABNF. | ||||
Add a note about colons in userid. | ||||
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. | ||||
C.5. Since draft-ietf-httpauth-basicauth-update-03 | ||||
Update reference for draft-ietf-precis-saslprepbis (which renames | ||||
"Password" to "OpaqueString"). | ||||
Mention HTTPS as enhancement for securing the transmission of | ||||
credentials. | ||||
Update DIGEST reference and change it to informative. | ||||
Use RFC 20 as reference for ASCII. | This specification takes over the definition of the "Basic" HTTP | |||
Authentication Scheme, previously defined in RFC 2617. We thank John | ||||
Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. | ||||
Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for | ||||
their work on that specification, from which significant amounts of | ||||
text were borrowed. See Section 6 of [RFC2617] for further | ||||
acknowledgements. | ||||
C.6. Since draft-ietf-httpauth-basicauth-update-04 | The internationalization problem with respect to the character | |||
encoding scheme used for user-pass was reported as a Mozilla bug back | ||||
in the year 2000 (see <https://bugzilla.mozilla.org/ | ||||
show_bug.cgi?id=41489> and also the 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. | ||||
Fixed definition of authentication scope. Updated DIGEST reference. | We also thank the members of the HTTPAUTH Working Group and other | |||
reviewers, namely, Stephen Farrell, Roy Fielding, Daniel Kahn | ||||
Gillmor, Tony Hansen, Bjoern Hoehrmann, Kari Hurtta, Amos Jeffries, | ||||
Benjamin Kaduk, Michael Koeller, Eric Lawrence, Barry Leiba, James | ||||
Manger, Alexey Melnikov, Kathleen Moriarty, Juergen Schoenwaelder, | ||||
Yaron Sheffer, Meral Shirazipour, Michael Sweet, and Martin Thomson | ||||
for feedback on this revision. | ||||
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. 102 change blocks. | ||||
300 lines changed or deleted | 286 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |