Subject: RE: PKINIT review comments

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 4 Jan 2006 12:43:31 -0800

Sam Hartman wrote: 

> That may be problematic for Larry.  If so, then we add a sett of
client preferences in the future. 

 Yes, this would be difficult. Let's leave it as is now given the signed
structure we have is extensible.

> The ideal way of handling this is to add an algorithm ID at least now.

Can we just re-use the algorithm ID of the paChecksum, is there a reason
why the KDF would use a different digest algorithm than that of the
paChecksum?

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Wednesday, January 04, 2006 11:35 AM
To: Jeffrey Hutzelman
Cc: [email-masked]
Subject: Re: PKINIT review comments

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> * As currently defined, paChecksum is REQUIRED to be
    Jeffrey> SHA-1.  I see no mechanism for indicating what algorithm
    Jeffrey> is in use, and no mechanism for a KDC to indicate that a
    Jeffrey> client has used an algorithm which it does not support or
    Jeffrey> is configured not to accept.  At a minimum, it needs to
    Jeffrey> be possible to modify the protocol in the future to allow
    Jeffrey> for algorithm agility in a backward-compatible fashion.
    Jeffrey> Ideally, we should be specifying a way to use SHA-256
    Jeffrey> today.

I think the intent is that we add a new field to the sequence and make
sure that current implementations will return a well-defined error if
the current checksum is not used.

Of course, it's not optional so this doesn't actually work.

We need to choose some solution that actually works for Larry based on
his current implementation time constraints.

    Jeffrey> * An error KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED is defined to
    Jeffrey> be returned "If the hash algorithm used in the key
    Jeffrey> derivation function is not acceptable by the KDC".
    Jeffrey> However, the only algorithm currently defined is SHA-1,
    Jeffrey> and there is no mechanism defined for negotiating an
    Jeffrey> algorithm to use or indicating which algorithm is in use
    Jeffrey> -- if the KDC and client do not magically use the same
    Jeffrey> algorithm, they will simply compute different reply keys
    Jeffrey> and the exchange will mysteriously fail.

The ideal way of handling this is to add an algorithm ID at least now.
That may be problematic for Larry.  If so, then we add a sett of client
preferences in the future.  If the KDC understands the set of client
preferences (that is new enough that it knows what to do with that extra
field) then it includes an extra field describing what it picked.  Both
the preferences and the value picked by the KDC need to be signed.

I do agree the error seems useless.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Jan 2006 15:51:22 -0500

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

    >> The ideal way of handling this is to add an algorithm ID at

    Liqiang(Larry)> Can we just re-use the algorithm ID of the
    Liqiang(Larry)> paChecksum, is there a reason why the KDF would
    Liqiang(Larry)> use a different digest algorithm than that of the
    Liqiang(Larry)> paChecksum?

Well, two problems.  First, and not really important is that
pachecksum doesn't have an algorithm ID.  But we agree it will
eventually get one.

But secondly, I actually do expect that long term the KDF will be more
complex than just a hash function.  Take a look at the NIST KDF
document; that involves more than just hashing the key material.  So
you need a different ID.