Security Associations
The Security Associations, or SAs as they are normally referred to in IPSec terminology, form the basis for IPSec. The SAs are the contract between two communicating entities. They determine the IPSec protocols used for securing the packets, the transforms, the keys, and the duration for which the keys are valid to name a few. Any IPSec implementation always builds an SA database (SADB) that maintains the SAs that the IPSec protocols use to secure packets.
The SAs are one way, i.e., simplex. If two hosts, A and B, are communicating securely using ESP, then the host A will have an SA, SAout, for processing outbound packets and will have a different SA, SAin, for processing the inbound packets. The host B will also create two SAs for processing its packets. The SAout of the host A and the SAin of the host B will share the same cryptographic parameters such as keys. Similarly, SAin of the host A and the SAout of the host B will share the same cryptographic parameters. As SAs are unidirectional, a separate table is maintained for SAs used for outbound and inbound processing.
The SAs are also protocol specific. There is an SA for each protocol. If two hosts A and B are communicating securely using both AH and ESP, then each host builds a separate SA for each protocol.
There is another component in the IPSec architecture called the security policy database (SPD). The SPD works in conjunction with the SADB in processing packets. The policy is an extremely important component of IPSEC architecture. The policy defines the security communications characteristics between two entities. It defines what protocols to use in what modes and the transforms to use. It also defines how the IP packets are treated. This is discussed in detail in later sections.
Security Parameter Index (SPI)
The SPI is a very important element in the SA. An SPI is a 32-bit entity that is used to uniquely identify an SA at the receiver. It was mentioned before that the security context or SA is a contract between two hosts communicating securely and indicates the parameters, such as keys and algorithms. However, there has to be some mechanism for the source to identify which SA to use to secure the packet and for the destination to identify which SA to use to check the security of the received packet. The source identifies the SA by using the selectors. However, the destination does not have access to all the fields in the selectors as some of the fields in the selectors belong to the transport layer.
To solve the problem of identifying the SA on the destination, the SPI that uniquely identifies the SA on the destination is sent with every packet. The destination uses this value to index into the receiving SADB and fetch the SA. The obvious questions are who guarantees the uniqueness of the mapping between the SPI and SA and what is the domain of uniqueness on the destination for each protocol global, per source, or per address on the host. It is up to receiver/destination to guarantee this uniqueness. It is a requirement to maintain a separate SPI domain for each protocol. The destination can use any consistent mechanism to guarantee uniqueness inside each domain. The IPSec architecture specifies that the <spi, destination address> in the packet should uniquely identify an SA.
The receiver allocates the SPI that is stored as part of the SA on the sender. The sender includes this in every packet under the assumption that the receiver can use this to uniquely identify the SA. If the receiver does not guarantee uniqueness, packets will fail security checks as invalid keys and transforms may be used.
The sending host uses the selectors to uniquely index into the sending SADB. The output of this lookup is an SA that has all the negotiated security parameters, including the SPI. The host that allocates the SPI guarantees uniqueness. The SPI is reused once the SA expires but it is guaranteed that at any point the mapping between <spi, dst>, and SA is one to one. The src address is used in cases where the host is multihomed, that is, a host with more than one IP interface. This can be because there is more than one network card on the host or because of the fact that multiple IP interfaces are configured on the same network card (the host has multiple IP addresses). In this case, it is possible that the index <spi, dst> is not unique and src is used to resolve the ambiguity.
The SPI is transmitted as part of AH and ESP headers. The receiving host uses the tuple <spi, dst, protocol> (where dst is the destination address in the IP header) to uniquely identify the SA. It is possible to use the source address in addition to <spi, dst, protocol> to uniquely identify an SA to conserve the SPI space. However, this is not part of the standards and is something specific to an implementation.
SA Management
The two most important tasks of the SA management are creation and deletion. The management of SAs can be either manual or through an Internet standard key management protocol such as IKE. The SA management requires an interface for the user applications (which includes IKE) to communicate with kernel to manage the SADB. The management aspect is discussed in greater detail in the chapter on policy.
Creation
The SA creation is a two-step processãnegotiating the parameters of the SA and updating the SADB with the SA.
Manual keying is mandatory to support and it was used extensively during the initial development and testing of IPSec. In manual keying, two sides agree on the parameters of the SA offline, either by phone or over e-mail (although unsecured e-mail is dangerous!). The process of allocating the SPI, negotiation of parameters is all manual. Needless to say, this process is error prone, cumbersome, and insecure. The other limiting factor is that these SAs never expire. Once they are created they stay good until they are deleted. Manual keying is a useful feature for debugging the base IPSec protocols when the key management protocols are failing. However, with a stable key management protocol, the use of manual keying is questionable.
In an environment where IPSec is deployed, the SAs are created through an Internet standard key management protocol such as IKE. IKE is invoked by the IPSec kernel when the policy mandates that the connection should be secure but the SA's are not yet established. IKE negotiates the SA with the destination or intermediate host/router, depending on the policy, and creates the SA. Once the SA is created and added to the SADB, secure packets start flowing between the two hosts.
In the previous sections, we discussed nested or chained implementations of IPSec. For example, a host creates a transport AH to end to end, but also creates a tunneled ESP to the gateway/firewall. In this case, for the packet to be processed properly, the source has to create two SAs, one for the gateway and another for the end host. When the policy requires establishment of multiple SAs for two hosts to communicate securely, the collection of SAs is called SA bundle.
Deletion
The SA is deleted for various reasons:
The lifetime has expired.
The keys are compromised.
The number of bytes encrypted/decrypted or authenticated using this SA has exceeded a certain threshold set by the policy.
The other end requests that the SA be deleted.
The SAs can be deleted manually or through the IKE. It is important to renew or refresh keys in security to reduce the chance of someone breaking the system. IPSec does not provide the ability to refresh keys. Instead, we have to delete existing SA and negotiate/create a new SA. Once the SA is deleted, the SPI it was using can be reused.
To avoid the problem of stalling the communication, a new SA is negotiated before the existing SA expires. For a small duration of time, until the soon-to-expire SA is deleted, the two entities have multiple SAs that can be used for secure communication. However, it is always desirable to use the newly established SA instead of the older SA.
Parameters
The SA maintains the context of a secure communication between two entities. The SA stores both protocol-specific and generic fields. This section discusses the fields that are used by both AH and ESP. The protocol-specific fields are discussed in AH and ESP chapters. These fields are used in processing each IP packet. Some of the fields are used for outbound processing, some for inbound processing, and some for both, depending on the usage of the field. Certain fields are updated when the SA is used to process a packet. Semantics associated with the parameters in an SA are discussed below.
Sequence Number
The sequence number is a 32-bit field and is used in outbound processing. The sequence number is part of both AH and ESP header. The sequence number is incremented by 1 every time the SA is used to secure a packet. This field is used to detect replay attacks by the destination. When the SA is established this field is set to 0. Normally, SAs are renegotiated before this field overflows as it is unsafe to send more than 4 Giga (4,000,000,000) packets using the same keys.
Sequence Number Overflow
This field is used in outbound processing and is set when the sequence number overflows. The policy determines if the SA can still be used to process additional packets.
Antireplay Window
This field is used in inbound processing. One of the concerns in networks today is replay attack. In replay attacks, applications get bombarded with the same packets. IPSec overcomes this by detecting packets replayed by rogue hosts. This is discussed in greater detail where the inbound processing of packets is described in the implementation chapter.
Lifetime
There is a lifetime associated with each SA beyond which the SA cannot be used. The lifetime is specified either in terms of number of bytes that has been secured using this SA or the duration for which the SA has been used or both. When the lifetime of the SA expires, it cannot be used anymore. In order to avoid the problem of breaking the communication when the SA expires, there are two kinds of lifetimesãsoft and hard. The soft lifetime is used to warn the kernel that the SA is about to expire. This allows the kernel to negotiate a new SA before the hard lifetime expires.
Mode
IPSec protocols can be used either in tunnel or transport mode. The payload is processed differently depending on the value of this field. This field is set to tunnel mode, transport mode, or a wild card. In the cases where this field is set to wild card, the information as to whether it is IPSec in tunnel or transport mode is gleaned from someplace else, that is, sockets. When this field is set to a wild card, it implies that the SA can be used either for tunnel or transport mode.
Tunnel Destination
For IPSec in tunnel mode, this indicates the tunnel destinationãthe destination IP address of the outer header.
PMTU parameters
When IPSec is used in tunnel mode, it has to maintain the PMTU information so that it can fragment the packets accordingly. As a part of PMTU field, the SA maintains two valuesãthe PMTU and the aging field. This is discussed in greater detail in the implementation chapter.
Security Policy
The security policy determines the security services afforded to a packet. As mentioned earlier, all IPSec implementations store the policy in a database called the SPD. The database is indexed by selectors and contains the information on the security services offered to an IP packet.
The security policy is consulted for both inbound and outbound processing of the IP packets. On inbound or outbound packet processing, the SPD is consulted to determine the services afforded to the packet. A separate SPD can be maintained for the inbound and the outbound packets to support asymmetric policy, that is, providing different security services for inbound and outbound packets between two hosts. However, the key management protocol always negotiates bidirectional SAs. In practice, the tunneling and nesting will be mostly symmetric.
For the outbound traffic, the output of the SA lookup in the SADB is a pointer to the SA or SA bundle, provided the SAs are already established. The SA or SA bundle will be ordered to process the outbound packet as specified in the policy. If the SAs are not established, the key management protocol is invoked to establish the packet. For the inbound traffic, the packet is first afforded security processing. The SPD is then indexed by the selector to validate the policy on the packet. We will discuss this in greater detail when we talk about IPSec in action.
The security policy requires policy management to add, delete, and modify policy. The SPD is stored in the kernel and IPSec implementations should provide an interface to manipulate the SPD. This management of SPD is implementation specific and there is no standard defined. However, the management application should provide the ability to handle all the fields defined in the selectors that are discussed below.
Selectors
This section defines the various selectors used to determine the security services afforded to a packet. The selectors are extracted from the network and transport layer headers.
Source Address
The source address can be a wild card, an address range, a network prefix, or a specific host. Wild card is particularly useful when the policy is the same for all the packets originating from a host. The network prefix and address range is used for security gateways providing security to hosts behind it and to build VPNs. A specific host is used either on a multihomed host or in the gateways when a host
s security requirements are specific.
Destination Address
The destination address can be a wild card, an address range, a network prefix, or a specific host. The first three are used for hosts behind secure gateways. The destination address field used as a selector is different from the destination address used to look up SAs in the case of tunneled IP packets. In the case of tunneled IP packets, the destination IP address of the outer header can be different from that of the inner header when the packets are tunneled. However, the policy in the destination gateway is set based on the actual destination and this address is used to index into the SPD.
Name
The name field is used to identify a policy tied to a valid user or system name. These include a DNS name, X.500 Distinguished Name, or other name types defined in the IPSec DOI. The name field is used as a selector only during the IKE negotiation, not during the packet processing. This field cannot be used as a selector during packet processing as there is no way to tie an IP address to a name currently.
Protocol
The protocol field specifies the transport protocol whenever the transport protocol is accessible. In many cases, when ESP is used, the transport protocol is not accessible. Under these circumstances, a wild card is used.
Upper Layer Ports
In cases where there is session-oriented keying, the upper layer ports represent the src and dst ports to which the policy is applicable. The wild card is used when the ports are inaccessible.
Top IPSec (2nd Edition) ISBN: 013046189X
EAN: 2147483647 Year: 2004
Pages: 76 Authors: Naganand Doraswamy, Dan Harkins
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |