Internet DRAFT - draft-moskowitz-hip-new-crypto

draft-moskowitz-hip-new-crypto







HIP                                                         R. Moskowitz
Internet-Draft                                            HTT Consulting
Updates: 7401, 7402 (if approved)                                S. Card
Intended status: Standards Track                         A. Wiethuechter
Expires: 3 February 2022                                   AX Enterprize
                                                           2 August 2021


                  New Cryptographic Algorithms for HIP
                   draft-moskowitz-hip-new-crypto-10

Abstract

   This document provides new cryptographic algorithms to be used with
   HIP.  The Edwards Elliptic Curve and the Keccak sponge functions are
   the main focus.  The HIP parameters and processing instructions
   impacted by these algorithms are defined.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 3 February 2022.

Copyright Notice

   Copyright (c) 2021 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 (https://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.



Moskowitz, et al.        Expires 3 February 2022                [Page 1]

Internet-Draft               HIP New Crypto                  August 2021


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Terminology  . . . . . . . . . . . . . . . .   3
     2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  HIP Parameter values for new Cryptographic Functions  . . . .   4
     3.1.  Elliptic Curves for Diffie-Hellman  . . . . . . . . . . .   4
       3.1.1.  DIFFIE_HELLMAN  . . . . . . . . . . . . . . . . . . .   5
     3.2.  Edward Digital Signature Algorithm for HITs . . . . . . .   5
       3.2.1.  HOST_ID . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.2.  HIT_SUITE_LIST  . . . . . . . . . . . . . . . . . . .   6
     3.3.  Hashing in HIP  . . . . . . . . . . . . . . . . . . . . .   7
       3.3.1.  Hashing with the Sponge Functions . . . . . . . . . .   7
       3.3.2.  RHASH . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.3.3.  HIP_MAC and HIP_MAC2  . . . . . . . . . . . . . . . .   8
     3.4.  HIP Cipher  . . . . . . . . . . . . . . . . . . . . . . .   9
       3.4.1.  HIP_CIPHER  . . . . . . . . . . . . . . . . . . . . .   9
     3.5.  ESP Transform . . . . . . . . . . . . . . . . . . . . . .   9
       3.5.1.  ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . .  10
   4.  Generating a HIT from an HI . . . . . . . . . . . . . . . . .  10
   5.  HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . . .  10
     5.1.  The Keccak KEYMAT . . . . . . . . . . . . . . . . . . . .  11
     5.2.  The Xoodyak KEYMAT  . . . . . . . . . . . . . . . . . . .  11
   6.  Pseudorandom Function (PRF) . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     8.1.  Keymat vulnerabilities  . . . . . . . . . . . . . . . . .  12
     8.2.  KMAC Security as a KDF  . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   This document adds new cryptographic algorithms for HIPv2 [RFC7401]
   and [RFC7402].  This includes:

   *  New elliptic curves for ECDH.

   *  The Edwards Elliptic Curve Digital Signature Algorithm (EdDSA)
      used in Host Identities (HI) and for Base Exchange (BEX)
      signatures.

   *  Hashes used in Host Identity Tag (HIT) generation, and wherever
      else hashes are needed.



Moskowitz, et al.        Expires 3 February 2022                [Page 2]

Internet-Draft               HIP New Crypto                  August 2021


   *  Keyed hashes used for KEYMAT generation and packet MACing
      operations.

   *  AEAD and stream ciphers to use in HIP and HIP enabled secure
      communication protocols.

   The hashes and encryption are all built on the Keccak [Keccak] sponge
   function and the Xoodyak [Xoodyak] lightweight scheme.

   These additions reflect selection of advances in the field of
   cryptography that would best benefit HIP, particularly in constrained
   devices and communications.

   Ed Note: The Xoodyak function calls should be considered the 1st best
   effort.  There are a few areas open for discussion, like which of the
   3 choices for adding in the nonce to the AEAD mode and when to use
   counter and Id.  Also there may be copy errors from the source
   specification, nicer function calls, better acronyms.

2.  Terms and Definitions

2.1.  Requirements 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 BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Definitions

   cSHAKE (The customizable SHAKE function [NIST SP800-185]):
      Extends the SHAKE scheme to allow users to customize their use of
      the function.

   DEC function (Doubly-Extendable Cryptographic function):
      An extendable output function (XOF) that accepts sequences of
      strings as input and that supports incremental queries
      efficiently.

   DECK function (Doubly-Extendable Cryptographic Keyed function):
      A keyed function that takes a sequence of input strings and
      returns a pseudorandom string of arbitrary length and that can be
      computed incrementally.







Moskowitz, et al.        Expires 3 February 2022                [Page 3]

Internet-Draft               HIP New Crypto                  August 2021


   Keccak:
      The family of all sponge functions with a KECCAK-f permutation as
      the underlying function and multi-rate padding as the padding
      rule.  In particular all the functions referenced from [NIST
      FIPS-202] and [NIST SP800-185].

   KMAC (KECCAK Message Authentication Code [NIST SP800-185]):
      A pseduo random function (PRF) and keyed hash function based on
      KECCAK.

   SHAKE (Secure Hash Algorithm KECCAK [NIST FIPS-202]):
      A secure hash that allows for an arbitrary output length.
      SHAKE128 and SHAKE256 are instances of XOFs.  SHAKE is shorthand
      for SHAKE128.

   PRF (Pseudorandom Function):
      A function that takes as input a key and that it is hard to
      distinguish from a random oracle by an adversary that does not
      know the key.

   XHASH (Xoodyak Hash Algorithm):
      A secure hash, based on Xoodyak, that allows for an arbitrary
      output length.  XHASH is an instance of XOF.

   XMAC (Xoodyak Message Authentication Code):
      A keyed hash function similar to KMAC, based on Xoodyak, that
      allows for an arbitrary output length.

   XOF (eXtendable-Output Function [NIST FIPS-202]):
      A function on bit strings (also called messages) in which the
      output can be extended to any desired length.

3.  HIP Parameter values for new Cryptographic Functions

   HIP parameters carry information that is necessary for establishing
   and maintaining a HIP association.  For example, the device's public
   keys as well as the signaling for negotiating ciphers and payload
   handling are encapsulated in HIP parameters.  Additional information,
   meaningful for end hosts or middleboxes, may also be included in HIP
   parameters.  The specification of the HIP parameters and their
   mapping to HIP packets and packet types is flexible to allow HIP
   extensions to define new parameters and new protocol behavior.

3.1.  Elliptic Curves for Diffie-Hellman

   Elliptic curves Curve25519 and Curve448 [RFC7748] are specified here
   for use in the HIP Diffie-Hellman exchange.




Moskowitz, et al.        Expires 3 February 2022                [Page 4]

Internet-Draft               HIP New Crypto                  August 2021


   Curve25519 and Curve448 are already defined in Section 5.2.1 of
   [hip-dex], using the HIP-DEX CKDF.  Here they are defined for using
   the new KMAC [NIST SP800-185] or XMAC [Xoodyak] derived KDF in
   Section 5.

3.1.1.  DIFFIE_HELLMAN

   The DIFFIE_HELLMAN parameter may be included in selected HIP packets
   based on the DH Group ID selected.  The DIFFIE_HELLMAN parameter is
   defined in Section 5.2.7 of [RFC7401].

   The following Elliptic Curves are defined here:

   Group                              KDF              Value

   Curve25519 [RFC7748]               KMAC             13
   Curve448   [RFC7748]               KMAC             14

   A new KDF for KEYMAT, Section 6.5 of [RFC7401] using Keccak or
   Xoodyak is defined in Section 5.

3.2.  Edward Digital Signature Algorithm for HITs

   This section is extracted from Appendix D of [drip-rid].  It may
   later be pulled and only maintained there.

   Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032] are
   specified here for use as Host Identities (HIs) per HIPv2 [RFC7401].
   Further the HIT_SUITE_LIST is specified as used in [RFC7343].

