Subject: RE: PRF's and PKINIT: status

From: "Paul Leach" <[email-masked]>
Date: Mon, 27 Sep 2004 20:55:03 -0700

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Monday, September 27, 2004 8:39 PM
> To: Paul Leach
> Cc: Nicolas Williams; Ken Raeburn; Liqiang(Larry) Zhu;
[email-masked]
> Subject: Re: PRF's and PKINIT: status
> 
> >>>>> "Paul" == Paul Leach <[email-masked]> writes:
> 
> I'm explicitly avoiding discussing the pkinit issues until the AES PRF
> is resolved.  I believe I have an answer to the pkinit problem that
> will satisfy the entire working group.  I'll deliver that answer once
> we get done with the AES discussion.
>     Paul> However, lets forget about PRF+ for now. Assume we just need
>     Paul> a 128 bit AES key, so that the output of the AES PRF is
>     Paul> enough without using PRF+.
> 
>     Paul> The problem is with the PRF itself, as I see it. It takes a
>     Paul> key whose length is determined by the krypto suite. How do
>     Paul> we get a hash of k_dh to use as the input of the PRF --
>     Paul> there are no hash functions in kcrypto. And even if we have
>     Paul> a hash, how do we get it to be the appropriate length if it
>     Paul> isn't long enough?
> 
>     Paul> For PKINIT and k_dh, the following would work (ignoring type
>     Paul> safety) given the current AES PRF (or any PRF that is
>     Paul> cryptographically strong):
> 
>     Paul> 	k = PRF(some-128-bit-constant-key, g^xy | n_c | n_k)
> 
>     Paul> That seems weird, however.
> 
> The security of a PRF depends on its key being well chosen.  The AES
> PRF in particular will devolve to sha-1 with a constant key.

[Paul Leach] Maybe the claim that the PRFs for kcrypto must be
cryptographically strong is ambiguous (or underspecified), but I think
that reasonable interpretations of what "cryptographically strong" means
for the PRF can imply that this construction is OK (assuming that g^xy
is kept secret) -- even if it isn't a PRF.

> 
> I don't say that isn't appropriate for key generation, but it is not a
> PRF and the theoretical arguments about PRFs do not apply to it.

[Paul Leach] I think you mean to say that, even though PRF(k, i) is a
PRF, NRF(i), defined as PRF(constant, i), is not. I wasn't claiming that
NRF was a PRF, however -- just that it's OK for key generation if
"enough" of its input is a secret.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 28 Sep 2004 01:01:17 -0700

Ken Raeburn wrote:
> Try this:

>   string-to-key(pass=base64(k_dh), salt="pkinit", opaque=default)

> with "base64" defined as taking an octet string input and producing a
> UTF8 string output by the obvious process.  Could use a hex
representation too, simpler conversion but more > useless bits.

Humm..., Paul and I proposed this solution to Sam in June when he and
Jeff were here at Redmond. Sam did not think we could rely on string2key
to preserve the amount of entropy. Sam might want to elaborate on that.

> If the kcrypto spec is revamped at this point to add this requirement,

> there's no need for this "default"; just update DES and 3DES
> (and in the other draft, AES) random-to-key functions.

Great, this is the right thing to do and the random-to-key functions can
be backward-compatible.

> Changing the function specification, and each of the definitions, 
> at this late stage?  

I do not see anything intrusive. In addition, if the draft does not do
what we want, 
it is never too late to fix it.

> I seriously doubt it.  If I were in the IESG's shoes, 
> I might say, "take the document back, and resubmit it when you're
> *really* done".  And I'd be pretty skeptical if it was resubmitted
soon after.

I would try to explain to the AD about the situation: we finally try to
apply kcrypto in PKINIT, and the current primitives are not sufficient.

I would think this would be the really last time for us taking back the
ID voluntarily and resubmit it. It is worth the trouble and it is the
right thing to do.

> And I'd be pretty skeptical if it was resubmitted soon after.

Can you get a version ready before even talking to the AD? Say in a
week? This way we know we are not risking the publication too further
down the road.

-- Larry

-----Original Message-----
From: Ken Raeburn [mailto:[email-masked]] 
Sent: Tuesday, September 28, 2004 12:44 AM
To: Liqiang(Larry) Zhu
Cc: Paul Leach; Ken Raeburn; [email-masked]
Subject: Re: PRF's and PKINIT: status

On Sep 28, 2004, at 02:47, Liqiang((Larry)) Zhu wrote:

> Ken Raeburn wrote:
>> If this functionality needs to be in kcrypto, well, then I think 
>> we're back to talking about asking the IESG to send it back to
> us.
>
> We need to have this in kcrypto in order to have no dependency on the 
> hashing algrithms being used, and let's just figure out how to handle 
> it.

