idnits 2.17.1 draft-oiwa-http-mutualauth-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1550. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 8, 2008) is 5922 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 952 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) == Outdated reference: A later version (-10) exists of draft-altman-tls-channel-bindings-03 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Y. Oiwa 3 Internet-Draft H. Watanabe 4 Intended status: Standards Track H. Takagi 5 Expires: August 11, 2008 RCIS, AIST 6 H. Suzuki 7 Yahoo! Japan 8 February 8, 2008 10 Mutual Authentication Protocol for HTTP 11 draft-oiwa-http-mutualauth-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 11, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document specifies the "Mutual authentication protocol for 45 Hyper-Text Transport Protocol". This protocol provides true mutual 46 authentication between HTTP clients and servers using simple 47 password-based authentication. Unlike Basic and Digest HTTP access 48 authentication protocol, the protocol ensures that server knows the 49 user's entity (encrypted password) upon successful authentication. 50 This prevents common phishing attacks: phishing attackers cannot 51 convince users that the user has been authenticated to the genuine 52 website. Furthermore, even when a user has been authenticated 53 against an illegitimate server, the server cannot gain any bit of 54 information about user's passwords. The protocol is designed as an 55 extension to the HTTP protocol, and the protocol design intends to 56 replace existing authentication mechanism such as Basic/Digest access 57 authentications and form-based authentications. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Tokens and Extensive-tokens . . . . . . . . . . . . . . . 7 66 3.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.3. Strings . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. 401-B0 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.2. 401-B0-stale . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.3. req-A1 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.4. 401-B1 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.5. req-A3 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.6. 200-B4 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 5. Decision procedure for the client . . . . . . . . . . . . . . 13 76 6. Decision procedure for the server . . . . . . . . . . . . . . 18 77 7. Authentication Algorithms . . . . . . . . . . . . . . . . . . 19 78 7.1. Common functions . . . . . . . . . . . . . . . . . . . . . 19 79 7.2. Functions for discrete-logarithm settings . . . . . . . . 21 80 7.3. Functions for elliptic-curve settings . . . . . . . . . . 22 81 8. Validation Methods . . . . . . . . . . . . . . . . . . . . . . 23 82 9. Session Management . . . . . . . . . . . . . . . . . . . . . . 24 83 10. Extension 1: Optional Mutual Authentication . . . . . . . . . 25 84 11. Methods to extend this protocol . . . . . . . . . . . . . . . 26 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 86 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 87 13.1. General Assumptions . . . . . . . . . . . . . . . . . . . 27 88 13.2. Implementation Considerations . . . . . . . . . . . . . . 27 89 13.3. Usage Considerations . . . . . . . . . . . . . . . . . . . 28 90 14. Notice on intellectual properties . . . . . . . . . . . . . . 28 91 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29 92 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 93 16.1. Normative References . . . . . . . . . . . . . . . . . . . 29 94 16.2. Informative References . . . . . . . . . . . . . . . . . . 30 95 Appendix A. Group parameters for discrete-logarithm based 96 algorithms . . . . . . . . . . . . . . . . . . . . . 30 97 Appendix B. Derived numerical values . . . . . . . . . . . . . . 33 98 Appendix C. Draft Remarks from the Authors . . . . . . . . . . . 34 99 Appendix D. Draft Change Log . . . . . . . . . . . . . . . . . . 34 100 D.1. Changes in revision 02 . . . . . . . . . . . . . . . . . . 34 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 102 Intellectual Property and Copyright Statements . . . . . . . . . . 36 104 1. Introduction 106 This document specifies the "Mutual authentication protocol for 107 Hyper-Text Transport Protocol". This protocol provides true mutual 108 authentication between HTTP clients and servers using simple 109 password-based authentication. Unlike Basic and Digest HTTP access 110 authentication protocol [RFC2617], the protocol ensures that server 111 knows the user's entity (encrypted password) upon successful 112 authentication. This prevents common phishing attacks: phishing 113 attackers cannot convince users that the user has been authenticated 114 to the genuine website. Furthermore, even when a user has been 115 authenticated against an illegitimate server, the server cannot gain 116 any bit of information about user's passwords. 118 Recently, phishing attacks are getting more and more sophisticated. 119 Phishers not only steal user's password directly, but imitate 120 successful authentication to steal user's sensitive information, 121 check the password validity by forwarding the password to the 122 legitimate server, or employ a man-in-the-middle attack to hijack 123 user's login session. Existing countermeasures such as one-time 124 passwords cannot completely solve these problems. 126 The protocol prevents such attacks by providing users a way to 127 discriminate between true and fake web servers using their own 128 passwords. Even when a user inputs his/her password to a fake 129 website, using this authentication method, any information about the 130 password does not leak to the phisher, and the user certainly notices 131 that the mutual authentication has failed. Phishers cannot make such 132 authentication attempt succeed, even if they forward received data 133 from a user to the legitimate server or vice versa. Users can safely 134 input sensitive data to the web forms after confirming that the 135 mutual authentication has succeeded. 137 To achieve this goal, this protocol uses a mechanism in ISO/IEC 138 11770-4 [ISO.11770-4.2006], a kind of PAKE (Password-Authenticated 139 Key Exchange) authentication algorithms as a basis. The use of PAKE 140 mechanism allows users to use familiar ID/password based accesses, 141 without fear of leaking any password information to the communication 142 peer. The protocol, as a whole, is designed as a natural extension 143 to the HTTP protocol [RFC2616]. 145 The design also considers to replace current form-based Web 146 authentication, which is very vulnerable against phishing attacks. 147 To this purpose, several extensions to current HTTP authentication 148 mechanism [RFC2617] are introduced. 150 1.1. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 2. Protocol Overview 158 The following sequence is a typical sequence for the first access to 159 the resource. 161 o If the server (S) has received a request for mutual-authentication 162 protected resources from the Client (C) (which is not a req-A1 nor 163 a req-A3 message), it sends a 401-B0 message to C. 165 When C has received a 401-B0 message, C SHOULD check validity of 166 the message. If succeed, C processes the body of the message, and 167 enables the password entry field. 169 o If the user has input the username and password as a response to 170 the 401-B0 message, C creates a value s_A, calculates the value 171 w_A, and construct and send a req-A1 message. 173 o If S has received an req-A1 message, S should check validity of 174 w_A, record the received w_A value, and then look up the username 175 from the user table. if the user is found, S prepares a new 176 session id (sid), record it into a session table, and then 177 construct s_B, calculate w_B, and then send an 401-B1 message. 179 If there is no matching user found, the server SHOULD construct a 180 fake w_B value, and let the protocol going on by sending an 401-B1 181 message. 183 o When C has received an 401-B1 message as a response for a req-A1 184 message, C should check validity of w_B, and compute z and o_A, 185 and send an req-A3 message. 187 If C receives any messages other than 401-B1, C MUST NOT process 188 the message body and treat it as a fatal communication error 189 condition. This case includes the reception of HTTP OK (200- 190 status) message. 192 o If S has received an req-A3 message, S should look up the received 193 sid from the session table. If no matching sid message is 194 received, or if S has not received the corresponding req-A1 195 message beforehand, S SHOULD send an 401-B0-stale message. 197 Otherwise, S should computes o_A and check its value. If the 198 validation has failed, the server SHOULD send an 401-B0 message. 200 If the validation has succeeded, the server SHOULD calculate o_B, 201 and send a 200-B4 message. 203 o When C has received an 401-B0 message, it means the authentication 204 has been failed, possibly due to that the wrong password has been 205 given. C MAY ignore the body of the 401-B0 message in this case. 207 When C has received an 200-B4 message, C MUST first compute the 208 value of o_B and validate the value o_B sent from the server. If 209 it has not verified successfully, C MUST ignore the body of the 210 message, and treat it as a fatal communication error condition. 211 If it has succeed, C will process the body of the message. 213 If C receives any messages other than 401-B0 or valid 200-B4, C 214 MUST NOT process the message body and other headers and treat it 215 as a fatal communication error condition. This case includes the 216 reception of usual HTTP OK (200-status) messages. 218 For the second or later request to the server, if the client knows 219 that the resource is likely to require the authentication, the client 220 MAY omit first unauthenticated request and send req-A1 message 221 immediately. In this case, the first (and only the first) response 222 from the server MAY be a normal, unauthenticated message, and client 223 MAY accept such messages. 225 Furthermore, if client owns a valid session ID (sid), the client MAY 226 send a req-A3 message using existing sid. In such cases, the server 227 MAY have thrown out the corresponding sessions, then the server 228 SHOULD send a 401-B0-stale message as a response to req-A3 message, 229 and C SHOULD retry from constructing req-A1 message. 231 For more detail, see Section 5. 233 3. Message Syntax 235 The Mutual authentication protocol uses four headers: 236 WWW-Authenticate (in responses with status code 401), 237 Optional-WWW-Authenticate (in responses with positive status codes), 238 Authorization (in requests), and Authentication-info (in positive 239 responses). These three headers share the common syntax described in 240 Figure 1. The syntax is denoted in the augmented BNF syntax defined 241 in [RFC4234]. The syntax is a subset of the one described in 242 [RFC2617]. 244 header = header-name ":" [spaces] "Mutual" spaces fields 245 header-name = "WWW-Authenticate" / "Optional-WWW-Authenticate" 246 / "Authorization" / "Authentication-info" 247 spaces = 1*(" " / %x09 / %x0D.0A (" " / %x09)) ; LWSP 248 fields = field *([spaces] "," spaces field) 249 field = key "=" value 250 key = extensive-token 251 extensive-token = token / extension-token 252 extension-token = token "@" token 253 token = 1*(%x30-39 / %x41-5A / %x61-7A / "." / "-" / "_") 254 value = extensive-token / integer / hex-integer 255 / hex-fixed-number 256 / base64-fixed-number / string 257 integer = "0" / (%x31-39 *%x30-39) ; no leading zeros 258 hex-integer = "0" 259 / ((%x31-39 / %x41-46 / %x61-66) ; no leading zeros 260 *(%x30-39 / %x41-46 / %x61-66)) 261 hex-fixed-number = 1*(%x30-39 / %x41-46 / %x61-66) 262 base64-fixed-number = string 263 string = %x22 *(%x20-21 / %x23-5B / %x5D-FF 264 / %x5C.22 / "\\" / "\,") %x22 266 Figure 1: the BNF syntax for the headers used in the protocol 268 3.1. Tokens and Extensive-tokens 270 The tokens MUST be interpreted case-insensitive, and SHOULD be sent 271 in the same case as shown in the specification. When these are used 272 as (partial) inputs to any hash or other mathematical functions, it 273 MUST be used in lower-case. All hex-fixed-number or hex-integer 274 numbers are also case-insensitive, and SHOULD be sent in lower-case. 276 Extensive-tokens are used where the set of acceptable tokens are 277 extensible. Any non-standard extensions of this protocol MUST use 278 the extension-tokens of format "@", where domain- 279 name is the valid registered (sub-)domain name on the Internet owned 280 by the party who defines extensions. 282 3.2. Numbers 284 The syntax definitions of integer and hex-integer only allow 285 representations which do not contain extra leading 0s. 287 The numbers represented as a hex-fixed-number MUST have even 288 characters (i.e. multiple of eight bits). When these are generated 289 from cryptographic values, those SHOULD have the natural length: if 290 these are generated from a hash function, these lengths SHOULD 291 correspond to the hash size; if these are representing elements of a 292 mathematical group, its lengths SHOULD be the shortest which can 293 represent all elements in the group. See Appendix B for information 294 about the length of the fields used in this specification. Other 295 values such as session-id are represented in any (even) length 296 determined by the side who generates it first, and the same length 297 SHALL be used throughout the whole communications by both peers. 299 The numbers represented as a base64-fixed-number SHALL be generated 300 as follows: first, the number is converted to a big-endian octet- 301 string representation. The length of the representation is 302 determined in the same way as above. Then, the string is encoded by 303 the Base 64 encoding [RFC3548], and then enclosed by two double- 304 quotations. 306 3.3. Strings 308 All strings outside ASCII or equivalent character sets SHOULD be 309 encoded using UTF-8 encoding [RFC3629] of the ISO 10646-1 character 310 set [ISO.10646-1.1993]. Both peers SHOULD reject any invalid UTF-8 311 sequences which causes decoding ambiguities (e.g. containing <"> in 312 the second or later byte of the UTF-8 encoded characters). To encode 313 character strings, these will first be encoded according to UTF-8 314 without leading BOM, then all occurrences of characters <"> and "\" 315 will be escaped by prepending "\", and two <">s will be put around 316 the string. If the contents of the strings are comma-separated 317 values, the commas in the values are also quoted by "\". 319 If strings are representing a domain name or URI which contains non- 320 ASCII characters, the host parts SHOULD be encoded using puny-code 321 defined in [RFC3492] instead of UTF-8, and SHOULD use lower-case 322 ASCII characters. 324 For Base64-fixed-numbers, which use the string syntax, see the 325 previous section. 327 4. Messages 329 In this section, formats and requirements of the headers for each 330 message are presented. The allowed type for values for each header 331 field is shown in parenthesis after the key names. The type 332 "algorithm-determined" means that the acceptable value type for the 333 field is one of the types defined in Section 3, and is determined by 334 the value of the "algorithm" field. 336 Note: The term "optional" here means that omitting the field is 337 allowed and has specific meanings in communications (i.e. it is not 338 generally "OPTIONAL" defined in [RFC2119]). 340 4.1. 401-B0 342 Every 401-B0 message SHALL be a valid HTTP 401 (Authentication 343 Required) message containing one (and only one: hereafter not 344 explicitly noticed) "WWW-Authenticate" header of the following 345 format. 347 WWW-Authenticate: Mutual algorithm=xxxx, validation=xxxx, 348 realm="xxxx", stale=0 350 The header SHALL contain the fields with the following keys: 352 algorithm: (extensive-token) specifies the authentication 353 algorithm to be used. The value MUST be one of the 354 tokens described in Section 7, or the tokens specified 355 in other supplemental specification documentations. 357 validation: (extensive-token) specifies the method of host 358 validation. The value MUST be one of the tokens 359 described in Section 8, or the tokens specified in 360 other supplemental specification documentations. 362 realm: (string) is a UTF-8 encoded name of the authentication 363 domain inside the server. 365 pwd-hash: (optional, extensive-token) specifies the hash 366 algorithm (referred to by ph) used for additionally 367 hashing the password. The valid tokens are 369 * none: ph(p) = p 371 * md5: ph(p) = MD5(p) 373 * digest-md5: ph(p) = MD5(username | ":" | realm | 374 ":" | p), the same value as MD5(A1) for "MD5" 375 algorithm in [RFC2617]. 377 * sha1: ph(p) = SHA1(p) 379 If omitted, the value "none" is assumed. The use of 380 "none" is recommended. 382 auth-domain: (optional, string) MUST currently be one of the 383 following strings. 385 * the host part of the requested URI, 386 * the string in format "scheme://host:port", where 387 scheme, host and port are the URI parts of the 388 requested URI. The scheme and host are in lower- 389 case, and the port is in a shortest decimal 390 representation. Even if the request-URI does not 391 have a port part, the string will include the one. 393 If the value is omitted, it is assumed to be the host 394 part of the requested URI. The triple of auth-domain, 395 algorithm, and realm determines the "authentication 396 realm" which defines the area where the same user-name 397 and passwords are applicable. 399 stale: (token) MUST be "0". 401 Any additional fields SHOULD NOT be contained in the header, except 402 those explicitly specified in supplement specifications of the 403 "authentication algorithm". 405 The algorithm will determine the types and the values for w_A, w_B, 406 o_A and o_B. 408 4.2. 401-B0-stale 410 A 401-B0-stale message is a variant of 401-B0 message, which means 411 that the client has sent a request message which is not for any 412 active session. 414 WWW-Authenticate: Mutual algorithm=xxxx, validation=xxxx, 415 realm="xxxx", stale=1 417 The header MUST contain the same fields as in 401-B0, except that 418 stale field holds the integer 1. 420 4.3. req-A1 422 Every req-A1 message SHALL be a valid HTTP request message containing 423 a "Authorization" header of the following format. 425 Authorization: Mutual algorithm=xxxx, validation=xxxx, realm="xxxx", 426 user="xxxx", wa=xxxx 428 The header SHALL contain the fields with the following keys: 430 algorithm, validation, auth-domain, realm: MUST be the same value as 431 it is received from S. 433 user: (string) is the UTF-8 encoded name of the user. 435 wa: (algorithm-determined) is the value of w_A specified 436 by the used algorithm. 438 4.4. 401-B1 440 Every 401-B1 message SHALL be a valid HTTP 401 (Authentication 441 Required) message containing a "WWW-Authenticate" header of the 442 following format. 444 WWW-Authenticate: Mutual algorithm=xxxx, validation=xxxx, 445 realm="xxxx", sid=xxxx, wb=xxxx, nc-max=x, nc-window=x, time=x, 446 path="xxxx" 448 The header SHALL contain the fields with the following keys: 450 algorithm, validation, auth-domain, realm: MUST be the same value as 451 it is received from C. 453 sid: (hex-fixed-number) MUST be a session id, which is a 454 random integer. The sid SHOULD have uniqueness of at 455 least 80 bits or the square of the maximal estimated 456 transactions concurrently available in the session 457 table, whichever is larger. Sids are local to each 458 authentication realm concerned: the same sids for 459 different authentication realms SHOULD be treated as 460 independent ones. 462 wb: (algorithm-determined) is the value of w_B specified 463 by the algorithm. 465 nc-max: (hex-integer) is the maximal value of nonce counts 466 which S accepts. 468 nc-window: (hex-integer) the number of available nonce slots 469 which S will accept. The value of nc-window is 470 RECOMMENDED to be thirty-two ("20" in hex-integer) or 471 more. 473 time: (integer) represents the suggested time (in seconds) 474 which C can reuse the session represented by sid. It 475 is RECOMMENDED to be at least 60. The value of this 476 field is not directly linked to the duration that S 477 keeps track of the session represented by sid. 479 path: (optional, string) specifies for which path in the URI 480 space the same authentication is expected to apply. 481 The value is in the same format as it is specified in 482 [RFC2617] for the Digest authentications, and clients 483 are RECOMMENDED to recognize it. The all path 484 elements contained in the field MUST be inside the 485 specified auth-domain: if not, client SHOULD ignore 486 such elements. 488 4.5. req-A3 490 Every req-A3 message SHALL be a valid HTTP request message containing 491 a "Authorization" header of the following format. 493 Authorization: Mutual algorithm=xxxx, validation=xxxx, realm="xxxx", 494 sid=xxxx, nc=x, oa=xxxx 496 The fields contained in the header is as follows: 498 algorithm, validation, auth-domain, realm: MUST be the same value as 499 it is received from S for the session. 501 sid: (hex-fixed-number) MUST be one of the sid values which 502 has been received from S. 504 nc: (hex-integer) is a nonce value which is unique among 505 the requests sharing the same sid. The value of nc 506 SHOULD satisfy the following properties: 508 * It is not larger than the nc-max value which has 509 been sent from S in the session represented by the 510 sid. 512 * C have not sent the same value in the same session. 514 * It is not smaller than (largest-nc - nc-window), 515 where largest-nc is the maximal value of nc which 516 has previously been sent in the session, and nc- 517 window is the value of the nc-window field which 518 has been sent from S in the session. 520 oa: (algorithm-determined) is the value of o_A specified 521 by the algorithm. 523 4.6. 200-B4 525 Every 200-B1 message SHALL be a valid HTTP message which is not 401 526 (Authentication Required) type, containing an "Authentication-Info" 527 header of the following format. 529 Authentication-Info: Mutual sid=xxxx, ob=xxxx 531 The fields contained in the header is as follows: 533 sid: (hex-fixed-number) MUST be the value received from C. 535 ob: (algorithm-determined) is the value of o_B specified 536 by the algorithm. 538 logout-timeout: (optional, integer) is a number of seconds after 539 which the client should re-validate the user's 540 password for the current authentication realm. As a 541 special case, the value 0 means that the client SHOULD 542 automatically forget the user-inputed password to the 543 current authentication realm and revert to the 544 unauthenticated state (i.e.~server-initiated logout). 545 This does not, however, mean that the long-term 546 memories for the passwords (such as password reminders 547 and auto fill-ins) should be removed. If a new value 548 of timeout is received for the same authentication 549 realm, it overrides the previous timeout. 551 5. Decision procedure for the client 553 To securely implement the protocol, the user client must be careful 554 to accepting authenticated responses from the server. 556 Clients SHOULD implement the decision procedure equivalent to the one 557 shown below. (Unless implementers understand what is required for 558 the security, they should not alter this.) The labels on the steps 559 are for informational purpose only. 561 Step 1 (step_new_request): 562 If the client software needs to get a new Web resource, check 563 whether the resource is expected to be inside some authentication 564 realm for which the user has already authenticated. If yes, go 565 to Step 2. Otherwise, go to Step 5. 567 Step 2: 568 Check whether there is an available sid for the authentication 569 realm you expects. If there is one, go to Step 3. Otherwise, go 570 to Step 4. 572 Step 3 (step_send_a3_1): 573 Send a req-A3 request. 575 * If you receive a 401-B0 message with a different 576 authentication realm than expected, go to Step 6. 578 * If you receive a 401-B0-stale message, go to Step 9. 580 * If you receive a 401-B0 message, go to Step 13. 582 * If you receive a valid 200-B4 message, go to Step 14. 584 * If you receive a normal response (without Mutual-specific 585 headers), go to Step 11. 587 Step 4 (step_send_a1_1): 588 Send a req-A1 request. 590 * If you receive a 401-B0 message with a different 591 authentication realm than expected, go to Step 6. 593 * If you receive a 401-B0-stale message, go to Step 9. 595 * If you receive a 401-B1 message, go to Step 10. 597 * If you receive a normal response (without Mutual-specific 598 headers), go to Step 10. 600 Step 5 (step_send_normal_1): 601 Send a request without any authentication headers. 603 * If you receive a 401-B0 message, go to Step 6. 605 * If you receive a normal response (without Mutual-specific 606 headers), go to Step 11. 608 Step 6 (step_rcvd_b0): 609 Check whether you know the user's password for the requested 610 authentication realm. If yes, go to Step 7. Otherwise, go to 611 Step 12. 613 Step 7: 614 Check whether there is an available sid for the authentication 615 realm you expects. If there is one, go to Step 8. Otherwise, go 616 to Step 9. 618 Step 8 (step_send_a3): 619 Send a req-A3 request. 621 * If you receive a 401-B0 message with a different 622 authentication realm than expected, go to Step 6. 624 * If you receive a 401-B0-stale message, go to Step 9. 626 * If you receive a 401-B0 message, go to Step 13. 628 * If you receive a valid 200-B4 message, go to Step 14. 630 Step 9 (step_send_a1): 631 Send a req-A1 request. 633 * If you receive a 401-B1 message, go to Step 10. 635 Step 10 (step_rcvd_b1): 636 Send a req-A3 request. 638 * If you receive a 401-B0 message, go to Step 13. 640 * If you receive a valid 200-B4 message, go to Step 14. 642 Step 11 (step_rcvd_normal): 643 This case means that the resource requested is out of the 644 authenticated area. The client will be in "UNAUTHENTICATED" 645 status. 647 Step 12 (step_rcvd_b0_unknown): 648 This case means that the resource requested requires Mutual 649 authentication, and the user is not authenticated yet. The 650 client will be in "AUTH_REQUESTED" status, is RECOMMENDED to 651 process the content sent from the server and ask user a username 652 and password. If the user has input those, go to Step 9. 654 Step 13 (step_rcvd_b0_failed): 655 This case means that in some reason the authentication failed: 656 possibly the password or the username is invalid for the 657 authenticated resource. Forget the password for the 658 authentication realm and go to Step 12. 660 Step 14 (step_rcvd_b4): 661 This case means that the mutual authentication has been 662 succeeded. The client will be in "AUTH_SUCCEEDED" status. 664 All other kind of responses than shown in above procedure SHOULD be 665 interpreted as fatal communication error, and in such cases user 666 clients MUST NOT process any data (contents and other content-related 667 headers) sent from the server. 669 The client software SHOULD show the three client status to the end- 670 user. 672 Figure 2 shows the full client-side state diagram. 674 =========== -(11)------------ 675 NEW REQUEST ( UNAUTHENTICATED ) 676 =========== ----------------- 677 | ^ 678 | |normal 679 v |response 680 +(1)-------------------+ NO +(5)----------+ 681 | The requested URI |--------------------------->| send normal | 682 | known to be auth'ed? | | request | 683 +----------------------+ +-------------+ 684 |YES 401-B0, 200-Opt-B0 |401-B0 685 | with different realm |200-Opt-B0 686 | -----------------------------------. | 687 | / v v 688 | | -(12)------------ NO +(6)--------+ 689 | | ( AUTH_REQUESTED )<------| user/pass | 690 | | ----------------- | known? | 691 | | +-----------+ 692 | | |YES 693 v | v 694 +(2)--------+ | +(7)--------+ 695 | session | | | session | NO 696 NO /| available?| | | available?|\ 697 / +-----------+ | +-----------+ | 698 / |YES | |YES | 699 | | /| | | 700 | v / | 401- v | 701 | +(3)--------+ | B0 --(13)---------- 401-B0 +(8)--------+ | 702 | | send |--+----->/ AUTH_REQUESTED \<-------| send | | 703 | /| req-A3 | | \forget user/pass/ | req-A3 | | 704 \/ +-----------+ / ---------------- /+-----------+ | 705 /\ \ \/ ^ 401-B0 | |401-B0- | 706 | -------. \/\ 401-B0-stale | | |stale / 707 | | /\ -----------------+--------------+----. | / 708 | v / \ | | v v v 709 | +(4)--------+ | 401-B1 +(10)-------+ 401-B1 | +(9)--------+ 710 | | send |-|--------->| send |<-------+-| send | 711 | --| req-A1 | | | req-A3 | | | req-A1 | 712 |/ +-----------+ | +-----------+ | +-----------+ 713 | |200-B4 | 200-B4| ^ 714 |normal | |200-B4 / | 715 |response | v / ================= 716 v \ -(14)--------- / USER/PASS INPUTED 717 -(11)------------ ------->( AUTH-SUCCEED )<-- ================= 718 ( UNAUTHENTICATED ) -------------- 719 ----------------- 721 Figure 2: State diagram for clients 723 6. Decision procedure for the server 725 Servers SHOULD respond to the client requests according to the 726 following procedure: 728 o When the server receives a normal request: 730 * If the requested resource is not protected by Mutual 731 Authentication, send a normal response. 733 * If the resource is protected by Mutual Authentication, send a 734 401-B0 response. 736 * If the resource is protected by Mutual Authentication with 737 Optional Mutual Authentication extension (Section 10), send a 738 200-Optional-B0 response. 740 o When the server receives a req-A1 request: 742 * If the requested resource is not protected by Mutual 743 Authentication, send a normal response. 745 * If the authentication realm specified in the req-A1 request is 746 non-expected one, send a 401-B0 (or 200-Optional-B0) response. 748 * If the server cannot validate field wa, send a 401-B0 response. 750 * If the received user name is invalid, send a fake 401-B1 751 response. 753 * Otherwise, send a 401-B1 response. 755 o When the server receives a req-A3 request: 757 * If the requested resource is not protected by Mutual 758 Authentication, send a normal response. 760 * If the authentication realm specified in the req-A3 request is 761 non-expected one, send a 401-B0 (or 200-Optional-B0) response. 763 * If the received sid is invalid, inactive or unknown, send a 764 401-B0-stale response. 766 * If the receive oa is invalid, send a 401-B0 response. 768 * If the receive oa is correct, send a 200-B4 response. 770 7. Authentication Algorithms 772 This document specifies only one family of the authentication 773 algorithm. The family consists of four authentication algorithms, 774 which only differ in underlying mathematical groups and security 775 parameters. The algorithms do not add any additional fields. The 776 tokens for algorithms are 778 o "iso11770-4-ec-p256" for the 256-bit prime-field elliptic-curve 779 setting. 781 o "iso11770-4-ec-p521" for the 521-bit prime-field elliptic-curve 782 setting. 784 o "iso11770-4-dl-2048" for the 2048-bit discrete-logarithm setting. 786 o "iso11770-4-dl-4096" for the 4096-bit discrete-logarithm setting. 788 For the elliptic-curve settings, the underlying fields and the curves 789 used for elliptic-curve cryptography are the prime field and the 790 Curve P-256 and P-521, respectively, specified in the appendix of 791 FIPS PUB 186-2 [FIPS.186-2.2000] specification. The hash functions H 792 are SHA-256 for P-256 curve and SHA-512 for P-521 curve, 793 respectively, defined in FIPS PUB 180-2 [FIPS.180-2.2002]. The 794 representation of fields wa, wb, oa, and ob is hex-fixed-number. 796 For discrete-logarithm settings, the underlying groups are 2048-bit 797 and 4096-bit MODP groups defined in [RFC3526] respectively. See 798 Appendix A for the exact specification of the group and associated 799 parameters. The hash functions H are SHA-256 for the 2048-bit field 800 and SHA-512 for the 4096-bit field, respectively. The representation 801 of fields wa, wb, oa, and ob is base64-fixed-number. 803 The clients SHOULD support at least "iso11770-4-dl-2048" algorithm, 804 and are advised to support all of the above four algorithms whenever 805 possible. The server software implementations SHOULD support at 806 least "iso11770-4-dl-2048" algorithm, unless it is known that users 807 will not use it. 809 This algorithm uses Key Agreement Mechanism 3 (KAM3) defined in 810 Section 6.3 of ISO/IEC-11770-4 [ISO.11770-4.2006] as a basis. 812 7.1. Common functions 814 The password-based string pi used by this authentication is derived 815 in the following manner: 817 pi = H(VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username) | 818 VS(ph(password)). 820 The values of algorithm, realm and auth-domain are taken from the 821 values contained in the 401-B0 message. When pi is used in the 822 context of an octet string, it SHALL have the natural length derived 823 from the size of the output of function H (e.g. 32 octets for SHA- 824 256). The function ph is defined by the value of the pwd-hash field 825 given in a 401-B0 message. 827 The function VI encodes natural numbers into octet strings in the 828 following manner: integers are represented in big-endian radix-128 829 string, where each digit is represented by a octet 0x80-0xff except 830 the last digit represented by 0x00-0x7f. The first octet MUST NOT be 831 0x80. For example, VI(i) = octet(i) for i < 128, and VI(i) = 832 octet(0x80 | (i >> 7)) | octet(i & 127) for 128 <= i < 16384. This 833 encoding is the same as the one used in the length field in the ASN.1 834 encoding [ITU.X690.1994]. 836 The function VS encodes variable-length octet string into decodable 837 octet string, as in the following manner: 839 VS(s) = VI(length(s)) | s 841 where length(s) is a number of octets (not characters) in s. 843 The function OCTETS converts an integer to corresponding radix-256 844 big-endian octet string having its natural length: See Section 3.2 845 for the definition of the "natural length". Note that this is 846 different from the function GE2OS_x in [ISO.11770-4.2006], which 847 takes the shortest representation. 849 The equations for J, w_A, T, z, and w_B are specified differently for 850 the discrete-logarithm setting and the elliptic-curve setting based 851 on [ISO.11770-4.2006]. These equations are defined later in this 852 section. 854 The values o_A and o_B are derived by the following equation. Note 855 that these equations are different from ones specified in 856 [ISO.11770-4.2006]. 858 o_A = H(octet(04) | OCTETS(w_A) | OCTETS(w_B) | OCTETS(z) | VI(nc) | 859 VS(v)) 861 o_B = H(octet(03) | OCTETS(w_A) | OCTETS(w_B) | OCTETS(z) | VI(nc) | 862 VS(v)) 864 7.2. Functions for discrete-logarithm settings 866 In this section, the equation (x / y mod z) denotes an natural number 867 w less than z which satisfies (w * y) mod z = x mod z. 869 For the discrete-logarithm, we refer some of the domain parameters by 870 the following symbols: 872 o q: for "the prime" of the group. 874 o g: for "the generator" associated with the group. 876 o r: for the order of the subgroup generated by g. 878 The function J is defined as 880 J(pi) = g^(pi) mod q, 882 where g and q are domain parameters of the underlying field. 884 The value of w_A is derived as 886 w_A = g^(s_A) mod q, 888 where s_A is a random integer within range [1, r-1] and r is the size 889 of the subgroup generated by g. In addition, s_A MUST be larger than 890 log(q)/log(g) (so that g^(s_A) > q). The value of w_A SHALL satisfy 891 1 < w_A < q-1. The server MUST check this condition upon reception. 893 The value of w_B is derived from J(pi) and w_A as: 895 w_B = (J(pi) * w_A^(H(octet(1) | OCTETS(w_A))))^s_B mod q, 897 where s_B is a random number within range [1, r-1]. The value of w_B 898 MUST satisfy 1 < w_B < q-1. If this condition is not hold, the 899 server MUST retry with another value of s_B. The client MUST check 900 this condition upon reception. 902 The value z in the client side is derived by the following equation: 904 z = w_B^((s_A + H(octet(2) | OCTETS(w_A) | OCTETS(w_B))) / (s_A * 905 H(octet(1) | w_A) + pi) mod r) mod q. 907 The value z in the server side is derived by the following equation: 909 z = (w_A * g^(H(octet(2) | OCTETS(w_A) | OCTETS(w_B))))^s_B mod q. 911 7.3. Functions for elliptic-curve settings 913 For the elliptic-curve setting, we refer some of the domain 914 parameters by the following symbols: 916 o q: for the prime used to define the field, 918 o G: for the defined point called the generator, 920 o r: for the order of the subfield generated by G. 922 The function P(p) converts a curve point p to an integer representing 923 the point p, by computing x * 2 + (y mod 2), where (x, y) are the 924 coordinates of the point p. P'(z) is the inverse of function P, that 925 is, it converts an integer z to a point p which satisfies P(p) = z. 926 If such p is exist, it is uniquely defined. Otherwise, z does not 927 represent a valid curve point. The operation [x] * p denotes an 928 integer-multiplication of point p: it calculates p + p + ... (x 929 times) ... + p. See literatures on elliptic-curve cryptography for 930 the exact algorithms for those. 0_E represents the infinity point. 931 The equation (x / y mod z) denotes an natural number w less than z 932 which satisfies (w * y) mod z = x mod z. 934 the function J is defined as 936 J(pi) = [pi] * G. 938 The value of w_A is derived as 940 w_A = P(W_A), where W_A = [s_A] x G. 942 where s_A is a random number within range [1, r-1]. The value of w_A 943 MUST represent a valid curve point, and W_A SHALL NOT be 0_E. The 944 server MUST check this condition upon reception. 946 The value of w_B is derived from J(pi) and W_A = P'(w_A) as: 948 w_B = P(W_B), where W_B = [s_B] * (J(pi) + [H(octet(1) | 949 OCTETS(w_A))] * W_A). 951 where s_B is a random number within range [1, r-1]. The value of w_B 952 MUST represent a valid curve point and satisfy [4] * P'(w_B) <> 0_E. 953 If this condition is not hold, the server MUST retry with another 954 value of s_B. The client MUST check this condition upon reception. 956 The value z in the client side is derived by the following equation: 958 z = P([(s_A + H(octet(2) | OCTETS(w_A) | OCTETS(w_B))) / (s_A * 959 H(octet(1) | OCTETS(w_A)) + pi) mod r] * W_B), where W_B = P'(w_B). 961 The value z in the server side is derived by the following equation: 963 z = P([s_B] * (W_A + [H(octet(2) | OCTETS(w_A) | OCTETS(w_B))] * G)), 964 where W_A = P'(w_A). 966 8. Validation Methods 968 The "validation method" specifies a method to "relate" the mutual 969 authentication processed by this protocol with other authentications 970 already performed in the underlying layers and to prevent man-in-the- 971 middle attacks. It decides the value of v which is an input to 972 authentication protocols. 974 The valid tokens for the validation field and corresponding values of 975 v are as follows: 977 host: hostname validation: v will be the ASCII string in the 978 following format: "scheme://host:port", where scheme, 979 host and port are the URI parts correspond to the 980 currently accessing resource. The scheme and host are 981 lower-case, and the port is in a shortest decimal 982 representation. Even if the request-URI does not have 983 a port part, v will include the one. 985 tls-cert: TLS certificate validation: v will be the octet string 986 of the hash value of the public key certificate used 987 in underlying TLS [RFC4346] (or SSL) connection. The 988 hash value is defined as the value of the 989 "tbsCertificate" stream hashed by the hash algorithm 990 corresponding to the signing algorithm specified in 991 the "signatureAlgorithm" field of the X.509 992 certificate as defined in [RFC3280]. This value is 993 equal to the verified signature value stored in the 994 "signatureValue" field, once certificate signature has 995 been verified successfully. 997 tls-key: TLS shared-key validation: v will be the octet string 998 of the shared master secret negotiated in underlying 999 TLS (or SSL) connection. 1001 If the HTTP protocol is used on unencrypted channel, the validation 1002 type MUST be "host". If HTTP/TLS [RFC2818] (https) protocol is used 1003 with server certificates, the validation type MUST be either "tls- 1004 cert" or "tls-key". If HTTP/TLS protocol is used with anonymous 1005 Diffie-Hellman key exchange, the validation type MUST be "tls-key" 1006 (but see the note below). 1008 The client MUST validate this field upon reception of 401-B0 1009 messages. 1011 However, when the protocol is used on web browsers with any scripting 1012 capabilities, the anonymous Diffie-Hellman family of TLS (or SSL) 1013 cipher-suite MUST NOT be used even if "tls-key" validated Mutual 1014 authentication has been employed, and the certificate shown in TLS 1015 (or SSL) negotiation MUST be verified using PKI. For other systems, 1016 if the "tls-key" validation is used on TLS (or SSL) protocol without 1017 certificate verification using PKI, those systems MUST ensure that 1018 all transactions with authenticated peer servers MUST use and be 1019 validated by the Mutual authentication protocol, regardless of the 1020 existence of the 401-B0 responses. 1022 The protocol defines two variants for validation on TLS connections. 1023 The method "tls-key" method is the more secure, so it is recommended 1024 to use tls-key when applicable. However, there are some situations 1025 where tls-cert is more preferable. 1027 o When TLS accelerating proxies are used. In this case, it is 1028 difficult for the authenticating server to acquire the TLS key 1029 information which are used between the client and the proxy. It 1030 is not the case for client-side "tunneling" proxies using CONNECT 1031 method extension of HTTP. 1033 o When a black-box implementation of the TLS protocol is used on 1034 either peer. 1036 9. Session Management 1038 By the first 4 messages (first request, 401-B0, req-A1 and 401-B1), a 1039 session represented by a sid is generated. This session can be used 1040 for 1 or more requests for resources protected by the same realm in 1041 the same server. Note that the session management is only an inside 1042 detail of the protocol and usually not visible to normal users. If a 1043 session expires, the client and server will automatically reestablish 1044 another session without telling it to the users. 1046 The server SHOULD accept at least one req-A3 request for each 1047 session, given that the request reaches the server in a time window 1048 specified by the timeout field in the 401-B1 message, and that there 1049 are no emergent reasons (such as flooding attacks) to forget the 1050 sessions. After that, the server MAY discard any session at any time 1051 and MAY send 401-B0-stale messages for any req-A3 requests. 1053 The client MAY send more than one requests using a single session 1054 specified by the sid. However, for all such requests, the values of 1055 the nonce-counter (nc field) MUST be different from each other. The 1056 server MUST check for duplication of the received nonces, and if any 1057 duplication is detected, the server MUST discard the session and 1058 respond by a 401-B0-stale message. 1060 In addition, for each sessions, if the client has already sent a 1061 request with nonce value x, it SHOULD NOT send requests with a nonce 1062 value not larger than (x - nc-window). The server MAY reject any 1063 requests with nonces violating this rule with 401-B0-stale responses. 1064 This restriction enables servers to implement duplicated nonce 1065 detection in a constant memory. 1067 Values of nonces and nonce-related values MUST always be treated as 1068 natural numbers within infinite range. Implementations using fixed- 1069 width integers or fixed-precision floating numbers MUST handle 1070 integer overflow correctly and carefully. Such implementations are 1071 RECOMMENDED to accept any larger values which cannot be represented 1072 in the fixed-width integer representations, as long as other limits 1073 such as internal header-length restrictions are not involved. The 1074 protocol is designed carefully so that both clients and servers can 1075 implement the protocol only with fixed-width integers, by rounding 1076 any overflowed values to the maximum possible value. 1078 10. Extension 1: Optional Mutual Authentication 1080 In several Web applications, users can access the same contents both 1081 as a guest user and as a authenticated users. In usual Web 1082 applications, it is implemented using Cookies and custom form-based 1083 authentications. The extension described in this section provides a 1084 replacement for those authentication systems. The support for this 1085 extension is RECOMMENDED. 1087 Servers MAY send HTTP successful responses (response code 200, 206 1088 and others) containing the Optional-WWW-Authenticate header, when it 1089 is allowed to send 401-B0 responses and the requests do not contain 1090 Authentication-Info: headers. Such responses are hereafter called 1091 200-Optional-B0 responses. 1093 HTTP/1.1 200 OK 1094 Optional-WWW-Authenticate: Mutual algorithm=xxxx, validation=xxxx, 1095 realm="xxxx", stale=0 1097 The fields contained in the Optional-WWW-Authenticate header is the 1098 same as the 401-B0 message described in Section 4.1. The client 1099 software supporting the mutual authentication protocol receiving a 1100 200-Optional-B0 message will process the contents of the message and 1101 enables an authentication input field. 1103 When the user input the username and password, the client resends the 1104 request with req-A1 header. The server MUST respond with a 401-B1 1105 message. In terms of the state management in Section 5, 200- 1106 Optional-B0 responses are treated as if it is 401-B0 response: these 1107 messages SHOULD NOT be sent as a response to req-A1 and req-A3 1108 messages, unless the authentication realm sent from the client or 1109 indicated by sid is different from the one which the server expects. 1111 Servers requesting optional mutual authentication SHOULD send the 1112 path field in 401-B1 messages with an appropriate value. Client 1113 software supporting optional mutual authentication MUST recognize the 1114 field, and MUST send either req-A1 or req-A3 request for the URI 1115 space inside the specified paths, instead of unauthenticated 1116 requests. 1118 11. Methods to extend this protocol 1120 If a non-standard extension to the this protocol is implemented, it 1121 MUST use the extension-tokens defined in Section 3 to avoid conflicts 1122 with this protocol and other extensions. 1124 Authentication algorithms other than those defined in this document 1125 MAY use other representations for keys "wa", "wb", "oa" and "ob", 1126 replace those keys, and/or add fields to the messages containing 1127 those fields by supplemental specifications. If those specifications 1128 use keys other than shown above, it is RECOMMENDED to use extension- 1129 tokens to avoid any key-name conflict with the future extension of 1130 this protocol. 1132 12. IANA Considerations 1134 The tokens used for authentication-algorithm, pwd-hash, and 1135 validation fields MUST be allocated by IANA. To acquire registered 1136 token, IESG Approval outlined in [RFC2434] is required. Extension- 1137 tokens MAY be freely used for any non-standard, private and/or 1138 experimental uses for those fields provided that the domain part in 1139 the token is appropriately used. 1141 13. Security Considerations 1142 13.1. General Assumptions 1144 o The protocol is secure against passive eavesdropping and replay 1145 attacks. However, the protocol relies on transport security 1146 including DNS security for active attacks. HTTP/TLS SHOULD be 1147 used where transport security is not assured and data secrecy is 1148 important. 1150 o When used with HTTP/TLS, the protocol gives true protection 1151 against active man-in-the-middle attacks for each HTTP request/ 1152 response pair, even when the server certificate is not used or is 1153 unreliable. However, in such cases, JavaScript or similar 1154 scripting facilities can be used to affect Mutually-authenticated 1155 contents from those not protected by this authentication 1156 mechanism. This is why this memo requires that valid TLS server 1157 certificates MUST be presented (Section 8). 1159 13.2. Implementation Considerations 1161 o To securely implement the protocol, the Authentication-Info 1162 headers in the 200-B4 messages MUST always be validated by the 1163 client. If the validation is failed, the client MUST NOT process 1164 any content sent with the message, including the body part. Non- 1165 compliance to this will enable phishing attacks. 1167 o The authentication status on the client-side SHOULD be visible to 1168 the users of the client. In addition, the method for asking 1169 user's name and passwords SHOULD be carefully designed so that (1) 1170 the user can easily distinguish request of this authentication 1171 methods from other existing authentication methods such as Basic 1172 and Digest methods, and (2) the Web contents cannot imitate the 1173 user-interfaces of this protocol. 1175 An informational memo regarding user-interface considerations and 1176 recommendations for implementing this protocol will be separately 1177 published. 1179 o For HTTP/TLS communications, when a web form is submitted from 1180 Mutually-authenticated pages with the validation methods of "tls- 1181 cert" to a URI which is protected by the same realm (so indicated 1182 by the path field), if server certificate has been changed since 1183 the pages has been received, the peer is RECOMMENDED to be 1184 revalidated using a req-A1 message with an "Expect: 100-continue" 1185 header. The same applies when the page is received with the 1186 validation methods of "tls-key", and when the TLS session has been 1187 expired. 1189 o Server-side storages of user passwords are advised to have the 1190 values encrypted by one-way function J(pi), instead of the real 1191 passwords, those hashed by ph, or pi. 1193 13.3. Usage Considerations 1195 o The user-names inputted by user may be sent automatically to any 1196 servers sharing the same auth-domain. This means that when host- 1197 type auth-domain is used for authentication in HTTPS site, and 1198 when an HTTP server on the same host requests Mutual 1199 authentication with the same realm, the client will send the user- 1200 name in a clear text. If user-names have to kept secret against 1201 eavesdropping, the server must use full-scheme-type auth-domain 1202 parameter. On the contrary, passwords are not exposed to 1203 eavesdroppers even on HTTP requests. 1205 o "Pwd_hash" field is only provided for backward compatibility for 1206 password databases, and using "none" function is the most secure 1207 and RECOMMENDED. If values other than "none" is used, you must 1208 ensure that the hash values of the passwords were not exposed to 1209 the public. Note that hashed password databases for plain-text 1210 authentications are usually not considered secret. 1212 o If the server provides several ways of storing server-side 1213 password database, it is advised to store the values encrypted by 1214 one-way function J(pi), instead of the real passwords, those 1215 hashed by ph, or pi. 1217 14. Notice on intellectual properties 1219 The National Institute of Advanced Industrial Science and Technology 1220 (AIST) and Yahoo! Japan, Inc. has jointly submitted a patent 1221 application about the protocol proposed in this documentation to the 1222 Patent Office of Japan. The patent is intended to be open to any 1223 implementors of this protocol and its variants under non-exclusive 1224 royalty-free manner once the protocol is accepted as an Internet 1225 standard. For the detail of the patent application, contact the 1226 author of this document. 1228 The elliptic-curve based authentication algorithms might involve 1229 several existing patents of third-parties. The authors of the 1230 document take no position regarding the validity or scope of such 1231 patents, and other patents as well. 1233 15. Acknowledgement 1235 We gratefully acknowledge Lepidum, Co. Ltd. for support on design 1236 and trial implementation of this protocol. 1238 16. References 1240 16.1. Normative References 1242 [FIPS.180-2.2002] 1243 National Institute of Standards and Technology, "Secure 1244 Hash Standard", FIPS PUB 180-2, August 2002, . 1247 [FIPS.186-2.2000] 1248 National Institute of Standards and Technology, "Digital 1249 Signature Standard (DSS)", FIPS PUB 186-2, January 2000, < 1250 http://csrc.nist.gov/publications/fips/fips186-2/ 1251 fips186-2-change1.pdf>. 1253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1254 Requirement Levels", BCP 14, RFC 2119, March 1997. 1256 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1257 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1258 October 1998. 1260 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1262 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1263 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1264 RFC 3526, May 2003. 1266 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1267 Encodings", RFC 3548, July 2003. 1269 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1270 10646", STD 63, RFC 3629, November 2003. 1272 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1273 Specifications: ABNF", RFC 4234, October 2005. 1275 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1276 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1278 16.2. Informative References 1280 [I-D.altman-tls-channel-bindings] 1281 Altman, J. and N. Williams, "Unique Channel Bindings for 1282 TLS", draft-altman-tls-channel-bindings-03 (work in 1283 progress), November 2007. 1285 [ISO.10646-1.1993] 1286 International Organization for Standardization, 1287 "Information Technology - Universal Multiple-octet coded 1288 Character Set (UCS) - Part 1: Architecture and Basic 1289 Multilingual Plane", ISO Standard 10646-1, May 1993. 1291 [ISO.11770-4.2006] 1292 International Organization for Standardization, 1293 "Information technology - Security techniques - Key 1294 management - Part 4: Mechanisms based on weak secrets", 1295 ISO Standard 11770-4, May 2006. 1297 [ITU.X690.1994] 1298 International Telecommunications Union, "Information 1299 Technology - ASN.1 encoding rules: Specification of Basic 1300 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1301 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1302 X.690, 1994. 1304 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1305 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1306 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1308 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1309 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1310 Authentication: Basic and Digest Access Authentication", 1311 RFC 2617, June 1999. 1313 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1314 X.509 Public Key Infrastructure Certificate and 1315 Certificate Revocation List (CRL) Profile", RFC 3280, 1316 April 2002. 1318 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1319 for Internationalized Domain Names in Applications 1320 (IDNA)", RFC 3492, March 2003. 1322 Appendix A. Group parameters for discrete-logarithm based algorithms 1324 The MODP group used for the iso11770-4-dl-2048 algorithm is defined 1325 by the following parameters. 1327 The prime is: 1329 q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 1330 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 1331 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 1332 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 1333 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D 1334 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 1335 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 1336 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B 1337 E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 1338 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 1339 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF. 1341 The generator is: 1343 g = 2. 1345 The size of the subgroup generated by g is: 1347 r = (q - 1) / 2 = 1348 0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 1349 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E 1350 F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 1351 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 1352 F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E 1353 E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF 1354 C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 1355 B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D 1356 F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964 1357 EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288 1358 0AB9472D 45565534 7FFFFFFF FFFFFFFF. 1360 The MODP group used for the iso11770-4-dl-4096 algorithm is defined 1361 by the following parameters. 1363 The prime is: 1365 q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 1366 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 1367 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 1368 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 1369 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D 1370 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 1371 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 1372 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B 1373 E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 1374 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 1375 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 1376 ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 1377 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B 1378 F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C 1379 BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 1380 43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 1381 88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA 1382 2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6 1383 287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED 1384 1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9 1385 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199 1386 FFFFFFFF FFFFFFFF. 1388 The generator is: 1390 g = 2. 1392 The size of the subgroup generated by g is: 1394 r = (q - 1) / 2 = 1395 0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 1396 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E 1397 F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 1398 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 1399 F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E 1400 E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF 1401 C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 1402 B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D 1403 F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964 1404 EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288 1405 0AB9472D 45556216 D6998B86 82283D19 D42A90D5 EF8E5D32 1406 767DC282 2C6DF785 457538AB AE83063E D9CB87C2 D370F263 1407 D5FAD746 6D8499EB 8F464A70 2512B0CE E771E913 0D697735 1408 F897FD03 6CC50432 6C3B0139 9F643532 290F958C 0BBD9006 1409 5DF08BAB BD30AEB6 3B84C460 5D6CA371 047127D0 3A72D598 1410 A1EDADFE 707E8847 25C16890 54908400 8D391E09 53C3F36B 1411 C438CD08 5EDD2D93 4CE1938C 357A711E 0D4A341A 5B0A85ED 1412 12C1F4E5 156A2674 6DDDE16D 826F477C 97477E0A 0FDF6553 1413 143E2CA3 A735E02E CCD94B27 D04861D1 119DD0C3 28ADF3F6 1414 8FB094B8 67716BD7 DC0DEEBB 10B8240E 68034893 EAD82D54 1415 C9DA754C 46C7EEE0 C37FDBEE 48536047 A6FA1AE4 9A0318CC 1416 FFFFFFFF FFFFFFFF. 1418 Appendix B. Derived numerical values 1420 This section gives several numerical values for implementing this 1421 protocol, derived from the above specifications. The values shown in 1422 this section are for informative purpose only. 1424 +----------------+---------+---------+---------+---------+----------+ 1425 | | dl-2048 | dl-4096 | ec-p256 | ec-p521 | | 1426 +----------------+---------+---------+---------+---------+----------+ 1427 | Size of w_A | 2048 | 4096 | 257 | 522 | (bits) | 1428 | etc. | | | | | | 1429 | Size of H(...) | 256 | 512 | 256 | 512 | (bits) | 1430 | length of | 256 | 512 | 33 | 66 | (octets) | 1431 | OCTETS(w_A) | | | | | | 1432 | etc. | | | | | | 1433 | length of wa, | 346 * | 686 * | 66 | 132 | (octets) | 1434 | wb field | | | | | | 1435 | values. | | | | | | 1436 | length of oa, | 46 * | 90 * | 64 | 128 | (octets) | 1437 | ob field | | | | | | 1438 | values. | | | | | | 1439 | minimum | 2048 | 4096 | 1 | 1 | | 1440 | allowed s_A | | | | | | 1441 +----------------+---------+---------+---------+---------+----------+ 1443 (The numbers marked with * include enclosing quotation marks.) 1445 Appendix C. Draft Remarks from the Authors 1447 The following items are currently under consideration for future 1448 revisions by the authors. 1450 o Allow wildcard domain specifications (e.g. "*.example.com") for 1451 auth-domain parameters (Section 4.1). 1453 o Whether to allow host validation for HTTP/TLS (Section 8). 1455 o Hashing functions for "tls-cert" verification: whether to use the 1456 certificate-specified one or algorithm-specified one (Section 8). 1457 Note that existing implementations of TLS should be considered to 1458 determine this. 1460 o Whether to use "TLS channel binding" 1461 [I-D.altman-tls-channel-bindings] for "tls-key" verification 1462 (Section 8). The same as above. 1464 Appendix D. Draft Change Log 1466 D.1. Changes in revision 02 1468 o Auth-realm is extended to allow full-scheme type. 1470 o A decision diagram for clients and decision procedures for servers 1471 are added. 1473 o 401-B1 and req-A3 messages is changed to have authentication realm 1474 information. 1476 o Bugs on equations for o_A and o_B is fixed. 1478 o Detailed equations for the whole algorithm is included. 1480 o Elliptic-curve algorithms are updated. 1482 o Several clarifications and other minor updates. 1484 Authors' Addresses 1486 Yutaka Oiwa 1487 National Institute of Advanced Industrial Science and Technology 1488 Research Center for Information Security 1489 Akihabara Daibiru #1102 1490 1-18-13 Sotokanda 1491 Chiyoda-ku, Tokyo 1492 JP 1494 Phone: +81 3-5298-4722 1495 Email: mutual-auth-contact@m.aist.go.jp 1497 Hajime Watanabe 1498 National Institute of Advanced Industrial Science and Technology 1500 Hiromitsu Takagi 1501 National Institute of Advanced Industrial Science and Technology 1503 Hirofumi Suzuki 1504 Yahoo! Japan, Inc. 1505 Roppongi Hills Mori Tower 1506 6-10-1 Roppongi 1507 Minato-ku, Tokyo 1508 JP 1510 Phone: +81 3-6440-6290 1512 Full Copyright Statement 1514 Copyright (C) The IETF Trust (2008). 1516 This document is subject to the rights, licenses and restrictions 1517 contained in BCP 78, and except as set forth therein, the authors 1518 retain all their rights. 1520 This document and the information contained herein are provided on an 1521 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1522 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1523 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1524 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1525 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1526 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1528 Intellectual Property 1530 The IETF takes no position regarding the validity or scope of any 1531 Intellectual Property Rights or other rights that might be claimed to 1532 pertain to the implementation or use of the technology described in 1533 this document or the extent to which any license under such rights 1534 might or might not be available; nor does it represent that it has 1535 made any independent effort to identify any such rights. Information 1536 on the procedures with respect to rights in RFC documents can be 1537 found in BCP 78 and BCP 79. 1539 Copies of IPR disclosures made to the IETF Secretariat and any 1540 assurances of licenses to be made available, or the result of an 1541 attempt made to obtain a general license or permission for the use of 1542 such proprietary rights by implementers or users of this 1543 specification can be obtained from the IETF on-line IPR repository at 1544 http://www.ietf.org/ipr. 1546 The IETF invites any interested party to bring to its attention any 1547 copyrights, patents or patent applications, or other proprietary 1548 rights that may cover technology that may be required to implement 1549 this standard. Please address the information to the IETF at 1550 ietf-ipr@ietf.org. 1552 Acknowledgment 1554 Funding for the RFC Editor function is provided by the IETF 1555 Administrative Support Activity (IASA).