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

[Benjamin Kaduk <[e-mail]>]

Hi Russ,

On Fri, Aug 16, 2019 at 02:09:03PM -0400, Russ Housley wrote:
> 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.

Sorry that I did not more effectively make use of the extra lead time you
gave me.

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

It is helpful to see this and understand the origin of what's in the
document.  (Also that the salt is listed as "secret or non-secret" here, as
in at least one other place I looked at during my background reading I saw
it listed as "not-secret", which would be problematic when we want to put a
secret key in it!)

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

Agreed.

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

Okay, but I'm not sure we've really gotten onto the same page.

I think my main question is whether we're comfortable using a KDF
abstraction like the above (KDF(secret, otherInput)) in a fully general
sense, and asking for this mix-with-psk to work properly for all possible
KDFs.  For example, would you be comfortable using the construction in this
document with PBKDF1 as the KDF?  I don't even see where we could slot in
the PSK from this document into PBKDF1 -- the API just doesn't seem to be
flexible enough.  PBKDF2 allows a more-than-8-octet salt, but is that going
to provide the kind of mixing that we need?

I just don't know if all KDFs are going to guarantee the contributory
behavior from the otherInput that we need in order for this scheme to work.

-Ben