draft-ietf-lwig-ikev2-minimal-01.txt   draft-ietf-lwig-ikev2-minimal-02.txt 
Light-Weight Implementation Guidance T. Kivinen Light-Weight Implementation Guidance (lwig) T. Kivinen
(lwig) INSIDE Secure Internet-Draft INSIDE Secure
Internet-Draft October 17, 2013 Intended status: Informational March 2015
Intended status: Informational Expires: September 12, 2015
Expires: April 20, 2014
Minimal IKEv2 Minimal IKEv2
draft-ietf-lwig-ikev2-minimal-01.txt draft-ietf-lwig-ikev2-minimal-02.txt
Abstract Abstract
This document describes minimal version of the Internet Key Exchange This document describes minimal version of the Internet Key Exchange
version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for
performing mutual authentication and establishing and maintaining performing mutual authentication and establishing and maintaining
Security Associations (SAs). IKEv2 includes several optional Security Associations (SAs). IKEv2 includes several optional
features, which are not needed in minimal implementations. This features, which are not needed in minimal implementations. This
document describes what is required from the minimal implementation, document describes what is required from the minimal implementation,
and also describes various optimizations which can be done. The and also describes various optimizations which can be done. The
protocol described here is compliant with full IKEv2 with exception protocol described here is compliant with full IKEv2 with exception
that this document describes mainly shared secret authentication that this document describes mainly shared secret authentication
(IKEv2 requires support for certificate authentication in addition to (IKEv2 requires support for certificate authentication in addition to
shared secret authentication). shared secret authentication).
This document does not update or modify RFC 5996, but provides more This document does not update or modify RFC 7296, but provides 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 5996 conflicts then RFC 5996 is the authoritative document and RFC 7296 conflicts 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 20, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
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.
This Internet-Draft will expire on September 12, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . . 6 2.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . . 4
2.2. Other Exchanges . . . . . . . . . . . . . . . . . . . . . 11 2.2. Other Exchanges . . . . . . . . . . . . . . . . . . . . . 9
2.3. Generating Keying Material . . . . . . . . . . . . . . . . 12 2.3. Generating Keying Material . . . . . . . . . . . . . . . . 10
3. Conformance Requirements . . . . . . . . . . . . . . . . . . . 14 3. Conformance Requirements . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Header and Payload Formats . . . . . . . . . . . . . 19 Appendix A. Header and Payload Formats . . . . . . . . . . . . . . 12
A.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A.1. The IKE Header . . . . . . . . . . . . . . . . . 12
A.2. Generic Payload Header . . . . . . . . . . . . . . . . . . 21 Appendix A.2. Generic Payload Header . . . . . . . . . . . . . 14
A.3. Security Association Payload . . . . . . . . . . . . . . . 22 Appendix A.3. Security Association Payload . . . . . . . . . . 16
A.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 24 Appendix A.3.1. Proposal Substructure . . . . . . . . . . . . 17
A.3.2. Transform Substructure . . . . . . . . . . . . . . . . 25 Appendix A.3.2. Transform Substructure . . . . . . . . . . . 18
A.3.3. Valid Transform Types by Protocol . . . . . . . . . . 27 Appendix A.3.3. Valid Transform Types by Protocol . . . . . . 20
A.3.4. Transform Attributes . . . . . . . . . . . . . . . . . 28 Appendix A.3.4. Transform Attributes . . . . . . . . . . . . 21
A.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . . 28 Appendix A.4. Key Exchange Payload . . . . . . . . . . . . . . 21
A.5. Identification Payloads . . . . . . . . . . . . . . . . . 29 Appendix A.5. Identification Payloads . . . . . . . . . . . . . 22
A.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 30 Appendix A.6. Certificate Payload . . . . . . . . . . . . . . . 23
A.7. Certificate Request Payload . . . . . . . . . . . . . . . 31 Appendix A.7. Certificate Request Payload . . . . . . . . . . . 24
A.8. Authentication Payload . . . . . . . . . . . . . . . . . . 32 Appendix A.8. Authentication Payload . . . . . . . . . . . . . 24
A.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 33 Appendix A.9. Nonce Payload . . . . . . . . . . . . . . . . . . 25
A.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . . 33 Appendix A.10. Notify Payload . . . . . . . . . . . . . . . . . 25
A.10.1. Notify Message Types . . . . . . . . . . . . . . . . . 34 Appendix A.10.1. Notify Message Types . . . . . . . . . . . . 26
A.11. Traffic Selector Payload . . . . . . . . . . . . . . . . . 35 Appendix A.11. Traffic Selector Payload . . . . . . . . . . . . 27
A.11.1. Traffic Selector . . . . . . . . . . . . . . . . . . . 37 Appendix A.11.1. Traffic Selector . . . . . . . . . . . . . . 29
A.12. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 38 Appendix A.12. Encrypted Payload . . . . . . . . . . . . . . . . 30
Appendix B. Useful Optional Features . . . . . . . . . . . . . . 41 Appendix B. Useful Optional Features . . . . . . . . . . . . . . . 31
B.1. IKE SA Delete Notification . . . . . . . . . . . . . . . . 41 Appendix B.1. IKE SA Delete Notification . . . . . . . . . . . 31
B.2. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 42 Appendix B.2. Raw Public Keys . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This document tells what minimal IKEv2 implementation could look This document tells what minimal IKEv2 implementation could look
like. Minimal IKEv2 implementation only supports initiator end of like. Minimal IKEv2 implementation only supports initiator end of
the protocol. It only supports the initial IKE_SA_INIT and IKE_AUTH the 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 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:
skipping to change at page 4, line 36 skipping to change at page 3, line 47
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 which 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 omitted from this document, only those which are of interest for
minimal implementation are listed in this document. minimal implementation are listed in this document.
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 the IKEv2, as it is easiest to implement. In some authentication in the IKEv2, as it is easiest to implement. In some
cases that is not enough and the Appendix B.2 describes how to use cases that is not enough and the [raw-public-keys] describes how to
Raw Public keys instead of shared secret authentication. use Raw Public keys instead of shared secret authentication.
For more information check the full IKEv2 specification in RFC 5996 For more information check the full IKEv2 specification in RFC 7296
[RFC5996] and [IKEV2IANA]. [RFC7296] 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]. document are to be interpreted as described in [RFC2119].
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 environments
the node initiating connections is usually very small and the other the node initiating connections is usually very small and the other
end of the communication channel is some kind of larger device. end of the communication channel is some kind of larger device.
An example of the small initiating node could be an remote garage An example of the small initiating node could be an remote garage
door opener device. I.e. device having buttons which open and close door opener device. I.e. device having buttons which open and close
garage door, and which connects to the home area network server over garage door, and which connects to the home area network server over
wireless link. wireless link.
Another example of the such device is some kind of sensor device, for Another example of the such device is some kind of sensor device, for
example room temperature sensor, which sends periodic temperature example room temperature sensor, which sends periodic temperature
data to some centralized node. data to some centralized node.
Those devices are usually sleeping long times, and only wakes up Those devices are usually sleeping long times, and only wakes up
because of user interaction or periodically. The data transfer is because of user interaction or periodically. The data transfer is
always initiated from the sleeping node and after they send packets always initiated from the sleeping node and after they send packets
there might be ACKs or other packets coming back before they go back there might be ACKs or other packets coming back before they go back
to sleep. If some data needs to be transferred from server node to to sleep. If some data needs to be transferred from server node to
the small device, it can be implemented by polling, i.e. small node the small device, it can be implemented by polling, i.e. small node
periodically polls for the server to see if it for example have some periodically polls for the server to see if it for example have some
configuration changes or similar. configuration changes or similar.
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 a "request/response pair". Every request requires a response. called a "request/response pair". Every request requires a response.
skipping to change at page 6, line 24 skipping to change at page 4, line 46
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 first two exchanges The minimal implementation of IKEv2 only uses first two exchanges
called IKE_SA_INIT and IKE_AUTH. Those are used to create the IKE SA called IKE_SA_INIT and IKE_AUTH. Those are used to create the IKE SA
and the first child SA. In addition to those messages minimal IKEv2 and the first child SA. In addition to those messages minimal IKEv2
implementation need to understand CREATE_CHILD_SA request so it can implementation need to understand CREATE_CHILD_SA request so it can
reply with CREATE_CHILD_SA error response saying NO_ADDITIONAL_SAS to reply with CREATE_CHILD_SA error response saying NO_ADDITIONAL_SAS to
it, and understand INFORMATIONAL request so much, it can reply with it, and understand INFORMATIONAL request so much, it can reply with
empty INFORMATIONAL response to it. There is no requirement to be empty INFORMATIONAL response to it. There is no requirement to be
able to respond to any other requests. able to respond to any 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.
skipping to change at page 7, line 51 skipping to change at page 6, line 18
Flags: Initiator, Message ID=0), Flags: Initiator, Message ID=0),
SAi1, KEi, Ni --> SAi1, KEi, Ni -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT, <-- HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT,
Flags: Response, Message ID=0), Flags: Response, Message ID=0),
SAr1, KEr, Nr, [CERTREQ] SAr1, KEr, Nr, [CERTREQ]
HDR contains the Security Parameter Indexes (SPIs), version numbers, HDR contains the Security Parameter Indexes (SPIs), version numbers,
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
SPI value is not yet known by the sender. value is not yet known by the sender.
Incoming IKEv2 packets are mapped to an IKE SA only using the Incoming IKEv2 packets are mapped to an IKE SA only using 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 payload contain Diffie-
Hellman values and Ni and Nr are the nonces. The SAr1 contains Hellman values and Ni and Nr are the nonces. The SAr1 contains
chosen cryptographic suite from initiator's offered choices. Minimal chosen cryptographic suite from initiator's offered choices. Minimal
implementation using shared secrets will ignore the CERTREQ payload. implementation using shared secrets will ignore the CERTREQ 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,
skipping to change at page 8, line 40 skipping to change at page 6, line 56
where: where:
T1 = prf (K, S | 0x01) T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02) T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03) T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04) T4 = prf (K, T3 | S | 0x04)
... ...
(indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
SK_pi, and SK_pr are taken in order from the generated bits of the SK_pi, and SK_pr are taken in order from the generated bits of the
prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman
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 PRF agreed upon.
skipping to change at page 9, line 45 skipping to change at page 8, line 9
In the IKE_AUTH initiator sends SA offer(s) in the SAi2 payload, and In the IKE_AUTH initiator sends SA offer(s) in the SAi2 payload, and
the proposed Traffic Selectors for the proposed Child SA in the TSi the proposed Traffic Selectors for the proposed Child SA in the TSi
and TSr payloads. The responder replies with the accepted offer in and TSr payloads. The responder replies with the accepted offer in
an SAr2 payload, and selected Traffic Selectors. The selected an SAr2 payload, and selected Traffic Selectors. The selected
Traffic Selectors may be a subset of what the initiator proposed. Traffic Selectors may be a subset of what 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 ESP, but the algorithms are most likely going to be the used in the ESP, but the algorithms are most likely going to be the
one and only supported set. The TS payloads on the initiator end one and only supported set. The TS payloads on the initiator end
will most likely say from any to any, i.e. full wildcard ranges, or will most likely say from any to any, i.e. full wildcard ranges, or
from the local IP to the remote IP. In the wildcard case the server from the local IP to the remote IP. In the wildcard case the server
quite often narrow the range down to the one IP address pair. Using quite often narrow the range down to the one IP address pair. Using
single IP address pair as a traffic selectors when sending IKE_AUTH single IP address pair as a traffic selectors when sending IKE_AUTH
will simplify processing as then server will either accept that pair will simplify processing as then server will either accept that pair
or return error. If wildcard ranges are used, there is possibility or return error. If wildcard ranges are used, there is possibility
that server narrows the range to some other range than what was that server narrows the range to some other range than what was
intended. intended.
The IKE_AUTH (and IKE_SA_INIT) responses may contain multiple status The IKE_AUTH (and IKE_SA_INIT) responses may contain multiple status
notification payloads which can be ignored by minimal implementation. notification payloads which can be ignored by minimal implementation.
There can also be Vendor ID, Certificate, Certificate Request or There can also be Vendor ID, Certificate, Certificate Request or
skipping to change at page 14, line 7 skipping to change at page 11, line 18
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 5996 For an implementation to be called conforming to 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 RFC5996 responders must also PKIX certificates at all. As full RFC7296 responders must also
support that shared key authentication, this allows minimal support that shared key authentication, this allows minimal
implementation to be able to interoperate with all RFC 5996 compliant implementation to be able to interoperate with all RFC 7296 compliant
implementations. implementations.
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 compromize (see Appendix B.2). keys would probably be the best compromize (see [raw-public-keys]).
4. Security Considerations 4. Security Considerations
As this implements same protocol as RFC 5996 this means all security As this implements same protocol as RFC 7296 this means all security
considerations from it also apply to this document. considerations from it also apply to this document.
5. IANA Considerations 5. IANA Considerations
There is no new IANA considerations in this document. There is no new IANA considerations in this document.
6. Acknowledgements 6. Acknowledgements
Most of the contents of this document is copied from the RFC 5996. Most of the contents of this document is copied from the RFC 7296.
7. References 7. References
7.1. Normative References 7.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P. and T.
"Internet Key Exchange Protocol Version 2 (IKEv2)", Kivinen, "Internet Key Exchange Protocol Version 2
RFC 5996, September 2010. (IKEv2)", STD 79, RFC 7296, October 2014.
7.2. Informative References 7.2. Informative References
[I-D.ietf-ipsecme-oob-pubkey] [I-D.ietf-ipsecme-oob-pubkey]
Kivinen, T., Wouters, P., and H. Tschofenig, "More Raw Kivinen, T, Wouters, P and H Tschofenig, "More Raw Public
Public Keys for IKEv2", draft-ietf-ipsecme-oob-pubkey-00 Keys for IKEv2", Internet-Draft draft-ietf-ipsecme-oob-
(work in progress), April 2013. pubkey-00, April 2013.
[IKEV2IANA] [IKEV2IANA]
"Internet Key Exchange Version 2 (IKEv2) Parameters", "Internet Key Exchange Version 2 (IKEv2) Parameters", ,
<http://www.iana.org>. <http://www.iana.org>.
[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.
[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, May 2008. (CRL) Profile", RFC 5280, May 2008.
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 RFC5996 and more information can be found from mostly copied from the RFC7296 and more information can be found from
there. there.
Various payload contains RESERVED fields and those MUST be sent as Various payload contains 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 byte order"). "network byte order").
A.1. The IKE Header Appendix 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 follow. If a payload of type "Encrypted" is found, that payloads follow. If a payload of type "Encrypted" is found, that
payload is decrypted and its contents parsed as additional payloads. payload is decrypted and its contents parsed as additional payloads.
An Encrypted payload MUST be the last payload in a packet and an An Encrypted payload MUST be the last payload in a packet and an
skipping to change at page 20, line 24 skipping to change at page 14, line 5
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 0. 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
CREATE_CHILD_SA 36 CREATE_CHILD_SA 36
INFORMATIONAL 37 INFORMATIONAL 37
o Flags (1 octet) - Indicates specific options that are set for the o Flags (1 octet) - Indicates specific options that are set for the
message. Presence of options is indicated by the appropriate bit message. Presence of options is indicated by the appropriate bit
in the flags field being set. The bits are as follows: in the flags field being set. The bits are as follows:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|X|X|R|V|I|X|X|X| |X|X|R|V|I|X|X|X|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
In the description below, a bit being 'set' means its value is In the description below, a bit being 'set' means its value is '1',
'1', while 'cleared' means its value is '0'. 'X' bits MUST be while 'cleared' means its value is '0'. 'X' bits MUST be cleared when
cleared when sending and MUST be ignored on receipt. 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
response to a message containing the same Message ID. This bit to a message containing the same Message ID. This bit MUST be
MUST be cleared in all request messages and MUST be set in all cleared in all request messages and MUST be set in all responses.
responses. An IKEv2 endpoint MUST NOT generate a response to a An IKEv2 endpoint MUST NOT generate a response to a message that
message that is marked as being a response. 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
capable of speaking a higher major version number of the of speaking a higher major version number of the protocol than the
protocol than the one indicated in the major version number one indicated in the major version number field. Implementations
field. Implementations of IKEv2 MUST clear this bit when of IKEv2 MUST clear this bit when sending and MUST ignore it in
sending and MUST ignore it in incoming messages. 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
messages sent by the original responder. It is used by the sent by the original responder. It is used by the recipient to
recipient to determine which eight octets of the SPI were determine which eight octets of the SPI were generated by the
generated by the recipient. This bit changes to reflect who recipient. This bit changes to reflect who initiated the last
initiated the last rekey of the IKE SA. 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 Appendix 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, 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 0. This field provides a
"chaining" capability whereby additional payloads can be added to "chaining" capability whereby additional payloads can be added to
a message by appending each one to the end of the message and 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 0);
conversely, the Next Payload field of the last contained payload conversely, the Next Payload field of the last contained payload
is set to zero). The payload type values needed for minimal is set to zero). The payload type values needed for minimal
implementations are listed here. 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
Authentication AUTH 39 Authentication AUTH 39
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 one 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 Appendix 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 only attribute is key length attribute for variable length
ciphers, meaning there is exactly zero or one attribute). 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
w/keysize 128, ENCR_AES w/keysize 256, AUTH_HMAC_MD5, and /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 proposal, so there is no need to do INVALID_KE_PAYLOAD
processing in responses. processing in responses.
skipping to change at page 24, line 29 skipping to change at page 17, line 54
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ <Proposals> ~ ~ <Proposals> ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Security Association Payload Figure 3: Security Association Payload
o Proposals (variable) - One or more proposal substructures. o Proposals (variable) - One or more proposal substructures.
A.3.1. Proposal Substructure Appendix A.3.1. Proposal Substructure
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 2 | RESERVED | Proposal Length | | 0 (last) or 2 | RESERVED | Proposal Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proposal Num | Protocol ID | SPI Size |Num Transforms| | Proposal Num | Protocol ID | SPI Size |Num Transforms|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (variable) ~ ~ SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 25, line 14 skipping to change at page 18, line 35
o Proposal Num (1 octet) - When a proposal is made, the first o Proposal Num (1 octet) - When a proposal is made, the first
proposal in an SA payload MUST be 1, and subsequent proposals MUST proposal in an SA payload MUST be 1, and subsequent proposals MUST
be one more than the previous proposal. When a proposal is be one more than the previous proposal. When a proposal is
accepted, the proposal number in the SA payload MUST match the accepted, the proposal number in the SA payload MUST match the
number on the proposal sent that was accepted. number on the proposal sent that was accepted.
o Protocol ID (1 octet) - Specifies the IPsec protocol identifier o Protocol ID (1 octet) - Specifies the IPsec protocol identifier
for the current negotiation. for the current negotiation.
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, 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
field is zero, this field is not present in the Security is zero, this field is not present in the Security Association
Association payload. payload.
o Transforms (variable) - One or more transform substructures. o Transforms (variable) - One or more transform substructures.
A.3.2. Transform Substructure Appendix A.3.2. Transform Substructure
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 3 | RESERVED | Transform Length | | 0 (last) or 3 | RESERVED | Transform Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transform Type | RESERVED | Transform ID | |Transform Type | RESERVED | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Transform Attributes ~ ~ Transform Attributes ~
| | | |
skipping to change at page 27, line 36 skipping to change at page 20, line 44
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.
A.3.3. Valid Transform Types by Protocol Appendix A.3.3. Valid Transform Types by Protocol
The number and type of transforms that accompany an SA payload are The number and type of transforms that accompany an SA payload are
dependent on the protocol in the SA itself. An SA payload proposing dependent on the protocol in the SA itself. An SA payload proposing
the establishment of an SA has the following mandatory and optional the establishment of an SA has the following mandatory and optional
Transform Types. A compliant implementation MUST understand all Transform Types. A compliant implementation MUST understand all
mandatory and optional types for each protocol it supports (though it mandatory and optional types for each protocol it supports (though it
need not accept proposals with unacceptable suites). A proposal MAY need not accept proposals with unacceptable suites). A proposal MAY
omit the optional types if the only value for them it will accept is omit the optional types if the only value for them it will accept is
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 Appendix 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
skipping to change at page 28, line 36 skipping to change at page 21, line 36
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 Appendix 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 ~
skipping to change at page 29, line 17 skipping to change at page 22, line 10
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 group (MODP) groups 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 Appendix 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 IP address has problems in environments where IP
skipping to change at page 30, line 34 skipping to change at page 23, line 34
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 serial number or similar device
specific unique static identification data for the device. specific unique static identification data for the device.
A.6. Certificate Payload Appendix 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 | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~ Certificate Data ~ ~ Certificate Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 TBD
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 quite
quite simple ASN.1 object which contains mostly static parts simple ASN.1 object which contains mostly static parts before the
before the actual public key values. See actual public key values. See [I-D.ietf-ipsecme-oob-pubkey] for
[I-D.ietf-ipsecme-oob-pubkey] for more information. more information.
A.7. Certificate Request Payload Appendix 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 ~
| | | |
skipping to change at page 32, line 7 skipping to change at page 24, line 50
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 certificate payload. The Certification Authority field contains an
indicator of trusted authorities for this certificate type. The indicator of trusted authorities for this certificate type. The
Certification Authority value is a concatenated list of SHA-1 hashes Certification Authority value is a concatenated list of SHA-1 hashes
of the public keys of trusted Certification Authorities (CAs). Each of the public keys of trusted Certification Authorities (CAs). Each
is encoded as the SHA-1 hash of the Subject Public Key Info element is encoded as the SHA-1 hash of the Subject Public Key Info element
(see Section 4.1.2.7 of [RFC5280]) from each Trust Anchor (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 Appendix 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Method | RESERVED | | Auth Method | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Authentication Data ~ ~ Authentication Data ~
| | | |
skipping to change at page 32, line 36 skipping to change at page 25, line 25
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 RSASSA-PKCS1-v1_5 signature
scheme specified in [PKCS1], see [RFC5996] Section 2.15 for scheme specified in [PKCS1], see [RFC7296] Section 2.15 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.
DSS Digital Signature 3 o Authentication Data (variable length) - see [initial-exchange].
Using a DSS private key (see [DSS]) over a SHA-1 hash, see
[RFC5996] Section 2.15 for details.
o Authentication Data (variable length) - see Section 2.1.
A.9. Nonce Payload Appendix 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 ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Nonce Payload Format Figure 12: Nonce Payload Format
o Nonce Data (variable length) - Contains the random data generated o Nonce Data (variable length) - Contains the random data generated
by the transmitting entity. by the transmitting entity.
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 Appendix 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
skipping to change at page 34, line 7 skipping to change at page 26, line 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Notification Data ~ ~ Notification Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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.
A.10.1. Notify Message Types Appendix A.10.1. Notify Message Types
Notification information can be error messages specifying why an SA Notification information can be error messages specifying why an SA
could not be established. It can also be status data that a process could not be established. It can also be status data that a process
managing an SA database wishes to communicate with a peer process. managing an SA database wishes to communicate with a peer process.
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
skipping to change at page 35, line 38 skipping to change at page 27, line 50
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 Appendix 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 SPD to their peers. TS payloads specify
the selection criteria for packets that will be forwarded over the the selection criteria for packets that will be forwarded over the
newly set up SA. 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 |
skipping to change at page 36, line 40 skipping to change at page 28, line 40
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-responder).
TSi specifies the source address of traffic forwarded from (or the TSi specifies the source address of traffic forwarded from (or the
destination address of traffic forwarded to) the initiator of the destination address of traffic forwarded to) the initiator of the
Child SA pair. TSr specifies the destination address of the traffic Child SA pair. TSr specifies the destination address of the traffic
forwarded to (or the source address of the traffic forwarded from) forwarded to (or the source address of the traffic forwarded from)
the responder of the Child SA pair. 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
skipping to change at page 37, line 21 skipping to change at page 29, line 17
SHOULD include as the first Traffic Selector in each of TSi and TSr a SHOULD include as the first Traffic Selector in each of 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 initiator's IP address to responders
IP address (i.e. no port or protocol selectors and only one range). IP address (i.e. no port or protocol selectors and only one range).
A.11.1. Traffic Selector Appendix 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Starting Address ~ ~ Starting Address ~
skipping to change at page 37, line 46 skipping to change at page 29, line 42
| | | |
~ 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 (one 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
smallest port number allowed by this Traffic Selector. For smallest port number allowed by this Traffic Selector. For
protocols for which port is undefined (including protocol 0), or protocols for which port is undefined (including protocol 0), or
if all ports are allowed, this field MUST be zero. if all ports are allowed, this field MUST be zero.
skipping to change at page 38, line 42 skipping to change at page 30, line 32
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 sixteen-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 Appendix A.12. Encrypted Payload
The Encrypted payload, denoted SK{...} in this document, contains The Encrypted payload, denoted 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 |
skipping to change at page 41, line 11 skipping to change at page 31, line 53
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 IKE SA delete notification.
B.1. IKE SA Delete Notification Appendix B.1. IKE SA Delete Notification
In some scenarios the minimal implementation device creates IKE SA, In some scenarios the minimal implementation device creates 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
device goes back to sleep forgetting the IKE SA. In such scenarios device goes back to sleep forgetting the IKE SA. In such scenarios
it would be nice for the minimal implementation to send the IKE SA it would be nice for the minimal implementation to send the IKE SA
delete notification to tell the other end that the IKE SA is going delete notification to tell the other end that the IKE SA is going
away, so it can free the resources. away, so it can free the resources.
Deleting the IKE SA can be done using by sending one packet with Deleting the IKE SA can be done using by sending one packet with
fixed Message ID, and with only one payload inside the encrypted fixed Message ID, and with only one payload inside the encrypted
payload. The other end will send back an empty response: payload. The other end will send back an empty response:
skipping to change at page 42, line 6 skipping to change at page 32, line 44
| | | |
~ 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 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 Appendix 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 himself of enough, as anybody who knows the secret can impersonate himself of
being the server. If the shared secret is printed on the side of the being the server. If the shared secret is printed on the side of the
device, then anybody who gets physical access to the device can read device, then anybody who gets physical access to the device can read
it. In such environments public key authentication allows stronger it. In such 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
allows similar scalability than certificates. The fingerprint of the allows similar scalability than certificates. The fingerprint of the
Raw Public Key can still be distributed by for example printing it on Raw Public Key can still be distributed by for example printing it on
skipping to change at page 43, line 6 skipping to change at page 33, line 41
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 the sign the hash The CERT payloads contains the Raw Public Keys used the sign the hash
of the InitiatorSignedOctects/ResponderSignedOctects when generating of the InitiatorSignedOctects/ResponderSignedOctects when generating
AUTH payload. Minimal implementations should use SHA-1 as the hash AUTH payload. Minimal implementations should use SHA-1 as the hash
function as that is the SHOULD support algorithm specified in the function as that is the SHOULD support algorithm specified in the
RFC5996, so it is the most likely one that is supported by all RFC7296, so it is the most likely one that is supported by all
devices. devices.
Note, that the More Raw Public Keys for IKEv2 Note, that the RFC7296 already obsoleted the old Raw RSA Key method,
([I-D.ietf-ipsecme-oob-pubkey]) document obsoletes the old Raw RSA and More Raw Public Keys for IKEv2 ([I-D.ietf-ipsecme-oob-pubkey])
Key methods, and adds new format to allow any types of Raw Public adds new format to allow any types of Raw Public Keys to IKEv2. This
Keys to IKEv2. This document only specifies how to use the new document only specifies how to use the new format.
format.
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 FI
Email: kivinen@iki.fi Email: kivinen@iki.fi
 End of changes. 79 change blocks. 
210 lines changed or deleted 192 lines changed or added

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