freeswan/doc/src/ipsec.html

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