draft-ietf-httpauth-extension-07.txt   draft-ietf-httpauth-extension-08.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 8, 2017 ITRI, AIST Expires: February 18, 2017 ITRI, AIST
K. Maeda
T. Hayashi T. Hayashi
Lepidum Lepidum
Y. Ioku Y. Ioku
Individual Individual
July 7, 2016 August 17, 2016
HTTP Authentication Extensions for Interactive Clients HTTP Authentication Extensions for Interactive Clients
draft-ietf-httpauth-extension-07 draft-ietf-httpauth-extension-08
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
skipping to change at page 1, line 45 skipping to change at page 1, line 46
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 8, 2017. This Internet-Draft will expire on February 18, 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
skipping to change at page 3, line 40 skipping to change at page 3, line 40
5.4. Parallel deployment with Form/Cookie authentications . . . 20 5.4. Parallel deployment with Form/Cookie authentications . . . 20
6. Methods to extend this protocol . . . . . . . . . . . . . . . 21 6. Methods to extend this protocol . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . 25
B.1. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 25 B.1. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 25
B.2. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 25 B.2. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 26
B.3. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 26 B.3. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 26
B.4. Changes in Httpauth WG revision 04 . . . . . . . . . . . . 26 B.4. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 26
B.5. Changes in Httpauth WG revision 03 . . . . . . . . . . . . 26 B.5. Changes in Httpauth WG revision 04 . . . . . . . . . . . . 26
B.6. Changes in Httpauth WG revision 02 . . . . . . . . . . . . 26 B.6. Changes in Httpauth WG revision 03 . . . . . . . . . . . . 26
B.7. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 26 B.7. Changes in Httpauth WG revision 02 . . . . . . . . . . . . 26
B.8. Changes in Httpauth revision 00 and HttpBis revision 00 . 26 B.8. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 26
B.9. Changes in revision 02 . . . . . . . . . . . . . . . . . . 26 B.9. Changes in Httpauth revision 00 and HttpBis revision 00 . 26
B.10. Changes in revision 01 . . . . . . . . . . . . . . . . . . 26 B.10. Changes in revision 02 . . . . . . . . . . . . . . . . . . 26
B.11. Changes in revision 00 . . . . . . . . . . . . . . . . . . 26 B.11. Changes in revision 01 . . . . . . . . . . . . . . . . . . 26
B.12. Changes in revision 00 . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
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
skipping to change at page 14, line 12 skipping to change at page 14, line 12
content. This behavior is common for most of the current content. This behavior is common for most of the current
implementations of Basic and Digest authentication schemes. implementations of Basic and Digest authentication schemes.
The value "non-modal" means that the server thinks the content of the The value "non-modal" means that the server thinks the content of the
response (body and other content-related headers) is valuable for response (body and other content-related headers) is valuable for
users before processing an authentication request. The clients are users before processing an authentication request. The clients are
expected to first process the content and then provide users the expected to first process the content and then provide users the
opportunity to perform authentication. opportunity to perform authentication.
The default behavior for clients is implementation-dependent, and it The default behavior for clients is implementation-dependent, and it
may also depending on authentication schemes. The proposed default may also depend on authentication schemes. The proposed default
behavior is "modal" for all authentication schemes unless otherwise behavior is "modal" for all authentication schemes unless otherwise
specified. specified.
The above two different methods of authentication possibly introduce The above two different methods of authentication possibly introduce
a observable difference of semantics when the response contains a observable difference of semantics when the response contains
state-changing side effects; for example, it can affect how Cookie state-changing side effects; for example, it can affect how Cookie
headers [RFC6265] in 401 responses are processed. However, the headers [RFC6265] in 401 responses are processed. However, the
server applications SHOULD NOT depend on existence of such side server applications SHOULD NOT depend on existence of such side
effects. effects.
skipping to change at page 24, line 44 skipping to change at page 24, line 44
[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] [I-D.ietf-httpauth-mutual]
Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
T., and Y. Ioku, "Mutual Authentication Protocol for T., and Y. Ioku, "Mutual Authentication Protocol for
HTTP", draft-ietf-httpauth-mutual-08 (work in progress), HTTP", draft-ietf-httpauth-mutual-09 (work in progress),
July 2016. 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>.
skipping to change at page 25, line 41 skipping to change at page 25, line 41
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 07 B.1. Changes in Httpauth WG Revision 08
o Typo fixed.
o Authors' addresses updated.
B.2. Changes in Httpauth WG Revision 07
o WGLC comments are reflected to the text. o WGLC comments are reflected to the text.
B.2. Changes in Httpauth WG Revision 06 B.3. 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.3. Changes in Httpauth WG Revision 05 B.4. Changes in Httpauth WG Revision 05
o Authors' addresses updated. o Authors' addresses updated.
B.4. Changes in Httpauth WG revision 04 B.5. Changes in Httpauth WG revision 04
o IANA consideration section added. o IANA consideration section added.
B.5. Changes in Httpauth WG revision 03 B.6. 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.6. Changes in Httpauth WG revision 02 B.7. 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.7. Changes in Httpauth WG revision 01 B.8. 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.8. Changes in Httpauth revision 00 and HttpBis revision 00 B.9. Changes in Httpauth revision 00 and HttpBis revision 00
None. None.
B.9. Changes in revision 02 B.10. Changes in revision 02
o Added usage examples. o Added usage examples.
B.10. Changes in revision 01 B.11. 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.11. Changes in revision 00 B.12. 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
skipping to change at page 27, line 20 skipping to change at page 27, line 28
Authors' Addresses Authors' Addresses
Yutaka Oiwa Yutaka Oiwa
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Information Technology Research Institute Information Technology Research Institute
Tsukuba Central 1 Tsukuba Central 1
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Email: mutual-auth-contact-ml@aist.go.jp Email: y.oiwa@aist.go.jp
Hajime Watanabe Hajime Watanabe
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Information Technology Research Institute Information Technology Research Institute
Tsukuba Central 1 Tsukuba Central 1
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Email: h-watanabe@aist.go.jp
Hiromitsu Takagi Hiromitsu Takagi
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Information Technology Research Institute Information Technology Research Institute
Tsukuba Central 1 Tsukuba Central 1
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Email: takagi.hiromitsu@aist.go.jp
Kaoru Maeda
Lepidum Co. Ltd.
Village Sasazuka 3, Suite #602
1-30-3 Sasazuka
Shibuya-ku, Tokyo
JP
Email: maeda@lepidum.co.jp
Tatsuya Hayashi Tatsuya Hayashi
Lepidum Co. Ltd. Lepidum Co. Ltd.
#602, Village Sasazuka 3 Village Sasazuka 3, Suite #602
1-30-3 Sasazuka 1-30-3 Sasazuka
Shibuya-ku, Tokyo Shibuya-ku, Tokyo
JP JP
Email: hayashi@lepidum.co.jp
Yuichi Ioku Yuichi Ioku
Individual Individual
Email: mutual-work@ioku.org
 End of changes. 25 change blocks. 
32 lines changed or deleted 54 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/