[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-03.txt
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:Stephen.Waters@cabletron.com]
Sent: Friday, October 08, 1999 3:30 PM
To: ipsec@lists.tislabs.com
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.
Follow-Ups: