Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT)

[Russ Housley <[e-mail]>]

Ben:

Thanks for doing all of the reading necessary to raise this question.

I want to respond to the DISCUSS in this note.  I'll tackle the non-blocking comments is a separate message.

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I think we need to have a discussion about the abstract API for a
> KEY-DERIVATION instance and how that relates to what we need for a key
> combination operation.  In Section 5 we assume that we can use the
> HKDF terminology, but that doesn't seem to hold universally for
> KEY-DERIVATION; for example, while HKDF has IKM, salt, and info, PBKDF2
> (from RFC 3211 that AFAICT introduces keyDerivationalgorithm for CMS) is
> specified by RFC 2898 as taking just the input secret (password) and a
> salt, with no separate 'info' (and of course the different iteration
> count and PRF parameters needed for its construction).  I note (with
> chagrin, as sponsoring AD) that RFC 8619 says "PARAMS ARE absent" for
> the HKDF-based KEY-DERIVATION instances but is silent about how one is
> supposed to know what to pass for salt/info (the IKM we can perhaps
> assume will be obvious).
> 
> In short, should we be seeking to define a distinct key combination
> operation like KRB-FX-CF2 (RFC6113) rather than trying to repurpose key
> derivation?  Some KDFs support this fairly well, but it's not clear to
> me that it is a universal property.  For example, the proof in [H2019]
> seems to be assuming HKDF but this draft does not (as is clearly seen
> from the use of the X9.63 KDF in one of the examples).

NIST SP 800-56 Revision 1 offers this high-level interface to the KDF:

   KDF(Z, OtherInput)

  - Z: a byte string that represents the shared secret.  This ic called IKM in the HKDF terminology.

  - OtherInput includes:

   -- salt - a non-null (secret  or non-secret) byte string.
   
   -- L - a  positive  integer  that  indicates  the  length  (in  bits)  of  the  secret  keying  material to be derived.

   -- FixedInfo - a bit string of context-specific data that is appropriate for the relying key-establishment scheme.

I do not think that this very high level of API really solves your concern, but it did guide my thinking in writing the document.

The KDF algorithm identifier has this structure:

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

The algorithm part lets us name many different KDFs.  As you point out, the examples in Appendix A and Appendix B use HKDF and X9.63 KDF.

Recent discussions in the LAMPS WG show a big bias against complex parameter strictures.  Instead, people have voiced a strong preference for an object identifier that names all of the options.  This leads to more object identifier assignments, but clear understanding of all options when one is chosen or negotiated.  The one exception is an initialization vector, where a fresh value is expected each time the algorithm is invoked.

So, in this document, I have defined a structure of the OtherInput portion of the NIST API.  If a particular KDF needs to use a value from that structure in a particular way, is can do so.  The document uses HKDF terminology.

If a KDF requires a salt, then it should be provided as a parameter.  I can certainly add that to the document.  I believe that KMAC128 and KMAC256 are algorithms that require a salt.

Russ