Re: [Design] Re: [Users] Making FreeS/WAN harder to use, INTENTIONALLY.

At present, most people get by with exposing all their traffic to in-transit monitoring, or by encrypting selected connections at the fourth protocol layer, e.g. TLS or ssh. A political goal of the FreeS/WAN project is to change this attitude into "if the peer is capable of encryption, we should do it". For the hoi polloi to buy into that goal, it mustn't cost them too much in sysadmin effort. Specifically:

FreeS/WAN grew up on the Security Gateway model, where packets leaving the departmental subnet have to pass through one router running FreeS/WAN. My department uses purchased dedicated routers (under shared administration with several other departments), and while our vendor would be happy to sell us an IPSEC upgrade, we (and our friends) cannot justify that expense as an operational necessity, nor the political wrangling necessary to get a Security Gateway set up.

On the other hand, I have set up a machine in our DMZ running FreeS/WAN, which does NAT on the DMZ interface so answer packets will return to the IPSEC gateway, not to the peer in plain text. It uses X.509 certificates to authenticate the clients. That's easily justified, and not too hard to set up.

Many of our users, myself included, would like a secure channel from home, but we have NAT boxes. Various issues prevent FreeS/WAN from working in this case, a major one being that the IP addresses of different clients could be the same, typically 192.168.0.1. The Cisco VPN-5000 product works through NAT if you give it a command-line switch. If FreeS/WAN could be made to work through NAT, the number of potential clients could be increased greatly.

The Cisco VPN-5000 product appears to do SASL to authenticate the user, not the machine (which could be stolen). Not to wax too positive on the degree of security of some authentication methods useable from SASL, but SASL-type authentication is a lot easier to administer, particularly authenticator
(password) changes, then RSA host keys, particularly if the IP address (for
opportunistic encryption) is issued by your ISP. Also (to echo part of what someone else said), trust is dubious in the host key obtained from somewhere for opportunistic encryption. When the partners are effectively anonymous, it would seem (to me) much less hassle, and equally secure, to use Diffie-Hellman key exchange.

Users would really like to turn on FreeS/WAN at boot time and have it encrypt to capable destinations which it discovers on the fly, and unobtrusively pass packets in the clear to the majority of sites that know nothing of IPSEC. (Our X.509 authentication of course needs special configuration.) At boot time it's common to not have any IP address, if you have a dialup connection or, paranoid, you only turn on your DSL or cable modem interface when there's actual traffic. And when the interface goes up and down, it's likely to get a different IP address the next time. It's my impression that FreeS/WAN is bothered by that kind of activity, and it's a lot healthier if you start it after getting the IP address, and you kill it before taking down the interface. Greater agility in the face of changing network interfaces would induce potential clients to treat it as an unobtrusive helper rather than something that's hard, to be used only when absolutely needed.

Perhaps it would be useful to review why my user community wants IPSEC.

1. Very little of our traffic actually needs to be protected from in-transit monitoring, particularly if TLS is used to protect plain-text passwords. (Other organizations have data which must be kept secret, and they are under constant attack from snoopers.)
2. Nonetheless, people are skittish about interception on the wireless net, whereas wired switched Ethernet is perceived as being more private
   (probably justifiably so, given our low threat from industrial
   espionage).
3. We have licensed content (commercial databases) under hostbased authentication, so we need to make a tunnel from home to work, and do NAT so the traffic appears to come from the work IP range. We need to restrict this tunnel to authorized users. Encryption of the tunnel is not a high-value feature for our user community.
4. While it's important for our department server to authenticate the remote users, there would be little lossage, beyond denial of service, if someone impersonated the department server. (Other organizations could have a serious loss if impersonation were successful.)

I think these values are quite a bit different from most people in the IPSEC community, but even so, I suspect that they're fairly representative of the people you need to convince, if you want lots and lots of people to start using IPSEC.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc(at)math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key)