MISSION CRITICAL! INTERNET SECURITY phần 3 docx

IPSec • Chapter 3 85 Although ISAKMP is responsible for supplying the consistent framework under which encryption keys are transferred, it is not the same as a “key exchange” protocol. Additionally, the ISAKMP protocol is not responsible for key generation, encryption algorithms, or authentication mechanisms. ISAKMP is responsible for supporting the negotiation of SAs at all levels of the OSI model, and its centralization of management of SAs reduces the amount of duplicated functionality within each security protocol. A Security Association is a one-way connection that defines the security services that the traffic traveling through it will be using. Security services are granted to an SA through the use of the Authentication Header (AH) or Encrypting Security Payload (ESP), but not both. When using more than one security mechanism simultaneously, then two (or more) SAs are created to afford protection to the traffic stream. To secure typical, bi-directional communication between two hosts, or between two security gateways, two SAs (one in each direction) are required. Because there are two types of IPSec tunnels that can be created (host to gateway and gateway to gateway) there are two distinct types of SAs that can be defined: transport mode and tunnel mode. A transport mode SA, or an SA between two hosts, the security header appears immediately after the IP header in IPv4 and after the base IP header and extensions in IPv6 (see the Authentication Header section for more information). A tunnel mode SA is an SA applied to an IP tunnel. The general rule for tunnel mode is that if either end of the association is a security gateway the SA must be a tunnel mode SA. For the determination of what a “gateway” is you need to look at what activities the host is performing. If the host in question is transitioning traffic it is a gateway. If the host is the destination for the datagrams in question, it is a host and will not require the tunnel mode SA. This distinction is made due to packet frag- mentation and reassembly. If there are multiple paths to an inside destina- tion via different security gateways, the datagrams should be allowed to pass through without reassembly. In a tunnel mode SA there are two IP headers—one for the outer por- tion that tells the datagram where the IPSec processing destination is, and an inner header that tells the datagram what the ultimate destination for the data is. SA Functionality What the SA does and how it operates is dependent on several factors: the security protocol selected, the SA mode, the endpoints of the SA, and on the optional services within the protocol. An example of this is the granularity of the security in an IP datagram. AH provides “data origin authentication and connectionless integrity,” but the precision of the authentication service is determined by the SA with which the Authentication Header is employed. www.syngress.com 115_MC_intsec_03 12/12/00 3:08 PM Page 85 86 Chapter 3 • IPSec Through the use of sequence integrity, AH offers anti-replay services at the discretion of the receiver (the receiver always determines if anti-replay is engaged, but regardless of whether it is used or not, the AH sequence number field is always set to zero when a communication starts and incre- ments upwards by one). Because AH is not responsible for encrypting datagrams, it is a good choice for communications that need content integrity but not confidentiality. IP packets transmitted via a single SA can either be protected by AH or ESP, but not both. When a combination of security policies is called for, multiple SAs must be employed in a “security association bundle.” SAs in the bundle may terminate at different endpoints but they are combined typically in one of two ways: ■ Transport Adjacency This refers to the application of more than one security protocol to the same IP datagram, without the use of a tunnel. As you can see in Figure 3.3, the use of two security pro- tocols requires the use of two SAs, even though the communica- tion channel exists between only two hosts. ■ Iterated Tunneling This refers to the application of multiple layers of security protocols through IP tunneling. As shown in Figure 3.4, SA 1 and SA 2 include discreet datastream between the endpoints, each within an IPSec tunnel of their own. This section taught you that a Security Association is required for IPSec communications because it is what determines the security language that the hosts or gateways will use to converse with each other. www.syngress.com Figure 3.3 Transport adjacency. 1010101010101010101010101010101010101010101010101010 Host 1 Host 2Firewall Firewall Internet SA #1 - Authentication Header SA #2 - Encrypting Security Payload 115_MC_intsec_03 12/12/00 3:08 PM Page 86 IPSec • Chapter 3 87 Concentrated ISAKMP We already talked a little bit about ISAKMP, but it’s important that we talk just a little bit more, to allow us to get a complete picture of the Security Association. Going back to our RFC resource for a minute, the ISAKMP protocol allows us to combine the security concepts of authentication, key management, and security associations to create the required security for communications over the Internet or other public networks. SAs are a core component of the key management protocol and are linked with the authentication and key exchange process. When hosts or gateways set up for secure communication, they must first come to an agreement on the initial security attributes. It’s through this secure channel that ISAKMP communicates its subsequent messages. As stated by RFC 2408, this ini- tial security also “indicates the authentication method and key exchange that will be performed as part of the ISAKMP protocol.” After all the upfront and basic security attributes have been set up (identities authenti- cated, keys generated, and so on), this SA can be used for ongoing commu- nications. Strong authentication must be used in ISAKMP exchanges. A strong authenticator is something that is verifiable and difficult to impersonate or substitute. ISAKMP requires the use of digital certificates and digital signa- tures to provide the strong level of authentication required. Without being able to be certain of the authenticity of the entity at the other end of IPSec communication, the SA and session key established are suspect. Additionally, though encryption and integrity will protect all the session communications, without being able to properly authenticate the other end, you could be communicating securely with “the Enemy.” www.syngress.com Figure 3.4 Iterated tunneling. 1010101010101010101010101010101010101010101010101010 1010101010101010101010101010101010101010101010101010 Host 1 Host 2Firewall Firewall Internet SA #1 SA #2 115_MC_intsec_03 12/12/00 3:08 PM Page 87 88 Chapter 3 • IPSec ISAKMP requires the use of digital certificates, but it also has the ability to allow secondary authentication through optional authentication mechanisms. It provides the protections for secure communications described in the following sections. Prevention from Denial of Service Attacks Denial of Service (DoS) attacks are very difficult to protect against since they use the basics of IP to overload devices listening for connections. (An attacker can send partially formed packets to a device listening for connec- tions and cause it to be in a wait state until it times out the connection. Send a few thousand of these connections and you have effectively denied legitimate users from connecting.) ISAKMP uses a cookie or anti-clogging token (ACT) that is aimed at protecting the computing resources from attack, and it does so without spending excessive CPU resources to deter- mine its authenticity. By performing an exchange prior to CPU-intensive public key operations, you can thwart some Denial of Service attempts (such as simple flooding with bogus IP source addresses). Absolute protec- tion against Denial of Service is impossible, but this goes a long way for making it easier to handle Connection Hijacking Connection hijacking refers to the ability of attackers to insert themselves into a trusted data stream between two hosts, effectively negating the need to hack at accounts or passwords. Because the session is already estab- lished and the two hosts are communicating with each other, when the attackers insert themselves they can take over the connection or desyn- chronize the hosts, causing the connection to drop. ISAKMP can prevent this type of attack by linking the authentication, key exchange, and secu- rity association exchanges. This linking prevents an attacker from allowing the authentication to complete and then jumping in and impersonating one entity to the other during the key and security association exchanges. Man-in-the-Middle Attacks A man-in-the-middle (MITM) attack occurs when two hosts who are com- municating with each other are actually talking with a third party, imper- sonating the other hosts. MITM attacks are difficult to pull off but are powerful because the middle-man can alter data and make it appear that it came from a legitimate communication partner. Consider a communica- tion with your bank to transfer $100 between accounts. A MITM can alter the stream so that you just transferred $10,000 to his account. In sum- mary, man-in-the-middle attacks include interception, insertion, deletion, and modification of messages; reflecting messages back at the sender; replaying old messages; and redirecting messages. ISAKMP can prevent www.syngress.com 115_MC_intsec_03 12/12/00 3:08 PM Page 88 IPSec • Chapter 3 89 these types of attacks from being successful by preventing the insertion of messages in the protocol exchange. ISAKMP requires the use of strong authentication and can prevent an SA from being established with anyone other than the intended party. Messages may be redirected to a different destination or modified but this will be detected and an SA will not be established. ISAKMP defines where abnormal processing has occurred and can notify the appropriate party of this abnormality. Authentication Header (AH) As defined in IETF RFC 2402 (www.ietf.org/rfc/rfc2402), the Authenti- cation Header (AH) is “used to provide connectionless integrity and data origin authentication for IP datagrams and to provide protection against replays.” In this section we will discuss how AH does what it does, and what it means to IPSec and your encrypted communications. In the proc- ess we will interleave information regarding Encapsulating Security Payload (ESP) and Security Association (SA). IPSec tunnels have several methods of implementation, each requiring a slightly different security implementation. The two most common are host-to-gateway and gateway-to-gateway, the former being a tunnel created between a remote host machine and a network and the latter being two (or more) networks connected via a tunnel. Additionally, the industry has two phrases for the method in which IPSec has been implemented. A “Bump-in-the-stack” (BITS) refers to when IPSec has been imple- mented below an existing IP stack—between it and the network drivers. This type of implementation is used with host-based tunnel creation since it easily slips into the communication channel via a third-party driver. When in host or transport mode, the AH is placed after the IP header, but before the upper layer protocol or any other IPSec headers (see Figure 3.5). When used with IPv6, AH is considered to be an end-to-end payload and will appear after routing and extension headers (see Figure 3.6). www.syngress.com Figure 3.5 IPv4 before and after AH insertion. IPv4 IPv4 Orig. IP Header + Options TCP DATA Orig. IP Header + Options TCP DATAAH 115_MC_intsec_03 12/12/00 3:08 PM Page 89 90 Chapter 3 • IPSec A “Bump-in-the-wire” (BITW) refers to when IPSec has been imple- mented as an outside process or device (such as a network encryptor). The device can service both gateways and hosts, and although it’s reachable as a network node, its presence is similar to a gateway in that all traffic for the IPSec tunnel is passed through it with little intervention from the host. Regardless of where the tunnel is created (host or gateway), the datagram in question must be transformed with the AH so that it may be secured. By placing the AH in the datagram prior to the data payload, it is pos- sible to determine if the packet has been tampered with in transit. In the next section we will take a look at what is contained in the Authentication Header, and how you can prevent over-the-wire interference with your datagrams. Authentication Header Format The Authentication Header depicted in Figure 3.7 follows the same struc- ture and format for implementations in IPv4 and 6. The changes between protocol versions are within the header fields themselves. www.syngress.com Figure 3.6 IPv6 before and after AH insertion. IPv6 IPv6 Orig. IP Header + Options Orig. IP Header + Options Destination Options TCPAH TCP DATAEXT Headers Hop-by-Hop DATA Authenticated except for fields that are mutable Figure 3.7 The AH Header. 61 2 3 4 5 70 49 0 1 2 3 58 27 8 9 0 1 36 Authentication Data (Variable) Sequence Number Field Security Parameters Index (SPI) 05 6 7 8 9 14 Next Header Payload Length RESERVED 0 1 2 3 115_MC_intsec_03 12/12/00 3:08 PM Page 90 IPSec • Chapter 3 91 The basic breakdown of the header is as follows Next Header An 8-bit field that identifies the type of the next payload after the Authentication Header. Payload Length An 8-bit field composed of 32 bit-words describing the length of the AH. Reserved A 16-bit field that is reserved for future use. Because of this, it must be set to zero or the packet will be dropped. Security Parameters Index (SPI) A random 32-bit value that is used to identify the SA for a datagram when used in combination with the destina- tion IP address and security protocol. It is ordinarily selected by the desti- nation system upon establishment of an SA. This unsigned 32-bit field contains an increasing counter value or sequence number. This value is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. The decision to use the Sequence Number field is determined by the receiver, so even if the sender sends it, the destination may choose to ignore it. The counter values are all set to zero at the time of the establishment of the SA. If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Authentication Data A variable-length field that contains the Integrity Check Value (ICV) for this packet. This field must always be an integer in multiples of 32 bits in length and can include padding. The padding is to ensure that the value length meets the 32-bit requirement. Understanding the ICV During the transit of the datagram, several of the header fields may be altered to reflect its progress to the final destination. The ICV, which is integral to determining tampering while in transit, is calculated from the immutable or predictable fields in the datagram header, the actual AH header, and upper level protocol data. For every header field that can be altered while in transit, the ICV gives it a zero value (for the purpose of the computation). For every header field that is alterable, but whose value is predictable, ICV uses that value for the computation. ICV keeps mutable and unpredictable fields at a value of zero for two reasons. First, by keeping a value associated with alterable fields instead of removing a value all together, the ICV can keep the calculation aligned with the placement of the fields. Second, by including a zero value it defeats the insertion of a new value in the unused fields for the purpose of the ICV calculation. www.syngress.com 115_MC_intsec_03 12/12/00 3:08 PM Page 91 92 Chapter 3 • IPSec Table 3.1 depicts the fields that are immutable, mutable but pre- dictable, and mutable and zeroed out for the purposes of ICV calculations, for IPv4 and Ipv6. Table 3.1 Mutable and Immutable Fields for IPv4 and IPv6 Field Type Field IP Version Immutable Version v4, v6 Internet Header Length v4 Total Length v4 Identification v4 Protocol v4 Source Address v4, v6 Destination Address v4, v6 Payload length v6 Next Header v6 Mutable but Predictable Destination Address v4, v6 Zeroed Out Type of Service v4 Flags v4 Fragment Offset v4 TTL v4 Header Checksum v4 Class v6 Flow Label v6 Hop Limit v6 Packet Processing During transmission, IP packets can be fragmented, but the Authentication Header is applied only to whole IP datagrams (so defragmentation must occur prior to processing). When an IP datagram appears at the receiving host, if it is marked for AH processing it must be unfragmented or else it will be discarded. Packets marked for AH must be reassembled before reaching the IPSec host or gateway that will process the packet. Once a proper packet that is marked for AH processing is received, the receiver must determine the appropriate SA (based on the destination IP address, the security protocol, and the SPI). If no SA can be determined for the packet, it must be discarded. If sequence numbers are being used (the sequence number value is always calculated and updated, but the destination node determines if it will refer to that value) the receiving station resets the value in the SA to zero at the start of the conversation. Each packet that is received must be checked www.syngress.com 115_MC_intsec_03 12/12/00 3:08 PM Page 92 IPSec • Chapter 3 93 for the sequence number to make sure it has not been duplicated or that it is not out of order. Duplicate packets or packets with incorrect sequencing are rejected. If the packet appears to be correct (for example, it is not lower in sequence than the last received packet, and it falls within the window of acceptable sequence numbers), the receiving station performs ICV verifica- tion. Any failure while checking ICV will require the packet to be discarded. The sequence window is updated only if the packet passes ICV verification. The receiver can validate the ICV by saving the ICV value, zeroing out all other fields modified in transit, and pushing the result through an algo- rithm. If the computed result equals the saved result, the ICV is validated. Encapsulating Security Payload (ESP) Encapsulating Security Payload (ESP) is documented in IETF RFC 2406 (www.ietf.org/rfc/2406) and is designed to provide confidentiality, authen- tication of the sender, data integrity, and anti-replay services. ESP can be used on its own or in conjunction with the Authentication Header in either IPv4 or IPv6. As with other IPSec protocols, what ESP provides is depen- dent on what the Security Association requires of it. It is important to note, however, that the use of confidentiality without the use of authentication could create a situation where you are securely sending data to a compro- mised or unintended recipient. The ESP Header format, depicted in Figure 3.8, is broken out as follows: Security Parameters Index (SPI) In conjunction with the destination IP address and security protocol to identify the Security Association for the datagram. This field is 32 bits and is set to zero for local functions. Zero means that there is no SA yet. Sequence Number An unsigned 32-bit field that increments in a mono- tonic fashion. This field is mandatory and is always present, even if the destination host does not require sequencing for anti-replay. At the begin- ning of the conversation, the counter is set to zero and the first packet will receive a value of 1. If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. The sender’s counter and the receiver’s counter must be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2 32 packet on an SA. Payload Data A field of variable length that contains data described by the Next Header field. The Payload Data field is mandatory and is an inte- gral number of bytes in length. In the case where the encryption algorithm used to encrypt the payload requires synchronization data (otherwise known as an Initialization Vector) then that data can be explicitly carried in the Payload field. www.syngress.com 115_MC_intsec_03 12/12/00 3:08 PM Page 93 94 Chapter 3 • IPSec Padding (for Encryption) There are several reasons that padding would be required: ■ If an encryption algorithm is employed that requires the plain text to be a multiple of some number of bytes, for example, the block size of a block cipher, the Padding field is used to fill the plain text (consisting of the Payload Data, Pad Length, and Next Header fields, as well as the Padding) to the size required by the algorithm. ■ Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right-aligned within a 4-byte word, as illustrated in the ESP packet format in Figure 3.8, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary. ■ Padding beyond that required for the algorithm or alignment rea- sons just cited may be used to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth impli- cations and thus its use should be undertaken with care. Pad Length A mandatory field indicating how many bytes are immediately preceding it. www.syngress.com Figure 3.8 ESP Header format. Security Parameters Index (SPI) Sequence Number Authentication Data (variable) Payload Data (variable) Pad Length Next Header Padding 115_MC_intsec_03 12/12/00 3:08 PM Page 94 [...]... www.syngress.com 1 03 115_MC_intsec_ 03 12/12/00 3: 08 PM Page 104 115_MC_intsec_04 12/12/00 3: 09 PM Page 105 Chapter 4 Internet Security Applications Solutions in this chapter: s Using Digital Signatures s Acquiring Digital Certificates s Understanding SSL s Understanding SSH s Understanding PGP s Understanding S/MIME s Understanding Kerberos 105 115_MC_intsec_04 106 12/12/00 3: 09 PM Page 106 Chapter 4 • Internet Security. .. digital certificates is X.509v3 The X.509 Standard The X.509v3 standard, defined in Request for Comments (RFC) 2459, describes an agreed-upon format for digital certificates Version 1 and 2 digital certificates are not widely in use, so we will concentrate only on version 3 www.syngress.com 115_MC_intsec_04 12/12/00 3: 09 PM Page 115 Internet Security Applications • Chapter 4 This X.509v3 standard defines the elements... rarely provide adequate security for a system Public keys are relatively secureæso long as they are trusted See if you notice other patterns, as this will help you to find flaws and spot limitations of new protocols and applications as they are introduced www.syngress.com 107 115_MC_intsec_04 108 12/12/00 3: 09 PM Page 108 Chapter 4 • Internet Security Applications Security Services Most security software can... establish communication channels over Transmission Control Protocol /Internet Protocol (TCP/IP) networks SSL was designed to be a separate security protocol that enhances the HTTP standard Logically, SSL inserts itself between the HTTP application protocol and the TCP layer of a www.syngress.com 119 115_MC_intsec_04 120 12/12/00 3: 09 PM Page 120 Chapter 4 • Internet Security Applications conversation This... public keys and secret keys differ in their size /security relationship For example, a 512-bit RSA key actually provides less security than a 128-bit Blowfish key Table 4.1 summarizes some generally agreed-upon public key lengths in relation to secret key block ciphers www.syngress.com 111 115_MC_intsec_04 112 12/12/00 3: 09 PM Page 112 Chapter 4 • Internet Security Applications Table 4.1 Comparable Sizes... provided adequate security for most purposes SSL or TLS? The Internet Engineering Task Force (IETF) is responsible for the future development of the SSL standard, now known as Transport Layer Security (TLS) (The Netscape Communications Corporation originally developed TLS.) TLS 1.0, defined in RFC 2246, offers only minor enhancements to the SSL 3. 0 protocol Effectively, TLS is SSL version 3. 1 New enhancements... signature can help verify that a document or transaction was not modified from its original state at the time of signing www.syngress.com 115_MC_intsec_04 12/12/00 3: 09 PM Page 1 13 Internet Security Applications • Chapter 4 How Does a Digital Signature Add Security? Unlike a handwritten signature, digital signatures are almost un-forgeable when implemented properly Under ideal circumstances, this means that... termed “symmetric” utilizes the same passphrase for the plain-text to ciphertext transition as for the ciphertext to plain-text transition www.syngress.com 95 115_MC_intsec_ 03 96 12/12/00 3: 08 PM Page 96 Chapter 3 • IPSec Figure 3. 10 ESP Header placement in IPv6 IPv6 IP Header Ext Headers IPv6 IP Header Hop-by-hop ESP Header TCP Data Destination Options TCP Data ESP Trailer ESP Auth Encrypted Authenticated... approach to security Figure 4.1 A scenario using SSL and SSH together Web browser Firewall Internet Demilitarized Zone (DMZ) SSL encryption between a Web browser and a Web server Web server SSH session from an administrator on the internal network to the Web server Firewall Internal Network Administrator workstation Security Concerns Different applications discussed in this chapter address different security. .. message and produce a 128-bit digest This digest is used to verify that the contents of the message have not changed during transmission, by recreating the digest at the receiving end and comparing them www.syngress.com 97 115_MC_intsec_ 03 98 12/12/00 3: 08 PM Page 98 Chapter 3 • IPSec The Encryption Process The process of encrypting an IP packet with ESP is as follows: s The sender encapsulates into . except for fields that are mutable Figure 3. 7 The AH Header. 61 2 3 4 5 70 49 0 1 2 3 58 27 8 9 0 1 36 Authentication Data (Variable) Sequence Number Field Security Parameters Index (SPI) 05 6 7. your internal computing infrastructure. www.syngress.com 115_MC_intsec_ 03 12/12/00 3: 08 PM Page 1 03 115_MC_intsec_ 03 12/12/00 3: 08 PM Page 104 . other. www.syngress.com Figure 3. 3 Transport adjacency. 1010101010101010101010101010101010101010101010101010 Host 1 Host 2Firewall Firewall Internet SA #1 - Authentication Header SA #2 - Encrypting Security Payload 115_MC_intsec_03