draft-ietf-httpauth-extension-08.txt   draft-ietf-httpauth-extension-09.txt 
HTTPAUTH Working Group Y. Oiwa HTTPAUTH Working Group Y. Oiwa
Internet-Draft H. Watanabe Internet-Draft H. Watanabe
Intended status: Experimental H. Takagi Intended status: Experimental H. Takagi
Expires: February 18, 2017 ITRI, AIST Expires: March 21, 2017 ITRI, AIST
K. Maeda K. Maeda
T. Hayashi T. Hayashi
Lepidum Lepidum
Y. Ioku Y. Ioku
Individual Individual
August 17, 2016 September 17, 2016
HTTP Authentication Extensions for Interactive Clients HTTP Authentication Extensions for Interactive Clients
draft-ietf-httpauth-extension-08 draft-ietf-httpauth-extension-09
Abstract Abstract
This document specifies extensions for the HTTP authentication This document specifies extensions for the HTTP authentication
framework for interactive clients. Currently, fundamental features framework for interactive clients. Currently, fundamental features
of HTTP-level authentication are insufficient for complex of HTTP-level authentication are insufficient for complex
requirements of various Web-based applications. This forces these requirements of various Web-based applications. This forces these
applications to implement their own authentication frameworks by applications to implement their own authentication frameworks by
means like HTML forms, which becomes one of the hurdles against means like HTML forms, which becomes one of the hurdles against
introducing secure authentication mechanisms handled jointly by introducing secure authentication mechanisms handled jointly by
servers and user-agent. The extended framework fills gaps between servers and user-agent. The extended framework fills gaps between
Web application requirements and HTTP authentication provisions to Web application requirements and HTTP authentication provisions to
solve the above problems, while maintaining compatibility with solve the above problems, while maintaining compatibility with
existing Web and non-Web uses of HTTP authentications. existing Web and non-Web uses of HTTP authentication.
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 February 18, 2017. This Internet-Draft will expire on March 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terms for describing authentication protocol flow . . . . 5 2.1. Terms for describing authentication protocol flow . . . . 4
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
3. Optional Authentication . . . . . . . . . . . . . . . . . . . 8 3. Optional Authentication . . . . . . . . . . . . . . . . . . . 8
3.1. Note on Optional-WWW-Authenticate and use of 3.1. Note on Optional-WWW-Authenticate and use of
WWW-Authenticate header with non-401 status . . . . . . . 9 WWW-Authenticate header with non-401 status . . . . . . . 10
4. Authentication-Control header . . . . . . . . . . . . . . . . 11 4. Authentication-Control header . . . . . . . . . . . . . . . . 11
4.1. Non-ASCII extended header parameters . . . . . . . . . . . 12 4.1. Non-ASCII extended header parameters . . . . . . . . . . . 12
4.2. Auth-style parameter . . . . . . . . . . . . . . . . . . . 13 4.2. Auth-style parameter . . . . . . . . . . . . . . . . . . . 13
4.3. Location-when-unauthenticated parameter . . . . . . . . . 14 4.3. Location-when-unauthenticated parameter . . . . . . . . . 14
4.4. No-auth parameter . . . . . . . . . . . . . . . . . . . . 15 4.4. No-auth parameter . . . . . . . . . . . . . . . . . . . . 15
4.5. Location-when-logout parameter . . . . . . . . . . . . . . 15 4.5. Location-when-logout parameter . . . . . . . . . . . . . . 15
4.6. Logout-timeout parameter . . . . . . . . . . . . . . . . . 16 4.6. Logout-timeout parameter . . . . . . . . . . . . . . . . . 16
4.7. Username parameter . . . . . . . . . . . . . . . . . . . . 17 4.7. Username parameter . . . . . . . . . . . . . . . . . . . . 17
5. Usage examples . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Usage examples . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Example 1: a portal site . . . . . . . . . . . . . . . . . 18 5.1. Example 1: a portal site . . . . . . . . . . . . . . . . . 18
5.1.1. Case 1: a simple application . . . . . . . . . . . . . 18 5.1.1. Case 1: a simple application . . . . . . . . . . . . . 19
5.1.2. Case 2: specific action required on log-out . . . . . 19 5.1.2. Case 2: specific action required on log-out . . . . . 19
5.1.3. Case 3: specific page displayed before log-in . . . . 19 5.1.3. Case 3: specific page displayed before log-in . . . . 19
5.2. Example 2: authenticated user-only sites . . . . . . . . . 19 5.2. Example 2: authenticated user-only sites . . . . . . . . . 20
5.3. When to use Cookies . . . . . . . . . . . . . . . . . . . 20 5.3. When to use Cookies . . . . . . . . . . . . . . . . . . . 20
5.4. Parallel deployment with Form/Cookie authentications . . . 20 5.4. Parallel deployment with Form/Cookie authentication . . . 21
6. Methods to extend this protocol . . . . . . . . . . . . . . . 21 6. Methods to extend this protocol . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8.1. Security implication of the username parameter . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. (Informative) Applicability of features for each Appendix A. (Informative) Applicability of features for each
messages . . . . . . . . . . . . . . . . . . . . . . 25 messages . . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. (Informative) Draft Change Log . . . . . . . . . . . 25 Appendix B. (Informative) Draft Change Log . . . . . . . . . . . 26
B.1. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 25 B.1. Changes in Httpauth WG Revision 09 . . . . . . . . . . . . 26
B.2. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 26 B.2. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 26
B.3. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 26 B.3. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 26
B.4. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 26 B.4. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 26
B.5. Changes in Httpauth WG revision 04 . . . . . . . . . . . . 26 B.5. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 26
B.6. Changes in Httpauth WG revision 03 . . . . . . . . . . . . 26 B.6. Changes in Httpauth WG revision 04 . . . . . . . . . . . . 27
B.7. Changes in Httpauth WG revision 02 . . . . . . . . . . . . 26 B.7. Changes in Httpauth WG revision 03 . . . . . . . . . . . . 27
B.8. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 26 B.8. Changes in Httpauth WG revision 02 . . . . . . . . . . . . 27
B.9. Changes in Httpauth revision 00 and HttpBis revision 00 . 26 B.9. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 27
B.10. Changes in revision 02 . . . . . . . . . . . . . . . . . . 26 B.10. Changes in Httpauth revision 00 and HttpBis revision 00 . 27
B.11. Changes in revision 01 . . . . . . . . . . . . . . . . . . 26 B.11. Changes in revision 02 . . . . . . . . . . . . . . . . . . 27
B.12. Changes in revision 00 . . . . . . . . . . . . . . . . . . 27 B.12. Changes in revision 01 . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 B.13. Changes in revision 00 . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
This document defines several extensions to the current HTTP This document defines several extensions to the current HTTP
authentication framework, to provide functionality comparable with authentication framework, to provide functionality comparable with
current widely-used form-based Web authentication. A majority of the current widely-used form-based Web authentication. A majority of the
recent websites on the Internet use custom application-layer recent websites on the Internet use custom application-layer
authentication implementations using Web forms. The reasons for authentication implementations using Web forms. The reasons for
these may vary, but many people believe that the current HTTP Basic these may vary, but many people believe that the current HTTP Basic
and Digest authentication methods do not have enough functionality and Digest authentication methods do not have enough functionality
skipping to change at page 4, line 38 skipping to change at page 4, line 38
o finer control for redirection depending on authentication status o finer control for redirection depending on authentication status
(Section 4). (Section 4).
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
The terms "encouraged" and "advised" are used for suggestions that do
not constitute "SHOULD"-level requirements. People MAY freely choose
not to include the suggested items. However, complying with those
suggestions would be a best practice; it will improve the security,
interoperability, and/or operational performance.
This document distinguishes the terms "client" and "user" in the This document distinguishes the terms "client" and "user" in the
following way: A "client" is an entity understanding and talking HTTP following way: A "client" is an entity understanding and talking HTTP
and the specified authentication protocol, usually computer software; and the specified authentication protocol, usually computer software;
a "user" is a (usually natural) person who wants to access data a "user" is a (usually natural) person who wants to access data
resources using "a client". resources using "a client".
2. Definitions 2. Definitions
2.1. Terms for describing authentication protocol flow 2.1. Terms for describing authentication protocol flow
skipping to change at page 5, line 23 skipping to change at page 5, line 14
1) A non-authenticating request is a request not attempting any 1) A non-authenticating request is a request not attempting any
authentication: a request without any Authorization header field. authentication: a request without any Authorization header field.
2) An authenticating request is the opposite: a request with an 2) An authenticating request is the opposite: a request with an
Authorization header field. Authorization header field.
For responses, For responses,
1) A non-authenticated response is a response which does not involve 1) A non-authenticated response is a response which does not involve
any HTTP authentication. It does not contain any WWW-Authenticate any HTTP authentication. It does not contain any WWW-Authenticate
or Authentication-Info header field. ([RFC7235]) or Authentication-Info header field ([RFC7615]).
Servers send this response when the requested resource is not Servers send this response when the requested resource is not
protected by an HTTP authentication mechanism. In context of this protected by an HTTP authentication mechanism. In context of this
specification, non-authentication-related negative responses (e.g. specification, non-authentication-related negative responses (e.g.
403 and 404) are also considered non-authenticated responses. 403 and 404) are also considered non-authenticated responses.
(See note on successfully-authenticated responses below for some (See note on successfully-authenticated responses below for some
ambiguous cases.) ambiguous cases.)
2) An authentication-initializing response is a response which 2) An authentication-initializing response is a response which
skipping to change at page 6, line 17 skipping to change at page 6, line 9
* On the other hand, if client already has enough authentication * On the other hand, if client already has enough authentication
credentials to the requested protection space, the client will credentials to the requested protection space, the client will
automatically send an authenticating request. Such cases often automatically send an authenticating request. Such cases often
occur when the client did not know beforehand that the current occur when the client did not know beforehand that the current
request-URL requires authentication. request-URL requires authentication.
3) A successfully-authenticated response is a response for an 3) A successfully-authenticated response is a response for an
authenticating request meaning that the authentication attempt was authenticating request meaning that the authentication attempt was
granted. (Note: if the authentication scheme used does not use an granted. (Note: if the authentication scheme used does not use an
Authentication-Info header field, it can't be distinguishable from Authentication-Info header field, it can't be distinguished from a
a non-authenticated response.) non-authenticated response.)
4) An intermediate authenticating response is a response for an 4) An intermediate authenticating response is a response for an
authenticating request which requires more reaction by the client authenticating request which requires more reaction by the client
software without involving users. Such a response is required software without involving users. Such a response is required
when an authentication scheme requires two or more round-trip when an authentication scheme requires two or more round-trip
messages to perform authentication, or when an authentication messages to perform authentication, or when an authentication
scheme uses some speculative short-cut method (such as uses of scheme uses some speculative short-cut method (such as uses of
cached shared secrets) and it failed. cached shared secrets) and it failed.
5) A negatively-authenticated response is a response for an 5) A negatively-authenticated response is a response for an
skipping to change at page 7, line 24 skipping to change at page 7, line 24
YES | / initializing| YES | / initializing|
v / | v / |
+------------------+ NO / | +------------------+ NO / |
| Can auth-req.(*1)|--------- | | Can auth-req.(*1)|--------- |
| be constructed? | | | be constructed? | |
+------------------+ | +------------------+ |
YES | initializing | YES | initializing |
| ---------------------------------------. | | ---------------------------------------. |
| / v v | / v v
| | ---------------- NO +-----------+ | | ---------------- NO +-----------+
| | ( AUTH-REQUESTED )<------|credentials| | | ( AUTH-REQUESTED )<------| passwords |
| | ---------------- | known? | | | ---------------- |etc. known?|
v | +-----------+ v | +-----------+
+-----------+ negative ------------- negative |YES +-----------+ negative ------------- negative |YES
| send |---------->( AUTH-FAILED )<---------, | | send |---------->( AUTH-FAILED )<---------, |
/| auth-req | ------------- | | /| auth-req | ------------- | |
/ +-----------+\ | v / +-----------+\ | v
| \ \ intermediate +-----------+ | \ \ intermediate +-----------+
| \ -------------------------------->| send | | \ -------------------------------->| send |
| \ | auth-req | | \ | auth-req |
| non-auth. \successful successful +-----------+ | non-auth. \successful successful +-----------+
| response (*2) \ / | ^ | response (*2) \ / | ^
skipping to change at page 8, line 12 skipping to change at page 8, line 12
This specification uses an extended ABNF syntax defined in [RFC7230] This specification uses an extended ABNF syntax defined in [RFC7230]
and [RFC5234]. The following syntax definitions are quoted from and [RFC5234]. The following syntax definitions are quoted from
[RFC7230] and [RFC7235]: auth-scheme, quoted-string, auth-param, SP, [RFC7230] and [RFC7235]: auth-scheme, quoted-string, auth-param, SP,
BWS, header-field, and challenge. It also uses the convention of BWS, header-field, and challenge. It also uses the convention of
using header field names for specifying the syntax of values for the using header field names for specifying the syntax of values for the
header field. header field.
Additionally, this specification uses the following syntax Additionally, this specification uses the following syntax
definitions as a refinement for token and the right-hand-side of definitions as a refinement for token and the right-hand-side of
auth-param in [RFC7235]. (Note: these definitions are consistent auth-param in [RFC7235].
with those in [I-D.ietf-httpauth-mutual].)
bare-token = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_") bare-token = bare-token-lead-char *bare-token-char
extension-token = "-" bare-token 1*("." bare-token) bare-token-lead-char = %x30-39 / %x41-5A / %x61-7A
extensive-token = bare-token / extension-token bare-token-char = %x30-39 / %x41-5A / %x61-7A / "-" / "_"
integer = "0" / (%x31-39 *%x30-39) ; no leading zeros extension-token = "-" bare-token 1*("." bare-token)
extensive-token = bare-token / extension-token
integer = "0" / (%x31-39 *%x30-39) ; no leading zeros
Figure 2: the BNF syntax for common notations Figure 2: the BNF syntax for common notations
Extensive-tokens are used in this protocol where the set of Extensive-tokens are used in this protocol where the set of
acceptable tokens includes private extensions. Any extensions of acceptable tokens includes private extensions. Any extensions of
this protocol MAY use either bare-tokens allocated by IANA (under the this protocol MAY use either bare-tokens allocated by IANA (under the
procedure described in Section 7), or extension-tokens with the procedure described in Section 7), or extension-tokens with the
format "-<token>.<domain-name>", where <domain-name> is a valid format "-<token>.<domain-name>", where <domain-name> is a valid
(sub-)domain name on the Internet owned by the party who defines the (sub-)domain name on the Internet owned by the party who defines the
extension. extension.
skipping to change at page 8, line 45 skipping to change at page 8, line 46
In several Web applications, users can access the same contents as In several Web applications, users can access the same contents as
both a guest user and an authenticated user. In most Web both a guest user and an authenticated user. In most Web
applications, this functionality is implemented using HTTP cookies applications, this functionality is implemented using HTTP cookies
[RFC6265] and custom form-based authentication. The new [RFC6265] and custom form-based authentication. The new
authentication method using this message will provide a replacement authentication method using this message will provide a replacement
for these authentication systems. for these authentication systems.
Servers MAY send HTTP non-interim responses containing the Servers MAY send HTTP non-interim responses containing the
Optional-WWW-Authenticate header as a replacement of a 401 response Optional-WWW-Authenticate header as a replacement of a 401 response
when it the response is authentication-initializing. The when it is authentication-initializing. The
Optional-WWW-Authenticate header MUST NOT sent on 401 responses (i.e. Optional-WWW-Authenticate header MUST NOT be sent on 401 responses
a usual WWW-Authenticate header MUST be used on 401 responses.) (i.e. a usual WWW-Authenticate header MUST be used on 401 responses).
HTTP/1.1 200 OK
Optional-WWW-Authenticate: Basic realm="xxxx"
Optional-WWW-Authenticate = 1#challenge Optional-WWW-Authenticate = 1#challenge
Figure 3: BNF syntax for Optional-WWW-Authenticate header Figure 3: BNF syntax for Optional-WWW-Authenticate header
Example:
HTTP/1.1 200 OK
Optional-WWW-Authenticate: Basic realm="xxxx"
The challenges contained in the Optional-WWW-Authenticate header are The challenges contained in the Optional-WWW-Authenticate header are
the same as those for a 401 responses corresponding to the same the same as those for a 401 responses corresponding to the same
request. For authentication-related matters, an optional request. For authentication-related matters, an optional
authentication request will have the same meaning as a 401 message authentication request will have the same meaning as a 401 message
with a corresponding WWW-Authenticate header (as an authentication- with a corresponding WWW-Authenticate header (as an authentication-
initializing response). (The behavior for other matters MAY be initializing response). (The behavior for other matters MAY be
different between the optional authentication and 401 messages. For different between the optional authentication and 401 messages. For
example, clients MAY choose to cache the 200 messages with example, clients MAY choose to cache the 200 messages with
Optional-WWW-Authenticate header field but not the 401 messages by Optional-WWW-Authenticate header field but not the 401 messages by
default.) default.)
skipping to change at page 9, line 43 skipping to change at page 9, line 44
Whenever an authentication scheme supports servers sending some Whenever an authentication scheme supports servers sending some
parameter which gives a hint of the URL space for the corresponding parameter which gives a hint of the URL space for the corresponding
protection space for the same realm (e.g. "path" or "domain"), protection space for the same realm (e.g. "path" or "domain"),
servers requesting non-mandatory authentication SHOULD send such servers requesting non-mandatory authentication SHOULD send such
parameter with the response. Clients supporting non-mandatory parameter with the response. Clients supporting non-mandatory
authentication MUST recognize the parameter, and MUST send a request authentication MUST recognize the parameter, and MUST send a request
with an appropriate authentication credential in an Authorization with an appropriate authentication credential in an Authorization
header for any URI inside the specified paths. header for any URI inside the specified paths.
Support of this header is OPTIONAL; clients MAY also implement this Implementations are not required to support this header for all of
extension only for some selected authentication schemes. New their supported authentication schemes (i.e., they may choose to
authentication schemes can make support of the optional implement it only for a subset of their supported schemes). New
authentication mandatory by its specification, though. authentication schemes can require support of the optional
authentication as a prerequisite, though.
3.1. Note on Optional-WWW-Authenticate and use of WWW-Authenticate 3.1. Note on Optional-WWW-Authenticate and use of WWW-Authenticate
header with non-401 status header with non-401 status
In the current specification of HTTP/1.1, it is clarified that the In the current specification of HTTP/1.1, it is clarified that the
WWW-Authenticate header can be used with messages with status codes WWW-Authenticate header can be used with messages with status codes
other than 401 (Authentication Required). Especially, the use of other than 401 (Authentication Required). Especially, the use of
WWW-Authenticate header with the 200 status messages implies a very WWW-Authenticate header with the 200 status messages implies a very
similar meaning to the above-defined Optional-WWW-Authenticate similar meaning to the above-defined Optional-WWW-Authenticate
header. header.
The design of Optional-WWW-Authenticate header expects that the use The design of Optional-WWW-Authenticate header expects that the use
of a new header guarantees that clients which is unaware of this of a new header guarantees that clients which are unaware of this
extension will ignore the header, and that Web developers can rely on extension will ignore the header, and that Web developers can rely on
that behavior to implement a secondary fallback method of that behavior to implement a secondary fallback method of
authentications. Several behavioral requirements written in the authentication. Several behavioral requirements written in the above
above section also assumes this property, and defines a necessary section also assumes this property, and defines a necessary
functionality to implement an HTTP optional authentication reliably functionality to implement an HTTP optional authentication reliably
and consistently. and consistently.
On the other hand, some experiments and discussions on the IETF On the other hand, some experiments and discussions on the IETF
mailing list revealed that most of (but not necessarily all of) the mailing list revealed that most of (but not necessarily all of) the
existing HTTP clients, at the time of writing, just ignores the WWW- existing HTTP clients, at the time of writing, just ignore the WWW-
Authenticate headers in non-401 messages, giving the similar behavior Authenticate headers in non-401 messages, giving the similar behavior
with the Optional-WWW-Authenticate. However, every corner case of with the Optional-WWW-Authenticate. However, every corner case of
behavior was not fully tested, nor well-defined in the existing behavior was not fully tested, nor well-defined in the existing
specifications. specifications.
Considering these situations, the author of this document chose to Considering these situations, the authors of this document chose to
use a new header for a new feature "experiment". This is to avoid use a new header for a new feature "experiment". This is to avoid
defining every corner-case behavior for the existing standard WWW- defining every corner-case behavior for the existing standard WWW-
Authentication header in this experimental document, which could be Authentication header in this experimental document, which could be
considered by some implementer as an "incompatible changes to considered by some implementers as an "incompatible changes to
existing specification". existing specification".
Experimentally, the authors propose implementer of the standard Experimentally, the authors propose implementers of the standard
HTTP/1.1 specification (especially implementer of this extension) to HTTP/1.1 specification (especially implementers of this extension) to
implement undefined (implementation-dependant) detailed handling of implement undefined (implementation-dependant) detailed handling of
WWW-Authenticate header with non-401 status messages as similar as WWW-Authenticate header with non-401 status messages as similar as
those defined above for the Optional-WWW-Authenticate header. For those defined above for the Optional-WWW-Authenticate header. For
example, we propose for servers to return 401 status for failed example, we propose for servers to return 401 status for failed
authentication attempts, even when the unauthenticated request to the authentication attempts, even when the unauthenticated request to the
same resource will result in the 200 status. This can realize how same resource will result in the 200 status. This can realize how
(whether) we can implement non-mandatory authentication using the (whether) we can implement non-mandatory authentication using the
standard header fields and status codes. If this experiment is standard header fields and status codes. If this experiment is
successful, the future revision of this experimental document may successful, the future revision of this experimental document may
"bless" and recommend the use of standard WWW-Authenticate header, "bless" and recommend the use of standard WWW-Authenticate header,
skipping to change at page 11, line 21 skipping to change at page 11, line 21
ext-value = <see RFC 5987, Section 3.2> ext-value = <see RFC 5987, Section 3.2>
Figure 4: the BNF syntax for the Authentication-Control header Figure 4: the BNF syntax for the Authentication-Control header
The Authentication-Control header provides a more precise control of The Authentication-Control header provides a more precise control of
the client behavior for Web applications using an HTTP authentication the client behavior for Web applications using an HTTP authentication
protocol. This header is supposed to be generated in the application protocol. This header is supposed to be generated in the application
layer, as opposed to WWW-Authenticate headers which will usually be layer, as opposed to WWW-Authenticate headers which will usually be
generated by the Web servers. generated by the Web servers.
Support of this header is OPTIONAL, and clients MAY choose any subset Clients MAY freely choose any subset of these parameters to be
of these parameters to be supported. The set of supported parameters supported. Also, these are not required to support any of these
MAY also be authentication scheme-dependent. However, some parameters for all of their supported authentication schemes.
authentication schemes can require mandatory/recommended support for However, authentication schemes can require/recommend support for
some or all of the features provided in this header. some of these parameters as a prerequisite.
The Authentication-Control header contains one or more The Authentication-Control header contains one or more
"authentication control entries" each of which corresponds to a "authentication control entries" each of which corresponds to a
single realm for a specific authentication scheme. If the single realm for a specific authentication scheme. If the
auth-scheme specified for an entry supports the HTTP "realm" feature, auth-scheme specified for an entry supports the HTTP "realm" feature,
that entry MUST contain the "realm" parameter. If not, the entry that entry MUST contain the "realm" parameter. If not, the entry
MUST NOT contain the "realm" parameter. MUST NOT contain the "realm" parameter.
Among the multiple entries in the header, the relevant entries in the Among the multiple entries in the header, the relevant entries in the
header are those corresponding to an auth-scheme and a realm (if header are those corresponding to an auth-scheme and a realm (if
skipping to change at page 12, line 28 skipping to change at page 12, line 28
The type of parameter value depends on the parameter name as defined The type of parameter value depends on the parameter name as defined
in the following subsections. Regardless of the type, however, the in the following subsections. Regardless of the type, however, the
recipients MUST accept both quoted and unquoted representations of recipients MUST accept both quoted and unquoted representations of
values as defined in HTTP. If the parameter is defined to have a values as defined in HTTP. If the parameter is defined to have a
string value, implementations MUST send any value outside of the string value, implementations MUST send any value outside of the
"token" ABNF syntax in either a quoted form or an an ext-value form "token" ABNF syntax in either a quoted form or an an ext-value form
(see Section 4.1). If the parameter is defined as a token (or (see Section 4.1). If the parameter is defined as a token (or
similar) or an integer, the value SHOULD follow the corresponding similar) or an integer, the value SHOULD follow the corresponding
ABNF syntax after possible unquoting of the quoted-string value (as ABNF syntax after possible unquoting of the quoted-string value (as
defined in HTTP), and MUST be sent in an plain (not an ext-value) defined in HTTP), and MUST be sent in a plain (not an ext-value)
form. (Note: the rest of this document will show all string-value form. (Note: the rest of this document will show all string-value
parameters in quoted forms, and others in unquoted forms.) parameters in quoted forms, and others in unquoted forms.)
Any parameters contained in this header MAY be ignored by clients. Any parameters contained in this header MAY be ignored by clients.
Also, even when a client accepts this header, users are able to Also, even when a client accepts this header, users are able to
circumvent the semantics of this header. Therefore, if this header circumvent the semantics of this header. Therefore, if this header
is used for security purposes, its use MUST be limited to providing is used for security purposes, its use MUST be limited to providing
some non-fundamental additional security measures valuable for end- some non-fundamental additional security measures valuable for end-
users (such as client-side log-out for protecting against console users (such as client-side log-out for protecting against console
takeover). Server-side applications MUST NOT rely on the use of this takeover). Server-side applications MUST NOT rely on the use of this
skipping to change at page 13, line 24 skipping to change at page 13, line 24
more than once, regardless of the used syntax. more than once, regardless of the used syntax.
For example, a parameter "username" with value "Renee of France" For example, a parameter "username" with value "Renee of France"
SHOULD be sent as < username="Renee of France" >. If the value is SHOULD be sent as < username="Renee of France" >. If the value is
"Ren<e acute>e of France", it SHOULD be sent as "Ren<e acute>e of France", it SHOULD be sent as
< username*=UTF-8''Ren%C3%89e%20of%20France > instead. < username*=UTF-8''Ren%C3%89e%20of%20France > instead.
Interoperability note: [RFC7235], Section 2.2, defines the "realm" Interoperability note: [RFC7235], Section 2.2, defines the "realm"
authentication parameter which cannot be replaced by the "realm*" authentication parameter which cannot be replaced by the "realm*"
extend parameter. It means that the use of non-ASCII values for an extend parameter. It means that the use of non-ASCII values for an
authentication realm is not the defined behavior in the HTTP. authentication realm is not the defined behavior in HTTP.
Unfortunately, some people currently use non-ASCII realm parameter in Unfortunately, some people currently use a non-ASCII realm parameter
reality, but even its encoding scheme is not well-defined. in reality, but even its encoding scheme is not well-defined.
Given this background, this document does not specify how to handle Given this background, this document does not specify how to handle a
non-ASCII "realm" parameter in the extended header fields. If non-ASCII "realm" parameter in the extended header fields. If
needed, the authors propose to use a non-extended "realm" parameter needed, the authors propose to use a non-extended "realm" parameter
form, with a wish for maximum interoperability. form, with a wish for maximum interoperability.
4.2. Auth-style parameter 4.2. Auth-style parameter
Example: Example:
Authentication-Control: Digest realm="protected space", Authentication-Control: Digest realm="protected space",
auth-style=modal auth-style=modal
The parameter "auth-style" specifies the server's preferences for The parameter "auth-style" specifies the server's preference for user
user interface behavior for user authentication. This parameter can interface behavior for user authentication. This parameter can be
be included in any kind of response, however, it is only meaningful included in any kind of response, however, it is only meaningful for
for either authentication-initializing or negatively-authenticated either authentication-initializing or negatively-authenticated
responses. The value of this parameter MUST be one of the bare- responses. The value of this parameter MUST be one of the bare-
tokens "modal" or "non-modal". When the Optional-WWW-Authenticate tokens "modal" or "non-modal". When the Optional-WWW-Authenticate
header is used, the value of this parameter MUST be disregarded and header is used, the value of this parameter MUST be disregarded and
the value "non-modal" is implied. the value "non-modal" is implied.
The value "modal" means that the server thinks the content of the The value "modal" means that the server thinks the content of the
response (body and other content-related headers) is valuable only response (body and other content-related headers) is valuable only
for users refusing the authentication request. The clients are for users refusing the authentication request. The clients are
expected to ask the user for a password before processing the expected to ask the user for a password before processing the
content. This behavior is common for most of the current content. This behavior is common for most of the current
skipping to change at page 15, line 17 skipping to change at page 15, line 17
Example: Example:
Authentication-Control: Basic realm="entrance", no-auth=true Authentication-Control: Basic realm="entrance", no-auth=true
The parameter "no-auth" is a variant of the The parameter "no-auth" is a variant of the
location-when-unauthenticated parameter; it specifies that new location-when-unauthenticated parameter; it specifies that new
authentication attempts are not to be performed on this location in authentication attempts are not to be performed on this location in
order to improve the user experience, without specifying the order to improve the user experience, without specifying the
redirection on the HTTP level. This header can be used, for example, redirection on the HTTP level. This header can be used, for example,
when there is a central login page for the entire Web application, when there is a central login page for the entire Web application,
and when an explicit user interaction with the Web content is desired and when an explicit user interaction with the Web content is desired
before authentications. The value of this parameter MUST be a token before authentication. The value of this parameter MUST be a token
"true". If the value is incorrect, client MAY ignore this parameter. "true". If the value is incorrect, client MAY ignore this parameter.
This parameter MAY be used with authentication-initiating responses. This parameter MAY be used with authentication-initiating responses.
It can also be contained, although this is NOT RECOMMENDED, in a It can also be contained, although this is NOT RECOMMENDED, in a
positive response with an Optional-WWW-Authenticate header. The positive response with an Optional-WWW-Authenticate header. The
clients MUST ignore this parameter when a response is either clients MUST ignore this parameter when a response is either
successfully-authenticated or intermediately-authenticated. successfully-authenticated or intermediately-authenticated.
When a client receives an authentication-initiating response with When a client receives an authentication-initiating response with
this parameter, if the client has to ask users for authentication this parameter, if the client has to ask users for authentication
credentials, the client will ignore the WWW-Authenticate header credentials, the client will ignore the WWW-Authenticate header
contained in the response and treat the whole response as a normal contained in the response and treat the whole response as a normal
negative 4xx-class response instead of giving the user an opportunity negative 4xx-class response instead of giving the user an opportunity
to start authentication. If the client can process authentication to start authentication. If the client can process authentication
without the user's interaction, this parameter MUST be ignored. without the user's interaction, this parameter MUST be ignored.
This parameter SHOULD NOT be used along with the Using this parameter along with location-when-unauthenticated
location-when-unauthenticated parameter. If both were supplied, parameter is meaningless. If both were supplied, clients SHOULD
clients MAY choose which one is to be honored. ignore the location-when-unauthenticated parameter.
This parameter SHOULD NOT be used as a security measure to prevent This parameter SHOULD NOT be used as a security measure to prevent
authentication attempts, as it is easily circumvented by users. This authentication attempts, as it is easily circumvented by users. This
parameter SHOULD be used solely for improving user experience of Web parameter SHOULD be used solely for improving user experience of Web
applications. applications.
4.5. Location-when-logout parameter 4.5. Location-when-logout parameter
Example: Example:
Authentication-Control: Digest realm="protected space", Authentication-Control: Digest realm="protected space",
skipping to change at page 16, line 10 skipping to change at page 16, line 10
The parameter "location-when-logout" specifies a location where the The parameter "location-when-logout" specifies a location where the
client is to be redirected when the user explicitly requests a client is to be redirected when the user explicitly requests a
logout. The value of this parameter MUST be a string that contains logout. The value of this parameter MUST be a string that contains
an URL location. If a given URL is not absolute, the clients MUST an URL location. If a given URL is not absolute, the clients MUST
consider it a relative URL from the current location. consider it a relative URL from the current location.
This parameter MAY be used with successfully-authenticated responses. This parameter MAY be used with successfully-authenticated responses.
If this parameter is contained in other kinds of responses, the If this parameter is contained in other kinds of responses, the
clients MUST ignore this parameter. clients MUST ignore this parameter.
When the user requests termination of an authentication period, and When the user tells the client to terminate the current
if the client currently displays a page supplied by a response with authentication period, if the client currently displays a page
this parameter, the client will be redirected to the specified supplied by a response with this parameter, the client will
location by a new GET request (as if it received a 303 response). automatically change current location to the location specified in
The log-out operation (e.g. erasing memories of user name, this parameter, using a new GET request, as if it has received a 303
authentication credential and all related one-time credentials such response. Any operations related to logging-out (e.g. erasing
as nonce or keys) SHOULD occur before processing a redirection. memories of user name, authentication credential and all related one-
time credentials such as nonce or keys) SHOULD occur before
processing a page transition.
When the user requests termination of an authentication period, if When the user requests the client for the termination of an
the client supports this parameter but the server response does not authentication period, if the client supports this parameter but the
contain this parameter, the client's RECOMMENDED behavior is as server response does not contain this parameter, the client's
follows: if the request corresponding to the current content was GET RECOMMENDED behavior is as follows: if the request corresponding to
method, reload the page without the authentication credential. the current content was GET method, reload the page without the
Otherwise, keep the current content as-is and simply forget the authentication credential. Otherwise, keep the current content as-is
authentication status. The client SHOULD NOT replay a non-idempotent and simply forget the authentication status. The client SHOULD NOT
request without the user's explicit approval. replay a non-idempotent request without the user's explicit approval.
Web applications are encouraged to send this parameter with an Web applications are encouraged to send this parameter with an
appropriate value for any responses (except those with redirection appropriate value for any responses (except those with redirection
(3XX) statuses) for non-GET requests. (3XX) statuses) for non-GET requests.
See Section 5 for some examples for possible deployment of this
parameter.
4.6. Logout-timeout parameter 4.6. Logout-timeout parameter
Example: Example:
Authentication-Control: Basic realm="entrance", logout-timeout=300 Authentication-Control: Basic realm="entrance", logout-timeout=300
The parameter "logout-timeout", when contained in a successfully- The parameter "logout-timeout", when contained in a successfully-
authenticated response, means that any authentication credentials and authenticated response, means that any authentication credentials and
state related to the current protection space are to be discarded if state related to the current protection space are to be discarded if
a time specified in this header (in seconds) has passed since from a time specified in this header (in seconds) has passed since the
the time this header was received. The value MUST be an integer. As time this header was received. The value MUST be an integer. As a
a special case, the value 0 means that the client is requested to special case, the value 0 means that the server is logging the client
immediately log-out from the current authentication space and revert out immediately from the current authentication space and that the
to an unauthenticated status. This does not, however, mean that the client is now returns to unauthenticated state. This does not,
long-term memories for the passwords and passwords-related details however, mean that the long-term memories for the passwords and
(such as the password reminders and auto fill-ins) should be removed. passwords-related details (such as password reminders and auto fill-
If a new timeout value is received for the same authentication space, ins) should be removed. If a new timeout value is received for the
it cancels the previous timeout and sets a new timeout. same authentication space, it cancels the previous timeout and sets a
new timeout.
4.7. Username parameter 4.7. Username parameter
Example: Example:
Authentication-Control: Basic realm="configuration", username="admin" Authentication-Control: Basic realm="configuration", username="admin"
The parameter "username" tells that the only "user name" to be The parameter "username" tells that the only "user name" to be
accepted by the server is the value given in this parameter. This accepted by the server is the value given in this parameter.
parameter is particularly useful, for example, for routers and other
appliances with a Web configuration interface. This parameter is particularly useful, for example, for routers and
other network appliances with a Web configuration interface. Many of
those use a HTTP Basic authentication with one predefined user name,
with many varieties such as "admin", "root", "user" etc. In current
situation, users have almost no hint about the valid user name upon
the authentication request. Some shows the valid value in a "realm"
string, some in the 401-status response page, shown _after_ the user
giving up the authentication and cancelled the authentication dialog.
If this parameter is given, the client Web browser can auto-fill the
user-name field in the authentication dialog before the users attempt
to authenticate themselves.
This parameter MAY be used with authentication-initiating responses This parameter MAY be used with authentication-initiating responses
or negatively-authenticated responses requiring another attempt of or negatively-authenticated responses requiring another attempt of
authentication. The clients MUST ignore this parameter when a authentication. The clients MUST ignore this parameter when a
response is either successfully-authenticated or intermediately- response is either successfully-authenticated or intermediately-
authenticated. authenticated.
If the authentication scheme to be used has a syntax limitation on If the authentication scheme to be used has a syntax limitation on
the allowed user names (e.g. Basic and Digest do not allow colons in the allowed user names (e.g. Basic and Digest do not allow colons in
user names), the specified value MUST follow that limitation. user names), the specified value MUST follow that limitation.
Clients SHOULD ignore any values which do not conform to such Clients SHOULD ignore any values which do not conform to such
limitations. limitations.
Also, if the used authentication scheme requires a specific style of Also, if the used authentication scheme requires a specific style of
text preparation for the user name (e.g., PRECIS [RFC7564] string text preparation for the user name (e.g., PRECIS [RFC7564] string
preparation or Unicode normalization), the server SHOULD send the preparation or Unicode normalization), the server SHOULD send the
values satisfying such requirements (so that clients can use the values satisfying such requirements (so that clients can use the
given user name as is). given user name as is).
Clients MAY still send any authentication requests with other user Clients MAY still send any authentication requests with other user
names, possibly in vain. Servers are not strictly required to reject names, possibly in vain. Clients are not required (also not
user names other than specified, but doing so will give bad user forbidden) to give users opportunities for supplying a user name
experiences and may confuse users and clients. different from the server-specified one. Servers are also not
strictly required to reject user names other than specified, but
doing so will usually give bad user experiences and may confuse users
and clients.
Although this parameter is useful in a specific class of use cases,
using it in a general use cases has many security implications and
possible pit-falls. Please consult Section 8.1 before deciding to
use this parameter.
5. Usage examples 5. Usage examples
This section shows some examples for applying this extension to This section shows some examples for applying this extension to
typical websites which are using Forms and cookies for managing typical websites which are using Forms and cookies for managing
authentication and authorization. The content of this section is not authentication and authorization. The content of this section is not
normative and for illustrative purposes only. normative and for illustrative purposes only.
In these examples, we assume that there are two kinds of clients (Web In these examples, we assume that there are two kinds of clients (Web
browsers). One kind of these implements all features described in browsers). One kind of these implements all features described in
skipping to change at page 20, line 16 skipping to change at page 20, line 36
authenticate. authenticate.
o For all pages for POST requests, it is advisable to have o For all pages for POST requests, it is advisable to have
"location-when-logout=<some page>", too. "location-when-logout=<some page>", too.
o De-authentication pages are not needed. If the site will have o De-authentication pages are not needed. If the site will have
one, put "logout-timeout=0" there. one, put "logout-timeout=0" there.
5.3. When to use Cookies 5.3. When to use Cookies
In the current Web sites using form-based authentications, Cookies In current Web sites using form-based authentication, Cookies
[RFC6265] are used for managing both authorization and application [RFC6265] are used for managing both authorization and application
sessions. Using the extensions in this document, the former features sessions. Using the extensions in this document, the former features
will be provided by using (extended) HTTP authentication/ will be provided by using (extended) HTTP authentication/
authorization mechanisms. In some cases, there will be ambiguity on authorization mechanisms. In some cases, there will be ambiguity on
whether some functions are for authorization management or for whether some functions are for authorization management or for
session management. The following hints will be helpful for deciding session management. The following hints will be helpful for deciding
which features to use. which features to use.
o If there is a need to serve multiple sessions for a single user o If there is a need to serve multiple sessions for a single user
using multiple browsers concurrently, use a Cookie for using multiple browsers concurrently, use a Cookie for
skipping to change at page 20, line 45 skipping to change at page 21, line 18
their consoles and browsers hijacked (i.e. benefits are on the their consoles and browsers hijacked (i.e. benefits are on the
users' side). In such cases, the time-out features provided in users' side). In such cases, the time-out features provided in
this extension can be used. On the other hand, the requirement is this extension can be used. On the other hand, the requirement is
to protect server's privilege (e.g. when some regulations require to protect server's privilege (e.g. when some regulations require
to limit the time difference between user's two-factor to limit the time difference between user's two-factor
authentication and financial transaction commitment; the authentication and financial transaction commitment; the
requirement is strictly on the servers' side), that should be requirement is strictly on the servers' side), that should be
managed on the server side using Cookies or other session managed on the server side using Cookies or other session
management mechanisms. management mechanisms.
5.4. Parallel deployment with Form/Cookie authentications 5.4. Parallel deployment with Form/Cookie authentication
In some transition periods, sites can need to support both HTTP-layer In some transition periods, sites can need to support both HTTP-layer
and form-based authentication. The following example shows one way and form-based authentication. The following example shows one way
to achieve that. to achieve that.
o If Cookies are used even for HTTP-authenticated users, each o If Cookies are used even for HTTP-authenticated users, each
session determined by Cookies SHOULD identify which authentication session determined by Cookies SHOULD identify which authentication
has been used for the session. has been used for the session.
o First, set up any of the above settings for enabling HTTP-layer o First, set up any of the above settings for enabling HTTP-layer
skipping to change at page 21, line 21 skipping to change at page 21, line 40
o For unauthenticated users, add the following things to the Web o For unauthenticated users, add the following things to the Web
pages, unless the client supports this extension and HTTP-level pages, unless the client supports this extension and HTTP-level
authentication. authentication.
* For non-mandatory authenticated pages, put a link to Form-based * For non-mandatory authenticated pages, put a link to Form-based
authenticated pages. authenticated pages.
* For mandatory authenticated pages, either put a link to Form- * For mandatory authenticated pages, either put a link to Form-
based authenticated pages, or put a HTML-level redirection based authenticated pages, or put a HTML-level redirection
(using >META http-equiv="refresh" ...< element) to such pages. (using <META http-equiv="refresh" ...> element) to such pages.
o In Form-based authenticated pages, if users are not authenticated, o In Form-based authenticated pages, if users are not authenticated,
the page can provide a redirection for HTTP-level authentication the page can provide a redirection for HTTP-level authentication
by "location-when-unauthenticated" setting. by "location-when-unauthenticated" setting.
o Users are identified to authorization and content customization by o Users are identified to authorization and content customization by
the following logic. the following logic.
* First, check the result of the HTTP-level authentication. If * First, check the result of the HTTP-level authentication. If
there is a Cookie session tied to a specific user, both should there is a Cookie session tied to a specific user, both should
skipping to change at page 22, line 18 skipping to change at page 22, line 37
"-<bare-token>.<domain-name>", where <domain-name> is a validly "-<bare-token>.<domain-name>", where <domain-name> is a validly
registered (sub-)domain name on the Internet owned by the party who registered (sub-)domain name on the Internet owned by the party who
defines the extensions. Any unknown parameter name is to be ignored defines the extensions. Any unknown parameter name is to be ignored
regardless of whether it is an extension-token or a bare-token. regardless of whether it is an extension-token or a bare-token.
7. IANA Considerations 7. IANA Considerations
This document defines two new entries for the "Permanent Message This document defines two new entries for the "Permanent Message
Header Field Names" registry. Header Field Names" registry.
+---------------------------+----------+----------------------------+ +-------------+---------------------------+-------------------------+
| Header Field Name | Protocol | Specification | | | Entry 1: | Entry 2: |
+---------------------------+----------+----------------------------+ +-------------+---------------------------+-------------------------+
| Optional-WWW-Authenticate | http | Section 3 of this document | | Header | Optional-WWW-Authenticate | Authentication-Control |
| Authentication-Control | http | Section 4 of this document | | Field Name | | |
+---------------------------+----------+----------------------------+ | Protocol | http | http |
| Status | experimental | experimental |
| Change | IETF | IETF |
| Control | | |
| Spec. | Section 3 of this | Section 4 of this |
| Document | document | document |
+-------------+---------------------------+-------------------------+
This document also establishes a registry for HTTP authentication This document also establishes a registry for HTTP authentication
control parameters. The registry manages case-insensitive ASCII control parameters. The registry manages case-insensitive ASCII
strings. The string MUST follow the extensive-token syntax defined strings. The string MUST follow the extensive-token syntax defined
in Section 2.2. in Section 2.2.
To acquire registered tokens, a specification for the use of such To acquire registered tokens, a specification for the use of such
tokens MUST be available as a publicly-accessible documents, as tokens MUST be available as a publicly-accessible document, as
outlined as "Specification Required" level in [RFC5226]. outlined as "Specification Required" level in [RFC5226].
Registrations for authentication control parameters are required to Registrations for authentication control parameters are required to
include a description of the control extension. New registrations include a description of the control extension. New registrations
are advised to provide the following information: are advised to provide the following information:
o Token: a token used in HTTP headers for identifying the algorithm. o Token: a token used in HTTP headers for identifying the algorithm.
o Specification: A reference for a specification defining the o Specification: A reference for a specification defining the
algorithm. algorithm.
skipping to change at page 23, line 21 skipping to change at page 23, line 39
| location-when-logout | Section 4.5 of this document | | location-when-logout | Section 4.5 of this document |
| logout-timeout | Section 4.6 of this document | | logout-timeout | Section 4.6 of this document |
| username | Section 4.7 of this document | | username | Section 4.7 of this document |
+-------------------------------+------------------------------+ +-------------------------------+------------------------------+
8. Security Considerations 8. Security Considerations
The purpose of the log-out timeout feature in the Authentication- The purpose of the log-out timeout feature in the Authentication-
control header is to protect users of clients from impersonation control header is to protect users of clients from impersonation
caused by an attacker having access to the same console. The server caused by an attacker having access to the same console. The server
application implementer SHOULD be aware that the directive may always application implementers SHOULD be aware that the directive may
be ignored by either malicious clients or clients not supporting this always be ignored by either malicious clients or clients not
extension. If the purpose of introducing a timeout for an supporting this extension. If the purpose of introducing a timeout
authentication period is to protect server-side resources, this for an authentication period is to protect server-side resources,
protection MUST be implemented by other means such as HTTP Cookies this protection MUST be implemented by other means such as HTTP
[RFC6265]. Cookies [RFC6265].
All parameters in the Authentication-Control header SHOULD NOT be All parameters in the Authentication-Control header SHOULD NOT be
used for any security-enforcement purposes. Server-side applications used for any security-enforcement purposes. Server-side applications
MUST NOT assume that the header will be honored by clients and users. MUST NOT assume that the header will be honored by clients and users.
8.1. Security implication of the username parameter
The "username" parameter sometimes reveals sensitive information The "username" parameter sometimes reveals sensitive information
about the HTTP server and its configurations, useful for security about the HTTP server and its configurations, useful for security
attacks. The use of the "username" parameter SHOULD be limited to attacks. In general, security common practice suggests that any kind
cases where the all of the following conditions are met: of information on the existence/non-existence of specific user-name
shall not be disclosed before the successful authentication.
Obviously, the "username" parameter contradicts with this practice.
Given this background, the use of the "username" parameter SHOULD be
strictly limited to cases where the all of the following conditions
are met:
(1) the valid user name is pre-configured and not modifiable (such (1) the valid user name is pre-configured and not modifiable (such
as root, admin or similar ones); as root, admin or similar ones);
(2) the valid user name for such an appliance is publicly known (for (2) the valid user name for such an appliance is publicly known (for
example, written in a manual document); and example, written in a manual document); and
(3) either the valid user name for the server is easily guessable by (3) either the valid user name for the server is easily guessable by
other means (for example, from the model number shown in an other means (for example, from the model number shown in an
unauthenticated page), or the server is only accessible from unauthenticated page), or the server is accessible only from
limited networks. limited networks.
Most importantly, the "username" parameter SHOULD NOT be used in any Most importantly, the "username" parameter SHOULD NOT be used in any
case when the valid user names can be changed by users or case when the valid user names can be changed/configured by users or
administrators. administrators.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 24, line 41 skipping to change at page 25, line 22
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235, Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014, DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>. <http://www.rfc-editor.org/info/rfc7235>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-httpauth-mutual]
Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
T., and Y. Ioku, "Mutual Authentication Protocol for
HTTP", draft-ietf-httpauth-mutual-09 (work in progress),
August 2016.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>. <http://www.rfc-editor.org/info/rfc6265>.
[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols", Internationalized Strings in Application Protocols",
RFC 7564, DOI 10.17487/RFC7564, May 2015, RFC 7564, DOI 10.17487/RFC7564, May 2015,
<http://www.rfc-editor.org/info/rfc7564>. <http://www.rfc-editor.org/info/rfc7564>.
[RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-
Authentication-Info Response Header Fields", RFC 7615,
DOI 10.17487/RFC7615, September 2015,
<http://www.rfc-editor.org/info/rfc7615>.
[W3C.REC-webstorage-20130730] [W3C.REC-webstorage-20130730]
Hickson, I., "Web Storage", World Wide Web Consortium Hickson, I., "Web Storage", World Wide Web Consortium
Recommendation REC-webstorage-20130730, July 2013, Recommendation REC-webstorage-20130730, July 2013,
<http://www.w3.org/TR/2013/REC-webstorage-20130730>. <http://www.w3.org/TR/2013/REC-webstorage-20130730>.
Appendix A. (Informative) Applicability of features for each messages Appendix A. (Informative) Applicability of features for each messages
This section provides a cross-reference table showing the This section provides a cross-reference table showing the
applicability of the features provided in this specification to each applicability of the features provided in this specification to each
kind of responses described in Section 2.1. The table provided in kind of responses described in Section 2.1. The table provided in
skipping to change at page 25, line 41 skipping to change at page 26, line 26
Legends: Legends:
O = MAY contain; n = SHOULD NOT contain; N = MUST NOT contain O = MAY contain; n = SHOULD NOT contain; N = MUST NOT contain
i = SHOULD be ignored; I = MUST be ignored; i = SHOULD be ignored; I = MUST be ignored;
- = meaningless (to be ignored) - = meaningless (to be ignored)
Appendix B. (Informative) Draft Change Log Appendix B. (Informative) Draft Change Log
[To be removed on final publication] [To be removed on final publication]
B.1. Changes in Httpauth WG Revision 08 B.1. Changes in Httpauth WG Revision 09
o More comments are reflected to the text.
B.2. Changes in Httpauth WG Revision 08
o Typo fixed. o Typo fixed.
o Authors' addresses updated. o Authors' addresses updated.
B.2. Changes in Httpauth WG Revision 07 B.3. Changes in Httpauth WG Revision 07
o WGLC comments are reflected to the text. o WGLC comments are reflected to the text.
B.3. Changes in Httpauth WG Revision 06 B.4. Changes in Httpauth WG Revision 06
o Several comments from reviewers are reflected to the text. o Several comments from reviewers are reflected to the text.
B.4. Changes in Httpauth WG Revision 05 B.5. Changes in Httpauth WG Revision 05
o Authors' addresses updated. o Authors' addresses updated.
B.5. Changes in Httpauth WG revision 04 B.6. Changes in Httpauth WG revision 04
o IANA consideration section added. o IANA consideration section added.
B.6. Changes in Httpauth WG revision 03 B.7. Changes in Httpauth WG revision 03
o Adopting RFC 5987 extended syntax for non-ASCII parameter values. o Adopting RFC 5987 extended syntax for non-ASCII parameter values.
B.7. Changes in Httpauth WG revision 02 B.8. Changes in Httpauth WG revision 02
o Added realm parameter. o Added realm parameter.
o Added username parameter. We acknowledge Michael Sweet's proposal o Added username parameter. We acknowledge Michael Sweet's proposal
for including this to the Basic authentication. for including this to the Basic authentication.
B.8. Changes in Httpauth WG revision 01 B.9. Changes in Httpauth WG revision 01
o Clarification on peers' responsibility about handling of relative o Clarification on peers' responsibility about handling of relative
URLs. URLs.
o Automatic reloading should be allowed only on safe methods, not o Automatic reloading should be allowed only on safe methods, not
always on idempotent methods. always on idempotent methods.
B.9. Changes in Httpauth revision 00 and HttpBis revision 00 B.10. Changes in Httpauth revision 00 and HttpBis revision 00
None. None.
B.10. Changes in revision 02 B.11. Changes in revision 02
o Added usage examples. o Added usage examples.
B.11. Changes in revision 01 B.12. Changes in revision 01
o Syntax notations and parsing semantics changed to match httpbis o Syntax notations and parsing semantics changed to match httpbis
style. style.
B.12. Changes in revision 00 B.13. Changes in revision 00
o Separated from HTTP Mutual authentication proposal (-09). o Separated from HTTP Mutual authentication proposal (-09).
o Adopting httpbis works as a referencing point to HTTP. o Adopting httpbis works as a referencing point to HTTP.
o Generalized, now applicable for all HTTP authentication schemes. o Generalized, now applicable for all HTTP authentication schemes.
o Added "no-auth" and "auth-style" parameters. o Added "no-auth" and "auth-style" parameters.
o Loosened standardization requirements for parameter-name tokens o Loosened standardization requirements for parameter-name tokens
 End of changes. 66 change blocks. 
150 lines changed or deleted 189 lines changed or added

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