Subject: RE: pkinit DH parameter caching

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 16 Sep 2004 15:21:44 -0700

Sam Hartman wrote:

> The fresh signature is desirable to make sure you're talking to the
real KDC.

Allowing the KDC to insert a nonce would ensure the derived key is
always fresh.

This is because we do not seem to have a way to cache the DH domain
parameters but use a fresh x each time.

another point Sam brought up during off-line discussion is that the
session key can be discovered from the TGT (say by virtual of stolen KDC
master secrets), this defeats PFS, I think we should allow the KDC to
place a key handle in the TGT, not the key itself, when DH is chosen.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Thursday, September 16, 2004 2:47 PM
To: Pradeep S
Cc: [email-masked]
Subject: Re: pkinit DH parameter caching

I am working on a longer note describing some discussions I've had with
Paul and including a specific proposal.  I do believe I have answers to
your questions independent of that note though.

It is desirable for the client to be able to force the KDC to use fresh
DH parameters (or at least a fresh DH signature).  In fact the current
protocol requires this by having a client nonce in the KDC reply.  The
fresh signature is desirable to make sure you're talking to the real
KDC.

So you need at least some client support to say that a cached signature
is acceptable.

You want the client to enforce the expiration of the KDC signature
because that's the only point where the signature expiration can be
enforced.  An attacker may replay an old signed message from the KDC so
the message needs to include a time past which it should be considered
old.  Clients should check this time.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 16 Sep 2004 18:43:29 -0400

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

    >> The fresh signature is desirable to make sure you're talking to
    Liqiang(Larry)> real KDC.

    Liqiang(Larry)> This is because we do not seem to have a way to
    Liqiang(Larry)> cache the DH domain parameters but use a fresh x
    Liqiang(Larry)> each time.

I'm assuming the KDC always caches the DH domain parameters.  I
believe the performance problem we're solving is avoiding using a
fresh x.

The way the document is currently specified we use group 1 or 2 from
IPSec.  That will clearly need to change before it goes to the IESG,
but it seems like the protocol assumes a small number of groups.

    Liqiang(Larry)> another point Sam brought up during off-line
    Liqiang(Larry)> discussion is that the session key can be
    Liqiang(Larry)> discovered from the TGT (say by virtual of stolen
    Liqiang(Larry)> KDC master secrets), this defeats PFS, I think we
    Liqiang(Larry)> should allow the KDC to place a key handle in the
    Liqiang(Larry)> TGT, not the key itself, when DH is chosen.

I'm  confused by this concept of a key handle.