RE: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-03.txt

[Lisa Wilkinson <[e-mail]>]

Stephen,

I would have a couple of questions with this approach:

- as the client is not solely responsible for its private key, how is no 
non repudiation dealt with
- what means of "secure" transmission and storage of private keys does it 
propose
- in case of a compromise of the secure store of private keys, as with 
Kerberos, would all private keys need to revoked, regenerated and 
re-issued.  Does this not lead to administrative and scalability problems?

Lisa
-----Original Message-----
From:	Waters, Stephen [SMTP:[e-mail]]
Sent:	Friday, October 08, 1999 3:30 PM
To:	[e-mail]
Subject:	RE: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-03.txt


Derrell,

I've taken a quick wonder through the GSS documents now. And I have a
questions:

A few weeks/months back, we were debating on the list how public-key could
be used with IKE without the need for PKI (CA/CRL/RA).

One of the suggestions that came out (that I was fond of :) ), was you
provide clients with just their own private key, and the public key of the
server.  The server has its own public/private key, and access to a secure
database containing the clients private keys. This was given the name
'private public-key'. The IKE exchange is standard signature 
authentication,
with off-line cracking protection.


>From what I can tell from GSS and your draft, it is basically the same
model, except that we are talking about adding a new 'thing' everywhere
called GSS-API software.

Cheers, Steve.