draft-ietf-lwig-ikev2-minimal-05.txt   rfc7815.txt 
Light-Weight Implementation Guidance (lwig) T. Kivinen Internet Engineering Task Force (IETF) T. Kivinen
Internet-Draft INSIDE Secure Request for Comments: 7815 INSIDE Secure
Intended status: Informational November 23, 2015 Category: Informational March 2016
Expires: May 26, 2016 ISSN: 2070-1721
Minimal IKEv2 Initiator Implementation Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation
draft-ietf-lwig-ikev2-minimal-05.txt
Abstract Abstract
This document describes a minimal initiator version of the Internet This document describes a minimal initiator version of the Internet
Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2
is a component of IPsec used for performing mutual authentication and is a component of IPsec used for performing mutual authentication and
establishing and maintaining Security Associations (SAs). IKEv2 establishing and maintaining Security Associations (SAs). IKEv2
includes several optional features, which are not needed in minimal includes several optional features, which are not needed in minimal
implementations. This document describes what is required from the implementations. This document describes what is required from the
minimal implementation, and also describes various optimizations minimal implementation and also describes various optimizations that
which can be done. The protocol described here is interoperable with can be done. The protocol described here is interoperable with a
a full IKEv2 implementation using shared secret authentication (IKEv2 full IKEv2 implementation using shared secret authentication (IKEv2
does not require the use of certificate authentication). This does not require the use of certificate authentication). This
minimal initiator implementation can only talk to a full IKEv2 minimal initiator implementation can only talk to a full IKEv2
implementation acting as responder, thus two minimal initiator implementation acting as the responder; thus, two minimal initiator
implementations cannot talk to each other. implementations cannot talk to each other.
This document does not update or modify RFC 7296, but provides more This document does not update or modify RFC 7296 but provides a more
compact description of the minimal version of the protocol. If this compact description of the minimal version of the protocol. If this
document and RFC 7296 conflicts then RFC 7296 is the authoritative document and RFC 7296 conflict, then RFC 7296 is the authoritative
description. description.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on May 26, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7815.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 34 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . 5 2.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . 5
2.2. Other Exchanges . . . . . . . . . . . . . . . . . . . . . 11 2.2. Other Exchanges . . . . . . . . . . . . . . . . . . . . . 12
2.3. Generating Keying Material . . . . . . . . . . . . . . . 11 2.3. Generating Keying Material . . . . . . . . . . . . . . . 12
3. Conformance Requirements . . . . . . . . . . . . . . . . . . 12 3. Conformance Requirements . . . . . . . . . . . . . . . . . . 13
4. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Header and Payload Formats . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 14 A.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Header and Payload Formats . . . . . . . . . . . . . 14 A.2. Generic Payload Header . . . . . . . . . . . . . . . . . 19
A.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 15 A.3. Security Association Payload . . . . . . . . . . . . . . 21
A.2. Generic Payload Header . . . . . . . . . . . . . . . . . 17 A.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 23
A.3. Security Association Payload . . . . . . . . . . . . . . 18 A.3.2. Transform Substructure . . . . . . . . . . . . . . . 24
A.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 20 A.3.3. Valid Transform Types by Protocol . . . . . . . . . . 26
A.3.2. Transform Substructure . . . . . . . . . . . . . . . 21 A.3.4. Transform Attributes . . . . . . . . . . . . . . . . 26
A.3.3. Valid Transform Types by Protocol . . . . . . . . . . 23 A.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 27
A.3.4. Transform Attributes . . . . . . . . . . . . . . . . 23 A.5. Identification Payloads . . . . . . . . . . . . . . . . . 27
A.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 24 A.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 29
A.5. Identification Payloads . . . . . . . . . . . . . . . . . 25 A.7. Certificate Request Payload . . . . . . . . . . . . . . . 30
A.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 26 A.8. Authentication Payload . . . . . . . . . . . . . . . . . 31
A.7. Certificate Request Payload . . . . . . . . . . . . . . . 27 A.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 31
A.8. Authentication Payload . . . . . . . . . . . . . . . . . 28 A.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 32
A.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 28 A.10.1. Notify Message Types . . . . . . . . . . . . . . . . 33
A.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 29 A.11. Traffic Selector Payload . . . . . . . . . . . . . . . . 34
A.10.1. Notify Message Types . . . . . . . . . . . . . . . . 30 A.11.1. Traffic Selector . . . . . . . . . . . . . . . . . . 36
A.11. Traffic Selector Payload . . . . . . . . . . . . . . . . 31 A.12. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 37
A.11.1. Traffic Selector . . . . . . . . . . . . . . . . . . 33 Appendix B. Useful Optional Features . . . . . . . . . . . . . . 39
A.12. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 34 B.1. IKE SA Delete Notification . . . . . . . . . . . . . . . 39
Appendix B. Useful Optional Features . . . . . . . . . . . . . . 36 B.2. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 40
B.1. IKE SA Delete Notification . . . . . . . . . . . . . . . 36 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41
B.2. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
The Internet Protocol Suite is increasingly used on small devices The Internet Protocol Suite is increasingly used on small devices
with severe constraints on power, memory, and processing resources. with severe constraints on power, memory, and processing resources.
This document describes a minimal IKEv2 implementation designed for This document describes a minimal IKEv2 implementation designed for
use on such constrained nodes that is interoperable with Internet Key use on such constrained nodes that is interoperable with "Internet
Exchange Protocol Version 2 (IKEv2) [RFC7296]. Key Exchange Protocol Version 2 (IKEv2)" [RFC7296].
A minimal IKEv2 implementation only supports the initiator end of the A minimal IKEv2 implementation only supports the initiator end of the
protocol. It only supports the initial IKE_SA_INIT and IKE_AUTH protocol. It only supports the initial IKE_SA_INIT and IKE_AUTH
exchanges and does not initiate any other exchanges. It also replies exchanges and does not initiate any other exchanges. It also replies
with empty (or error) message to all incoming requests. with an empty (or error) message to all incoming requests.
This means that most of the optional features of IKEv2 are left out: This means that most of the optional features of IKEv2 are left out:
NAT Traversal, IKE SA rekey, Child SA rekey, Multiple Child SAs, NAT traversal, IKE SA rekey, Child SA rekey, multiple Child SAs,
Deleting Child / IKE SAs, Configuration payloads, EAP authentication, deleting Child / IKE SAs, Configuration payloads, Extensible
COOKIEs etc. Authentication Protocol (EAP) authentication, COOKIEs, etc.
Some optimizations can be done because of the limited set of Some optimizations can be done because of the limited set of
supported features, and this text should not be considered for supported features, and this text should not be considered for
generic IKEv2 implementations (for example Message IDs can be done as generic IKEv2 implementations (for example, Message IDs can be done
specified because minimal implementation is only sending out as specified because minimal implementation is only sending out an
IKE_SA_INIT and IKE_AUTH request, and do not send any other request). IKE_SA_INIT and IKE_AUTH request and not any other request).
This document is intended to be stand-alone, meaning everything This document is intended to be standalone, meaning everything needed
needed to implement IKEv2 is copied here except the description of to implement IKEv2 is copied here except the description of the
the cryptographic algorithms. The IKEv2 specification has lots of cryptographic algorithms. The IKEv2 specification has lots of
background information and rationale which has been omitted from this background information and rationale that has been omitted from this
document. document.
Numerous additional numeric values from IANA registries have been Numerous additional numeric values from IANA registries have been
omitted from this document, only those which are of interest for a omitted from this document; only those which are of interest for a
minimal implementation are listed in this document. minimal implementation are listed.
The main body of this document describes how to use the shared secret The main body of this document describes how to use the shared secret
authentication in IKEv2, as it is easiest to implement. In some authentication in IKEv2, as it is easiest to implement. In some
cases that is not enough and Appendix B.2 describes how to use Raw cases, that is not enough, and Appendix B.2 describes how to use raw
Public keys instead of shared secret authentication. public keys instead of shared secret authentication.
For more information check the full IKEv2 specification in RFC 7296 For more information, check the full IKEv2 specification in [RFC7296]
[RFC7296] and [IKEV2IANA]. and [IKEV2IANA].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. The term document are to be interpreted as described in [RFC2119]. The term
"Constrained Node" is defined in the Terminology for Constrained-Node "Constrained Node" is defined in "Terminology for Constrained-Node
Networks document [RFC7228]. Networks" [RFC7228].
1.1. Use Cases 1.1. Use Cases
One use case for this kind of minimal implementation is in small One use case for this kind of minimal implementation is in small
devices doing machine-to-machine communication. In such environments devices doing machine-to-machine communication. In such
the node initiating connections can be very small and the other end environments, the node initiating connections can be very small, and
of the communication channel is some kind of larger device. the other end of the communication channel is some kind of larger
device.
An example of the small initiating node could be a remote garage door An example of the small initiating node could be a remote garage door
opener device, i.e., a device having buttons which open and close a opener device, i.e., a device having buttons that open and close a
garage door, and which connects to the home area network server over garage door and that connects to the home area network server over a
wireless link. wireless link.
Another example of such a device is some kind of sensor device, for Another example of such a device is some kind of sensor device, for
example a room temperature sensor, which sends periodic temperature example, a room temperature sensor, which sends periodic temperature
data to some centralized node. data to some centralized node.
Those devices are usually sleeping for a long time, and only wake up Those devices usually sleep for a long time and only wake up
because of user interaction or periodically. The data transfer is periodically or because of user interaction. The data transfer is
always initiated from that sleeping node when they wake up and after always initiated from that sleeping node when they wake up; after
they send packets there might be ACKs or other packets coming back they send packets, there might be ACKs or other packets coming back
before they go back to sleep. If some data needs to be transferred before they go back to sleep. If some data needs to be transferred
from a server node to the small device, it can be implemented by from a server node to the small device, it can be implemented by
polling, i.e. the small node periodically polls for the server to see polling, i.e., the small node periodically polls for the server to
if it for example has some configuration changes or similar. While see if it, for example, has some configuration changes or similar.
the device is sleeping it will not maintain the IKEv2 SA. That is, While the device is sleeping, it will not maintain the IKEv2 SA.
it will always create the IKEv2 SA again when it wakes up. This That is, it will always create the IKEv2 SA again when it wakes up.
means there is no need to do liveness checks for the server, as after This means there is no need to do liveness checks for the server, as
the device wakes up again the minimal implementation will start from after the device wakes up again, the minimal implementation will
the beginning again. start from the beginning again.
2. Exchanges 2. Exchanges
2.1. Initial Exchange 2.1. Initial Exchange
All IKEv2 communications consist of pairs of messages: a request and All IKEv2 communications consist of pairs of messages: a request and
a response. The pair is called an "exchange", and is sometimes a response. The pair is called an "exchange" and is sometimes called
called a "request/response pair". Every request requires a response. a "request/response pair". Every request requires a response.
For every pair of IKEv2 messages, the initiator is responsible for For every pair of IKEv2 messages, the initiator is responsible for
retransmission in the event of a timeout. The responder MUST never retransmission in the event of a timeout. The responder MUST never
retransmit a response unless it receives a retransmission of the retransmit a response unless it receives a retransmission of the
request. request.
IKEv2 is a reliable protocol: the initiator MUST retransmit a request IKEv2 is a reliable protocol: the initiator MUST retransmit a request
until it either receives a corresponding response or deems the IKE SA until it either receives a corresponding response or deems the IKE SA
to have failed. A retransmission from the initiator MUST be bitwise to have failed. A retransmission from the initiator MUST be bitwise
identical to the original request. Retransmission times MUST identical to the original request. Retransmission times MUST
increase exponentially. increase exponentially.
IKEv2 is run over UDP port 500. All IKEv2 implementations MUST be IKEv2 is run over UDP port 500. All IKEv2 implementations MUST be
able to send, receive, and process IKEv2 messages that are up to 1280 able to send, receive, and process IKEv2 messages that are up to 1280
octets long. An implementation MUST accept incoming requests even if octets long. An implementation MUST accept incoming requests even if
the source port is not 500, and MUST respond to the address and port the source port is not 500 and MUST respond to the address and port
from which the request was received. from which the request was received.
The minimal implementation of IKEv2 only uses the first two The minimal implementation of IKEv2 only uses the first two
exchanges, called IKE_SA_INIT and IKE_AUTH. These are used to create exchanges, called IKE_SA_INIT and IKE_AUTH. These are used to create
the IKE SA and the first Child SA. In addition to those messages, a the IKE SA and the first Child SA. In addition to those messages, a
minimal IKEv2 implementation needs to understand the CREATE_CHILD_SA minimal IKEv2 implementation needs to understand the CREATE_CHILD_SA
request enough to generate an CREATE_CHILD_SA response containing the request enough to generate a CREATE_CHILD_SA response containing the
NO_ADDITIONAL_SAS error notify. It needs to understand the NO_ADDITIONAL_SAS error notify. It needs to understand the
INFORMATIONAL request enough to generate an empty INFORMATIONAL INFORMATIONAL request enough to generate an empty INFORMATIONAL
response to it. There is no requirement to be able to respond to any response to it. There is no requirement to be able to respond to any
other requests. other requests.
All messages following the IKE_SA_INIT exchange are cryptographically All messages following the IKE_SA_INIT exchange are cryptographically
protected using the cryptographic algorithms and keys negotiated in protected using the cryptographic algorithms and keys negotiated in
the IKE_SA_INIT exchange. the IKE_SA_INIT exchange.
Every IKEv2 message contains a Message ID as part of its fixed Every IKEv2 message contains a Message ID as part of its fixed
header. This Message ID is used to match up requests and responses, header. This Message ID is used to match up requests and responses
and to identify retransmissions of messages. and to identify retransmissions of messages.
Minimal implementations only need to support the role of initiator, Minimal implementations only need to support the role of initiator,
so so it typically only sends an IKE_SA_INIT request which, when so it typically only sends an IKE_SA_INIT request that, when
answered, is followed by an IKE_AUTH. As those messages have fixed answered, is followed by an IKE_AUTH. As those messages have fixed
Message IDs (0 and 1) it does not need to keep track of its own Message IDs (0 and 1), it does not need to keep track of its own
Message IDs for outgoing requests after that. Message IDs for outgoing requests after that.
Minimal implementations can also optimize Message ID handling of the Minimal implementations can also optimize Message ID handling of the
incoming requests, as they do not need to protect incoming requests incoming requests, as they do not need to protect incoming requests
against replays. This is possible because minimal implementations against replays. This is possible because minimal implementations
will only return error or empty notification replies to incoming will only return error or empty notification replies to incoming
requests. This means that any of those incoming requests do not have requests. This means that any of those incoming requests do not have
any effect on the minimal implementation, thus processing them again any effect on the minimal implementation, thus processing them again
does not cause any harm. Because of this a minimal implementation does not cause any harm. Because of this, a minimal implementation
can always answer to request coming in, with the same Message ID than can always answer a request coming in, with the same Message ID than
what the request had and then forget the request/response pair what the request had, and then forget the request/response pair
immediately. This means there is no need to keep track of Message immediately. This means there is no need to keep track of Message
IDs of the incoming requests. IDs of the incoming requests.
In the following descriptions, the payloads contained in the message In the following descriptions, the payloads contained in the message
are indicated by the names listed below. are indicated by the names listed below.
Notation Payload Notation Payload
----------------------------------------- -----------------------------------------
AUTH Authentication AUTH Authentication
CERTREQ Certificate Request CERTREQ Certificate Request
skipping to change at page 7, line 10 skipping to change at page 7, line 47
and flags of various sorts. Each endpoint chooses one of the two and flags of various sorts. Each endpoint chooses one of the two
SPIs and MUST choose them so as to be unique identifiers of an IKE SPIs and MUST choose them so as to be unique identifiers of an IKE
SA. An SPI value of zero is special: it indicates that the remote SA. An SPI value of zero is special: it indicates that the remote
SPI value is not yet known by the sender. SPI value is not yet known by the sender.
Incoming IKEv2 packets are mapped to an IKE SA using only the Incoming IKEv2 packets are mapped to an IKE SA using only the
packet's SPI, not using (for example) the source IP address of the packet's SPI, not using (for example) the source IP address of the
packet. packet.
The SAi1 payload states the cryptographic algorithms the initiator The SAi1 payload states the cryptographic algorithms the initiator
supports for the IKE SA. The KEi and KEr payload contain Diffie- supports for the IKE SA. The KEi and KEr payloads contain Diffie-
Hellman values and Ni and Nr are the nonces. The SAr1 contains the Hellman values, and Ni and Nr are the nonces. The SAr1 contains the
chosen cryptographic suite from initiator's offered choices. A chosen cryptographic suite from the initiator's offered choices. A
minimal implementation using shared secrets will ignore the CERTREQ minimal implementation using shared secrets will ignore the CERTREQ
payload. payload.
Minimal implementation will most likely support exactly one set of Minimal implementation will most likely support exactly one set of
cryptographic algorithms, meaning the SAi1 payload will be static. cryptographic algorithms, meaning the SAi1 payload will be static.
It needs to check that the SAr1 received matches the proposal it It needs to check that the SAr1 received matches the proposal it
sent. sent.
At this point in the negotiation, each party can generate SKEYSEED, At this point in the negotiation, each party can generate SKEYSEED,
from which all keys are derived for that IKE SA. from which all keys are derived for that IKE SA.
skipping to change at page 7, line 51 skipping to change at page 8, line 40
exchange. g^ir is represented as a string of octets in big endian exchange. g^ir is represented as a string of octets in big endian
order padded with zeros if necessary to make it the length of the order padded with zeros if necessary to make it the length of the
modulus. Ni and Nr are the nonces, stripped of any headers. modulus. Ni and Nr are the nonces, stripped of any headers.
The SK_d is used for deriving new keys for the Child SAs. The SK_ai The SK_d is used for deriving new keys for the Child SAs. The SK_ai
and SK_ar are used as a key to the integrity protection algorithm for and SK_ar are used as a key to the integrity protection algorithm for
authenticating the component messages of subsequent exchanges. The authenticating the component messages of subsequent exchanges. The
SK_ei and SK_er are used for encrypting (and of course decrypting) SK_ei and SK_er are used for encrypting (and of course decrypting)
all subsequent exchanges. The SK_pi and SK_pr are used when all subsequent exchanges. The SK_pi and SK_pr are used when
generating an AUTH payload. The lengths of SK_d, SK_pi, and SK_pr generating an AUTH payload. The lengths of SK_d, SK_pi, and SK_pr
MUST be the preferred key length of the PRF agreed upon. MUST be the preferred key length of the Pseudorandom Function (PRF)
agreed upon.
A separate SK_e and SK_a is computed for each direction. The keys A separate SK_e and SK_a is computed for each direction. The keys
used to protect messages from the original initiator are SK_ai and used to protect messages from the original initiator are SK_ai and
SK_ei. The keys used to protect messages in the other direction are SK_ei. The keys used to protect messages in the other direction are
SK_ar and SK_er. The notation SK { ... } indicates that these SK_ar and SK_er. The notation SK { ... } indicates that these
payloads are encrypted and integrity protected using that direction's payloads are encrypted and integrity protected using that direction's
SK_e and SK_a. SK_e and SK_a.
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1), Flags: Initiator, Message ID=1),
SK {IDi, AUTH, SAi2, TSi, TSr, SK {IDi, AUTH, SAi2, TSi, TSr,
N(INITIAL_CONTACT)} --> N(INITIAL_CONTACT)} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags: <-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1), Response, Message ID=1),
SK {IDr, AUTH, SAr2, TSi, TSr} SK {IDr, AUTH, SAr2, TSi, TSr}
The initiator asserts its identity with the IDi payload, proves The initiator asserts its identity with the IDi payload, proves
knowledge of the secret corresponding to IDi and integrity protects knowledge of the secret corresponding to IDi, and integrity protects
the contents of the first message using the AUTH payload. The the contents of the first message using the AUTH payload. The
responder asserts its identity with the IDr payload, authenticates responder asserts its identity with the IDr payload, authenticates
its identity and protects the integrity of the second message with its identity, and protects the integrity of the second message with
the AUTH payload. the AUTH payload.
As minimal implementation usually has only one host where it As minimal implementation usually has only one host where it
connects, and that means it has only one shared secret. This means connects, that means it has only one shared secret. This means it
it does not need to care about IDr payload that much. If the other does not need to care about the IDr payload that much. If the other
end sends AUTH payload which initiator can verify using the shared end sends an AUTH payload that the initiator can verify using the
secret it has, then it knows the other end is the peer it was shared secret it has, then it knows the other end is the peer it was
configured to talk to. configured to talk to.
In the IKE_AUTH request, the initiator sends the SA offer(s) in the In the IKE_AUTH request, the initiator sends the SA offer(s) in the
SAi2 payload, and the proposed Traffic Selectors for the Child SA in SAi2 payload and the proposed Traffic Selectors (TSs) for the Child
the TSi and TSr payloads. The responder replies with the accepted SA in the TSi and TSr payloads. The responder replies with the
offer in an SAr2 payload, and with the selected Traffic Selectors. accepted offer in an SAr2 payload and with the selected Traffic
The selected Traffic Selectors may be a subset of what the initiator Selectors. The selected Traffic Selectors may be a subset of what
proposed. the initiator proposed.
In the minimal implementation both SA payloads and TS payloads are In the minimal implementation, both SA payloads and TS payloads are
going to be mostly static. The SA payload will have the SPI value going to be mostly static. The SA payload will have the SPI value
used in the Encapsulating Security Payload (ESP), but the algorithms used in the Encapsulating Security Payload (ESP), but the algorithms
are most likely going to be the one and only supported set. The TS are most likely going to be the one and only supported set. The TS
payloads on the initiator end will most likely say from any to any, payloads on the initiator end will most likely say from any to any,
i.e. full wildcard ranges, or from the local IP to the remote IP. In i.e., full wildcard ranges, or from the local IP to the remote IP.
the wildcard case the responder quite often narrows the range down to In the wildcard case, the responder quite often narrows the range
the one IP address pair. Using a single IP address pair as the down to the one IP address pair. Using a single IP address pair as
Traffic Selectors when sending the IKE_AUTH request will simplify the Traffic Selectors when sending the IKE_AUTH request will simplify
processing as the responder will either accept the IP address pair or processing as the responder will either accept the IP address pair or
return an error. If wildcard ranges are used, there is a possibility return an error. If wildcard ranges are used, there is a possibility
that the responder will narrow the Traffic Selector range to range that the responder will narrow the Traffic Selector range to range
that is not acceptable by the initiator. that is not acceptable by the initiator.
The IKE_AUTH (and IKE_SA_INIT) responses may contain multiple status The IKE_AUTH (and IKE_SA_INIT) response may contain multiple status
notification payloads which can be ignored by minimal notification payloads that can be ignored by minimal implementations.
implementations. There can also be Vendor ID, Certificate,
Certificate Request or Configuration payloads, but any payload There can also be Vendor ID, Certificate, Certificate Request, or
unknown to minimal implementations can simply be skipped over Configuration payloads, but any payload unknown to minimal
(response messages cannot have critical unsupported payloads). implementations can simply be skipped over (response messages cannot
have critical unsupported payloads).
The exchange above includes N(INITIAL_CONTACT) notification in the The exchange above includes N(INITIAL_CONTACT) notification in the
request as that is quite commonly sent by a minimal implementation. request as that is quite commonly sent by a minimal implementation.
It indicates to the other end that the initiator does not have any It indicates to the other end that the initiator does not have any
other IKE SAs between it and the responder, and if there is any left other IKE SAs between it and the responder, and if there is any left
from previous runs those can be deleted by the responder. As minimal from previous runs, those can be deleted by the responder. As
implementations delete IKE SAs without sending IKE SA delete minimal implementations delete IKE SAs without sending IKE SA delete
requests, this will help the responder to clean up leftover state. requests, this will help the responder to clean up leftover state.
When using shared secret authentication, the peers are authenticated When using shared secret authentication, the peers are authenticated
by having each calculating a MAC over a block of data: by having each calculating a Message Authentication Code (MAC) over a
block of data:
For the initiator: For the initiator:
AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
<InitiatorSignedOctets>) <InitiatorSignedOctets>)
For the responder: For the responder:
AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
<ResponderSignedOctets>) <ResponderSignedOctets>)
The string "Key Pad for IKEv2" is 17 ASCII characters without null The string "Key Pad for IKEv2" is 17 ASCII characters without null
termination. The implementation can precalculate the inner prf and termination. The implementation can precalculate the inner prf and
only store the output of it. This is possible because a minimal only store the output of it. This is possible because a minimal
IKEv2 implementation usually only supports one PRF. IKEv2 implementation usually only supports one PRF.
In following calculations, IDi' and IDr' are the entire ID payloads In the following calculations, IDi' and IDr' are the entire ID
excluding the fixed header and the Ni and Nr are only the value, not payloads excluding the fixed header, and the Ni and Nr are only the
the payload containing it. Note that neither the nonce Ni/Nr nor the values, not the payloads containing it. Note that neither the nonce
value prf(SK_pr, IDr')/prf(SK_pi, IDi') are transmitted. Ni/Nr nor the value prf(SK_pr, IDr')/prf(SK_pi, IDi') are
transmitted.
The initiator signs the first message (IKE_SA_INIT request), starting The initiator signs the first message (IKE_SA_INIT request), starting
with the first octet of the first SPI in the header and ending with with the first octet of the first SPI in the header and ending with
the last octet of the last payload in that first message. Appended the last octet of the last payload in that first message. Appended
to this (for purposes of computing the signature) are the responder's to this (for purposes of computing the signature) are the responder's
nonce Nr, and the value prf(SK_pi, IDi'). nonce Nr and the value prf(SK_pi, IDi').
For the responder, the octets to be signed start with the first octet For the responder, the octets to be signed start with the first octet
of the first SPI in the header of the second message (IKE_SA_INIT of the first SPI in the header of the second message (IKE_SA_INIT
response) and end with the last octet of the last payload in that response) and end with the last octet of the last payload in that
second message. Appended to this are the initiator's nonce Ni, and second message. Appended to this are the initiator's nonce Ni and
the value prf(SK_pr, IDr'). the value prf(SK_pr, IDr').
The initiator's signed octets can be described as: The initiator's signed octets can be described as:
InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
RealIKEHDR = SPIi | SPIr | . . . | Length RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage1 = RealIKEHDR | RestOfMessage1 RealMessage1 = RealIKEHDR | RestOfMessage1
NonceRPayload = PayloadHeader | NonceRData NonceRPayload = PayloadHeader | NonceRData
InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData RestOfInitIDPayload = IDType | RESERVED | InitIDData
skipping to change at page 10, line 32 skipping to change at page 11, line 29
RealMessage2 = RealIKEHDR | RestOfMessage2 RealMessage2 = RealIKEHDR | RestOfMessage2
NonceIPayload = PayloadHeader | NonceIData NonceIPayload = PayloadHeader | NonceIData
ResponderIDPayload = PayloadHeader | RestOfRespIDPayload ResponderIDPayload = PayloadHeader | RestOfRespIDPayload
RestOfRespIDPayload = IDType | RESERVED | RespIDData RestOfRespIDPayload = IDType | RESERVED | RespIDData
MACedIDForR = prf(SK_pr, RestOfRespIDPayload) MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
Note that all of the payloads inside the RestOfMessageX are included Note that all of the payloads inside the RestOfMessageX are included
under the signature, including any payload types not listed in this under the signature, including any payload types not listed in this
document. document.
The initiator might also get an unauthenticated response back having The initiator might also get an unauthenticated response back that
a notification payload with an error code inside. As that error code has a notification payload with an error code inside. As that error
will be unauthenticated and may be faked, there is no need to do code will be unauthenticated and may be faked, there is no need to do
anything for those. A minimal implementation can simply ignore those anything for those. A minimal implementation can simply ignore those
errors, and retransmit its request until it times out and if that errors and retransmit its request until it times out, and if that
happens then the IKE SA (and Child SA) creation failed. happens, then the IKE SA (and Child SA) creation failed.
The responder might also reply with an IKE_AUTH response packet which The responder might also reply with an IKE_AUTH response packet that
does not contain the payloads needed to set up a Child SA (SAr2, TSi does not contain the payloads needed to set up a Child SA (SAr2, TSi,
and TSr), but instead contain AUTH payload and an error. Minimal and TSr) but instead contain AUTH payload and an error. Minimal
implementation that do not support the CREATE_CHILD_SA exchange implementation that does not support the CREATE_CHILD_SA exchange
cannot recover from this scenario. It can delete the IKE SA and cannot recover from this scenario. It can delete the IKE SA and
start over from the beginning (which might fail again if this is a start over from the beginning (which might fail again if this is a
configuration error, or it might succeed if this was temporal configuration error, or it might succeed if this was temporal
failure). failure).
2.2. Other Exchanges 2.2. Other Exchanges
Minimal implementations MUST be able to reply to INFORMATIONAL Minimal implementations MUST be able to reply to INFORMATIONAL
requests by sending back an empty INFORMATIONAL response: requests by sending back an empty INFORMATIONAL response:
skipping to change at page 11, line 38 skipping to change at page 12, line 38
<-- HDR(SPIi=xxx, SPIy=yyy, CREATE_CHILD_SA, <-- HDR(SPIi=xxx, SPIy=yyy, CREATE_CHILD_SA,
Flags: none, Message ID=m), Flags: none, Message ID=m),
SK {...} SK {...}
HDR(SPIi=xxx, SPIr=yyy, CREATE_CHILD_SA, HDR(SPIi=xxx, SPIr=yyy, CREATE_CHILD_SA,
Flags: Initiator | Response, Message ID=m), Flags: Initiator | Response, Message ID=m),
SK {N(NO_ADDITIONAL_SAS)} --> SK {N(NO_ADDITIONAL_SAS)} -->
Note that INFORMATIONAL and CREATE_CHILD_SA requests might contain Note that INFORMATIONAL and CREATE_CHILD_SA requests might contain
unsupported critical payloads, in which case a compliant unsupported critical payloads, in which case a compliant
implementation MUST ignore the request, and send a response message implementation MUST ignore the request and send a response message
back having the UNSUPPORTED_CRITICAL_PAYLOAD notification. That back that has the UNSUPPORTED_CRITICAL_PAYLOAD notification. That
notification payload data contains a one-octet payload type of the notification payload data contains a 1-octet payload type of the
unsupported critical payload. unsupported critical payload.
2.3. Generating Keying Material 2.3. Generating Keying Material
The keying material for the Child SA created by the IKE_AUTH exchange The keying material for the Child SA created by the IKE_AUTH exchange
is generated as follows: is generated as follows:
KEYMAT = prf+(SK_d, Ni | Nr) KEYMAT = prf+(SK_d, Ni | Nr)
Where Ni and Nr are the nonces from the IKE_SA_INIT exchange. Where Ni and Nr are the nonces from the IKE_SA_INIT exchange.
A single CHILD_SA negotiation may result in multiple Security A single CHILD_SA negotiation may result in multiple Security
Associations. ESP and AH SAs exist in pairs (one in each direction), Associations. ESP and Authentication Header (AH) SAs exist in pairs
so two SAs are created in a single Child SA negotiation for them. (one in each direction), so two SAs are created in a single Child SA
The keying material for each Child SA MUST be taken from the expanded negotiation for them. The keying material for each Child SA MUST be
KEYMAT using the following rules: taken from the expanded KEYMAT using the following rules:
o All keys for SAs carrying data from the initiator to the responder o All keys for SAs carrying data from the initiator to the responder
are taken before SAs going from the responder to the initiator. are taken before SAs going from the responder to the initiator.
o If an IPsec protocol requires multiple keys, the order in which o If an IPsec protocol requires multiple keys, the order in which
they are taken from the SA's keying material needs to be described they are taken from the SA's keying material needs to be described
in the protocol's specification. For ESP and AH, [IPSECARCH] in the protocol's specification. For ESP and AH, [IPSECARCH]
defines the order, namely: the encryption key (if any) MUST be defines the order, namely: the encryption key (if any) MUST be
taken from the first bits and the integrity key (if any) MUST be taken from the first bits, and the integrity key (if any) MUST be
taken from the remaining bits. taken from the remaining bits.
Each cryptographic algorithm takes a fixed number of bits of keying Each cryptographic algorithm takes a fixed number of bits of keying
material specified as part of the algorithm, or negotiated in SA material specified as part of the algorithm or negotiated in SA
payloads. payloads.
3. Conformance Requirements 3. Conformance Requirements
For an implementation to be called conforming to RFC 7296 For an implementation to be called conforming to the RFC 7296
specification, it MUST be possible to configure it to accept the specification, it MUST be possible to configure it to accept the
following: following:
o Public Key Infrastructure using X.509 (PKIX) Certificates o Public Key Infrastructure using X.509 (PKIX) Certificates
containing and signed by RSA keys of size 1024 or 2048 bits, where containing and signed by RSA keys of size 1024 or 2048 bits, where
the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or
ID_DER_ASN1_DN. ID_DER_ASN1_DN.
o Shared key authentication where the ID passed is any of ID_KEY_ID, o Shared key authentication where the ID passed is any of ID_KEY_ID,
ID_FQDN, or ID_RFC822_ADDR. ID_FQDN, or ID_RFC822_ADDR.
o Authentication where the responder is authenticated using PKIX o Authentication where the responder is authenticated using PKIX
Certificates and the initiator is authenticated using shared key Certificates, and the initiator is authenticated using shared key
authentication. authentication.
This document only supports the second bullet, it does not support This document only supports the second bullet; it does not support
PKIX certificates at all. As full RFC 7296 responders must also PKIX Certificates at all. As full RFC 7296 responders must also
support that shared key authentication, this allows a minimal support that shared key authentication, this allows a minimal
implementation to be able to interoperate with all RFC 7296 compliant implementation to be able to interoperate with all implementations
implementations. that are compliant with RFC 7296.
PKIX certificates are left out from the minimal implementation as PKIX Certificates are left out from the minimal implementation as
those would add quite a lot of complexity to the implementation. The those would add quite a lot of complexity to the implementation. The
actual code changes needed in the IKEv2 protocol are small, but the actual code changes needed in the IKEv2 protocol are small, but the
certificate validation code would be more complex than the whole certificate validation code would be more complex than the whole
minimal IKEv2 implementation itself. If public key based minimal IKEv2 implementation itself. If public-key-based
authentication is needed for scalability reasons, then raw public authentication is needed for scalability reasons, then raw public
keys would probably be the best compromise (see Appendix B.2). keys would probably be the best compromise (see Appendix B.2).
4. Implementation Status 4. Implementation Status
This document describes a minimal implementation written by the This document describes a minimal implementation written by the
author of this document. The minimal implementation supported the author of this document. The minimal implementation supported the
base IKE_SA_INIT and IKE_AUTH exchanges, and successfully base IKE_SA_INIT and IKE_AUTH exchanges and successfully
interoperated with a full IKEv2 server. This minimal implementation interoperated with a full IKEv2 server. This minimal implementation
was presented in the Interconnecting Smart Objects with Internet was presented in the Interconnecting Smart Objects with Internet
Workshop in Prague March 2011 ([Kiv11]). This implementation was Workshop in Prague in March 2011 [Kiv11]. This implementation was
written as proof of concept in perl. written as proof of concept in perl.
There was another proof of concept implementation written in python, There was another proof-of-concept implementation written in python,
which also interoperated with a full IKEv2 server. which also interoperated with a full IKEv2 server.
Both implementations were written just for demonstration purposes, Both implementations were written just for demonstration purposes and
and included fixed configuration built in to the code, and both also included fixed configuration built into the code, and both also
implemented ESP, ICMP and IP layers to the level that was needed to implemented ESP, ICMP, and IP layers to the level that was needed to
send and receive one ICMP echo packet. Both implementations were send and receive one ICMP echo packet. Both implementations were
about 1000 lines of code excluding cryptographic libraries but about 1000 lines of code excluding cryptographic libraries but
including ESP, ICMP and IP layers. including ESP, ICMP, and IP layers.
5. Security Considerations 5. Security Considerations
As this implements same protocol as RFC 7296 this means all security As this implements the same protocol as RFC 7296, this means all
considerations from it also apply to this document. security considerations from it also apply to this document.
6. IANA Considerations
There is no new IANA considerations in this document.
7. Acknowledgements
Most of the content of this document is copied from the RFC 7296.
8. References 6. References
8.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>. 2014, <http://www.rfc-editor.org/info/rfc7296>.
8.2. Informative References 6.2. Informative References
[I-D.kivinen-ipsecme-oob-pubkey] [EAI] Yang, A., Steele, S., and N. Freed, "Internationalized
Kivinen, T., Wouters, P., and H. Tschofenig, "Generic Raw Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
Public Key Support for IKEv2", draft-kivinen-ipsecme-oob- 2012, <http://www.rfc-editor.org/info/rfc6532>.
pubkey-14 (work in progress), October 2015.
[IDNA] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>.
[IKEV2IANA] [IKEV2IANA]
"Internet Key Exchange Version 2 (IKEv2) Parameters", IANA, "Internet Key Exchange Version 2 (IKEv2)
<http://www.iana.org>. Parameters",
<http://www.iana.org/assignments/ikev2-parameters>.
[Kiv11] Kivinen, T., "IKEv2 and Smart Objects", March 2011, [IPSEARCH] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[Kiv11] Kivinen, T., "Interconnecting Smart Objects with Internet
Workshop 2011-03025; IKEv2 and Smart Objects", March 2011,
<https://www.iab.org/wp-content/IAB-uploads/2011/04/ <https://www.iab.org/wp-content/IAB-uploads/2011/04/
Kivinen.pdf>. Kivinen.pdf>.
[MODES] National Institute of Standards and Technology, U.S. [MODES] National Institute of Standards and Technology, U.S.
Department of Commerce, "Recommendation for Block Cipher Department of Commerce, "Recommendation for Block Cipher
Modes of Operation", SP 800-38A, 2001. Modes of Operation", SP 800-38A, 2001.
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, DOI 10.17487/ Constrained-Node Networks", RFC 7228,
RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>. <http://www.rfc-editor.org/info/rfc7228>.
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
Method in the Internet Key Exchange Protocol Version 2 Method in the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
<http://www.rfc-editor.org/info/rfc7619>. <http://www.rfc-editor.org/info/rfc7619>.
[RFC7670] Kivinen, T., Wouters, P., and H. Tschofenig, "Generic Raw
Public-Key Support for IKEv2", RFC 7670,
DOI 10.17487/RFC7670, January 2016,
<http://www.rfc-editor.org/info/rfc7670>.
Appendix A. Header and Payload Formats Appendix A. Header and Payload Formats
This appendix describes actual packet payload formats. This is This appendix describes actual packet payload formats. This is
required to make the document self contained. The descriptions are required to make the document self-contained. The descriptions are
mostly copied from the RFC7296 and more information can be found from mostly copied from RFC 7296, and more information can be found from
there. there.
Various payload contains RESERVED fields and those MUST be sent as Various payloads contain RESERVED fields, and those MUST be sent as
zero and MUST be ignored on receipt. zero and MUST be ignored on receipt.
All multi-octet fields representing integers are laid out in big All multi-octet fields representing integers are laid out in big
endian order (also known as "most significant byte first", or endian order (also known as "most significant byte first" or "network
"network byte order"). byte order").
A.1. The IKE Header A.1. The IKE Header
Each IKEv2 message begins with the IKE header, denoted HDR in this Each IKEv2 message begins with the IKE header, denoted HDR in this
document. Following the header are one or more IKE payloads each document. Following the header are one or more IKE payloads each
identified by a "Next Payload" field in the preceding payload. identified by a Next Payload field in the preceding payload.
Payloads are identified in the order in which they appear in an IKE 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 message by looking in the Next Payload field in the IKE header and,
subsequently according to the "Next Payload" field in the IKE payload subsequently, according to the Next Payload field in the IKE payload
itself until a "Next Payload" field of zero indicates that no itself until a Next Payload field of zero indicates that no payloads
payloads follow. If a payload of type "Encrypted" is found, that follow. If a payload of type "Encrypted" is found, that payload is
payload is decrypted and its contents parsed as additional payloads. decrypted and its contents parsed as additional payloads. An
An Encrypted payload MUST be the last payload in a packet and an Encrypted payload MUST be the last payload in a packet, and an
Encrypted payload MUST NOT contain another Encrypted payload. Encrypted payload MUST NOT contain another Encrypted payload.
The format of the IKE header is shown in Figure 1. The format of the IKE header is shown in Figure 1.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE SA Initiator's SPI | | IKE SA Initiator's SPI |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 16 skipping to change at page 18, line 24
immediately follows the header. The format and value of each immediately follows the header. The format and value of each
payload are defined below. payload are defined below.
o Major Version (4 bits) - Indicates the major version of the IKE o Major Version (4 bits) - Indicates the major version of the IKE
protocol in use. Implementations based on this version of IKE protocol in use. Implementations based on this version of IKE
MUST set the major version to 2 and MUST drop the messages with a MUST set the major version to 2 and MUST drop the messages with a
higher major version number. higher major version number.
o Minor Version (4 bits) - Indicates the minor version of the IKE o Minor Version (4 bits) - Indicates the minor version of the IKE
protocol in use. Implementations based on this version of IKE protocol in use. Implementations based on this version of IKE
MUST set the minor version to 0. They MUST ignore the minor MUST set the minor version to zero. They MUST ignore the minor
version number of received messages. version number of received messages.
o Exchange Type (1 octet) - Indicates the type of exchange being o Exchange Type (1 octet) - Indicates the type of exchange being
used. This constrains the payloads sent in each message in an used. This constrains the payloads sent in each message in an
exchange. exchange.
Exchange Type Value Exchange Type Value
---------------------------------- ----------------------------------
IKE_SA_INIT 34 IKE_SA_INIT 34
IKE_AUTH 35 IKE_AUTH 35
skipping to change at page 16, line 50 skipping to change at page 19, line 17
cleared when sending and MUST be ignored on receipt. cleared when sending and MUST be ignored on receipt.
* R (Response) - This bit indicates that this message is a * R (Response) - This bit indicates that this message is a
response to a message containing the same Message ID. This bit response to a message containing the same Message ID. This bit
MUST be cleared in all request messages and MUST be set in all MUST be cleared in all request messages and MUST be set in all
responses. An IKEv2 endpoint MUST NOT generate a response to a responses. An IKEv2 endpoint MUST NOT generate a response to a
message that is marked as being a response. message that is marked as being a response.
* V (Version) - This bit indicates that the transmitter is * V (Version) - This bit indicates that the transmitter is
capable of speaking a higher major version number of the capable of speaking a higher major version number of the
protocol than the one indicated in the major version number protocol than the one indicated in the Major Version field.
field. Implementations of IKEv2 MUST clear this bit when Implementations of IKEv2 MUST clear this bit when sending and
sending and MUST ignore it in incoming messages. MUST ignore it in incoming messages.
* I (Initiator) - This bit MUST be set in messages sent by the * I (Initiator) - This bit MUST be set in messages sent by the
original initiator of the IKE SA and MUST be cleared in original initiator of the IKE SA and MUST be cleared in
messages sent by the original responder. It is used by the messages sent by the original responder. It is used by the
recipient to determine which eight octets of the SPI were recipient to determine which 8 octets of the SPI were generated
generated by the recipient. This bit changes to reflect who by the recipient. This bit changes to reflect who initiated
initiated the last rekey of the IKE SA. the last rekey of the IKE SA.
o Message ID (4 octets, unsigned integer) - Message identifier used o Message ID (4 octets, unsigned integer) - Message identifier used
to control retransmission of lost packets and matching of requests to control retransmission of lost packets and matching of requests
and responses. It is essential to the security of the protocol and responses. It is essential to the security of the protocol
because it is used to prevent message replay attacks. because it is used to prevent message replay attacks.
o Length (4 octets, unsigned integer) - Length of the total message o Length (4 octets, unsigned integer) - Length of the total message
(header + payloads) in octets. (header + payloads) in octets.
A.2. Generic Payload Header A.2. Generic Payload Header
Each IKE payload begins with a generic payload header, shown in Each IKE payload begins with a generic payload header, as shown in
Figure 2. Figures for each payload below will include the generic Figure 2. Figures for each payload below will include the generic
payload header, but for brevity, the description of each field will payload header, but for brevity, the description of each field will
be omitted. be omitted.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Generic Payload Header Figure 2: Generic Payload Header
The Generic Payload Header fields are defined as follows: The Generic Payload Header fields are defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of the o Next Payload (1 octet) - Identifier for the payload type of the
next payload in the message. If the current payload is the last next payload in the message. If the current payload is the last
in the message, then this field will be 0. This field provides a in the message, then this field will be zero. This field provides
"chaining" capability whereby additional payloads can be added to a "chaining" capability whereby additional payloads can be added
a message by appending each one to the end of the message and to a message by appending each one to the end of the message and
setting the "Next Payload" field of the preceding payload to setting the Next Payload field of the preceding payload to
indicate the new payload's type. An Encrypted payload, which must indicate the new payload's type. An Encrypted payload, which must
always be the last payload of a message, is an exception. It always be the last payload of a message, is an exception. It
contains data structures in the format of additional payloads. In contains data structures in the format of additional payloads. In
the header of an Encrypted payload, the Next Payload field is set the header of an Encrypted payload, the Next Payload field is set
to the payload type of the first contained payload (instead of 0); to the payload type of the first contained payload (instead of
conversely, the Next Payload field of the last contained payload zero); conversely, the Next Payload field of the last contained
is set to zero). The payload type values needed for minimal payload is set to zero). The payload type values needed for
implementations are listed here. minimal implementations are listed here.
Next Payload Type Notation Value Next Payload Type Notation Value
-------------------------------------------------- --------------------------------------------------
No Next Payload 0 No Next Payload 0
Security Association SA 33 Security Association SA 33
Key Exchange KE 34 Key Exchange KE 34
Identification - Initiator IDi 35 Identification - Initiator IDi 35
Identification - Responder IDr 36 Identification - Responder IDr 36
Certificate CERT 37 Certificate CERT 37
Certificate Request CERTREQ 38 Certificate Request CERTREQ 38
skipping to change at page 18, line 25 skipping to change at page 20, line 42
Nonce Ni, Nr 40 Nonce Ni, Nr 40
Notify N 41 Notify N 41
Delete D 42 Delete D 42
Traffic Selector - Initiator TSi 44 Traffic Selector - Initiator TSi 44
Traffic Selector - Responder TSr 45 Traffic Selector - Responder TSr 45
Encrypted and Authenticated SK 46 Encrypted and Authenticated SK 46
o Critical (1 bit) - MUST be set to zero if the sender wants the o Critical (1 bit) - MUST be set to zero if the sender wants the
recipient to skip this payload if it does not understand the recipient to skip this payload if it does not understand the
payload type code in the Next Payload field of the previous payload type code in the Next Payload field of the previous
payload. MUST be set to one if the sender wants the recipient to payload. MUST be set to 1 if the sender wants the recipient to
reject this entire message if it does not understand the payload reject this entire message if it does not understand the payload
type. MUST be ignored by the recipient if the recipient type. MUST be ignored by the recipient if the recipient
understands the payload type code. MUST be set to zero for understands the payload type code. MUST be set to zero for
payload types defined in this document. Note that the critical payload types defined in this document. Note that the critical
bit applies to the current payload rather than the "next" payload bit applies to the current payload rather than the "next" payload
whose type code appears in the first octet. whose type code appears in the first octet.
o Payload Length (2 octets, unsigned integer) - Length in octets of o Payload Length (2 octets, unsigned integer) - Length in octets of
the current payload, including the generic payload header. the current payload, including the generic payload header.
A.3. Security Association Payload A.3. Security Association Payload
The Security Association payload, denoted SA in this document, is The Security Association payload, denoted SA in this document, is
used to negotiate attributes of a Security Association. used to negotiate attributes of a Security Association.
An SA payload consists of one or more proposals. Each proposal An SA payload consists of one or more proposals. Each proposal
includes one protocol. Each protocol contains one or more transforms includes one protocol. Each protocol contains one or more transforms
-- each specifying a cryptographic algorithm. Each transform -- each specifying a cryptographic algorithm. Each transform
contains zero or more attributes (attributes are needed only if the contains zero or more attributes (attributes are needed only if the
Transform ID does not completely specify the cryptographic algorithm, Transform ID does not completely specify the cryptographic algorithm;
currently only attribute is key length attribute for variable length currently, the only attribute is the Key Length attribute for
ciphers, meaning there is exactly zero or one attribute). variable-length ciphers, meaning there is exactly zero or one
attribute).
The responder MUST choose a single suite, which may be any subset of The responder MUST choose a single suite, which may be any subset of
the SA proposal following the rules below. the SA proposal following the rules below.
Each proposal contains one protocol. If a proposal is accepted, the Each proposal contains one protocol. If a proposal is accepted, the
SA response MUST contain the same protocol. Each IPsec protocol SA response MUST contain the same protocol. Each IPsec protocol
proposal contains one or more transforms. Each transform contains a proposal contains one or more transforms. Each transform contains a
Transform Type. The accepted cryptographic suite MUST contain Transform Type. The accepted cryptographic suite MUST contain
exactly one transform of each type included in the proposal. For exactly one transform of each type included in the proposal. For
example: if an ESP proposal includes transforms ENCR_3DES, ENCR_AES example: if an ESP proposal includes transforms ENCR_3DES, ENCR_AES
w/keysize 128, ENCR_AES w/keysize 256, AUTH_HMAC_MD5, and w/keysize 128, ENCR_AES w/keysize 256, AUTH_HMAC_MD5, and
AUTH_HMAC_SHA, the accepted suite MUST contain one of the ENCR_ AUTH_HMAC_SHA, the accepted suite MUST contain one of the ENCR_
transforms and one of the AUTH_ transforms. Thus, six combinations transforms and one of the AUTH_ transforms. Thus, six combinations
are acceptable. are acceptable.
Minimal implementation can create very simple SA proposal, i.e. Minimal implementation can create very simple SA proposal, i.e.,
include one proposal, which contains exactly one transform for each include one proposal, which contains exactly one transform for each
transform type. It is important to only include one Diffie-Hellman Transform Type. It is important to only include one Diffie-Hellman
group in proposal, so there is no need to do INVALID_KE_PAYLOAD group in the proposal, so there is no need to do INVALID_KE_PAYLOAD
processing in responses. processing in responses.
When parsing an SA, an implementation MUST check that the total When parsing an SA, an implementation MUST check that the total
Payload Length is consistent with the payload's internal lengths and Payload Length is consistent with the payload's internal lengths and
counts. Proposals, Transforms, and Attributes each have their own counts. Proposals, Transforms, and Attributes each have their own
variable-length encodings. They are nested such that the Payload variable-length encodings. They are nested such that the Payload
Length of an SA includes the combined contents of the SA, Proposal, Length of an SA includes the combined contents of the SA, Proposal,
Transform, and Attribute information. The length of a Proposal Transform, and Attribute information. The length of a Proposal
includes the lengths of all Transforms and Attributes it contains. includes the lengths of all Transforms and Attributes it contains.
The length of a Transform includes the lengths of all Attributes it The length of a Transform includes the lengths of all Attributes it
skipping to change at page 19, line 51 skipping to change at page 22, line 20
in the header of each transform. in the header of each transform.
If there are multiple transforms with the same Transform Type, the If there are multiple transforms with the same Transform Type, the
proposal is an OR of those transforms. If there are multiple proposal is an OR of those transforms. If there are multiple
transforms with different Transform Types, the proposal is an AND of transforms with different Transform Types, the proposal is an AND of
the different groups. the different groups.
A given transform MAY have one or more Attributes. Attributes are A given transform MAY have one or more Attributes. Attributes are
necessary when the transform can be used in more than one way, as necessary when the transform can be used in more than one way, as
when an encryption algorithm has a variable key size. The transform when an encryption algorithm has a variable key size. The transform
would specify the algorithm and the attribute would specify the key would specify the algorithm, and the attribute would specify the key
size. To propose alternate values for an attribute (for example, size. To propose alternate values for an attribute (for example,
multiple key sizes for the AES encryption algorithm), an multiple key sizes for the AES encryption algorithm), an
implementation MUST include multiple transforms with the same implementation MUST include multiple transforms with the same
Transform Type each with a single Attribute. Transform Type each with a single Attribute.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 17 skipping to change at page 23, line 47
Protocol Protocol ID Protocol Protocol ID
----------------------------------- -----------------------------------
IKE 1 IKE 1
AH 2 AH 2
ESP 3 ESP 3
o SPI Size (1 octet) - For an initial IKE SA negotiation, this field o SPI Size (1 octet) - For an initial IKE SA negotiation, this field
MUST be zero; the SPI is obtained from the outer header. During MUST be zero; the SPI is obtained from the outer header. During
subsequent negotiations, it is equal to the size, in octets, of subsequent negotiations, it is equal to the size, in octets, of
the SPI of the corresponding protocol (8 for IKE, 4 for ESP and the SPI of the corresponding protocol (8 for IKE and 4 for ESP and
AH). AH).
o Num Transforms (1 octet) - Specifies the number of transforms in o Num Transforms (1 octet) - Specifies the number of transforms in
this proposal. this proposal.
o SPI (variable) - The sending entity's SPI. When the SPI Size o SPI (variable) - The sending entity's SPI. When the SPI Size
field is zero, this field is not present in the Security field is zero, this field is not present in the Security
Association payload. Association payload.
o Transforms (variable) - One or more transform substructures. o Transforms (variable) - One or more transform substructures.
skipping to change at page 22, line 42 skipping to change at page 25, line 32
ENCR_AES_CBC 12 ENCR_AES_CBC 12
ENCR_AES-CCM_8 14 ENCR_AES-CCM_8 14
For Transform Type 2 (Pseudorandom Function), the relevant Transform For Transform Type 2 (Pseudorandom Function), the relevant Transform
IDs are listed below. IDs are listed below.
Name Number Name Number
---------------------------------- ----------------------------------
PRF_HMAC_SHA1 2 PRF_HMAC_SHA1 2
For Transform Type 3 (Integrity Algorithm), relevant Transform IDs For Transform Type 3 (Integrity Algorithm), the relevant Transform
are listed below. IDs are listed below.
Name Number Name Number
--------------------------- ---------------------------
AUTH_HMAC_SHA1_96 2 AUTH_HMAC_SHA1_96 2
AUTH_AES_XCBC_96 5 AUTH_AES_XCBC_96 5
For Transform Type 4 (Diffie-Hellman group), relevant Transform IDs For Transform Type 4 (Diffie-Hellman group), the relevant Transform
are listed below. IDs are listed below.
Name Number Name Number
------------------------- -------------------------
1536-bit MODP 5 1536-bit MODP 5
2048-bit MODP 14 2048-bit MODP 14
For Transform Type 5 (Extended Sequence Numbers), the relevant
For Transform Type 5 (Extended Sequence Numbers), relevant Transform Transform IDs are listed below.
IDs are listed below.
Name Number Name Number
-------------------------------------------- --------------------------------------------
No Extended Sequence Numbers 0 No Extended Sequence Numbers 0
Extended Sequence Numbers 1 Extended Sequence Numbers 1
Note that an initiator who supports ESNs will usually include two ESN Note that an initiator who supports ESNs will usually include two ESN
transforms, with values "0" and "1", in its proposals. A proposal transforms, with values "0" and "1", in its proposals. A proposal
containing a single ESN transform with value "1" means that using containing a single ESN transform with value "1" means that using
normal (non-extended) sequence numbers is not acceptable. normal (non-extended) sequence numbers is not acceptable.
skipping to change at page 23, line 42 skipping to change at page 26, line 36
NONE. NONE.
Protocol Mandatory Types Optional Types Protocol Mandatory Types Optional Types
--------------------------------------------------- ---------------------------------------------------
IKE ENCR, PRF, INTEG, D-H IKE ENCR, PRF, INTEG, D-H
ESP ENCR, ESN INTEG, D-H ESP ENCR, ESN INTEG, D-H
AH INTEG, ESN D-H AH INTEG, ESN D-H
A.3.4. Transform Attributes A.3.4. Transform Attributes
Transform type 1 (Encryption Algorithm) transforms might include one Transform Type 1 (Encryption Algorithm) transforms might include one
transform attribute: Key Length. transform attribute: Key Length.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Attribute Type | Attribute Value | |1| Attribute Type | Attribute Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Data Attributes Figure 6: Data Attributes
o Attribute Type (15 bits) - Unique identifier for each type of o Attribute Type (15 bits) - Unique identifier for each type of
attribute (see below). attribute (see below).
o Attribute Value - Value of the attribute associated with the o Attribute Value - Value of the attribute associated with the
attribute type. attribute type.
Attribute Type Value Attribute Type Value
---------------------------- ----------------------------
skipping to change at page 24, line 22 skipping to change at page 27, line 16
---------------------------- ----------------------------
Key Length (in bits) 14 Key Length (in bits) 14
The Key Length attribute specifies the key length in bits (MUST use The Key Length attribute specifies the key length in bits (MUST use
network byte order) for certain transforms as follows: network byte order) for certain transforms as follows:
o The Key Length attribute MUST NOT be used with transforms that use o The Key Length attribute MUST NOT be used with transforms that use
a fixed-length key. a fixed-length key.
o Some transforms specify that the Key Length attribute MUST be o Some transforms specify that the Key Length attribute MUST be
always included. For example ENCR_AES_CBC. always included. For example, ENCR_AES_CBC.
A.4. Key Exchange Payload A.4. Key Exchange Payload
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Group Num | RESERVED | | Diffie-Hellman Group Num | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Key Exchange Data ~ ~ Key Exchange Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Key Exchange Payload Format Figure 7: Key Exchange Payload Format
A Key Exchange payload is constructed by copying one's Diffie-Hellman A Key Exchange payload is constructed by copying one's Diffie-Hellman
public value into the "Key Exchange Data" portion of the payload. public value into the "Key Exchange Data" portion of the payload.
The length of the Diffie-Hellman public value for modular The length of the Diffie-Hellman public value for modular
exponentiation group (MODP) groups MUST be equal to the length of the exponentiation groups (MODPs) MUST be equal to the length of the
prime modulus over which the exponentiation was performed, prepending prime modulus over which the exponentiation was performed, prepending
zero bits to the value if necessary. zero bits to the value if necessary.
The Diffie-Hellman Group Num identifies the Diffie-Hellman group in The Diffie-Hellman Group Num identifies the Diffie-Hellman group in
which the Key Exchange Data was computed. This Diffie-Hellman Group which the Key Exchange Data was computed. This Diffie-Hellman Group
Num MUST match a Diffie-Hellman group specified in a proposal in the Num MUST match a Diffie-Hellman group specified in a proposal in the
SA payload that is sent in the same message SA payload that is sent in the same message.
A.5. Identification Payloads A.5. Identification Payloads
The Identification payloads, denoted IDi and IDr in this document, The Identification payloads, denoted IDi and IDr in this document,
allow peers to assert an identity to one another. When using the allow peers to assert an identity to one another. When using the
ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2
does not require this address to match the address in the IP header does not require this address to match the address in the IP header
of IKEv2 packets, or anything in the TSi/TSr payloads. The contents of IKEv2 packets or anything in the TSi/TSr payloads. The contents
of IDi/IDr are used purely to fetch the policy and authentication of IDi/IDr are used purely to fetch the policy and authentication
data related to the other party. In minimal implementation it might data related to the other party. In minimal implementation, it might
be easiest to always use KEY_ID type. This allows the ID payload to be easiest to always use KEY_ID type. This allows the ID payload to
be static. Using IP address has problems in environments where IP be static. Using an IP address has problems in environments where IP
addresses are dynamically allocated. addresses are dynamically allocated.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | RESERVED | | ID Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 26, line 11 skipping to change at page 28, line 40
The following table lists the assigned semantics for the The following table lists the assigned semantics for the
Identification Type field. Identification Type field.
ID Type Value ID Type Value
------------------------------------------------------------------- -------------------------------------------------------------------
ID_IPV4_ADDR 1 ID_IPV4_ADDR 1
A single four (4) octet IPv4 address. A single four (4) octet IPv4 address.
ID_FQDN 2 ID_FQDN 2
A fully-qualified domain name string. An example of an ID_FQDN A fully qualified domain name string. An example of an ID_FQDN
is "example.com". The string MUST NOT contain any terminators is "example.com". The string MUST NOT contain any terminators
(e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
for an "internationalized domain name", the syntax is as defined for an "internationalized domain name", the syntax is as defined
in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". in [IDNA], for example, "xn--tmonesimerkki-bfbb.example.net".
ID_RFC822_ADDR 3 ID_RFC822_ADDR 3
A fully-qualified RFC 822 email address string. An example of a A fully qualified RFC 822 email address string based [RFC5322].
ID_RFC822_ADDR is "jsmith@example.com". The string MUST NOT An example of an ID_RFC822_ADDR is "jsmith@example.com". The
contain any terminators. Because of [EAI], implementations would string MUST NOT contain any terminators. Because of [EAI],
be wise to treat this field as UTF-8 encoded text, not as implementations would be wise to treat this field as
pure ASCII. UTF-8-encoded text, not as pure ASCII.
ID_IPV6_ADDR 5 ID_IPV6_ADDR 5
A single sixteen (16) octet IPv6 address. A single sixteen (16) octet IPv6 address.
ID_KEY_ID 11 ID_KEY_ID 11
An opaque octet stream that may be used to pass vendor- An opaque octet stream that may be used to pass vendor-
specific information necessary to do certain proprietary specific information necessary to do certain proprietary
types of identification. Minimal implementation might use types of identification. Minimal implementation might use
this type to send out serial number or similar device this type to send out a serial number or similar device-specific
specific unique static identification data for the device. unique static Identification Data for the device.
A.6. Certificate Payload A.6. Certificate Payload
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | | | Cert Encoding | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
skipping to change at page 27, line 8 skipping to change at page 29, line 37
Figure 9: Certificate Payload Format Figure 9: Certificate Payload Format
o Certificate Encoding (1 octet) - This field indicates the type of o Certificate Encoding (1 octet) - This field indicates the type of
certificate or certificate-related information contained in the certificate or certificate-related information contained in the
Certificate Data field. Certificate Data field.
Certificate Encoding Value Certificate Encoding Value
---------------------------------------------------- ----------------------------------------------------
X.509 Certificate - Signature 4 X.509 Certificate - Signature 4
Raw Public Key TBD Raw Public Key 15
o Certificate Data (variable length) - Actual encoding of o Certificate Data (variable length) - Actual encoding of
certificate data. The type of certificate is indicated by the certificate data. The type of certificate is indicated by the
Certificate Encoding field. Certificate Encoding field.
The syntax of the types above are: The syntax of the types above are:
o "X.509 Certificate - Signature" contains a DER-encoded X.509 o "X.509 Certificate - Signature" contains a DER-encoded X.509
certificate whose public key is used to validate the sender's AUTH certificate whose public key is used to validate the sender's AUTH
payload. Note that with this encoding, if a chain of certificates payload. Note that with this encoding, if a chain of certificates
needs to be sent, multiple CERT payloads are used, only the first 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 of which holds the public key used to validate the sender's AUTH
payload. payload.
o "Raw Public Key" contains a raw public key. In essence the o "Raw Public Key" contains a raw public key. In essence, the
Certificate Payload contains the SubjectPublicKeyInfo part of the Certificate Payload contains the SubjectPublicKeyInfo part of the
PKIX certificate (See Section 4.1.2.7 of [RFC5280]). This is PKIX Certificate (see Section 4.1.2.7 of [RFC5280]). This is a
quite simple ASN.1 object which contains mostly static parts quite simple ASN.1 object that contains mostly static parts before
before the actual public key values. See the actual public key values. See [RFC7670] for more information.
[I-D.kivinen-ipsecme-oob-pubkey] for more information.
A.7. Certificate Request Payload A.7. Certificate Request Payload
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | | | Cert Encoding | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~ Certification Authority ~ ~ Certification Authority (CA) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Certificate Request Payload Format Figure 10: Certificate Request Payload Format
o Certificate Encoding (1 octet) - Contains an encoding of the type o Certificate Encoding (1 octet) - Contains an encoding of the type
or format of certificate requested. or format of certificate requested.
o Certification Authority (variable length) - Contains an encoding o Certification Authority (variable length) - Contains an encoding
of an acceptable certification authority for the type of of an acceptable certification authority for the type of
certificate requested. certificate requested.
The Certificate Encoding field has the same values as those defined The Certificate Encoding field has the same values as those defined
certificate payload. The Certification Authority field contains an by the certificate payload. The Certification Authority field
indicator of trusted authorities for this certificate type. The contains an indicator of trusted authorities for this certificate
Certification Authority value is a concatenated list of SHA-1 hashes type. The Certification Authority value is a concatenated list of
of the public keys of trusted Certification Authorities (CAs). Each SHA-1 hashes of the public keys of trusted Certification Authorities.
is encoded as the SHA-1 hash of the Subject Public Key Info element Each is encoded as the SHA-1 hash of the Subject Public Key Info
(see Section 4.1.2.7 of [RFC5280]) from each Trust Anchor element (see Section 4.1.2.7 of [RFC5280]) from each Trust Anchor
certificate. The 20-octet hashes are concatenated and included with certificate. The 20-octet hashes are concatenated and included with
no other formatting. no other formatting.
A.8. Authentication Payload A.8. Authentication Payload
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 28, line 37 skipping to change at page 31, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Authentication Payload Format Figure 11: Authentication Payload Format
o Auth Method (1 octet) - Specifies the method of authentication o Auth Method (1 octet) - Specifies the method of authentication
used. used.
Mechanism Value Mechanism Value
----------------------------------------------------------------- -----------------------------------------------------------------
RSA Digital Signature 1 RSA Digital Signature 1
Using an RSA private key with RSASSA-PKCS1-v1_5 signature Using an RSA private key with an RSASSA-PKCS1-v1_5 signature
scheme specified in [PKCS1], see [RFC7296] Section 2.15 for scheme specified in [PKCS1]; see Section 2.15 of [RFC7296] for
details. details.
Shared Key Message Integrity Code 2 Shared Key Message Integrity Code 2
Computed as specified earlier using the shared key associated Computed as specified earlier using the shared key associated
with the identity in the ID payload and the negotiated PRF. with the identity in the ID payload and the negotiated PRF.
o Authentication Data (variable length) - see Section 2.1. o Authentication Data (variable length) - see Section 2.1.
A.9. Nonce Payload A.9. Nonce Payload
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Nonce Data ~ ~ Nonce Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 29, line 28 skipping to change at page 32, line 14
The size of the Nonce Data MUST be between 16 and 256 octets, The size of the Nonce Data MUST be between 16 and 256 octets,
inclusive. Nonce values MUST NOT be reused. inclusive. Nonce values MUST NOT be reused.
A.10. Notify Payload A.10. Notify Payload
The Notify payload, denoted N in this document, is used to transmit The Notify payload, denoted N in this document, is used to transmit
informational data, such as error conditions and state transitions, informational data, such as error conditions and state transitions,
to an IKE peer. A Notify payload may appear in a response message to an IKE peer. A Notify payload may appear in a response message
(usually specifying why a request was rejected), in an INFORMATIONAL (usually specifying why a request was rejected), in an INFORMATIONAL
Exchange (to report an error not in an IKE request), or in any other exchange (to report an error not in an IKE request), or in any other
message to indicate sender capabilities or to modify the meaning of message to indicate sender capabilities or to modify the meaning of
the request. the request.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type | | Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 30, line 10 skipping to change at page 32, line 44
Figure 13: Notify Payload Format Figure 13: Notify Payload Format
o Protocol ID (1 octet) - If this notification concerns an existing o Protocol ID (1 octet) - If this notification concerns an existing
SA whose SPI is given in the SPI field, this field indicates the SA whose SPI is given in the SPI field, this field indicates the
type of that SA. If the SPI field is empty, this field MUST be type of that SA. If the SPI field is empty, this field MUST be
sent as zero and MUST be ignored on receipt. sent as zero and MUST be ignored on receipt.
o SPI Size (1 octet) - Length in octets of the SPI as defined by the o SPI Size (1 octet) - Length in octets of the SPI as defined by the
IPsec protocol ID or zero if no SPI is applicable. For a IPsec protocol ID or zero if no SPI is applicable. For a
notification concerning the IKE SA, the SPI Size MUST be zero and notification concerning the IKE SA, the SPI Size MUST be zero and
the field must be empty. the SPI field must be empty.
o Notify Message Type (2 octets) - Specifies the type of o Notify Message Type (2 octets) - Specifies the type of
notification message. notification message.
o SPI (variable length) - Security Parameter Index. o SPI (variable length) - Security Parameter Index.
o Notification Data (variable length) - Status or error data o Notification Data (variable length) - Status or error data
transmitted in addition to the Notify Message Type. Values for transmitted in addition to the Notify Message Type. Values for
this field are type specific. this field are type specific.
skipping to change at page 30, line 36 skipping to change at page 33, line 24
Types in the range 0 - 16383 are intended for reporting errors. An Types in the range 0 - 16383 are intended for reporting errors. An
implementation receiving a Notify payload with one of these types implementation receiving a Notify payload with one of these types
that it does not recognize in a response MUST assume that the that it does not recognize in a response MUST assume that the
corresponding request has failed entirely. Unrecognized error types corresponding request has failed entirely. Unrecognized error types
in a request and status types in a request or response MUST be in a request and status types in a request or response MUST be
ignored, and they should be logged. ignored, and they should be logged.
Notify payloads with status types MAY be added to any message and Notify payloads with status types MAY be added to any message and
MUST be ignored if not recognized. They are intended to indicate MUST be ignored if not recognized. They are intended to indicate
capabilities, and as part of SA negotiation, are used to negotiate capabilities and, as part of SA negotiation, are used to negotiate
non-cryptographic parameters. non-cryptographic parameters.
NOTIFY messages: error types Value NOTIFY messages: error types Value
------------------------------------------------------------------- -------------------------------------------------------------------
UNSUPPORTED_CRITICAL_PAYLOAD 1 UNSUPPORTED_CRITICAL_PAYLOAD 1
Indicates that the one-octet payload type included in the Indicates that the 1-octet payload type included in the
Notification Data field is unknown. Notification Data field is unknown.
INVALID_SYNTAX 7 INVALID_SYNTAX 7
Indicates the IKE message that was received was invalid because Indicates the IKE message that was received was invalid because
some type, length, or value was out of range or because the some type, length, or value was out of range or because the
request was rejected for policy reasons. To avoid a DoS request was rejected for policy reasons. To avoid a
attack using forged messages, this status may only be Denial-of-Service (DoS) attack using forged messages, this
returned for and in an encrypted packet if the Message ID and status may only be returned for and in an encrypted packet if
cryptographic checksum were valid. To avoid leaking information the Message ID and cryptographic checksum were valid. To avoid
to someone probing a node, this status MUST be sent in response leaking information to someone probing a node, this status MUST
to any error not covered by one of the other status types. be sent in response to any error not covered by one of the other
To aid debugging, more detailed error information should be status types. To aid debugging, more detailed error information
written to a console or log. should be written to a console or log.
NO_PROPOSAL_CHOSEN 14 NO_PROPOSAL_CHOSEN 14
None of the proposed crypto suites was acceptable. This can be None of the proposed crypto suites was acceptable. This can be
sent in any case where the offered proposals are not acceptable sent in any case where the offered proposals are not acceptable
for the responder. for the responder.
NO_ADDITIONAL_SAS 35 NO_ADDITIONAL_SAS 35
Specifies that the node is unwilling to accept any more Child Specifies that the node is unwilling to accept any more Child
SAs. SAs.
NOTIFY messages: status types Value NOTIFY messages: status types Value
------------------------------------------------------------------- -------------------------------------------------------------------
INITIAL_CONTACT 16384 INITIAL_CONTACT 16384
Asserts that this IKE SA is the only IKE SA currently active Asserts that this IKE SA is the only IKE SA currently active
between the authenticated identities. between the authenticated identities.
A.11. Traffic Selector Payload A.11. Traffic Selector Payload
Traffic Selector (TS) payloads allow endpoints to communicate some of Traffic Selector (TS) payloads allow endpoints to communicate some of
the information from their SPD to their peers. TS payloads specify the information from their Security Policy Database (SPD) to their
the selection criteria for packets that will be forwarded over the peers. TS payloads specify the selection criteria for packets that
newly set up SA. will be forwarded over the newly set up SA.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of TSs | RESERVED | | Number of TSs | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ <Traffic Selectors> ~ ~ <Traffic Selectors> ~
skipping to change at page 32, line 31 skipping to change at page 34, line 44
o Traffic Selectors (variable length) - One or more individual o Traffic Selectors (variable length) - One or more individual
Traffic Selectors. Traffic Selectors.
The length of the Traffic Selector payload includes the TS header and The length of the Traffic Selector payload includes the TS header and
all the Traffic Selectors. all the Traffic Selectors.
There is no requirement that TSi and TSr contain the same number of There is no requirement that TSi and TSr contain the same number of
individual Traffic Selectors. Thus, they are interpreted as follows: individual Traffic Selectors. Thus, they are interpreted as follows:
a packet matches a given TSi/TSr if it matches at least one of the a packet matches a given TSi/TSr if it matches at least one of the
individual selectors in TSi, and at least one of the individual individual selectors in TSi and at least one of the individual
selectors in TSr. selectors in TSr.
Two TS payloads appear in each of the messages in the exchange that Two TS payloads appear in each of the messages in the exchange that
creates a Child SA pair. Each TS payload contains one or more creates a Child SA pair. Each TS payload contains one or more
Traffic Selectors. Each Traffic Selector consists of an address Traffic Selectors. Each Traffic Selector consists of an address
range (IPv4 or IPv6), a port range, and an IP protocol ID. range (IPv4 or IPv6), a port range, and an IP protocol ID.
The first of the two TS payloads is known as TSi (Traffic Selector- The first of the two TS payloads is known as TSi (Traffic Selector -
initiator). The second is known as TSr (Traffic Selector-responder). initiator). The second is known as TSr (Traffic Selector -
TSi specifies the source address of traffic forwarded from (or the responder). TSi specifies the source address of traffic forwarded
destination address of traffic forwarded to) the initiator of the from (or the destination address of traffic forwarded to) the
Child SA pair. TSr specifies the destination address of the traffic initiator of the Child SA pair. TSr specifies the destination
forwarded to (or the source address of the traffic forwarded from) address of the traffic forwarded to (or the source address of the
the responder of the Child SA pair. traffic forwarded from) the responder of the Child SA pair.
IKEv2 allows the responder to choose a subset of the traffic proposed IKEv2 allows the responder to choose a subset of the traffic proposed
by the initiator. by the initiator.
When the responder chooses a subset of the traffic proposed by the When the responder chooses a subset of the traffic proposed by the
initiator, it narrows the Traffic Selectors to some subset of the initiator, it narrows the Traffic Selectors to some subset of the
initiator's proposal (provided the set does not become the null set). initiator's proposal (provided the set does not become the null set).
If the type of Traffic Selector proposed is unknown, the responder If the type of Traffic Selector proposed is unknown, the responder
ignores that Traffic Selector, so that the unknown type is not ignores that Traffic Selector, so that the unknown type is not
returned in the narrowed set. returned in the narrowed set.
To enable the responder to choose the appropriate range, if the To enable the responder to choose the appropriate range, if the
initiator has requested the SA due to a data packet, the initiator initiator has requested the SA due to a data packet, the initiator
SHOULD include as the first Traffic Selector in each of TSi and TSr a SHOULD include as the first Traffic Selector in each TSi and TSr a
very specific Traffic Selector including the addresses in the packet very specific Traffic Selector including the addresses in the packet
triggering the request. If the initiator creates the Child SA pair triggering the request. If the initiator creates the Child SA pair
not in response to an arriving packet, but rather, say, upon startup, not in response to an arriving packet, but rather, say, upon startup,
then there may be no specific addresses the initiator prefers for the then there may be no specific addresses the initiator prefers for the
initial tunnel over any other. In that case, the first values in TSi initial tunnel over any other. In that case, the first values in TSi
and TSr can be ranges rather than specific values. and TSr can be ranges rather than specific values.
As minimal implementations might only support one SA, the traffic As minimal implementations might only support one SA, the Traffic
selectors will usually be from initiator's IP address to responders Selectors will usually be from the initiator's IP address to the
IP address (i.e. no port or protocol selectors and only one range). responder's IP address (i.e., no port or protocol selectors and only
one range).
A.11.1. Traffic Selector A.11.1. Traffic Selector
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Type |IP Protocol ID | Selector Length | | TS Type |IP Protocol ID | Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Port | End Port | | Start Port | End Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 33, line 43 skipping to change at page 36, line 25
~ Starting Address ~ ~ Starting Address ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Ending Address ~ ~ Ending Address ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Traffic Selector Figure 15: Traffic Selector
o TS Type (one octet) - Specifies the type of Traffic Selector. o TS Type (1 octet) - Specifies the type of Traffic Selector.
o IP protocol ID (1 octet) - Value specifying an associated IP o IP protocol ID (1 octet) - Value specifying an associated IP
protocol ID (such as UDP, TCP, and ICMP). A value of zero means protocol ID (such as UDP, TCP, and ICMP). A value of zero means
that the protocol ID is not relevant to this Traffic Selector -- that the protocol ID is not relevant to this Traffic Selector --
the SA can carry all protocols. the SA can carry all protocols.
o Selector Length - Specifies the length of this Traffic Selector o Selector Length - Specifies the length of this Traffic Selector
substructure including the header. substructure including the header.
o Start Port (2 octets, unsigned integer) - Value specifying the o Start Port (2 octets, unsigned integer) - Value specifying the
skipping to change at page 34, line 27 skipping to change at page 37, line 11
o Ending Address - The largest address included in this Traffic o Ending Address - The largest address included in this Traffic
Selector (length determined by TS Type). Selector (length determined by TS Type).
The following table lists values for the Traffic Selector Type field The following table lists values for the Traffic Selector Type field
and the corresponding Address Selector Data. and the corresponding Address Selector Data.
TS Type Value TS Type Value
------------------------------------------------------------------- -------------------------------------------------------------------
TS_IPV4_ADDR_RANGE 7 TS_IPV4_ADDR_RANGE 7
A range of IPv4 addresses, represented by two 4-octet
A range of IPv4 addresses, represented by two four-octet
values. The first value is the beginning IPv4 address values. The first value is the beginning IPv4 address
(inclusive) and the second value is the ending IPv4 address (inclusive), and the second value is the ending IPv4 address
(inclusive). All addresses falling between the two specified (inclusive). All addresses falling between the two specified
addresses are considered to be within the list. addresses are considered to be within the list.
TS_IPV6_ADDR_RANGE 8 TS_IPV6_ADDR_RANGE 8
A range of IPv6 addresses, represented by two 16-octet
A range of IPv6 addresses, represented by two sixteen-octet
values. The first value is the beginning IPv6 address values. The first value is the beginning IPv6 address
(inclusive) and the second value is the ending IPv6 address (inclusive), and the second value is the ending IPv6 address
(inclusive). All addresses falling between the two specified (inclusive). All addresses falling between the two specified
addresses are considered to be within the list. addresses are considered to be within the list.
A.12. Encrypted Payload A.12. Encrypted Payload
The Encrypted payload, denoted SK{...} in this document, contains The Encrypted payload, denoted as SK{...} in this document, contains
other payloads in encrypted form. other payloads in encrypted form.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector | | Initialization Vector |
| (length is block size for encryption algorithm) | | (length is block size for the encryption algorithm) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encrypted IKE Payloads ~ ~ Encrypted IKE Payloads ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) | | | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length | | | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~ ~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Encrypted Payload Format Figure 16: Encrypted Payload Format
o Next Payload - The payload type of the first embedded payload. o Next Payload - The payload type of the first embedded payload.
Note that this is an exception in the standard header format, Note that this is an exception in the standard header format,
since the Encrypted payload is the last payload in the message and since the Encrypted payload is the last payload in the message;
therefore the Next Payload field would normally be zero. But therefore, the Next Payload field would normally be zero. But
because the content of this payload is embedded payloads and there because the content of this payload is embedded payloads and there
was no natural place to put the type of the first one, that type was no natural place to put the type of the first one, that type
is placed here. is placed here.
o Payload Length - Includes the lengths of the header, o Payload Length - Includes the lengths of the header,
initialization vector (IV), Encrypted IKE payloads, Padding, Pad initialization vector (IV), Encrypted IKE payloads, Padding, Pad
Length, and Integrity Checksum Data. Length, and Integrity Checksum Data.
o Initialization Vector - For CBC mode ciphers, the length of the o Initialization Vector - For Cipher Block Chaining (CBC) mode
initialization vector (IV) is equal to the block length of the ciphers, the length of the initialization vector (IV) is equal to
underlying encryption algorithm. Senders MUST select a new the block length of the underlying encryption algorithm. Senders
unpredictable IV for every message; recipients MUST accept any MUST select a new unpredictable IV for every message; recipients
value. The reader is encouraged to consult [MODES] for advice on MUST accept any value. The reader is encouraged to consult
IV generation. In particular, using the final ciphertext block of [MODES] for advice on IV generation. In particular, using the
the previous message is not considered unpredictable. For modes final ciphertext block of the previous message is not considered
other than CBC, the IV format and processing is specified in the unpredictable. For modes other than CBC, the IV format and
document specifying the encryption algorithm and mode. processing is specified in the document specifying the encryption
algorithm and mode.
o IKE payloads are as specified earlier in this section. This field o IKE payloads are as specified earlier in this section. This field
is encrypted with the negotiated cipher. is encrypted with the negotiated cipher.
o Padding MAY contain any value chosen by the sender, and MUST have o Padding MAY contain any value chosen by the sender and MUST have a
a length that makes the combination of the payloads, the Padding, length that makes the combination of the payloads, the Padding,
and the Pad Length to be a multiple of the encryption block size. and the Pad Length to be a multiple of the encryption block size.
This field is encrypted with the negotiated cipher. This field is encrypted with the negotiated cipher.
o Pad Length is the length of the Padding field. The sender SHOULD o Pad Length is the length of the Padding field. The sender SHOULD
set the Pad Length to the minimum value that makes the combination set the Pad Length to the minimum value that makes the combination
of the payloads, the Padding, and the Pad Length a multiple of the of the payloads, the Padding, and the Pad Length a multiple of the
block size, but the recipient MUST accept any length that results block size, but the recipient MUST accept any length that results
in proper alignment. This field is encrypted with the negotiated in proper alignment. This field is encrypted with the negotiated
cipher. cipher.
o Integrity Checksum Data is the cryptographic checksum of the o Integrity Checksum Data is the cryptographic checksum of the
entire message starting with the Fixed IKE header through the Pad entire message starting with the Fixed IKE header through the Pad
Length. The checksum MUST be computed over the encrypted message. Length. The checksum MUST be computed over the encrypted message.
Its length is determined by the integrity algorithm negotiated. Its length is determined by the integrity algorithm negotiated.
Appendix B. Useful Optional Features Appendix B. Useful Optional Features
There are some optional features of IKEv2, which might be useful for There are some optional features of IKEv2, which might be useful for
minimal implementations in some scenarios. Such features include Raw minimal implementations in some scenarios. Such features include raw
public keys authentication, and sending IKE SA delete notification. public keys authentication and sending an IKE SA delete notification.
B.1. IKE SA Delete Notification B.1. IKE SA Delete Notification
In some scenarios, a minimal implementation device creates an IKE SA, In some scenarios, a minimal implementation device creates an IKE SA,
sends one or few packets, perhaps gets some packets back, and then sends one or few packets, perhaps gets some packets back, and then
the device goes back to sleep forgetting the IKE SA. In such the device goes back to sleep, forgetting the IKE SA. In such
scenarios it would be nice for the minimal implementation to send the scenarios, it would be nice for the minimal implementation to send
IKE SA delete notification to tell the other end that the IKE SA is the IKE SA delete notification to tell the other end that the IKE SA
going away, so it can free the resources. is going away, so it can free the resources.
Deleting the IKE SA can be done by sending one packet with a fixed Deleting the IKE SA can be done by sending one packet with a fixed
Message ID, and with only one payload inside the encrypted payload. Message ID and with only one payload inside the Encrypted payload.
The other end will send back an empty response: The other end will send back an empty response:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL, HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Initiator, Message ID=2), Flags: Initiator, Message ID=2),
SK {D} --> SK {D} -->
<-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL, <-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Response, Message ID=2), Flags: Response, Message ID=2),
SK {} SK {}
The delete payload format is: The Delete payload format is:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Num of SPIs | | Protocol ID | SPI Size | Num of SPIs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Security Parameter Index(es) (SPI) ~ ~ Security Parameter Index(es) (SPI) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Delete Payload Format Figure 17: Delete Payload Format
o Protocol ID (1 octet) - Must be 1 for an IKE SA. o Protocol ID (1 octet) - Must be 1 for an IKE SA.
o SPI Size (1 octet) - Length in octets of the SPI as defined by the o SPI Size (1 octet) - Length in octets of the SPI as defined by the
protocol ID. It MUST be zero for IKE (SPI is in message header). protocol ID. It MUST be zero for IKE (SPI is in the message
header).
o Num of SPIs (2 octets, unsigned integer) - The number of SPIs o Num of SPIs (2 octets, unsigned integer) - The number of SPIs
contained in the Delete payload. This MUST be zero for IKE. contained in the Delete payload. This MUST be zero for IKE.
o Security Parameter Index(es) (variable length) - Identifies the o Security Parameter Index(es) (variable length) - Identifies the
specific Security Association(s) to delete. The length of this specific Security Association(s) to delete. The length of this
field is determined by the SPI Size and Num of SPIs fields. This field is determined by the SPI Size and Num of SPIs fields. This
field is empty for the IKE SA delete. field is empty for the IKE SA delete.
B.2. Raw Public Keys B.2. Raw Public Keys
In some scenarios the shared secret authentication is not safe In some scenarios, the shared secret authentication is not safe
enough, as anybody who knows the secret can impersonate the server. enough, as anybody who knows the secret can impersonate the server.
If the shared secret is printed on the side of the device, then If the shared secret is printed on the side of the device, then
anybody who gets physical access to the device can read it. In such anybody who gets physical access to the device can read it. In such
environments, public key authentication allows stronger environments, public key authentication allows stronger
authentication with minimal operational overhead. Certificate authentication with minimal operational overhead. Certificate
support is quite complex, and minimal implementations do not usually support is quite complex, and minimal implementations do not usually
have need for them. Using Raw Public Keys is much simpler, and it have need for them. Using Raw Public Keys is much simpler, and it
scales similar to certificates. The fingerprint of the Raw Public scales similar to certificates. The fingerprint of the raw public
Key can still be distributed by, for example, printing it on the side key can still be distributed by, for example, printing it on the side
of the device allowing setup similar to using a shared secret. of the device allowing setup similar to using a shared secret.
Raw Public Keys can also be used in a "leap of faith" or baby duck Raw public keys can also be used in a "leap of faith" or baby duck
style initial setup, where the device imprints itself to the first style initial setup, where the device imprints itself to the first
device it sees when it boots up the first time. After that initial device it sees when it boots up the first time. After that initial
connection it stores the fingerprint of the Raw Public Key of the connection, it stores the fingerprint of the Raw Public Key of the
server in its own configuration and verifies that it never changes server in its own configuration and verifies that it never changes
(unless a "reset to factory settings" or similar command is issued). (unless a "reset to factory settings" or similar command is issued).
This changes the initial IKE_AUTH payloads as follows: This changes the initial IKE_AUTH payloads as follows:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1), Flags: Initiator, Message ID=1),
SK {IDi, CERT, AUTH, SAi2, TSi, TSr, SK {IDi, CERT, AUTH, SAi2, TSi, TSr,
N(INITIAL_CONTACT)} --> N(INITIAL_CONTACT)} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags: <-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1), Response, Message ID=1),
SK {IDr, CERT, AUTH, SAr2, TSi, TSr} SK {IDr, CERT, AUTH, SAr2, TSi, TSr}
The CERT payloads contains the Raw Public Keys used to sign the hash The CERT payloads contain the raw public keys used to sign the hash
of the InitiatorSignedOctects/ResponderSignedOctects when generating of the InitiatorSignedOctects/ResponderSignedOctects when generating
an AUTH payload. Minimal implementations should use SHA-1 as the an AUTH payload. Minimal implementations should use SHA-1 as the
hash function as that is the "SHOULD" support algorithm specified in hash function as that is the "SHOULD" support algorithm specified in
RFC 7296, so it is the most likely one that is supported by all RFC 7296, so it is the most likely one that is supported by all
devices. devices.
Note, that RFC 7296 already obsoleted the old Raw RSA Key method, and Note that RFC 7296 already obsoleted the old Raw RSA Key method, and
More Raw Public Keys for IKEv2 ([I-D.kivinen-ipsecme-oob-pubkey]) "Generic Raw Public-Key Support for IKEv2" [RFC7670] adds a new
adds a new format to allow using any types of Raw Public Keys with format to allow using any types of raw public keys with IKEv2. This
IKEv2. This document only specifies how to use the new format. document only specifies how to use the new format.
In these setups it might be possible that authenticating the server In these setups, it might be possible that authenticating the server
is not needed at all. If a minimal device is sending, for example, is not needed at all. If a minimal device is sending, for example,
sensor information to the server, the server wants to verify that the sensor information to the server, the server wants to verify that the
sensor is who it claims to be using raw public keys, but the sensor sensor is who it claims to be using raw public keys, but the sensor
does not really care who the server is. In such cases the NULL does not really care who the server is. In such cases, the NULL
authentication method ([RFC7619]) would be useful, as it allows authentication method [RFC7619] would be useful, as it allows devices
devices to do one-way authentication. to do one-way authentication.
Acknowledgements
Most of the content of this document is copied from RFC 7296.
Author's Address Author's Address
Tero Kivinen Tero Kivinen
INSIDE Secure INSIDE Secure
Eerikinkatu 28 Eerikinkatu 28
HELSINKI FI-00180 HELSINKI FI-00180
FI FINLAND
Email: kivinen@iki.fi Email: kivinen@iki.fi
 End of changes. 151 change blocks. 
350 lines changed or deleted 373 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/