yption. If you have an IPSEC tunnel between two branch offices, it might appear silly to send PGP-encrypted email through that tunnel. However, if you suspect someone is snooping your traffic, then it does make sense:
it protects the mail headers; they cannot even see who is mailing who
it protects against user bungles or software malfunctions that accidentally send messages in the clear
it makes any attack on the mail encryption much harder; first they have to find the mail
Similar arguments apply for SSL-encrypted web traffic or SSH-encrypted remote login sessions, even for end-to-end IPSEC tunnels between systems in the two offices.
2.Using fewer tunnels
It may also help to use fewer tunnels. For example, if all you actually need encrypted is connections between:
mail servers at branch and head offices
a few branch office users and the head office database server
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?
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:
it is easier to build and administer
it resists traffic analysis somewhat better
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.
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.
Cryptographic components
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.
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 glossary. See also our bibliography and cryptography web links.
Block ciphers
The encryption in the ESP encapsulation protocol is done with a block cipher.
We do not implement single DES. It is insecure. Our default, and currently only, block cipher is triple DES .
The Rijndael block cipher has just won the AES competition to choose a relacement for DES. It will almost certainly be added to FreeS/WAN and to other IPSEC implementations.
Hash functions
The HMAC construct
IPSEC packet authentication is done with the HMAC construct. This is not just a hash of the packet data, but a more complex operation which uses both a hashing algorithm (MD5 or SHA) 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.
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.
Diffie-Hellman key agreement
The Diffie-Hellman key agreement protocol allows two parties (A and B or Alice and Bob) to agree on a key in such a way that an eavesdropper who intercepts the entire conversation cannot learn the key.
The protocol is based on the discrete logarithm 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.
RSA authentication
The RSA algorithm (named for its inventors -- Rivest, Shamir and Adleman) is a very widely used public key cryptographic technique. It is used in IPSEC as one method of authenticating gateways for Diffie-Hellman key negotiation.
Structure of IPSEC
There are three protocols used in an IPSEC implementation:
ESP, Encapsulating Security Payload
Encrypts and/or authenticates data
AH, Authentication Header
Provides a packet authentication service
IKE, Internet Key Exchange
Negotiates connection parameters, including keys, for the other two
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.
IKE (Internet Key Exchange)
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.
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:
ISAKMP (RFC 2408)
The Internet Security A ssociation and Key Management Protocol manages negotiation of connections and defines SAs (Security Associations) as a means of describing connection properties.
IPSEC DOI for ISAKMP (RFC 2407)
A Domain Of I 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.
Oakley key determination protocol (RFC 2412)
Oakley creates keys using the Diffie-Hellman key agreement protocol.
For all the details, you would need to read the four RFCs just mentioned (over 200 pages) and a number of others. We give a summary below, but it is far from complete.
1.Phases of IKE
IKE negotiations have two phases.
Phase one
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.
Phase two
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.
Both of these phases use the UDP protocol and port 500 for their negotiations.
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.
The IKE protocol is designed to be extremely flexible. Among the things that can be negotiated (separately for each SA) are:
SA lifetime before rekeying
encryption algorithm used. We currently support only triple DES. Single DES is insecure. The RFCs say you MUST do DES, SHOULD do 3DES and MAY do various others. We do not do any of the others.
authentication algorithms. We support MD5 and SHA. These are the two the RFCs require.
choice of group for Diffie-Hellman 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.
The protocol also allows implementations to add their own encryption algorithms, authentication algorithms or Diffie-Hellman groups. We do not support any such extensions.
There are a number of complications:
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 configuration document.
Phase one can be done in two ways.
Main Mode is required by the RFCs and supported in FreeS/WAN.
Aggressive Mode is somewhat faster but reveals more to an eavesdropper. This is optional in the RFCs, not currently supported by FreeS/WAN, and not likely to be.
Phase two always uses Quick Mode, but there are two variants of that:
One variant provides Perfect Forward Secrecy (PFS). 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.
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 上一页 [1] [2] [3] [4] [5] 下一页 |
