IPSEC Primer

Let's start with some vocabulary ... (RFC 4301 - Security Architecture for the Internet Protocol)


Authentication - Used informally to refer to the combination of two nominally distinct security services, data origin authentication and connectionless integrity.


Confidentiality - The security service that protects data from unauthorized disclosure. In the IPsec context, using ESP in tunnel mode, especially at a security gateway, can provide some level of traffic flow confidentiality.


Data Origin Authentication - A security service that verifies the identity of the claimed source of data. This service is usually bundled with connectionless integrity service.


Encryption - A security mechanism used to transform data from an intelligible form (plaintext) into an unintelligible form (ciphertext), to provide confidentiality.


Integrity - A security service that ensures that modifications to data are detectable. IPsec supports two forms of integrity:
      
	o Connectionless integrity is a service that detects modification of an individual IP datagram, without regard to the ordering of the datagram in a stream of traffic.  

	o The form of partial sequence integrity offered in IPsec is referred to as anti-replay integrity, and it detects arrival of duplicate IP datagrams (within a constrained window).  




What does IPsec do?

IPsec creates a boundary between unprotected and protected interfaces, for a host or a network. Traffic traversing the boundary is subject to the access controls specified by the user or administrator responsible for the IPsec configuration.


How does IPsec work?

IPsec uses two protocols to provide traffic security services -- Authentication Header (AH) and Encapsulating Security Payload (ESP).

IPsec implementations MUST support ESP and MAY support AH. (there are very few contexts in which ESP cannot provide the requisite security services. ESP can be used to provide only integrity, without confidentiality, making it comparable to AH in most contexts.)


	o The IP Authentication Header (AH) offers integrity and data origin authentication, with optional (at the discretion of the receiver) anti-replay features.

   	o The Encapsulating Security Payload (ESP) protocol offers the same set of services, and also offers confidentiality. Use of ESP to provide confidentiality without integrity is NOT RECOMMENDED.

   	o Both AH and ESP offer access control, enforced through the distribution of cryptographic keys and the management of traffic flows as dictated by the Security Policy Database.



What are the components that I need to know about?


Security Association (SA) - (KNOW ME !!)

An SA is a simplex "connection" that affords security services to the traffic carried by it.  
Security services are afforded to an SA by the use of AH, or ESP, but not both. If both AH and ESP protection are applied to a traffic stream, then two SAs must be created and coordinated to effect protection of the security protocols. 

To secure typical, bi-directional communication between two IPsec-enabled systems, a pair of SAs (one in each direction) is required. IKE(v2) explicitly creates these SA pairs.


The set of security services offered by an SA depends on the security protocol selected, the SA mode, the endpoints of the SA, and the election of optional services within the protocol.




What about Databases? (DO NOT KNOW ME !!)


There are three nominal databases: the Security Policy Database (SPD), the Security Association Database (SAD), and the Peer Authorization Database (PAD). 


The Security Policy Database (SPD) specifies the policies that determine the disposition of all IP traffic inbound or outbound from a host or security gateway. (what services are to be offered to IP datagrams and in what fashion)

	An SPD is logically divided into three pieces:

		SPD-S (secure traffic) contains entries for all traffic subject to IPsec
      protection.  

		SPD-O (outbound) contains entries for all outbound traffic that is to be bypassed or discarded.

		SPD-I (inbound) is applied to inbound traffic that will be bypassed or discarded.




The Security Association Database (SAD) contains parameters that are associated with each established (keyed) SA.



The Peer Authorization Database (PAD) provides the link between the SPD and a security association management protocol such as IKE. It embodies several critical functions:

        o identifies the peers or groups of peers that are authorized to communicate with this IPsec entity
        o specifies the protocol and method used to authenticate each peer
        o provides the authentication data for each peer
        o constrains the types and values of IDs that can be asserted by a peer with regard to child SA creation, to ensure that the peer does not assert identities for lookup in the SPD that it is not authorized to represent, when child SAs are created
        o peer gateway location info, e.g., IP address(es) or DNS names, MAY be included for peers that are known to be "behind" a security gateway



What about the Authentication Header (AH)? (KNOW ME !!!)


The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams and to provide protection against replays.


AH provides authentication for as much of the IP header as possible, as well as for next level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the sender. The values of such fields cannot be protected by AH. Thus, the protection provided to the IP header by AH is piecemeal.


AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP), or in a nested fashion. ESP may be used to provide the same anti-replay and similar integrity services, and it also provides a confidentiality (encryption) service.


