draft-ietf-httpauth-extension-00.txt   draft-ietf-httpauth-extension-01.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: January 2, 2014 RISEC, AIST Expires: April 24, 2014 RISEC, AIST
B. Kihara
T. Hayashi T. Hayashi
Lepidum Lepidum
Y. Ioku Y. Ioku
Yahoo! Japan Individual
July 1, 2013 October 21, 2013
HTTP Authentication Extensions for Interactive Clients HTTP Authentication Extensions for Interactive Clients
draft-ietf-httpauth-extension-00 draft-ietf-httpauth-extension-01
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 46 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 January 2, 2014. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 3, line 32 skipping to change at page 3, line 32
5.1.2. Case 2: specific action required on log-out . . . . . 15 5.1.2. Case 2: specific action required on log-out . . . . . 15
5.1.3. Case 3: specific page displayed before log-in . . . . 16 5.1.3. Case 3: specific page displayed before log-in . . . . 16
5.2. Example 2: authenticated user-only sites . . . . . . . . . 16 5.2. Example 2: authenticated user-only sites . . . . . . . . . 16
5.3. When to use Cookies . . . . . . . . . . . . . . . . . . . 16 5.3. When to use Cookies . . . . . . . . . . . . . . . . . . . 16
5.4. Parallel deployment with Form/Cookie authentications . . . 17 5.4. Parallel deployment with Form/Cookie authentications . . . 17
6. Methods to extend this protocol . . . . . . . . . . . . . . . 18 6. Methods to extend this protocol . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. (Informative) Applicability of features for each Appendix A. (Informative) Applicability of features for each
messages . . . . . . . . . . . . . . . . . . . . . . 20 messages . . . . . . . . . . . . . . . . . . . . . . 20
Appendix B. (Informative) Draft Notes . . . . . . . . . . . . . . 20 Appendix B. (Informative) Draft Notes . . . . . . . . . . . . . . 20
Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 21 Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 21
C.1. Changes in Httpauth revision 00 . . . . . . . . . . . . . 21 C.1. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 21
C.2. Changes in HttpBis revision 00 . . . . . . . . . . . . . . 21 C.2. Changes in Httpauth revision 00 and HttpBis revision 00 . 21
C.3. Changes in revision 02 . . . . . . . . . . . . . . . . . . 21 C.3. Changes in revision 02 . . . . . . . . . . . . . . . . . . 21
C.4. Changes in revision 01 . . . . . . . . . . . . . . . . . . 21 C.4. Changes in revision 01 . . . . . . . . . . . . . . . . . . 21
C.5. Changes in revision 00 . . . . . . . . . . . . . . . . . . 21 C.5. Changes in revision 00 . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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 11, line 52 skipping to change at page 11, line 52
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
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 MUST be for the entire Web application. The value of this parameter is a
a string that contains an absolute URL location. If a given URL is string that contains an absolute URL location. Senders MUST always
not absolute, the clients MAY consider it a relative URL from the send an absolute URL location. If a received URL is not absolute,
current location. the clients SHOULD either ignore it or consider it a relative URL
from the current location.
This parameter MAY be used with a 401 response for authentication- This parameter MAY be used with a 401 response for authentication-
initializing response. It can also be contained, although initializing response. It can also be contained, although
NOT RECOMMENDED, in a positive response with an NOT RECOMMENDED, in a positive response with an
Optional-WWW-Authenticate header. The clients MUST ignore this Optional-WWW-Authenticate header. The clients MUST ignore this
parameter, when a response is either successfully-authenticated or parameter, when a response is either successfully-authenticated or
intermediately-authenticated. The clients SHOULD ignore this intermediately-authenticated. The clients SHOULD ignore this
parameter when a response is a negatively-authenticated one (the case parameter when a response is a negatively-authenticated one (the case
is unlikely to happen, though). is unlikely to happen, though).
skipping to change at page 13, line 43 skipping to change at page 13, line 44
the client currently displays a page supplied by a response with this the client currently displays a page supplied by a response with this
parameter, the client will be redirected to the specified location by parameter, the client will be redirected to the specified location by
a new GET request (as if it received a 303 response). The log-out a new GET request (as if it received a 303 response). The log-out
operation (e.g. erasing memories of user name, authentication operation (e.g. erasing memories of user name, authentication
credential and all related one-time credentials such as nonce or credential and all related one-time credentials such as nonce or
keys) SHOULD occur before processing a redirection. keys) SHOULD occur before processing a redirection.
When the user requests to terminate an authentication period, if the When the user requests to terminate an authentication period, if the
client supports this parameter but the server response does not client supports this parameter but the server response does not
contain this parameter, the client's RECOMMENDED behavior is as contain this parameter, the client's RECOMMENDED behavior is as
follows: if the request corresponding to the current content was follows: if the request corresponding to the current content was safe
idempotent (e.g. GET), reload the page without the authentication (e.g. GET), reload the page without the authentication credential.
credential. If the request was non-idempotent (e.g. POST), keep the If the request was non-idempotent (e.g. POST), keep the current
current content as-is and simply forget the authentication status. content as-is and simply forget the authentication status. The
The client SHOULD NOT replay a non-idempotent request without the client SHOULD NOT replay a non-idempotent request without the user's
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
Authentication-Control: Basic logout-timeout=300 Authentication-Control: Basic logout-timeout=300
The parameter "logout-timeout", when contained in a successfully- The parameter "logout-timeout", when contained in a successfully-
skipping to change at page 18, line 39 skipping to change at page 18, line 39
Extension-tokens MAY be freely used for any non-standard, private, Extension-tokens MAY be freely used for any non-standard, private,
and/or experimental uses. The extension-tokens MUST be with format and/or experimental uses. The extension-tokens MUST be with format
"-<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. Unknown parameter names are to be ignored defines the extensions. Unknown parameter names are to be ignored
regardless of whether it is extension-tokens or bare-tokens. regardless of whether it is extension-tokens or bare-tokens.
7. IANA Considerations 7. IANA Considerations
The header "Optional-WWW-Authenticate" and "Authentication-Control"
should be registered to IANA registry appropriately (TO-DO).
Tokens used for the authentication control parameters may be either Tokens used for the authentication control parameters may be either
extension-tokens or bare-tokens as outlined in Section 2.2. When extension-tokens or bare-tokens as outlined in Section 2.2. When
bare-tokens are used in this protocol, these MUST be allocated by bare-tokens are used in this protocol, these MUST be allocated by
IANA. Any tokens used for non-private, non-experimental parameters IANA. Any tokens used for non-private, non-experimental parameters
are RECOMMENDED to be registered to IANA, regardless of the kind of are RECOMMENDED to be registered to IANA, regardless of the kind of
tokens used. tokens used.
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 documents, as
outlined as "Specification Required" level in [RFC5226]. outlined as "Specification Required" level in [RFC5226].
skipping to change at page 19, line 30 skipping to change at page 19, line 33
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 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-httpbis-p1-messaging] [I-D.ietf-httpbis-p1-messaging]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-22 (work in progress), draft-ietf-httpbis-p1-messaging-24 (work in progress),
February 2013. September 2013.
[I-D.ietf-httpbis-p7-auth] [I-D.ietf-httpbis-p7-auth]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-22 (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-24
(work in progress), February 2013. (work in progress), September 2013.
[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.
9.2. Informative References 9.2. Informative References
[I-D.ietf-httpauth-mutual] [I-D.ietf-httpauth-mutual]
Oiwa, Y., Watanabe, H., Takagi, H., Kihara, B., Hayashi, Oiwa, Y., Watanabe, H., Takagi, H., Hayashi, T., and Y.
T., and Y. Ioku, "Mutual Authentication Protocol for Ioku, "Mutual Authentication Protocol for HTTP",
HTTP", draft-ietf-httpauth-mutual-00 (work in progress), draft-ietf-httpauth-mutual-01 (work in progress),
July 2013. October 2013.
[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.CR-webstorage-20111208]
Hickson, I., "Web Storage", World Wide Web Consortium Hickson, I., "Web Storage", World Wide Web Consortium
CR CR-webstorage-20111208, December 2011, CR CR-webstorage-20111208, December 2011,
<http://www.w3.org/TR/2011/CR-webstorage-20111208>. <http://www.w3.org/TR/2011/CR-webstorage-20111208>.
Appendix A. (Informative) Applicability of features for each messages Appendix A. (Informative) Applicability of features for each messages
skipping to change at page 21, line 13 skipping to change at page 21, line 18
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 revision 00 C.1. Changes in Httpauth WG revision 01
None. o Clarification on peers' responsibility about handling of relative
URLs.
C.2. Changes in HttpBis revision 00 o Automatic reloading should be allowed only on safe methods, not
always on idempotent methods.
C.2. Changes in Httpauth revision 00 and HttpBis revision 00
None. None.
C.3. Changes in revision 02 C.3. Changes in revision 02
o Added usage examples. o Added usage examples.
C.4. Changes in revision 01 C.4. Changes in revision 01
o Syntax notations and parsing semantics changed to match httpbis o Syntax notations and parsing semantics changed to match httpbis
skipping to change at page 22, line 32 skipping to change at page 22, line 32
JP JP
Hiromitsu Takagi Hiromitsu Takagi
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Research Institute for Secure Systems Research Institute for Secure Systems
Tsukuba Central 2 Tsukuba Central 2
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Boku Kihara
Lepidum Co. Ltd.
#602, Village Sasazuka 3
1-30-3 Sasazuka
Shibuya-ku, Tokyo
JP
Tatsuya Hayashi Tatsuya Hayashi
Lepidum Co. Ltd. Lepidum Co. Ltd.
#602, Village Sasazuka 3 #602, Village Sasazuka 3
1-30-3 Sasazuka 1-30-3 Sasazuka
Shibuya-ku, Tokyo Shibuya-ku, Tokyo
JP JP
Yuichi Ioku Yuichi Ioku
Yahoo! Japan, Inc. Individual
Midtown Tower
9-7-1 Akasaka
Minato-ku, Tokyo
JP
 End of changes. 20 change blocks. 
38 lines changed or deleted 40 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/