HTTPAUTH Working Group
Internet Engineering Task Force (IETF)                           Y. Oiwa
Internet-Draft
Request for Comments: 8121                                   H. Watanabe
Intended status:
Category: Experimental                                         H. Takagi
Expires: May 18, 2017
ISSN: 2070-1721                                               ITRI, AIST
                                                                K. Maeda
                                                  Individual Contributor
                                                              T. Hayashi
                                                                 Lepidum
                                                                 Y. Ioku
                                                  Individual
                                                       November 14, 2016 Contributor
                                                              April 2017

   Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms
                   draft-ietf-httpauth-mutual-algo-07
             Based on the Key Agreement Mechanism 3 (KAM3)

Abstract

   This document specifies cryptographic algorithms for use with the
   Mutual user authentication method for the Hyper-text Transport Hypertext Transfer Protocol
   (HTTP).

Status of this This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and BCP 79.

   Internet-Drafts are working documents
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF
   community.  It has received public review and has been approved for
   publication by the Internet Engineering Steering Group (IESG).  Not
   all documents approved by the IESG are a maximum candidate for any level of
   Internet Standard; see Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 18, 2017.
   http://www.rfc-editor.org/info/rfc8121.

Copyright Notice

   Copyright (c) 2016 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3 ....................................................2
      1.1. Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3 ................................................3
   2. Cryptographic Overview (Non-normative) . . . . . . . . . . . .  3 ..........................3
   3. Authentication Algorithms  . . . . . . . . . . . . . . . . . .  4 .......................................4
      3.1. Support Functions and Notations  . . . . . . . . . . . . .  5 ............................5
      3.2. Functions for Discrete Logarithm Discrete-Logarithm Settings  . . . . . . . .  6 ..................6
      3.3. Functions for Elliptic-Curve Settings  . . . . . . . . . .  7 ......................7
   4. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8 .............................................9
   5. Security Considerations  . . . . . . . . . . . . . . . . . . .  9 .........................................9
      5.1. General Implementation Considerations  . . . . . . . . . .  9 ......................9
      5.2. Cryptographic Assumptions and Considerations . . . . . . .  9 ..............10
   6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 .....................................................11
      6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 ......................................11
      6.2. Informative References . . . . . . . . . . . . . . . . . . 10 ....................................12
   Appendix A. (Informative) Group Parameters for Algorithms Based
               on the Discrete Logarithm Based Algorithms  . . . . . . . . . . . . . 11 .............................13
   Appendix B. (Informative) Derived Numerical Values  . . . . . . . 13 ................16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 ................................................17

1.  Introduction

   This document specifies algorithms for use with the Mutual
   authentication protocol for Hyper-Text Transport the Hypertext Transfer Protocol (HTTP)
   [I-D.ietf-httpauth-mutual] (referred
   [RFC8120] (hereafter referred to as the "core specification"
   hereafter). specification").  The
   algorithms are based on "Augmented Password-based
   Authenticated Key Exchange" (Augmented augmented password-based authenticated key
   exchange (augmented PAKE) techniques.  In particular, it uses one of
   three key exchange algorithms defined in ISO 11770-4: "Key 11770-4 ("Information
   technology - Security techniques - Key management - Part 4:
   Mechanisms based on weak secrets" secrets") [ISO.11770-4.2006] as its basis.

   In very brief summary,

   To briefly summarize, the Mutual authentication protocol exchanges
   four
   values, values -- K_c1, K_s1, VK_c VK_c, and VK_s, VK_s -- to perform authenticated
   key exchanges, using the password-derived secret pi and its
   "augmented version" J(pi).  This document defines the set of
   functions K_c1, K_s1, and J for a specific algorithm family.

   Please note that from the point of view of cryptographic literature, literature related to
   cryptography, the original functionality of Augmented augmented PAKE is
   separated into the functions K_c1 and K_s1 as defined in this draft,
   document, and the functions VK_c and VK_s, which are defined in
   Section 11 12.2 of
   [I-D.ietf-httpauth-mutual] [RFC8120] as "default functions".  For the purpose of
   security analysis, please also refer to these functions.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   The term "natural numbers" refers to the non-negative integers (including
   zero) throughout this document.

   This document treats both the input (domain) and the output
   (codomain) of hash functions to be as octet strings.  When a natural
   number natural-number
   output of hash function H is required, it will be notated like notated, for
   example, as INT(H(s)).

