IP Security Architecture Overview

The IP security architecture (IPsec) provides cryptographic protection for IP datagrams in IPv4 and IPv6 network packets. This protection can include confidentiality, strong integrity of the data, data authentication, and partial sequence integrity. Partial sequence integrity is also known as replay protection.

IPsec is performed inside the IP module. IPsec can be applied with or without the knowledge of an Internet application. When used properly, IPsec is an effective tool in securing network traffic.

Authentication Header

Format

There are two protocol header’s available for the version used that proceed the AH header. The value is to be set 51 for Protocol (IPv4) or Next Header (IPv6, IPv6 Extension) fields. The fields that make up our AH are:

****Next Header:

A byte long field giving the type of next payload. If this value is 4 so IPv4, 41 is for IPv6 and 6 tells that it is TCP. This is used to link headers together.

****Payload Length:

A byte long field measuring the total length of AH in 4-byte units minus 2. So suppose if the integrity algorithm gives a value of 96-bit, this field will be 4. (3 32-bit words fixed field plus 3 32-bit words for ICV, minus 2)

****Reserved:

These two bytes have been reserved for future implementation. So when formulating the packet it is set to be zero and is ignored at the receiver end.

****Security Parameter Index:

A 32-bit field which is used by the receiver to identify the SA of the incoming packet.

****Sequence Number:

An unsigned 32-bit field. This is basically packet counter which is incremented by one for each packet sent. At the initialization of SA, both sender and receiver Sequence Number is set to zero

****Extended Sequence Number:

This is an extension that is available for high-speed IPsec implementations. For IKEv2, this negotiation is implicit.

****Integrity Check Value:

The last field is a variable-length which contains ICV for the packet. ICV is basically the results obtained from the hashing algorithm. The value must be an integral multiple of 32 bits in length.

AH with Modes

Now that we know about its format, the last thing we would like to touch is the effective working of AH in both modes available.

Transport Mode:

Transport Mode provides protection from end-to-end conversations between two hosts. This is not a tunneling procedure but a secured IP connection. The IP packet is changed by inserting the AH header between the IP header and payload. There is shuffling of protocol code linking headers together. When the packet is authenticated, the original protocol type (UDP, TCP) is restored. This is done by removing the AH header and replacing it with the saved Next Protocol.

Tunnel Mode:

This mode makes use of the tunneling concept. As the Tunnel Mode encapsulates the entire IP packet (IP packet + Payload), the source and destination are different from the original packet. When this packet is received at its destination, it discards its IP and AH headers thus giving back the original IP datagram.

Encapsulating Security Payload (ESP)

Encapsulating Security Payload (ESP) is a member of the Internet Protocol Security (IPsec) set of protocols that encrypt and authenticate the packets of data between computers using a Virtual Private Network (VPN). The focus and layer on which ESP operates makes it possible for VPNs to function securely. 

The enhanced version of IPsec in use is an Internet-layer security protocol. It is pre-programmed for IP-layer application security whereas other protocols such as  Transport Layer Security (TLS) and Secure Shell (SSH) function on the application layer. 

Security Authentication Header (AH) is another IPsec member protocol. ESP and AH can operate between hosts and between networks. The can also operate in two modes: the less-secure Transport Mode that encrypts the data packet, for use between two workstations that are running a VPN client; and Tunnel Mode, which is more secure. Tunnel Mode encrypts the whole packet including header info and source, and is used between networks.

COMBINING SECURITY ASSOCIATIONS

An individual SA can implement either the AH or ESP protocol but not both. Sometimes a particular traffic flow will call for the services provided by both AH and ESP. Further, a particular traffic flow may require IPsec services between hosts and, for that same flow, separate services between security gateways, such as fire- walls. In all of these cases, multiple SAs must be employed for the same traffic flow to achieve the desired IPsec services. The term security association bundle refers to a sequence of SAs through which traffic must be processed to provide a desired set of IPsec services. The SAs in a bundle may terminate at different endpoints or at the same endpoints.

Security associations may be combined into bundles in two  ways:

•                           Transport adjacency: Refers to applying more than one security protocol to the same IP packet without invoking tunneling. This approach to combining AH and ESP allows for only one level of combination; further nesting yields no added benefit since the processing is performed at one IPsec instance: the (ultimate) destination.

•                           Iterated tunneling: Refers to the application of multiple layers of security protocols effected through IP tunneling. This approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a different IPsec site along the path.

The two approaches can be combined, for example, by having a transport SA between hosts travel part of the way through a tunnel SA between security gateways. One interesting issue that arises when considering SA bundles is the order in which authentication and encryption may be applied between a given pair of endpoints and the ways of doing so. We examine that issue next. Then we look at combinations of SAs that involve at least one tunnel.

Authentication Plus Confidentiality

Encryption and authentication can be combined in order to transmit an IP packet that has both confidentiality and authentication between hosts. We look at several approaches.

ESP WITH AUTHENTICATION OPTION This approach is illustrated in Figure 19.8. In this approach, the user first applies ESP to the data to be protected and then appends the authentication data field. There are actually two subcases:

•                           Transport mode ESP: Authentication and encryption apply to the IP payload delivered to the host, but the IP header is not protected.

•                           Tunnel mode ESP: Authentication applies to the entire IP packet delivered to the outer IP destination address (e.g., a firewall), and authentication is performed at that destination. The entire inner IP packet is protected by the privacy mechanism for delivery to the inner IP destination.

For both cases, authentication applies to the ciphertext rather than the plaintext.