Try this:

   string-to-key(pass=base64(k_dh), salt="pkinit", opaque=default)

with "base64" defined as taking an octet string input and producing a
UTF8 string output by the obvious process.  Could use a hex
representation too, simpler conversion but more useless bits.

> Some of us recognized AES-PRF need to be fixed, that is great, but IMO

> PRF is not the solution to this problem.

Some believe it, some of us are still not convinced.

> I would suggest to extend the random-to-key() operation to take bits 
> of arbitrary length. We can supply a default implementation if the 
> underlying primitive does not take a seed with length larger than K:
> just SHA1 hash it and truncate the hash output to K bits.  Since this 
> default implementation is applied only to the legacy enctypes (also 
> known as NOT "newer" enctypes), I do not think we are risking anything

If the kcrypto spec is revamped at this point to add this requirement,
there's no need for this "default"; just update DES and 3DES (and in the
other draft, AES) random-to-key functions.

> Can this change be handled with just one additional round-trip to AD. 
> if
> so, we would be happy.

Changing the function specification, and each of the definitions, at
this late stage?  I seriously doubt it.  If I were in the IESG's shoes,
I might say, "take the document back, and resubmit it when you're
*really* done".  And I'd be pretty skeptical if it was resubmitted soon
after.

Ken

---

From: "Paul Leach" <[email-masked]>
Date: Tue, 28 Sep 2004 10:28:52 -0700

OK -- so we can use H.

Let HMAC-H be an HMAC constructed from H as per RFC 2104
	HMAC-H(k, i)
Where k and i are octet-string (i.e., k is not a key in the crypto
system selected).

Let HMAC-H+(k, N, i) be
	truncate(N, HMAC-H(k, 0 | i) | HMAC-H(k, 1 | i)...)

Now, for PKINIT derive the key from k_dh by
	k = random2key(HMAC-H+(k_dh, sizeof(k), n_c | n_k))

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 28 Sep 2004 19:49:12 -0700

Jeffrey Hutzelman wrote:

> The kcrypto document provides the framework for defining enctypes and 
> cksumtypes; it does not provide a full range of 
> cryptographic utilities. 

We have now effectively turned enctypes into something similar to TLS
ciphersuites, this is more self-evident in gssapi-cfx.  The kerberos
protocol can only negotiate at enctype level, and an enctype should be
sufficient to identify all crypto algorithms negotiated.

In that sense, I consider it not acceptable when kcrypto fails to
include an random-to-key() that can take the whole ZZ and produce a key.

But let's put this aside, and try to figure out a solution that we are
all happy with.

> However, PKINIT already provides a means for the client to name a
hash, as part of the paChecksum which is always > 
> performed using an unkeyed hash. 
> Derive the reply key using whatever checksum the client chooses here.

I prefer random-to-key(), if I can not get that, your proposed algorithm
is fine with me. I am also waiting for Sam's solution that he promised.

-- Larry

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Tuesday, September 28, 2004 1:03 PM
To: Liqiang(Larry) Zhu; Nicolas Williams; Jeffrey Altman
Cc: [email-masked]
Subject: RE: PRF's and PKINIT: status

On Tuesday, September 28, 2004 12:33:24 -0700 "Liqiang(Larry) Zhu" 
<[email-masked]> wrote:

> I believe strongly that kcrypto is fatally flawed when it does not 
> include an operation that can take a long bitstring with 
> sparsely-populated entropy.

I probably should stay out of this argument, but...

The lack of a function to take an arbitrary long bitstring and turn it
into a protocol key is _not_ a flaw in kcrypto, fatal or otherwise.  The
kcrypto document provides the framework for defining enctypes and
cksumtypes; it does not provide a full range of cryptographic utilities.
The profile for an enctype includes only those things which are actually
specific to the enctype.  This includes an operation which takes the
_correct_ amount of random data and formats it as a valid key.  This is
the only part of key generation which is dependent on the type of key
being generated.  Coming up with the correct amount of random data is
_not the enctype's problem_.

I am inclined to propose a solution which, if acceptable, should allow
PKINIT to make progress without hacking on kcrypto which is, I believe,
an essentially finished document.

We've already discussed how the right amount of random data can be
generated given a suitable unkeyed hash.  Sam has objected in the past
to requiring a fixed hash without negotiation, and he has also objected
to adding a parameter to the enctype profile to associate a hash with
each enctype.

However, PKINIT already provides a means for the client to name a hash,
as part of the paChecksum which is always performed using an unkeyed
hash. 
Derive the reply key using whatever checksum the client chooses here.

Comments?

-- Jeff