3.2.1.  HOST_ID

   The HOST_ID parameter specifies the public key algorithm, and for
   elliptic curves, a name.  The HOST_ID parameter is defined in
   Section 5.2.19 of [RFC7401].

        Algorithm
        profiles         Values

        EdDSA            13 [RFC8032]

   For hosts that implement EdDSA as the algorithm, the following ECC
   curves are available:








Moskowitz, et al.        Expires 3 February 2022                [Page 5]

Internet-Draft               HIP New Crypto                  August 2021


        Algorithm    Curve            Values

        EdDSA        RESERVED         0
        EdDSA        EdDSA25519       1 [RFC8032]
        EdDSA        EdDSA25519ph     2 [RFC8032]
        EdDSA        EdDSA448         3 [RFC8032]
        EdDSA        EdDSA448ph       4 [RFC8032]

3.2.2.  HIT_SUITE_LIST

   The HIT_SUITE_LIST parameter contains a list of the supported HIT
   suite IDs of the Responder.  Based on the HIT_SUITE_LIST, the
   Initiator can determine which source HIT Suite IDs are supported by
   the Responder.  The HIT_SUITE_LIST parameter is defined in
   Section 5.2.10 of [RFC7401].

   The following HIT Suite ID is defined, and the relationship between
   the four-bit ID value used in the OGA ID field and the eight-bit
   encoding within the HIT_SUITE_LIST ID field is clarified:

        HIT Suite       Four-bit ID    Eight-bit encoding
        RESERVED            0             0x00
        EdDSA/cSHAKE128     5             0x50
        EdDSA/XHASH         6             0x60

   The following table provides more detail on the above HIT Suite
   combinations.  The input for each generation algorithm is the
   encoding of the HI as defined herein.

   The output of cSHAKE128 and XHASH are variable per the needs of a
   specific ORCHID construction.  It is at most 96 bits long and is
   directly used in the ORCHID (without truncation).

     +=======+===========+=========+===========+====================+
     | Index | Hash      | HMAC    | Signature | Description        |
     |       | function  |         | algorithm |                    |
     |       |           |         | family    |                    |
     +=======+===========+=========+===========+====================+
     |     5 | cSHAKE128 | KMAC128 | EdDSA     | EdDSA HI hashed    |
     |       |           |         |           | with cSHAKE128,    |
     |       |           |         |           | output is variable |
     +-------+-----------+---------+-----------+--------------------+
     |     6 | XHASH     | XMAC    | EdDSA     | EdDSA HI hashed    |
     |       |           |         |           | with XMAC, output  |
     |       |           |         |           | is variable        |
     +-------+-----------+---------+-----------+--------------------+

                           Table 1: HIT Suites



