From owner-freebsd-security Thu Feb 7 11:44:41 2002 Delivered-To: freebsd-security@freebsd.org Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by hub.freebsd.org (Postfix) with ESMTP id A31A837B419 for ; Thu, 7 Feb 2002 11:44:26 -0800 (PST) Received: from home.com ([68.61.32.116]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20020207194425.HBMT16300.femail12.sdc1.sfba.home.com@home.com> for ; Thu, 7 Feb 2002 11:44:25 -0800 Message-ID: <3C62D82C.7070507@home.com> Date: Thu, 07 Feb 2002 14:40:28 -0500 From: Dexter Coffin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: security@freebsd.org Subject: Re: Questions (Rants?) About IPSEC References: <20020207163347.51C606B29@mail.cise.ufl.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Here are some thoughts. YMMV. Anyone, please feel free to confirm or denounce my info ... anyway, I HTH ... Please note that all of my IPSec experience comes from COTS products like CheckPoint, Cisco, Nokia, and Nortel. Never used S/WAN or racoon ... James F. Hranicky wrote: > After reading up on IPSEC, I have one major question: Is it really > a good protocol? Yes. Room for improvement abounds, tho. See the end of this reply for some more thoughts. > > It may be that I don't understand it well enough, or that the > implementations I've looked at are lacking in features that I want, > but it seems to me that it simply isn't a good solution for anything > more than a small number of users. Here are the problems I have with > IPSEC: > > - IPSEC routers don't seem to be able to advertise routes > for an arbitrary number of networks behind them > Stuff like OSPF, which uses a multicast address IIRC cannot work through IPSec, a definite shortcoming. The exception is like a Cisco to Cisco that both agree on a non-standard (read: not part of the IPSec standard which, for multicast, there is none) way of doing it. All routes must otherwise be static. > - 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). Cisco's add on also breaks some compatibility with other IPSec devices, like CheckPoint FireWall-1 4.0- IIRC. But, yes, the IPSec gateway does have to function as a router to some degree whether or not it is an actual router. This can be a real PITA if you have lots of incongrous and/or non-sequential networks behind it (like the RFC 1918 private addresses and some poorly chosen public networks that really are private ... if you get my meaning). One could do a one-legged IPSec device and let a router handle routing. ~~~~~~~~~~~~ ~ Internet ~ ~~~~~~~~~~~~ | | <------------------ default route, hopefully w/ FW in between | +---A----+ +-------+ | router B-+-C IPSec | <- outbound route for assigned client addresses +---D----+ | +-------+ or static gateway addresses (& protected | | LANs via remote gateway); device default | | routes to router interface B | | +-------+ | +-| DHCP | <- for inbound IPSec client IP assignment (maybe | +-------+ not a seperate host) | | <------------------ OSPF, BGP, etc. ... maybe FW here, too | ~~~~~~~~~~~~ ~ Private ~ ~ LAN ~ ~~~~~~~~~~~~ ... where interface A = public Internet routable address for all Internet traffic interface B = public Internet routable address for IPSec traffic interface C = public Internet routable address for IPSec traffic interface D = private address for unencrypted traffic and whatever network/pool you use for clients defaut routes from the internal LAN to the IPSec gateway w/ maybe static NAT involved. ... I have to admit that I don't know if one can have dynamic routing on but one router interface. I think you can specify trusted routers for OSPF, etc ... And, of course, don't forget a firewall (or two). > > - Clients with dynamic IPs are poorly supported. True. IPSec is too dependent upon static IPs for gateway to gateway connections (tunnel mode, I believe). Transport mode, the client to gateway stuff, works with DHCP or is supposed to. My experience shows that if a client's DHCP lease expires and they do not get the same IP back, they do have to either renegotiate or reauthenticate depending upon the flexibility of both peers. SSL does a nicer job in this regard ... Best case it (dynamic IPs and IPSec) consumes time and worse case the connection is lost. If I have transport and tunnel swapped please forgive. > > 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? A predefined static IP is required for tunnel (gateway) mode, not transport (client). But you have the PKI thing right. It should be the client's public key, not private, that is exchanged. > > o Isn't requiring the server to have the private cert > key the same as having a shared secret? With a shared secret, it would theoretically be possible to launch a man-in-the-middle attack, because the math for the IPSec would be based partially on a known value. If I can find my Cisco IPSec class notes, I can send the formulas. Something like the remote public key is hashed with the local private key and there's a remainder/mod in there somewhere which is common to both, but never sent over the wire, to which the encryption is based. The authentication is somewhat independent and based off of the common root certifier ... CRLs and whatnot come into play. With shared secret, the secret is hashed and that is the basis for the encrytion *AND* authentication. Also, managing loads of shared secrets is a pain if you have lots of peers. ANX (Automotive Network eXchange, a huge IPSec network of auto manufacturers and suppliers) uses only shared secret at the moment (years after implementation ... but that is another story). > > o If I'm not wrong, and cert's private keys are required per > IP address, is there some problem with the scheme I detailed > above? As a comparison, isn't the whole point of the > ssh_known_hosts file to keep only the public keys on the > remote server? I mean, wouldn't it be great if ssh supported > x509 certs, obviating the need for even the ssh_known_hosts > file, as host keys would be signed by the CA? > > Isn't this what we want for IPSEC??? I think the private key thing in the racoon man page is a typo. Private keys are never shared, nor should ever be shared. > > 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. > > 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 True. Bad form unless it is unavoidable. And, the sharing of the shared secret would need to be done over an OOB trusted media (like heavily encrypted email, trusted phone call, face to face, etc.). Tracking and troubleshooting also become exponetially more difficult in this scenario. Imagine having to change the secret if it is compromised! > > - Different shared secrets for all users/client machines. > > Key management nightmare. Indeed. See note above. > > - Different x509 certs for all users/client machines. > > See above. Well, a good PKI takes care of that. As long as the certs have a common root, everything should be good. That's what I'm doing with an 1100 user base, but all commercial software and hardware. Some combine other authentication methods, like S/Key or smartcards, into the mix. > > - GSSAPI Auth . > > Does this even work? Does it work with w2k clients and an MIT > KDC? If it does, this would probably do what I need for any w2k > boxes out there, but all the info I read said it didn't work > with w2k yet. Never mind any other IPSEC client software. > Beyond me on this one. > Is there another VPN solution (mpd-netgraph+PPTP) that would suit my needs > any better? > > Any enlightenment I can receive that can convince me IPSEC is anything > more than an alpha-quality protocol that requires vendors (a la Cisco) > to fix it would be most appreciated. It's entirely possible I have > no idea what I'm talking about. Well, an okay closed system is from Nokia that's relatively inexpensive. But they are negotiating with CheckPoint and the cost may well rise. > > ---------------------------------------------------------------------- > | Jim Hranicky, Senior SysAdmin UF/CISE Department | > | E314D CSE Building Phone (352) 392-1499 | > | jfh@cise.ufl.edu http://www.cise.ufl.edu/~jfh | > ---------------------------------------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > IMHO, it'd be great if IPSec had SSL's flexibility (NAT is no problem, dynamic IPs are ~usually~ no problem, highly portable, light weight) and SSL had IPSec's robustness (better encryption, (w/ public key) better authentication and integrity, gateway to gateway tunnel-like mode for network to network connectivity). I don't know if SSL handles multicast, but IPSec certainly needs to. As I said at the top, YMMV. HTH!!! :^D -- ( )) >===<--. Dexter Coffin - America's Favorite Ne'er-Do-Well C|~~| | = |-' idnopheq@home.com - http://www.members.home.com/idnopheq `--' `-----' idnopheq@perlmonk.org - http://idnopheq.perlmonk.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message