draft-ietf-httpauth-mutual-algo-04.txt   draft-ietf-httpauth-mutual-algo-05.txt 
HTTPAUTH Working Group Y. Oiwa HTTPAUTH Working Group Y. Oiwa
Internet-Draft H. Watanabe Internet-Draft H. Watanabe
Intended status: Experimental H. Takagi Intended status: Experimental H. Takagi
Expires: July 10, 2016 ITRI, AIST Expires: November 23, 2016 ITRI, AIST
K. Maeda K. Maeda
T. Hayashi T. Hayashi
Lepidum Lepidum
Y. Ioku Y. Ioku
Individual Individual
January 7, 2016 May 22, 2016
Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic
Algorithms Algorithms
draft-ietf-httpauth-mutual-algo-04 draft-ietf-httpauth-mutual-algo-05
Abstract Abstract
This document specifies some cryptographic algorithms which will be This document specifies cryptographic algorithms for use with the
used for the Mutual user authentication method for the Hyper-text Mutual user authentication method for the Hyper-text Transport
Transport Protocol (HTTP). Protocol (HTTP).
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 10, 2016. This Internet-Draft will expire on November 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Cryptographic Overview (Non-normative) . . . . . . . . . . . . 3 2. Cryptographic Overview (Non-normative) . . . . . . . . . . . . 3
3. Authentication Algorithms . . . . . . . . . . . . . . . . . . 4 3. Authentication Algorithms . . . . . . . . . . . . . . . . . . 4
3.1. Support Functions and Notations . . . . . . . . . . . . . 5 3.1. Support Functions and Notations . . . . . . . . . . . . . 5
3.2. Functions for Discrete-Logarithm Settings . . . . . . . . 5 3.2. Functions for Discrete Logarithm Settings . . . . . . . . 5
3.3. Functions for Elliptic-Curve Settings . . . . . . . . . . 7 3.3. Functions for Elliptic-Curve Settings . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. General Implementation Considerations . . . . . . . . . . 9 5.1. General Implementation Considerations . . . . . . . . . . 9
5.2. Cryptographic Assumptions and Considerations . . . . . . . 9 5.2. Cryptographic Assumptions and Considerations . . . . . . . 9
6. Notice on intellectual properties . . . . . . . . . . . . . . 10 6. Intellectual Properties Notice . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. (Informative) Group Parameters for Appendix A. (Informative) Group Parameters for Discrete
Discrete-Logarithm Based Algorithms . . . . . . . . . 11 Logarithm Based Algorithms . . . . . . . . . . . . . 11
Appendix B. (Informative) Derived Numerical Values . . . . . . . 13 Appendix B. (Informative) Derived Numerical Values . . . . . . . 13
Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 14 Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 14
C.1. Changes in HTTPAUTH-WG revision 04 . . . . . . . . . . . . 14 C.1. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 14
C.2. Changes in HTTPAUTH-WG revision 03 . . . . . . . . . . . . 14 C.2. Changes in Httpauth WG revision 04 . . . . . . . . . . . . 14
C.3. Changes in HTTPAUTH-WG revision 02 . . . . . . . . . . . . 14 C.3. Changes in Httpauth WG revision 03 . . . . . . . . . . . . 14
C.4. Changes in HTTPAUTH-WG revision 01 . . . . . . . . . . . . 14 C.4. Changes in Httpauth WG revision 02 . . . . . . . . . . . . 14
C.5. Changes in HTTPAUTH-WG revision 00 . . . . . . . . . . . . 14 C.5. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 14
C.6. Changes in HTTPAUTH revision 02 . . . . . . . . . . . . . 14 C.6. Changes in Httpauth WG revision 00 . . . . . . . . . . . . 14
C.7. Changes in HTTPAUTH revision 01 . . . . . . . . . . . . . 14 C.7. Changes in HTTPAUTH revision 02 . . . . . . . . . . . . . 14
C.8. Changes in revision 02 . . . . . . . . . . . . . . . . . . 15 C.8. Changes in HTTPAUTH revision 01 . . . . . . . . . . . . . 14
C.9. Changes in revision 01 . . . . . . . . . . . . . . . . . . 15 C.9. Changes in revision 02 . . . . . . . . . . . . . . . . . . 15
C.10. Changes in revision 00 . . . . . . . . . . . . . . . . . . 15 C.10. Changes in revision 01 . . . . . . . . . . . . . . . . . . 15
C.11. Changes in revision 00 . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document specifies some algorithms for Mutual authentication This document specifies algorithms for use withMutual authentication
protocol for Hyper-Text Transport Protocol (HTTP) protocol for Hyper-Text Transport Protocol (HTTP)
[I-D.ietf-httpauth-mutual]. The algorithms are based on so-called [I-D.ietf-httpauth-mutual]. The algorithms are based on "Augmented
"Augmented Password-based Authenticated Key Exchange" (Augmented Password-based Authenticated Key Exchange" (Augmented PAKE)
PAKE) techniques. In particular, it uses one of three key exchange techniques. In particular, it uses one of three key exchange
algorithm defined in the ISO 11770-4: "Key management - Mechanisms algorithms defined in ISO 11770-4: "Key management - Mechanisms based
based on weak secrets" [ISO.11770-4.2006] as a basis. on weak secrets" [ISO.11770-4.2006] as its basis.
In very brief summary, the Mutual authentication protocol exchanges In very brief summary, Mutual authentication protocol exchanges four
four values, K_c1, K_s1, VK_c and VK_s, to perform authenticated key values, K_c1, K_s1, VK_c and VK_s, to perform authenticated key
exchanges, using the password-derived secret pi and its "augmented exchanges, using the password-derived secret pi and its "augmented
version" J(pi). This document defines the set of functions K_c1, version" J(pi). This document defines the set of functions K_c1,
K_s1, and J for a specific algorithm family. K_s1, and J for a specific algorithm family.
Please note that, from the view of cryptographic literature, the Please note that from the view of cryptographic literature, the
original functionality of Augmented PAKE is separated into 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 functions K_c1 and K_s1 as defined in this draft, and the functions
and VK_s defined in Section 11 of [I-D.ietf-httpauth-mutual] as VK_c and VK_s, which are defined in Section 11 of
"default functions". For the purpose of security analysis, please [I-D.ietf-httpauth-mutual] as "default functions". For the purpose
also refer to these functions. of security analysis, please also refer to these functions.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
The term "natural numbers" refers to the non-negative integers The term "natural numbers" refers to the non-negative integers
(including zero) throughout this document. (including zero) throughout this document.
This document treats target (codomain) of hash functions to be octet This document treats both the input (domain) and the output
strings. The notation INT(H(s)) gives a natural-number output of (codomain) of hash functions to be octet strings. When a natural
hash function H applied to string s. number output is required, the notation INT(H(s)) is used.
2. Cryptographic Overview (Non-normative) 2. Cryptographic Overview (Non-normative)
The cryptographic primitive used in this algorithm specification is The cryptographic primitive used in this algorithm specification is
based on a variant of augmented PAKE proposed by T. Kwon, called based on a variant of augmented PAKE proposed by T. Kwon, called
APKAS-AMP, originally submitted to IEEE P1363.2. The general flow of APKAS-AMP, originally submitted to IEEE P1363.2. The general flow of
the successful exchange is shown below, for informative purposes the successful exchange is shown below, for informative purposes
only. The DL-based notations are used, and all group operations (mod only. The DL-based notations are used, and all group operations (mod
q and mod r) are omitted. q and mod r) are omitted.
Note that the only messages corresponding to the earlier two Note that the only messages corresponding to the first two messages
exchanges are defined in this specification. Those for latter two are defined in this specification. Those for latter two messages are
exchanges are defined in the main specification defined in the main specification [I-D.ietf-httpauth-mutual].
[I-D.ietf-httpauth-mutual].
C: S_c1 = random C: S_c1 = random
C: K_c1 = g^(S_c1) C: K_c1 = g^(S_c1)
----- ID, K_c1 -----> ----- ID, K_c1 ----->
C: t_1 = H1(K_c1) S: t_1 = H1(K_c1) C: t_1 = H1(K_c1) S: t_1 = H1(K_c1)
S: fetch J = g^pi by ID S: fetch J = g^pi by ID
S: S_s1 = random S: S_s1 = random
S: K_s1 = (J * K_c1^(t_1))^(S_s1) S: K_s1 = (J * K_c1^(t_1))^(S_s1)
<----- K_s1 ----- <----- K_s1 -----
C: t_2 = H2(K_c1, K_s1) S: t_2 = H2(K_c1, K_s1) C: t_2 = H2(K_c1, K_s1) S: t_2 = H2(K_c1, K_s1)
skipping to change at page 4, line 31 skipping to change at page 4, line 30
C: VK_c = H4(K_c1, K_s1, z) S: VK_c' = H4(K_c1, K_s1, z') C: VK_c = H4(K_c1, K_s1, z) S: VK_c' = H4(K_c1, K_s1, z')
----- VK_c -------> ----- VK_c ------->
S: assert(VK_c = 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') C: VK_s' = H3(K_c1, K_s1, z) S: VK_s = H3(K_c1, K_s1, z')
<----- VK_s ------ <----- VK_s ------
C: assert(VK_s = VK_s') C: assert(VK_s = VK_s')
3. Authentication Algorithms 3. Authentication Algorithms
This document specifies only one family of the authentication This document specifies one family of APKAS-AMP based algorithm.
algorithm. The family consists of four authentication algorithms, This family consists of four authentication algorithms, which differ
which only differ in their underlying mathematical groups and only in their underlying mathematical groups and security parameters.
security parameters. The algorithms do not add any additional These algorithms do not add any additional parameters. The tokens
parameters. The tokens for these algorithms are for these algorithms are
o iso-kam3-dl-2048-sha256: for the 2048-bit discrete-logarithm o iso-kam3-dl-2048-sha256: for the 2048-bit discrete logarithm
setting with the SHA-256 hash function. setting with the SHA-256 hash function.
o iso-kam3-dl-4096-sha512: for the 4096-bit discrete-logarithm o iso-kam3-dl-4096-sha512: for the 4096-bit discrete logarithm
setting with the SHA-512 hash function. setting with the SHA-512 hash function.
o iso-kam3-ec-p256-sha256: for the 256-bit prime-field elliptic- o iso-kam3-ec-p256-sha256: for the 256-bit prime-field elliptic-
curve setting with the SHA-256 hash function. curve setting with the SHA-256 hash function.
o iso-kam3-ec-p521-sha512: for the 521-bit prime-field elliptic- o iso-kam3-ec-p521-sha512: for the 521-bit prime-field elliptic-
curve setting with the SHA-512 hash function. curve setting with the SHA-512 hash function.
For discrete-logarithm settings, the underlying groups are the 2048- For discrete logarithm settings, the underlying groups are the 2048-
bit and 4096-bit MODP groups defined in [RFC3526], respectively. See bit and 4096-bit MODP groups defined in [RFC3526]. See Appendix A
Appendix A for the exact specifications of the groups and associated for the exact specifications of the groups and associated parameters.
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 The hash functions H are SHA-256 for the 2048-bit group and SHA-512
180-2 [FIPS.180-2.2002]. The hash iteration count nIterPi is 16384. for the 4096-bit group, respectively, defined in FIPS PUB 180-2
The representation of the parameters kc1, ks1, vkc, and vks is [FIPS.180-2.2002]. The hash iteration count nIterPi is 16384. The
base64-fixed-number. representation of the parameters kc1, ks1, vkc, and vks is base64-
fixed-number.
For the elliptic-curve settings, the underlying groups are the For the elliptic-curve settings, the underlying groups are the
elliptic curves over the prime fields P-256 and P-521, respectively, elliptic curves over the prime fields P-256 and P-521, respectively,
specified in the appendix D.1.2 of FIPS PUB 186-4 [FIPS.186-4.2013] specified in the appendix D.1.2 of the FIPS PUB 186-4
specification. The hash functions H, which are referenced by the [FIPS.186-4.2013] specification. The hash functions H, which are
core document, are SHA-256 for the P-256 curve and SHA-512 for the referenced by the core document, are SHA-256 for the P-256 curve and
P-521 curve, respectively. Cofactors of these curves are 1. The SHA-512 for the P-521 curve, respectively. Cofactors of these curves
hash iteration count nIterPi is 16384. The representation of the are 1. The hash iteration count nIterPi is 16384. The
parameters kc1, ks1, vkc, and vks is hex-fixed-number. 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) 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 defined in Section 6.3 of ISO/IEC 11770-4 [ISO.11770-4.2006] with a
few modifications/improvements. However, implementers should use few modifications/improvements. However, implementers should use
this document as the normative reference, because the algorithm has this document as the normative reference, because the algorithm has
been changed in several minor details as well as major improvements. been changed in several minor details as well as with major
improvements.
3.1. Support Functions and Notations 3.1. Support Functions and Notations
The algorithm definitions use several support functions and notations The algorithm definitions use the support functions and notations
defined below: defined below:
The integers in the specification are in decimal, or in hexadecimal The integers in the specification are in decimal by default, or in
when prefixed with "0x". hexadecimal when prefixed with "0x".
The functions named octet(), OCTETS(), and INT() are those defined in The functions named octet(), OCTETS(), and INT() are those defined in
the core specification [I-D.ietf-httpauth-mutual]. the core specification [I-D.ietf-httpauth-mutual].
Note: The definition of OCTETS() is different from the function Note: The definition of OCTETS() is different from the function
GE2OS_x in the original ISO specification, which takes the shortest GE2OS_x in the original ISO specification, which takes the shortest
representation without preceding zeros. representation without preceding zeros.
All of the algorithms defined in this specification use the default All of the algorithms defined in this specification use the default
functions defined in the core specification (defined in Section 11 of functions defined in the core specification (defined in Section 11 of
[I-D.ietf-httpauth-mutual]) for computing the values pi, VK_c and [I-D.ietf-httpauth-mutual]) for computing the values pi, VK_c and
VK_s. VK_s.
3.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 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. less than z that satisfies (w * y) mod z = x mod z.
For the discrete-logarithm, we refer to some of the domain parameters For the discrete logarithm, we refer to some of the domain parameters
by using the following symbols: by using the following symbols:
o q: for "the prime" defining the MODP group. o q: for "the prime" defining the MODP group.
o g: for "the generator" associated with the group. o g: for "the generator" associated with the group.
o r: for the order of the subgroup generated by g. o r: for the order of the subgroup generated by g.
The function J is defined as The function J is defined as
J(pi) = g^(pi) mod q. J(pi) = g^(pi) mod q.
The value of K_c1 is derived as The value of K_c1 is derived as
K_c1 = g^(S_c1) mod q, K_c1 = g^(S_c1) mod q,
where S_c1 is a random integer within range [1, r-1] and r is the where S_c1 is a random integer within range [1, r-1] and r is the
size of the subgroup generated by g. In addition, S_c1 MUST be 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). larger than log(q)/log(g) (so that g^(S_c1) > q).
The value of K_c1 SHALL satisfy 1 < K_c1 < q-1. The server MUST The server MUST check the condition 1 < K_c1 < q-1 upon reception.
check this condition upon reception.
Let an intermediate value t_1 be Let an intermediate value t_1 be
t_1 = INT(H(octet(1) | OCTETS(K_c1))), t_1 = INT(H(octet(1) | OCTETS(K_c1))),
the value of K_s1 is derived from J(pi) and K_c1 as: 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 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 where S_s1 is a random number within range [1, r-1]. The value of
skipping to change at page 7, line 7 skipping to change at page 7, line 7
the value z on the client side is derived by the following equation: 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. 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: The value z on the server side is derived by the following equation:
z = (K_c1 * g^(t_2))^(S_s1) mod q. z = (K_c1 * g^(t_2))^(S_s1) mod q.
(Note: the original ISO specification contained a message pair (Note: the original ISO specification contained a message pair
containing verification of value z along with the "transcript" of the containing verification of value z along with the "transcript" of the
protocol exchange. The functionality of this kind is contained in protocol exchange. This functionality is contained in the functions
the functions VK_c and VK_s.) VK_c and VK_s.)
3.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 For the elliptic-curve setting, we refer to some of the domain
parameters by the following symbols: parameters by the following symbols:
o q: for the prime used to define the group. o q: for the prime used to define the group.
o G: for the defined point called the generator. o G: for the defined point called the generator.
skipping to change at page 7, line 35 skipping to change at page 7, line 35
are the coordinates of point p. P'(z) is the inverse of function P, 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) = 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 z. If such p exists, it is uniquely defined. Otherwise, z does not
represent a valid curve point. represent a valid curve point.
The operator + indicates the elliptic-curve group operation, and the The operator + indicates the elliptic-curve group operation, and the
operation [x] * p denotes an integer-multiplication of point p: it operation [x] * p denotes an integer-multiplication of point p: it
calculates p + p + ... (x times) ... + p. See the literature on calculates p + p + ... (x times) ... + p. See the literature on
elliptic-curve cryptography for the exact algorithms used for those elliptic-curve cryptography for the exact algorithms used for those
functions (e.g. Section 3 of [RFC6090], which uses different functions (e.g. Section 3 of [RFC6090], which uses different
notations, though.) 0_E represents the infinity point. The equation notations, though). 0_E represents the infinity point. The equation
(x / y mod z) denotes a natural number w less than z that satisfies (x / y mod z) denotes a natural number w less than z that satisfies
(w * y) mod z = x mod z. (w * y) mod z = x mod z.
The function J is defined as The function J is defined as
J(pi) = [pi] * G. J(pi) = [pi] * G.
The value of K_c1 is derived as The value of K_c1 is derived as
K_c1 = P(K_c1'), where K_c1' = [S_c1] * G, 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 where S_c1 is a random number within range [1, r-1]. The server MUST
K_c1 MUST represent a valid curve point, and [h] * K_c1' SHALL NOT be check that the value of received K_c1 represents a valid curve point,
0_E. The server MUST check this condition upon reception. and [h] * K_c1' is not equal to 0_E.
Let an intermediate integer t_1 be Let an intermediate integer t_1 be
t_1 = INT(H(octet(1) | OCTETS(K_c1))), 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: 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')), 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 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 [h] * P'(K_s1) <> K_s1 MUST represent a valid curve point and satisfy [h] * P'(K_s1) <>
skipping to change at page 8, line 29 skipping to change at page 8, line 29
the value z on the client side is derived by the following equation: 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)). 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: The value z on the server side is derived by the following equation:
z = P([S_s1] * (P'(K_c1) + [t_2] * G)). z = P([S_s1] * (P'(K_c1) + [t_2] * G)).
4. IANA Considerations 4. IANA Considerations
This document defines four new tokens to be added for "HTTP Mutual This document defines four new tokens to be added to the "HTTP Mutual
authentication algorithms" registry; iso-kam3-dl-2048-sha256, authentication algorithms" registry; iso-kam3-dl-2048-sha256,
iso-kam3-dl-4096-sha512, iso-kam3-ec-p256-sha256 and iso-kam3-dl-4096-sha512, iso-kam3-ec-p256-sha256 and
iso-kam3-ec-p521-sha512, as follows: iso-kam3-ec-p521-sha512, as follows:
+-------------------------+-------------------------+---------------+ +-------------------------+-------------------------+---------------+
| Token | Description | Specification | | Token | Description | Specification |
+-------------------------+-------------------------+---------------+ +-------------------------+-------------------------+---------------+
| iso-kam3-dl-2048-sha256 | ISO-11770-4 KAM3, | This document | | iso-kam3-dl-2048-sha256 | ISO-11770-4 KAM3, | This document |
| | 2048-bit DL | | | | 2048-bit DL | |
| iso-kam3-dl-4096-sha512 | ISO-11770-4 KAM3, | This document | | iso-kam3-dl-4096-sha512 | ISO-11770-4 KAM3, | This document |
| | 4096-bit DL | | | | 4096-bit DL | |
| iso-kam3-ec-p256-sha256 | ISO-11770-4 KAM3, | This document | | iso-kam3-ec-p256-sha256 | ISO-11770-4 KAM3, | This document |
| | 256-bit EC | | | | 256-bit EC | |
| iso-kam3-ec-p521-sha512 | ISO-11770-4 KAM3, | This document | | iso-kam3-ec-p521-sha512 | ISO-11770-4 KAM3, | This document |
| | 521-bit EC | | | | 521-bit EC | |
+-------------------------+-------------------------+---------------+ +-------------------------+-------------------------+---------------+
5. Security Considerations 5. Security Considerations
Refer the corresponding section of the core specification for Please refer to the corresponding section of the core specification
algorithm-independent, generic considerations, too. [I-D.ietf-httpauth-mutual] for algorithm-independent considerations.
5.1. General Implementation Considerations 5.1. General Implementation Considerations
o During the exchange, the value VK_s, defined in o During the exchange, the value VK_s, defined in
[I-D.ietf-httpauth-mutual], MUST only be sent when the server has [I-D.ietf-httpauth-mutual], MUST only be sent when the server has
received a correct (expected) value of VK_c. This is a received a correct (expected) value of VK_c. This is a
requirement from underlying cryptography stated in cryptographic requirement, stated in [ISO.11770-4.2006].
[ISO.11770-4.2006].
o All random numbers used in these algorithms MUST be at least o All random numbers used in these algorithms MUST be at least
cryptographically computationally secure against forward and cryptographically computationally secure against forward and
backward guessing attacks. backward guessing attacks.
o Computation times of all numerical operations on discrete- o Computation times of all numerical operations on discrete
logarithm group elements and elliptic-curve points MUST be logarithm group elements and elliptic-curve points MUST be
normalized and made independent of the exact values, to prevent normalized and made independent of the exact values, to prevent
timing-based side-channel attacks. timing-based side-channel attacks.
5.2. Cryptographic Assumptions and Considerations 5.2. Cryptographic Assumptions and Considerations
The notices on this subsection is mostly for those who analyze the The notices in this subsection are for those who analyze the security
security of this algorithm, and those who might want to make a of this algorithm, and those who might want to make a derived work
derived work of this algorithm specification. from this algorithm specification.
o Handling of invalid K_s1 value in the exchange (now: to reject the o handling of an invalid K_s1 value in the exchange has been changed
exchange) has been changed from original ISO specification from the original ISO specification. The original specifies that
(original: to retry with another random S_s1 value). This is due the sender should retry with another random S_s1 value, while we
to an observation that this condition is less likely from the specify that the exchange must be rejected. This is due to an
random error caused by unlucky choice of S_s1, but more likely observation that this condition is less likely to result from the
from the systematic failure from invalid J(pi) value, even random error caused by an unlucky choice of S_s1, but more likely
implying possible denial-of-service attacks. the result of a systematic failure from an invalid J(pi) value
(even implying possible denial-of-service attacks).
o The usual construction of authenticated key exchange algorithms o The usual construction of authenticated key exchange algorithms
are build from a key-exchange period and a key verification consists of a key exchange phase and a key verification phase.
period, and the latter usually involving some kind of exchange The latter usually involves some kinds of exchange transaction to
transaction to be verified, to avoid security risks or be verified, to avoid security risks or vulnerabilities caused by
vulnerabilities caused from mixing of values from two or more key mixing values from from two or more key exchanges. In the design
exchanges. In the design of the algorithms in this document, such of the algorithms in this document, such a functionality is
a functionality is defined in generalized manner in the core defined in a generalized manner in the core specification
specification [I-D.ietf-httpauth-mutual] (see definitions of VK_c [I-D.ietf-httpauth-mutual] (see definitions of VK_c and VK_s). If
and VK_s). If any attempts to reuse the algorithm defined above the algorithm defined above is used in other protocols, this
with any other protocols exist, care MUST be taken on that aspect. aspect MUST be given careful consideration.
o The domain parameters chosen and specified in this draft has a few o The domain parameters chosen and specified in this draft are based
assumptions. In the DL setting, q has to be safe prime ([(q - 1) on a few assumptions. In the DL setting, q has to be a safe prime
/ 2] must also be prime), and r should be the largest possible ([(q - 1) / 2] must also be prime), and r should be the largest
value [(q - 1) / 2]. In the EC setting, r has to be prime. possible value [(q - 1) / 2]. In the EC setting, r has to be
Defining a variation of this algorithm using a different domain prime. Defining a variation of this algorithm using a different
parameter SHOULD care about these conditions. domain parameter SHOULD be attentive to these conditions.
6. Notice on intellectual properties 6. Intellectual Properties Notice
The National Institute of Advanced Industrial Science and Technology The National Institute of Advanced Industrial Science and Technology
(AIST) and Yahoo! Japan, Inc. has jointly submitted a patent (AIST) and Yahoo! Japan, Inc. have jointly submitted a patent
application on the protocol proposed in this documentation to the application on the protocol proposed in this documentation to the
Patent Office of Japan. The patent is intended to be open to any Patent Office of Japan. The patent is intended to be open to any
implementers of this protocol and its variants under non-exclusive implementer of this protocol and its variants in a non-exclusive
royalty-free manner. For the details of the patent application and royalty-free manner. For the details of the patent application and
its status, please contact the author of this document. its status, please contact the author of this document.
The elliptic-curve based authentication algorithms might involve The elliptic-curve based authentication algorithms might involve
several existing third-party patents. The authors of the document several existing third-party patents. The authors of the document
take no position regarding the validity or scope of such patents, and take no position regarding the validity or scope of such patents, and
other patents as well. other patents as well.
7. References 7. References
skipping to change at page 10, line 44 skipping to change at page 10, line 44
csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>. csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>.
[FIPS.186-4.2013] [FIPS.186-4.2013]
National Institute of Standards and Technology, "Digital National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-4, July 2013, <htt Signature Standard (DSS)", FIPS PUB 186-4, July 2013, <htt
p://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>. p://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>.
[I-D.ietf-httpauth-mutual] [I-D.ietf-httpauth-mutual]
Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
T., and Y. Ioku, "Mutual Authentication Protocol for T., and Y. Ioku, "Mutual Authentication Protocol for
HTTP", draft-ietf-httpauth-mutual-06 (work in progress), HTTP", draft-ietf-httpauth-mutual-07 (work in progress),
January 2016. January 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, DOI 10.17487/RFC3526, May 2003, RFC 3526, DOI 10.17487/RFC3526, May 2003,
skipping to change at page 11, line 23 skipping to change at page 11, line 23
International Organization for Standardization, International Organization for Standardization,
"Information technology - Security techniques - Key "Information technology - Security techniques - Key
management - Part 4: Mechanisms based on weak secrets", management - Part 4: Mechanisms based on weak secrets",
ISO Standard 11770-4, May 2006. ISO Standard 11770-4, May 2006.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/ Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/
RFC6090, February 2011, RFC6090, February 2011,
<http://www.rfc-editor.org/info/rfc6090>. <http://www.rfc-editor.org/info/rfc6090>.
Appendix A. (Informative) Group Parameters for Discrete-Logarithm Based Appendix A. (Informative) Group Parameters for Discrete Logarithm Based
Algorithms Algorithms
The MODP group used for the iso-kam3-dl-2048-sha256 algorithm is The MODP group used for the iso-kam3-dl-2048-sha256 algorithm is
defined by the following parameters. defined by the following parameters.
The prime is: The prime is:
q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
skipping to change at page 14, line 13 skipping to change at page 14, line 13
| values. | | | | | | | values. | | | | | |
| minimum | 2048 | 4096 | 1 | 1 | | | minimum | 2048 | 4096 | 1 | 1 | |
| allowed S_c1 | | | | | | | allowed S_c1 | | | | | |
+----------------+---------+---------+---------+---------+----------+ +----------------+---------+---------+---------+---------+----------+
(The numbers marked with an * do not include any enclosing quotation (The numbers marked with an * do not include any enclosing quotation
marks.) marks.)
Appendix C. (Informative) Draft Change Log Appendix C. (Informative) Draft Change Log
C.1. Changes in HTTPAUTH-WG revision 04 C.1. Changes in Httpauth WG Revision 05
o Several comments from reviewers are reflected to the text.
C.2. Changes in Httpauth WG revision 04
o Authors address updated. o Authors address updated.
C.2. Changes in HTTPAUTH-WG revision 03 C.3. Changes in Httpauth WG revision 03
o IANA registration information added. o IANA registration information added.
C.3. Changes in HTTPAUTH-WG revision 02 C.4. Changes in Httpauth WG revision 02
o No technical changes: references updated. o No technical changes: references updated.
C.4. Changes in HTTPAUTH-WG revision 01 C.5. Changes in Httpauth WG revision 01
o Changed behavior on failed generation of K_s1. o Changed behavior on failed generation of K_s1.
o Security considerations updated. o Security considerations updated.
C.5. Changes in HTTPAUTH-WG revision 00 C.6. Changes in Httpauth WG revision 00
o Added a note on the choice of elliptic curves. o Added a note on the choice of elliptic curves.
C.6. Changes in HTTPAUTH revision 02 C.7. Changes in HTTPAUTH revision 02
o Added nIterPi parameter to adjust to the changes to the core o Added nIterPi parameter to adjust to the changes to the core
draft. draft.
o Added a note on the verification of exchange transaction. o Added a note on the verification of exchange transaction.
C.7. Changes in HTTPAUTH revision 01 C.8. Changes in HTTPAUTH revision 01
o Notation change: integer output of hash function will be notated o Notation change: integer output of hash function will be notated
as INT(H(*)), changed from H(*). as INT(H(*)), changed from H(*).
C.8. Changes in revision 02 C.9. Changes in revision 02
o Implementation hints in appendix changed (number of characters for o Implementation hints in appendix changed (number of characters for
base64-fixed-number does not contain double-quotes). base64-fixed-number does not contain double-quotes).
C.9. Changes in revision 01 C.10. Changes in revision 01
o Parameter names renamed. o Parameter names renamed.
o Some expressions clarified without changing the value. o Some expressions clarified without changing the value.
C.10. Changes in revision 00 C.11. Changes in revision 00
The document is separated from the revision 08 of the core The document is separated from the revision 08 of the core
documentation. documentation.
Authors' Addresses Authors' Addresses
Yutaka Oiwa Yutaka Oiwa
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Information Technology Research Institute Information Technology Research Institute
Tsukuba Central 1 Tsukuba Central 1
 End of changes. 53 change blocks. 
122 lines changed or deleted 128 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/