2.  Cryptographic Overview (Non-normative)

   The cryptographic primitive used in this algorithm specification is
   based on a variant of augmented PAKE called "APKAS-AMP" (augmented
   password-authenticated key agreement scheme, version AMP), proposed
   by T. Kwon, called
   APKAS-AMP, Kwon and originally submitted to IEEE P1363.2. [IEEE-1363.2_2008].  The
   general flow of the successful exchange is shown below, below for
   informative purposes only.  The multiplicative notations are used for
   group operators, and all modulus operations for finite groups (mod q
   and mod r) are omitted.

      C: S_c1 = random
      C: K_c1 = g^(S_c1)
                       ----- ID, K_c1 ----->
      C: t_1 = H1(K_c1)                S: t_1 = H1(K_c1)
                                       S: fetch J = g^pi by ID
                                       S: S_s1 = random
                                       S: K_s1 = (J * K_c1^(t_1))^(S_s1)
                       <----- K_s1 -----
      C: t_2 = H2(K_c1, K_s1)          S: t_2 = H2(K_c1, K_s1)
      C: z = K_s1^((S_c1 + t_2) / (S_c1 * t_1 + pi))
                                       S: z' = (K_c1 * g^(t_2))^(S_s1)
      (assumption at this point: z = z' if authentication succeeded)

      C: VK_c = H4(K_c1, K_s1, z)      S: VK_c' = H4(K_c1, K_s1, z')
                       ----- VK_c ------->
                                       S: assert(VK_c = VK_c')

      C: VK_s' = H3(K_c1, K_s1, z)     S: VK_s = H3(K_c1, K_s1, z')
                       <----- VK_s ------
      C: assert(VK_s = VK_s')

   Note that the concrete (binary) message formats (mapping to HTTP
   messages), as well as the formal definitions of equations for the
   latter two messages, are defined in the core specification
   [I-D.ietf-httpauth-mutual]. [RFC8120].
   The formal definitions for values corresponding to the first two
   messages are defined in the following sections.

3.  Authentication Algorithms

   This document specifies one family of APKAS-AMP algorithms based algorithm. on APKAS-AMP,
   to be used with [RFC8120].  This family consists of four
   authentication algorithms, which differ only in their underlying
   mathematical groups and security parameters.  These algorithms do not
   add any additional parameters.  The tokens for these algorithms are
   as follows:

   o  iso-kam3-dl-2048-sha256: for the 2048-bit discrete logarithm discrete-logarithm
      setting with the SHA-256 hash function.

   o  iso-kam3-dl-4096-sha512: for the 4096-bit discrete logarithm discrete-logarithm
      setting with the SHA-512 hash function.

   o  iso-kam3-ec-p256-sha256: for the 256-bit prime-field elliptic-
      curve
      elliptic-curve setting with the SHA-256 hash function.

   o  iso-kam3-ec-p521-sha512: for the 521-bit prime-field elliptic-
      curve
      elliptic-curve setting with the SHA-512 hash function.

   For discrete logarithm discrete-logarithm settings, the underlying groups are the 2048-
   bit
   2048-bit and 4096-bit MODP Modular Exponential (MODP) groups defined in
   [RFC3526].  See Appendix A for the exact specifications of for the
   groups and associated parameters.
   The hash functions  Hash function H are is SHA-256 for the
   2048-bit group and SHA-512 for the 4096-bit group, respectively, as
   defined in FIPS PUB 180-2
   [FIPS.180-2.2002]. 180-4 [FIPS.180-4.2015].  The hash iteration
   count nIterPi is 16384.  The representation of the parameters kc1, ks1, vkc, "kc1",
   "ks1", "vkc", and vks "vks" is base64-
   fixed-number. base64-fixed-number.

   For the elliptic-curve settings, the underlying groups are the
   elliptic curves over the prime fields P-256 and P-521, respectively,
   as specified in the appendix Appendix D.1.2 of the FIPS PUB 186-4
   [FIPS.186-4.2013] specification.  The hash functions H, which are
   referenced by the core document, are  Hash function H is SHA-256 for the
   P-256 curve and SHA-512 for the P-521 curve, respectively.  Cofactors
   of these curves are 1.  The hash iteration count nIterPi is 16384.
   The representation of the parameters kc1, ks1, vkc, "kc1", "ks1", "vkc", and vks "vks"
   is hex-fixed-
   number. hex-fixed-number.

   Note: This algorithm is based on the Key Agreement Mechanism 3 (KAM3)
   as defined in Section 6.3 of ISO/IEC 11770-4 [ISO.11770-4.2006] [ISO.11770-4.2006], with
   a few modifications/improvements.  However, implementers should use
   consider this document as the normative reference, normative, because the algorithm has
   been changed in several minor details as well as with of
   the algorithm have changed and major
   improvements. improvements have been made.

3.1.  Support Functions and Notations

   The algorithm definitions use the support functions and notations
   defined below:

   The below.

   Decimal notations are used for integers in the this specification are in decimal by default, or
   default.  Integers in hexadecimal when notations are prefixed with "0x".

   The functions named

   In this document, the octet(), OCTETS(), and INT() functions are those used
   as defined in the core specification [I-D.ietf-httpauth-mutual]. [RFC8120].

   Note: The definition of OCTETS() is different from the function
   GE2OS_x in the original ISO specification, which specification; GE2OS_x takes the shortest
   representation without preceding zeros.

   All of the algorithms defined in this specification use the default
   functions defined in the core specification (defined in Section 11 12.2 of
   [I-D.ietf-httpauth-mutual]) [RFC8120] for computing the
   values pi, VK_c VK_c, and VK_s.

3.2.  Functions for Discrete Logarithm Discrete-Logarithm Settings

   In this section, an equation (x / y mod z) denotes a natural number w
   less than z that satisfies (w * y) mod z = x mod z.

   For the discrete logarithm, we refer to some of the domain parameters
   by using the following symbols:

   o  q: for "the prime" defining the MODP group.

   o  g: for "the generator" associated with the group.

   o  r: for the order of the subgroup generated by g.

   The function J is defined as

      J(pi) = g^(pi) mod q. q

   The value of K_c1 is derived as

      K_c1 = g^(S_c1) mod q, q

   where S_c1 is a random integer within the range [1, r-1] and r is the
   size of the subgroup generated by g.  In addition, S_c1 MUST be
   larger than log(q)/log(g) (so that g^(S_c1) > q).

   The server MUST check the condition 1 < K_c1 < q-1 upon reception.

   Let an intermediate value t_1 be

      t_1 = INT(H(octet(1) | OCTETS(K_c1))),

   the OCTETS(K_c1)))

   The value of K_s1 is derived from J(pi) and K_c1 as: as

      K_s1 = (J(pi) * K_c1^(t_1))^(S_s1) mod q

   where S_s1 is a random number within the range [1, r-1].  The value
   of K_s1 MUST satisfy 1 < K_s1 < q-1.  If this condition is not held,
   the server MUST reject the exchange.  The client MUST check this
   condition upon reception.

   Let an intermediate value t_2 be

      t_2 = INT(H(octet(2) | OCTETS(K_c1) | OCTETS(K_s1))),

   the OCTETS(K_s1)))

   The value z on the client side is derived by the following equation:

      z = K_s1^((S_c1 + t_2) / (S_c1 * t_1 + pi) mod r) mod q. q
   The value z on the server side is derived by the following equation:

      z = (K_c1 * g^(t_2))^(S_s1) mod q. q

   (Note: the The original ISO specification contained a message pair
   containing verification of value z along with the "transcript" of the
   protocol exchange.  This functionality is contained in the functions
   VK_c and VK_s.)

