Subject: RE: PRF's and PKINIT: status

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 27 Sep 2004 23:47:18 -0700

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.

Some of us recognized AES-PRF need to be fixed, that is great, but IMO
PRF is not the solution to this problem.

Nico proposed the bitstring2key() operation, I like it the best, but it
is a new operation, it might not serve our best interest at this stage.

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
by doing so.  We need to make sure we have good random-to-key functions
for AES and "newer enctypes" that can take a seed of arbitrary length.
A possible good one that is also backward compatible could be:

   random-to-key (bitstring[L])-> if L == K, identify-function
                                  else K-truncate(SHA1(0x00 | bitstring)
|  SHA1(0x01 | bitstring) | ...)

Note that L >= K

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

-- Larry
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ken Raeburn
Sent: Monday, September 27, 2004 10:54 PM
To: Paul Leach
Cc: <[email-masked]>
Subject: Re: PRF's and PKINIT: status

On Sep 27, 2004, at 23:01, Paul Leach wrote:
> However, lets forget about PRF+ for now. Assume we just need a 128 bit

> AES key, so that the output of the AES PRF is enough without using
> PRF+.

Okay, I think this is where one problem starts.

The PRF in the AES specification (rather, the simplified-profile-based
specification) is for generating pseudo-random data suitable for key
generation given an existing AES key.  The combine-keys operation
discussed some time back is one case where it might be desirable;
generating secondary encryption keys for use related to an existing
authentication context is another.

Put another way, the association of a PRF definition in the Kerberos
crypto framework with a particular encryption system has to do only with
the type of secret (not published!) key you're feeding it; it has
nothing to do with the kind of key you want to generate.  That's what
random-to-key is for.  If you don't already have a key, the only
operations you can use out of kcrypto are string-to-key, which takes a
UTF-8 input, or random-to-key, which takes a fixed-size input -- and if
your input is not of that size, it's your problem.

For getting a Kerberos key out of PKINIT, you need to come up with a
random bit string of the appropriate length.  For this, yes, a
pseudo-random function is desirable.  But not the one in the Kerberos
crypto profile.  That's not how it was designed to be used (insofar as
it can be said to have been designed).  Perhaps that means we did it
wrong, or solved the wrong problem, and what we did is useless.  We
thought we had some uses for it in that form.

You need a PRF, or a PRF+ construction, and for this usage, kcrypto
doesn't help you.

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.

> The problem is with the PRF itself, as I see it. It takes a key whose 
> length is determined by the krypto suite. How do we get a hash of k_dh

> to use as the input of the PRF -- there are no hash functions in 
> kcrypto. And even if we have a hash, how do we get it to be the 
> appropriate length if it isn't long enough?

These, and the general problem of taking a long bit string and boiling
it down -- or expanding it -- to the right size, are outside the scope
of kcrypto.

"no hash functions in kcrypto" -- we do have two unkeyed checksum types,
and I'm supposed to be writing up SHA1 for PKINIT.  But I suspect what
you mean is that we have no way of saying "I need to generate this key
type with so many bits, give me a hash function to use"?  And which is
it, key type or number of bits?  Should 128-bit and 256-bit AES use
different hash functions?  What about 3DES?

> For PKINIT and k_dh, the following would work (ignoring type safety) 
> given the current AES PRF (or any PRF that is cryptographically
> strong):
>
> 	k = PRF(some-128-bit-constant-key, g^xy | n_c | n_k)
>
> That seems weird, however.
>
> IMO, it would be better if PRFs took arbitrary length keys.

I think these "arbitrary length keys" are not the same "keys" as the
encryption-system-specific things we talk about in kcrypto.  If the PRFs
in kcrypto took arbitrary length secret inputs instead of cryptosystem
keys, then they would be PRFs, but they would not be associated with the
cryptosystems.

> E.g., for the AES PRF:
> 	PRF(k, i) {
> 		kt = SHA1(k)
> 		t = SHA1(i)
> 		return (E(kt, t, zero-IV)
> 	}
>
> Then for PKINIT and k_dh, we'd have
> 	k = PRF(k_dh, n_c | n_k)
> which seems intuitively just right -- k_dh ought to be the key for the

> PRF.
>
> Even better would be the following PRF for AES (and everything else 
> with key length less that 160 bits):
>
> 	PRF(k, i) == HMAC-SHA1(k, i)
>
> Or, if SHA1 is too weak, then HMAC-SHA256 for keys up to 256 bits,
> HMAC-SHA512 for larger keys.

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 28 Sep 2004 03:43:46 -0400

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

> PRF is not the solution to this problem.

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

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

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: Jeffrey Altman <[email-masked]>
Date: Tue, 28 Sep 2004 07:22:59 -0400

Ken Raeburn wrote:

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

Personally I would be very unhappy to see any of our existing documents 
be pulled back from the IESG
at this late date.  We have a fairly poor track record so far with 
allowing documents to complete their
cycle.  No matter how many times we think we are done we have always 
found "just one more small
change" that needs to be made.  At some point we lose credibility.

At the moment we have kcrypto, aes kcrypto, gss-cfx in the RFC Editor's 
queue and Clarifications
which is dependent on kcrypto being evaluated by the IESG.  As far as I 
am concerned pulling back
kcrypto at this late stage is out of the question.  I see two possible 
directions the working group
can choose to follow:

(1) create a new document containing extensions to kcrypto which will be 
a dependency for pk-init
      and which will be merged into the next revision of kcrypto at a 
later date

(2) start work on kcrypto2 now and make that the basis for extensions, 
pk-init, etc. 

Option (1) has the benefit of being a path of least resistence for the 
publication of pk-init.
Option (2) has the benefit that it will need to be done before 
extensions is published anyway.

There will be no harm done in the eyes of the IESG if we are working on 
an improved document
even while the RFC editor is publishing the existing ones.  It happens 
all the time and is in
fact a good thing.

Jeffrey Altman