Rfc isakmp pdf

Random information which is used to guarantee liveness and protect against replay attacks is also transmitted.

Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. In the second message 2 , the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Again, random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Local security policy dictates the action of the responder if no proposed protection suite is accepted.

One possible action is the transmission of a Notify payload as part of an Informational Exchange. In the third 3 and fourth 4 messages, the initiator and responder, respectively, exchange keying material used to arrive at a common shared secret and identification information.

This information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action if an error occurs during these messages. Separating the Key Exchange from the Identity and Authentication related information provides protection of the communicating identities at the expense of two additional messages.

Identities are exchanged under the protection of a previously established common shared secret. The following diagram shows the messages with the possible payloads sent in each message and notes for an example of the Identity Protection Exchange. In the third 3 and fourth 4 messages, the initiator and responder, respectively, exchange keying material used to arrive at a common shared secret and random information which is used to guarantee liveness and protect against replay attacks.

In the fifth 5 and sixth 6 messages, the initiator and responder, respectively, exchange identification information and the results of the agreed upon authentication function. This information is Maughan, et. The benefit of this exchange is the ability to perform only authentication without the computational expense of computing keys.

Using this exchange during negotiation, none of the transmitted information will be encrypted. However, the information may be encrypted in other places. For example, if encryption is negotiated during the first phase of a negotiation and the authentication only exchange is used in the second phase of a negotiation, then the authentication only exchange will be encrypted by the ISAKMP SAs negotiated in the first phase. The following diagram shows the messages with possible payloads sent in each message and notes for an example of the Authentication Only Exchange.

Again, random information which is used to Maughan, et. Additionally, the responder transmits identification information. All of this information is transmitted under the protection of the agreed upon authentication function. In the third message 3 , the initiator transmits identification information.

Combining the Security Association, Key Exchange, and Authentication-related information into one message reduces the number of round-trips at the expense of not providing identity protection. Additionally, the Aggressive Exchange is attempting to establish all security relevant information in a single exchange. The following diagram shows the messages with possible payloads sent in each message and notes for an example of the Aggressive Exchange.

There can be only one Proposal and one Transform offered i. Keying material used to arrive at a common shared secret and random information which is used to guarantee liveness and protect against replay attacks are also transmitted.

Additionally, the initiator transmits identification information. Keying material used to arrive at a common shared secret and random information which is used to guarantee liveness and protect against replay attacks is also transmitted. This information is transmitted under the protection of the common shared secret. The following diagram shows the messages with possible payloads sent in each message and notes for an example of the Informational Exchange.

All exchanges are similar in that with the beginning of any exchange, cryptographic synchronization MUST occur. This will ensure cryptographic synchronization is maintained for existing communications and the Informational Exchange will be processed correctly. For a description of the Commit Bit, see section 3. These payloads are used in the exchanges described in section 4 and can be used in exchanges defined for a specific DOI.

This section describes the processing for each of the payloads. This section suggests the logging of events to a system audit file. This action is controlled by a system security policy and is, therefore, only a suggested action. The receiving entity initiator or responder MUST do the following: 1. This action is dictated by a system security policy. Set a timer and initialize a retry counter. Instead, transmission timer values should be adjusted dynamically based on measured round trip times.

In addition, successive retransmissions of the same packet should be separated by increasingly longer time intervals e. Create the respective cookie. See section 2. Determine the relevant security characteristics of the session i. DOI and situation. Transmit the message to the destination host as described in section5. Verify the Initiator and Responder "cookies".

Check the Next Payload field to confirm it is valid. Check the Major and Minor Version fields to confirm they are correct see section 3. If the Version field validation fails, the message is discarded and the following actions are Maughan, et.

Check the Exchange Type field to confirm it is valid. Check the Flags field to ensure it contains correct values. Check the Message ID field to ensure it contains correct values. Place the value of the Next Payload in the Next Payload field. These values are described in section 3. Place the length in octets of the payload in the Payload Length field. Construct the payloads as defined in the remainder of this section. Process the remaining payloads as defined by the Next Payload field. Determine the Domain of Interpretation for which this negotiation is being performed.

Determine the situation within the determined DOI for which this negotiation is being performed. Determine the proposal s and transform s within the situation. These are described, respectively, in sections 3.

