draft-ietf-httpauth-mutual-algo-07.txt   rfc8121.txt 
HTTPAUTH Working Group Y. Oiwa Internet Engineering Task Force (IETF) Y. Oiwa
Internet-Draft H. Watanabe Request for Comments: 8121 H. Watanabe
Intended status: Experimental H. Takagi Category: Experimental H. Takagi
Expires: May 18, 2017 ITRI, AIST ISSN: 2070-1721 ITRI, AIST
K. Maeda K. Maeda
Individual Contributor
T. Hayashi T. Hayashi
Lepidum Lepidum
Y. Ioku Y. Ioku
Individual Individual Contributor
November 14, 2016 April 2017
Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Mutual Authentication Protocol for HTTP: Cryptographic Algorithms
Algorithms Based on the Key Agreement Mechanism 3 (KAM3)
draft-ietf-httpauth-mutual-algo-07
Abstract Abstract
This document specifies cryptographic algorithms for use with the This document specifies cryptographic algorithms for use with the
Mutual user authentication method for the Hyper-text Transport Mutual user authentication method for the Hypertext Transfer Protocol
Protocol (HTTP). (HTTP).
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for examination, experimental implementation, and
working documents as Internet-Drafts. The list of current Internet- evaluation.
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on May 18, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8121.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 ....................................................2
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 . . . . . . . . 6 3.2. Functions for Discrete-Logarithm Settings ..................6
3.3. Functions for Elliptic-Curve Settings . . . . . . . . . . 7 3.3. Functions for Elliptic-Curve Settings ......................7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations .............................................9
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 ..............10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. References .....................................................11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References ......................................11
6.2. Informative References . . . . . . . . . . . . . . . . . . 10 6.2. Informative References ....................................12
Appendix A. (Informative) Group Parameters for Discrete Appendix A. (Informative) Group Parameters for Algorithms Based
Logarithm Based Algorithms . . . . . . . . . . . . . 11 on the Discrete Logarithm .............................13
Appendix B. (Informative) Derived Numerical Values . . . . . . . 13 Appendix B. (Informative) Derived Numerical Values ................16
Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 14 Authors' Addresses ................................................17
C.1. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 14
C.2. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 14
C.3. Changes in Httpauth WG revision 04 . . . . . . . . . . . . 14
C.4. Changes in Httpauth WG revision 03 . . . . . . . . . . . . 14
C.5. Changes in Httpauth WG revision 02 . . . . . . . . . . . . 14
C.6. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 14
C.7. Changes in Httpauth WG revision 00 . . . . . . . . . . . . 14
C.8. Changes in HTTPAUTH revision 02 . . . . . . . . . . . . . 14
C.9. Changes in HTTPAUTH revision 01 . . . . . . . . . . . . . 15
C.10. Changes in revision 02 . . . . . . . . . . . . . . . . . . 15
C.11. Changes in revision 01 . . . . . . . . . . . . . . . . . . 15
C.12. Changes in revision 00 . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document specifies algorithms for use with Mutual authentication This document specifies algorithms for use with the Mutual
protocol for Hyper-Text Transport Protocol (HTTP) authentication protocol for the Hypertext Transfer Protocol (HTTP)
[I-D.ietf-httpauth-mutual] (referred as the "core specification" [RFC8120] (hereafter referred to as the "core specification"). The
hereafter). The algorithms are based on "Augmented Password-based algorithms are based on augmented password-based authenticated key
Authenticated Key Exchange" (Augmented PAKE) techniques. In exchange (augmented PAKE) techniques. In particular, it uses one of
particular, it uses one of three key exchange algorithms defined in three key exchange algorithms defined in ISO 11770-4 ("Information
ISO 11770-4: "Key management - Mechanisms based on weak secrets" technology - Security techniques - Key management - Part 4:
[ISO.11770-4.2006] as its basis. Mechanisms based on weak secrets") [ISO.11770-4.2006] as its basis.
In very brief summary, Mutual authentication protocol exchanges four To briefly summarize, the Mutual authentication protocol exchanges
values, K_c1, K_s1, VK_c and VK_s, to perform authenticated key four values -- K_c1, K_s1, VK_c, and VK_s -- to perform authenticated
exchanges, using the password-derived secret pi and its "augmented key exchanges, using the password-derived secret pi and its
version" J(pi). This document defines the set of functions K_c1, "augmented version" J(pi). This document defines the set of
K_s1, and J for a specific algorithm family. functions K_c1, K_s1, and J for a specific algorithm family.
Please note that from the view of cryptographic literature, the Please note that from the point of view of literature related to
original functionality of Augmented PAKE is separated into the cryptography, the original functionality of augmented PAKE is
functions K_c1 and K_s1 as defined in this draft, and the functions separated into the functions K_c1 and K_s1 as defined in this
VK_c and VK_s, which are defined in Section 11 of document, and the functions VK_c and VK_s, which are defined in
[I-D.ietf-httpauth-mutual] as "default functions". For the purpose Section 12.2 of [RFC8120] as "default functions". For the purpose of
of security analysis, please also refer to these functions. 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 non-negative integers (including
(including zero) throughout this document. zero) throughout this document.
This document treats both the input (domain) and the output This document treats both the input (domain) and the output
(codomain) of hash functions to be octet strings. When a natural (codomain) of hash functions as octet strings. When a natural-number
number output of hash function H is required, it will be notated like output of hash function H is required, it will be notated, for
INT(H(s)). example, as INT(H(s)).
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 called "APKAS-AMP" (augmented
APKAS-AMP, originally submitted to IEEE P1363.2. The general flow of password-authenticated key agreement scheme, version AMP), proposed
the successful exchange is shown below, for informative purposes by T. Kwon and originally submitted to [IEEE-1363.2_2008]. The
only. The multiplicative notations are used for group operators, and general flow of the successful exchange is shown below for
all modulus operations for finite groups (mod q and mod r) are informative purposes only. The multiplicative notations are used for
omitted. group operators, and all modulus operations for finite groups (mod q
and mod r) are omitted.
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 29 skipping to change at page 4, line 28
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')
Note that the concrete (binary) message formats (mapping to HTTP Note that the concrete (binary) message formats (mapping to HTTP
messages), as well as the formal definitions of equations for the messages), as well as the formal definitions of equations for the
latter two messages, are defined in core specification latter two messages, are defined in the core specification [RFC8120].
[I-D.ietf-httpauth-mutual]. The formal definitions for values The formal definitions for values corresponding to the first two
corresponding to the first two messages are defined in the following messages are defined in the following sections.
sections.
3. Authentication Algorithms 3. Authentication Algorithms
This document specifies one family of APKAS-AMP based algorithm. This document specifies one family of algorithms based on APKAS-AMP,
This family consists of four authentication algorithms, which differ to be used with [RFC8120]. This family consists of four
only in their underlying mathematical groups and security parameters. authentication algorithms, which differ only in their underlying
These algorithms do not add any additional parameters. The tokens mathematical groups and security parameters. These algorithms do not
for these algorithms are add any additional parameters. The tokens for these algorithms are
as follows:
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
curve setting with the SHA-256 hash function. elliptic-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
curve setting with the SHA-512 hash function. elliptic-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
bit and 4096-bit MODP groups defined in [RFC3526]. See Appendix A 2048-bit and 4096-bit Modular Exponential (MODP) groups defined in
for the exact specifications of the groups and associated parameters. [RFC3526]. See Appendix A for the exact specifications for the
The hash functions H are SHA-256 for the 2048-bit group and SHA-512 groups and associated parameters. Hash function H is SHA-256 for the
for the 4096-bit group, respectively, defined in FIPS PUB 180-2 2048-bit group and SHA-512 for the 4096-bit group, respectively, as
[FIPS.180-2.2002]. The hash iteration count nIterPi is 16384. The defined in FIPS PUB 180-4 [FIPS.180-4.2015]. The hash iteration
representation of the parameters kc1, ks1, vkc, and vks is base64- count nIterPi is 16384. The representation of the parameters "kc1",
fixed-number. "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 the FIPS PUB 186-4 as specified in Appendix D.1.2 of the FIPS PUB 186-4
[FIPS.186-4.2013] specification. The hash functions H, which are [FIPS.186-4.2013] specification. Hash function H is SHA-256 for the
referenced by the core document, are SHA-256 for the P-256 curve and P-256 curve and SHA-512 for the P-521 curve, respectively. Cofactors
SHA-512 for the P-521 curve, respectively. Cofactors of these curves of these curves are 1. The hash iteration count nIterPi is 16384.
are 1. The hash iteration count nIterPi is 16384. The The representation of the parameters "kc1", "ks1", "vkc", and "vks"
representation of the parameters kc1, ks1, vkc, and vks is hex-fixed- is hex-fixed-number.
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 as defined in Section 6.3 of ISO/IEC 11770-4 [ISO.11770-4.2006], with
few modifications/improvements. However, implementers should use a few modifications/improvements. However, implementers should
this document as the normative reference, because the algorithm has consider this document as normative, because several minor details of
been changed in several minor details as well as with major the algorithm have changed and major improvements have been made.
improvements.
3.1. Support Functions and Notations 3.1. Support Functions and Notations
The algorithm definitions use the 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 by default, or in Decimal notations are used for integers in this specification by
hexadecimal when prefixed with "0x". default. Integers in hexadecimal notations are prefixed with "0x".
The functions named octet(), OCTETS(), and INT() are those defined in In this document, the octet(), OCTETS(), and INT() functions are used
the core specification [I-D.ietf-httpauth-mutual]. as defined in the core specification [RFC8120].
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; GE2OS_x 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 Section 12.2 of [RFC8120] for computing the
[I-D.ietf-httpauth-mutual]) for computing the values pi, VK_c and 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 the 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 server MUST check the condition 1 < K_c1 < q-1 upon reception. The server MUST check the condition 1 < K_c1 < q-1 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 the range [1, r-1]. The value
K_s1 MUST satisfy 1 < K_s1 < q-1. If this condition is not held, the of K_s1 MUST satisfy 1 < K_s1 < q-1. If this condition is not held,
server MUST reject the exchange. The client MUST check this the server MUST reject the exchange. The client MUST check this
condition upon reception. condition upon reception.
Let an intermediate value t_2 be Let an intermediate value t_2 be
t_2 = INT(H(octet(2) | OCTETS(K_c1) | OCTETS(K_s1))), 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: 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. This functionality is contained in the functions protocol exchange. This functionality is contained in 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 settings, 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 point defined with the underlying group called "the o G: for the point defined with the underlying group called
generator". "the generator".
o h: for the cofactor of the group. o h: for the cofactor of 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 P(p) converts a curve point p into an integer 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) 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, 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
z. If such p exists, it is uniquely defined. Otherwise, z does not P(p) = z. If such p exists, it is uniquely defined. Otherwise,
represent a valid curve point. z does not represent a valid curve point.
The operator + indicates the elliptic-curve group operation, and the The operator "+" indicates the elliptic-curve group operation, and
operation [x] * p denotes an integer-multiplication of point p: it the operation [x] * p denotes an integer-multiplication of point p:
calculates p + p + ... (x times) ... + p. See the literature on it 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]; however, note that [RFC6090]
notations, though). 0_E represents the infinity point. The equation uses different notations). 0_E represents the infinity point. The
(x / y mod z) denotes a natural number w less than z that satisfies equation (x / y mod z) denotes a natural number w less than z that
(w * y) mod z = x mod z. satisfies (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 server MUST where S_c1 is a random number within the range [1, r-1]. The server
check that the value of received K_c1 represents a valid curve point, MUST check that (1) the value of received K_c1 represents a valid
and [h] * K_c1' is not equal to 0_E. curve point and (2) [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 the range [1, r-1]. The value
K_s1 MUST represent a valid curve point and satisfy [h] * P'(K_s1) <> of K_s1 MUST represent a valid curve point and satisfy
0_E. If this condition is not satisfied, the server MUST reject the [h] * P'(K_s1) <> 0_E. If this condition is not satisfied, the
exchange. The client MUST check this condition upon reception. server MUST reject the exchange. The client MUST check this
condition upon reception.
Let an intermediate integer t_2 be Let an intermediate integer t_2 be
t_2 = INT(H(octet(2) | OCTETS(K_c1) | OCTETS(K_s1))), 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: 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 to the "HTTP Mutual This document defines four new tokens that have been added to the
authentication algorithms" registry; iso-kam3-dl-2048-sha256, "HTTP Mutual Authentication Algorithms" registry:
iso-kam3-dl-4096-sha512, iso-kam3-ec-p256-sha256 and
iso-kam3-ec-p521-sha512, as follows:
+-------------------------+-------------------------+---------------+ +-------------------------+-----------------------------+-----------+
| Token | Description | Specification | | Token | Description | Reference |
+-------------------------+-------------------------+---------------+ +-------------------------+-----------------------------+-----------+
| iso-kam3-dl-2048-sha256 | ISO-11770-4 KAM3, | This document | | iso-kam3-dl-2048-sha256 | ISO-11770-4 KAM3, | RFC 8121 |
| | 2048-bit DL | | | | 2048-bit DL | |
| iso-kam3-dl-4096-sha512 | ISO-11770-4 KAM3, | This document | | | | |
| | 4096-bit DL | | | iso-kam3-dl-4096-sha512 | ISO-11770-4 KAM3, | RFC 8121 |
| iso-kam3-ec-p256-sha256 | ISO-11770-4 KAM3, | This document | | | 4096-bit DL | |
| | 256-bit EC | | | | | |
| iso-kam3-ec-p521-sha512 | ISO-11770-4 KAM3, | This document | | iso-kam3-ec-p256-sha256 | ISO-11770-4 KAM3, | RFC 8121 |
| | 521-bit EC | | | | 256-bit EC | |
+-------------------------+-------------------------+---------------+ | | | |
| iso-kam3-ec-p521-sha512 | ISO-11770-4 KAM3, | RFC 8121 |
| | 521-bit EC | |
+-------------------------+-----------------------------+-----------+
5. Security Considerations 5. Security Considerations
Please refer to the corresponding section of the core specification Please refer to the Security Considerations section of the core
[I-D.ietf-httpauth-mutual] for algorithm-independent considerations. specification [RFC8120] 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 [RFC8120], MUST
[I-D.ietf-httpauth-mutual], MUST only be sent when the server has only be sent when the server has received a correct (expected)
received a correct (expected) value of VK_c. This is a value of VK_c. This is a cryptographic requirement, as 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
cryptographically computationally secure against forward and cryptographically secure against forward and backward guessing
backward guessing attacks. attacks.
o Computation times of all numerical operations on discrete o To prevent timing-based side-channel attacks, computation times of
logarithm group elements and elliptic-curve points MUST be all numerical operations on discrete-logarithm group elements and
normalized and made independent of the exact values, to prevent elliptic-curve points MUST be normalized and made independent of
timing-based side-channel attacks. the exact values.
5.2. Cryptographic Assumptions and Considerations 5.2. Cryptographic Assumptions and Considerations
The notices in this subsection are for those who analyze the security The notes in this subsection are for those who analyze the security
of this algorithm, and those who might want to make a derived work of this algorithm and those who might want to make a derived work
from this algorithm specification. from this algorithm specification.
o handling of an invalid K_s1 value in the exchange has been changed o The treatment of an invalid K_s1 value in the exchange has been
from the original ISO specification. The original specifies that changed from the method defined in the original ISO specification,
the sender should retry with another random S_s1 value, while we which specifies that the sender should retry with another random
specify that the exchange must be rejected. This is due to an S_s1 value. We specify that the exchange must be rejected. This
observation that this condition is less likely to result from the is due to an observation that this condition is less likely to
random error caused by an unlucky choice of S_s1, but more likely result from a random error caused by an unlucky choice of S_s1 but
the result of a systematic failure from an invalid J(pi) value is more likely the result of a systematic failure caused by an
(even implying possible denial-of-service attacks). 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
consists of a key exchange phase and a key verification phase. consists of a key exchange phase and a key verification phase. To
The latter usually involves some kinds of exchange transaction to avoid security risks or vulnerabilities caused by mixing values
be verified, to avoid security risks or vulnerabilities caused by from two or more key exchanges, the latter usually involves some
mixing values from from two or more key exchanges. In the design kinds of exchange transactions to be verified. In the algorithms
of the algorithms in this document, such a functionality is defined in this document, such verification steps are provided in
defined in a generalized manner in the core specification the generalized definitions of VK_c and VK_s in [RFC8120]. If the
[I-D.ietf-httpauth-mutual] (see definitions of VK_c and VK_s). If algorithm defined above is used in other protocols, this aspect
the algorithm defined above is used in other protocols, this MUST be given careful consideration.
aspect MUST be given careful consideration.
o The domain parameters chosen and specified in this draft are based o The domain parameters chosen and specified in this document are
on a few assumptions. In the discrete-logarithm setting, q has to based on a few assumptions. In the discrete-logarithm setting,
be a safe prime ([(q - 1) / 2] must also be prime), and r should q has to be a safe prime ([(q - 1) / 2] must also be prime), and
be the largest possible value [(q - 1) / 2]. In the elliptic- r should be the largest possible value [(q - 1) / 2]. In the
curve setting, r has to be prime. Defining a variation of this elliptic-curve setting, r has to be prime. Implementers defining
algorithm using a different domain parameter SHOULD be attentive a variation of this algorithm using a different domain parameter
to these conditions. SHOULD be attentive to these conditions.
6. References 6. References
6.1. Normative References 6.1. Normative References
[FIPS.180-2.2002] [FIPS.180-4.2015]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, <http:// Hash Standard (SHS)", FIPS PUB 180-4,
csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>. DOI 10.6028/NIST.FIPS.180-4, August 2015,
<http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.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,
p://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>. DOI 10.6028/NIST.FIPS.186-4, July 2013,
<http://nvlpubs.nist.gov/nistpubs/FIPS/
[I-D.ietf-httpauth-mutual] NIST.FIPS.186-4.pdf>.
Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
T., and Y. Ioku, "Mutual Authentication Protocol for
HTTP", draft-ietf-httpauth-mutual-11 (work in progress),
November 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,
RFC2119, March 1997, DOI 10.17487/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,
<http://www.rfc-editor.org/info/rfc3526>. <http://www.rfc-editor.org/info/rfc3526>.
[RFC8120] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
T., and Y. Ioku, "Mutual Authentication Protocol for
HTTP", RFC 8120, DOI 10.17487/RFC8120, April 2017,
<http://www.rfc-editor.org/info/rfc8120>.
6.2. Informative References 6.2. Informative References
[IEEE-1363.2_2008]
IEEE, "IEEE Standard Specifications for Password-Based
Public-Key Cryptographic Techniques", IEEE 1363.2-2008,
DOI 10.1109/ieeestd.2009.4773330,
<http://ieeexplore.ieee.org/servlet/
opac?punumber=4773328>.
[ISO.11770-4.2006] [ISO.11770-4.2006]
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,
<http://www.iso.org/iso/iso_catalogue/catalogue_tc/
catalogue_detail.htm?csnumber=39723>.
[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,
RFC6090, February 2011, DOI 10.17487/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 Algorithms Based on the
Algorithms Discrete Logarithm
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
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AACAA68 FFFFFFFF FFFFFFFF. 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
The generator is: The generator is
g = 2. g = 2
The size of the subgroup generated by g is: The size of the subgroup generated by g is
r = (q - 1) / 2 = r = (q - 1) / 2 =
0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68
94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E
F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122
F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6
F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E
E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF
C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36
B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D
F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964 F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964
EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288 EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288
0AB9472D 45565534 7FFFFFFF FFFFFFFF. 0AB9472D 45565534 7FFFFFFF FFFFFFFF
The MODP group used for the iso-kam3-dl-4096-sha512 algorithm is The MODP group used for the iso-kam3-dl-4096-sha512 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
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA 88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6 2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED 287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9 1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
FFFFFFFF FFFFFFFF. FFFFFFFF FFFFFFFF
The generator is: The generator is
g = 2. g = 2
The size of the subgroup generated by g is: The size of the subgroup generated by g is
r = (q - 1) / 2 = r = (q - 1) / 2 =
0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68
94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E
F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122
F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6
F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E
E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF
C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36
B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D
F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964 F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964
EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288 EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288
0AB9472D 45556216 D6998B86 82283D19 D42A90D5 EF8E5D32 0AB9472D 45556216 D6998B86 82283D19 D42A90D5 EF8E5D32
767DC282 2C6DF785 457538AB AE83063E D9CB87C2 D370F263 767DC282 2C6DF785 457538AB AE83063E D9CB87C2 D370F263
D5FAD746 6D8499EB 8F464A70 2512B0CE E771E913 0D697735 D5FAD746 6D8499EB 8F464A70 2512B0CE E771E913 0D697735
F897FD03 6CC50432 6C3B0139 9F643532 290F958C 0BBD9006 F897FD03 6CC50432 6C3B0139 9F643532 290F958C 0BBD9006
5DF08BAB BD30AEB6 3B84C460 5D6CA371 047127D0 3A72D598 5DF08BAB BD30AEB6 3B84C460 5D6CA371 047127D0 3A72D598
A1EDADFE 707E8847 25C16890 54908400 8D391E09 53C3F36B A1EDADFE 707E8847 25C16890 54908400 8D391E09 53C3F36B
C438CD08 5EDD2D93 4CE1938C 357A711E 0D4A341A 5B0A85ED C438CD08 5EDD2D93 4CE1938C 357A711E 0D4A341A 5B0A85ED
12C1F4E5 156A2674 6DDDE16D 826F477C 97477E0A 0FDF6553 12C1F4E5 156A2674 6DDDE16D 826F477C 97477E0A 0FDF6553
143E2CA3 A735E02E CCD94B27 D04861D1 119DD0C3 28ADF3F6 143E2CA3 A735E02E CCD94B27 D04861D1 119DD0C3 28ADF3F6
8FB094B8 67716BD7 DC0DEEBB 10B8240E 68034893 EAD82D54 8FB094B8 67716BD7 DC0DEEBB 10B8240E 68034893 EAD82D54
C9DA754C 46C7EEE0 C37FDBEE 48536047 A6FA1AE4 9A0318CC C9DA754C 46C7EEE0 C37FDBEE 48536047 A6FA1AE4 9A0318CC
FFFFFFFF FFFFFFFF. FFFFFFFF FFFFFFFF
Appendix B. (Informative) Derived Numerical Values Appendix B. (Informative) Derived Numerical Values
This section provides several numerical values for implementing this This section provides several numerical values for implementing this
protocol, derived from the above specifications. The values shown in protocol. These values are derived from the specifications provided
this section are for informative purposes only. in Section 3. The values shown in this section are for informative
purposes only.
+----------------+---------+---------+---------+---------+----------+ +----------------+---------+---------+---------+---------+----------+
| | dl-2048 | dl-4096 | ec-p256 | ec-p521 | | | | dl-2048 | dl-4096 | ec-p256 | ec-p521 | |
+----------------+---------+---------+---------+---------+----------+ +----------------+---------+---------+---------+---------+----------+
| Size of K_c1 | 2048 | 4096 | 257 | 522 | (bits) | | Size of K_c1, | 2048 | 4096 | 257 | 522 | (bits) |
| etc. | | | | | | | etc. | | | | | |
| hSize, Size of | 256 | 512 | 256 | 512 | (bits) | | | | | | | |
| hSize, size of | 256 | 512 | 256 | 512 | (bits) |
| H(...) | | | | | | | H(...) | | | | | |
| length of | 256 | 512 | 33 | 66 | (octets) | | | | | | | |
| OCTETS(K_c1) | | | | | | | Length of | 256 | 512 | 33 | 66 | (octets) |
| OCTETS(K_c1), | | | | | |
| etc. | | | | | | | etc. | | | | | |
| length of kc1, | 344 * | 684 * | 66 | 132 | (octets) | | | | | | | |
| Length of kc1, | 344* | 684* | 66 | 132 | (octets) |
| ks1 param. | | | | | | | ks1 param. | | | | | |
| values. | | | | | | | values | | | | | |
| length of vkc, | 44 * | 88 * | 64 | 128 | (octets) | | | | | | | |
| Length of vkc, | 44* | 88* | 64 | 128 | (octets) |
| vks param. | | | | | | | vks param. | | | | | |
| 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
marks.) quotation marks.)
Appendix C. (Informative) Draft Change Log
C.1. Changes in Httpauth WG Revision 06
o Authors' addresses updated.
C.2. Changes in Httpauth WG Revision 05
o Several comments from reviewers are reflected to the text.
C.3. Changes in Httpauth WG revision 04
o Authors address updated.
C.4. Changes in Httpauth WG revision 03
o IANA registration information added.
C.5. Changes in Httpauth WG revision 02
o No technical changes: references updated.
C.6. Changes in Httpauth WG revision 01
o Changed behavior on failed generation of K_s1.
o Security considerations updated.
C.7. Changes in Httpauth WG revision 00
o Added a note on the choice of elliptic curves.
C.8. Changes in HTTPAUTH revision 02
o Added nIterPi parameter to adjust to the changes to the core
draft.
o Added a note on the verification of exchange transaction.
C.9. Changes in HTTPAUTH revision 01
o Notation change: integer output of hash function will be notated
as INT(H(*)), changed from H(*).
C.10. Changes in revision 02
o Implementation hints in appendix changed (number of characters for
base64-fixed-number does not contain double-quotes).
C.11. Changes in revision 01
o Parameter names renamed.
o Some expressions clarified without changing the value.
C.12. Changes in revision 00
The document is separated from the revision 08 of the core
documentation.
Authors' Addresses 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
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP Japan
Email: y.oiwa@aist.go.jp Email: y.oiwa@aist.go.jp
Hajime Watanabe Hajime Watanabe
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
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP Japan
Email: h-watanabe@aist.go.jp Email: h-watanabe@aist.go.jp
Hiromitsu Takagi Hiromitsu Takagi
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
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP Japan
Email: takagi.hiromitsu@aist.go.jp Email: takagi.hiromitsu@aist.go.jp
Kaoru Maeda Kaoru Maeda
Lepidum Co. Ltd. Individual Contributor
Village Sasazuka 3, Suite #602 Email: kaorumaeda.ml@gmail.com
1-30-3 Sasazuka
Shibuya-ku, Tokyo
JP
Email: maeda@lepidum.co.jp
Tatsuya Hayashi Tatsuya Hayashi
Lepidum Co. Ltd. Lepidum Co. Ltd.
Village Sasazuka 3, Suite #602 Village Sasazuka 3, Suite #602
1-30-3 Sasazuka 1-30-3 Sasazuka
Shibuya-ku, Tokyo Shibuya-ku, Tokyo
JP Japan
Email: hayashi@lepidum.co.jp Email: hayashi@lepidum.co.jp
Yuichi Ioku Yuichi Ioku
Individual Individual Contributor
Email: mutual-work@ioku.org Email: mutual-work@ioku.org
 End of changes. 108 change blocks. 
418 lines changed or deleted 355 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/