idnits 2.17.1 draft-oiwa-http-auth-extension-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2011) is 4567 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 570, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-16 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-16 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-12) exists of draft-oiwa-http-mutualauth-09 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Y. Oiwa 3 Internet-Draft H. Watanabe 4 Intended status: Standards Track H. Takagi 5 Expires: April 27, 2012 RCIS, AIST 6 B. Kihara 7 T. Hayashi 8 Lepidum 9 Y. Ioku 10 Yahoo! Japan 11 October 25, 2011 13 HTTP Authentication Extensions for Interactive Clients 14 draft-oiwa-http-auth-extension-00 16 Abstract 18 This document specifies an extension of HTTP authentication framework 19 for use with interactive clients. Recently, the fundamental features 20 of HTTP-level authentication is not enough for complex requirements 21 of various Web-based applications. This makes these applications to 22 implement their own authentication frameworks using HTML Forms and 23 other means, which becomes one of the hurdles against introducing 24 secure authentication mechanisms handled jointly by servers and user- 25 agent clients. The extended framework fills gaps between Web 26 application requirements and HTTP authentication provisions to solve 27 the above problems, while maintaining some upper-compatibility 28 against existing Web and non-Web uses of HTTP authentications. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 27, 2012. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Terms for describing authentication protocol flow . . . . 4 67 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 68 3. Optional Authentication . . . . . . . . . . . . . . . . . . . 7 69 4. Authentication-Control header . . . . . . . . . . . . . . . . 9 70 4.1. Auth-style parameter . . . . . . . . . . . . . . . . . . . 9 71 4.2. Location-when-unauthenticated parameter . . . . . . . . . 10 72 4.3. No-auth parameter . . . . . . . . . . . . . . . . . . . . 11 73 4.4. Location-when-logout parameter . . . . . . . . . . . . . . 12 74 4.5. Logout-timeout . . . . . . . . . . . . . . . . . . . . . . 12 75 5. Usage examples [TBD] . . . . . . . . . . . . . . . . . . . . . 13 76 6. Methods to extend this protocol . . . . . . . . . . . . . . . 13 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 82 Appendix A. (Informative) Applicability of features for each 83 messages . . . . . . . . . . . . . . . . . . . . . . 15 84 Appendix B. (Informative) Draft Notes . . . . . . . . . . . . . . 15 85 Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 16 86 C.1. Changes in revision 00 . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 The document proposes several extensions to the current HTTP 92 authentication framework, to provide enough functionality comparable 93 with current widely-used form-based Web authentication. A majority 94 of the recent Web-sites on the Internet use custom application-layer 95 authentication implementations using Web forms. The reasons for 96 these may vary, but many people believe that the current HTTP Basic 97 (and Digest, too) authentication method does not have enough 98 functionality (including a good-feeling user interfaces) to support 99 most of realistic Web-based applications. However, the method is 100 very weak against phishing attacks, because the whole behavior of the 101 authentication is controlled from the server side. To overcome this 102 problem, we need to "modernize" the HTTP authentication framework so 103 that better client-controlled secure methods can be used with Web 104 applications. The extensions proposed in this document include: 106 o non-mandatory, optional authentication on HTTP (Section 3), 108 o log out from both server and client side (Section 4), and 110 o finer control for redirection depending on authentication status 111 (Section 4). 113 [I-D note: These extensions are initially proposed as a part of 114 [I-D.oiwa-http-mutualauth]. However, since these might possibly be 115 useful in combination with other authentication schemes, the 116 extensions were separated as an independent draft.] 118 1.1. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in 123 [RFC2119]. 125 The terms "encouraged" and "advised" are used for suggestions that do 126 not constitute "SHOULD"-level requirements. People MAY freely choose 127 not to include the suggested items regarding [RFC2119], but complying 128 with those suggestions would be a best practice; it will improve the 129 security, interoperability, and/or operational performance. 131 This document distinguishes the terms "client" and "user" in the 132 following way: A "client" is an entity understanding and talking HTTP 133 and the specified authentication protocol, usually computer software; 134 a "user" is a (usually natural) person who wants to access data 135 resources using "a client". 137 2. Definitions 139 2.1. Terms for describing authentication protocol flow 141 HTTP Authentication defined in [I-D.ietf-httpbis-p7-auth] may involve 142 with several pairs of HTTP requests/responses. Throughout this 143 document, the following terms are used to categorize those messages: 144 for requests, 146 o A non-authenticating request is a request not attempting any 147 authentication: a request without any Authorization header. 149 o An authenticating request is the opposite: a request with an 150 Authorization header. 152 For responses, 154 1) A non-authenticated response: is a response which does not 155 involve with any HTTP authentication. It may not contain any 156 WWW-Authenticate or Authentication-Info header. 158 Servers send this response when the requested resource is not 159 protected by HTTP authentication mechanisms. In context of this 160 specification, not-authentication-related negative responses (e.g. 161 403 and 404) are also considered as non-authenticated responses. 163 (See note on successfully-authenticated responses below for some 164 ambiguous cases.) 166 2) An authentication-initializing response: is a response which 167 requires or allows clients to start authentication attempts. 168 Servers send this response when the requested resource is 169 protected by HTTP authentication mechanism, and the request meets 170 one of the following cases: 172 * The request is non-authenticating request, or 174 * The request contained an authentication trial directed to the 175 protection space (realm) other than the server's expected one. 177 The server will specify the protection space for authentication in 178 this response. 180 Upon reception, the client's behavior is further divided to two 181 possible cases. 183 * If the client may have no prior knowledge on authentication 184 credentials (e.g. a user-name and a password) related to the 185 requested protection space, the protocol flow terminates and 186 the client will ask the user to provide authentication 187 credentials, 189 * On the other hand, if client already have an enough credentials 190 for authentication to the requested protection space, the 191 client will automatically send an authenticating request. Such 192 cases often occur when the client did not know beforehand that 193 the current request-URL requires an authentication. 195 3) A successfully-authenticated response: is a response for an 196 authenticating request meaning that the authentication attempt was 197 granted. (Note: if the authentication scheme used does not use an 198 Authentication-Info header, it may be indistinguishable from a 199 non-authenticated response.) 201 4) An intermediate authenticating response: is a response for an 202 authenticating request which requires some more reaction by the 203 client software without involving users. Such a response is 204 required when an authentication scheme requires two or more round- 205 trip messages to perform authentication, or when an authentication 206 scheme uses some speculative short-cut method (such as uses of 207 cached shared secrets) and it failed. 209 5) A negatively-authenticated response: is a response for an 210 authenticating request which means that the authentication attempt 211 was declined and can not continue without another authentication 212 credential. Clients typically erase memory of the currently-using 213 credentials and ask the user for other ones. 215 Usually the format of these responses are as same as the one for 216 authentication-initializing responses. Client can distinguish it 217 by comparing the protection spaces contained in the request and in 218 the response. 220 Figure 1 shows a state diagram of generic HTTP authentication with 221 the above message categorization. Note that many authentication 222 schemes uses only a subset of the transitions described on the 223 diagram. Labels in the figure show the abbreviated names of response 224 types. 226 =========== ----------------- 227 NEW REQUEST ( UNAUTHENTICATED ) 228 =========== ----------------- 229 | ^ non-auth. 230 v | response 231 +----------------------+ NO +-------------+ 232 | The requested URI |--------------------------->| send normal | 233 | known to be auth'ed? | ---------------->| request | 234 +----------------------+ / +-------------+ 235 YES | / initializing| 236 v / | 237 +------------------+ NO / | 238 | Can auth-req (*1)|--------- | 239 | be constructed? | | 240 +------------------+ | 241 YES | initializing | 242 | ---------------------------------------. | 243 | / v v 244 | | ---------------- NO +-----------+ 245 | | ( AUTH-REQUESTED )<------|credentials| 246 | | ---------------- | known? | 247 v | +-----------+ 248 +-----------+ negative ------------- negative |YES 249 | send |---------->( AUTH-FAILED )<---------, | 250 /| auth-req | ------------- | | 251 / +-----------+\ | v 252 | \ \ intermediate +-----------+ 253 | \ -------------------------------->| send | 254 | \ | auth-req | 255 | non-auth. \successful successful +-----------+ 256 | response (*2) \ / | ^ 257 v \ / | | 258 ----------------- \ -------------- / `----' 259 ( UNAUTHENTICATED ) ----->( AUTH-SUCCEED )<---- intermediate 260 ----------------- -------------- 262 Figure 1: Generic state diagram for HTTP authentication 264 Note: (*1) For example, "Digest" scheme requires server-provided 265 nonces to construct client-side challenges. 266 (*2) In "Basic" and some others, this cannot be distinguished from a 267 successfully-authenticated response. 269 2.2. Syntax Notation 271 This specification uses an extended BNF syntax defined in 272 [I-D.ietf-httpbis-p1-messaging]. The following syntax definitions 273 are quoted from [I-D.ietf-httpbis-p1-messaging] and 274 [I-D.ietf-httpbis-p7-auth]: auth-scheme, quoted-string, auth-param, 275 SP, header-field, and challenge. It also uses the convention of 276 using header names for specifying syntax of header values. 278 Additionally, this specification uses the following syntax elements 279 following syntax definitions as a refinement for token and the 280 righthand-side of auth-param in [I-D.ietf-httpbis-p7-auth]. Note 281 that bare-token, extension-token and integer are subset of the 282 token's syntax, and the extension-param is a subset of auth-param. 283 (Note: these definitions are consistent with those in 284 [I-D.oiwa-http-mutualauth].) 286 bare-token = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_") 287 extension-token = "-" bare-token 1*("." bare-token) 288 extension-param = (bare-token / extension-token) "=" value 289 value = bare-token / extension-token / quoted-string 290 integer = "0" / (%x31-39 *%x30-39) ; no leading zeros 292 Figure 2: the BNF syntax for common notations 294 Extensive-tokens are used in this protocol where the set of 295 acceptable tokens may include private extensions. Any private 296 extensions of this protocol MUST use the extension-tokens with format 297 "-.", where is a validly registered 298 (sub-)domain name on the Internet owned by the party who defines the 299 extensions. 301 3. Optional Authentication 303 The Optional-WWW-Authenticate header enables a non-mandatory 304 authentication, which is not possible under the current HTTP 305 authentication mechanism. In several Web applications, users can 306 access the same contents as both a guest user and an authenticated 307 user. In most Web applications, it is implemented using HTTP cookies 308 [RFC6265] and custom form-based authentications. The new 309 authentication method using this message will provide a replacement 310 for these authentication systems. 312 Servers MAY send HTTP successful responses (response code 200, 206 313 and others) containing the Optional-WWW-Authenticate header as a 314 replacement of a 401 response when it is an authentication- 315 initializing response. The Optional-WWW-Authenticate header MUST NOT 316 be contained in 401 responses. 318 HTTP/1.1 200 OK 319 Optional-WWW-Authenticate: Basic realm="xxxx" 321 Optional-WWW-Authenticate = challenge 323 Figure 3: BNF syntax for Optional-WWW-Authenticate header 325 The challenge contained in the Optional-WWW-Authenticate header are 326 the same as those for a 401 responses corresponding for a same 327 request. For authentication-related matters, an optional 328 authentication request will have the same meaning as a 401 message 329 with a corresponding WWW-Authenticate header (as an authentication- 330 initializing response). (The behavior for other matters, such as 331 caching, MAY be different between the optional authentication and 401 332 messages.) 334 A response with an Optional-WWW-Authenticate header SHOULD be 335 returned from the server only when the request is either non- 336 authenticated or authenticating to a wrong (not the server's 337 expected) protection space. If a response is either an intermediate 338 or a negative response to a client's authentication attempt, the 339 server MUST respond with a 401 status response with a 340 WWW-Authenticate header instead. Failure to comply this rule will 341 make client not able to distinguish authentication successes and 342 failures. 344 The server is NOT RECOMMENDED to include an Optional-WWW-Authenticate 345 header in a positive response when a client's authentication attempt 346 succeeds. 348 Whenever an authentication scheme support for servers to send some 349 parameter which gives a hint of URL space for the corresponding 350 protection space for the same realm (e.g. "path" or "domain"), 351 servers requesting non-mandatory authentication SHOULD send such 352 parameter with the response. Clients supporting non-mandatory 353 authentication MUST recognize the parameter, and MUST send a request 354 with an appropriate authentication credential in an Authorization 355 header for any URI inside the specified paths. 357 Support of this header is OPTIONAL; Clients MAY also choose any set 358 of authentication schemes for which optional authentication is 359 supported (in other words, its support MAY be scheme-dependent). 360 However, some authentication schemes MAY require mandatory/ 361 recommended support for this header, so that server-side applications 362 MAY assume that clients supporting such schemes are likely to support 363 the extension as well. 365 4. Authentication-Control header 367 Authentication-Control = auth-scheme 1*SP 1#Auth-Ctrl-params 368 Auth-Ctrl-params = auth-style / no-auth / loc-when-unauthed 369 / loc-when-logout / logout-timeout 370 / extension-param 371 auth-style = "auth-style" "=" ( "modal" / "non-modal" ) 372 no-auth = "no-auth" "=" "true" 373 loc-when-unauthed = "location-when-unauthenticated" "=" quoted-string 374 loc-when-logout = "location-when-logout" "=" quoted-string 375 logout-timeout = "logout-timeout" "=" integer 377 Figure 4: the BNF syntax for the Authentication-Control header 379 The Authentication-Control header provides a more precise control of 380 the client behavior for Web applications using an HTTP authentication 381 protocol. This header is supposed to be generated in the application 382 layer, as opposed to WWW-Authenticate headers which will be generated 383 by the Web servers. 385 Support of this header is OPTIONAL, and clients MAY choose any subset 386 of these parameters to be supported. The set of supported parameters 387 MAY also be authentication scheme-dependent. However, some 388 authentication schemes MAY require mandatory/recommended support for 389 some or all of the features provided in this header. 391 The "auth-scheme" specified in this header and other authentication- 392 related headers within the same message MUST be the same. Clients 393 MUST ignore any unknown parameters contained in this header. 395 Server-side application SHOULD always be reminded that any parameters 396 contained in this header MAY be ignored by clients. Also, even when 397 a client accepts this header, users may always be able to circumvent 398 semantics of this header. Therefore, if this header is used for 399 security purposes, its use MUST be limited for providing some non- 400 fundamental additional security measures valuable for end-users (such 401 as client-side log-out for protecting against console takeover). 402 Server-side application MUST NOT rely on the use of this header for 403 protecting server-side resources. 405 4.1. Auth-style parameter 407 Authentication-Control: Digest auth-style=modal 409 The parameter "auth-style" specifies the server's preferences over 410 user interface behavior for user authentication. This parameter can 411 be included in any kind of responses, however, it is only meaningful 412 for either authentication-initializing or negatively-authenticated 413 responses. The value of this parameter MUST be one of the tokens 414 "modal" or "non-modal". When the Optional-WWW-Authenticate header is 415 used, the value of this parameter MUST be disregarded and the value 416 "non-modal" is implied. 418 The value of "modal" means that the server thinks the content of the 419 response (body and other content-related headers) is valuable only 420 for users refusing authentication request. The clients are expected 421 to ask the user a password before processing the content. This 422 behavior is common for most of the current implementations of Basic 423 and Digest authentication schemes. 425 The value of "non-modal" means that the server thinks the content of 426 the response (body and other content-related headers) is valuable for 427 users before processing an authentication request. The clients are 428 expected to first process the content and then provide users 429 opportunities to perform authentication. 431 The default behavior for the clients is implementation-dependent, and 432 clients MAY choose different defaults for different authentication 433 schemes. The proposed default behavior is "modal" for all 434 authentication schemes, but specifications for authentication schemes 435 MAY propose a different default. 437 The above two different methods of authentication may introduce a 438 observable difference of semantics when the response contains state- 439 changing side effects; for example, it may change whether Cookie 440 headers [RFC6265] in 401 responses are processed or not. However, 441 the server applications SHOULD NOT depend on both existence and non- 442 existence of such side effects. 444 4.2. Location-when-unauthenticated parameter 446 Authentication-Control: Mutual 447 location-when-unauthenticated="http://www.example.com/login.html" 449 The parameter "location-when-unauthenticated" specifies a location 450 where any unauthenticated clients should be redirected to. This 451 header may be used, for example, when there is a central login page 452 for the entire Web application. The value of this parameter MUST be 453 a string that contains an absolute URL location. If a given URL is 454 not absolute, the clients MAY consider it a relative URL from the 455 current location. 457 This parameter MAY be used with a 401 response for authentication- 458 initializing response. It can also be contained, although 459 NOT RECOMMENDED, in a positive response with an 460 Optional-WWW-Authenticate header. The clients MUST ignore this 461 parameter, when a response is either successfully-authenticated or 462 intermediately-authenticated. The clients SHOULD ignore this 463 parameter when a response is a negatively-authenticated one (the case 464 is unlikely to happen, though). 466 When a client receives an authentication-initiating response with 467 this parameter, if the client has to ask users for authentication 468 credentials, the client will treat the entire response as if it were 469 a 303 "See Other" response with a Location header that contains the 470 value of this parameter (i.e., client will be redirected to the 471 specified location with a GET request). Unlike a normal 303 472 response, if the client can process authentication without the user's 473 interaction, this parameter MUST be ignored. 475 4.3. No-auth parameter 477 Authentication-Control: Basic no-auth=true 479 The parameter "no-auth" is a variant of the 480 location-when-unauthenticated parameter; it specifies that new 481 authentication attempt is not to be performed on this location for 482 better user experience, without specifying the redirection on the 483 HTTP level. This header may be used, for example, when there is a 484 central login page for the entire Web application, and when a (Web 485 content's level) explicit interaction of users is desired before 486 authentications. The value of this parameter MUST be a token "true". 487 If the value is incorrect, client MAY ignore this parameter. 489 This parameter MAY be used with authentication-initiating responses. 490 It can also be contained, although NOT RECOMMENDED, in a positive 491 response with an Optional-WWW-Authenticate header. The clients MUST 492 ignore this parameter, when a response is either successfully- 493 authenticated or intermediately-authenticated. The clients SHOULD 494 ignore this parameter when a response is a negatively-authenticated 495 one (the case is unlikely to happen, though). 497 When a client receives an authentication-initiating response with 498 this parameter, if the client has to ask users for authentication 499 credentials, the client will ignore the WWW-Authenticate header 500 contained in the response and treat the whole response as a normal 501 negative 4xx-class response instead of giving user an opportunity to 502 start authentication. If the client can process authentication 503 without the user's interaction, this parameter MUST ignored. 505 This parameter SHOULD NOT be used along with the 506 location-when-unauthenticated parameter. If both were supplied, 507 clients MAY choose which one is to be honored. 509 This parameter SHOULD NOT be used as any security measures to prevent 510 authentication attempts, as it is easily circumvented by users. This 511 parameter SHOULD be used solely for improving user experience of web 512 applications. 514 4.4. Location-when-logout parameter 516 Authentication-Control: Digest 517 location-when-logout="http://www.example.com/byebye.html" 519 The parameter "location-when-logout" specifies a location where the 520 client is to be redirected when the user explicitly request a logout. 521 The value of this parameter MUST be a string that contains an 522 absolute URL location. If a given URL is not absolute, the clients 523 MAY consider it a relative URL from the current location. 525 This parameter MAY be used with successfully-authenticated responses. 526 If this parameter is contained in other kinds of responses, the 527 clients MUST ignore this parameter. 529 When the user requests to terminate an authentication period, and if 530 the client currently displays a page supplied by a response with this 531 parameter, the client will be redirected to the specified location by 532 a new GET request (as if it received a 303 response). The log-out 533 operation (e.g. erasing memories of user name, authentication 534 credential and all related one-time credentials such as nonce or 535 keys) SHOULD occur before processing a redirection. 537 When the user requests to terminate an authentication period, if the 538 client supports this parameter but the server response does not 539 contain this parameter, the client's RECOMMENDED behavior is as 540 follows: if the request corresponding to the current content was 541 idempotent (e.g. GET), reload the page without the authentication 542 credential. If the request was non-idempotent (e.g. POST), keep the 543 current content as-is and simply forget the authentication status. 544 The client SHOULD NOT replay a non-idempotent request without the 545 user's explicit approval. 547 Web applications are encouraged to send this parameter with an 548 appropriate value for any responses (except those with redirection 549 (3XX) statuses) for non-GET requests. 551 4.5. Logout-timeout 553 Authentication-Control: Basic logout-timeout=300 555 The parameter "logout-timeout", when contained in a successfully- 556 authenticated response, means that any authentication credentials and 557 states related to the current protection space are to be discarded if 558 a time specified in this header (in seconds) has been passed from the 559 time received. As a special case, the value of logout-timeout=0 560 means that the client is requested to immediately log-out from the 561 current authentication space and revert to an unauthenticated status. 562 This does not, however, mean that the long-term memories for the 563 passwords (such as the password reminders and auto fill-ins) should 564 be removed. If a new timeout value is received for the same 565 authentication space, it cancels the previous timeout and sets a new 566 timeout. 568 5. Usage examples [TBD] 570 [TBD] 572 6. Methods to extend this protocol 574 If a non-standard extension to this protocol is implemented, it MUST 575 use the extension-param to avoid conflicts with this protocol and 576 other future official extensions. 578 Extension-tokens MAY be freely used for any non-standard, private, 579 and/or experimental uses. The extension-tokens MUST be with format 580 "-.", where is a validly 581 registered (sub-)domain name on the Internet owned by the party who 582 defines the extensions. 584 7. IANA Considerations 586 Tokens used for the authentication control parameters may be either 587 extension-tokens or bare-tokens as outlined in Section 2.2. When 588 bare-tokens are used in this protocol, these MUST be allocated by 589 IANA. Any tokens used for non-private, non-experimental parameters 590 are RECOMMENDED to be registered to IANA, regardless of the kind of 591 tokens used. 593 To acquire registered tokens, a specification for the use of such 594 tokens MUST be available as a publicly-accessible documents, as 595 outlined as "Specification Required" level in [RFC5226]. 597 Note: More formal declarations will be added in the future drafts to 598 meet the RFC 5226 requirements. 600 8. Security Considerations 602 The purpose of the log-out timeout feature in the Authentication- 603 control header is to protect users of clients from impersonation 604 caused by an attacker having access to the same console. Server 605 application implementors SHOULD be aware that the directive may 606 always be ignored by either malicious clients or clients not 607 supporting this extension. If the purpose of introducing a timeout 608 for an authentication period is to protect server-side resources, 609 such features MUST be implemented by other means such as HTTP Cookies 610 [RFC6265]. 612 All parameters in Authentication-Control header SHOULD NOT be used 613 for any security-enforcement purposes. Server-side applications MUST 614 be implemented always considering that the header may be either 615 ignored by clients or even bypassed by users. 617 9. References 619 9.1. Normative References 621 [I-D.ietf-httpbis-p1-messaging] 622 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 623 Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and 624 Y. Lafon, "HTTP/1.1, part 1: URIs, Connections, and 625 Message Parsing", draft-ietf-httpbis-p1-messaging-16 (work 626 in progress), August 2011. 628 [I-D.ietf-httpbis-p7-auth] 629 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 630 Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and 631 Y. Lafon, "HTTP/1.1, part 7: Authentication", 632 draft-ietf-httpbis-p7-auth-16 (work in progress), 633 August 2011. 635 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 636 Requirement Levels", BCP 14, RFC 2119, March 1997. 638 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 639 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 640 May 2008. 642 9.2. Informative References 644 [I-D.oiwa-http-mutualauth] 645 Oiwa, Y., Watanabe, H., Ioku, Y., and T. Hayashi, "Mutual 646 Authentication Protocol for HTTP", 647 draft-oiwa-http-mutualauth-09 (work in progress), 648 July 2011. 650 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 651 April 2011. 653 Appendix A. (Informative) Applicability of features for each messages 655 This section provides cross-reference table about applicability of 656 each features provided in this specification for each kinds of 657 responses described in Section 2.1. The table provided in this 658 section is for informative purposes only. 660 +-------------------+-------+----------+-----------+------+ 661 | | init. | success. | intermed. | neg. | 662 +-------------------+-------+----------+-----------+------+ 663 | Optional auth. | O | n | N | N | 664 | auth-style | O | - | - | O | 665 | loc.-when-unauth. | O | I | I | i | 666 | no-auth | O | I | I | i | 667 | loc.-when-logout | - | O | - | - | 668 | logout-timeout | - | O | - | - | 669 +-------------------+-------+----------+-----------+------+ 671 Legends: 672 O = MAY contain; n = SHOULD NOT contain; N = MUST NOT contain 673 i = SHOULD be ignored; I = MUST be ignored; 674 - = meaningless (to be ignored) 676 Appendix B. (Informative) Draft Notes 678 Things which might be considered for future revisions: 680 o In [I-D.ietf-httpbis-p7-auth], meaning of WWW-Authenticate headers 681 in non-401 responses are defined as "supplying credentials (or 682 different credentials) might affect the response". This 683 clarification change leaves a way for using 200-status responses 684 along with a WWW-Authenticate header for providing optional 685 authentication. 686 Incorporating this possibility, however, needs more detailed 687 analysis on the behavior of existing clients and intermediate 688 proxies for such possibly-confusing responses. Optional-WWW- 689 Authenticate is safer, at least for minimum backward 690 compatibility, because clients not supporting this extension will 691 consider this header as an unrecognized entity-header, possibly 692 providing opportunity for silently falling-back to application- 693 level authentications. 695 Appendix C. (Informative) Draft Change Log 697 C.1. Changes in revision 00 699 o Separated from HTTP Mutual authentication proposal (-09). 701 o Adopting httpbis works as a referencing point to HTTP. 703 o Generalized, now applicable for all HTTP authentication schemes. 705 o Added "no-auth" and "auth-style" parameters. 707 o Loosened standardization requirements for parameter-name tokens 708 registration. 710 Authors' Addresses 712 Yutaka Oiwa 713 National Institute of Advanced Industrial Science and Technology 714 Research Center for Information Security 715 Tsukuba Central 2 716 1-1-1 Umezono 717 Tsukuba-shi, Ibaraki 718 JP 720 Email: mutual-auth-contact@m.aist.go.jp 722 Hajime Watanabe 723 National Institute of Advanced Industrial Science and Technology 725 Hiromitsu Takagi 726 National Institute of Advanced Industrial Science and Technology 728 Boku Kihara 729 Lepidum Co. Ltd. 730 #602, Village Sasazuka 3 731 1-30-3 Sasazuka 732 Shibuya-ku, Tokyo 733 JP 734 Tatsuya Hayashi 735 Lepidum Co. Ltd. 737 Yuichi Ioku 738 Yahoo! Japan, Inc. 739 Midtown Tower 740 9-7-1 Akasaka 741 Minato-ku, Tokyo 742 JP