Construct a Security Association payload. Transmit the message to the receiving entity as described in section 5. When a Security Association payload is received, the receiving entity initiator or responder MUST do the following: 1. Determine if the given situation can be protected. Process the remaining payloads i.

Proposal, Transform of the Security Association Payload. If the Security Association Maughan, et. Determine the Protocol for this proposal. Determine the number of proposals to be offered for this protocol and the number of transforms for each proposal. Transforms are described in section 3. Generate a unique pseudo-random SPI. Construct a Proposal payload. When a Proposal payload is received, the receiving entity initiator or responder MUST do the following: 1.

Determine if the Protocol is supported. Determine if the SPI is valid. Ensure the Proposals are presented according to the details given in section 3. Process the Proposal and Transform payloads as defined by the Next Payload field.

Examples of processing these payloads are given in section 4. Determine the Transform for this transform. Determine the number of transforms to be offered for this proposal. Transforms are described in sections 3. Construct a Transform payload. When a Transform payload is received, the receiving entity initiator or responder MUST do the following: 1. Determine if the Transform is supported. Ensure the Transforms are presented according to the details given in section 3.

Process the subsequent Transform and Proposal payloads as defined by the Next Payload field. Construct a Key Exchange payload. Determine if the Key Exchange is supported. Determine the Identification information to be used as defined by the DOI and possibly the situation. Construct an Identification payload. When an Identification payload is received, the receiving entity initiator or responder MUST do the following: 1. Determine if the Identification Type is supported.

This may be based on the DOI and Situation. Determine the Certificate Encoding to be used. This may be specified by the DOI. Ensure the existence of a certificate formatted as defined by the Certificate Encoding. Construct a Certificate payload. When a Certificate payload is received, the receiving entity initiator or responder MUST do the following: 1.

Determine if the Certificate Encoding is supported. Process the Certificate Data field. Determine the type of Certificate Encoding to be requested. Determine the name of an acceptable Certificate Authority which is to be requested if applicable. Construct a Certificate Request payload. Determine if the Certificate Authority is supported for the specified Certificate Encoding. Process the Certificate Request. Determine the Hash function to be used as defined by the SA negotiation.

Construct a Hash payload. When a Hash payload is received, the receiving entity initiator or responder MUST do the following: 1. Determine if the Hash is supported. Determine the Signature function to be used as defined by the SA negotiation.

Construct a Signature payload. When a Signature payload is received, the receiving entity initiator or responder MUST do the following: 1. Determine if the Signature is supported. Create a unique random value to be used as a nonce.

Construct a Nonce payload. When a Nonce payload is received, the receiving entity initiator or responder MUST do the following: 1. There are no specific procedures for handling Nonce payloads. The Informational Exchange with a Notify Payload provides a controlled method of informing a peer entity that errors have occurred during protocol processing. Determine the DOI for this Notification. Determine the Protocol-ID for this Notification. This field is necessary because different security protocols have different SPI sizes.

Determine the Notify Message Type based on the error or status message desired. Determine the SPI which is associated with this notification. Determine if additional Notification Data is to be included. This is additional information specified by the DOI. Construct a Notification payload. Because the Informational Exchange with a Notification payload is a unidirectional message a retransmission will not be performed.

The local security policy will dictate the procedures for continuing. When a Notification payload is received, the receiving entity initiator or responder MUST do the following: 1. If the Encryption Bit is set, i. Once the decryption is complete the processing can continue as described below. Once the authentication is completed, the processing can continue as described below. If the Informational Exchange is not encrypted or authentication, the payload processing can continue as described below.

Determine if the Protocol-Id is supported. Determine if the Notify Message Type is valid. Process the Notification payload, including additional Notification Data, and take appropriate action, according to local security policy.

Determining whether this has occurred is not an easy task and is outside the scope of this memo. However, if it is discovered that transmissions are being compromised, then it is necessary to establish a new SA and delete the current SA. The Informational Exchange with a Delete Payload provides a controlled method of informing a peer entity that the transmitting entity has deleted the SA s.

The SA Establishment procedure must be invoked to re-establish secure communications. Determine the DOI for this Deletion. Determine the Protocol-ID for this Deletion. Determine the of SPIs to be deleted for this protocol. Determine the SPI s which is are associated with this deletion. Construct a Delete payload. Because the Informational Exchange with a Delete payload is a unidirectional message a retransmission will not be performed. When a Delete payload is received, the receiving entity initiator or responder MUST do the following: 1.

