<<On Thu, 07 Feb 2002 11:33:47 -0500, "James F. Hranicky" <jfhcise.ufl.edu> said:

> After reading up on IPSEC, I have one major question: Is it really
> a good protocol?

No, but it's the best one we've got.

> - IPSEC routers don't seem to be able to advertise routes
> for an arbitrary number of networks behind them

That's an issue with your routing process; it's not related to IPSEC.

> - IPSEC routers have to basically be the border router for
> a site, as there is no post-decryption NAT protocol to
> get packets back to a router on the inside of the network
> (Apparently, Cisco VPN boxes have this capability, but
> it's an add-on to IPSEC AFAICT).

IPSEC is designed to thwart processes which corrupt packet headers
(including NAT).

> - Clients with dynamic IPs are poorly supported.

That's what the `generate_policy' option in racoon is for.

> AFAICT, what I want is to be able to issuce x509 certs to
> any of my remote users for key exchange, and accept any
> cert from any client that was signed by my CA. That's what
> PKI is all about, right? Checking the racoon.conf man pages
> and sample racoon.conf files shows that I need to have the
> client's *private* key for a *specific* IP address.

> o Is this really the case, or am I just wrong here?

You are wrong. There are two distinct models: you can have pre-shared
keys, in which case you have no certificates and a single secret key
for every pair of communicating entities; or you can use public-key
certificates. I have some issues with the way the certificate support
works, that's not one of them. Pre-shared keys are not necesarily
specific to an IP address; you can use any type of identifier
supported in the IKE protocol.

> In the end, if I go with a FreeBSD racoon or isakmpd solution, am I limited
> to the following setups ? :

> - One shared secret for all my users in the interest of manageability.

If you were to use pre-shared keys, and you're concerned about
manageability, there is an obvious mechanism to avoid everyone use the
same key. Let C be a standard representation of each client's
identity, and S likewise for the server. H is a hash function of some
sort; Kp is a key known only to you. Then,

        K = { H(C | S) }
         C,S Kp

gives you a unique key for each pair (C,S) which you can easily derive
at will given C, S, and Kp. Granted, this is not as theoretically
secure as having a unique random bits for every key, but it's better
than having every user know every other user's key.

> I can only assume this means any user could theoretically listen in
> on the key exchange and thus be able to decrypt another's IPSEC
> communications

If you all used the same keys, that is conceivable. More to the
point, any user could impersonate any other user.

-GAWollman

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]