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

[Russ Housley <[e-mail]>]

Ben:

> On Fri, Aug 23, 2019 at 02:23:14PM -0400, Russ Housley wrote:
>> 
>>>>> ----------------------------------------------------------------------
>>>>> 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!)
>> 
>> In thins case, I do not see a need for a secret salt, but the NIST SP 800-56C API allows for 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.
>> 
>> No, we were not on the same page.  The paragraph below really helps me understand your point.
>> 
>> I few things regarding RFC 2631, RFC 3211, RFC 5912, and RFC 5990 just to make sure we are totally on the same page.
>> 
>> RFC 2631 (Diffie-Hellman Key Agreement Method) and X9.42 use a KDF to compute a KEK from a Diffie-Hellman shared secret and an OtherInfo structure.  RFC 2631 does not call it a KDF, but X9.42 does so.  The API looks a lot like the one for HKDF, except there is no salt.  In fact, the X9.42 KDF could work just fine in with this document.
>> 
>> RFC 3211 (Password-based Encryption for CMS) introduced the KeyDerivationAlgorithmIdentifer, but it does not really offer an API.  It just says that the algorithm is "used to convert the password into a KEK."  It makes PBKDF2, which is specified in RFC 2898, the mandatory to implement algorithm, but I do not think it would be straightforward to specify the use of HKDF for this purpose.  (I am not sure there is a need to do this; PBKDF2 works just fine with modern hash functions.)
>> 
>> RFC 5912 (New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)) introduced the KEY-DERIVATION class.  It does not nail down an API.  It couples the object identifier to a parameter structure for the KeyDerivationAlgorithmIdentifer.  RFC5912 uses PBKDF2 as an example, so there is no doubt that it was intended to support RFC 321.  I do not see anything to prevent the use of the KeyDerivationAlgorithmIdentifer with HDDF, X9.63, and many others.
>> 
>> RFC 5990 (Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)) uses the ALGORITHM class, which is very similar to the KEY-DERIVATION class, for two KDFs, whch are defined in X9.44:
>> 
>>   KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}}
>> 
>> Both of these KDFs would seem to fit well with this document.
> 
> Thanks for laying these out -- I was looking at RFCs 3211 and 5912 when
> doing my review, and agree with your conclusions about 2631 and 5990 as
> well.
> 
>>> 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?
>> 
>> No.
>> 
>>> 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.  
>> 
>> Correct.  There is no place to input the CMSORIforPSKOtherInfo to be input.
>> 
>>> PBKDF2 allows a more-than-8-octet salt, but is that going
>>> to provide the kind of mixing that we need?
>> 
>> Yes, I think it would, but conventions would need to be specified for mapping the IKM and info inputs into the password input.  Simple concatenation would be okay I suspect.  (Again, I am not sure there is a need to do this.)
> 
> (I'm not sure there's a need, either.)
> 
>>> 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.
>> 
>> So, would text in Section 6 that says an acceptable KDF MUST accept IKM, L, and info inputs, and it MAY also accept salt and other inputs.
> 
> I think that addresses the core of my concern, yes, and would be enough to
> resolve the Discuss.  (Technically it doesn't really require that the info
> input gets fully mixed in, but if anyone defines a KDF that does that, they
> probably deserve what they get.)

I will add a sentence that all of the inputs MUST influence the output of the KDF.  I do not want to turn this into a how-to for KDF design...

Russ