Security Architecture for the Internet Protocol
obsoleted by
- rfc-2401 — Security Architecture for the Internet Protocol
Extracted elements (30)
Key management data is intentionally carried by an upper-layer protocol (UDP, TCP) rather than within the IP layer, providing clear separation of mechanism and allowing new key management methods to be substituted without modifying AH or ESP implementations.
Standard default algorithms (keyed MD5 for AH, DES-CBC for ESP) are specified to ensure interoperability in the global Internet; these defaults match those used in SNMPv2 security to achieve consistency across protocols.
The Authentication Header deliberately omits confidentiality so that implementations will be widely available even in locations where export, import, or use of encryption is regulated.
The key management protocol is coupled to AH and ESP only via the Security Parameters Index (SPI), allowing AH and ESP to be defined without specifying key management and enabling multiple key management systems — including manual configuration — to be used interchangeably.
The SPI is receiver-oriented (the destination system selects the SPI value for unicast) to prevent conflicts between manually configured and automatically configured Security Associations.
User-oriented keying is preferred over host-oriented keying on multi-user hosts because host-oriented keying allows a malicious user to obtain the shared key via chosen-plaintext attack and then read or forge other users' traffic.
When multiple senders share a single Security Association with a multicast group and symmetric algorithms are used, the receiver can only authenticate that a packet came from one of the group members, not which specific sender originated it.
All explicit IP sensitivity labels MUST be authenticated using either ESP, AH, or both, to ensure end-to-end label integrity in multi-level secure environments.
All implementations MUST permit the configuration of host-oriented keying. Implementations on multi-user hosts SHOULD support user-granularity (user-oriented) Security Associations.
All implementations of AH or ESP MUST support manual configuration of Security Associations.
All IPv6-capable hosts MUST implement the IP Authentication Header with at least the MD5 algorithm using a 128-bit key. IPv4 systems claiming to implement AH MUST also implement AH with at least the MD5 algorithm using a 128-bit key.
All such implementations SHOULD support an Internet standard Security Association establishment protocol (e.g., IKMP, Photuris) once such a protocol is published as an Internet standards-track RFC.
An implementation of the Authentication Header or the Encapsulating Security Payload MUST support the concept of a Security Association identified by the SPI and Destination Address.
An IP system MUST take reasonable steps to protect the keys and other security association information from unauthorized examination or modification, because all of the security lies in the keys.
For interoperability throughout the worldwide Internet, all conforming implementations of the IP Encapsulating Security Payload MUST support DES in Cipher-Block Chaining (CBC) Mode as detailed in the ESP specification.
Given two endpoints, it MUST be possible to have more than one concurrent Security Association for communications between them.
In MLS environments, the sensitivity level of protected traffic MUST NOT dominate the sensitivity level of the Security Association used, and the sensitivity level of the SA MUST NOT dominate the sensitivity level of the key.
Routing headers for which integrity has not been cryptographically protected SHOULD be ignored by the receiver, to avoid source routing and related attacks.
Security gateways MUST perform address-based IP packet filtering on unauthenticated packets purporting to be from a system known to be using IP security.
Support for user-oriented keying SHOULD be present in all IP implementations, as described in the IP Key Management Requirements section.
When a formerly valid Security Association becomes invalid, the destination system SHOULD NOT immediately reuse that SPI value and instead SHOULD let that SPI value become stale before reusing it for another Security Association.
A Security Association normally includes: authentication algorithm and keys (REQUIRED for AH), encryption algorithm and keys (REQUIRED for ESP), IV/sync field presence and size (REQUIRED for ESP), key and SA lifetimes (RECOMMENDED), source address(es) (RECOMMENDED), and sensitivity level (REQUIRED for MLS systems).
A Security Association (SA) is the set of security information relating to a given network connection or set of connections. It is uniquely identified by the combination of a Security Parameters Index (SPI) and a Destination Address, and is normally one-way.
ESP Tunnel mode encapsulates an entire IP datagram within the ESP header, while Transport mode encapsulates only the upper-layer protocol (e.g., TCP or UDP). Transport mode reduces bandwidth overhead and processing cost when full IP header confidentiality is not required.
The IP Authentication Header (AH) provides integrity and authentication without confidentiality to IP datagrams. It computes a cryptographic function over the IP datagram using a secret key; mutable fields like TTL/Hop Limit are excluded from the computation. The default algorithm is keyed MD5.
The IP Encapsulating Security Payload (ESP) provides integrity, authentication, and confidentiality to IP datagrams by encapsulating either an entire IP datagram (tunnel mode) or only upper-layer protocol data (transport mode), encrypting most of the ESP contents, and prepending a new cleartext IP header.
Cryptographic transforms for ESP that use a block-chaining algorithm and lack a strong integrity mechanism are vulnerable to a cut-and-paste attack (Bellovin) and SHOULD NOT be used unless AH is always present with packets using that ESP transform.
If a receiving system does not verify that the Security Association used for a packet is valid for the claimed source address, an attacker sharing a different SA with the destination can forge the source address of another sender, causing the receiver to misattribute the packet's origin.
The quality of security provided depends entirely on the strength of the cryptographic algorithms, key strength, correct implementation of those algorithms, security of the key management protocol, and security of the underlying operating system (e.g., OS must keep private keys confidential).
These IP security mechanisms do not provide protection against traffic analysis. Bulk link encryption is identified as one traditional countermeasure; users must independently ensure their traffic analysis protection needs are met.