6.5.1.3 The IP Security Architecture (IPSec)
(source : http://www.redbooks.ibm.com/redbooks/pdfs/sg242580.pdf)
The IP Security Architecture (IPSec) provides a framework for security at the IP
layer for both IPv4 and IPv6. By providing security at this layer, higher layer
transport protocols and applications can use IPSec protection without the need of
being changed. This has turned out to be a major advantage in designing modern
networks and has made IPSec one of the most, if not the most attractive
technologies to provide IP network security.
IPSec is an open, standards-based security architecture (RFC 2401-2412, 2451)
that offers the following features:
• Provides authentication, encryption, data integrity and replay protection
• Provides secure creation and automatic refresh of cryptographic keys
• Uses strong cryptographic algorithms to provide security
• Provides certificate-based authentication
• Accommodation of future cryptographic algorithms and key exchange
protocols
• Provides security for L2TP and PPTP remote access tunneling protocols
IPSec was designed for interoperability. When correctly implemented, it does not
affect networks and hosts that do not support it. IPSec uses state-of-the-art
cryptographic algorithms. The specific implementation of an algorithm for use by
an IPSec protocol is often called a transform. For example, the DES algorithm
used in ESP is called the ESP DES-CBC transform. The transforms, as the
protocols, are published in RFCs and in Internet drafts.
Authentication Header (AH)
AH provides origin authentication for a whole IP datagram and is an effective
measure against IP spoofing and session hijacking attacks. AH provides the
following features:
• Provides data integrity and replay protection
• Uses hashed message authentication codes (HMAC), based on shared
secrets
• Cryptographically strong but economical on CPU load
• Datagram content is not encrypted
• Does not use changeable IP header fields to compute integrity check value
(ICV), which are:
• TOS, Flags, Fragment Offset, TTL, Checksum
AH adds approximately 24 bytes per packet that can be a consideration for
throughput calculation, fragmentation, and path MTU discovery. AH is illustrated
in Figure 94 on page 202.
IPSec was designed for interoperability. When correctly implemented, it does not
affect networks and hosts that do not support it. IPSec uses state-of-the-art
cryptographic algorithms. The specific implementation of an algorithm for use by
an IPSec protocol is often called a transform. For example, the DES algorithm
used in ESP is called the ESP DES-CBC transform. The transforms, as the
protocols, are published in RFCs and in Internet drafts.
Authentication Header (AH)
AH provides origin authentication for a whole IP datagram and is an effective
measure against IP spoofing and session hijacking attacks. AH provides the
following features:
• Provides data integrity and replay protection
• Uses hashed message authentication codes (HMAC), based on shared
secrets
• Cryptographically strong but economical on CPU load
• Datagram content is not encrypted
• Does not use changeable IP header fields to compute integrity check value
(ICV), which are:
• TOS, Flags, Fragment Offset, TTL, Checksum
AH adds approximately 24 bytes per packet that can be a consideration for
throughput calculation, fragmentation, and path MTU discovery. AH is illustrated
in Figure 94 on page 202.
The following transforms are supported with AH:
• Mandatory authentication transforms
• HMAC-MD5-96 (RFC 2403)
• HMAC-SHA-1-96 (RFC 2404)
• Optional authentication transforms
• DES-MAC
• Obsolete authentication transforms
• Keyed-MD5 (RFC 1828)
Encapsulating Security Payload (ESP)
ESP encrypts the payload of IP packet using shared secrets. The Next Header
field actually identifies the protocol carried in the payload. ESP also optionally
provides data origin authentication, data integrity, and replay protection in a
similar way as AH. However, the protection of ESP does not extend over the
whole IP datagram as opposed to AH.
ESP adds approximately 24 bytes per packet that can be a consideration for
throughput calculation, fragmentation, and path MTU discovery. ESP is illustrated
in Figure 95 on page 203.
The following transforms are supported with ESP:
• Mandatory encryption transforms
• DES_CBC (RFC 2405)
• NULL (RFC 2410)
• Optional encryption transforms
• CAST-128 (RFC 2451)
• RC5 (RFC 2451)
• IDEA (RFC 2451)
• Blowfish (RFC 2451)
• 3DES (RFC 2451)
• Mandatory authentication transforms
• HMAC-MD5-96 (RFC 2403)
• HMAC-SHA-1-96 (RFC 2404)
• NULL (RFC 2410)
• Optional authentication transforms
• DES-MAC
Note: The NULL transform cannot be used for both encryption and authentication
at the same time.
Internet Key Exchange Protocol (IKE)
The IPSec protocols AH and ESP require that shared secrets are known to all
participating parties that require either manual key entry or out-of-band key
distribution. The problem is that keys can become lost, compromised or simply
expire. Moreover, manual techniques do not scale when there are many Security
Associations to manage (for example for an Extranet VPN). A robust key
exchange mechanism for IPSec must therefore meet the following requirements:
• Independent of specific cryptographic algorithms
• Independent of a specific key exchange protocol
• Authentication of key management entities
• Establish SA over "unsecured" transport
• Efficient use of resources
• Accommodate on-demand creation of host and session-based SAs
The Internet Key Exchange Protocol (IKE) has been designed to meet those
requirements. It is based on the Internet Security Associations and Key
Management Protocol (ISAKMP) framework and the Oakley key distribution
protocol. IKE offers the following features:
• Key generation and identity authentication procedures
• Automatic key refresh
• Solves the "first key" problem
• Each security protocol (that is, AH, ESP) has its own Security Parameter Index
(SPI) space
• Built-in protection
• Against resource-clogging (denial-of-service) attacks
• Against connection/session hijacking
• Perfect forward secrecy (PFS)
• Two-phased approach
• Phase 1 - Establish keys and SA for key exchanges
• Phase 2 - Establish SAs for data transfer
• Implemented as application over UDP, port 500
• Supports host-oriented (IP address) and user-oriented (long-term identity)
certificates
• Uses strong authentication for ISAKMP exchanges
• Pre-shared keys
• No actual keys are shared, only a token used to create keying material
• Digital signatures (using either DSS or RSA methods)
• Public key encryption (RSA and revised RSA)
• For performance reasons revised RSA uses a generated secret key
instead of a public/private key during the second Phase 1 exchange.
The differences between those authentication methods is illustrated in Figure
96 on page 205.
As mentioned before, IKE requires two phases be completed before traffic can be
protected with AH and/or ESP.
IKE Phase 1
During phase 1, the partners exchange proposals for the ISAKMP SA and agree
on one. This contains specifications of authentication methods, hash functions
and encryption algorithms to be used to protect the key exchanges. The partners
then exchange information for generating a shared master secret:
• "Cookies" that also serve as SPIs for the ISAKMP SA
• Diffie-Hellman values
• Nonces (random numbers)
• Optionally exchange IDs when public key authentication is used
Both parties then generate keying material and shared secrets before exchanging
additional authentication information.
Note: When all goes well, both parties derive the same keying material and
actual encryption and authentication keys without ever sending any keys over the
network.
IKE Phase 2
During phase 2, the partners exchange proposals for Protocol SAs and agree on
one. This contains specifications of authentication methods, hash functions and encryption algorithms to be used to protect packets using AH and/or ESP. To generate keys, both parties use the keying material from a previous phase 1 exchange and they can optionally perform an additional Diffie-Hellman exchange for PFS.
The phase 2 exchange is protected by the keys that have been generated during
phase 1, which effectively ties a phase 2 to a particular phase 1. However, you
can have multiple phase 2 exchanges under the same phase 1 protection to
provide granular protection for different applications between the same two systems. For instance, you may want to encrypt FTP traffic with a stronger algorithm than TELNET, but you want to refresh the keys for TELNET more often
than those for FTP.
Systems can also negotiate protocol SAs for third-parties (proxy negotiation) which is used to automatically create tunnel filter rules in security gateways.
