idnits 2.17.1 draft-ietf-httpauth-mutual-algo-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 (November 14, 2016) is 2720 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPAUTH Working Group Y. Oiwa 3 Internet-Draft H. Watanabe 4 Intended status: Experimental H. Takagi 5 Expires: May 18, 2017 ITRI, AIST 6 K. Maeda 7 T. Hayashi 8 Lepidum 9 Y. Ioku 10 Individual 11 November 14, 2016 13 Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic 14 Algorithms 15 draft-ietf-httpauth-mutual-algo-07 17 Abstract 19 This document specifies cryptographic algorithms for use with the 20 Mutual user authentication method for the Hyper-text Transport 21 Protocol (HTTP). 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 18, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Cryptographic Overview (Non-normative) . . . . . . . . . . . . 3 60 3. Authentication Algorithms . . . . . . . . . . . . . . . . . . 4 61 3.1. Support Functions and Notations . . . . . . . . . . . . . 5 62 3.2. Functions for Discrete Logarithm Settings . . . . . . . . 6 63 3.3. Functions for Elliptic-Curve Settings . . . . . . . . . . 7 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 5.1. General Implementation Considerations . . . . . . . . . . 9 67 5.2. Cryptographic Assumptions and Considerations . . . . . . . 9 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 70 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 71 Appendix A. (Informative) Group Parameters for Discrete 72 Logarithm Based Algorithms . . . . . . . . . . . . . 11 73 Appendix B. (Informative) Derived Numerical Values . . . . . . . 13 74 Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 14 75 C.1. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 14 76 C.2. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 14 77 C.3. Changes in Httpauth WG revision 04 . . . . . . . . . . . . 14 78 C.4. Changes in Httpauth WG revision 03 . . . . . . . . . . . . 14 79 C.5. Changes in Httpauth WG revision 02 . . . . . . . . . . . . 14 80 C.6. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 14 81 C.7. Changes in Httpauth WG revision 00 . . . . . . . . . . . . 14 82 C.8. Changes in HTTPAUTH revision 02 . . . . . . . . . . . . . 14 83 C.9. Changes in HTTPAUTH revision 01 . . . . . . . . . . . . . 15 84 C.10. Changes in revision 02 . . . . . . . . . . . . . . . . . . 15 85 C.11. Changes in revision 01 . . . . . . . . . . . . . . . . . . 15 86 C.12. Changes in revision 00 . . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 This document specifies algorithms for use with Mutual authentication 92 protocol for Hyper-Text Transport Protocol (HTTP) 93 [I-D.ietf-httpauth-mutual] (referred as the "core specification" 94 hereafter). The algorithms are based on "Augmented Password-based 95 Authenticated Key Exchange" (Augmented PAKE) techniques. In 96 particular, it uses one of three key exchange algorithms defined in 97 ISO 11770-4: "Key management - Mechanisms based on weak secrets" 98 [ISO.11770-4.2006] as its basis. 100 In very brief summary, Mutual authentication protocol exchanges four 101 values, K_c1, K_s1, VK_c and VK_s, to perform authenticated key 102 exchanges, using the password-derived secret pi and its "augmented 103 version" J(pi). This document defines the set of functions K_c1, 104 K_s1, and J for a specific algorithm family. 106 Please note that from the view of cryptographic literature, the 107 original functionality of Augmented PAKE is separated into the 108 functions K_c1 and K_s1 as defined in this draft, and the functions 109 VK_c and VK_s, which are defined in Section 11 of 110 [I-D.ietf-httpauth-mutual] as "default functions". For the purpose 111 of security analysis, please also refer to these functions. 113 1.1. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 [RFC2119]. 120 The term "natural numbers" refers to the non-negative integers 121 (including zero) throughout this document. 123 This document treats both the input (domain) and the output 124 (codomain) of hash functions to be octet strings. When a natural 125 number output of hash function H is required, it will be notated like 126 INT(H(s)). 128 2. Cryptographic Overview (Non-normative) 130 The cryptographic primitive used in this algorithm specification is 131 based on a variant of augmented PAKE proposed by T. Kwon, called 132 APKAS-AMP, originally submitted to IEEE P1363.2. The general flow of 133 the successful exchange is shown below, for informative purposes 134 only. The multiplicative notations are used for group operators, and 135 all modulus operations for finite groups (mod q and mod r) are 136 omitted. 138 C: S_c1 = random 139 C: K_c1 = g^(S_c1) 140 ----- ID, K_c1 -----> 141 C: t_1 = H1(K_c1) S: t_1 = H1(K_c1) 142 S: fetch J = g^pi by ID 143 S: S_s1 = random 144 S: K_s1 = (J * K_c1^(t_1))^(S_s1) 145 <----- K_s1 ----- 146 C: t_2 = H2(K_c1, K_s1) S: t_2 = H2(K_c1, K_s1) 147 C: z = K_s1^((S_c1 + t_2) / (S_c1 * t_1 + pi)) 148 S: z' = (K_c1 * g^(t_2))^(S_s1) 149 (assumption at this point: z = z' if authentication succeeded) 151 C: VK_c = H4(K_c1, K_s1, z) S: VK_c' = H4(K_c1, K_s1, z') 152 ----- VK_c -------> 153 S: assert(VK_c = VK_c') 155 C: VK_s' = H3(K_c1, K_s1, z) S: VK_s = H3(K_c1, K_s1, z') 156 <----- VK_s ------ 157 C: assert(VK_s = VK_s') 159 Note that the concrete (binary) message formats (mapping to HTTP 160 messages), as well as the formal definitions of equations for the 161 latter two messages, are defined in core specification 162 [I-D.ietf-httpauth-mutual]. The formal definitions for values 163 corresponding to the first two messages are defined in the following 164 sections. 166 3. Authentication Algorithms 168 This document specifies one family of APKAS-AMP based algorithm. 169 This family consists of four authentication algorithms, which differ 170 only in their underlying mathematical groups and security parameters. 171 These algorithms do not add any additional parameters. The tokens 172 for these algorithms are 174 o iso-kam3-dl-2048-sha256: for the 2048-bit discrete logarithm 175 setting with the SHA-256 hash function. 177 o iso-kam3-dl-4096-sha512: for the 4096-bit discrete logarithm 178 setting with the SHA-512 hash function. 180 o iso-kam3-ec-p256-sha256: for the 256-bit prime-field elliptic- 181 curve setting with the SHA-256 hash function. 183 o iso-kam3-ec-p521-sha512: for the 521-bit prime-field elliptic- 184 curve setting with the SHA-512 hash function. 186 For discrete logarithm settings, the underlying groups are the 2048- 187 bit and 4096-bit MODP groups defined in [RFC3526]. See Appendix A 188 for the exact specifications of the groups and associated parameters. 189 The hash functions H are SHA-256 for the 2048-bit group and SHA-512 190 for the 4096-bit group, respectively, defined in FIPS PUB 180-2 191 [FIPS.180-2.2002]. The hash iteration count nIterPi is 16384. The 192 representation of the parameters kc1, ks1, vkc, and vks is base64- 193 fixed-number. 195 For the elliptic-curve settings, the underlying groups are the 196 elliptic curves over the prime fields P-256 and P-521, respectively, 197 specified in the appendix D.1.2 of the FIPS PUB 186-4 198 [FIPS.186-4.2013] specification. The hash functions H, which are 199 referenced by the core document, are SHA-256 for the P-256 curve and 200 SHA-512 for the P-521 curve, respectively. Cofactors of these curves 201 are 1. The hash iteration count nIterPi is 16384. The 202 representation of the parameters kc1, ks1, vkc, and vks is hex-fixed- 203 number. 205 Note: This algorithm is based on the Key Agreement Mechanism 3 (KAM3) 206 defined in Section 6.3 of ISO/IEC 11770-4 [ISO.11770-4.2006] with a 207 few modifications/improvements. However, implementers should use 208 this document as the normative reference, because the algorithm has 209 been changed in several minor details as well as with major 210 improvements. 212 3.1. Support Functions and Notations 214 The algorithm definitions use the support functions and notations 215 defined below: 217 The integers in the specification are in decimal by default, or in 218 hexadecimal when prefixed with "0x". 220 The functions named octet(), OCTETS(), and INT() are those defined in 221 the core specification [I-D.ietf-httpauth-mutual]. 223 Note: The definition of OCTETS() is different from the function 224 GE2OS_x in the original ISO specification, which takes the shortest 225 representation without preceding zeros. 227 All of the algorithms defined in this specification use the default 228 functions defined in the core specification (defined in Section 11 of 229 [I-D.ietf-httpauth-mutual]) for computing the values pi, VK_c and 230 VK_s. 232 3.2. Functions for Discrete Logarithm Settings 234 In this section, an equation (x / y mod z) denotes a natural number w 235 less than z that satisfies (w * y) mod z = x mod z. 237 For the discrete logarithm, we refer to some of the domain parameters 238 by using the following symbols: 240 o q: for "the prime" defining the MODP group. 242 o g: for "the generator" associated with the group. 244 o r: for the order of the subgroup generated by g. 246 The function J is defined as 248 J(pi) = g^(pi) mod q. 250 The value of K_c1 is derived as 252 K_c1 = g^(S_c1) mod q, 254 where S_c1 is a random integer within range [1, r-1] and r is the 255 size of the subgroup generated by g. In addition, S_c1 MUST be 256 larger than log(q)/log(g) (so that g^(S_c1) > q). 258 The server MUST check the condition 1 < K_c1 < q-1 upon reception. 260 Let an intermediate value t_1 be 262 t_1 = INT(H(octet(1) | OCTETS(K_c1))), 264 the value of K_s1 is derived from J(pi) and K_c1 as: 266 K_s1 = (J(pi) * K_c1^(t_1))^(S_s1) mod q 268 where S_s1 is a random number within range [1, r-1]. The value of 269 K_s1 MUST satisfy 1 < K_s1 < q-1. If this condition is not held, the 270 server MUST reject the exchange. The client MUST check this 271 condition upon reception. 273 Let an intermediate value t_2 be 275 t_2 = INT(H(octet(2) | OCTETS(K_c1) | OCTETS(K_s1))), 277 the value z on the client side is derived by the following equation: 279 z = K_s1^((S_c1 + t_2) / (S_c1 * t_1 + pi) mod r) mod q. 281 The value z on the server side is derived by the following equation: 283 z = (K_c1 * g^(t_2))^(S_s1) mod q. 285 (Note: the original ISO specification contained a message pair 286 containing verification of value z along with the "transcript" of the 287 protocol exchange. This functionality is contained in the functions 288 VK_c and VK_s.) 290 3.3. Functions for Elliptic-Curve Settings 292 For the elliptic-curve setting, we refer to some of the domain 293 parameters by the following symbols: 295 o q: for the prime used to define the group. 297 o G: for the point defined with the underlying group called "the 298 generator". 300 o h: for the cofactor of the group. 302 o r: for the order of the subgroup generated by G. 304 The function P(p) converts a curve point p into an integer 305 representing point p, by computing x * 2 + (y mod 2), where (x, y) 306 are the coordinates of point p. P'(z) is the inverse of function P, 307 that is, it converts an integer z to a point p that satisfies P(p) = 308 z. If such p exists, it is uniquely defined. Otherwise, z does not 309 represent a valid curve point. 311 The operator + indicates the elliptic-curve group operation, and the 312 operation [x] * p denotes an integer-multiplication of point p: it 313 calculates p + p + ... (x times) ... + p. See the literature on 314 elliptic-curve cryptography for the exact algorithms used for those 315 functions (e.g. Section 3 of [RFC6090], which uses different 316 notations, though). 0_E represents the infinity point. The equation 317 (x / y mod z) denotes a natural number w less than z that satisfies 318 (w * y) mod z = x mod z. 320 The function J is defined as 322 J(pi) = [pi] * G. 324 The value of K_c1 is derived as 326 K_c1 = P(K_c1'), where K_c1' = [S_c1] * G, 328 where S_c1 is a random number within range [1, r-1]. The server MUST 329 check that the value of received K_c1 represents a valid curve point, 330 and [h] * K_c1' is not equal to 0_E. 332 Let an intermediate integer t_1 be 334 t_1 = INT(H(octet(1) | OCTETS(K_c1))), 336 the value of K_s1 is derived from J(pi) and K_c1' = P'(K_c1) as: 338 K_s1 = P([S_s1] * (J(pi) + [t_1] * K_c1')), 340 where S_s1 is a random number within range [1, r-1]. The value of 341 K_s1 MUST represent a valid curve point and satisfy [h] * P'(K_s1) <> 342 0_E. If this condition is not satisfied, the server MUST reject the 343 exchange. The client MUST check this condition upon reception. 345 Let an intermediate integer t_2 be 347 t_2 = INT(H(octet(2) | OCTETS(K_c1) | OCTETS(K_s1))), 349 the value z on the client side is derived by the following equation: 351 z = P([(S_c1 + t_2) / (S_c1 * t_1 + pi) mod r] * P'(K_s1)). 353 The value z on the server side is derived by the following equation: 355 z = P([S_s1] * (P'(K_c1) + [t_2] * G)). 357 4. IANA Considerations 359 This document defines four new tokens to be added to the "HTTP Mutual 360 authentication algorithms" registry; iso-kam3-dl-2048-sha256, 361 iso-kam3-dl-4096-sha512, iso-kam3-ec-p256-sha256 and 362 iso-kam3-ec-p521-sha512, as follows: 364 +-------------------------+-------------------------+---------------+ 365 | Token | Description | Specification | 366 +-------------------------+-------------------------+---------------+ 367 | iso-kam3-dl-2048-sha256 | ISO-11770-4 KAM3, | This document | 368 | | 2048-bit DL | | 369 | iso-kam3-dl-4096-sha512 | ISO-11770-4 KAM3, | This document | 370 | | 4096-bit DL | | 371 | iso-kam3-ec-p256-sha256 | ISO-11770-4 KAM3, | This document | 372 | | 256-bit EC | | 373 | iso-kam3-ec-p521-sha512 | ISO-11770-4 KAM3, | This document | 374 | | 521-bit EC | | 375 +-------------------------+-------------------------+---------------+ 377 5. Security Considerations 379 Please refer to the corresponding section of the core specification 380 [I-D.ietf-httpauth-mutual] for algorithm-independent considerations. 382 5.1. General Implementation Considerations 384 o During the exchange, the value VK_s, defined in 385 [I-D.ietf-httpauth-mutual], MUST only be sent when the server has 386 received a correct (expected) value of VK_c. This is a 387 cryptographic requirement, stated in [ISO.11770-4.2006]. 389 o All random numbers used in these algorithms MUST be at least 390 cryptographically computationally secure against forward and 391 backward guessing attacks. 393 o Computation times of all numerical operations on discrete 394 logarithm group elements and elliptic-curve points MUST be 395 normalized and made independent of the exact values, to prevent 396 timing-based side-channel attacks. 398 5.2. Cryptographic Assumptions and Considerations 400 The notices in this subsection are for those who analyze the security 401 of this algorithm, and those who might want to make a derived work 402 from this algorithm specification. 404 o handling of an invalid K_s1 value in the exchange has been changed 405 from the original ISO specification. The original specifies that 406 the sender should retry with another random S_s1 value, while we 407 specify that the exchange must be rejected. This is due to an 408 observation that this condition is less likely to result from the 409 random error caused by an unlucky choice of S_s1, but more likely 410 the result of a systematic failure from an invalid J(pi) value 411 (even implying possible denial-of-service attacks). 413 o The usual construction of authenticated key exchange algorithms 414 consists of a key exchange phase and a key verification phase. 415 The latter usually involves some kinds of exchange transaction to 416 be verified, to avoid security risks or vulnerabilities caused by 417 mixing values from from two or more key exchanges. In the design 418 of the algorithms in this document, such a functionality is 419 defined in a generalized manner in the core specification 420 [I-D.ietf-httpauth-mutual] (see definitions of VK_c and VK_s). If 421 the algorithm defined above is used in other protocols, this 422 aspect MUST be given careful consideration. 424 o The domain parameters chosen and specified in this draft are based 425 on a few assumptions. In the discrete-logarithm setting, q has to 426 be a safe prime ([(q - 1) / 2] must also be prime), and r should 427 be the largest possible value [(q - 1) / 2]. In the elliptic- 428 curve setting, r has to be prime. Defining a variation of this 429 algorithm using a different domain parameter SHOULD be attentive 430 to these conditions. 432 6. References 434 6.1. Normative References 436 [FIPS.180-2.2002] 437 National Institute of Standards and Technology, "Secure 438 Hash Standard", FIPS PUB 180-2, August 2002, . 441 [FIPS.186-4.2013] 442 National Institute of Standards and Technology, "Digital 443 Signature Standard (DSS)", FIPS PUB 186-4, July 2013, . 446 [I-D.ietf-httpauth-mutual] 447 Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 448 T., and Y. Ioku, "Mutual Authentication Protocol for 449 HTTP", draft-ietf-httpauth-mutual-11 (work in progress), 450 November 2016. 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 454 RFC2119, March 1997, 455 . 457 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 458 Diffie-Hellman groups for Internet Key Exchange (IKE)", 459 RFC 3526, DOI 10.17487/RFC3526, May 2003, 460 . 462 6.2. Informative References 464 [ISO.11770-4.2006] 465 International Organization for Standardization, 466 "Information technology - Security techniques - Key 467 management - Part 4: Mechanisms based on weak secrets", 468 ISO Standard 11770-4, May 2006. 470 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 471 Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/ 472 RFC6090, February 2011, 473 . 475 Appendix A. (Informative) Group Parameters for Discrete Logarithm Based 476 Algorithms 478 The MODP group used for the iso-kam3-dl-2048-sha256 algorithm is 479 defined by the following parameters. 481 The prime is: 483 q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 484 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 485 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 486 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 487 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D 488 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 489 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 490 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B 491 E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 492 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 493 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF. 495 The generator is: 497 g = 2. 499 The size of the subgroup generated by g is: 501 r = (q - 1) / 2 = 502 0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 503 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E 504 F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 505 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 506 F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E 507 E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF 508 C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 509 B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D 510 F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964 511 EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288 512 0AB9472D 45565534 7FFFFFFF FFFFFFFF. 514 The MODP group used for the iso-kam3-dl-4096-sha512 algorithm is 515 defined by the following parameters. 517 The prime is: 519 q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 520 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 521 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 522 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 523 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D 524 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 525 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 526 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B 527 E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 528 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 529 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 530 ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 531 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B 532 F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C 533 BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 534 43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 535 88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA 536 2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6 537 287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED 538 1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9 539 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199 540 FFFFFFFF FFFFFFFF. 542 The generator is: 544 g = 2. 546 The size of the subgroup generated by g is: 548 r = (q - 1) / 2 = 549 0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 550 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E 551 F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 552 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 553 F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E 554 E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF 555 C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 556 B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D 557 F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964 558 EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288 559 0AB9472D 45556216 D6998B86 82283D19 D42A90D5 EF8E5D32 560 767DC282 2C6DF785 457538AB AE83063E D9CB87C2 D370F263 561 D5FAD746 6D8499EB 8F464A70 2512B0CE E771E913 0D697735 562 F897FD03 6CC50432 6C3B0139 9F643532 290F958C 0BBD9006 563 5DF08BAB BD30AEB6 3B84C460 5D6CA371 047127D0 3A72D598 564 A1EDADFE 707E8847 25C16890 54908400 8D391E09 53C3F36B 565 C438CD08 5EDD2D93 4CE1938C 357A711E 0D4A341A 5B0A85ED 566 12C1F4E5 156A2674 6DDDE16D 826F477C 97477E0A 0FDF6553 567 143E2CA3 A735E02E CCD94B27 D04861D1 119DD0C3 28ADF3F6 568 8FB094B8 67716BD7 DC0DEEBB 10B8240E 68034893 EAD82D54 569 C9DA754C 46C7EEE0 C37FDBEE 48536047 A6FA1AE4 9A0318CC 570 FFFFFFFF FFFFFFFF. 572 Appendix B. (Informative) Derived Numerical Values 574 This section provides several numerical values for implementing this 575 protocol, derived from the above specifications. The values shown in 576 this section are for informative purposes only. 578 +----------------+---------+---------+---------+---------+----------+ 579 | | dl-2048 | dl-4096 | ec-p256 | ec-p521 | | 580 +----------------+---------+---------+---------+---------+----------+ 581 | Size of K_c1 | 2048 | 4096 | 257 | 522 | (bits) | 582 | etc. | | | | | | 583 | hSize, Size of | 256 | 512 | 256 | 512 | (bits) | 584 | H(...) | | | | | | 585 | length of | 256 | 512 | 33 | 66 | (octets) | 586 | OCTETS(K_c1) | | | | | | 587 | etc. | | | | | | 588 | length of kc1, | 344 * | 684 * | 66 | 132 | (octets) | 589 | ks1 param. | | | | | | 590 | values. | | | | | | 591 | length of vkc, | 44 * | 88 * | 64 | 128 | (octets) | 592 | vks param. | | | | | | 593 | values. | | | | | | 594 | minimum | 2048 | 4096 | 1 | 1 | | 595 | allowed S_c1 | | | | | | 596 +----------------+---------+---------+---------+---------+----------+ 598 (The numbers marked with an * do not include any enclosing quotation 599 marks.) 601 Appendix C. (Informative) Draft Change Log 603 C.1. Changes in Httpauth WG Revision 06 605 o Authors' addresses updated. 607 C.2. Changes in Httpauth WG Revision 05 609 o Several comments from reviewers are reflected to the text. 611 C.3. Changes in Httpauth WG revision 04 613 o Authors address updated. 615 C.4. Changes in Httpauth WG revision 03 617 o IANA registration information added. 619 C.5. Changes in Httpauth WG revision 02 621 o No technical changes: references updated. 623 C.6. Changes in Httpauth WG revision 01 625 o Changed behavior on failed generation of K_s1. 627 o Security considerations updated. 629 C.7. Changes in Httpauth WG revision 00 631 o Added a note on the choice of elliptic curves. 633 C.8. Changes in HTTPAUTH revision 02 635 o Added nIterPi parameter to adjust to the changes to the core 636 draft. 638 o Added a note on the verification of exchange transaction. 640 C.9. Changes in HTTPAUTH revision 01 642 o Notation change: integer output of hash function will be notated 643 as INT(H(*)), changed from H(*). 645 C.10. Changes in revision 02 647 o Implementation hints in appendix changed (number of characters for 648 base64-fixed-number does not contain double-quotes). 650 C.11. Changes in revision 01 652 o Parameter names renamed. 654 o Some expressions clarified without changing the value. 656 C.12. Changes in revision 00 658 The document is separated from the revision 08 of the core 659 documentation. 661 Authors' Addresses 663 Yutaka Oiwa 664 National Institute of Advanced Industrial Science and Technology 665 Information Technology Research Institute 666 Tsukuba Central 1 667 1-1-1 Umezono 668 Tsukuba-shi, Ibaraki 669 JP 671 Email: y.oiwa@aist.go.jp 673 Hajime Watanabe 674 National Institute of Advanced Industrial Science and Technology 675 Information Technology Research Institute 676 Tsukuba Central 1 677 1-1-1 Umezono 678 Tsukuba-shi, Ibaraki 679 JP 681 Email: h-watanabe@aist.go.jp 682 Hiromitsu Takagi 683 National Institute of Advanced Industrial Science and Technology 684 Information Technology Research Institute 685 Tsukuba Central 1 686 1-1-1 Umezono 687 Tsukuba-shi, Ibaraki 688 JP 690 Email: takagi.hiromitsu@aist.go.jp 692 Kaoru Maeda 693 Lepidum Co. Ltd. 694 Village Sasazuka 3, Suite #602 695 1-30-3 Sasazuka 696 Shibuya-ku, Tokyo 697 JP 699 Email: maeda@lepidum.co.jp 701 Tatsuya Hayashi 702 Lepidum Co. Ltd. 703 Village Sasazuka 3, Suite #602 704 1-30-3 Sasazuka 705 Shibuya-ku, Tokyo 706 JP 708 Email: hayashi@lepidum.co.jp 710 Yuichi Ioku 711 Individual 713 Email: mutual-work@ioku.org