diff options
Diffstat (limited to 'doc/src/ipsec.html')
| -rw-r--r-- | doc/src/ipsec.html | 1206 |
1 files changed, 0 insertions, 1206 deletions
diff --git a/doc/src/ipsec.html b/doc/src/ipsec.html deleted file mode 100644 index 4647eaf66..000000000 --- a/doc/src/ipsec.html +++ /dev/null @@ -1,1206 +0,0 @@ -<html> -<head> - <meta http-equiv="Content-Type" content="text/html"> - <title>IPsec protocols</title> - <meta name="keywords" - content="Linux, IPsec, VPN, security, FreeSWAN, protocol, ESP, AH, IKE"> - <!-- - - Written by Sandy Harris for the Linux FreeS/WAN project - Freely distributable under the GNU General Public License - - More information at www.freeswan.org - Feedback to users@lists.freeswan.org - - CVS information: - RCS ID: $Id: ipsec.html,v 1.1 2004/03/15 20:35:24 as Exp $ - Last changed: $Date: 2004/03/15 20:35:24 $ - Revision number: $Revision: 1.1 $ - - CVS revision numbers do not correspond to FreeS/WAN release numbers. - --> -</head> - -<body> -<h1><a name="ipsec.detail">The IPsec protocols</a></h1> - -<p>This section provides information on the IPsec protocols which FreeS/WAN -implements. For more detail, see the <a href="rfc.html">RFCs</a>.</p> - -<p>The basic idea of IPsec is to provide security functions, <a -href="glossary.html#authentication">authentication</a> and <a -href="glossary.html#encryption">encryption</a>, at the IP (Internet Protocol) -level. This requires a higher-level protocol (IKE) to set things up for the -IP-level services (ESP and AH).</p> - -<h2>Protocols and phases</h2> - -<p>Three protocols are used in an IPsec implementation:</p> -<dl> - <dt>ESP, Encapsulating Security Payload</dt> - <dd>Encrypts and/or authenticates data</dd> - <dt>AH, Authentication Header</dt> - <dd>Provides a packet authentication service</dd> - <dt>IKE, Internet Key Exchange</dt> - <dd>Negotiates connection parameters, including keys, for the other - two</dd> -</dl> - -<p>The term "IPsec" (also written as IPSEC) is slightly ambiguous. In some -contexts, it includes all three of the above but in other contexts it refers -only to AH and ESP.</p> - -<p>There is more detail below, but a quick summary of how the whole thing -works is:</p> -<dl> - <dt>Phase one IKE (main mode exchange)</dt> - <dd>sets up a keying channel (ISAKMP SA) between the two gateways</dd> - <dt>Phase two IKE (quick mode exchange)</dt> - <dd>sets up data channels (IPsec SAs)</dd> - <dt>IPsec proper</dt> - <dd>exchanges data using AH or ESP</dd> -</dl> - -<p>Both phases of IKE are repeated periodically to automate re-keying.</p> - -<h2><a name="others">Applying IPsec</a></h2> - -<p>Authentication and encryption functions for network data can, of course, -be provided at other levels. Many security protocols work at levels above -IP.</p> -<ul> - <li><a href="glossary.html#PGP">PGP</a> encrypts and authenticates mail - messages</li> - <li><a href="glossary.html#SSH">SSH</a> authenticates remote logins and - then encrypts the session</li> - <li><a href="glossary.html#SSL">SSL</a> or <a - href="glossary.html#TLS">TLS</a> provides security at the sockets layer, - e.g. for secure web browsing</li> -</ul> - -<p>and so on. Other techniques work at levels below IP. For example, data on -a communications circuit or an entire network can be encrypted by specialised -hardware. This is common practice in high-security applications.</p> - -<h3><a name="advantages">Advantages of IPsec</a></h3> - -<p>There are, however, advantages to doing it at the IP level instead of, or -as well as, at other levels.</p> - -<p>IPsec is the <strong>most general way to provide these services for the -Internet</strong>.</p> -<ul> - <li>Higher-level services protect a <em>single protocol</em>; for example - PGP protects mail.</li> - <li>Lower level services protect a <em>single medium</em>; for example a - pair of encryption boxes on the ends of a line make wiretaps on that line - useless unless the attacker is capable of breaking the encryption.</li> -</ul> - -<p>IPsec, however, can protect <em>any protocol</em> running above IP and -<em>any medium</em> which IP runs over. More to the point, it can protect a -mixture of application protocols running over a complex combination of media. -This is the normal situation for Internet communication; IPsec is the only -general solution.</p> - -<p>IPsec can also provide some security services "in the background", with -<strong>no visible impact on users</strong>. To use <a -href="glossary.html#PGP">PGP</a> encryption and signatures on mail, for -example, the user must at least:</p> -<ul> - <li>remember his or her passphrase,</li> - <li>keep it secure</li> - <li>follow procedures to validate correspondents' keys</li> -</ul> - -<p>These systems can be designed so that the burden on users is not onerous, -but any system will place some requirements on users. No such system can hope -to be secure if users are sloppy about meeting those requirements. The author -has seen username and password stuck on terminals with post-it notes in an -allegedly secure environment, for example.</p> - -<h3><a name="limitations">Limitations of IPsec</a></h3> - -<p>IPsec is designed to secure IP links between machines. It does that well, -but it is important to remember that there are many things it does not do. -Some of the important limitations are:</p> -<dl> - <dt><a name="depends">IPsec cannot be secure if your system isn't</a></dt> - <dd>System security on IPsec gateway machines is an essential requirement - if IPsec is to function as designed. No system can be trusted if the - underlying machine has been subverted. See books on Unix security such - as <a href="biblio.html#practical">Garfinkel and Spafford</a> or our - web references for <a href="web.html#linsec">Linux security</a> or more - general <a href="web.html#compsec">computer security</a>. - <p>Of course, there is another side to this. IPsec can be a powerful - tool for improving system and network security. For example, requiring - packet authentication makes various spoofing attacks harder and IPsec - tunnels can be extremely useful for secure remote administration of - various things.</p> - </dd> - <dt><a name="not-end-to-end">IPsec is not end-to-end</a></dt> - <dd>IPsec cannot provide the same end-to-end security as systems working - at higher levels. IPsec encrypts an IP connection between two machines, - which is quite a different thing than encrypting messages between users - or between applications. - <p>For example, if you need mail encrypted from the sender's desktop to - the recipient's desktop and decryptable only by the recipient, use <a - href="glossary.html#PGP">PGP</a> or another such system. IPsec can - encrypt any or all of the links involved -- between the two mail - servers, or between either server and its clients. It could even be - used to secure a direct IP link from the sender's desktop machine to - the recipient's, cutting out any sort of network snoop. What it cannot - ensure is end-to-end user-to-user security. If only IPsec is used to - secure mail, then anyone with appropriate privileges on any machine - where that mail is stored (at either end or on any store-and-forward - servers in the path) can read it.</p> - <p>In another common setup, IPsec encrypts packets at a security - gateway machine as they leave the sender's site and decrypts them on - arrival at the gateway to the recipient's site. This does provide a - useful security service -- only encrypted data is passed over the - Internet -- but it does not even come close to providing an end-to-end - service. In particular, anyone with appropriate privileges on either - site's LAN can intercept the message in unencrypted form.</p> - </dd> - <dt><a name="notpanacea">IPsec cannot do everything</a></dt> - <dd>IPsec also cannot provide all the functions of systems working at - higher levels of the protocol stack. If you need a document - electronically signed by a particular person, then you need his or her - <a href="glossary.html#signature">digital signature</a> and a <a - href="glossary.html#public">public key cryptosystem</a> to verify it - with. - <p>Note, however, that IPsec authentication of the underlying - communication can make various attacks on higher-level protocols more - difficult. In particular, authentication prevents <a - href="glossary.html#middle">man-in-the-middle attacks</a>.</p> - </dd> - <dt><a name="no_user">IPsec authenticates machines, not users</a></dt> - <dd>IPsec uses strong authentication mechanisms to control which messages - go to which machines, but it does not have the concept of user ID, - which is vital to many other security mechansims and policies. This - means some care must be taken in fitting the various security - mechansims on a network together. For example, if you need to control - which users access your database server, you need some non-IPsec - mechansim for that. IPsec can control which machines connect to the - server, and can ensure that data transfer to those machines is done - securely, but that is all. Either the machines themselves must control - user access or there must be some form of user authentication to the - database, independent of IPsec.</dd> - <dt><a name="DoS">IPsec does not stop denial of service attacks</a></dt> - <dd><a href="glossary.html#DOS">Denial of service</a> attacks aim at - causing a system to crash, overload, or become confused so that - legitimate users cannot get whatever services the system is supposed to - provide. These are quite different from attacks in which the attacker - seeks either to use the service himself or to subvert the service into - delivering incorrect results. - <p>IPsec shifts the ground for DoS attacks; the attacks possible - against systems using IPsec are different than those that might be used - against other systems. It does not, however, eliminate the possibility - of such attacks.</p> - </dd> - <dt><a name="traffic">IPsec does not stop traffic analysis</a></dt> - <dd><a href="glossary.html#traffic">Traffic analysis</a> is the attempt - to derive intelligence from messages without regard for their contents. - In the case of IPsec, it would mean analysis based on things visible in - the unencrypted headers of encrypted packets -- source and destination - gateway addresses, packet size, et cetera. Given the resources to - acquire such data and some skill in analysing it (both of which any - national intelligence agency should have), this can be a very powerful - technique. - <p>IPsec is not designed to defend against this. Partial defenses are - certainly possible, and some are <a href="#traffic.resist">described - below</a>, but it is not clear that any complete defense can be - provided.</p> - </dd> -</dl> - -<h3><a name="uses">IPsec is a general mechanism for securing IP</a></h3> - -<p>While IPsec does not provide all functions of a mail encryption package, -it can encrypt your mail. In particular, it can ensure that all mail passing -between a pair or a group of sites is encrypted. An attacker looking only at -external traffic, without access to anything on or behind the IPsec gateway, -cannot read your mail. He or she is stymied by IPsec just as he or she would -be by <a href="glossary.html#PGP">PGP</a>.</p> - -<p>The advantage is that IPsec can provide the same protection for <strong> -anything transmitted over IP</strong>. In a corporate network example, PGP -lets the branch offices exchange secure mail with head office. SSL and SSH -allow them to securely view web pages, connect as terminals to machines, and -so on. IPsec can support all those applications, plus database queries, file -sharing (NFS or Windows), other protocols encapsulated in IP (Netware, -Appletalk, ...), phone-over-IP, video-over-IP, ... anything-over-IP. The only -limitation is that IP Multicast is not yet supported, though there are -Internet Draft documents for that.</p> - -<p>IPsec creates <strong>secure tunnels through untrusted networks</strong>. -Sites connected by these tunnels form VPNs, <a -href="glossary.html#VPN">Virtual Private Networks</a>.</p> - -<p>IPsec gateways can be installed wherever they are required.</p> -<ul> - <li>One organisation might choose to install IPsec only on firewalls - between their LANs and the Internet. This would allow them to create a - VPN linking several offices. It would provide protection against anyone - outside their sites.</li> - <li>Another might install IPsec on departmental servers so everything on - the corporate backbone net was encrypted. This would protect messages on - that net from everyone except the sending and receiving department.</li> - <li>Another might be less concerned with information secrecy and more with - controlling access to certain resources. They might use IPsec packet - authentication as part of an access control mechanism, with or without - also using the IPsec encryption service.</li> - <li>It is even possible (assuming adequate processing power and an IPsec - implementation in each node) to make every machine its own IPsec gateway - so that everything on a LAN is encrypted. This protects information from - everyone outside the sending and receiving machine.</li> - <li>These techniques can be combined in various ways. One might, for - example, require authentication everywhere on a network while using - encryption only for a few links.</li> -</ul> - -<p>Which of these, or of the many other possible variants, to use is up to -you. <strong>IPsec provides mechanisms; you provide the policy</strong>.</p> - -<p><strong>No end user action is required</strong> for IPsec security to be -used; they don't even have to know about it. The site administrators, of -course, do have to know about it and to put some effort into making it work. -Poor administration can compromise IPsec as badly as the post-it notes -mentioned above. It seems reasonable, though, for organisations to hope their -system administrators are generally both more security-conscious than end -users and more able to follow computer security procedures. If not, at least -there are fewer of them to educate or replace.</p> - -<p>IPsec can be, and often should be, used with along with security protocols -at other levels. If two sites communicate with each other via the Internet, -then IPsec is the obvious way to protect that communication. If two others -have a direct link between them, either link encryption or IPsec would make -sense. Choose one or use both. Whatever you use at and below the IP level, -use other things as required above that level. Whatever you use above the IP -level, consider what can be done with IPsec to make attacks on the higher -levels harder. For example, <a href="glossary.html#middle">man-in-the-middle -attacks</a> on various protocols become difficult if authentication at packet -level is in use on the potential victims' communication channel.</p> - -<h3><a name="authonly">Using authentication without encryption</a></h3> - -<p>Where appropriate, IPsec can provide authentication without encryption. -One might do this, for example:</p> -<ul> - <li>where the data is public but one wants to be sure of getting the right - data, for example on some web sites</li> - <li>where encryption is judged unnecessary, for example on some company or - department LANs</li> - <li>where strong encryption is provided at link level, below IP</li> - <li>where strong encryption is provided in other protocols, above IP<br> - Note that IPsec authentication may make some attacks on those protocols - harder.</li> -</ul> - -<p>Authentication has lower overheads than encryption.</p> - -<p>The protocols provide four ways to build such connections, using either an -AH-only connection or ESP using null encryption, and in either manually or -automatically keyed mode. FreeS/WAN supports only one of these, manually -keyed AH-only connections, and <strong>we do not recommend using -that</strong>. Our reasons are discussed under <a -href="#traffic.resist">Resisting traffic analysis</a> a few sections further -along.</p> - -<h3><a name="encnoauth">Encryption without authentication is -dangerous</a></h3> - -<p>Originally, the IPsec encryption protocol <a -href="glossary.html#ESP">ESP</a> didn't do integrity checking. It only did -encryption. Steve Bellovin found many ways to attack ESP used without -authentication. See his paper <a -href="http://www.research.att.com/~smb/papers/badesp.ps">Problem areas for -the IP Security Protocols</a>. To make a secure connection, you had to add an -<a href="glossary.html#AH">AH</a> Authentication Header as well as ESP. -Rather than incur the overhead of several layers (and rather than provide an -ESP layer that didn't actually protect the traffic), the IPsec working group -built integrity and replay checking directly into ESP.</p> - -<p>Today, typical usage is one of:</p> -<ul> - <li>ESP for encryption and authentication</li> - <li>AH for authentication alone</li> -</ul> - -<p>Other variants are allowed by the standard, but not much used:</p> -<dl> - <dt>ESP encryption without authentication</dt> - <dd><strong>Bellovin has demonstrated fatal flaws in this. Do not - use.</strong></dd> - <dt>ESP encryption with AH authentication</dt> - <dd>This has higher overheads than using the authentication in ESP, and - no obvious benefit in most cases. The exception might be a network - where AH authentication was widely or universally used. If you're going - to do AH to conform with network policy, why authenticate again in the - ESP layer?</dd> - <dt>Authenticate twice, with AH and with ESP</dt> - <dd>Why? Of course, some folk consider "belt and suspenders" the sensible - approach to security. If you're among them, you might use both - protocols here. You might also use both to satisfy different parts of a - security policy. For example, an organisation might require AH - authentication everywhere but two users within the organisation might - use ESP as well.</dd> - <dt>ESP authentication without encryption</dt> - <dd>The standard allows this, calling it "null encryption". FreeS/WAN - does not support it. We recommend that you use AH instead if - authentication is all you require. AH authenticates parts of the IP - header, which ESP-null does not do.</dd> -</dl> - -<p>Some of these variants cannot be used with FreeS/WAN because we do not -support ESP-null and do not support automatic keying of AH-only -connections.</p> - -<p>There are fairly frequent suggestions that AH be dropped entirely from the -IPsec specifications since ESP and null encryption can handle that situation. -It is not clear whether this will occur. My guess is that it is unlikely.</p> - -<h3><a name="multilayer">Multiple layers of IPsec processing are -possible</a></h3> - -<p>The above describes combinations possible on a single IPsec connection. In -a complex network you may have several layers of IPsec in play, with any of -the above combinations at each layer.</p> - -<p>For example, a connection from a desktop machine to a database server -might require AH authentication. Working with other host, network and -database security measures, AH might be just the thing for access control. -You might decide not to use ESP encryption on such packets, since it uses -resources and might complicate network debugging. Within the site where the -server is, then, only AH would be used on those packets.</p> - -<p>Users at another office, however, might have their whole connection (AH -headers and all) passing over an IPsec tunnel connecting their office to the -one with the database server. Such a tunnel should use ESP encryption and -authentication. You need authentication in this layer because without -authentication the encryption is vulnerable and the gateway cannot verify the -AH authentication. The AH is between client and database server; the gateways -aren't party to it.</p> - -<p>In this situation, some packets would get multiple layers of IPsec applied -to them, AH on an end-to-end client-to-server basis and ESP from one office's -security gateway to the other.</p> - -<h3><a name="traffic.resist">Resisting traffic analysis</a></h3> - -<p><a href="glossary.html#traffic">Traffic analysis</a> is the attempt to -derive useful intelligence from encrypted traffic without breaking the -encryption.</p> - -<p>Is your CEO exchanging email with a venture capital firm? With bankruptcy -trustees? With an executive recruiting agency? With the holder of some -important patents? If an eavesdropper learns about any of those, then he has -interesting intelligence on your company, whether or not he can read the -messages themselves.</p> - -<p>Even just knowing that there is network traffic between two sites may tell -an analyst something useful, especially when combined with whatever other -information he or she may have. For example, if you know Company A is having -cashflow problems and Company B is looking for aquisitions, then knowing that -packets are passing between the two is interesting. It is more interesting if -you can tell it is email, and perhaps yet more if you know the sender and -recipient.</p> - -<p>Except in the simplest cases, traffic analysis is hard to do well. It -requires both considerable resources and considerable analytic skill. -However, intelligence agencies of various nations have been doing it for -centuries and many of them are likely quite good at it by now. Various -commercial organisations, especially those working on "targeted marketing" -may also be quite good at analysing certain types of traffic.</p> - -<p>In general, defending against traffic analysis is also difficult. -Inventing a really good defense could get you a PhD and some interesting job -offers.</p> - -<p>IPsec is not designed to stop traffic analysis and we know of no plausible -method of extending it to do so. That said, there are ways to make traffic -analysis harder. This section describes them.</p> - -<h4><a name="extra">Using "unnecessary" encryption</a></h4> - -<p>One might choose to use encryption even where it appears unnecessary in -order to make analysis more difficult. Consider two offices which pass a -small volume of business data between them using IPsec and also transfer -large volumes of Usenet news. At first glance, it would seem silly to encrypt -the newsfeed, except possibly for any newsgroups that are internal to the -company. Why encrypt data that is all publicly available from many sites?</p> - -<p>However, if we encrypt a lot of news and send it down the same connection -as our business data, we make <a href="glossary.html#traffic">traffic -analysis</a> much harder. A snoop cannot now make inferences based on -patterns in the volume, direction, sizes, sender, destination, or timing of -our business messages. Those messages are hidden in a mass of news messages -encapsulated in the same way.</p> - -<p>If we're going to do this we need to ensure that keys change often enough -to remain secure even with high volumes and with the adversary able to get -plaintext of much of the data. We also need to look at other attacks this -might open up. For example, can the adversary use a chosen plaintext attack, -deliberately posting news articles which, when we receive and encrypt them, -will help break our encryption? Or can he block our business data -transmission by flooding us with silly news articles? Or ...</p> - -<p>Also, note that this does not provide complete protection against traffic -analysis. A clever adversary might still deduce useful intelligence from -statistical analysis (perhaps comparing the input newsfeed to encrypted -output, or comparing the streams we send to different branch offices), or by -looking for small packets which might indicate establishment of TCP -connections, or ...</p> - -<p>As a general rule, though, to improve resistance to traffic analysis, you -should <strong>encrypt as much traffic as possible, not just as much as seems -necessary.</strong></p> - -<h4><a name="multi-encrypt">Using multiple encryption</a></h4> - -<p>This also applies to using multiple layers of encryption. If you have an -IPsec tunnel between two branch offices, it might appear silly to send <a -href="glossary.html#PGP">PGP</a>-encrypted email through that tunnel. -However, if you suspect someone is snooping your traffic, then it does make -sense:</p> -<ul> - <li>it protects the mail headers; they cannot even see who is mailing - who</li> - <li>it protects against user bungles or software malfunctions that - accidentally send messages in the clear</li> - <li>it makes any attack on the mail encryption much harder; they have to - break IPsec or break into your network before they can start on the mail - encryption</li> -</ul> - -<p>Similar arguments apply for <a href="glossary.html#SSL">SSL</a>-encrypted -web traffic or <a href="glossary.html#SSH">SSH</a>-encrypted remote login -sessions, even for end-to-end IPsec tunnels between systems in the two -offices.</p> - -<h4><a name="fewer">Using fewer tunnels</a></h4> - -<p>It may also help to use fewer tunnels. For example, if all you actually -need encrypted is connections between:</p> -<ul> - <li>mail servers at branch and head offices</li> - <li>a few branch office users and the head office database server</li> -</ul> - -<p>You might build one tunnel per mail server and one per remote database -user, restricting traffic to those applications. This gives the traffic -analyst some information, however. He or she can distinguish the tunnels by -looking at information in the ESP header and, given that distinction and the -patterns of tunnel usage, might be able to figure out something useful. -Perhaps not, but why take the risk?</p> - -<p>We suggest instead that you build one tunnel per branch office, encrypting -everything passing from head office to branches. This has a number of -advantages:</p> -<ul> - <li>it is easier to build and administer</li> - <li>it resists traffic analysis somewhat better</li> - <li>it provides security for whatever you forgot. For example, if some user - at a remote office browses proprietary company data on some head office - web page (that the security people may not even know about!), then that - data is encrypted before it reaches the Internet.</li> -</ul> - -<p>Of course you might also want to add additional tunnels. For example, if -some of the database data is confidential and should not be exposed even -within the company, then you need protection from the user's desktop to the -database server. We suggest you do that in whatever way seems appropriate -- -IPsec, SSH or SSL might fit -- but, whatever you choose, pass it between -locations via a gateway-to-gateway IPsec tunnel to provide some resistance to -traffic analysis.</p> - -<h2><a name="primitives">Cryptographic components</a></h2> - -<p>IPsec combines a number of cryptographic techniques, all of them -well-known and well-analyzed. The overall design approach was conservative; -no new or poorly-understood components were included.</p> - -<p>This section gives a brief overview of each technique. It is intended only -as an introduction. There is more information, and links to related topics, -in our <a href="glossary.html">glossary</a>. See also our <a -href="biblio.html">bibliography</a> and cryptography <a -href="web.html#crypto.link">web links</a>.</p> - -<h3><a name="block.cipher">Block ciphers</a></h3> - -<p>The <a href="glossary.html#encryption">encryption</a> in the <a -href="glossary.html#ESP">ESP</a> encapsulation protocol is done with a <a -href="glossary.html#block">block cipher</a>.</p> - -<p>We do not implement <a href="glossary.html#DES">single DES</a>. It is <a -href="politics.html#desnotsecure">insecure</a>. Our default, and currently -only, block cipher is <a href="glossary.html#3DES">triple DES</a>.</p> - -<p>The <a href="glossary.html#rijndael">Rijndael</a> block cipher has won the -<a href="glossary.html#AES">AES</a> competition to choose a relacement for -DES. It will almost certainly be added to FreeS/WAN and to other IPsec -implementations. <a href="web.html#patch">Patches</a> are already -available.</p> - -<h3><a name="hash.ipsec">Hash functions</a></h3> - -<h4><a name="hmac.ipsec">The HMAC construct</a></h4> - -<p>IPsec packet authentication is done with the <a -href="glossary.html#HMAC">HMAC</a> construct. This is not just a hash of the -packet data, but a more complex operation which uses both a hashing algorithm -and a key. It therefore does more than a simple hash would. A simple hash -would only tell you that the packet data was not changed in transit, or that -whoever changed it also regenerated the hash. An HMAC also tells you that the -sender knew the HMAC key.</p> - -<p>For IPsec HMAC, the output of the hash algorithm is truncated to 96 bits. -This saves some space in the packets. More important, it prevents an attacker -from seeing all the hash output bits and perhaps creating some sort of attack -based on that knowledge.</p> - -<h4>Choice of hash algorithm</h4> - -<p>The IPsec RFCs require two hash algorithms -- <a -href="glossary.html#MD5">MD5</a> and <a href="glossary.html#SHA">SHA-1</a> -- -both of which FreeS/WAN implements.</p> - -<p>Various other algorithms -- such as RIPEMD and Tiger -- are listed in the -RFCs as optional. None of these are in the FreeS/WAN distribution, or are -likely to be added, although user <a href="web.html#patch">patches</a> exist -for several of them.</p> - -<p>Additional hash algorithms -- <a href="glossary.html#SHA-256">SHA-256, -SHA-384 and SHA-512</a> -- may be required to give hash strength matching the -strength of <a href="glossary.html#AES">AES</a>. These are likely to be added -to FreeS/WAN along with AES.</p> - -<h3><a name="DH.keying">Diffie-Hellman key agreement</a></h3> - -<p>The <a href="glossary.html#DH">Diffie-Hellman</a> key agreement protocol -allows two parties (A and B or <a href="glossary.html#alicebob">Alice and -Bob</a>) to agree on a key in such a way that an eavesdropper who intercepts -the entire conversation cannot learn the key.</p> - -<p>The protocol is based on the <a href="glossary.html#dlog">discrete -logarithm</a> problem and is therefore thought to be secure. Mathematicians -have been working on that problem for years and seem no closer to a solution, -though there is no proof that an efficient solution is impossible.</p> - -<h3><a name="RSA.auth">RSA authentication</a></h3> - -<p>The <a href="glossary.html#RSA">RSA</a> algorithm (named for its inventors --- Rivest, Shamir and Adleman) is a very widely used <a -href="glossary.html#">public key</a> cryptographic technique. It is used in -IPsec as one method of authenticating gateways for Diffie-Hellman key -negotiation.</p> - -<h2><a name="structure">Structure of IPsec</a></h2> - -<p>There are three protocols used in an IPsec implementation:</p> -<dl> - <dt>ESP, Encapsulating Security Payload</dt> - <dd>Encrypts and/or authenticates data</dd> - <dt>AH, Authentication Header</dt> - <dd>Provides a packet authentication service</dd> - <dt>IKE, Internet Key Exchange</dt> - <dd>Negotiates connection parameters, including keys, for the other - two</dd> -</dl> - -<p>The term "IPsec" is slightly ambiguous. In some contexts, it includes all -three of the above but in other contexts it refers only to AH and ESP.</p> - -<h3><a name="IKE.ipsec">IKE (Internet Key Exchange)</a></h3> - -<p>The IKE protocol sets up IPsec (ESP or AH) connections after negotiating -appropriate parameters (algorithms to be used, keys, connection lifetimes) -for them. This is done by exchanging packets on UDP port 500 between the two -gateways.</p> - -<p>IKE (RFC 2409) was the outcome of a long, complex process in which quite a -number of protocols were proposed and debated. Oversimplifying mildly, IKE -combines:</p> -<dl> - <dt>ISAKMP (RFC 2408)</dt> - <dd>The <strong>I</strong>nternet <strong>S</strong>ecurity - <strong>A</strong>ssociation and <strong>K</strong>ey - <strong>M</strong>anagement <strong>P</strong>rotocol manages - negotiation of connections and defines <a - href="glossary.html#SA">SA</a>s (Security Associations) as a means of - describing connection properties.</dd> - <dt>IPsec DOI for ISAKMP (RFC 2407)</dt> - <dd>A <strong>D</strong>omain <strong>O</strong>f - <strong>I</strong>nterpretation fills in the details necessary to turn - the rather abstract ISAKMP protocol into a more tightly specified - protocol, so it becomes applicable in a particular domain.</dd> - <dt>Oakley key determination protocol (RFC 2412)</dt> - <dd>Oakley creates keys using the <a - href="glossary.html#DH">Diffie-Hellman</a> key agreement protocol.</dd> -</dl> - -<p>For all the details, you would need to read the four <a -href="rfc.html">RFCs</a> just mentioned (over 200 pages) and a number of -others. We give a summary below, but it is far from complete.</p> - -<h4><a name="phases">Phases of IKE</a></h4> - -<p>IKE negotiations have two phases.</p> -<dl> - <dt>Phase one</dt> - <dd>The two gateways negotiate and set up a two-way ISAKMP SA which they - can then use to handle phase two negotiations. One such SA between a - pair of gateways can handle negotiations for multiple tunnels.</dd> - <dt>Phase two</dt> - <dd>Using the ISAKMP SA, the gateways negotiate IPsec (ESP and/or AH) SAs - as required. IPsec SAs are unidirectional (a different key is used in - each direction) and are always negotiated in pairs to handle two-way - traffic. There may be more than one pair defined between two - gateways.</dd> -</dl> - -<p>Both of these phases use the UDP protocol and port 500 for their -negotiations.</p> - -<p>After both IKE phases are complete, you have IPsec SAs to carry your -encrypted data. These use the ESP or AH protocols. These protocols do not -have ports. Ports apply only to UDP or TCP.</p> - -<p>The IKE protocol is designed to be extremely flexible. Among the things -that can be negotiated (separately for each SA) are:</p> -<ul> - <li>SA lifetime before rekeying</li> - <li>encryption algorithm used. We currently support only <a - href="glossary.html#3DES">triple DES</a>. Single DES is <a - href="politics.html#desnotsecure">insecure</a>. The RFCs say you MUST do - DES, SHOULD do 3DES and MAY do various others. We do not do any of the - others.</li> - <li>authentication algorithms. We support <a - href="glossary.html#MD5">MD5</a> and <a href="glossary.html#SHA">SHA</a>. - These are the two the RFCs require.</li> - <li>choice of group for <a href="glossary.html#DH">Diffie-Hellman</a> key - agreement. We currently support Groups 2 and 5 (which are defined modulo - primes of various lengths) and do not support Group 1 (defined modulo a - shorter prime, and therefore cryptographically weak) or groups 3 and 4 - (defined using elliptic curves). The RFCs require only Group 1.</li> -</ul> - -<p>The protocol also allows implementations to add their own encryption -algorithms, authentication algorithms or Diffie-Hellman groups. We do not -support any such extensions, but there are some <a -href="web.html#patch">patches</a> that do.</p> - -<p>There are a number of complications:</p> -<ul> - <li>The gateways must be able to authenticate each other's identities - before they can create a secure connection. This host authentication is - part of phase one negotiations, and is a required prerequisite for packet - authentication used later. Host authentication can be done in a variety - of ways. Those supported by FreeS/WAN are discussed in our <a - href="adv_config.html#auto-auth">advanced configuration</a> document.</li> - <li>Phase one can be done in two ways. - <ul> - <li>Main Mode is required by the RFCs and supported in FreeS/WAN. It - uses a 6-packet exzchange.</li> - <li>Aggressive Mode is somewhat faster (only 3 packets) but reveals - more to an eavesdropper. This is optional in the RFCs, not currently - supported by FreeS/WAN, and not likely to be.</li> - </ul> - </li> - <li>A new group exchange may take place after phase one but before phase - two, defining an additional group for use in the <a - href="glossary.html#DH">Diffie-Hellman</a> key agreement part of phase - two. FreeS/WAN does not currently support this.</li> - <li>Phase two always uses Quick Mode, but there are two variants of that: - <ul> - <li>One variant provides <a href="glossary.html#PFS">Perfect Forward - Secrecy (PFS)</a>. An attacker that obtains your long-term host - authentication key does not immediately get any of your short-term - packet encryption of packet authentication keys. He must conduct - another successful attack each time you rekey to get the short-term - keys. Having some short-term keys does not help him learn others. In - particular, breaking your system today does not let him read messages - he archived yestarday, assuming you've changed short-term keys in the - meanwhile. We enable PFS as the default.</li> - <li>The other variant disables PFS and is therefore slightly faster. We - do not recommend this since it is less secure, but FreeS/WAN does - support it. You can enable it with a <var>pfs=no</var> statement in - <a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a>.</li> - <li>The protocol provides no way to negotiate which variant will be - used. If one gateway is set for PFS and the other is not, the - negotiation fails. This has proved a fairly common source of - interoperation problems.</li> - </ul> - </li> - <li>Several types of notification message may be sent by either side during - either phase, or later. FreeS/WAN does not currently support these, but - they are a likely addition in future releases.</li> - <li>There is a commit flag which may optionally be set on some messages. - The <a href="http://www.lounge.org/ike_doi_errata.html">errata</a> page - for the RFCs includes two changes related to this, one to clarify the - description of its use and one to block a <a - href="glossary.html#DOS">denial of service</a> attack which uses it. We - currently do not implement this feature.</li> -</ul> - -<p>These complications can of course lead to problems, particularly when two -different implementations attempt to interoperate. For example, we have seen -problems such as:</p> -<ul> - <li>Some implementations (often products crippled by <a - href="politics.html#exlaw">export laws</a>) have the insecure DES - algorithm as their only supported encryption method. Other parts of our - documentation discuss the <a - href="politics.html#desnotsecure">reasons we do not implement single - DES</a>, and <a href="interop.html#noDES">how to cope with crippled - products</a>.</li> - <li>Windows 2000 IPsec tries to negotiate using Aggressive Mode, which we - don't support. Later on, it uses the commit bit, which we also don't - support.</li> - <li>Various implementations disable PFS by default, and therefore will not - talk to FreeS/WAN until you either turn on PFS on their end or turn it - off in FreeS/WAN with a <var>pfs=no</var> entry in the connection - description.</li> - <li>FreeS/WAN's interaction with PGPnet is complicated by their use of - notification messages we do not yet support.</li> -</ul> - -<p>Despite this, we do interoperate successfully with many implementations, -including both Windows 2000 and PGPnet. Details are in our <a -href="interop.html">interoperability</a> document.</p> - -<h4><a name="sequence">Sequence of messages in IKE</a></h4> - -<p>Each phase (see <a href="#phases">previous section</a>)of IKE involves a -series of messages. In Pluto error messages, these are abbreviated using:</p> -<dl> - <dt>M</dt> - <dd><strong>M</strong>ain mode, settting up the keying channel (ISAKMP - SA)</dd> - <dt>Q</dt> - <dd><strong>Q</strong>uick mode, setting up the data channel (IPsec - SA)</dd> - <dt>I</dt> - <dd><strong>I</strong>nitiator, the machine that starts the - negotiation</dd> - <dt>R</dt> - <dd><strong>R</strong>esponder</dd> -</dl> - -<p>For example, the six messages of a main mode negotiation, in sequence, are -labelled:</p> -<pre> MI1 ----------> - <---------- MR1 - MI2 ----------> - <---------- MR2 - MI3 ----------> - <---------- MR3</pre> - -<h4><a name="struct.exchange">Structure of IKE messages</a></h4> - -<p>Here is our Pluto developer explaining some of this on the mailing -list:</p> -<pre>When one IKE system (for example, Pluto) is negotiating with another -to create an SA, the Initiator proposes a bunch of choices and the -Responder replies with one that it has selected. - -The structure of the choices is fairly complicated. An SA payload -contains a list of lists of "Proposals". The outer list is a set of -choices: the selection must be from one element of this list. - -Each of these elements is a list of Proposals. A selection must be -made from each of the elements of the inner list. In other words, -*all* of them apply (that is how, for example, both AH and ESP can -apply at once). - -Within each of these Proposals is a list of Transforms. For each -Proposal selected, one Transform must be selected (in other words, -each Proposal provides a choice of Transforms). - -Each Transform is made up of a list of Attributes describing, well, -attributes. Such as lifetime of the SA. Such as algorithm to be -used. All the Attributes apply to a Transform. - -You will have noticed a pattern here: layers alternate between being -disjunctions ("or") and conjunctions ("and"). - -For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is -cut back. There must be exactly one Proposal. So this degenerates to -a list of Transforms, one of which must be chosen.</pre> - -<h3><a name="services">IPsec Services, AH and ESP</a></h3> - -<p>IPsec offers two services, <a -href="glossary.html#authentication">authentication</a> and <a -href="glossary.html#encryption">encryption</a>. These can be used separately -but are often used together.</p> -<dl> - <dt>Authentication</dt> - <dd>Packet-level authentication allows you to be confident that a packet - came from a particular machine and that its contents were not altered - en route to you. No attempt is made to conceal or protect the contents, - only to assure their integrity. Packet authentication can be provided - separately using an <a href="glossary.html#AH">Authentication - Header</a>, described just below, or it can be included as part of the - <a href="glossary.html#ESP">ESP</a> (Encapsulated Security Payload) - service, described in the following section. That service offers - encryption as well as authentication. In either case, the <a - href="glossary.html#HMAC">HMAC</a> construct is used as the - authentication mechanism. - <p>There is a separate authentication operation at the IKE level, in - which each gateway authenticates the other. This can be done in a - variety of ways.</p> - </dd> - <dt>Encryption</dt> - <dd>Encryption allows you to conceal the contents of a message from - eavesdroppers. - <p>In IPsec this is done using a <a href="glossary.html#block">block - cipher</a> (normally <a href="glossary.html#3DES">Triple DES</a> for - Linux). In the most used setup, keys are automatically negotiated, and - periodically re-negotiated, using the <a - href="glossary.html#IKE">IKE</a> (Internet Key Exchange) protocol. In - Linux FreeS/WAN this is handled by the Pluto Daemon.</p> - <p>The IPsec protocol offering encryption is <a - href="glossary.html#ESP">ESP</a>, Encapsulated Security Payload. It can - also include a packet authentication service.</p> - </dd> -</dl> - -<p>Note that <strong>encryption should always be used with some packet -authentication service</strong>. Unauthenticated encryption is vulnerable to -<a href="glossary.html#middle">man-in-the-middle attacks</a>. Also note that -encryption does not prevent <a href="glossary.html#traffic">traffic -analysis</a>.</p> - -<h3><a name="AH.ipsec">The Authentication Header (AH)</a></h3> - -<p>Packet authentication can be provided separately from encryption by adding -an authentication header (AH) after the IP header but before the other -headers on the packet. This is the subject of this section. Details are in -RFC 2402.</p> - -<p>Each of the several headers on a packet header contains a "next protocol" -field telling the system what header to look for next. IP headers generally -have either TCP or UDP in this field. When IPsec authentication is used, the -packet IP header has AH in this field, saying that an Authentication Header -comes next. The AH header then has the next header type -- usually TCP, UDP -or encapsulated IP.</p> - -<p>IPsec packet authentication can be added in transport mode, as a -modification of standard IP transport. This is shown in this diagram from the -RFC:</p> -<pre> BEFORE APPLYING AH - ---------------------------- - IPv4 |orig IP hdr | | | - |(any options)| TCP | Data | - ---------------------------- - - AFTER APPLYING AH - --------------------------------- - IPv4 |orig IP hdr | | | | - |(any options)| AH | TCP | Data | - --------------------------------- - || - except for mutable fields</pre> - -<p>Athentication can also be used in tunnel mode, encapsulating the -underlying IP packet beneath AH and an additional IP header.</p> -<pre> || -IPv4 | new IP hdr* | | orig IP hdr* | | | - |(any options)| AH | (any options) |TCP | Data | - ------------------------------------------------ - || - | in the new IP hdr |</pre> - -<p>This would normally be used in a gateway-to-gateway tunnel. The receiving -gateway then strips the outer IP header and the AH header and forwards the -inner IP packet.</p> - -<p>The mutable fields referred to are things like the time-to-live field in -the IP header. These cannot be included in authentication calculations -because they change as the packet travels.</p> - -<h4><a name="keyed">Keyed MD5 and Keyed SHA</a></h4> - -<p>The actual authentication data in the header is typically 96 bits and -depends both on a secret shared between sender and receiver and on every byte -of the data being authenticated. The technique used is <a -href="glossary.html#HMAC">HMAC</a>, defined in RFC 2104.</p> - -<p>The algorithms involved are the <a href="glossary.html#MD5">MD5</a> -Message Digest Algorithm or <a href="glossary.html#SHA">SHA</a>, the Secure -Hash Algorithm. For details on their use in this application, see RFCs 2403 -and 2404 respectively.</p> - -<p>For descriptions of the algorithms themselves, see RFC 1321 for MD5 and <a -href="glossary.html#FIPS">FIPS</a> (Federal Information Processing Standard) -number 186 from <a href="glossary.html#NIST">NIST</a>, the US National -Institute of Standards and Technology for SHA. <a -href="biblio.html#schneier"><cite>Applied Cryptography</cite></a> covers both -in some detail, MD5 starting on page 436 and SHA on 442.</p> - -<p>These algorithms are intended to make it nearly impossible for anyone to -alter the authenticated data in transit. The sender calculates a digest or -hash value from that data and includes the result in the authentication -header. The recipient does the same calculation and compares results. For -unchanged data, the results will be identical. The hash algorithms are -designed to make it extremely difficult to change the data in any way and -still get the correct hash.</p> - -<p>Since the shared secret key is also used in both calculations, an -interceptor cannot simply alter the authenticated data and change the hash -value to match. Without the key, he or she (or even the dreaded They) cannot -produce a usable hash.</p> - -<h4><a name="sequence">Sequence numbers</a></h4> - -<p>The authentication header includes a sequence number field which the -sender is required to increment for each packet. The receiver can ignore it -or use it to check that packets are indeed arriving in the expected -sequence.</p> - -<p>This provides partial protection against <a -href="glossary.html#replay">replay attacks</a> in which an attacker resends -intercepted packets in an effort to confuse or subvert the receiver. Complete -protection is not possible since it is necessary to handle legitmate packets -which are lost, duplicated, or delivered out of order, but use of sequence -numbers makes the attack much more difficult.</p> - -<p>The RFCs require that sequence numbers never cycle, that a new key always -be negotiated before the sequence number reaches 2^32-1. This protects both -against replays attacks using packets from a previous cyclce and against <a -href="glossary.html#birthday">birthday attacks</a> on the the packet -authentication algorithm.</p> - -<p>In Linux FreeS/WAN, the sequence number is ignored for manually keyed -connections and checked for automatically keyed ones. In manual mode, there -is no way to negotiate a new key, or to recover from a sequence number -problem, so we don't use sequence numbers.</p> - -<h3><a name="ESP.ipsec">Encapsulated Security Payload (ESP)</a></h3> - -<p>The ESP protocol is defined in RFC 2406. It provides one or both of -encryption and packet authentication. It may be used with or without AH -packet authentication.</p> - -<p>Note that <strong>some form of packet authentication should -<em>always</em> be used whenever data is encrypted</strong>. Without -authentication, the encryption is vulnerable to active attacks which may -allow an enemy to break the encryption. ESP should <strong>always</strong> -either include its own authentication or be used with AH authentication.</p> - -<p>The RFCs require support for only two mandatory encryption algorithms -- -<a href="glossary.html#DES">DES</a>, and null encryption -- and for two -authentication methods -- keyed MD5 and keyed SHA. Implementers may choose to -support additional algorithms in either category.</p> - -<p>The authentication algorithms are the same ones used in the IPsec <a -href="#AH">authentication header</a>.</p> - -<p>We do not implement single DES since <a -href="politics.html#desnotsecure">DES is insecure</a>. Instead we provide <a -href="glossary.html#3DES">triple DES or 3DES</a>. This is currently the only -encryption algorithm supported.</p> - -<p>We do not implement null encryption since it is obviously insecure.</p> - -<h2><a name="modes">IPsec modes</a></h2> - -<p>IPsec can connect in two modes. Transport mode is a host-to-host -connection involving only two machines. In tunnel mode, the IPsec machines -act as gateways and trafiic for any number of client machines may be -carried.</p> - -<h3><a name="tunnel.ipsec">Tunnel mode</a></h3> - -<p>Security gateways are required to support tunnel mode connections. In this -mode the gateways provide tunnels for use by client machines behind the -gateways. The client machines need not do any IPsec processing; all they have -to do is route things to gateways.</p> - -<h3><a name="transport.ipsec">Transport mode</a></h3> - -<p>Host machines (as opposed to security gateways) with IPsec implementations -must also support transport mode. In this mode, the host does its own IPsec -processing and routes some packets via IPsec.</p> - -<h2><a name="parts">FreeS/WAN parts</a></h2> - -<h3><a name="KLIPS.ipsec">KLIPS: Kernel IPsec Support</a></h3> - -<p>KLIPS is <strong>K</strong>erne<strong>L</strong> <strong>IP</strong>SEC -<strong>S</strong>upport, the modifications necessary to support IPsec within -the Linux kernel. KILPS does all the actual IPsec packet-handling, -including</p> -<ul> - <li>encryption</li> - <li>packet authentication calculations</li> - <li>creation of ESP and AH headers for outgoing packets</li> - <li>interpretation of those headers on incoming packets</li> -</ul> - -<p>KLIPS also checks all non-IPsec packets to ensure they are not bypassing -IPsec security policies.</p> - -<h3><a name="Pluto.ipsec">The Pluto daemon</a></h3> - -<p><a href="manpage.d/ipsec_pluto.8.html">Pluto(8)</a> is a daemon which -implements the IKE protocol. It</p> -<ul> - <li>handles all the Phase one ISAKMP SAs</li> - <li>performs host authentication and negotiates with other gateways</li> - <li>creates IPsec SAs and passes the data required to run them to KLIPS</li> - <li>adjust routing and firewall setup to meet IPsec requirements. See our - <a href="firewall.html">IPsec and firewalling</a> document for - details.</li> -</ul> - -<p>Pluto is controlled mainly by the <a -href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> configuration file.</p> - -<h3><a name="command">The ipsec(8) command</a></h3> - -<p>The <a href="manpage.d/ipsec.8.html">ipsec(8)</a> command is a front end -shellscript that allows control over IPsec activity.</p> - -<h3><a name="ipsec.conf">Linux FreeS/WAN configuration file</a></h3> - -<p>The configuration file for Linux FreeS/WAN is</p> -<pre> /etc/ipsec.conf</pre> - -<p>For details see the <a -href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> manual page .</p> - -<h2><a name="key">Key management</a></h2> - -<p>There are several ways IPsec can manage keys. Not all are implemented in -Linux FreeS/WAN.</p> - -<h3><a name="current">Currently Implemented Methods</a></h3> - -<h4><a name="manual">Manual keying</a></h4> - -<p>IPsec allows keys to be manually set. In Linux FreeS/WAN, such keys are -stored with the connection definitions in /etc/ipsec.conf.</p> - -<p><a href="glossary.html#manual">Manual keying</a> is useful for debugging -since it allows you to test the <a href="glossary.html#KLIPS">KLIPS</a> -kernel IPsec code without the <a href="glossary.html#Pluto">Pluto</a> daemon -doing key negotiation.</p> - -<p>In general, however, automatic keying is preferred because it is more -secure.</p> - -<h4><a name="auto">Automatic keying</a></h4> - -<p>In automatic keying, the <a href="glossary.html#Pluto">Pluto</a> daemon -negotiates keys using the <a href="glossary.html#IKE">IKE</a> Internet Key -Exchange protocol. Connections are automatically re-keyed periodically.</p> - -<p>This is considerably more secure than manual keying. In either case an -attacker who acquires a key can read every message encrypted with that key, -but automatic keys can be changed every few hours or even every few minutes -without breaking the connection or requiring intervention by the system -administrators. Manual keys can only be changed manually; you need to shut -down the connection and have the two admins make changes. Moreover, they have -to communicate the new keys securely, perhaps with <a -href="glossary.html#PGP">PGP</a> or <a href="glossary.html#SSH">SSH</a>. This -may be possible in some cases, but as a general solution it is expensive, -bothersome and unreliable. Far better to let <a -href="glossary.html#Pluto">Pluto</a> handle these chores; no doubt the -administrators have enough to do.</p> - -<p>Also, automatic keying is inherently more secure against an attacker who -manages to subvert your gateway system. If manual keying is in use and an -adversary acquires root privilege on your gateway, he reads your keys from -/etc/ipsec.conf and then reads all messages encrypted with those keys.</p> - -<p>If automatic keying is used, an adversary with the same privileges can -read /etc/ipsec.secrets, but this does not contain any keys, only the secrets -used to authenticate key exchanges. Having an adversary able to authenticate -your key exchanges need not worry you overmuch. Just having the secrets does -not give him any keys. You are still secure against <a -href="glossary.html#passive">passive</a> attacks. This property of automatic -keying is called <a href="glossary.html#PFS">perfect forward secrecy</a>, -abbreviated PFS.</p> - -<p>Unfortunately, having the secrets does allow an <a -href="glossary.html#active">active attack</a>, specifically a <a -href="glossary.html#middle">man-in-the-middle</a> attack. Losing these -secrets to an attacker may not be quite as disastrous as losing the actual -keys, but it is <em>still a serious security breach</em>. These secrets -should be guarded as carefully as keys.</p> - -<h3><a name="notyet">Methods not yet implemented</a></h3> - -<h4><a name="noauth">Unauthenticated key exchange</a></h4> - -<p>It would be possible to exchange keys without authenticating the players. -This would support <a href="glossary.html#carpediem">opportunistic -encryption</a> -- allowing any two systems to encrypt their communications -without requiring a shared PKI or a previously negotiated secret -- and would -be secure against <a href="glossary.html#passive">passive attacks</a>. It -would, however, be highly vulnerable to active <a -href="glossary.html#middle">man-in-the-middle</a> attacks. RFC 2408 therefore -specifies that all <a href="glossary.html#ISAKMP">ISAKMP</a> key management -interactions <em>must</em> be authenticated.</p> - -<p>There is room for debate here. Should we provide immediate security -against <a href="glossary.html#passive">passive attacks</a> and encourage -widespread use of encryption, at the expense of risking the more difficult <a -href="glossary.html#active">active attacks</a>? Or should we wait until we -can implement a solution that can both be widespread and offer security -against active attacks?</p> - -<p>So far, we have chosen the second course, complying with the RFCs and -waiting for secure DNS (see <a href="glossary.html#DNS">below</a>) so that we -can do <a href="glossary.html#carpediem">opportunistic encryption</a> -right.</p> - -<h4><a name="DNS">Key exchange using DNS</a></h4> - -<p>The IPsec RFCs allow key exchange based on authentication services -provided by <a href="glossary.html#SDNS">Secure DNS</a>. Once Secure DNS -service becomes widely available, we expect to make this the <em>primary key -management method for Linux FreeS/WAN</em>. It is the best way we know of to -support <a href="glossary.html#carpediem">opportunistic encryption</a>, -allowing two systems without a common PKI or previous negotiation to secure -their communication.</p> - -<p>We currently have code to acquire RSA keys from DNS but do not yet have -code to validate Secure DNS signatures.</p> - -<h4><a name="PKI">Key exchange using a PKI</a></h4> - -<p>The IPsec RFCs allow key exchange based on authentication services -provided by a <a href="glossary.html#PKI">PKI</a> or Public Key -Infrastructure. With many vendors selling such products and many large -organisations building these infrastructures, this will clearly be an -important application of IPsec and one Linux FreeS/WAN will eventually -support.</p> - -<p>On the other hand, this is not as high a priority for Linux FreeS/WAN as -solutions based on <a href="glossary.html#SDNS">secure DNS</a>. We do not -expect any PKI to become as universal as DNS.</p> - -<p>Some <a href="web.html#patch">patches</a> to handle authentication with -X.509 certificates, which most PKIs use, are available.</p> - -<h4><a name="photuris">Photuris</a></h4> - -<p><a href="glossary.html#photuris">Photuris</a> is another key management -protocol, an alternative to IKE and ISAKMP, described in RFCs 2522 and 2523 -which are labelled "experimental". Adding Photuris support to Linux FreeS/WAN -might be a good project for a volunteer. The likely starting point would be -the OpenBSD photurisd code.</p> - -<h4><a name="skip">SKIP</a></h4> - -<p><a href="glossary.html#SKIP">SKIP</a> is yet another key management -protocol, developed by Sun. At one point it was fairly widely used, but it -now seems moribund, displaced by IKE. Sun now (as of Solaris 8.0) ship an -IPsec implementation using IKE. We have no plans to implement SKIP. If a user -were to implement it, we would almost certainly not want to add the code to -our distribution.</p> -</body> -</html> |