tion algorithms -- DES, and null encryption -- and for two authentication methods -- keyed MD5 and keyed SHA. Implementers may choose to support additional algorithms in either category.
The authentication algorithms are the same ones used in the IPSEC authentication header.
We do not implement single DES since DES is insecure. Instead we provide triple DES or 3DES. This is currently the only encryption algorithm supported.
We do not implement null encryption since it is obviously insecure.
IPSEC modes IPSEC can connect in two modes. Transport mode is a host-to-host connection involving only two machines. In tunnel mode, the IPSEC machines act as gateways and trafiic for any number of client machines may be carried.
Tunnel mode Security gateways are required to support tunnel mode connections. In this mode the gateways provide tunnels for use by client machines behind the gateways. The client machines need not do any IPSEC processing; all they have to do is route things to gateways.
Transport mode Host machines (as opposed to security gateways) with IPSEC implementations must also support transport mode. In this mode, the host does its own IPSEC processing and routes some packets via IPSEC.
FreeS/WAN parts KLIPS: Kernel IPSEC Support KLIPS is KerneL IP SEC Support, the modifications necessary to support IPSEC within the Linux kernel. KILPS does all the actual IPSEC packet-handling, including
encryption packet authentication calculations creation of ESP and AH headers for outgoing packets interpretation of those headers on incoming packets KLIPS also checks all non-IPSEC packets to ensure they are not bypassing IPSEC security policies.
The Pluto daemon Pluto(8) is a daemon which implements the IKE protocol. It
handles all the Phase one ISAKMP SAs performs host authentication and negotiates with other gateways creates IPSEC SAs and passes the data required to run them to KLIPS adjust routing and firewall setup to meet IPSEC requirements. See our IPSEC and firewalling document for details. Pluto is controlled mainly by the ipsec.conf(5) configuration file.
The ipsec(8) command The ipsec(8) command is a front end that allows control over IPSEC activity.
Linux FreeS/WAN configuration file The configuration file for Linux FreeS/WAN is
/etc/ipsec.conf
For details see the ipsec.conf(5) manual page and our Configuration section. Key management There are several ways IPSEC can manage keys. Not all are implemented in Linux FreeS/WAN.
Currently Implemented Methods Manual keying IPSEC allows keys to be manually set. In Linux FreeS/WAN, such keys are stored with the connection definitions in /etc/ipsec.conf.
Manual keying is useful for debugging since it allows you to test the KLIPS kernel IPSEC code without the Pluto daemon doing key negotiation.
In general, however, automatic keying is preferred because it is more secure.
+Automatic keying In automatic keying, the Pluto daemon negotiates keys using the IKE Internet Key Exchange protocol. Connections are automatically re-keyed periodically.
This is considerably more secure than manual keying. In either case an attacker who acquires a key can read every message encrypted with that key, but automatic keys can be changed every few hours or even every few minutes without breaking the connection or requiring intervention by the system administrators. Manual keys can only be changed manually; you need to shut down the connection and have the two admins make changes. Moreover, they have to communicate the new keys securely, perhaps with PGP or SSH. This may be possible in some cases, but as a general solution it is expensive, bothersome and unreliable. Far better to let Pluto handle these chores; no doubt the administrators have enough to do.
Also, automatic keying is inherently more secure against an attacker who manages to subvert your gateway system. If manual keying is in use and an adversary acquires root privilege on your gateway, he reads your keys from /etc/ipsec.conf and then reads all messages encrypted with those keys.
If automatic keying is used, an adversary with the same privileges can read /etc/ipsec.secrets, but this does not contain any keys, only the secrets used to authenticate key exchanges. Having an adversary able to authenticate your key exchanges need not worry you overmuch. Just having the secrets does not give him any keys. You are still secure against passive attacks. This property of automatic keying is called perfect forward secrecy, abbreviated PFS.
Unfortunately, having the secrets does allow an active attack, specifically a man-in-the-middle attack. Losing these secrets to an attacker may not be quite as disastrous as losing the actual keys, but it is still a serious security breach. These secrets should be guarded as carefully as keys.
Methods not yet implemented 1.Unauthenticated key exchange It would be possible to exchange keys without authenticating the players. This would support opportunistic encryption -- allowing any two systems to encrypt their communications without requiring a shared PKI or a previously negotiated secret -- and would be secure against passive attacks. It would, however, be highly vulnerable to active man-in-the-middle attacks. RFC 2408 therefore specifies that all ISAKMP key management interactions must be authenticated.
There is room for debate here. Should we provide immediate security against passive attacks and encourage widespread use of encryption, at the expense of risking the more difficult active attacks? Or should we wait until we can implement a solution that can both be widespread and offer security against active attacks?
So far, we have chosen the second course, complying with the RFCs and waiting for secure DNS (see below) so that we can do opportunistic encryption right.
2.Key exchange using DNS The IPSEC RFCs allow key exchange based on authentication services provided by Secure DNS. Once Secure DNS service becomes widely available, we expect to make this the primary key management method for Linux FreeS/WAN. It is the best way we know of to support opportunistic encryption, allowing two systems without a common PKI or previous negotiation to secure their communication.
As of FreeS/WAN 1.4, we have experimental code to acquire RSA keys from DNS but do not yet have code to validate Secure DNS signatures.
3.Key exchange using a PKI The IPSEC RFCs allow key exchange based on authentication services provided by a PKI or Public Key Infrastructure. With many vendors selling such products and many large organisations building these infrastructures, this will clearly be an important application of IPSEC and one Linux FreeS/WAN will eventually support.
On the other hand, this is not as high a priority for Linux FreeS/WAN as solutions based on secure DNS . We do not expect any PKI to become as universal as DNS.
Some patches to handle authentication with X.509 certificates, which most PKIs use, are available.
4.Photuris Photuris is another key management protocol, an alternative to IKE and ISAKMP, described in RFCs 2522 and 2523 which are labelled "experimental". Adding Photuris support to Linux FreeS/WAN might be a good project for a volunteer. The likely starting point would be the OpenBSD photurisd code.
SKIP SKIP is yet another key management protocol, developed by Sun. At one point it was fairly widely used, but our current impression is that it is moribund, displaced by IKE. Sun now (as of Solaris 8.0) ship an IPSEC implementation using IKE. We have no plans to implement SKIP.
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
