draft-ietf-httpauth-extension-01.txt   draft-ietf-httpauth-extension-02.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: April 24, 2014 RISEC, AIST Expires: February 20, 2015 RISEC, AIST
T. Hayashi T. Hayashi
Lepidum Lepidum
Y. Ioku Y. Ioku
Individual Individual
October 21, 2013 August 19, 2014
HTTP Authentication Extensions for Interactive Clients HTTP Authentication Extensions for Interactive Clients
draft-ietf-httpauth-extension-01 draft-ietf-httpauth-extension-02
Abstract Abstract
This document specifies a few extensions of HTTP authentication This document specifies a few extensions of HTTP authentication
framework for interactive clients. Recently, fundamental features of framework for interactive clients. Recently, fundamental features of
HTTP-level authentication is not enough for complex requirements of HTTP-level authentication is not enough for complex requirements of
various Web-based applications. This makes these applications to various Web-based applications. This makes these applications to
implement their own authentication frameworks using HTML Forms and implement their own authentication frameworks using HTML Forms and
other means, which becomes one of the hurdles against introducing other means, which becomes one of the hurdles against introducing
secure authentication mechanisms handled jointly by servers and user- secure authentication mechanisms handled jointly by servers and user-
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014. This Internet-Draft will expire on February 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 15 skipping to change at page 3, line 15
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terms for describing authentication protocol flow . . . . 5 2.1. Terms for describing authentication protocol flow . . . . 5
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
3. Optional Authentication . . . . . . . . . . . . . . . . . . . 8 3. Optional Authentication . . . . . . . . . . . . . . . . . . . 8
4. Authentication-Control header . . . . . . . . . . . . . . . . 9 4. Authentication-Control header . . . . . . . . . . . . . . . . 9
4.1. Auth-style parameter . . . . . . . . . . . . . . . . . . . 11 4.1. Auth-style parameter . . . . . . . . . . . . . . . . . . . 11
4.2. Location-when-unauthenticated parameter . . . . . . . . . 11 4.2. Location-when-unauthenticated parameter . . . . . . . . . 12
4.3. No-auth parameter . . . . . . . . . . . . . . . . . . . . 12 4.3. No-auth parameter . . . . . . . . . . . . . . . . . . . . 13
4.4. Location-when-logout parameter . . . . . . . . . . . . . . 13 4.4. Location-when-logout parameter . . . . . . . . . . . . . . 13
4.5. Logout-timeout . . . . . . . . . . . . . . . . . . . . . . 14 4.5. Logout-timeout parameter . . . . . . . . . . . . . . . . . 14
5. Usage examples (informative) . . . . . . . . . . . . . . . . . 14 4.6. Username parameter . . . . . . . . . . . . . . . . . . . . 15
5.1. Example 1: a portal site . . . . . . . . . . . . . . . . . 14 5. Usage examples (informative) . . . . . . . . . . . . . . . . . 15
5.1.1. Case 1: a simple application . . . . . . . . . . . . . 15 5.1. Example 1: a portal site . . . . . . . . . . . . . . . . . 16
5.1.2. Case 2: specific action required on log-out . . . . . 15 5.1.1. Case 1: a simple application . . . . . . . . . . . . . 16
5.1.3. Case 3: specific page displayed before log-in . . . . 16 5.1.2. Case 2: specific action required on log-out . . . . . 16
5.2. Example 2: authenticated user-only sites . . . . . . . . . 16 5.1.3. Case 3: specific page displayed before log-in . . . . 17
5.3. When to use Cookies . . . . . . . . . . . . . . . . . . . 16 5.2. Example 2: authenticated user-only sites . . . . . . . . . 17
5.4. Parallel deployment with Form/Cookie authentications . . . 17 5.3. When to use Cookies . . . . . . . . . . . . . . . . . . . 18
6. Methods to extend this protocol . . . . . . . . . . . . . . . 18 5.4. Parallel deployment with Form/Cookie authentications . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Methods to extend this protocol . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. (Informative) Applicability of features for each Appendix A. (Informative) Applicability of features for each
messages . . . . . . . . . . . . . . . . . . . . . . 20 messages . . . . . . . . . . . . . . . . . . . . . . 21
Appendix B. (Informative) Draft Notes . . . . . . . . . . . . . . 20 Appendix B. (Informative) Draft Notes . . . . . . . . . . . . . . 22
Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 21 Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 22
C.1. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 21 C.1. Changes in Httpauth WG revision 02 . . . . . . . . . . . . 22
C.2. Changes in Httpauth revision 00 and HttpBis revision 00 . 21 C.2. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 23
C.3. Changes in revision 02 . . . . . . . . . . . . . . . . . . 21 C.3. Changes in Httpauth revision 00 and HttpBis revision 00 . 23
C.4. Changes in revision 01 . . . . . . . . . . . . . . . . . . 21 C.4. Changes in revision 02 . . . . . . . . . . . . . . . . . . 23
C.5. Changes in revision 00 . . . . . . . . . . . . . . . . . . 21 C.5. Changes in revision 01 . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 C.6. Changes in revision 00 . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The document proposes several extensions to the current HTTP The document proposes several extensions to the current HTTP
authentication framework, to provide enough functionality comparable authentication framework, to provide enough functionality comparable
with current widely-used form-based Web authentication. A majority with current widely-used form-based Web authentication. A majority
of the recent Web-sites on the Internet use custom application-layer of the recent Web-sites 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, too) authentication method does not have enough (and Digest, too) authentication method does not have enough
skipping to change at page 5, line 12 skipping to change at page 5, line 12
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
HTTP Authentication defined in [I-D.ietf-httpbis-p7-auth] may involve HTTP Authentication defined in [RFC7235] may involve with several
with several pairs of HTTP requests/responses. Throughout this pairs of HTTP requests/responses. Throughout this document, the
document, the following terms are used to categorize those messages: following terms are used to categorize those messages: for requests,
for requests,
o A non-authenticating request is a request not attempting any o A non-authenticating request is a request not attempting any
authentication: a request without any Authorization header. authentication: a request without any Authorization header.
o An authenticating request is the opposite: a request with an o An authenticating request is the opposite: a request with an
Authorization header. Authorization header.
For responses, For responses,
1) A non-authenticated response: is a response which does not 1) A non-authenticated response: is a response which does not
skipping to change at page 6, line 47 skipping to change at page 6, line 47
credential. Clients typically erase memory of the currently-using credential. Clients typically erase memory of the currently-using
credentials and ask the user for other ones. credentials and ask the user for other ones.
Usually the format of these responses are as same as the one for Usually the format of these responses are as same as the one for
authentication-initializing responses. Client can distinguish it authentication-initializing responses. Client can distinguish it
by comparing the protection spaces contained in the request and in by comparing the protection spaces contained in the request and in
the response. the response.
Figure 1 shows a state diagram of generic HTTP authentication with Figure 1 shows a state diagram of generic HTTP authentication with
the above message categorization. Note that many authentication the above message categorization. Note that many authentication
schemes uses only a subset of the transitions described on the schemes use only a subset of the transitions described on the
diagram. Labels in the figure show the abbreviated names of response diagram. Labels in the figure show the abbreviated names of response
types. types.
=========== ----------------- =========== -----------------
NEW REQUEST ( UNAUTHENTICATED ) NEW REQUEST ( UNAUTHENTICATED )
=========== ----------------- =========== -----------------
| ^ non-auth. | ^ non-auth.
v | response v | response
+----------------------+ NO +-------------+ +----------------------+ NO +-------------+
| The requested URI |--------------------------->| send normal | | The requested URI |--------------------------->| send normal |
| known to be auth'ed? | ---------------->| request | | known to be auth'ed? | ---------------->| request |
+----------------------+ / +-------------+ +----------------------+ / +-------------+
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 )<------|credentials|
| | ---------------- | known? | | | ---------------- | known? |
v | +-----------+ v | +-----------+
+-----------+ negative ------------- negative |YES +-----------+ negative ------------- negative |YES
skipping to change at page 7, line 50 skipping to change at page 7, line 50
Figure 1: Generic state diagram for HTTP authentication Figure 1: Generic state diagram for HTTP authentication
Note: (*1) For example, "Digest" scheme requires server-provided Note: (*1) For example, "Digest" scheme requires server-provided
nonces to construct client-side challenges. nonces to construct client-side challenges.
(*2) In "Basic" and some others, this cannot be distinguished from a (*2) In "Basic" and some others, this cannot be distinguished from a
successfully-authenticated response. successfully-authenticated response.
2.2. Syntax Notation 2.2. Syntax Notation
This specification uses an extended BNF syntax defined in This specification uses an extended BNF syntax defined in [RFC7230].
[I-D.ietf-httpbis-p1-messaging]. The following syntax definitions The following syntax definitions are quoted from [RFC7230] and
are quoted from [I-D.ietf-httpbis-p1-messaging] and
[I-D.ietf-httpbis-p7-auth]: auth-scheme, quoted-string, auth-param, [RFC7235]: auth-scheme, quoted-string, auth-param, SP, header-field,
SP, header-field, and challenge. It also uses the convention of and challenge. It also uses the convention of using header names for
using header names for specifying syntax of header values. specifying syntax of header values.
Additionally, this specification uses the following syntax elements Additionally, this specification uses the following syntax elements
following syntax definitions as a refinement for token and the following syntax definitions as a refinement for token and the
righthand-side of auth-param in [I-D.ietf-httpbis-p7-auth]. (Note: righthand-side of auth-param in [RFC7235]. (Note: these definitions
these definitions are consistent with those in are consistent with those in [I-D.ietf-httpauth-mutual].)
[I-D.ietf-httpauth-mutual].)
bare-token = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_") bare-token = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_")
extension-token = "-" bare-token 1*("." bare-token) extension-token = "-" bare-token 1*("." bare-token)
extensive-token = bare-token / extension-token extensive-token = bare-token / extension-token
integer = "0" / (%x31-39 *%x30-39) ; no leading zeros 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 may include private extensions. Any private acceptable tokens may include private extensions. Any private
skipping to change at page 9, line 5 skipping to change at page 8, line 48
Servers MAY send HTTP successful responses (response code 200, 206 Servers MAY send HTTP successful responses (response code 200, 206
and others) containing the Optional-WWW-Authenticate header as a and others) containing the Optional-WWW-Authenticate header as a
replacement of a 401 response when it is an authentication- replacement of a 401 response when it is an authentication-
initializing response. The Optional-WWW-Authenticate header MUST NOT initializing response. The Optional-WWW-Authenticate header MUST NOT
be contained in 401 responses. be contained in 401 responses.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Optional-WWW-Authenticate: Basic realm="xxxx" Optional-WWW-Authenticate: Basic realm="xxxx"
Optional-WWW-Authenticate = challenge Optional-WWW-Authenticate = 1#challenge
Figure 3: BNF syntax for Optional-WWW-Authenticate header Figure 3: BNF syntax for Optional-WWW-Authenticate header
The challenge 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 for a same the same as those for a 401 responses corresponding for a 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, such as initializing response). (The behavior for other matters, such as
caching, MAY be different between the optional authentication and 401 caching, MAY be different between the optional authentication and 401
messages.) messages.)
A response with an Optional-WWW-Authenticate header SHOULD be A response with an Optional-WWW-Authenticate header SHOULD be
returned from the server only when the request is either non- returned from the server only when the request is either non-
skipping to change at page 10, line 4 skipping to change at page 9, line 46
Support of this header is OPTIONAL; Clients MAY also choose any set Support of this header is OPTIONAL; Clients MAY also choose any set
of authentication schemes for which optional authentication is of authentication schemes for which optional authentication is
supported (in other words, its support MAY be scheme-dependent). supported (in other words, its support MAY be scheme-dependent).
However, some authentication schemes MAY require mandatory/ However, some authentication schemes MAY require mandatory/
recommended support for this header, so that server-side applications recommended support for this header, so that server-side applications
MAY assume that clients supporting such schemes are likely to support MAY assume that clients supporting such schemes are likely to support
the extension as well. the extension as well.
4. Authentication-Control header 4. Authentication-Control header
Authentication-Control = auth-scheme 1*SP 1#auth-param
Authentication-Control = 1#Auth-Control-Entry
Auth-Control-Entry = auth-scheme 1*SP 1#auth-param
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 be generated layer, as opposed to WWW-Authenticate headers which will be generated
usually by the Web servers. usually by the Web servers.
Support of this header is OPTIONAL, and clients MAY choose any subset Support of this header is OPTIONAL, and clients MAY choose any subset
of these parameters to be supported. The set of supported parameters of these parameters to be supported. The set of supported parameters
MAY also be authentication scheme-dependent. However, some MAY also be authentication scheme-dependent. However, some
authentication schemes MAY require mandatory/recommended support for authentication schemes MAY require mandatory/recommended support for
some or all of the features provided in this header. some or all of the features provided in this header.
The "auth-scheme" specified in this header and other authentication- The Authentication-Control header contains one or more
related headers within the same message MUST be the same. If there "authentication control entries" each of which corresponds to a
are no authentication currently performed, and the auth-scheme single realm for a specific authentication scheme. If the
contained in this header is not recognizable for the client, the auth-scheme specified for an entry supports the HTTP "realm" feature,
whole header SHOULD be ignored. that entry MUST contain the "realm" parameter. If not, the entry
MUST NOT contain the "realm" parameter.
The header contain one or more parameters, each of which is a name- Among the multiple entries in the header, the meaningful entries in
the header are those corresponding to an auth-scheme and a realm (if
any), for which "the authentication process is being performed, or
going to be performed". In more detail,
(1) If the response is either an authentication-initializing
response or a negatively-authenticated response, there may be
multiple challenges in the WWW-Authenticate (or Optional-WWW-
Authenticate defined in this extension) header, each of which
corresponds to a different scheme and realm. The client will
determine the scheme and realm to perform an authentication, and
the entries corresponding to the chosen scheme and realm will be
meaningful.
(2) If the response is either an intermediate authenticating
response or a successfully-authenticated response, the scheme
and a realm given in the Authorization header of the HTTP
request will determine the currently-ongoing authentication
process. Only the entries correspond to that scheme and realm
are meaningful.
The server MAY send an Authentication-Control header containing non-
meaningful entries. The client MUST ignore all non-meaningful
entries it received.
Each entry contains one or more parameters, each of which is a name-
value pair. The name of each parameter MUST be an extensive-token. value pair. The name of each parameter MUST be an extensive-token.
Clients MUST ignore any unknown parameters contained in this header. Clients MUST ignore any unknown parameters contained in this header.
The entries for the same auth-scheme and the realm MUST NOT contain
the duplicated parameters for the same name.
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 SHOULD accept both quoted and unquoted representations of recipients SHOULD accept both quoted and unquoted representations of
values as defined in HTTP. If it is defined as a string, it is values as defined in HTTP. If it is defined as a string, it is
encouraged to be sent in a quoted-string form. If it defined as a encouraged to be sent in a quoted-string form. If it defined as a
token (or similar) or an integer, the value SHOULD follow the token (or similar) or an integer, the value SHOULD follow the
corresponding ABNF syntax after possible unquoting of the quoted- corresponding ABNF syntax after possible unquoting of the quoted-
string value (as defined in HTTP), and is encouraged to be sent in a string value (as defined in HTTP), and is encouraged to be sent in a
unquoted form. unquoted form.
skipping to change at page 11, line 5 skipping to change at page 11, line 26
Server-side application SHOULD always be reminded that any parameters Server-side application SHOULD always be reminded that any parameters
contained in this header MAY be ignored by clients. Also, even when contained in this header MAY be ignored by clients. Also, even when
a client accepts this header, users may always be able to circumvent a client accepts this header, users may always be able to circumvent
semantics of this header. Therefore, if this header is used for semantics of this header. Therefore, if this header is used for
security purposes, its use MUST be limited for providing some non- security purposes, its use MUST be limited for providing some non-
fundamental additional security measures valuable for end-users (such fundamental additional security measures valuable for end-users (such
as client-side log-out for protecting against console takeover). as client-side log-out for protecting against console takeover).
Server-side application MUST NOT rely on the use of this header for Server-side application MUST NOT rely on the use of this header for
protecting server-side resources. protecting server-side resources.
Note: The header syntax allows servers to specify Authentication-
Control for multiple authentication schemes, either as multiple
occurances of this header or as a combined single header (see Section
3.2.2 of [RFC7230] for rationale). The same care as for parsing
multiple authnetication challenges SHALL be taken.
4.1. Auth-style parameter 4.1. Auth-style parameter
Authentication-Control: Digest auth-style=modal Authentication-Control: Digest realm="protected space",
auth-style=modal
The parameter "auth-style" specifies the server's preferences over The parameter "auth-style" specifies the server's preferences over
user interface behavior for user authentication. This parameter can user interface behavior for user authentication. This parameter can
be included in any kind of responses, however, it is only meaningful be included in any kind of responses, however, it is only meaningful
for either authentication-initializing or negatively-authenticated for 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.
skipping to change at page 11, line 46 skipping to change at page 12, line 26
The above two different methods of authentication may introduce a The above two different methods of authentication may introduce a
observable difference of semantics when the response contains state- observable difference of semantics when the response contains state-
changing side effects; for example, it may change whether Cookie changing side effects; for example, it may change whether Cookie
headers [RFC6265] in 401 responses are processed or not. However, headers [RFC6265] in 401 responses are processed or not. However,
the server applications SHOULD NOT depend on both existence and non- the server applications SHOULD NOT depend on both existence and non-
existence of such side effects. existence of such side effects.
4.2. Location-when-unauthenticated parameter 4.2. Location-when-unauthenticated parameter
Authentication-Control: Mutual Authentication-Control: Mutual realm="auth-space-1",
location-when-unauthenticated="http://www.example.com/login.html" location-when-unauthenticated="http://www.example.com/login.html"
The parameter "location-when-unauthenticated" specifies a location The parameter "location-when-unauthenticated" specifies a location
where any unauthenticated clients should be redirected to. This where any unauthenticated clients should be redirected to. This
header may be used, for example, when there is a central login page header may be used, for example, when there is a central login page
for the entire Web application. The value of this parameter is a for the entire Web application. The value of this parameter is a
string that contains an absolute URL location. Senders MUST always string that contains an absolute URL location. Senders MUST always
send an absolute URL location. If a received URL is not absolute, send an absolute URL location. If a received URL is not absolute,
the clients SHOULD either ignore it or consider it a relative URL the clients SHOULD either ignore it or consider it a relative URL
from the current location. from the current location.
skipping to change at page 12, line 29 skipping to change at page 13, line 9
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 treat the entire response as if it were credentials, the client will treat the entire response as if it were
a 303 "See Other" response with a Location header that contains the a 303 "See Other" response with a Location header that contains the
value of this parameter (i.e., client will be redirected to the value of this parameter (i.e., client will be redirected to the
specified location with a GET request). Unlike a normal 303 specified location with a GET request). Unlike a normal 303
response, if the client can process authentication without the user's response, if the client can process authentication without the user's
interaction, this parameter MUST be ignored. interaction, this parameter MUST be ignored.
4.3. No-auth parameter 4.3. No-auth parameter
Authentication-Control: Basic 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 attempt is not to be performed on this location for authentication attempt is not to be performed on this location for
better user experience, without specifying the redirection on the better user experience, without specifying the redirection on the
HTTP level. This header may be used, for example, when there is a HTTP level. This header may be used, for example, when there is a
central login page for the entire Web application, and when a (Web central login page for the entire Web application, and when a (Web
content's level) explicit interaction of users is desired before content's level) explicit interaction of users is desired before
authentications. The value of this parameter MUST be a token "true". authentications. The value of this parameter MUST be a token "true".
If the value is incorrect, client MAY ignore this parameter. If the value is incorrect, client MAY ignore this parameter.
skipping to change at page 13, line 20 skipping to change at page 13, line 48
location-when-unauthenticated parameter. If both were supplied, location-when-unauthenticated parameter. If both were supplied,
clients MAY choose which one is to be honored. clients MAY choose which one is to be honored.
This parameter SHOULD NOT be used as any security measures to prevent This parameter SHOULD NOT be used as any security measures 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.4. Location-when-logout parameter 4.4. Location-when-logout parameter
Authentication-Control: Digest Authentication-Control: Digest realm="protected space",
location-when-logout="http://www.example.com/byebye.html" location-when-logout="http://www.example.com/byebye.html"
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 request a logout. client is to be redirected when the user explicitly request a logout.
The value of this parameter MUST be a string that contains an The value of this parameter MUST be a string that contains an
absolute URL location. If a given URL is not absolute, the clients absolute URL location. If a given URL is not absolute, the clients
MAY consider it a relative URL from the current location. MAY 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.
skipping to change at page 14, line 7 skipping to change at page 14, line 35
(e.g. GET), reload the page without the authentication credential. (e.g. GET), reload the page without the authentication credential.
If the request was non-idempotent (e.g. POST), keep the current If the request was non-idempotent (e.g. POST), keep the current
content as-is and simply forget the authentication status. The content as-is and simply forget the authentication status. The
client SHOULD NOT replay a non-idempotent request without the user's client SHOULD NOT replay a non-idempotent request without the user's
explicit approval. 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.
4.5. Logout-timeout 4.5. Logout-timeout parameter
Authentication-Control: Basic 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
states related to the current protection space are to be discarded if states related to the current protection space are to be discarded if
a time specified in this header (in seconds) has been passed from the a time specified in this header (in seconds) has been passed from the
time received. The value MUST be an integer. As a special case, the time received. The value MUST be an integer. As a special case, the
value 0 means that the client is requested to immediately log-out value 0 means that the client is requested to immediately log-out
from the current authentication space and revert to an from the current authentication space and revert to an
unauthenticated status. This does not, however, mean that the long- unauthenticated status. This does not, however, mean that the long-
term memories for the passwords (such as the password reminders and term memories for the passwords (such as the password reminders and
auto fill-ins) should be removed. If a new timeout value is received auto fill-ins) should be removed. If a new timeout value is received
for the same authentication space, it cancels the previous timeout for the same authentication space, it cancels the previous timeout
and sets a new timeout. and sets a new timeout.
4.6. Username parameter
Authentication-Control: Basic realm="configuration", username="admin"
The parameter "username" tells that the only "user name" to be
accepted by the server is the value given in this parameter. This
parameter is particularly useful, for example, for routers and other
appliances with a Web configuration interface.
This parameter MAY be used with authentication-initiating responses
or negatively-authenticated responses requiring another attempt of
authentication. The clients MUST ignore this parameter, when a
response is either successfully-authenticated or intermediately-
authenticated.
If the authentication scheme to be used has syntax limitation on the
allowed user names (e.g. Basic and Digest do not allow colons in
user names), the specified value MUST follow that limitation. Client
SHOULD ignore any values which do not conform to such limitations.
Clients MAY still send any authentication requests with other user
names, possibly in vain. Servers are not strictly required to reject
user names other than specified, but doing it will give bad user
experiences and may confuse users and clients.
5. Usage examples (informative) 5. Usage examples (informative)
This section shows some examples for applying this extension to This section shows some examples for applying this extension to
typical Web-sites which are using Forms and cookies for managing typical Web-sites 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.
We assume that all features described in the previous sections are We assume that all features described in the previous sections are
implemented in clients (Web browsers). We also assume that browsers implemented in clients (Web browsers). We also assume that browsers
will have a user interface which allows users to deactivate (log-out will have a user interface which allows users to deactivate (log-out
skipping to change at page 17, line 14 skipping to change at page 18, line 23
will be provided by using (extended) HTTP authentication/ will be provided by using (extended) HTTP authentication/
authorization mechanisms. In some cases, there will be some authorization mechanisms. In some cases, there will be some
ambiguous situations whether some functions are authorization ambiguous situations whether some functions are authorization
management or session management. The following hints will be management or session management. The following hints will be
helpful for deciding which features to be used. helpful for deciding which features to be used.
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
distinguishing between sessions for the same user. (C.f. if there distinguishing between sessions for the same user. (C.f. if there
is a need to distinguish sessions in the same browser, HTML5 Web is a need to distinguish sessions in the same browser, HTML5 Web
Storage [W3C.CR-webstorage-20111208] features may be used instead Storage [W3C.REC-webstorage-20130730] features may be used instead
of Cookies.) of Cookies.)
o If a web site is currently deploying a session time-out feature, o If a web site is currently deploying a session time-out feature,
consider who benefits from the feature. In most cases, the main consider who benefits from the feature. In most cases, the main
requirement for such feature is to protect users from their requirement for such feature is to protect users from their
consoles and browsers hijacked (i.e. benefits are on the users' consoles and browsers hijacked (i.e. benefits are on the users'
side). In such cases, the time-out features provided in this side). In such cases, the time-out features provided in this
extension may be used. On the other hand, the requirements is to extension may be used. On the other hand, the requirements 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 authentication limit the time difference between user's two-factor authentication
skipping to change at page 19, line 26 skipping to change at page 20, line 36
supporting this extension. If the purpose of introducing a timeout supporting this extension. If the purpose of introducing a timeout
for an authentication period is to protect server-side resources, for an authentication period is to protect server-side resources,
such features MUST be implemented by other means such as HTTP Cookies such features MUST be implemented by other means such as HTTP Cookies
[RFC6265]. [RFC6265].
All parameters in Authentication-Control header SHOULD NOT be used All parameters in Authentication-Control header SHOULD NOT be used
for any security-enforcement purposes. Server-side applications MUST for any security-enforcement purposes. Server-side applications MUST
be implemented always considering that the header may be either be implemented always considering that the header may be either
ignored by clients or even bypassed by users. ignored by clients or even bypassed by users.
9. References The "username" parameter may reveal sensitive information about the
HTTP server and its configurations, useful for security attacks. The
use of the "username" parameter SHOULD be limited to cases where the
all of the following conditions are met:
9.1. Normative References (1) the valid user name is pre-configured and not modifiable (such
as root, admin or similar ones);
[I-D.ietf-httpbis-p1-messaging] (2) the valid user name for such an appliance is publicly known (for
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol example, written in a manual); and
(HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-24 (work in progress),
September 2013.
[I-D.ietf-httpbis-p7-auth] (3) either the valid user name for the server is easily guessable by
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol other means (for example, from the model number shown in an
(HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-24 unauthenticated page), or the server is only accesible from
(work in progress), September 2013. limited networks.
Especially, it SHOULD NOT be used in any case when the valid user
names are configured by its users or administrators.
9. 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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230,
June 2014.
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, June 2014.
9.2. Informative References 9.2. Informative References
[I-D.ietf-httpauth-mutual] [I-D.ietf-httpauth-mutual]
Oiwa, Y., Watanabe, H., Takagi, H., Hayashi, T., and Y. Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
Ioku, "Mutual Authentication Protocol for HTTP", T., and Y. Ioku, "Mutual Authentication Protocol for
draft-ietf-httpauth-mutual-01 (work in progress), HTTP", draft-ietf-httpauth-mutual-03 (work in progress),
October 2013. August 2014.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[W3C.CR-webstorage-20111208] [W3C.REC-webstorage-20130730]
Hickson, I., "Web Storage", World Wide Web Consortium Hickson, I., "Web Storage", World Wide Web Consortium
CR CR-webstorage-20111208, December 2011, Recommendation REC-webstorage-20130730, July 2013,
<http://www.w3.org/TR/2011/CR-webstorage-20111208>. <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 cross-reference table about applicability of This section provides cross-reference table about applicability of
each features provided in this specification for each kinds of each features provided in this specification for each kinds of
responses described in Section 2.1. The table provided in this responses described in Section 2.1. The table provided in this
section is for informative purposes only. section is for informative purposes only.
+-------------------+-------+----------+-----------+------+ +-------------------+-------+----------+-----------+------+
| | init. | success. | intermed. | neg. | | | init. | success. | intermed. | neg. |
+-------------------+-------+----------+-----------+------+ +-------------------+-------+----------+-----------+------+
| Optional auth. | O | n | N | N | | Optional auth. | O | n | N | N |
| auth-style | O | - | - | O | | auth-style | O | - | - | O |
| loc.-when-unauth. | O | I | I | i | | loc.-when-unauth. | O | I | I | i |
| no-auth | O | I | I | i | | no-auth | O | I | I | i |
| loc.-when-logout | - | O | - | - | | loc.-when-logout | - | O | - | - |
| logout-timeout | - | O | - | - | | logout-timeout | - | O | - | - |
| username | O | - | - | O |
+-------------------+-------+----------+-----------+------+ +-------------------+-------+----------+-----------+------+
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 Notes Appendix B. (Informative) Draft Notes
Things which might be considered for future revisions: Things which might be considered for future revisions:
o In [I-D.ietf-httpbis-p7-auth], meaning of WWW-Authenticate headers o In [RFC7235], meaning of WWW-Authenticate headers in non-401
in non-401 responses are defined as "supplying credentials (or responses are defined as "supplying credentials (or different
different credentials) might affect the response". This credentials) might affect the response". This clarification
clarification change leaves a way for using 200-status responses change leaves a way for using 200-status responses along with a
along with a WWW-Authenticate header for providing optional WWW-Authenticate header for providing optional authentication.
authentication.
Incorporating this possibility, however, needs more detailed Incorporating this possibility, however, needs more detailed
analysis on the behavior of existing clients and intermediate analysis on the behavior of existing clients and intermediate
proxies for such possibly-confusing responses. Optional-WWW- proxies for such possibly-confusing responses. Optional-WWW-
Authenticate is safer, at least for minimum backward Authenticate is safer, at least for minimum backward
compatibility, because clients not supporting this extension will compatibility, because clients not supporting this extension will
consider this header as an unrecognized entity-header, possibly consider this header as an unrecognized entity-header, possibly
providing opportunity for silently falling-back to application- providing opportunity for silently falling-back to application-
level authentications. level authentications.
Appendix C. (Informative) Draft Change Log Appendix C. (Informative) Draft Change Log
C.1. Changes in Httpauth WG revision 01 C.1. Changes in Httpauth WG revision 02
o Added realm parameter.
o Added username parameter. We acknowledge Michael Sweet's proposal
for including this to the Basic authentication.
C.2. 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.
C.2. Changes in Httpauth revision 00 and HttpBis revision 00 C.3. Changes in Httpauth revision 00 and HttpBis revision 00
None. None.
C.3. Changes in revision 02 C.4. Changes in revision 02
o Added usage examples. o Added usage examples.
C.4. Changes in revision 01 C.5. 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.
C.5. Changes in revision 00 C.6. 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. 43 change blocks. 
93 lines changed or deleted 177 lines changed or added

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