Subject: Re: [Ietf-krb-wg] Standardizing Key Derivation Functions

From: Sam Hartman <[email-masked]>
Date: Fri, 03 Apr 2009 15:26:21 -0400

O, I definitely think using his construction to replace string-to-key for new enctypes would be a good idea
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 06 Apr 2009 16:05:31 +0200

> for new enctypes would be a good idea

Reading Hugo's paper it seems password-based KDF's are barely mentioned,
together with a note that they have different requirements from the
KDF's that Hugo discuss.  So I'm not sure you can use Hugo's KDF for
passwords directly.  But I haven't seen any I-D yet, so I don't know for
sure.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Apr 2009 09:54:05 -0500

On Mon, Mar 30, 2009 at 11:14:45PM -0400, Sam Hartman wrote:
> >>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
> 
>     Simon> The presentation below at SAAG is relevant to the krb5-prf
>     Simon> discussion.  I propose that any future Kerberos enctypes
>     Simon> specify a "pseudo-random" (in RFC 3961 terminology)
>     Simon> function based on Hugo's ideas rather than 1) re-use the
>     Simon> RFC 3961 pseudo-random function, or 2) use the mit-prf.
> 
> I object to this because Hugo's construction is based on a hash rather
> than a block cipher.  There are a lot of contexts where this makes
> sense, but I don't think Kerberos is one of them.  I think it would be
> fine to ask Hugo to review what we're doing.

I agree that future enctypes may well want to use different KDFs
(perhaps because they'll have no hash function).  Enctypes that fit into
the RFC3961 cryptographic profile should use this KDF, but most likely
we'll have new enctypes -AEAD ones- that do not fit the RFC3961
cryptographic profile.

However, it would have been nice to have had this Hugo's paper and
presentation when we worked on GSS_Pseudo_random() -- we're missing a
step in RFC4402, the entropy extraction step.  In practice no one will
be using GSS_Pseudo_random() to generate very long octet strings, so
this is unlikely to be a problem.

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 6 Apr 2009 12:44:17 -0400

> we'll have new enctypes -AEAD ones- that do not fit the RFC3961

You mean the so-called "simplified profile"?  The general profiles for  
encryption and checksum are defined (more or less) by what Kerberos  
needs, so future enctypes that don't fit that (or some rfc3961bis)  
would be a problem for us to use.  But yes, if the simplified profile  
is used, there's a hash function already provided.  We can contemplate  
whether a given hash function has the necessary properties, but in  
both triple-DES and AES cases, we're using the same SHA1 hash that  
Hugo recommends in his paper.

For future cryptosystems based on AEAD modes of block ciphers, I do  
think it would be desirable to build it all on the block cipher, but  
we have to be very careful about the properties we need for the key  
derivation and krb5-prf operations.

> this is unlikely to be a problem.

It seems to me that (aside from the bit Simon points out, where in  
section 9 Hugo describes differences in requirements for password- 
based key generation) the "protocol key" we discuss in RFC 3961 would  
be the "pseudorandom key" in Hugo's paper, the result of the "extract"  
operation, not the "source key material".  At least, if we intend that  
the protocol key be uniformly random (an assumption supported by the  
specification of random-to-key) and of suitable size (not so clear --  
in Hugo's paper this would usually be an HMAC output, not an AES key).

Hugo says on page 2, "It is illustrative to note that when SKM is  
already a good key (as it is the case of some KDF applications, e.g.,  
SKM is output by a strong RNG), the XtX scheme can skip the first  
stage and use SKM directly as the PRF key."  That probably holds in  
general for session keys, subsession keys, and service keys when  
machine-generated.

We should still be concerned about a user's password-derived long-term  
key, in this analysis.  From skimming the paragraph Hugo writes in his  
paper, I think maybe our use of PKCS#5 for AES is adequate for an  
extractor (though I'd be happier with the randomized-salt approach  
I've suggested before), but I'd want to look into it further.  (Or,  
better, ask a real cryptographer like Hugo to take a look.)  I  
wouldn't suggest trying to use the precise KDF proposed by Hugo  
directly for a string-to-key function for passwords, for the reasons  
he gives; that doesn't necessarily invalidate the extract-then-expand  
approach.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Apr 2009 12:33:25 -0500

On Mon, Apr 06, 2009 at 12:44:17PM -0400, Ken Raeburn wrote:
> ...

Yes.

> derivation and krb5-prf operations.

Agreed.

> in Hugo's paper this would usually be an HMAC output, not an AES key).

Ah, so effectively, from the p.o.v. of this paper the entropy extraction
process has already happened.  Good, thanks for pointing that out.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Apr 2009 12:41:56 -0500

> for new enctypes would be a good idea

Building a new PBKDF atop a generic KDF seems like a good idea, but
outright replacement of a PBKDF with a generic KDF is not since PBKDF
adds that all-important iteration count -- generic KDFs should, I think,
not have such a feature.

But still, it would be nice to have a generic PBKDF construction based
on a generic KDF.

Nico