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/ |