Arto Pulkki
Department of Physics
Helsinki University of Technology
Arto.Pulkki@hut.fi
1. Introduction
1.1 Technical Definitions
This section provides basic definitions that are applicable to information
security in general and especially to the IP Security Architecture (IPSEC).
Basic security functions as defined in IETF and ISO [1].
Other definitions used in IPSEC, as defined in [2].
1.3 IP Authentication Header
The IP Authentication Header was designed to provide at least strong
integrity and authentication to IP datagrams. It does this by
computing a cryptografic authentication function over the IP datagram
and using a secret authentication key in the computation. It may also
provide non-repudiation, but that depends on implemented algorithms and
how keying is performed. The intended lack on confidentiality
(encryption) is though to ensure its wide use on the Internet even on
locations where the export, import or use of encryption is regulated
[4]. Currently implemented
algorithms and modes are Keyed MD5
[5] and Keyed SHA
[6], although only the former is needed
for conformance to the standard and the latter is still considered
experimental [2, 6].
1.4 IP Encapsulating Security Payload
The IP Encapsulating Security Payload was designed to provide at least
integrity and confidentiality to IP datagrams. It does this by
encrypting data to be protected and placing the encrypted data in the
data portion of the IP Encapsulating Security Payload. It may also
provide authentication, but that depends on implemented algorithms and
their modes of use. It should be noted that non-repudiation and
protection from traffic analysis are not provided by ESP.
[3]
Currently implemented algorithms and modes are standard DES used in
CBC-mode [7] and
triple DES in CBC-mode [8],
although only the former is needed for conformance to the standard
and the latter is still considered experimental [2,
8].
1.5 Security Association
The concept of "Security Association" is fundamental to both ESP and
AH. It is a combination of an unstructured opaque index called
"Security Parameters Index" (SPI) and a Destination Address. This
combination uniquely identifies all parameters needed for secure
communication between any two parties conforming to IPSEC (e.g,
algorithm, mode, keys, transform, lifetimes, etc)
[2].
SPI is a 32-bit pseudo-random value identifying the security association for a particular datagram. The Security Parameters Index value 0 is reserved to indicate that "no security association exists". The set of Security Parameters Index values in the range 1 through 255 are reserved to the Internet Assigned Numbers Authority (IANA) for future use. A reserved SPI value will not normally be assigned by IANA unless the use of that particular assigned SPI value is openly specified in an RFC [4].
2. Syntax and Use
2.1 Authentication Header
The IP Authentication Header seeks to provide security by adding
authentication information to an IP datagram. This authentication
information is calculated using all of the fields in the IP datagram
(including not only the IP Header, but also other headers and the user
data) which do not change in transit. Fields or options which need
to change in transit (e.g., "hop count", "time to live", "ident",
"fragment offset", or "routing pointer") are considered to be zero
for the calculation of the authentication data. This provides
significantly more security than is currently present in IPv4 and
might be sufficient for the needs of many users.
| Next Header | Lenght | RESERVED SPACE | |
| Security Association Identifier (SPI), 32 bits | |||
| Authentication Data (variable number of 32-bit words) | |||
| IPv4 Header | Auth Header | Upper Protocol (e.g. TCP, UDP) |
| IPv6 Header | Hop-by-Hop/Routing | Auth Header | Others | Upper Protocol (e.g. TCP, UDP) |
2.2 Encapsulating Security Payload
ESP consists of an unencrypted header followed by encrypted data. The
encrypted data includes both the protected ESP header fields and the
protected user data, which is either an entire IP datagram or an
upper-layer protocol frame (e.g., TCP or UDP)
[3].
| Security Association Identifier (SPI), 32 bits | Opaque Transform Data, variable length |
| IP Header | Other IP Headers | ESP Header | encrypted data | ||
| IP Header | Other IP Headers | ESP Header | encrypted data | ||
In Transport-mode, the ESP header is placed into the IP datagram immediately prior to the transport-layer protocol header. This method has less protocol overhead and uses less bandwidth as there are no encrypted IP headers.
In Tunnel-mode, the original IP datagram is inserted in the encrypted portion of the ESP, and that entire frame is placed within a datagram having a unencrypted IP header to be used in routing.
2.3 Control and communication
In the case where a security gateway is providing services on behalf
of one or more 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 the external system(s)
[2].
Gateway's operation can be controlled automatically, as a system which receives a datagram containing a recognized sensitivity label from a trusted host should take that label's value into consideration when creating/selecting a Security Association for use with ESP and AH between the gateway and the external destination. This works both ways as in such an environment, a gateway which receives a IP packet containing the IP Encapsulating Security Payload (ESP) should add appropriate authentication, including implicit (i.e., contained in the Security Association used) or explicit label information (e.g., IPSO), for the decrypted packet that it forwards to the trusted host that is the ultimate destination [2]. The standard also states that the IP Authentication Header should always be used on packets containing explicit sensitivity labels to ensure end-to-end label integrity [2].
3. Algorithms
3.1 Introduction
The quality of security provided in IPSEC depends completely on the
strength of the implemented cryptographic algorithms, the strength of the
key being used, the correct implementation of the cryptographic algorithms,
the security of the key management protocol, and on the correct implementation
of IP and the several security mechanisms in all of the participating
systems [2].
It should be noted that the security of the implementation is in part related to the security of the operating system which embodies the security implementations [2]. For more detailed presentation about computer system security evaluation, see [17, 18].
3.2 Standard Algorithms
Currently IPSEC provides only two standards and required algorithms to
be used with it; MD5 for AH and DES-CBC for ESP [3,
4]. The standard is constructed in a way that
new algorithms can be easily added and this is a very likely scenario
with the shortcomings of the two implemented algorithms. It is currently
thought that these new methods will become optional, and only MD5 and
DES will be needed to comform to the standard, but it is not said that
this could not change.
Current MD5 software speeds are adequate for commonly used LAN and WAN links, but they are reportedly too slow for newer link technologies [10]. It is also considered disturbing by some authors [11] that the current cryptanalysis technologies are catching up with the MD5, and that it is now possible to produce collisions in the compression function of MD5, even if there are no known methods to exploit these findings [5].
Even though MD5 is probably adequately secure and speedy for most of the current needs of the Internet, IETF is actively looking for an alternative authentication algorithm that has faster throughput, is not patent-encumbered, and would still be adequately cryptografically strong [5].
Standard DES is no longer considered to be a good encryption algorithm for protection even for moderate value information, as it has been shown that one should be able to produce a brute force DES cracking machine that can crack one key every 3.5 hours with only 1 million USD. Also progress made in the fields of linear and differential cryptanalysis has weakened its credibility. The triple DES introduced in 3.3 is considered to be much more stronger [7].
For a good explanation and implementation information for DES, see [11].
3.3 Experimental Algorithms
The shortcomings of the two above mentioned methods became very clear
during and even before the IPSEC development process and so optional
algorithms were seeked to offer more speed and stronger encryption. This
was done parallel to the actual standard development and only a month after
the originals, MD5 AH and DES-CBC ESP, were published, the same groups
published their works with new algorithms described below
[7, 8, 5,
6].
It should be noted that implementation of these algorithms is not required in IPSEC and they should be treated as experimental.
The shared key is not constrained by this transform to any particular size. Lengths of up to 160 bits must be supported by the implementation, although any particular key may be shorter. Longer keys are encouraged by the authors [6].
At the time of writing this document, there are no known flaws in the SHA algorithm. That is, there are no known attacks on SHA or any of its components that are better than brute force, and the 160-bit hash output by SHA is substantially more resistant to brute force attacks than the 128-bit hash size of MD4 and MD5 [6].
Although preliminary results indicate that SHA is 62% as fast as MD5, and 80% as fast as DES hashing, IETF is still actively looking for alternative authentication algorithms that have faster throughput, are not patent-encumbered, and would still be adequately cryptografically strong [6].
Three DES-CBC implementations may be pipelined in series to provide parallel computation. At the time of writing, at least one hardware implementation can encrypt or decrypt at about 1 Gbps [11].
For a good explanation and implementation information for 3DES, see [11].
4. Key Management
4.1 Standard Requirements
IPSEC tries to decouple the key management mechanisms from the security
protocol mechanisms. The only coupling between the key management
protocol and the security protocol is with the Security Parameters
Index (SPI). This decoupling permits several different key management
mechanisms to be used. More importantly, it permits the key management
protocol to be changed or corrected without impacting the security
protocol implementations [3, 4].
The key management mechanism is used to negotiate a number of parameters for each "Security Association", including not only the keys but also other information (e.g., algorithms and modes) used by the communicating parties. The key management mechanism creates and maintains a logical table containing the several parameters for each current security association. An implementation of the IPSEC will need to read that logical table of security parameters to determine how to process each datagram containing an AH or ESP (e.g., to determine which algorithm/mode and key to use) [3, 4].
The standard itself only requires that all implementations conforming to it must support the manual configuration of Security Associations. It does, however, suggest that all implementations should support an Internet standard Security Association establishment protocol (e.g., Photuris, SKIP) once such a protocol is published as an Internet standards-track [15] RFC [2].
4.2 Photuris Key Management Protocol
Photuris doesn't need on-line third party (e.g. Central Authority) to handle key exchange and/or store their values in a central database like Kerberos and is therefore considered much more redundant and secure [16].
Initiator
Cookie_Request ->
Responder
<- Cookie_Response
In addition, supported exchange schemes are offered for calculating the shared-secret [16].
Initiator
Exchange_Request ->
Responder
<- Exchange_Response
In addition, supported attributes are offered for use in the Security Associations [16].
Initiator
Identification_Message ->
Responder
<- Identification_Message
The shared-secret provides a basis to generate separate Security Association session-keys in each direction, which are in turn used for conventional authentication or encryption. Additional security attributes are also exchanged as needed.
This exchange may also be encrypted for privacy using another permutation of the shared-secret. This protects the identities of the parties and hides the security parameter values [16].
Initiator
Change_Message(s) ->
Responder
<- Change_Message(s)
These exchanges may also be encrypted for privacy in the same fashion as above.
5.2 IP Multicasting
5.3 Multi-level Networks
The Authentication Header can be used to provide strong assurance for both mandatory access control decisions in multi-level networks and discretionary access control decisions in all kinds of networks [2].
The Encapsulating Security Payload can be combined with appropriate key policies to provide full multi-level secure networking. In this case each key must be used only at a single sensitivity level and compartment. For example, Key "A" might only be used for sensitive Unclassified packets, while Key "B" is used only for Secret/No- compartments traffic, and Key "C" is then used only for Secret/No-Foreign traffic. The sensitivity level of the key should be the same as the sensitivity level of the Security Association and neither should dominate each other [2].
6. Observations
6.1 Performance Impact
The use of standard IPSEC will increase the IP protocol
processing costs in participating end systems and will also increase
the communications latency. In cases where a host alone is providing
both MD5-AH and DES-ESP with IPv6, without any dedicated hardware help,
the performance hit could be very severe. Low-end router-gateways with
hardware assisted protocol processing should be able to survive the
impact much more easily, as they most likely would only need to
upgrade their RISC or VLSI to the next performance level to get more
or less acceptable performance for current link speeds in means of
packet thruput. This of course is only speculation, as there are no
working implementations at the time of writing this document.
High-end, high-thruput systems will suffer from standard IPSEC even if they are able to use dedicated hardware to perform time consuming hash calculations and encryption transforms. The obvious bottleneck is the required use of the MD5 algorithm, which in the current implementations is only capable of 87Mbps in software and 256Mbps in hardware, compared to 1Gbps speeds of DES and 3DES [10]. This is obviously too slow to be used in the next generation of high speed WANs and LANs.
However, the solution to corporate level gateways is found very easily by adding extra AH and ESP algorithms to standard IPSEC. By doing this, organizations can benefit from the faster speeds of extra implementations where it's necessary and they can still use standard based algorithms when communicating with third parties that support only standard IPSEC. And IPSEC can do all this without user interference by transparently negotiating the fastest implementation both sides support.
6.2 Legal Issues
In the past the widespread use of security tools with encryption mechanisms
has been blocked by national laws and rules concerning export, import and
actual use of encrypted communications. This has lead to a use of 'export'
versions of security software and hardware with algorithms not suited for
the application or with the original algorithms, but with shorter keys. It is
to counter this that IPSEC defines two clearly separate mechanisms for IP
level security; one with encryption and one without.
This is a very good idea as it really provides a method for providing at least strong authentication and integrity checking (i.e. AH) even if one is not allowed to use encrypted communications (i.e. ESP). It also provides an easy solution to those wanting to use encrypted in-country communications, but are not allowed to use it in inter-country communications (e.g. USA), as IPSEC allows one to use both methods in parallel and their use can be easily controlled by SPI.
| AH | Authentication Header |
| CBC | Cipher Block Chaining |
| DES | US Data Encryption Standard |
| ESP | Encapsulating Security Payload |
| ICMP | Internet Control Message Protocol |
| IETF | Internet Engineering Task Force |
| IP | Internet Protocol |
| ISO | International Standards Organication |
| LAN | Local Area Network |
| OSI | Open Systems Interconnection |
| TCP | Transmission Control Protocol |
| UDP | User Datagram Protocol |
| WAN | Wide Area Network |