The term IPsec (IP Security Protocol) refers to a set of mechanisms designed to protect the traffic at the IP level (IPv4 or IPv6). The security services provided by IPsec are connectionless integrity, data origin authentication, protection against replays and confidentiality (data confidentiality and partial protection against traffic analysis). These services are provided at the IP layer, thus offering protection for IP and all upper layer protocols. Optional in IPv4, IPsec is mandatory for any implementation of IPv6. Once IPv6 is widely spread, it will be possible for any user wishing to use security functions to use IPsec. In the meantime, we must rely on IPsec implementations under IPv4.
IPsec is developed by a working group of the same name within the IETF (Internet Engineering Task Force). This group was created in 1992 and a first version of the proposed mechanisms was published in the form of RFCs in 1995. This first version didn't include the key management part, which is more recent. Key management was included in the new IPsec RFCs that came out in November 1998. But IPsec remains an evolving standard, which is still subject to multiple Internet drafts. This presentation only covers the 1998 RFCs.
This section provides a high level description of how IPsec works, its components and the way in which they interact, and the possible uses of IPsec.
1.1. Structure of IPsec
Exchanges on TCP networks can be secured in a variety of manners. Approaches vary according to the layer at which they take place, for example: application layer (encrypted mails for example), transport layer (TLS/SSL, SSH...), or, on the opposite, physical layer (black boxes encrypting all the data going through a given link). IPsec aims at securing the exchanges at the network layer.
The AH and ESP mechanisms
These objectives are met through the use of two security mechanisms, the AH and ESP "protocols", which are added to traditional IP processing:
Authentication Header (AH) is conceived to ensure integrity and authentication of IP datagrams, without data encryption (i.e. without confidentiality).
The principle of AH is to add an additional field to the traditional IP datagram; this field makes it possible for the receiver to check the authenticity of the data included in the datagram.
Encapsulating Security Payload (ESP) is primarily designed for ensuring confidentiality, but can also provide data authenticity.
The principle of ESP is to generate, from a traditional IP datagram, a new datagram in which the data and eventually the original header are encrypted.
These mechanisms can be applied alone or in combination with each other to provide the desired security services. They will be described in detail in the chapter "2. Security mechanisms: AH and ESP".
Security association concept
The mechanisms mentioned above use cryptography, and thus require a certain number of parameters (encryption algorithms used, keys, selected mechanisms ...) on which the communicating parties must agree. In order to manage these parameters, IPsec uses the Security Association (SA) concept.
A security association is a one-way "connection" that provides security services to the traffic carried by it. One can also regard it as a set of parameters that describe how a given communication is to be secured.
A SA is unidirectional, consequently, protecting a typical bi-directional communication requires two associations, one in each direction. The security services are provided either by the use of AH or ESP. If AH and ESP are both applied to the traffic in question, then two (or more) SAs are created to protect the traffic; they are called a SA bundle.
In fact, each association is uniquely identified by the following triple:
the packets' destination address,
the security protocol identifier (AH or ESP),
a Security Parameter Index (SPI).
A SPI is a 32 bits block transmitted in clear in the header of each exchanged packet; the receiver chooses it.
IPsec stores active security associations in a database called the Security Association Database (SAD). It contains all the parameters related to each SA and is consulted to know how to treat each received or sent packet.
Keys and security associations management
As mentioned in the preceding paragraph, a SA contains all the parameters necessary for IPsec operations (including the keys in use). Key management for IPsec is only related to the different security mechanisms through the SAs. The SAs can be configured manually if the situation is simple enough, but the general rule is to use a specific protocol, which allows the dynamic negotiation of SAs and in particular the exchange of session keys.
In addition, IPv6 is not intended to support in-band key management, where the data related to key management would be transported using a distinct an IPv6 header. Instead, it uses an out-of-band key management system, where the data related to key management is transported by an upper-layer protocol such as UDP or TCP. This allows the clear decoupling of the key management mechanism from other security mechanisms. It is thus possible to substitute the key management methods without having to modify the implementation of the security mechanisms.
The protocol for negotiating the SAs developed for IPsec is called "Internet Security Association and Key Management Protocol" (ISAKMP). In fact, ISAKMP is not usable alone: it is a generic framework which allows the use of several key exchange protocols and which can be used for other security mechanisms that those of IPsec. Within the framework of the standardization of IPsec, ISAKMP is associated with part of the SKEME and Oakley protocols to result in a protocol called IKE (Internet Key Exchange). These protocols will be described in detail in the chapter "3. Key management: ISAKMP and IKE".
The protections offered by IPsec are based on policy choices defined in the Security Policy Database (SPD). This database is established and maintained by a user, a system administrator or an application installed by them. It makes it possible to decide, for each packet, if it will be afforded IPsec security services, discarded or allowed to bypass IPsec.
The SPD contains an ordered list of rules, each rule being identified by one or more selectors that define the set of IP traffic affected by this rule. The possible selectors are the set of information available in the IP and transport layer headers. The selectors define the granularity for applying the security services and directly influence the corresponding number of SAs. If security services are to be applied to the traffic corresponding to an entry, the entry includes a SA (or SA bundle) specification, listing the IPsec protocols, modes, and algorithms to be employed, including any nesting requirements.
1.2. Principle of operation
The diagram below represents all the elements presented above (in blue), their positions and their interactions.
- Figure 1. Organization of IPsec -
Two situations are distinguished:
- Outbound traffic
When the IPsec "layer" receives data to be sent, it starts by consulting the policy database (SPD) to determine what processing is required for the packet. If the packet must be afforded security services, the IPsec engine recovers the characteristics of the corresponding SA(s) and consults the SA database (SAD). If the necessary SA already exists, it is used to process the traffic in question. In the contrary case, IPsec calls IKE to establish a new SA with the necessary characteristics.
- Inbound traffic
When the IPsec "layer" receives a packet from the network, it examines the header to determine if this packet was afforded IPsec protection and if so what are the SA references. It then consults the SAD to determine the parameters to use for checking and/or the deciphering of the packet. Once the packet is checked and/or deciphered, the SPD is consulted to determine if the required IPsec processing was applied.
If the received packet is a "normal" IP packet, the SPD makes it possible to know if it can nevertheless bypass IPsec. For example, IKE packets are an exception. They are to be treated by IKE, which can send administrative alarms in the event of an unsuccessful attempt to establish connection.
1.3. Possible types of uses
After having seen how IPsec is made up and how it works, we will now take a look at the various ways of using it. An important point to notice is the fact that acting at the network layer makes the security completely transparent for the applications.
Equipment providing IPsec
IPsec can be used either on a terminal host or on a security gateway, thus allowing both link-by-link and end-to-end security. Three basic configurations are possible:
- Figure 2. Various possible configurations depending on the equipment implementing IPsec -
The first situation when two distant private network are to be connected using an unreliable network such as the Internet. In such a case, a virtual private network (VPN) is established between the security gateways.
The second situation corresponds to the case where mobile users are to securely access the intranet. The unreliable network can be the Internet, the telephone network...
Lastly, in the third situation, two parties wish to communicate in a secure way but do not have any confidence in the network that separates them.
One can also imagine more complex configurations where several security associations, possibly affording different security services, would follow one another or would be partially superposed:
- Figure 3. Examples of double uses of IPsec -
In the above example, the first association can ensure the security services required by the external security policy (authentication and confidentiality for example), and the second SA can ensure the services required by the internal security policy (authentication of the terminal host for example).
For each security mechanism in IPsec, there are two modes: transport mode and tunnel mode.
In transport mode, only the data coming from the upper-layer protocol and transported by the IP datagrams are protected. This mode is usable only on final equipment.
In tunnel mode, the IP header is also protected (authentication, integrity and/or confidentiality) and is replaced by a new header. This new header is used to transport the packet to the end of the tunnel, where the original header is restored. Tunnel mode is usable either on final equipment or on security gateways. This mode makes it possible to ensure a more significant protection against traffic analysis.
Summary and bibliography
IPsec is security protocol that works at the IP level and relies on two mechanisms (or protocols), AH (Authentication Header) and ESP (Encapsulating Security Payload). The parameters necessary to the use of these protocols are managed thanks to security associations (SA), an association containing the parameters used to protect a given part of the traffic. SAs are stored in the Security Association Database (SAD) and are managed using the IKE (Internet Key Exchange) protocol. The protection offered by IPsec is based on choices defined in the Security Policy Database (SPD). This database allows to decide, for each packet, if it will be afforded some security services, will be authorized to pass by or will be rejected.
IPsec can be used either on a terminal host or on a security gateway, which allows for both link-by-link and end-to-end security. IPsec can thus be used, in particular, for the creation of virtual private networks (VPNs) or for the protection of remote accesses. Finaly, IPsec has two modes: transport mode, which protects only the transported data, and tunnel mode, which also protects the IP header.
The base document on IPsec is entitled "Security Architecture for the Internet Protocol"; the most recent version is [RFC 2401].
2. Security mechanisms: AH and ESP
As we already mentioned in the previous chapter, two basic mechanisms are used to afford the security functions provided by IPsec. They are:
Authentication Header (AH), which is conceived to ensure integrity and authentication of the IP datagrams without encryption of the data (i.e. without confidentiality).
Encapsulating Security Payload (ESP), whose role first is to ensure confidentiality.
These mechanisms can be used alone or combined to obtain the desired security functions.
The IPsec mechanisms are not related to any specific cryptographic algorithm, therefore these algorithms can be modified without affecting the other elements of an implementation. However, to ensure interoperability, default algorithms are given. Furthermore, the properties of the algorithm used will have some influence on the provided security functions.
I will start by a small reminder on security services and mechanisms concerning the protection of data flows, before detailing how the AH and ESP protocols work.
2.1. Reminder on security services and associated mechanisms
Confidentiality is a security service that consists in making sure that only the authorized people can have knowledge of some data. The mechanism that makes it possible to obtain this service is generally data encryption using a cryptographic algorithm.
If only the transported data are encrypted, an eavesdropper can still rely on the external characteristics of the traffic transiting on a network to obtain some information: frequency of the transmissions, identities of the communicating peers, quantities of transferred data. Associated with information of different nature (appointment date, public news ...) these elements can enable an adversary to make interesting deductions. Protection against traffic analysis is offered when hiding the source and destination addresses, the size of the packets, the frequency of the exchanges ... prevents traffic analysis.
Authentication and integrity
There are two types of authentication:
Authentication of a party is the action that consists in proving one's identity.
This service is generally provided by the use of an "authentication exchange" which implies some dialogue between the peers.
Data origin authentication is used to prove that the received data were indeed transmitted by the declared transmitter.
Integrity is a security service that consists in making sure that only the authorized people will be able to modify some data. Within the world of communications, this service consists in allowing the detection of modification of data during its transfer. There are two types of integrity:
Connectionless integrity makes it possible to detect modifications on an individual datagram, but not on the order of the datagrams.
Integrity in connected mode allows, in addition, the detection of the loss of packets or their reordering.
When one communicates with another person through an unsure channel, one would like that the recipient can make sure that the message indeed emanates from the author to which it is allotted and that it was not tampered with during its transfer. The corresponding services are data origin authentication and integrity.
One-way hash functions make it possible to ensure data integrity: applied to some data, such a function generates a block of smaller size called hash. Any modification of the data involves a modification of the hash, and it is very difficult to generate a message having the same hash as the original. If one has
a secure (but more expensive) channel in parallel of the normal communication channel, one can communicate the hashes of the messages via this channel. At reception, the recipient recomputes the hash and compares it with the original one to check that the data were not modified.
Without a secure channel, the problem becomes more complicated: if one transfers the hash on an insecure communication channel, a "man-in-the-middle" can modify the data and recompute the hash. It is thus necessary to find a way of making sure that only the sender is able to calculate the hash. For that, one can use, for example, a one-way hash function which also uses a secret or private key. By doing this, data origin authentication is also provided. Conversely, if data origin authentication is provided by a means that does not guarantee data integrity, an intruder can modify the message and thus make the receiver accept any data as authenticated. This is why integrity and data origin authentication are generally provided jointly by the same mechanism. I will sometimes use the term "authenticity" to indicate integrity coupled with data origin authentication. The term "authentication" is also often used to indicate both authentication and integrity.
The two mechanisms that make it possible to ensure the authenticity of the transmitted data are sealing and signature.
Sealing consists in associating a seal or Message Authentication Code (MAC) to the message. A MAC is the result of a one-way hash function with a secret key: the hash depends both on the data and on the key. Thus, only the peers who know the secret key can compute the MAC.
Digital signature ensures data authenticity, but also provides non-repudiation with proof of the origin: the sender cannot deny having sent a message that he signed. This last point differentiates the signature from message authentication codes; its consequence is that most signature algorithms use public key cryptography.
Lastly, protection against replay is a form of partial connectionfull integrity, which makes it possible to counter the attacks during which an adversary sends a previously intercepted message, hoping that the recipient will accept it as valid. This service is generally ensured by the use of a sequence number.
Summary and bibliography
The main network security services are:
Confidentiality, which is ensured by data encryption.
Authenticity (authentication + integrity), which is ensured by adding a message authentication code to each transferred packet.
The various services and mechanisms intervening in network security are formally defined in the [ISO 7498-2] standard.
For more details on the cryptographic concepts mentioned here, you can refer to the bibliography on cryptology.
2.2. Authentication Header (AH)
AH ensures connectionless data integrity, data origin authentication and, optionally, protection against replay.
The absence of confidentiality in AH makes it possible to ensure that this standard will be widespread on the Internet, including in the places where export, importation or use of encryption for confidentiality are restricted by law. That's one of the reasons for the use of two distinct mechanisms.
In AH, integrity and authentication are provided jointly, using an additional block added to the protected message. This block is called an Integrity Check Value (ICV), a generic term used to indicate either a Message Authentication Code (MAC), or a digital signature. For the moment, all the proposed algorithms are sealing algorithms, obtained using a one-way hash function and a secret key. The use of public key cryptography to generate a digital signature is also possible.
Protection against replay is provided by a sequence number; its use can be selected by the recipient at the time of the options negotiation.
Here is the organization of the authentication header:
- Figure 4. AH format -
The sender computes the authentication data on the invariant fields of the final IP datagram, AH included, which makes it possible to extend the authentication to the SPI and sequence number in particular. The variable fields (TTL, routing ...) and the field intended to receive the authentication data are considered equal to zero for calculation. The authentication data is then added to the IP datagram thanks to the authentication header (AH). The receiver checks the validity of this data upon reception.
The figures below indicate the position of AH and the service brought depending on the selected mode (transport or tunnel).
- Figure 5. Position of AH in transport mode (IPv4) -
- Figure 6. Position of AH in tunnel mode (IPv4) -
The default AH algorithms that must be provided by any implementation of IPsec are, at the time this document is written, HMAC-MD5 and HMAC-SHA-1. Other possible algorithms are KPDK-MD5, DES-MAC and HMAC-RIPE-MD.
Summary and bibliography
AH ensures authenticity of the transported data and the IP header by adding a message authentication code (HMAC-MD5, HMAC-SHA-1) to the protected packet. When using IKE, AH can also protect against replay.
AH is described in the document entitled "IP Authentication Header", which last version is [RFC 2402].
The authentication algorithms for use with AH are listed in the IPsec DOI [RFC 2407] and are described in various documents.
2.3. Encapsulating Security Payload (ESP)
ESP can ensure, on choice, one or several of the following services:
confidentiality (data confidentiality and partial protection against traffic analysis if tunnel mode is used),
connectionless data integrity and data origin authentication, protection against replay.
Confidentiality can be selected independently of the other services, but its use without integrity/authentication (directly with ESP or with AH) makes the traffic vulnerable to certain types of active attacks which could weaken the confidentiality service. As in AH, authentication and integrity are two services that go hand in hand and are often regrouped under the term "authentication"; they are provided by the use of an ICV (in practice, a MAC). Protection against replay can be selected only if authentication was selected. It is provided by a sequence number, which the receiver of the packets checks.
Contrary to AH, which only consisted of adding a new header to the datagram, ESP functions according to the encapsulation principle: the original data are encrypted then encapsulated between a header and a trailer. Here is the organization of ESP:
- Figure 7. ESP format -
The padding field can be necessary for block ciphers or to align the encrypted text on a 4 bytes limit.
Authentication data is present only if this service was selected.
Let us see now how confidentiality is ensured in ESP. The sender:
Encapsulates, in the payload field of ESP, the data transported by the original datagram and eventually the IP header (tunnel mode).
If necessary, adds some padding.
Encrypts the result (data, padding, length and next header fields).
Eventually adds an initialization vector at the beginning of the payload.
If it was selected, authentication is always applied after the data was encrypted. That makes it possible, upon reception, to check the validity of the datagram before starting the expensive task of deciphering. Contrary to AH, the authentication in ESP is only applied to the ESP "packet" (header + payload + trailer) and includes neither the IP header nor the authentication field.
The figures below indicate the position of ESP and the services it provides, depending on the selected mode (transport or tunnel).
- Figure 8. Position of ESP in transport mode (IPv4) -
- Figure 9. Position of ESP in tunnel mode (IPv4) -
The algorithms that are proposed for use with ESP at the time this document is written are:
Confidentiality: triple DES (MUST), DES-CBC, RC5, CAST, IDEA, triple IDEA, Blowfish, RC4 and NULL for cases in which encryption is not wanted.
Authentication: HMAC-MD5 (MUST), HMAC-SHA-1 (MUST), DES-MAC, HMAC-RIPE-MD, KPDK-MD5 and NULL for cases in which authenticity is not selected.
Summary and bibliography
3. Key management
The security protocols presented in the preceding chapter all use cryptographic algorithms and thus need keys. One of the fundamental problems of cryptography is the management of these keys. The term "management" covers the generation, distribution, storage and deletion of the keys.
3.1. General concepts regarding key management
The purpose of this paragraph is to introduce some useful concepts for understanding the parts of this paper related to key management.
3.1.1. Keys hierarchy
Several key types can be defined, depending on their role:
- Keys encrypting keys
Located in top of the hierarchy, these keys are exclusively used to encrypt other keys and generally have a long life span. Cryptanalysis is made more difficult at their level by the fact that they are only used to encrypt random number. Public key cryptography is often used to transport secret session keys by encrypting them with public keys.
- Master keys
Master keys are keys that are not used to encrypt but only to generate other keys by derivation. A master key can thus be used, for example, to generate two keys: one for encryption and one for signature.
- Session keys
Of a generally short life span (the key can even be changed with each message), such a key, as opposed to the preceding ones, is used to encrypt data and is thus located at the bottom of the hierarchy. Because of their slowness, asymmetrical algorithms are rarely used for encrypting data, and session keys are thus generally secret keys.
It should be noted that language misuses often happen with these terms. Thus, the term session key is often used to refer to a master key of the same life span and which is used to generate several keys: one for authentication, one for encryption...
3.1.2. Public key infrastructures
Many protocols and applications use public key cryptography on a large scale and must be able to manage large lists of public keys for distributed systems. For that, they resort to public key infrastructures, which are conceived to manage public keys on a large scale.
Most public key infrastructures are based on certification authorities (CAs), which are entitled to deliver certificates. More exactly, they verify and authenticate public keys. These authorities are generally organized in a hierarchy, which allows a greater flexibility for the management of the public keys by the means of certificates signed by these authorities and of certificate revocation lists (CRLs).
There are currently many PKIs, most of which are still in development stage. Examples of public key infrastructures include PKIX (Public-Key Infrastructure X.509), SPKI (Simple Public Key Infrastructure) and DNSSEC (Domain Name System Security), which are all being standardized by the IETF.
3.1.3. Key exchange and authentication
The establishment of a secure communication generally starts by an authentication exchange to provide access control. Then, a key exchange provides the material necessary to use security mechanisms to protect the traffic: the authentication is thus extended to the rest of the communication. Of course, the key exchange must be authenticated. The combinaison of the initial authentication and of the key exchange is provided by an authenticated key exchange protocol.
3.1.4. Key exchange protocols properties
Diffie, Van Oorschot and Wiener defined, in [DOW92], the concept of a secure authenticated key exchange protocol. A protocol is said to be secure if the two following conditions are verified in every case where the protocol is carried out and on of the two parties, for example Alice, carries out the protocol honestly and accepts the identity of the other party:
When Alice accepts Bob's identity, the recordings of the messages exchanged by two parties correspond (i.e. the messages were not modified during their transfer).
It is materially impossible for anybody except Alice and Bob to find the exchanged key.
The above property represents the minimum necessary for any key exchange protocol. However, other properties of key exchange protocols can be desirable:
The property known as Perfect Forward Secrecy (PFS) is guaranteed if the discovery, by an opponent, of the long-term secrets does not compromise the session keys that were previously generated: the past session keys cannot be recovered with the knowledge long-term secrets. It is generally considered that this property also ensures that the discovery of a session key compromises neither the long-term secrets nor the other session keys. Perfect Forward Secrecy can be provided, for example, by generating the session keys using the Diffie-Hellman protocol (see below), wherein the Diffie-Hellman exponentials are short-term values.
The property known as Back Traffic Protection is provided if the generation of each session key is done in an independent way: the new keys do not depend on the preceding keys and the discovery of a session key makes it possible neither to find the last session keys nor to deduce the future keys.
A protocol provides direct authentication if, at the end of the protocol, the values being used to generate the shared secret are authenticated or if each party proved that he knew the session key. By opposition, authentication is said to be indirect if it is not guaranteed at the end of the protocol, but depends on the capacity of each party to use, during the exchanges that follow, the keys that were agreed upon.
A protocol guaranties identity protection if an eavesdropper will not be able to know the identities of the communicating peers.
Lastly, the use of timestamps in order to avoid replay is subject to controversy, mainly because of its too great dependence on synchronized clocks.
Invented in 1976 by Diffie and Hellman, this protocol enables two parties to generate a shared secret without having any preliminary information on one another. Diffie-Hellman is based on public key cryptology: it uses public values and private values. Its security depends on the difficulty of calculating discrete logarithms in a finite field. The secret generated using this protocol can be used to derive one or more keys.
Here is the course of the protocol:
Alice and Bob agree on a large prime n and on g such that g is primitive modulo n. These two integers are public.
Alice randomly chooses a large integer a, which she keeps secret, and computes her public value A=ga mod n. Bob does the same thing and generates b and B=gb mod n.
Alice sends A to Bob; Bob sends B to Alice.
Alice computes KAB=Ba mod n; Bob computes KBA=Ab mod n. KAB=KBA=gab mod n is the secret shared by Alice and Bob.
A person who listens to the communication knows g, n, A=ga mod n and B=gb mod n, which does not enable him to compute gab mod n: for that, he would first have to compute the discrete logarithm of A or B so as to recover a or b.
On the other hand, Diffie-Hellman is vulnerable to the active attack known as the man-in-the-middle attack.
The principle of the man-in-the-middle attack is that, while two parties carry out a key exchange by using a protocol such as Diffie-Hellman, an adversary intercepts all the exchanges. By modifying the messages the adversary carries out a key exchange with each party. At the end of the protocol, each party will thus use a different key, each key being known by the adversary. For each message transmitted thereafter, the adversary will proceed to its deciphering with the corresponding key and will cipher it with the other key before sending it to the intended recipient: the two parties will think they are communicating in a secure way even though the adversary can read all the messages and even make up fake messages.
Here is how this attack works for Diffie-Hellman:
Alice sends her public value A=ga mod n to Bob; Ingrid the interceptor replaces this public value by hers. Bob thus receives I=gi mod n.
Bob sends his public value to Alice; Ingrid also replaces this value by hers.
Alice generates the "secret" KAI=Ia mod n. Ingrid generates the same secret by computing Ai mod n.
Bob generates the "secret" KBI=Ib mod n. Ingrid
generates the same secret by computing Bi mod n.
Alice and Bob believe they share a secret, but in fact they both share a different secret with Ingrid.
A way to circumvent that problem is to authenticate the public values used for the generation of the shared secret. That can be done in two ways:
By using authenticated public values, using certificates for example. The SKIP protocol is based on this method.
By authenticating the public values after having exchanged them, for example by signing them. This method is used, among others, by the Photuris protocol.
The disadvantage, in both cases, is the possibility to generate a shared secret without any preliminary information on the interlocutor is lost. But, if the public values are short-term values, authenticated Diffie-Hellman provides perfect forward secrecy.
For further details on communications security in the Internet world, [Opp98] gives a good overview of various technologies.
For further details on the cryptographic concepts mentioned here, please refer to the bibliography on cryptology.
3.2. Authenticated key exchange protocols developed for IP
There are many authenticated key exchange protocols, which impose different requirements (pre-shared secret, public key infrastructure ...) and provide different properties (direct authentication, perfect forward secrecy ...).
Within the scope of the key exchange protocols developed for securing exchanges using IP, an additional distinction is necessary between the connection-oriented protocols and the connectionless ones. In the first case, an authenticated key establishment protocol is used "off-band", before the communication. The resulting key is then used to secure the IP traffic. The disadvantage of this approach is that it requires the establishment and the management of a pseudo session layer under IP, whereas IP is a connectionless protocol. In the second case, a stateless authenticated key establishment protocol is used, which does not require any connection. This is feasible through an "in-band" protocol, where the key that is used to encrypt the packet is transmitted with it, encrypted with the recipient's public key for example. The disadvantage of this system is that it adds data to each transmitted packet.
In addition, Diffie-Hellman is often used by the protocols presented here, the differences coming from the life span of the public values used and the way in which they are authenticated and exchanged.
SKIP (Simple Key management for Internet Protocols) is an example of a protocol which is not based on the establishment of a connection. Indeed, no preliminary exchange of messages is necessary before being able to send an encrypted packet and each packet transports the information that is necessary to decipher it. As far as the network layers are concerned, the consequence is that SKIP is situated at the IP level, and not above TCP or UDP like most of the key management protocols.
In addition, SKIP is based on the generation of shared secret using Diffie-Hellman with authenticated public values, therefore the only requirement is that each party must own an authenticated Diffie-Hellman public value.
SKIP was created in 1994 by Ashar Aziz and Whitfield Diffie from Sun Microsystems. Sun Microsystems applied for a patent in June 1994 then placed it in the public domain shortly after. SKIP was proposed as a standard key management protocol for IPsec and a certain number of Internet drafts were published to that effect until August 1996. At that time, the two possible standards for key management in IPsec were SKIP and ISAKMP/Oakley. A choice was necessary, and the question was solved in favor of ISAKMP/Oakley in September 1996. Although ISAKMP/Oakley (which as since be renamed IKE) was selected to be the compulsory protocol for any implementation, the use of SKIP is not excluded. However, the publication of Internet drafts about it has ceased since that date. Sun Microsystems continues to develop this protocol and includes it in various products, in particular SunScreen SKIP. SKIP can also be used for IPsec key management in the product Firewall-1 by Check
SKIP is based on a Diffie-Hellman shared secret generation, with authentication to avoid a possible man-in-the-middle attack. As the two peers both own an authenticated Diffie-Hellman public value, they can, with the knowledge of the other's public value and of their own private value, compute a shared secret.
So, in order to use SKIP, each peer must have an authenticated Diffie-Hellman public value. This authentication can be obtained in various ways: X.509 certificate, secure DNS, PGP signed key ... In addition, to be able to communicate with a chosen peer, a party must obtain his public value. A way of providing that is by distributing the public values thanks to a "directory service" or thanks to the "Certificate Discovery Protocol" (CDP).
Let I and J be the two peers. The private values are respectively i and j and the public values gi mod p and gj mod p. Each peer computes the shared secret by raising the public value of its partner to the power his own private value: (gj mod p)i=(gi mod p)j. gij mod p is called long-term shared secret and is used to derive a secret key Kij. Indeed, gij mod p will typically be at least 1024 bits long, whereas Kij is a secret key whose length typically ranges from 40 to 256 bits. In SKIP, Kij is composed of the lower weight bits of gij mod p.
That's all for the key exchange. SKIP also specifies how this key is used to protect the exchanges between I and J. Kij is in fact a key encryption key that is used exclusively to encrypt keys of much shorter life span. Indeed, Kij is used to encrypt Kp, a key called packet key, which itself is used to derive two keys, one for the encryption and one for the authentication of the IP packet (or a part of the packets).
SKIP's operating mode, although it does not require an exchange before the sending of encrypted packets, implies, on the other hand, an increase in the size of each packet. Indeed, an additional header, known as the SKIP header, is added to the IP datagrams; it is in particular used to transmit Kp (encrypted with Kij) and to indicate the algorithms used.
Extension for the property of perfect forward secrecy
The above protocol does not to provide perfect forward secrecy. Indeed, if Kij is discovered, all the session keys Kp used in the past are compromised. So, an extension to SKIP that guarantees this additional security was developed. It uses an "ephemeral" Diffie-Hellman key exchange, "ephemeral" meaning that the public values have a short life span. The ephemeral shared secret replaces the long-term shared secret from the traditional version of SKIP.
The use of an ephemeral Diffie-Hellman key exchange implies the exchange of certificates containing the corresponding public values. This exchange is done using CDP (Certificate Discovery Protocol) and uses the Kij key. Unlike the basic SKIP protocol, SKIP PFS thus requires the exchange of some messages between the parties before enabling them to exchange encrypted data.
SKIP PFS also provides identity protection, which was not guaranteed by SKIP.
Summary and bibliography
SKIP is an on-line key management protocol specifically designed to secure connectionless protocols like IP. It uses the Diffie-Hellman protocol, based on authenticated public values. The shared secret generated thanks to that protocol is used to encrypt session keys. A consequence is that SKIP does not provide perfect forward secrecy (PFS). An extension of SKIP was defined which provides PFS and anonymity, at the price of an additional exchange of certificates between the peers.
Bibliography on SKIP.
Developped since 1995 by Phil Karn from Qualcomm and William Simpson from DayDreamer, Photuris uses the same principle as the STS (Station-To-Station) protocol created by Diffie, Van Oorschot and Wiener [DOW92]. Photuris was described, independently from any working group, in several Internet drafts and RFCs, and is designed for use with IPsec. A few implementations use it, although IKE is much more common.
Contrary to SKIP, Photuris is a connection-oriented protocol in the sense that it is composed of a certain number of exchanges (for the negotiation of options and the generation of keys) preliminary to any exchange of encrypted messages. UDP port 468 was assigned to Photuris by the IANA.
Photuris is based on the generation of a shared secret thanks to Diffie-Hellman. This shared secret has a short life span: it is used to generate the session keys necessary to protect the rest of the communication. In order to counter the man-in-the-middle attack to which Diffie-Hellman is vulnerable, the exchange of the values being used to generate the shared secret is followed of an authentication of these values thanks to long-term secrets. As these long-term secrets are used only for authentication, Photuris provides perfect forward secrecy.
A problem with Diffie-Hellman is that it requires operations with a high cost in system resources, which makes it vulnerable to denial of service attacks called "flooding attacks". In order to make that type of attacks more difficult, Photuris uses a cookie exchange before carrying out the Diffie-Hellman values exchange. The value of the cookies depends on the involved parties, in particular via their IP addresses, and of the UDP port number. This aims at preventing an attacker from obtaining a valid cookie and using it to flood the victim with requests coming from arbitrary IP addresses and/or ports. In addition, it should not be possible, for an attacker, to generate cookies that will be accepted by an entity as generated by itself. This implies that the transmitting entity uses some local secret information in the generation of its cookies and in their later checking.
Photuris is composed of the three following stages:
A cookies exchange to counter some simple denial of service attacks. Each involved party generates a cookie and the cookies are transmitted with each message.
A public values exchange for the generation of a shared secret.
An identities exchange so that the parties are identified to one another and can check the authenticity of the values exchanged during the preceding stage. This exchange is protected in confidentiality thanks to private keys derived, among others, from the shared secret and the cookies.
Other messages can later be exchanged to modify the session keys or the security parameters. These messages will be protected in confidentiality in the same way as the messages from exchange 3.
Simultaneously with the above exchanges, the communicating peers agree on the method for shared secret generation and on some security parameters useful for the security association.
Summary and bibliography
Photuris is an on-line protocol, which uses a Diffie-Hellman shared secret generation, followed of an authentication of the public values used, to establish a session key. Photuris introduces the concept of cookie, a mechanism that makes it possible to counter some denial of service attacks. The protocol is composed of three phases: cookies exchange, public values exchange and identities exchange.
Bibliography on Photuris.
Developed specifically for IPsec, SKEME is an extension of Photuris suggested in 1996 by Hugo Krawczyk of the IBM T. J. Watson Research Center. Contrary to Photuris, which imposes a precise course for the protocol, SKEME provides various modes of key exchange.
Like STS and Photuris, SKEME's basic mode is based on the use of public keys and a Diffie-Hellman shared secret generation. However, SKEME is not restricted to the use of public keys, but also allows the use of a pre-shared key. This key can be obtained by manual distribution or by the intermediary of a key distribution center (KDC) such as Kerberos. The KDC enables the communicating peers to share a secret by the intermediary of a trusted third party. The use of this secret for the authentication of the Diffie-Hellman secret and not directly as a session key decreases the necessity of trust in the KDC. Lastly, SKEME also makes it possible to carry out faster exchanges by not using Diffie-Hellman when perfect forward secrecy is not required.
In short, SKEME contains four distinct modes:
Basic mode, which provides a key exchange based on public keys and ensures PFS thanks to Diffie-Hellman.
A key exchange based on the use of public keys, but without Diffie-Hellman.
A key exchange based on the use of a pre-shared key and on Diffie-Hellman.
A mechanism of fast rekeying based only on symmetrical algorithms.
In addition, SKEME is composed of three phases: SHARE, EXCH and AUTH.
During the SHARE phase, the peers exchange half-keys, encrypted with their respective public keys. These two half-keys are used to compute a secret key K. If anonymity is wanted, the identities of the two peers are also encrypted. If a shared secret already exists, this phase is skipped.
The exchange phase (EXCH) is used, depending on the selected mode, to exchange either Diffie-Hellman public values or nonces. The Diffie-Hellman shared secret will only be computed after the end of the exchanges.
The public values or nonces are authenticated during the authentication phase (AUTH), using the secret key established during the SHARE phase.
The messages from these three phases do not necessarily follow the order described above; in actual practice they are combined to minimize the number of exchanged messages.
Another phase, known as the COOKIES phase, can be added before the SHARE phase to provide protection against denial of service attacks thanks to the cookies mechanism introduces by Photuris.
Summary and bibliography
SKEME is a connection-oriented protocol which provides four key exchange modes and is composed of three phases: share, exchange and authentication. SKEME can also use the cookies mechanism from Photuris.
Bibliography on SKEME.
Initially proposed by Hilarie Orman from the computer department of the university of Arizona, Oakley has been the subject of several Internet drafts within the IPsec group and is, with ISAKMP and SKEME, at the base of IPsec's key exchange.
Actually, Oakley's goal is to allow the peers to securely share a set of parameters for the protection of the exchanges: name of the key, secret key, identities of the peers, encryption algorithms, authentication and hash functions.
Several options are available in Oakley. In addition to the traditional Diffie-Hellman key exchange, Oakley can be used to derive a new key from an old one or to distribute a key by encrypting it. These options result in the existence of several modes.
The main principle of Oakley is that the initiator of the exchanges starts by specifying as much information than he wishes in his first message. His interlocutor answers by also providing as much information than he wishes. The conversation goes on until the required state is reached. The choice of the quantity of information to include in each message depends on the selected options (use of stateless cookies, identity protection, PFS, non-repudiation ...).
The three components of the protocol are:
cookies exchange (optionally stateless),
Diffie-Hellman public values exchange (optional),
Authentication (options: anonymity, PFS on the identities, non-repudiation).
Summary and bibliography
Oakley is a lot like SKEME, and additionally proposes the possibility to negotiate a set of parameters.
Oakley is described in [RFC 2412].
3.3. Key management for IPsec: ISAKMP and IKE
IKE (Internet Key Exchange) is a protocol developed specifically for IPsec which aims at providing authentication and key exchange mechanisms adapted to most of the situations which can occur on the Internet. It is composed of several elements: a framework called ISAKMP and parts of the Oakley and SKEME protocols. When it is used for IPsec, IKE is associated to the IPsec Domain of Interpretation (DOI).
We saw, at the beginning of this presentation, that using security services means using security associations to manage the necessary parameters (keys, protocols ...). ISAKMP (Internet Security Association and Key Protocol Management) is designed to negotiate, establish, modify and delete security associations and their attributes.
Mechanisms independence: domain of interpretation and phases
ISAKMP is a generic framework which does not dependent on the mechanisms in favor of which the negotiation takes place. Indeed, ISAKMP can be used to negotiate, in the form of security associations, the parameters relating to any security mechanism: IPsec, TLS ... It is designed to support SA negotiation for any protocol of the IP level or any upper layer.
This is possible thanks to the way in which the negotiations take place. First of all, ISAKMP is designed to work independently of the security mechanisms: the data related to the key management is transported separately. ISAKMP can be implemented directly above IP, or above any transport layer protocol. In particular, it was assigned UDP port 500 by the IANA.
Secondly, ISAKMP defines a framework to negotiate security associations, but it does not impose anything about the parameters that compose them. A document, called Domain of Interpretation (DOI) must define the negotiated parameters and the conventions to use ISAKMP within a specific framework. A DOI identifier is used to interpret the content of the ISAKMP messages. [RFC 2407] defines the IPsec DOI. More details about this document will be given in the following chapter.
Lastly, ISAKMP has two phases, which allow for a clear separation between ISAKMP traffic protection and SA negotiation for a given protocol:
During the first phase, a set of security related attributes is negotiated, the identities of the peers are authenticated and some keys are generated. These elements constitute a first security association, known as the ISAKMP SA. Contrary to IPsec SAs, an ISAKMP SA is bi-directional. It will be used to secure all the following ISAKMP exchanges.
The second phase is used to negotiate the security parameters related to a SA to establish for a given security mechanism (for example AH or ESP). The exchanges from this phase are protected (confidentiality, authenticity ...) thanks to the ISAKMP SA. The ISAKMP SA can of course be used to negotiate several phase 2 SAs.
The ISAKMP SA parameters can be specific to ISAKMP only, or they can contain some elements specific to a given security protocol and defined in the corresponding DOI. In the first case, the security association is said to be a generic ISAKMP SA, and it can be used to negotiate SAs for any security protocol. In the second case, the ISAKMP SA can only be used to negotiate SAs which dependent on the same DOI.
Key management protocol independence: construction of the messages by payloads
ISAKMP is also independent of the key generation method, authentication and encryption algorithms used. It is thus independent of any key exchange protocol, which makes it possible to clearly separate the details from security associations' management and the details of the key exchange. Various key exchange protocols, presenting different properties can thus be used with ISAKMP.
This is possible because ISAKMP does not impose a fixed course, based on the definition of a limited set of messages. ISAKMP is rather some kind of construction kit, since ISAKMP messages consist of a header followed by a variable number of payloads. These payloads are ISAKMP's building blocks.
Each ISAKMP message starts with a header of fixed length. It includes two cookies, the initiator cookie and the responder cookie, which, in addition to the traditional anti-clogging role, make it possible to identify the ISAKMP security association in progress (contrary to IPsec SAs, it is not identified by a SPI).
A field called Exchange Type indicates the type of exchange in progress (see further) and thus the organization and the number of messages.
The ISAKMP header also includes a field, Next Payload, which indicates the type of the first payload in the message. Each payload starts in turn with its own header, which indicates its length and the type of the following payload. The last payload of the message indicates 0 for the following payload's type. The construction of ISAKMP messages thus uses payload chaining.
The main document on ISAKMP defines 13 different payloads:
The Security Association (SA) payload is used to negotiate the security attributes.
In itself, it contains a field that indicates the context of the negotiation (DOI and situation). The situation is a parameter which depends on the DOI and which indicate which type of security policy one wishes to use. A value of 0 for the DOI during phase 1 indicates that a generic SA ISAKMP is being negotiated. A value of 1 indicates the IPsec DOI.
A SA payload is always followed of one or more Proposal payloads to make proposals (presented by order of preference) to the interlocutor.
Each Proposal payload constitutes a proposal for a set of security association attributes.
In itself, the Proposal payload indicates the proposed security mechanism (AH, ESP ...) as well as the SPI to be associated with the resulting SA if this proposal is adopted. As it is possible to leave the choice to the interlocutor by making several proposals, each Proposal payload is numbered. When several proposals constitute a set (for example if one wants to negotiate a protection by AH + ESP), they have the same number and will result in the creation of a SA bundle.
A P payload is always followed of one or more Transform payloads, which are used to specify the attributes chosen for the concerned SA.
Each Transform payload indicates a transformation (encryption algorithm, hash function ...) and its attributes. These elements depend, of course, on the DOI and the security mechanism selected in the preceding payloads.
The Transform payloads are also numbered: if two blocks carry the same number, they form a set and must be selected together; payloads with different numbers indicate a choice possibility.
These first three types of payloads are not independent and can be considered as imbricated. As a consequence, a set of SA, P and T payloads is often represented by just SA.
- Figure 10. Organization of the SA, P and T payloads -
The set represented in the above drawing could be a set of proposals sent by a peer to another. The recipient of this message must answer by an identical set in which he keeps only the chosen proposal (or group of proposals). The security association (or bundle of security associations) resulting from this negotiation will be assigned the SPI of the adopted proposal.
The Key Exchange payload is used to transport the data necessary to the generation of the session key. Its interpretation depends on the DOI and on the selected key exchange protocol.
The Identification payload is used to transport the data necessary to the identification of the peers. Its interpretation depends on the DOI.
A field entitled ID Type indicates the type of identification data contained in the payload. For ISAKMP this can be an IP address (IPv4 or IPv6) or a range of IP addresses (addresses/netmask). Each DOI can define additional types of identification.
The Certificate payload provides a means of transporting certificates or all other information related to the certificates.
A field entitled Certificate Encoding indicates the type of certificate (or data related to the certificates) contained in the field Certificate Data. The currently defined types are:
- PKCS #7 wrapped X.509 certificate
- PGP certificate
- DNS signed key
- X.509 certificate - signature
- X.509 certificate - key exchange
- Kerberos tokens
- Certificate revocation list (CRL)
- Authority revocation list (ARL)
- SPKI certificate
- X.509 certificate - attribute
The Certificate Request payload enables a peer to request a certificate.
As in the preceding payload, a field indicates the type of certificate requested. A second field, Certificate Authority, contains the references of an acceptable certification authority. This field is optional.
The Hash payload contains the result of the application of the previously selected hash function to all or part of the message or to a given state variable.
This payload can be used to check the authenticity of an ISAKMP message.
In the same way, the Signature payload contains the result of the application of a previously selected digital signature function to all or part of the message or to a given state variable.
The use is the same one as for the Hash payload.
The Nonce payload is used to transport nonces.
The Notification payload is used to convey information or error messages concerning the current status of the negotiations. Its interpretation depending on the DOI, the DOI is indicated at the beginning of the payload.
The beginning of the payload also contains the references of the concerned security association (mechanism and SPI). The message is composed of two fields: Notify Message Type and Notification Data (optional).
The Delete payload enables the transmitter to announce that he has just removed a security association and that it is thus no longer valid.
A single payload can be used to notice the deletion of several SAs, provided they all use the same mechanism.
In ISAKMP, the modification of a SA is done by creating a new SA and then removing the old one.
The Vendor ID payload can be used to enable two instances of an implementation to recognize one another and be able to use elements specific to this implementation and not in conformity with the standards.
Interoperability and guidelines: exchange types
Using these payloads, ISAKMP defines exchange types. An exchange type is a specification of the set of messages composing a given exchange type. Each exchange type is conceived to provide a certain number security services, like anonymity, perfect forward secrecy, mutual authentication ... The reference document on ISAKMP, [RFC 2408], defines, to ensure interoperability and indicate how the ISAKMP payloads should be used within the framework of a given negotiation, default exchange types. Other exchange types can of course be defined, depending on the key exchange protocol and DOI in use. In addition, several proposals for additional exchange types have been proposed in separate Internet drafts.
The current ISAKMP specification contains five exchange types: Base Exchange, Identity Protection Exchange, Authentication-Only Exchange, Aggressive Exchange, Informational Exchange. Only the last one is mandatory. All these exchanges can be used either during phase 1, or during phase 2. In the descriptions below, we will use the following notations:
||Security Association Payload
||Key Exchange Payload
||Authentication Payload (HASH or SIG)
||Means that the message is encrypted
- Figure 11. Notations for the ISAKMP exchanges -
The Base Exchange is designed to allow the key exchange and authentication-related information to be transmitted together. Combining the key exchange and identity information into one message reduces the number of round-trips at the expense of not providing identity protection. Indeed, the identities are exchanged before a shared secret has been established and, therefore, they can not be encrypted.
The data exchanged during messages 3 and 4 are protected, thanks to an AUTH payload, by the authentication function selected during the negotiation conducted thanks to messages 1 and 2.
The Identity Protection Exchange is designed to separate the key exchange information from the identity and authentication-related information, thus providing protection of the communicating identities at the expense of two additional messages. Indeed, the identities are exchanged under the protection of a previously-established shared secret.
The Authentication Only Exchange is designed to allow only authentication-related information to be transmitted. The benefit of this exchange is the ability to perform only authentication without the computational expense of computing keys. This exchange is particularly useful during the second phase, where it will be protected by the security services negotiated during the first phase.
The Aggressive Exchange is designed to allow the security association, key exchange and authentication-related payloads to be transmitted together. This reduces the number of round-trips at the expense of not providing identity protection. Additionally, there can be only one Proposal and one Transform offered (i.e. no choices) in order for the aggressive exchange to work.
The Informational Exchange is designed as a one-way transmittal of information that can be used for security association management. It uses either a Notification payload, or a Delete payload. This message is only protected by the ISAKMP SA if it has been established.
Summary and bibliography
ISAKMP lays the basis for the construction of various key (and more generally security associations) negotiation protocols. Its main characteristics are:
It defines a way of proceeding, in two stages called phase 1 and phase 2: during phase 1, some security parameters specific to ISAKMP are set up, in order to establish a secure channel between the peers; during phase 2, this channel is used to negotiate security associations for the security mechanisms one wishes to use (AH or ESP for example).
It supplies the basic syntax of messages, through payload types that have a precise role.
It defines some exchange types, composed of such messages, which present different properties: identity protection, perfect forward secrecy...
ISAKMP is described in [RFC 2408].
3.3.2. IPsec DOI
ISAKMP defines a framework for negotiating security associations, but does not impose anything concerning the parameters that compose them. A document entitled "Domain of Interpretation" (DOI) defines the negotiated parameters and the conventions for using ISAKMP within a precise framework. A DOI identifier is used to interpret the contents of the ISAKMP messages. [RFC 2407] defines the DOI for using ISAKMP with IPsec.
SA payload: situation
Used in the SA payload, the situation field specifies the situation under which the negotiation must take place. The IPsec DOI defines three different situations:
- Identity only, which imposes an identification of the peers through an ID payload.
- Secrecy, which allows the use of confidentiality level indicators.
- Integrity, which allows the use of integrity level indicators.
The IPsec DOI also defines additional fields in the SA payload to transport the situation-related data: confidentiality level, integrity level...
P payload: security protocol
The protocols (or mechanisms) which are part of the IPsec DOI framework are:
ISAKMP (for a phase 1 negotiation with the IPsec DOI, instead of generic ISAKMP)
IPCOMP is a data compression protocol that works at the IP level. As data encryption renders any later compression ineffective, it can be interesting to compress the data before encrypting it.
T payload: transform and attributes
For each of the four protocols mentioned above, it is possible to use various transforms; the Transform payload makes it possible to choose among these transforms.
For ISAKMP, this method makes it possible to choose the key exchange protocol to be used. The only possible choice within the IPsec framework is IKE.
The AH transforms are MD5, SHA and DES. The choice of one of these transforms is completed through the SA Attributes field of the Transform payload, by the reference of the algorithm to use. Which gives four possibilities: HMAC-MD5, KPDK-MD5, HMAC-SHA and DES-MAC.
The ESP transforms are DES_IV32, DES_IV64 (DES in CBC mode with an initialization vector of 32 or 64 bits respectively), DES (DES in CBC mode, needs to be specified thanks to attributes), 3DES (needs to be specified thanks to attributes), RC5, IDEA, CAST, BLOWFISH, 3IDEA, RC4 and NULL (to use ESP without data encryption).
Lastly, the transformations usable with IPCOMP are OUI (proprietary transform, needs to be specified thanks to attributes), DEFLATE, LZS and V42BIS.
In addition to the attributes mentioned above, it is possible to use various attributes to specify the group on which to carry out Diffie-Hellman, the SAs' life span, the key length for the algorithms with variable key lengths ... These elements are described in detail in [RFC 2407].
The IPsec DOI adds the fields Protocol ID (UDP, TCP ...) and Port to the ID payload, and defines the following modes of identification:
IPv4 address, IPv6 address
IPv4 or IPv6 sub-network (addresses/netmask)
Range of IPv4 or IPv6 addresses (first address - last address)
- FQDN (foo.bar.com)
- User FQDN (email@example.com)
- Binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501]
- binary DER encoding of an ASN.1 X.500 General Name [X.509]
KEY ID: vendor-specific information necessary to identify which pre-shared key should be used
3 new status messages are introduced:
Summary and bibliography
The IPsec DOI is a document which defines the negotiated parameters and the conventions related to using ISAKMP with Ipsec.
The IPsec domain of interpretation is described in [RFC 2407].
If the IPsec DOI specifies the content of the ISAKMP payloads within the framework of IPsec, IKE on the other hand uses ISAKMP to build a practical protocol. The key management protocol associated with ISAKMP to this end is inspired by both Oakley and SKEME. More exactly, IKE uses some of the modes defined by Oakley and borrows SKEME's use of public key encryption for authentication and its method of fast rekeying through nonces exchange. In addition, IKE does not depend on a particular DOI but can use any DOI.
IKE includes four modes: Main Mode, Aggressive Mode, Quick Mode and New Group Mode. Main Mode and Aggressive Mode are used during phase 1, Quick Mode is a phase 2 exchange. New Group Mode is a little apart: it is neither a phase exchange nor a phase 2 exchange, but it can take place only once an ISAKMP SA has been established; it is used to agree on a new group for future Diffie-Hellman exchanges.
Phase 1: Main Mode and Aggressive Mode
The following attributes are used by IKE and are negotiated during phase 1: an encryption algorithm, a hash function, an authentication method and a Diffie-Hellman group.
Three keys are generated at the end of phase 1: for encryption, for authentication and for the derivation of other keys. These keys depend on the cookies, the exchanged nonces and on the public Diffie-Hellman values or on the pre-shared secret. Their computation uses the hash function chosen for the ISAKMP SA and depends on the selected authentication mode. For the exact formulas, please see [RFC 2409].
Main Mode is an instantiation of the ISAKMP Identity Protection Exchange: it is composed of six messages, the first two being used to negotiate the SA, the next two for the exchange of Diffie-Hellman public values, and the last two for the authentication of these public values.
The first two messages provide IKE parameters negotiation: encryption algorithm, hash function, peer authentiation method and Diffie-Hellman group.
- Figure 12. Main Mode: first exchange example -
The four possible authentication methods are digital signature, two forms of authentication through public key encryption and the use of a pre-shared secret.
The two following messages enable the establishment of a shared secret through the use of the Diffie-Hellman protocol
- Figure 13. Main Mode: second exchange -
The shared secret is used to generate session keys, two of them being used to protect the following exchange with the encryption and hash algorithms previously negotiated.
The last two messages provide authentication of the exchanges, notably of the public values
- Figure 14. Main Mode: third exchange -
Aggressive Mode is an instantiation of the ISAKMP Aggressive Exchange: it is only composed of three messages.
In these two cases, the method selected for the authentication influences the content of the messages and the session key generation method. The four possible authentication methods are digital signature, two forms of authentication by public key encryption and the use of a pre-shared secret. [RFC 2408] details the messages exchanged in each case and the formulas for computing the signatures and hashes.
Phase 2: Quick Mode
The messages exchanged during phase 2 are protected (authenticity and confidentiality) thanks to the elements negotiated during phase 1. The authenticity of the messages is ensured by the addition of HASH payload after the ISAKMP header, and
confidentiality is ensured by the encryption of all the payloads of the message.
Quick Mode is used for the negotiation of security associations for security protocols like IPsec. Each negotiation leads in fact to two SAs, one in each direction of the communication.
More precisely, the exchanges composing this mode have the following role:
Negotiate a set of IPsec parameters (SA bundles)
Exchange random numbers, used to generate a new session key which derives from the secret generated during phase 1 using Diffie-Hellman. Optionally, it is possible to resort to a new Diffie-Hellman exchange, so as to get the Perfect Forward Secrecy property, which is not provided when generating a new key from the old one and the random numbers.
Identify the traffic that this SA bundle will protect, using selectors (optional IDi and IDr payloads: in their absence, the IP addresses of the peers are used).
The exchanges composing this mode are the following:
Or, in terms of messages composition by payloads:
Groups: New Group Mode
The group to be used for Diffie-Hellman can be negotiated, by the means of a SA payload, either during Main Mode, or later on thanks to New Group Mode. In both cases, there are two ways of indicating the group to be used:
Giving the reference of a preset group: there are currently four, the four Oakley groups (two MODP groups and two EC2N groups).
Giving the characteristics of the desired group: type of group (MODP, ECP, EC2N), prime or irreducible polynomial, generators...
Phases and modes
Finally, the course of an IKE negotiation follows the following diagram:
Summary and bibliography
Combination of ISAKMP, Oakley and SKEME, IKE (Internet Key Exchange) is the protocol for managing the security parameters used by Ipsec.
IKE includes several modes and options:
During phase 1, the negotiation of an ISAKMP SA can be done either in Main Mode (6 messages), or in Aggressive Mode (3 messages). Peer authentication can be done using a pre-shared secret, public key encryption or digital signature.
During phase 2, the IPsec SA negotiation uses Quick Mode, with or without the Perfect Forward Secrecy option.
IKE is described in [RFC 2409].
Initials and acronyms
||Association Française de Normalisation (French standardization association)
||Cipher Block Chaining
||Data Encryption Standard
||Domain Of Interpretation
||Encapsulating Security Payload
||Frequently Asked Questions
||Generic Security Service API
||a MAC mechanism based on cryptographic Hash functions
||Internet Assigned Numbers Authority
||Internet Control Message Protocol
||Integrity Check Value
||International Data Encryption Algorithm
||Internet Engineering Task Force
||Internet Key Exchange
||IP new generation
||IP Payload Compression Protocol
||IP security protocol
||IP version 4
||IP version 6
||Internet Security Association and Key Management Protocol
||International Standardization Organization
||Message Authentication Code
||Message Digest n
||Open Systems Interconnection
||Perfect Forward Secrecy
||Research and development in Advanced Communication technologies in Europe
||Rivest's Code n
||Request For Comments
||RACE Integrity Primitives Evaluation
||RIPE Message Digest
||Rivest, Shamir, Adleman
||Security Association Database
||Secure Hash Algorithm
||a Versatile Secure Key Exchange Mechanism for Internet
||Simple Key management for Internet Protocols
||Security Policy Database
||Security Parameter Index
||Secure Socket Layer
||Transmission Control Protocol
||Transport Layer Security
||Time To Live
||User Datagram Protocol
||Virtual Private Network
Cryptographic or encryption algorithm
Process or mathematical function used for encryption and decryption. In modern cryptography, the algorithm is often public and the secrecy depends on a parameter called key.
Observation of the external characteristics of the traffic going through a network, in order to try to gain information: transmission frequency, identities of the communicating peers, amount of data transferred. Combined with information of other origin (meeting date, news...) those elements can allow an opponent to make interesting deductions.
Security Association (SA)
Simplex (one-way) connection created to secure data exchanges. All the traffic which goes through a SA is protected by the same set of security services. A SA thus corresponds to a set of parameters, which characterize the services provided through mechanisms of security like AH and ESP.
See the chapters "The security association concept" and "3.3. Key management for IPsec: ISAKMP and IKE".
Term used in this document to indicate the security service which consists in ensuring both integrity anddata origin authentication.
There are two types of authentication:
- User authentification.
It is the action which consists in proving one's identity.
This service is generally provided by the use of an "authentication exchange", which implies a certain dialogue between the peers.
- Data origin authentication.
It is used to prove that the received data were indeed transmitted by the declared sender.
In this case, the word "authentication" often refers to the combination of two services: authentication and off-line integrity. Indeed, these two services do not make sense separately and are often provided jointly.
An implementation is said to be a bump-in-the-stack implementation if it is fits in between two layers of the protocol stack (for example, between PPP and the modem). The inserted code is perceived by the layer of row n as being that of row n-1 and reciprocally.
CAM - Voir Code d'authentification de message
Electronic document which contains the public key of an entity, as well as a certain number of information relating to it, such as its identity. This document is signed by a certification authority which has previously checked the information.
Encryption, to encrypt
Application of a cryptographic algorithm to a set of data called plaintext in order to obtain a ciphertext.
Encryption is a security mechanism which provides data confidentiality.
Key (secret, public, private)
Parameter of an encryption or decryption algorithm, on which the secret depends.
There are two types of keys:
Key encrypting key
Secret keys, used by symmetric algorithms, for which the encryption and decryption keys are similar/
the (public key, private key) couples, used by asymmetric algorithms, for which the encryption and decryption keys are distinct.
Key used exclusively for encrypting other keys, so as to send them to a peer. A key encrypting key generally has a long lifetime, in contrast with the keys it encrypts.
See the chapter "3.1.1. Keys hierarchy".
Key with a limited lifetime, generally the lifetime of a session.
Session keys are generally secret keys, used to encrypt transmitted data, and that the communicating peers generate at the beginning at the communication.
See the chapter "3.1.1. Keys hierarchy".
Key used to derive other keys.
See the chapter "3.1.1. Keys hierarchy".
Message Authentication Code (MAC)
Result of a secret key one-way hash function. The hash depends both on the data and on the key; it can only be computed by people knowing the key. Added to the data from which it was computed, it enables checking their authenticity (authentication + integrity).
Security service which consists in making sure that only the authorized people can have access to a set of data.
The mechanism which provides this service is generally data encryption with a cryptographic algorithm.
Traffic confidentiality is provided when preventing traffic analysis by hiding source and destination addresses, packets size, exchange frequency...
Relation logique établie entre deux entités.
Chaque couche réseau fournit aux couches supérieures un certain nombre de services dont certains sont dits sans connexion et d'autres orientés connexion. Dans un service sans connexion, chaque message est considéré comme totalement indépendant des autres et peut être envoyé à tout moment, sans procédure préalable et sans que le destinataire final soit nécessairement présent à ce moment. C'est le cas par exemple de IP, qui n'offre qu'un service de type remise de datagrammes. Dans un service orienté connexion, l'initiateur de la communication doit d'abord établir un lien logique avec l'entité avec laquelle il désire communiquer. Cette procédure est appelée ouverture de la connexion et implique généralement de se mettre d'accord sur un certain nombre d'options.
Security service enabling to determine, after user authentication, what its privileges are and apply them. This service aims at preventing unauthorized use is a resource (network, machine, data...)
Cryptanalysis or cryptographic analysis
Science which studies the security of the cryptographic processes to try to find weaknesses and notably perform decryption.
Also called ciphertext. Data obtained by applying an encryption algorithm. The semantic content of this data is not intelligible.
Scientific study of cryptography and cryptanalysis.
Denial of service
Fixed length string obtained by applying a hash function to a set of data.
A one-way function is a function which is easy to compute but difficult to reverse.
Public key cryptography relies on the use of one-way functions with a secret breach; for anyone knowing the secret (i.e. the private key), the function becomes easy to reverse.
Function which converts a string of any length into a smaller and fixed length string; this string is called digest of the initial string.
One-way hash function
ICV (Integrity Check Value)
See the chapter "2.2. Authentication Header (AH)".
See the chapter "Equipment providing IPsec".
Perfect Forward Secrecy (PFS)
Property of a key exchange protocol according to which, even if an opponent discovers the long term secret(s), he can not find the session keys.
See the chapter "3.1.4. Key exchange protocols properties".
Action consisting in sending a previously intercepted message, hoping it will be accepted as valid by the destination.
Virtual Private Network (VPN)
Within the network security scope, network composed of a set of hosts and devices which use specific protocols to secure their communications.
See the chapter "Equipment providing IPsec".
RFC (Request For Comment)
Security mechanism providing data integrity and data origin authentication.
Digest of a set of data, computed by the sender before sending the data and computed again by the receiver to check data integrity.
SPI (Security Parameter Index)
32 bits block which, combined with a destination address and the security protocol name (AH, ESP), uniquely identifies a security association (SA). The SPI is transported in any packet, to enable the receiver to select the SA which will be used to process the packet. The SPI is chosen by the receiver upon SA creation.
See the chapter "The security association concept".
Also called cryptogram.
Data obtained by applying an encryption algorithm. The semantic content of this data is not intelligible.
Intelligible data, of which the semantic is understandable.
Technic consisting of creating a "tunnel" between two network devices by transforming packets at one end (generally encapsulation in an appropriate protocol) and reconstructing them at the other end.
Initialization Vector (IV)
Block used to initialize a cipher block chaining encryption, making sure that two identical messages give different cryptograms.
This bibliography lists the main documents used in the making of this presentation, classified by theme. The index enables finding a document from its reference.
Most of the documents listed below are available online. For instance, the RFCs can be found on numerous FTP sites (for example ftp://ftp.normos.org/ietf/rfc/) and Internet drafts on the IETF site (http://www.ietf.org). The address at which an article can be found is given when this article is available online. The Cryptography Author Sites page by Cryptography Research (http://www.cryptography.com/resources/authors/index.html) lists many authors' web pages, providing access to numerous articles.
Schneier Bruce, Cryptographie appliquée - Algorithmes, protocoles et codes source en C - 2ème édition, International Thomson Publishing France, 1997.
This book is a translation, the original title being
Applied Cryptography - Protocols, Algorithms, and Source Code in C - 2nd Edition.
Reference book on modern cryptography.
[RSA - FAQ]
RSA Laboratories, Frequently Asked Questions About Today's Cryptography - Version 4.1, 2000.
Quick presentation of numerous cryptography concepts, in FAQ form.
Labouret Ghislaine, Introduction à la cryptologie, document de synthèse personnel, 1998.
Message authentication codes
Tsudik Gene, Message Authentication with One-Way Hash Functions, ACM Computer Communication Review, Vol. 22, pp. 29-38, 1992.
Secret prefix, secret suffix and secret envelop methods.
Krawczyk Hugo, Bellare Mihir, Canetti R, HMAC: Keyed-Hashing for Message Authentication, RFC 2104, février 1997.
Diffie Whitfield, Van Oorschot Paul C., Wiener Michael J., Authentication and Authenticated Key Exchanges, Designs, Codes and Cryptography, 2, pp. 107-125, Kluwer Academic Publishers, 1992.
Key exchange and mutual authentication protocols: definition of a secure protocol, requested properties for such protocols, presentation of the STS protocol.
Network and data exchange security
Oppliger Rolf, Internet and Intranet Security, Artech House, 1998 (seconde édition en 2002).
Available from amazon.fr
International Standardization Organization, Systèmes de traitement de l'information : interconnexion de systèmes ouverts - Modèle de référence de base - Partie 2 : architecture de sécurité, NOR Z 70-102 (NF ISO 7498-2), AFNOR, 1989.
Available from AFNOR
The IPsec presentation in this document is based on the November 1998 RFCs by the IETF IPsec group.
Thayer Rodney, Doraswamy Naganand, Glenn R., IP Security Document Roadmap, RFC 2411, November 1998.
This document explains the organization of the IPsec docuemnts.
Here is a reproduction of this organization:
- Figure 12. Organization of the IPsec documents -
Atkinson Randall, Kent Stephen, Security Architecture for the Internet Protocol, RFC 2401, November 1998.
Presentation of the Ipsec architecture.
Kent Stephen, Atkinson Randall, IP Authentication Header, RFC 2402, November 1998.
Kent Stephen, Atkinson Randall, IP Encapsulating Security Payload (ESP), RFC 2406, November 1998.
Metzger P., Simpson W., IP Authentication using Keyed MD5, RFC 1828, August 1995.
Metzger P., Simpson W., IP Authentication using Keyed SHA, RFC 1852, September 1995.
Madson C., Glenn R., The Use of HMAC-MD5-96 within ESP and AH, RFC 2403, November 1998.
Madson C., Glenn R., The Use of HMAC-SHA-1-96 within ESP and AH, RFC 2404, November 1998.
Provos Niels, Keromytis Angelos, The Use of HMAC-RIPEMD-160-96 within ESP and AH, RFC 2857, June2000.
Karn P., Metzger P., Simpson W., The ESP DES-CBC Transform, RFC 1829, August1995.
Doraswamy Naganand, Madson C., The ESP DES-CBC Cipher Algorithm With Explicit IV, RFC 2405, November 1998.
Adams R., Pereira R., The ESP CBC-Mode Cipher Algorithms, RFC 2451, November 1998.
CAST-128, RC5, IDEA, Blowfish, triple DES
Kent Stephen, Glenn R., The NULL Encryption Algorithm and Its Use With IPsec, RFC 2410, November 1998.
SKIP development is performed by Sun Microsystems
Aziz Ashar, Markson Tom, Prafullchandra Hemma, Simple Key-Management for Internet Protocols (SKIP), Sun Microsystems Laboratories, April 1997.
Technical specifications of SKIP; this document reproduces the SKIP Internet draft, which expired in 1997.
Aziz Ashar, Markson Tom, Prafullchandra Hemma, Simple Key-Management for Internet Protocols (SKIP), Internet Draft, expired, August 1996.
The latest SKIP Internet draft
Aziz Ashar, SKIP Extension for Perfect Forward Secrecy (PFS), Sun Microsystems Laboratories, February 1998.
Extension to SKIP to provide PFS.
Simpson W. A., Karn Phil, Photuris: Session-Key Management Protocol, RFC 2522, March 1999.
Simpson W. A., Karn Phil, Photuris: Extended Schemes and Attributes, RFC 2523, March 1999.
Krawczyk Hugo, SKEME: A Versatile Secure Key Exchange Mechanism for Internet, Symposium on Network and Distributed System Security, February 1996.
Maughan Douglas, Schertler Mark, Schneider Mark, Turner Jeff, Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408, November 1998.
Orman Hilarie, The OAKLEY Key Determination Protocol, RFC 2412, November 1998.
Harkins D., Carrel D., The Internet Key Exchange (IKE), RFC 2409, November 1998.
IKE = ISAKMP/Oakley
Piper Derrell, The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407, November 1998.
Ferguson Niels, Schneier Bruce, A Cryptographic Evaluation of IPsec, December 1999.
Bellovin Steven M., Probable Plaintext Cryptanalysis of the IP Security Protocols, Proceedings of the Symposium on Network and Distributed System Security, pp. 155-160, February 1997.
Bellovin Steven M., Problem Areas for the IP Security Protocols, Proceedings of the Sixth Usenix Unix Security Symposium, pp. 1-16, July 1996.