1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
4 <TITLE>Introduction to FreeS/WAN
</TITLE>
5 <META HTTP-EQUIV=
"Content-Type" CONTENT=
"text/html; CHARSET=iso-8859-1">
6 <STYLE TYPE=
"text/css"><!--
7 BODY { font-family: serif }
8 H1 { font-family: sans-serif }
9 H2 { font-family: sans-serif }
10 H3 { font-family: sans-serif }
11 H4 { font-family: sans-serif }
12 H5 { font-family: sans-serif }
13 H6 { font-family: sans-serif }
14 SUB { font-size: smaller }
15 SUP { font-size: smaller }
16 PRE { font-family: monospace }
20 <A HREF=
"toc.html">Contents
</A>
21 <A HREF=
"politics.html">Previous
</A>
22 <A HREF=
"mail.html">Next
</A>
24 <H1><A name=
"ipsec.detail">The IPsec protocols
</A></H1>
25 <P>This section provides information on the IPsec protocols which
26 FreeS/WAN implements. For more detail, see the
<A href=
"rfc.html"> RFCs
</A>
28 <P>The basic idea of IPsec is to provide security functions,
<A href=
"glossary.html#authentication">
29 authentication
</A> and
<A href=
"glossary.html#encryption"> encryption
</A>
30 , at the IP (Internet Protocol) level. This requires a higher-level
31 protocol (IKE) to set things up for the IP-level services (ESP and AH).
</P>
32 <H2><A NAME=
"27_1">Protocols and phases
</A></H2>
33 <P>Three protocols are used in an IPsec implementation:
</P>
35 <DT>ESP, Encapsulating Security Payload
</DT>
36 <DD>Encrypts and/or authenticates data
</DD>
37 <DT>AH, Authentication Header
</DT>
38 <DD>Provides a packet authentication service
</DD>
39 <DT>IKE, Internet Key Exchange
</DT>
40 <DD>Negotiates connection parameters, including keys, for the other two
</DD>
42 <P>The term
"IPsec
" (also written as IPSEC) is slightly ambiguous. In
43 some contexts, it includes all three of the above but in other contexts
44 it refers only to AH and ESP.
</P>
45 <P>There is more detail below, but a quick summary of how the whole
48 <DT>Phase one IKE (main mode exchange)
</DT>
49 <DD>sets up a keying channel (ISAKMP SA) between the two gateways
</DD>
50 <DT>Phase two IKE (quick mode exchange)
</DT>
51 <DD>sets up data channels (IPsec SAs)
</DD>
53 <DD>exchanges data using AH or ESP
</DD>
55 <P>Both phases of IKE are repeated periodically to automate re-keying.
</P>
56 <H2><A name=
"others">Applying IPsec
</A></H2>
57 <P>Authentication and encryption functions for network data can, of
58 course, be provided at other levels. Many security protocols work at
61 <LI><A href=
"glossary.html#PGP">PGP
</A> encrypts and authenticates mail
63 <LI><A href=
"glossary.html#SSH">SSH
</A> authenticates remote logins and
64 then encrypts the session
</LI>
65 <LI><A href=
"glossary.html#SSL">SSL
</A> or
<A href=
"glossary.html#TLS">
66 TLS
</A> provides security at the sockets layer, e.g. for secure web
69 <P>and so on. Other techniques work at levels below IP. For example,
70 data on a communications circuit or an entire network can be encrypted
71 by specialised hardware. This is common practice in high-security
73 <H3><A name=
"advantages">Advantages of IPsec
</A></H3>
74 <P>There are, however, advantages to doing it at the IP level instead
75 of, or as well as, at other levels.
</P>
76 <P>IPsec is the
<STRONG> most general way to provide these services for
77 the Internet
</STRONG>.
</P>
79 <LI>Higher-level services protect a
<EM> single protocol
</EM>; for
80 example PGP protects mail.
</LI>
81 <LI>Lower level services protect a
<EM> single medium
</EM>; for example a
82 pair of encryption boxes on the ends of a line make wiretaps on that
83 line useless unless the attacker is capable of breaking the encryption.
</LI>
85 <P>IPsec, however, can protect
<EM> any protocol
</EM> running above IP
86 and
<EM> any medium
</EM> which IP runs over. More to the point, it can
87 protect a mixture of application protocols running over a complex
88 combination of media. This is the normal situation for Internet
89 communication; IPsec is the only general solution.
</P>
90 <P>IPsec can also provide some security services
"in the background
",
91 with
<STRONG> no visible impact on users
</STRONG>. To use
<A href=
"glossary.html#PGP">
92 PGP
</A> encryption and signatures on mail, for example, the user must
95 <LI>remember his or her passphrase,
</LI>
96 <LI>keep it secure
</LI>
97 <LI>follow procedures to validate correspondents' keys
</LI>
99 <P>These systems can be designed so that the burden on users is not
100 onerous, but any system will place some requirements on users. No such
101 system can hope to be secure if users are sloppy about meeting those
102 requirements. The author has seen username and password stuck on
103 terminals with post-it notes in an allegedly secure environment, for
105 <H3><A name=
"limitations">Limitations of IPsec
</A></H3>
106 <P>IPsec is designed to secure IP links between machines. It does that
107 well, but it is important to remember that there are many things it
108 does not do. Some of the important limitations are:
</P>
110 <DT><A name=
"depends">IPsec cannot be secure if your system isn't
</A></DT>
111 <DD>System security on IPsec gateway machines is an essential
112 requirement if IPsec is to function as designed. No system can be
113 trusted if the underlying machine has been subverted. See books on Unix
114 security such as
<A href=
"biblio.html#practical"> Garfinkel and Spafford
</A>
115 or our web references for
<A href=
"web.html#linsec"> Linux security
</A>
116 or more general
<A href=
"web.html#compsec"> computer security
</A>.
117 <P>Of course, there is another side to this. IPsec can be a powerful
118 tool for improving system and network security. For example, requiring
119 packet authentication makes various spoofing attacks harder and IPsec
120 tunnels can be extremely useful for secure remote administration of
123 <DT><A name=
"not-end-to-end">IPsec is not end-to-end
</A></DT>
124 <DD>IPsec cannot provide the same end-to-end security as systems working
125 at higher levels. IPsec encrypts an IP connection between two machines,
126 which is quite a different thing than encrypting messages between users
127 or between applications.
128 <P>For example, if you need mail encrypted from the sender's desktop to
129 the recipient's desktop and decryptable only by the recipient, use
<A href=
"glossary.html#PGP">
130 PGP
</A> or another such system. IPsec can encrypt any or all of the
131 links involved -- between the two mail servers, or between either
132 server and its clients. It could even be used to secure a direct IP
133 link from the sender's desktop machine to the recipient's, cutting out
134 any sort of network snoop. What it cannot ensure is end-to-end
135 user-to-user security. If only IPsec is used to secure mail, then
136 anyone with appropriate privileges on any machine where that mail is
137 stored (at either end or on any store-and-forward servers in the path)
139 <P>In another common setup, IPsec encrypts packets at a security gateway
140 machine as they leave the sender's site and decrypts them on arrival at
141 the gateway to the recipient's site. This does provide a useful
142 security service -- only encrypted data is passed over the Internet --
143 but it does not even come close to providing an end-to-end service. In
144 particular, anyone with appropriate privileges on either site's LAN can
145 intercept the message in unencrypted form.
</P>
147 <DT><A name=
"notpanacea">IPsec cannot do everything
</A></DT>
148 <DD>IPsec also cannot provide all the functions of systems working at
149 higher levels of the protocol stack. If you need a document
150 electronically signed by a particular person, then you need his or her
<A
151 href=
"glossary.html#signature"> digital signature
</A> and a
<A href=
"glossary.html#public">
152 public key cryptosystem
</A> to verify it with.
153 <P>Note, however, that IPsec authentication of the underlying
154 communication can make various attacks on higher-level protocols more
155 difficult. In particular, authentication prevents
<A href=
"glossary.html#middle">
156 man-in-the-middle attacks
</A>.
</P>
158 <DT><A name=
"no_user">IPsec authenticates machines, not users
</A></DT>
159 <DD>IPsec uses strong authentication mechanisms to control which
160 messages go to which machines, but it does not have the concept of user
161 ID, which is vital to many other security mechansims and policies. This
162 means some care must be taken in fitting the various security
163 mechansims on a network together. For example, if you need to control
164 which users access your database server, you need some non-IPsec
165 mechansim for that. IPsec can control which machines connect to the
166 server, and can ensure that data transfer to those machines is done
167 securely, but that is all. Either the machines themselves must control
168 user access or there must be some form of user authentication to the
169 database, independent of IPsec.
</DD>
170 <DT><A name=
"DoS">IPsec does not stop denial of service attacks
</A></DT>
171 <DD><A href=
"glossary.html#DOS">Denial of service
</A> attacks aim at
172 causing a system to crash, overload, or become confused so that
173 legitimate users cannot get whatever services the system is supposed to
174 provide. These are quite different from attacks in which the attacker
175 seeks either to use the service himself or to subvert the service into
176 delivering incorrect results.
177 <P>IPsec shifts the ground for DoS attacks; the attacks possible against
178 systems using IPsec are different than those that might be used against
179 other systems. It does not, however, eliminate the possibility of such
182 <DT><A name=
"traffic">IPsec does not stop traffic analysis
</A></DT>
183 <DD><A href=
"glossary.html#traffic">Traffic analysis
</A> is the attempt
184 to derive intelligence from messages without regard for their contents.
185 In the case of IPsec, it would mean analysis based on things visible in
186 the unencrypted headers of encrypted packets -- source and destination
187 gateway addresses, packet size, et cetera. Given the resources to
188 acquire such data and some skill in analysing it (both of which any
189 national intelligence agency should have), this can be a very powerful
191 <P>IPsec is not designed to defend against this. Partial defenses are
192 certainly possible, and some are
<A href=
"#traffic.resist"> described
193 below
</A>, but it is not clear that any complete defense can be
197 <H3><A name=
"uses">IPsec is a general mechanism for securing IP
</A></H3>
198 <P>While IPsec does not provide all functions of a mail encryption
199 package, it can encrypt your mail. In particular, it can ensure that
200 all mail passing between a pair or a group of sites is encrypted. An
201 attacker looking only at external traffic, without access to anything
202 on or behind the IPsec gateway, cannot read your mail. He or she is
203 stymied by IPsec just as he or she would be by
<A href=
"glossary.html#PGP">
205 <P>The advantage is that IPsec can provide the same protection for
<STRONG>
206 anything transmitted over IP
</STRONG>. In a corporate network example,
207 PGP lets the branch offices exchange secure mail with head office. SSL
208 and SSH allow them to securely view web pages, connect as terminals to
209 machines, and so on. IPsec can support all those applications, plus
210 database queries, file sharing (NFS or Windows), other protocols
211 encapsulated in IP (Netware, Appletalk, ...), phone-over-IP,
212 video-over-IP, ... anything-over-IP. The only limitation is that IP
213 Multicast is not yet supported, though there are Internet Draft
214 documents for that.
</P>
215 <P>IPsec creates
<STRONG> secure tunnels through untrusted networks
</STRONG>
216 . Sites connected by these tunnels form VPNs,
<A href=
"glossary.html#VPN">
217 Virtual Private Networks
</A>.
</P>
218 <P>IPsec gateways can be installed wherever they are required.
</P>
220 <LI>One organisation might choose to install IPsec only on firewalls
221 between their LANs and the Internet. This would allow them to create a
222 VPN linking several offices. It would provide protection against anyone
223 outside their sites.
</LI>
224 <LI>Another might install IPsec on departmental servers so everything on
225 the corporate backbone net was encrypted. This would protect messages
226 on that net from everyone except the sending and receiving department.
</LI>
227 <LI>Another might be less concerned with information secrecy and more
228 with controlling access to certain resources. They might use IPsec
229 packet authentication as part of an access control mechanism, with or
230 without also using the IPsec encryption service.
</LI>
231 <LI>It is even possible (assuming adequate processing power and an IPsec
232 implementation in each node) to make every machine its own IPsec
233 gateway so that everything on a LAN is encrypted. This protects
234 information from everyone outside the sending and receiving machine.
</LI>
235 <LI>These techniques can be combined in various ways. One might, for
236 example, require authentication everywhere on a network while using
237 encryption only for a few links.
</LI>
239 <P>Which of these, or of the many other possible variants, to use is up
240 to you.
<STRONG> IPsec provides mechanisms; you provide the policy
</STRONG>
242 <P><STRONG>No end user action is required
</STRONG> for IPsec security to
243 be used; they don't even have to know about it. The site
244 administrators, of course, do have to know about it and to put some
245 effort into making it work. Poor administration can compromise IPsec as
246 badly as the post-it notes mentioned above. It seems reasonable,
247 though, for organisations to hope their system administrators are
248 generally both more security-conscious than end users and more able to
249 follow computer security procedures. If not, at least there are fewer
250 of them to educate or replace.
</P>
251 <P>IPsec can be, and often should be, used with along with security
252 protocols at other levels. If two sites communicate with each other via
253 the Internet, then IPsec is the obvious way to protect that
254 communication. If two others have a direct link between them, either
255 link encryption or IPsec would make sense. Choose one or use both.
256 Whatever you use at and below the IP level, use other things as
257 required above that level. Whatever you use above the IP level,
258 consider what can be done with IPsec to make attacks on the higher
259 levels harder. For example,
<A href=
"glossary.html#middle">
260 man-in-the-middle attacks
</A> on various protocols become difficult if
261 authentication at packet level is in use on the potential victims'
262 communication channel.
</P>
263 <H3><A name=
"authonly">Using authentication without encryption
</A></H3>
264 <P>Where appropriate, IPsec can provide authentication without
265 encryption. One might do this, for example:
</P>
267 <LI>where the data is public but one wants to be sure of getting the
268 right data, for example on some web sites
</LI>
269 <LI>where encryption is judged unnecessary, for example on some company
270 or department LANs
</LI>
271 <LI>where strong encryption is provided at link level, below IP
</LI>
272 <LI>where strong encryption is provided in other protocols, above IP
273 <BR> Note that IPsec authentication may make some attacks on those
274 protocols harder.
</LI>
276 <P>Authentication has lower overheads than encryption.
</P>
277 <P>The protocols provide four ways to build such connections, using
278 either an AH-only connection or ESP using null encryption, and in
279 either manually or automatically keyed mode. FreeS/WAN supports only
280 one of these, manually keyed AH-only connections, and
<STRONG> we do not
281 recommend using that
</STRONG>. Our reasons are discussed under
<A href=
"#traffic.resist">
282 Resisting traffic analysis
</A> a few sections further along.
</P>
283 <H3><A name=
"encnoauth">Encryption without authentication is dangerous
</A>
285 <P>Originally, the IPsec encryption protocol
<A href=
"glossary.html#ESP">
286 ESP
</A> didn't do integrity checking. It only did encryption. Steve
287 Bellovin found many ways to attack ESP used without authentication. See
288 his paper
<A href=
"http://www.research.att.com/~smb/papers/badesp.ps">
289 Problem areas for the IP Security Protocols
</A>. To make a secure
290 connection, you had to add an
<A href=
"glossary.html#AH"> AH
</A>
291 Authentication Header as well as ESP. Rather than incur the overhead of
292 several layers (and rather than provide an ESP layer that didn't
293 actually protect the traffic), the IPsec working group built integrity
294 and replay checking directly into ESP.
</P>
295 <P>Today, typical usage is one of:
</P>
297 <LI>ESP for encryption and authentication
</LI>
298 <LI>AH for authentication alone
</LI>
300 <P>Other variants are allowed by the standard, but not much used:
</P>
302 <DT>ESP encryption without authentication
</DT>
303 <DD><STRONG>Bellovin has demonstrated fatal flaws in this. Do not use.
</STRONG>
305 <DT>ESP encryption with AH authentication
</DT>
306 <DD>This has higher overheads than using the authentication in ESP, and
307 no obvious benefit in most cases. The exception might be a network
308 where AH authentication was widely or universally used. If you're going
309 to do AH to conform with network policy, why authenticate again in the
311 <DT>Authenticate twice, with AH and with ESP
</DT>
312 <DD>Why? Of course, some folk consider
"belt and suspenders
" the
313 sensible approach to security. If you're among them, you might use both
314 protocols here. You might also use both to satisfy different parts of a
315 security policy. For example, an organisation might require AH
316 authentication everywhere but two users within the organisation might
317 use ESP as well.
</DD>
318 <DT>ESP authentication without encryption
</DT>
319 <DD>The standard allows this, calling it
"null encryption
". FreeS/WAN
320 does not support it. We recommend that you use AH instead if
321 authentication is all you require. AH authenticates parts of the IP
322 header, which ESP-null does not do.
</DD>
324 <P>Some of these variants cannot be used with FreeS/WAN because we do
325 not support ESP-null and do not support automatic keying of AH-only
327 <P>There are fairly frequent suggestions that AH be dropped entirely
328 from the IPsec specifications since ESP and null encryption can handle
329 that situation. It is not clear whether this will occur. My guess is
330 that it is unlikely.
</P>
331 <H3><A name=
"multilayer">Multiple layers of IPsec processing are
333 <P>The above describes combinations possible on a single IPsec
334 connection. In a complex network you may have several layers of IPsec
335 in play, with any of the above combinations at each layer.
</P>
336 <P>For example, a connection from a desktop machine to a database server
337 might require AH authentication. Working with other host, network and
338 database security measures, AH might be just the thing for access
339 control. You might decide not to use ESP encryption on such packets,
340 since it uses resources and might complicate network debugging. Within
341 the site where the server is, then, only AH would be used on those
343 <P>Users at another office, however, might have their whole connection
344 (AH headers and all) passing over an IPsec tunnel connecting their
345 office to the one with the database server. Such a tunnel should use
346 ESP encryption and authentication. You need authentication in this
347 layer because without authentication the encryption is vulnerable and
348 the gateway cannot verify the AH authentication. The AH is between
349 client and database server; the gateways aren't party to it.
</P>
350 <P>In this situation, some packets would get multiple layers of IPsec
351 applied to them, AH on an end-to-end client-to-server basis and ESP
352 from one office's security gateway to the other.
</P>
353 <H3><A name=
"traffic.resist">Resisting traffic analysis
</A></H3>
354 <P><A href=
"glossary.html#traffic">Traffic analysis
</A> is the attempt
355 to derive useful intelligence from encrypted traffic without breaking
357 <P>Is your CEO exchanging email with a venture capital firm? With
358 bankruptcy trustees? With an executive recruiting agency? With the
359 holder of some important patents? If an eavesdropper learns about any
360 of those, then he has interesting intelligence on your company, whether
361 or not he can read the messages themselves.
</P>
362 <P>Even just knowing that there is network traffic between two sites may
363 tell an analyst something useful, especially when combined with
364 whatever other information he or she may have. For example, if you know
365 Company A is having cashflow problems and Company B is looking for
366 aquisitions, then knowing that packets are passing between the two is
367 interesting. It is more interesting if you can tell it is email, and
368 perhaps yet more if you know the sender and recipient.
</P>
369 <P>Except in the simplest cases, traffic analysis is hard to do well. It
370 requires both considerable resources and considerable analytic skill.
371 However, intelligence agencies of various nations have been doing it
372 for centuries and many of them are likely quite good at it by now.
373 Various commercial organisations, especially those working on
"targeted
374 marketing
" may also be quite good at analysing certain types of
376 <P>In general, defending against traffic analysis is also difficult.
377 Inventing a really good defense could get you a PhD and some
378 interesting job offers.
</P>
379 <P>IPsec is not designed to stop traffic analysis and we know of no
380 plausible method of extending it to do so. That said, there are ways to
381 make traffic analysis harder. This section describes them.
</P>
382 <H4><A name=
"extra">Using
"unnecessary
" encryption
</A></H4>
383 <P>One might choose to use encryption even where it appears unnecessary
384 in order to make analysis more difficult. Consider two offices which
385 pass a small volume of business data between them using IPsec and also
386 transfer large volumes of Usenet news. At first glance, it would seem
387 silly to encrypt the newsfeed, except possibly for any newsgroups that
388 are internal to the company. Why encrypt data that is all publicly
389 available from many sites?
</P>
390 <P>However, if we encrypt a lot of news and send it down the same
391 connection as our business data, we make
<A href=
"glossary.html#traffic">
392 traffic analysis
</A> much harder. A snoop cannot now make inferences
393 based on patterns in the volume, direction, sizes, sender, destination,
394 or timing of our business messages. Those messages are hidden in a mass
395 of news messages encapsulated in the same way.
</P>
396 <P>If we're going to do this we need to ensure that keys change often
397 enough to remain secure even with high volumes and with the adversary
398 able to get plaintext of much of the data. We also need to look at
399 other attacks this might open up. For example, can the adversary use a
400 chosen plaintext attack, deliberately posting news articles which, when
401 we receive and encrypt them, will help break our encryption? Or can he
402 block our business data transmission by flooding us with silly news
404 <P>Also, note that this does not provide complete protection against
405 traffic analysis. A clever adversary might still deduce useful
406 intelligence from statistical analysis (perhaps comparing the input
407 newsfeed to encrypted output, or comparing the streams we send to
408 different branch offices), or by looking for small packets which might
409 indicate establishment of TCP connections, or ...
</P>
410 <P>As a general rule, though, to improve resistance to traffic analysis,
411 you should
<STRONG> encrypt as much traffic as possible, not just as
412 much as seems necessary.
</STRONG></P>
413 <H4><A name=
"multi-encrypt">Using multiple encryption
</A></H4>
414 <P>This also applies to using multiple layers of encryption. If you have
415 an IPsec tunnel between two branch offices, it might appear silly to
416 send
<A href=
"glossary.html#PGP"> PGP
</A>-encrypted email through that
417 tunnel. However, if you suspect someone is snooping your traffic, then
418 it does make sense:
</P>
420 <LI>it protects the mail headers; they cannot even see who is mailing
422 <LI>it protects against user bungles or software malfunctions that
423 accidentally send messages in the clear
</LI>
424 <LI>it makes any attack on the mail encryption much harder; they have to
425 break IPsec or break into your network before they can start on the
428 <P>Similar arguments apply for
<A href=
"glossary.html#SSL"> SSL
</A>
429 -encrypted web traffic or
<A href=
"glossary.html#SSH"> SSH
</A>-encrypted
430 remote login sessions, even for end-to-end IPsec tunnels between
431 systems in the two offices.
</P>
432 <H4><A name=
"fewer">Using fewer tunnels
</A></H4>
433 <P>It may also help to use fewer tunnels. For example, if all you
434 actually need encrypted is connections between:
</P>
436 <LI>mail servers at branch and head offices
</LI>
437 <LI>a few branch office users and the head office database server
</LI>
439 <P>You might build one tunnel per mail server and one per remote
440 database user, restricting traffic to those applications. This gives
441 the traffic analyst some information, however. He or she can
442 distinguish the tunnels by looking at information in the ESP header
443 and, given that distinction and the patterns of tunnel usage, might be
444 able to figure out something useful. Perhaps not, but why take the
446 <P>We suggest instead that you build one tunnel per branch office,
447 encrypting everything passing from head office to branches. This has a
448 number of advantages:
</P>
450 <LI>it is easier to build and administer
</LI>
451 <LI>it resists traffic analysis somewhat better
</LI>
452 <LI>it provides security for whatever you forgot. For example, if some
453 user at a remote office browses proprietary company data on some head
454 office web page (that the security people may not even know about!),
455 then that data is encrypted before it reaches the Internet.
</LI>
457 <P>Of course you might also want to add additional tunnels. For example,
458 if some of the database data is confidential and should not be exposed
459 even within the company, then you need protection from the user's
460 desktop to the database server. We suggest you do that in whatever way
461 seems appropriate -- IPsec, SSH or SSL might fit -- but, whatever you
462 choose, pass it between locations via a gateway-to-gateway IPsec tunnel
463 to provide some resistance to traffic analysis.
</P>
464 <H2><A name=
"primitives">Cryptographic components
</A></H2>
465 <P>IPsec combines a number of cryptographic techniques, all of them
466 well-known and well-analyzed. The overall design approach was
467 conservative; no new or poorly-understood components were included.
</P>
468 <P>This section gives a brief overview of each technique. It is intended
469 only as an introduction. There is more information, and links to
470 related topics, in our
<A href=
"glossary.html"> glossary
</A>. See also
471 our
<A href=
"biblio.html"> bibliography
</A> and cryptography
<A href=
"web.html#crypto.link">
473 <H3><A name=
"block.cipher">Block ciphers
</A></H3>
474 <P>The
<A href=
"glossary.html#encryption"> encryption
</A> in the
<A href=
"glossary.html#ESP">
475 ESP
</A> encapsulation protocol is done with a
<A href=
"glossary.html#block">
476 block cipher
</A>.
</P>
477 <P>We do not implement
<A href=
"glossary.html#DES"> single DES
</A>. It is
<A
478 href=
"politics.html#desnotsecure"> insecure
</A>. Our default, and
479 currently only, block cipher is
<A href=
"glossary.html#3DES"> triple DES
</A>
481 <P>The
<A href=
"glossary.html#rijndael"> Rijndael
</A> block cipher has
482 won the
<A href=
"glossary.html#AES"> AES
</A> competition to choose a
483 relacement for DES. It will almost certainly be added to FreeS/WAN and
484 to other IPsec implementations.
<A href=
"web.html#patch"> Patches
</A>
485 are already available.
</P>
486 <H3><A name=
"hash.ipsec">Hash functions
</A></H3>
487 <H4><A name=
"hmac.ipsec">The HMAC construct
</A></H4>
488 <P>IPsec packet authentication is done with the
<A href=
"glossary.html#HMAC">
489 HMAC
</A> construct. This is not just a hash of the packet data, but a
490 more complex operation which uses both a hashing algorithm and a key.
491 It therefore does more than a simple hash would. A simple hash would
492 only tell you that the packet data was not changed in transit, or that
493 whoever changed it also regenerated the hash. An HMAC also tells you
494 that the sender knew the HMAC key.
</P>
495 <P>For IPsec HMAC, the output of the hash algorithm is truncated to
96
496 bits. This saves some space in the packets. More important, it prevents
497 an attacker from seeing all the hash output bits and perhaps creating
498 some sort of attack based on that knowledge.
</P>
499 <H4>Choice of hash algorithm
</H4>
500 <P>The IPsec RFCs require two hash algorithms --
<A href=
"glossary.html#MD5">
501 MD5
</A> and
<A href=
"glossary.html#SHA"> SHA-
1</A> -- both of which
502 FreeS/WAN implements.
</P>
503 <P>Various other algorithms -- such as RIPEMD and Tiger -- are listed in
504 the RFCs as optional. None of these are in the FreeS/WAN distribution,
505 or are likely to be added, although user
<A href=
"web.html#patch">
506 patches
</A> exist for several of them.
</P>
507 <P>Additional hash algorithms --
<A href=
"glossary.html#SHA-256">
508 SHA-
256, SHA-
384 and SHA-
512</A> -- may be required to give hash
509 strength matching the strength of
<A href=
"glossary.html#AES"> AES
</A>.
510 These are likely to be added to FreeS/WAN along with AES.
</P>
511 <H3><A name=
"DH.keying">Diffie-Hellman key agreement
</A></H3>
512 <P>The
<A href=
"glossary.html#DH"> Diffie-Hellman
</A> key agreement
513 protocol allows two parties (A and B or
<A href=
"glossary.html#alicebob">
514 Alice and Bob
</A>) to agree on a key in such a way that an eavesdropper
515 who intercepts the entire conversation cannot learn the key.
</P>
516 <P>The protocol is based on the
<A href=
"glossary.html#dlog"> discrete
517 logarithm
</A> problem and is therefore thought to be secure.
518 Mathematicians have been working on that problem for years and seem no
519 closer to a solution, though there is no proof that an efficient
520 solution is impossible.
</P>
521 <H3><A name=
"RSA.auth">RSA authentication
</A></H3>
522 <P>The
<A href=
"glossary.html#RSA"> RSA
</A> algorithm (named for its
523 inventors -- Rivest, Shamir and Adleman) is a very widely used
<A href=
"glossary.html#">
524 public key
</A> cryptographic technique. It is used in IPsec as one
525 method of authenticating gateways for Diffie-Hellman key negotiation.
</P>
526 <H2><A name=
"structure">Structure of IPsec
</A></H2>
527 <P>There are three protocols used in an IPsec implementation:
</P>
529 <DT>ESP, Encapsulating Security Payload
</DT>
530 <DD>Encrypts and/or authenticates data
</DD>
531 <DT>AH, Authentication Header
</DT>
532 <DD>Provides a packet authentication service
</DD>
533 <DT>IKE, Internet Key Exchange
</DT>
534 <DD>Negotiates connection parameters, including keys, for the other two
</DD>
536 <P>The term
"IPsec
" is slightly ambiguous. In some contexts, it includes
537 all three of the above but in other contexts it refers only to AH and
539 <H3><A name=
"IKE.ipsec">IKE (Internet Key Exchange)
</A></H3>
540 <P>The IKE protocol sets up IPsec (ESP or AH) connections after
541 negotiating appropriate parameters (algorithms to be used, keys,
542 connection lifetimes) for them. This is done by exchanging packets on
543 UDP port
500 between the two gateways.
</P>
544 <P>IKE (RFC
2409) was the outcome of a long, complex process in which
545 quite a number of protocols were proposed and debated. Oversimplifying
546 mildly, IKE combines:
</P>
548 <DT>ISAKMP (RFC
2408)
</DT>
549 <DD>The
<STRONG> I
</STRONG>nternet
<STRONG> S
</STRONG>ecurity
<STRONG> A
</STRONG>
550 ssociation and
<STRONG> K
</STRONG>ey
<STRONG> M
</STRONG>anagement
<STRONG>
551 P
</STRONG>rotocol manages negotiation of connections and defines
<A href=
"glossary.html#SA">
552 SA
</A>s (Security Associations) as a means of describing connection
554 <DT>IPsec DOI for ISAKMP (RFC
2407)
</DT>
555 <DD>A
<STRONG> D
</STRONG>omain
<STRONG> O
</STRONG>f
<STRONG> I
</STRONG>
556 nterpretation fills in the details necessary to turn the rather abstract
557 ISAKMP protocol into a more tightly specified protocol, so it becomes
558 applicable in a particular domain.
</DD>
559 <DT>Oakley key determination protocol (RFC
2412)
</DT>
560 <DD>Oakley creates keys using the
<A href=
"glossary.html#DH">
561 Diffie-Hellman
</A> key agreement protocol.
</DD>
563 <P>For all the details, you would need to read the four
<A href=
"rfc.html">
564 RFCs
</A> just mentioned (over
200 pages) and a number of others. We
565 give a summary below, but it is far from complete.
</P>
566 <H4><A name=
"phases">Phases of IKE
</A></H4>
567 <P>IKE negotiations have two phases.
</P>
570 <DD>The two gateways negotiate and set up a two-way ISAKMP SA which they
571 can then use to handle phase two negotiations. One such SA between a
572 pair of gateways can handle negotiations for multiple tunnels.
</DD>
574 <DD>Using the ISAKMP SA, the gateways negotiate IPsec (ESP and/or AH)
575 SAs as required. IPsec SAs are unidirectional (a different key is used
576 in each direction) and are always negotiated in pairs to handle two-way
577 traffic. There may be more than one pair defined between two gateways.
</DD>
579 <P>Both of these phases use the UDP protocol and port
500 for their
581 <P>After both IKE phases are complete, you have IPsec SAs to carry your
582 encrypted data. These use the ESP or AH protocols. These protocols do
583 not have ports. Ports apply only to UDP or TCP.
</P>
584 <P>The IKE protocol is designed to be extremely flexible. Among the
585 things that can be negotiated (separately for each SA) are:
</P>
587 <LI>SA lifetime before rekeying
</LI>
588 <LI>encryption algorithm used. We currently support only
<A href=
"glossary.html#3DES">
589 triple DES
</A>. Single DES is
<A href=
"politics.html#desnotsecure">
590 insecure
</A>. The RFCs say you MUST do DES, SHOULD do
3DES and MAY do
591 various others. We do not do any of the others.
</LI>
592 <LI>authentication algorithms. We support
<A href=
"glossary.html#MD5">
593 MD5
</A> and
<A href=
"glossary.html#SHA"> SHA
</A>. These are the two the
595 <LI>choice of group for
<A href=
"glossary.html#DH"> Diffie-Hellman
</A>
596 key agreement. We currently support Groups
2 and
5 (which are defined
597 modulo primes of various lengths) and do not support Group
1 (defined
598 modulo a shorter prime, and therefore cryptographically weak) or groups
599 3 and
4 (defined using elliptic curves). The RFCs require only Group
1.
</LI>
601 <P>The protocol also allows implementations to add their own encryption
602 algorithms, authentication algorithms or Diffie-Hellman groups. We do
603 not support any such extensions, but there are some
<A href=
"web.html#patch">
604 patches
</A> that do.
</P>
605 <P>There are a number of complications:
</P>
607 <LI>The gateways must be able to authenticate each other's identities
608 before they can create a secure connection. This host authentication is
609 part of phase one negotiations, and is a required prerequisite for
610 packet authentication used later. Host authentication can be done in a
611 variety of ways. Those supported by FreeS/WAN are discussed in our
<A href=
"adv_config.html#auto-auth">
612 advanced configuration
</A> document.
</LI>
613 <LI>Phase one can be done in two ways.
615 <LI>Main Mode is required by the RFCs and supported in FreeS/WAN. It
616 uses a
6-packet exzchange.
</LI>
617 <LI>Aggressive Mode is somewhat faster (only
3 packets) but reveals more
618 to an eavesdropper. This is optional in the RFCs, not currently
619 supported by FreeS/WAN, and not likely to be.
</LI>
622 <LI>A new group exchange may take place after phase one but before phase
623 two, defining an additional group for use in the
<A href=
"glossary.html#DH">
624 Diffie-Hellman
</A> key agreement part of phase two. FreeS/WAN does not
625 currently support this.
</LI>
626 <LI>Phase two always uses Quick Mode, but there are two variants of
629 <LI>One variant provides
<A href=
"glossary.html#PFS"> Perfect Forward
630 Secrecy (PFS)
</A>. An attacker that obtains your long-term host
631 authentication key does not immediately get any of your short-term
632 packet encryption of packet authentication keys. He must conduct
633 another successful attack each time you rekey to get the short-term
634 keys. Having some short-term keys does not help him learn others. In
635 particular, breaking your system today does not let him read messages
636 he archived yestarday, assuming you've changed short-term keys in the
637 meanwhile. We enable PFS as the default.
</LI>
638 <LI>The other variant disables PFS and is therefore slightly faster. We
639 do not recommend this since it is less secure, but FreeS/WAN does
640 support it. You can enable it with a
<VAR> pfs=no
</VAR> statement in
<A href=
"manpage.d/ipsec.conf.5.html">
641 ipsec.conf(
5)
</A>.
</LI>
642 <LI>The protocol provides no way to negotiate which variant will be
643 used. If one gateway is set for PFS and the other is not, the
644 negotiation fails. This has proved a fairly common source of
645 interoperation problems.
</LI>
648 <LI>Several types of notification message may be sent by either side
649 during either phase, or later. FreeS/WAN does not currently support
650 these, but they are a likely addition in future releases.
</LI>
651 <LI>There is a commit flag which may optionally be set on some messages.
652 The
<A href=
"http://www.lounge.org/ike_doi_errata.html"> errata
</A> page
653 for the RFCs includes two changes related to this, one to clarify the
654 description of its use and one to block a
<A href=
"glossary.html#DOS">
655 denial of service
</A> attack which uses it. We currently do not
656 implement this feature.
</LI>
658 <P>These complications can of course lead to problems, particularly when
659 two different implementations attempt to interoperate. For example, we
660 have seen problems such as:
</P>
662 <LI>Some implementations (often products crippled by
<A href=
"politics.html#exlaw">
663 export laws
</A>) have the insecure DES algorithm as their only
664 supported encryption method. Other parts of our documentation discuss
665 the
<A href=
"politics.html#desnotsecure"> reasons we do not implement
666 single DES
</A>, and
<A href=
"interop.html#noDES"> how to cope with
667 crippled products
</A>.
</LI>
668 <LI>Windows
2000 IPsec tries to negotiate using Aggressive Mode, which
669 we don't support. Later on, it uses the commit bit, which we also don't
671 <LI>Various implementations disable PFS by default, and therefore will
672 not talk to FreeS/WAN until you either turn on PFS on their end or turn
673 it off in FreeS/WAN with a
<VAR> pfs=no
</VAR> entry in the connection
675 <LI>FreeS/WAN's interaction with PGPnet is complicated by their use of
676 notification messages we do not yet support.
</LI>
678 <P>Despite this, we do interoperate successfully with many
679 implementations, including both Windows
2000 and PGPnet. Details are in
680 our
<A href=
"interop.html"> interoperability
</A> document.
</P>
681 <H4><A name=
"sequence">Sequence of messages in IKE
</A></H4>
682 <P>Each phase (see
<A href=
"#phases"> previous section
</A>)of IKE
683 involves a series of messages. In Pluto error messages, these are
684 abbreviated using:
</P>
687 <DD><STRONG>M
</STRONG>ain mode, settting up the keying channel (ISAKMP
690 <DD><STRONG>Q
</STRONG>uick mode, setting up the data channel (IPsec SA)
</DD>
692 <DD><STRONG>I
</STRONG>nitiator, the machine that starts the negotiation
</DD>
694 <DD><STRONG>R
</STRONG>esponder
</DD>
696 <P>For example, the six messages of a main mode negotiation, in
697 sequence, are labelled:
</P>
698 <PRE> MI1 ----------
>
703 <---------- MR3
</PRE>
704 <H4><A name=
"struct.exchange">Structure of IKE messages
</A></H4>
705 <P>Here is our Pluto developer explaining some of this on the mailing
707 <PRE>When one IKE system (for example, Pluto) is negotiating with another
708 to create an SA, the Initiator proposes a bunch of choices and the
709 Responder replies with one that it has selected.
711 The structure of the choices is fairly complicated. An SA payload
712 contains a list of lists of
"Proposals
". The outer list is a set of
713 choices: the selection must be from one element of this list.
715 Each of these elements is a list of Proposals. A selection must be
716 made from each of the elements of the inner list. In other words,
717 *all* of them apply (that is how, for example, both AH and ESP can
720 Within each of these Proposals is a list of Transforms. For each
721 Proposal selected, one Transform must be selected (in other words,
722 each Proposal provides a choice of Transforms).
724 Each Transform is made up of a list of Attributes describing, well,
725 attributes. Such as lifetime of the SA. Such as algorithm to be
726 used. All the Attributes apply to a Transform.
728 You will have noticed a pattern here: layers alternate between being
729 disjunctions (
"or
") and conjunctions (
"and
").
731 For Phase
1 / Main Mode (negotiating an ISAKMP SA), this structure is
732 cut back. There must be exactly one Proposal. So this degenerates to
733 a list of Transforms, one of which must be chosen.
</PRE>
734 <H3><A name=
"services">IPsec Services, AH and ESP
</A></H3>
735 <P>IPsec offers two services,
<A href=
"glossary.html#authentication">
736 authentication
</A> and
<A href=
"glossary.html#encryption"> encryption
</A>
737 . These can be used separately but are often used together.
</P>
739 <DT>Authentication
</DT>
740 <DD>Packet-level authentication allows you to be confident that a packet
741 came from a particular machine and that its contents were not altered
742 en route to you. No attempt is made to conceal or protect the contents,
743 only to assure their integrity. Packet authentication can be provided
744 separately using an
<A href=
"glossary.html#AH"> Authentication Header
</A>
745 , described just below, or it can be included as part of the
<A href=
"glossary.html#ESP">
746 ESP
</A> (Encapsulated Security Payload) service, described in the
747 following section. That service offers encryption as well as
748 authentication. In either case, the
<A href=
"glossary.html#HMAC"> HMAC
</A>
749 construct is used as the authentication mechanism.
750 <P>There is a separate authentication operation at the IKE level, in
751 which each gateway authenticates the other. This can be done in a
755 <DD>Encryption allows you to conceal the contents of a message from
757 <P>In IPsec this is done using a
<A href=
"glossary.html#block"> block
758 cipher
</A> (normally
<A href=
"glossary.html#3DES"> Triple DES
</A> for
759 Linux). In the most used setup, keys are automatically negotiated, and
760 periodically re-negotiated, using the
<A href=
"glossary.html#IKE"> IKE
</A>
761 (Internet Key Exchange) protocol. In Linux FreeS/WAN this is handled by
762 the Pluto Daemon.
</P>
763 <P>The IPsec protocol offering encryption is
<A href=
"glossary.html#ESP">
764 ESP
</A>, Encapsulated Security Payload. It can also include a packet
765 authentication service.
</P>
768 <P>Note that
<STRONG> encryption should always be used with some packet
769 authentication service
</STRONG>. Unauthenticated encryption is
770 vulnerable to
<A href=
"glossary.html#middle"> man-in-the-middle attacks
</A>
771 . Also note that encryption does not prevent
<A href=
"glossary.html#traffic">
772 traffic analysis
</A>.
</P>
773 <H3><A name=
"AH.ipsec">The Authentication Header (AH)
</A></H3>
774 <P>Packet authentication can be provided separately from encryption by
775 adding an authentication header (AH) after the IP header but before the
776 other headers on the packet. This is the subject of this section.
777 Details are in RFC
2402.
</P>
778 <P>Each of the several headers on a packet header contains a
"next
779 protocol
" field telling the system what header to look for next. IP
780 headers generally have either TCP or UDP in this field. When IPsec
781 authentication is used, the packet IP header has AH in this field,
782 saying that an Authentication Header comes next. The AH header then has
783 the next header type -- usually TCP, UDP or encapsulated IP.
</P>
784 <P>IPsec packet authentication can be added in transport mode, as a
785 modification of standard IP transport. This is shown in this diagram
787 <PRE> BEFORE APPLYING AH
788 ----------------------------
789 IPv4 |orig IP hdr | | |
790 |(any options)| TCP | Data |
791 ----------------------------
794 ---------------------------------
795 IPv4 |orig IP hdr | | | |
796 |(any options)| AH | TCP | Data |
797 ---------------------------------
799 except for mutable fields
</PRE>
800 <P>Athentication can also be used in tunnel mode, encapsulating the
801 underlying IP packet beneath AH and an additional IP header.
</P>
803 IPv4 | new IP hdr* | | orig IP hdr* | | |
804 |(any options)| AH | (any options) |TCP | Data |
805 ------------------------------------------------
807 | in the new IP hdr |
</PRE>
808 <P>This would normally be used in a gateway-to-gateway tunnel. The
809 receiving gateway then strips the outer IP header and the AH header and
810 forwards the inner IP packet.
</P>
811 <P>The mutable fields referred to are things like the time-to-live field
812 in the IP header. These cannot be included in authentication
813 calculations because they change as the packet travels.
</P>
814 <H4><A name=
"keyed">Keyed MD5 and Keyed SHA
</A></H4>
815 <P>The actual authentication data in the header is typically
96 bits and
816 depends both on a secret shared between sender and receiver and on
817 every byte of the data being authenticated. The technique used is
<A href=
"glossary.html#HMAC">
818 HMAC
</A>, defined in RFC
2104.
</P>
819 <P>The algorithms involved are the
<A href=
"glossary.html#MD5"> MD5
</A>
820 Message Digest Algorithm or
<A href=
"glossary.html#SHA"> SHA
</A>, the
821 Secure Hash Algorithm. For details on their use in this application,
822 see RFCs
2403 and
2404 respectively.
</P>
823 <P>For descriptions of the algorithms themselves, see RFC
1321 for MD5
824 and
<A href=
"glossary.html#FIPS"> FIPS
</A> (Federal Information
825 Processing Standard) number
186 from
<A href=
"glossary.html#NIST"> NIST
</A>
826 , the US National Institute of Standards and Technology for SHA.
<A href=
"biblio.html#schneier">
827 <CITE> Applied Cryptography
</CITE></A> covers both in some detail, MD5
828 starting on page
436 and SHA on
442.
</P>
829 <P>These algorithms are intended to make it nearly impossible for anyone
830 to alter the authenticated data in transit. The sender calculates a
831 digest or hash value from that data and includes the result in the
832 authentication header. The recipient does the same calculation and
833 compares results. For unchanged data, the results will be identical.
834 The hash algorithms are designed to make it extremely difficult to
835 change the data in any way and still get the correct hash.
</P>
836 <P>Since the shared secret key is also used in both calculations, an
837 interceptor cannot simply alter the authenticated data and change the
838 hash value to match. Without the key, he or she (or even the dreaded
839 They) cannot produce a usable hash.
</P>
840 <H4><A name=
"sequence">Sequence numbers
</A></H4>
841 <P>The authentication header includes a sequence number field which the
842 sender is required to increment for each packet. The receiver can
843 ignore it or use it to check that packets are indeed arriving in the
844 expected sequence.
</P>
845 <P>This provides partial protection against
<A href=
"glossary.html#replay">
846 replay attacks
</A> in which an attacker resends intercepted packets in
847 an effort to confuse or subvert the receiver. Complete protection is
848 not possible since it is necessary to handle legitmate packets which
849 are lost, duplicated, or delivered out of order, but use of sequence
850 numbers makes the attack much more difficult.
</P>
851 <P>The RFCs require that sequence numbers never cycle, that a new key
852 always be negotiated before the sequence number reaches
2^
32-
1. This
853 protects both against replays attacks using packets from a previous
854 cyclce and against
<A href=
"glossary.html#birthday"> birthday attacks
</A>
855 on the the packet authentication algorithm.
</P>
856 <P>In Linux FreeS/WAN, the sequence number is ignored for manually keyed
857 connections and checked for automatically keyed ones. In manual mode,
858 there is no way to negotiate a new key, or to recover from a sequence
859 number problem, so we don't use sequence numbers.
</P>
860 <H3><A name=
"ESP.ipsec">Encapsulated Security Payload (ESP)
</A></H3>
861 <P>The ESP protocol is defined in RFC
2406. It provides one or both of
862 encryption and packet authentication. It may be used with or without AH
863 packet authentication.
</P>
864 <P>Note that
<STRONG> some form of packet authentication should
<EM>
865 always
</EM> be used whenever data is encrypted
</STRONG>. Without
866 authentication, the encryption is vulnerable to active attacks which
867 may allow an enemy to break the encryption. ESP should
<STRONG> always
</STRONG>
868 either include its own authentication or be used with AH
870 <P>The RFCs require support for only two mandatory encryption algorithms
871 --
<A href=
"glossary.html#DES"> DES
</A>, and null encryption -- and for
872 two authentication methods -- keyed MD5 and keyed SHA. Implementers may
873 choose to support additional algorithms in either category.
</P>
874 <P>The authentication algorithms are the same ones used in the IPsec
<A href=
"glossary.html#AH">
875 authentication header
</A>.
</P>
876 <P>We do not implement single DES since
<A href=
"politics.html#desnotsecure">
877 DES is insecure
</A>. Instead we provide
<A href=
"glossary.html#3DES">
878 triple DES or
3DES
</A>. This is currently the only encryption algorithm
880 <P>We do not implement null encryption since it is obviously insecure.
</P>
881 <H2><A name=
"modes">IPsec modes
</A></H2>
882 <P>IPsec can connect in two modes. Transport mode is a host-to-host
883 connection involving only two machines. In tunnel mode, the IPsec
884 machines act as gateways and trafiic for any number of client machines
886 <H3><A name=
"tunnel.ipsec">Tunnel mode
</A></H3>
887 <P>Security gateways are required to support tunnel mode connections. In
888 this mode the gateways provide tunnels for use by client machines
889 behind the gateways. The client machines need not do any IPsec
890 processing; all they have to do is route things to gateways.
</P>
891 <H3><A name=
"transport.ipsec">Transport mode
</A></H3>
892 <P>Host machines (as opposed to security gateways) with IPsec
893 implementations must also support transport mode. In this mode, the
894 host does its own IPsec processing and routes some packets via IPsec.
</P>
895 <H2><A name=
"parts">FreeS/WAN parts
</A></H2>
896 <H3><A name=
"KLIPS.ipsec">KLIPS: Kernel IPsec Support
</A></H3>
897 <P>KLIPS is
<STRONG> K
</STRONG>erne
<STRONG>L
</STRONG><STRONG> IP
</STRONG>
898 SEC
<STRONG> S
</STRONG>upport, the modifications necessary to support
899 IPsec within the Linux kernel. KILPS does all the actual IPsec
900 packet-handling, including
</P>
903 <LI>packet authentication calculations
</LI>
904 <LI>creation of ESP and AH headers for outgoing packets
</LI>
905 <LI>interpretation of those headers on incoming packets
</LI>
907 <P>KLIPS also checks all non-IPsec packets to ensure they are not
908 bypassing IPsec security policies.
</P>
909 <H3><A name=
"Pluto.ipsec">The Pluto daemon
</A></H3>
910 <P><A href=
"manpage.d/ipsec_pluto.8.html">Pluto(
8)
</A> is a daemon which
911 implements the IKE protocol. It
</P>
913 <LI>handles all the Phase one ISAKMP SAs
</LI>
914 <LI>performs host authentication and negotiates with other gateways
</LI>
915 <LI>creates IPsec SAs and passes the data required to run them to KLIPS
</LI>
916 <LI>adjust routing and firewall setup to meet IPsec requirements. See
917 our
<A href=
"firewall.html"> IPsec and firewalling
</A> document for
920 <P>Pluto is controlled mainly by the
<A href=
"manpage.d/ipsec.conf.5.html">
921 ipsec.conf(
5)
</A> configuration file.
</P>
922 <H3><A name=
"command">The ipsec(
8) command
</A></H3>
923 <P>The
<A href=
"manpage.d/ipsec.8.html"> ipsec(
8)
</A> command is a front
924 end shellscript that allows control over IPsec activity.
</P>
925 <H3><A name=
"ipsec.conf">Linux FreeS/WAN configuration file
</A></H3>
926 <P>The configuration file for Linux FreeS/WAN is
</P>
927 <PRE> /etc/ipsec.conf
</PRE>
928 <P>For details see the
<A href=
"manpage.d/ipsec.conf.5.html">
929 ipsec.conf(
5)
</A> manual page .
</P>
930 <H2><A name=
"key">Key management
</A></H2>
931 <P>There are several ways IPsec can manage keys. Not all are implemented
932 in Linux FreeS/WAN.
</P>
933 <H3><A name=
"current">Currently Implemented Methods
</A></H3>
934 <H4><A name=
"manual">Manual keying
</A></H4>
935 <P>IPsec allows keys to be manually set. In Linux FreeS/WAN, such keys
936 are stored with the connection definitions in /etc/ipsec.conf.
</P>
937 <P><A href=
"glossary.html#manual">Manual keying
</A> is useful for
938 debugging since it allows you to test the
<A href=
"glossary.html#KLIPS">
939 KLIPS
</A> kernel IPsec code without the
<A href=
"glossary.html#Pluto">
940 Pluto
</A> daemon doing key negotiation.
</P>
941 <P>In general, however, automatic keying is preferred because it is more
943 <H4><A name=
"auto">Automatic keying
</A></H4>
944 <P>In automatic keying, the
<A href=
"glossary.html#Pluto"> Pluto
</A>
945 daemon negotiates keys using the
<A href=
"glossary.html#IKE"> IKE
</A>
946 Internet Key Exchange protocol. Connections are automatically re-keyed
948 <P>This is considerably more secure than manual keying. In either case
949 an attacker who acquires a key can read every message encrypted with
950 that key, but automatic keys can be changed every few hours or even
951 every few minutes without breaking the connection or requiring
952 intervention by the system administrators. Manual keys can only be
953 changed manually; you need to shut down the connection and have the two
954 admins make changes. Moreover, they have to communicate the new keys
955 securely, perhaps with
<A href=
"glossary.html#PGP"> PGP
</A> or
<A href=
"glossary.html#SSH">
956 SSH
</A>. This may be possible in some cases, but as a general solution
957 it is expensive, bothersome and unreliable. Far better to let
<A href=
"glossary.html#Pluto">
958 Pluto
</A> handle these chores; no doubt the administrators have enough
960 <P>Also, automatic keying is inherently more secure against an attacker
961 who manages to subvert your gateway system. If manual keying is in use
962 and an adversary acquires root privilege on your gateway, he reads your
963 keys from /etc/ipsec.conf and then reads all messages encrypted with
965 <P>If automatic keying is used, an adversary with the same privileges
966 can read /etc/ipsec.secrets, but this does not contain any keys, only
967 the secrets used to authenticate key exchanges. Having an adversary
968 able to authenticate your key exchanges need not worry you overmuch.
969 Just having the secrets does not give him any keys. You are still
970 secure against
<A href=
"glossary.html#passive"> passive
</A> attacks.
971 This property of automatic keying is called
<A href=
"glossary.html#PFS">
972 perfect forward secrecy
</A>, abbreviated PFS.
</P>
973 <P>Unfortunately, having the secrets does allow an
<A href=
"glossary.html#active">
974 active attack
</A>, specifically a
<A href=
"glossary.html#middle">
975 man-in-the-middle
</A> attack. Losing these secrets to an attacker may
976 not be quite as disastrous as losing the actual keys, but it is
<EM>
977 still a serious security breach
</EM>. These secrets should be guarded
978 as carefully as keys.
</P>
979 <H3><A name=
"notyet">Methods not yet implemented
</A></H3>
980 <H4><A name=
"noauth">Unauthenticated key exchange
</A></H4>
981 <P>It would be possible to exchange keys without authenticating the
982 players. This would support
<A href=
"glossary.html#carpediem">
983 opportunistic encryption
</A> -- allowing any two systems to encrypt
984 their communications without requiring a shared PKI or a previously
985 negotiated secret -- and would be secure against
<A href=
"glossary.html#passive">
986 passive attacks
</A>. It would, however, be highly vulnerable to active
<A
987 href=
"glossary.html#middle"> man-in-the-middle
</A> attacks. RFC
2408
988 therefore specifies that all
<A href=
"glossary.html#ISAKMP"> ISAKMP
</A>
989 key management interactions
<EM> must
</EM> be authenticated.
</P>
990 <P>There is room for debate here. Should we provide immediate security
991 against
<A href=
"glossary.html#passive"> passive attacks
</A> and
992 encourage widespread use of encryption, at the expense of risking the
993 more difficult
<A href=
"glossary.html#active"> active attacks
</A>? Or
994 should we wait until we can implement a solution that can both be
995 widespread and offer security against active attacks?
</P>
996 <P>So far, we have chosen the second course, complying with the RFCs and
997 waiting for secure DNS (see
<A href=
"glossary.html#DNS"> below
</A>) so
998 that we can do
<A href=
"glossary.html#carpediem"> opportunistic
999 encryption
</A> right.
</P>
1000 <H4><A name=
"DNS">Key exchange using DNS
</A></H4>
1001 <P>The IPsec RFCs allow key exchange based on authentication services
1002 provided by
<A href=
"glossary.html#SDNS"> Secure DNS
</A>. Once Secure
1003 DNS service becomes widely available, we expect to make this the
<EM>
1004 primary key management method for Linux FreeS/WAN
</EM>. It is the best
1005 way we know of to support
<A href=
"glossary.html#carpediem">
1006 opportunistic encryption
</A>, allowing two systems without a common PKI
1007 or previous negotiation to secure their communication.
</P>
1008 <P>We currently have code to acquire RSA keys from DNS but do not yet
1009 have code to validate Secure DNS signatures.
</P>
1010 <H4><A name=
"PKI">Key exchange using a PKI
</A></H4>
1011 <P>The IPsec RFCs allow key exchange based on authentication services
1012 provided by a
<A href=
"glossary.html#PKI"> PKI
</A> or Public Key
1013 Infrastructure. With many vendors selling such products and many large
1014 organisations building these infrastructures, this will clearly be an
1015 important application of IPsec and one Linux FreeS/WAN will eventually
1017 <P>On the other hand, this is not as high a priority for Linux FreeS/WAN
1018 as solutions based on
<A href=
"glossary.html#SDNS"> secure DNS
</A>. We
1019 do not expect any PKI to become as universal as DNS.
</P>
1020 <P>Some
<A href=
"web.html#patch"> patches
</A> to handle authentication
1021 with X
.509 certificates, which most PKIs use, are available.
</P>
1022 <H4><A name=
"photuris">Photuris
</A></H4>
1023 <P><A href=
"glossary.html#photuris">Photuris
</A> is another key
1024 management protocol, an alternative to IKE and ISAKMP, described in
1025 RFCs
2522 and
2523 which are labelled
"experimental
". Adding Photuris
1026 support to Linux FreeS/WAN might be a good project for a volunteer. The
1027 likely starting point would be the OpenBSD photurisd code.
</P>
1028 <H4><A name=
"skip">SKIP
</A></H4>
1029 <P><A href=
"glossary.html#SKIP">SKIP
</A> is yet another key management
1030 protocol, developed by Sun. At one point it was fairly widely used, but
1031 it now seems moribund, displaced by IKE. Sun now (as of Solaris
8.0)
1032 ship an IPsec implementation using IKE. We have no plans to implement
1033 SKIP. If a user were to implement it, we would almost certainly not
1034 want to add the code to our distribution.
</P>
1036 <A HREF=
"toc.html">Contents
</A>
1037 <A HREF=
"politics.html">Previous
</A>
1038 <A HREF=
"mail.html">Next
</A>
projects / thirdparty / strongswan.git / blob