Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Articles > IPsec: a technical overview
Go to: HSC Trainings
Version française
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o Training courses
o E-learning
o Agenda
o Past events
o Tutorials
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
o HSC Newsletter
o Press review
o Press releases
o Publications
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|IPsec: a technical overview  
> Access to the content HTML Beginning of the article
PDF PDF version [270KB]  
> Description A technical paper giving an overview of the IPsec standard.  
> Context & Dates Internal study.
Initial version on 7 December 1998.
Last revised on 16 juin 2000  
> Author Ghislaine Labouret  
> Type  
> Abstract &
Table of content
1. Overview
1.1. Structure of IPsec
AH and ESP mechanisms
The security association concept
Keys and security associations management
Security policies
1.2. Principle of operation
1.3. Possible types of uses
Equipment providing IPsec
Operating modes
2. Security mechanisms: AH and ESP
2.1. Reminder on security services and associated mechanisms
Authentication and integrity
2.2. Authentication Header (AH)
2.3. Encapsulating Security Payload (ESP)
3. Key management
3.1. General concepts regarding key management
3.1.1. Keys hierarchy
3.1.2. Public key infrastructures
3.1.3. Key exchange and authentication
3.1.4. Key exchange protocols properties
3.1.5. Diffie-Hellman
3.2. Authenticated key exchange protocols developed for IP
3.2.1. SKIP
3.2.2. Photuris
3.2.3. SKEME
3.2.4. Oakley
3.3. Key management for IPsec: ISAKMP and IKE
3.3.1. ISAKMP
3.3.2. IPsec DOI
3.3.3. IKE
Initials and acronyms


Commented bibliography
Networks and exchanges security
> Related documents
dir  Documents Documents on IPsec @hsc.fr [French/English]
[Course]  IPsec
[Course]  Data Exchanges Security: IPsec, SSL, SSH
[Presentation]  Feedback from the ETSI IPsec over IPv6 Interoperability Tests [6 December 2002 - English]
[Presentation]  IPsec Interoperability [28 March 2002 - French]
[Techno-watch]  IPsec 2001 [29 October 2001 - French]
dir  IPsec 2001 - IKE Interoperability Demonstrations and Tests [October 2001 - French/English]
[Presentation]  IP VPN with IPsec tunnels [12 September 2001 - French]
[Presentation]  IP filtering and IPsec in Windows 2000 [7 September 2001 - French]
[Presentation]  IPsec Overview [20 June 2001 - English]
[Presentation]  IPsec interoperability [6 March 2001 - French]
[Tip]  How to configure an IPsec tunnel on an agency Cisco router, with dynamic addressing and an ISDN line [5 December 2000 - French]
dir  IPsec 2000 - IKE Interoperability Demonstrations and Tests [November 2000 - French/English]
[Presentation]  The Different OpenSource Implementations of IPsec [27 October 2000 - English]
[Presentation]  Network encryption: IPsec, SSL, SSH [26 September 2000 - English]
[Presentation]  Network Encryption: IPsec, SSL, SSH [26 April 2000 - French/English]
[Presentation]  IPsec: from Fundamentals to the IKE Protocol [21 March 2000 - English]
[Presentation]  Directories, PKIs, IPsec VPNs and certificates: global security at last? [13 March 2000 - French]
[Presentation]  Network Security with Linux: SSL, IPsec, SSH [1 February 2000 - French]
[Presentation]  Résultats de tests d'interopérabilité IPsec réalisés par HSC [29 October 1999 - English]
[Presentation]  Dynamic Management of the IPsec Parameters: The IKE Protocol [27 October 1999 - English]
[Presentation]  Encrypted tunnels with Linux [18 June 1999 - French]
[Presentation]  Network security with IPsec [3 June 1999 - French]
[Article]  Network Security with IPsec [March 1999 - French]
[Presentation]  Key management for IPsec [14 January 1999 - French]
[Presentation]  IPsec and key management [3 November 1998 - French]
> Copyright © 1998-2000, Hervé Schauer Consultants, all rights reserved.



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.

1. Overview

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".

Security policies

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).

Operating modes

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

ESP can ensure data confidentiality and/or authenticity

