idnits 2.17.1 draft-oiwa-httpauth-mutual-algo-02.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 (April 24, 2014) is 3652 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '4' on line 284 == Outdated reference: A later version (-11) exists of draft-ietf-httpauth-mutual-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPAUTH Working Group Y. Oiwa 3 Internet-Draft H. Watanabe 4 Intended status: Experimental H. Takagi 5 Expires: October 26, 2014 RISEC, AIST 6 K. Maeda 7 T. Hayashi 8 Lepidum 9 Y. Ioku 10 Individual 11 April 24, 2014 13 Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic 14 Algorithms 15 draft-oiwa-httpauth-mutual-algo-02 17 Abstract 19 This document specifies some cryptographic algorithms which will be 20 used for the Mutual user authentication method for the Hyper-text 21 Transport 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 October 26, 2014. 40 Copyright Notice 42 Copyright (c) 2014 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. Authentication Algorithms . . . . . . . . . . . . . . . . . . 3 60 2.1. Support Functions and Notations . . . . . . . . . . . . . 4 61 2.2. Functions for Discrete-Logarithm Settings . . . . . . . . 5 62 2.3. Functions for Elliptic-Curve Settings . . . . . . . . . . 6 63 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 5. Notice on intellectual properties . . . . . . . . . . . . . . 8 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 68 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 69 Appendix A. (Informative) Group Parameters for 70 Discrete-Logarithm Based Algorithms . . . . . . . . . 9 71 Appendix B. (Informative) Derived Numerical Values . . . . . . . 11 72 Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 12 73 C.1. Changes in HTTPAUTH revision 02 . . . . . . . . . . . . . 12 74 C.2. Changes in HTTPAUTH revision 01 . . . . . . . . . . . . . 12 75 C.3. Changes in revision 02 . . . . . . . . . . . . . . . . . . 12 76 C.4. Changes in revision 01 . . . . . . . . . . . . . . . . . . 12 77 C.5. Changes in revision 00 . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 This document specifies some algorithms for Mutual authentication 83 protocol for Hyper-Text Transport Protocol (HTTP) 84 [I-D.ietf-httpauth-mutual]. The algorithms are based on so-called 85 "Augumented Password-based Authenticated Key Exchange" (Augumented 86 PAKE) techniques. In particular, it uses one of three key exchange 87 algorithm defined in the ISO 11770-4: "Key management - Mechanisms 88 based on weak secrets" [ISO.11770-4.2006] as a basis. 90 In very brief summary, the Mutual authentication protocol exchanges 91 four values, K_c1, K_s1, VK_c and VK_s, to perform authenticated key 92 exchanges, using the password-derived secret pi and its "augumented 93 version" J(pi). This document defines the set of functions K_c1, 94 K_s1, and J for a specific algorithm family. 96 Please note that, from the view of cryptographic literatures, the 97 original functionality of Augumented PAKE is separated into the 98 functions K_c1 and K_s1 defined in this draft, and the functions VK_c 99 and VK_s defined in Section 11 of [I-D.ietf-httpauth-mutual] as 100 "default functions". For the purpose of security analysis, please 101 also refer to these functions. 103 1.1. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in 108 [RFC2119]. 110 The term "natural numbers" refers to the non-negative integers 111 (including zero) throughout this document. 113 This document treats target (codomain) of hash functions to be octet 114 strings. The notation INT(H(s)) gives a natural-number output of 115 hash function H applied to string s. 117 2. Authentication Algorithms 119 This document specifies only one family of the authentication 120 algorithm. The family consists of four authentication algorithms, 121 which only differ in their underlying mathematical groups and 122 security parameters. The algorithms do not add any additional 123 parameters. The tokens for these algorithms are 125 o iso-kam3-dl-2048-sha256: for the 2048-bit discrete-logarithm 126 setting with the SHA-256 hash function. 128 o iso-kam3-dl-4096-sha512: for the 4096-bit discrete-logarithm 129 setting with the SHA-512 hash function. 131 o iso-kam3-ec-p256-sha256: for the 256-bit prime-field elliptic- 132 curve setting with the SHA-256 hash function. 134 o iso-kam3-ec-p521-sha512: for the 521-bit prime-field elliptic- 135 curve setting with the SHA-512 hash function. 137 For discrete-logarithm settings, the underlying groups are the 2048- 138 bit and 4096-bit MODP groups defined in [RFC3526], respectively. See 139 Appendix A for the exact specifications of the groups and associated 140 parameters. The hash functions H are SHA-256 for the 2048-bit group 141 and SHA-512 for the 4096-bit group, respectively, defined in FIPS PUB 142 180-2 [FIPS.180-2.2002]. The hash iteration count nIterPi is 16384. 143 The representation of the parameters kc1, ks1, vkc, and vks is 144 base64-fixed-number. 146 For the elliptic-curve settings, the underlying groups are the 147 elliptic curves over the prime fields P-256 and P-521, respectively, 148 specified in the appendix D.1.2 of FIPS PUB 186-3 [FIPS.186-3.2009] 149 specification. The hash functions H, which are referenced by the 150 core document, are SHA-256 for the P-256 curve and SHA-512 for the 151 P-521 curve, respectively. The hash iteration count nIterPi is 152 16384. The representation of the parameters kc1, ks1, vkc, and vks 153 is hex-fixed-number. 155 Note: This algorithm is based on the Key Agreement Mechanism 3 (KAM3) 156 defined in Section 6.3 of ISO/IEC 11770-4 [ISO.11770-4.2006] with a 157 few modifications/improvements. However, implementers should use 158 this document as the normative reference, because the algorithm has 159 been changed in several minor details as well as major improvements. 161 2.1. Support Functions and Notations 163 The algorithm definitions use several support functions and notations 164 defined below: 166 The integers in the specification are in decimal, or in hexadecimal 167 when prefixed with "0x". 169 The functions named octet(), OCTETS(), and INT() are those defined in 170 the core specification [I-D.ietf-httpauth-mutual]. 172 Note: The definition of OCTETS() is different from the function 173 GE2OS_x in the original ISO specification, which takes the shortest 174 representation without preceding zeros. 176 All of the algorithms defined in this specification use the default 177 functions defined in the core specification (defined in Section 11 of 178 [I-D.ietf-httpauth-mutual]) for computing the values pi, VK_c and 179 VK_s. 181 2.2. Functions for Discrete-Logarithm Settings 183 In this section, an equation (x / y mod z) denotes a natural number w 184 less than z that satisfies (w * y) mod z = x mod z. 186 For the discrete-logarithm, we refer to some of the domain parameters 187 by using the following symbols: 189 o q: for "the prime" defining the MODP group. 191 o g: for "the generator" associated with the group. 193 o r: for the order of the subgroup generated by g. 195 The function J is defined as 197 J(pi) = g^(pi) mod q. 199 The value of K_c1 is derived as 201 K_c1 = g^(S_c1) mod q, 203 where S_c1 is a random integer within range [1, r-1] and r is the 204 size of the subgroup generated by g. In addition, S_c1 MUST be 205 larger than log(q)/log(g) (so that g^(S_c1) > q). 207 The value of K_c1 SHALL satisfy 1 < K_c1 < q-1. The server MUST 208 check this condition upon reception. 210 Let an intermediate value t_1 be 212 t_1 = INT(H(octet(1) | OCTETS(K_c1))), 214 the value of K_s1 is derived from J(pi) and K_c1 as: 216 K_s1 = (J(pi) * K_c1^(t_1))^(S_s1) mod q 218 where S_s1 is a random number within range [1, r-1]. The value of 219 K_s1 MUST satisfy 1 < K_s1 < q-1. If this condition is not held, the 220 server MUST retry using another value for S_s1. The client MUST 221 check this condition upon reception. 223 Let an intermediate value t_2 be 224 t_2 = INT(H(octet(2) | OCTETS(K_c1) | OCTETS(K_s1))), 226 the value z on the client side is derived by the following equation: 228 z = K_s1^((S_c1 + t_2) / (S_c1 * t_1 + pi) mod r) mod q. 230 The value z on the server side is derived by the following equation: 232 z = (K_c1 * g^(t_2))^(S_s1) mod q. 234 (Note: the original ISO specification contained a message pair 235 containing verification of value z along with the "transcript" of the 236 protocol exchange. The functionality of this kind is contained in 237 the functions VK_c and VK_s.) 239 2.3. Functions for Elliptic-Curve Settings 241 For the elliptic-curve setting, we refer to some of the domain 242 parameters by the following symbols: 244 o q: for the prime used to define the group. 246 o G: for the defined point called the generator. 248 o r: for the order of the subgroup generated by G. 250 The function P(p) converts a curve point p into an integer 251 representing point p, by computing x * 2 + (y mod 2), where (x, y) 252 are the coordinates of point p. P'(z) is the inverse of function P, 253 that is, it converts an integer z to a point p that satisfies P(p) = 254 z. If such p exists, it is uniquely defined. Otherwise, z does not 255 represent a valid curve point. The operator + indicates the 256 elliptic-curve group operation, and the operation [x] * p denotes an 257 integer-multiplication of point p: it calculates p + p + ... (x 258 times) ... + p. See the literatures on elliptic-curve cryptography 259 for the exact algorithms used for those functions (e.g. Section 3 of 260 [RFC6090], which uses different notations, though.) 0_E represents 261 the infinity point. The equation (x / y mod z) denotes a natural 262 number w less than z that satisfies (w * y) mod z = x mod z. 264 The function J is defined as 266 J(pi) = [pi] * G. 268 The value of K_c1 is derived as 270 K_c1 = P(K_c1'), where K_c1' = [S_c1] * G, 271 where S_c1 is a random number within range [1, r-1]. The value of 272 K_c1 MUST represent a valid curve point, and K_c1' SHALL NOT be 0_E. 273 The server MUST check this condition upon reception. 275 Let an intermediate integer t_1 be 277 t_1 = INT(H(octet(1) | OCTETS(K_c1))), 279 the value of K_s1 is derived from J(pi) and K_c1' = P'(K_c1) as: 281 K_s1 = P([S_s1] * (J(pi) + [t_1] * K_c1')), 283 where S_s1 is a random number within range [1, r-1]. The value of 284 K_s1 MUST represent a valid curve point and satisfy [4] * P'(K_s1) <> 285 0_E. If this condition is not satisfied, the server MUST retry using 286 another value for S_s1. The client MUST check this condition upon 287 reception. 289 Let an intermediate integer t_2 be 291 t_2 = INT(H(octet(2) | OCTETS(K_c1) | OCTETS(K_s1))), 293 the value z on the client side is derived by the following equation: 295 z = P([(S_c1 + t_2) / (S_c1 * t_1 + pi) mod r] * P'(K_s1)). 297 The value z on the server side is derived by the following equation: 299 z = P([S_s1] * (P'(K_c1) + [t_2] * G)). 301 3. IANA Considerations 303 Four tokens iso-kam3-dl-2048-sha256, iso-kam3-dl-4096-sha512, 304 iso-kam3-ec-p256-sha256 and iso-kam3-ec-p521-sha512 shall be 305 allocated and registered according to the provision of the core 306 documentation when this document is promoted to an RFC. 308 Note: More formal declarations will be added in the future drafts to 309 meet the RFC 5226 requirements. 311 4. Security Considerations 313 Refer the corresponding section of the core specification for 314 algorithm-independent, generic considerations. 316 o All random numbers used in these algorithms MUST be at least 317 cryptographically computationally secure against forward and 318 backward guessing attacks. 320 o Computation times of all numerical operations on discrete- 321 logarithm group elements and elliptic-curve points MUST be 322 normalized and made independent of the exact values, to prevent 323 timing-based side-channel attacks. 325 The usual construction of authenticated key exchange algorithms are 326 build from a key-exchange period and a key verification period, and 327 the latter usually involving some kind of exchange transaction to be 328 verified, to avoid security risks or vulnerabilities caused from 329 mixing of values from two or more key exchanges. In the design of 330 the algorithms in this document, such a functionality is defined in 331 generalized manner in the core specification 332 [I-D.ietf-httpauth-mutual] (see definitions of VK_c and VK_s). If 333 any attempts to reuse the algorithm defined above with any other 334 protocols exist, care MUST be taken on that aspect. 336 5. Notice on intellectual properties 338 The National Institute of Advanced Industrial Science and Technology 339 (AIST) and Yahoo! Japan, Inc. has jointly submitted a patent 340 application on the protocol proposed in this documentation to the 341 Patent Office of Japan. The patent is intended to be open to any 342 implementors of this protocol and its variants under non-exclusive 343 royalty-free manner. For the details of the patent application and 344 its status, please contact the author of this document. 346 The elliptic-curve based authentication algorithms might involve 347 several existing third-party patents. The authors of the document 348 take no position regarding the validity or scope of such patents, and 349 other patents as well. 351 6. References 353 6.1. Normative References 355 [FIPS.180-2.2002] 356 National Institute of Standards and Technology, "Secure 357 Hash Standard", FIPS PUB 180-2, August 2002, . 360 [FIPS.186-3.2009] 361 National Institute of Standards and Technology, "Digital 362 Signature Standard (DSS)", FIPS PUB 186-3, June 2009, . 366 [I-D.ietf-httpauth-mutual] 367 Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 368 T., and Y. Ioku, "Mutual Authentication Protocol for 369 HTTP", draft-ietf-httpauth-mutual-02 (work in progress), 370 April 2014. 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 375 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 376 Diffie-Hellman groups for Internet Key Exchange (IKE)", 377 RFC 3526, May 2003. 379 6.2. Informative References 381 [ISO.11770-4.2006] 382 International Organization for Standardization, 383 "Information technology - Security techniques - Key 384 management - Part 4: Mechanisms based on weak secrets", 385 ISO Standard 11770-4, May 2006. 387 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 388 Curve Cryptography Algorithms", RFC 6090, February 2011. 390 Appendix A. (Informative) Group Parameters for Discrete-Logarithm Based 391 Algorithms 393 The MODP group used for the iso-kam3-dl-2048-sha256 algorithm is 394 defined by the following parameters. 396 The prime is: 398 q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 399 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 400 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 401 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 402 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D 403 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 404 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 405 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B 406 E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 407 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 408 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF. 410 The generator is: 412 g = 2. 414 The size of the subgroup generated by g is: 416 r = (q - 1) / 2 = 417 0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 418 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E 419 F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 420 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 421 F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E 422 E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF 423 C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 424 B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D 425 F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964 426 EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288 427 0AB9472D 45565534 7FFFFFFF FFFFFFFF. 429 The MODP group used for the iso-kam3-dl-4096-sha512 algorithm is 430 defined by the following parameters. 432 The prime is: 434 q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 435 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 436 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 437 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 438 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D 439 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 440 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 441 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B 442 E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 443 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 444 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 445 ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 446 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B 447 F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C 448 BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 449 43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 450 88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA 451 2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6 452 287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED 453 1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9 454 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199 455 FFFFFFFF FFFFFFFF. 457 The generator is: 459 g = 2. 461 The size of the subgroup generated by g is: 463 r = (q - 1) / 2 = 464 0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 465 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E 466 F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 467 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 468 F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E 469 E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF 470 C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 471 B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D 472 F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964 473 EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288 474 0AB9472D 45556216 D6998B86 82283D19 D42A90D5 EF8E5D32 475 767DC282 2C6DF785 457538AB AE83063E D9CB87C2 D370F263 476 D5FAD746 6D8499EB 8F464A70 2512B0CE E771E913 0D697735 477 F897FD03 6CC50432 6C3B0139 9F643532 290F958C 0BBD9006 478 5DF08BAB BD30AEB6 3B84C460 5D6CA371 047127D0 3A72D598 479 A1EDADFE 707E8847 25C16890 54908400 8D391E09 53C3F36B 480 C438CD08 5EDD2D93 4CE1938C 357A711E 0D4A341A 5B0A85ED 481 12C1F4E5 156A2674 6DDDE16D 826F477C 97477E0A 0FDF6553 482 143E2CA3 A735E02E CCD94B27 D04861D1 119DD0C3 28ADF3F6 483 8FB094B8 67716BD7 DC0DEEBB 10B8240E 68034893 EAD82D54 484 C9DA754C 46C7EEE0 C37FDBEE 48536047 A6FA1AE4 9A0318CC 485 FFFFFFFF FFFFFFFF. 487 Appendix B. (Informative) Derived Numerical Values 489 This section provides several numerical values for implementing this 490 protocol, derived from the above specifications. The values shown in 491 this section are for informative purposes only. 493 +----------------+---------+---------+---------+---------+----------+ 494 | | dl-2048 | dl-4096 | ec-p256 | ec-p521 | | 495 +----------------+---------+---------+---------+---------+----------+ 496 | Size of K_c1 | 2048 | 4096 | 257 | 522 | (bits) | 497 | etc. | | | | | | 498 | hSize, Size of | 256 | 512 | 256 | 512 | (bits) | 499 | H(...) | | | | | | 500 | length of | 256 | 512 | 33 | 66 | (octets) | 501 | OCTETS(K_c1) | | | | | | 502 | etc. | | | | | | 503 | length of kc1, | 344 * | 684 * | 66 | 132 | (octets) | 504 | ks1 param. | | | | | | 505 | values. | | | | | | 506 | length of vkc, | 44 * | 88 * | 64 | 128 | (octets) | 507 | vks param. | | | | | | 508 | values. | | | | | | 509 | minimum | 2048 | 4096 | 1 | 1 | | 510 | allowed S_c1 | | | | | | 511 +----------------+---------+---------+---------+---------+----------+ 513 (The numbers marked with an * do not include any enclosing quotation 514 marks.) 516 Appendix C. (Informative) Draft Change Log 518 C.1. Changes in HTTPAUTH revision 02 520 o Added nIterPi parameter to adjust to the changes to the core 521 draft. 523 o Added a note on the verification of exchange transaction. 525 C.2. Changes in HTTPAUTH revision 01 527 o Notation change: integer output of hash function will be notated 528 as INT(H(*)), changed from H(*). 530 C.3. Changes in revision 02 532 o Implementation hints in appendix changed (number of characters for 533 base64-fixed-number does not contain double-quotes). 535 C.4. Changes in revision 01 537 o Parameter names renamed. 539 o Some expressions clarified without changing the value. 541 C.5. Changes in revision 00 543 The document is separated from the revision 08 of the core 544 documentation. 546 Authors' Addresses 548 Yutaka Oiwa 549 National Institute of Advanced Industrial Science and Technology 550 Research Institute for Secure Systems 551 3-11-46 Nakouji 552 Amagasaki, Hyogo 553 JP 555 Email: mutual-auth-contact-ml@aist.go.jp 557 Hajime Watanabe 558 National Institute of Advanced Industrial Science and Technology 559 Research Institute for Secure Systems 560 Tsukuba Central 2 561 1-1-1 Umezono 562 Tsukuba-shi, Ibaraki 563 JP 565 Hiromitsu Takagi 566 National Institute of Advanced Industrial Science and Technology 567 Research Institute for Secure Systems 568 Tsukuba Central 2 569 1-1-1 Umezono 570 Tsukuba-shi, Ibaraki 571 JP 573 Kaoru Maeda 574 Lepidum Co. Ltd. 575 #602, Village Sasazuka 3 576 1-30-3 Sasazuka 577 Shibuya-ku, Tokyo 578 JP 580 Tatsuya Hayashi 581 Lepidum Co. Ltd. 582 #602, Village Sasazuka 3 583 1-30-3 Sasazuka 584 Shibuya-ku, Tokyo 585 JP 586 Yuichi Ioku 587 Individual