Moskowitz, et al.        Expires 3 February 2022                [Page 6]

Internet-Draft               HIP New Crypto                  August 2021


3.3.  Hashing in HIP

   Hashing is used in HIP for HIT generation and keyed hashes of HIP
   payloads.  The hash algorithm used is designated as part of the
   HIT_SUITE_ID.  The keyed hash function is the "common" such function
   used in conjunction with the HIT hash.

3.3.1.  Hashing with the Sponge Functions

   The XOF function in SHA-3, Secure Hash Algorithm Keccak (SHAKE) [NIST
   FIPS-202] and the more recent Xoodyak [Xoodyak] algorithm are called
   sponge functions.  Sponge functions have a special feature in which
   an arbitrary number of output bits are "squeezed" out of the hashing
   state.  This is a significant use change in that hash truncation or
   multiple "runs" for enough bits are not used with sponge functions.

3.3.1.1.  cSHAKE, the customizable SHAKE function

   The customizable SHAKE function (cSHAKE) in [NIST SP800-185] will be
   used as a HIP hash.  As a Keccak XOF, it does not use the truncation
   operation that other hashes need.  The invocation of cSHAKE specifies
   the desired number of bits in the hash output.  Further, cSHAKE has a
   parameter 'S' as a customization bit string.  This parameter will be
   used for including hash specific customization like the ORCHID
   Context Identifier in a standard fashion.

   Hardware implementation of Keccak in VHDL is available from Keccak
   [Keccak] team website.

