Re: 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.

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: [email protected]    http://www.math.ucla.edu/~jimc (q.v. for PGP key)