idnits 2.17.00 (12 Aug 2021) /tmp/idnits25791/draft-ietf-httpauth-mutual-11.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 (November 14, 2016) is 2009 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-httpauth-extension has been published as RFC 8053 ** 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 7613 (Obsoleted by RFC 8265) == Outdated reference: draft-ietf-httpauth-mutual-algo has been published as RFC 8121 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7564 (Obsoleted by RFC 8264) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: May 18, 2017 ITRI, AIST 6 K. Maeda 7 T. Hayashi 8 Lepidum 9 Y. Ioku 10 Individual 11 November 14, 2016 13 Mutual Authentication Protocol for HTTP 14 draft-ietf-httpauth-mutual-11 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 May 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 . . . . . . . . . . . . . . . . . . . . . . . 6 62 1.2. Document Structure and Related Documents . . . . . . . . . 6 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 44 101 17.1. Security Properties . . . . . . . . . . . . . . . . . . . 44 102 17.2. Secrecy of Credentials . . . . . . . . . . . . . . . . . . 44 103 17.3. Denial-of-service Attacks to Servers . . . . . . . . . . . 45 104 17.3.1. On-line Active Password Attacks . . . . . . . . . . . 45 105 17.4. Communicating the status of mutual authentication with 106 users . . . . . . . . . . . . . . . . . . . . . . . . . . 45 107 17.5. Implementation Considerations . . . . . . . . . . . . . . 46 108 17.6. Usage Considerations . . . . . . . . . . . . . . . . . . . 47 109 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 110 18.1. Normative References . . . . . . . . . . . . . . . . . . . 47 111 18.2. Informative References . . . . . . . . . . . . . . . . . . 48 112 Appendix A. (Informative) Draft Change Log . . . . . . . . . . . 50 113 A.1. Changes in Httpauth WG Revision 11 . . . . . . . . . . . . 50 114 A.2. Changes in Httpauth WG Revision 10 . . . . . . . . . . . . 50 115 A.3. Changes in Httpauth WG Revision 09 . . . . . . . . . . . . 50 116 A.4. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 50 117 A.5. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 51 118 A.6. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 51 119 A.7. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 51 120 A.8. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 51 121 A.9. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 51 122 A.10. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 51 123 A.11. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 52 124 A.12. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 52 125 A.13. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 52 126 A.14. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 52 127 A.15. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 52 128 A.16. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 53 129 A.17. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 54 130 A.18. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 54 131 A.19. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 54 132 A.20. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 55 133 A.21. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 55 134 A.22. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 55 135 A.23. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 55 136 A.24. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 56 137 A.25. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 56 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 140 1. Introduction 142 This document specifies a mutual authentication scheme for Hypertext 143 Transfer Protocol (HTTP). The scheme, called "Mutual Authentication 144 Protocol" in this document, provides true mutual authentication 145 between an HTTP client and an HTTP server, using just a simple 146 password as a credential. 148 Password-stealing attacks are one of most critical threats for Web 149 systems. For a long time, plain-text password authentications (Basic 150 and Web form-based) are widely used (and are in use now). When these 151 are used with plain HTTP protocols, it is trivially easy for 152 attackers to sniff the password credentials on the wire. 154 Digest authentication scheme [RFC7616] uses a SHA-2 (formerly SHA-1 155 and MD5) hash algorithms to hide the raw user password from the 156 sniffing. However, if the number of possible candidates of users' 157 password is not enough, recent powerful computers can compute 158 possible hash values for billions of password candidates, and compare 159 these with the sniffed values to find out the correct password. This 160 kind of attack is called "offline password dictionary attacks"; 161 recently, the size of possible search space by computers is quite 162 competing with possibility of user's memorable passwords, threatening 163 the effectiveness of such hash-based password protections. 165 TLS [RFC5246] provides a strong cryptographic protection against the 166 network-based sniffing of passwords and other communication contents. 167 If TLS is correctly used by both server operators and client users, 168 passwords and other credentials will not be available for any outside 169 attackers. However, there is a pit-hole in the TLS deployment on the 170 Web systems; if the users are forged into a "wrong website" by some 171 kind of social attacks and tridked to perform authentication on that 172 site, the credentials will be sent to the attacker's server and 173 trivially leaked. Such attacks are called "Phishing", and becoming a 174 real threats in these days. In the curent Web system deployment, TLS 175 certificates will be issued to almost any users of Internet 176 (including malicious attackers). Although those certificate includes 177 several levels of the "validation results" (such as corporate names) 178 of the issued entities, task of "checking" those validation results 179 are left to the users of Web browsers, still leaving the possibility 180 of such social attacks. 182 Another direction to avoid such threats is to avoid password-based 183 authentication and use some kind of pre-deployed strong secret keys 184 (either on client side or on server-side) for authentications. 185 Several federated authentication framework as well as HOBA [RFC7486] 186 are proposed and deployed on the real Web systems to satisfy those 187 needs. However, a kind of authentication based on "human-memorable 188 secret" (i.e. passwords) is still required on several situations 189 within those systems, such is initialization, key deployment to new 190 clients, or recovery of secret accounts with lost cryptographic keys. 192 The Mutual authentication protocol proposed in this document is a 193 strong cryptographic solution for password authentications. It 194 mainly provides the two key features: 196 o No password information, at all, is exchanged in the 197 communications. When the server and the user fails to 198 authenticate with each other, the protocol will not reveal the 199 tiniest bit of information about the user's password. This 200 prevents any kind of off-line password dictionary attacks, even 201 with the existence of Phishing attacks. 203 o To successfully authenticate, the server must own the valid 204 registered credentials (authentication secret), as well as client 205 users. (Non-intuitively, this is not true for Basic and Digest 206 authentication. For example, servers for Basic authentications 207 can answer "YES" to any clients, without actually checking 208 authentication at all.) This means that phishing attackers cannot 209 forge users that they are the "authentic" servers. Client users 210 can assert whether the communicating peer is "the server" who have 211 registered their account beforehand. In other words, it provides 212 "true" mutual authentication between servers and clients. 214 Given these, the proposed protocol can serve as a strong alternative 215 to the Basic, Digest, and web-form-based authentications, and also as 216 a strong companion to the non-password-based authentication 217 frameworks. 219 The proposed protocol will serve in the same way as existing Basic/ 220 Digest authentication: it meets the requirement for new 221 authentication scheme for HTTP as described in Section 5.1.2 of 222 [RFC7235]. Additionally, to communiate authentication results more 223 reliably between the server and the client user, it suggests for Web 224 browsers to have some "secure" way of displaying the authentication 225 results. Having such an user interface in future browser will 226 greatly reduce the risk of impersonation by kinds of social attacks, 227 similarly in the manner of the "green padlock" for extended 228 verification TLS certificates. 230 Technically, the authentication scheme proposed in this document is a 231 general framework for using password-based authenticated key exchange 232 (PAKE) and similar stronger cryptographic primitives with HTTP. The 233 two key features shown above are corresponding to the nature of PAKE. 235 1.1. Terminology 237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 239 "OPTIONAL" in this document are to be interpreted as described in 240 [RFC2119]. 242 This document distinguishes the terms "client" and "user" in the 243 following way: A "client" is an entity understanding and talking HTTP 244 and the specified authentication protocol, usually computer software; 245 a "user" is a (usually natural) person who wants to access data 246 resources using a "client". 248 The term "natural numbers" refers to the non-negative integers 249 (including zero) throughout this document. 251 This document treats both the input (domain) and the output 252 (codomain) of hash functions to be octet strings. When a natural 253 number output for a hash function is required, it will be written as 254 INT(H(s)). 256 1.2. Document Structure and Related Documents 258 The entire document is organized as follows: 260 o Section 2 presents an overview of the protocol design. 262 o Sections 3 to 11 define a general framework of the Mutual 263 authentication protocol. This framework is independent of 264 specific cryptographic primitives. 266 o Section 12 describes properties needed for cryptographic 267 algorithms used with this protocol framework, and defines a few 268 functions which will be shared among such cryptographic 269 algorithms. 271 o The sections after that contain general normative and informative 272 information about the protocol. 274 In addition, there are two companion documents which are referred 275 from/related to this specification: 277 o [I-D.ietf-httpauth-mutual-algo]: defines cryptographic primitives 278 which can be used with this protocol framework. 280 o [I-D.ietf-httpauth-extension]: defines small but useful extensions 281 to the current HTTP authentication framework so that it can 282 support application-level semantics of existing Web systems. 284 2. Protocol Overview 286 The protocol, as a whole, is designed as a natural extension to the 287 HTTP protocol [RFC7230] using a framework defined in [RFC7235]. 288 Internally, the server and the client will first perform a 289 cryptographic key exchange, using the secret password as a "tweak" to 290 the exchange. The key exchange will only succeed when the secrets 291 used by the both peers are correctly related (i.e., generated from 292 the same password). Then, both peers will verify the authentication 293 results by confirming the sharing of the exchanged key. This section 294 provides a brief outline of the protocol and the exchanged messages. 296 2.1. Messages Overview 298 The authentication protocol uses seven kinds of messages to perform 299 mutual authentication. These messages have specific names within 300 this specification. 302 o Authentication request messages: used by the servers to request 303 clients to start mutual authentication. 305 * 401-INIT message: a general message to start the authentication 306 protocol. It is also used as a message indicating an 307 authentication failure. 309 * 401-STALE message: a message indicating that client has to 310 start a new key exchange. 312 o Authenticated key exchange messages: used by both peers to perform 313 authentication and the sharing of a cryptographic secret. 315 * req-KEX-C1 message: a message sent from the client. 317 * 401-KEX-S1 message: an intermediate response to a req-KEX-C1 318 message from the server. 320 o Authentication verification messages: used by both peers to verify 321 the authentication results. 323 * req-VFY-C message: a message used by the client, requesting the 324 server authenticate and authorize the client. 326 * 200-VFY-S message: a response used by the server to indicate 327 the successful client-authentication. It also contains 328 information necessary for the client to check the authenticity 329 of the server. 331 In addition to the above, either a request or a response without any 332 HTTP headers related to this specification will be hereafter called a 333 "normal request" or a "normal response", respectively. 335 2.2. Typical Flows of the Protocol 337 In typical cases, the client access to a resource protected by the 338 Mutual authentication scheme will use the following protocol 339 sequence. 341 Client Server 342 | | 343 | ---- (1) normal request ---------> | 344 GET / HTTP/1.1 | 345 | | 346 | <---------------- (2) 401-INIT --- | 347 | 401 Authentication Required 348 | WWW-Authenticate: Mutual realm="a realm" 349 | | 350 [user, | | 351 pass]-->| | 352 | ---- (3) req-KEX-C1 -------------> | 353 GET / HTTP/1.1 | 354 Authorization: Mutual user="john", |--> [user DB] 355 kc1="...", ... |<-- [user info] 356 | | 357 | <-------------- (4) 401-KEX-S1 --- | 358 | 401 Authentication Required 359 | WWW-Authenticate: Mutual sid=..., ks1="...", ... 360 | | 361 [compute] (5) compute session secret [compute] 362 | | 363 | | 364 | ---- (6) req-VFY-C --------------> | 365 GET / HTTP/1.1 |--> [verify (6)] 366 Authorization: Mutual sid=..., |<-- OK 367 vkc="...", ... | 368 | | 369 | <--------------- (7) 200-VFY-S --- | 370 [verify | 200 OK | 371 (7)]<--| Authentication-Info: Mutual vks="..." 372 | | 373 v v 375 Figure 1: Typical communication flow for first access to resource 377 o As usual in general HTTP protocol designs, a client will at first 378 request a resource without any authentication attempt (1). If the 379 requested resource is protected by the Mutual authentication, the 380 server will respond with a message requesting authentication 381 (401-INIT) (2). 383 o The client processes the body of the message and waits for the 384 user to input the user name and a password. If the user name and 385 the password are available, the client will send a message with 386 the authenticated key exchange (req-KEX-C1) to start the 387 authentication (3). 389 o If the server has received a req-KEX-C1 message, the server looks 390 up the user's authentication information within its user database. 391 Then the server creates a new session identifier (sid) that will 392 be used to identify sets of the messages that follow it and 393 responds back with a message containing a server-side 394 authenticated key exchange value (401-KEX-S1) (4). 396 o At this point (5), both peers calculate a shared "session secret" 397 using the exchanged values in the key exchange messages. Only 398 when both the server and the client have used secret credentials 399 generated from the same password will the session secret values 400 match. This session secret will be used for access authentication 401 of every individual request/response pair after this point. 403 o The client will send a request with a client-side authentication 404 verification value (req-VFY-C) (6), calculated from the client- 405 generated session secret. The server will check the validity of 406 the verification value using its own version of the session 407 secret. 409 o If the authentication verification value from the client was 410 correct, it means that the client definitely owns the credential 411 based on the expected password (i.e., the client authentication 412 succeeded). The server will respond with a successful message 413 (200-VFY-S) (7). Contrary to the usual one-way authentication 414 (e.g., HTTP Basic authentication or POP APOP authentication 415 [RFC1939]), this message also contains a server-side 416 authentication verification value. 418 When the client's verification value is incorrect (e.g., because 419 the user-supplied password was incorrect), the server will respond 420 with the 401-INIT message (the same one as used in (2)) instead. 422 o The client MUST first check the validity of the server-side 423 authentication verification value contained in the message (7). 424 If the value was equal to the expected one, server authentication 425 succeeded. 427 If it is not the value expected, or if the message does not 428 contain the authentication verification value, it means that the 429 mutual authentication has been broken for some unexpected reason. 430 The client MUST NOT process any body or header values contained in 431 the HTTP response in this case. (Note: This case should not 432 happen between a correctly implemented server and client without 433 any active attacks. The possible cause of such a case might be 434 either a man-in-the-middle attack or an incorrect implementation.) 436 2.3. Alternative Flows 438 As shown above, the typical flow for a first authentication request 439 requires three request-response pairs. To reduce the protocol 440 overhead, the protocol enables several short-cut flows which require 441 fewer messages. 443 o (case A) If the client knows that the resource is likely to 444 require authentication, the client MAY omit the first 445 unauthenticated request (1) and immediately send a key exchange 446 (req-KEX-C1 message). This will reduce one round-trip of 447 messages. 449 o (case B) If both the client and the server previously shared a 450 session secret associated with a valid session identifier (sid), 451 the client MAY directly send a req-VFY-C message using the 452 existing session identifier and corresponding session secret. 453 This will further reduce one round-trip of messages. 455 The server MAY have thrown out the corresponding session from the 456 session table. If so, the server will respond with a 401-STALE 457 message, indicating a new key exchange is required. The client 458 SHOULD retry constructing a req-KEX-C1 message in this case. 460 Figure 2 depicts the shortcut flows described above. Under the 461 appropriate settings and implementations, most of the requests to 462 resources are expected to meet both criteria, and thus only one 463 round-trip of request/response will be required. 465 (A) omit first request 466 (2 round trips) 468 Client Server 469 | | 470 | --- req-KEX-C1 ----> | 471 | | 472 | <---- 401-KEX-S1 --- | 473 | | 474 | ---- req-VFY-C ----> | 475 | | 476 | <----- 200-VFY-S --- | 477 | | 479 (B) reusing session secret (re-authentication) 481 (B-1) key available (B-2) key expired 482 (1 round trip) (3 round trips) 484 Client Server Client Server 485 | | | | 486 | ---- req-VFY-C ----> | | --- req-VFY-C -------> | 487 | | | | 488 | <----- 200-VFY-S --- | | <------- 401-STALE --- | 489 | | | | 490 | --- req-KEX-C1 ------> | 491 | | 492 | <------ 401-KEX-S1 --- | 493 | | 494 | --- req-VFY-C -------> | 495 | | 496 | <------- 200-VFY-S --- | 497 | | 499 Figure 2: Several alternative protocol flows 501 For more details, see Sections 10 and 11. 503 3. Message Syntax 505 Throughout this specification, the syntax is denoted in the extended 506 augmented BNF syntax defined in [RFC7230], and [RFC5234]. The 507 following elements are quoted from [RFC5234], [RFC7230] and 508 [RFC7235]: DIGIT, ALPHA, SP, auth-scheme, quoted-string, auth-param, 509 header-field, token, challenge, and credential. 511 The Mutual authentication protocol uses three headers: 512 WWW-Authenticate (usually in responses with status code 401), 513 Authorization (in requests), and Authentication-Info (in responses 514 other than 401 status). These headers follow a common framework 515 described in [RFC7235] and [RFC7615]. The detailed meanings for 516 these headers are contained in Section 4. 518 The framework in [RFC7235] defines the syntax for the headers 519 WWW-Authenticate and Authorization as the syntax elements "challenge" 520 and "credentials", respectively. The "auth-scheme" contained in 521 those headers MUST be "Mutual" throughout this protocol 522 specification. The syntax for "challenge" and "credentials" to be 523 used with the "Mutual" auth-scheme SHALL be name-value pairs (#auth- 524 param), not the "b64token" defined in [RFC7235]. 526 The Authentication-Info: header used in this protocol SHALL follow 527 the syntax defined in [RFC7615]. 529 In HTTP, the WWW-Authenticate header may contain two or more 530 challenges. Client implementations SHOULD be aware of and be capable 531 of handling those cases correctly. 533 3.1. Non-ASCII extended header parameters 535 All of parameters contained in the above three headers, except the 536 "realm" field, MAY be extended to ISO 10646-1 values using the 537 framework described in [RFC5987]. All servers and clients MUST be 538 capable of receiving and sending values encoded in [RFC5987] syntax. 540 If a value to be sent contains only ASCII characters, the field MUST 541 be sent using plain RFC 7235 syntax. The syntax as extended by RFC 542 5987 MUST NOT be used in this case. 544 If a value (except the "realm" header) contains one or more non-ASCII 545 characters, the parameter SHOULD be sent using the syntax defined in 546 Section 3.2 of [RFC5987] as "ext-parameter". Such a parameter MUST 547 have a charset value of "UTF-8", and the language value MUST always 548 be omitted (have an empty value). The same parameter MUST NOT be 549 sent more than once, regardless of the used syntax. 551 For example, a parameter "user" with value "Renee of France" SHOULD 552 be sent as < user="Renee of France" >. If the value is 553 "Rene of France", it SHOULD be sent as < user*=UTF- 554 8''Ren%C3%89e%20of%20France > instead. 556 [RFC7235] requires the realm parameter to be in its plain form (not 557 as an extended "realm*" parameter), so RFC 5987 syntax MUST NOT be 558 used for this parameter. 560 3.2. Values 562 The parameter values contained in challenge/credentials MUST be 563 parsed strictly conforming to the HTTP semantics (especially un- 564 quoting of the string parameter values). In this protocol, those 565 values are further categorized into the following value types: tokens 566 (bare-token and extensive-token), string, integer, hex-fixed-number, 567 and base64-fixed-number. 569 For clarity, implementations are RECOMMENDED to use the canonical 570 representations specified in the following subsections for sending 571 values. However, recipients MUST accept both quoted and unquoted 572 representations interchangeably as specified in HTTP. 574 3.2.1. Tokens 576 For sustaining both security and extensibility at the same time, this 577 protocol defines a stricter sub-syntax for the "token" to be used. 578 Extensive-token values SHOULD use the following syntax (after HTTP 579 value parsing): 581 bare-token = bare-token-lead-char *bare-token-char 582 bare-token-lead-char = %x30-39 / %x41-5A / %x61-7A 583 bare-token-char = %x30-39 / %x41-5A / %x61-7A / "-" / "_" 584 extension-token = "-" bare-token 1*("." bare-token) 585 extensive-token = bare-token / extension-token 587 Figure 3: BNF syntax for token values 589 The tokens (bare-token and extension-token) are case insensitive; 590 Senders SHOULD send these in lower case, and receivers MUST accept 591 both upper and lower cases. When tokens are used as (partial) inputs 592 to any hash or other mathematical functions, they MUST always be used 593 in lower case. 595 Extensive-tokens are used in this protocol where the set of 596 acceptable tokens may include non-standard extensions. Any extension 597 of this protocol MAY use either the bare-tokens allocated by IANA 598 (under the procedure described in Section 16), or extension-tokens 599 with the format "-.", where is 600 a valid (sub-)domain name on the Internet owned by the party who 601 defines the extension. 603 Bare-tokens and extensive-tokens are also used for parameter names, 604 in the unquoted form. Requirements for using the extension-token for 605 the parameter names are the same as the previous paragraph. 607 The canonical format for bare-tokens and extensive-tokens is the 608 unquoted representation. 610 3.2.2. Strings 612 All character strings MUST be encoded to octet strings using the 613 UTF-8 encoding [RFC3629] for the Unicode character set [Unicode]. 614 Such strings MUST NOT contain any leading BOM markers (also known as 615 ZERO WIDTH NO-BREAK SPACE, U+FEFF or EF BB BF). Both peers are 616 RECOMMENDED to reject any invalid UTF-8 sequences that might cause 617 decoding ambiguities (e.g., containing <"> in the second or later 618 bytes of the UTF-8 encoded characters). 620 If strings are representing a domain name or URI that contains non- 621 ASCII characters, the host parts SHOULD be encoded as it is used in 622 the HTTP protocol layer (e.g., in a Host: header); under current 623 standards it will be the one defined in [RFC5890]. It SHOULD use 624 lower-case ASCII characters. 626 The canonical format for strings is quoted-string (as it may contain 627 equal signs, plus signs and slashes), unless the parameter containing 628 the string value will use extended syntax defined in [RFC5987]. (An 629 [RFC5987] extended parameter will have an unquoted encoded value, as 630 defined therein.) 632 3.2.3. Numbers 634 The following syntax definitions give a syntax for numeric values: 636 integer = "0" / (%x31-39 *DIGIT) ; no leading zeros 637 hex-fixed-number = 1*(2(DIGIT / %x41-46 / %x61-66)) 638 base64-fixed-number = 1*( ALPHA / DIGIT / "+" / "/" ) 0*2"=" 640 Figure 4: BNF syntax for numbers 642 The syntax definition of the integers only allows representations 643 that do not contain leading zeros. 645 A number represented as a hex-fixed-number MUST include an even 646 number of hexadecimal digits (i.e., multiples of eight bits). Those 647 values are case-insensitive, and SHOULD be sent in lower case. When 648 these values are generated from any cryptographic values, they MUST 649 have their "natural length"; if these values are generated from a 650 hash function, these lengths correspond to the hash size; if these 651 are representing elements of a mathematical set (or group), these 652 lengths SHALL be the shortest for representing all the elements in 653 the set. For example, the results of the SHA-256 hash function will 654 be represented by 64 digits, and any elements in a 2048-bit prime 655 field (modulo a 2048-bit integer) will be represented by 512 digits, 656 regardless of how much zeros appear in front of such representations. 657 Session-identifiers and other non-cryptographically generated values 658 are represented in any (even) length determined by the side that 659 generates it first, and the same length MUST be used throughout all 660 communications by both peers. 662 The numbers represented as base64-fixed-number SHALL be generated as 663 follows: first, the number is converted to a big-endian radix-256 664 binary representation as an octet string. The length of the 665 representation is determined in the same way as mentioned above. 666 Then, the string is encoded using the Base 64 encoding (described in 667 Section 4 of [RFC4648]) without any spaces and newlines. 668 Implementations decoding base64-fixed-number SHOULD reject any input 669 data with invalid characters, excess/insufficient padding, or non- 670 canonical pad bits (See Sections 3.1 to 3.5 of [RFC4648]). 672 The canonical format for integer and hex-fixed-number are unquoted 673 tokens, and that for base64-fixed-number is quoted-string. 675 4. Messages 677 In this section we define the seven kinds of messages used in the 678 authentication protocol along with the formats and requirements of 679 the headers for each message. 681 To determine in what circumstances each message is expected to be 682 sent, see Sections 10 and 11. 684 In the descriptions below, the type of allowable values for each 685 header parameter is shown in parenthesis after each parameter name. 686 The "algorithm-determined" type means that the acceptable value for 687 the parameter is one of the types defined in Section 3, and is 688 determined by the value of the "algorithm" parameter. The parameters 689 marked "mandatory" SHALL be contained in the message. The parameters 690 marked "non-mandatory" MAY either be contained or omitted in the 691 message. Each parameter SHALL appear in each header exactly once at 692 most. 694 All credentials and challenges MAY contain any parameters not 695 explicitly specified in the following sections. Recipients that do 696 not understand such parameters MUST silently ignore those. However, 697 all credentials and challenges MUST meet the following criteria: 699 o For responses, the parameters "reason", any "ks#" (where # stands 700 for any decimal integer), and "vks" are mutually exclusive; any 701 challenge MUST NOT contain two or more parameters among them. 702 They MUST NOT contain any "kc#" or "vkc" parameters. 704 o For requests, the parameters "kc#" (where # stands for any decimal 705 integer), and "vkc" are mutually exclusive and any challenge 706 MUST NOT contain two or more parameters among them. They MUST NOT 707 contain any "ks#" or "vks" parameters. 709 Every message in this section contains a "version" field, to detect 710 future, incompatible revisions of the protocol. Implementations of 711 the protocol described in this specification MUST always send a token 712 "1", and recipients MUST reject messages that contain any other value 713 as a version, unless another specification defines a behavior for 714 that version. 716 4.1. 401-INIT and 401-STALE 718 Every 401-INIT or 401-STALE message SHALL be a valid HTTP 401-status 719 (Authentication Required) message (or other 4XX status if sensible) 720 containing one and only one (hereafter not explicitly noted) 721 "WWW-Authenticate" header containing a "reason" parameter in the 722 challenge. The challenge SHALL contain all of the parameters marked 723 "mandatory" below, and MAY contain those marked "non-mandatory". 725 version: (mandatory extensive-token) should be the token "1". 727 algorithm: (mandatory extensive-token) specifies the 728 authentication algorithm to be used. The value MUST 729 be one of the tokens specified in 730 [I-D.ietf-httpauth-mutual-algo] or another 731 supplemental specification. 733 validation: (mandatory extensive-token) specifies the method of 734 host validation. The value MUST be one of the tokens 735 described in Section 7 or the tokens specified in 736 another supplemental specification. 738 auth-scope: (non-mandatory string) specifies the authentication 739 scope, the set of hosts for which the authentication 740 credentials are valid. It MUST be one of the strings 741 described in Section 5. If the value is omitted, it 742 is assumed to be the "single-server" type domain in 743 Section 5. 745 realm: (mandatory string) is a string representing the name 746 of the authentication realm inside the authentication 747 scope. As specified in [RFC7235], this value MUST 748 always be sent in the quoted-string form, and an 749 [RFC5987] encoding MUST NOT be used. 750 The realm value sent from the server SHOULD be an 751 ASCII string. Clients MAY treat any non-ASCII value 752 received in this field as a binary blob, an NFC- 753 normalized UTF-8 string, or an error. 755 reason: (mandatory extensive-token) SHALL be an extensive- 756 token that describes the possible reason of the failed 757 authentication/authorization. Both servers and 758 clients SHALL understand and support the following 759 three tokens: 761 * initial: authentication was not tried because there 762 was no Authorization header in the corresponding 763 request. 765 * stale-session: the provided sid in the request was 766 either unknown to or expired in the server. 768 * auth-failed: authentication trial was failed for 769 some reason, possibly with a bad authentication 770 credential. 772 Implementations MAY support the following tokens or 773 any extensive-tokens defined outside this 774 specification. If clients receive any unknown tokens, 775 they SHOULD treat these as if they were "auth-failed" 776 or "initial". 778 * reauth-needed: the server-side application requires 779 a new authentication trial, regardless of the 780 current status. 782 * invalid-parameters: the server did not attempt 783 authentication because some parameters were not 784 acceptable. 786 * internal-error: the server did not attempt 787 authentication because there are some troubles on 788 the server-side. 790 * user-unknown: this is a special case of auth- 791 failed, suggesting that the provided user name is 792 invalid. The use of this parameter is 793 NOT RECOMMENDED due to security implications, 794 except for special-purpose applications where it 795 makes sense. 797 * invalid-credential: ditto, suggesting that the 798 provided user name was valid but authentication 799 still failed. The use of this parameter is 800 NOT RECOMMENDED for security reasons. 802 * authz-failed: authentication was successful, but 803 access to the specified resource is not authorized 804 to the specific authenticated user. (It might be 805 used along with either a 401 or 403 status to 806 indicate that the authentication result is one of 807 the existing reasons for the failed authorization.) 809 It is RECOMMENDED to record the reasons to a kind of 810 diagnostic log, for an example, or shown to the client 811 user immediately. It will be helpful to find out 812 later that the reason of the failed authentication is 813 either technical reasons of user errors. 815 The algorithm specified in this header will determine the types 816 (among those defined in Section 3) and the values for K_c1, K_s1, 817 VK_c and VK_s. 819 Among these messages, those with the reason parameter of value 820 "stale-session" will be called "401-STALE" messages hereafter, 821 because these have a special meaning in the protocol flow. Messages 822 with any other reason parameters will be called "401-INIT" messages. 824 4.2. req-KEX-C1 826 Every req-KEX-C1 message SHALL be a valid HTTP request message 827 containing an "Authorization" header with a credential containing a 828 "kc1" parameter. 830 The credential SHALL contain the parameters with the following names: 832 version: (mandatory, extensive-token) should be the token "1". 834 algorithm, validation, auth-scope, realm: MUST be the same values as 835 received from the server. 837 user: (mandatory, string) is the UTF-8 encoded name of the 838 user. The string SHOULD be prepared according to the 839 method presented in Section 9. 841 kc1: (mandatory, algorithm-determined) is the client-side 842 key exchange value K_c1, which is specified by the 843 algorithm that is used. 845 4.3. 401-KEX-S1 847 Every 401-KEX-S1 message SHALL be a valid HTTP 401-status 848 (Authentication Required) response message containing a 849 "WWW-Authenticate" header with a challenge containing a "ks1" 850 parameter. 852 The challenge SHALL contain the parameters with the following names: 854 version: (mandatory, extensive-token) should be the token "1". 856 algorithm, validation, auth-scope, realm: MUST be the same values as 857 received from the client. 859 sid: (mandatory, hex-fixed-number) MUST be a session 860 identifier, which is a random integer. The sid SHOULD 861 have uniqueness of at least 80 bits or the square of 862 the maximum estimated transactions concurrently 863 available in the session table, whichever is larger. 864 See Section 6 for more details. 866 ks1: (mandatory, algorithm-determined) is the server-side 867 key exchange value K_s1, which is specified by the 868 algorithm. 870 nc-max: (mandatory, integer) is the maximum value of nonce 871 numbers that the server accepts. 873 nc-window: (mandatory, integer) the number of available nonce 874 number slots that the server will accept. The value 875 of the nc-window parameter is RECOMMENDED to be 128 or 876 more. 878 time: (mandatory, integer) represents the suggested time (in 879 seconds) that the client can reuse the session 880 represented by the sid. It is RECOMMENDED to be at 881 least 60. The value of this parameter is not directly 882 linked to the duration that the server keeps track for 883 the session represented by the sid. 885 path: (non-mandatory, string) specifies which path in the 886 URI space the same authentication is expected to be 887 applied. The value is a space-separated list of URIs, 888 in the same format as it was specified in domain 889 parameter [RFC7616] for Digest authentications. All 890 path elements contained in the parameter MUST be 891 inside the specified auth-scope; if not, clients 892 SHOULD ignore such elements. For better performance, 893 recognition of this parameter by clients is important. 895 4.4. req-VFY-C 897 Every req-VFY-C message SHALL be a valid HTTP request message 898 containing an "Authorization" header with a credential containing a 899 "vkc" parameter. 901 The parameters contained in the header are as follows: 903 version: (mandatory, extensive-token) should be the token "1". 905 algorithm, validation, auth-scope, realm: MUST be the same values as 906 received from the server for the session. 908 sid: (mandatory, hex-fixed-number) MUST be one of the sid 909 values that was received from the server for the same 910 authentication realm. 912 nc: (mandatory, integer) is a nonce request number that is 913 unique among the requests sharing the same sid. The 914 values of the nonce numbers SHOULD satisfy the 915 properties outlined in Section 6. 917 vkc: (mandatory, algorithm-determined) is the client-side 918 authentication verification value VK_c, which is 919 specified by the algorithm. 921 4.5. 200-VFY-S 923 Every 200-VFY-S message SHALL be a valid HTTP message that does not 924 have a 401 (Authentication Required) status code and SHALL contain an 925 "Authentication-Info" header with a "vks" parameter. 927 The parameters contained in the header are as follows: 929 version: (mandatory, extensive-token) should be the token "1". 931 sid: (mandatory, hex-fixed-number) MUST be the value 932 received from the client. 934 vks: (mandatory, algorithm-determined) is the server-side 935 authentication verification value VK_s, which is 936 specified by the algorithm. 938 The header MUST be sent before the content body: it MUST NOT be sent 939 in the trailer of a chunked-encoded response. If a "100 Continue" 940 response is sent from the server, the Authentication-Info header 941 SHOULD be included in that response, instead of the final response. 943 5. Authentication Realms 945 In this protocol, an "authentication realm" is defined as a set of 946 resources (URIs) for which the same set of user names and passwords 947 is valid. If the server requests authentication for an 948 authentication realm that the client is already authenticated for, 949 the client will automatically perform the authentication using the 950 already-known credentials. However, for different authentication 951 realms, clients MUST NOT automatically reuse user names and passwords 952 for another realm. 954 Just like in the Basic and Digest access authentication protocols, 955 the Mutual authentication protocol supports multiple, separate 956 protection spaces to be set up inside each host. Furthermore, the 957 protocol allows a single authentication realm to span over several 958 hosts within the same Internet domain. 960 Each authentication realm is defined and distinguished by the triple 961 of an "authentication algorithm", an "authentication scope", and a 962 "realm" parameter. However, server operators are NOT RECOMMENDED to 963 use the same pair of an authentication scope and a realm with 964 different authentication algorithms. 966 The realm parameter is a string as defined in Section 4. 967 Authentication scopes are described in the remainder of this section. 969 An authentication scope specifies the range of hosts that the 970 authentication realm spans over. In this protocol, it MUST be one of 971 the following kinds of strings. 973 o Single-server type: A string in the format "://" or 974 "://:", where , , and are 975 the corresponding URI parts of the request URI. If the default 976 port (i.e., 80 for http and 443 for https) is used for the 977 underlying HTTP communications, the port part MUST be omitted, 978 regardless of whether it was present in the request-URI. In all 979 other cases, the port part MUST be present, and it MUST NOT 980 contain leading zeros. Use this format when authentication is 981 only valid for a specific protocol (such as https). This format 982 is equivalent to the ASCII serialization of a Web Origin, 983 presented in Section 6.2 of [RFC6454]. 985 o Single-host type: The "host" part of the requested URI. This is 986 the default value. Authentication realms within this kind of 987 authentication scope will span over several protocols (e.g., http 988 and https) and ports, but not over different hosts. 990 o Wildcard-domain type: A string in the format "*.", 991 where is either the host part of the requested 992 URI or any domain in which the requested host is included (this 993 means that the specification "*.example.com" is valid for all of 994 hosts "www.example.com", "web.example.com", 995 "www.sales.example.com" and "example.com"). The domain-postfix 996 sent by the servers MUST be equal to or included in a valid 997 Internet domain assigned to a specific organization; if clients 998 know, by some means such as a blacklist for HTTP cookies 999 [RFC6265], that the specified domain is not to be assigned to any 1000 specific organization (e.g., "*.com" or "*.jp"), clients are 1001 RECOMMENDED to reject the authentication request. 1003 In the above specifications, every "scheme", "host", and "domain" 1004 MUST be in lower case, and any internationalized domain names beyond 1005 the ASCII character set SHALL be represented in the way they are sent 1006 in the underlying HTTP protocol, represented in lower case 1007 characters, i.e., these domain names SHALL be in the form of LDH 1008 labels in IDNA [RFC5890]. A "port" MUST be given in the shortest, 1009 unsigned, decimal number notation. Not obeying these requirements 1010 will cause failure of valid authentication attempts. 1012 5.1. Resolving Ambiguities 1014 In the above definitions of authentication scopes, several scopes may 1015 overlap each other. If a client has already been authenticated to 1016 several realms applicable to the same server, the client may have a 1017 multiple lists of the "path" parameters received with the 1018 "401-KEX-S1" message (see Section 4). If these path lists have any 1019 overlap, a single URI may belong to multiple possible candidate of 1020 realms to be authenticated to. In such cases, clients faces an 1021 ambiguity in deciding which credentials to send for a new request (in 1022 steps 3 and 4 of the decision procedure presented in Section 10). 1024 In such cases, a client MAY send request which belong to any of these 1025 candidate realms freely, or it MAY simply send an unauthenticated 1026 request and see for which realm the server requests an 1027 authentication. Server operators are RECOMMENDED to provide 1028 properly-configured "path" parameters (more precisely, disjoint path 1029 sets for each realms) for clients so that such ambiguities will not 1030 occur. 1032 The following procedure is one possible tactic for resolving 1033 ambiguity in such cases. 1035 o If the client has previously sent a request to the same URI, and 1036 if it remembers the authentication realm requested by the 401-INIT 1037 message at that time, use that realm. 1039 o In other cases, use one of the authentication realms representing 1040 the most-specific authentication scopes. The list of possible 1041 domain specifications shown above is given from most specific to 1042 least specific. 1044 If there are several choices with different wildcard-domain 1045 specifications, the one that has the longest domain-postfix has 1046 priority over ones with shorter domain-postfixes. 1048 o If there are realms with the same authentication scope, there is 1049 no defined priority; the client MAY choose any one of the possible 1050 choices. 1052 6. Session Management 1054 In the Mutual authentication protocol, a session represented by an 1055 sid is set up using four messages (first request, 401-INIT, 1056 req-KEX-C1 and 401-KEX-S1), after which a "session secret" (z) 1057 associated with the session is established. After mutually 1058 establishing a session secret, this session, along with the secret, 1059 can be used for one or more requests for resources protected by the 1060 same realm on the same server. Note that session management is only 1061 an inside detail of the protocol and usually not visible to normal 1062 users. If a session expires, the client and server SHOULD 1063 automatically re-establish another session without informing the 1064 user. 1066 Sessions and session identifiers are local to each server (defined by 1067 scheme, host, and port), even if an authentication scope covers 1068 multiple servers; clients MUST establish separate sessions for each 1069 port of a host to be accessed. Furthermore, sessions and identifiers 1070 are also local to each authentication realm, even if these are 1071 provided by the same server. The same session identifiers provided 1072 either from different servers or for different realms MUST be treated 1073 as independent or each other. 1075 The server SHOULD accept at least one req-VFY-C request for each 1076 session, if the request reaches the server in a time window specified 1077 by the timeout parameter in the 401-KEX-S1 message, and there are no 1078 emergent reasons (such as flooding attacks) to forget the session. 1079 After that, the server MAY discard any session at any time and MAY 1080 send 401-STALE messages for any further req-VFY-C requests received 1081 for that session. 1083 The client MAY send two or more requests using a single session 1084 specified by the sid. However, for all such requests, each value of 1085 the nonce number (in the nc parameter) MUST satisfy the following 1086 conditions: 1088 o It is a natural number. 1090 o The same nonce number was not sent within the same session. 1092 o It is not larger than the nc-max value that was sent from the 1093 server in the session represented by the sid. 1095 o It is larger than (largest-nc - nc-window), where largest-nc is 1096 the largest value of nc which was previously sent in the session, 1097 and nc-window is the value of the nc-window parameter that was 1098 received from the server for the session. 1100 The last condition allows servers to reject any nonce numbers that 1101 are "significantly" smaller than the "current" value (defined by the 1102 value of nc-window) of the nonce number used in the session involved. 1103 In other words, servers MAY treat such nonce numbers as "already 1104 received". This restriction enables servers to implement duplicate 1105 nonce detection in a constant amount of memory for each session. 1107 Servers MUST check for duplication of the received nonce numbers, and 1108 if any duplication is detected, the server MUST discard the session 1109 and respond with a 401-STALE message, as outlined in Section 11. The 1110 server MAY also reject other invalid nonce numbers (such as ones 1111 above the nc-max limit) by sending a 401-STALE message. 1113 For example, assume the nc-window value of the current session is 1114 128, nc-max is 400, and that the client has already used the 1115 following nonce numbers: {1-120, 122, 124, 130-238, 255-360, 363- 1116 372}. Then the nonce number that can be used for the next request is 1117 one of the following set: {245-254, 361, 362, 373-400}. The values 1118 {0, 121, 123, 125-129, 239-244} MAY be rejected by the server because 1119 they are not above the current "window limit" (244 = 372 - 128). 1121 Typically, clients can ensure the above property by using a 1122 monotonically-increasing integer counter that counts from zero up to 1123 the value of nc-max. 1125 The values of the nonce numbers and any nonce-related values MUST 1126 always be treated as natural numbers within an infinite range. 1127 Implementations which uses fixed-width integer representations, 1128 fixed-precision floating-point numbers, or similar representations 1129 SHOULD NOT reject any larger values which overflow such 1130 representative limits, and MUST NOT silently truncate them using any 1131 modulus-like rounding operation (e.g., by mod 2^32). Instead, the 1132 whole protocol is carefully designed so that recipients MAY replace 1133 any such overflowing values (e.g. 2^80) with some reasonably-large 1134 maximum representative integer (e.g., 2^31 - 1 or others). 1136 7. Host Validation Methods 1138 The "validation method" specifies a method to "relate" (or "bind") 1139 the mutual authentication processed by this protocol with other 1140 authentications already performed in the underlying layers and to 1141 prevent man-in-the-middle attacks. It determines the value vh that 1142 is an input to the authentication protocols. 1144 When HTTPS or other possible secure transport is used, this 1145 corresponds to the idea of "channel binding" described in [RFC5929]. 1146 Even when HTTP is used, similar, but somewhat limited, "binding" is 1147 performed to prevent a malicious server from trying to authenticate 1148 itself to another server as a valid user by forwarding the received 1149 credentials. 1151 The valid tokens for the validation parameter and corresponding 1152 values of vh are as follows: 1154 host: host-name validation: The value vh will be the ASCII 1155 string in the following format: 1156 "://:", where , , 1157 and are the URI components corresponding to the 1158 server-side resource currently being accessed. The 1159 scheme and host are in lower case, and the port is in 1160 a shortest decimal representation. Even if the 1161 request-URI does not have a port part, v will include 1162 the default port number. 1164 tls-server-end-point: TLS endpoint (certificate) validation: The 1165 value vh will be the octet string of the hash value of 1166 the server's public key certificate used in the 1167 underlying TLS [RFC5246] connection, processed as 1168 specified in Section 4.1 of [RFC5929]. 1170 tls-unique: TLS shared-key validation: The value vh will be the 1171 channel binding material derived from the Finished 1172 messages, as defined in Section 3.1 of [RFC5929]. 1173 (Note: see Section 7.2 for some security notices when 1174 using this validation method.) 1176 If HTTP is used on a non-encrypted channel (TCP and SCTP, for 1177 example), the validation type MUST be "host". If HTTP/TLS [RFC2818] 1178 (HTTPS) is used with a server certificate, the validation type MUST 1179 be "tls-server-end-point". If HTTP/TLS is used with an anonymous 1180 Diffie-Hellman key exchange, the validation type MUST be "tls-unique" 1181 (see the note below). 1183 If the validation type "tls-server-end-point" is used, the server 1184 certificate provided in the TLS connection MUST be verified at least 1185 to make sure that the server actually owns the corresponding private 1186 key. (Note: this verification is automatic in some RSA-based key 1187 exchanges but NOT automatic in Diffie-Hellman-based key exchanges 1188 with separate exchange for server verification.) 1190 Clients MUST validate this parameter upon receipt of 401-INIT 1191 messages. 1193 Note: The protocol defines two variants of validation on the TLS 1194 connections. The "tls-unique" method is technically more secure. 1195 However, there are some situations where tls-server-end-point is more 1196 preferable. 1198 o When TLS accelerating proxies are used, it is difficult for the 1199 authenticating server to acquire the TLS key information that is 1200 used between the client and the proxy. This is not the case for 1201 client-side "tunneling" proxies using the HTTP CONNECT method. 1203 o When a black-box implementation of the TLS protocol is used on 1204 either peer. 1206 7.1. Applicability notes 1208 When the client is a Web browser with any scripting capabilities 1209 (dynamic contents support), the underlying TLS channel used with 1210 HTTP/TLS MUST provide server identity verification. This means (1) 1211 anonymous Diffie-Hellman key exchange cipher suites MUST NOT be used, 1212 and (2) verification of the server certificate provided by the server 1213 MUST be performed. This is to prevent loading identity- 1214 unauthenticated scripts or dynamic contents, which are referenced 1215 from the authenticated page. 1217 For other systems, when the underlying TLS channel used with HTTP/TLS 1218 does not perform server identity verification, the client SHOULD 1219 ensure that all responses are validated using the Mutual 1220 authentication protocol, regardless of the existence of 401-INIT 1221 responses. 1223 7.2. Notes on tls-unique 1225 As described in the interoperability note in the above channel 1226 binding specification, the tls-unique verification value will be 1227 changed by possible TLS renegotiation, causing an interoperability 1228 problem. TLS re-negotiations are used in several HTTPS server 1229 implementations for enforcing some security properties (such as 1230 cryptographic strength) for some specific responses. 1232 If an implementation supports the "tls-unique" verification method, 1233 the following caution SHOULD be taken: 1235 o Both peers must be aware that the vh values used for vkc (in 1236 req-VFY-C) and for vks (in 200-VFY-S) may be different. These 1237 values MUST be retrieved from underlying TLS libraries each time 1238 they are used. 1240 o After calculating the values vh and vkc to send a req-VFY-C 1241 request, Clients SHOULD NOT initiate TLS renegotiation until the 1242 end of the corresponding response header is received. An 1243 exception is that clients can and SHOULD perform TLS re- 1244 negotiation as a response to the server's request for TLS 1245 renegotiation, before receipt of the beginning of the response 1246 header. 1248 Also, implementers MUST take care of session resumption attacks 1249 regarding tls-unique channel binding mechanisms and master secrets. 1250 As a mitigation, a TLS extension defined in [RFC7627] SHOULD be used 1251 when tls-unique host verification is to be used. 1253 8. Authentication Extensions 1255 Interactive clients (e.g., Web browsers) supporting this protocol are 1256 RECOMMENDED to support non-mandatory authentication and the 1257 Authentication-Control header defined in 1258 [I-D.ietf-httpauth-extension], except for the "auth-style" parameter. 1259 This specification also proposes (however, does not mandate) the 1260 default "auth-style" be "non-modal". Web applications SHOULD however 1261 consider the security impacts of the behaviors of clients that do not 1262 support these headers. 1264 Authentication-initializing messages with the 1265 Optional-WWW-Authenticate header are used only where the 401-INIT 1266 response is valid. It will not replace other 401-type messages such 1267 as 401-STALE and 401-KEX-S1. That is, the reason field of such a 1268 message MUST be "initial" (or any extensive-tokens NOT defined in 1269 Section 4.1). 1271 9. String Preparation 1273 It is important for interoperability that user names and passwords 1274 used in this protocol are binary-comparable regardless of the user's 1275 input methods and/or environments. To ensure this, the following 1276 preparation SHOULD be performed: 1278 o User names received from users SHOULD be prepared using the 1279 "UsernameCasePreserved" profile defined in Section 3.3 of 1280 [RFC7613]. 1282 o Passwords received from users SHOULD be prepared using the 1283 "OpaqueString" profile defined in Section 4.2 of [RFC7613]. 1285 In both cases, it is the sender's duty to correctly prepare the 1286 character strings. If any non-prepared character string is received 1287 from the other peer of the communication, the behavior of its 1288 recipient is not defined; the recipient MAY either accept or reject 1289 such input. 1291 Server applications SHOULD also prepare user names and passwords 1292 accordingly upon registration of user credentials. 1294 In addition, binary-based "interfaces" of implementations MAY require 1295 and assume that the string is already prepared accordingly; when a 1296 string is already stored as a binary Unicode string form, 1297 implementations MAY omit preparation and Unicode normalization 1298 (performing UTF-8 encoding only) before using it. When a string is 1299 already stored as an octet blob, implementations MAY send it as is. 1301 10. Decision Procedure for Clients 1303 10.1. General Principles and Requirements 1305 To securely implement the protocol, the client must be careful about 1306 accepting the authenticated responses from the server. This also 1307 holds true for the reception of a "normal response" (a response which 1308 does not contain Mutual authentication-related headers) from HTTP 1309 servers. 1311 As usual in the HTTP authentication, a single user-level request may 1312 result in exchange of two-or-more HTTP requests and responses in 1313 sequence. The following normative rules MUST be followed by the 1314 clients implementing this protocol: 1316 o Any kind of a "normal response" MUST only be accepted for the very 1317 first request in the sequence. Any "normal response" returned for 1318 the second or later requests in the sequence SHALL be considered 1319 invalid. 1321 o In the same principle, if any response is related to an 1322 authentication realm which is different from that of the client's 1323 request (for example, a 401-INIT message requesting authentication 1324 on another realm), it MUST only be accepted for the very first 1325 request in the sequence. Such a response returned for a second or 1326 later request in the sequence SHALL be considered invalid. 1328 o A req-KEX-C1 message MAY be sent either as a initial request or as 1329 a response to 401-INIT or 401-STALE. However, it SHOULD NOT be 1330 sent more than once in the sequence for a single authentication 1331 realm, to avoid infinite loops of messages. A 401-KEX-S1 response 1332 MUST be accepted only when the corresponding request is 1333 req-KEX-C1. 1335 o A req-VFY-C message MAY be sent if there is a valid session secret 1336 shared between the client and the server, established by 1337 req-KEX-C1 and 401-KEX-S1. If any response with 401 status is 1338 returned for such a message, the corresponding session secret 1339 SHOULD be discarded as unusable. 1340 Especially, upon the reception of a 401-STALE response, the client 1341 SHOULD try establishing a new session by sending req-KEX-C1, but 1342 only once within the request/response sequence. 1344 o A 200-VFY-S message MUST be accepted only as a response to 1345 req-VFY-C and nothing else. The VK_s values of such response 1346 messages MUST always be checked against the correct value, and if 1347 it is incorrect, the whole response SHOULD be considered invalid. 1349 The final status of the client request following the message exchange 1350 sequence shall be determined as follows: 1352 o AUTH-SUCCEED: A 200-VFY-S message with the correct VK_s value was 1353 returned in response to the req-VFY-C request in the sequence. 1355 o AUTH-REQUIRED: Two cases exists. 1357 * A 401-INIT message was returned from the server, and the client 1358 does not know how to authenticate to the given authentication 1359 realm. 1361 * A 401-INIT response was returned for req-VFY-C (or req-KEX-C1), 1362 which means the user-supplied authentication credentials were 1363 not accepted. 1365 o UNAUTHENTICATED: a normal response is returned for an initial 1366 request of any kind in the sequence. 1368 Any kind of response (including a normal response) other than those 1369 explicitly allowed in the above rules SHOULD be interpreted as a 1370 fatal communication error. In such cases, the clients MUST NOT 1371 process any data (the response body and other content-related 1372 headers) sent from the server. However, to handle exceptional error 1373 cases, clients MAY accept a message without an Authentication-Info 1374 header, if it has a Server-Error (5xx) status code. In such cases, 1375 they SHOULD be careful about processing the body of the content 1376 (ignoring it is still RECOMMENDED, as it may possibly be forged by 1377 intermediate attackers), and the client will be in the 1378 "UNAUTHENTICATED" status then. 1380 If a request is a sub-request for a resource included in another 1381 resource (e.g., embedded images, style sheets, frames etc.), clients 1382 MAY treat an AUTH-REQUESTED status as the same as an UNAUTHENTICATED 1383 status. In other words, the client MAY ignore server's request to 1384 start authentication with new credentials via sub-requests. 1386 10.2. State machine for the client (informative) 1388 The following state machine describes the possible request-response 1389 sequences derived from the above normative rules. If implementers 1390 are not quite sure on the security consequences of the above rules, 1391 it is strongly advised to follow the decision procedure below. In 1392 particular, clients SHOULD NOT accept "normal responses" unless 1393 explicitly allowed in the rules. The labels on the steps are for 1394 informational purposes only. Action entries within each step are 1395 checked in top-to-bottom order, and the first clause satisfied is to 1396 be followed. 1398 Step 1 (step_new_request): 1399 If the client software needs to access a new Web resource, check 1400 whether the resource is expected to be inside some authentication 1401 realm for which the user has already been authenticated by the 1402 Mutual authentication scheme. If yes, go to Step 2. Otherwise, 1403 go to Step 5. 1405 Step 2: 1406 Check whether there is an available sid for the expected 1407 authentication realm. If there is one, go to Step 3. Otherwise, 1408 go to Step 4. 1410 Step 3 (step_send_vfy_1): 1411 Send a req-VFY-C request. 1413 * If you receive a 401-INIT message with a different 1414 authentication realm than expected, go to Step 6. 1416 * If a 401-STALE message is received, go to Step 9. 1418 * If a 401-INIT message is received, go to Step 13. 1420 * If a 200-VFY-S message is received, go to Step 14. 1422 * If a normal response is received, go to Step 11. 1424 Step 4 (step_send_kex1_1): 1425 Send a req-KEX-C1 request. 1427 * If a 401-INIT message is received with a different 1428 authentication realm than expected, go to Step 6. 1430 * If a 401-KEX-S1 message is received, go to Step 10. 1432 * If a 401-INIT message is received with the same authentication 1433 realm, go to Step 13 (see Note 1). 1435 * If a normal response is received, go to Step 11. 1437 Step 5 (step_send_normal_1): 1438 Send a request without any Mutual authentication headers. 1440 * If a 401-INIT message is received, go to Step 6. 1442 * If a normal response is received, go to Step 11. 1444 Step 6 (step_rcvd_init): 1445 Check whether the user's password for the requested 1446 authentication realm is known. If yes, go to Step 7. Otherwise, 1447 go to Step 12. 1449 Step 7: 1450 Check whether there is an available sid for the expected 1451 authentication realm. If there is one, go to Step 8. Otherwise, 1452 go to Step 9. 1454 Step 8 (step_send_vfy): 1455 Send a req-VFY-C request. 1457 * If a 401-STALE message is received, go to Step 9. 1459 * If a 401-INIT message is received, go to Step 13. 1461 * If a 200-VFY-S message is received, go to Step 14. 1463 Step 9 (step_send_kex1): 1464 Send a req-KEX-C1 request. 1466 * If a 401-KEX-S1 message is received, go to Step 10. 1468 * If a 401-INIT message is received, go to Step 13 (See Note 1). 1470 Step 10 (step_rcvd_kex1): 1471 Send a req-VFY-C request. 1473 * If a 401-INIT message is received, go to Step 13. 1475 * If a 200-VFY-S message is received, go to Step 14. 1477 Step 11 (step_rcvd_normal): 1478 The requested resource is out of the authenticated area. The 1479 client will be in the "UNAUTHENTICATED" status. If the response 1480 contains a request for authentications other than Mutual, it MAY 1481 be handled normally. 1483 Step 12 (step_rcvd_init_unknown): 1484 The requested resource requires Mutual authentication, and the 1485 user is not yet authenticated. The client will be in the "AUTH- 1486 REQUESTED" status, and is RECOMMENDED to process the content sent 1487 from the server, and to ask the user for a user name and a 1488 password. When those are supplied from the user, proceed to Step 1489 9. 1491 Step 13 (step_rcvd_init_failed): 1492 For some reason the authentication failed: possibly the password 1493 or the username is invalid for the authenticated resource. 1494 Forget the user-provided credentials for the authentication realm 1495 and go to Step 12. 1497 Step 14 (step_rcvd_vfy): 1498 The received message is the 200-VFY-S message, which always 1499 contains a vks field. Check the validity of the received VK_s 1500 value. If it is equal to the expected value, it means that the 1501 mutual authentication has succeeded. The client will be in the 1502 "AUTH-SUCCEEDED" status. 1504 If the value is unexpected, it is a fatal communication error. 1506 If a user explicitly requests to log out (via the user 1507 interface), the client MUST forget the user's password, go to 1508 step 5, and reload the current resource without an authentication 1509 header. 1511 Note 1: These transitions MAY be accepted by clients, but are 1512 NOT RECOMMENDED for servers to initiate. 1514 Figure 5 shows an informative diagram of the client state. 1516 =========== -(11)------------ 1517 NEW REQUEST ( UNAUTHENTICATED ) 1518 =========== ----------------- 1519 | ^ normal 1520 v | response 1521 +(1)-------------------+ NO +(5)----------+ 1522 | The requested URI |--------------------------->| send normal | 1523 | known to be auth'ed? | | request | 1524 +----------------------+ +-------------+ 1525 YES | 401-INIT 401-INIT| 1526 | with a different realm | 1527 | -----------------------------------. | 1528 | / v v 1529 | | -(12)------------ NO +(6)--------+ 1530 | | ( AUTH-REQUESTED )<------| user/pass | 1531 | | ----------------- | known? | 1532 | | +-----------+ 1533 | | |YES 1534 v | v 1535 +(2)--------+ | +(7)--------+ 1536 | session | | | session | NO 1537 NO /| available?| | | available?|\ 1538 / +-----------+ | +-----------+ | 1539 / |YES | |YES | 1540 | | /| | | 1541 | v / | 401- 401- v | 1542 | +(3)--------+ | INIT --(13)---------- INIT +(8)--------+ | 1543 | | send |--+----->/ AUTH-REQUESTED \<-------| send | | 1544 | /| req-VFY-C | | \forget password / | req-VFY-C | | 1545 \/ +-----------+ / ---------------- /+-----------+ | 1546 /\ \ \/ ^ 401-INIT | |401- | 1547 | ------ \/\ 401-STALE | | | STALE / 1548 | \ /\ -----------------+--------------+---. | / 1549 | | / \ | | | | / 1550 | v / | 401- | 401- | v v v 1551 | +(4)--------+ | KEX-S1 +(10)-------+ KEX-S1 | +(9)--------+ 1552 | | send |-|--------->| send |<-------+-| send | 1553 | --| req-KEX-C1| | | req-VFY-C | | | req-KEX-C1| 1554 |/ +-----------+ | +-----------+ | +-----------+ 1555 | |200-VFY-S | 200-VFY-S| ^ 1556 |normal | |200-VFY-S / | 1557 |response | v / ================== 1558 v \ -(14)--------- / USER/PASS INPUTTED 1559 -(11)------------ ------->( AUTH-SUCCEED )<-- ================== 1560 ( UNAUTHENTICATED ) -------------- 1561 ----------------- 1563 Figure 5: State diagram for clients 1565 11. Decision Procedure for Servers 1567 Each server SHOULD have a table of session states. This table need 1568 not be persistent over the long term; it MAY be cleared upon server 1569 restart, reboot, or for other reasons. Each entry in the table 1570 SHOULD contain at least the following information: 1572 o The session identifier, which is the value of the sid parameter. 1574 o The algorithm used. 1576 o The authentication realm. 1578 o The state of the protocol: one of "key exchanging", 1579 "authenticated", "rejected", or "inactive". 1581 o The user name received from the client. 1583 o A boolean flag representing whether or not the session is fake. 1585 o When the state is "key exchanging", the values of K_c1 and S_s1. 1587 o When the state is "authenticated", the following information: 1589 * The value of the session secret, z 1591 * The largest nc received from the client (largest-nc) 1593 * For each possible nc values between (largest-nc - nc- 1594 window + 1) and max_nc, a boolean flag whether or not a request 1595 with the corresponding nc has been received. 1597 The table MAY contain other information. 1599 Servers SHOULD respond to the client requests according to the 1600 following procedure: (See Note 1 below for 401-INIT message with a 1601 plus sign) 1603 o When the server receives a normal request: 1605 * If the requested resource is not protected by the Mutual 1606 authentication, send a normal response. 1608 * If the resource is protected by the Mutual authentication, send 1609 a 401-INIT response. 1611 o When the server receives a req-KEX-C1 request: 1613 * If the requested resource is not protected by the Mutual 1614 authentication, send a normal response. 1616 * If the authentication realm specified in the req-KEX-C1 request 1617 is not the expected one, send a 401-INIT response. 1619 * If the server cannot validate the parameter kc1, send a 1620 401-INIT (+) response. 1622 * If the received user name is either invalid, unknown or 1623 unacceptable, create a new session, mark it a "fake" session, 1624 compute a random value as K_s1, and send a fake 401-KEX-S1 1625 response. (See Note 2.) 1627 * Otherwise, create a new session, compute K_s1 and send a 1628 401-KEX-S1 response. The created session is marked as not 1629 fake, and its largest-nc is initialized to zero. 1631 The created session has the "key exchanging" state. 1633 o When the server receives a req-VFY-C request: 1635 * If the requested resource is not protected by the Mutual 1636 authentication, send a normal response. 1638 * If the authentication realm specified in the req-VFY-C request 1639 is not the expected one, send a 401-INIT response. 1641 If none of above holds true, the server will look up the session 1642 corresponding to the received sid and the authentication realm. 1644 * If the session corresponding to the received sid could not be 1645 found, or it is in the "inactive" state, send a 401-STALE 1646 response. 1648 * If the session is in the "rejected" state, send either a 1649 401-INIT (+) or a 401-STALE message. 1651 * If the nc value in the request is larger than the nc-max 1652 parameter sent from the server, or if it is not larger then 1653 (largest-nc - nc-window) (when in "authenticated" status), the 1654 server MAY (but is not REQUIRED to; See Note 3) send a 1655 401-STALE message. The session is changed to the "inactive" 1656 state if so did. 1658 * If the session is in the "authenticated" state, and the request 1659 has an nc value that was previously received from the client, 1660 send a 401-STALE message. The session it changed to the 1661 "inactive" state. 1663 * If the session is a "fake" session, or if the received vkc is 1664 incorrect, then send a 401-INIT (+) response. If the session 1665 is in the "key exchanging" state, it MUST be changed to the 1666 "rejected" state; otherwise, it MAY either be changed to the 1667 "rejected" state or kept in the previous state. 1669 * Otherwise, send a 200-VFY-S response. If the session was in 1670 the "key exchanging" state, the session SHOULD be changed to an 1671 "authenticated" state. The maximum nc and nc flags of the 1672 state MUST be updated appropriately. 1674 At any time, the server MAY change any state entries with both the 1675 "rejected" and "authenticated" states to the "inactive" status, and 1676 MAY discard any "inactive" states from the table. Entries with the 1677 "key exchanging" state SHOULD be kept unless there is an emergency 1678 situation such as a server reboot or a table capacity overflow. 1680 Note 1: In relation with and following the specification of the 1681 optional authentication defined in [I-D.ietf-httpauth-extension], the 1682 401-INIT messages marked with the pluses cannot be replaced with a 1683 successful responses with an Optional-WWW-Authenticate header. Every 1684 other 401-INIT can be a response with an Optional-WWW-Authenticate. 1686 Note 2: the server SHOULD NOT send a 401-INIT response in this case, 1687 because it will leak the information to the client that the specified 1688 user name will not be accepted. Instead, postpone it to the response 1689 for the next req-VFY-C request. 1691 Note 3: The next case implies that, when the request is not rejected 1692 in this clause, the server must be able to determine whether the same 1693 nc value was previously received from the client. If the server does 1694 not remember a whole history of the nc values received from the 1695 client, the server MUST send a 401-STALE message on this clause. 1697 12. Authentication Algorithms 1699 Cryptographic authentication algorithms which are used with this 1700 protocol will be defined separately. The algorithm definition MUST 1701 at least provide definitions for the following functions: 1703 o The server-side authentication credential J, derived from client- 1704 side authentication credential pi. 1706 o Key exchange values K_c1, K_s1 (exchanged on wire) and S_c1, S_s1 1707 (kept secret in each peer). 1709 o Shared session secret z, to be computed by both server and client. 1711 o A hash function H to be used with the protocol, along with its 1712 output size hSize. 1714 o The number of iterations for password hashing nIterPi, if it uses 1715 the default password hashing function defined below. 1717 Specifications for cryptographic algorithms used with this framework 1718 MUST specify whether these will use the default functions defined 1719 below for values pi, VK_c, and VK_s; or, these will define their own 1720 versions for these. 1722 All algorithm used with this protocol SHOULD provide secure mutual 1723 authentication between client and servers, and generate a 1724 cryptographically strong shared secret value z, equivalently strong 1725 to or stronger than the hash function H. If any passwords (or pass- 1726 phrases or any equivalents, i.e., weak secrets) are involved, these 1727 SHOULD NOT be guessable from any data transmitted in the protocol, 1728 even if an attacker (either an eavesdropper or an active server) 1729 knows the possible thoroughly-searchable candidate list of the 1730 passwords. Furthermore, if possible, the function J for deriving 1731 server-side authentication credential J(pi) is RECOMMENDED to be one- 1732 way so that pi should not be easily computed from J(pi). 1734 12.1. Support Functions and Notations 1736 In this section we define several support functions and notations to 1737 be shared by several algorithm definitions. 1739 The integers in the specification are in decimal, or in hexadecimal 1740 when prefixed with "0x". 1742 The function octet(i) generates an octet string containing a single 1743 octet of value i. The operator |, when applied to octet strings, 1744 denotes the concatenation of two operands. 1746 The function VI encodes natural numbers into octet strings in the 1747 following manner: numbers are represented as big-endian radix-128 1748 strings, where each digit is represented by an octet within the range 1749 0x80-0xff except the last digit, which is represented by a octet 1750 within the range 0x00-0x7f. The first octet MUST NOT be 0x80. For 1751 example, VI(i) = octet(i) for i < 128, and VI(i) = octet(0x80 + (i >> 1752 7)) | octet(i & 127) for 128 <= i < 16384. This encoding is the same 1753 as the one used for the sub-components of object identifiers in the 1754 ASN.1 encoding [ITU.X690.1994], and available as a "w" conversion in 1755 the "pack" function of several scripting languages. 1757 The function VS encodes a variable-length octet string into a 1758 uniquely-decoded, self-delimited octet string, as in the following 1759 manner: 1761 VS(s) = VI(length(s)) | s 1763 where length(s) is a number of octets (not characters) in s. 1765 Some examples: 1767 VI(0) = "\000" (in C string notation) 1769 VI(100) = "d" 1771 VI(10000) = "\316\020" 1773 VI(1000000) = "\275\204@" 1775 VS("") = "\000" 1777 VS("Tea") = "\003Tea" 1779 VS("Caf" [in UTF-8]) = "\005Caf\303\251" 1781 VS([10000 "a"s]) = "\316\020aaaaa..." (10002 octets) 1783 (Note: Unlike the colon-separated notion used in the Basic/Digest 1784 HTTP authentication scheme, the string generated by a concatenation 1785 of the VS-encoded strings will be unique, regardless of the 1786 characters included in the strings to be encoded.) 1788 The function OCTETS converts an integer into the corresponding radix- 1789 256 big-endian octet string having its natural length. See 1790 Section 3.2.3 for the definition of "natural length". 1792 The function INT converts an octet string into a natural number, 1793 where the input string is treated as being in radix-256 big-endian 1794 notation. The identity INT(OCTETS(n)) = n always holds for any 1795 natural number n. 1797 12.2. Default Functions for Algorithms 1799 The functions defined in this section are common default functions 1800 among authentication algorithms. 1802 The client-side password-based (credential) pi used by this 1803 authentication is a natural number derived in the following manner: 1805 pi = INT(PBKDF2(HMAC_H, password, VS(algorithm) | VS(auth-scope) | 1806 VS(realm) | VS(username), nIterPi, hSize / 8)), 1808 where 1810 o PBKDF2 is the password-based key derivation function defined in 1811 [RFC2898], 1813 o HMAC_H is the HMAC function, defined in [RFC2104], composed from 1814 the hash function H, and 1816 o hSize is the output size of hash H in bits. 1818 The values of algorithm, realm, and auth-scope are taken from the 1819 values contained in the 401-INIT message. If the password comes from 1820 user input, it SHOULD first be prepared according to the method 1821 presented in Section 9. Then, the password SHALL be encoded as a 1822 UTF-8 string. 1824 The values VK_c and VK_s are derived by the following equation. 1826 VK_c = INT(H(octet(4) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | 1827 VI(nc) | VS(vh))) 1829 VK_s = INT(H(octet(3) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | 1830 VI(nc) | VS(vh))) 1832 13. Application Channel Binding 1834 Applications and upper-layer communication protocols may need 1835 authentication binding to the HTTP-layer authenticated user. Such 1836 applications MAY use the following values as a standard shared 1837 secret. 1839 These values are parameterized with an optional octet string (t) 1840 which may be arbitrarily chosen by each application or protocol. If 1841 there is no appropriate value to be specified, use an empty string 1842 for t. 1844 For applications requiring binding to either an authenticated user or 1845 a shared-key session (to ensure that the requesting client is 1846 certainly authenticated), the following value b_1 MAY be used. 1848 b_1 = H(H(octet(6) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(0) 1849 | VS(vh)) | VS(t)). 1851 For applications requiring binding to a specific request (to ensure 1852 that the payload data is generated for the exact HTTP request), the 1853 following value b_2 MAY be used. 1855 b_2 = H(H(octet(7) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(nc) 1856 | VS(vh)) | VS(t)). 1858 Note: Channel bindings to lower-layer transports (TCP and TLS) are 1859 defined in Section 7. 1861 14. Application for Proxy Authentication 1863 The authentication scheme defined by the previous sections can be 1864 applied (with modifications) for proxy authentication. In such 1865 cases, the following alterations MUST be applied: 1867 o The 407 status is to be sent and recognized in places where the 1868 401 status is used, 1870 o Proxy-Authenticate header is to be used in places where WWW- 1871 Authenticate is used, 1873 o Proxy-Authorization header is to be used in places where 1874 Authorization is used, 1876 o Proxy-Authentication-Info header is to be used in places where 1877 Authentication-Info is used, 1879 o The auth-scope parameter is fixed to the host-name of the proxy, 1880 which means it covers all requests processed through the specific 1881 proxy, 1883 o The limitation for the paths contained in the path parameter of 1884 401-KEX-S1 messages is disregarded, 1886 o The omission of the path parameter of 401-KEX-S1 messages means 1887 that the authentication realm will potentially cover all requests 1888 processed by the proxy, 1890 o The scheme, host name, and the port of the proxy is used for host 1891 validation tokens, and 1893 o Authentication extensions in [I-D.ietf-httpauth-extension] are not 1894 applicable. 1896 15. Methods to Extend This Protocol 1898 If a private extension to this protocol is implemented, it MUST use 1899 the extension-tokens defined in Section 3 to avoid conflicts with 1900 this protocol and other extensions. (Standardized or being- 1901 standardized extensions MAY use either bare-tokens or extension- 1902 tokens.) 1904 Specifications defining authentication algorithms MAY use other 1905 representations for the parameters "kc1", "ks1", "vkc", and "vks", 1906 replace those parameter names, and/or add parameters to the messages 1907 containing those parameters in supplemental specifications, provided 1908 that syntactic and semantic requirements in Section 3, [RFC7230] and 1909 [RFC7235] are satisfied. Any parameters starting with "kc", "ks", 1910 "vkc" or "vks" and followed by decimal natural numbers (e.g. kc2, 1911 ks0, vkc1, vks3 etc.) are reserved for this purpose. If those 1912 specifications use names other than those mentioned above, it is 1913 RECOMMENDED to use extension-tokens to avoid any parameter name 1914 conflict with future extensions to this protocol. 1916 Extension-tokens MAY be freely used for any non-standard, private, 1917 and/or experimental uses for those parameters provided that the 1918 domain part in the token is used in the manner defined in Section 3. 1920 16. IANA Considerations 1922 This document requires an additional entry to the "Hypertext Transfer 1923 Protocol (HTTP) Authentication Scheme Registry" as follows: 1925 o Authentication Scheme Name: "Mutual" 1927 o Pointer to specification text: (this document) 1929 When bare-tokens are used for the authentication-algorithm and 1930 validation parameters, these MUST be allocated by IANA. To acquire 1931 registered tokens, the usage of such tokens MUST be reviewed by a 1932 designated expert, as outlined in [RFC5226]. 1934 16.1. Registry for Authentication Algorithms 1936 This document establishes a registry for HTTP Mutual authentication 1937 algorithms. The registry manages case-insensitive ASCII strings. 1938 The strings MUST follow the extensive-token syntax defined in 1939 Section 3. 1941 Registrations for an authentication algorithm are required to include 1942 a description of the authentication algorithms. Reviewers assigned 1943 by IESG are advised to examine minimum security requirements and 1944 consistency of the key exchange algorithm descriptions. 1946 New registrations are advised to provide the following information: 1948 o Token: a token used in HTTP headers for identifying the algorithm. 1950 o Description: A brief description of the algorithm. 1952 o Specification: A reference for a specification defining the 1953 algorithm. 1955 The initial content of this registry is empty. [[Editorial Note: A 1956 separate document [I-D.ietf-httpauth-mutual-algo] will effectively 1957 define the initial content of the registry.]] 1959 16.2. Registry for Validation Methods 1961 This document establishes a registry for HTTP Mutual authentication 1962 host validation methods. The registry manages case-insensitive ASCII 1963 strings. The strings MUST follow the extensive-token syntax defined 1964 in Section 3. 1966 Registrations for a validation method are required to include a 1967 description of the validation method. Reviewers assigned by IESG are 1968 advised to examine its use-case requirements and security consequence 1969 of its introduction. 1971 New registrations are advised to provide the following information: 1973 o Token: a token used in HTTP headers for identifying the method. 1975 o Description: A brief description of the method. 1977 o Specification: A reference for a specification defining the 1978 method. 1980 The initial content of this registry is as follows: 1982 +----------------------+----------------------------+---------------+ 1983 | Token | Description | Specification | 1984 +----------------------+----------------------------+---------------+ 1985 | host | Host name verification | Section 7 | 1986 | | only | | 1987 | tls-server-end-point | TLS certificate-based | Section 7 | 1988 | tls-unique | TLS unique key-based | Section 7 | 1989 +----------------------+----------------------------+---------------+ 1991 17. Security Considerations 1993 17.1. Security Properties 1995 o The protocol is secure against passive eavesdropping and replay 1996 attacks. However, the protocol relies on transport security 1997 including DNS integrity for data secrecy and integrity. HTTP/TLS 1998 SHOULD be used where transport security is not assured and/or data 1999 confidentiality is important. 2001 o When used with HTTP/TLS, if TLS server certificates are reliably 2002 verified, the protocol provides true protection against active 2003 man-in-the-middle attacks. 2005 o Even if the server certificate is not used or is unreliable, the 2006 protocol provides protection against active man-in-the-middle 2007 attacks for each HTTP request/response pair. However, in such 2008 cases, JavaScript or similar scripting facilities can be used to 2009 affect the Mutually-authenticated contents from other contents not 2010 protected by this authentication mechanism. This is the reason 2011 why this protocol requires that valid TLS server certificates MUST 2012 be presented (Section 7). 2014 17.2. Secrecy of Credentials 2016 The client-side password credential MUST be kept secret all the time, 2017 and SHOULD NOT be used with any other (possibly insecure) 2018 authentication purpose. Loss of control of the credential will 2019 directly affect the control of corresponding server-side account. 2021 Use of client-side credential with THIS authentication scheme is 2022 always safe, even if the connected server peer is not trustful 2023 (condition of Phishing). However, if it is used with other 2024 authentication schemes (such as Web forms), and if the recipient is 2025 rogue, the result will be obvious. 2027 The server-side password credential (J) is also important to be kept 2028 secret. If it is stolen, and if the client's choice of password is 2029 not strong, the person aware of server-side password credential can 2030 employ a off-line dictionary attack to search for the client 2031 password. However, if the client has chosen a strong password, so 2032 that the attacker cannot guess the client's password from dictionary 2033 candidate, the client is still well protected from any attacks. 2035 The shared session secret (z) MUST be kept secret inside the server/ 2036 client software; if it is lost, and if the session is still active, 2037 it will lead to session hijacking. After the session is expired, the 2038 key is valueless for attackers. 2040 17.3. Denial-of-service Attacks to Servers 2042 The protocol requires a server-side table of active sessions, which 2043 may become a critical point for server resource consumption. For 2044 proper operation, the protocol requires that at least one key 2045 verification request is processed for each session identifier. After 2046 that, servers MAY discard sessions internally at any time, without 2047 causing any operational problems to clients. Clients will silently 2048 reestablish a new session then. 2050 However, if a malicious client sends too many requests for key 2051 exchanges (req-KEX-C1 messages) only, resource starvation might 2052 occur. In such critical situations, servers MAY discard any kind of 2053 existing sessions regardless of their statuses. One way to mitigate 2054 such attacks is that servers MAY have a number and a time limit for 2055 unverified, pending key exchange requests (in the "key exchanging" 2056 state). 2058 This is a common weakness of authentication protocols with almost any 2059 kind of negotiations or states, including Digest authentication 2060 scheme and most Cookie-based authentication implementations. 2061 However, regarding the resource consumption, the situation for the 2062 mutual authentication scheme is a slightly better than for Digest, 2063 because HTTP requests without any kind of authentication requests 2064 will not generate any kind of sessions. Session identifiers are only 2065 generated after a client starts a key negotiation. It means that 2066 simple clients such as Web crawlers will not accidentally consume 2067 server-side resources for session managements. 2069 17.3.1. On-line Active Password Attacks 2071 Although the protocol provides very strong protection against off- 2072 line dictionary attacks from eavesdropped traffic, the protocol, by 2073 its nature, cannot prevent active password attacks in which the 2074 attackers sends so many authentication trial requests for every 2075 possible password. 2077 Possible countermeasures for preventing such attacks may be rate- 2078 limiting of password authentication trials, statistics-based 2079 intrusion detection measures, or similar protection schemes. If the 2080 server operators assume that the passwords of users are not strong 2081 enough, it may be desirable to introduce such ad-hoc countermeasures. 2083 17.4. Communicating the status of mutual authentication with users 2085 This protocol is designed for two goals. The first goal is just 2086 providing a secure alternative for existing Basic and Digest 2087 authentication. The second goal is to provide users a way to detect 2088 forged rogue servers imitating a user's registered account on a 2089 server, commonly known as (a part or kind of) Phishing attacks. 2091 For this protocol to effectively work as some countermeasure to such 2092 attacks, it is very important that end users of clients be notified 2093 of the result of the mutual authentication performed by this 2094 protocol, especially the three states "AUTH-SUCCEED", 2095 "UNAUTHENTICATED", and "AUTH-REQUIRED" defined in Section 10. The 2096 design of secure user interfaces of the HTTP interactive clients is 2097 out of the scope of this document, but if possible, having some kind 2098 of UI indication for the three states above will be desirable for the 2099 user's security benefit. 2101 Of course, in such cases, the user interfaces for asking passwords 2102 for this authentication shall be clearly identifiable against 2103 imitation by other insecure password input fields (such as forms). 2104 If the passwords are known to malicious attackers outside of the 2105 protocol, the protocol cannot work as an effective security measures. 2107 17.5. Implementation Considerations 2109 o To securely implement the protocol, the Authentication-Info 2110 headers in the 200-VFY-S messages MUST always be validated by the 2111 client. If the validation fails, the client MUST NOT process any 2112 content sent with the message, including other headers and the 2113 body part. Non-compliance to this requirement will allow phishing 2114 attacks. 2116 o For HTTP/TLS communications, when a web form is submitted from 2117 Mutually-authenticated pages with the "tls-server-end-point" 2118 validation method to a URI that is protected by the same realm (so 2119 indicated by the path parameter), if the server certificate has 2120 been changed since the pages were received, the peer is 2121 RECOMMENDED to be re-validated using a req-KEX-C1 message with an 2122 "Expect: 100-continue" header. The same applies when the page is 2123 received with the "tls-unique" validation method, and when the TLS 2124 session has expired. 2126 o For better protection against possible password database stealing, 2127 server-side storage of user passwords should contain the values 2128 encrypted by the one-way function J(pi), instead of the real 2129 passwords or those hashed by pi. 2131 o If the TLS 1.2 is used for underlying HTTP/TLS communications, 2132 follow best practices in [RFC7525]. 2134 17.6. Usage Considerations 2136 o The user names inputted by a user may be sent automatically to any 2137 servers sharing the same auth-scope. This means that when a host- 2138 type auth-scope is used for authentication on an HTTPS site, and 2139 when an HTTP server on the same host requests Mutual 2140 authentication within the same realm, the client will send the 2141 user name in clear text. If user names have to be kept secret 2142 against eavesdropping, the server must use the full-scheme-type 2143 auth-scope parameter and HTTPS. Contrarily, passwords are not 2144 exposed to eavesdroppers even on HTTP requests. 2146 o If the server provides several ways for storing server-side 2147 password secrets in the password database, it is desirable for 2148 better security to store the values encrypted by using the one-way 2149 function J(pi), instead of the real passwords or those hashed by 2150 pi. 2152 18. References 2154 18.1. Normative References 2156 [I-D.ietf-httpauth-extension] 2157 Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 2158 T., and Y. Ioku, "HTTP Authentication Extensions for 2159 Interactive Clients", draft-ietf-httpauth-extension-09 2160 (work in progress), August 2016. 2162 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2163 Hashing for Message Authentication", RFC 2104, 2164 DOI 10.17487/RFC2104, February 1997, 2165 . 2167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2168 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 2169 RFC2119, March 1997, 2170 . 2172 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 2173 Specification Version 2.0", RFC 2898, DOI 10.17487/ 2174 RFC2898, September 2000, 2175 . 2177 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2178 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 2179 November 2003, . 2181 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2182 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2183 . 2185 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2186 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 2187 RFC5234, January 2008, 2188 . 2190 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2191 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 2192 RFC5246, August 2008, 2193 . 2195 [RFC5987] Reschke, J., "Character Set and Language Encoding for 2196 Hypertext Transfer Protocol (HTTP) Header Field 2197 Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010, 2198 . 2200 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2201 Protocol (HTTP/1.1): Message Syntax and Routing", 2202 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2203 . 2205 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2206 Protocol (HTTP/1.1): Authentication", RFC 7235, 2207 DOI 10.17487/RFC7235, June 2014, 2208 . 2210 [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, 2211 Enforcement, and Comparison of Internationalized Strings 2212 Representing Usernames and Passwords", RFC 7613, 2213 DOI 10.17487/RFC7613, August 2015, 2214 . 2216 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- 2217 Authentication-Info Response Header Fields", RFC 7615, 2218 DOI 10.17487/RFC7615, September 2015, 2219 . 2221 [Unicode] The Unicode Consortium, "The Unicode Standard", 2222 . 2224 18.2. Informative References 2226 [I-D.ietf-httpauth-mutual-algo] 2227 Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 2228 T., and Y. Ioku, "Mutual Authentication Protocol for HTTP: 2230 KAM3-based Cryptographic Algorithms", 2231 draft-ietf-httpauth-mutual-algo-07 (work in progress), 2232 November 2016. 2234 [ITU.X690.1994] 2235 International Telecommunications Union, "Information 2236 Technology - ASN.1 encoding rules: Specification of Basic 2237 Encoding Rules (BER), Canonical Encoding Rules (CER) and 2238 Distinguished Encoding Rules (DER)", ITU-T Recommendation 2239 X.690, 1994. 2241 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 2242 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 2243 . 2245 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 2246 RFC2818, May 2000, 2247 . 2249 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2250 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2251 DOI 10.17487/RFC5226, May 2008, 2252 . 2254 [RFC5890] Klensin, J., "Internationalized Domain Names for 2255 Applications (IDNA): Definitions and Document Framework", 2256 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2257 . 2259 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 2260 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 2261 . 2263 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2264 DOI 10.17487/RFC6265, April 2011, 2265 . 2267 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 2268 DOI 10.17487/RFC6454, December 2011, 2269 . 2271 [RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin- 2272 Bound Authentication (HOBA)", RFC 7486, DOI 10.17487/ 2273 RFC7486, March 2015, 2274 . 2276 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2277 "Recommendations for Secure Use of Transport Layer 2278 Security (TLS) and Datagram Transport Layer Security 2279 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, 2280 May 2015, . 2282 [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 2283 Preparation, Enforcement, and Comparison of 2284 Internationalized Strings in Application Protocols", 2285 RFC 7564, DOI 10.17487/RFC7564, May 2015, 2286 . 2288 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 2289 Digest Access Authentication", RFC 7616, DOI 10.17487/ 2290 RFC7616, September 2015, 2291 . 2293 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 2294 Langley, A., and M. Ray, "Transport Layer Security (TLS) 2295 Session Hash and Extended Master Secret Extension", 2296 RFC 7627, DOI 10.17487/RFC7627, September 2015, 2297 . 2299 Appendix A. (Informative) Draft Change Log 2301 [To be removed on final publication] 2303 A.1. Changes in Httpauth WG Revision 11 2305 o Reflecting IESG comments. 2307 A.2. Changes in Httpauth WG Revision 10 2309 o Small rephrasing and a typo fix. 2311 A.3. Changes in Httpauth WG Revision 09 2313 o Reflected AD review comments. 2315 o Authors' addresses updated. 2317 A.4. Changes in Httpauth WG Revision 08 2319 o Minor text update, in sync with httpauth-extension. 2321 o The version token is raised to "1". 2323 A.5. Changes in Httpauth WG Revision 07 2325 o Several comments from reviewers are reflected to the text. 2327 o The password-hash has been completely dropped. 2329 o The version token is raised to "1". 2331 A.6. Changes in Httpauth WG Revision 06 2333 o The auth-domain parameter has been renamed to auth-scope, 2334 following suggestions on the mailing list. 2336 o The digest-md5 password-hash has been dropped, as Digest with MD5 2337 hash is now obsoleted. 2339 A.7. Changes in Httpauth WG Revision 05 2341 o Minimum nonce number window has increased to 128. (HTTP 2.0 2342 recommends at least 100 concurrent sessions to exist) 2344 o Reference to TLS session hash extension added for tls-unique 2345 security issues. 2347 o Comments in the previous F2F meeting has been reflected to the 2348 text. 2350 A.8. Changes in Httpauth WG Revision 04 2352 o Merged httpauthprep proposal into general PRECIS Username/Password 2353 profile. 2355 o Adopting RFC 5987 extended syntax for non-ASCII parameter values. 2357 o Refer draft-ietf-httpbis-auth-info for Authentication-Info header. 2358 This results in a different syntax for that header. 2360 A.9. Changes in Httpauth WG Revision 03 2362 o Incompatible change: Single-port type authentication realm label 2363 has been changed to harmonize with Web Origin. (That is, the 2364 default ports (80 and 443) are to be omitted.) 2366 A.10. Changes in Httpauth WG Revision 02 2368 o Major change: introduction of password-strengthening function 2369 PBKDF2. 2371 o Changed Section 10 to adopt "list of requirements" style. Strict 2372 definition of state machine is now a derived, informational 2373 definition. 2375 A.11. Changes in Httpauth WG Revision 01 2377 o Changed "tls-key" verification to "tls-unique" verification, and 2378 "tls-cert" to "tls-server-end-point", adopting RFC 5929. 2380 o Adopted PRECIS framework [RFC7564]. 2382 o Reverted reservation of "rekey-sid" and "rekey-method" parameters. 2384 o Degraded secure UI requirement to application note level, non- 2385 normative. 2387 o Adjusted levels of several requirements. 2389 o Added warning text for handling of exceptional 5XX responses. 2391 o Dropped several references for optional authentications, except 2392 one "Note". 2394 o Several textual fixes, improvements and revisions. 2396 A.12. Changes in Httpauth Revision 00 2398 o Changed the version token. 2400 o Renamed "verification tokens" to "Host verification tokens" and 2401 variables "v" to "vh" for clarification. (Back-ported from 2402 draft-oiwa-httpauth-multihop-template-00) 2404 A.13. Changes in HttpBis Revision 00 2406 None. 2408 A.14. Changes in Revision 12 2410 o Added a reason "authz-failed". 2412 A.15. Changes in Revision 11 2414 o Message syntax definition reverted to pre-07 style as httpbis-p1 2415 and p7 now defines a precise rule for parameter value parsing. 2417 o Replaced "stale" parameter with more informative/extensive 2418 "reason" parameter in 401-INIT and 401-STALE. 2420 o Reserved "rekey-sid" and "rekey-method" parameters for future 2421 extensions. 2423 o Added descriptions for replacing/non-replacing existing 2424 technologies. 2426 A.16. Changes in Revision 10 2428 o The authentication extension parts (non-mandatory authentication 2429 and authentication controls) are separated to yet another draft. 2431 o The default auth-domain parameter is changed to the full scheme- 2432 host-port syntax, which is consistent with usual HTTP 2433 authentication framework behavior. 2435 o Provision for application channel binding is added. 2437 o Provision for proxy access authentication is added. 2439 o Bug fix: syntax specification of sid parameter was wrong: it was 2440 inconsistent with the type specified in the main text (the bug 2441 introduced in -07 draft). 2443 o Terminologies for headers are changed to be in harmony with 2444 httpbis drafts (e.g. field to parameter). 2446 o Syntax definitions are changed to use HTTP-extended ABNF syntax, 2447 and only the header values are shown for header syntax, in harmony 2448 with httpbis drafts. 2450 o Names of parameters and corresponding mathematical values are now 2451 renamed to more informative ones. The following list shows 2452 correspondence between the new and the old names. 2454 +------------+----------+-------------------------------------------+ 2455 | new name | old name | description | 2456 +------------+----------+-------------------------------------------+ 2457 | S_c1, S_s1 | s_a, s_b | client/server-side secret randoms | 2458 | K_c1, K_s1 | w_a, w_b | client/server-side exchanged key | 2459 | | | components | 2460 | kc1, ks1 | wa, wb | parameter names for those | 2461 | VK_c, VK_s | o_a, o_b | client/server-side key verifiers | 2462 | vkc, vks | oa, ob | parameter names for those | 2463 | z | z | session secrets | 2464 +------------+----------+-------------------------------------------+ 2466 A.17. Changes in Revision 09 2468 o The (default) cryptographic algorithms are separated to another 2469 draft. 2471 o Names of the messages are changed to more informative ones than 2472 before. The following is the correspondence table of those names: 2474 +-------------------+-----------------+-----------------------------+ 2475 | new name | old name | description | 2476 +-------------------+-----------------+-----------------------------+ 2477 | 401-INIT | 401-B0 | initial response | 2478 | 401-STALE | 401-B0-stale | session shared secret | 2479 | | | expired | 2480 | req-KEX-C1 | req-A1 | client->server key exchange | 2481 | 401-KEX-S1 | 401-B1 | server->client key exchange | 2482 | req-VFY-C | req-A3 | client->server auth. | 2483 | | | verification | 2484 | 200-VFY-S | 200-B4 | server->client auth. | 2485 | | | verification | 2486 | 200-Optional-INIT | 200-Optional-B0 | initial with non-mandatory | 2487 | | | authentication | 2488 +-------------------+-----------------+-----------------------------+ 2490 A.18. Changes in Revision 08 2492 o The English text has been revised. 2494 A.19. Changes in Revision 07 2496 o Adapt to httpbis HTTP/1.1 drafts: 2498 * Changed definition of extensive-token. 2500 * LWSP continuation-line (%0D.0A.20) deprecated. 2502 o To simplify the whole spec, the type of nonce-counter related 2503 parameters are change from hex-integer to integer. 2505 o Algorithm tokens are renamed to include names of hash algorithms. 2507 o Clarified the session management, added details of server-side 2508 protocol decisions. 2510 o The whole draft was reorganized; introduction and overview has 2511 been rewritten. 2513 A.20. Changes in Revision 06 2515 o Integrated Optional Mutual Authentication to the main part. 2517 o Clarified the decision procedure for message recognitions. 2519 o Clarified that a new authentication request for any sub-requests 2520 in interactive clients may be silently discarded. 2522 o Typos and confusing phrases are fixed. 2524 o Several "future considerations" are added. 2526 A.21. Changes in Revision 05 2528 o A new parameter called "version" is added for supporting future 2529 incompatible changes with a single implementation. In the (first) 2530 final specification its value will be changed to 1. 2532 o A new header "Authentication-Control" is added for precise control 2533 of application-level authentication behavior. 2535 A.22. Changes in Revision 04 2537 o Changed text of patent licenses: the phrase "once the protocol is 2538 accepted as an Internet standard" is removed so that the sentence 2539 also covers the draft versions of this protocol. 2541 o The "tls-key" verification is now OPTIONAL. 2543 o Several description fixes and clarifications. 2545 A.23. Changes in Revision 03 2547 o Wildcard domain specifications (e.g. "*.example.com") are allowed 2548 for auth-domain parameters (Section 4.1). 2550 o Specification of the tls-cert verification is updated 2551 (incompatible change). 2553 o State transitions fixed. 2555 o Requirements for servers concerning w_a values are clarified. 2557 o RFC references are updated. 2559 A.24. Changes in Revision 02 2561 o Auth-realm is extended to allow full-scheme type. 2563 o A decision diagram for clients and decision procedures for servers 2564 are added. 2566 o 401-B1 and req-A3 messages are changed to contain authentication 2567 realm information. 2569 o Bugs on equations for o_A and o_B are fixed. 2571 o Detailed equations for the entire algorithm are included. 2573 o Elliptic-curve algorithms are updated. 2575 o Several clarifications and other minor updates. 2577 A.25. Changes in Revision 01 2579 o Several texts are rewritten for clarification. 2581 o Added several security consideration clauses. 2583 Authors' Addresses 2585 Yutaka Oiwa 2586 National Institute of Advanced Industrial Science and Technology 2587 Information Technology Research Institute 2588 Tsukuba Central 1 2589 1-1-1 Umezono 2590 Tsukuba-shi, Ibaraki 2591 JP 2593 Email: y.oiwa@aist.go.jp 2595 Hajime Watanabe 2596 National Institute of Advanced Industrial Science and Technology 2597 Information Technology Research Institute 2598 Tsukuba Central 1 2599 1-1-1 Umezono 2600 Tsukuba-shi, Ibaraki 2601 JP 2603 Email: h-watanabe@aist.go.jp 2604 Hiromitsu Takagi 2605 National Institute of Advanced Industrial Science and Technology 2606 Information Technology Research Institute 2607 Tsukuba Central 1 2608 1-1-1 Umezono 2609 Tsukuba-shi, Ibaraki 2610 JP 2612 Email: takagi.hiromitsu@aist.go.jp 2614 Kaoru Maeda 2615 Lepidum Co. Ltd. 2616 Village Sasazuka 3, Suite #602 2617 1-30-3 Sasazuka 2618 Shibuya-ku, Tokyo 2619 JP 2621 Email: maeda@lepidum.co.jp 2623 Tatsuya Hayashi 2624 Lepidum Co. Ltd. 2625 Village Sasazuka 3, Suite #602 2626 1-30-3 Sasazuka 2627 Shibuya-ku, Tokyo 2628 JP 2630 Email: hayashi@lepidum.co.jp 2632 Yuichi Ioku 2633 Individual 2635 Email: mutual-work@ioku.org