3.3.1.2.  The Xoodyak Hash

   The Xoodyak [Xoodyak] sponge function is a candidate in the NIST
   Lightweight Cryptography (LWC) Standardization process (see [NISTIR
   8369]).  Xoodyak has been selected here for use in HIP from the LWC
   2nd round candidates as it was developed by the Keccak team, making
   it more directly in line with Keccak.

   Xoodyak has a hash function mode.  More specifically, this hash mode
   is an extendable output function (XOF).

   As the Xoodyak specification [Xoodyak_Spec] does not provide high-
   level function calls, rather a set of primitives to use to construct
   the various modes, the appropriate primitive calls will be detailed
   below.  Xoodyak as a hash will be called here "XHASH".

   To get a n-byte digest of some input x: XHASH(n, x), use the
   following set of Xoodyak primitives:




Moskowitz, et al.        Expires 3 February 2022                [Page 7]

Internet-Draft               HIP New Crypto                  August 2021


        Cyclist(ε,ε,ε)
        Absorb(x)
        Squeeze(n)

   Xoodyak can also naturally implement a DEC function and process a
   sequence of strings.  Here the output depends on the sequence as such
   and not just on the concatenation of the different strings.  To
   compute a n-byte digest, XHASH(n, {x1, x2, x3}) the Xoodyak
   primitives are:

        Cyclist(ε,ε,ε)
        Absorb(x1)
        Absorb(x2)
        Absorb(x3)
        Squeeze(n)

   The equivalent of the parameter 'S' in cSHAKE above can be
   implemented as the last Absorb primitive call in the DEC function.
   That is: XHASH(L, {S, N, X}) is equivalent to cSHAKE(X, L, N, S).

3.3.2.  RHASH

   RHASH is the general term used throughout [RFC7401] to refer to the
   hash used for a specific HIT suite.  For this addendum cSHAKE128 for
   Keccak or XHASH for Xoodyak is used, even for HITs of EdDSA448.

   Unless otherwise specified, L of cSHAKE128 or n of XHASH is 256,
   resulting in a similar output to SHA256.  Any truncation used for,
   older, fixed output hashes is still used.  This is to simplify code
   integration.  One exception to this is in Section 4.

3.3.3.  HIP_MAC and HIP_MAC2

   The HIP_MAC and HIP_MAC2 parameters in [RFC7401] use HMAC [RFC2104].
   This performs two hashes on a string with a key for a keyed hash the
   length of the underlying hash.

   For both HIP_MAC and HIP_MAC2 use, the parameter S below is NULL.  It
   is included for complete function definition.

3.3.3.1.  The Keccak Keyed MAC

   Here, KMAC from NIST SP 800-185 [NIST SP800-185] is used.  This is a
   single pass using the underlying cSHAKE function.  The function call
   is:

        KMAC128(Key, Input String, 256, S)




Moskowitz, et al.        Expires 3 February 2022                [Page 8]

Internet-Draft               HIP New Crypto                  August 2021


3.3.3.2.  The Xoodyak Keyed MAC

   Here, XMAC is defined as the keyed hash function based on Xoodyak.
   It is built with primitives from [Xoodyak_Spec] as a DEC function.

   To get a n-byte keyed MAC of some input x: XMAC(Key, n, {x, S}).
   Where n=256, use the following set of Xoodyak primitives:

        Cyclist(Key,Id,ε)
        Absorb(S)           Only if S is non-null
        Absorb(Input String)
        Squeeze(32)

   Id is "HIP_MAC" and "HIP_MAC2" respectively.  Note since S is null in
   this XMAC usage, the first Absorb call is not performed.

3.4.  HIP Cipher

   HIP encrypted parameters use the HIP_CIPHER, Section 5.2.8 of
   [RFC7401].  The Xoodyak cipher, [Xoodyak], is recommended.  Here
   Xoodyak is used in encrypt only mode.

3.4.1.  HIP_CIPHER

   The HIP_CIPHER parameter value for Xoodyak is:

   hip_cipher
        Suite ID           Value

        Xoodyak            6     (Xoodyak)

   The Xoodyak primitive calls for encrypt only are:

        Cyclist(Key,Id,ε)
        Absorb(IV)
        C ← Encrypt(P)

        Where Id is HIP parameter name (e.g. "ENCRYPTED").
        IV is from the encrypted HIP parameter.
        P is the plain-text per the specific HIP encrypted parameter.
        C is the ciphertext.

