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

[Markku Savela <[e-mail]>]

> From:	Waters, Stephen [SMTP:[e-mail]]
>
> 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.

As I'm trying to specify a suitable test environment for demonstrating
IPSEC (more than just PING over fixed end points), the above appears
to be fairly close what I have in mind.

But, as I'm still a bit out of my area when public keys and ISAKMP is
involved, there may be some catches that I am not aware of. And to
verify, if I understood all correctly, I present my ideas and
understanding the above here:

 - we have a server host with known fixed IP address (for example,
   SMTP + POP + IMAP, perhaps IRC, WWW or whatever),

 - we want to allow client IPSEC device to connect this server from
   random IP address (e.g. client calls any suitable ISP and uses
   whatever dynamic address it gets)

 - only known users must be able to connect (eg. only company
   employees, or people who have paid for the service)

Would this be achieved with the following setup

 - the organizaion runs own server specific CA setup

 - the server ISAKMP only accepts clients that have their keys signed
   by the server CA directly (e.g. server ISAKMP is configured only to
   accept single CA = self)

 - the access to server is given to client by having their public key
   certified by the servers key (including policy changes for IPSEC on
   the client). That is, client is given 3 pieces of information:
   IPSEC policy changes, servers public key and clients
   server-certified public key.

Is there ISAKMP negotiation mode that can establish a connection from
client to server based on above information? As far as I can see, the
clients IP address should not be needed (the server policy requires
IPSEC for ALL connections by default, except of course having port 500
clear!)

It would seem that certificate revocation would be fairly easy to
manage as the control is all within organization. Revoked certificate
list could be on the server and directly available to the
ISAKMP. Thus, if a client is careless with the private key,
certificates based on it can be quickly revoked.

-- 
Markku Savela ([e-mail]) Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/