Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3)
draftietfhttpauthmutualalgo07
The information below is for an old version of the document that is already published as an RFC.
Document  Type 
This is an older version of an InternetDraft that was ultimately published as RFC 8121.



Authors  Yutaka Oiwa , Hajime Watanabe , Hiromitsu Takagi , Kaoru Maeda , Tatsuya Hayashi , Yuichi Ioku  
Last updated  20170411 (Latest revision 20161113)  
RFC stream  Internet Engineering Task Force (IETF)  
Intended RFC status  Experimental  
Formats  
Reviews  
Additional resources  Mailing list discussion  
Stream  WG state  Submitted to IESG for Publication  
Document shepherd  Yoav Nir  
Shepherd writeup  Show Last changed 20160716  
IESG  IESG state  Became RFC 8121 (Experimental)  
Action Holders 
(None)


Consensus boilerplate  Yes  
Telechat date  (None)  
Responsible AD  Kathleen Moriarty  
Send notices to  "Yoav Nir" <ynir.ietf@gmail.com>  
IANA  IANA review state  Version Changed  Review Needed  
IANA action state  RFCEdAck 
draftietfhttpauthmutualalgo07
HTTPAUTH Working Group Y. Oiwa InternetDraft H. Watanabe Intended status: Experimental H. Takagi Expires: May 18, 2017 ITRI, AIST K. Maeda T. Hayashi Lepidum Y. Ioku Individual November 14, 2016 Mutual Authentication Protocol for HTTP: KAM3based Cryptographic Algorithms draftietfhttpauthmutualalgo07 Abstract This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hypertext Transport Protocol (HTTP). Status of this Memo This InternetDraft is submitted in full conformance with the provisions of BCP 78 and BCP 79. InternetDrafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as InternetDrafts. The list of current Internet Drafts is at http://datatracker.ietf.org/drafts/current/. InternetDrafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use InternetDrafts as reference material or to cite them other than as "work in progress." This InternetDraft will expire on May 18, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/licenseinfo) in effect on the date of publication of this document. Please review these documents Oiwa, et al. Expires May 18, 2017 [Page 1] InternetDraft HTTP Mutual Authentication: algorithms November 2016 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Cryptographic Overview (Nonnormative) . . . . . . . . . . . . 3 3. Authentication Algorithms . . . . . . . . . . . . . . . . . . 4 3.1. Support Functions and Notations . . . . . . . . . . . . . 5 3.2. Functions for Discrete Logarithm Settings . . . . . . . . 6 3.3. Functions for EllipticCurve Settings . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.1. General Implementation Considerations . . . . . . . . . . 9 5.2. Cryptographic Assumptions and Considerations . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. (Informative) Group Parameters for Discrete Logarithm Based Algorithms . . . . . . . . . . . . . 11 Appendix B. (Informative) Derived Numerical Values . . . . . . . 13 Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 14 C.1. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 14 C.2. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 14 C.3. Changes in Httpauth WG revision 04 . . . . . . . . . . . . 14 C.4. Changes in Httpauth WG revision 03 . . . . . . . . . . . . 14 C.5. Changes in Httpauth WG revision 02 . . . . . . . . . . . . 14 C.6. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 14 C.7. Changes in Httpauth WG revision 00 . . . . . . . . . . . . 14 C.8. Changes in HTTPAUTH revision 02 . . . . . . . . . . . . . 14 C.9. Changes in HTTPAUTH revision 01 . . . . . . . . . . . . . 15 C.10. Changes in revision 02 . . . . . . . . . . . . . . . . . . 15 C.11. Changes in revision 01 . . . . . . . . . . . . . . . . . . 15 C.12. Changes in revision 00 . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Oiwa, et al. Expires May 18, 2017 [Page 2] InternetDraft HTTP Mutual Authentication: algorithms November 2016 1. Introduction This document specifies algorithms for use with Mutual authentication protocol for HyperText Transport Protocol (HTTP) [ID.ietfhttpauthmutual] (referred as the "core specification" hereafter). The algorithms are based on "Augmented Passwordbased Authenticated Key Exchange" (Augmented PAKE) techniques. In particular, it uses one of three key exchange algorithms defined in ISO 117704: "Key management  Mechanisms based on weak secrets" [ISO.117704.2006] as its basis. In very brief summary, Mutual authentication protocol exchanges four values, K_c1, K_s1, VK_c and VK_s, to perform authenticated key exchanges, using the passwordderived secret pi and its "augmented version" J(pi). This document defines the set of functions K_c1, K_s1, and J for a specific algorithm family. Please note that from the view of cryptographic literature, the original functionality of Augmented PAKE is separated into the functions K_c1 and K_s1 as defined in this draft, and the functions VK_c and VK_s, which are defined in Section 11 of [ID.ietfhttpauthmutual] as "default functions". For the purpose of security analysis, please also refer to these functions. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The term "natural numbers" refers to the nonnegative integers (including zero) throughout this document. This document treats both the input (domain) and the output (codomain) of hash functions to be octet strings. When a natural number output of hash function H is required, it will be notated like INT(H(s)). 2. Cryptographic Overview (Nonnormative) The cryptographic primitive used in this algorithm specification is based on a variant of augmented PAKE proposed by T. Kwon, called APKASAMP, originally submitted to IEEE P1363.2. The general flow of the successful exchange is shown below, for informative purposes only. The multiplicative notations are used for group operators, and all modulus operations for finite groups (mod q and mod r) are Oiwa, et al. Expires May 18, 2017 [Page 3] InternetDraft HTTP Mutual Authentication: algorithms November 2016 omitted. C: S_c1 = random C: K_c1 = g^(S_c1)  ID, K_c1 > C: t_1 = H1(K_c1) S: t_1 = H1(K_c1) S: fetch J = g^pi by ID S: S_s1 = random S: K_s1 = (J * K_c1^(t_1))^(S_s1) < K_s1  C: t_2 = H2(K_c1, K_s1) S: t_2 = H2(K_c1, K_s1) C: z = K_s1^((S_c1 + t_2) / (S_c1 * t_1 + pi)) S: z' = (K_c1 * g^(t_2))^(S_s1) (assumption at this point: z = z' if authentication succeeded) C: VK_c = H4(K_c1, K_s1, z) S: VK_c' = H4(K_c1, K_s1, z')  VK_c > S: assert(VK_c = VK_c') C: VK_s' = H3(K_c1, K_s1, z) S: VK_s = H3(K_c1, K_s1, z') < VK_s  C: assert(VK_s = VK_s') Note that the concrete (binary) message formats (mapping to HTTP messages), as well as the formal definitions of equations for the latter two messages, are defined in core specification [ID.ietfhttpauthmutual]. The formal definitions for values corresponding to the first two messages are defined in the following sections. 3. Authentication Algorithms This document specifies one family of APKASAMP based algorithm. This family consists of four authentication algorithms, which differ only in their underlying mathematical groups and security parameters. These algorithms do not add any additional parameters. The tokens for these algorithms are o isokam3dl2048sha256: for the 2048bit discrete logarithm setting with the SHA256 hash function. o isokam3dl4096sha512: for the 4096bit discrete logarithm setting with the SHA512 hash function. o isokam3ecp256sha256: for the 256bit primefield elliptic curve setting with the SHA256 hash function. Oiwa, et al. Expires May 18, 2017 [Page 4] InternetDraft HTTP Mutual Authentication: algorithms November 2016 o isokam3ecp521sha512: for the 521bit primefield elliptic curve setting with the SHA512 hash function. For discrete logarithm settings, the underlying groups are the 2048 bit and 4096bit MODP groups defined in [RFC3526]. See Appendix A for the exact specifications of the groups and associated parameters. The hash functions H are SHA256 for the 2048bit group and SHA512 for the 4096bit group, respectively, defined in FIPS PUB 1802 [FIPS.1802.2002]. The hash iteration count nIterPi is 16384. The representation of the parameters kc1, ks1, vkc, and vks is base64 fixednumber. For the ellipticcurve settings, the underlying groups are the elliptic curves over the prime fields P256 and P521, respectively, specified in the appendix D.1.2 of the FIPS PUB 1864 [FIPS.1864.2013] specification. The hash functions H, which are referenced by the core document, are SHA256 for the P256 curve and SHA512 for the P521 curve, respectively. Cofactors of these curves are 1. The hash iteration count nIterPi is 16384. The representation of the parameters kc1, ks1, vkc, and vks is hexfixed number. Note: This algorithm is based on the Key Agreement Mechanism 3 (KAM3) defined in Section 6.3 of ISO/IEC 117704 [ISO.117704.2006] with a few modifications/improvements. However, implementers should use this document as the normative reference, because the algorithm has been changed in several minor details as well as with major improvements. 3.1. Support Functions and Notations The algorithm definitions use the support functions and notations defined below: The integers in the specification are in decimal by default, or in hexadecimal when prefixed with "0x". The functions named octet(), OCTETS(), and INT() are those defined in the core specification [ID.ietfhttpauthmutual]. Note: The definition of OCTETS() is different from the function GE2OS_x in the original ISO specification, which takes the shortest representation without preceding zeros. All of the algorithms defined in this specification use the default functions defined in the core specification (defined in Section 11 of [ID.ietfhttpauthmutual]) for computing the values pi, VK_c and VK_s. Oiwa, et al. Expires May 18, 2017 [Page 5] InternetDraft HTTP Mutual Authentication: algorithms November 2016 3.2. Functions for Discrete Logarithm Settings In this section, an equation (x / y mod z) denotes a natural number w less than z that satisfies (w * y) mod z = x mod z. For the discrete logarithm, we refer to some of the domain parameters by using the following symbols: o q: for "the prime" defining the MODP group. o g: for "the generator" associated with the group. o r: for the order of the subgroup generated by g. The function J is defined as J(pi) = g^(pi) mod q. The value of K_c1 is derived as K_c1 = g^(S_c1) mod q, where S_c1 is a random integer within range [1, r1] and r is the size of the subgroup generated by g. In addition, S_c1 MUST be larger than log(q)/log(g) (so that g^(S_c1) > q). The server MUST check the condition 1 < K_c1 < q1 upon reception. Let an intermediate value t_1 be t_1 = INT(H(octet(1)  OCTETS(K_c1))), the value of K_s1 is derived from J(pi) and K_c1 as: K_s1 = (J(pi) * K_c1^(t_1))^(S_s1) mod q where S_s1 is a random number within range [1, r1]. The value of K_s1 MUST satisfy 1 < K_s1 < q1. If this condition is not held, the server MUST reject the exchange. The client MUST check this condition upon reception. Let an intermediate value t_2 be t_2 = INT(H(octet(2)  OCTETS(K_c1)  OCTETS(K_s1))), the value z on the client side is derived by the following equation: z = K_s1^((S_c1 + t_2) / (S_c1 * t_1 + pi) mod r) mod q. Oiwa, et al. Expires May 18, 2017 [Page 6] InternetDraft HTTP Mutual Authentication: algorithms November 2016 The value z on the server side is derived by the following equation: z = (K_c1 * g^(t_2))^(S_s1) mod q. (Note: the original ISO specification contained a message pair containing verification of value z along with the "transcript" of the protocol exchange. This functionality is contained in the functions VK_c and VK_s.) 3.3. Functions for EllipticCurve Settings For the ellipticcurve setting, we refer to some of the domain parameters by the following symbols: o q: for the prime used to define the group. o G: for the point defined with the underlying group called "the generator". o h: for the cofactor of the group. o r: for the order of the subgroup generated by G. The function P(p) converts a curve point p into an integer representing point p, by computing x * 2 + (y mod 2), where (x, y) are the coordinates of point p. P'(z) is the inverse of function P, that is, it converts an integer z to a point p that satisfies P(p) = z. If such p exists, it is uniquely defined. Otherwise, z does not represent a valid curve point. The operator + indicates the ellipticcurve group operation, and the operation [x] * p denotes an integermultiplication of point p: it calculates p + p + ... (x times) ... + p. See the literature on ellipticcurve cryptography for the exact algorithms used for those functions (e.g. Section 3 of [RFC6090], which uses different notations, though). 0_E represents the infinity point. The equation (x / y mod z) denotes a natural number w less than z that satisfies (w * y) mod z = x mod z. The function J is defined as J(pi) = [pi] * G. The value of K_c1 is derived as K_c1 = P(K_c1'), where K_c1' = [S_c1] * G, where S_c1 is a random number within range [1, r1]. The server MUST Oiwa, et al. Expires May 18, 2017 [Page 7] InternetDraft HTTP Mutual Authentication: algorithms November 2016 check that the value of received K_c1 represents a valid curve point, and [h] * K_c1' is not equal to 0_E. Let an intermediate integer t_1 be t_1 = INT(H(octet(1)  OCTETS(K_c1))), the value of K_s1 is derived from J(pi) and K_c1' = P'(K_c1) as: K_s1 = P([S_s1] * (J(pi) + [t_1] * K_c1')), where S_s1 is a random number within range [1, r1]. The value of K_s1 MUST represent a valid curve point and satisfy [h] * P'(K_s1) <> 0_E. If this condition is not satisfied, the server MUST reject the exchange. The client MUST check this condition upon reception. Let an intermediate integer t_2 be t_2 = INT(H(octet(2)  OCTETS(K_c1)  OCTETS(K_s1))), the value z on the client side is derived by the following equation: z = P([(S_c1 + t_2) / (S_c1 * t_1 + pi) mod r] * P'(K_s1)). The value z on the server side is derived by the following equation: z = P([S_s1] * (P'(K_c1) + [t_2] * G)). 4. IANA Considerations This document defines four new tokens to be added to the "HTTP Mutual authentication algorithms" registry; isokam3dl2048sha256, isokam3dl4096sha512, isokam3ecp256sha256 and isokam3ecp521sha512, as follows: ++++  Token  Description  Specification  ++++  isokam3dl2048sha256  ISO117704 KAM3,  This document    2048bit DL    isokam3dl4096sha512  ISO117704 KAM3,  This document    4096bit DL    isokam3ecp256sha256  ISO117704 KAM3,  This document    256bit EC    isokam3ecp521sha512  ISO117704 KAM3,  This document    521bit EC   ++++ Oiwa, et al. Expires May 18, 2017 [Page 8] InternetDraft HTTP Mutual Authentication: algorithms November 2016 5. Security Considerations Please refer to the corresponding section of the core specification [ID.ietfhttpauthmutual] for algorithmindependent considerations. 5.1. General Implementation Considerations o During the exchange, the value VK_s, defined in [ID.ietfhttpauthmutual], MUST only be sent when the server has received a correct (expected) value of VK_c. This is a cryptographic requirement, stated in [ISO.117704.2006]. o All random numbers used in these algorithms MUST be at least cryptographically computationally secure against forward and backward guessing attacks. o Computation times of all numerical operations on discrete logarithm group elements and ellipticcurve points MUST be normalized and made independent of the exact values, to prevent timingbased sidechannel attacks. 5.2. Cryptographic Assumptions and Considerations The notices in this subsection are for those who analyze the security of this algorithm, and those who might want to make a derived work from this algorithm specification. o handling of an invalid K_s1 value in the exchange has been changed from the original ISO specification. The original specifies that the sender should retry with another random S_s1 value, while we specify that the exchange must be rejected. This is due to an observation that this condition is less likely to result from the random error caused by an unlucky choice of S_s1, but more likely the result of a systematic failure from an invalid J(pi) value (even implying possible denialofservice attacks). o The usual construction of authenticated key exchange algorithms consists of a key exchange phase and a key verification phase. The latter usually involves some kinds of exchange transaction to be verified, to avoid security risks or vulnerabilities caused by mixing values from from two or more key exchanges. In the design of the algorithms in this document, such a functionality is defined in a generalized manner in the core specification [ID.ietfhttpauthmutual] (see definitions of VK_c and VK_s). If the algorithm defined above is used in other protocols, this aspect MUST be given careful consideration. Oiwa, et al. Expires May 18, 2017 [Page 9] InternetDraft HTTP Mutual Authentication: algorithms November 2016 o The domain parameters chosen and specified in this draft are based on a few assumptions. In the discretelogarithm setting, q has to be a safe prime ([(q  1) / 2] must also be prime), and r should be the largest possible value [(q  1) / 2]. In the elliptic curve setting, r has to be prime. Defining a variation of this algorithm using a different domain parameter SHOULD be attentive to these conditions. 6. References 6.1. Normative References [FIPS.1802.2002] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 1802, August 2002, <http:// csrc.nist.gov/publications/fips/fips1802/fips1802.pdf>. [FIPS.1864.2013] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 1864, July 2013, <htt p://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.1864.pdf>. [ID.ietfhttpauthmutual] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, T., and Y. Ioku, "Mutual Authentication Protocol for HTTP", draftietfhttpauthmutual11 (work in progress), November 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, <http://www.rfceditor.org/info/rfc2119>. [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) DiffieHellman groups for Internet Key Exchange (IKE)", RFC 3526, DOI 10.17487/RFC3526, May 2003, <http://www.rfceditor.org/info/rfc3526>. 6.2. Informative References [ISO.117704.2006] International Organization for Standardization, "Information technology  Security techniques  Key management  Part 4: Mechanisms based on weak secrets", ISO Standard 117704, May 2006. [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Oiwa, et al. Expires May 18, 2017 [Page 10] InternetDraft HTTP Mutual Authentication: algorithms November 2016 Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/ RFC6090, February 2011, <http://www.rfceditor.org/info/rfc6090>. Appendix A. (Informative) Group Parameters for Discrete Logarithm Based Algorithms The MODP group used for the isokam3dl2048sha256 algorithm is defined by the following parameters. The prime is: q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF. The generator is: g = 2. The size of the subgroup generated by g is: r = (q  1) / 2 = 0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964 EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288 0AB9472D 45565534 7FFFFFFF FFFFFFFF. The MODP group used for the isokam3dl4096sha512 algorithm is defined by the following parameters. The prime is: Oiwa, et al. Expires May 18, 2017 [Page 11] InternetDraft HTTP Mutual Authentication: algorithms November 2016 q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199 FFFFFFFF FFFFFFFF. The generator is: g = 2. The size of the subgroup generated by g is: Oiwa, et al. Expires May 18, 2017 [Page 12] InternetDraft HTTP Mutual Authentication: algorithms November 2016 r = (q  1) / 2 = 0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964 EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288 0AB9472D 45556216 D6998B86 82283D19 D42A90D5 EF8E5D32 767DC282 2C6DF785 457538AB AE83063E D9CB87C2 D370F263 D5FAD746 6D8499EB 8F464A70 2512B0CE E771E913 0D697735 F897FD03 6CC50432 6C3B0139 9F643532 290F958C 0BBD9006 5DF08BAB BD30AEB6 3B84C460 5D6CA371 047127D0 3A72D598 A1EDADFE 707E8847 25C16890 54908400 8D391E09 53C3F36B C438CD08 5EDD2D93 4CE1938C 357A711E 0D4A341A 5B0A85ED 12C1F4E5 156A2674 6DDDE16D 826F477C 97477E0A 0FDF6553 143E2CA3 A735E02E CCD94B27 D04861D1 119DD0C3 28ADF3F6 8FB094B8 67716BD7 DC0DEEBB 10B8240E 68034893 EAD82D54 C9DA754C 46C7EEE0 C37FDBEE 48536047 A6FA1AE4 9A0318CC FFFFFFFF FFFFFFFF. Appendix B. (Informative) Derived Numerical Values This section provides several numerical values for implementing this protocol, derived from the above specifications. The values shown in this section are for informative purposes only. +++++++   dl2048  dl4096  ecp256  ecp521   +++++++  Size of K_c1  2048  4096  257  522  (bits)   etc.        hSize, Size of  256  512  256  512  (bits)   H(...)        length of  256  512  33  66  (octets)   OCTETS(K_c1)        etc.        length of kc1,  344 *  684 *  66  132  (octets)   ks1 param.        values.        length of vkc,  44 *  88 *  64  128  (octets)   vks param.        values.       Oiwa, et al. Expires May 18, 2017 [Page 13] InternetDraft HTTP Mutual Authentication: algorithms November 2016  minimum  2048  4096  1  1    allowed S_c1       +++++++ (The numbers marked with an * do not include any enclosing quotation marks.) Appendix C. (Informative) Draft Change Log C.1. Changes in Httpauth WG Revision 06 o Authors' addresses updated. C.2. Changes in Httpauth WG Revision 05 o Several comments from reviewers are reflected to the text. C.3. Changes in Httpauth WG revision 04 o Authors address updated. C.4. Changes in Httpauth WG revision 03 o IANA registration information added. C.5. Changes in Httpauth WG revision 02 o No technical changes: references updated. C.6. Changes in Httpauth WG revision 01 o Changed behavior on failed generation of K_s1. o Security considerations updated. C.7. Changes in Httpauth WG revision 00 o Added a note on the choice of elliptic curves. C.8. Changes in HTTPAUTH revision 02 o Added nIterPi parameter to adjust to the changes to the core draft. o Added a note on the verification of exchange transaction. Oiwa, et al. Expires May 18, 2017 [Page 14] InternetDraft HTTP Mutual Authentication: algorithms November 2016 C.9. Changes in HTTPAUTH revision 01 o Notation change: integer output of hash function will be notated as INT(H(*)), changed from H(*). C.10. Changes in revision 02 o Implementation hints in appendix changed (number of characters for base64fixednumber does not contain doublequotes). C.11. Changes in revision 01 o Parameter names renamed. o Some expressions clarified without changing the value. C.12. Changes in revision 00 The document is separated from the revision 08 of the core documentation. Authors' Addresses Yutaka Oiwa National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 111 Umezono Tsukubashi, Ibaraki JP Email: y.oiwa@aist.go.jp Hajime Watanabe National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 111 Umezono Tsukubashi, Ibaraki JP Email: hwatanabe@aist.go.jp Oiwa, et al. Expires May 18, 2017 [Page 15] InternetDraft HTTP Mutual Authentication: algorithms November 2016 Hiromitsu Takagi National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 111 Umezono Tsukubashi, Ibaraki JP Email: takagi.hiromitsu@aist.go.jp Kaoru Maeda Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1303 Sasazuka Shibuyaku, Tokyo JP Email: maeda@lepidum.co.jp Tatsuya Hayashi Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1303 Sasazuka Shibuyaku, Tokyo JP Email: hayashi@lepidum.co.jp Yuichi Ioku Individual Email: mutualwork@ioku.org Oiwa, et al. Expires May 18, 2017 [Page 16]