Internet Engineering Task Force Y. Oiwa Internet-Draft H. Watanabe Intended status: Standards Track H. Takagi Expires: April 27, 2012 RCIS, AIST B. Kihara T. Hayashi Lepidum Y. Ioku Yahoo! Japan October 25, 2011 HTTP Authentication Extensions for Interactive Clients draft-oiwa-http-auth-extension-00 Abstract This document specifies an extension of HTTP authentication framework for use with interactive clients. Recently, the fundamental features of HTTP-level authentication is not enough for complex requirements of various Web-based applications. This makes these applications to implement their own authentication frameworks using HTML Forms and other means, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user- agent clients. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining some upper-compatibility against existing Web and non-Web uses of HTTP authentications. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 27, 2012. Copyright Notice Oiwa, et al. Expires April 27, 2012 [Page 1] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terms for describing authentication protocol flow . . . . 4 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 3. Optional Authentication . . . . . . . . . . . . . . . . . . . 7 4. Authentication-Control header . . . . . . . . . . . . . . . . 9 4.1. Auth-style parameter . . . . . . . . . . . . . . . . . . . 9 4.2. Location-when-unauthenticated parameter . . . . . . . . . 10 4.3. No-auth parameter . . . . . . . . . . . . . . . . . . . . 11 4.4. Location-when-logout parameter . . . . . . . . . . . . . . 12 4.5. Logout-timeout . . . . . . . . . . . . . . . . . . . . . . 12 5. Usage examples [TBD] . . . . . . . . . . . . . . . . . . . . . 13 6. Methods to extend this protocol . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. (Informative) Applicability of features for each messages . . . . . . . . . . . . . . . . . . . . . . 15 Appendix B. (Informative) Draft Notes . . . . . . . . . . . . . . 15 Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 16 C.1. Changes in revision 00 . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Oiwa, et al. Expires April 27, 2012 [Page 2] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 1. Introduction The document proposes several extensions to the current HTTP authentication framework, to provide enough functionality comparable with current widely-used form-based Web authentication. A majority of the recent Web-sites on the Internet use custom application-layer authentication implementations using Web forms. The reasons for these may vary, but many people believe that the current HTTP Basic (and Digest, too) authentication method does not have enough functionality (including a good-feeling user interfaces) to support most of realistic Web-based applications. However, the method is very weak against phishing attacks, because the whole behavior of the authentication is controlled from the server side. To overcome this problem, we need to "modernize" the HTTP authentication framework so that better client-controlled secure methods can be used with Web applications. The extensions proposed in this document include: o non-mandatory, optional authentication on HTTP (Section 3), o log out from both server and client side (Section 4), and o finer control for redirection depending on authentication status (Section 4). [I-D note: These extensions are initially proposed as a part of [I-D.oiwa-http-mutualauth]. However, since these might possibly be useful in combination with other authentication schemes, the extensions were separated as an independent draft.] 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [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 regarding [RFC2119], but 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 following way: A "client" is an entity understanding and talking HTTP and the specified authentication protocol, usually computer software; a "user" is a (usually natural) person who wants to access data resources using "a client". Oiwa, et al. Expires April 27, 2012 [Page 3] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 2. Definitions 2.1. Terms for describing authentication protocol flow HTTP Authentication defined in [I-D.ietf-httpbis-p7-auth] may involve with several pairs of HTTP requests/responses. Throughout this document, the following terms are used to categorize those messages: for requests, o A non-authenticating request is a request not attempting any authentication: a request without any Authorization header. o An authenticating request is the opposite: a request with an Authorization header. For responses, 1) A non-authenticated response: is a response which does not involve with any HTTP authentication. It may not contain any WWW-Authenticate or Authentication-Info header. Servers send this response when the requested resource is not protected by HTTP authentication mechanisms. In context of this specification, not-authentication-related negative responses (e.g. 403 and 404) are also considered as non-authenticated responses. (See note on successfully-authenticated responses below for some ambiguous cases.) 2) An authentication-initializing response: is a response which requires or allows clients to start authentication attempts. Servers send this response when the requested resource is protected by HTTP authentication mechanism, and the request meets one of the following cases: * The request is non-authenticating request, or * The request contained an authentication trial directed to the protection space (realm) other than the server's expected one. The server will specify the protection space for authentication in this response. Upon reception, the client's behavior is further divided to two possible cases. * If the client may have no prior knowledge on authentication credentials (e.g. a user-name and a password) related to the Oiwa, et al. Expires April 27, 2012 [Page 4] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 requested protection space, the protocol flow terminates and the client will ask the user to provide authentication credentials, * On the other hand, if client already have an enough credentials for authentication to the requested protection space, the client will automatically send an authenticating request. Such cases often occur when the client did not know beforehand that the current request-URL requires an authentication. 3) A successfully-authenticated response: is a response for an authenticating request meaning that the authentication attempt was granted. (Note: if the authentication scheme used does not use an Authentication-Info header, it may be indistinguishable from a non-authenticated response.) 4) An intermediate authenticating response: is a response for an authenticating request which requires some more reaction by the client software without involving users. Such a response is required when an authentication scheme requires two or more round- trip messages to perform authentication, or when an authentication scheme uses some speculative short-cut method (such as uses of cached shared secrets) and it failed. 5) A negatively-authenticated response: is a response for an authenticating request which means that the authentication attempt was declined and can not continue without another authentication credential. Clients typically erase memory of the currently-using credentials and ask the user for other ones. Usually the format of these responses are as same as the one for authentication-initializing responses. Client can distinguish it by comparing the protection spaces contained in the request and in the response. Figure 1 shows a state diagram of generic HTTP authentication with the above message categorization. Note that many authentication schemes uses only a subset of the transitions described on the diagram. Labels in the figure show the abbreviated names of response types. Oiwa, et al. Expires April 27, 2012 [Page 5] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 =========== ----------------- NEW REQUEST ( UNAUTHENTICATED ) =========== ----------------- | ^ non-auth. v | response +----------------------+ NO +-------------+ | The requested URI |--------------------------->| send normal | | known to be auth'ed? | ---------------->| request | +----------------------+ / +-------------+ YES | / initializing| v / | +------------------+ NO / | | Can auth-req (*1)|--------- | | be constructed? | | +------------------+ | YES | initializing | | ---------------------------------------. | | / v v | | ---------------- NO +-----------+ | | ( AUTH-REQUESTED )<------|credentials| | | ---------------- | known? | v | +-----------+ +-----------+ negative ------------- negative |YES | send |---------->( AUTH-FAILED )<---------, | /| auth-req | ------------- | | / +-----------+\ | v | \ \ intermediate +-----------+ | \ -------------------------------->| send | | \ | auth-req | | non-auth. \successful successful +-----------+ | response (*2) \ / | ^ v \ / | | ----------------- \ -------------- / `----' ( UNAUTHENTICATED ) ----->( AUTH-SUCCEED )<---- intermediate ----------------- -------------- Figure 1: Generic state diagram for HTTP authentication Note: (*1) For example, "Digest" scheme requires server-provided nonces to construct client-side challenges. (*2) In "Basic" and some others, this cannot be distinguished from a successfully-authenticated response. 2.2. Syntax Notation This specification uses an extended BNF syntax defined in [I-D.ietf-httpbis-p1-messaging]. The following syntax definitions Oiwa, et al. Expires April 27, 2012 [Page 6] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 are quoted from [I-D.ietf-httpbis-p1-messaging] and [I-D.ietf-httpbis-p7-auth]: auth-scheme, quoted-string, auth-param, SP, header-field, and challenge. It also uses the convention of using header names for specifying syntax of header values. Additionally, this specification uses the following syntax elements following syntax definitions as a refinement for token and the righthand-side of auth-param in [I-D.ietf-httpbis-p7-auth]. Note that bare-token, extension-token and integer are subset of the token's syntax, and the extension-param is a subset of auth-param. (Note: these definitions are consistent with those in [I-D.oiwa-http-mutualauth].) bare-token = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_") extension-token = "-" bare-token 1*("." bare-token) extension-param = (bare-token / extension-token) "=" value value = bare-token / extension-token / quoted-string integer = "0" / (%x31-39 *%x30-39) ; no leading zeros Figure 2: the BNF syntax for common notations Extensive-tokens are used in this protocol where the set of acceptable tokens may include private extensions. Any private extensions of this protocol MUST use the extension-tokens with format "-.", where is a validly registered (sub-)domain name on the Internet owned by the party who defines the extensions. 3. Optional Authentication The Optional-WWW-Authenticate header enables a non-mandatory authentication, which is not possible under the current HTTP authentication mechanism. In several Web applications, users can access the same contents as both a guest user and an authenticated user. In most Web applications, it is implemented using HTTP cookies [RFC6265] and custom form-based authentications. The new authentication method using this message will provide a replacement for these authentication systems. Servers MAY send HTTP successful responses (response code 200, 206 and others) containing the Optional-WWW-Authenticate header as a replacement of a 401 response when it is an authentication- initializing response. The Optional-WWW-Authenticate header MUST NOT be contained in 401 responses. Oiwa, et al. Expires April 27, 2012 [Page 7] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 HTTP/1.1 200 OK Optional-WWW-Authenticate: Basic realm="xxxx" Optional-WWW-Authenticate = challenge Figure 3: BNF syntax for Optional-WWW-Authenticate header The challenge contained in the Optional-WWW-Authenticate header are the same as those for a 401 responses corresponding for a same request. For authentication-related matters, an optional authentication request will have the same meaning as a 401 message with a corresponding WWW-Authenticate header (as an authentication- initializing response). (The behavior for other matters, such as caching, MAY be different between the optional authentication and 401 messages.) A response with an Optional-WWW-Authenticate header SHOULD be returned from the server only when the request is either non- authenticated or authenticating to a wrong (not the server's expected) protection space. If a response is either an intermediate or a negative response to a client's authentication attempt, the server MUST respond with a 401 status response with a WWW-Authenticate header instead. Failure to comply this rule will make client not able to distinguish authentication successes and failures. The server is NOT RECOMMENDED to include an Optional-WWW-Authenticate header in a positive response when a client's authentication attempt succeeds. Whenever an authentication scheme support for servers to send some parameter which gives a hint of URL space for the corresponding protection space for the same realm (e.g. "path" or "domain"), servers requesting non-mandatory authentication SHOULD send such parameter with the response. Clients supporting non-mandatory authentication MUST recognize the parameter, and MUST send a request with an appropriate authentication credential in an Authorization header for any URI inside the specified paths. Support of this header is OPTIONAL; Clients MAY also choose any set of authentication schemes for which optional authentication is supported (in other words, its support MAY be scheme-dependent). However, some authentication schemes MAY require mandatory/ recommended support for this header, so that server-side applications MAY assume that clients supporting such schemes are likely to support the extension as well. Oiwa, et al. Expires April 27, 2012 [Page 8] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 4. Authentication-Control header Authentication-Control = auth-scheme 1*SP 1#Auth-Ctrl-params Auth-Ctrl-params = auth-style / no-auth / loc-when-unauthed / loc-when-logout / logout-timeout / extension-param auth-style = "auth-style" "=" ( "modal" / "non-modal" ) no-auth = "no-auth" "=" "true" loc-when-unauthed = "location-when-unauthenticated" "=" quoted-string loc-when-logout = "location-when-logout" "=" quoted-string logout-timeout = "logout-timeout" "=" integer Figure 4: the BNF syntax for the Authentication-Control header The Authentication-Control header provides a more precise control of the client behavior for Web applications using an HTTP authentication protocol. This header is supposed to be generated in the application layer, as opposed to WWW-Authenticate headers which will be generated by the Web servers. Support of this header is OPTIONAL, and clients MAY choose any subset of these parameters to be supported. The set of supported parameters MAY also be authentication scheme-dependent. However, some authentication schemes MAY require mandatory/recommended support for some or all of the features provided in this header. The "auth-scheme" specified in this header and other authentication- related headers within the same message MUST be the same. Clients MUST ignore any unknown parameters contained in this header. Server-side application SHOULD always be reminded that any parameters contained in this header MAY be ignored by clients. Also, even when a client accepts this header, users may always be able to circumvent semantics of this header. Therefore, if this header is used for security purposes, its use MUST be limited for providing some non- fundamental additional security measures valuable for end-users (such as client-side log-out for protecting against console takeover). Server-side application MUST NOT rely on the use of this header for protecting server-side resources. 4.1. Auth-style parameter Authentication-Control: Digest auth-style=modal The parameter "auth-style" specifies the server's preferences over user interface behavior for user authentication. This parameter can be included in any kind of responses, however, it is only meaningful for either authentication-initializing or negatively-authenticated Oiwa, et al. Expires April 27, 2012 [Page 9] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 responses. The value of this parameter MUST be one of the tokens "modal" or "non-modal". When the Optional-WWW-Authenticate header is used, the value of this parameter MUST be disregarded and the value "non-modal" is implied. The value of "modal" means that the server thinks the content of the response (body and other content-related headers) is valuable only for users refusing authentication request. The clients are expected to ask the user a password before processing the content. This behavior is common for most of the current implementations of Basic and Digest authentication schemes. The value of "non-modal" means that the server thinks the content of the response (body and other content-related headers) is valuable for users before processing an authentication request. The clients are expected to first process the content and then provide users opportunities to perform authentication. The default behavior for the clients is implementation-dependent, and clients MAY choose different defaults for different authentication schemes. The proposed default behavior is "modal" for all authentication schemes, but specifications for authentication schemes MAY propose a different default. The above two different methods of authentication may introduce a observable difference of semantics when the response contains state- changing side effects; for example, it may change whether Cookie headers [RFC6265] in 401 responses are processed or not. However, the server applications SHOULD NOT depend on both existence and non- existence of such side effects. 4.2. Location-when-unauthenticated parameter Authentication-Control: Mutual location-when-unauthenticated="http://www.example.com/login.html" The parameter "location-when-unauthenticated" specifies a location where any unauthenticated clients should be redirected to. This 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 a string that contains an absolute URL location. If a given URL is not absolute, the clients MAY consider it a relative URL from the current location. This parameter MAY be used with a 401 response for authentication- initializing response. It can also be contained, although NOT RECOMMENDED, in a positive response with an Optional-WWW-Authenticate header. The clients MUST ignore this Oiwa, et al. Expires April 27, 2012 [Page 10] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 parameter, when a response is either successfully-authenticated or intermediately-authenticated. The clients SHOULD ignore this parameter when a response is a negatively-authenticated one (the case is unlikely to happen, though). When a client receives an authentication-initiating response with this parameter, if the client has to ask users for authentication credentials, the client will treat the entire response as if it were a 303 "See Other" response with a Location header that contains the value of this parameter (i.e., client will be redirected to the specified location with a GET request). Unlike a normal 303 response, if the client can process authentication without the user's interaction, this parameter MUST be ignored. 4.3. No-auth parameter Authentication-Control: Basic no-auth=true The parameter "no-auth" is a variant of the location-when-unauthenticated parameter; it specifies that new authentication attempt is not to be performed on this location for better user experience, without specifying the redirection on the 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 content's level) explicit interaction of users is desired before authentications. The value of this parameter MUST be a token "true". If the value is incorrect, client MAY ignore this parameter. This parameter MAY be used with authentication-initiating responses. It can also be contained, although NOT RECOMMENDED, in a positive response with an Optional-WWW-Authenticate header. The clients MUST ignore this parameter, when a response is either successfully- authenticated or intermediately-authenticated. The clients SHOULD ignore this parameter when a response is a negatively-authenticated one (the case is unlikely to happen, though). When a client receives an authentication-initiating response with this parameter, if the client has to ask users for authentication credentials, the client will ignore the WWW-Authenticate header contained in the response and treat the whole response as a normal negative 4xx-class response instead of giving user an opportunity to start authentication. If the client can process authentication without the user's interaction, this parameter MUST ignored. This parameter SHOULD NOT be used along with the location-when-unauthenticated parameter. If both were supplied, clients MAY choose which one is to be honored. Oiwa, et al. Expires April 27, 2012 [Page 11] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 This parameter SHOULD NOT be used as any security measures to prevent authentication attempts, as it is easily circumvented by users. This parameter SHOULD be used solely for improving user experience of web applications. 4.4. Location-when-logout parameter Authentication-Control: Digest location-when-logout="http://www.example.com/byebye.html" The parameter "location-when-logout" specifies a location where the client is to be redirected when the user explicitly request a logout. The value of this parameter MUST be a string that contains an absolute URL location. If a given URL is not absolute, the clients MAY consider it a relative URL from the current location. This parameter MAY be used with successfully-authenticated responses. If this parameter is contained in other kinds of responses, the clients MUST ignore this parameter. When the user requests to terminate an authentication period, and if the client currently displays a page supplied by a response with this 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 operation (e.g. erasing memories of user name, authentication credential and all related one-time credentials such as nonce or keys) SHOULD occur before processing a redirection. When the user requests to terminate an authentication period, if the client supports this parameter but the server response does not contain this parameter, the client's RECOMMENDED behavior is as follows: if the request corresponding to the current content was idempotent (e.g. GET), reload the page without the authentication credential. If the request was non-idempotent (e.g. POST), keep the current content as-is and simply forget the authentication status. The client SHOULD NOT replay a non-idempotent request without the user's explicit approval. Web applications are encouraged to send this parameter with an appropriate value for any responses (except those with redirection (3XX) statuses) for non-GET requests. 4.5. Logout-timeout Authentication-Control: Basic logout-timeout=300 The parameter "logout-timeout", when contained in a successfully- authenticated response, means that any authentication credentials and Oiwa, et al. Expires April 27, 2012 [Page 12] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 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 time received. As a special case, the value of logout-timeout=0 means that the client is requested to immediately log-out from the current authentication space and revert to an unauthenticated status. This does not, however, mean that the long-term memories for the passwords (such as the password reminders and auto fill-ins) should be removed. If a new timeout value is received for the same authentication space, it cancels the previous timeout and sets a new timeout. 5. Usage examples [TBD] [TBD] 6. Methods to extend this protocol If a non-standard extension to this protocol is implemented, it MUST use the extension-param to avoid conflicts with this protocol and other future official extensions. Extension-tokens MAY be freely used for any non-standard, private, and/or experimental uses. The extension-tokens MUST be with format "-.", where is a validly registered (sub-)domain name on the Internet owned by the party who defines the extensions. 7. IANA Considerations Tokens used for the authentication control parameters may be either extension-tokens or bare-tokens as outlined in Section 2.2. When bare-tokens are used in this protocol, these MUST be allocated by IANA. Any tokens used for non-private, non-experimental parameters are RECOMMENDED to be registered to IANA, regardless of the kind of tokens used. To acquire registered tokens, a specification for the use of such tokens MUST be available as a publicly-accessible documents, as outlined as "Specification Required" level in [RFC5226]. Note: More formal declarations will be added in the future drafts to meet the RFC 5226 requirements. Oiwa, et al. Expires April 27, 2012 [Page 13] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 8. Security Considerations The purpose of the log-out timeout feature in the Authentication- control header is to protect users of clients from impersonation caused by an attacker having access to the same console. Server application implementors SHOULD be aware that the directive may always be ignored by either malicious clients or clients not supporting this extension. If the purpose of introducing a timeout for an authentication period is to protect server-side resources, such features MUST be implemented by other means such as HTTP Cookies [RFC6265]. All parameters in Authentication-Control header SHOULD NOT be used for any security-enforcement purposes. Server-side applications MUST be implemented always considering that the header may be either ignored by clients or even bypassed by users. 9. References 9.1. Normative References [I-D.ietf-httpbis-p1-messaging] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and Y. Lafon, "HTTP/1.1, part 1: URIs, Connections, and Message Parsing", draft-ietf-httpbis-p1-messaging-16 (work in progress), August 2011. [I-D.ietf-httpbis-p7-auth] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and Y. Lafon, "HTTP/1.1, part 7: Authentication", draft-ietf-httpbis-p7-auth-16 (work in progress), August 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 9.2. Informative References [I-D.oiwa-http-mutualauth] Oiwa, Y., Watanabe, H., Ioku, Y., and T. Hayashi, "Mutual Authentication Protocol for HTTP", Oiwa, et al. Expires April 27, 2012 [Page 14] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 draft-oiwa-http-mutualauth-09 (work in progress), July 2011. [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011. Appendix A. (Informative) Applicability of features for each messages This section provides cross-reference table about applicability of each features provided in this specification for each kinds of responses described in Section 2.1. The table provided in this section is for informative purposes only. +-------------------+-------+----------+-----------+------+ | | init. | success. | intermed. | neg. | +-------------------+-------+----------+-----------+------+ | Optional auth. | O | n | N | N | | auth-style | O | - | - | O | | loc.-when-unauth. | O | I | I | i | | no-auth | O | I | I | i | | loc.-when-logout | - | O | - | - | | logout-timeout | - | O | - | - | +-------------------+-------+----------+-----------+------+ Legends: O = MAY contain; n = SHOULD NOT contain; N = MUST NOT contain i = SHOULD be ignored; I = MUST be ignored; - = meaningless (to be ignored) Appendix B. (Informative) Draft Notes Things which might be considered for future revisions: o In [I-D.ietf-httpbis-p7-auth], meaning of WWW-Authenticate headers in non-401 responses are defined as "supplying credentials (or different credentials) might affect the response". This clarification change leaves a way for using 200-status responses along with a WWW-Authenticate header for providing optional authentication. Incorporating this possibility, however, needs more detailed analysis on the behavior of existing clients and intermediate proxies for such possibly-confusing responses. Optional-WWW- Authenticate is safer, at least for minimum backward compatibility, because clients not supporting this extension will consider this header as an unrecognized entity-header, possibly providing opportunity for silently falling-back to application- Oiwa, et al. Expires April 27, 2012 [Page 15] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 level authentications. Appendix C. (Informative) Draft Change Log C.1. Changes in revision 00 o Separated from HTTP Mutual authentication proposal (-09). o Adopting httpbis works as a referencing point to HTTP. o Generalized, now applicable for all HTTP authentication schemes. o Added "no-auth" and "auth-style" parameters. o Loosened standardization requirements for parameter-name tokens registration. Authors' Addresses Yutaka Oiwa National Institute of Advanced Industrial Science and Technology Research Center for Information Security Tsukuba Central 2 1-1-1 Umezono Tsukuba-shi, Ibaraki JP Email: mutual-auth-contact@m.aist.go.jp Hajime Watanabe National Institute of Advanced Industrial Science and Technology Hiromitsu Takagi National Institute of Advanced Industrial Science and Technology Boku Kihara Lepidum Co. Ltd. #602, Village Sasazuka 3 1-30-3 Sasazuka Shibuya-ku, Tokyo JP Oiwa, et al. Expires April 27, 2012 [Page 16] Internet-Draft HTTP Auth. Ext. for Interactive Clients October 2011 Tatsuya Hayashi Lepidum Co. Ltd. Yuichi Ioku Yahoo! Japan, Inc. Midtown Tower 9-7-1 Akasaka Minato-ku, Tokyo JP Oiwa, et al. Expires April 27, 2012 [Page 17]