> ESP is described in the document entitled "IP Encapsulating Security Payload (ESP)", whose last version is [RFC 2406].
> The authentication algorithms for use with ESP are described in the same documents as for AH.
> The encryption algorithms for use with ESP are listed in the IPsec DOI [RFC 2407] and are detailed in various documents.

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.

3.1.5. Diffie-Hellman

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:

  1. Alice and Bob agree on a large prime n and on g such that g is primitive modulo n. These two integers are public.
  2. 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.
  3. Alice sends A to Bob; Bob sends B to Alice.
  4. 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:

  1. 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.
  2. Bob sends his public value to Alice; Ingrid also replaces this value by hers.
  3. Alice generates the "secret" KAI=Ia mod n. Ingrid generates the same secret by computing Ai mod n.
  4. 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.

3.2.1. SKIP

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 Point.


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.

3.2.2. Photuris


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:

  1. 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.
  2. A public values exchange for the generation of a shared secret.
  3. 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.

3.2.3. SKEME


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.

3.2.4. Oakley

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.

Oakley is a key exchange protocol that has a lot in common with SKEME: it also has several modes, uses cookies and does not require the computation of the Diffie-Hellman shared secret before the end of the protocol. It differs from the previous protocols by the fact that it explicitly enables the peers to agree on the key exchange, encryption and authentication mechanisms to use.

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:

  1. cookies exchange (optionally stateless),
  2. Diffie-Hellman public values exchange (optional),
  3. 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).

3.3.1. ISAKMP

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:

Name Initials
Security Association SA
Proposal P
Transform T
Key Exchange KE
Identification ID
Certificate CERT
Certificate Request CR
Signature SIG
Notification N
Delete D
Vendor ID VID
  • 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:

SA Security Association Payload
KE Key Exchange Payload
ID Identity Payload
AUTH Authentication Payload (HASH or SIG)
NONCE Nonce Payload
* 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.

    Base exchange

    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.

    Identity Protection Exchange

  • 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.

    uthentication Only Exchange

  • 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.

    Aggressive Exchange

  • 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.

    Informational Exchange

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)
  • AH
  • ESP
    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].

ID payload

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 (user@foo.bar.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

N payload

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].

3.3.3. IKE

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.

    Main Mode: first exchange example
    - 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

    Main Mode: second exchange
    - 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

    Main Mode: third exchange
    - 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:

Quick Mode

Or, in terms of messages composition by payloads:

Quick Mode

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:

Phases and modes

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

3DES Triple DES
AFNOR Association Française de Normalisation (French standardization association)
AH Authentication Header
CBC Cipher Block Chaining
DES Data Encryption Standard
DH Diffie-Hellman
DOI Domain Of Interpretation
ESP Encapsulating Security Payload
FAQ Frequently Asked Questions
GSS-API Generic Security Service API
HMAC a MAC mechanism based on cryptographic Hash functions
IANA Internet Assigned Numbers Authority
ICMP Internet Control Message Protocol
ICV Integrity Check Value
IDEA International Data Encryption Algorithm
IETF Internet Engineering Task Force
IKE Internet Key Exchange
IP Internet Protocol
IPng IP new generation
IPPCP IP Payload Compression Protocol
IPsec IP security protocol
IPv4 IP version 4
IPv6 IP version 6
ISAKMP Internet Security Association and Key Management Protocol
ISO International Standardization Organization
IV Initialization Vector
MAC Message Authentication Code
MDn Message Digest n
OSI Open Systems Interconnection
PFS Perfect Forward Secrecy
RACE Research and development in Advanced Communication technologies in Europe
RCn Rivest's Code n
RFC Request For Comments
RIPE RACE Integrity Primitives Evaluation
RIPE-MD RIPE Message Digest
RSA Rivest, Shamir, Adleman
SA Security Association
SAD Security Association Database
SHA Secure Hash Algorithm
SKEME a Versatile Secure Key Exchange Mechanism for Internet
SKIP Simple Key management for Internet Protocols
SPD Security Policy Database
SPI Security Parameter Index
SSH Secure SHell
SSL Secure Socket Layer
TCP Transmission Control Protocol
TLS Transport Layer Security
TTL Time To Live
UDP User Datagram Protocol
VPN 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.

Traffic analysis

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:

  • 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 encrypting key

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".

Session key

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".

Master key

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.

Access control

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.


One-way function

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.

