For more information on IPSEC, see our file of IPSEC links or the RFCs which are the official definitions of these protocols.
IPSEC is designed to let different implementations work together. Many
other implementations are
listed in our IPSEC links document. Information on using FreeS/WAN with other
implementations is in our compatibility document.
There is a VPN Consortium fostering
cooperation among companies and interoperability among implementations.
Project goals
Our project is Free S/WAN for Linux.
Our overall goal is to make the Internet more secure and more private,
to make Internet "wiretapping" entirely impractical.
IPSEC is designed to support (among other things) VPNs or virtual private networks, which allow multiple sites from an organisation (optionally, and its clients, suppliers, etc.) to communicate securely over an insecure Internet by encrypting all communication between the sites. We want to extend that to a real private network in which anyone who choses to communicate securely can do so, in which strong encryption is universally available.
More detailed objectives are:
From a message project leader John Gilmore posted to the mailing list:
John Denker wrote: > Indeed there are several ways in which the documentation overstates the > scope of what this project does -- starting with the name > FreeS/WAN. There's a big difference between having an encrypted IP tunnel > versus having a Secure Wide-Area Network. This software does a fine job of > the former, which is necessary but not sufficient for the latter. The goal of the project is to make it very hard to tap your wide area communications. The current system provides very good protection against passive attacks (wiretapping and those big antenna farms). Active attacks, which involve the intruder sending packets to your system (like packets that break into sendmail and give them a root shell :-) are much harder to guard against. Active attacks that involve sending people (breaking into your house and replacing parts of your computer with ones that transmit what you're doing) are also much harder to guard against. Though we are putting effort into protecting against active attacks, it's a much bigger job than merely providing strong encryption. It involves general computer security, and general physical security, which are two very expensive problems for even a site to solve, let alone to build into a whole society. The societal benefit of building an infrastructure that protects well against passive attacks is that it makes it much harder to do undetected bulk monitoring of the population. It's a defense against police-states, not against policemen. Policemen can put in the effort required to actively attack sites that they have strong suspicions about. But police states won't be able to build systems that automatically monitor everyone's communications. Either they will be able to monitor only a small subset of the populace (by targeting those who screwed up their passive security), or their monitoring activities will be detectable by those monitored (active attacks leave packet traces or footprints), which can then be addressed through the press and through political means if they become too widespread. FreeS/WAN does not protect very well against traffic analysis, which is a kind of widespread police-state style monitoring that still reveals significant information (who's talking to who) without revealing the contents of what was said. Defenses against traffic analysis are an open research problem. Zero Knowledge Systems is actively deploying a system designed to thwart it, designed by Ian Goldberg. The jury is out on whether it actually works; a lot more experience with it will be needed.Denker is a co-author of a paper on a large FreeS/WAN application. Information on Zero Knowledge is on their web site. Their Freedom product is designed to provide untracable pseudonyms for use on the net.
IPSEC is the most general way to provide these services for the Internet.
IPSEC can also provide some security services "in the background", with no visible impact on users. To use PGP encryption and signatures on mail, for example, the user must at least:
Of course, there is another side to this. IPSEC can be a powerful tool
for improving system and network security. For example, requiring packet
authentication makes various spoofing attacks harder and IPSEC tunnels
can be extremely useful for secure remote administration of various
things.
For example, if you need mail encrypted from the sender's desktop to
the recipient's desktop and decryptable only by the recipient, use
PGP or another such system. IPSEC
can encrypt any or all of the links involved -- between the two mail
servers, or between either server and its clients. It could even be
used to secure a direct IP link from the sender's desktop machine to
the recipient's, cutting out any sort of network snoop.
What it cannot ensure is end-to-end user-to-user security. If only
IPSEC is used to secure mail, then anyone with appropriate privileges
on any machine where that mail is stored (at either end or on any
store-and-forward servers in the path) can read it.
In another common setup, IPSEC encrypts packets at a security gateway
machine as they leave the sender's site and decrypts them on arrival at
the gateway to the recipient's site. This does not even come close to
providing an end-to-end service. In particular, anyone with appropriate
privileges on either site's LAN can intercept the message in unencrypted
form.
Note, however, that IPSEC authentication
of the underlying communication can make various attacks on higher-level
protocols more difficult. In particular, authentication prevents
man-in-the-middle attacks.
IPSEC shifts the ground for DoS attacks; the attacks possible against
systems using IPSEC are different than those that might be used against
other systems. It does not, however, eliminate the possibility of
such attacks.
IPSEC is not designed to defend against this. Partial defenses are certainly
possible, and one is described below, but it is not
clear that any complete defense can be provided.
The advantage is that IPSEC can provide the same protection for anything transmitted over IP. In a corporate network example, PGP lets the branch offices exchange secure mail with head office. SSL and SSH allow them to securely view web pages, connect as terminals to machines, and so on. IPSEC can support all those applications, plus database queries, file sharing (NFS or Windows), other protocols encapsulated in IP (Netware, Appletalk, ...), phone-over-IP, video-over-IP, ... anything-over-IP. The only limitation is that IP Multicast is not yet supported, though there are Internet Draft documents for that.
IPSEC creates secure tunnels through untrusted networks. Sites connected by these tunnels form VPNs, Virtual Private Networks.
IPSEC gateways can be installed wherever they are required.
No end user action is required for IPSEC security to be used; they don't even have to know about it. The site administrators, of course, do have to know about it and to put some effort into making it work. Poor administration can compromise IPSEC as badly as the post-it notes mentioned above. It seems reasonable, though, for organisations to hope their system administrators are generally both more security-conscious than end users and more able to follow computer security procedures. If not, at least there are fewer of them to educate or replace.
IPSEC can be, and often should be, used with along with security protocols
at other levels. If two sites communicate with each other via the Internet,
then IPSEC is the obvious way to protect that communication. If two others
have a direct link between them, either link encryption or IPSEC would make
sense. Choose one or use both. Whatever you use at and below the IP level,
use other things as required above that level. Whatever you use above the
IP level, consider what can be done with IPSEC to make attacks on the
higher levels harder. For example,
man-in-the-middle attacks on various
protocols become difficult if authentication at packet level is in use on
the potential victims' communication channel.
Using authentication without encryption
Where appropriate, IPSEC can provide authentication without encryption. One
might do this, for example:
Authentication has lower overheads than encryption.
Note that IPSEC authentication may make some attacks on those protocols harder.
Encryption without authentication is dangerous
Originally, the IPSEC encryption protocol ESP didn't do
integrity checking. It only did encryption. Steve Bellovin found many ways to attack
ESP used without authentication. See his paper
Problem areas for the IP Security Protocols.
To make a secure connection, you had to add an AH
Authentication Header as well as ESP. Rather than
incur the overhead of several layers (and rather than provide an ESP
layer that didn't actually protect the traffic), the IPSEC working
group built integrity and replay checking directly into ESP.
Today, typical usage is one of:
For example, a connection from a desktop machine to a database server might require AH authentication. Working with other host, network and database security measures, AH might be just the thing for access control. You might decide not to use ESP encryption on such packets, since it uses resources and might complicate network debugging. Within the site where the server is, then, only AH would be used on those packets.
Users at another office, however, might have their whole connection (AH headers and all) passing over an IPSEC tunnel connecting their office to the one with the database server. Such a tunnel should use ESP encryption and authentication. You need authentication in this layer because without authentication the encryption is vulnerable and the gateway cannot verify the AH authentication. The AH is between client and database server; the gateways aren't party to it.
In this situation, some packets would get multiple layers of IPSEC
applied to them, AH on an end-to-end client-to-server basis and ESP
from one office's security gateway to the other.
However, if we encrypt a lot of news and send it down the same connection as
our business data, we make traffic analysis
much harder. A snoop cannot now make inferences based on patterns in the volume,
direction, sizes, sender, destination, or timing of our business messages. Those
messages are hidden in a mass of news messages encapsulated in the same way.
Of course, if we're going to do this
we need to ensure that keys change often enough to remain secure even with
high volumes and with the adversary able to get plaintext of much of the data.
We also need to look at what information the adversary might gain by snooping
on our incoming non-encrypted newsfeeds and comparing things there to the
encrypted version.
IKE (RFC 2409) was the outcome of a long, complex process in which quite
a number of protocols were proposed and debated. Oversimplifying mildly,
IKE combines:
There are a number of complications:
Packet authentication can be provided separately using an
Authentication Header, described just below, or
it can be included as part of the ESP (Encapsulated
Security Payload) service, described in the following section. That
service offers encryption as well as authentication.
In IPSEC this is done using a block cipher
(normally Triple DES for
Linux FreeS/WAN). In the most used setup,
keys are automatically negotiated, and periodically re-negotiated, using the
IKE (Internet Key Exchange) protocol. In
Linux FreeS/WAN this is handled by the
Pluto Daemon.
The IPSEC protocol offering encryption is ESP, Encapsulated
Security Payload. It can also include a packet authentication service.
Each of the several headers on a packet header contains a "next
protocol" field telling the system what
header to look for next. IP headers generally have either TCP
or UDP in this field. When IPSEC authentication is used, the
packet IP header has AH in this field, saying that an Authentication
Header comes next. The AH header then has the next header type --
usually TCP, UDP or encapsulated IP.
IPSEC packet authentication can be added in transport mode, as a
modification of standard IP transport. This is shown in this
diagram from the RFC:
The mutable fields referred to are things like the time-to-live
field in the IP header. These cannot be included in authentication
calculations because they change as the packet travels.
The actual authentication data in the header is typically 96
bits and depends both on a secret shared between sender and
receiver and on every byte of the data being authenticated.
The algorithms involved are the MD5
Message Digest algorithm or SHA, the
Secure Hash Algorithm. For details on their use in this application,
see RFCs 2403 and 2404 respectively.
For descriptions of the algorithms themselves, see RFC 1321
for MD5 and FIPS (Federal Information Processing Standard)
number 186 from NIST, the US National Institute of Standards and
Technology for SHA.
Applied Cryptography
covers both in some detail, MD5 starting on
page 436 and SHA on 442.
These algorithms are intended to make it nearly impossible for
anyone to alter the authenticated data in transit. The sender
calculates a digest or hash value from that data and includes
the result in the authentication header. The recipient does
the same calculation and compares results. For unchanged data,
the results will be identical. The hash algorithms are designed
to make it extremely difficult to change the data in any way and
still get the correct hash.
Since the shared secret key is also used in both calculations,
an interceptor cannot simply alter the authenticated data and
change the hash value to match. Without the key, he or she (or
even the dreaded They) cannot produce a usable hash.
This provides partial protection against
replay attacks in which an
attacker resends intercepted packets in an effort to confuse or
subvert the receiver. Complete protection is not possible since
it is necessary to handle legitmate packets which are lost,
duplicated, or delivered out of order, but use of sequence numbers
makes the attack much more difficult.
The RFCs require that sequence numbers never cycle, that a new key
always be negotiated before the sequence number reaches 2^32-1.
This protects both against replays attacks using packets from a
previous cyclce and against
birthday attacks on the
the packet authentication algorithm.
In Linux FreeS/WAN, the sequence number is ignored for manually
keyed connections and checked for automatically keyed ones.
In automatic mode, we do that. In manual mode, there is no way
to negotiate a new key, or to recover from a sequence number problem,
so we don't use sequence numbers.
The ESP protocol is defined in RFC 2406. It provides one or both
of encryption and packet authentication. It may be used with or
without AH packet authentication.
Note that some form of packet authentication should always
be used whenever data is encrypted. Without authentication, the
encryption is vulnerable to active attacks which may allow an enemy to
break the encryption. ESP should always either include
its own authentication or be used with AH authentication.
The RFCs require support for only two mandatory encryption algorithms --
DES,
and null encryption -- and for two authentication
methods -- keyed MD5 and keyed SHA. Implementers may choose to
support additional algorithms in either category.
The authentication algorithms are the same ones used in the IPSEC
authentication header.
We do not implement single DES since DES is insecure.
Instead we provide triple DES or 3DES. This
is currently the only encryption algorithm supported.
We do implement null encryption, but it is disabled by default. You can
enable it in the IPSEC part of kernel configuration if required. We would
suggest, however, that if you need only authentication, you should use AH
rather than ESP with null encryption.
Manual keying is useful
for debugging since it allows you to test the
KLIPS kernel IPSEC code
without the
Pluto daemon doing key negotiation.
In general, however, automatic keying is preferred because it is
more secure.
This is considerably more secure than manual keying. In either case an
attacker who acquires a key can read every message encrypted with that
key, but automatic keys can be changed every few hours or even every few
minutes without breaking the connection or requiring intervention by the
system administrators. Manual keys can only be changed manually; you
need to shut down the connection and have the two admins make changes.
Moreover, they have to communicate the new keys securely, perhaps with
PGP or
SSH. This may be possible in some cases,
but as a general solution it is expensive, bothersome and unreliable.
Far better to let Pluto handle these
chores; no doubt the administrators have enough to do.
Also, automatic keying is inherently more secure against an attacker
who manages to subvert your gateway system. If manual keying is in use
and an adversary acquires root privilege on your gateway, he reads your
keys from /etc/ipsec.conf and then reads all messages encrypted with
those keys.
If automatic keying is used, an adversary with the same privileges can
read /etc/ipsec.secrets, but this does not contain any keys, only the
secrets used to authenticate key exchanges. Having an adversary able to
authenticate your key exchanges need not worry you overmuch. Just having
the secrets does not give him any keys. You are still secure against
passive attacks. This property of
automatic keying is called
perfect forward secrecy, abbreviated PFS.
Unfortunately, having the secrets does allow an
active attack, specifically a
man-in-the-middle attack. Losing
these secrets to an attacker may not be quite as disastrous as losing
the actual keys, but it is still a serious security breach.
These secrets should be guarded as carefully as keys.
There is room for debate here. Should we provide immediate security
against passive attacks and
encourage widespread use of encryption, at the expense of risking
the more difficult active attacks?
Or should we wait until we can implement a solution that can both be
widespread and offer security against active attacks?
So far, we have chosen the second course, complying with the RFCs and
waiting for secure DNS (see below) so that we can do
opportunistic encryption right.
As of FreeS/WAN 1.4, we have experimental code to acquire RSA keys
from DNS but do not yet have code to validate Secure DNS signatures.
On the other hand, this is not as high a priority for Linux FreeS/WAN
as solutions based on secure DNS. We
do not expect any PKI to become as universal as DNS. Adding support
for PKIs might be a good project for
volunteers.
Some patches
to handle authentication with X.509 certificates, which most PKIs use,
were written by a volunteer for an earlier
FreeS/WAN version.
Using "unnecessary" encryption to frustrate attackers
One might choose to use encryption even where it appears
unnecessary in order to make certain attacks more difficult. Consider two
offices which pass a small volume of business data between them using IPSEC
and also transfer large volumes of Usenet news. At first glance, it would
seem silly to encrypt the newsfeed, except possibly for any newsgroups that
are internal to the company. Why encrypt data that is all publicly
available from many sites?
Structure of IPSEC
There are three protocols used in an IPSEC implementation:
The term "IPSEC" is slightly ambiguous. In some contexts, it includes
all three of the above but in other contexts it refers only to AH and ESP.
IKE (Internet Key Exchange)
The IKE protocol sets up IPSEC (ESP or AH) connections after negotiating
appropriate parameters (algorithms to be used, keys, connection lifetimes)
for them. This is done by exchanging packets on UDP port 500 between the
two gateways.
For all the details, you would need to read the four RFCs
just mentioned (over 200 pages) and a number of others. We give a summary
below, but it is far from complete.
Phases of IKE
IKE negotiations have two phases.
Both of these phases use the UDP protocol and port 500 for their negotiations.
The actual IPSEC SAs use the ESP or AH protocols. These protocols do not have
ports; ports apply only to UDP or TCP.
These complications can of course lead to problems, particularly when two
different implementations attempt to interoperate. For example, we have
seen problems such as:
Despite this, we do interoperate successfully with many implementations,
including both Windows 2000 and PGPnet. Details are in our
compatibility document.
Structure of IKE messages
Here is our Pluto developer explaining some of this on the mailing list:
When one IKE system (for example, Pluto) is negotiating with another
to create an SA, the Initiator proposes a bunch of choices and the
Responder replies with one that it has selected.
The structure of the choices is fairly complicated. An SA payload
contains a list of lists of "Proposals". The outer list is a set of
choices: the selection must be from one element of this list.
Each of these elements is a list of Proposals. A selection must be
made from each of the elements of the inner list. In other words,
*all* of them apply (that is how, for example, both AH and ESP can
apply at once).
Within each of these Proposals is a list of Transforms. For each
Proposal selected, one Transform must be selected (in other words,
each Proposal provides a choice of Transforms).
Each Transform is made up of a list of Attributes describing, well,
attributes. Such as lifetime of the SA. Such as algorithm to be
used. All the Attributes apply to a Transform.
You will have noticed a pattern here: layers alternate between being
disjunctions ("or") and conjunctions ("and").
For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is
cut back. There must be exactly one Proposal. So this degenerates to
a list of Transforms, one of which must be chosen.
IPSEC Services, AH and ESP
IPSEC offers two services, authentication
and encryption.
These can be used separately but are often used together.
Note that encryption should always be used with some packet authentication
service. Unauthenticated encryption is vulnerable to man-in-the-middle attacks.
Also note that encryption does not necessarily prevent
traffic analysis.
The Authentication Header (AH)
Packet authentication can be provided separately from encryption by
adding an authentication header (AH) after the IP header but before
the other headers on the packet. This is the subject of this section.
Details are in RFC 2402.
BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING AH
---------------------------------
IPv4 |orig IP hdr | | | |
|(any options)| AH | TCP | Data |
---------------------------------
|<------- authenticated ------->|
except for mutable fields
Athentication can also be used in tunnel mode, encapsulating the
underlying IP packet beneath AH and an additional IP header.
|<-- original IP packet --->|
IPv4 | new IP hdr* | | orig IP hdr* | | |
|(any options)| AH | (any options) |TCP | Data |
------------------------------------------------
|<- authenticated except for mutable fields -->|
| in the new IP hdr |
This would normally be used in a gateway-to-gateway tunnel.
The receiving gateway then strips the outer IP header and the
AH header and forwards the inner IP packet.
Keyed MD5 and Keyed SHA
Sequence numbers
The authentication header includes a sequence number field which
the sender is required to increment for each packet. The receiver
can ignore it or use it to check that packets are indeed arriving
in the expected sequence.
Encapsulated Security Payload (ESP)
IPSEC modes
Tunnel mode
Security gateways are required to support tunnel mode connections. In this
mode the gateways provide tunnels for use by client machines behind
the gateways. The client machines need not do any IPSEC processing; all
they have to do is route things to gateways.
Transport mode
Host machines (as opposed to security gateways) with IPSEC implementations
must also support transport mode. In this mode, the host does its own
IPSEC processing and routes some packets via IPSEC.
FreeS/WAN parts
KLIPS: Kernel IPSEC Support
KLIPS is KerneL IPSEC Support,
the modifications necessary to support IPSEC within the Linux kernel. KILPS does all the actual
IPSEC packet-handling, including
KLIPS also checks all non-IPSEC packets to ensure they are not bypassing IPSEC security policies.
The Pluto daemon
Pluto(8) is a daemon which implements the IKE protocol. It
Pluto is controlled mainly by the ipsec.conf(5)
configuration file.
The ipsec(8) command
The ipsec(8) command is a front end that allows control over
IPSEC activity.
Linux FreeS/WAN configuration file
The configuration file for
Linux FreeS/WAN
is
/etc/ipsec.conf
For details see the ipsec.conf(5)
manual page
and our Setup and
Configuration
HTML documents.
Key management
There are several ways IPSEC can manage keys. Not all are
implemented in Linux FreeS/WAN.
Currently Implemented Methods
Manual keying
IPSEC allows keys to be manually set. In Linux FreeS/WAN,
such keys are stored with the connection definitions in
/etc/ipsec.conf.
Automatic keying
In automatic keying, the Pluto
daemon negotiates keys using the IKE
Internet Key Exchange protocol. Connections are automatically re-keyed
periodically.
Methods not yet implemented
Unauthenticated key exchange
It would be possible to exchange keys without authenticating the
players. This would support
opportunistic encryption
-- allowing
any two systems to encrypt their communications without requiring
a shared PKI or a previously negotiated secret -- and would be
secure against passive attacks.
It would, however, be highly vulnerable to active
man-in-the-middle attacks. RFC
2408 therefore specifies that all ISAKMP
key management interactions must be authenticated.
Key exchange using DNS
The IPSEC RFCs allow key exchange based on authentication services
provided by Secure DNS. Once Secure
DNS service becomes widely available, we expect to make this the
primary key management method for Linux FreeS/WAN. It is the best
way we know of to support
opportunistic encryption,
allowing two systems without a common PKI or previous negotiation
to secure their communication.
Key exchange using a PKI
The IPSEC RFCs allow key exchange based on authentication services
provided by a PKI or Public Key
Infrastructure. With many vendors selling such products and many
large organisations building these infrastructures, this will
clearly be an important application of IPSEC and one Linux FreeS/WAN
will eventually support.
Photuris
Photuris is another key management
protocol, an alternative to IKE and ISAKMP, described in RFCs 2522 and
2523 which are labelled "experimental". Adding Photuris support to Linux
FreeS/WAN might be a good project for a volunteer. The likely starting
point would be the OpenBSD photurisd code.
SKIP
SKIP is yet another key management
protocol, developed by Sun. At one point it was fairly widely used,
but our current impression is that it is moribund, displaced by IKE.
Sun now (as of Solaris 8.0) ship an IPSEC implementation using IKE.
We have no plans to implement SKIP.
Click below to go to: