In particular, it MUST forget the secrets used in the Diffie-Hellman calculation and any state that may persist in the state of a pseudo-random number generator that could be used to recompute the Diffie-Hellman secrets. Since the computing of Diffie-Hellman exponentials is computationally expensive, an endpoint may find it advantageous to reuse those exponentials for multiple connection setups.
There are several reasonable strategies for doing this. An endpoint could choose a new exponential only periodically though this could result in less-than- perfect forward secrecy if some connection lasts for less than the lifetime of the exponential.
Or it could keep track of which exponential was used for each connection and delete the information associated with the exponential only when some corresponding connection was closed. This would allow the exponential to be reused without losing perfect forward secrecy at the cost of maintaining more state.
Decisions as to whether and when to reuse Diffie-Hellman exponentials is a private decision in the sense that it will not affect interoperability. An implementation that reuses exponentials MAY choose to remember the exponential used by the other endpoint on past exchanges and if one is reused to avoid the second half of the calculation. Kaufman Standards Track [Page 27] RFC IKEv2 December We assume that each encryption algorithm and integrity protection algorithm uses a fixed-size key and that any randomly chosen value of that fixed size can serve as an appropriate key.
For algorithms that accept a variable length key, a fixed key size MUST be specified as part of the cryptographic transform negotiated. For algorithms for which not all values are valid keys such as DES or 3DES with key parity , the algorithm by which keys are derived from arbitrary values MUST be specified by the cryptographic transform.
For integrity protection functions based on Hashed Message Authentication Code HMAC , the fixed key size is the size of the output of the underlying hash function. When the prf function takes a variable length key, variable length data, and produces a fixed-length output e. When the key for the prf function has fixed length, the data provided as a key is truncated or padded with zeros as necessary unless exceptional processing is explained following the formula. Keying material will always be derived as the output of the negotiated prf algorithm.
Since the amount of keying material needed may be greater than the size of the output of the prf algorithm, we will use the prf iteratively. The keys are taken from the output string without regard to boundaries e.
The constant concatenated to the end of each string feeding the prf is a single octet. Ni and Nr are the nonces, stripped of any headers. If the negotiated prf takes a fixed-length key and the lengths of Ni and Nr do not add up to that length, half the bits must come from Ni and half from Nr, taking the first bits of each.
The two directions of traffic flow use different keys. Each algorithm takes a fixed number of bits of keying material, which is specified as part of the algorithm.
For integrity algorithms based on a keyed hash, the key size is always equal to the length of the output of the underlying hash function. For the responder, the octets to be signed start with the first octet of the first SPI in the header of the second message and end with the last octet of the last payload in the second message. Similarly, the initiator signs the first message, starting with the first octet of the first SPI in the header and ending with the last octet of the last payload.
It is critical to the security of the exchange that each side sign the other side's nonce. Note that all of the payloads are included under the signature, including any payload types not defined in this document. Optionally, messages 3 and 4 MAY include a certificate, or certificate chain providing evidence that the key used to compute a digital signature belongs to the name in the ID payload.
The signature or MAC will be computed using algorithms dictated by the type of key used by the signer, and specified by the Auth Method field in the Authentication payload. There is no requirement that the initiator and responder sign with the same cryptographic algorithms. The choice of cryptographic algorithms depends on the type of key each has. In particular, the initiator may be using a shared key while the responder may have a public signature key and certificate.
It will commonly be the case but it is not required that if a shared secret is used for authentication that the same key is used in both directions. Note that it is a common but typically insecure practice to have a shared key derived solely from a user- chosen password without incorporating another source of randomness.
This is typically insecure because user-chosen passwords are unlikely to have sufficient unpredictability to resist dictionary attacks and these attacks are not prevented in this authentication method.
The shared secret can be variable length. The pad string is added so that if the shared secret is derived from a password, the IKE implementation need not store the password in cleartext, but rather can store the value prf Shared Secret,"Key Pad for IKEv2" , which could not be used as a password equivalent for protocols other than IKEv2. As noted above, deriving the shared secret from a password is not secure.
This construction is used because it is anticipated that people will do it anyway. The management interface MAY accept other encodings if the algorithm for translating the encoding to a binary string is specified. If the negotiated prf takes a fixed-size key, the shared secret MUST be of that fixed size. Typically, these methods are asymmetric designed for a user authenticating to a server , and they may not be mutual.
For this reason, these protocols are typically used to authenticate the initiator to the responder and MUST be used in conjunction with a public key signature based authentication of the responder to the initiator. These methods are often associated with mechanisms referred to as "Legacy Authentication" mechanisms. While this memo references [ EAP ] with the intent that new methods can be added in the future without updating this specification, some simpler variations are documented here and in section 3.
An initiator indicates a desire to use extensible authentication by leaving out the AUTH payload from message 3. Please see the Security Considerations section for more details. If multiple IPsec protocols are negotiated, keying material is taken in the order in which the protocol headers will appear in the encapsulated packet.
If a single protocol has both encryption and authentication keys, the encryption key is taken from the first octets of KEYMAT and the authentication key is taken from the next octets. Each cryptographic algorithm takes a fixed number of bits of keying material specified as part of the algorithm.
Requesting an Internal Address on a Remote Network Most commonly occurring in the endpoint-to-security-gateway scenario, an endpoint may need an IP address in the network protected by the security gateway and may need to have that address dynamically assigned. If a request is received that is badly formatted or unacceptable for reasons of policy e. If an error occurs outside the context of an IKE request e. There is a trade-off between wanting to be helpful in diagnosing a problem and responding to it and wanting to avoid being a dupe in a denial of service attack based on forged messages.
An implementation SHOULD limit the frequency of such tests to avoid being tricked into participating in a denial of service attack. A node MUST limit the rate at which it will send messages in response to unprotected messages. A side effect of separating the negotiation of IPComp from cryptographic parameters is that it is not possible to propose multiple cryptographic suites and propose IP compression with some of them but not others.
This section briefly describes what they are and how they are likely to act on IKE traffic. Many people believe that NATs are evil and that we should not design our protocols so as to make them work better. NATs exist primarily because of the shortage of IPv4 addresses, though there are other rationales. IP nodes that are "behind" a NAT have IP addresses that are not globally unique, but rather are assigned from some space that is unique within the network behind the NAT but that are likely to be reused by nodes behind other NATs.
There are exceptions to that rule. When those nodes make connections to nodes on the real Internet, the NAT gateway "translates" the IP source address to an address that will be routed back to the gateway. Messages to the gateway from the Internet have their destination addresses "translated" to the internal address that will route the packet to the correct endnode. NATs are designed to be "transparent" to endnodes.
Achieving this transparency is more difficult with some protocols than with others. Protocols that include IP addresses of the endpoints within the payloads of the packet will fail unless the NAT gateway understands the protocol and modifies the internal references as well as those in the headers. Such knowledge is inherently unreliable, is a network layer violation, and often results in subtle problems. If the connection runs in transport mode, changing the IP addresses on packets will cause the checksums to fail and the NAT cannot correct the checksums because they are cryptographically protected.
Even in tunnel mode, there are routing problems because transparently translating the addresses of AH and ESP packets requires special logic in the NAT and that logic is heuristic and unreliable in nature.
This encoding is slightly less efficient but is easier for NATs to process. This is because the ports may be modified as the packets pass through NATs. Support for NAT traversal is optional. In this case, this end should allow dynamic update of the other ends IP address, as described later.
There are cases where a NAT box decides to remove mappings that are still alive for example, the keepalive interval is too long, or the NAT box is rebooted. To recover in these cases, hosts that are not behind a NAT SHOULD send all packets including retransmission packets to the IP address and port from the last valid authenticated packet from the other end i. Note that similar but probably not identical actions will likely be needed to make IKE work with Mobile IP, but such processing is not addressed by this document.
Header and Payload Formats 3. Information from the beginning of the packet through the UDP header is largely ignored except that the IP addresses and UDP ports from the headers are reversed and used for return packets. These four octets of zero are not part of the IKE message and are not included in any of the length fields or checksums defined by IKE.
Following the header are one or more IKE payloads each identified by a "Next Payload" field in the preceding payload. Payloads are processed in the order in which they appear in an IKE message by invoking the appropriate processing routine according to the "Next Payload" field in the IKE header and subsequently according to the "Next Payload" field in the IKE payload itself until a "Next Payload" field of zero indicates that no payloads follow.
If a payload of type "Encrypted" is found, that payload is decrypted and its contents parsed as additional payloads. It is therefore possible for a single instance of IKE to multiplex distinct sessions with multiple peers. All multi-octet fields representing integers are laid out in big endian order aka most significant byte first, or network byte order.
The format of the IKE header is shown in Figure 4. Next Payload! Exchange Type! Message ID! The format and value of each payload are defined below.
They MUST ignore the minor version number of received messages. This constrains the payloads sent in each message and orderings of messages in an exchange. Presence of options are indicated by the appropriate bit in the flags field being set. The bits are defined LSB first, so bit 0 would be the least significant bit of the Flags octet. In the description below, a bit being 'set' means its value is '1', while 'cleared' means its value is '0'. It is used by the recipient to determine which eight octets of the SPI were generated by the recipient.
It is essential to the security of the protocol because it is used to prevent message replay attacks. See sections 2. Figures for each payload below will include the generic payload header, but for brevity the description of each field will be omitted.
Payload Length! If the current payload is the last in the message, then this field will be 0. This field provides a "chaining" capability whereby additional payloads can be added to a message by appending it to the end of the message and setting the "Next Payload" field of the preceding payload to indicate the new payload's type.
An Encrypted payload, which must always be the last payload of a message, is an exception. It contains data structures in the format of additional payloads. In the header of an Encrypted payload, the Next Payload field is set to the payload type of the first contained payload instead of 0. Payload type values are for private use among mutually consenting parties. MUST be set to one if the sender wants the recipient to reject this entire message if it does not understand the payload type.
MUST be ignored by the recipient if the recipient understands the payload type code. MUST be set to zero for payload types defined in this document. Note that the critical bit applies to the current payload rather than the "next" payload whose type code appears in the first octet. The reasoning behind not setting the critical bit for payloads defined in this document is that all implementations MUST understand all payload types defined in this document and therefore must ignore the Critical bit's value.
Skipped payloads are expected to have valid Next Payload and Payload Length fields. Assembly of Security Association Payloads requires great peace of mind. If there is more than one, they MUST be ordered from most preferred to least preferred. Proposals, Transforms, and Attributes each have their own variable length encodings.
The length of a Proposal includes the lengths of all Transforms and Attributes it contains. The length of a Transform includes the lengths of all Attributes it contains. The reason for the complexity and the hierarchy is to allow for multiple possible combinations of algorithms to be encoded in a single SA.
Sometimes there is a choice of multiple algorithms, whereas other times there is a combination of algorithms. If two successive structures have the same Proposal number, it means that the proposal consists of the first structure AND the second. The number of different transforms is generally determined by the Protocol. AH generally has a single transform: an integrity check algorithm. ESP generally has two: an encryption algorithm and an integrity check algorithm. For each Protocol, the set of permissible transforms is assigned transform ID numbers, which appear in the header of each transform.
If there are multiple transforms with the same Transform Type, the proposal is an OR of those transforms. This effectively proposes four combinations of algorithms. Instead, the initiator would have to construct two different Proposals, each with two transforms. A given transform MAY have one or more Attributes. Attributes are necessary when the transform can be used in more than one way, as when an encryption algorithm has a variable key size.
The transform would specify the algorithm and the attribute would specify the key size. Most transforms do not have attributes. To propose alternate values for an attribute for example, multiple key sizes for the AES encryption algorithm , and implementation MUST include multiple Transforms with the same Transform Type each with a single Attribute. In IKEv1, a single Transform carried multiple algorithms for a protocol with one carried in the Transform and the others carried in the Attributes.
The payload type for the Security Association Payload is thirty three Proposal Length! Protocol ID! SPI Size! The value 2 corresponds to a Payload Type of Proposal in IKEv1, and the first 4 octets of the Proposal structure are designed to look somewhat like the header of a Payload. Even if the SPI Size is not a multiple of 4 octets, there is no padding applied to the payload.
Transform Length! Transform Type! Transform ID! Different protocols support different transform types. For some protocols, some of the transforms may be optional. If a transform is optional and the initiator wishes to propose that the transform be omitted, no transform of the given type is included in the proposal. Values are for private use among mutually consenting parties.
An SA payload proposing the establishment of an SA has the following mandatory and optional transform types. A compliant implementation MUST understand all mandatory and optional types for each protocol it supports though it need not accept proposals with unacceptable suites.
An important lesson learned from IKEv1 is that no system should only implement the mandatory algorithms and expect them to be the best choice for all customers. It is likely that IANA will add additional transforms in the future, and some users may want to use private suites, especially for IKE where implementations should be capable of supporting different parameters, up to certain size limits. Upon receipt of a payload with a set of transform IDs, the implementation MUST compare the transmitted transform IDs against those locally configured via the management controls, to verify that the proposed suite is acceptable based on local policy.
Results do not reflect any position of the funding agencies. References 8. This document is subject to the rights, licenses and restrictions contained in BCP 78 , and except as set forth therein, the authors retain all their rights.
Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr ietf.
Standards Track [Page 7]. Please refer to the current edition of the "Internet Official Protocol Standards" STD 1 for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available.
This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. Introduction The Internet Key Exchange protocol provides for the negotiation of cryptographic algorithms between both endpoints of a cryptographic association. However, the IETF desires that all implementations should have some way to interoperate. In particular, this requires that IKE define a set of mandatory-to-implement algorithms because IKE itself uses such algorithms as part of its own negotiations.
This requires that some set of algorithms be specified as "mandatory-to-implement" for IKE. If errors are seen that indicate that the peers do not have the same state, it might be good to delete the IKE SA to clean up state and start over. If the message is marked as a request, the node can audit the suspicious event and MAY send a response. The message might be a forgery or might be a response that a genuine correspondent was tricked into sending. If an error occurs outside the context of an IKE request e.
It is not explicitly mentioned in any Delete payload. Negotiation of IP Compression is separate from the negotiation of cryptographic parameters associated with a Child SA. A message accepting an SA may contain at most one. The Transform IDs are listed here.
The values in the following table are only current as of the publication date of RFC Other values may have been added since then or will be added after the publication of this document.
A side effect of separating the negotiation of IPComp from cryptographic parameters is that it is not possible to propose multiple cryptographic suites and propose IP Compression with some of them but not others. This section briefly describes what they are and how they are likely to act on IKE traffic.
Many people believe that NATs are evil and that we should not design our protocols so as to make them work better. IP nodes that are "behind" a NAT have IP addresses that are not globally unique, but rather are assigned from some space that is unique within the network behind the NAT but that are likely to be reused by nodes behind other NATs. There are exceptions to that rule.
When those nodes make connections to nodes on the real Internet, the NAT gateway "translates" the IP source address to an address that will be routed back to the gateway. Messages to the gateway from the Internet have their destination addresses "translated" to the internal address that will route the packet to the correct endnode. NATs are designed to be "transparent" to endnodes. Achieving this transparency is more difficult with some protocols than with others.
Protocols that include IP addresses of the endpoints within the payloads of the packet will fail unless the NAT gateway understands the protocol and modifies the internal references as well as those in the headers. Such knowledge is inherently unreliable, is a network layer violation, and often results in subtle problems.
If the connection runs in transport mode, changing the IP addresses on packets will cause the checksums to fail and the NAT cannot correct the checksums because they are cryptographically protected. Even in tunnel mode, there are routing problems because transparently translating the addresses of AH and ESP packets requires special logic in the NAT and that logic is heuristic and unreliable in nature.
This encoding is slightly less efficient but is easier for NATs to process. It is a common practice of NATs to translate TCP and UDP port numbers as well as addresses and use the port numbers of inbound packets to decide which internal node should get a given packet. This is because the ports may be modified as the packets pass through NATs.
Either side can decide whether or not to use UDP encapsulation for ESP irrespective of the choice made by the other side. Support for NAT traversal is optional. In this case, the system receiving the payloads should allow dynamic updates of the other system's IP address, as described later.
This is covered in greater detail in Section 2. This will be apparent to a host if it receives a packet whose integrity protection validates, but has Kaufman, et al.
Also, dynamic address update should only be done in response to a new packet; otherwise, an attacker can revert the addresses with old replayed packets. Because of this, dynamic updates can only be done safely if replay protection is enabled. See Section 3. This allows the client to connect to a server by connecting to the IPN2. Standards Track [Page 66] RFC IKEv2bis October In this scenario, both the client and server are configured to use transport mode for the traffic originating from the client node and destined to the server.
Because IP1 does not really mean anything to the server it is the address client has behind the NAT , it is useless to do a lookup based on that if transport mode is used. On the other hand, the server cannot know whether transport mode is allowed by its policy before it finds the matching SPD entry. In this case, the server should first check that the initiator requested transport mode, and then do address substitution on the Traffic Selectors.
It needs to first store the old Traffic Selector IP addresses to be used later for the incremental checksum fixup the IP address in the TSi can be stored as the original source address and the IP address in the TSr can be stored as the original destination address. If an entry is found and it allows transport mode, then that entry is used. If an entry is found but it does not allow transport mode, then the server MAY undo the address substitution and redo the SPD lookup using the original Traffic Selectors.
If the second lookup succeeds, the server will create an SA in tunnel mode using real Traffic Selectors sent by the other end. This address substitution in transport mode is needed because the SPD is looked up using the addresses that will be seen by the local host. This will also ensure that the Security Association Database SAD entries for the tunnel exit checks and return packets are added using the addresses as seen by the local operating system stack.
The most common case is that the server's SPD will contain wildcard entries matching any addresses, but this also allows making different SPD entries, for example, for different known NATs' outer addresses. It will again use the already substituted Traffic Selectors, and it will thus send back Traffic Selectors having IPN1 and IP2 as their IP addresses; it can still narrow down the protocol number or port ranges used by the Traffic Selectors.
When the client receives the server's response to the Child SA, it will do similar processing. If the transport mode SA was created, the client can store the original returned Traffic Selectors as original source and destination addresses. This includes verification that Traffic Selectors were narrowed correctly by the other end, creation of the SAD entry, and so on. Exchange Collisions Because IKEv2 exchanges can be initiated by either peer, it is possible that two exchanges affecting the same SA partly overlap.
This can lead to a situation where the SA state information is temporarily not synchronized, and a peer can receive a request that it cannot process in a normal fashion.
Obviously, using a window size greater than 1 leads to more complex situations, especially if requests are processed out of order. This section concentrates on problems that can arise even with a window size of 1, and recommends solutions. The recipient MAY retry the request one or more times over a period of several minutes.
If a peer continues to Kaufman, et al. These are items for which there are no known specifications and therefore interoperability is currently impossible. Information from the beginning of the packet through the UDP header is largely ignored except that the IP addresses and UDP ports from the headers are reversed and used for return packets. These four octets of zeros are not part of the IKE message and are not included in any of the length fields or checksums defined by IKE.
Following the header are one or more IKE payloads each identified by a Next Payload field in the preceding payload. Payloads are identified in the order in which they appear in an IKE message by looking in the Next Payload field in the IKE header, and subsequently according to the Next Payload field in the IKE payload itself until a Next Payload field of zero indicates that no payloads follow.
If a payload of type "Encrypted" is found, that payload is decrypted and its contents parsed as additional payloads. It is therefore possible for a single instance of IKE to multiplex distinct sessions with multiple peers, including multiple sessions per peer. All multi-octet fields representing integers are laid out in big endian order also known as "most significant byte first", or "network byte order".
The format and value of each payload are defined below. They MUST ignore the minor version number of received messages. This constrains the payloads sent in each message in an exchange. Presence of options is indicated by the appropriate bit in the flags field being set. It is used by the recipient to determine which eight octets of the SPI were generated by the recipient.
It is essential to the security of the protocol because it is used to prevent message replay attacks. See Sections 2. Figures for each payload below will include the generic payload header, but for brevity, the description of each field will be omitted. If the current payload is the last in the message, then this field will be 0. This field provides a "chaining" capability whereby additional payloads can be added to a message by appending each one to the end of the message and setting the Next Payload field of the preceding payload to indicate the new payload's type.
An Encrypted payload, which must always be the last payload of a message, is an exception. It contains data structures in the format of additional payloads.
In the header of an Encrypted payload, the Next Payload field is set to the payload type of the first contained payload instead of 0 ; conversely, the Next Payload field of the last contained payload is set to zero. The payload type values are listed here. MUST be set to one if the sender wants the recipient to reject this entire message if it does not understand the payload type.
MUST be ignored by the recipient if the recipient understands the payload type code. MUST be set to zero for payload types defined in this document.
Note that the critical bit applies to the current payload rather than the "next" payload whose type code appears in the first octet. The reasoning behind not setting the critical bit for payloads defined in this document is that all implementations MUST understand all payload types defined in this document and therefore must ignore the critical bit's value.
Skipped payloads are expected to have valid Next Payload and Payload Length fields. Assembly of Security Association payloads requires great peace of mind. If there is more than one, they MUST be ordered from most preferred to least preferred. Proposals, Transforms, and Attributes each have their own variable-length encodings. The length of a Proposal includes the lengths of all Transforms and Attributes it contains. The length of a Transform includes the lengths of all Attributes it contains.
The reason for the complexity and the hierarchy is to allow for multiple possible combinations of algorithms to be encoded in a single SA.
Sometimes there is a choice of multiple algorithms, whereas other times there is a combination of algorithms. Each structure MUST have a proposal number one 1 greater than the previous structure. One reason to use multiple proposals is to propose both standard crypto ciphers and combined-mode ciphers. If an initiator wants to propose both combined- mode ciphers and normal ciphers, it must include two proposals: one will have all the combined-mode ciphers, and the other will have all Kaufman, et al.
For example, one such proposal would have two proposal structures. The number of different transforms is generally determined by the Protocol. For each Protocol, the set of permissible transforms is assigned Transform ID numbers, which appear in the header of each transform. If there are multiple transforms with the same Transform Type, the proposal is an OR of those transforms.
If there are multiple transforms with different Transform Types, the proposal is an AND of the different groups. This effectively proposes four combinations of algorithms. Instead, the initiator would have to construct two different Proposals, each with two transforms. A given transform MAY have one or more Attributes. Attributes are necessary when the transform can be used in more than one way, as when an encryption algorithm has a variable key size.
The transform would specify the algorithm and the attribute would specify the key size. Most transforms do not have attributes. To propose alternate values for an attribute for example, multiple key sizes for the AES encryption algorithm , an implementation MUST include multiple transforms with the same Transform Type each with a single Attribute.
In IKEv1, a single Transform carried multiple algorithms for a protocol with one carried in the Transform and the others carried in the Attributes. This field has a value of 0 if this was the last Proposal Substructure, and a value of 2 if there are more Proposal Substructures. The value 2 corresponds to a payload type of Proposal in IKEv1, and the first four octets of the Proposal structure are designed to look somewhat like the header of a payload.
When a proposal is accepted, the proposal number in the SA payload MUST match the number on the proposal sent that was accepted. Even if the SPI Size is not a multiple of 4 octets, there is no padding applied to the payload. This field has a value of 0 if this was the last Transform Substructure, and a Kaufman, et al. This syntax is inherited from ISAKMP, but is unnecessary because the last transform could be identified from the length of the proposal.
The value 3 corresponds to a payload type of Transform in IKEv1, and the first four octets of the Transform structure are designed to look somewhat like the header of a payload. Different protocols support different Transform Types. For some protocols, some of the transforms may be optional. If a transform is optional and the initiator wishes to propose that the transform be omitted, no transform of the given type is included in the proposal. The Transform Type values are listed below.
Description Trans. For example, [ AEAD ] specifies additional formats based on authenticated encryption, in which a separate integrity algorithm is not negotiated. Note that the MODP Diffie-Hellman groups listed above do not need any special validity tests to be performed, but other types of groups elliptic curve groups, and MODP groups with small subgroups need to have some additional tests performed on them to use them securely.
A proposal containing a single ESN transform with value "1" means that using normal non-extended sequence numbers is not acceptable. A compliant implementation MUST understand all mandatory and optional types for each protocol it supports though it need not accept proposals with unacceptable suites.
At the time of publication of this document, [ RFC ] specifies these suites, but note that it might be updated in the future, and other RFCs might specify different sets of suites. An important lesson learned from IKEv1 is that no system should only implement the mandatory algorithms and expect them to be the best choice for all customers. It is likely that IANA will add additional transforms in the future, and some users may want to use private suites, especially for IKE where implementations should be capable of supporting different parameters, up to certain size limits.
In support of this goal, all implementations of IKEv2 SHOULD include a management facility that allows specification by a user or system administrator of Diffie- Hellman parameters the generator, modulus, and exponent lengths and values for new Diffie-Hellman groups.
Standards Track [Page 85] RFC IKEv2bis October provide a management interface through which these parameters and the associated Transform IDs may be entered by a user or system administrator , to enable negotiating such groups.
Upon receipt of a payload with a set of Transform IDs, the implementation MUST compare the transmitted Transform IDs against those locally configured via the management controls, to verify that the proposed suite is acceptable based on local policy. Note that cryptographic suites that MUST be implemented need not be configured as acceptable to local policy. Transform Attributes Each transform in a Security Association payload may include attributes that modify or complete the specification of the transform.
The set of valid attributes depends on the transform. Currently, only a single attribute type is defined: the Key Length attribute is used by certain encryption transforms with variable- length keys see below for details. Attributes can have a value with a fixed two-octet length or a variable-length value. If the AF bit is a zero 0 , this field has a variable length defined by the Attribute Length field.
If the AF bit is a one 1 , the Attribute Value has a length of 2 octets. The only currently defined attribute type Key Length is fixed length; the variable-length encoding specification is included only for future extensions. Note: This is a change from IKEv1, where increased flexibility may have simplified the composer of messages but certainly complicated the parser.
Attribute Type Value Attribute Format Key Length in bits 14 TV Values and were used in a similar context in IKEv1, and should not be assigned except to matching values.
It is recommended that future Type 2 or 3 transforms do not use this attribute. Implementation note: To further interoperability and to support upgrading endpoints independently, implementers of this protocol SHOULD accept values that they deem to supply greater security. For instance, if a peer is configured to accept a variable-length cipher with a key length of X bits and is offered that cipher with a larger key length, the implementation SHOULD accept the offer if it supports use of the longer key.
However, as the attribute is always returned unchanged see the next section , an initiator willing to accept multiple key lengths has to include multiple transforms with the same Transform Type, each with a different Key Length attribute. Attribute Negotiation During Security Association negotiation initiators present offers to responders. Responders MUST select a single complete set of parameters from the offers or reject all offers if none are acceptable. If there are multiple proposals, the responder MUST choose a single proposal.
If the selected proposal has multiple transforms with the same type, the responder MUST choose a single one. Any attributes of a selected transform MUST be returned unmodified. If the responder receives a proposal that contains a Transform Type it does not understand, or a proposal that is missing a mandatory Transform Type, it MUST consider this proposal unacceptable; however, other proposals in the same SA payload are processed as usual.
Similarly, if the responder receives a transform that it does not understand, or one that contains a Transform Attribute it does not understand, it MUST consider this transform unacceptable; other transforms with the same Transform Type are processed as usual.
This allows new Transform Types and Transform Attributes to be defined in the future. Negotiating Diffie-Hellman groups presents some special challenges. If in the initial exchange the initiator offers to use one of several Diffie-Hellman groups, it SHOULD pick the one the responder is most likely to accept and Kaufman, et al.
If the responder selects a proposal using a different Diffie-Hellman group other than NONE , the responder will indicate the correct group in the response and the initiator SHOULD pick an element of that group for its KE value when retrying the first message. It SHOULD, however, continue to propose its full supported set of groups in order to prevent a man-in-the-middle downgrade attack.
The length of the Diffie-Hellman public value for MODP groups MUST be equal to the length of the prime modulus over which the exponentiation was performed, prepending zero bits to the value if necessary.
See also Sections 1. The payload type for the Key Exchange payload is thirty-four Identification Payloads The Identification payloads, denoted IDi and IDr in this document, allow peers to assert an identity to one another.
This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions. See Section 4. The length of the Identification Data is computed from the size in the ID payload header. The payload types for the Identification payload are thirty-five 35 for IDi and thirty-six 36 for IDr. The following table lists the assigned semantics for the Identification Type field.
Two implementations will interoperate only if each can generate a type of ID acceptable to the other. Although NAIs look a bit like email addresses e. Note that the term "Certificate payload" is somewhat misleading, because not all authentication mechanisms use certificates and data other than certificates may be passed in this payload.
The type of certificate is indicated by the Certificate Encoding field. The payload type for the Certificate payload is thirty-seven The types whose syntax is defined in this document are: o "X. Note that with this encoding, if a chain of certificates needs to be sent, multiple CERT payloads are used, only the first of which holds the public key used to validate the sender's AUTH payload. The other certificates may be sent in any order.
Certificate Request payloads MAY be included in an exchange when the sender needs to get the certificate of the receiver. Values are listed in Section 3. The payload type for the Certificate Request payload is thirty-eight The Certification Authority field contains an indicator of trusted authorities for this certificate type.
The octet hashes are concatenated and included with no other formatting. The contents of the Certification Authority field are defined only for X. Note that the term "Certificate Request" is somewhat misleading, in that values other than certificates are defined in a "Certificate" payload and requests for those values can be present in a Certificate Request payload.
The syntax of the Certificate Request payload in such cases is not defined in this document. The Certificate Request payload is processed by inspecting the Cert Encoding field to determine whether the processor has any certificates of this type. If so, the Certification Authority field is inspected to determine if the processor has any certificates that can be validated up to one of the specified certification authorities. This can be a chain of certificates. Certificate revocation checking must be considered during the chaining process used to select a certificate.
Note that even if two peers are configured to use two different CAs, cross-certification relationships should be supported by appropriate selection logic. Standards Track [Page 96] RFC IKEv2bis October The intent is not to prevent communication through the strict adherence of selection of a certificate based on CERTREQ, when an alternate certificate could be selected by the sender that would still enable the recipient to successfully validate and trust it through trust conveyed by cross-certification, CRLs, or other out-of-band configured means.
This is not an error condition of the protocol. The syntax of the Authentication Data varies according to the Auth Method as specified below. The types of signatures are listed here. Implementations can use the certificates received from a given peer as a hint for selecting a mutually understood hash function for the AUTH payload signature. Note, however, that the hash algorithm used in the AUTH payload signature doesn't have to be the same as any hash algorithm s used in the certificate s.
The payload type for the Authentication payload is thirty-nine Nonce Payload The Nonce payload, denoted as Ni and Nr in this document for the initiator's and responder's nonce, respectively, contains random data used to guarantee liveness during an exchange and protect against replay attacks.
The payload type for the Nonce payload is forty Notify Payload The Notify payload, denoted N in this document, is used to transmit informational data, such as error conditions and state transitions, to an IKE peer. Values for this field are type specific see below. The payload type for the Notify payload is forty-one Notify Message Types Notification information can be error messages specifying why an SA could not be established.
It can also be status data that a process managing an SA database wishes to communicate with a peer process. The table below lists the notification messages and their corresponding values. The number of different error statuses was greatly reduced from IKEv1 both for simplification and to avoid giving configuration information to probers.
Types in the range 0 - are intended for reporting errors. An implementation receiving a Notify payload with one of these types that it does not recognize in a response MUST assume that the corresponding request has failed entirely. Unrecognized error types in a request and status types in a request or response MUST be ignored, and they should be logged.
They are intended to indicate capabilities, and as part of SA negotiation, are used to negotiate non-cryptographic parameters.
0コメント