Hash function

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)".






Security gateway

> 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.

Digital signature


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.

Commented bibliogrpahy

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 Laboratories, Frequently Asked Questions About Today's Cryptography - Version 4.1, 2000.

o http://www.rsa.com/

> Quick presentation of numerous cryptography concepts, in FAQ form.


Labouret Ghislaine, Introduction à la cryptologie, document de synthèse personnel, 1998.

o http://www.labouret.net/crypto/

Message authentication codes


Tsudik Gene, Message Authentication with One-Way Hash Functions, ACM Computer Communication Review, Vol. 22, pp. 29-38, 1992.

o http://www.ics.uci.edu/~gts/paps/t92.ps.gz

> Secret prefix, secret suffix and secret envelop methods.

[RFC 2104]

Krawczyk Hugo, Bellare Mihir, Canetti R, HMAC: Keyed-Hashing for Message Authentication, RFC 2104, février 1997.


Key exchange


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).

o Available from amazon.fr

[ISO 7498-2]

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.

o Available from AFNOR


The IPsec presentation in this document is based on the November 1998 RFCs by the IETF IPsec group.

[RFC 2411]

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 -


[RFC 2401]

Atkinson Randall, Kent Stephen, Security Architecture for the Internet Protocol, RFC 2401, November 1998.

> Presentation of the Ipsec architecture.

AH protocol

[RFC 2402]

Kent Stephen, Atkinson Randall, IP Authentication Header, RFC 2402, November 1998.

Protocole ESP

[RFC 2406]

Kent Stephen, Atkinson Randall, IP Encapsulating Security Payload (ESP), RFC 2406, November 1998.

Authentication algorithms

[RFC 1828]

Metzger P., Simpson W., IP Authentication using Keyed MD5, RFC 1828, August 1995.

> Keyed-MD5

[RFC 1852]

Metzger P., Simpson W., IP Authentication using Keyed SHA, RFC 1852, September 1995.

> Keyed-SHA

[RFC 2403]

Madson C., Glenn R., The Use of HMAC-MD5-96 within ESP and AH, RFC 2403, November 1998.

[RFC 2404]

Madson C., Glenn R., The Use of HMAC-SHA-1-96 within ESP and AH, RFC 2404, November 1998.

[RFC 2857]

Provos Niels, Keromytis Angelos, The Use of HMAC-RIPEMD-160-96 within ESP and AH, RFC 2857, June2000.

Encryption algorithms

[RFC 1829]

Karn P., Metzger P., Simpson W., The ESP DES-CBC Transform, RFC 1829, August1995.

[RFC 2405]

Doraswamy Naganand, Madson C., The ESP DES-CBC Cipher Algorithm With Explicit IV, RFC 2405, November 1998.

[RFC 2451]

Adams R., Pereira R., The ESP CBC-Mode Cipher Algorithms, RFC 2451, November 1998.

> CAST-128, RC5, IDEA, Blowfish, triple DES

[RFC 2410]

Kent Stephen, Glenn R., The NULL Encryption Algorithm and Its Use With IPsec, RFC 2410, November 1998.

Key management


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.


[RFC 2522]

Simpson W. A., Karn Phil, Photuris: Session-Key Management Protocol, RFC 2522, March 1999.

[RFC 2523]

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.

o http://www.isoc.org/conferences/ndss96/krawczyk.ps


[RFC 2408]

Maughan Douglas, Schertler Mark, Schneider Mark, Turner Jeff, Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408, November 1998.


[RFC 2412]

Orman Hilarie, The OAKLEY Key Determination Protocol, RFC 2412, November 1998.

> Oakley

[RFC 2409]

Harkins D., Carrel D., The Internet Key Exchange (IKE), RFC 2409, November 1998.

> IKE = ISAKMP/Oakley

Domaine d'interprétation

[RFC 2407]

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.

o http://www.counterpane.com/ipsec.html


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.

o  http://www.research.att.com/


Bellovin Steven M., Problem Areas for the IP Security Protocols, Proceedings of the Sixth Usenix Unix Security Symposium, pp. 1-16, July 1996.

o  http://www.research.att.com/

Last modified on 6 November 2007 at 16:25:10 CET - webmaster@hsc.fr
Information on this server - © 1989-2013 Hervé Schauer Consultants