idnits 2.17.1 draft-ietf-httpauth-mutual-09.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 (August 17, 2016) is 2780 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-httpauth-extension-08 ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5987 (Obsoleted by RFC 8187) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7613 (Obsoleted by RFC 8265) ** Obsolete normative reference: RFC 7615 (Obsoleted by RFC 9110) == Outdated reference: A later version (-07) exists of draft-ietf-httpauth-mutual-algo-06 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 7564 (Obsoleted by RFC 8264) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPAUTH Working Group Y. Oiwa 3 Internet-Draft H. Watanabe 4 Intended status: Experimental H. Takagi 5 Expires: February 18, 2017 ITRI, AIST 6 K. Maeda 7 T. Hayashi 8 Lepidum 9 Y. Ioku 10 Individual 11 August 17, 2016 13 Mutual Authentication Protocol for HTTP 14 draft-ietf-httpauth-mutual-09 16 Abstract 18 This document specifies a mutual authentication scheme for the 19 Hypertext Transfer Protocol (HTTP). This scheme provides true mutual 20 authentication between an HTTP client and an HTTP server using 21 password-based authentication. Unlike the Basic and Digest 22 authentication schemes, the Mutual authentication scheme specified in 23 this document assures the user that the server truly knows the user's 24 encrypted password. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 18, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.2. Document Structure and Related Documents . . . . . . . . . 6 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 64 2.1. Messages Overview . . . . . . . . . . . . . . . . . . . . 7 65 2.2. Typical Flows of the Protocol . . . . . . . . . . . . . . 8 66 2.3. Alternative Flows . . . . . . . . . . . . . . . . . . . . 10 67 3. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 68 3.1. Non-ASCII extended header parameters . . . . . . . . . . . 12 69 3.2. Values . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 3.2.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . 13 71 3.2.2. Strings . . . . . . . . . . . . . . . . . . . . . . . 14 72 3.2.3. Numbers . . . . . . . . . . . . . . . . . . . . . . . 14 73 4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 4.1. 401-INIT and 401-STALE . . . . . . . . . . . . . . . . . . 16 75 4.2. req-KEX-C1 . . . . . . . . . . . . . . . . . . . . . . . . 18 76 4.3. 401-KEX-S1 . . . . . . . . . . . . . . . . . . . . . . . . 19 77 4.4. req-VFY-C . . . . . . . . . . . . . . . . . . . . . . . . 20 78 4.5. 200-VFY-S . . . . . . . . . . . . . . . . . . . . . . . . 20 79 5. Authentication Realms . . . . . . . . . . . . . . . . . . . . 21 80 5.1. Resolving Ambiguities . . . . . . . . . . . . . . . . . . 22 81 6. Session Management . . . . . . . . . . . . . . . . . . . . . . 23 82 7. Host Validation Methods . . . . . . . . . . . . . . . . . . . 25 83 7.1. Applicability notes . . . . . . . . . . . . . . . . . . . 26 84 7.2. Notes on tls-unique . . . . . . . . . . . . . . . . . . . 27 85 8. Authentication Extensions . . . . . . . . . . . . . . . . . . 27 86 9. String Preparation . . . . . . . . . . . . . . . . . . . . . . 28 87 10. Decision Procedure for Clients . . . . . . . . . . . . . . . . 28 88 10.1. General Principles and Requirements . . . . . . . . . . . 28 89 10.2. State machine for the client (informative) . . . . . . . . 30 90 11. Decision Procedure for Servers . . . . . . . . . . . . . . . . 35 91 12. Authentication Algorithms . . . . . . . . . . . . . . . . . . 37 92 12.1. Support Functions and Notations . . . . . . . . . . . . . 38 93 12.2. Default Functions for Algorithms . . . . . . . . . . . . . 39 94 13. Application Channel Binding . . . . . . . . . . . . . . . . . 40 95 14. Application for Proxy Authentication . . . . . . . . . . . . . 41 96 15. Methods to Extend This Protocol . . . . . . . . . . . . . . . 42 97 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 98 16.1. Registry for Authentication Algorithms . . . . . . . . . . 42 99 16.2. Registry for Validation Methods . . . . . . . . . . . . . 43 100 17. Security Considerations . . . . . . . . . . . . . . . . . . . 43 101 17.1. Security Properties . . . . . . . . . . . . . . . . . . . 43 102 17.2. Denial-of-service Attacks to Servers . . . . . . . . . . . 44 103 17.2.1. On-line Active Password Attacks . . . . . . . . . . . 45 104 17.3. Communicating the status of mutual authentication with 105 users . . . . . . . . . . . . . . . . . . . . . . . . . . 45 106 17.4. Implementation Considerations . . . . . . . . . . . . . . 45 107 17.5. Usage Considerations . . . . . . . . . . . . . . . . . . . 46 108 18. Notice on Intellectual Properties . . . . . . . . . . . . . . 46 109 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 110 19.1. Normative References . . . . . . . . . . . . . . . . . . . 47 111 19.2. Informative References . . . . . . . . . . . . . . . . . . 48 112 Appendix A. (Informative) Draft Change Log . . . . . . . . . . . 50 113 A.1. Changes in Httpauth WG Revision 09 . . . . . . . . . . . . 50 114 A.2. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 50 115 A.3. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 50 116 A.4. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 50 117 A.5. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 50 118 A.6. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 51 119 A.7. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 51 120 A.8. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 51 121 A.9. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 51 122 A.10. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 52 123 A.11. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 52 124 A.12. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 52 125 A.13. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 52 126 A.14. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 52 127 A.15. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 53 128 A.16. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 54 129 A.17. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 54 130 A.18. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 54 131 A.19. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 54 132 A.20. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 55 133 A.21. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 55 134 A.22. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 55 135 A.23. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 55 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 138 1. Introduction 140 This document specifies a mutual authentication scheme for Hypertext 141 Transfer Protocol (HTTP). The scheme, called "Mutual Authentication 142 Protocol" in this document, provides true mutual authentication 143 between an HTTP client and an HTTP server, using just a simple 144 password as a credential. 146 Password-stealing attacks are a one of most critical threats in the 147 Web systems. For a long time, plain-text password authentications 148 (Basic and Web form-based) are widely used (and is in use now). When 149 it is used with plain HTTP protocols, it is trivially easy for 150 attackers to sniff the password credentials. Digest authentication 151 scheme [RFC7616] uses a SHA-2 (formally SHA-1 and MD5) hash 152 algorithms to hide the raw user password from the sniffing. However, 153 if the number of possible candidates of users' password is not 154 enough, Digest scheme suffers from so-called "offline password 155 dictionary attacks": recent powerful computers can compute possible 156 hash values for billions of password candidates, and compare these 157 with the sniffed values to find out the correct password. Recently, 158 the size of possible search space by computers is quite competing 159 with possibility of user's memorable password space, threatening the 160 effectiveness of such hash-based password protections. 162 TLS [RFC5246] provides a strong cryptographic protection against the 163 network-based sniffing of passwords and other communication contents. 164 If TLS is correctly used by both server operators and client users, 165 passwords and other credentials will not be available for any outside 166 attackers. However, there is a pit-hole in the TLS deployment on the 167 Web systems. If the users are forged into a "wrong website" by some 168 kind of social attacks and performing authentication on that site, 169 the credentials will be leaked. Such attacks are called "Phishing", 170 and becoming a real threats in these days. In the Web system 171 deployment, TLS certificates will be issued to almost any users of 172 Internet (including malicious attackers). Those certificate includes 173 several levels of the "validation results" (such as corporate names) 174 of the issued entities. However, "verification" of validation 175 results are left to the users of Web browsers, leaving the 176 possibility of such social attacks. 178 Another direction to avoid such threats is to avoid password-based 179 authentication and use some kind of pre-deployed strong secret keys 180 (either on client side or on server-side) for authentications. 181 Several federated authentication framework as well as HOBA [RFC7486] 182 are proposed and deployed on the real Web systems to satisfy those 183 needs. However, a kind of authentication based on "human-memorable 184 secret" is still required on several situations within those systems, 185 such is initialization, key deployment to new clients, or secret 186 account recoveries. 188 The Mutual authentication protocol proposed in this document is a 189 strong cryptographic solution for password authentications. It 190 mainly provides the two key features: 192 o No password information, at all, is exchanged in the 193 communications. When the server and the user fails to 194 authenticate with each other, the protocol will not reveal the 195 tiniest bit of information about the user's password. This 196 prevents any kind of off-line password dictionary attacks, even 197 with the existence of Phishing attacks. 199 o To successfully authenticate, the server must own the valid 200 registered credentials (authentication secret), as well as client 201 users. (Non-intuitively, this is not true for Basic and Digest 202 authentication. For example, servers for Basic authentications 203 can answer "YES" to any clients, without actually checking 204 authentication at all.) This means that phishing attackers cannot 205 forge users that they are the "authentic" servers. Client users 206 can assert whether the communicating peer is "the server" who have 207 registered their account beforehand. In other words, it provides 208 "true" mutual authentication between servers and clients. 210 Given these, the proposed protocol can serve as a strong alternative 211 to the Basic, Digest, and web-form-based authentications, and also as 212 a strong companion to the non-password-based authentication framework 213 systems. 215 The Mutual authentication protocol proposed in this document is a 216 strong cryptographic solution for password authentications. It 217 mainly provides the two key features: 219 Technically, the authentication scheme proposed in this document is a 220 general framework for using password-based authenticated key exchange 221 (PAKE) and similar stronger cryptographic primitives with HTTP. The 222 two key features shown above are corresponding to the nature of PAKE. 224 1.1. Terminology 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 228 "OPTIONAL" in this document are to be interpreted as described in 229 [RFC2119]. 231 This document distinguishes the terms "client" and "user" in the 232 following way: A "client" is an entity understanding and talking HTTP 233 and the specified authentication protocol, usually computer software; 234 a "user" is a (usually natural) person who wants to access data 235 resources using a "client". 237 The term "natural numbers" refers to the non-negative integers 238 (including zero) throughout this document. 240 This document treats both the input (domain) and the output 241 (codomain) of hash functions to be octet strings. When a natural 242 number output is required, the notation INT(H(s)) is used. 244 1.2. Document Structure and Related Documents 246 The entire document is organized as follows: 248 o Section 2 presents an overview of the protocol design. 250 o Sections 3 to 11 define a general framework of the Mutual 251 authentication protocol. This framework is independent of 252 specific cryptographic primitives. 254 o Section 12 describes properties needed for cryptographic 255 algorithms used with this protocol framework, and defines a few 256 functions which will be shared among such cryptographic 257 algorithms. 259 o The sections after that contain general normative and informative 260 information about the protocol. 262 o The appendices contain some information that may help developers 263 to implement the protocol. 265 In addition, there are two companion documents which are referred 266 from/related to this specification: 268 o [I-D.ietf-httpauth-mutual-algo]: defines cryptographic primitives 269 which can be used with this protocol framework. 271 o [I-D.ietf-httpauth-extension]: defines small but useful extensions 272 to the current HTTP authentication framework so that it can 273 support application-level semantics of existing Web systems. 275 2. Protocol Overview 277 The protocol, as a whole, is designed as a natural extension to the 278 HTTP protocol [RFC7230] using a framework defined in [RFC7235]. 279 Internally, the server and the client will first perform a 280 cryptographic key exchange, using the secret password as a "tweak" to 281 the exchange. The key exchange will only succeed when the secrets 282 used by the both peers are correctly related (i.e., generated from 283 the same password). Then, both peers will verify the authentication 284 results by confirming the sharing of the exchanged key. This section 285 provides a brief outline of the protocol and the exchanged messages. 287 2.1. Messages Overview 289 The authentication protocol uses seven kinds of messages to perform 290 mutual authentication. These messages have specific names within 291 this specification. 293 o Authentication request messages: used by the servers to request 294 clients to start mutual authentication. 296 * 401-INIT message: a general message to start the authentication 297 protocol. It is also used as a message indicating an 298 authentication failure. 300 * 401-STALE message: a message indicating that client has to 301 start a new key exchange. 303 o Authenticated key exchange messages: used by both peers to perform 304 authentication and the sharing of a cryptographic secret. 306 * req-KEX-C1 message: a message sent from the client. 308 * 401-KEX-S1 message: an intermediate response to a req-KEX-C1 309 message from the server. 311 o Authentication verification messages: used by both peers to verify 312 the authentication results. 314 * req-VFY-C message: a message used by the client, requesting the 315 server authenticate and authorize the client. 317 * 200-VFY-S message: a response used by the server to indicate 318 the successful client-authentication. It also contains 319 information necessary for the client to check the authenticity 320 of the server. 322 In addition to the above, either a request or a response without any 323 HTTP headers related to this specification will be hereafter called a 324 "normal request" or a "normal response", respectively. 326 2.2. Typical Flows of the Protocol 328 In typical cases, the client access to a resource protected by the 329 Mutual authentication scheme will use the following protocol 330 sequence. 332 Client Server 333 | | 334 | ---- (1) normal request ---------> | 335 GET / HTTP/1.1 | 336 | | 337 | <---------------- (2) 401-INIT --- | 338 | 401 Authentication Required 339 | WWW-Authenticate: Mutual realm="a realm" 340 | | 341 [user, | | 342 pass]-->| | 343 | ---- (3) req-KEX-C1 -------------> | 344 GET / HTTP/1.1 | 345 Authorization: Mutual user="john", |--> [user DB] 346 kc1="...", ... |<-- [user info] 347 | | 348 | <-------------- (4) 401-KEX-S1 --- | 349 | 401 Authentication Required 350 | WWW-Authenticate: Mutual sid=..., ks1="...", ... 351 | | 352 [compute] (5) compute session secret [compute] 353 | | 354 | | 355 | ---- (6) req-VFY-C --------------> | 356 GET / HTTP/1.1 |--> [verify (6)] 357 Authorization: Mutual sid=..., |<-- OK 358 vkc="...", ... | 359 | | 360 | <--------------- (7) 200-VFY-S --- | 361 [verify | 200 OK | 362 (7)]<--| Authentication-Info: Mutual vks="..." 363 | | 364 v v 366 Figure 1: Typical communication flow for first access to resource 368 o As usual in general HTTP protocol designs, a client will at first 369 request a resource without any authentication attempt (1). If the 370 requested resource is protected by the Mutual authentication, the 371 server will respond with a message requesting authentication 372 (401-INIT) (2). 374 o The client processes the body of the message and waits for the 375 user to input the user name and a password. If the user name and 376 the password are available, the client will send a message with 377 the authenticated key exchange (req-KEX-C1) to start the 378 authentication (3). 380 o If the server has received a req-KEX-C1 message, the server looks 381 up the user's authentication information within its user database. 382 Then the server creates a new session identifier (sid) that will 383 be used to identify sets of the messages that follow it and 384 responds back with a message containing a server-side 385 authenticated key exchange value (401-KEX-S1) (4). 387 o At this point (5), both peers calculate a shared "session secret" 388 using the exchanged values in the key exchange messages. Only 389 when both the server and the client have used secret credentials 390 generated from the same password will the session secret values 391 match. This session secret will be used for access authentication 392 of every individual request/response pair after this point. 394 o The client will send a request with a client-side authentication 395 verification value (req-VFY-C) (6), calculated from the client- 396 generated session secret. The server will check the validity of 397 the verification value using its own version of the session 398 secret. 400 o If the authentication verification value from the client was 401 correct, it means that the client definitely owns the credential 402 based on the expected password (i.e., the client authentication 403 succeeded). The server will respond with a successful message 404 (200-VFY-S) (7). Contrary to the usual one-way authentication 405 (e.g., HTTP Basic authentication or POP APOP authentication 406 [RFC1939]), this message also contains a server-side 407 authentication verification value. 409 When the client's verification value is incorrect (e.g., because 410 the user-supplied password was incorrect), the server will respond 411 with the 401-INIT message (the same one as used in (2)) instead. 413 o The client MUST first check the validity of the server-side 414 authentication verification value contained in the message (7). 415 If the value was equal to the expected one, server authentication 416 succeeded. 418 If it is not the value expected, or if the message does not 419 contain the authentication verification value, it means that the 420 mutual authentication has been broken for some unexpected reason. 421 The client MUST NOT process any body or header values contained in 422 the HTTP response in this case. (Note: This case should not 423 happen between a correctly implemented server and client without 424 any active attacks. The possible cause of such a case might be 425 either a man-in-the-middle attack or an incorrect implementation.) 427 2.3. Alternative Flows 429 As shown above, the typical flow for a first authentication request 430 requires three request-response pairs. To reduce the protocol 431 overhead, the protocol enables several short-cut flows which require 432 fewer messages. 434 o (case A) If the client knows that the resource is likely to 435 require authentication, the client MAY omit the first 436 unauthenticated request (1) and immediately send a key exchange 437 (req-KEX-C1 message). This will reduce one round-trip of 438 messages. 440 o (case B) If both the client and the server previously shared a 441 session secret associated with a valid session identifier (sid), 442 the client MAY directly send a req-VFY-C message using the 443 existing session identifier and corresponding session secret. 444 This will further reduce one round-trip of messages. 446 The server MAY have thrown out the corresponding session from the 447 session table. If so, the server will respond with a 401-STALE 448 message, indicating a new key exchange is required. The client 449 SHOULD retry constructing a req-KEX-C1 message in this case. 451 Figure 2 depicts the shortcut flows described above. Under the 452 appropriate settings and implementations, most of the requests to 453 resources are expected to meet both criteria, and thus only one 454 round-trip of request/response will be required. 456 (A) omit first request 457 (2 round trips) 459 Client Server 460 | | 461 | --- req-KEX-C1 ----> | 462 | | 463 | <---- 401-KEX-S1 --- | 464 | | 465 | ---- req-VFY-C ----> | 466 | | 467 | <----- 200-VFY-S --- | 468 | | 470 (B) reusing session secret (re-authentication) 472 (B-1) key available (B-2) key expired 473 (1 round trip) (3 round trips) 475 Client Server Client Server 476 | | | | 477 | ---- req-VFY-C ----> | | --- req-VFY-C -------> | 478 | | | | 479 | <----- 200-VFY-S --- | | <------- 401-STALE --- | 480 | | | | 481 | --- req-KEX-C1 ------> | 482 | | 483 | <------ 401-KEX-S1 --- | 484 | | 485 | --- req-VFY-C -------> | 486 | | 487 | <------- 200-VFY-S --- | 488 | | 490 Figure 2: Several alternative protocol flows 492 For more details, see Sections 10 and 11. 494 3. Message Syntax 496 Throughout this specification, the syntax is denoted in the extended 497 augmented BNF syntax defined in [RFC7230], and [RFC5234]. The 498 following elements are quoted from [RFC5234], [RFC7230] and 499 [RFC7235]: DIGIT, ALPHA, SP, auth-scheme, quoted-string, auth-param, 500 header-field, token, challenge, and credential. 502 The Mutual authentication protocol uses three headers: 503 WWW-Authenticate (usually in responses with status code 401), 504 Authorization (in requests), and Authentication-Info (in responses 505 other than 401 status). These headers follow a common framework 506 described in [RFC7235] and [RFC7615]. The detailed meanings for 507 these headers are contained in Section 4. 509 The framework in [RFC7235] defines the syntax for the headers 510 WWW-Authenticate and Authorization as the syntax elements "challenge" 511 and "credentials", respectively. The "auth-scheme" contained in 512 those headers MUST be "Mutual" throughout this protocol 513 specification. The syntax for "challenge" and "credentials" to be 514 used with the "Mutual" auth-scheme SHALL be name-value pairs (#auth- 515 param), not the "b64token" defined in [RFC7235]. 517 The Authentication-Info: header used in this protocol SHALL follow 518 the syntax defined in [RFC7615]. 520 In HTTP, the WWW-Authenticate header may contain two or more 521 challenges. Client implementations SHOULD be aware of and be capable 522 of handling those cases correctly. 524 3.1. Non-ASCII extended header parameters 526 All of parameters contained in the above three headers, except the 527 "realm" field, MAY be extended to ISO 10646-1 values using the 528 framework described in [RFC5987]. All servers and clients MUST be 529 capable of receiving and sending values encoded in [RFC5987] syntax. 531 If a value to be sent contains only ASCII characters, the field MUST 532 be sent using plain RFC 7235 syntax. The syntax as extended by RFC 533 5987 MUST NOT be used in this case. 535 If a value (except the "realm" header) contains one or more non-ASCII 536 characters, the parameter SHOULD be sent using the syntax defined in 537 Section 3.2 of [RFC5987] as "ext-parameter". Such a parameter MUST 538 have a charset value of "UTF-8", and the language value MUST always 539 be omitted (have an empty value). The same parameter MUST NOT be 540 sent more than once, regardless of the used syntax. 542 For example, a parameter "user" with value "Renee of France" SHOULD 543 be sent as < user="Renee of France" >. If the value is 544 "Rene of France", it SHOULD be sent as < user*=UTF- 545 8''Ren%C3%89e%20of%20France > instead. 547 [RFC7235] requires the realm parameter to be in its plain form (not 548 as an extended "realm*" parameter), so RFC 5987 syntax MUST NOT be 549 used for this parameter. 551 3.2. Values 553 The parameter values contained in challenge/credentials MUST be 554 parsed strictly conforming to the HTTP semantics (especially un- 555 quoting of the string parameter values). In this protocol, those 556 values are further categorized into the following value types: tokens 557 (bare-token and extensive-token), string, integer, hex-fixed-number, 558 and base64-fixed-number. 560 For clarity, implementations are RECOMMENDED to use the canonical 561 representations specified in the following subsections for sending 562 values. Recipients SHOULD accept both quoted and unquoted 563 representations interchangeably as specified in HTTP. 565 3.2.1. Tokens 567 For sustaining both security and extensibility at the same time, this 568 protocol defines a stricter sub-syntax for the "token" to be used. 569 Extensive-token values SHOULD use the following syntax (after HTTP 570 value parsing): 572 bare-token = 1*(DIGIT / ALPHA / "-" / "_") 573 extension-token = "-" bare-token 1*("." bare-token) 574 extensive-token = bare-token / extension-token 576 Figure 3: BNF syntax for token values 578 The tokens (bare-token and extension-token) are case insensitive; 579 Senders SHOULD send these in lower case, and receivers MUST accept 580 both upper and lower cases. When tokens are used as (partial) inputs 581 to any hash or other mathematical functions, they MUST always be used 582 in lower case. 584 Extensive-tokens are used in this protocol where the set of 585 acceptable tokens may include non-standard extensions. Any extension 586 of this protocol MAY use either the bare-tokens allocated by IANA 587 (under the procedure described in Section 16), or extension-tokens 588 with the format "-.", where is 589 a valid (sub-)domain name on the Internet owned by the party who 590 defines the extension. 592 Bare-tokens and extensive-tokens are also used for parameter names, 593 in the unquoted form. Requirements for using the extension-token for 594 the parameter names are the same as the previous paragraph. 596 The canonical format for bare-tokens and extensive-tokens is the 597 unquoted representation. 599 3.2.2. Strings 601 All character strings MUST be encoded to octet strings using the 602 UTF-8 encoding [RFC3629] for the ISO 10646-1 character set 603 [ISO.10646-1.1993]. Such strings MUST NOT contain any leading BOM 604 characters (ZERO WIDTH NO-BREAK SPACE, U+FEFF or EF BB BF). Both 605 peers are RECOMMENDED to reject any invalid UTF-8 sequences that 606 might cause decoding ambiguities (e.g., containing <"> in the second 607 or later bytes of the UTF-8 encoded characters). 609 If strings are representing a domain name or URI that contains non- 610 ASCII characters, the host parts SHOULD be encoded as it is used in 611 the HTTP protocol layer (e.g., in a Host: header); under current 612 standards it will be the one defined in [RFC5890]. It SHOULD use 613 lower-case ASCII characters. 615 The canonical format for strings is quoted-string (as it may contain 616 equal signs, plus signs and slashes), unless the parameter containing 617 the string value will use extended syntax defined in [RFC5987]. (An 618 [RFC5987] extended parameter will have an unquoted encoded value, as 619 defined therein.) 621 3.2.3. Numbers 623 The following syntax definitions give a syntax for numeric values: 625 integer = "0" / (%x31-39 *DIGIT) ; no leading zeros 626 hex-fixed-number = 1*(2(DIGIT / %x41-46 / %x61-66)) 627 base64-fixed-number = 1*( ALPHA / DIGIT / "+" / "/" ) 0*2"=" 629 Figure 4: BNF syntax for numbers 631 The syntax definition of the integers only allows representations 632 that do not contain leading zeros. 634 A number represented as a hex-fixed-number MUST include an even 635 number of hexadecimal digits (i.e., multiples of eight bits). Those 636 values are case-insensitive, and SHOULD be sent in lower case. When 637 these values are generated from any cryptographic values, they SHOULD 638 have their "natural length"; if these are generated from a hash 639 function, these lengths SHOULD correspond to the hash size; if these 640 are representing elements of a mathematical set (or group), its 641 lengths SHOULD be the shortest for representing all the elements in 642 the set. For example, the results of the SHA-256 hash function will 643 be represented by 64 digits, and any elements in a 2048-bit prime 644 field (modulo a 2048-bit integer) will be represented by 512 digits, 645 regardless of how much zeros appear in front of such representations. 646 Session-identifiers and other non-cryptographically generated values 647 are represented in any (even) length determined by the side that 648 generates it first, and the same length SHALL be used throughout all 649 communications by both peers. 651 The numbers represented as base64-fixed-number SHALL be generated as 652 follows: first, the number is converted to a big-endian radix-256 653 binary representation as an octet string. The length of the 654 representation is determined in the same way as mentioned above. 655 Then, the string is encoded using the Base 64 encoding [RFC4648] 656 without any spaces and newlines. Implementations decoding base64- 657 fixed-number SHOULD reject any input data with invalid characters, 658 excess/insufficient padding, or non-canonical pad bits (See Sections 659 3.1 to 3.5 of [RFC4648]). 661 The canonical format for integer and hex-fixed-number are unquoted 662 tokens, and that for base64-fixed-number is quoted-string. 664 4. Messages 666 In this section we define the seven kinds of messages used in the 667 authentication protocol along with the formats and requirements of 668 the headers for each message. 670 To determine in what circumstances each message is expected to be 671 sent, see Sections 10 and 11. 673 In the descriptions below, the type of allowable values for each 674 header parameter is shown in parenthesis after each parameter name. 675 The "algorithm-determined" type means that the acceptable value for 676 the parameter is one of the types defined in Section 3, and is 677 determined by the value of the "algorithm" parameter. The parameters 678 marked "mandatory" SHALL be contained in the message. The parameters 679 marked "non-mandatory" MAY either be contained or omitted in the 680 message. Each parameter SHALL appear in each header exactly once at 681 most. 683 All credentials and challenges MAY contain any parameters not 684 explicitly specified in the following sections. Recipients that do 685 not understand such parameters MUST silently ignore those. However, 686 all credentials and challenges MUST meet the following criteria: 688 o For responses, the parameters "reason", any "ks#" (where # stands 689 for any decimal integer), and "vks" are mutually exclusive; any 690 challenge MUST NOT contain two or more parameters among them. 691 They MUST NOT contain any "kc#" or "vkc" parameters. 693 o For requests, the parameters "kc#" (where # stands for any decimal 694 integer), and "vkc" are mutually exclusive and any challenge 695 MUST NOT contain two or more parameters among them. They MUST NOT 696 contain any "ks#" or "vks" parameters. 698 Every message in this section contains a "version" field, to detect 699 future, incompatible revisions of the protocol. Implementations of 700 the protocol described in this specification MUST always send a token 701 "1", and recipients MUST reject messages that contain any other value 702 as a version, unless another specification defines a behavior for 703 that version. 705 4.1. 401-INIT and 401-STALE 707 Every 401-INIT or 401-STALE message SHALL be a valid HTTP 401-status 708 (Authentication Required) message (or other 4XX status if sensible) 709 containing one and only one (hereafter not explicitly noted) 710 "WWW-Authenticate" header containing a "reason" parameter in the 711 challenge. The challenge SHALL contain all of the parameters marked 712 "mandatory" below, and MAY contain those marked "non-mandatory". 714 version: (mandatory extensive-token) should be the token "1". 716 algorithm: (mandatory extensive-token) specifies the 717 authentication algorithm to be used. The value MUST 718 be one of the tokens specified in 719 [I-D.ietf-httpauth-mutual-algo] or another 720 supplemental specification. 722 validation: (mandatory extensive-token) specifies the method of 723 host validation. The value MUST be one of the tokens 724 described in Section 7 or the tokens specified in 725 another supplemental specification. 727 auth-scope: (non-mandatory string) specifies the authentication 728 scope, the set of hosts for which the authentication 729 credentials are valid. It MUST be one of the strings 730 described in Section 5. If the value is omitted, it 731 is assumed to be the "single-server" type domain in 732 Section 5. 734 realm: (mandatory string) is a string representing the name 735 of the authentication realm inside the authentication 736 scope. As specified in [RFC7235], this value MUST 737 always be sent in the quoted-string form, and an 738 [RFC5987] encoding MUST NOT be used. 739 The realm value sent from the server SHOULD be an 740 ASCII string. Clients MAY treat any non-ASCII value 741 received in this field as a binary blob, an NFC- 742 normalized UTF-8 string, or an error. 744 reason: (mandatory extensive-token) SHALL be an extensive- 745 token that describes the possible reason of the failed 746 authentication/authorization. Both servers and 747 clients SHALL understand and support the following 748 three tokens: 750 * initial: authentication was not tried because there 751 was no Authorization header in the corresponding 752 request. 754 * stale-session: the provided sid in the request was 755 either unknown to or expired in the server. 757 * auth-failed: authentication trial was failed for 758 some reason, possibly with a bad authentication 759 credential. 761 Implementations MAY support the following tokens or 762 any extensive-tokens defined outside this 763 specification. If clients receive any unknown tokens, 764 they SHOULD treat these as if they were "auth-failed" 765 or "initial". 767 * reauth-needed: the server-side application requires 768 a new authentication trial, regardless of the 769 current status. 771 * invalid-parameters: the server did not attempt 772 authentication because some parameters were not 773 acceptable. 775 * internal-error: the server did not attempt 776 authentication because there are some troubles on 777 the server-side. 779 * user-unknown: this is a special case of auth- 780 failed, suggesting that the provided user name is 781 invalid. The use of this parameter is 782 NOT RECOMMENDED due to security implications, 783 except for special-purpose applications where it 784 makes sense. 786 * invalid-credential: ditto, suggesting that the 787 provided user name was valid but authentication 788 still failed. The use of this parameter is 789 NOT RECOMMENDED for security reasons. 791 * authz-failed: authentication was successful, but 792 access to the specified resource is not authorized 793 to the specific authenticated user. (It might be 794 used along with either a 401 or 403 status to 795 indicate that the authentication result is one of 796 the existing reasons for the failed authorization.) 798 It is &RECOMMENDED to record the reasons to a kind of 799 diagnostic log, for an example, or shown to the client 800 user immediately. It will be helpful to find out 801 later that the reason of the failed authentication is 802 either technical reasons of user errors. 804 The algorithm specified in this header will determine the types 805 (among those defined in Section 3) and the values for K_c1, K_s1, 806 VK_c and VK_s. 808 Among these messages, those with the reason parameter of value 809 "stale-session" will be called "401-STALE" messages hereafter, 810 because these have a special meaning in the protocol flow. Messages 811 with any other reason parameters will be called "401-INIT" messages. 813 4.2. req-KEX-C1 815 Every req-KEX-C1 message SHALL be a valid HTTP request message 816 containing an "Authorization" header with a credential containing a 817 "kc1" parameter. 819 The credential SHALL contain the parameters with the following names: 821 version: (mandatory, extensive-token) should be the token "1". 823 algorithm, validation, auth-scope, realm: MUST be the same values as 824 received from the server. 826 user: (mandatory, string) is the UTF-8 encoded name of the 827 user. The string SHOULD be prepared according to the 828 method presented in Section 9. 830 kc1: (mandatory, algorithm-determined) is the client-side 831 key exchange value K_c1, which is specified by the 832 algorithm that is used. 834 4.3. 401-KEX-S1 836 Every 401-KEX-S1 message SHALL be a valid HTTP 401-status 837 (Authentication Required) response message containing a 838 "WWW-Authenticate" header with a challenge containing a "ks1" 839 parameter. 841 The challenge SHALL contain the parameters with the following names: 843 version: (mandatory, extensive-token) should be the token "1". 845 algorithm, validation, auth-scope, realm: MUST be the same values as 846 received from the client. 848 sid: (mandatory, hex-fixed-number) MUST be a session 849 identifier, which is a random integer. The sid SHOULD 850 have uniqueness of at least 80 bits or the square of 851 the maximum estimated transactions concurrently 852 available in the session table, whichever is larger. 853 See Section 6 for more details. 855 ks1: (mandatory, algorithm-determined) is the server-side 856 key exchange value K_s1, which is specified by the 857 algorithm. 859 nc-max: (mandatory, integer) is the maximum value of nonce 860 numbers that the server accepts. 862 nc-window: (mandatory, integer) the number of available nonce 863 number slots that the server will accept. The value 864 of the nc-window parameter is RECOMMENDED to be 128 or 865 more. 867 time: (mandatory, integer) represents the suggested time (in 868 seconds) that the client can reuse the session 869 represented by the sid. It is RECOMMENDED to be at 870 least 60. The value of this parameter is not directly 871 linked to the duration that the server keeps track for 872 the session represented by the sid. 874 path: (non-mandatory, string) specifies which path in the 875 URI space the same authentication is expected to be 876 applied. The value is a space-separated list of URIs, 877 in the same format as it was specified in domain 878 parameter [RFC7616] for Digest authentications. All 879 path elements contained in the parameter MUST be 880 inside the specified auth-scope; if not, clients 881 SHOULD ignore such elements. For better performance, 882 recognition of this parameter by clients is important. 884 4.4. req-VFY-C 886 Every req-VFY-C message SHALL be a valid HTTP request message 887 containing an "Authorization" header with a credential containing a 888 "vkc" parameter. 890 The parameters contained in the header are as follows: 892 version: (mandatory, extensive-token) should be the token "1". 894 algorithm, validation, auth-scope, realm: MUST be the same values as 895 received from the server for the session. 897 sid: (mandatory, hex-fixed-number) MUST be one of the sid 898 values that was received from the server for the same 899 authentication realm. 901 nc: (mandatory, integer) is a nonce request number that is 902 unique among the requests sharing the same sid. The 903 values of the nonce numbers SHOULD satisfy the 904 properties outlined in Section 6. 906 vkc: (mandatory, algorithm-determined) is the client-side 907 authentication verification value VK_c, which is 908 specified by the algorithm. 910 4.5. 200-VFY-S 912 Every 200-VFY-S message SHALL be a valid HTTP message that does not 913 have a 401 (Authentication Required) status code and SHALL contain an 914 "Authentication-Info" header with a "vks" parameter. 916 The parameters contained in the header are as follows: 918 version: (mandatory, extensive-token) should be the token "1". 920 sid: (mandatory, hex-fixed-number) MUST be the value 921 received from the client. 923 vks: (mandatory, algorithm-determined) is the server-side 924 authentication verification value VK_s, which is 925 specified by the algorithm. 927 The header MUST be sent before the content body: it MUST NOT be sent 928 in the trailer of a chunked-encoded response. If a "100 Continue" 929 response is sent from the server, the Authentication-Info header 930 SHOULD be included in that response, instead of the final response. 932 5. Authentication Realms 934 In this protocol, an "authentication realm" is defined as a set of 935 resources (URIs) for which the same set of user names and passwords 936 is valid. If the server requests authentication for an 937 authentication realm that the client is already authenticated for, 938 the client will automatically perform the authentication using the 939 already-known credentials. However, for different authentication 940 realms, clients MUST NOT automatically reuse user names and passwords 941 for another realm. 943 Just like in the Basic and Digest access authentication protocols, 944 the Mutual authentication protocol supports multiple, separate 945 protection spaces to be set up inside each host. Furthermore, the 946 protocol allows a single authentication realm to span over several 947 hosts within the same Internet domain. 949 Each authentication realm is defined and distinguished by the triple 950 of an "authentication algorithm", an "authentication scope", and a 951 "realm" parameter. However, server operators are NOT RECOMMENDED to 952 use the same pair of an authentication scope and a realm with 953 different authentication algorithms. 955 The realm parameter is a string as defined in Section 4. 956 Authentication scopes are described in the remainder of this section. 958 An authentication scope specifies the range of hosts that the 959 authentication realm spans over. In this protocol, it MUST be one of 960 the following kinds of strings. 962 o Single-server type: A string in the format "://" or 963 "://:", where , , and are 964 the corresponding URI parts of the request URI. If the default 965 port (i.e., 80 for http and 443 for https) is used for the 966 underlying HTTP communications, the port part MUST be omitted, 967 regardless of whether it was present in the request-URI. In all 968 other cases, the port part MUST be present, and it MUST NOT 969 contain leading zeros. Use this format when authentication is 970 only valid for a specific protocol (such as https). This format 971 is equivalent to the ASCII serialization of a Web Origin, 972 presented in Section 6.2 of [RFC6454]. 974 o Single-host type: The "host" part of the requested URI. This is 975 the default value. Authentication realms within this kind of 976 authentication scope will span over several protocols (e.g., http 977 and https) and ports, but not over different hosts. 979 o Wildcard-domain type: A string in the format "*.", 980 where is either the host part of the requested 981 URI or any domain in which the requested host is included (this 982 means that the specification "*.example.com" is valid for all of 983 hosts "www.example.com", "web.example.com", 984 "www.sales.example.com" and "example.com"). The domain-postfix 985 sent by the servers MUST be equal to or included in a valid 986 Internet domain assigned to a specific organization; if clients 987 know, by some means such as a blacklist for HTTP cookies 988 [RFC6265], that the specified domain is not to be assigned to any 989 specific organization (e.g., "*.com" or "*.jp"), clients are 990 RECOMMENDED to reject the authentication request. 992 In the above specifications, every "scheme", "host", and "domain" 993 MUST be in lower case, and any internationalized domain names beyond 994 the ASCII character set SHALL be represented in the way they are sent 995 in the underlying HTTP protocol, represented in lower case 996 characters, i.e., these domain names SHALL be in the form of LDH 997 labels in IDNA [RFC5890]. A "port" MUST be given in the shortest, 998 unsigned, decimal number notation. Not obeying these requirements 999 will cause failure of valid authentication attempts. 1001 5.1. Resolving Ambiguities 1003 In the above definitions of authentication scopes, several scopes may 1004 overlap each other. If a client has already been authenticated to 1005 several realms applicable to the same server, the client may have a 1006 multiple lists of the "path" parameters received with the 1007 "401-KEX-S1" message (see Section 4). If these path lists have any 1008 overlap, a single URI may belong to multiple possible candidate of 1009 realms to be authenticated to. In such cases, clients faces an 1010 ambiguity in deciding which credentials to send for a new request (in 1011 steps 3 and 4 of the decision procedure presented in Section 10). 1013 In such cases, a client MAY send request which belong to any of these 1014 candidate realms freely, or it MAY simply send an unauthenticated 1015 request and see for which realm the server requests an 1016 authentication. Server operators are RECOMMENDED to provide 1017 properly-configured "path" parameters (more precisely, disjoint path 1018 sets for each realms) for clients so that such ambiguities will not 1019 occur. 1021 The following procedure is one possible tactic for resolving 1022 ambiguity in such cases. 1024 o If the client has previously sent a request to the same URI, and 1025 if it remembers the authentication realm requested by the 401-INIT 1026 message at that time, use that realm. 1028 o In other cases, use one of the authentication realms representing 1029 the most-specific authentication scopes. The list of possible 1030 domain specifications shown above is given from most specific to 1031 least specific. 1033 If there are several choices with different wildcard-domain 1034 specifications, the one that has the longest domain-postfix has 1035 priority over ones with shorter domain-postfixes. 1037 o If there are realms with the same authentication scope, there is 1038 no defined priority; the client MAY choose any one of the possible 1039 choices. 1041 6. Session Management 1043 In the Mutual authentication protocol, a session represented by an 1044 sid is set up using four messages (first request, 401-INIT, 1045 req-KEX-C1 and 401-KEX-S1), after which a "session secret" (z) 1046 associated with the session is established. After mutually 1047 establishing a session secret, this session, along with the secret, 1048 can be used for one or more requests for resources protected by the 1049 same realm on the same server. Note that session management is only 1050 an inside detail of the protocol and usually not visible to normal 1051 users. If a session expires, the client and server SHOULD 1052 automatically re-establish another session without informing the 1053 user. 1055 Sessions and session identifiers are local to each server (defined by 1056 scheme, host, and port), even if an authentication scope covers 1057 multiple servers; clients MUST establish separate sessions for each 1058 port of a host to be accessed. Furthermore, sessions and identifiers 1059 are also local to each authentication realm, even if these are 1060 provided by the same server. The same session identifiers provided 1061 either from different servers or for different realms MUST be treated 1062 as independent or each other. 1064 The server SHOULD accept at least one req-VFY-C request for each 1065 session, if the request reaches the server in a time window specified 1066 by the timeout parameter in the 401-KEX-S1 message, and there are no 1067 emergent reasons (such as flooding attacks) to forget the session. 1068 After that, the server MAY discard any session at any time and MAY 1069 send 401-STALE messages for any further req-VFY-C requests received 1070 for that session. 1072 The client MAY send two or more requests using a single session 1073 specified by the sid. However, for all such requests, each value of 1074 the nonce number (in the nc parameter) MUST satisfy the following 1075 conditions: 1077 o It is a natural number. 1079 o The same nonce number was not sent within the same session. 1081 o It is not larger than the nc-max value that was sent from the 1082 server in the session represented by the sid. 1084 o It is larger than (largest-nc - nc-window), where largest-nc is 1085 the largest value of nc which was previously sent in the session, 1086 and nc-window is the value of the nc-window parameter that was 1087 received from the server for the session. 1089 The last condition allows servers to reject any nonce numbers that 1090 are "significantly" smaller than the "current" value (defined by the 1091 value of nc-window) of the nonce number used in the session involved. 1092 In other words, servers MAY treat such nonce numbers as "already 1093 received". This restriction enables servers to implement duplicate 1094 nonce detection in a constant amount of memory for each session. 1096 Servers MUST check for duplication of the received nonce numbers, and 1097 if any duplication is detected, the server MUST discard the session 1098 and respond with a 401-STALE message, as outlined in Section 11. The 1099 server MAY also reject other invalid nonce numbers (such as ones 1100 above the nc-max limit) by sending a 401-STALE message. 1102 For example, assume the nc-window value of the current session is 1103 128, nc-max is 400, and that the client has already used the 1104 following nonce numbers: {1-120, 122, 124, 130-238, 255-360, 363- 1105 372}. Then the nonce number that can be used for the next request is 1106 one of the following set: {245-254, 361, 362, 373-400}. The values 1107 {0, 121, 123, 125-129, 239-244} MAY be rejected by the server because 1108 they are not above the current "window limit" (244 = 372 - 128). 1110 Typically, clients can ensure the above property by using a 1111 monotonically-increasing integer counter that counts from zero up to 1112 the value of nc-max. 1114 The values of the nonce numbers and any nonce-related values MUST 1115 always be treated as natural numbers within an infinite range. 1116 Implementations which uses fixed-width integer representations, 1117 fixed-precision floating-point numbers, or similar representations 1118 SHOULD NOT reject any larger values which overflow such 1119 representative limits, and MUST NOT silently truncate them using any 1120 modulus-like rounding operation (e.g., by mod 2^32). Instead, the 1121 whole protocol is carefully designed so that recipients MAY replace 1122 any such overflowing values (e.g. 2^80) with some reasonably-large 1123 maximum representative integer (e.g., 2^31 - 1 or others). 1125 7. Host Validation Methods 1127 The "validation method" specifies a method to "relate" (or "bind") 1128 the mutual authentication processed by this protocol with other 1129 authentications already performed in the underlying layers and to 1130 prevent man-in-the-middle attacks. It determines the value vh that 1131 is an input to the authentication protocols. 1133 When HTTPS or other possible secure transport is used, this 1134 corresponds to the idea of "channel binding" described in [RFC5929]. 1135 Even when HTTP is used, similar, but somewhat limited, "binding" is 1136 performed to prevent a malicious server from trying to authenticate 1137 itself to another server as a valid user by forwarding the received 1138 credentials. 1140 The valid tokens for the validation parameter and corresponding 1141 values of vh are as follows: 1143 host: host-name validation: The value vh will be the ASCII 1144 string in the following format: 1145 "://:", where , , 1146 and are the URI components corresponding to the 1147 currently accessing server-side resource. The scheme 1148 and host are in lower case, and the port is in a 1149 shortest decimal representation. Even if the request- 1150 URI does not have a port part, v will include the 1151 default port number. 1153 tls-server-end-point: TLS endpoint (certificate) validation: The 1154 value vh will be the octet string of the hash value of 1155 the server's public key certificate used in the 1156 underlying TLS [RFC5246] connection, processed as 1157 specified in Section 4.1 of [RFC5929]. 1159 tls-unique: TLS shared-key validation: The value vh will be the 1160 channel binding material derived from the Finished 1161 messages, as defined in Section 3.1 of [RFC5929]. 1162 (Note: see Section 7.2 for some security notices when 1163 using this validation method.) 1165 If HTTP is used on a non-encrypted channel (TCP and SCTP, for 1166 example), the validation type MUST be "host". If HTTP/TLS [RFC2818] 1167 (HTTPS) is used with a server certificate, the validation type MUST 1168 be "tls-server-end-point". If HTTP/TLS is used with an anonymous 1169 Diffie-Hellman key exchange, the validation type MUST be "tls-unique" 1170 (see the note below). 1172 Implementations supporting Mutual authentication over HTTPS SHOULD 1173 support the "tls-server-end-point" validation. Support for 1174 "tls-unique" validation is OPTIONAL for both servers and clients. 1176 If the validation type "tls-server-end-point" is used, the server 1177 certificate provided in the TLS connection MUST be verified at least 1178 to make sure that the server actually owns the corresponding private 1179 key. (Note: this verification is automatic in some RSA-based key 1180 exchanges but NOT automatic in Diffie-Hellman-based key exchanges 1181 with separate exchange for server verification.) 1183 Clients MUST validate this parameter upon receipt of 401-INIT 1184 messages. 1186 Note: The protocol defines two variants of validation on the TLS 1187 connections. The "tls-unique" method is more secure. However, there 1188 are some situations where tls-server-end-point is more preferable. 1190 o When TLS accelerating proxies are used, it is difficult for the 1191 authenticating server to acquire the TLS key information that is 1192 used between the client and the proxy. This is not the case for 1193 client-side "tunneling" proxies using the HTTP CONNECT method. 1195 o When a black-box implementation of the TLS protocol is used on 1196 either peer. 1198 7.1. Applicability notes 1200 When the client is a Web browser with any scripting capabilities, the 1201 underlying TLS channel used with HTTP/TLS MUST provide server 1202 identity verification. This means (1) anonymous Diffie-Hellman key 1203 exchange cipher suites MUST NOT be used, and (2) verification of the 1204 server certificate provided by the server MUST be performed. 1206 For other systems, when the underlying TLS channel used with HTTP/TLS 1207 does not perform server identity verification, the client SHOULD 1208 ensure that all the responses are validated using the Mutual 1209 authentication protocol, regardless of the existence of 401-INIT 1210 responses. 1212 7.2. Notes on tls-unique 1214 As described in the interoperability note in the above channel 1215 binding specification, the tls-unique verification value will be 1216 changed by possible TLS renegotiation, causing an interoperability 1217 problem. TLS re-negotiations are used in several HTTPS server 1218 implementations for enforcing some security properties (such as 1219 cryptographic strength) for some specific responses. 1221 If an implementation supports the "tls-unique" verification method, 1222 the following caution SHOULD be taken: 1224 o Both peers must be aware that the vh values used for vkc (in 1225 req-VFY-C) and for vks (in 200-VFY-S) may be different. These 1226 values MUST be retrieved from underlying TLS libraries each time 1227 they are used. 1229 o After calculating the values vh and vkc to send a req-VFY-C 1230 request, Clients SHOULD NOT initiate TLS renegotiation until the 1231 end of the corresponding response header is received. An 1232 exception is that clients can and SHOULD perform TLS re- 1233 negotiation as a response to the server's request for TLS 1234 renegotiation, before receipt of the beginning of the response 1235 header. 1237 Also, implementers MUST take care of session resumption attacks 1238 regarding tls-unique channel binding mechanisms and master secrets. 1239 As a mitigation, a TLS extension defined in [RFC7627] SHOULD be used 1240 when tls-unique host verification is to be used. 1242 8. Authentication Extensions 1244 Interactive clients (e.g., Web browsers) supporting this protocol are 1245 RECOMMENDED to support non-mandatory authentication and the 1246 Authentication-Control header defined in 1247 [I-D.ietf-httpauth-extension], except for the "auth-style" parameter. 1248 This specification also proposes (however, does not mandate) the 1249 default "auth-style" be "non-modal". Web applications SHOULD however 1250 consider the security impacts of the behaviors of clients that do not 1251 support these headers. 1253 Authentication-initializing messages with the 1254 Optional-WWW-Authenticate header are used only where the 401-INIT 1255 response is valid. It will not replace other 401-type messages such 1256 as 401-STALE and 401-KEX-S1. That is, the reason field of such a 1257 message &MUST be "initial" (or any extensive-tokens NOT defined in 1258 Section 4.1). 1260 9. String Preparation 1262 It is important for interoperability that user names and passwords 1263 used in this protocol are binary-comparable regardless of the user's 1264 input methods and/or environments. To ensure this, the following 1265 preparation SHOULD be performed: 1267 o User names received from users SHOULD be prepared using the 1268 "UsernameCasePreserved" profile defined in Section 3.3 of 1269 [RFC7613]. 1271 o Passwords received from users SHOULD be prepared using the 1272 "OpaqueString" profile defined in Section 4.2 of [RFC7613]. 1274 In both cases, it is the sender's duty to correctly prepare the 1275 character strings. If any non-normalized character string is 1276 received from the other peer of the communication, recipients MAY 1277 either use it as a bare UTF-8 string without any preparation, perform 1278 any appropriate preparations (which may cause authentication 1279 failure), or reject any ill-prepared inputs from the sender and 1280 respond as a communication error. 1282 Server applications SHOULD also prepare user names and passwords 1283 accordingly upon registration of user credentials. 1285 In addition, binary-based "interfaces" of implementations MAY require 1286 and assume that the string is already prepared accordingly; when a 1287 string is already stored as a binary Unicode string form, 1288 implementations MAY omit preparation and Unicode normalization 1289 (performing UTF-8 encoding only) before using it. When a string is 1290 already stored as an octet blob, implementations MAY send it as is. 1292 10. Decision Procedure for Clients 1294 10.1. General Principles and Requirements 1296 To securely implement the protocol, the client must be careful about 1297 accepting the authenticated responses from the server. This also 1298 holds true for the reception of a "normal response" (a response which 1299 does not contain Mutual authentication-related headers) from HTTP 1300 servers. 1302 As usual in the HTTP authentication, a single user-level request may 1303 result in exchange of two-or-more HTTP requests and responses in 1304 sequence. The following normative rules MUST be followed by the 1305 clients implementing this protocol: 1307 o Any kind of a "normal response" MUST only be accepted for the very 1308 first request in the sequence. Any "normal response" returned for 1309 the second or later requests in the sequence SHALL be considered 1310 invalid. 1312 o In the same principle, if any response is related to an 1313 authentication realm which is different from that of the client's 1314 request (for example, a 401-INIT message requesting authentication 1315 on another realm), it MUST only be accepted for the very first 1316 request in the sequence. Such a response returned for a second or 1317 later request in the sequence SHALL be considered invalid. 1319 o A req-KEX-C1 message MAY be sent either as a initial request or as 1320 a response to 401-INIT or 401-STALE. However, it SHOULD NOT be 1321 sent more than once in the sequence for a single authentication 1322 realm, to avoid infinite loops of messages. A 401-KEX-S1 response 1323 MUST be accepted only when the corresponding request is 1324 req-KEX-C1. 1326 o A req-VFY-C message MAY be sent if there is a valid session key 1327 shared between the client and the server, established by 1328 req-KEX-C1 and 401-KEX-S1. If any response with 401 status is 1329 returned for such a message, the corresponding session key SHOULD 1330 be discarded as unusable. 1331 Especially, upon the reception of a 401-STALE response, the client 1332 SHOULD try establishing a new session by sending req-KEX-C1, but 1333 only once within the request/response sequence. 1335 o A 200-VFY-S message MUST be accepted only as a response to 1336 req-VFY-C and nothing else. The VK_s values of such response 1337 messages MUST always be checked against the correct value, and if 1338 it is incorrect, the whole response SHOULD be considered invalid. 1340 The final status of the client request following the message exchange 1341 sequence shall be determined as follows: 1343 o AUTH-SUCCEED: A 200-VFY-S message with the correct VK_s value was 1344 returned in response to the req-VFY-C request in the sequence. 1346 o AUTH-REQUIRED: Two cases exists. 1348 * A 401-INIT message was returned from the server, and the client 1349 does not know how to authenticate to the given authentication 1350 realm. 1352 * A 401-INIT response was returned for req-VFY-C (or req-KEX-C1), 1353 which means the user-supplied authentication credentials were 1354 not accepted. 1356 o UNAUTHENTICATED: a normal response is returned for an initial 1357 request of any kind in the sequence. 1359 Any kind of response (including a normal response) other than those 1360 explicitly allowed in the above rules SHOULD be interpreted as a 1361 fatal communication error. In such cases, the clients MUST NOT 1362 process any data (the response body and other content-related 1363 headers) sent from the server. However, to handle exceptional error 1364 cases, clients MAY accept a message without an Authentication-Info 1365 header, if it has a Server-Error (5xx) status code. In such cases, 1366 they SHOULD be careful about processing the body of the content 1367 (ignoring it is still RECOMMENDED, as it may possibly be forged by 1368 intermediate attackers), and the client will be in the 1369 "UNAUTHENTICATED" status then. 1371 If a request is a sub-request for a resource included in another 1372 resource (e.g., embedded images, style sheets, frames etc.), clients 1373 MAY treat an AUTH-REQUESTED status as the same as an UNAUTHENTICATED 1374 status. In other words, the client MAY ignore server's request to 1375 start authentication with new credentials via sub-requests. 1377 10.2. State machine for the client (informative) 1379 The following state machine describes the possible request-response 1380 sequences derived from the above normative rules. If implementers 1381 are not quite sure on the security consequences of the above rules, 1382 it is strongly advised to follow the decision procedure below. In 1383 particular, clients SHOULD NOT accept "normal responses" unless 1384 explicitly allowed in the rules. The labels on the steps are for 1385 informational purposes only. Action entries within each step are 1386 checked in top-to-bottom order, and the first clause satisfied is to 1387 be followed. 1389 Step 1 (step_new_request): 1390 If the client software needs to access a new Web resource, check 1391 whether the resource is expected to be inside some authentication 1392 realm for which the user has already been authenticated by the 1393 Mutual authentication scheme. If yes, go to Step 2. Otherwise, 1394 go to Step 5. 1396 Step 2: 1397 Check whether there is an available sid for the expected 1398 authentication realm. If there is one, go to Step 3. Otherwise, 1399 go to Step 4. 1401 Step 3 (step_send_vfy_1): 1402 Send a req-VFY-C request. 1404 * If you receive a 401-INIT message with a different 1405 authentication realm than expected, go to Step 6. 1407 * If a 401-STALE message is received, go to Step 9. 1409 * If a 401-INIT message is received, go to Step 13. 1411 * If a 200-VFY-S message is received, go to Step 14. 1413 * If a normal response is received, go to Step 11. 1415 Step 4 (step_send_kex1_1): 1416 Send a req-KEX-C1 request. 1418 * If a 401-INIT message is received with a different 1419 authentication realm than expected, go to Step 6. 1421 * If a 401-KEX-S1 message is received, go to Step 10. 1423 * If a 401-INIT message is received with the same authentication 1424 realm, go to Step 13 (see Note 1). 1426 * If a normal response is received, go to Step 11. 1428 Step 5 (step_send_normal_1): 1429 Send a request without any Mutual authentication headers. 1431 * If a 401-INIT message is received, go to Step 6. 1433 * If a normal response is received, go to Step 11. 1435 Step 6 (step_rcvd_init): 1436 Check whether the user's password for the requested 1437 authentication realm is known. If yes, go to Step 7. Otherwise, 1438 go to Step 12. 1440 Step 7: 1441 Check whether there is an available sid for the expected 1442 authentication realm. If there is one, go to Step 8. Otherwise, 1443 go to Step 9. 1445 Step 8 (step_send_vfy): 1446 Send a req-VFY-C request. 1448 * If a 401-STALE message is received, go to Step 9. 1450 * If a 401-INIT message is received, go to Step 13. 1452 * If a 200-VFY-S message is received, go to Step 14. 1454 Step 9 (step_send_kex1): 1455 Send a req-KEX-C1 request. 1457 * If a 401-KEX-S1 message is received, go to Step 10. 1459 * If a 401-INIT message is received, go to Step 13 (See Note 1). 1461 Step 10 (step_rcvd_kex1): 1462 Send a req-VFY-C request. 1464 * If a 401-INIT message is received, go to Step 13. 1466 * If a 200-VFY-S message is received, go to Step 14. 1468 Step 11 (step_rcvd_normal): 1469 The requested resource is out of the authenticated area. The 1470 client will be in the "UNAUTHENTICATED" status. If the response 1471 contains a request for authentications other than Mutual, it MAY 1472 be handled normally. 1474 Step 12 (step_rcvd_init_unknown): 1475 The requested resource requires Mutual authentication, and the 1476 user is not yet authenticated. The client will be in the "AUTH- 1477 REQUESTED" status, and is RECOMMENDED to process the content sent 1478 from the server, and to ask the user for a user name and a 1479 password. When those are supplied from the user, proceed to Step 1480 9. 1482 Step 13 (step_rcvd_init_failed): 1483 For some reason the authentication failed: possibly the password 1484 or the username is invalid for the authenticated resource. 1485 Forget the user-provided credentials for the authentication realm 1486 and go to Step 12. 1488 Step 14 (step_rcvd_vfy): 1489 The received message is the 200-VFY-S message, which always 1490 contains a vks field. Check the validity of the received VK_s 1491 value. If it is equal to the expected value, it means that the 1492 mutual authentication has succeeded. The client will be in the 1493 "AUTH-SUCCEEDED" status. 1495 If the value is unexpected, it is a fatal communication error. 1497 If a user explicitly requests to log out (via the user 1498 interface), the client MUST forget the user's password, go to 1499 step 5, and reload the current resource without an authentication 1500 header. 1502 Note 1: These transitions MAY be accepted by clients, but are 1503 NOT RECOMMENDED for servers to initiate. 1505 Figure 5 shows an informative diagram of the client state. 1507 =========== -(11)------------ 1508 NEW REQUEST ( UNAUTHENTICATED ) 1509 =========== ----------------- 1510 | ^ normal 1511 v | response 1512 +(1)-------------------+ NO +(5)----------+ 1513 | The requested URI |--------------------------->| send normal | 1514 | known to be auth'ed? | | request | 1515 +----------------------+ +-------------+ 1516 YES | 401-INIT 401-INIT| 1517 | with a different realm | 1518 | -----------------------------------. | 1519 | / v v 1520 | | -(12)------------ NO +(6)--------+ 1521 | | ( AUTH-REQUESTED )<------| user/pass | 1522 | | ----------------- | known? | 1523 | | +-----------+ 1524 | | |YES 1525 v | v 1526 +(2)--------+ | +(7)--------+ 1527 | session | | | session | NO 1528 NO /| available?| | | available?|\ 1529 / +-----------+ | +-----------+ | 1530 / |YES | |YES | 1531 | | /| | | 1532 | v / | 401- 401- v | 1533 | +(3)--------+ | INIT --(13)---------- INIT +(8)--------+ | 1534 | | send |--+----->/ AUTH-REQUESTED \<-------| send | | 1535 | /| req-VFY-C | | \forget password / | req-VFY-C | | 1536 \/ +-----------+ / ---------------- /+-----------+ | 1537 /\ \ \/ ^ 401-INIT | |401- | 1538 | ------ \/\ 401-STALE | | | STALE / 1539 | \ /\ -----------------+--------------+---. | / 1540 | | / \ | | | | / 1541 | v / | 401- | 401- | v v v 1542 | +(4)--------+ | KEX-S1 +(10)-------+ KEX-S1 | +(9)--------+ 1543 | | send |-|--------->| send |<-------+-| send | 1544 | --| req-KEX-C1| | | req-VFY-C | | | req-KEX-C1| 1545 |/ +-----------+ | +-----------+ | +-----------+ 1546 | |200-VFY-S | 200-VFY-S| ^ 1547 |normal | |200-VFY-S / | 1548 |response | v / ================== 1549 v \ -(14)--------- / USER/PASS INPUTTED 1550 -(11)------------ ------->( AUTH-SUCCEED )<-- ================== 1551 ( UNAUTHENTICATED ) -------------- 1552 ----------------- 1554 Figure 5: State diagram for clients 1556 11. Decision Procedure for Servers 1558 Each server SHOULD have a table of session states. This table need 1559 not be persistent over the long term; it MAY be cleared upon server 1560 restart, reboot, or for other reasons. Each entry in the table 1561 SHOULD contain at least the following information: 1563 o The session identifier, which is the value of the sid parameter. 1565 o The algorithm used. 1567 o The authentication realm. 1569 o The state of the protocol: one of "key exchanging", 1570 "authenticated", "rejected", or "inactive". 1572 o The user name received from the client. 1574 o A boolean flag representing whether or not the session is fake. 1576 o When the state is "key exchanging", the values of K_c1 and S_s1. 1578 o When the state is "authenticated", the following information: 1580 * The value of the session secret, z 1582 * The largest nc received from the client (largest-nc) 1584 * For each possible nc values between (largest-nc - nc- 1585 window + 1) and max_nc, a boolean flag whether or not a request 1586 with the corresponding nc has been received. 1588 The table MAY contain other information. 1590 Servers SHOULD respond to the client requests according to the 1591 following procedure: (See Note 1 below for 401-INIT message with a 1592 plus sign) 1594 o When the server receives a normal request: 1596 * If the requested resource is not protected by the Mutual 1597 authentication, send a normal response. 1599 * If the resource is protected by the Mutual authentication, send 1600 a 401-INIT response. 1602 o When the server receives a req-KEX-C1 request: 1604 * If the requested resource is not protected by the Mutual 1605 authentication, send a normal response. 1607 * If the authentication realm specified in the req-KEX-C1 request 1608 is not the expected one, send a 401-INIT response. 1610 * If the server cannot validate the parameter kc1, send a 1611 401-INIT (+) response. 1613 * If the received user name is either invalid, unknown or 1614 unacceptable, create a new session, mark it a "fake" session, 1615 compute a random value as K_s1, and send a fake 401-KEX-S1 1616 response. (See Note 2.) 1618 * Otherwise, create a new session, compute K_s1 and send a 1619 401-KEX-S1 response. The created session is marked as not 1620 fake, and its largest-nc is initialized to zero. 1622 The created session has the "key exchanging" state. 1624 o When the server receives a req-VFY-C request: 1626 * If the requested resource is not protected by the Mutual 1627 authentication, send a normal response. 1629 * If the authentication realm specified in the req-VFY-C request 1630 is not the expected one, send a 401-INIT response. 1632 If none of above holds true, the server will look up the session 1633 corresponding to the received sid and the authentication realm. 1635 * If the session corresponding to the received sid could not be 1636 found, or it is in the "inactive" state, send a 401-STALE 1637 response. 1639 * If the session is in the "rejected" state, send either a 1640 401-INIT (+) or a 401-STALE message. 1642 * If the nc value in the request is larger than the nc-max 1643 parameter sent from the server, or if it is not larger then 1644 (largest-nc - nc-window) (when in "authenticated" status), the 1645 server MAY (but is not REQUIRED to; See Note 3) send a 1646 401-STALE message. The session SHOULD be changed to the 1647 "inactive" state if so. 1649 * If the session is in the "authenticated" state, and the request 1650 has an nc value that was previously received from the client, 1651 send a 401-STALE message. The session SHOULD be changed to the 1652 "inactive" state. 1654 * If the session is a "fake" session, or if the received vkc is 1655 incorrect, then send a 401-INIT (+) response. If the session 1656 is in the "key exchanging" state, it SHOULD be changed to the 1657 "rejected" state; otherwise, it MAY either be changed to the 1658 "rejected" state or kept in the previous state. 1660 * Otherwise, send a 200-VFY-S response. If the session was in 1661 the "key exchanging" state, the session SHOULD be changed to an 1662 "authenticated" state. The maximum nc and nc flags of the 1663 state SHOULD be updated appropriate. 1665 At any time, the server MAY change any state entries with both the 1666 "rejected" and "authenticated" states to the "inactive" status, and 1667 MAY discard any "inactive" states from the table. Entries with the 1668 "key exchanging" state SHOULD be kept unless there is an emergency 1669 situation such as a server reboot or a table capacity overflow. 1671 Note 1: In relation with and following the specification of the 1672 optional authentication defined in [I-D.ietf-httpauth-extension], the 1673 401-INIT messages marked with the pluses cannot be replaced with a 1674 successful responses with an Optional-WWW-Authenticate header. Every 1675 other 401-INIT can be a response with an Optional-WWW-Authenticate. 1677 Note 2: the server SHOULD NOT send a 401-INIT response in this case, 1678 because it will leak the information to the client that the specified 1679 user name will not be accepted. Instead, postpone it to the response 1680 for the next req-VFY-C request. 1682 Note 3: The next case implies that, when the request is not rejected 1683 under this clause, the server MUST be decidable whether the same nc 1684 value was previously received from the client. If the server does 1685 not remember a whole history of the nc values received from the 1686 client, the server MUST send a 401-STALE message in this clause. 1688 12. Authentication Algorithms 1690 Cryptographic authentication algorithms which are used with this 1691 protocol will be defined separately. The algorithm definition MUST 1692 at least provide definitions for the following functions: 1694 o The server-side authentication credential J, derived from client- 1695 side authentication credential pi. 1697 o Key exchange values K_c1, K_s1 (exchanged on wire) and S_c1, S_s1 1698 (kept secret in each peer). 1700 o Shared secret z, to be computed by both server and client. 1702 o A hash function H to be used with the protocol, along with its 1703 output size hSize. 1705 o The number of iterations for password hashing nIterPi, if it uses 1706 the default password hashing function defined below. 1708 Specifications for cryptographic algorithms used with this framework 1709 MUST specify whether these will use the default functions defined 1710 below for values pi, VK_c, and VK_s; or, these will define their own 1711 versions for these. 1713 All algorithm used with this protocol SHOULD provide secure mutual 1714 authentication between client and servers, and generate a 1715 cryptographically strong shared secret value z, equivalently strong 1716 to or stronger than the hash function H. If any passwords (or pass- 1717 phrases or any equivalents, i.e., weak secrets) are involved, these 1718 SHOULD NOT be guessable from any data transmitted in the protocol, 1719 even if an attacker (either an eavesdropper or an active server) 1720 knows the possible thoroughly-searchable candidate list of the 1721 passwords. Furthermore, if possible, the function J for deriving 1722 server-side authentication credential J(pi) is RECOMMENDED to be one- 1723 way so that pi should not be easily computed from J(pi). 1725 12.1. Support Functions and Notations 1727 In this section we define several support functions and notations to 1728 be shared by several algorithm definitions. 1730 The integers in the specification are in decimal, or in hexadecimal 1731 when prefixed with "0x". 1733 The function octet(i) generates an octet string containing a single 1734 octet of value i. The operator |, when applied to octet strings, 1735 denotes the concatenation of two operands. 1737 The function VI encodes natural numbers into octet strings in the 1738 following manner: numbers are represented as big-endian radix-128 1739 strings, where each digit is represented by an octet within the range 1740 0x80-0xff except the last digit, which is represented by a octet 1741 within the range 0x00-0x7f. The first octet MUST NOT be 0x80. For 1742 example, VI(i) = octet(i) for i < 128, and VI(i) = octet(0x80 + (i >> 1743 7)) | octet(i & 127) for 128 <= i < 16384. This encoding is the same 1744 as the one used for the sub-components of object identifiers in the 1745 ASN.1 encoding [ITU.X690.1994], and available as a "w" conversion in 1746 the "pack" function of several scripting languages. 1748 The function VS encodes a variable-length octet string into a 1749 uniquely-decoded, self-delimited octet string, as in the following 1750 manner: 1752 VS(s) = VI(length(s)) | s 1754 where length(s) is a number of octets (not characters) in s. 1756 Some examples: 1758 VI(0) = "\000" (in C string notation) 1760 VI(100) = "d" 1762 VI(10000) = "\316\020" 1764 VI(1000000) = "\275\204@" 1766 VS("") = "\000" 1768 VS("Tea") = "\003Tea" 1770 VS("Caf" [in UTF-8]) = "\005Caf\303\251" 1772 VS([10000 "a"s]) = "\316\020aaaaa..." (10002 octets) 1774 (Note: Unlike the colon-separated notion used in the Basic/Digest 1775 HTTP authentication scheme, the string generated by a concatenation 1776 of the VS-encoded strings will be unique, regardless of the 1777 characters included in the strings to be encoded.) 1779 The function OCTETS converts an integer into the corresponding radix- 1780 256 big-endian octet string having its natural length. See 1781 Section 3.2.3 for the definition of "natural length". 1783 The function INT converts an octet string into a natural number, 1784 where the input string is treated as being in radix-256 big-endian 1785 notation. The identity INT(OCTETS(n)) = n always holds for any 1786 natural number n. 1788 12.2. Default Functions for Algorithms 1790 The functions defined in this section are common default functions 1791 among authentication algorithms. 1793 The client-side password-based (credential) pi used by this 1794 authentication is a natural number derived in the following manner: 1796 pi = INT(PBKDF2(HMAC_H, password, VS(algorithm) | VS(auth-scope) | 1797 VS(realm) | VS(username), nIterPi, hSize / 8)), 1799 where 1801 o PBKDF2 is the password-based key derivation function defined in 1802 [RFC2898], 1804 o HMAC_H is the HMAC function, defined in [RFC2104], composed from 1805 the hash function H, and 1807 o hSize is the output size of hash H in bits. 1809 The values of algorithm, realm, and auth-scope are taken from the 1810 values contained in the 401-INIT message. If the password comes from 1811 user input, it SHOULD first be prepared according to the method 1812 presented in Section 9. Then, the password SHALL be encoded as a 1813 UTF-8 string. 1815 The values VK_c and VK_s are derived by the following equation. 1817 VK_c = INT(H(octet(4) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | 1818 VI(nc) | VS(vh))) 1820 VK_s = INT(H(octet(3) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | 1821 VI(nc) | VS(vh))) 1823 13. Application Channel Binding 1825 Applications and upper-layer communication protocols may need 1826 authentication binding to the HTTP-layer authenticated user. Such 1827 applications MAY use the following values as a standard shared 1828 secret. 1830 These values are parameterized with an optional octet string (t) 1831 which may be arbitrarily chosen by each application or protocol. If 1832 there is no appropriate value to be specified, use an empty string 1833 for t. 1835 For applications requiring binding to either an authenticated user or 1836 a shared-key session (to ensure that the requesting client is 1837 certainly authenticated), the following value b_1 MAY be used. 1839 b_1 = H(H(octet(6) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(0) 1840 | VS(vh)) | VS(t)). 1842 For applications requiring binding to a specific request (to ensure 1843 that the payload data is generated for the exact HTTP request), the 1844 following value b_2 MAY be used. 1846 b_2 = H(H(octet(7) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(nc) 1847 | VS(vh)) | VS(t)). 1849 Note: Channel bindings to lower-layer transports (TCP and TLS) are 1850 defined in Section 7. 1852 14. Application for Proxy Authentication 1854 The authentication scheme defined by the previous sections can be 1855 applied (with modifications) for proxy authentication. In such 1856 cases, the following alterations MUST be applied: 1858 o The 407 status is to be sent and recognized in places where the 1859 401 status is used, 1861 o Proxy-Authenticate header is to be used in places where WWW- 1862 Authenticate is used, 1864 o Proxy-Authorization header is to be used in places where 1865 Authorization is used, 1867 o Proxy-Authentication-Info header is to be used in places where 1868 Authentication-Info is used, 1870 o The auth-scope parameter is fixed to the host-name of the proxy, 1871 which means it covers all requests processed through the specific 1872 proxy, 1874 o The limitation for the paths contained in the path parameter of 1875 401-KEX-S1 messages is disregarded, 1877 o The omission of the path parameter of 401-KEX-S1 messages means 1878 that the authentication realm will potentially cover all requests 1879 processed by the proxy, 1881 o The scheme, host name, and the port of the proxy is used for host 1882 validation tokens, and 1884 o Authentication extensions in [I-D.ietf-httpauth-extension] are not 1885 applicable. 1887 15. Methods to Extend This Protocol 1889 If a private extension to this protocol is implemented, it MUST use 1890 the extension-tokens defined in Section 3 to avoid conflicts with 1891 this protocol and other extensions. (Standardized or being- 1892 standardized extensions MAY use either bare-tokens or extension- 1893 tokens.) 1895 Specifications defining authentication algorithms MAY use other 1896 representations for the parameters "kc1", "ks1", "vkc", and "vks", 1897 replace those parameter names, and/or add parameters to the messages 1898 containing those parameters in supplemental specifications, provided 1899 that syntactic and semantic requirements in Section 3, [RFC7230] and 1900 [RFC7235] are satisfied. Any parameters starting with "kc", "ks", 1901 "vkc" or "vks" and followed by decimal natural numbers (e.g. kc2, 1902 ks0, vkc1, vks3 etc.) are reserved for this purpose. If those 1903 specifications use names other than those mentioned above, it is 1904 RECOMMENDED to use extension-tokens to avoid any parameter name 1905 conflict with future extensions to this protocol. 1907 Extension-tokens MAY be freely used for any non-standard, private, 1908 and/or experimental uses for those parameters provided that the 1909 domain part in the token is used in the manner defined in Section 3. 1911 16. IANA Considerations 1913 When bare-tokens are used for the authentication-algorithm, pwd-hash, 1914 and validation parameters, these MUST be allocated by IANA. To 1915 acquire registered tokens, a specification for the use of such tokens 1916 MUST be reviewed by a designated expert, as outlined in [RFC5226]. 1918 16.1. Registry for Authentication Algorithms 1920 This document establishes a registry for HTTP Mutual authentication 1921 algorithms. The registry manages case-insensitive ASCII strings. 1922 The strings MUST follow the extensive-token syntax defined in 1923 Section 3. 1925 Registrations for an authentication algorithm are required to include 1926 a description of the authentication algorithms. Reviewers assigned 1927 by IESG are advised to examine minimum security requirements and 1928 consistency of the key exchange algorithm descriptions. 1930 New registrations are advised to provide the following information: 1932 o Token: a token used in HTTP headers for identifying the algorithm. 1934 o Description: A brief description of the algorithm. 1936 o Specification: A reference for a specification defining the 1937 algorithm. 1939 The initial content of this registry is empty. [[Editorial Note: A 1940 separate document [I-D.ietf-httpauth-mutual-algo] will effectively 1941 define the initial content of the registry.]] 1943 16.2. Registry for Validation Methods 1945 This document establishes a registry for HTTP Mutual authentication 1946 host validation methods. The registry manages case-insensitive ASCII 1947 strings. The strings MUST follow the extensive-token syntax defined 1948 in Section 3. 1950 Registrations for a validation method are required to include a 1951 description of the validation method. Reviewers assigned by IESG are 1952 advised to examine its use-case requirements and security consequence 1953 of its introduction. 1955 New registrations are advised to provide the following information: 1957 o Token: a token used in HTTP headers for identifying the method. 1959 o Description: A brief description of the method. 1961 o Specification: A reference for a specification defining the 1962 method. 1964 The initial content of this registry is as follows: 1966 +----------------------+----------------------------+---------------+ 1967 | Token | Description | Specification | 1968 +----------------------+----------------------------+---------------+ 1969 | host | Host name verification | Section 7 | 1970 | | only | | 1971 | tls-server-end-point | TLS certificate-based | Section 7 | 1972 | tls-unique | TLS unique key-based | Section 7 | 1973 +----------------------+----------------------------+---------------+ 1975 17. Security Considerations 1977 17.1. Security Properties 1978 o The protocol is secure against passive eavesdropping and replay 1979 attacks. However, the protocol relies on transport security 1980 including DNS integrity for data secrecy and integrity. HTTP/TLS 1981 SHOULD be used where transport security is not assured and/or data 1982 confidentiality is important. 1984 o When used with HTTP/TLS, if TLS server certificates are reliably 1985 verified, the protocol provides true protection against active 1986 man-in-the-middle attacks. 1988 o Even if the server certificate is not used or is unreliable, the 1989 protocol provides protection against active man-in-the-middle 1990 attacks for each HTTP request/response pair. However, in such 1991 cases, JavaScript or similar scripting facilities can be used to 1992 affect the Mutually-authenticated contents from other contents not 1993 protected by this authentication mechanism. This is the reason 1994 why this protocol requires that valid TLS server certificates MUST 1995 be presented (Section 7). 1997 17.2. Denial-of-service Attacks to Servers 1999 The protocol requires a server-side table of active sessions, which 2000 may become a critical point for server resource consumption. For 2001 proper operation, the protocol requires that at least one key 2002 verification request is processed for each session identifier. After 2003 that, servers MAY discard sessions internally at any time, without 2004 causing any operational problems to clients. Clients will silently 2005 reestablish a new session then. 2007 However, if a malicious client sends too many requests for key 2008 exchanges (req-KEX-C1 messages) only, resource starvation might 2009 occur. In such critical situations, servers MAY discard any kind of 2010 existing sessions regardless of their statuses. One way to mitigate 2011 such attacks is that servers MAY have a number and a time limit for 2012 unverified, pending key exchange requests (in the "key exchanging" 2013 state). 2015 This is a common weakness of authentication protocols with almost any 2016 kind of negotiations or states, including Digest authentication 2017 scheme and most Cookie-based authentication implementations. 2018 However, regarding the resource consumption, the situation for the 2019 mutual authentication scheme is a slightly better than for Digest, 2020 because HTTP requests without any kind of authentication requests 2021 will not generate any kind of sessions. Session identifiers are only 2022 generated after a client starts a key negotiation. It means that 2023 simple clients such as Web crawlers will not accidentally consume 2024 server-side resources for session managements. 2026 17.2.1. On-line Active Password Attacks 2028 Although the protocol provides very strong protection against off- 2029 line dictionary attacks from eavesdropped traffic, the protocol, by 2030 its nature, cannot prevent active password attacks in which the 2031 attackers sends so many authentication trial requests for every 2032 possible password. 2034 Possible countermeasures for preventing such attacks may be rate- 2035 limiting of password authentication trials, statistics-based 2036 intrusion detection measures, or similar protection schemes. If the 2037 server operators assume that the passwords of users are not strong 2038 enough, it may be desirable to introduce such ad-hoc countermeasures. 2040 17.3. Communicating the status of mutual authentication with users 2042 This protocol is designed for two goals. The first goal is just 2043 providing a secure alternative for existing Basic and Digest 2044 authentication. The second goal is to provide users a way to detect 2045 forged rogue servers imitating a user's registered account on a 2046 server, commonly known as (a part or kind of) Phishing attacks. 2048 For this protocol to effectively work as some countermeasure to such 2049 attacks, it is very important that end users of clients be notified 2050 of the result of the mutual authentication performed by this 2051 protocol, especially the three states "AUTH-SUCCEED", 2052 "UNAUTHENTICATED", and "AUTH-REQUIRED" defined in Section 10. The 2053 design of secure user interfaces of the HTTP interactive clients is 2054 out of the scope of this document, but if possible, having some kind 2055 of UI indication for the three states above will be desirable for the 2056 user's security benefit. 2058 Of course, in such cases, the user interfaces for asking passwords 2059 for this authentication shall be clearly identifiable against 2060 imitation by other insecure password input fields (such as forms). 2061 If the passwords are known to malicious attackers outside of the 2062 protocol, the protocol cannot work as an effective security measures. 2064 17.4. Implementation Considerations 2066 o To securely implement the protocol, the Authentication-Info 2067 headers in the 200-VFY-S messages MUST always be validated by the 2068 client. If the validation fails, the client MUST NOT process any 2069 content sent with the message, including other headers and the 2070 body part. Non-compliance to this requirement will allow phishing 2071 attacks. 2073 o For HTTP/TLS communications, when a web form is submitted from 2074 Mutually-authenticated pages with the "tls-server-end-point" 2075 validation method to a URI that is protected by the same realm (so 2076 indicated by the path parameter), if the server certificate has 2077 been changed since the pages were received, the peer is 2078 RECOMMENDED to be re-validated using a req-KEX-C1 message with an 2079 "Expect: 100-continue" header. The same applies when the page is 2080 received with the "tls-unique" validation method, and when the TLS 2081 session has expired. 2083 o For better protection against possible password database stealing, 2084 server-side storage of user passwords should contain the values 2085 encrypted by the one-way function J(pi), instead of the real 2086 passwords or those hashed by pi. 2088 o If the TLS 1.2 is used for underlying HTTP/TLS communications, 2089 follow best practices in [RFC7525]. 2091 17.5. Usage Considerations 2093 o The user names inputted by a user may be sent automatically to any 2094 servers sharing the same auth-scope. This means that when a host- 2095 type auth-scope is used for authentication on an HTTPS site, and 2096 when an HTTP server on the same host requests Mutual 2097 authentication within the same realm, the client will send the 2098 user name in clear text. If user names have to be kept secret 2099 against eavesdropping, the server must use the full-scheme-type 2100 auth-scope parameter and HTTPS. Contrarily, passwords are not 2101 exposed to eavesdroppers even on HTTP requests. 2103 o If the server provides several ways for storing server-side 2104 password secrets in the password database, it is desirable for 2105 better security to store the values encrypted by using the one-way 2106 function J(pi), instead of the real passwords or those hashed by 2107 pi. 2109 18. Notice on Intellectual Properties 2111 The National Institute of Advanced Industrial Science and Technology 2112 (AIST) and Yahoo! Japan, Inc. have jointly submitted a patent 2113 application to the Patent Office of Japan for the protocol proposed 2114 in this documentation. The patent is intended to be open to any 2115 implementer of this protocol and its variants under non-exclusive 2116 royalty-free terms. For the details of the patent application and 2117 its status, please contact the authors of this document. 2119 The elliptic-curve based authentication algorithms might involve 2120 several existing third-party patents. The authors of the document 2121 take no position regarding the validity or scope of such patents and 2122 other patents as well. 2124 19. References 2126 19.1. Normative References 2128 [I-D.ietf-httpauth-extension] 2129 Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 2130 T., and Y. Ioku, "HTTP Authentication Extensions for 2131 Interactive Clients", draft-ietf-httpauth-extension-08 2132 (work in progress), August 2016. 2134 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2135 Hashing for Message Authentication", RFC 2104, 2136 DOI 10.17487/RFC2104, February 1997, 2137 . 2139 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2140 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 2141 RFC2119, March 1997, 2142 . 2144 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 2145 Specification Version 2.0", RFC 2898, DOI 10.17487/ 2146 RFC2898, September 2000, 2147 . 2149 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2150 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 2151 November 2003, . 2153 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2154 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2155 . 2157 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2158 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 2159 RFC5234, January 2008, 2160 . 2162 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2163 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 2164 RFC5246, August 2008, 2165 . 2167 [RFC5987] Reschke, J., "Character Set and Language Encoding for 2168 Hypertext Transfer Protocol (HTTP) Header Field 2169 Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010, 2170 . 2172 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2173 Protocol (HTTP/1.1): Message Syntax and Routing", 2174 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2175 . 2177 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2178 Protocol (HTTP/1.1): Authentication", RFC 7235, 2179 DOI 10.17487/RFC7235, June 2014, 2180 . 2182 [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, 2183 Enforcement, and Comparison of Internationalized Strings 2184 Representing Usernames and Passwords", RFC 7613, 2185 DOI 10.17487/RFC7613, August 2015, 2186 . 2188 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- 2189 Authentication-Info Response Header Fields", RFC 7615, 2190 DOI 10.17487/RFC7615, September 2015, 2191 . 2193 19.2. Informative References 2195 [I-D.ietf-httpauth-mutual-algo] 2196 Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 2197 T., and Y. Ioku, "Mutual Authentication Protocol for HTTP: 2198 KAM3-based Cryptographic Algorithms", 2199 draft-ietf-httpauth-mutual-algo-06 (work in progress), 2200 August 2016. 2202 [ISO.10646-1.1993] 2203 International Organization for Standardization, 2204 "Information Technology - Universal Multiple-octet coded 2205 Character Set (UCS) - Part 1: Architecture and Basic 2206 Multilingual Plane", ISO Standard 10646-1, May 1993. 2208 [ITU.X690.1994] 2209 International Telecommunications Union, "Information 2210 Technology - ASN.1 encoding rules: Specification of Basic 2211 Encoding Rules (BER), Canonical Encoding Rules (CER) and 2212 Distinguished Encoding Rules (DER)", ITU-T Recommendation 2213 X.690, 1994. 2215 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 2216 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 2217 . 2219 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 2220 RFC2818, May 2000, 2221 . 2223 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2224 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2225 DOI 10.17487/RFC5226, May 2008, 2226 . 2228 [RFC5890] Klensin, J., "Internationalized Domain Names for 2229 Applications (IDNA): Definitions and Document Framework", 2230 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2231 . 2233 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 2234 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 2235 . 2237 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2238 DOI 10.17487/RFC6265, April 2011, 2239 . 2241 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 2242 DOI 10.17487/RFC6454, December 2011, 2243 . 2245 [RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin- 2246 Bound Authentication (HOBA)", RFC 7486, DOI 10.17487/ 2247 RFC7486, March 2015, 2248 . 2250 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2251 "Recommendations for Secure Use of Transport Layer 2252 Security (TLS) and Datagram Transport Layer Security 2253 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, 2254 May 2015, . 2256 [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 2257 Preparation, Enforcement, and Comparison of 2258 Internationalized Strings in Application Protocols", 2259 RFC 7564, DOI 10.17487/RFC7564, May 2015, 2260 . 2262 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 2263 Digest Access Authentication", RFC 7616, DOI 10.17487/ 2264 RFC7616, September 2015, 2265 . 2267 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 2268 Langley, A., and M. Ray, "Transport Layer Security (TLS) 2269 Session Hash and Extended Master Secret Extension", 2270 RFC 7627, DOI 10.17487/RFC7627, September 2015, 2271 . 2273 Appendix A. (Informative) Draft Change Log 2275 [To be removed on final publication] 2277 A.1. Changes in Httpauth WG Revision 09 2279 o Reflected AD review comments. 2281 o Authors' addresses updated. 2283 A.2. Changes in Httpauth WG Revision 08 2285 o Minor text update, in sync with httpauth-extension. 2287 o The version token is raised to "1". 2289 A.3. Changes in Httpauth WG Revision 07 2291 o Several comments from reviewers are reflected to the text. 2293 o The password-hash has been completely dropped. 2295 o The version token is raised to "1". 2297 A.4. Changes in Httpauth WG Revision 06 2299 o The auth-domain parameter has been renamed to auth-scope, 2300 following suggestions on the mailing list. 2302 o The digest-md5 password-hash has been dropped, as Digest with MD5 2303 hash is now obsoleted. 2305 A.5. Changes in Httpauth WG Revision 05 2307 o Minimum nonce number window has increased to 128. (HTTP 2.0 2308 recommends at least 100 concurrent sessions to exist) 2310 o Reference to TLS session hash extension added for tls-unique 2311 security issues. 2313 o Comments in the previous F2F meeting has been reflected to the 2314 text. 2316 A.6. Changes in Httpauth WG Revision 04 2318 o Merged httpauthprep proposal into general PRECIS Username/Password 2319 profile. 2321 o Adopting RFC 5987 extended syntax for non-ASCII parameter values. 2323 o Refer draft-ietf-httpbis-auth-info for Authentication-Info header. 2324 This results in a different syntax for that header. 2326 A.7. Changes in Httpauth WG Revision 03 2328 o Incompatible change: Single-port type authentication realm label 2329 has been changed to harmonize with Web Origin. (That is, the 2330 default ports (80 and 443) are to be omitted.) 2332 A.8. Changes in Httpauth WG Revision 02 2334 o Major change: introduction of password-strengthening function 2335 PBKDF2. 2337 o Changed Section 10 to adopt "list of requirements" style. Strict 2338 definition of state machine is now a derived, informational 2339 definition. 2341 A.9. Changes in Httpauth WG Revision 01 2343 o Changed "tls-key" verification to "tls-unique" verification, and 2344 "tls-cert" to "tls-server-end-point", adopting RFC 5929. 2346 o Adopted PRECIS framework [RFC7564]. 2348 o Reverted reservation of "rekey-sid" and "rekey-method" parameters. 2350 o Degraded secure UI requirement to application note level, non- 2351 normative. 2353 o Adjusted levels of several requirements. 2355 o Added warning text for handling of exceptional 5XX responses. 2357 o Dropped several references for optional authentications, except 2358 one "Note". 2360 o Several textual fixes, improvements and revisions. 2362 A.10. Changes in Httpauth Revision 00 2364 o Changed the version token. 2366 o Renamed "verification tokens" to "Host verification tokens" and 2367 variables "v" to "vh" for clarification. (Back-ported from 2368 draft-oiwa-httpauth-multihop-template-00) 2370 A.11. Changes in HttpBis Revision 00 2372 None. 2374 A.12. Changes in Revision 12 2376 o Added a reason "authz-failed". 2378 A.13. Changes in Revision 11 2380 o Message syntax definition reverted to pre-07 style as httpbis-p1 2381 and p7 now defines a precise rule for parameter value parsing. 2383 o Replaced "stale" parameter with more informative/extensive 2384 "reason" parameter in 401-INIT and 401-STALE. 2386 o Reserved "rekey-sid" and "rekey-method" parameters for future 2387 extensions. 2389 o Added descriptions for replacing/non-replacing existing 2390 technologies. 2392 A.14. Changes in Revision 10 2394 o The authentication extension parts (non-mandatory authentication 2395 and authentication controls) are separated to yet another draft. 2397 o The default auth-domain parameter is changed to the full scheme- 2398 host-port syntax, which is consistent with usual HTTP 2399 authentication framework behavior. 2401 o Provision for application channel binding is added. 2403 o Provision for proxy access authentication is added. 2405 o Bug fix: syntax specification of sid parameter was wrong: it was 2406 inconsistent with the type specified in the main text (the bug 2407 introduced in -07 draft). 2409 o Terminologies for headers are changed to be in harmony with 2410 httpbis drafts (e.g. field to parameter). 2412 o Syntax definitions are changed to use HTTP-extended ABNF syntax, 2413 and only the header values are shown for header syntax, in harmony 2414 with httpbis drafts. 2416 o Names of parameters and corresponding mathematical values are now 2417 renamed to more informative ones. The following list shows 2418 correspondence between the new and the old names. 2420 +------------+----------+-------------------------------------------+ 2421 | new name | old name | description | 2422 +------------+----------+-------------------------------------------+ 2423 | S_c1, S_s1 | s_a, s_b | client/server-side secret randoms | 2424 | K_c1, K_s1 | w_a, w_b | client/server-side exchanged key | 2425 | | | components | 2426 | kc1, ks1 | wa, wb | parameter names for those | 2427 | VK_c, VK_s | o_a, o_b | client/server-side key verifiers | 2428 | vkc, vks | oa, ob | parameter names for those | 2429 | z | z | session secrets | 2430 +------------+----------+-------------------------------------------+ 2432 A.15. Changes in Revision 09 2434 o The (default) cryptographic algorithms are separated to another 2435 draft. 2437 o Names of the messages are changed to more informative ones than 2438 before. The following is the correspondence table of those names: 2440 +-------------------+-----------------+-----------------------------+ 2441 | new name | old name | description | 2442 +-------------------+-----------------+-----------------------------+ 2443 | 401-INIT | 401-B0 | initial response | 2444 | 401-STALE | 401-B0-stale | session key expired | 2445 | req-KEX-C1 | req-A1 | client->server key exchange | 2446 | 401-KEX-S1 | 401-B1 | server->client key exchange | 2447 | req-VFY-C | req-A3 | client->server auth. | 2448 | | | verification | 2449 | 200-VFY-S | 200-B4 | server->client auth. | 2450 | | | verification | 2451 | 200-Optional-INIT | 200-Optional-B0 | initial with non-mandatory | 2452 | | | authentication | 2453 +-------------------+-----------------+-----------------------------+ 2455 A.16. Changes in Revision 08 2457 o The English text has been revised. 2459 A.17. Changes in Revision 07 2461 o Adapt to httpbis HTTP/1.1 drafts: 2463 * Changed definition of extensive-token. 2465 * LWSP continuation-line (%0D.0A.20) deprecated. 2467 o To simplify the whole spec, the type of nonce-counter related 2468 parameters are change from hex-integer to integer. 2470 o Algorithm tokens are renamed to include names of hash algorithms. 2472 o Clarified the session management, added details of server-side 2473 protocol decisions. 2475 o The whole draft was reorganized; introduction and overview has 2476 been rewritten. 2478 A.18. Changes in Revision 06 2480 o Integrated Optional Mutual Authentication to the main part. 2482 o Clarified the decision procedure for message recognitions. 2484 o Clarified that a new authentication request for any sub-requests 2485 in interactive clients may be silently discarded. 2487 o Typos and confusing phrases are fixed. 2489 o Several "future considerations" are added. 2491 A.19. Changes in Revision 05 2493 o A new parameter called "version" is added for supporting future 2494 incompatible changes with a single implementation. In the (first) 2495 final specification its value will be changed to 1. 2497 o A new header "Authentication-Control" is added for precise control 2498 of application-level authentication behavior. 2500 A.20. Changes in Revision 04 2502 o Changed text of patent licenses: the phrase "once the protocol is 2503 accepted as an Internet standard" is removed so that the sentence 2504 also covers the draft versions of this protocol. 2506 o The "tls-key" verification is now OPTIONAL. 2508 o Several description fixes and clarifications. 2510 A.21. Changes in Revision 03 2512 o Wildcard domain specifications (e.g. "*.example.com") are allowed 2513 for auth-domain parameters (Section 4.1). 2515 o Specification of the tls-cert verification is updated 2516 (incompatible change). 2518 o State transitions fixed. 2520 o Requirements for servers concerning w_a values are clarified. 2522 o RFC references are updated. 2524 A.22. Changes in Revision 02 2526 o Auth-realm is extended to allow full-scheme type. 2528 o A decision diagram for clients and decision procedures for servers 2529 are added. 2531 o 401-B1 and req-A3 messages are changed to contain authentication 2532 realm information. 2534 o Bugs on equations for o_A and o_B are fixed. 2536 o Detailed equations for the entire algorithm are included. 2538 o Elliptic-curve algorithms are updated. 2540 o Several clarifications and other minor updates. 2542 A.23. Changes in Revision 01 2544 o Several texts are rewritten for clarification. 2546 o Added several security consideration clauses. 2548 Authors' Addresses 2550 Yutaka Oiwa 2551 National Institute of Advanced Industrial Science and Technology 2552 Information Technology Research Institute 2553 Tsukuba Central 1 2554 1-1-1 Umezono 2555 Tsukuba-shi, Ibaraki 2556 JP 2558 Email: y.oiwa@aist.go.jp 2560 Hajime Watanabe 2561 National Institute of Advanced Industrial Science and Technology 2562 Information Technology Research Institute 2563 Tsukuba Central 1 2564 1-1-1 Umezono 2565 Tsukuba-shi, Ibaraki 2566 JP 2568 Email: h-watanabe@aist.go.jp 2570 Hiromitsu Takagi 2571 National Institute of Advanced Industrial Science and Technology 2572 Information Technology Research Institute 2573 Tsukuba Central 1 2574 1-1-1 Umezono 2575 Tsukuba-shi, Ibaraki 2576 JP 2578 Email: takagi.hiromitsu@aist.go.jp 2580 Kaoru Maeda 2581 Lepidum Co. Ltd. 2582 Village Sasazuka 3, Suite #602 2583 1-30-3 Sasazuka 2584 Shibuya-ku, Tokyo 2585 JP 2587 Email: maeda@lepidum.co.jp 2588 Tatsuya Hayashi 2589 Lepidum Co. Ltd. 2590 Village Sasazuka 3, Suite #602 2591 1-30-3 Sasazuka 2592 Shibuya-ku, Tokyo 2593 JP 2595 Email: hayashi@lepidum.co.jp 2597 Yuichi Ioku 2598 Individual 2600 Email: mutual-work@ioku.org