3.5.  ESP Transform

   The ESP_TRANSFORM parameter is used during ESP SA establishment,
   Section 5.1.2 of [RFC7402].  The Xoodyak cipher, [Xoodyak], is
   recommended.  Here Xoodyak is used in AEAD mode.




Moskowitz, et al.        Expires 3 February 2022                [Page 9]

Internet-Draft               HIP New Crypto                  August 2021


   Further, it is recommended to use Implicit IV ESP [RFC8750] to match
   its lightweight over-the-air format with the lightweight Xoodyak AEAD
   cipher.

3.5.1.  ESP_TRANSFORM

   The ESP_TRANSFORM Suite IDs for Xoodyak are:

   hip_cipher
        Suite ID           Value

        Xoodyak-96         16     (Xoodyak)
        Xoodyak            17     (Xoodyak)
        Implicit IV        18     [8750]

   The Implicit IV Suite ID is unique in that it is an AND condition
   with ciphers that can use it.  That is AES-GCM and Xoodyak can both
   use 'regular' ESP [RFC4303] or [RFC8750].

   The Xoodyak primitive calls for AEAD encrypt are:

        Cyclist(Key,Id,ε)
        Absorb(IV)
        Absorb(A)
        C ← Encrypt(P)
        T ← Squeeze(t)

   Where Id is "ESP_TRANSFORM".  The IV is either a 32 bit ESP IV per
   [RFC4303] or the ESP Seq Number per[RFC8750].  P is the plain-text
   and A is the associated data.  t is either 12 or 16.  T is the ESP
   ICV of length t.

4.  Generating a HIT from an HI

   The EdDSA/cSHAKE based HITs require a new ORCHID generation method
   than that described in section 3.2 of [RFC7401].  The XOF
   functionality of cSHAKE produces an output of L bits.  This replaces
   the Encode_96 function in the ORCHID generation.

   For identities that are EdDSA public keys, ORCHIDs will be generated
   per the process defined in Appendix C.2.1 of [drip-rid].

5.  HIP KEYMAT Generation

   For either the Keccak or Xoodyak KEYMAT generation, the inputs are
   consistent.  The only practical difference is that cSHAKE allows for
   128 or 256 bits of strength, whereas Xoodyak only provides 128 bits.




Moskowitz, et al.        Expires 3 February 2022               [Page 10]

Internet-Draft               HIP New Crypto                  August 2021


   L is the derived key bit length.  Since 4 HIP keys are "drawn" from
   this output, the length is 4 * HIP_key_size.  Per ASIACRYPT 2017, pp.
   606-637 [ASIACRYPT-2017] each of these derived keys will have the
   same strength as the Diffie-Hellman shared secret.

   S is the byte string 01001011 || 01000100 || 01000110, which
   represents the sequence of characters "K", "D", and "F" in 8-bit
   ASCII.

   Salt and info are derived as defined in sec 6.5 of [RFC7401].  There
   are special security considerations for IKM per [RFC7748].

5.1.  The Keccak KEYMAT

   The KMAC function provides a new, more efficient, key derivation
   function over HKDF [RFC5869].  KMAC as a KDF is defined below.

   The two HIs MUST be used in constructing IKM as follows:

        IKM = Diffie-Hellman secret | sort(HI-I | HI-R)

   The two HIs are separately DER encoded per [RFC7401]

   The choice of KMAC128 or KMAC256 is based on the strength of the
   output key material.  For 256 bits of strength equivalent to HMAC-
   SHA256, use KMAC256.  Per [NIST SP800-56Cr1], Section 4.1, Option 3:

        OKM = KMAC[128|256](salt | info, IKM, L, S)

5.2.  The Xoodyak KEYMAT

   Here, XMAC from Section 3.3.3.2 is used.  The DEC function XMAC("",
   L, {DH, sort(HI-I, HI-R), info, Salt, S}) primitives are:

        Cyclist(ε, ε, ε)
        Absorb(S)
        Absorb(salt)
        Absorb(info)
        Absorb(max(HI-I , HI-R))
        Absorb(min(HI-I , HI-R))
        Absorb(Diffie-Hellman secret)
        Squeeze(L)   Where L is bytes

   Ed Note: Need to check that all above are well defined bytestrings
   per 7401.  I think they are.






