Timo Aalto
Tik-110.551 Internetworking Seminar
Department
of Computer Science
Helsinki University of Technology
aalto@snakemail.hut.fi
1. Introduction
The authentication header (AH) and encapsulated
security payload (ESP) are the security mechanisms of the Internet protocol
security architecture. The IPSEC mechanisms AH and ESP provide authentication,
integrity and confidentiality security services. The AH and ESP are defined for
both IPv6 and IPv4. The implementation of the security mechanisms is mandatory
for IPv6 and optional for IPv4.
The IP security architecture is defined as an integral part of IPv6. Thus, every vendor, who claims to offer IPv6 compliant implementation, must support authentication header and encapsulated security payload. Support for the AH and ESP does not mean that these services must be used, but they must be available if needed [20]. "If a security is provided at the Internet level, it becomes a standard service that all applications can use." [4]. The application can request the operating system to set up a security association before starting a TCP connection or a UDP exchange.[4]
Although the use of authentication, integrity and encryption adds IP prosessing costs and increases communication latency, the availability of security services for end-use and infrastructure protection is worth the penalty. [20]
2. IP Security Architecture
The IP security architehture is defined
by the IETF in RFC 1825 [1],
RFC 1826 [2],
and RFC 1827 [3].
The IP security architecture can be described using the formal model presented
in [5].
Using the concepts of this model, the IP security architecture consists of
security variables, mechanisms, control, and management. The figure below
presents the conceptual model [5].
2.1 Security Associations
The use of the AH or ESP requires that
senders and receivers agree on a key, on an authentication or encryption
algorithm and on set of additional parameters needed in the use of algorithm.
"This set of agreements constitues a security association between senders and
receivers" [4].
From the implementation point of view, the security association contains all the
variables that are needed for the control and calculation of the AH and ESP.
The security association separates the key management and the security mechanisms from each other. The key management updates the variables in the security association and the mechanisms read and use those values. "The only coupling between the key management protocol and the security protocol is with the security parameter index (SPI)" [2, 3].
A security association is one-way; a communications session between two hosts will normally have two security associations in use, one for each direction. The sending host uses the sending userid and destination address to select appropriate security association (and SPI). "The receiving host uses the combination of SPI value and destination address to distinguish the correct association" [1]. The receiver-orientation of the security association implies that the receiver selects the SPI value. This prevents the conficts between manually configured and automatically configured security associations. [1]
A security association can be either host-oriented or user-oriented. A host-oriented security association supports the use of the same session key for all the users in the same host. If user-oriented security associations are supported, then all users will have separate session keys in use.
Security policy with the enforcement of such a policy controls the use of the IP layer security mechanisms. Host-oriented and user-oriented security associations are selected on the basis of the security policy. Security policy controls the choice of appropriate security association. From the implementation point of view, the security policy defines all the variables that are needed to enforce the security policy when selecting correct security association and SPI for the datagrams.
Using the concepts of security association and security policy, the security context can be defined to consist of the two security associations and security policy records associated with a given flow of IP packets [18]. A security context should be thought of as a management concept denoting the security variables and mutual trust shared by the communicating parties [5].
Examples for a security association and a security policy are given in tables 1 and 2.
| Security Parameter | Example value |
|---|---|
| SPI (Security Parameter Index) | 2916 |
| AH Algorithm | MD5 |
| AH Algorithm Mode | Keyed |
| AH Transform | RFC 1828 |
| AH Key(s) | a 128 bit MD5 key |
| AH Mode | Entire Datagram |
| ESP Algorithm | DES |
| ESP Algorithm Mode | CBC |
| ESP Transform | RFC 1829 |
| ESP Key(s) | a 56 bit DES key |
| ESP Mode | Transport |
| ESP Synch/Init Vector Size | 64 |
| Lifetime | an absolute time in Unix Time format |
| IPSO/CIPSO Sensitivity Label | Nuclear/Classified |
Table 1: An example of a security association
| Security Parameter | Example value |
|---|---|
| SPI (Security Parameter Index) | 2916 |
| IP Destination Address | 128 bit IPv6 address value |
| IP Source Address | 128 bit IPv6 address value |
| Protocol | TCP |
| TCP/UDP Destination Port | 23 |
| TCP/UDP Source Port | 1234 |
| Userid | Unix UID or other credentials |
Table 2: An example of a security policy record with user-oriented keying enforcement
2.2 Key and SA Management
Key and SA management are separated from
IP security mechanisms by the security association interface. The management and
the mechanisms are coupled only via SPI values.
Key management is responsible for establishing and updating the variables in the security associations.
RFC 1825 [1] defines the key management requirements for all IPv6 implementations.
In manual key management, the system's own keys, and also the keys of the communicating systems are configured manually to the system. This may work in a small and static environment, but does not scale. [1]
Widespread use of IP security will require an Internet standard scalable key management protocol [1]. A number of candidates of the key management protocols have been proposed: ISAKMP [22], SKIP [23, 24, 25, 26, 27], Oakley [28], Photuris [29, 30], and SKEME [31]; so far none of them has been adopted as a standard. A more descriptive information about IPv6 key management protocols can be found e.g. in [33].
Most of the key management protocols assume an authenticated public key of the other party to be available. Work is ongoing in the IETF to specify DNS security extensions [32], where the public keys of the IP hosts will be available. In addition to pure technical solutions an Internet-wide public-key infrastructure is required.
2.3 Authentication Header
The purpose of the authentication header
is to convey the authentication information in the IP datagram. The
authentication information is calculated using all the fields of the datagram
that do not change in transit [1,
2].
The authenication header is placed in IPv6 after the fragmentation and
end-to-end headers and before ESP and transport-layer headers [2].
Authentication header has the payload type 51 [21].
An example of an authenticated IPv6 header is presented below.
+------------+-------------------+------------+-------+---------------+ | IPv6 Header| Hop-by-Hop/Routing| Auth Header| Others| Upper Protocol| +------------+-------------------+------------+-------+---------------+
+---------------+---------------+---------------+---------------+
| Next Header | Length | RESERVED |
+---------------+---------------+---------------+---------------+
| Security Parameters Index |
+---------------+---------------+---------------+---------------+
| |
+ Authentication Data (variable number of 32-bit words) |
| |
+---------------+---------------+---------------+---------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
For outbound datagrams the calculation proceeds as follows:
+------------+-------------------+-------+---------------+ | IPv6 Header| Hop-by-Hop/Routing| Others| Upper Protocol| +------------+-------------------+-------+---------------+ AH calculation +------------+-------------------+------------+-------+---------------+ | IPv6 Header| Hop-by-Hop/Routing| Auth Header| Others| Upper Protocol| +------------+-------------------+------------+-------+---------------+For inbound datagrams the calculation proceeds as follows:
+------------+-------------------+------------+-------+---------------+ | IPv6 Header| Hop-by-Hop/Routing| Auth Header| Others| Upper Protocol| +------------+-------------------+------------+-------+---------------+ AH calculation +------------+-------------------+-------+---------------+ | IPv6 Header| Hop-by-Hop/Routing| Others| Upper Protocol| +------------+-------------------+-------+---------------+
In addition to the mandatory keyed MD5 transform alternative AH transforms can be supported. At the moment, keyed SHA transform [13] was been specified. Own AH transforms are also possible, if used among closed group of hosts supporting this specific transform.
2.4 Encapsulated Security Payload
The purpose of the encapsulated
security payload is to convey the encrypted data of the IP datagram. The
encrypted data is obtained by applying a specified encryption transform to the
data to be protected.
"ESP may appear anywhere after the IP header and before the final transport-layer protocol" [3]. The encapsulated security payload has the payload type 50 [21].
An IPv6 datagrams with ESP is presented below:
|<-- Unencrypted -->|<---- Encrypted ------>| +-------------+--------------------+------------+---------------------+ | IPv6 Header | Other IPv6 Headers | ESP Header | encrypted data | +-------------+--------------------+------------+---------------------+The ESP can be used in two modes. Tunnel mode ESP encapsulates an entire IP datagram inside ESP and adds a cleartext IPv6 header. Transport mode ESP encapsulates an upper layer protocol inside ESP.[1]
+-------------+--------------------+------------+---------------------+ | Security Association Identifier (SPI), 32 bits | +=============+====================+============+=====================+ | Opaque Transform Data, variable length | +-------------+--------------------+------------+---------------------+32-bit wide SPI identifies the security association for this datagram. The SPI field is the only unencrypted and transform-independent field in the ESP.
The contents of the Opaque Transform Data are specified in the transformation specifications.
|<-- Unencrypted ------>
+-------------+--------------------+----------------------------------+
| IPv6 Header | Other IPv6 Headers | Upper Protocol |
+-------------+--------------------+------------+---------------------+
ESP encryption transform (The whole IP datagram)
|<-- Unencrypted -->|<---- Encrypted ------>|
+-------------+--------------------+------------+---------------------+
| IPv6 Header | Other IPv6 Headers | ESP Header | encrypted data |
+-------------+--------------------+------------+---------------------+
Inbound datagrams:
|<-- Unencrypted -->|<---- Encrypted ------>|
+-------------+--------------------+------------+---------------------+
| IPv6 Header | Other IPv6 Headers | ESP Header | encrypted data |
+-------------+--------------------+------------+---------------------+
ESP decryption transform (ESP)
|<-- Unencrypted ------>
+-------------+--------------------+----------------------------------+
| IPv6 Header | Other IPv6 Headers | Upper Protocol |
+-------------+--------------------+------------+---------------------+
|<-- Unencrypted ------>
+-------------+--------------------+----------------------------------+
| IPv6 Header | Other IPv6 Headers | Upper Protocol |
+-------------+--------------------+------------+---------------------+
ESP encryption transform (Upper Protocol)
|<-- Unencrypted -->|<---- Encrypted ------>|
+-------------+--------------------+------------+---------------------+
| IPv6 Header | Other IPv6 Headers | ESP Header | encrypted data |
+-------------+--------------------+------------+---------------------+
Inbound datagrams:
|<-- Unencrypted -->|<---- Encrypted ------>|
+-------------+--------------------+------------+---------------------+
| IPv6 Header | Other IPv6 Headers | ESP Header | encrypted data |
+-------------+--------------------+------------+---------------------+
ESP decryption transform (ESP)
|<-- Unencrypted ------>
+-------------+--------------------+----------------------------------+
| IPv6 Header | Other IPv6 Headers | Upper Protocol |
+-------------+--------------------+------------+---------------------+
In addition to the mandatory DES CBC ESP transform [6] alternative ESP transforms can be supported. At the moment Triple DES transform [7], DES CBC plus MD5 transform [8], and Combined DES-CBC, MD5 and replay prevention security transform [9] have been specified. Own ESP transforms are also possible, if used among a closed group of hosts supporting this specific transform.
2.5 Control and Logic of the Mechanisms
The control of the AH and
ESP mechanisms for outgoing and incoming traffic is based on the security policy
and security associations. For outbound and inbound datagrams the security
policy determines the correct security association for the datagram. The
security association in turn determines which transforms are applied to the
datagrams and how they are applied.
Some ESP transformations [8, 9] provide authentication, integrity and confidentiality. If such transformations are not available, the IPSEC specifications allow the combined use of the AH and ESP security mechanisms. The AH should always be used, if the used ESP transformation and algorithm does not guarantee integrity for the encrypted messages. Authentication, integrity and confidentiality can be achieved by using both AH and ESP [3]. There are many possible ways to combine AH and ESP, depending on which data is to be authenticated. The following three cases visualize different possibilities.
Case 1: Transport mode ESP and AH authenticating the entire datagram
Outbound packet:
The ESP is first applied to the transport layer data and ESP is added to the datagram. Then the AH is calculated across the entire IP datagram. AH is placed before ESP.
|<-- Unencrypted ------>
+-------------+--------------------+-----------------+
| IPv6 Header | Other IPv6 Headers | Upper Protocol |
+-------------+--------------------+-----------------+
ESP encryption transform (Upper Protocol)
|<-- Unencrypted -->|<----- Encrypted ------>|
+-------------+--------------------+------------+----------------+
| IPv6 Header | Other IPv6 Headers | ESP Header | encrypted data |
+-------------+--------------------+------------+----------------+
AH calculation (The whole datagram)
|<-- Unencrypted -->|<----- Encrypted ------>|
+------------+-------------------+------------+------------+----------------+
| IPv6 Header| Hop-by-Hop/Routing| Auth Header| ESP Header | encrypted data |
+------------+-------------------+------------+------------+----------------+
Inbound packet:
The authentication and integrity with the AH are first checked for the whole datagram. Then the ESP transform decryption is applied to the ESP part.
|<-- Unencrypted -->|<----- Encrypted ------>| +------------+-------------------+------------+------------+----------------+ | IPv6 Header| Hop-by-Hop/Routing| Auth Header| ESP Header | encrypted data | +------------+-------------------+------------+------------+----------------+ AH calculation (The whole datagram) |<-- Unencrypted -->|<----- Encrypted ------>| +-------------+--------------------+------------+----------------+ | IPv6 Header | Other IPv6 Headers | ESP Header | encrypted data | +-------------+--------------------+------------+----------------+ ESP calculation (ESP) |<-- Unencrypted ------> +-------------+--------------------+-----------------+ | IPv6 Header | Other IPv6 Headers | Upper Protocol | +-------------+--------------------+-----------------+Case 2: Tunnel mode ESP and AH authenticating the entire datagram.
Outbound packet:
The ESP is applied to the entire original datagram. Then other plaintext IP headers are appended to the ESP header. Finally AH is calculated over the resulting datagram normally. [3]
|<-- Unencrypted ------>
+-------------+--------------------+-----------------+
| IPv6 Header | Other IPv6 Headers | Upper Protocol |
+-------------+--------------------+-----------------+
ESP encryption transform (The whole datagram)
|<-- Unencrypted -->|<----- Encrypted ------>|
+-------------+--------------------+------------+----------------+
| IPv6 Header | Other IPv6 Headers | ESP Header | encrypted data |
+-------------+--------------------+------------+----------------+
AH calculation (The whole datagram)
+------------+-------------------+------------+------------+----------------+
| IPv6 Header| Hop-by-Hop/Routing| Auth Header| ESP Header | encrypted data |
+------------+-------------------+------------+------------+----------------+
Inbound packet:
First the authenticity and integrity of the entire datagram is verified normally. Then the normal ESP transformation is applied.
+------------+-------------------+------------+------------+----------------+ | IPv6 Header| Hop-by-Hop/Routing| Auth Header| ESP Header | encrypted data | +------------+-------------------+------------+------------+----------------+ AH calculation (The whole datagram) |<-- Unencrypted -->|<----- Encrypted ------>| +-------------+--------------------+------------+----------------+ | IPv6 Header | Other IPv6 Headers | ESP Header | encrypted data | +-------------+--------------------+------------+----------------+ ESP calculation (ESP) |<-- Unencrypted ------> +-------------+--------------------+-----------------+ | IPv6 Header | Other IPv6 Headers | Upper Protocol | +-------------+--------------------+-----------------+Case 3: Tunnel mode ESP and AH authenticating only the ESP part of the datagram.
Outbound packet:
The authentication data is first calculated for the datagram to be encrypted later. AH is placed normally to the datagram. Then the ESP is applied to the entire IP datagram.
+------------+-------------------+---------------+ | IPv6 Header| Hop-by-Hop/Routing| Upper Protocol| +------------+-------------------+---------------+ AH calculation (The whole datagram) +------------+-------------------+------------+---------------+ | IPv6 Header| Hop-by-Hop/Routing| Auth Header| Upper Protocol| +------------+-------------------+------------+---------------+ ESP calculation (The whole datagram) |<-- Unencrypted -->|<----- Encrypted ------>| +-------------+-------------------+------------+----------------+ | IPv6 Header | Hop-by-Hop/Routing| ESP Header | encrypted data | +-------------+-------------------+------------+----------------+Inbound packet:
The ESP decryption transformation is applied to the ESP part. After the ESP is removed, the authentication and integrity are verified for the datagram without ESP.
|<-- Unencrypted -->|<----- Encrypted ------>| +-------------+-------------------+------------+----------------+ | IPv6 Header | Hop-by-Hop/Routing| ESP Header | encrypted data | +-------------+-------------------+------------+----------------+ ESP calculation (ESP) +------------+-------------------+------------+---------------+ | IPv6 Header| Hop-by-Hop/Routing| Auth Header| Upper Protocol| +------------+-------------------+------------+---------------+ AH calculation (The whole datagram) +------------+-------------------+---------------+ | IPv6 Header| Hop-by-Hop/Routing| Upper Protocol| +------------+-------------------+---------------+
There is also an Internet draft for the ICMP security failure messages [11]. This work is progress.
3. AH and ESP Use and Limitations
This chapter presents using
possibilities for the IPSEC mechanisms, discusses the cost of using
cryptographic algorithms, presents services that IPSEC does not provide and
presents attacks that are not in the scope of IPSEC protection.
3.1 Security Gateway Functionality
The AH and ESP support security
between two hosts, between host and security gateway and between two security
gateways.
"A security gateway is a system which acts as the communication
gateway between external untrusted systems and trusted hosts on their own
subnetwork" [1].
"A trusted subnetwork contains hosts and routers that trust each other not to
engage in active or passive attacks and trust that the underlying communication
channel isn't being attacked"[1].
The security gateway provides security services for the trusted hosts when they
communicate with the external untrusted systems.
When a security gateway provides services on behalf of hosts on a trusted subnet, the security gateway is responsible for establishing the security association on behalf of its trusted host and for providing security services between the security gateway and external system(s)[1].
3.2 Security Services for Upper Layers
Secure applications can
utilize the security services implemented at the IP layer. Secure applications
may request to send and receive authenticated, intact and encrypted IP
datagrams. The availability of these IP layer security services for the
application layer programs requires the presence of user-oriented keying in a
multi-user environment and security service support from the network programming
interfaces. The network programming interface support for security services
might be for example be new options to the sockets [4] or
security API [18].
3.3 Security Services for Routing Protocols
"Network integrity
cannot be maintained if routing protocols are not secured"[4].
Intruders may disrupt the communication or divert some connections by forging
routing updates. Routing protocols should be run on top of security associations
between the routers. [4].
Especially authentication and integrity of routing information is important to
the security of routing protocols, confidentiality is not always necessary.
"Using IP security is probably a good alternative to the definition of
protocol-specific authentication or encryption functions" [4].
3.4 Cost/Benefit Analysis of Using Cryptographic Algorithms
The use
of AH and ESP increases the IP protocol processing costs and communication
latency. In the case of AH, the increased latency is caused by the calculation
and comparison of the authentication data. In the case of ESP, the increased
latency is caused by the encryption and decryption of the ESP. [1,
2,
3]
"Public-key algorithms are slow. Symmetric algorithms are generally at least 1000 times faster than public-key algorithms" [15]. However public key algorithms with long key lengths provide in general better security than symmetric ones with short key lengths. Running cryptographic algorithms on hardware and parallerizing the computation of the cryptographic algorithms speeds up the computation. The use of cryptographic algorithms is a trade between benefits and costs, the stronger security is wanted, the bigger is the cost of computing cryptographic algorithm.
Below is a table comparing encryption speeds of some block ciphers on a 33 MHz 486SX: [15]
| Algorithm | Encryption Speed | Key length |
|---|---|---|
| DES | 35 KB/s | 56 bits |
| 3DES | 12 KB/s | 112 bits |
| IDEA | 70 KB/s | 128 bits |
Below is a table comparing encryption speeds of some hash functions on a 33 MHz 486SX. [15]
| Algorithm | Encryption Speed | Hash Lenght |
|---|---|---|
| MD5 | 174 MB/s | 128 bits |
| SHA | 75 MB/s | 160 bits |
3.5 Limitations of the IP Security Mechanisms
The AH and ESP do not
provide security against traffic analysis. It is not economical to
provide protection against traffic analysis at the IP layer. One approach in the
protection against the traffic analysis is the use of bulk link encryption,
another is sending false traffic in order to increase the noise in the data
listened by the traffic analyst. [1]
AH or ESP do not provide non-repudiation when used with the default algorithms (keyed MD5 and DES). Use of certain algorithms, for example, RSA with appropriate transformation provides non-repudiation. Non-repudiation should be concerned with the application layer security.
The AH keyed MD5 (RFC 1828) [12], AH keyed SHA (RFC 1852) [13], ESP DES DBC (RFC 1829) [6], or ESP Triple-DES (RFC 1851) [7] transformations do not protect against replay attacks. ESP transformation: "Combined DES-CBC, MD5 and Replay Prevention Security Transform" has been proposed [9]. This transformation may replace RFC 1829 [6] as a ESP conformance requirement. Protection against replay attacks may be also provided at the upper protocol layers.
The IPSEC mechanisms do not provide protection against all the Denial of Service attacks . It is hard to protect against all the denial of service attacks, for example a power cut caused by the enemy.
4. IPSEC Implementation Approaches
This chapter presents
implementation issues of the IPSEC. An example IPv6 implementation containing
IPSEC is described in [19].
An example of IPv4 AH implementation is described in [17].
Some of the issues presented here are raised from [18]
and from the author's own work with IPv4 IPSEC prototype implementing both AH
and ESP with manual key management into the Solaris 2.X environment.
4.1 Possibilities in placing IPSEC to TCP/IP stack
The IPSEC is
logically defined as a part of the upper half of the IP layer as shown in the
figure below.
There are basically three ways to implement IPSEC as part of the logical IP layer:
The benefits and drawbacks of implementing IPSEC below IP layer are described
rigorously in [17].
4.2 Independence of the Key Management Mechanism
One design
objective of the IPSEC specifications is to separate key management and security
mechanisms from each other. The design of a well-defined security association
interface to the implementation makes is possible to replace key management part
with new key management protocols when they are specified. It also makes it
easier to change the existing key management protocol to the better one, for
example, when security holes are found from the key management protocol.
4.3 Independence of the Cryptographic Algorithms
One desing
objective of the IPSEC specifications is to separate IP security mechanisms AH
and ESP from the cryptographic algorithms and transformations. The design of a
well-defined protocol - algorithm interface to the implementation makes it
possible to easily add new transformations and algorithms to the IPSEC after
they are specified. Also, cryptographic algorithms can easily be replaced with
stronger and better ones, if security holes are found from the existing one
without changing the whole AH and ESP implementation. A well-defined and
implemented interface makes it easier to put the algorithms on a separate
hardware.
4.4 Security of the Keys in the Host
One requirement for the IPSEC
key management is to pay special attention to the security of the keys in the IP
host system. A secure way is to put the keys outside the host operating system
into a separate hardware. The key parameters on the OS level security
associations represent the keys indirectly [18].
The actual keys stays at the hardware, and a key index is used to refer to a
specific key [18].
5. Summary
The IPSEC security mechanisms AH and ESP belong to IPv6
as integral parts. The presence of the mechanisms at the Internet layer provides
wide availability of the security services for the applications and the Internet
infrastructure as a whole.
The authentication header provides authentication and integrity. The encapsulated security payload provides confidentiality, and in addition integrity and authentication, if appropriate transforms and algorithms are used. Keyed MD5 transform must be implemented in AH compliant implementations and DES CBC transform must be implemented in ESP compliant implementations.
The Internet standard key management protocol and existing public key infrastructure is a prerequisite for wide-spread use of the IP security architecture among different organizations and persons in the international environment. The work is ongoing in the IETF to specify key management protocols and to provide technical support for public key infrastructure.
The requirement to support mandatory ESP in IPv6 and existing US export regulations may create problems to the manufactures to make IPv6 implementations. "One could thus select to develop the encryption products in a country such as Finland or Switzerland, which do not regulate export, assemble IPv6 package there, and export it from this neutral country to the whole world. Alternatively, one could ask developers in each country to produce an national version of ESP and DES-CBC, integrate it locally with IPv6 product, and distribute it nationally." [4].
| Authentication | The property of knowing that the data received is the same as the data that was sent and that the claimed sender is in fact the actual sender. |
| Integrity | The property of ensuring that data is transmitted from source to destination without undetected alteration. |
| Confidentiality | The property of communicating such that the intended recipients know what was being sent but unintended parties cannot determine what was sent. |
| Encryption | A mechanism commonly used to provide confidentiality. |
| Non-repudiation | The property of a receiver being able to prove that the sender of some data did in fact send the data even though the sender might later desire to deny ever having sent that data. |
| SPI | Acronym for "Security Parameters Index". An unstructured opaque index which is used in conjunction with the Destination Address to identify a particular Security Association. |
| Security Association | The set of security information relating to a given network connection or set of connections. This is described in detail below. |
| Traffic Analysis | The analysis of network traffic flow for the purpose of deducing information that is useful to an adversary. Examples of such information are frequency of transmission, the identities of the conversing parties, sizes of packets, Flow Identifiers used, etc. |
Timo Aalto