Subject: pkinit DH parameter caching

From: Pradeep S <[email-masked]>
Date: Wed, 15 Sep 2004 18:24:44 -0700 (PDT)

Hi all,
I might sound crazy. If I am wrong, help me in
correcting that.

Why is diffie-hellman key caching be choosen by
client?
Is it client specific?
Wont it be better if KDC generates a DH parameter for
a fixed time say 2 hrs (or) 10000 authentication and
for all the clients during that time it uses the same
key. Anyway, when signing this key, KDC can add
expiration time into the message. So, clients do
normal DH negotiation and if KDC needs (and to me its
a better entity to decide than client) when to
generate new key. So, it saves the burden on KDC to
generate DH parameters for every client. Anyway,
client has to generate a new DH parameter every time
and it has to compute the g^ab every time. It involves
same amount of computational complexity as existing
solution.

This question is basically with the assumptions that 
(1) In a typical PKINIT situation, KDC is expected to
generate new DH parameter for the client request? And 
(2)DH parameters are not too bad that it has to be
regenerated too often?

Correct me if I am wrong?

Thanks & Regards
S.Pradeep.

=====
S. Pradeep,
Senior Software Engineer,
Novell, Bangalore.
Ph- (080)5731856/8  Extn 2236
Cell - 98452 57671

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Sep 2004 23:34:54 -0400

I was also coming to the same conclusion as Pradeep.  I believe that
any such KDC will have to defend against small group attacks by
checking to make sure that client parameters are valid.  There will
also be a problem if the KDC ends up with a different generator or
modulus than the client.

I'm also not sure how this interacts with the work Paul, Larry and I
were doing on allowing both parties to get a good key even if both
parties cached their parameters.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 16 Sep 2004 17:46:39 -0400

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