--- 1/draft-ietf-httpauth-mutual-algo-00.txt 2014-08-18 20:14:36.122067950 -0700
+++ 2/draft-ietf-httpauth-mutual-algo-01.txt 2014-08-18 20:14:36.154068729 -0700
@@ -1,25 +1,25 @@
HTTPAUTH Working Group Y. Oiwa
Internet-Draft H. Watanabe
Intended status: Experimental H. Takagi
-Expires: January 5, 2015 RISEC, AIST
+Expires: February 20, 2015 RISEC, AIST
K. Maeda
T. Hayashi
Lepidum
Y. Ioku
Individual
- July 4, 2014
+ August 19, 2014
Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic
Algorithms
- draft-ietf-httpauth-mutual-algo-00
+ draft-ietf-httpauth-mutual-algo-01
Abstract
This document specifies some cryptographic algorithms which will be
used for the Mutual user authentication method for the Hyper-text
Transport Protocol (HTTP).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
@@ -28,101 +28,140 @@
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts 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 Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on January 5, 2015.
+ This Internet-Draft will expire on February 20, 2015.
Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Authentication Algorithms . . . . . . . . . . . . . . . . . . 3
- 2.1. Support Functions and Notations . . . . . . . . . . . . . 4
- 2.2. Functions for Discrete-Logarithm Settings . . . . . . . . 5
- 2.3. Functions for Elliptic-Curve Settings . . . . . . . . . . 6
- 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
- 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
- 5. Notice on intellectual properties . . . . . . . . . . . . . . 8
- 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
- 6.2. Informative References . . . . . . . . . . . . . . . . . . 9
+ 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 . . . . . . . . . . . . . . . . . . . . . 8
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 5.1. General Implementation Considerations . . . . . . . . . . 8
+ 5.2. Cryptographic Assumptions and Considerations . . . . . . . 9
+ 6. Notice on intellectual properties . . . . . . . . . . . . . . 10
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. (Informative) Group Parameters for
- Discrete-Logarithm Based Algorithms . . . . . . . . . 9
- Appendix B. (Informative) Derived Numerical Values . . . . . . . 12
- Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 13
- C.1. Changes in HTTPAUTH-WG revision 00 . . . . . . . . . . . . 13
- C.2. Changes in HTTPAUTH revision 02 . . . . . . . . . . . . . 13
- C.3. Changes in HTTPAUTH revision 01 . . . . . . . . . . . . . 13
- C.4. Changes in revision 02 . . . . . . . . . . . . . . . . . . 13
- C.5. Changes in revision 01 . . . . . . . . . . . . . . . . . . 13
- C.6. Changes in revision 00 . . . . . . . . . . . . . . . . . . 13
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 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 01 . . . . . . . . . . . . 14
+ C.2. Changes in HTTPAUTH-WG revision 00 . . . . . . . . . . . . 14
+ C.3. Changes in HTTPAUTH revision 02 . . . . . . . . . . . . . 14
+ C.4. Changes in HTTPAUTH revision 01 . . . . . . . . . . . . . 14
+ C.5. Changes in revision 02 . . . . . . . . . . . . . . . . . . 14
+ C.6. Changes in revision 01 . . . . . . . . . . . . . . . . . . 14
+ C.7. Changes in revision 00 . . . . . . . . . . . . . . . . . . 14
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
This document specifies some algorithms for Mutual authentication
protocol for Hyper-Text Transport Protocol (HTTP)
[I-D.ietf-httpauth-mutual]. The algorithms are based on so-called
- "Augumented Password-based Authenticated Key Exchange" (Augumented
+ "Augmented Password-based Authenticated Key Exchange" (Augmented
PAKE) techniques. In particular, it uses one of three key exchange
algorithm defined in the ISO 11770-4: "Key management - Mechanisms
based on weak secrets" [ISO.11770-4.2006] as a basis.
In very brief summary, 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 "augumented
+ 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 view of cryptographic literatures, the
- original functionality of Augumented PAKE is separated into the
+ 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 defined in this draft, and the functions VK_c
and VK_s defined in Section 11 of [I-D.ietf-httpauth-mutual] 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 non-negative integers
(including zero) throughout this document.
This document treats target (codomain) of hash functions to be octet
strings. The notation INT(H(s)) gives a natural-number output of
hash function H applied to string s.
-2. Authentication Algorithms
+2. Cryptographic Overview (Non-normative)
+
+ The cryptographic primitive used in this algorithm specification is
+ based on a variant of augmented PAKE proposed by T. Kwon, called
+ APKAS-AMP, originally submitted to IEEE P1363.2. The general flow of
+ the successful exchange is shown below, for informative purposes
+ only. The DL-based notations are used, and all group operations (mod
+ q and mod r) are omitted.
+
+ Note that the only messages corresponding to the earlier two
+ exchanges are defined in this specification. Those for latter two
+ exchanges are defined in the main specification
+ [I-D.ietf-httpauth-mutual].
+
+ 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')
+
+3. Authentication Algorithms
This document specifies only one family of the authentication
algorithm. The family consists of four authentication algorithms,
which only differ in their underlying mathematical groups and
security parameters. The algorithms do not add any additional
parameters. The tokens for these algorithms are
o iso-kam3-dl-2048-sha256: for the 2048-bit discrete-logarithm
setting with the SHA-256 hash function.
@@ -139,63 +178,58 @@
bit and 4096-bit MODP groups defined in [RFC3526], respectively. See
Appendix A for the exact specifications of the groups and associated
parameters. The hash functions H are SHA-256 for the 2048-bit group
and SHA-512 for the 4096-bit group, respectively, defined in FIPS PUB
180-2 [FIPS.180-2.2002]. 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,
- specified in the appendix D.1.2 of FIPS PUB 186-3 [FIPS.186-3.2009]
+ specified in the appendix D.1.2 of FIPS PUB 186-4 [FIPS.186-4.2013]
specification. The hash functions H, which are referenced by the
core document, are SHA-256 for the P-256 curve and SHA-512 for the
- P-521 curve, respectively. The hash iteration count nIterPi is
- 16384. The representation of the parameters kc1, ks1, vkc, and vks
- is hex-fixed-number.
+ 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.
[[Editorial Note: remove before submission] We should take a care on
recent hot discussion topic on the choice of elliptic curves for
- cryptography. If the discussion leads to some recommendation on
- "default choice of curves" before publishing this document as an RFC,
- the authors will reflect that change to the paragraph above
- (reference to FIPS 186-3). If not, we may need to update this
- document with specifying a new set of algorithm identifier tokens for
- use of new curves.]
+ cryptography.]]
Note: This algorithm is based on the Key Agreement Mechanism 3 (KAM3)
defined in Section 6.3 of ISO/IEC 11770-4 [ISO.11770-4.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 major improvements.
-2.1. Support Functions and Notations
+3.1. Support Functions and Notations
The algorithm definitions use several support functions and notations
defined below:
The integers in the specification are in decimal, or in hexadecimal
when prefixed with "0x".
The functions named octet(), OCTETS(), and INT() are those defined in
the core specification [I-D.ietf-httpauth-mutual].
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
[I-D.ietf-httpauth-mutual]) for computing the values pi, VK_c and
VK_s.
-2.2. Functions for Discrete-Logarithm Settings
+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.
@@ -220,49 +254,51 @@
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, r-1]. The value of
K_s1 MUST satisfy 1 < K_s1 < q-1. If this condition is not held, the
- server MUST retry using another value for S_s1. The client MUST
- check this condition upon reception.
+ 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.
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. The functionality of this kind is contained in
the functions VK_c and VK_s.)
-2.3. Functions for Elliptic-Curve Settings
+3.3. Functions for Elliptic-Curve Settings
For the elliptic-curve 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 defined point 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
@@ -274,128 +310,154 @@
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, r-1]. The value of
- K_c1 MUST represent a valid curve point, and K_c1' SHALL NOT be 0_E.
- The server MUST check this condition upon reception.
+ K_c1 MUST represent a valid curve point, and [h] * K_c1' SHALL NOT be
+ 0_E. The server MUST check this condition upon reception.
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, r-1]. The value of
- K_s1 MUST represent a valid curve point and satisfy [4] * P'(K_s1) <>
- 0_E. If this condition is not satisfied, the server MUST retry using
- another value for S_s1. The client MUST check this condition upon
- reception.
+ 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)).
-3. IANA Considerations
+4. IANA Considerations
Four tokens iso-kam3-dl-2048-sha256, iso-kam3-dl-4096-sha512,
iso-kam3-ec-p256-sha256 and iso-kam3-ec-p521-sha512 shall be
allocated and registered according to the provision of the core
documentation when this document is promoted to an RFC.
Note: More formal declarations will be added in the future drafts to
meet the RFC 5226 requirements.
-4. Security Considerations
+5. Security Considerations
Refer the corresponding section of the core specification for
- algorithm-independent, generic considerations.
+ algorithm-independent, generic considerations, too.
+
+5.1. General Implementation Considerations
+ o During the exchange, the value VK_s, defined in
+ [I-D.ietf-httpauth-mutual], MUST only be sent when the server has
+ received a correct (expected) value of VK_c. This is a
+ requirement from underlying cryptography stated in
+ [ISO.11770-4.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 elliptic-curve points MUST be
normalized and made independent of the exact values, to prevent
timing-based side-channel attacks.
- The usual construction of authenticated key exchange algorithms are
- build from a key-exchange period and a key verification period, and
- the latter usually involving some kind of exchange transaction to be
- verified, to avoid security risks or vulnerabilities caused from
- mixing of values from two or more key exchanges. In the design of
- the algorithms in this document, such a functionality is defined in
- generalized manner in the core specification
- [I-D.ietf-httpauth-mutual] (see definitions of VK_c and VK_s). If
- any attempts to reuse the algorithm defined above with any other
- protocols exist, care MUST be taken on that aspect.
+5.2. Cryptographic Assumptions and Considerations
-5. Notice on intellectual properties
+ The notices on this subsection is mostly for those who analyze the
+ security of this algorithm, and those who might want to make a
+ derived work of this algorithm specification.
+
+ o Handling of invalid K_s1 value in the exchange (now: to reject the
+ exchange) has been changed from original ISO specification
+ (original: to retry with another random S_s1 value). This is due
+ to an observation that this condition is less likely from the
+ random error caused by unlucky choice of S_s1, but more likely
+ from the systematic failure from invalid J(pi) value, even
+ implying possible denial-of-service attacks.
+
+ o The usual construction of authenticated key exchange algorithms
+ are build from a key-exchange period and a key verification
+ period, and the latter usually involving some kind of exchange
+ transaction to be verified, to avoid security risks or
+ vulnerabilities caused from mixing of values from two or more key
+ exchanges. In the design of the algorithms in this document, such
+ a functionality is defined in generalized manner in the core
+ specification [I-D.ietf-httpauth-mutual] (see definitions of VK_c
+ and VK_s). If any attempts to reuse the algorithm defined above
+ with any other protocols exist, care MUST be taken on that aspect.
+
+ o The domain parameters chosen and specified in this draft has a few
+ assumptions. In the DL setting, q has to be safe prime ([(q - 1)
+ / 2] must also be prime), and r should be the largest possible
+ value [(q - 1) / 2]. In the EC setting, r has to be prime.
+ Defining a variation of this algorithm using a different domain
+ parameter SHOULD care about these conditions.
+
+6. Notice on intellectual properties
The National Institute of Advanced Industrial Science and Technology
(AIST) and Yahoo! Japan, Inc. has jointly submitted a patent
application on the protocol proposed in this documentation to the
Patent Office of Japan. The patent is intended to be open to any
- implementors of this protocol and its variants under non-exclusive
+ implementers of this protocol and its variants under non-exclusive
royalty-free manner. For the details of the patent application and
its status, please contact the author of this document.
The elliptic-curve based authentication algorithms might involve
several existing third-party patents. The authors of the document
take no position regarding the validity or scope of such patents, and
other patents as well.
-6. References
+7. References
-6.1. Normative References
+7.1. Normative References
[FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, .
- [FIPS.186-3.2009]
+ [FIPS.186-4.2013]
National Institute of Standards and Technology, "Digital
- Signature Standard (DSS)", FIPS PUB 186-3, June 2009, .
+ Signature Standard (DSS)", FIPS PUB 186-4, July 2013, .
[I-D.ietf-httpauth-mutual]
Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
T., and Y. Ioku, "Mutual Authentication Protocol for
- HTTP", draft-ietf-httpauth-mutual-02 (work in progress),
- April 2014.
+ HTTP", draft-ietf-httpauth-mutual-03 (work in progress),
+ August 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
-6.2. Informative References
+7.2. Informative References
[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.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011.
@@ -520,48 +582,54 @@
| values. | | | | | |
| 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 00
+C.1. Changes in HTTPAUTH-WG revision 01
+
+ o Changed behavior on failed generation of K_s1.
+
+ o Security considerations updated.
+
+C.2. Changes in HTTPAUTH-WG revision 00
o Added a note on the choice of elliptic curves.
-C.2. Changes in HTTPAUTH revision 02
+C.3. 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.
-C.3. Changes in HTTPAUTH revision 01
+C.4. Changes in HTTPAUTH revision 01
o Notation change: integer output of hash function will be notated
as INT(H(*)), changed from H(*).
-C.4. Changes in revision 02
+C.5. Changes in revision 02
o Implementation hints in appendix changed (number of characters for
base64-fixed-number does not contain double-quotes).
-C.5. Changes in revision 01
+C.6. Changes in revision 01
o Parameter names renamed.
o Some expressions clarified without changing the value.
-C.6. Changes in revision 00
+C.7. 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
Research Institute for Secure Systems
3-11-46 Nakouji