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

[Pyda Srisuresh <[e-mail]>]

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 <[e-mail]> wrote:
> > 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/
> 


=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com