Subject: RE: pkinit DH parameter caching

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

Sam Hartman wrote:

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

A key handle is an identifier that the KDC can use to index to a table
of keys and locate the session key itself. 

The KDC has to store the key itself in the key table for the duration of
the TGT lifetime. Because the # of active TGTs can be potentially large,
two TGTs might have to share the same session key, to reduce the size of
this key table.

Do we get PFS if we do this?

Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Thursday, September 16, 2004 3:43 PM
To: Liqiang(Larry) Zhu
Cc: Pradeep S; [email-masked]
Subject: Re: pkinit DH parameter caching

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

    Liqiang(Larry)> Sam Hartman wrote:
    >> The fresh signature is desirable to make sure you're talking to
    >> the
    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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 16 Sep 2004 23:07:08 -0400

> Do we get PFS if we do this?

I imagine that depends on where the KDC stores the handle-to-key mappings 
and how they are propagated to other KDC's for that realm.  I'm not sure 
you can have PFS here, since that is at odds with the idea that you should 
be able to reboot a KDC and have the tickets still work.

What you _do_ get, I think, is a gaping hole where one user's TGS requests 
are protected by a key that another user knows.  That would tend to make me 
very nervous.

One possible alternative approach is to keep multiple versions of the TGS 
service key, change it frequently, and delete old keys once any tickets 
issued against them have expired.  This lets you have arbitrary numbers of 
outstanding tickets without the KDC having to keep an unbounded amount of 
state, and you get as much PFS as you are willing to pay for in short 
ticket life.

I think this is functionally equivalent to encrypting the session key and 
having a key handle which tells you in what meta-key the session key is 
encrypted.  The meta-key could safely be shared between TGT's, since 
clients wouldn't know it.  The meta-key then becomes a version of the TGS 
service key, and the "handle" becomes the kvno....

It doesn't seem that the key-handle mechanism is specific to PKINIT; 
there's nothing to say that a KDC that does this can't do it for all TGT's. 
Further, I think it can be done as an implementation-specific extension 
without any changes to the protocol: store a bogus session key in the 
ticket, and add authorization-data which contains the key-handle.

Getting back to your original question...
Modulo the caveats I've already mentioned, yes, I think with PKINIT, DH, 
and the key-handle approach you do indeed get PFS.  But I'm not sure it's 
worth the price, at this level.  I'd be much more interested in getting PFS 
at the application level, say through the use of an extension that allows 
DH negotation of a subsession key during an AP-REQ/AP-REP exchange....

-- Jeff