From aa0f5b38aec14428b4b80e06f90ff781f8bca5f1 Mon Sep 17 00:00:00 2001 From: Rene Mayrhofer Date: Mon, 22 May 2006 05:12:18 +0000 Subject: Import initial strongswan 2.7.0 version into SVN. --- doc/src/ipsec.html | 1206 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1206 insertions(+) create mode 100644 doc/src/ipsec.html (limited to 'doc/src/ipsec.html') diff --git a/doc/src/ipsec.html b/doc/src/ipsec.html new file mode 100644 index 000000000..4647eaf66 --- /dev/null +++ b/doc/src/ipsec.html @@ -0,0 +1,1206 @@ + + + + IPsec protocols + + + + + +

The IPsec protocols

+ +

This section provides information on the IPsec protocols which FreeS/WAN +implements. For more detail, see the RFCs.

+ +

The basic idea of IPsec is to provide security functions, authentication and encryption, at the IP (Internet Protocol) +level. This requires a higher-level protocol (IKE) to set things up for the +IP-level services (ESP and AH).

+ +

Protocols and phases

+ +

Three protocols are used in an IPsec implementation:

+
+
ESP, Encapsulating Security Payload
+
Encrypts and/or authenticates data
+
AH, Authentication Header
+
Provides a packet authentication service
+
IKE, Internet Key Exchange
+
Negotiates connection parameters, including keys, for the other + two
+
+ +

