idnits 2.17.1 draft-ietf-httpauth-mutual-07.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 (May 22, 2016) is 2888 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-06 ** 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: November 23, 2016 ITRI, AIST 6 K. Maeda 7 T. Hayashi 8 Lepidum 9 Y. Ioku 10 Individual 11 May 22, 2016 13 Mutual Authentication Protocol for HTTP 14 draft-ietf-httpauth-mutual-07 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 November 23, 2016. 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 07 . . . . . . . . . . . . 48 114 A.2. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 48 115 A.3. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 48 116 A.4. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 48 117 A.5. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 48 118 A.6. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 48 119 A.7. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 49 120 A.8. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 49 121 A.9. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 49 122 A.10. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 49 123 A.11. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 49 124 A.12. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 50 125 A.13. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 51 126 A.14. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 51 127 A.15. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 51 128 A.16. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 52 129 A.17. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 52 130 A.18. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 52 131 A.19. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 52 132 A.20. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 53 133 A.21. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 53 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 136 1. Introduction 138 This document specifies a mutual authentication scheme for Hypertext 139 Transfer Protocol (HTTP). The scheme, called "Mutual Authentication 140 Protocol" in this document, provides true mutual authentication 141 between an HTTP client and an HTTP server, using just a simple 142 password as a credential. 144 The authentication scheme proposed in this document is a general 145 framework for using password-based authenticated key exchange (PAKE) 146 and similar stronger cryptographic primitives with HTTP. It has the 147 following main characteristics: 149 o It provides "true" mutual authentication: in addition to assuring 150 the server that the user knows the password, it also assures the 151 user that the server truly knows the user's encrypted password at 152 the same time. This makes it impossible for fake website owners 153 to persuade users that they have authenticated with the original 154 websites. 156 o It uses only passwords as the user's credential: unlike public- 157 key-based security algorithms, the scheme does not rely on secret 158 keys or other cryptographic data that have to be stored inside the 159 users' computers. The proposed scheme can be used as a drop-in 160 replacement to the current authentication schemes like Basic or 161 Digest, while ensuring a much stronger level of security. 163 o It is secure: when the server fails to authenticate with a user, 164 the protocol will not reveal the tiniest bit of information about 165 the user's password. 167 1.1. Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in 172 [RFC2119]. 174 This document distinguishes the terms "client" and "user" in the 175 following way: A "client" is an entity understanding and talking HTTP 176 and the specified authentication protocol, usually computer software; 177 a "user" is a (usually natural) person who wants to access data 178 resources using a "client". 180 The term "natural numbers" refers to the non-negative integers 181 (including zero) throughout this document. 183 This document treats both the input (domain) and the output 184 (codomain) of hash functions to be octet strings. When a natural 185 number output is required, the notation INT(H(s)) is used. 187 1.2. Document Structure and Related Documents 189 The entire document is organized as follows: 191 o Section 2 presents an overview of the protocol design. 193 o Sections 3 to 11 define a general framework of the Mutual 194 authentication protocol. This framework is independent of 195 specific cryptographic primitives. 197 o Section 12 describes properties needed for cryptographic 198 algorithms used with this protocol framework, and defines a few 199 functions which will be shared among such cryptographic 200 algorithms. 202 o The sections after that contain general normative and informative 203 information about the protocol. 205 o The appendices contain some information that may help developers 206 to implement the protocol. 208 In addition, there are two companion documents which are referred 209 from/related to this specification: 211 o [I-D.ietf-httpauth-mutual-algo]: defines cryptographic primitives 212 which can be used with this protocol framework. 214 o [I-D.ietf-httpauth-extension]: defines small but useful extensions 215 to the current HTTP authentication framework so that it can 216 support application-level semantics of existing Web systems. 218 2. Protocol Overview 220 The protocol, as a whole, is designed as a natural extension to the 221 HTTP protocol [RFC7230] using a framework defined in [RFC7235]. 222 Internally, the server and the client will first perform a 223 cryptographic key exchange, using the secret password as a "tweak" to 224 the exchange. The key exchange will only succeed when the secrets 225 used by the both peers are correctly related (i.e., generated from 226 the same password). Then, both peers will verify the authentication 227 results by confirming the sharing of the exchanged key. This section 228 provides a brief outline of the protocol and the exchanged messages. 230 2.1. Messages Overview 232 The authentication protocol uses seven kinds of messages to perform 233 mutual authentication. These messages have specific names within 234 this specification. 236 o Authentication request messages: used by the servers to request 237 clients to start mutual authentication. 239 * 401-INIT message: a general message to start the authentication 240 protocol. It is also used as a message indicating an 241 authentication failure. 243 * 401-STALE message: a message indicating that client has to 244 start a new key exchange. 246 o Authenticated key exchange messages: used by both peers to perform 247 authentication and the sharing of a cryptographic secret. 249 * req-KEX-C1 message: a message sent from the client. 251 * 401-KEX-S1 message: a message sent from the server in response 252 to a req-KEX-C1 message. 254 o Authentication verification messages: used by both peers to verify 255 the authentication results. 257 * req-VFY-C message: a message used by the client, requesting the 258 server authenticate and authorize the client. 260 * 200-VFY-S message: a client-authentication successful response 261 used by the server, which also simultaneously asserts to the 262 client that the server is authentic. 264 In addition to the above, either a request or a response without any 265 HTTP headers related to this specification will be hereafter called a 266 "normal request" or a "normal response", respectively. 268 2.2. Typical Flows of the Protocol 270 In typical cases, the client access to a resource protected by the 271 Mutual authentication scheme will use the following protocol 272 sequence. 274 Client Server 275 | | 276 | ---- (1) normal request ---------> | 277 GET / HTTP/1.1 | 278 | | 279 | <---------------- (2) 401-INIT --- | 280 | 401 Authentication Required 281 | WWW-Authenticate: Mutual realm="a realm" 282 | | 283 [user, | | 284 pass]-->| | 285 | ---- (3) req-KEX-C1 -------------> | 286 GET / HTTP/1.1 | 287 Authorization: Mutual user="john", |--> [user DB] 288 kc1="...", ... |<-- [user info] 289 | | 290 | <-------------- (4) 401-KEX-S1 --- | 291 | 401 Authentication Required 292 | WWW-Authenticate: Mutual sid=..., ks1="...", ... 293 | | 294 [compute] (5) compute session secret [compute] 295 | | 296 | | 297 | ---- (6) req-VFY-C --------------> | 298 GET / HTTP/1.1 |--> [verify (6)] 299 Authorization: Mutual sid=..., |<-- OK 300 vkc="...", ... | 301 | | 302 | <--------------- (7) 200-VFY-S --- | 303 [verify | 200 OK | 304 (7)]<--| Authentication-Info: Mutual vks="..." 305 | | 306 v v 308 Figure 1: Typical communication flow for first access to resource 310 o As usual in general HTTP protocol designs, a client will at first 311 request a resource without any authentication attempt (1). If the 312 requested resource is protected by the Mutual authentication, the 313 server will respond with a message requesting authentication 314 (401-INIT) (2). 316 o The client processes the body of the message and waits for the 317 user to input the user name and a password. If the user name and 318 the password are available, the client will send a message with 319 the authenticated key exchange (req-KEX-C1) to start the 320 authentication (3). 322 o If the server has received a req-KEX-C1 message, the server looks 323 up the user's authentication information within its user database. 324 Then the server creates a new session identifier (sid) that will 325 be used to identify sets of the messages that follow it and 326 responds back with a message containing a server-side 327 authenticated key exchange value (401-KEX-S1) (4). 329 o At this point (5), both peers calculate a shared "session secret" 330 using the exchanged values in the key exchange messages. Only 331 when both the server and the client have used secret credentials 332 generated from the same password will the session secret values 333 match. This session secret will be used for access authentication 334 of every individual normal after this point. 336 o The client will send a request with a client-side authentication 337 verification value (req-VFY-C) (6), calculated from the client- 338 generated session secret. The server will check the validity of 339 the verification value using its own version of the session 340 secret. 342 o If the authentication verification value from the client was 343 correct, it means that the client definitely owns the credential 344 based on the expected password (i.e., the client authentication 345 succeeded). The server will respond with a successful message 346 (200-VFY-S) (7). Contrary to the usual one-way authentication 347 (e.g., HTTP Basic authentication or POP APOP authentication 348 [RFC1939]), this message also contains a server-side 349 authentication verification value. 351 When the client's verification value is incorrect (e.g., because 352 the user-supplied password was incorrect), the server will respond 353 with the 401-INIT message (the same one as used in (2)) instead. 355 o The client MUST first check the validity of the server-side 356 authentication verification value contained in the message (7). 357 If the value was equal to the expected one, server authentication 358 succeeded. 360 If it is not the value expected, or if the message does not 361 contain the authentication verification value, it means that the 362 mutual authentication has been broken for some unexpected reason. 363 The client MUST NOT process any body or header values contained in 364 the HTTP response in this case. (Note: This case should not 365 happen between a correctly implemented server and client without 366 any active attacks. The possible cause of such a case might be 367 either a man-in-the-middle attack or an incorrect implementation.) 369 2.3. Alternative Flows 371 As shown above, the typical flow for a first authentication request 372 requires three request-response pairs. To reduce the protocol 373 overhead, the protocol enables several short-cut flows which require 374 fewer messages. 376 o (case A) If the client knows that the resource is likely to 377 require authentication, the client MAY omit the first 378 unauthenticated request (1) and immediately send a key exchange 379 (req-KEX-C1 message). This will reduce one round-trip of 380 messages. 382 o (case B) If both the client and the server previously shared a 383 session secret associated with a valid session identifier (sid), 384 the client MAY directly send a req-VFY-C message using the 385 existing session identifier and corresponding session secret. 386 This will further reduce one round-trip of messages. 388 The server MAY have thrown out the corresponding session from the 389 session table. If so, the server will respond with a 401-STALE 390 message, indicating a new key exchange is required. The client 391 SHOULD retry constructing a req-KEX-C1 message in this case. 393 Figure 2 depicts the shortcut flows described above. Under the 394 appropriate settings and implementations, most of the requests to 395 resources are expected to meet both criteria, and thus only one 396 round-trip of request/response will be required. 398 (A) omit first request 399 (2 round trips) 401 Client Server 402 | | 403 | --- req-KEX-C1 ----> | 404 | | 405 | <---- 401-KEX-S1 --- | 406 | | 407 | ---- req-VFY-C ----> | 408 | | 409 | <----- 200-VFY-S --- | 410 | | 412 (B) reusing session secret (re-authentication) 414 (B-1) key available (B-2) key expired 415 (1 round trip) (3 round trips) 417 Client Server Client Server 418 | | | | 419 | ---- req-VFY-C ----> | | --- req-VFY-C -------> | 420 | | | | 421 | <----- 200-VFY-S --- | | <------- 401-STALE --- | 422 | | | | 423 | --- req-KEX-C1 ------> | 424 | | 425 | <------ 401-KEX-S1 --- | 426 | | 427 | --- req-VFY-C -------> | 428 | | 429 | <------- 200-VFY-S --- | 430 | | 432 Figure 2: Several alternative protocol flows 434 For more details, see Sections 10 and 11. 436 3. Message Syntax 438 Throughout this specification, the syntax is denoted in the extended 439 augmented BNF syntax defined in [RFC7230], and [RFC5234]. The 440 following elements are quoted from [RFC5234], [RFC7230] and 441 [RFC7235]: DIGIT, ALPHA, SP, auth-scheme, quoted-string, auth-param, 442 header-field, token, challenge, and credential. 444 The Mutual authentication protocol uses three headers: 445 WWW-Authenticate (usually in responses with status code 401), 446 Authorization (in requests), and Authentication-Info (in responses 447 other than 401 status). These headers follow a common framework 448 described in [RFC7235] and [RFC7615]. The detailed meanings for 449 these headers are contained in Section 4. 451 The framework in [RFC7235] defines the syntax for the headers 452 WWW-Authenticate and Authorization as the syntax elements "challenge" 453 and "credentials", respectively. The "auth-scheme" contained in 454 those headers MUST be "Mutual" throughout this protocol 455 specification. The syntax for "challenge" and "credentials" to be 456 used with the "Mutual" auth-scheme SHALL be name-value pairs (#auth- 457 param), not the "b64token" defined in [RFC7235]. 459 The Authentication-Info: header used in this protocol SHALL follow 460 the syntax defined in [RFC7615]. 462 In HTTP, the WWW-Authenticate header may contain two or more 463 challenges. Client implementations SHOULD be aware of and be capable 464 of handling those cases correctly. 466 3.1. Non-ASCII extended header parameters 468 All of parameters contained in the above three headers, except the 469 "realm" field, MAY be extended to ISO 10646-1 values using the 470 framework described in [RFC5987]. All servers and clients MUST be 471 capable of receiving and sending values encoded in [RFC5987] syntax. 473 If a value to be sent contains only ASCII characters, the field MUST 474 be sent using plain RFC 7235 syntax. The syntax as extended by RFC 475 5987 MUST NOT be used in this case. 477 If a value (except the "realm" header) contains one or more non-ASCII 478 characters, the parameter SHOULD be sent using the syntax defined in 479 Section 3.2 of [RFC5987] as "ext-parameter". Such a parameter MUST 480 have a charset value of "UTF-8", and the language value MUST always 481 be omitted (have an empty value). The same parameter MUST NOT be 482 sent more than once, regardless of the used syntax. 484 For example, a parameter "user" with value "Renee of France" SHOULD 485 be sent as < user="Renee of France" >. If the value is 486 "Rene of France", it SHOULD be sent as < user*=UTF- 487 8''Ren%C3%89e%20of%20France > instead. 489 [RFC7235] requires the realm parameter to be in its plain form (not 490 as an extended "realm*" parameter), so RFC 5987 syntax MUST NOT be 491 used for this parameter. 493 3.2. Values 495 The parameter values contained in challenge/credentials MUST be 496 parsed strictly conforming to the HTTP semantics (especially un- 497 quoting of the string parameter values). In this protocol, those 498 values are further categorized into the following value types: tokens 499 (bare-token and extensive-token), string, integer, hex-fixed-number, 500 and base64-fixed-number. 502 For clarity, implementations are RECOMMENDED to use the canonical 503 representations specified in the following subsections for sending 504 values. Recipients SHOULD accept both quoted and unquoted 505 representations interchangeably as specified in HTTP. 507 3.2.1. Tokens 509 For sustaining both security and extensibility at the same time, this 510 protocol defines a stricter sub-syntax for the "token" to be used. 511 Extensive-token values SHOULD use the following syntax (after HTTP 512 value parsing): 514 bare-token = 1*(DIGIT / ALPHA / "-" / "_") 515 extension-token = "-" bare-token 1*("." bare-token) 516 extensive-token = bare-token / extension-token 518 Figure 3: BNF syntax for token values 520 The tokens (bare-token and extension-token) are case insensitive; 521 Senders SHOULD send these in lower case, and receivers MUST accept 522 both upper and lower cases. When tokens are used as (partial) inputs 523 to any hash or other mathematical functions, they MUST always be used 524 in lower case. 526 Extensive-tokens are used in this protocol where the set of 527 acceptable tokens may include non-standard extensions. Any non- 528 standard extension of this protocol SHOULD use the extension-token 529 with the format "-.", where is 530 a valid (sub-)domain name on the Internet owned by the party who 531 defines the extension. 533 Bare-tokens and extensive-tokens are also used for parameter names, 534 in the unquoted form. Requirements for using the extension-token for 535 the parameter names are the same as the previous paragraph. 537 The canonical format for bare-tokens and extensive-tokens is the 538 unquoted representation. 540 3.2.2. Strings 542 All character strings MUST be encoded to octet strings using the 543 UTF-8 encoding [RFC3629] for the ISO 10646-1 character set 544 [ISO.10646-1.1993]. Such strings MUST NOT contain any leading BOM 545 characters (ZERO WIDTH NO-BREAK SPACE, U+FEFF or EF BB BF). Both 546 peers are RECOMMENDED to reject any invalid UTF-8 sequences that 547 might cause decoding ambiguities (e.g., containing <"> in the second 548 or later bytes of the UTF-8 encoded characters). 550 If strings are representing a domain name or URI that contains non- 551 ASCII characters, the host parts SHOULD be encoded as it is used in 552 the HTTP protocol layer (e.g., in a Host: header); under current 553 standards it will be the one defined in [RFC5890]. It SHOULD use 554 lower-case ASCII characters. 556 The canonical format for strings is quoted-string (as it may contain 557 equal signs, plus signs and slashes), unless the parameter containing 558 the string value will use extended syntax defined in [RFC5987]. (An 559 [RFC5987] extended parameter will have an unquoted encoded value, as 560 defined therein.) 562 3.2.3. Numbers 564 The following syntax definitions give a syntax for numeric values: 566 integer = "0" / (%x31-39 *DIGIT) ; no leading zeros 567 hex-fixed-number = 1*(2(DIGIT / %x41-46 / %x61-66)) 568 base64-fixed-number = 1*( ALPHA / DIGIT / "+" / "/" ) 0*2"=" 570 Figure 4: BNF syntax for numbers 572 The syntax definition of the integers only allows representations 573 that do not contain leading zeros. 575 A number represented as a hex-fixed-number MUST include an even 576 number of hexadecimal digits (i.e., multiples of eight bits). Those 577 values are case-insensitive, and SHOULD be sent in lower case. When 578 these values are generated from any cryptographic values, they SHOULD 579 have their "natural length"; if these are generated from a hash 580 function, these lengths SHOULD correspond to the hash size; if these 581 are representing elements of a mathematical set (or group), its 582 lengths SHOULD be the shortest for representing all the elements in 583 the set. For example, the results of the SHA-256 hash function will 584 be represented by 64 digits, and any elements in a 2048-bit prime 585 field (modulo a 2048-bit integer) will be represented by 512 digits, 586 regardless of how much zeros appear in front of such representations. 587 Session-identifiers and other non-cryptographically generated values 588 are represented in any (even) length determined by the side that 589 generates it first, and the same length SHALL be used throughout all 590 communications by both peers. 592 The numbers represented as base64-fixed-number SHALL be generated as 593 follows: first, the number is converted to a big-endian radix-256 594 binary representation as an octet string. The length of the 595 representation is determined in the same way as mentioned above. 596 Then, the string is encoded using the Base 64 encoding [RFC4648] 597 without any spaces and newlines. Implementations decoding base64- 598 fixed-number SHOULD reject any input data with invalid characters, 599 excess/insufficient padding, or non-canonical pad bits (See Sections 600 3.1 to 3.5 of [RFC4648]). 602 The canonical format for integer and hex-fixed-number are unquoted 603 tokens, and that for base64-fixed-number is quoted-string. 605 4. Messages 607 In this section we define the seven kinds of messages used in the 608 authentication protocol along with the formats and requirements of 609 the headers for each message. 611 To determine in what circumstances each message is expected to be 612 sent, see Sections 10 and 11. 614 In the descriptions below, the type of allowable values for each 615 header parameter is shown in parenthesis after each parameter name. 616 The "algorithm-determined" type means that the acceptable value for 617 the parameter is one of the types defined in Section 3, and is 618 determined by the value of the "algorithm" parameter. The parameters 619 marked "mandatory" SHALL be contained in the message. The parameters 620 marked "non-mandatory" MAY either be contained or omitted in the 621 message. Each parameter SHALL appear in each header exactly once at 622 most. 624 All credentials and challenges MAY contain any parameters not 625 explicitly specified in the following sections. Recipients that do 626 not understand such parameters MUST silently ignore those. However, 627 all credentials and challenges MUST meet the following criteria: 629 o For responses, the parameters "reason", any "ks#" (where # stands 630 for any decimal integer), and "vks" are mutually exclusive; any 631 challenge MUST NOT contain two or more parameters among them. 632 They MUST NOT contain any "kc#" or "vkc" parameters. 634 o For requests, the parameters "kc#" (where # stands for any decimal 635 integer), and "vkc" are mutually exclusive and any challenge 636 MUST NOT contain two or more parameters among them. They MUST NOT 637 contain any "ks#" or "vks" parameters. 639 Every message in this section contains a "version" field, to detect 640 future, incompatible revisions of the protocol. Implementations of 641 the protocol described in this specification MUST always send a token 642 "1", and recipients MUST reject messages that contain any other value 643 as a version, unless another specification defines a behavior for 644 that version. 646 4.1. 401-INIT and 401-STALE 648 Every 401-INIT or 401-STALE message SHALL be a valid HTTP 401-status 649 (Authentication Required) message (or other 4XX status if sensible) 650 containing one and only one (hereafter not explicitly noted) 651 "WWW-Authenticate" header containing a "reason" parameter in the 652 challenge. The challenge SHALL contain all of the parameters marked 653 "mandatory" below, and MAY contain those marked "non-mandatory". 655 version: (mandatory extensive-token) should be the token "1". 657 algorithm: (mandatory extensive-token) specifies the 658 authentication algorithm to be used. The value MUST 659 be one of the tokens specified in 660 [I-D.ietf-httpauth-mutual-algo] or another 661 supplemental specification. 663 validation: (mandatory extensive-token) specifies the method of 664 host validation. The value MUST be one of the tokens 665 described in Section 7 or the tokens specified in 666 another supplemental specification. 668 auth-scope: (non-mandatory string) specifies the authentication 669 scope, the set of hosts for which the authentication 670 credentials are valid. It MUST be one of the strings 671 described in Section 5. If the value is omitted, it 672 is assumed to be the "single-server" type domain in 673 Section 5. 675 realm: (mandatory string) is a string representing the name 676 of the authentication realm inside the authentication 677 scope. As specified in [RFC7235], this value MUST 678 always be sent in the quoted-string form, and an 679 [RFC5987] encoding MUST NOT be used. 680 The realm value sent from the server SHOULD be an 681 ASCII string. Clients MAY treat any non-ASCII value 682 received in this field as a binary blob, an NFC- 683 normalized UTF-8 string, or an error. 685 reason: (mandatory extensive-token) SHALL be an extensive- 686 token that describes the possible reason of the failed 687 authentication/authorization. Both servers and 688 clients SHALL understand and support the following 689 three tokens: 691 * initial: authentication was not tried because there 692 was no Authorization header in the corresponding 693 request. 695 * stale-session: the provided sid in the request was 696 either unknown to or expired in the server. 698 * auth-failed: authentication trial was failed for 699 some reason, possibly with a bad authentication 700 credential. 702 Implementations MAY support the following tokens or 703 any extensive-tokens defined outside this 704 specification. If clients receive any unknown tokens, 705 they SHOULD treat these as if they were "auth-failed" 706 or "initial". 708 * reauth-needed: the server-side application requires 709 a new authentication trial, regardless of the 710 current status. 712 * invalid-parameters: the server did not attempt 713 authentication because some parameters were not 714 acceptable. 716 * internal-error: the server did not attempt 717 authentication because there are some troubles on 718 the server-side. 720 * user-unknown: this is a special case of auth- 721 failed, suggesting that the provided user name is 722 invalid. The use of this parameter is 723 NOT RECOMMENDED due to security implications, 724 except for special-purpose applications where it 725 makes sense. 727 * invalid-credential: ditto, suggesting that the 728 provided user name was valid but authentication 729 still failed. The use of this parameter is 730 NOT RECOMMENDED for security reasons. 732 * authz-failed: authentication was successful, but 733 access to the specified resource is not authorized 734 to the specific authenticated user. (It might be 735 used along with either a 401 or 403 status to 736 indicate that the authentication result is one of 737 the existing reasons for the failed authorization.) 739 The algorithm specified in this header will determine the types 740 (among those defined in Section 3) and the values for K_c1, K_s1, 741 VK_c and VK_s. 743 Among these messages, those with the reason parameter of value 744 "stale-session" will be called "401-STALE" messages hereafter, 745 because these have a special meaning in the protocol flow. Messages 746 with any other reason parameters will be called "401-INIT" messages. 748 4.2. req-KEX-C1 750 Every req-KEX-C1 message SHALL be a valid HTTP request message 751 containing an "Authorization" header with a credential containing a 752 "kc1" parameter. 754 The credential SHALL contain the parameters with the following names: 756 version: (mandatory, extensive-token) should be the token "1". 758 algorithm, validation, auth-scope, realm: MUST be the same values as 759 received from the server. 761 user: (mandatory, string) is the UTF-8 encoded name of the 762 user. The string SHOULD be prepared according to the 763 method presented in Section 9. 765 kc1: (mandatory, algorithm-determined) is the client-side 766 key exchange value K_c1, which is specified by the 767 algorithm that is used. 769 4.3. 401-KEX-S1 771 Every 401-KEX-S1 message SHALL be a valid HTTP 401-status 772 (Authentication Required) response message containing a 773 "WWW-Authenticate" header with a challenge containing a "ks1" 774 parameter. 776 The challenge SHALL contain the parameters with the following names: 778 version: (mandatory, extensive-token) should be the token "1". 780 algorithm, validation, auth-scope, realm: MUST be the same values as 781 received from the client. 783 sid: (mandatory, hex-fixed-number) MUST be a session 784 identifier, which is a random integer. The sid SHOULD 785 have uniqueness of at least 80 bits or the square of 786 the maximum estimated transactions concurrently 787 available in the session table, whichever is larger. 788 See Section 6 for more details. 790 ks1: (mandatory, algorithm-determined) is the server-side 791 key exchange value K_s1, which is specified by the 792 algorithm. 794 nc-max: (mandatory, integer) is the maximum value of nonce 795 numbers that the server accepts. 797 nc-window: (mandatory, integer) the number of available nonce 798 number slots that the server will accept. The value 799 of the nc-window parameter is RECOMMENDED to be 128 or 800 more. 802 time: (mandatory, integer) represents the suggested time (in 803 seconds) that the client can reuse the session 804 represented by the sid. It is RECOMMENDED to be at 805 least 60. The value of this parameter is not directly 806 linked to the duration that the server keeps track for 807 the session represented by the sid. 809 path: (non-mandatory, string) specifies which path in the 810 URI space the same authentication is expected to be 811 applied. The value is a space-separated list of URIs, 812 in the same format as it was specified in domain 813 parameter [RFC7616] for Digest authentications. All 814 path elements contained in the parameter MUST be 815 inside the specified auth-scope; if not, clients 816 SHOULD ignore such elements. For better performance, 817 recognition of this parameter by clients is important. 819 4.4. req-VFY-C 821 Every req-VFY-C message SHALL be a valid HTTP request message 822 containing an "Authorization" header with a credential containing a 823 "vkc" parameter. 825 The parameters contained in the header are as follows: 827 version: (mandatory, extensive-token) should be the token "1". 829 algorithm, validation, auth-scope, realm: MUST be the same values as 830 received from the server for the session. 832 sid: (mandatory, hex-fixed-number) MUST be one of the sid 833 values that was received from the server for the same 834 authentication realm. 836 nc: (mandatory, integer) is a nonce request number that is 837 unique among the requests sharing the same sid. The 838 values of the nonce numbers SHOULD satisfy the 839 properties outlined in Section 6. 841 vkc: (mandatory, algorithm-determined) is the client-side 842 authentication verification value VK_c, which is 843 specified by the algorithm. 845 4.5. 200-VFY-S 847 Every 200-VFY-S message SHALL be a valid HTTP message that does not 848 have a 401 (Authentication Required) status code and SHALL contain an 849 "Authentication-Info" header with a "vks" parameter. 851 The parameters contained in the header are as follows: 853 version: (mandatory, extensive-token) should be the token "1". 855 sid: (mandatory, hex-fixed-number) MUST be the value 856 received from the client. 858 vks: (mandatory, algorithm-determined) is the server-side 859 authentication verification value VK_s, which is 860 specified by the algorithm. 862 The header MUST be sent before the content body: it MUST NOT be sent 863 in the trailer of a chunked-encoded response. If a "100 Continue" 864 response is sent from the server, the Authentication-Info header 865 SHOULD be included in that response, instead of the final response. 867 5. Authentication Realms 869 In this protocol, an "authentication realm" is defined as a set of 870 resources (URIs) for which the same set of user names and passwords 871 is valid. If the server requests authentication for an 872 authentication realm that the client is already authenticated for, 873 the client will automatically perform the authentication using the 874 already-known credentials. However, for different authentication 875 realms, clients MUST NOT automatically reuse user names and passwords 876 for another realm. 878 Just like in the Basic and Digest access authentication protocols, 879 the Mutual authentication protocol supports multiple, separate 880 protection spaces to be set up inside each host. Furthermore, the 881 protocol allows a single authentication realm to span over several 882 hosts within the same Internet domain. 884 Each authentication realm is defined and distinguished by the triple 885 of an "authentication algorithm", an "authentication scope", and a 886 "realm" parameter. However, server operators are NOT RECOMMENDED to 887 use the same pair of an authentication scope and a realm with 888 different authentication algorithms. 890 The realm parameter is a string as defined in Section 4. 891 Authentication scopes are described in the remainder of this section. 893 An authentication scope specifies the range of hosts that the 894 authentication realm spans over. In this protocol, it MUST be one of 895 the following kinds of strings. 897 o Single-server type: A string in the format "://" or 898 "://:", where , , and are 899 the corresponding URI parts of the request URI. If the default 900 port (i.e., 80 for http and 443 for https) is used for the 901 underlying HTTP communications, the port part MUST be omitted, 902 regardless of whether it was present in the request-URI. In all 903 other cases, the port part MUST be present, and it MUST NOT 904 contain leading zeros. Use this format when authentication is 905 only valid for a specific protocol (such as https). This format 906 is equivalent to the ASCII serialization of a Web Origin, 907 presented in Section 6.2 of [RFC6454]. 909 o Single-host type: The "host" part of the requested URI. This is 910 the default value. Authentication realms within this kind of 911 authentication scope will span over several protocols (e.g., http 912 and https) and ports, but not over different hosts. 914 o Wildcard-domain type: A string in the format "*.", 915 where is either the host part of the requested 916 URI or any domain in which the requested host is included (this 917 means that the specification "*.example.com" is valid for all of 918 hosts "www.example.com", "web.example.com", 919 "www.sales.example.com" and "example.com"). The domain-postfix 920 sent by the servers MUST be equal to or included in a valid 921 Internet domain assigned to a specific organization; if clients 922 know, by some means such as a blacklist for HTTP cookies 923 [RFC6265], that the specified domain is not to be assigned to any 924 specific organization (e.g., "*.com" or "*.jp"), clients are 925 RECOMMENDED to reject the authentication request. 927 In the above specifications, every "scheme", "host", and "domain" 928 MUST be in lower case, and any internationalized domain names beyond 929 the ASCII character set SHALL be represented in the way they are sent 930 in the underlying HTTP protocol, represented in lower case 931 characters, i.e., these domain names SHALL be in the form of LDH 932 labels in IDNA [RFC5890]. A "port" MUST be given in the shortest, 933 unsigned, decimal number notation. Not obeying these requirements 934 will cause failure of valid authentication attempts. 936 5.1. Resolving Ambiguities 938 In the above definitions of authentication scopes, several scopes may 939 overlap each other. If a client has already been authenticated to 940 several realms applicable to the same server, the client may have a 941 multiple lists of the "path" parameters received with the 942 "401-KEX-S1" message (see Section 4). If these path lists have any 943 overlap, a single URI may belong to multiple possible candidate of 944 realms to be authenticated to. In such cases, clients faces an 945 ambiguity in deciding which credentials to send for a new request (in 946 steps 3 and 4 of the decision procedure presented in Section 10). 948 In such cases, a client MAY send request which belong to any of these 949 candidate realms freely, or it MAY simply send an unauthenticated 950 request and see for which realm the server requests an 951 authentication. Server operators are RECOMMENDED to provide 952 properly-configured "path" parameters (more precisely, disjoint path 953 sets for each realms) for clients so that such ambiguities will not 954 occur. 956 The following procedure is one possible tactic for resolving 957 ambiguity in such cases. 959 o If the client has previously sent a request to the same URI, and 960 if it remembers the authentication realm requested by the 401-INIT 961 message at that time, use that realm. 963 o In other cases, use one of the authentication realms representing 964 the most-specific authentication scopes. The list of possible 965 domain specifications shown above is given from most specific to 966 least specific. 968 If there are several choices with different wildcard-domain 969 specifications, the one that has the longest domain-postfix has 970 priority over ones with shorter domain-postfixes. 972 o If there are realms with the same authentication scope, there is 973 no defined priority; the client MAY choose any one of the possible 974 choices. 976 6. Session Management 978 In the Mutual authentication protocol, a session represented by an 979 sid is set up using four messages (first request, 401-INIT, 980 req-KEX-C1 and 401-KEX-S1), after which a "session secret" (z) 981 associated with the session is established. After mutually 982 establishing a session secret, this session, along with the secret, 983 can be used for one or more requests for resources protected by the 984 same realm on the same server. Note that session management is only 985 an inside detail of the protocol and usually not visible to normal 986 users. If a session expires, the client and server SHOULD 987 automatically re-establish another session without informing the 988 user. 990 Sessions and session identifiers are local to each server (defined by 991 scheme, host, and port), even if an authentication scope covers 992 multiple servers; clients MUST establish separate sessions for each 993 port of a host to be accessed. Furthermore, sessions and identifiers 994 are also local to each authentication realm, even if these are 995 provided by the same server. The same session identifiers provided 996 either from different servers or for different realms MUST be treated 997 as independent or each other. 999 The server SHOULD accept at least one req-VFY-C request for each 1000 session, if the request reaches the server in a time window specified 1001 by the timeout parameter in the 401-KEX-S1 message, and there are no 1002 emergent reasons (such as flooding attacks) to forget the session. 1003 After that, the server MAY discard any session at any time and MAY 1004 send 401-STALE messages for any further req-VFY-C requests received 1005 for that session. 1007 The client MAY send two or more requests using a single session 1008 specified by the sid. However, for all such requests, each value of 1009 the nonce number (in the nc parameter) MUST satisfy the following 1010 conditions: 1012 o It is a natural number. 1014 o The same nonce number was not sent within the same session. 1016 o It is not larger than the nc-max value that was sent from the 1017 server in the session represented by the sid. 1019 o It is larger than (largest-nc - nc-window), where largest-nc is 1020 the largest value of nc which was previously sent in the session, 1021 and nc-window is the value of the nc-window parameter that was 1022 received from the server for the session. 1024 The last condition allows servers to reject any nonce numbers that 1025 are "significantly" smaller than the "current" value (defined by the 1026 value of nc-window) of the nonce number used in the session involved. 1027 In other words, servers MAY treat such nonce numbers as "already 1028 received". This restriction enables servers to implement duplicate 1029 nonce detection in a constant amount of memory for each session. 1031 Servers MUST check for duplication of the received nonce numbers, and 1032 if any duplication is detected, the server MUST discard the session 1033 and respond with a 401-STALE message, as outlined in Section 11. The 1034 server MAY also reject other invalid nonce numbers (such as ones 1035 above the nc-max limit) by sending a 401-STALE message. 1037 For example, assume the nc-window value of the current session is 1038 128, nc-max is 400, and that the client has already used the 1039 following nonce numbers: {1-120, 122, 124, 130-238, 255-360, 363- 1040 372}. Then the nonce number that can be used for the next request is 1041 one of the following set: {245-254, 361, 362, 373-400}. The values 1042 {0, 121, 123, 125-129, 239-244} MAY be rejected by the server because 1043 they are not above the current "window limit" (244 = 372 - 128). 1045 Typically, clients can ensure the above property by using a 1046 monotonically-increasing integer counter that counts from zero up to 1047 the value of nc-max. 1049 The values of the nonce numbers and any nonce-related values MUST 1050 always be treated as natural numbers within an infinite range. 1051 Implementations which uses fixed-width integer representations, 1052 fixed-precision floating-point numbers, or similar representations 1053 SHOULD NOT reject any larger values which overflow such 1054 representative limits, and MUST NOT silently truncate them using any 1055 modulus-like rounding operation (e.g., by mod 2^32). Instead, the 1056 whole protocol is carefully designed so that recipients MAY replace 1057 any such overflowing values (e.g. 2^80) with some reasonably-large 1058 maximum representative integer (e.g., 2^31 - 1 or others). 1060 7. Host Validation Methods 1062 The "validation method" specifies a method to "relate" (or "bind") 1063 the mutual authentication processed by this protocol with other 1064 authentications already performed in the underlying layers and to 1065 prevent man-in-the-middle attacks. It determines the value vh that 1066 is an input to the authentication protocols. 1068 When HTTPS or other possible secure transport is used, this 1069 corresponds to the idea of "channel binding" described in [RFC5929]. 1070 Even when HTTP is used, similar, but somewhat limited, "binding" is 1071 performed to prevent a malicious server from trying to authenticate 1072 itself to another server as a valid user by forwarding the received 1073 credentials. 1075 The valid tokens for the validation parameter and corresponding 1076 values of vh are as follows: 1078 host: host-name validation: The value vh will be the ASCII 1079 string in the following format: 1080 "://:", where , , 1081 and are the URI components corresponding to the 1082 currently accessing resource. The scheme and host are 1083 in lower case, and the port is in a shortest decimal 1084 representation. Even if the request-URI does not have 1085 a port part, v will include the default port number. 1087 tls-server-end-point: TLS endpoint (certificate) validation: The 1088 value vh will be the octet string of the hash value of 1089 the server's public key certificate used in the 1090 underlying TLS [RFC5246] connection, processed as 1091 specified in Section 4.1 of [RFC5929]. 1093 tls-unique: TLS shared-key validation: The value vh will be the 1094 channel binding material derived from the Finished 1095 messages, as defined in Section 3.1 of [RFC5929]. 1096 (Note: see Section 7.2 for some security notices when 1097 using this validation method.) 1099 If HTTP is used on a non-encrypted channel (TCP and SCTP, for 1100 example), the validation type MUST be "host". If HTTP/TLS [RFC2818] 1101 (HTTPS) is used with a server certificate, the validation type MUST 1102 be "tls-server-end-point". If HTTP/TLS is used with an anonymous 1103 Diffie-Hellman key exchange, the validation type MUST be "tls-unique" 1104 (see the note below). 1106 Implementations supporting Mutual authentication over HTTPS SHOULD 1107 support the "tls-server-end-point" validation. Support for 1108 "tls-unique" validation is OPTIONAL for both servers and clients. 1110 If the validation type "tls-server-end-point" is used, the server 1111 certificate provided in the TLS connection MUST be verified at least 1112 to make sure that the server actually owns the corresponding private 1113 key. (Note: this verification is automatic in some RSA-based key 1114 exchanges but NOT automatic in Diffie-Hellman-based key exchanges 1115 with separate exchange for server verification.) 1117 Clients MUST validate this parameter upon receipt of 401-INIT 1118 messages. 1120 Note: The protocol defines two variants of validation on the TLS 1121 connections. The "tls-unique" method is more secure. However, there 1122 are some situations where tls-server-end-point is more preferable. 1124 o When TLS accelerating proxies are used, it is difficult for the 1125 authenticating server to acquire the TLS key information that is 1126 used between the client and the proxy. This is not the case for 1127 client-side "tunneling" proxies using the HTTP CONNECT method. 1129 o When a black-box implementation of the TLS protocol is used on 1130 either peer. 1132 7.1. Applicability notes 1134 When the client is a Web browser with any scripting capabilities, the 1135 underlying TLS channel used with HTTP/TLS MUST provide server 1136 identity verification. This means (1) anonymous Diffie-Hellman key 1137 exchange cipher suites MUST NOT be used, and (2) verification of the 1138 server certificate provided by the server MUST be performed. 1140 For other systems, when the underlying TLS channel used with HTTP/TLS 1141 does not perform server identity verification, the client SHOULD 1142 ensure that all the responses are validated using the Mutual 1143 authentication protocol, regardless of the existence of 401-INIT 1144 responses. 1146 7.2. Notes on tls-unique 1148 As described in the interoperability note in the above channel 1149 binding specification, the tls-unique verification value will be 1150 changed by possible TLS renegotiation, causing an interoperability 1151 problem. TLS re-negotiations are used in several HTTPS server 1152 implementations for enforcing some security properties (such as 1153 cryptographic strength) for some specific responses. 1155 If an implementation supports the "tls-unique" verification method, 1156 the following caution SHOULD be taken: 1158 o Both peers must be aware that the vh values used for vkc (in 1159 req-VFY-C) and for vks (in 200-VFY-S) may be different. These 1160 values MUST be retrieved from underlying TLS libraries each time 1161 they are used. 1163 o After calculating the values vh and vkc to send a req-VFY-C 1164 request, Clients SHOULD NOT initiate TLS renegotiation until the 1165 end of the corresponding response header is received. An 1166 exception is that clients can and SHOULD perform TLS re- 1167 negotiation as a response to the server's request for TLS 1168 renegotiation, before receipt of the beginning of the response 1169 header. 1171 Also, implementers MUST take care of session resumption attacks 1172 regarding tls-unique channel binding mechanisms and master secrets. 1173 As a mitigation, a TLS extension defined in [RFC7627] SHOULD be used 1174 when tls-unique host verification is to be used. 1176 8. Authentication Extensions 1178 Interactive clients (e.g., Web browsers) supporting this protocol are 1179 RECOMMENDED to support non-mandatory authentication and the 1180 Authentication-Control header defined in 1181 [I-D.ietf-httpauth-extension], except for the "auth-style" parameter. 1182 This specification also proposes (however, does not mandate) the 1183 default "auth-style" be "non-modal". Web applications SHOULD however 1184 consider the security impacts of the behaviors of clients that do not 1185 support these headers. 1187 Authentication-initializing messages with the 1188 Optional-WWW-Authenticate header are used only where the 401-INIT 1189 response is valid. It will not replace other 401-type messages such 1190 as 401-STALE and 401-KEX-S1. 1192 9. String Preparation 1194 It is important for interoperability that user names and passwords 1195 used in this protocol are binary-comparable regardless of the user's 1196 input methods and/or environments. To ensure this, the following 1197 preparation SHOULD be performed: 1199 o User names received from users SHOULD be prepared using the 1200 "UsernameCasePreserved" profile defined in Section 3.3 of 1201 [RFC7613]. 1203 o Passwords received from users SHOULD be prepared using the 1204 "OpaqueString" profile defined in Section 4.2 of [RFC7613]. 1206 In both cases, it is the sender's duty to correctly prepare the 1207 character strings. If any non-normalized character string is 1208 received from the other peer of the communication, recipients MAY 1209 either use it as a bare UTF-8 string without any preparation, perform 1210 any appropriate preparations (which may cause authentication 1211 failure), or reject any ill-prepared inputs from the sender and 1212 respond as a communication error. 1214 Server applications SHOULD also prepare user names and passwords 1215 accordingly upon registration of user credentials. 1217 In addition, binary-based "interfaces" of implementations MAY require 1218 and assume that the string is already prepared accordingly; when a 1219 string is already stored as a binary Unicode string form, 1220 implementations MAY omit preparation and Unicode normalization 1221 (performing UTF-8 encoding only) before using it. When a string is 1222 already stored as an octet blob, implementations MAY send it as is. 1224 10. Decision Procedure for Clients 1226 10.1. General Principles and Requirements 1228 To securely implement the protocol, the client must be careful about 1229 accepting the authenticated responses from the server. This also 1230 holds true for the reception of "normal responses" (responses which 1231 do not contain Mutual authentication-related headers) from HTTP 1232 servers. 1234 As usual in the HTTP authentication, a single user-level request may 1235 result in exchange of two-or-more HTTP requests and responses in 1236 sequence. The following normative rules MUST be followed by the 1237 clients implementing this protocol: 1239 o Any kinds of "normal responses" MUST only be accepted for the very 1240 first request in the sequence. Any "normal responses" returned 1241 for the second or later requests in the sequence SHALL be 1242 considered invalid. 1244 o In the same principle, any responses which refer to or request 1245 changing to an authentication realm different from the client's 1246 request MUST only be accepted for the very first request in the 1247 sequence. Any kind of responses referring to different realms 1248 which are returned for the second or later requests in the 1249 sequence SHALL be considered invalid. 1251 o A req-KEX-C1 message MAY be sent either as a initial request or as 1252 a response to 401-INIT or 401-STALE. However, it SHOULD NOT be 1253 sent more than once in the sequence for a single authentication 1254 realm, to avoid infinite loops of messages. A 401-KEX-S1 response 1255 MUST be accepted only when the corresponding request is 1256 req-KEX-C1. 1258 o A req-VFY-C message MAY be sent if there is a valid session key 1259 shared between the client and the server, established by 1260 req-KEX-C1 and 401-KEX-S1. If any response with 401 status is 1261 returned for such a message, the corresponding session key SHOULD 1262 be discarded as unusable. 1263 Especially, upon the reception of a 401-STALE response, the client 1264 SHOULD try establishing a new session by sending req-KEX-C1, but 1265 only once within the request/response sequence. 1267 o A 200-VFY-S message MUST be accepted only as a response to 1268 req-VFY-C and nothing else. The VK_s values of such response 1269 messages MUST always be checked against the correct value, and if 1270 it is incorrect, the whole response SHOULD be considered invalid. 1272 The final status of the client request following the message exchange 1273 sequence shall be determined as follows: 1275 o AUTH-SUCCEED: A 200-VFY-S message with the correct VK_s value was 1276 returned in response to the req-VFY-C request in the sequence. 1278 o AUTH-REQUIRED: Two cases exists. 1280 * A 401-INIT message was returned from the server, and the client 1281 does not know how to authenticate to the given authentication 1282 realm. 1284 * A 401-INIT response was returned for req-VFY-C (or req-KEX-C1), 1285 which means the user-supplied authentication credentials were 1286 not accepted. 1288 o UNAUTHENTICATED: a normal response is returned for an initial 1289 request of any kind in the sequence. 1291 Any kind of response (including a normal response) other than those 1292 explicitly allowed in the above rules SHOULD be interpreted as a 1293 fatal communication error. In such cases, the clients MUST NOT 1294 process any data (the response body and other content-related 1295 headers) sent from the server. However, to handle exceptional error 1296 cases, clients MAY accept a message without an Authentication-Info 1297 header, if it has a Server-Error (5xx) status code. In such cases, 1298 they SHOULD be careful about processing the body of the content 1299 (ignoring it is still RECOMMENDED, as it may possibly be forged by 1300 intermediate attackers), and the client will be in the 1301 "UNAUTHENTICATED" status then. 1303 If a request is a sub-request for a resource included in another 1304 resource (e.g., embedded images, style sheets, frames etc.), clients 1305 MAY treat an AUTH-REQUESTED status as the same as an UNAUTHENTICATED 1306 status. In other words, the client MAY ignore server's request to 1307 start authentication with new credentials via sub-requests. 1309 10.2. State machine for the client (informative) 1311 The following state machine describes the possible request-response 1312 sequences derived from the above normative rules. If implementers 1313 are not quite sure on the security consequences of the above rules, 1314 it is strongly advised to follow the decision procedure below. In 1315 particular, clients SHOULD NOT accept "normal responses" unless 1316 explicitly allowed in the rules. The labels on the steps are for 1317 informational purposes only. Action entries within each step are 1318 checked in top-to-bottom order, and the first clause satisfied is to 1319 be followed. 1321 Step 1 (step_new_request): 1322 If the client software needs to access a new Web resource, check 1323 whether the resource is expected to be inside some authentication 1324 realm for which the user has already been authenticated by the 1325 Mutual authentication scheme. If yes, go to Step 2. Otherwise, 1326 go to Step 5. 1328 Step 2: 1329 Check whether there is an available sid for the expected 1330 authentication realm. If there is one, go to Step 3. Otherwise, 1331 go to Step 4. 1333 Step 3 (step_send_vfy_1): 1334 Send a req-VFY-C request. 1336 * If you receive a 401-INIT message with a different 1337 authentication realm than expected, go to Step 6. 1339 * If a 401-STALE message is received, go to Step 9. 1341 * If a 401-INIT message is received, go to Step 13. 1343 * If a 200-VFY-S message is received, go to Step 14. 1345 * If a normal response is received, go to Step 11. 1347 Step 4 (step_send_kex1_1): 1348 Send a req-KEX-C1 request. 1350 * If a 401-INIT message is received with a different 1351 authentication realm than expected, go to Step 6. 1353 * If a 401-KEX-S1 message is received, go to Step 10. 1355 * If a 401-INIT message is received with the same authentication 1356 realm, go to Step 13 (see Note 1). 1358 * If a normal response is received, go to Step 11. 1360 Step 5 (step_send_normal_1): 1361 Send a request without any Mutual authentication headers. 1363 * If a 401-INIT message is received, go to Step 6. 1365 * If a normal response is received, go to Step 11. 1367 Step 6 (step_rcvd_init): 1368 Check whether the user's password for the requested 1369 authentication realm is known. If yes, go to Step 7. Otherwise, 1370 go to Step 12. 1372 Step 7: 1373 Check whether there is an available sid for the expected 1374 authentication realm. If there is one, go to Step 8. Otherwise, 1375 go to Step 9. 1377 Step 8 (step_send_vfy): 1378 Send a req-VFY-C request. 1380 * If a 401-STALE message is received, go to Step 9. 1382 * If a 401-INIT message is received, go to Step 13. 1384 * If a 200-VFY-S message is received, go to Step 14. 1386 Step 9 (step_send_kex1): 1387 Send a req-KEX-C1 request. 1389 * If a 401-KEX-S1 message is received, go to Step 10. 1391 * If a 401-INIT message is received, go to Step 13 (See Note 1). 1393 Step 10 (step_rcvd_kex1): 1394 Send a req-VFY-C request. 1396 * If a 401-INIT message is received, go to Step 13. 1398 * If a 200-VFY-S message is received, go to Step 14. 1400 Step 11 (step_rcvd_normal): 1401 The requested resource is out of the authenticated area. The 1402 client will be in the "UNAUTHENTICATED" status. If the response 1403 contains a request for authentications other than Mutual, it MAY 1404 be handled normally. 1406 Step 12 (step_rcvd_init_unknown): 1407 The requested resource requires Mutual authentication, and the 1408 user is not yet authenticated. The client will be in the "AUTH- 1409 REQUESTED" status, and is RECOMMENDED to process the content sent 1410 from the server, and to ask the user for a user name and a 1411 password. When those are supplied from the user, proceed to Step 1412 9. 1414 Step 13 (step_rcvd_init_failed): 1415 For some reason the authentication failed: possibly the password 1416 or the username is invalid for the authenticated resource. 1417 Forget the user-provided credentials for the authentication realm 1418 and go to Step 12. 1420 Step 14 (step_rcvd_vfy): 1421 The received message is the 200-VFY-S message, which always 1422 contains a vks field. Check the validity of the received VK_s 1423 value. If it is equal to the expected value, it means that the 1424 mutual authentication has succeeded. The client will be in the 1425 "AUTH-SUCCEEDED" status. 1427 If the value is unexpected, it is a fatal communication error. 1429 If a user explicitly requests to log out (via the user 1430 interface), the client MUST forget the user's password, go to 1431 step 5, and reload the current resource without an authentication 1432 header. 1434 Note 1: These transitions MAY be accepted by clients, but are 1435 NOT RECOMMENDED for servers to initiate. 1437 Figure 5 shows an informative diagram of the client state. 1439 =========== -(11)------------ 1440 NEW REQUEST ( UNAUTHENTICATED ) 1441 =========== ----------------- 1442 | ^ normal 1443 v | response 1444 +(1)-------------------+ NO +(5)----------+ 1445 | The requested URI |--------------------------->| send normal | 1446 | known to be auth'ed? | | request | 1447 +----------------------+ +-------------+ 1448 YES | 401-INIT 401-INIT| 1449 | with a different realm | 1450 | -----------------------------------. | 1451 | / v v 1452 | | -(12)------------ NO +(6)--------+ 1453 | | ( AUTH-REQUESTED )<------| user/pass | 1454 | | ----------------- | known? | 1455 | | +-----------+ 1456 | | |YES 1457 v | v 1458 +(2)--------+ | +(7)--------+ 1459 | session | | | session | NO 1460 NO /| available?| | | available?|\ 1461 / +-----------+ | +-----------+ | 1462 / |YES | |YES | 1463 | | /| | | 1464 | v / | 401- 401- v | 1465 | +(3)--------+ | INIT --(13)---------- INIT +(8)--------+ | 1466 | | send |--+----->/ AUTH-REQUESTED \<-------| send | | 1467 | /| req-VFY-C | | \forget password / | req-VFY-C | | 1468 \/ +-----------+ / ---------------- /+-----------+ | 1469 /\ \ \/ ^ 401-INIT | |401- | 1470 | ------ \/\ 401-STALE | | | STALE / 1471 | \ /\ -----------------+--------------+---. | / 1472 | | / \ | | | | / 1473 | v / | 401- | 401- | v v v 1474 | +(4)--------+ | KEX-S1 +(10)-------+ KEX-S1 | +(9)--------+ 1475 | | send |-|--------->| send |<-------+-| send | 1476 | --| req-KEX-C1| | | req-VFY-C | | | req-KEX-C1| 1477 |/ +-----------+ | +-----------+ | +-----------+ 1478 | |200-VFY-S | 200-VFY-S| ^ 1479 |normal | |200-VFY-S / | 1480 |response | v / ================== 1481 v \ -(14)--------- / USER/PASS INPUTTED 1482 -(11)------------ ------->( AUTH-SUCCEED )<-- ================== 1483 ( UNAUTHENTICATED ) -------------- 1484 ----------------- 1486 Figure 5: State diagram for clients 1488 11. Decision Procedure for Servers 1490 Each server SHOULD have a table of session states. This table need 1491 not be persistent over the long term; it MAY be cleared upon server 1492 restart, reboot, or for other reasons. Each entry in the table 1493 SHOULD contain at least the following information: 1495 o The session identifier, which is the value of the sid parameter. 1497 o The algorithm used. 1499 o The authentication realm. 1501 o The state of the protocol: one of "key exchanging", 1502 "authenticated", "rejected", or "inactive". 1504 o The user name received from the client. 1506 o A boolean flag representing whether or not the session is fake. 1508 o When the state is "key exchanging", the values of K_c1 and S_s1. 1510 o When the state is "authenticated", the following information: 1512 * The value of the session secret, z 1514 * The largest nc received from the client (largest-nc) 1516 * For each possible nc values between (largest-nc - nc- 1517 window + 1) and max_nc, a boolean flag whether or not a request 1518 with the corresponding nc has been received. 1520 The table MAY contain other information. 1522 Servers SHOULD respond to the client requests according to the 1523 following procedure: (See Note 1 below for 401-INIT message with a 1524 plus sign) 1526 o When the server receives a normal request: 1528 * If the requested resource is not protected by the Mutual 1529 authentication, send a normal response. 1531 * If the resource is protected by the Mutual authentication, send 1532 a 401-INIT response. 1534 o When the server receives a req-KEX-C1 request: 1536 * If the requested resource is not protected by the Mutual 1537 authentication, send a normal response. 1539 * If the authentication realm specified in the req-KEX-C1 request 1540 is not the expected one, send a 401-INIT response. 1542 * If the server cannot validate the parameter kc1, send a 1543 401-INIT (+) response. 1545 * If the received user name is either invalid, unknown or 1546 unacceptable, create a new session, mark it a "fake" session, 1547 compute a random value as K_s1, and send a fake 401-KEX-S1 1548 response. (See Note 2.) 1550 * Otherwise, create a new session, compute K_s1 and send a 1551 401-KEX-S1 response. The created session is marked as not 1552 fake, and its largest-nc is initialized to zero. 1554 The created session has the "key exchanging" state. 1556 o When the server receives a req-VFY-C request: 1558 * If the requested resource is not protected by the Mutual 1559 authentication, send a normal response. 1561 * If the authentication realm specified in the req-VFY-C request 1562 is not the expected one, send a 401-INIT response. 1564 If none of above holds true, the server will look up the session 1565 corresponding to the received sid and the authentication realm. 1567 * If the session corresponding to the received sid could not be 1568 found, or it is in the "inactive" state, send a 401-STALE 1569 response. 1571 * If the session is in the "rejected" state, send either a 1572 401-INIT (+) or a 401-STALE message. 1574 * If the nc value in the request is larger than the nc-max 1575 parameter sent from the server, or if it is not larger then 1576 (largest-nc - nc-window) (when in "authenticated" status), the 1577 server MAY (but is not REQUIRED to; See Note 3) send a 1578 401-STALE message. The session SHOULD be changed to the 1579 "inactive" state if so. 1581 * If the session is in the "authenticated" state, and the request 1582 has an nc value that was previously received from the client, 1583 send a 401-STALE message. The session SHOULD be changed to the 1584 "inactive" state. 1586 * If the session is a "fake" session, or if the received vkc is 1587 incorrect, then send a 401-INIT (+) response. If the session 1588 is in the "key exchanging" state, it SHOULD be changed to the 1589 "rejected" state; otherwise, it MAY either be changed to the 1590 "rejected" state or kept in the previous state. 1592 * Otherwise, send a 200-VFY-S response. If the session was in 1593 the "key exchanging" state, the session SHOULD be changed to an 1594 "authenticated" state. The maximum nc and nc flags of the 1595 state SHOULD be updated appropriate. 1597 At any time, the server MAY change any state entries with both the 1598 "rejected" and "authenticated" states to the "inactive" status, and 1599 MAY discard any "inactive" states from the table. Entries with the 1600 "key exchanging" state SHOULD be kept unless there is an emergency 1601 situation such as a server reboot or a table capacity overflow. 1603 Note 1: In relation with and following the specification of the 1604 optional authentication defined in [I-D.ietf-httpauth-extension], the 1605 401-INIT messages marked with the pluses cannot be replaced with a 1606 successful responses with an Optional-WWW-Authenticate header. Every 1607 other 401-INIT can be a response with an Optional-WWW-Authenticate. 1609 Note 2: the server SHOULD NOT send a 401-INIT response in this case, 1610 because it will leak the information to the client that the specified 1611 user name will not be accepted. Instead, postpone it to the response 1612 for the next req-VFY-C request. 1614 Note 3: The next case implies that, when the request is not rejected 1615 under this clause, the server MUST be decidable whether the same nc 1616 value was previously received from the client. If the server does 1617 not remember a whole history of the nc values received from the 1618 client, the server MUST send a 401-STALE message in this clause. 1620 12. Authentication Algorithms 1622 Cryptographic authentication algorithms which are used with this 1623 protocol will be defined separately. The algorithm definition MUST 1624 at least provide definitions for the following functions: 1626 o The server-side authentication credential J, derived from client- 1627 side authentication credential pi. 1629 o Key exchange values K_c1, K_s1 (exchanged on wire) and S_c1, S_s1 1630 (kept secret in each peer). 1632 o Shared secret z, to be computed by both server and client. 1634 o A hash function H to be used with the protocol, along with its 1635 output size hSize. 1637 o The number of iterations for password hashing nIterPi, if it uses 1638 the default password hashing function defined below. 1640 Specifications for cryptographic algorithms used with this framework 1641 MUST specify whether these will use the default functions defined 1642 below for values pi, VK_c, and VK_s; or, these will define their own 1643 versions for these. 1645 All algorithm used with this protocol SHOULD provide secure mutual 1646 authentication between client and servers, and generate a 1647 cryptographically strong shared secret value z, equivalently strong 1648 to or stronger than the hash function H. If any passwords (or pass- 1649 phrases or any equivalents, i.e., weak secrets) are involved, these 1650 SHOULD NOT be guessable from any data transmitted in the protocol, 1651 even if an attacker (either an eavesdropper or an active server) 1652 knows the possible thoroughly-searchable candidate list of the 1653 passwords. Furthermore, if possible, the function J for deriving 1654 server-side authentication credential J(pi) is RECOMMENDED to be one- 1655 way so that pi should not be easily computed from J(pi). 1657 12.1. Support Functions and Notations 1659 In this section we define several support functions and notations to 1660 be shared by several algorithm definitions. 1662 The integers in the specification are in decimal, or in hexadecimal 1663 when prefixed with "0x". 1665 The function octet(i) generates an octet string containing a single 1666 octet of value i. The operator |, when applied to octet strings, 1667 denotes the concatenation of two operands. 1669 The function VI encodes natural numbers into octet strings in the 1670 following manner: numbers are represented as big-endian radix-128 1671 strings, where each digit is represented by an octet within the range 1672 0x80-0xff except the last digit, which is represented by a octet 1673 within the range 0x00-0x7f. The first octet MUST NOT be 0x80. For 1674 example, VI(i) = octet(i) for i < 128, and VI(i) = octet(0x80 + (i >> 1675 7)) | octet(i & 127) for 128 <= i < 16384. This encoding is the same 1676 as the one used for the sub-components of object identifiers in the 1677 ASN.1 encoding [ITU.X690.1994], and available as a "w" conversion in 1678 the "pack" function of several scripting languages. 1680 The function VS encodes a variable-length octet string into a 1681 uniquely-decoded, self-delimited octet string, as in the following 1682 manner: 1684 VS(s) = VI(length(s)) | s 1686 where length(s) is a number of octets (not characters) in s. 1688 Some examples: 1690 VI(0) = "\000" (in C string notation) 1692 VI(100) = "d" 1694 VI(10000) = "\316\020" 1696 VI(1000000) = "\275\204@" 1698 VS("") = "\000" 1700 VS("Tea") = "\003Tea" 1702 VS("Caf" [in UTF-8]) = "\005Caf\303\251" 1704 VS([10000 "a"s]) = "\316\020aaaaa..." (10002 octets) 1706 (Note: Unlike the colon-separated notion used in the Basic/Digest 1707 HTTP authentication scheme, the string generated by a concatenation 1708 of the VS-encoded strings will be unique, regardless of the 1709 characters included in the strings to be encoded.) 1711 The function OCTETS converts an integer into the corresponding radix- 1712 256 big-endian octet string having its natural length. See 1713 Section 3.2.3 for the definition of "natural length". 1715 The function INT converts an octet string into a natural number, 1716 where the input string is treated as being in radix-256 big-endian 1717 notation. The identity INT(OCTETS(n)) = n always holds for any 1718 natural number n. 1720 12.2. Default Functions for Algorithms 1722 The functions defined in this section are common default functions 1723 among authentication algorithms. 1725 The client-side password-based (credential) pi used by this 1726 authentication is a natural number derived in the following manner: 1728 pi = INT(PBKDF2(HMAC_H, password, VS(algorithm) | VS(auth-scope) | 1729 VS(realm) | VS(username), nIterPi, hSize / 8)), 1731 where 1733 o PBKDF2 is the password-based key derivation function defined in 1734 [RFC2898], 1736 o HMAC_H is the HMAC function, defined in [RFC2104], composed from 1737 the hash function H, and 1739 o hSize is the output size of hash H in bits. 1741 The values of algorithm, realm, and auth-scope are taken from the 1742 values contained in the 401-INIT message. If the password comes from 1743 user input, it SHOULD first be prepared according to the method 1744 presented in Section 9. Then, the password SHALL be encoded as a 1745 UTF-8 string. 1747 The values VK_c and VK_s are derived by the following equation. 1749 VK_c = INT(H(octet(4) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | 1750 VI(nc) | VS(vh))) 1752 VK_s = INT(H(octet(3) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | 1753 VI(nc) | VS(vh))) 1755 13. Application Channel Binding 1757 Applications and upper-layer communication protocols may need 1758 authentication binding to the HTTP-layer authenticated user. Such 1759 applications MAY use the following values as a standard shared 1760 secret. 1762 These values are parameterized with an optional octet string (t) 1763 which may be arbitrarily chosen by each application or protocol. If 1764 there is no appropriate value to be specified, use an empty string 1765 for t. 1767 For applications requiring binding to either an authenticated user or 1768 a shared-key session (to ensure that the requesting client is 1769 certainly authenticated), the following value b_1 MAY be used. 1771 b_1 = H(H(octet(6) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(0) 1772 | VS(vh)) | VS(t)). 1774 For applications requiring binding to a specific request (to ensure 1775 that the payload data is generated for the exact HTTP request), the 1776 following value b_2 MAY be used. 1778 b_2 = H(H(octet(7) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VI(nc) 1779 | VS(vh)) | VS(t)). 1781 Note: Channel bindings to lower-layer transports (TCP and TLS) are 1782 defined in Section 7. 1784 14. Application for Proxy Authentication 1786 The authentication scheme defined by the previous sections can be 1787 applied (with modifications) for proxy authentication. In such 1788 cases, the following alterations MUST be applied: 1790 o The 407 status is to be sent and recognized in places where the 1791 401 status is used, 1793 o Proxy-Authenticate header is to be used in places where WWW- 1794 Authenticate is used, 1796 o Proxy-Authorization header is to be used in places where 1797 Authorization is used, 1799 o Proxy-Authentication-Info header is to be used in places where 1800 Authentication-Info is used, 1802 o The auth-scope parameter is fixed to the host-name of the proxy, 1803 which means it covers all requests processed through the specific 1804 proxy, 1806 o The limitation for the paths contained in the path parameter of 1807 401-KEX-S1 messages is disregarded, 1809 o The omission of the path parameter of 401-KEX-S1 messages means 1810 that the authentication realm will potentially cover all requests 1811 processed by the proxy, 1813 o The scheme, host name, and the port of the proxy is used for host 1814 validation tokens, and 1816 o Authentication extensions in [I-D.ietf-httpauth-extension] are not 1817 applicable. 1819 15. Methods to Extend This Protocol 1821 If a private extension to this protocol is implemented, it MUST use 1822 the extension-tokens defined in Section 3 to avoid conflicts with 1823 this protocol and other extensions. (Standardized or being- 1824 standardized extensions MAY use either bare-tokens or extension- 1825 tokens.) 1827 Specifications defining authentication algorithms MAY use other 1828 representations for the parameters "kc1", "ks1", "vkc", and "vks", 1829 replace those parameter names, and/or add parameters to the messages 1830 containing those parameters in supplemental specifications, provided 1831 that syntactic and semantic requirements in Section 3, [RFC7230] and 1832 [RFC7235] are satisfied. Any parameters starting with "kc", "ks", 1833 "vkc" or "vks" and followed by decimal natural numbers (e.g. kc2, 1834 ks0, vkc1, vks3 etc.) are reserved for this purpose. If those 1835 specifications use names other than those mentioned above, it is 1836 RECOMMENDED to use extension-tokens to avoid any parameter name 1837 conflict with future extensions to this protocol. 1839 Extension-tokens MAY be freely used for any non-standard, private, 1840 and/or experimental uses for those parameters provided that the 1841 domain part in the token is used in the manner defined in Section 3. 1843 16. IANA Considerations 1845 When bare-tokens are used for the authentication-algorithm, pwd-hash, 1846 and validation parameters, these MUST be allocated by IANA. To 1847 acquire registered tokens, a specification for the use of such tokens 1848 MUST be reviewed by a designated expert, as outlined in [RFC5226]. 1850 16.1. Registry for Authentication Algorithms 1852 This document establishes a registry for HTTP Mutual authentication 1853 algorithms. The registry manages case-insensitive ASCII strings. 1854 The strings MUST follow the extensive-token syntax defined in 1855 Section 3. 1857 Registrations for an authentication algorithm are required to include 1858 a description of the authentication algorithms. Reviewers assigned 1859 by IESG are advised to examine minimum security requirements and 1860 consistency of the key exchange algorithm descriptions. 1862 New registrations are advised to provide the following information: 1864 o Token: a token used in HTTP headers for identifying the algorithm. 1866 o Description: A brief description of the algorithm. 1868 o Specification: A reference for a specification defining the 1869 algorithm. 1871 The initial content of this registry is empty. [[Editorial Note: A 1872 separate document [I-D.ietf-httpauth-mutual-algo] will effectively 1873 define the initial content of the registry.]] 1875 16.2. Registry for Validation Methods 1877 This document establishes a registry for HTTP Mutual authentication 1878 host validation methods. The registry manages case-insensitive ASCII 1879 strings. The strings MUST follow the extensive-token syntax defined 1880 in Section 3. 1882 Registrations for a validation method are required to include a 1883 description of the validation method. Reviewers assigned by IESG are 1884 advised to examine its use-case requirements and security consequence 1885 of its introduction. 1887 New registrations are advised to provide the following information: 1889 o Token: a token used in HTTP headers for identifying the method. 1891 o Description: A brief description of the method. 1893 o Specification: A reference for a specification defining the 1894 method. 1896 The initial content of this registry is as follows: 1898 +----------------------+----------------------------+---------------+ 1899 | Token | Description | Specification | 1900 +----------------------+----------------------------+---------------+ 1901 | host | Host name verification | Section 7 | 1902 | | only | | 1903 | tls-server-end-point | TLS certificate-based | Section 7 | 1904 | tls-unique | TLS unique key-based | Section 7 | 1905 +----------------------+----------------------------+---------------+ 1907 17. Security Considerations 1909 17.1. Security Properties 1910 o The protocol is secure against passive eavesdropping and replay 1911 attacks. However, the protocol relies on transport security 1912 including DNS integrity for data secrecy and integrity. HTTP/TLS 1913 SHOULD be used where transport security is not assured and/or data 1914 confidentiality is important. 1916 o When used with HTTP/TLS, if TLS server certificates are reliably 1917 verified, the protocol provides true protection against active 1918 man-in-the-middle attacks. 1920 o Even if the server certificate is not used or is unreliable, the 1921 protocol provides protection against active man-in-the-middle 1922 attacks for each HTTP request/response pair. However, in such 1923 cases, JavaScript or similar scripting facilities can be used to 1924 affect the Mutually-authenticated contents from other contents not 1925 protected by this authentication mechanism. This is the reason 1926 why this protocol requires that valid TLS server certificates MUST 1927 be presented (Section 7). 1929 17.2. Denial-of-service Attacks to Servers 1931 The protocol requires a server-side table of active sessions, which 1932 may become a critical point for server resource consumption. For 1933 proper operation, the protocol requires that at least one key 1934 verification request is processed for each session identifier. After 1935 that, servers MAY discard sessions internally at any time, without 1936 causing any operational problems to clients. Clients will silently 1937 reestablish a new session then. 1939 However, if a malicious client sends too many requests for key 1940 exchanges (req-KEX-C1 messages) only, resource starvation might 1941 occur. In such critical situations, servers MAY discard any kind of 1942 existing sessions regardless of their statuses. One way to mitigate 1943 such attacks is that servers MAY have a number and a time limit for 1944 unverified, pending key exchange requests (in the "key exchanging" 1945 state). 1947 This is a common weakness of authentication protocols with almost any 1948 kind of negotiations or states, including Digest authentication 1949 scheme and most Cookie-based authentication implementations. 1950 However, regarding the resource consumption, the situation for the 1951 mutual authentication scheme is a slightly better than for Digest, 1952 because HTTP requests without any kind of authentication requests 1953 will not generate any kind of sessions. Session identifiers are only 1954 generated after a client starts a key negotiation. It means that 1955 simple clients such as Web crawlers will not accidentally consume 1956 server-side resources for session managements. 1958 17.2.1. On-line Active Password Attacks 1960 Although the protocol provides very strong protection against off- 1961 line dictionary attacks from eavesdropped traffic, the protocol, by 1962 its nature, cannot prevent active password attacks in which the 1963 attackers sends so many authentication trial requests for every 1964 possible password. 1966 Possible countermeasures for preventing such attacks may be rate- 1967 limiting of password authentication trials, statistics-based 1968 intrusion detection measures, or similar protection schemes. If the 1969 server operators assume that the passwords of users are not strong 1970 enough, it may be desirable to introduce such ad-hoc countermeasures. 1972 17.3. Communicating the status of mutual authentication with users 1974 This protocol is designed for two goals. The first goal is just 1975 providing a secure alternative for existing Basic and Digest 1976 authentication. The second goal is to provide users a way to detect 1977 forged rogue servers imitating a user's registered account on a 1978 server, commonly known as (a part or kind of) Phishing attacks. 1980 For this protocol to effectively work as some countermeasure to such 1981 attacks, it is very important that end users of clients be notified 1982 of the result of the mutual authentication performed by this 1983 protocol, especially the three states "AUTH-SUCCEED", 1984 "UNAUTHENTICATED", and "AUTH-REQUIRED" defined in Section 10. The 1985 design of secure user interfaces of the HTTP interactive clients is 1986 out of the scope of this document, but if possible, having some kind 1987 of UI indication for the three states above will be desirable for the 1988 user's security benefit. 1990 Of course, in such cases, the user interfaces for asking passwords 1991 for this authentication shall be clearly identifiable against 1992 imitation by other insecure password input fields (such as forms). 1993 If the passwords are known to malicious attackers outside of the 1994 protocol, the protocol cannot work as an effective security measures. 1996 17.4. Implementation Considerations 1998 o To securely implement the protocol, the Authentication-Info 1999 headers in the 200-VFY-S messages MUST always be validated by the 2000 client. If the validation fails, the client MUST NOT process any 2001 content sent with the message, including other headers and the 2002 body part. Non-compliance to this requirement will allow phishing 2003 attacks. 2005 o For HTTP/TLS communications, when a web form is submitted from 2006 Mutually-authenticated pages with the "tls-server-end-point" 2007 validation method to a URI that is protected by the same realm (so 2008 indicated by the path parameter), if the server certificate has 2009 been changed since the pages were received, the peer is 2010 RECOMMENDED to be re-validated using a req-KEX-C1 message with an 2011 "Expect: 100-continue" header. The same applies when the page is 2012 received with the "tls-unique" validation method, and when the TLS 2013 session has expired. 2015 o For better protection against possible password database stealing, 2016 server-side storage of user passwords should contain the values 2017 encrypted by the one-way function J(pi), instead of the real 2018 passwords or those hashed by pi. 2020 17.5. Usage Considerations 2022 o The user names inputted by a user may be sent automatically to any 2023 servers sharing the same auth-scope. This means that when a host- 2024 type auth-scope is used for authentication on an HTTPS site, and 2025 when an HTTP server on the same host requests Mutual 2026 authentication within the same realm, the client will send the 2027 user name in clear text. If user names have to be kept secret 2028 against eavesdropping, the server must use the full-scheme-type 2029 auth-scope parameter and HTTPS. Contrarily, passwords are not 2030 exposed to eavesdroppers even on HTTP requests. 2032 o If the server provides several ways for storing server-side 2033 password secrets in the password database, it is desirable for 2034 better security to store the values encrypted by using the one-way 2035 function J(pi), instead of the real passwords or those hashed by 2036 pi. 2038 18. Notice on Intellectual Properties 2040 The National Institute of Advanced Industrial Science and Technology 2041 (AIST) and Yahoo! Japan, Inc. have jointly submitted a patent 2042 application to the Patent Office of Japan for the protocol proposed 2043 in this documentation. The patent is intended to be open to any 2044 implementer of this protocol and its variants under non-exclusive 2045 royalty-free terms. For the details of the patent application and 2046 its status, please contact the authors of this document. 2048 The elliptic-curve based authentication algorithms might involve 2049 several existing third-party patents. The authors of the document 2050 take no position regarding the validity or scope of such patents and 2051 other patents as well. 2053 19. References 2055 19.1. Normative References 2057 [I-D.ietf-httpauth-extension] 2058 Oiwa, Y., Watanabe, H., Takagi, H., Hayashi, T., and Y. 2059 Ioku, "HTTP Authentication Extensions for Interactive 2060 Clients", draft-ietf-httpauth-extension-06 (work in 2061 progress), January 2016. 2063 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2064 Hashing for Message Authentication", RFC 2104, 2065 DOI 10.17487/RFC2104, February 1997, 2066 . 2068 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2069 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 2070 RFC2119, March 1997, 2071 . 2073 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 2074 Specification Version 2.0", RFC 2898, DOI 10.17487/ 2075 RFC2898, September 2000, 2076 . 2078 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2079 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 2080 November 2003, . 2082 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2083 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2084 . 2086 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2087 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 2088 RFC5234, January 2008, 2089 . 2091 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2092 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 2093 RFC5246, August 2008, 2094 . 2096 [RFC5987] Reschke, J., "Character Set and Language Encoding for 2097 Hypertext Transfer Protocol (HTTP) Header Field 2098 Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010, 2099 . 2101 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2102 Protocol (HTTP/1.1): Message Syntax and Routing", 2103 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2104 . 2106 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2107 Protocol (HTTP/1.1): Authentication", RFC 7235, 2108 DOI 10.17487/RFC7235, June 2014, 2109 . 2111 [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, 2112 Enforcement, and Comparison of Internationalized Strings 2113 Representing Usernames and Passwords", RFC 7613, 2114 DOI 10.17487/RFC7613, August 2015, 2115 . 2117 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- 2118 Authentication-Info Response Header Fields", RFC 7615, 2119 DOI 10.17487/RFC7615, September 2015, 2120 . 2122 19.2. Informative References 2124 [I-D.ietf-httpauth-mutual-algo] 2125 Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 2126 T., and Y. Ioku, "Mutual Authentication Protocol for HTTP: 2127 KAM3-based Cryptographic Algorithms", 2128 draft-ietf-httpauth-mutual-algo-05 (work in progress), 2129 January 2016. 2131 [ISO.10646-1.1993] 2132 International Organization for Standardization, 2133 "Information Technology - Universal Multiple-octet coded 2134 Character Set (UCS) - Part 1: Architecture and Basic 2135 Multilingual Plane", ISO Standard 10646-1, May 1993. 2137 [ITU.X690.1994] 2138 International Telecommunications Union, "Information 2139 Technology - ASN.1 encoding rules: Specification of Basic 2140 Encoding Rules (BER), Canonical Encoding Rules (CER) and 2141 Distinguished Encoding Rules (DER)", ITU-T Recommendation 2142 X.690, 1994. 2144 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 2145 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 2146 . 2148 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 2149 RFC2818, May 2000, 2150 . 2152 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2153 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2154 DOI 10.17487/RFC5226, May 2008, 2155 . 2157 [RFC5890] Klensin, J., "Internationalized Domain Names for 2158 Applications (IDNA): Definitions and Document Framework", 2159 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2160 . 2162 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 2163 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 2164 . 2166 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 2167 DOI 10.17487/RFC6265, April 2011, 2168 . 2170 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 2171 DOI 10.17487/RFC6454, December 2011, 2172 . 2174 [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 2175 Preparation, Enforcement, and Comparison of 2176 Internationalized Strings in Application Protocols", 2177 RFC 7564, DOI 10.17487/RFC7564, May 2015, 2178 . 2180 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 2181 Digest Access Authentication", RFC 7616, DOI 10.17487/ 2182 RFC7616, September 2015, 2183 . 2185 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 2186 Langley, A., and M. Ray, "Transport Layer Security (TLS) 2187 Session Hash and Extended Master Secret Extension", 2188 RFC 7627, DOI 10.17487/RFC7627, September 2015, 2189 . 2191 Appendix A. (Informative) Draft Change Log 2193 [To be removed on final publication] 2195 A.1. Changes in Httpauth WG Revision 07 2197 o Several comments from reviewers are reflected to the text. 2199 o The password-hash has been completely dropped. 2201 o The version token is raised to "1". 2203 A.2. Changes in Httpauth WG Revision 06 2205 o The auth-domain parameter has been renamed to auth-scope, 2206 following suggestions on the mailing list. 2208 o The digest-md5 password-hash has been dropped, as Digest with MD5 2209 hash is now obsoleted. 2211 A.3. Changes in Httpauth WG Revision 05 2213 o Minimum nonce number window has increased to 128. (HTTP 2.0 2214 recommends at least 100 concurrent sessions to exist) 2216 o Reference to TLS session hash extension added for tls-unique 2217 security issues. 2219 o Comments in the previous F2F meeting has been reflected to the 2220 text. 2222 A.4. Changes in Httpauth WG Revision 04 2224 o Merged httpauthprep proposal into general PRECIS Username/Password 2225 profile. 2227 o Adopting RFC 5987 extended syntax for non-ASCII parameter values. 2229 o Refer draft-ietf-httpbis-auth-info for Authentication-Info header. 2230 This results in a different syntax for that header. 2232 A.5. Changes in Httpauth WG Revision 03 2234 o Incompatible change: Single-port type authentication realm label 2235 has been changed to harmonize with Web Origin. (That is, the 2236 default ports (80 and 443) are to be omitted.) 2238 A.6. Changes in Httpauth WG Revision 02 2240 o Major change: introduction of password-strengthening function 2241 PBKDF2. 2243 o Changed Section 10 to adopt "list of requirements" style. Strict 2244 definition of state machine is now a derived, informational 2245 definition. 2247 A.7. Changes in Httpauth WG Revision 01 2249 o Changed "tls-key" verification to "tls-unique" verification, and 2250 "tls-cert" to "tls-server-end-point", adopting RFC 5929. 2252 o Adopted PRECIS framework [RFC7564]. 2254 o Reverted reservation of "rekey-sid" and "rekey-method" parameters. 2256 o Degraded secure UI requirement to application note level, non- 2257 normative. 2259 o Adjusted levels of several requirements. 2261 o Added warning text for handling of exceptional 5XX responses. 2263 o Dropped several references for optional authentications, except 2264 one "Note". 2266 o Several textual fixes, improvements and revisions. 2268 A.8. Changes in Httpauth Revision 00 2270 o Changed the version token. 2272 o Renamed "verification tokens" to "Host verification tokens" and 2273 variables "v" to "vh" for clarification. (Back-ported from 2274 draft-oiwa-httpauth-multihop-template-00) 2276 A.9. Changes in HttpBis Revision 00 2278 None. 2280 A.10. Changes in Revision 12 2282 o Added a reason "authz-failed". 2284 A.11. Changes in Revision 11 2286 o Message syntax definition reverted to pre-07 style as httpbis-p1 2287 and p7 now defines a precise rule for parameter value parsing. 2289 o Replaced "stale" parameter with more informative/extensive 2290 "reason" parameter in 401-INIT and 401-STALE. 2292 o Reserved "rekey-sid" and "rekey-method" parameters for future 2293 extensions. 2295 o Added descriptions for replacing/non-replacing existing 2296 technologies. 2298 A.12. Changes in Revision 10 2300 o The authentication extension parts (non-mandatory authentication 2301 and authentication controls) are separated to yet another draft. 2303 o The default auth-domain parameter is changed to the full scheme- 2304 host-port syntax, which is consistent with usual HTTP 2305 authentication framework behavior. 2307 o Provision for application channel binding is added. 2309 o Provision for proxy access authentication is added. 2311 o Bug fix: syntax specification of sid parameter was wrong: it was 2312 inconsistent with the type specified in the main text (the bug 2313 introduced in -07 draft). 2315 o Terminologies for headers are changed to be in harmony with 2316 httpbis drafts (e.g. field to parameter). 2318 o Syntax definitions are changed to use HTTP-extended ABNF syntax, 2319 and only the header values are shown for header syntax, in harmony 2320 with httpbis drafts. 2322 o Names of parameters and corresponding mathematical values are now 2323 renamed to more informative ones. The following list shows 2324 correspondence between the new and the old names. 2326 +------------+----------+-------------------------------------------+ 2327 | new name | old name | description | 2328 +------------+----------+-------------------------------------------+ 2329 | S_c1, S_s1 | s_a, s_b | client/server-side secret randoms | 2330 | K_c1, K_s1 | w_a, w_b | client/server-side exchanged key | 2331 | | | components | 2332 | kc1, ks1 | wa, wb | parameter names for those | 2333 | VK_c, VK_s | o_a, o_b | client/server-side key verifiers | 2334 | vkc, vks | oa, ob | parameter names for those | 2335 | z | z | session secrets | 2336 +------------+----------+-------------------------------------------+ 2338 A.13. Changes in Revision 09 2340 o The (default) cryptographic algorithms are separated to another 2341 draft. 2343 o Names of the messages are changed to more informative ones than 2344 before. The following is the correspondence table of those names: 2346 +-------------------+-----------------+-----------------------------+ 2347 | new name | old name | description | 2348 +-------------------+-----------------+-----------------------------+ 2349 | 401-INIT | 401-B0 | initial response | 2350 | 401-STALE | 401-B0-stale | session key expired | 2351 | req-KEX-C1 | req-A1 | client->server key exchange | 2352 | 401-KEX-S1 | 401-B1 | server->client key exchange | 2353 | req-VFY-C | req-A3 | client->server auth. | 2354 | | | verification | 2355 | 200-VFY-S | 200-B4 | server->client auth. | 2356 | | | verification | 2357 | 200-Optional-INIT | 200-Optional-B0 | initial with non-mandatory | 2358 | | | authentication | 2359 +-------------------+-----------------+-----------------------------+ 2361 A.14. Changes in Revision 08 2363 o The English text has been revised. 2365 A.15. Changes in Revision 07 2367 o Adapt to httpbis HTTP/1.1 drafts: 2369 * Changed definition of extensive-token. 2371 * LWSP continuation-line (%0D.0A.20) deprecated. 2373 o To simplify the whole spec, the type of nonce-counter related 2374 parameters are change from hex-integer to integer. 2376 o Algorithm tokens are renamed to include names of hash algorithms. 2378 o Clarified the session management, added details of server-side 2379 protocol decisions. 2381 o The whole draft was reorganized; introduction and overview has 2382 been rewritten. 2384 A.16. Changes in Revision 06 2386 o Integrated Optional Mutual Authentication to the main part. 2388 o Clarified the decision procedure for message recognitions. 2390 o Clarified that a new authentication request for any sub-requests 2391 in interactive clients may be silently discarded. 2393 o Typos and confusing phrases are fixed. 2395 o Several "future considerations" are added. 2397 A.17. Changes in Revision 05 2399 o A new parameter called "version" is added for supporting future 2400 incompatible changes with a single implementation. In the (first) 2401 final specification its value will be changed to 1. 2403 o A new header "Authentication-Control" is added for precise control 2404 of application-level authentication behavior. 2406 A.18. Changes in Revision 04 2408 o Changed text of patent licenses: the phrase "once the protocol is 2409 accepted as an Internet standard" is removed so that the sentence 2410 also covers the draft versions of this protocol. 2412 o The "tls-key" verification is now OPTIONAL. 2414 o Several description fixes and clarifications. 2416 A.19. Changes in Revision 03 2418 o Wildcard domain specifications (e.g. "*.example.com") are allowed 2419 for auth-domain parameters (Section 4.1). 2421 o Specification of the tls-cert verification is updated 2422 (incompatible change). 2424 o State transitions fixed. 2426 o Requirements for servers concerning w_a values are clarified. 2428 o RFC references are updated. 2430 A.20. Changes in Revision 02 2432 o Auth-realm is extended to allow full-scheme type. 2434 o A decision diagram for clients and decision procedures for servers 2435 are added. 2437 o 401-B1 and req-A3 messages are changed to contain authentication 2438 realm information. 2440 o Bugs on equations for o_A and o_B are fixed. 2442 o Detailed equations for the entire algorithm are included. 2444 o Elliptic-curve algorithms are updated. 2446 o Several clarifications and other minor updates. 2448 A.21. Changes in Revision 01 2450 o Several texts are rewritten for clarification. 2452 o Added several security consideration clauses. 2454 Authors' Addresses 2456 Yutaka Oiwa 2457 National Institute of Advanced Industrial Science and Technology 2458 Information Technology Research Institute 2459 Tsukuba Central 1 2460 1-1-1 Umezono 2461 Tsukuba-shi, Ibaraki 2462 JP 2464 Email: mutual-auth-contact-ml@aist.go.jp 2466 Hajime Watanabe 2467 National Institute of Advanced Industrial Science and Technology 2468 Information Technology Research Institute 2469 Tsukuba Central 1 2470 1-1-1 Umezono 2471 Tsukuba-shi, Ibaraki 2472 JP 2473 Hiromitsu Takagi 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 Kaoru Maeda 2482 Lepidum Co. Ltd. 2483 Village Sasazuka 3, Suite #602 2484 1-30-3 Sasazuka 2485 Shibuya-ku, Tokyo 2486 JP 2488 Tatsuya Hayashi 2489 Lepidum Co. Ltd. 2490 Village Sasazuka 3, Suite #602 2491 1-30-3 Sasazuka 2492 Shibuya-ku, Tokyo 2493 JP 2495 Yuichi Ioku 2496 Individual