3.3.  Functions for Elliptic-Curve Settings

   For the elliptic-curve setting, settings, we refer to some of the domain
   parameters by the following symbols:

   o  q: for the prime used to define the group.

   o  G: for the point defined with the underlying group called
      "the generator".

   o  h: for the cofactor of the group.

   o  r: for the order of the subgroup generated by G.

   The function P(p) converts a curve point p into an integer
   representing point p, by computing x * 2 + (y mod 2), where (x, y)
   are the coordinates of point p.  P'(z) is the inverse of function P, P;
   that is, it converts an integer z to a point p that satisfies
   P(p) = z.  If such p exists, it is uniquely defined.  Otherwise,
   z does not represent a valid curve point.

   The operator + "+" indicates the elliptic-curve group operation, and
   the operation [x] * p denotes an integer-multiplication of point p:
   it calculates p + p + ... (x times) ... + p.  See the literature on
   elliptic-curve cryptography for the exact algorithms used for those
   functions (e.g. (e.g., Section 3 of [RFC6090], which [RFC6090]; however, note that [RFC6090]
   uses different
   notations, though). notations).  0_E represents the infinity point.  The
   equation (x / y mod z) denotes a natural number w less than z that
   satisfies (w * y) mod z = x mod z.

   The function J is defined as

      J(pi) = [pi] * G. G
   The value of K_c1 is derived as

      K_c1 = P(K_c1'), where K_c1' = [S_c1] * G, G

   where S_c1 is a random number within the range [1, r-1].  The server
   MUST check that (1) the value of received K_c1 represents a valid
   curve point, point and (2) [h] * K_c1' is not equal to 0_E.

   Let an intermediate integer t_1 be

      t_1 = INT(H(octet(1) | OCTETS(K_c1))),

   the OCTETS(K_c1)))

   The value of K_s1 is derived from J(pi) and K_c1' = P'(K_c1) as: as

      K_s1 = P([S_s1] * (J(pi) + [t_1] * K_c1')), K_c1'))

   where S_s1 is a random number within the range [1, r-1].  The value
   of K_s1 MUST represent a valid curve point and satisfy
   [h] * P'(K_s1) <> 0_E.  If this condition is not satisfied, the
   server MUST reject the exchange.  The client MUST check this
   condition upon reception.

   Let an intermediate integer t_2 be

      t_2 = INT(H(octet(2) | OCTETS(K_c1) | OCTETS(K_s1))),

   the OCTETS(K_s1)))

   The value z on the client side is derived by the following equation:

      z = P([(S_c1 + t_2) / (S_c1 * t_1 + pi) mod r] * P'(K_s1)). P'(K_s1))

   The value z on the server side is derived by the following equation:

      z = P([S_s1] * (P'(K_c1) + [t_2] * G)). G))

4.  IANA Considerations

   This document defines four new tokens to be that have been added to the
   "HTTP Mutual
   authentication algorithms" registry; iso-kam3-dl-2048-sha256,
   iso-kam3-dl-4096-sha512, iso-kam3-ec-p256-sha256 and
   iso-kam3-ec-p521-sha512, as follows:

   +-------------------------+-------------------------+---------------+ Authentication Algorithms" registry:

   +-------------------------+-----------------------------+-----------+
   | Token                   | Description                 | Specification Reference |
   +-------------------------+-------------------------+---------------+
   +-------------------------+-----------------------------+-----------+
   | iso-kam3-dl-2048-sha256 | ISO-11770-4 KAM3,           | This document RFC 8121  |
   |                         | 2048-bit DL                 |           |
   |                         |                             |           |
   | iso-kam3-dl-4096-sha512 | ISO-11770-4 KAM3,           | This document RFC 8121  |
   |                         | 4096-bit DL                 |           |
   |                         |                             |           |
   | iso-kam3-ec-p256-sha256 | ISO-11770-4 KAM3,           | This document RFC 8121  |
   |                         | 256-bit EC                  |           |
   |                         |                             |           |
   | iso-kam3-ec-p521-sha512 | ISO-11770-4 KAM3,           | This document RFC 8121  |
   |                         | 521-bit EC                  |           |
   +-------------------------+-------------------------+---------------+
   +-------------------------+-----------------------------+-----------+

5.  Security Considerations

   Please refer to the corresponding Security Considerations section of the core
   specification
   [I-D.ietf-httpauth-mutual] [RFC8120] for algorithm-independent considerations.

5.1.  General Implementation Considerations

   o  During the exchange, the value VK_s, defined in
      [I-D.ietf-httpauth-mutual], [RFC8120], MUST
      only be sent when the server has received a correct (expected)
      value of VK_c.  This is a cryptographic requirement, as stated in
      [ISO.11770-4.2006].

   o  All random numbers used in these algorithms MUST be at least
      cryptographically computationally secure against forward and backward guessing
      attacks.

   o  Computation  To prevent timing-based side-channel attacks, computation times of
      all numerical operations on discrete
      logarithm discrete-logarithm group elements and
      elliptic-curve points MUST be normalized and made independent of
      the exact values, to prevent
      timing-based side-channel attacks. values.

5.2.  Cryptographic Assumptions and Considerations

   The notices notes in this subsection are for those who analyze the security
   of this algorithm, algorithm and those who might want to make a derived work
   from this algorithm specification.

   o  handling  The treatment of an invalid K_s1 value in the exchange has been
      changed from the method defined in the original ISO specification.  The original specification,
      which specifies that the sender should retry with another random
      S_s1 value, while we value.  We specify that the exchange must be rejected.  This
      is due to an observation that this condition is less likely to
      result from the a random error caused by an unlucky choice of S_s1, S_s1 but
      is more likely the result of a systematic failure from caused by an
      invalid J(pi) value (even implying possible denial-of-service
      attacks).

   o  The usual construction of authenticated key exchange algorithms
      consists of a key exchange phase and a key verification phase.
      The latter usually involves some kinds of exchange transaction to
      be verified, to phase.  To
      avoid security risks or vulnerabilities caused by mixing values
      from from two or more key exchanges.  In exchanges, the design latter usually involves some
      kinds of exchange transactions to be verified.  In the algorithms
      defined in this document, such a functionality is
      defined in a generalized manner verification steps are provided in
      the core specification
      [I-D.ietf-httpauth-mutual] (see generalized definitions of VK_c and VK_s). VK_s in [RFC8120].  If the
      algorithm defined above is used in other protocols, this aspect
      MUST be given careful consideration.

   o  The domain parameters chosen and specified in this draft document are
      based on a few assumptions.  In the discrete-logarithm setting,
      q has to be a safe prime ([(q - 1) / 2] must also be prime), and
      r should be the largest possible value [(q - 1) / 2].  In the elliptic-
      curve
      elliptic-curve setting, r has to be prime.  Defining  Implementers defining
      a variation of this algorithm using a different domain parameter
      SHOULD be attentive to these conditions.

6.  References

6.1.  Normative References

   [FIPS.180-2.2002]

   [FIPS.180-4.2015]
              National Institute of Standards and Technology, "Secure
              Hash Standard", Standard (SHS)", FIPS PUB 180-2, 180-4,
              DOI 10.6028/NIST.FIPS.180-4, August 2002, <http://
              csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>. 2015,
              <http://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf>.

   [FIPS.186-4.2013]
              National Institute of Standards and Technology, "Digital
              Signature Standard (DSS)", FIPS PUB 186-4,
              DOI 10.6028/NIST.FIPS.186-4, July 2013, <htt
              p://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>.

   [I-D.ietf-httpauth-mutual]
              Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
              T., and Y. Ioku, "Mutual Authentication Protocol for
              HTTP", draft-ietf-httpauth-mutual-11 (work in progress),
              November 2016.
              <http://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.186-4.pdf>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/
              RFC2119, 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
              Diffie-Hellman groups for Internet Key Exchange (IKE)",
              RFC 3526, DOI 10.17487/RFC3526, May 2003,
              <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

   [IEEE-1363.2_2008]
              IEEE, "IEEE Standard Specifications for Password-Based
              Public-Key Cryptographic Techniques", IEEE 1363.2-2008,
              DOI 10.1109/ieeestd.2009.4773330,
              <http://ieeexplore.ieee.org/servlet/
              opac?punumber=4773328>.

   [ISO.11770-4.2006]
              International Organization for Standardization,
              "Information technology - -- Security techniques - -- Key
              management - -- Part 4: Mechanisms based on weak secrets",
              ISO Standard 11770-4, May 2006. 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
              Curve Cryptography Algorithms", RFC 6090,
              DOI 10.17487/
              RFC6090, 10.17487/RFC6090, February 2011,
              <http://www.rfc-editor.org/info/rfc6090>.

Appendix A.  (Informative) Group Parameters for Algorithms Based on the
             Discrete Logarithm Based
             Algorithms

   The MODP group used for the iso-kam3-dl-2048-sha256 algorithm is
   defined by the following parameters. parameters:

   The prime is: is

      q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
            C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
            83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
            670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
            E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
            DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
            15728E5A 8AACAA68 FFFFFFFF FFFFFFFF. FFFFFFFF

   The generator is: is

      g = 2. 2

   The size of the subgroup generated by g is: is

      r = (q - 1) / 2 =
          0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68
            94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E
            F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122
            F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6
            F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E
            E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF
            C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36
            B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D
            F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964
            EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288
            0AB9472D 45565534 7FFFFFFF FFFFFFFF. FFFFFFFF
   The MODP group used for the iso-kam3-dl-4096-sha512 algorithm is
   defined by the following parameters. parameters:

   The prime is: is

      q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
            C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
            83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
            670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
            E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
            DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
            15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
            ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
            ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
            F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
            BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
            43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
            88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
            2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
            287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
            1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
            93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
            FFFFFFFF FFFFFFFF. FFFFFFFF

   The generator is: is

      g = 2. 2
   The size of the subgroup generated by g is: is

      r = (q - 1) / 2 =
          0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68
            94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E
            F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122
            F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6
            F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E
            E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF
            C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36
            B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D
            F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964
            EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288
            0AB9472D 45556216 D6998B86 82283D19 D42A90D5 EF8E5D32
            767DC282 2C6DF785 457538AB AE83063E D9CB87C2 D370F263
            D5FAD746 6D8499EB 8F464A70 2512B0CE E771E913 0D697735
            F897FD03 6CC50432 6C3B0139 9F643532 290F958C 0BBD9006
            5DF08BAB BD30AEB6 3B84C460 5D6CA371 047127D0 3A72D598
            A1EDADFE 707E8847 25C16890 54908400 8D391E09 53C3F36B
            C438CD08 5EDD2D93 4CE1938C 357A711E 0D4A341A 5B0A85ED
            12C1F4E5 156A2674 6DDDE16D 826F477C 97477E0A 0FDF6553
            143E2CA3 A735E02E CCD94B27 D04861D1 119DD0C3 28ADF3F6
            8FB094B8 67716BD7 DC0DEEBB 10B8240E 68034893 EAD82D54
            C9DA754C 46C7EEE0 C37FDBEE 48536047 A6FA1AE4 9A0318CC
            FFFFFFFF FFFFFFFF. FFFFFFFF

Appendix B.  (Informative) Derived Numerical Values

   This section provides several numerical values for implementing this
   protocol,
   protocol.  These values are derived from the above specifications. specifications provided
   in Section 3.  The values shown in this section are for informative
   purposes only.

   +----------------+---------+---------+---------+---------+----------+
   |                | dl-2048 | dl-4096 | ec-p256 | ec-p521 |          |
   +----------------+---------+---------+---------+---------+----------+
   | Size of K_c1 K_c1,  | 2048    | 4096    | 257     | 522     | (bits)   |
   | etc.           |         |         |         |         |          |
   |                |         |         |         |         |          |
   | hSize, Size size of | 256     | 512     | 256     | 512     | (bits)   |
   | H(...)         |         |         |         |         |          |
   | length                |         |         |         |         |          |
   | Length of      | 256     | 512     | 33      | 66      | (octets) |
   | OCTETS(K_c1) OCTETS(K_c1),  |         |         |         |         |          |
   | etc.           |         |         |         |         |          |
   | length                |         |         |         |         |          |
   | Length of kc1, | 344 * 344*    | 684 * 684*    | 66      | 132     | (octets) |
   | ks1 param.     |         |         |         |         |          |
   | values. values         |         |         |         |         |          |
   | length                |         |         |         |         |          |
   | Length of vkc, | 44 * 44*     | 88 * 88*     | 64      | 128     | (octets) |
   | vks param.     |         |         |         |         |          |
   | values. values         |         |         |         |         |          |
   |                |         |         |         |         | minimum          |
   | Minimum        | 2048    | 4096    | 1       | 1       |          |
   | allowed S_c1   |         |         |         |         |          |
   +----------------+---------+---------+---------+---------+----------+

   (The numbers marked with an * "*" do not include any enclosing
   quotation marks.)

Appendix C.  (Informative) Draft Change Log

C.1.  Changes in Httpauth WG Revision 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

   Yutaka Oiwa
   National Institute of Advanced Industrial Science and Technology
   Information Technology Research Institute
   Tsukuba Central 1
   1-1-1 Umezono
   Tsukuba-shi, Ibaraki
   JP
   Japan
   Email: y.oiwa@aist.go.jp

   Hajime Watanabe
   National Institute of Advanced Industrial Science and Technology
   Information Technology Research Institute
   Tsukuba Central 1
   1-1-1 Umezono
   Tsukuba-shi, Ibaraki
   JP
   Japan
   Email: h-watanabe@aist.go.jp

   Hiromitsu Takagi
   National Institute of Advanced Industrial Science and Technology
   Information Technology Research Institute
   Tsukuba Central 1
   1-1-1 Umezono
   Tsukuba-shi, Ibaraki
   JP
   Japan
   Email: takagi.hiromitsu@aist.go.jp

   Kaoru Maeda
   Lepidum Co. Ltd.
   Village Sasazuka 3, Suite #602
   1-30-3 Sasazuka
   Shibuya-ku, Tokyo
   JP
   Individual Contributor
   Email: maeda@lepidum.co.jp kaorumaeda.ml@gmail.com

   Tatsuya Hayashi
   Lepidum Co. Ltd.
   Village Sasazuka 3, Suite #602
   1-30-3 Sasazuka
   Shibuya-ku, Tokyo
   JP
   Japan
   Email: hayashi@lepidum.co.jp

   Yuichi Ioku
   Individual Contributor
   Email: mutual-work@ioku.org