Date: Thu, 7 Feb 2002 16:42:13 -0500 (EST) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: "James F. Hranicky" <jfh@cise.ufl.edu> Cc: security@FreeBSD.ORG Subject: Questions (Rants?) About IPSEC Message-ID: <20020212021255.BD1C89F159@okeeffe.bestweb.net>
next in thread | raw e-mail | index | archive | help
<<On Thu, 07 Feb 2002 11:33:47 -0500, "James F. Hranicky" <jfh@cise.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 majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020212021255.BD1C89F159>