NOTE: The primary difference between the integrity provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (e.g., via use of tunnel mode).


The integrity algorithm employed for the Inetgrity Check Value (ICV) computation is specified by the SA. For point-to-point communication, suitable integrity algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., AES [AES]) or on one-way hash functions (e.g., MD5, SHA-1, SHA-256, etc.).



What about Encapsulating Security Payload (ESP)? (KNOW ME !!!)


The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. ESP may be applied alone, in combination with AH, or in a nested
fashion.


ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality. 

The set of services provided depends on options selected at the time of Security Association (SA) establishment and on the location of the implementation in a network topology.

Using encryption-only for confidentiality is allowed by ESP. However, it should be noted that in general, this will provide defense only against passive attackers. Using encryption without a strong integrity mechanism on top of it (either in ESP or separately via AH) may render the confidentiality service insecure against some forms of active attacks.

Moreover, an underlying integrity service, such as AH, applied before encryption does not
necessarily protect the encryption-only confidentiality against active attackers.


NOTE: Data origin authentication and connectionless integrity are joint services, referred to jointly as "integrity". On a per-packet basis, the computation being performed provides connectionless integrity directly; data origin authentication is provided indirectly as a result of binding the key used to verify the integrity to the identity of the IPsec peer. Typically, this binding is effected through the use of a shared, symmetric key.




What else is there? (KNOW ME !!!)


Internet Security Association and Key Management Protocol (ISAKMP) - provides a framework for authentication and key exchange, with actual authenticated keying material provided either by manual configuration with pre-shared keys, Internet Key Exchange (IKE and IKEv2), Kerberized Internet Negotiation of Keys (KINK), or IPSECKEY DNS records.


Transport mode - only the payload of the IP packet is usually encrypted or authenticated. The routing is intact, since the IP header is neither modified nor encrypted; however, when the authentication header is used, the IP addresses cannot be modified by network address translation, as this always invalidates the hash value. The transport and application layers are always secured by a hash, so they cannot be modified in any way, for example by translating the port numbers.

NOTE: A means to encapsulate IPsec messages for NAT traversal has been defined by RFC documents describing the NAT-T mechanism.


Tunnel mode - the entire IP packet is encrypted and authenticated. It is then encapsulated into a new IP packet with a new IP header. Tunnel mode is used to create virtual private networks for network-to-network communications (e.g. between routers to link sites), host-to-network communications (e.g. remote user access) and host-to-host communications (e.g. private chat).  Tunnel mode supports NAT traversal.



Cryptographic algorithms defined for use with IPsec include:

	o HMAC-SHA1/SHA2 for integrity protection and authenticity
	o TripleDES-CBC for confidentiality
	o AES-CBC for confidentiality
	o AES-GCM providing confidentiality and authentication together
	o ChaCha20 (TLS) + Poly1305 providing confidentiality and authentication together


Key exchange algorithms:

	o Diffie-Hellman (RFC 3526)
	o Elliptic-Curve Diffie Hellman (ECDH) (RFC 4753)


Authentication algorithms:

	o RSA
	o Elliptic-Curve Digital Signature Algorithm (ECDSA) (RFC 4754)
	o Pre-Shared Key (PSK) (RFC 6617)




Let's bring it all together now !!!



The IPSec components work in this fashion:

1. Local or group policy is applied to a computer during startup and periodically while the computer is on. This is not IPSec-specific, but rather the normal operation of Group Policy.

2. Any IPSec policies are retrieved by the IPSec Policy Agent.

3. When one or more IPSec policies exist, the IPSec Policy Agent monitors communication to the TCP/IP protocol from all applications. It's watching for traffic that matches the policy it is configured with, that is, network traffic that it must protect.

4. When network traffic that needs protection is identified, the IPSec Policy Agent communicates with the IPSec driver. It informs the IPSec driver of the type of protection required.

5. The IPSec driver then determines whether a Security Association (SA) exists that can be used to protect the traffic. (For the purposes of this discussion, an SA is a set of IPSec settings and key material that is shared between this computer and the destination computer.)

6. If no SA exists, the IPSec driver contacts the IKE service. IKE is responsible for negotiating settings between the computers, performing mutual authentication, and establishing shared secret keys that conform to the security policy. IKE uses ISAKMP for this task.

7. IKE provides the SA to the IPSec driver, which then protects the network traffic.

8. The driver returns the protected traffic to the TCP/IP protocol for continued processing.