idnits 2.17.1 draft-ietf-httpauth-mutual-08.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 (July 7, 2016) is 2822 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-httpauth-extension-07 ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5987 (Obsoleted by RFC 8187) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7613 (Obsoleted by RFC 8265) ** Obsolete normative reference: RFC 7615 (Obsoleted by RFC 9110) == Outdated reference: A later version (-07) exists of draft-ietf-httpauth-mutual-algo-05 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7564 (Obsoleted by RFC 8264) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: January 8, 2017 ITRI, AIST 6 K. Maeda 7 T. Hayashi 8 Lepidum 9 Y. Ioku 10 Individual 11 July 7, 2016 13 Mutual Authentication Protocol for HTTP 14 draft-ietf-httpauth-mutual-08 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 January 8, 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 . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Document Structure and Related Documents . . . . . . . . . 5 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Messages Overview . . . . . . . . . . . . . . . . . . . . 6 65 2.2. Typical Flows of the Protocol . . . . . . . . . . . . . . 6 66 2.3. Alternative Flows . . . . . . . . . . . . . . . . . . . . 9 67 3. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.1. Non-ASCII extended header parameters . . . . . . . . . . . 11 69 3.2. Values . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 3.2.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . 12 71 3.2.2. Strings . . . . . . . . . . . . . . . . . . . . . . . 13 72 3.2.3. Numbers . . . . . . . . . . . . . . . . . . . . . . . 13 73 4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.1. 401-INIT and 401-STALE . . . . . . . . . . . . . . . . . . 15 75 4.2. req-KEX-C1 . . . . . . . . . . . . . . . . . . . . . . . . 17 76 4.3. 401-KEX-S1 . . . . . . . . . . . . . . . . . . . . . . . . 17 77 4.4. req-VFY-C . . . . . . . . . . . . . . . . . . . . . . . . 18 78 4.5. 200-VFY-S . . . . . . . . . . . . . . . . . . . . . . . . 19 79 5. Authentication Realms . . . . . . . . . . . . . . . . . . . . 19 80 5.1. Resolving Ambiguities . . . . . . . . . . . . . . . . . . 21 81 6. Session Management . . . . . . . . . . . . . . . . . . . . . . 22 82 7. Host Validation Methods . . . . . . . . . . . . . . . . . . . 23 83 7.1. Applicability notes . . . . . . . . . . . . . . . . . . . 25 84 7.2. Notes on tls-unique . . . . . . . . . . . . . . . . . . . 25 85 8. Authentication Extensions . . . . . . . . . . . . . . . . . . 26 86 9. String Preparation . . . . . . . . . . . . . . . . . . . . . . 26 87 10. Decision Procedure for Clients . . . . . . . . . . . . . . . . 27 88 10.1. General Principles and Requirements . . . . . . . . . . . 27 89 10.2. State machine for the client (informative) . . . . . . . . 29 90 11. Decision Procedure for Servers . . . . . . . . . . . . . . . . 33 91 12. Authentication Algorithms . . . . . . . . . . . . . . . . . . 35 92 12.1. Support Functions and Notations . . . . . . . . . . . . . 36 93 12.2. Default Functions for Algorithms . . . . . . . . . . . . . 37 94 13. Application Channel Binding . . . . . . . . . . . . . . . . . 38 95 14. Application for Proxy Authentication . . . . . . . . . . . . . 39 96 15. Methods to Extend This Protocol . . . . . . . . . . . . . . . 40 97 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 98 16.1. Registry for Authentication Algorithms . . . . . . . . . . 40 99 16.2. Registry for Validation Methods . . . . . . . . . . . . . 41 100 17. Security Considerations . . . . . . . . . . . . . . . . . . . 41 101 17.1. Security Properties . . . . . . . . . . . . . . . . . . . 41 102 17.2. Denial-of-service Attacks to Servers . . . . . . . . . . . 42 103 17.2.1. On-line Active Password Attacks . . . . . . . . . . . 43 104 17.3. Communicating the status of mutual authentication with 105 users . . . . . . . . . . . . . . . . . . . . . . . . . . 43 106 17.4. Implementation Considerations . . . . . . . . . . . . . . 43 107 17.5. Usage Considerations . . . . . . . . . . . . . . . . . . . 44 108 18. Notice on Intellectual Properties . . . . . . . . . . . . . . 44 109 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 110 19.1. Normative References . . . . . . . . . . . . . . . . . . . 45 111 19.2. Informative References . . . . . . . . . . . . . . . . . . 46 112 Appendix A. (Informative) Draft Change Log . . . . . . . . . . . 47 113 A.1. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 48 114 A.2. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 48 115 A.3. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 48 116 A.4. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 48 117 A.5. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 48 118 A.6. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 48 119 A.7. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 49 120 A.8. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 49 121 A.9. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 49 122 A.10. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 49 123 A.11. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 49 124 A.12. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 50 125 A.13. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 50 126 A.14. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 51 127 A.15. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 51 128 A.16. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 51 129 A.17. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 52 130 A.18. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 52 131 A.19. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 52 132 A.20. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 52 133 A.21. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 53 134 A.22. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 53 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 137 1. Introduction 139 This document specifies a mutual authentication scheme for Hypertext 140 Transfer Protocol (HTTP). The scheme, called "Mutual Authentication 141 Protocol" in this document, provides true mutual authentication 142 between an HTTP client and an HTTP server, using just a simple 143 password as a credential. 145 The authentication scheme proposed in this document is a general 146 framework for using password-based authenticated key exchange (PAKE) 147 and similar stronger cryptographic primitives with HTTP. It has the 148 following main characteristics: 150 o It provides "true" mutual authentication: in addition to assuring 151 the server that the user knows the password, it also assures the 152 user that the server truly knows the user's encrypted password at 153 the same time. This makes it impossible for fake website owners 154 to persuade users that they have authenticated with the original 155 websites. 157 o It uses only passwords as the user's credential: unlike public- 158 key-based security algorithms, the scheme does not rely on secret 159 keys or other cryptographic data that have to be stored inside the 160 users' computers. The proposed scheme can be used as a drop-in 161 replacement to the current authentication schemes like Basic or 162 Digest, while ensuring a much stronger level of security. 164 o It is secure: when the server fails to authenticate with a user, 165 the protocol will not reveal the tiniest bit of information about 166 the user's password. 168 1.1. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in 173 [RFC2119]. 175 This document distinguishes the terms "client" and "user" in the 176 following way: A "client" is an entity understanding and talking HTTP 177 and the specified authentication protocol, usually computer software; 178 a "user" is a (usually natural) person who wants to access data 179 resources using a "client". 181 The term "natural numbers" refers to the non-negative integers 182 (including zero) throughout this document. 184 This document treats both the input (domain) and the output 185 (codomain) of hash functions to be octet strings. When a natural 186 number output is required, the notation INT(H(s)) is used. 188 1.2. Document Structure and Related Documents 190 The entire document is organized as follows: 192 o Section 2 presents an overview of the protocol design. 194 o Sections 3 to 11 define a general framework of the Mutual 195 authentication protocol. This framework is independent of 196 specific cryptographic primitives. 198 o Section 12 describes properties needed for cryptographic 199 algorithms used with this protocol framework, and defines a few 200 functions which will be shared among such cryptographic 201 algorithms. 203 o The sections after that contain general normative and informative 204 information about the protocol. 206 o The appendices contain some information that may help developers 207 to implement the protocol. 209 In addition, there are two companion documents which are referred 210 from/related to this specification: 212 o [I-D.ietf-httpauth-mutual-algo]: defines cryptographic primitives 213 which can be used with this protocol framework. 215 o [I-D.ietf-httpauth-extension]: defines small but useful extensions 216 to the current HTTP authentication framework so that it can 217 support application-level semantics of existing Web systems. 219 2. Protocol Overview 221 The protocol, as a whole, is designed as a natural extension to the 222 HTTP protocol [RFC7230] using a framework defined in [RFC7235]. 223 Internally, the server and the client will first perform a 224 cryptographic key exchange, using the secret password as a "tweak" to 225 the exchange. The key exchange will only succeed when the secrets 226 used by the both peers are correctly related (i.e., generated from 227 the same password). Then, both peers will verify the authentication 228 results by confirming the sharing of the exchanged key. This section 229 provides a brief outline of the protocol and the exchanged messages. 231 2.1. Messages Overview 233 The authentication protocol uses seven kinds of messages to perform 234 mutual authentication. These messages have specific names within 235 this specification. 237 o Authentication request messages: used by the servers to request 238 clients to start mutual authentication. 240 * 401-INIT message: a general message to start the authentication 241 protocol. It is also used as a message indicating an 242 authentication failure. 244 * 401-STALE message: a message indicating that client has to 245 start a new key exchange. 247 o Authenticated key exchange messages: used by both peers to perform 248 authentication and the sharing of a cryptographic secret. 250 * req-KEX-C1 message: a message sent from the client. 252 * 401-KEX-S1 message: a message sent from the server in response 253 to a req-KEX-C1 message. 255 o Authentication verification messages: used by both peers to verify 256 the authentication results. 258 * req-VFY-C message: a message used by the client, requesting the 259 server authenticate and authorize the client. 261 * 200-VFY-S message: a client-authentication successful response 262 used by the server, which also simultaneously asserts to the 263 client that the server is authentic. 265 In addition to the above, either a request or a response without any 266 HTTP headers related to this specification will be hereafter called a 267 "normal request" or a "normal response", respectively. 269 2.2. Typical Flows of the Protocol 271 In typical cases, the client access to a resource protected by the 272 Mutual authentication scheme will use the following protocol 273 sequence. 275 Client Server 276 | | 277 | ---- (1) normal request ---------> | 278 GET / HTTP/1.1 | 279 | | 280 | <---------------- (2) 401-INIT --- | 281 | 401 Authentication Required 282 | WWW-Authenticate: Mutual realm="a realm" 283 | | 284 [user, | | 285 pass]-->| | 286 | ---- (3) req-KEX-C1 -------------> | 287 GET / HTTP/1.1 | 288 Authorization: Mutual user="john", |--> [user DB] 289 kc1="...", ... |<-- [user info] 290 | | 291 | <-------------- (4) 401-KEX-S1 --- | 292 | 401 Authentication Required 293 | WWW-Authenticate: Mutual sid=..., ks1="...", ... 294 | | 295 [compute] (5) compute session secret [compute] 296 | | 297 | | 298 | ---- (6) req-VFY-C --------------> | 299 GET / HTTP/1.1 |--> [verify (6)] 300 Authorization: Mutual sid=..., |<-- OK 301 vkc="...", ... | 302 | | 303 | <--------------- (7) 200-VFY-S --- | 304 [verify | 200 OK | 305 (7)]<--| Authentication-Info: Mutual vks="..." 306 | | 307 v v 309 Figure 1: Typical communication flow for first access to resource 311 o As usual in general HTTP protocol designs, a client will at first 312 request a resource without any authentication attempt (1). If the 313 requested resource is protected by the Mutual authentication, the 314 server will respond with a message requesting authentication 315 (401-INIT) (2). 317 o The client processes the body of the message and waits for the 318 user to input the user name and a password. If the user name and 319 the password are available, the client will send a message with 320 the authenticated key exchange (req-KEX-C1) to start the 321 authentication (3). 323 o If the server has received a req-KEX-C1 message, the server looks 324 up the user's authentication information within its user database. 325 Then the server creates a new session identifier (sid) that will 326 be used to identify sets of the messages that follow it and 327 responds back with a message containing a server-side 328 authenticated key exchange value (401-KEX-S1) (4). 330 o At this point (5), both peers calculate a shared "session secret" 331 using the exchanged values in the key exchange messages. Only 332 when both the server and the client have used secret credentials 333 generated from the same password will the session secret values 334 match. This session secret will be used for access authentication 335 of every individual normal after this point. 337 o The client will send a request with a client-side authentication 338 verification value (req-VFY-C) (6), calculated from the client- 339 generated session secret. The server will check the validity of 340 the verification value using its own version of the session 341 secret. 343 o If the authentication verification value from the client was 344 correct, it means that the client definitely owns the credential 345 based on the expected password (i.e., the client authentication 346 succeeded). The server will respond with a successful message 347 (200-VFY-S) (7). Contrary to the usual one-way authentication 348 (e.g., HTTP Basic authentication or POP APOP authentication 349 [RFC1939]), this message also contains a server-side 350 authentication verification value. 352 When the client's verification value is incorrect (e.g., because 353 the user-supplied password was incorrect), the server will respond 354 with the 401-INIT message (the same one as used in (2)) instead. 356 o The client MUST first check the validity of the server-side 357 authentication verification value contained in the message (7). 358 If the value was equal to the expected one, server authentication 359 succeeded. 361 If it is not the value expected, or if the message does not 362 contain the authentication verification value, it means that the 363 mutual authentication has been broken for some unexpected reason. 364 The client MUST NOT process any body or header values contained in 365 the HTTP response in this case. (Note: This case should not 366 happen between a correctly implemented server and client without 367 any active attacks. The possible cause of such a case might be 368 either a man-in-the-middle attack or an incorrect implementation.) 370 2.3. Alternative Flows 372 As shown above, the typical flow for a first authentication request 373 requires three request-response pairs. To reduce the protocol 374 overhead, the protocol enables several short-cut flows which require 375 fewer messages. 377 o (case A) If the client knows that the resource is likely to 378 require authentication, the client MAY omit the first 379 unauthenticated request (1) and immediately send a key exchange 380 (req-KEX-C1 message). This will reduce one round-trip of 381 messages. 383 o (case B) If both the client and the server previously shared a 384 session secret associated with a valid session identifier (sid), 385 the client MAY directly send a req-VFY-C message using the 386 existing session identifier and corresponding session secret. 387 This will further reduce one round-trip of messages. 389 The server MAY have thrown out the corresponding session from the 390 session table. If so, the server will respond with a 401-STALE 391 message, indicating a new key exchange is required. The client 392 SHOULD retry constructing a req-KEX-C1 message in this case. 394 Figure 2 depicts the shortcut flows described above. Under the 395 appropriate settings and implementations, most of the requests to 396 resources are expected to meet both criteria, and thus only one 397 round-trip of request/response will be required. 399 (A) omit first request 400 (2 round trips) 402 Client Server 403 | | 404 | --- req-KEX-C1 ----> | 405 | | 406 | <---- 401-KEX-S1 --- | 407 | | 408 | ---- req-VFY-C ----> | 409 | | 410 | <----- 200-VFY-S --- | 411 | | 413 (B) reusing session secret (re-authentication) 415 (B-1) key available (B-2) key expired 416 (1 round trip) (3 round trips) 418 Client Server Client Server 419 | | | | 420 | ---- req-VFY-C ----> | | --- req-VFY-C -------> | 421 | | | | 422 | <----- 200-VFY-S --- | | <------- 401-STALE --- | 423 | | | | 424 | --- req-KEX-C1 ------> | 425 | | 426 | <------ 401-KEX-S1 --- | 427 | | 428 | --- req-VFY-C -------> | 429 | | 430 | <------- 200-VFY-S --- | 431 | | 433 Figure 2: Several alternative protocol flows 435 For more details, see Sections 10 and 11. 437 3. Message Syntax 439 Throughout this specification, the syntax is denoted in the extended 440 augmented BNF syntax defined in [RFC7230], and [RFC5234]. The 441 following elements are quoted from [RFC5234], [RFC7230] and 442 [RFC7235]: DIGIT, ALPHA, SP, auth-scheme, quoted-string, auth-param, 443 header-field, token, challenge, and credential. 445 The Mutual authentication protocol uses three headers: 446 WWW-Authenticate (usually in responses with status code 401), 447 Authorization (in requests), and Authentication-Info (in responses 448 other than 401 status). These headers follow a common framework 449 described in [RFC7235] and [RFC7615]. The detailed meanings for 450 these headers are contained in Section 4. 452 The framework in [RFC7235] defines the syntax for the headers 453 WWW-Authenticate and Authorization as the syntax elements "challenge" 454 and "credentials", respectively. The "auth-scheme" contained in 455 those headers MUST be "Mutual" throughout this protocol 456 specification. The syntax for "challenge" and "credentials" to be 457 used with the "Mutual" auth-scheme SHALL be name-value pairs (#auth- 458 param), not the "b64token" defined in [RFC7235]. 460 The Authentication-Info: header used in this protocol SHALL follow 461 the syntax defined in [RFC7615]. 463 In HTTP, the WWW-Authenticate header may contain two or more 464 challenges. Client implementations SHOULD be aware of and be capable 465 of handling those cases correctly. 467 3.1. Non-ASCII extended header parameters 469 All of parameters contained in the above three headers, except the 470 "realm" field, MAY be extended to ISO 10646-1 values using the 471 framework described in [RFC5987]. All servers and clients MUST be 472 capable of receiving and sending values encoded in [RFC5987] syntax. 474 If a value to be sent contains only ASCII characters, the field MUST 475 be sent using plain RFC 7235 syntax. The syntax as extended by RFC 476 5987 MUST NOT be used in this case. 478 If a value (except the "realm" header) contains one or more non-ASCII 479 characters, the parameter SHOULD be sent using the syntax defined in 480 Section 3.2 of [RFC5987] as "ext-parameter". Such a parameter MUST 481 have a charset value of "UTF-8", and the language value MUST always 482 be omitted (have an empty value). The same parameter MUST NOT be 483 sent more than once, regardless of the used syntax. 485 For example, a parameter "user" with value "Renee of France" SHOULD 486 be sent as < user="Renee of France" >. If the value is 487 "Rene of France", it SHOULD be sent as < user*=UTF- 488 8''Ren%C3%89e%20of%20France > instead. 490 [RFC7235] requires the realm parameter to be in its plain form (not 491 as an extended "realm*" parameter), so RFC 5987 syntax MUST NOT be 492 used for this parameter. 494 3.2. Values 496 The parameter values contained in challenge/credentials MUST be 497 parsed strictly conforming to the HTTP semantics (especially un- 498 quoting of the string parameter values). In this protocol, those 499 values are further categorized into the following value types: tokens 500 (bare-token and extensive-token), string, integer, hex-fixed-number, 501 and base64-fixed-number. 503 For clarity, implementations are RECOMMENDED to use the canonical 504 representations specified in the following subsections for sending 505 values. Recipients SHOULD accept both quoted and unquoted 506 representations interchangeably as specified in HTTP. 508 3.2.1. Tokens 510 For sustaining both security and extensibility at the same time, this 511 protocol defines a stricter sub-syntax for the "token" to be used. 512 Extensive-token values SHOULD use the following syntax (after HTTP 513 value parsing): 515 bare-token = 1*(DIGIT / ALPHA / "-" / "_") 516 extension-token = "-" bare-token 1*("." bare-token) 517 extensive-token = bare-token / extension-token 519 Figure 3: BNF syntax for token values 521 The tokens (bare-token and extension-token) are case insensitive; 522 Senders SHOULD send these in lower case, and receivers MUST accept 523 both upper and lower cases. When tokens are used as (partial) inputs 524 to any hash or other mathematical functions, they MUST always be used 525 in lower case. 527 Extensive-tokens are used in this protocol where the set of 528 acceptable tokens may include non-standard extensions. Any extension 529 of this protocol MAY use either the bare-tokens allocated by IANA 530 (under the procedure described in Section 16), or extension-tokens 531 with the format "-.", where is 532 a valid (sub-)domain name on the Internet owned by the party who 533 defines the extension. 535 Bare-tokens and extensive-tokens are also used for parameter names, 536 in the unquoted form. Requirements for using the extension-token for 537 the parameter names are the same as the previous paragraph. 539 The canonical format for bare-tokens and extensive-tokens is the 540 unquoted representation. 542 3.2.2. Strings 544 All character strings MUST be encoded to octet strings using the 545 UTF-8 encoding [RFC3629] for the ISO 10646-1 character set 546 [ISO.10646-1.1993]. Such strings MUST NOT contain any leading BOM 547 characters (ZERO WIDTH NO-BREAK SPACE, U+FEFF or EF BB BF). Both 548 peers are RECOMMENDED to reject any invalid UTF-8 sequences that 549 might cause decoding ambiguities (e.g., containing <"> in the second 550 or later bytes of the UTF-8 encoded characters). 552 If strings are representing a domain name or URI that contains non- 553 ASCII characters, the host parts SHOULD be encoded as it is used in 554 the HTTP protocol layer (e.g., in a Host: header); under current 555 standards it will be the one defined in [RFC5890]. It SHOULD use 556 lower-case ASCII characters. 558 The canonical format for strings is quoted-string (as it may contain 559 equal signs, plus signs and slashes), unless the parameter containing 560 the string value will use extended syntax defined in [RFC5987]. (An 561 [RFC5987] extended parameter will have an unquoted encoded value, as 562 defined therein.) 564 3.2.3. Numbers 566 The following syntax definitions give a syntax for numeric values: 568 integer = "0" / (%x31-39 *DIGIT) ; no leading zeros 569 hex-fixed-number = 1*(2(DIGIT / %x41-46 / %x61-66)) 570 base64-fixed-number = 1*( ALPHA / DIGIT / "+" / "/" ) 0*2"=" 572 Figure 4: BNF syntax for numbers 574 The syntax definition of the integers only allows representations 575 that do not contain leading zeros. 577 A number represented as a hex-fixed-number MUST include an even 578 number of hexadecimal digits (i.e., multiples of eight bits). Those 579 values are case-insensitive, and SHOULD be sent in lower case. When 580 these values are generated from any cryptographic values, they SHOULD 581 have their "natural length"; if these are generated from a hash 582 function, these lengths SHOULD correspond to the hash size; if these 583 are representing elements of a mathematical set (or group), its 584 lengths SHOULD be the shortest for representing all the elements in 585 the set. For example, the results of the SHA-256 hash function will 586 be represented by 64 digits, and any elements in a 2048-bit prime 587 field (modulo a 2048-bit integer) will be represented by 512 digits, 588 regardless of how much zeros appear in front of such representations. 589 Session-identifiers and other non-cryptographically generated values 590 are represented in any (even) length determined by the side that 591 generates it first, and the same length SHALL be used throughout all 592 communications by both peers. 594 The numbers represented as base64-fixed-number SHALL be generated as 595 follows: first, the number is converted to a big-endian radix-256 596 binary representation as an octet string. The length of the 597 representation is determined in the same way as mentioned above. 598 Then, the string is encoded using the Base 64 encoding [RFC4648] 599 without any spaces and newlines. Implementations decoding base64- 600 fixed-number SHOULD reject any input data with invalid characters, 601 excess/insufficient padding, or non-canonical pad bits (See Sections 602 3.1 to 3.5 of [RFC4648]). 604 The canonical format for integer and hex-fixed-number are unquoted 605 tokens, and that for base64-fixed-number is quoted-string. 607 4. Messages 609 In this section we define the seven kinds of messages used in the 610 authentication protocol along with the formats and requirements of 611 the headers for each message. 613 To determine in what circumstances each message is expected to be 614 sent, see Sections 10 and 11. 616 In the descriptions below, the type of allowable values for each 617 header parameter is shown in parenthesis after each parameter name. 618 The "algorithm-determined" type means that the acceptable value for 619 the parameter is one of the types defined in Section 3, and is 620 determined by the value of the "algorithm" parameter. The parameters 621 marked "mandatory" SHALL be contained in the message. The parameters 622 marked "non-mandatory" MAY either be contained or omitted in the 623 message. Each parameter SHALL appear in each header exactly once at 624 most. 626 All credentials and challenges MAY contain any parameters not 627 explicitly specified in the following sections. Recipients that do 628 not understand such parameters MUST silently ignore those. However, 629 all credentials and challenges MUST meet the following criteria: 631 o For responses, the parameters "reason", any "ks#" (where # stands 632 for any decimal integer), and "vks" are mutually exclusive; any 633 challenge MUST NOT contain two or more parameters among them. 634 They MUST NOT contain any "kc#" or "vkc" parameters. 636 o For requests, the parameters "kc#" (where # stands for any decimal 637 integer), and "vkc" are mutually exclusive and any challenge 638 MUST NOT contain two or more parameters among them. They MUST NOT 639 contain any "ks#" or "vks" parameters. 641 Every message in this section contains a "version" field, to detect 642 future, incompatible revisions of the protocol. Implementations of 643 the protocol described in this specification MUST always send a token 644 "1", and recipients MUST reject messages that contain any other value 645 as a version, unless another specification defines a behavior for 646 that version. 648 4.1. 401-INIT and 401-STALE 650 Every 401-INIT or 401-STALE message SHALL be a valid HTTP 401-status 651 (Authentication Required) message (or other 4XX status if sensible) 652 containing one and only one (hereafter not explicitly noted) 653 "WWW-Authenticate" header containing a "reason" parameter in the 654 challenge. The challenge SHALL contain all of the parameters marked 655 "mandatory" below, and MAY contain those marked "non-mandatory". 657 version: (mandatory extensive-token) should be the token "1". 659 algorithm: (mandatory extensive-token) specifies the 660 authentication algorithm to be used. The value MUST 661 be one of the tokens specified in 662 [I-D.ietf-httpauth-mutual-algo] or another 663 supplemental specification. 665 validation: (mandatory extensive-token) specifies the method of 666 host validation. The value MUST be one of the tokens 667 described in Section 7 or the tokens specified in 668 another supplemental specification. 670 auth-scope: (non-mandatory string) specifies the authentication 671 scope, the set of hosts for which the authentication 672 credentials are valid. It MUST be one of the strings 673 described in Section 5. If the value is omitted, it 674 is assumed to be the "single-server" type domain in 675 Section 5. 677 realm: (mandatory string) is a string representing the name 678 of the authentication realm inside the authentication 679 scope. As specified in [RFC7235], this value MUST 680 always be sent in the quoted-string form, and an 681 [RFC5987] encoding MUST NOT be used. 682 The realm value sent from the server SHOULD be an 683 ASCII string. Clients MAY treat any non-ASCII value 684 received in this field as a binary blob, an NFC- 685 normalized UTF-8 string, or an error. 687 reason: (mandatory extensive-token) SHALL be an extensive- 688 token that describes the possible reason of the failed 689 authentication/authorization. Both servers and 690 clients SHALL understand and support the following 691 three tokens: 693 * initial: authentication was not tried because there 694 was no Authorization header in the corresponding 695 request. 697 * stale-session: the provided sid in the request was 698 either unknown to or expired in the server. 700 * auth-failed: authentication trial was failed for 701 some reason, possibly with a bad authentication 702 credential. 704 Implementations MAY support the following tokens or 705 any extensive-tokens defined outside this 706 specification. If clients receive any unknown tokens, 707 they SHOULD treat these as if they were "auth-failed" 708 or "initial". 710 * reauth-needed: the server-side application requires 711 a new authentication trial, regardless of the 712 current status. 714 * invalid-parameters: the server did not attempt 715 authentication because some parameters were not 716 acceptable. 718 * internal-error: the server did not attempt 719 authentication because there are some troubles on 720 the server-side. 722 * user-unknown: this is a special case of auth- 723 failed, suggesting that the provided user name is 724 invalid. The use of this parameter is 725 NOT RECOMMENDED due to security implications, 726 except for special-purpose applications where it 727 makes sense. 729 * invalid-credential: ditto, suggesting that the 730 provided user name was valid but authentication 731 still failed. The use of this parameter is 732 NOT RECOMMENDED for security reasons. 734 * authz-failed: authentication was successful, but 735 access to the specified resource is not authorized 736 to the specific authenticated user. (It might be 737 used along with either a 401 or 403 status to 738 indicate that the authentication result is one of 739 the existing reasons for the failed authorization.) 741 The algorithm specified in this header will determine the types 742 (among those defined in Section 3) and the values for K_c1, K_s1, 743 VK_c and VK_s. 745 Among these messages, those with the reason parameter of value 746 "stale-session" will be called "401-STALE" messages hereafter, 747 because these have a special meaning in the protocol flow. Messages 748 with any other reason parameters will be called "401-INIT" messages. 750 4.2. req-KEX-C1 752 Every req-KEX-C1 message SHALL be a valid HTTP request message 753 containing an "Authorization" header with a credential containing a 754 "kc1" parameter. 756 The credential SHALL contain the parameters with the following names: 758 version: (mandatory, extensive-token) should be the token "1". 760 algorithm, validation, auth-scope, realm: MUST be the same values as 761 received from the server. 763 user: (mandatory, string) is the UTF-8 encoded name of the 764 user. The string SHOULD be prepared according to the 765 method presented in Section 9. 767 kc1: (mandatory, algorithm-determined) is the client-side 768 key exchange value K_c1, which is specified by the 769 algorithm that is used. 771 4.3. 401-KEX-S1 773 Every 401-KEX-S1 message SHALL be a valid HTTP 401-status 774 (Authentication Required) response message containing a 775 "WWW-Authenticate" header with a challenge containing a "ks1" 776 parameter. 778 The challenge SHALL contain the parameters with the following names: 780 version: (mandatory, extensive-token) should be the token "1". 782 algorithm, validation, auth-scope, realm: MUST be the same values as 783 received from the client. 785 sid: (mandatory, hex-fixed-number) MUST be a session 786 identifier, which is a random integer. The sid SHOULD 787 have uniqueness of at least 80 bits or the square of 788 the maximum estimated transactions concurrently 789 available in the session table, whichever is larger. 790 See Section 6 for more details. 792 ks1: (mandatory, algorithm-determined) is the server-side 793 key exchange value K_s1, which is specified by the 794 algorithm. 796 nc-max: (mandatory, integer) is the maximum value of nonce 797 numbers that the server accepts. 799 nc-window: (mandatory, integer) the number of available nonce 800 number slots that the server will accept. The value 801 of the nc-window parameter is RECOMMENDED to be 128 or 802 more. 804 time: (mandatory, integer) represents the suggested time (in 805 seconds) that the client can reuse the session 806 represented by the sid. It is RECOMMENDED to be at 807 least 60. The value of this parameter is not directly 808 linked to the duration that the server keeps track for 809 the session represented by the sid. 811 path: (non-mandatory, string) specifies which path in the 812 URI space the same authentication is expected to be 813 applied. The value is a space-separated list of URIs, 814 in the same format as it was specified in domain 815 parameter [RFC7616] for Digest authentications. All 816 path elements contained in the parameter MUST be 817 inside the specified auth-scope; if not, clients 818 SHOULD ignore such elements. For better performance, 819 recognition of this parameter by clients is important. 821 4.4. req-VFY-C 823 Every req-VFY-C message SHALL be a valid HTTP request message 824 containing an "Authorization" header with a credential containing a 825 "vkc" parameter. 827 The parameters contained in the header are as follows: 829 version: (mandatory, extensive-token) should be the token "1". 831 algorithm, validation, auth-scope, realm: MUST be the same values as 832 received from the server for the session. 834 sid: (mandatory, hex-fixed-number) MUST be one of the sid 835 values that was received from the server for the same 836 authentication realm. 838 nc: (mandatory, integer) is a nonce request number that is 839 unique among the requests sharing the same sid. The 840 values of the nonce numbers SHOULD satisfy the 841 properties outlined in Section 6. 843 vkc: (mandatory, algorithm-determined) is the client-side 844 authentication verification value VK_c, which is 845 specified by the algorithm. 847 4.5. 200-VFY-S 849 Every 200-VFY-S message SHALL be a valid HTTP message that does not 850 have a 401 (Authentication Required) status code and SHALL contain an 851 "Authentication-Info" header with a "vks" parameter. 853 The parameters contained in the header are as follows: 855 version: (mandatory, extensive-token) should be the token "1". 857 sid: (mandatory, hex-fixed-number) MUST be the value 858 received from the client. 860 vks: (mandatory, algorithm-determined) is the server-side 861 authentication verification value VK_s, which is 862 specified by the algorithm. 864 The header MUST be sent before the content body: it MUST NOT be sent 865 in the trailer of a chunked-encoded response. If a "100 Continue" 866 response is sent from the server, the Authentication-Info header 867 SHOULD be included in that response, instead of the final response. 869 5. Authentication Realms 871 In this protocol, an "authentication realm" is defined as a set of 872 resources (URIs) for which the same set of user names and passwords 873 is valid. If the server requests authentication for an 874 authentication realm that the client is already authenticated for, 875 the client will automatically perform the authentication using the 876 already-known credentials. However, for different authentication 877 realms, clients MUST NOT automatically reuse user names and passwords 878 for another realm. 880 Just like in the Basic and Digest access authentication protocols, 881 the Mutual authentication protocol supports multiple, separate 882 protection spaces to be set up inside each host. Furthermore, the 883 protocol allows a single authentication realm to span over several 884 hosts within the same Internet domain. 886 Each authentication realm is defined and distinguished by the triple 887 of an "authentication algorithm", an "authentication scope", and a 888 "realm" parameter. However, server operators are NOT RECOMMENDED to 889 use the same pair of an authentication scope and a realm with 890 different authentication algorithms. 892 The realm parameter is a string as defined in Section 4. 893 Authentication scopes are described in the remainder of this section. 895 An authentication scope specifies the range of hosts that the 896 authentication realm spans over. In this protocol, it MUST be one of 897 the following kinds of strings. 899 o Single-server type: A string in the format "://" or 900 "://:", where , , and are 901 the corresponding URI parts of the request URI. If the default 902 port (i.e., 80 for http and 443 for https) is used for the 903 underlying HTTP communications, the port part MUST be omitted, 904 regardless of whether it was present in the request-URI. In all 905 other cases, the port part MUST be present, and it MUST NOT 906 contain leading zeros. Use this format when authentication is 907 only valid for a specific protocol (such as https). This format 908 is equivalent to the ASCII serialization of a Web Origin, 909 presented in Section 6.2 of [RFC6454]. 911 o Single-host type: The "host" part of the requested URI. This is 912 the default value. Authentication realms within this kind of 913 authentication scope will span over several protocols (e.g., http 914 and https) and ports, but not over different hosts. 916 o Wildcard-domain type: A string in the format "*.", 917 where is either the host part of the requested 918 URI or any domain in which the requested host is included (this 919 means that the specification "*.example.com" is valid for all of 920 hosts "www.example.com", "web.example.com", 921 "www.sales.example.com" and "example.com"). The domain-postfix 922 sent by the servers MUST be equal to or included in a valid 923 Internet domain assigned to a specific organization; if clients 924 know, by some means such as a blacklist for HTTP cookies 925 [RFC6265], that the specified domain is not to be assigned to any 926 specific organization (e.g., "*.com" or "*.jp"), clients are 927 RECOMMENDED to reject the authentication request. 929 In the above specifications, every "scheme", "host", and "domain" 930 MUST be in lower case, and any internationalized domain names beyond 931 the ASCII character set SHALL be represented in the way they are sent 932 in the underlying HTTP protocol, represented in lower case 933 characters, i.e., these domain names SHALL be in the form of LDH 934 labels in IDNA [RFC5890]. A "port" MUST be given in the shortest, 935 unsigned, decimal number notation. Not obeying these requirements 936 will cause failure of valid authentication attempts. 938 5.1. Resolving Ambiguities 940 In the above definitions of authentication scopes, several scopes may 941 overlap each other. If a client has already been authenticated to 942 several realms applicable to the same server, the client may have a 943 multiple lists of the "path" parameters received with the 944 "401-KEX-S1" message (see Section 4). If these path lists have any 945 overlap, a single URI may belong to multiple possible candidate of 946 realms to be authenticated to. In such cases, clients faces an 947 ambiguity in deciding which credentials to send for a new request (in 948 steps 3 and 4 of the decision procedure presented in Section 10). 950 In such cases, a client MAY send request which belong to any of these 951 candidate realms freely, or it MAY simply send an unauthenticated 952 request and see for which realm the server requests an 953 authentication. Server operators are RECOMMENDED to provide 954 properly-configured "path" parameters (more precisely, disjoint path 955 sets for each realms) for clients so that such ambiguities will not 956 occur. 958 The following procedure is one possible tactic for resolving 959 ambiguity in such cases. 961 o If the client has previously sent a request to the same URI, and 962 if it remembers the authentication realm requested by the 401-INIT 963 message at that time, use that realm. 965 o In other cases, use one of the authentication realms representing 966 the most-specific authentication scopes. The list of possible 967 domain specifications shown above is given from most specific to 968 least specific. 970 If there are several choices with different wildcard-domain 971 specifications, the one that has the longest domain-postfix has 972 priority over ones with shorter domain-postfixes. 974 o If there are realms with the same authentication scope, there is 975 no defined priority; the client MAY choose any one of the possible 976 choices. 978 6. Session Management 980 In the Mutual authentication protocol, a session represented by an 981 sid is set up using four messages (first request, 401-INIT, 982 req-KEX-C1 and 401-KEX-S1), after which a "session secret" (z) 983 associated with the session is established. After mutually 984 establishing a session secret, this session, along with the secret, 985 can be used for one or more requests for resources protected by the 986 same realm on the same server. Note that session management is only 987 an inside detail of the protocol and usually not visible to normal 988 users. If a session expires, the client and server SHOULD 989 automatically re-establish another session without informing the 990 user. 992 Sessions and session identifiers are local to each server (defined by 993 scheme, host, and port), even if an authentication scope covers 994 multiple servers; clients MUST establish separate sessions for each 995 port of a host to be accessed. Furthermore, sessions and identifiers 996 are also local to each authentication realm, even if these are 997 provided by the same server. The same session identifiers provided 998 either from different servers or for different realms MUST be treated 999 as independent or each other. 1001 The server SHOULD accept at least one req-VFY-C request for each 1002 session, if the request reaches the server in a time window specified 1003 by the timeout parameter in the 401-KEX-S1 message, and there are no 1004 emergent reasons (such as flooding attacks) to forget the session. 1005 After that, the server MAY discard any session at any time and MAY 1006 send 401-STALE messages for any further req-VFY-C requests received 1007 for that session. 1009 The client MAY send two or more requests using a single session 1010 specified by the sid. However, for all such requests, each value of 1011 the nonce number (in the nc parameter) MUST satisfy the following 1012 conditions: 1014 o It is a natural number. 1016 o The same nonce number was not sent within the same session. 1018 o It is not larger than the nc-max value that was sent from the 1019 server in the session represented by the sid. 1021 o It is larger than (largest-nc - nc-window), where largest-nc is 1022 the largest value of nc which was previously sent in the session, 1023 and nc-window is the value of the nc-window parameter that was 1024 received from the server for the session. 1026 The last condition allows servers to reject any nonce numbers that 1027 are "significantly" smaller than the "current" value (defined by the 1028 value of nc-window) of the nonce number used in the session involved. 1029 In other words, servers MAY treat such nonce numbers as "already 1030 received". This restriction enables servers to implement duplicate 1031 nonce detection in a constant amount of memory for each session. 1033 Servers MUST check for duplication of the received nonce numbers, and 1034 if any duplication is detected, the server MUST discard the session 1035 and respond with a 401-STALE message, as outlined in Section 11. The 1036 server MAY also reject other invalid nonce numbers (such as ones 1037 above the nc-max limit) by sending a 401-STALE message. 1039 For example, assume the nc-window value of the current session is 1040 128, nc-max is 400, and that the client has already used the 1041 following nonce numbers: {1-120, 122, 124, 130-238, 255-360, 363- 1042 372}. Then the nonce number that can be used for the next request is 1043 one of the following set: {245-254, 361, 362, 373-400}. The values 1044 {0, 121, 123, 125-129, 239-244} MAY be rejected by the server because 1045 they are not above the current "window limit" (244 = 372 - 128). 1047 Typically, clients can ensure the above property by using a 1048 monotonically-increasing integer counter that counts from zero up to 1049 the value of nc-max. 1051 The values of the nonce numbers and any nonce-related values MUST 1052 always be treated as natural numbers within an infinite range. 1053 Implementations which uses fixed-width integer representations, 1054 fixed-precision floating-point numbers, or similar representations 1055 SHOULD NOT reject any larger values which overflow such 1056 representative limits, and MUST NOT silently truncate them using any 1057 modulus-like rounding operation (e.g., by mod 2^32). Instead, the 1058 whole protocol is carefully designed so that recipients MAY replace 1059 any such overflowing values (e.g. 2^80) with some reasonably-large 1060 maximum representative integer (e.g., 2^31 - 1 or others). 1062 7. Host Validation Methods 1064 The "validation method" specifies a method to "relate" (or "bind") 1065 the mutual authentication processed by this protocol with other 1066 authentications already performed in the underlying layers and to 1067 prevent man-in-the-middle attacks. It determines the value vh that 1068 is an input to the authentication protocols. 1070 When HTTPS or other possible secure transport is used, this 1071 corresponds to the idea of "channel binding" described in [RFC5929]. 1072 Even when HTTP is used, similar, but somewhat limited, "binding" is 1073 performed to prevent a malicious server from trying to authenticate 1074 itself to another server as a valid user by forwarding the received 1075 credentials. 1077 The valid tokens for the validation parameter and corresponding 1078 values of vh are as follows: 1080 host: host-name validation: The value vh will be the ASCII 1081 string in the following format: 1082 "://:", where , , 1083 and are the URI components corresponding to the 1084 currently accessing resource. The scheme and host are 1085 in lower case, and the port is in a shortest decimal 1086 representation. Even if the request-URI does not have 1087 a port part, v will include the default port number. 1089 tls-server-end-point: TLS endpoint (certificate) validation: The 1090 value vh will be the octet string of the hash value of 1091 the server's public key certificate used in the 1092 underlying TLS [RFC5246] connection, processed as 1093 specified in Section 4.1 of [RFC5929]. 1095 tls-unique: TLS shared-key validation: The value vh will be the 1096 channel binding material derived from the Finished 1097 messages, as defined in Section 3.1 of [RFC5929]. 1098 (Note: see Section 7.2 for some security notices when 1099 using this validation method.) 1101 If HTTP is used on a non-encrypted channel (TCP and SCTP, for 1102 example), the validation type MUST be "host". If HTTP/TLS [RFC2818] 1103 (HTTPS) is used with a server certificate, the validation type MUST 1104 be "tls-server-end-point". If HTTP/TLS is used with an anonymous 1105 Diffie-Hellman key exchange, the validation type MUST be "tls-unique" 1106 (see the note below). 1108 Implementations supporting Mutual authentication over HTTPS SHOULD 1109 support the "tls-server-end-point" validation. Support for 1110 "tls-unique" validation is OPTIONAL for both servers and clients. 1112 If the validation type "tls-server-end-point" is used, the server 1113 certificate provided in the TLS connection MUST be verified at least 1114 to make sure that the server actually owns the corresponding private 1115 key. (Note: this verification is automatic in some RSA-based key 1116 exchanges but NOT automatic in Diffie-Hellman-based key exchanges 1117 with separate exchange for server verification.) 1119 Clients MUST validate this parameter upon receipt of 401-INIT 1120 messages. 1122 Note: The protocol defines two variants of validation on the TLS 1123 connections. The "tls-unique" method is more secure. However, there 1124 are some situations where tls-server-end-point is more preferable. 1126 o When TLS accelerating proxies are used, it is difficult for the 1127 authenticating server to acquire the TLS key information that is 1128 used between the client and the proxy. This is not the case for 1129 client-side "tunneling" proxies using the HTTP CONNECT method. 1131 o When a black-box implementation of the TLS protocol is used on 1132 either peer. 1134 7.1. Applicability notes 1136 When the client is a Web browser with any scripting capabilities, the 1137 underlying TLS channel used with HTTP/TLS MUST provide server 1138 identity verification. This means (1) anonymous Diffie-Hellman key 1139 exchange cipher suites MUST NOT be used, and (2) verification of the 1140 server certificate provided by the server MUST be performed. 1142 For other systems, when the underlying TLS channel used with HTTP/TLS 1143 does not perform server identity verification, the client SHOULD 1144 ensure that all the responses are validated using the Mutual 1145 authentication protocol, regardless of the existence of 401-INIT 1146 responses. 1148 7.2. Notes on tls-unique 1150 As described in the interoperability note in the above channel 1151 binding specification, the tls-unique verification value will be 1152 changed by possible TLS renegotiation, causing an interoperability 1153 problem. TLS re-negotiations are used in several HTTPS server 1154 implementations for enforcing some security properties (such as 1155 cryptographic strength) for some specific responses. 1157 If an implementation supports the "tls-unique" verification method, 1158 the following caution SHOULD be taken: 1160 o Both peers must be aware that the vh values used for vkc (in 1161 req-VFY-C) and for vks (in 200-VFY-S) may be different. These 1162 values MUST be retrieved from underlying TLS libraries each time 1163 they are used. 1165 o After calculating the values vh and vkc to send a req-VFY-C 1166 request, Clients SHOULD NOT initiate TLS renegotiation until the 1167 end of the corresponding response header is received. An 1168 exception is that clients can and SHOULD perform TLS re- 1169 negotiation as a response to the server's request for TLS 1170 renegotiation, before receipt of the beginning of the response 1171 header. 1173 Also, implementers MUST take care of session resumption attacks 1174 regarding tls-unique channel binding mechanisms and master secrets. 1175 As a mitigation, a TLS extension defined in [RFC7627] SHOULD be used 1176 when tls-unique host verification is to be used. 1178 8. Authentication Extensions 1180 Interactive clients (e.g., Web browsers) supporting this protocol are 1181 RECOMMENDED to support non-mandatory authentication and the 1182 Authentication-Control header defined in 1183 [I-D.ietf-httpauth-extension], except for the "auth-style" parameter. 1184 This specification also proposes (however, does not mandate) the 1185 default "auth-style" be "non-modal". Web applications SHOULD however 1186 consider the security impacts of the behaviors of clients that do not 1187 support these headers. 1189 Authentication-initializing messages with the 1190 Optional-WWW-Authenticate header are used only where the 401-INIT 1191 response is valid. It will not replace other 401-type messages such 1192 as 401-STALE and 401-KEX-S1. 1194 9. String Preparation 1196 It is important for interoperability that user names and passwords 1197 used in this protocol are binary-comparable regardless of the user's 1198 input methods and/or environments. To ensure this, the following 1199 preparation SHOULD be performed: 1201 o User names received from users SHOULD be prepared using the 1202 "UsernameCasePreserved" profile defined in Section 3.3 of 1203 [RFC7613]. 1205 o Passwords received from users SHOULD be prepared using the 1206 "OpaqueString" profile defined in Section 4.2 of [RFC7613]. 1208 In both cases, it is the sender's duty to correctly prepare the 1209 character strings. If any non-normalized character string is 1210 received from the other peer of the communication, recipients MAY 1211 either use it as a bare UTF-8 string without any preparation, perform 1212 any appropriate preparations (which may cause authentication 1213 failure), or reject any ill-prepared inputs from the sender and 1214 respond as a communication error. 1216 Server applications SHOULD also prepare user names and passwords 1217 accordingly upon registration of user credentials. 1219 In addition, binary-based "interfaces" of implementations MAY require 1220 and assume that the string is already prepared accordingly; when a 1221 string is already stored as a binary Unicode string form, 1222 implementations MAY omit preparation and Unicode normalization 1223 (performing UTF-8 encoding only) before using it. When a string is 1224 already stored as an octet blob, implementations MAY send it as is. 1226 10. Decision Procedure for Clients 1228 10.1. General Principles and Requirements 1230 To securely implement the protocol, the client must be careful about 1231 accepting the authenticated responses from the server. This also 1232 holds true for the reception of "normal responses" (responses which 1233 do not contain Mutual authentication-related headers) from HTTP 1234 servers. 1236 As usual in the HTTP authentication, a single user-level request may 1237 result in exchange of two-or-more HTTP requests and responses in 1238 sequence. The following normative rules MUST be followed by the 1239 clients implementing this protocol: 1241 o Any kinds of "normal responses" MUST only be accepted for the very 1242 first request in the sequence. Any "normal responses" returned 1243 for the second or later requests in the sequence SHALL be 1244 considered invalid. 1246 o In the same principle, any responses which refer to or request 1247 changing to an authentication realm different from the client's 1248 request MUST only be accepted for the very first request in the 1249 sequence. Any kind of responses referring to different realms 1250 which are returned for the second or later requests in the 1251 sequence SHALL be considered invalid. 1253 o A req-KEX-C1 message MAY be sent either as a initial request or as 1254 a response to 401-INIT or 401-STALE. However, it SHOULD NOT be 1255 sent more than once in the sequence for a single authentication 1256 realm, to avoid infinite loops of messages. A 401-KEX-S1 response 1257 MUST be accepted only when the corresponding request is 1258 req-KEX-C1. 1260 o A req-VFY-C message MAY be sent if there is a valid session key 1261 shared between the client and the server, established by 1262 req-KEX-C1 and 401-KEX-S1. If any response with 401 status is 1263 returned for such a message, the corresponding session key SHOULD 1264 be discarded as unusable. 1265 Especially, upon the reception of a 401-STALE response, the client 1266 SHOULD try establishing a new session by sending req-KEX-C1, but 1267 only once within the request/response sequence. 1269 o A 200-VFY-S message MUST be accepted only as a response to 1270 req-VFY-C and nothing else. The VK_s values of such response 1271 messages MUST always be checked against the correct value, and if 1272 it is incorrect, the whole response SHOULD be considered invalid. 1274 The final status of the client request following the message exchange 1275 sequence shall be determined as follows: 1277 o AUTH-SUCCEED: A 200-VFY-S message with the correct VK_s value was 1278 returned in response to the req-VFY-C request in the sequence. 1280 o AUTH-REQUIRED: Two cases exists. 1282 * A 401-INIT message was returned from the server, and the client 1283 does not know how to authenticate to the given authentication 1284 realm. 1286 * A 401-INIT response was returned for req-VFY-C (or req-KEX-C1), 1287 which means the user-supplied authentication credentials were 1288 not accepted. 1290 o UNAUTHENTICATED: a normal response is returned for an initial 1291 request of any kind in the sequence. 1293 Any kind of response (including a normal response) other than those 1294 explicitly allowed in the above rules SHOULD be interpreted as a 1295 fatal communication error. In such cases, the clients MUST NOT 1296 process any data (the response body and other content-related 1297 headers) sent from the server. However, to handle exceptional error 1298 cases, clients MAY accept a message without an Authentication-Info 1299 header, if it has a Server-Error (5xx) status code. In such cases, 1300 they SHOULD be careful about processing the body of the content 1301 (ignoring it is still RECOMMENDED, as it may possibly be forged by 1302 intermediate attackers), and the client will be in the 1303 "UNAUTHENTICATED" status then. 1305 If a request is a sub-request for a resource included in another 1306 resource (e.g., embedded images, style sheets, frames etc.), clients 1307 MAY treat an AUTH-REQUESTED status as the same as an UNAUTHENTICATED 1308 status. In other words, the client MAY ignore server's request to 1309 start authentication with new credentials via sub-requests. 1311 10.2. State machine for the client (informative) 1313 The following state machine describes the possible request-response 1314 sequences derived from the above normative rules. If implementers 1315 are not quite sure on the security consequences of the above rules, 1316 it is strongly advised to follow the decision procedure below. In 1317 particular, clients SHOULD NOT accept "normal responses" unless 1318 explicitly allowed in the rules. The labels on the steps are for 1319 informational purposes only. Action entries within each step are 1320 checked in top-to-bottom order, and the first clause satisfied is to 1321 be followed. 1323 Step 1 (step_new_request): 1324 If the client software needs to access a new Web resource, check 1325 whether the resource is expected to be inside some authentication 1326 realm for which the user has already been authenticated by the 1327 Mutual authentication scheme. If yes, go to Step 2. Otherwise, 1328 go to Step 5. 1330 Step 2: 1331 Check whether there is an available sid for the expected 1332 authentication realm. If there is one, go to Step 3. Otherwise, 1333 go to Step 4. 1335 Step 3 (step_send_vfy_1): 1336 Send a req-VFY-C request. 1338 * If you receive a 401-INIT message with a different 1339 authentication realm than expected, go to Step 6. 1341 * If a 401-STALE message is received, go to Step 9. 1343 * If a 401-INIT message is received, go to Step 13. 1345 * If a 200-VFY-S message is received, go to Step 14. 1347 * If a normal response is received, go to Step 11. 1349 Step 4 (step_send_kex1_1): 1350 Send a req-KEX-C1 request. 1352 * If a 401-INIT message is received with a different 1353 authentication realm than expected, go to Step 6. 1355 * If a 401-KEX-S1 message is received, go to Step 10. 1357 * If a 401-INIT message is received with the same authentication 1358 realm, go to Step 13 (see Note 1). 1360 * If a normal response is received, go to Step 11. 1362 Step 5 (step_send_normal_1): 1363 Send a request without any Mutual authentication headers. 1365 * If a 401-INIT message is received, go to Step 6. 1367 * If a normal response is received, go to Step 11. 1369 Step 6 (step_rcvd_init): 1370 Check whether the user's password for the requested 1371 authentication realm is known. If yes, go to Step 7. Otherwise, 1372 go to Step 12. 1374 Step 7: 1375 Check whether there is an available sid for the expected 1376 authentication realm. If there is one, go to Step 8. Otherwise, 1377 go to Step 9. 1379 Step 8 (step_send_vfy): 1380 Send a req-VFY-C request. 1382 * If a 401-STALE message is received, go to Step 9. 1384 * If a 401-INIT message is received, go to Step 13. 1386 * If a 200-VFY-S message is received, go to Step 14. 1388 Step 9 (step_send_kex1): 1389 Send a req-KEX-C1 request. 1391 * If a 401-KEX-S1 message is received, go to Step 10. 1393 * If a 401-INIT message is received, go to Step 13 (See Note 1). 1395 Step 10 (step_rcvd_kex1): 1396 Send a req-VFY-C request. 1398 * If a 401-INIT message is received, go to Step 13. 1400 * If a 200-VFY-S message is received, go to Step 14. 1402 Step 11 (step_rcvd_normal): 1403 The requested resource is out of the authenticated area. The 1404 client will be in the "UNAUTHENTICATED" status. If the response 1405 contains a request for authentications other than Mutual, it MAY 1406 be handled normally. 1408 Step 12 (step_rcvd_init_unknown): 1409 The requested resource requires Mutual authentication, and the 1410 user is not yet authenticated. The client will be in the "AUTH- 1411 REQUESTED" status, and is RECOMMENDED to process the content sent 1412 from the server, and to ask the user for a user name and a 1413 password. When those are supplied from the user, proceed to Step 1414 9. 1416 Step 13 (step_rcvd_init_failed): 1417 For some reason the authentication failed: possibly the password 1418 or the username is invalid for the authenticated resource. 1419 Forget the user-provided credentials for the authentication realm 1420 and go to Step 12. 1422 Step 14 (step_rcvd_vfy): 1423 The received message is the 200-VFY-S message, which always 1424 contains a vks field. Check the validity of the received VK_s 1425 value. If it is equal to the expected value, it means that the 1426 mutual authentication has succeeded. The client will be in the 1427 "AUTH-SUCCEEDED" status. 1429 If the value is unexpected, it is a fatal communication error. 1431 If a user explicitly requests to log out (via the user 1432 interface), the client MUST forget the user's password, go to 1433 step 5, and reload the current resource without an authentication 1434 header. 1436 Note 1: These transitions MAY be accepted by clients, but are 1437 NOT RECOMMENDED for servers to initiate. 1439 Figure 5 shows an informative diagram of the client state. 1441 =========== -(11)------------ 1442 NEW REQUEST ( UNAUTHENTICATED ) 1443 =========== ----------------- 1444 | ^ normal 1445 v | response 1446 +(1)-------------------+ NO +(5)----------+ 1447 | The requested URI |--------------------------->| send normal | 1448 | known to be auth'ed? | | request | 1449 +----------------------+ +-------------+ 1450 YES | 401-INIT 401-INIT| 1451 | with a different realm | 1452 | -----------------------------------. | 1453 | / v v 1454 | | -(12)------------ NO +(6)--------+ 1455 | | ( AUTH-REQUESTED )<------| user/pass | 1456 | | ----------------- | known? | 1457 | | +-----------+ 1458 | | |YES 1459 v | v 1460 +(2)--------+ | +(7)--------+ 1461 | session | | | session | NO 1462 NO /| available?| | | available?|\ 1463 / +-----------+ | +-----------+ | 1464 / |YES | |YES | 1465 | | /| | | 1466 | v / | 401- 401- v | 1467 | +(3)--------+ | INIT --(13)---------- INIT +(8)--------+ | 1468 | | send |--+----->/ AUTH-REQUESTED \<-------| send | | 1469 | /| req-VFY-C | | \forget password / | req-VFY-C | | 1470 \/ +-----------+ / ---------------- /+-----------+ | 1471 /\ \ \/ ^ 401-INIT | |401- | 1472 | ------ \/\ 401-STALE | | | STALE / 1473 | \ /\ -----------------+--------------+---. | / 1474 | | / \ | | | | / 1475 | v / | 401- | 401- | v v v 1476 | +(4)--------+ | KEX-S1 +(10)-------+ KEX-S1 | +(9)--------+ 1477 | | send |-|--------->| send |<-------+-| send | 1478 | --| req-KEX-C1| | | req-VFY-C | | | req-KEX-C1| 1479 |/ +-----------+ | +-----------+ | +-----------+ 1480 | |200-VFY-S | 200-VFY-S| ^ 1481 |normal | |200-VFY-S / | 1482 |response | v / ================== 1483 v \ -(14)--------- / USER/PASS INPUTTED 1484 -(11)------------ ------->( AUTH-SUCCEED )<-- ================== 1485 ( UNAUTHENTICATED ) -------------- 1486 ----------------- 1488 Figure 5: State diagram for clients 1490 11. Decision Procedure for Servers 1492 Each server SHOULD have a table of session states. This table need 1493 not be persistent over the long term; it MAY be cleared upon server 1494 restart, reboot, or for other reasons. Each entry in the table 1495 SHOULD contain at least the following information: 1497 o The session identifier, which is the value of the sid parameter. 1499 o The algorithm used. 1501 o The authentication realm. 1503 o The state of the protocol: one of "key exchanging", 1504 "authenticated", "rejected", or "inactive". 1506 o The user name received from the client. 1508 o A boolean flag representing whether or not the session is fake. 1510 o When the state is "key exchanging", the values of K_c1 and S_s1. 1512 o When the state is "authenticated", the following information: 1514 * The value of the session secret, z 1516 * The largest nc received from the client (largest-nc) 1518 * For each possible nc values between (largest-nc - nc- 1519 window + 1) and max_nc, a boolean flag whether or not a request 1520 with the corresponding nc has been received. 1522 The table MAY contain other information. 1524 Servers SHOULD respond to the client requests according to the 1525 following procedure: (See Note 1 below for 401-INIT message with a 1526 plus sign) 1528 o When the server receives a normal request: 1530 * If the requested resource is not protected by the Mutual 1531 authentication, send a normal response. 1533 * If the resource is protected by the Mutual authentication, send 1534 a 401-INIT response. 1536 o When the server receives a req-KEX-C1 request: 1538 * If the requested resource is not protected by the Mutual 1539 authentication, send a normal response. 1541 * If the authentication realm specified in the req-KEX-C1 request 1542 is not the expected one, send a 401-INIT response. 1544 * If the server cannot validate the parameter kc1, send a 1545 401-INIT (+) response. 1547 * If the received user name is either invalid, unknown or 1548 unacceptable, create a new session, mark it a "fake" session, 1549 compute a random value as K_s1, and send a fake 401-KEX-S1 1550 response. (See Note 2.) 1552 * Otherwise, create a new session, compute K_s1 and send a 1553 401-KEX-S1 response. The created session is marked as not 1554 fake, and its largest-nc is initialized to zero. 1556 The created session has the "key exchanging" state. 1558 o When the server receives a req-VFY-C request: 1560 * If the requested resource is not protected by the Mutual 1561 authentication, send a normal response. 1563 * If the authentication realm specified in the req-VFY-C request 1564 is not the expected one, send a 401-INIT response. 1566 If none of above holds true, the server will look up the session 1567 corresponding to the received sid and the authentication realm. 1569 * If the session corresponding to the received sid could not be 1570 found, or it is in the "inactive" state, send a 401-STALE 1571 response. 1573 * If the session is in the "rejected" state, send either a 1574 401-INIT (+) or a 401-STALE message. 1576 * If the nc value in the request is larger than the nc-max 1577 parameter sent from the server, or if it is not larger then 1578 (largest-nc - nc-window) (when in "authenticated" status), the 1579 server MAY (but is not REQUIRED to; See Note 3) send a 1580 401-STALE message. The session SHOULD be changed to the 1581 "inactive" state if so. 1583 * If the session is in the "authenticated" state, and the request 1584 has an nc value that was previously received from the client, 1585 send a 401-STALE message. The session SHOULD be changed to the 1586 "inactive" state. 1588 * If the session is a "fake" session, or if the received vkc is 1589 incorrect, then send a 401-INIT (+) response. If the session 1590 is in the "key exchanging" state, it SHOULD be changed to the 1591 "rejected" state; otherwise, it MAY either be changed to the 1592 "rejected" state or kept in the previous state. 1594 * Otherwise, send a 200-VFY-S response. If the session was in 1595 the "key exchanging" state, the session SHOULD be changed to an 1596 "authenticated" state. The maximum nc and nc flags of the 1597 state SHOULD be updated appropriate. 1599 At any time, the server MAY change any state entries with both the 1600 "rejected" and "authenticated" states to the "inactive" status, and 1601 MAY discard any "inactive" states from the table. Entries with the 1602 "key exchanging" state SHOULD be kept unless there is an emergency 1603 situation such as a server reboot or a table capacity overflow. 1605 Note 1: In relation with and following the specification of the 1606 optional authentication defined in [I-D.ietf-httpauth-extension], the 1607 401-INIT messages marked with the pluses cannot be replaced with a 1608 successful responses with an Optional-WWW-Authenticate header. Every 1609 other 401-INIT can be a response with an Optional-WWW-Authenticate. 1611 Note 2: the server SHOULD NOT send a 401-INIT response in this case, 1612 because it will leak the information to the client that the specified 1613 user name will not be accepted. Instead, postpone it to the response 1614 for the next req-VFY-C request. 1616 Note 3: The next case implies that, when the request is not rejected 1617 under this clause, the server MUST be decidable whether the same nc 1618 value was previously received from the client. If the server does 1619 not remember a whole history of the nc values received from the 1620 client, the server MUST send a 401-STALE message in this clause. 1622 12. Authentication Algorithms 1624 Cryptographic authentication algorithms which are used with this 1625 protocol will be defined separately. The algorithm definition MUST 1626 at least provide definitions for the following functions: 1628 o The server-side authentication credential J, derived from client- 1629 side authentication credential pi. 1631 o Key exchange values K_c1, K_s1 (exchanged on wire) and S_c1, S_s1 1632 (kept secret in each peer). 1634 o Shared secret z, to be computed by both server and client. 1636 o A hash function H to be used with the protocol, along with its 1637 output size hSize. 1639 o The number of iterations for password hashing nIterPi, if it uses 1640 the default password hashing function defined below. 1642 Specifications for cryptographic algorithms used with this framework 1643 MUST specify whether these will use the default functions defined 1644 below for values pi, VK_c, and VK_s; or, these will define their own 1645 versions for these. 1647 All algorithm used with this protocol SHOULD provide secure mutual 1648 authentication between client and servers, and generate a 1649 cryptographically strong shared secret value z, equivalently strong 1650 to or stronger than the hash function H. If any passwords (or pass- 1651 phrases or any equivalents, i.e., weak secrets) are involved, these 1652 SHOULD NOT be guessable from any data transmitted in the protocol, 1653 even if an attacker (either an eavesdropper or an active server) 1654 knows the possible thoroughly-searchable candidate list of the 1655 passwords. Furthermore, if possible, the function J for deriving 1656 server-side authentication credential J(pi) is RECOMMENDED to be one- 1657 way so that pi should not be easily computed from J(pi). 1659 12.1. Support Functions and Notations 1661 In this section we define several support functions and notations to 1662 be shared by several algorithm definitions. 1664 The integers in the specification are in decimal, or in hexadecimal 1665 when prefixed with "0x". 1667 The function octet(i) generates an octet string containing a single 1668 octet of value i. The operator |, when applied to octet strings, 1669 denotes the concatenation of two operands. 1671 The function VI encodes natural numbers into octet strings in the 1672 following manner: numbers are represented as big-endian radix-128 1673 strings, where each digit is represented by an octet within the range 1674 0x80-0xff except the last digit, which is represented by a octet 1675 within the range 0x00-0x7f. The first octet MUST NOT be 0x80. For 1676 example, VI(i) = octet(i) for i < 128, and VI(i) = octet(0x80 + (i >> 1677 7)) | octet(i & 127) for 128 <= i < 16384. This encoding is the same 1678 as the one used for the sub-components of object identifiers in the 1679 ASN.1 encoding [ITU.X690.1994], and available as a "w" conversion in 1680 the "pack" function of several scripting languages. 1682 The function VS encodes a variable-length octet string into a 1683 uniquely-decoded, self-delimited octet string, as in the following 1684 manner: 1686 VS(s) = VI(length(s)) | s 1688 where length(s) is a number of octets (not characters) in s. 1690 Some examples: 1692 VI(0) = "\000" (in C string notation) 1694 VI(100) = "d" 1696 VI(10000) = "\316\020" 1698 VI(1000000) = "\275\204@" 1700 VS("") = "\000" 1702 VS("Tea") = "\003Tea" 1704 VS("Caf" [in UTF-8]) = "\005Caf\303\251" 1706 VS([10000 "a"s]) = "\316\020aaaaa..." (10002 octets) 1708 (Note: Unlike the colon-separated notion used in the Basic/Digest 1709 HTTP authentication scheme, the string generated by a concatenation 1710 of the VS-encoded strings will be unique, regardless of the 1711 characters included in the strings to be encoded.) 1713 The function OCTETS converts an integer into the corresponding radix- 1714 256 big-endian octet string having its natural length. See 1715 Section 3.2.3 for the definition of "natural length". 1717 The function INT converts an octet string into a natural number, 1718 where the input string is treated as being in radix-256 big-endian 1719 notation. The identity INT(OCTETS(n)) = n always holds for any 1720 natural number n. 1722 12.2. Default Functions for Algorithms 1724 The functions defined in this section are common default functions 1725 among authentication algorithms. 1727 The client-side password-based (credential) pi used by this 1728 authentication is a natural number derived in the following manner: 1730 pi = INT(PBKDF2(HMAC_H, password, VS(algorithm) | VS(auth-scope) | 1731 VS(realm) | VS(username), nIterPi, hSize / 8)), 1733 where 1735 o PBKDF2 is the password-based key derivation function defined in 1736 [RFC2898], 1738 o HMAC_H is the HMAC function, defined in [RFC2104], composed from 1739 the hash function H, and 1741 o hSize is the output size of hash H in bits. 1743 The values of algorithm, realm, and auth-scope are taken from the 1744 values contained in the 401-INIT message. If the password comes from 1745 user input, it SHOULD first be prepared according to the method 1746 presented in Section 9. Then, the password SHALL be encoded as a 1747 UTF-8 string. 1749 The values VK_c and VK_s are derived by the following equation. 1751 VK_c = INT(H(octet(4) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | 1752 VI(nc) | VS(vh))) 1754 VK_s = INT(H(octet(3) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | 1755 VI(nc) | VS(vh))) 1757 13. Application Channel Binding 1759 Applications and upper-layer communication protocols may need 1760 authentication binding to the HTTP-layer authenticated user. Such 1761 applications MAY use the following values as a standard shared 1762 secret. 1764 These values are parameterized with an optional octet string (t) 1765 which may be arbitrarily chosen by each application or protocol. If 1766 there is no appropriate value to be specified, use an empty string 1767 for t. 1769 For applications requiring binding to either an authenticated user or 1770 a shared-key session (to ensure that the requesting client is 1771 certainly authenticated), the following value b_1 MAY be used. 1773 b_1 = H(H(octet(6) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(0) 1774 | VS(vh)) | VS(t)). 1776 For applications requiring binding to a specific request (to ensure 1777 that the payload data is generated for the exact HTTP request), the 1778 following value b_2 MAY be used. 1780 b_2 = H(H(octet(7) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(nc) 1781 | VS(vh)) | VS(t)). 1783 Note: Channel bindings to lower-layer transports (TCP and TLS) are 1784 defined in Section 7. 1786 14. Application for Proxy Authentication 1788 The authentication scheme defined by the previous sections can be 1789 applied (with modifications) for proxy authentication. In such 1790 cases, the following alterations MUST be applied: 1792 o The 407 status is to be sent and recognized in places where the 1793 401 status is used, 1795 o Proxy-Authenticate header is to be used in places where WWW- 1796 Authenticate is used, 1798 o Proxy-Authorization header is to be used in places where 1799 Authorization is used, 1801 o Proxy-Authentication-Info header is to be used in places where 1802 Authentication-Info is used, 1804 o The auth-scope parameter is fixed to the host-name of the proxy, 1805 which means it covers all requests processed through the specific 1806 proxy, 1808 o The limitation for the paths contained in the path parameter of 1809 401-KEX-S1 messages is disregarded, 1811 o The omission of the path parameter of 401-KEX-S1 messages means 1812 that the authentication realm will potentially cover all requests 1813 processed by the proxy, 1815 o The scheme, host name, and the port of the proxy is used for host 1816 validation tokens, and 1818 o Authentication extensions in [I-D.ietf-httpauth-extension] are not 1819 applicable. 1821 15. Methods to Extend This Protocol 1823 If a private extension to this protocol is implemented, it MUST use 1824 the extension-tokens defined in Section 3 to avoid conflicts with 1825 this protocol and other extensions. (Standardized or being- 1826 standardized extensions MAY use either bare-tokens or extension- 1827 tokens.) 1829 Specifications defining authentication algorithms MAY use other 1830 representations for the parameters "kc1", "ks1", "vkc", and "vks", 1831 replace those parameter names, and/or add parameters to the messages 1832 containing those parameters in supplemental specifications, provided 1833 that syntactic and semantic requirements in Section 3, [RFC7230] and 1834 [RFC7235] are satisfied. Any parameters starting with "kc", "ks", 1835 "vkc" or "vks" and followed by decimal natural numbers (e.g. kc2, 1836 ks0, vkc1, vks3 etc.) are reserved for this purpose. If those 1837 specifications use names other than those mentioned above, it is 1838 RECOMMENDED to use extension-tokens to avoid any parameter name 1839 conflict with future extensions to this protocol. 1841 Extension-tokens MAY be freely used for any non-standard, private, 1842 and/or experimental uses for those parameters provided that the 1843 domain part in the token is used in the manner defined in Section 3. 1845 16. IANA Considerations 1847 When bare-tokens are used for the authentication-algorithm, pwd-hash, 1848 and validation parameters, these MUST be allocated by IANA. To 1849 acquire registered tokens, a specification for the use of such tokens 1850 MUST be reviewed by a designated expert, as outlined in [RFC5226]. 1852 16.1. Registry for Authentication Algorithms 1854 This document establishes a registry for HTTP Mutual authentication 1855 algorithms. The registry manages case-insensitive ASCII strings. 1856 The strings MUST follow the extensive-token syntax defined in 1857 Section 3. 1859 Registrations for an authentication algorithm are required to include 1860 a description of the authentication algorithms. Reviewers assigned 1861 by IESG are advised to examine minimum security requirements and 1862 consistency of the key exchange algorithm descriptions. 1864 New registrations are advised to provide the following information: 1866 o Token: a token used in HTTP headers for identifying the algorithm. 1868 o Description: A brief description of the algorithm. 1870 o Specification: A reference for a specification defining the 1871 algorithm. 1873 The initial content of this registry is empty. [[Editorial Note: A 1874 separate document [I-D.ietf-httpauth-mutual-algo] will effectively 1875 define the initial content of the registry.]] 1877 16.2. Registry for Validation Methods 1879 This document establishes a registry for HTTP Mutual authentication 1880 host validation methods. The registry manages case-insensitive ASCII 1881 strings. The strings MUST follow the extensive-token syntax defined 1882 in Section 3. 1884 Registrations for a validation method are required to include a 1885 description of the validation method. Reviewers assigned by IESG are 1886 advised to examine its use-case requirements and security consequence 1887 of its introduction. 1889 New registrations are advised to provide the following information: 1891 o Token: a token used in HTTP headers for identifying the method. 1893 o Description: A brief description of the method. 1895 o Specification: A reference for a specification defining the 1896 method. 1898 The initial content of this registry is as follows: 1900 +----------------------+----------------------------+---------------+ 1901 | Token | Description | Specification | 1902 +----------------------+----------------------------+---------------+ 1903 | host | Host name verification | Section 7 | 1904 | | only | | 1905 | tls-server-end-point | TLS certificate-based | Section 7 | 1906 | tls-unique | TLS unique key-based | Section 7 | 1907 +----------------------+----------------------------+---------------+ 1909 17. Security Considerations 1911 17.1. Security Properties 1912 o The protocol is secure against passive eavesdropping and replay 1913 attacks. However, the protocol relies on transport security 1914 including DNS integrity for data secrecy and integrity. HTTP/TLS 1915 SHOULD be used where transport security is not assured and/or data 1916 confidentiality is important. 1918 o When used with HTTP/TLS, if TLS server certificates are reliably 1919 verified, the protocol provides true protection against active 1920 man-in-the-middle attacks. 1922 o Even if the server certificate is not used or is unreliable, the 1923 protocol provides protection against active man-in-the-middle 1924 attacks for each HTTP request/response pair. However, in such 1925 cases, JavaScript or similar scripting facilities can be used to 1926 affect the Mutually-authenticated contents from other contents not 1927 protected by this authentication mechanism. This is the reason 1928 why this protocol requires that valid TLS server certificates MUST 1929 be presented (Section 7). 1931 17.2. Denial-of-service Attacks to Servers 1933 The protocol requires a server-side table of active sessions, which 1934 may become a critical point for server resource consumption. For 1935 proper operation, the protocol requires that at least one key 1936 verification request is processed for each session identifier. After 1937 that, servers MAY discard sessions internally at any time, without 1938 causing any operational problems to clients. Clients will silently 1939 reestablish a new session then. 1941 However, if a malicious client sends too many requests for key 1942 exchanges (req-KEX-C1 messages) only, resource starvation might 1943 occur. In such critical situations, servers MAY discard any kind of 1944 existing sessions regardless of their statuses. One way to mitigate 1945 such attacks is that servers MAY have a number and a time limit for 1946 unverified, pending key exchange requests (in the "key exchanging" 1947 state). 1949 This is a common weakness of authentication protocols with almost any 1950 kind of negotiations or states, including Digest authentication 1951 scheme and most Cookie-based authentication implementations. 1952 However, regarding the resource consumption, the situation for the 1953 mutual authentication scheme is a slightly better than for Digest, 1954 because HTTP requests without any kind of authentication requests 1955 will not generate any kind of sessions. Session identifiers are only 1956 generated after a client starts a key negotiation. It means that 1957 simple clients such as Web crawlers will not accidentally consume 1958 server-side resources for session managements. 1960 17.2.1. On-line Active Password Attacks 1962 Although the protocol provides very strong protection against off- 1963 line dictionary attacks from eavesdropped traffic, the protocol, by 1964 its nature, cannot prevent active password attacks in which the 1965 attackers sends so many authentication trial requests for every 1966 possible password. 1968 Possible countermeasures for preventing such attacks may be rate- 1969 limiting of password authentication trials, statistics-based 1970 intrusion detection measures, or similar protection schemes. If the 1971 server operators assume that the passwords of users are not strong 1972 enough, it may be desirable to introduce such ad-hoc countermeasures. 1974 17.3. Communicating the status of mutual authentication with users 1976 This protocol is designed for two goals. The first goal is just 1977 providing a secure alternative for existing Basic and Digest 1978 authentication. The second goal is to provide users a way to detect 1979 forged rogue servers imitating a user's registered account on a 1980 server, commonly known as (a part or kind of) Phishing attacks. 1982 For this protocol to effectively work as some countermeasure to such 1983 attacks, it is very important that end users of clients be notified 1984 of the result of the mutual authentication performed by this 1985 protocol, especially the three states "AUTH-SUCCEED", 1986 "UNAUTHENTICATED", and "AUTH-REQUIRED" defined in Section 10. The 1987 design of secure user interfaces of the HTTP interactive clients is 1988 out of the scope of this document, but if possible, having some kind 1989 of UI indication for the three states above will be desirable for the 1990 user's security benefit. 1992 Of course, in such cases, the user interfaces for asking passwords 1993 for this authentication shall be clearly identifiable against 1994 imitation by other insecure password input fields (such as forms). 1995 If the passwords are known to malicious attackers outside of the 1996 protocol, the protocol cannot work as an effective security measures. 1998 17.4. Implementation Considerations 2000 o To securely implement the protocol, the Authentication-Info 2001 headers in the 200-VFY-S messages MUST always be validated by the 2002 client. If the validation fails, the client MUST NOT process any 2003 content sent with the message, including other headers and the 2004 body part. Non-compliance to this requirement will allow phishing 2005 attacks. 2007 o For HTTP/TLS communications, when a web form is submitted from 2008 Mutually-authenticated pages with the "tls-server-end-point" 2009 validation method to a URI that is protected by the same realm (so 2010 indicated by the path parameter), if the server certificate has 2011 been changed since the pages were received, the peer is 2012 RECOMMENDED to be re-validated using a req-KEX-C1 message with an 2013 "Expect: 100-continue" header. The same applies when the page is 2014 received with the "tls-unique" validation method, and when the TLS 2015 session has expired. 2017 o For better protection against possible password database stealing, 2018 server-side storage of user passwords should contain the values 2019 encrypted by the one-way function J(pi), instead of the real 2020 passwords or those hashed by pi. 2022 17.5. Usage Considerations 2024 o The user names inputted by a user may be sent automatically to any 2025 servers sharing the same auth-scope. This means that when a host- 2026 type auth-scope is used for authentication on an HTTPS site, and 2027 when an HTTP server on the same host requests Mutual 2028 authentication within the same realm, the client will send the 2029 user name in clear text. If user names have to be kept secret 2030 against eavesdropping, the server must use the full-scheme-type 2031 auth-scope parameter and HTTPS. Contrarily, passwords are not 2032 exposed to eavesdroppers even on HTTP requests. 2034 o If the server provides several ways for storing server-side 2035 password secrets in the password database, it is desirable for 2036 better security to store the values encrypted by using the one-way 2037 function J(pi), instead of the real passwords or those hashed by 2038 pi. 2040 18. Notice on Intellectual Properties 2042 The National Institute of Advanced Industrial Science and Technology 2043 (AIST) and Yahoo! Japan, Inc. have jointly submitted a patent 2044 application to the Patent Office of Japan for the protocol proposed 2045 in this documentation. The patent is intended to be open to any 2046 implementer of this protocol and its variants under non-exclusive 2047 royalty-free terms. For the details of the patent application and 2048 its status, please contact the authors of this document. 2050 The elliptic-curve based authentication algorithms might involve 2051 several existing third-party patents. The authors of the document 2052 take no position regarding the validity or scope of such patents and 2053 other patents as well. 2055 19. References 2057 19.1. Normative References 2059 [I-D.ietf-httpauth-extension] 2060 Oiwa, Y., Watanabe, H., Takagi, H., Hayashi, T., and Y. 2061 Ioku, "HTTP Authentication Extensions for Interactive 2062 Clients", draft-ietf-httpauth-extension-07 (work in 2063 progress), July 2016. 2065 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2066 Hashing for Message Authentication", RFC 2104, 2067 DOI 10.17487/RFC2104, February 1997, 2068 . 2070 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2071 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 2072 RFC2119, March 1997, 2073 . 2075 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 2076 Specification Version 2.0", RFC 2898, DOI 10.17487/ 2077 RFC2898, September 2000, 2078 . 2080 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2081 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 2082 November 2003, . 2084 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2085 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2086 . 2088 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2089 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 2090 RFC5234, January 2008, 2091 . 2093 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2094 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 2095 RFC5246, August 2008, 2096 . 2098 [RFC5987] Reschke, J., "Character Set and Language Encoding for 2099 Hypertext Transfer Protocol (HTTP) Header Field 2100 Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010, 2101 . 2103 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2104 Protocol (HTTP/1.1): Message Syntax and Routing", 2105 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2106 . 2108 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2109 Protocol (HTTP/1.1): Authentication", RFC 7235, 2110 DOI 10.17487/RFC7235, June 2014, 2111 . 2113 [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, 2114 Enforcement, and Comparison of Internationalized Strings 2115 Representing Usernames and Passwords", RFC 7613, 2116 DOI 10.17487/RFC7613, August 2015, 2117 . 2119 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- 2120 Authentication-Info Response Header Fields", RFC 7615, 2121 DOI 10.17487/RFC7615, September 2015, 2122 . 2124 19.2. Informative References 2126 [I-D.ietf-httpauth-mutual-algo] 2127 Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 2128 T., and Y. Ioku, "Mutual Authentication Protocol for HTTP: 2129 KAM3-based Cryptographic Algorithms", 2130 draft-ietf-httpauth-mutual-algo-05 (work in progress), 2131 January 2016. 2133 [ISO.10646-1.1993] 2134 International Organization for Standardization, 2135 "Information Technology - Universal Multiple-octet coded 2136 Character Set (UCS) - Part 1: Architecture and Basic 2137 Multilingual Plane", ISO Standard 10646-1, May 1993. 2139 [ITU.X690.1994] 2140 International Telecommunications Union, "Information 2141 Technology - ASN.1 encoding rules: Specification of Basic 2142 Encoding Rules (BER), Canonical Encoding Rules (CER) and 2143 Distinguished Encoding Rules (DER)", ITU-T Recommendation 2144 X.690, 1994. 2146 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 2147 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 2148 . 2150 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 2151 RFC2818, May 2000, 2152 . 2154 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2155 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2156 DOI 10.17487/RFC5226, May 2008, 2157 . 2159 [RFC5890] Klensin, J., "Internationalized Domain Names for 2160 Applications (IDNA): Definitions and Document Framework", 2161 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2162 . 2164 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 2165 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 2166 . 2168 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2169 DOI 10.17487/RFC6265, April 2011, 2170 . 2172 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 2173 DOI 10.17487/RFC6454, December 2011, 2174 . 2176 [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 2177 Preparation, Enforcement, and Comparison of 2178 Internationalized Strings in Application Protocols", 2179 RFC 7564, DOI 10.17487/RFC7564, May 2015, 2180 . 2182 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 2183 Digest Access Authentication", RFC 7616, DOI 10.17487/ 2184 RFC7616, September 2015, 2185 . 2187 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 2188 Langley, A., and M. Ray, "Transport Layer Security (TLS) 2189 Session Hash and Extended Master Secret Extension", 2190 RFC 7627, DOI 10.17487/RFC7627, September 2015, 2191 . 2193 Appendix A. (Informative) Draft Change Log 2195 [To be removed on final publication] 2197 A.1. Changes in Httpauth WG Revision 08 2199 o Minor text update, in sync with httpauth-extension. 2201 o The version token is raised to "1". 2203 A.2. Changes in Httpauth WG Revision 07 2205 o Several comments from reviewers are reflected to the text. 2207 o The password-hash has been completely dropped. 2209 o The version token is raised to "1". 2211 A.3. Changes in Httpauth WG Revision 06 2213 o The auth-domain parameter has been renamed to auth-scope, 2214 following suggestions on the mailing list. 2216 o The digest-md5 password-hash has been dropped, as Digest with MD5 2217 hash is now obsoleted. 2219 A.4. Changes in Httpauth WG Revision 05 2221 o Minimum nonce number window has increased to 128. (HTTP 2.0 2222 recommends at least 100 concurrent sessions to exist) 2224 o Reference to TLS session hash extension added for tls-unique 2225 security issues. 2227 o Comments in the previous F2F meeting has been reflected to the 2228 text. 2230 A.5. Changes in Httpauth WG Revision 04 2232 o Merged httpauthprep proposal into general PRECIS Username/Password 2233 profile. 2235 o Adopting RFC 5987 extended syntax for non-ASCII parameter values. 2237 o Refer draft-ietf-httpbis-auth-info for Authentication-Info header. 2238 This results in a different syntax for that header. 2240 A.6. Changes in Httpauth WG Revision 03 2242 o Incompatible change: Single-port type authentication realm label 2243 has been changed to harmonize with Web Origin. (That is, the 2244 default ports (80 and 443) are to be omitted.) 2246 A.7. Changes in Httpauth WG Revision 02 2248 o Major change: introduction of password-strengthening function 2249 PBKDF2. 2251 o Changed Section 10 to adopt "list of requirements" style. Strict 2252 definition of state machine is now a derived, informational 2253 definition. 2255 A.8. Changes in Httpauth WG Revision 01 2257 o Changed "tls-key" verification to "tls-unique" verification, and 2258 "tls-cert" to "tls-server-end-point", adopting RFC 5929. 2260 o Adopted PRECIS framework [RFC7564]. 2262 o Reverted reservation of "rekey-sid" and "rekey-method" parameters. 2264 o Degraded secure UI requirement to application note level, non- 2265 normative. 2267 o Adjusted levels of several requirements. 2269 o Added warning text for handling of exceptional 5XX responses. 2271 o Dropped several references for optional authentications, except 2272 one "Note". 2274 o Several textual fixes, improvements and revisions. 2276 A.9. Changes in Httpauth Revision 00 2278 o Changed the version token. 2280 o Renamed "verification tokens" to "Host verification tokens" and 2281 variables "v" to "vh" for clarification. (Back-ported from 2282 draft-oiwa-httpauth-multihop-template-00) 2284 A.10. Changes in HttpBis Revision 00 2286 None. 2288 A.11. Changes in Revision 12 2290 o Added a reason "authz-failed". 2292 A.12. Changes in Revision 11 2294 o Message syntax definition reverted to pre-07 style as httpbis-p1 2295 and p7 now defines a precise rule for parameter value parsing. 2297 o Replaced "stale" parameter with more informative/extensive 2298 "reason" parameter in 401-INIT and 401-STALE. 2300 o Reserved "rekey-sid" and "rekey-method" parameters for future 2301 extensions. 2303 o Added descriptions for replacing/non-replacing existing 2304 technologies. 2306 A.13. Changes in Revision 10 2308 o The authentication extension parts (non-mandatory authentication 2309 and authentication controls) are separated to yet another draft. 2311 o The default auth-domain parameter is changed to the full scheme- 2312 host-port syntax, which is consistent with usual HTTP 2313 authentication framework behavior. 2315 o Provision for application channel binding is added. 2317 o Provision for proxy access authentication is added. 2319 o Bug fix: syntax specification of sid parameter was wrong: it was 2320 inconsistent with the type specified in the main text (the bug 2321 introduced in -07 draft). 2323 o Terminologies for headers are changed to be in harmony with 2324 httpbis drafts (e.g. field to parameter). 2326 o Syntax definitions are changed to use HTTP-extended ABNF syntax, 2327 and only the header values are shown for header syntax, in harmony 2328 with httpbis drafts. 2330 o Names of parameters and corresponding mathematical values are now 2331 renamed to more informative ones. The following list shows 2332 correspondence between the new and the old names. 2334 +------------+----------+-------------------------------------------+ 2335 | new name | old name | description | 2336 +------------+----------+-------------------------------------------+ 2337 | S_c1, S_s1 | s_a, s_b | client/server-side secret randoms | 2338 | K_c1, K_s1 | w_a, w_b | client/server-side exchanged key | 2339 | | | components | 2340 | kc1, ks1 | wa, wb | parameter names for those | 2341 | VK_c, VK_s | o_a, o_b | client/server-side key verifiers | 2342 | vkc, vks | oa, ob | parameter names for those | 2343 | z | z | session secrets | 2344 +------------+----------+-------------------------------------------+ 2346 A.14. Changes in Revision 09 2348 o The (default) cryptographic algorithms are separated to another 2349 draft. 2351 o Names of the messages are changed to more informative ones than 2352 before. The following is the correspondence table of those names: 2354 +-------------------+-----------------+-----------------------------+ 2355 | new name | old name | description | 2356 +-------------------+-----------------+-----------------------------+ 2357 | 401-INIT | 401-B0 | initial response | 2358 | 401-STALE | 401-B0-stale | session key expired | 2359 | req-KEX-C1 | req-A1 | client->server key exchange | 2360 | 401-KEX-S1 | 401-B1 | server->client key exchange | 2361 | req-VFY-C | req-A3 | client->server auth. | 2362 | | | verification | 2363 | 200-VFY-S | 200-B4 | server->client auth. | 2364 | | | verification | 2365 | 200-Optional-INIT | 200-Optional-B0 | initial with non-mandatory | 2366 | | | authentication | 2367 +-------------------+-----------------+-----------------------------+ 2369 A.15. Changes in Revision 08 2371 o The English text has been revised. 2373 A.16. Changes in Revision 07 2375 o Adapt to httpbis HTTP/1.1 drafts: 2377 * Changed definition of extensive-token. 2379 * LWSP continuation-line (%0D.0A.20) deprecated. 2381 o To simplify the whole spec, the type of nonce-counter related 2382 parameters are change from hex-integer to integer. 2384 o Algorithm tokens are renamed to include names of hash algorithms. 2386 o Clarified the session management, added details of server-side 2387 protocol decisions. 2389 o The whole draft was reorganized; introduction and overview has 2390 been rewritten. 2392 A.17. Changes in Revision 06 2394 o Integrated Optional Mutual Authentication to the main part. 2396 o Clarified the decision procedure for message recognitions. 2398 o Clarified that a new authentication request for any sub-requests 2399 in interactive clients may be silently discarded. 2401 o Typos and confusing phrases are fixed. 2403 o Several "future considerations" are added. 2405 A.18. Changes in Revision 05 2407 o A new parameter called "version" is added for supporting future 2408 incompatible changes with a single implementation. In the (first) 2409 final specification its value will be changed to 1. 2411 o A new header "Authentication-Control" is added for precise control 2412 of application-level authentication behavior. 2414 A.19. Changes in Revision 04 2416 o Changed text of patent licenses: the phrase "once the protocol is 2417 accepted as an Internet standard" is removed so that the sentence 2418 also covers the draft versions of this protocol. 2420 o The "tls-key" verification is now OPTIONAL. 2422 o Several description fixes and clarifications. 2424 A.20. Changes in Revision 03 2426 o Wildcard domain specifications (e.g. "*.example.com") are allowed 2427 for auth-domain parameters (Section 4.1). 2429 o Specification of the tls-cert verification is updated 2430 (incompatible change). 2432 o State transitions fixed. 2434 o Requirements for servers concerning w_a values are clarified. 2436 o RFC references are updated. 2438 A.21. Changes in Revision 02 2440 o Auth-realm is extended to allow full-scheme type. 2442 o A decision diagram for clients and decision procedures for servers 2443 are added. 2445 o 401-B1 and req-A3 messages are changed to contain authentication 2446 realm information. 2448 o Bugs on equations for o_A and o_B are fixed. 2450 o Detailed equations for the entire algorithm are included. 2452 o Elliptic-curve algorithms are updated. 2454 o Several clarifications and other minor updates. 2456 A.22. Changes in Revision 01 2458 o Several texts are rewritten for clarification. 2460 o Added several security consideration clauses. 2462 Authors' Addresses 2464 Yutaka Oiwa 2465 National Institute of Advanced Industrial Science and Technology 2466 Information Technology Research Institute 2467 Tsukuba Central 1 2468 1-1-1 Umezono 2469 Tsukuba-shi, Ibaraki 2470 JP 2472 Email: mutual-auth-contact-ml@aist.go.jp 2473 Hajime Watanabe 2474 National Institute of Advanced Industrial Science and Technology 2475 Information Technology Research Institute 2476 Tsukuba Central 1 2477 1-1-1 Umezono 2478 Tsukuba-shi, Ibaraki 2479 JP 2481 Hiromitsu Takagi 2482 National Institute of Advanced Industrial Science and Technology 2483 Information Technology Research Institute 2484 Tsukuba Central 1 2485 1-1-1 Umezono 2486 Tsukuba-shi, Ibaraki 2487 JP 2489 Kaoru Maeda 2490 Lepidum Co. Ltd. 2491 Village Sasazuka 3, Suite #602 2492 1-30-3 Sasazuka 2493 Shibuya-ku, Tokyo 2494 JP 2496 Tatsuya Hayashi 2497 Lepidum Co. Ltd. 2498 Village Sasazuka 3, Suite #602 2499 1-30-3 Sasazuka 2500 Shibuya-ku, Tokyo 2501 JP 2503 Yuichi Ioku 2504 Individual