Subject: RE: PRF's and PKINIT: status

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

We have two choices here: delaying kcrypto or delaying PKINIT. I would
prefer the former. I do not understand what we gain by having an
incomplete kcrypto published at all cost.

It makes me feel we will never get PKINIT done if we are going to have a
second version of kcrypto on which PKINIT will depend.

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 prefer to extend random-to-key to take bitstring of arbitrary length,
and make the new definition to be backward-compatible.  With that, the
reply key k can simply be random-to-key(ZZ | n_c | n_k).

I do not understand Nico's comment about the uniform distribution of
entropy.  According to RFC 3766, you will only have 256 bits of attack
resistance strength when you use a modulus of 14k bits, which implies to
me the density of the secrecy is pretty low, but the secrecy might have
been distributed uniformly after all.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Tuesday, September 28, 2004 11:41 AM
To: Jeffrey Altman
Cc: [email-masked]
Subject: Re: PRF's and PKINIT: status

On Tue, Sep 28, 2004 at 02:30:13PM -0400, Jeffrey Altman wrote:
> Here is what I propose for the IETF process part of this discussion.
> I really hope there are no disagreements:
> 
> The current kcrypto document remains in the RFC Editors queue and is 
> published as is.
> 
> For the purposes of changing the PRF description text and adding 
> whatever new functionality the working group believes is needed for 
> PK-INIT and Extensions will be done in a revised Kcrypto document 
> which will be recycled at "Proposed Standard".

If there any any references to analysis of the kcrypto PRF construction,
these could be added as informative in author's 48.  Otherwise I agree,
make no changes to kcrypto now, please.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 28 Sep 2004 15:46:05 -0400

> sparsely-populated entropy.

Larry:

You can submit kcrypto2 at exactly the same time you submit pkinit.
Directions for successful completion:

(1) Take the existing approved kcrypto draft and modify it to suit the
     needs of pkinit
(2) Publish kcrypto2 as an internet-draft.  Jhutz will approve it as a
     working group item.
(3) Modify current pkinit draft using the new operations you added to
     kcrypto2
(4) Publish the revised pkinit draft
(5) The working group issues last calls on both pk-init and kcrypto2
(6) The IETF issues last calls on both pk-init and kcrypto2
(7) The IESG hopefully approves the drafts
(8) The RFC-Editor publishes new RFCS.  Kcrypto2 replaces Kcrypto.

The only difference between this and what you want to do is that
there is no step zero of recalling the existing Kcrypto draft upon
which Kerberos Clarifications is dependent.  If you pull back Kcrypto
you must pull back Clarifications as well.

There is no time saved by pulling Kcrypto and Clarifications at this
point.  All that is going to happen is that you are going to get the
IESG and RFC Editor angry with us.  We will have lost face and the
IESG will be less likely to work with undo haste to approve our
future work.

Jeffrey Altman

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 28 Sep 2004 15:50:36 -0400

On Sep 28, 2004, at 15:33, Liqiang(Larry) Zhu wrote:
> We have two choices here: delaying kcrypto or delaying PKINIT.

I don't agree with that list of options.

PKINIT needs work to deal with crypto stuff.  That's true whether 
kcrypto is changed to add the stuff you want or not.  I see no 
additional delay in doing the work in PKINIT.

>  I would

Still not convinced it's incomplete, or that a second version is needed.

> reply key k can simply be random-to-key(ZZ | n_c | n_k).

Why do you refuse to address the matter on the PKINIT side?  For one 
thing, the "sparsely-populated entropy" could be dealt with in a way 
specific to the structure of the bit string available.  Or, currently, 
PKINIT already specifies sha1 in a couple places, so why not just build 
a PRF+ on it?

Ken

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 28 Sep 2004 16:02:44 -0400

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 28 Sep 2004 15:12:04 -0500

> incomplete kcrypto published at all cost.

For the record, that's your opinion.  I do not share it and I doubt the
WG as a whole shares it.

Kcrypto is *not* broken.  At worst it's incomplete -- missing a KDF.

Ken gives a KDF construction for PKINIT that does not require any
revisions to kcrypto, and I'm inclined to agree that PKINIT can specify
a KDF without having to have kcrypto specify one.

> sparsely-populated entropy.

"Fatally flawed?"  Those are very strong words.  So far you're the only
one saying that.

> been distributed uniformly after all.

The strength of modular DH is not related to the amount of entropy in
g^xy mod p but to attacks on the discrete logarithm problem; ECDH is
stronger in this respect so that ECDH groups are smaller for a given
measure of strength than comparable DH groups.  This has nothing to do
with whether or not truncation of g^xy mod p is safe or not.  That has
to do with whether or not the truncated result is as hard to compute as
the whole (which is now established) and whether the truncated result
has similar distribution as the whole (which may not be established).

None of which has anything to do with whether kcrypto is "fatally
flawed" -- it isn't, the WG didn't think it was, the ADs didn't think it
was nor did the IESG or the IETF as a whole, and it still isn't flawed;
at worst it's missing a KDF.

Nico
--