The term "IPsec" (also written as 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.

+ +

There is more detail below, but a quick summary of how the whole thing +works is:

+
+
Phase one IKE (main mode exchange)
+
sets up a keying channel (ISAKMP SA) between the two gateways
+
Phase two IKE (quick mode exchange)
+
sets up data channels (IPsec SAs)
+
IPsec proper
+
exchanges data using AH or ESP
+
+ +

Both phases of IKE are repeated periodically to automate re-keying.

+ +

Applying IPsec

+ +

Authentication and encryption functions for network data can, of course, +be provided at other levels. Many security protocols work at levels above +IP.

+ + +

and so on. Other techniques work at levels below IP. For example, data on +a communications circuit or an entire network can be encrypted by specialised +hardware. This is common practice in high-security applications.

+ +

Advantages of IPsec

+ +

There are, however, advantages to doing it at the IP level instead of, or +as well as, at other levels.

+ +

IPsec is the most general way to provide these services for the +Internet.

+ + +

IPsec, however, can protect any protocol running above IP and +any medium which IP runs over. More to the point, it can protect a +mixture of application protocols running over a complex combination of media. +This is the normal situation for Internet communication; IPsec is the only +general solution.

+ +

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:

+ + +

These systems can be designed so that the burden on users is not onerous, +but any system will place some requirements on users. No such system can hope +to be secure if users are sloppy about meeting those requirements. The author +has seen username and password stuck on terminals with post-it notes in an +allegedly secure environment, for example.

+ +

Limitations of IPsec

+ +

IPsec is designed to secure IP links between machines. It does that well, +but it is important to remember that there are many things it does not do. +Some of the important limitations are:

+
+
IPsec cannot be secure if your system isn't
+
System security on IPsec gateway machines is an essential requirement + if IPsec is to function as designed. No system can be trusted if the + underlying machine has been subverted. See books on Unix security such + as Garfinkel and Spafford or our + web references for Linux security or more + general computer security. +

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.

+
+
IPsec is not end-to-end
+
IPsec cannot provide the same end-to-end security as systems working + at higher levels. IPsec encrypts an IP connection between two machines, + which is quite a different thing than encrypting messages between users + or between applications. +

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 provide a + useful security service -- only encrypted data is passed over the + Internet -- but it 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.

+
+
IPsec cannot do everything
+
IPsec also cannot provide all the functions of systems working at + higher levels of the protocol stack. If you need a document + electronically signed by a particular person, then you need his or her + digital signature and a public key cryptosystem to verify it + with. +

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 authenticates machines, not users
+
IPsec uses strong authentication mechanisms to control which messages + go to which machines, but it does not have the concept of user ID, + which is vital to many other security mechansims and policies. This + means some care must be taken in fitting the various security + mechansims on a network together. For example, if you need to control + which users access your database server, you need some non-IPsec + mechansim for that. IPsec can control which machines connect to the + server, and can ensure that data transfer to those machines is done + securely, but that is all. Either the machines themselves must control + user access or there must be some form of user authentication to the + database, independent of IPsec.
+
IPsec does not stop denial of service attacks
+
Denial of service attacks aim at + causing a system to crash, overload, or become confused so that + legitimate users cannot get whatever services the system is supposed to + provide. These are quite different from attacks in which the attacker + seeks either to use the service himself or to subvert the service into + delivering incorrect results. +

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 does not stop traffic analysis
+
Traffic analysis is the attempt + to derive intelligence from messages without regard for their contents. + In the case of IPsec, it would mean analysis based on things visible in + the unencrypted headers of encrypted packets -- source and destination + gateway addresses, packet size, et cetera. Given the resources to + acquire such data and some skill in analysing it (both of which any + national intelligence agency should have), this can be a very powerful + technique. +

IPsec is not designed to defend against this. Partial defenses are + certainly possible, and some are described + below, but it is not clear that any complete defense can be + provided.

+
+
+ +

IPsec is a general mechanism for securing IP

+ +

While IPsec does not provide all functions of a mail encryption package, +it can encrypt your mail. In particular, it can ensure that all mail passing +between a pair or a group of sites is encrypted. An attacker looking only at +external traffic, without access to anything on or behind the IPsec gateway, +cannot read your mail. He or she is stymied by IPsec just as he or she would +be by PGP.

+ +

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.

+ + +

Which of these, or of the many other possible variants, to use is up to +you. IPsec provides mechanisms; you provide the policy.

+ +

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.

+ +

The protocols provide four ways to build such connections, using either an +AH-only connection or ESP using null encryption, and in either manually or +automatically keyed mode. FreeS/WAN supports only one of these, manually +keyed AH-only connections, and we do not recommend using +that. Our reasons are discussed under Resisting traffic analysis a few sections further +along.

+ +

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:

+ + +

Other variants are allowed by the standard, but not much used:

+
+
ESP encryption without authentication
+
Bellovin has demonstrated fatal flaws in this. Do not + use.
+
ESP encryption with AH authentication
+
This has higher overheads than using the authentication in ESP, and + no obvious benefit in most cases. The exception might be a network + where AH authentication was widely or universally used. If you're going + to do AH to conform with network policy, why authenticate again in the + ESP layer?
+
Authenticate twice, with AH and with ESP
+
Why? Of course, some folk consider "belt and suspenders" the sensible + approach to security. If you're among them, you might use both + protocols here. You might also use both to satisfy different parts of a + security policy. For example, an organisation might require AH + authentication everywhere but two users within the organisation might + use ESP as well.
+
ESP authentication without encryption
+
The standard allows this, calling it "null encryption". FreeS/WAN + does not support it. We recommend that you use AH instead if + authentication is all you require. AH authenticates parts of the IP + header, which ESP-null does not do.
+
+ +

Some of these variants cannot be used with FreeS/WAN because we do not +support ESP-null and do not support automatic keying of AH-only +connections.

+ +

There are fairly frequent suggestions that AH be dropped entirely from the +IPsec specifications since ESP and null encryption can handle that situation. +It is not clear whether this will occur. My guess is that it is unlikely.

+ +

Multiple layers of IPsec processing are +possible

+ +

The above describes combinations possible on a single IPsec connection. In +a complex network you may have several layers of IPsec in play, with any of +the above combinations at each layer.

+ +

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.

+ +

Resisting traffic analysis

+ +

Traffic analysis is the attempt to +derive useful intelligence from encrypted traffic without breaking the +encryption.

+ +

Is your CEO exchanging email with a venture capital firm? With bankruptcy +trustees? With an executive recruiting agency? With the holder of some +important patents? If an eavesdropper learns about any of those, then he has +interesting intelligence on your company, whether or not he can read the +messages themselves.

+ +

Even just knowing that there is network traffic between two sites may tell +an analyst something useful, especially when combined with whatever other +information he or she may have. For example, if you know Company A is having +cashflow problems and Company B is looking for aquisitions, then knowing that +packets are passing between the two is interesting. It is more interesting if +you can tell it is email, and perhaps yet more if you know the sender and +recipient.

+ +

Except in the simplest cases, traffic analysis is hard to do well. It +requires both considerable resources and considerable analytic skill. +However, intelligence agencies of various nations have been doing it for +centuries and many of them are likely quite good at it by now. Various +commercial organisations, especially those working on "targeted marketing" +may also be quite good at analysing certain types of traffic.

+ +

In general, defending against traffic analysis is also difficult. +Inventing a really good defense could get you a PhD and some interesting job +offers.

+ +

IPsec is not designed to stop traffic analysis and we know of no plausible +method of extending it to do so. That said, there are ways to make traffic +analysis harder. This section describes them.

+ +

Using "unnecessary" encryption

+ +

One might choose to use encryption even where it appears unnecessary in +order to make analysis 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?

+ +

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.

+ +

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 other attacks this +might open up. For example, can the adversary use a chosen plaintext attack, +deliberately posting news articles which, when we receive and encrypt them, +will help break our encryption? Or can he block our business data +transmission by flooding us with silly news articles? Or ...

+ +

Also, note that this does not provide complete protection against traffic +analysis. A clever adversary might still deduce useful intelligence from +statistical analysis (perhaps comparing the input newsfeed to encrypted +output, or comparing the streams we send to different branch offices), or by +looking for small packets which might indicate establishment of TCP +connections, or ...

+ +

As a general rule, though, to improve resistance to traffic analysis, you +should encrypt as much traffic as possible, not just as much as seems +necessary.

+ +

Using multiple encryption

+ +

This also applies to using multiple layers of encryption. If you have an +IPsec tunnel between two branch offices, it might appear silly to send PGP-encrypted email through that tunnel. +However, if you suspect someone is snooping your traffic, then it does make +sense:

+ + +

Similar arguments apply for SSL-encrypted +web traffic or SSH-encrypted remote login +sessions, even for end-to-end IPsec tunnels between systems in the two +offices.

+ +

Using fewer tunnels

+ +

It may also help to use fewer tunnels. For example, if all you actually +need encrypted is connections between:

+ + +

You might build one tunnel per mail server and one per remote database +user, restricting traffic to those applications. This gives the traffic +analyst some information, however. He or she can distinguish the tunnels by +looking at information in the ESP header and, given that distinction and the +patterns of tunnel usage, might be able to figure out something useful. +Perhaps not, but why take the risk?

+ +

We suggest instead that you build one tunnel per branch office, encrypting +everything passing from head office to branches. This has a number of +advantages:

+ + +

Of course you might also want to add additional tunnels. For example, if +some of the database data is confidential and should not be exposed even +within the company, then you need protection from the user's desktop to the +database server. We suggest you do that in whatever way seems appropriate -- +IPsec, SSH or SSL might fit -- but, whatever you choose, pass it between +locations via a gateway-to-gateway IPsec tunnel to provide some resistance to +traffic analysis.

+ +

Cryptographic components

+ +

IPsec combines a number of cryptographic techniques, all of them +well-known and well-analyzed. The overall design approach was conservative; +no new or poorly-understood components were included.

+ +

This section gives a brief overview of each technique. It is intended only +as an introduction. There is more information, and links to related topics, +in our glossary. See also our bibliography and cryptography web links.

+ +

Block ciphers

+ +

The encryption in the ESP encapsulation protocol is done with a block cipher.

+ +

We do not implement single DES. It is insecure. Our default, and currently +only, block cipher is triple DES.

+ +

The Rijndael block cipher has won the +AES competition to choose a relacement for +DES. It will almost certainly be added to FreeS/WAN and to other IPsec +implementations. Patches are already +available.

+ +

Hash functions

+ +

The HMAC construct

+ +

IPsec packet authentication is done with the HMAC construct. This is not just a hash of the +packet data, but a more complex operation which uses both a hashing algorithm +and a key. It therefore does more than a simple hash would. A simple hash +would only tell you that the packet data was not changed in transit, or that +whoever changed it also regenerated the hash. An HMAC also tells you that the +sender knew the HMAC key.

+ +

For IPsec HMAC, the output of the hash algorithm is truncated to 96 bits. +This saves some space in the packets. More important, it prevents an attacker +from seeing all the hash output bits and perhaps creating some sort of attack +based on that knowledge.

+ +

Choice of hash algorithm

+ +

The IPsec RFCs require two hash algorithms -- MD5 and SHA-1 -- +both of which FreeS/WAN implements.

+ +

Various other algorithms -- such as RIPEMD and Tiger -- are listed in the +RFCs as optional. None of these are in the FreeS/WAN distribution, or are +likely to be added, although user patches exist +for several of them.

+ +

Additional hash algorithms -- SHA-256, +SHA-384 and SHA-512 -- may be required to give hash strength matching the +strength of AES. These are likely to be added +to FreeS/WAN along with AES.

+ +

Diffie-Hellman key agreement

+ +

The Diffie-Hellman key agreement protocol +allows two parties (A and B or Alice and +Bob) to agree on a key in such a way that an eavesdropper who intercepts +the entire conversation cannot learn the key.

+ +

The protocol is based on the discrete +logarithm problem and is therefore thought to be secure. Mathematicians +have been working on that problem for years and seem no closer to a solution, +though there is no proof that an efficient solution is impossible.

+ +

RSA authentication

+ +

The RSA algorithm (named for its inventors +-- Rivest, Shamir and Adleman) is a very widely used public key cryptographic technique. It is used in +IPsec as one method of authenticating gateways for Diffie-Hellman key +negotiation.

+ +

Structure of IPsec

+ +

There are three protocols used in an IPsec implementation:

+
+
ESP, Encapsulating Security Payload
+
Encrypts and/or authenticates data
+
AH, Authentication Header
+
Provides a packet authentication service
+
IKE, Internet Key Exchange
+
Negotiates connection parameters, including keys, for the other + two
+
+ +

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.

+ +

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:

+
+
ISAKMP (RFC 2408)
+
The Internet Security + Association and Key + Management Protocol manages + negotiation of connections and defines SAs (Security Associations) as a means of + describing connection properties.
+
IPsec DOI for ISAKMP (RFC 2407)
+
A Domain Of + Interpretation fills in the details necessary to turn + the rather abstract ISAKMP protocol into a more tightly specified + protocol, so it becomes applicable in a particular domain.
+
Oakley key determination protocol (RFC 2412)
+
Oakley creates keys using the Diffie-Hellman key agreement protocol.
+
+ +

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.

+
+
Phase one
+
The two gateways negotiate and set up a two-way ISAKMP SA which they + can then use to handle phase two negotiations. One such SA between a + pair of gateways can handle negotiations for multiple tunnels.
+
Phase two
+
Using the ISAKMP SA, the gateways negotiate IPsec (ESP and/or AH) SAs + as required. IPsec SAs are unidirectional (a different key is used in + each direction) and are always negotiated in pairs to handle two-way + traffic. There may be more than one pair defined between two + gateways.
+
+ +

Both of these phases use the UDP protocol and port 500 for their +negotiations.

+ +

After both IKE phases are complete, you have IPsec SAs to carry your +encrypted data. These use the ESP or AH protocols. These protocols do not +have ports. Ports apply only to UDP or TCP.

+ +

The IKE protocol is designed to be extremely flexible. Among the things +that can be negotiated (separately for each SA) are:

+ + +

The protocol also allows implementations to add their own encryption +algorithms, authentication algorithms or Diffie-Hellman groups. We do not +support any such extensions, but there are some patches that do.

+ +

There are a number of complications:

+ + +

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 interoperability document.

+ +

Sequence of messages in IKE

+ +

Each phase (see previous section)of IKE involves a +series of messages. In Pluto error messages, these are abbreviated using:

+
+
M
+
Main mode, settting up the keying channel (ISAKMP + SA)
+
Q
+
Quick mode, setting up the data channel (IPsec + SA)
+
I
+
Initiator, the machine that starts the + negotiation
+
R
+
Responder
+
+ +

For example, the six messages of a main mode negotiation, in sequence, are +labelled:

+
       MI1 ---------->
+           <---------- MR1
+       MI2 ----------> 
+           <---------- MR2
+       MI3 ---------->
+           <---------- MR3
+ +

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.

+
+
Authentication
+
Packet-level authentication allows you to be confident that a packet + came from a particular machine and that its contents were not altered + en route to you. No attempt is made to conceal or protect the contents, + only to assure their integrity. 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 either case, the HMAC construct is used as the + authentication mechanism. +

There is a separate authentication operation at the IKE level, in + which each gateway authenticates the other. This can be done in a + variety of ways.

+
+
Encryption
+
Encryption allows you to conceal the contents of a message from + eavesdroppers. +

In IPsec this is done using a block + cipher (normally Triple DES for + Linux). 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.

+
+
+ +

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

+ +

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:

+
                  BEFORE APPLYING AH
+            ----------------------------
+      IPv4  |orig IP hdr  |     |      |
+            |(any options)| TCP | Data |
+            ----------------------------
+
+                  AFTER APPLYING AH
+            ---------------------------------
+      IPv4  |orig IP hdr  |    |     |      |
+            |(any options)| AH | TCP | Data |
+            ---------------------------------
+            ||
+                 except for mutable fields
+ +

Athentication can also be used in tunnel mode, encapsulating the +underlying IP packet beneath AH and an additional IP header.

+
                         ||
+IPv4  | new IP hdr* |    | orig IP hdr*  |    |      |
+      |(any options)| AH | (any options) |TCP | Data |
+      ------------------------------------------------
+      ||
+      |           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.

+ +

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.

+ +

Keyed MD5 and Keyed SHA

+ +

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 technique used is HMAC, defined in RFC 2104.

+ +

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.

+ +

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.

+ +

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

+ +

Encapsulated Security Payload (ESP)

+ +

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 not implement null encryption since it is obviously insecure.

+ +

IPsec modes

+ +

IPsec can connect in two modes. Transport mode is a host-to-host +connection involving only two machines. In tunnel mode, the IPsec machines +act as gateways and trafiic for any number of client machines may be +carried.

+ +

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 +shellscript 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 .

+ +

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.

+ +

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.

+ +

Automatic keying

+ +

In automatic keying, the Pluto daemon +negotiates keys using the IKE Internet Key +Exchange protocol. Connections are automatically re-keyed periodically.

+ +

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.

+ +

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.

+ +

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.

+ +

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.

+ +

We currently have code to acquire RSA keys from DNS but do not yet have +code to validate Secure DNS signatures.

+ +

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.

+ +

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.

+ +

Some patches to handle authentication with +X.509 certificates, which most PKIs use, are available.

+ +

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 it +now seems moribund, displaced by IKE. Sun now (as of Solaris 8.0) ship an +IPsec implementation using IKE. We have no plans to implement SKIP. If a user +were to implement it, we would almost certainly not want to add the code to +our distribution.

+ + -- cgit v1.2.3