7.5.2 Security Associations

  • Article

IPsec relies on the concept of a security association, which consists of a shared state, primarily cryptographic keys and parameters, maintained between two endpoints to secure traffic between them. Security associations are established between two hosts using either Internet Key Exchange (IKE) [RFC2409] [RFC4306] or Authenticated IP Protocol [MS-AIPS]. These protocols handle the negotiation of the shared state that makes up the security association, as well as authenticating the two hosts to each other. Once a security association is established, IPsec-encapsulated IP traffic can pass between the two endpoints.

After a security association is established, a host prepares to send an IPsec packet by marking the packet with a Security Parameter Index (SPI) ([RFC4303] section 2.1) from the security association shared state and performing the cryptographic and digital signing operations parameterized by the state in the security association ([RFC4301] section 5.1). The receiving host's IPsec layer uses the SPI and other packet information to find the security association's shared state values to check digital signatures and decrypt traffic as needed before passing the packet up to higher layer transports ([RFC4301] section 5.2).

Authentication between two IPsec hosts can be performed using three mechanisms:

  • Generic Security Services (GSS)-API-based authentication that can be performed by hosts that are Windows-domain-joined ([MS-AUTHSOD] section 2.1.2.1 and [MS-AUTHSOD] section 2.1.2.2). This form of authentication supports Kerberos, NTLM, or TLS authentications. IKE has been extended [MS-AIPS], to use GSS-API. This extension includes the ability to authenticate users and machines.

  • Certificate-based authentication (see [MS-CERSOD]).

  • Shared key, specified in [RFC2409] is a deprecated authentication method in Windows that is implemented in conformance with the IPsec RFCs. [RFC4109] updates [RFC2409].

On each host, the security association negotiation is controlled by a security policy database (SPD). The SPD specifies how an IPsec-supporting network stack will process packets, based on criteria such as their source, destination, and encapsulated protocol. The packet-processing requirements determine what cryptographic encapsulation will be used on data packets, and hence how a security association will be negotiated for it to support the required encapsulation. An abstract data model for the IPsec SPD structure is described in [RFC4301] section 4.4.1. When an outbound data packet is sent to IPsec, IPsec uses the packet information such as source, destination IP addresses, transport protocol (such as TCP), and transport source and destination ports to match the filters in the SPD to determine whether the packet requires additional IPsec processing such as encryption and/or digital signing.