Moskowitz, et al.        Expires 3 February 2022               [Page 11]

Internet-Draft               HIP New Crypto                  August 2021


6.  Pseudorandom Function (PRF)

   Appendix B of NIST SP 800-185 [NIST SP800-185] defines how to use
   SHAKE, cSHAKE, or KMAC as a PRF.

   For Xoodyak, XMAC from Section 3.3.3.2 is used in the same manner as
   KMAC above.

7.  IANA Considerations

   IANA will need to make the following changes to the "Host Identity
   Protocol (HIP) Parameters" registries:

   Diffie Hellman:
      This document defines the new Curve25519 and Curve448 for the
      Diffie-Hellman exchange (see Section 3.1.1).

   Host ID:
      This document defines the new EdDSA Host ID (see Section 3.2.1).

   HIT Suite ID:
      This document defines the new HIT Suite of EdDSA/cSHAKE and EdDSA/
      XHASH (see Section 3.2.2).

   HIP Cipher:
      This document defines the new Xoodyak cipher for HIP encrypted
      parameters (see Section 3.4.1).

   ESP Transform:
      This document defines the new Xoodyak cipher and use of [RFC8750]
      for the ESP Transform parameter (see Section 3.5).

8.  Security Considerations

8.1.  Keymat vulnerabilities

   [RFC7748] warns about using Curve25519 and Curve448 in Diffie-Hellman
   for key derivation:

   Designers using these curves should be aware that for each public
   key, there are several publicly computable public keys that are
   equivalent to it, i.e., they produce the same shared secrets.  Thus
   using a public key as an identifier and knowledge of a shared secret
   as proof of ownership (without including the public keys in the key
   derivation) might lead to subtle vulnerabilities.

   Thus the two Host IDs are included with the Diffie-Hellman secret in
   the KEYMAT generation.



Moskowitz, et al.        Expires 3 February 2022               [Page 12]

Internet-Draft               HIP New Crypto                  August 2021


8.2.  KMAC Security as a KDF

   Section 4.1 of NIST SP 800-185 [NIST SP800-185] states:

   "The KECCAK Message Authentication Code (KMAC) algorithm is a PRF and
   keyed hash function based on KECCAK . It provides variable-length
   output"

   That is, the output of KMAC is indistinguishable from a random
   string, regardless of the length of the output.  As such, the output
   of KMAC can be divided into multiple substrings, each with the
   strength of the function (KMAC128 or KMAC256) and provided that a
   long enough key is used, as discussed in Sec. 8.4.1 of SP 800-185.

   For example KMAC128(K, X, 512, S), where K is at least 128 bits, can
   produce 4 128 bit keys each with a strength of 128 bits.  That is a
   single sponge operation is replacing perhaps 5 HMAC-SHA256 operations
   (each 2 SHA256 operations) in HKDF.

9.  Acknowledgments

   Quynh Dang of NIST gave considerable guidance on using Keccak and the
   NIST supporting documents.  Joan Deamen of the Keccak team was
   especially helpful in many aspects of using Keccak and Xoodyak,
   particularly with the KEYMAT section and the strength of the derived
   keys.

   NIST is entering round 3 (final) of its Lightweight Crypto
   Competition with anticipated selection the end of 2021 or early in
   2022.  Events in this process will impact selections in this
   document.

10.  References

10.1.  Normative References

   [NIST FIPS-202]
              Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and
              Extendable-Output Functions", National Institute of
              Standards and Technology report,
              DOI 10.6028/nist.fips.202, July 2015,
              <https://doi.org/10.6028/nist.fips.202>.









Moskowitz, et al.        Expires 3 February 2022               [Page 13]

Internet-Draft               HIP New Crypto                  August 2021


   [NIST SP800-185]
              Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived
              functions: cSHAKE, KMAC, TupleHash and ParallelHash",
              National Institute of Standards and Technology report,
              DOI 10.6028/nist.sp.800-185, December 2016,
              <https://doi.org/10.6028/nist.sp.800-185>.

   [NIST SP800-56Cr1]
              Barker, E., Chen, L., and R. Davis, "Recommendation for
              key-derivation methods in key-establishment schemes",
              National Institute of Standards and Technology report,
              DOI 10.6028/nist.sp.800-56cr1, April 2018,
              <https://doi.org/10.6028/nist.sp.800-56cr1>.

   [NISTIR 8369]
              Sonmez Turan, M., McKay, K., Chang, D., Calik, C.,
              Bassham, L., Kang, J., and J. Kelsey, "Status Report on
              the Second Round of the NIST Lightweight Cryptography
              Standardization Process", National Institute of Standards
              and Technology report, DOI 10.6028/nist.ir.8369, July
              2021, <https://doi.org/10.6028/nist.ir.8369>.

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

   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
              RFC 7401, DOI 10.17487/RFC7401, April 2015,
              <https://www.rfc-editor.org/info/rfc7401>.

   [RFC7402]  Jokela, P., Moskowitz, R., and J. Melen, "Using the
              Encapsulating Security Payload (ESP) Transport Format with
              the Host Identity Protocol (HIP)", RFC 7402,
              DOI 10.17487/RFC7402, April 2015,
              <https://www.rfc-editor.org/info/rfc7402>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [Xoodyak]  Daemen, J., Hoffert, S., Peeters, M., Van Assche, G., and
              R. Van Keer, "The Xoodyak Cipher and Hash",
              <https://keccak.team/xoodyak.html>.






Moskowitz, et al.        Expires 3 February 2022               [Page 14]

Internet-Draft               HIP New Crypto                  August 2021


   [Xoodyak_Spec]
              Daemen, J., Hoffert, S., Peeters, M., Van Assche, G., and
              R. Van Keer, "Xoodoo cookbook", 2019,
              <https://eprint.iacr.org/2018/767.pdf>.

10.2.  Informative References

   [ASIACRYPT-2017]
              Daemen, J., Mennink, B., and G. Van Assche, "Full-State
              Keyed Duplex with Built-In Multi-user Support",
              DOI 10.1007/978-3-319-70697-9_21, Advances in Cryptology -
              ASIACRYPT 2017 pp. 606-637, 2017,
              <https://doi.org/10.1007/978-3-319-70697-9_21>.

   [drip-rid] Moskowitz, R., Card, S. W., Wiethuechter, A., and A.
              Gurtov, "Unmanned Aircraft System Remote Identification
              (UAS RID)", Work in Progress, Internet-Draft, draft-ietf-
              drip-rid-08, 25 July 2021,
              <https://tools.ietf.org/html/draft-ietf-drip-rid-08>.

   [hip-dex]  Moskowitz, R., Hummen, R., and M. Komu, "HIP Diet EXchange
              (DEX)", Work in Progress, Internet-Draft, draft-ietf-hip-
              dex-24, 19 January 2021,
              <https://tools.ietf.org/html/draft-ietf-hip-dex-24>.

   [Keccak]   Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and
              R. Van Keer, "The Keccak Function",
              <https://keccak.team/index.html>.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/info/rfc4303>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.

   [RFC7343]  Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
              Routable Cryptographic Hash Identifiers Version 2
              (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September
              2014, <https://www.rfc-editor.org/info/rfc7343>.




Moskowitz, et al.        Expires 3 February 2022               [Page 15]

Internet-Draft               HIP New Crypto                  August 2021


   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC8750]  Migault, D., Guggemos, T., and Y. Nir, "Implicit
              Initialization Vector (IV) for Counter-Based Ciphers in
              Encapsulating Security Payload (ESP)", RFC 8750,
              DOI 10.17487/RFC8750, March 2020,
              <https://www.rfc-editor.org/info/rfc8750>.

Authors' Addresses

   Robert Moskowitz
   HTT Consulting
   Oak Park, MI 48237
   United States of America

   Email: rgm@labs.htt-consult.com


   Stuart W. Card
   AX Enterprize
   4947 Commercial Drive
   Yorkville, NY 13495
   United States of America

   Email: stu.card@axenterprize.com


   Adam Wiethuechter
   AX Enterprize
   4947 Commercial Drive
   Yorkville, NY 13495
   United States of America

   Email: adam.wiethuechter@axenterprize.com










Moskowitz, et al.        Expires 3 February 2022               [Page 16]