Because the Informational Exchange is protected by some security service e. Once the security service processing is complete the processing can continue as described below.

Any errors that occur during the security service processing will be evident when checking information in the Delete payload.

Process the Delete payload and take appropriate action, according to local security policy. The massive growth of the Internet will lead to great diversity in network utilization, communications, security requirements, and security mechanisms.

ISAKMP contains all the features that will be needed for this dynamic and expanding communications environment. ISAKMP's Security Association SA feature coupled with authentication and key establishment provides the security and flexibility that will be needed for future growth and diversity. This security diversity of multiple key exchange techniques, encryption algorithms, authentication mechanisms, security services, and security attributes will allow users to select the appropriate security for their network, communications, and security needs.

The SA feature allows users to specify and negotiate security requirements with other users. An additional benefit of supporting multiple techniques in a single protocol is that as new techniques are developed they can easily be added to the protocol. This provides a path for the growth of Internet security services. These protocols and applications may be session-oriented or sessionless.

Having one SA establishment protocol that supports multiple security protocols eliminates the need for multiple, nearly identical authentication, key exchange and SA establishment protocols when more than one security protocol is in use or desired. Just as IP has provided the common networking layer for the Internet, a common security establishment protocol is needed if security is to become a reality on the Internet.

It is not coupled to other insecure transport protocols, therefore it is not vulnerable or weakened by attacks on other protocols. This protection provides the assurance that the SAs and keys established are with the desired party and not with an attacker. Protocol specific information only is in the protocol header, following the design principles of IPv6. The data transported by the protocol is separated into functional payloads. As the Internet grows and evolves, new payloads to support new security functionality can be added without modifying the entire protocol.

The framework provided by ISAKMP consists of header and payload definitions, exchange types for guiding message and payload exchanges, and general processing guidelines. ISAKMP does not define the mechanisms that will be used to establish and manage Security Associations and cryptographic keys in an authenticated and confidential manner.

The definition of mechanisms and their application is the purview of individual Domains of Interpretation DOIs. All other security protocols within that DOI will be numbered accordingly. Security protocol values are reserved to IANA for future use.

Values are permanently reserved for private use amongst mutually consenting implementations. Such private use values are unlikely to be interoperable across different implementations. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones 1s in the network mask indicate that the corresponding bit in the address is fixed, while zeros 0s indicate a "wildcard" bit. The first value is an IPv6 address. The second is an IPv6 network mask.

However, some groups may have a need to customize some aspect of a DOI, perhaps to add a different set of cryptographic algorithms, or perhaps because they want to make their security-relevant decisions based on something other than a host id or user id. Also, a particular group may have a need for a new exchange type, for example to support key management for multicast groups.

This section discusses guidelines for defining a new DOI. Defining a new DOI is likely to be a time-consuming process. If at all possible, it is recommended that the designer begin with an existing DOI and customize only the parts that are unacceptable. If a designer chooses to start from scratch, the following MUST be defined: o A "situation": the set of information that will be used to determine the required security services.

It must contain all of the data that will be used to determine the types and strengths of protections applied in an SA. For example, a US Department of Defense DOI would probably use unpublished algorithms and have additional special attributes to negotiate. These additional security attributes would be included in the situation. The DOI must define the set of security policies supported, because both parties in a negotiation must trust that the other party understands a situation, and will protect information appropriately, both in transit and in storage.

In a corporate setting, for example, both parties in a negotiation must agree to the meaning of the term "proprietary information" before they can negotiate how to protect it.

Note that including the required security policies in the DOI only specifies that the participating hosts understand and implement those policies in a full system context. This can usually be done by using IANA naming conventions, perhaps with some private extensions.

For several of the payload types, ISAKMP has included fields that would have to be present across all DOI such as a certificate authority in the certificate payload, or a key exchange identifier in the key exchange payload. The designer creates a new exchange type by choosing an unused exchange type value, and defining a sequence of messages composed of strings of the ISAKMP payload types. Note that any new exchange types must be rigorously analyzed for vulnerabilities.

Since this is an expensive and imprecise undertaking, a new exchange type should only be created when absolutely necessary. The continuing improvement in processing power makes once computationally prohibitive cryptographic attacks more realistic. New cryptographic algorithms and public key generation techniques are also being developed at a steady pace.

