From 9790537d64272aed35fda336ef18fac1fccd960d Mon Sep 17 00:00:00 2001 From: Rene Mayrhofer Date: Tue, 30 Jan 2007 12:25:57 +0000 Subject: - New upstream release. --- doc/src/ipsec.html | 1206 ---------------------------------------------------- 1 file changed, 1206 deletions(-) delete mode 100644 doc/src/ipsec.html (limited to 'doc/src/ipsec.html') diff --git a/doc/src/ipsec.html b/doc/src/ipsec.html deleted file mode 100644 index 4647eaf66..000000000 --- a/doc/src/ipsec.html +++ /dev/null @@ -1,1206 +0,0 @@ - - - - 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