From owner-freebsd-security Mon Feb 11 18:31:54 2002 Delivered-To: freebsd-security@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 6951E37B692 for ; Mon, 11 Feb 2002 18:19:34 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 9A180232F8; Mon, 11 Feb 2002 21:18:23 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id BD1C89F159; Mon, 11 Feb 2002 21:12:55 -0500 (EST) Date: Thu, 7 Feb 2002 16:42:13 -0500 (EST) From: Garrett Wollman To: "James F. Hranicky" Cc: security@FreeBSD.ORG Subject: Questions (Rants?) About IPSEC Message-Id: <20020212021255.BD1C89F159@okeeffe.bestweb.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < 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