New security services and mechanisms are being developed at an accelerated pace. A consistent method of choosing from a variety of security services and mechanisms and to exchange attributes required by the mechanisms is important to security in the complex structure of the Internet. Nx is the nonce payload; x can be: Views Read Edit View history.

AAA Server identity the user. Further complications arose from the fact that in many implementations the debug output was difficult to interpret, if there was any facility to produce diagnostic output at all. At Step 9. Pages using RFC magic links All articles with unsourced statements Articles with unsourced statements from June Wikipedia articles needing clarification from February All Wikipedia articles needing clarification Articles using small message boxes.

The IKE protocol uses UDP packets, usually on portand ile requires 4—6 packets with 2—3 turn-around times to create an SA security association on both sides. By using i,e site, you agree to the Terms of Use and Privacy Policy. Requesting an Internal Ile on a Remote Network. Kernel modules, on the other hand, can process packets efficiently and with minimum overhead—which is important for performance reasons.

Following sequence is based on RFC 2. At Step Extensible Authentication Protocol Methods. Implementations vary on how the interception of the packets is done—for example, some iie virtual devices, others take a slice out of the firewall, etc.

At step 3ePDG take out the information from the information e. An Unauthenticated Mode of IPsec. This page was last edited on 19 Decemberat A value chosen by the initiator to identify a unique IKE security association.

An initiator MAY provide multiple proposals for negotiation; a responder MUST reply with only one KE is the key exchange payload which contains the public information exchanged in a Diffie-Hellman exchange. This section may be confusing or unclear to readers. How can a device or a server can do DPD? Other non- mandatory attributes are described in Appendix A. The Diffie-Hellman group MUST be either specified using a defined group description section 6 or by defining all attributes of a group section 5.

Group attributes such as group type or prime-- see Appendix A MUST NOT be offered in conjunction with a previously defined group either a reserved group description or a private use description that is established after conclusion of a New Group Mode exchange.

The key is derived according to Appendix B. Exchanges There are two basic methods used to establish an authenticated key exchange: Main Mode and Aggressive Mode. Each generates authenticated keying material from an ephemeral Diffie-Hellman exchange. Exchanges conform to standard ISAKMP payload syntax, attribute encoding, timeouts and retransmits of messages, and informational messages-- e.

Except where otherwise noted, there are no requirements for ISAKMP payloads in any message to be in any particular order. The Diffie-Hellman public value passed in a KE payload, in either a phase 1 or phase 2 exchange, MUST be the length of the negotiated Diffie-Hellman group enforced, if necessary, by pre-pending the value with zeros.

The length of nonce payload MUST be between 8 and bytes inclusive. The authentication method negotiated as part of the initial ISAKMP exchange influences the composition of the payloads but not their purpose.

The first two messages negotiate policy, exchange Diffie-Hellman public values and ancillary data necessary for the exchange, and identities. In addition the second message authenticates the responder. The third message authenticates the initiator and provides a proof of participation in the exchange.

The graphic depictions of Aggressive Mode show the final payload in the clear; it need not be. Exchanges in IKE are not open ended and have a fixed number of messages. Security Association negotiation is limited with Aggressive Mode. Due to message construction requirements the group in which the Diffie- Hellman exchange is performed cannot be negotiated.

In addition, different authentication methods may further constrain attribute negotiation. For example, authentication with public key encryption cannot be negotiated and when using the revised method of public key encryption for authentication the cipher and hash cannot be negotiated.

For situations where the rich attribute negotiation capabilities of IKE are required Main Mode may be required. This document does not proscribe such behavior on offers in phase 2 exchanges. There is no limit on the number of offers the initiator may send to the responder but conformant implementations MAY choose to limit the number of offers it will inspect for performance reasons.

During security association negotiation, initiators present offers for potential security associations to responders. If the initiator of an exchange notices that attribute values have changed or attributes have been added or deleted from an offer made, that response MUST be rejected. Four different authentication methods are allowed with either Main Mode or Aggressive Mode-- digital signature, two forms of authentication with public key encryption, or pre-shared key.

The values of 0, 1, and 2 above are represented by a single octet. As mentioned above, the negotiated authentication method influences the content and use of messages for Phase 1 Modes, but not their intent. When using public keys for authentication, the Phase 1 exchange can be accomplished either by using signatures or by using public key encryption if the algorithm supports it. Following are Phase 1 exchanges with different authentication options.

