Internet Engineering Task Force (IETF) Y. Oiwa Request for Comments: 8121 H. Watanabe Category: Experimental H. Takagi ISSN: 2070-1721 ITRI, AIST K. Maeda Individual Contributor T. Hayashi Lepidum Y. Ioku Individual Contributor April 2017
Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3)
Abstract
This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hypertext Transfer Protocol (HTTP).
Status of This Memo
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8121.
Oiwa, et al. Experimental [Page 1]
RFC 8121 HTTP Mutual Authentication: Algorithms April 2017
Copyright Notice
Copyright (c) 2017 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/license-info) in effect on the date of publication of this document. Please review these documents 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 ....................................................2 1.1. Terminology ................................................3 2. Cryptographic Overview (Non-normative) ..........................3 3. Authentication Algorithms .......................................4 3.1. Support Functions and Notations ............................5 3.2. Functions for Discrete-Logarithm Settings ..................6 3.3. Functions for Elliptic-Curve Settings ......................7 4. IANA Considerations .............................................9 5. Security Considerations .........................................9 5.1. General Implementation Considerations ......................9 5.2. Cryptographic Assumptions and Considerations ..............10 6. References .....................................................11 6.1. Normative References ......................................11 6.2. Informative References ....................................12 Appendix A. (Informative) Group Parameters for Algorithms Based on the Discrete Logarithm .............................13 Appendix B. (Informative) Derived Numerical Values ................16 Authors' Addresses ................................................17
This document specifies algorithms for use with the Mutual authentication protocol for the Hypertext Transfer Protocol (HTTP) [RFC8120] (hereafter referred to as the "core specification"). The algorithms are based on augmented password-based authenticated key exchange (augmented PAKE) techniques. In particular, it uses one of three key exchange algorithms defined in ISO 11770-4 ("Information technology - Security techniques - Key management - Part 4: Mechanisms based on weak secrets") [ISO.11770-4.2006] as its basis.
Oiwa, et al. Experimental [Page 2]
RFC 8121 HTTP Mutual Authentication: Algorithms April 2017
To briefly summarize, the Mutual authentication protocol exchanges four values -- K_c1, K_s1, VK_c, and VK_s -- to perform authenticated key exchanges, using the password-derived 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 point of view of literature related to cryptography, the original functionality of augmented PAKE is separated into the functions K_c1 and K_s1 as defined in this document, and the functions VK_c and VK_s, which are defined in Section 12.2 of [RFC8120] as "default functions". For the purpose of security analysis, please also refer to these functions.
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 non-negative integers (including zero) throughout this document.
This document treats both the input (domain) and the output (codomain) of hash functions as octet strings. When a natural-number output of hash function H is required, it will be notated, for example, as INT(H(s)).
The cryptographic primitive used in this algorithm specification is based on a variant of augmented PAKE called "APKAS-AMP" (augmented password-authenticated key agreement scheme, version AMP), proposed by T. Kwon and originally submitted to [IEEE-1363.2_2008]. 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 omitted.
Oiwa, et al. Experimental [Page 3]
RFC 8121 HTTP Mutual Authentication: Algorithms April 2017
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)
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 the core specification [RFC8120]. The formal definitions for values corresponding to the first two messages are defined in the following sections.
This document specifies one family of algorithms based on APKAS-AMP, to be used with [RFC8120]. 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 as follows:
o iso-kam3-dl-2048-sha256: for the 2048-bit discrete-logarithm setting with the SHA-256 hash function.
o iso-kam3-dl-4096-sha512: for the 4096-bit discrete-logarithm setting with the SHA-512 hash function.
o iso-kam3-ec-p256-sha256: for the 256-bit prime-field elliptic-curve setting with the SHA-256 hash function.
o iso-kam3-ec-p521-sha512: for the 521-bit prime-field elliptic-curve setting with the SHA-512 hash function.
Oiwa, et al. Experimental [Page 4]
RFC 8121 HTTP Mutual Authentication: Algorithms April 2017
For discrete-logarithm settings, the underlying groups are the 2048-bit and 4096-bit Modular Exponential (MODP) groups defined in [RFC3526]. See Appendix A for the exact specifications for the groups and associated parameters. Hash function H is SHA-256 for the 2048-bit group and SHA-512 for the 4096-bit group, respectively, as defined in FIPS PUB 180-4 [FIPS.180-4.2015]. The hash iteration count nIterPi is 16384. The representation of the parameters "kc1", "ks1", "vkc", and "vks" is base64-fixed-number.
For the elliptic-curve settings, the underlying groups are the elliptic curves over the prime fields P-256 and P-521, respectively, as specified in Appendix D.1.2 of the FIPS PUB 186-4 [FIPS.186-4.2013] specification. Hash function H is SHA-256 for the P-256 curve and SHA-512 for the P-521 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 hex-fixed-number.
Note: This algorithm is based on the Key Agreement Mechanism 3 (KAM3) as defined in Section 6.3 of ISO/IEC 11770-4 [ISO.11770-4.2006], with a few modifications/improvements. However, implementers should consider this document as normative, because several minor details of the algorithm have changed and major improvements have been made.
The algorithm definitions use the support functions and notations defined below.
Decimal notations are used for integers in this specification by default. Integers in hexadecimal notations are prefixed with "0x".
In this document, the octet(), OCTETS(), and INT() functions are used as defined in the core specification [RFC8120].
Note: The definition of OCTETS() is different from the function GE2OS_x in the original ISO specification; GE2OS_x takes the shortest representation without preceding zeros.
All of the algorithms defined in this specification use the default functions defined in Section 12.2 of [RFC8120] for computing the values pi, VK_c, and VK_s.
Oiwa, et al. Experimental [Page 5]
RFC 8121 HTTP Mutual Authentication: Algorithms April 2017
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 the range [1, r-1] 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 < q-1 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 the range [1, r-1]. The value of K_s1 MUST satisfy 1 < K_s1 < q-1. If this condition is not held, the server MUST reject the exchange. The client MUST check this condition upon reception.
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. Experimental [Page 6]
RFC 8121 HTTP Mutual Authentication: Algorithms April 2017
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.)
For the elliptic-curve settings, 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 elliptic-curve group operation, and the operation [x] * p denotes an integer-multiplication of point p: it calculates p + p + ... (x times) ... + p. See the literature on elliptic-curve cryptography for the exact algorithms used for those functions (e.g., Section 3 of [RFC6090]; however, note that [RFC6090] uses different notations). 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
Oiwa, et al. Experimental [Page 7]
RFC 8121 HTTP Mutual Authentication: Algorithms April 2017
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 the range [1, r-1]. The server MUST check that (1) the value of received K_c1 represents a valid curve point and (2) [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 the range [1, r-1]. 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.
o During the exchange, the value VK_s, defined in [RFC8120], MUST only be sent when the server has received a correct (expected) value of VK_c. This is a cryptographic requirement, as stated in [ISO.11770-4.2006].
o All random numbers used in these algorithms MUST be cryptographically secure against forward and backward guessing attacks.
o To prevent timing-based side-channel attacks, computation times of all numerical operations on discrete-logarithm group elements and elliptic-curve points MUST be normalized and made independent of the exact values.
Oiwa, et al. Experimental [Page 9]
RFC 8121 HTTP Mutual Authentication: Algorithms April 2017
The notes 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 The treatment of an invalid K_s1 value in the exchange has been changed from the method defined in the original ISO specification, which specifies that the sender should retry with another random S_s1 value. We specify that the exchange must be rejected. This is due to an observation that this condition is less likely to result from a random error caused by an unlucky choice of S_s1 but is more likely the result of a systematic failure caused by an invalid J(pi) value (even implying possible denial-of-service attacks).
o The usual construction of authenticated key exchange algorithms consists of a key exchange phase and a key verification phase. To avoid security risks or vulnerabilities caused by mixing values from two or more key exchanges, the latter usually involves some kinds of exchange transactions to be verified. In the algorithms defined in this document, such verification steps are provided in the generalized definitions of VK_c and VK_s in [RFC8120]. If the algorithm defined above is used in other protocols, this aspect MUST be given careful consideration.
o The domain parameters chosen and specified in this document are based on a few assumptions. In the discrete-logarithm 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. Implementers defining a variation of this algorithm using a different domain parameter SHOULD be attentive to these conditions.
Oiwa, et al. Experimental [Page 10]
RFC 8121 HTTP Mutual Authentication: Algorithms April 2017
[FIPS.180-4.2015] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.
[FIPS.186-4.2013] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.
[IEEE-1363.2_2008] IEEE, "IEEE Standard Specifications for Password-Based Public-Key Cryptographic Techniques", IEEE 1363.2-2008, DOI 10.1109/ieeestd.2009.4773330, <http://ieeexplore.ieee.org/servlet/ opac?punumber=4773328>.
[ISO.11770-4.2006] International Organization for Standardization, "Information technology -- Security techniques -- Key management -- Part 4: Mechanisms based on weak secrets", ISO Standard 11770-4, May 2006, <http://www.iso.org/iso/iso_catalogue/catalogue_tc/ catalogue_detail.htm?csnumber=39723>.
RFC 8121 HTTP Mutual Authentication: Algorithms April 2017
Appendix B. (Informative) Derived Numerical Values
This section provides several numerical values for implementing this protocol. These values are derived from the specifications provided in Section 3. The values shown in this section are for informative purposes only.
(The numbers marked with an "*" do not include any enclosing quotation marks.)
Oiwa, et al. Experimental [Page 16]
RFC 8121 HTTP Mutual Authentication: Algorithms April 2017
Authors' Addresses
Yutaka Oiwa National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan Email: y.oiwa@aist.go.jp
Hajime Watanabe National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan Email: h-watanabe@aist.go.jp
Hiromitsu Takagi National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan Email: takagi.hiromitsu@aist.go.jp