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