However, this can be overridden for construction of the signature if the signature algorithm is tied to a particular hash algorithm e. The negotiated prf and hash function would continue to be used for all other prescribed pseudo- random functions. Since the hash algorithm used is already known there is no need to encode its OID into the signature. One or more certificate payloads MAY be optionally passed. Each party's ability to reconstruct a hash proving that the other party decrypted the nonce authenticates the exchange.

In order to perform the public key encryption, the initiator must already have the responder's public key. In the case where the responder has multiple public keys, a hash of the certificate the initiator is using to encrypt the ancillary information is passed as part of the third message. In this way the responder can determine which corresponding private key to use to decrypt the encrypted payloads and identity protection is retained.

In addition to the nonce, the identities of the parties IDii and IDir are also encrypted with the other party's public key. If the authentication method is public key encryption, the nonce and identity payloads MUST be encrypted with the public key of the other party. Only the body of the payloads are encrypted, the payload headers are left in the clear. When using encryption for authentication, Main Mode is defined as follows. The payload length is the length of the entire encrypted payload plus header.

The PKCS 1 encoding allows for determination of the actual length of the cleartext payload upon decryption. Using encryption for authentication provides for a plausably deniable exchange. There is no proof as with a digital signature that the conversation ever took place since each party can completely reconstruct both sides of the exchange.

In addition, security is added to secret generation since an attacker would have to successfully break not only the Diffie-Hellman exchange but also both RSA encryptions. Note that, unlike other authentication methods, authentication with public key encryption allows for identity protection with Aggressive Mode.

Unfortunately, this is at the cost of 4 public key operations-- two public key encryptions and two private key decryptions. This authentication mode retains the advantages of authentication using public key encryption but does so with half the public key operations. In this mode, the nonce is still encrypted using the public key of the peer, however the peer's identity and the certificate if it is sent is encrypted using the negotiated symmetric encryption algorithm from the SA payload with a key derived from the nonce.

This solution adds minimal complexity and state yet saves two costly public key operations on each side. In addition, the Key Exchange payload is also encrypted using the same derived key. This provides additional protection against cryptanalysis of the Diffie-Hellman exchange. As with the public key encryption method of authentication section 5.

In addition, the initiator my optionally send a certificate payload to provide the responder with a public key with which to respond. When using the revised encryption mode for authentication, Main Mode is defined as follows. Only the body of the payloads are encrypted in both public key and symmetric operations , the generic payload headers are left in the clear.

The payload length includes that added to perform encryption. The symmetric cipher keys are derived from the decrypted nonces as follows. The length of the value 0 in the computation of K1 is a single octet. Save the requirements on the location of the optional HASH payload and the mandatory nonce payload there are no further payload requirements.

If CBC mode is used for the symmetric encryption then the initialization vectors IVs are set as follows. The IV for encrypting the first payload following the nonce is set to 0 zero. Encrypted payloads are padded up to the nearest block size. All padding bytes, except for the last one, contain 0x The last byte of the padding contains the number of the padding bytes used, excluding the last one. Note that this means there will always be padding. The actual establishment of this key is out of the scope of this document.

Aggressive Mode allows for a wider range of identifiers of the pre-shared secret to be used. In addition, Aggressive Mode allows two parties to maintain multiple, different pre-shared keys and identify the correct one for a particular exchange. This HASH authenticates the message and also provides liveliness proofs. Quick Mode is essentially a SA negotiation and an exchange of nonces that provides replay protection. The nonces are used to generate fresh key material and prevent replay attacks from generating bogus security associations.

An optional Key Exchange payload can be exchanged to allow for an additional Diffie-Hellman exchange and exponentiation per Quick Mode. Base Quick Mode without the KE payload refreshes the keying material derived from the exponentiation in phase 1. This does not provide PFS. Using the optional KE payload, an additional exponentiation is performed and PFS is provided for the keying material.

Local policy will dictate whether the proposals are acceptable for the identities specified. The client identities are used to identify and direct traffic to the appropriate tunnel in cases where multiple tunnels exist between two peers and also to allow for unique and shared SAs with different granularities. All offers made during a Quick Mode are logically related and must be consistant. For example, if a KE payload is sent, the attribute describing the Diffie-Hellman group see section 6.