TRANSPORT ADJACENCY Another way to apply authentication after encryption is to use two bundled transport SAs, with the inner being an ESP SA and the outer being an AH SA. In this case, ESP is used without its authentication option. Because the inner SA is a transport SA, encryption is applied to the IP payload. The resulting packet consists of an IP header (and possibly IPv6 header extensions) followed by an ESP. AH is then applied in transport mode, so that authentication covers the ESP plus the original IP header (and extensions) except for mutable fields. The advantage of this approach over simply using a single ESP SA with the ESP authentication option is that the authentication covers more fields, including the source and destination IP addresses. The disadvantage is the overhead of two SAs versus one SA.

TRANSPORT-TUNNEL BUNDLE The use of authentication prior to encryption might be preferable for several reasons. First, because the authentication data are protected by encryption, it is impossible for anyone to intercept the message and alter the authentication data without detection. Second, it may be desirable to store the authentication information with the message at the destination for later reference. It is more convenient to do this if the authentication information applies to the unencrypted message; otherwise the message would have to be reencrypted to verify the authentication information.

One approach to applying authentication before encryption between two hosts is to use a bundle consisting of an inner AH transport SA and an outer ESP tunnel SA. In this case, authentication is applied to the IP payload plus the IP header (and extensions) except for mutable fields. The resulting IP packet is then processed in tunnel mode by ESP; the result is that the entire, authenticated inner packet is encrypted and a new outer IP header (and extensions) is added.

Basic Combinations of Security Associations

The IPsec Architecture document lists four examples of combinations of SAs that must be supported by compliant IPsec hosts (e.g., workstation, server) or security gateways (e.g. firewall, router). These are illustrated in Figure 19.10. The lower part

of each case in the figure represents the physical connectivity of the elements; the upper part represents logical connectivity via one or more nested SAs. Each SA can be either AH or ESP. For host-to-host SAs, the mode may be either transport or tunnel; otherwise it must be tunnel mode.

Case 1. All security is provided between end systems that implement IPsec. For any two end systems to communicate via an SA, they must share the appropri- ate secret keys. Among the possible combinations are

a.                                       AH in transport mode

b.                                       ESP in transport mode

c.                                        ESP followed by AH in transport mode (an ESP SA inside an AH SA)

d.                                       Any one of a, b, or c inside an AH or ESP in tunnel mode

We have already discussed how these various combinations can be used to support authentication, encryption, authentication before encryption, and authenti- cation after encryption.

Case 2. Security is provided only between gateways (routers, firewalls, etc.) and no hosts implement IPsec. This case illustrates simple virtual private network support. The security architecture document specifies that only a single tunnel SA is needed for this case. The tunnel could support AH, ESP, or ESP with the authenti- cation option. Nested tunnels are not required, because the IPsec services apply to the entire inner packet.

Case 3. This builds on case 2 by adding end-to-end security. The same combi- nations discussed for cases 1 and 2 are allowed here. The gateway-to-gateway tunnel provides either authentication, confidentiality, or both for all traffic between end systems. When the gateway-to-gateway tunnel is ESP, it also provides a limited form of traffic confidentiality. Individual hosts can implement any additional IPsec ser- vices required for given applications or given users by means of end-to-end   SAs.

Case 4. This provides support for a remote host that uses the Internet to reach an organization’s firewall and then to gain access to some server or workstation behind the firewall. Only tunnel mode is required between the remote host and the firewall.As in case 1, one or two SAs may be used between the remote host and the local host.

Key management define as managing cryptographic keys within a cryptosystem. It can manage with generating, exchanging, saving, using and replacing keys as required at the user level.

A key management system will also contains key servers, user process and protocols, including cryptographic protocol design. The security of the cryptosystem is based upon successful key management.

Cryptographic keys play an essential role in protecting sensitive data, avoiding data breaches, and understanding with regulations. Unfortunately, a lost or stolen key can lead to costly losses of systems and information, which is each security-aware company should provide strong key management protocols.

Encryption key management is a group of practices and rules that provide the secured use of cryptographic keys. Proper management provides a key stays secure throughout its lifecycle, from generation and use to saving and deletion.

A cryptographic key is a document that include a string of letters and numbers that can encrypt and decrypt information when processed by a crypto algorithm. The main objective of key management is to maintain these files away from unauthorized users and systems.

Key Management is the procedure of putting specific standards in place to provide the security of cryptographic keys in an organization. Key Management manage with the generation, exchange, storage, deletion, and updating of keys. They also manage with the members access of the keys.

Key management forms the basis of all information security. Data is encrypted and decrypted through the use of encryption keys, which define the loss or compromise of any encryption key would invalidate the information security measures establish into place. Keys also provide the secure transmission of information across an Internet connection.

With authentication methods, such as code signing, attackers can pretend to be a trusted service such as Microsoft, while providing victim’s computers malware, if they steal a poorly secured key.

Keys support compliance with specific standards and regulations to provide companies are using best practices when securing cryptographic keys and well protected keys are only applicable by users who require them.

Key management servers (KMS) are used to administer the complete lifecycle of cryptographic keys and secure them from loss or misuse. KMS solutions, and other key management technology, directly control the generation, management, storage, archival, and removal of encryption keys.

Moreover, it can completely protect their loss or misuse, companies should limit access to these keys, either by defining physical access or ruling user access by generating clear and defined roles.

The proper management of cryptographic keys is important to the efficient use of cryptography for security. Keys are similar to the combination of a safe. If a safe combination is called an adversary, the strongest safe supports no security against penetration. Likewise, poor key management can simply compromise strong algorithms.