[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-03.txt
Sounds like your approach should work. I believe, many vendors use this
type of an approach to get their initial IKE implementations (with
certificate based authentication support) out the door.
cheers,
suresh
--- Markku Savela <msa@anise.tte.vtt.fi> wrote:
> > From: Waters, Stephen [SMTP:Stephen.Waters@cabletron.com]
> >
> > 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 (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland
> Multimedia Systems, P.O.Box 1203,FIN-02044
> VTT,http://www.vtt.fi/tte/staff/msa/
>
=====
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com