draft-ietf-lwig-ikev2-minimal-03.txt   draft-ietf-lwig-ikev2-minimal-04.txt 
Light-Weight Implementation Guidance (lwig) T. Kivinen Light-Weight Implementation Guidance (lwig) T. Kivinen
Internet-Draft INSIDE Secure Internet-Draft INSIDE Secure
Intended status: Informational September 22, 2015 Intended status: Informational September 28, 2015
Expires: March 25, 2016 Expires: March 31, 2016
Minimal IKEv2 Initiator Implementation Minimal IKEv2 Initiator Implementation
draft-ietf-lwig-ikev2-minimal-03.txt draft-ietf-lwig-ikev2-minimal-04.txt
Abstract Abstract
This document describes minimal initiator version of the Internet Key This document describes a minimal initiator version of the Internet
Exchange version 2 (IKEv2) protocol. IKEv2 is a component of IPsec Key Exchange version 2 (IKEv2) protocol. IKEv2 is a component of
used for performing mutual authentication and establishing and IPsec used for performing mutual authentication and establishing and
maintaining Security Associations (SAs). IKEv2 includes several maintaining Security Associations (SAs). IKEv2 includes several
optional features, which are not needed in minimal implementations. optional features, which are not needed in minimal implementations.
This document describes what is required from the minimal This document describes what is required from the minimal
implementation, and also describes various optimizations which can be implementation, and also describes various optimizations which can be
done. The protocol described here is compliant with full IKEv2 with done. The protocol described here is interoperable with a full IKEv2
exception that this document describes mainly shared secret implementation using shared secret authentication (IKEv2 does not
authentication (IKEv2 requires support for certificate authentication require the use of certificate authentication). This minimal
in addition to shared secret authentication). This minimal initiator initiator implementation can only talk to a full IKEv2 implementation
implementation can only talk to the IKEv2 implementation which acting as responder, thus two minimal initiator implementations
supports also acting as responder, thus two minimal initiator 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 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 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.
skipping to change at page 1, line 48 skipping to change at page 1, line 47
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 March 25, 2016. This Internet-Draft will expire on March 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . 4 2.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . 5
2.2. Other Exchanges . . . . . . . . . . . . . . . . . . . . . 10 2.2. Other Exchanges . . . . . . . . . . . . . . . . . . . . . 11
2.3. Generating Keying Material . . . . . . . . . . . . . . . 11 2.3. Generating Keying Material . . . . . . . . . . . . . . . 11
3. Conformance Requirements . . . . . . . . . . . . . . . . . . 12 3. Conformance Requirements . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Header and Payload Formats . . . . . . . . . . . . . 14 Appendix A. Header and Payload Formats . . . . . . . . . . . . . 14
A.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 14 A.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 15
A.2. Generic Payload Header . . . . . . . . . . . . . . . . . 17 A.2. Generic Payload Header . . . . . . . . . . . . . . . . . 17
A.3. Security Association Payload . . . . . . . . . . . . . . 18 A.3. Security Association Payload . . . . . . . . . . . . . . 18
A.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 20 A.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 20
A.3.2. Transform Substructure . . . . . . . . . . . . . . . 21 A.3.2. Transform Substructure . . . . . . . . . . . . . . . 21
A.3.3. Valid Transform Types by Protocol . . . . . . . . . . 23 A.3.3. Valid Transform Types by Protocol . . . . . . . . . . 23
A.3.4. Transform Attributes . . . . . . . . . . . . . . . . 23 A.3.4. Transform Attributes . . . . . . . . . . . . . . . . 23
A.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 24 A.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 24
A.5. Identification Payloads . . . . . . . . . . . . . . . . . 24 A.5. Identification Payloads . . . . . . . . . . . . . . . . . 25
A.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 26 A.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 26
A.7. Certificate Request Payload . . . . . . . . . . . . . . . 27 A.7. Certificate Request Payload . . . . . . . . . . . . . . . 27
A.8. Authentication Payload . . . . . . . . . . . . . . . . . 28 A.8. Authentication Payload . . . . . . . . . . . . . . . . . 28
A.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 28 A.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 28
A.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 29 A.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 29
A.10.1. Notify Message Types . . . . . . . . . . . . . . . . 30 A.10.1. Notify Message Types . . . . . . . . . . . . . . . . 30
A.11. Traffic Selector Payload . . . . . . . . . . . . . . . . 31 A.11. Traffic Selector Payload . . . . . . . . . . . . . . . . 31
A.11.1. Traffic Selector . . . . . . . . . . . . . . . . . . 33 A.11.1. Traffic Selector . . . . . . . . . . . . . . . . . . 33
A.12. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 34 A.12. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 34
Appendix B. Useful Optional Features . . . . . . . . . . . . . . 36 Appendix B. Useful Optional Features . . . . . . . . . . . . . . 36
B.1. IKE SA Delete Notification . . . . . . . . . . . . . . . 36 B.1. IKE SA Delete Notification . . . . . . . . . . . . . . . 36
B.2. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 37 B.2. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This document tells what minimal IKEv2 implementation could look This document describes a minimal IKEv2 implementation that is
like. Minimal IKEv2 implementation only supports initiator end of interoperable with Internet Key Exchange Protocol Version 2 (IKEv2)
the protocol. It only supports the initial IKE_SA_INIT and IKE_AUTH [RFC7296].
A minimal IKEv2 implementation only supports the initiator end of 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:
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, EAP authentication,
COOKIEs etc. COOKIEs etc.
Some optimizations can be done because of limited set of supported Some optimizations can be done because of the limited set of
features, and this text should not be considered for generic IKEv2 supported features, and this text should not be considered for
implementations (for example Message IDs can be done as specified as generic IKEv2 implementations (for example Message IDs can be done as
implementation is only sending out IKE_SA_INIT and IKE_AUTH request, specified because minimal implementation is only sending out
and do not ever send any other request). IKE_SA_INIT and IKE_AUTH request, and do not send any other request).
This document should be stand-alone, meaning everything needed to This document is inteded to be stand-alone, meaning everything needed
implement IKEv2 is copied here except the description of the to implement IKEv2 is copied here except the description of 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 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 a
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 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 Appendix B.2 describes how to use Raw
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 RFC 7296
[RFC7296] 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 can be very small and the other end
end of the communication channel is some kind of larger device. 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 a remote garage door
door opener device. I.e. device having buttons which open and close opener device, i.e., a device having buttons which open and close a
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 such a device is some kind of sensor device, for
example 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 long times, and only wakes up Those devices are usually sleeping for a long time, and only wake 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 that sleeping node when they wale up and after
there might be ACKs or other packets coming back before they go back they send packets there might be ACKs or other packets coming back
to sleep. If some data needs to be transferred from server node to before they go back to sleep. If some data needs to be transferred
the small device, it can be implemented by polling, i.e. small node from a server node to the small device, it can be implemented by
periodically polls for the server to see if it for example have some polling, i.e. the small node periodically polls for the server to see
configuration changes or similar. While the device is sleeping it if it for example has some configuration changes or similar. While
will not maintain the IKEv2 SA, i.e., it will always create the IKEv2 the device is sleeping it will not maintain the IKEv2 SA. That is,
SA again when it wakes up. This means there is no need to do it will always create the IKEv2 SA again when it wakes up. This
liveness checks for the server, as after the device wakes up again means there is no need to do liveness checks for the server, as after
the minimal implementation will start from the beginning again. the device wakes up again the minimal implementation will 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 a "request/response pair". Every request requires a response. called 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
skipping to change at page 5, line 22 skipping to change at page 5, line 30
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 the first two
called IKE_SA_INIT and IKE_AUTH. Those are used to create the IKE SA exchanges, called IKE_SA_INIT and IKE_AUTH. These are used to create
and the first child SA. In addition to those messages minimal IKEv2 the IKE SA and the first Child SA. In addition to those messages, a
implementation need to understand CREATE_CHILD_SA request so it can minimal IKEv2 implementation needs to understand the CREATE_CHILD_SA
reply with CREATE_CHILD_SA error response saying NO_ADDITIONAL_SAS to request enough to generate an CREATE_CHILD_SA response containing the
it, and understand INFORMATIONAL request so much, it can reply with NO_ADDITIONAL_SAS error notify. It needs to understand the
empty INFORMATIONAL response to it. There is no requirement to be INFORMATIONAL request enough to generate an empty INFORMATIONAL
able to respond to any other requests. response to it. There is no requirement to be 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.
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 implementation need only support of being initiator, so it Minimal implementations only need to support the role of initiator,
does not ever need to send any other request as one IKE_SA_INIT, and so so it typically only sends an IKE_SA_INIT request which, when
one IKE_AUTH message. As those messages have fixed Message IDs (0 answered, is followed by an IKE_AUTH. As those messages have fixed
and 1) it does not need to keep track of its own Message IDs for Message IDs (0 and 1) it does not need to keep track of its own
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 implementation against replays. This is possible because minimal implementations
will only return error or empty notifications 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 the 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 to 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 any kind of track immediately. This means there is no need to keep track of Message
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 names as listed below. are indicated by the names listed below.
Notation Payload Notation Payload
----------------------------------------- -----------------------------------------
AUTH Authentication AUTH Authentication
CERTREQ Certificate Request CERTREQ Certificate Request
D Delete D Delete
HDR IKE header (not a payload) HDR IKE header (not a payload)
IDi Identification - Initiator IDi Identification - Initiator
IDr Identification - Responder IDr Identification - Responder
KE Key Exchange KE Key Exchange
skipping to change at page 6, line 45 skipping to change at page 7, line 5
<-- 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 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 only using 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 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 the
chosen cryptographic suite from initiator's offered choices. Minimal chosen cryptographic suite from initiator's offered choices. A
implementation using shared secrets will ignore the CERTREQ payload. minimal 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,
from which all keys are derived for that IKE SA. from which all keys are derived for that IKE SA.
SKEYSEED = prf(Ni | Nr, g^ir) SKEYSEED = prf(Ni | Nr, g^ir)
skipping to change at page 8, line 30 skipping to change at page 8, line 37
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, and that means it has only one shared secret. This means
it does not need to care about IDr payload that much. If the other it does not need to care about IDr payload that much. If the other
end sends AUTH payload which initiator can verify using the shared end sends AUTH payload which initiator can verify using the shared
secret it has, then it knows the other end is the peer it was 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 initiator sends SA offer(s) in the SAi2 payload, and In the IKE_AUTH request, the initiator sends the SA offer(s) in the
the proposed Traffic Selectors for the proposed Child SA in the TSi SAi2 payload, and the proposed Traffic Selectors for the Child SA in
and TSr payloads. The responder replies with the accepted offer in the TSi and TSr payloads. The responder replies with the accepted
an SAr2 payload, and selected Traffic Selectors. The selected offer in an SAr2 payload, and with the selected Traffic Selectors.
Traffic Selectors may be a subset of what the initiator proposed. The selected 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 Encapsulating Security Payload (ESP), but the algorithms
one and only supported set. The TS payloads on the initiator end are most likely going to be the one and only supported set. The TS
will most likely say from any to any, i.e. full wildcard ranges, or payloads on the initiator end will most likely say from any to any,
from the local IP to the remote IP. In the wildcard case the server i.e. full wildcard ranges, or from the local IP to the remote IP. In
quite often narrow the range down to the one IP address pair. Using the wildcard case the responder quite often narrows the range down to
single IP address pair as a traffic selectors when sending IKE_AUTH the one IP address pair. Using a single IP address pair as the
will simplify processing as then server will either accept that pair Traffic Selectors when sending the IKE_AUTH request will simplify
or return error. If wildcard ranges are used, there is possibility processing as the responder will either accept the IP address pair or
that server narrows the range to some other range than what was return an error. If wildcard ranges are used, there is a possibility
intended. that the responder will narrow the Traffic Selector range to range
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) responses may contain multiple status
notification payloads which can be ignored by minimal implementation. notification payloads which can be ignored by minimal
There can also be Vendor ID, Certificate, Certificate Request or implementations. There can also be Vendor ID, Certificate,
Configuration payloads, but any payload unknown to minimal Certificate Request or Configuration payloads, but any payload
implementation can simply be skipped over (response messages cannot unknown to minimal implementations can simply be skipped over
have critical unsupported payloads). (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 the 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 them, and if there is any left from previous other IKE SAs between it and the responder, and if there is any left
runs they can be deleted. As minimal implementation does not delete from previous runs those can be deleted by the responder. As minimal
IKE SAs by sending IKE SA delete, this will help server to clean up implementations delete IKE SAs without sending IKE SA delete
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 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 minimal IKEv2 only store the output of it. This is possible because a minimal
implementation usually only supports one PRF. IKEv2 implementation usually only supports one PRF.
In following calculations, IDi' and IDr' are the entire ID payloads
excluding the fixed header and the Ni and Nr are only the value, not
the payload containing it. Note that neither the nonce 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').
In these calculations, IDi' and IDr' are the entire ID payloads
excluding the fixed header and the Ni, and Nr are only the value, not
the payload containing it. Note that neither the nonce Ni/Nr nor the
value prf(SK_pr, IDr')/prf(SK_pi, IDi') are transmitted.
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
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
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
MACedIDForI = prf(SK_pi, RestOfInitIDPayload) MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
The responder's signed octets can be described as: The responder's signed octets can be described as:
ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length RealIKEHDR = SPIi | SPIr | . . . | Length
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 unauthenticated response back having The initiator might also get an unauthenticated response back having
notification payload with error code inside. As that error code will a notification payload with an error code inside. As that error code
be unauthenticated and may be faked, there is no need to do anything will be unauthenticated and may be faked, there is no need to do
for those. Minimal implementation can simply ignore those errors, anything for those. A minimal implementation can simply ignore those
and retransmit its request until it times out and if that happens errors, and retransmit its request until it times out and if that
then the IKE SA (and Child SA) creation failed. happens then the IKE SA (and Child SA) creation failed.
Responder might also reply with IKE_AUTH response packet which do not The responder might also reply with an IKE_AUTH response packet which
contain payloads needed to set up Child SA (SAr2, TSi and TSr), but does not contain the payloads needed to set up a Child SA (SAr2, TSi
contains AUTH payload and an error. As minimal implementation and TSr), but instead contain AUTH payload and an error. Minimal
probably do not support multiple SAs nor sending the CREATE_CHILD_SA implementation that do not support the CREATE_CHILD_SA exchange
exchanges the IKE SA is useless for initiator. It can delete the IKE cannot recover from this scenario. It can delete the IKE SA and
SA and start over from the beginning (which might fail again if this start over from the beginning (which might fail again if this is a
is 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 implementation MUST be able to reply to INFORMATIONAL request Minimal implementations MUST be able to reply to INFORMATIONAL
by sending empty response back: requests by sending back an empty INFORMATIONAL response:
Initiator Responder Minimal implementation Other end
------------------------------------------------------------------- -------------------------------------------------------------------
<-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL, <-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: none, Message ID=m), Flags: none, Message ID=m),
SK {...} SK {...}
HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL, HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Initiator | Response, Flags: Initiator | Response,
Message ID=m), Message ID=m),
SK {} --> SK {} -->
Minimal implementation also MUST be able to reply to incoming Minimal implementations MUST be able to reply to incoming
CREATE_CHILD_SA requests. Typical implementation will reject the CREATE_CHILD_SA requests. A typical implementation will reject the
CREATE_CHILD_SA exchanges by sending NO_ADDITIONAL_SAS error notify CREATE_CHILD_SA exchanges by sending a NO_ADDITIONAL_SAS error notify
back: back:
Initiator Responder Minimal implementation Other end
------------------------------------------------------------------- -------------------------------------------------------------------
<-- 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 complient implementation unsupported critical payloads, in which case a compliant
MUST ignore the request, and send response message back having the implementation MUST ignore the request, and send a response message
UNSUPPORTED_CRITICAL_PAYLOAD notification. That notification payload back having the UNSUPPORTED_CRITICAL_PAYLOAD notification. That
data contains one-octet payload type of the unsupported critical notification payload data contains a one-octet payload type of the
payload. unsupported critical payload.
2.3. Generating Keying Material 2.3. Generating Keying Material
Keying material for Child SA created by the IKE_AUTH exchange is The keying material for the Child SA created by the IKE_AUTH exchange
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 AH SAs exist in pairs (one in each direction),
so two SAs are created in a single Child SA negotiation for them. so two SAs are created in a single Child SA negotiation for them.
The keying material for each Child SA MUST be taken from the expanded The keying material for each Child SA MUST be taken from the expanded
KEYMAT using the following rules: KEYMAT using the following rules:
skipping to change at page 12, line 38 skipping to change at page 12, line 44
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 RFC7296 responders must also PKIX certificates at all. As full RFC 7296 responders must also
support that shared key authentication, this allows 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 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 compromise (see Appendix B.2).
4. Security Considerations 4. Implementation Status
This document describes minimal implementation written by the author
of this document. This minimal implementation supported the base
IKE_SA_INIT and IKE_AUTH exchanges, and successfully interoperated
with full IKEv2 server. This minimal implementation was presented in
the Interconnecting Smart Objects with Internet Workshop in Prague
March 2011 ([Kiv11]). This implementation was written as proof of
concept in perl.
There was also another proof of concept implementation written in
python, which also interoperated with full IKEv2 server.
Both implementations were written just for demonstration purposes,
and included fixed configuration built in to the code, and both also
implemented also ESP, ICMP and IP layers in the level that was needed
to send and receive one ICMP echo packet. Both implementations were
about 1000 lines of code excluding cryptographic libraries but
including ESP, ICMP and IP layers.
5. Security Considerations
As this implements same protocol as RFC 7296 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 6. IANA Considerations
There is no new IANA considerations in this document. There is no new IANA considerations in this document.
6. Acknowledgements 7. Acknowledgements
Most of the contents of this document is copied from the RFC 7296. Most of the content of this document is copied from the RFC 7296.
7. References 8. References
7.1. Normative References 8.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, DOI 10.17487/
RFC2119, March 1997, 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>.
7.2. Informative References 8.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 Keys for IKEv2", draft-ietf-ipsecme-oob-pubkey-00 Public Keys for IKEv2", draft-ietf-ipsecme-oob-pubkey-00
(work in progress), April 2013. (work in progress), 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>.
[Kiv11] Kivinen, T., "IKEv2 and Smart Objects", March 2011,
<https://www.iab.org/wp-content/IAB-uploads/2011/04/
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.
[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>.
skipping to change at page 36, line 25 skipping to change at page 36, line 25
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 B.1. IKE SA Delete Notification
In some scenarios the minimal implementation device creates 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
device goes back to sleep forgetting the IKE SA. In such scenarios the device goes back to sleep forgetting the IKE SA. In such
it would be nice for the minimal implementation to send the IKE SA scenarios it would be nice for the minimal implementation to send the
delete notification to tell the other end that the IKE SA is going IKE SA delete notification to tell the other end that the IKE SA is
away, so it can free the resources. going 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 by sending one packet with a fixed
fixed Message ID, and with only one payload inside the encrypted Message ID, and with only one payload inside the encrypted payload.
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 {}
skipping to change at page 37, line 35 skipping to change at page 37, line 35
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 himself of enough, as anybody who knows the secret can impersonate the server.
being the server. If the shared secret is printed on the side of the If the shared secret is printed on the side of the device, then
device, then anybody who gets physical access to the device can read anybody who gets physical access to the device can read it. In such
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
allows similar scalability than certificates. The fingerprint of the scales similar to certificates. The fingerprint of the Raw Public
Raw Public Key can still be distributed by for example printing it on Key can still be distributed by, for example, printing it on the side
the side of the device allowing similar setup than using shared of the device allowing setup similar to using a shared secret.
secret.
Raw Public Keys can also be used in leap of faith or baby duck style Raw Public Keys can also be used in a "leap of faith" or baby duck
initial setup, where the device imprints itself to the first device style initial setup, where the device imprints itself to the first
it sees when it first time boots up. After that initial connection device it sees when it boots up the first time. After that initial
it stores the fingerprint of the Raw Public Key of the server to its connection it stores the fingerprint of the Raw Public Key of the
own configuration and verifies that it never changes (unless reset to server in its own configuration and verifies that it never changes
factory setting 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 the sign the hash The CERT payloads contains the Raw Public Keys used to 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 an AUTH payload. Minimal implementations should use SHA-1 as the
function as that is the SHOULD support algorithm specified in the hash function as that is the "SHOULD" support algorithm specified in
RFC7296, 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 the RFC7296 already obsoleted the old Raw RSA Key method, Note, that RFC 7296 already obsoleted the old Raw RSA Key method, and
and More Raw Public Keys for IKEv2 ([I-D.ietf-ipsecme-oob-pubkey]) More Raw Public Keys for IKEv2 ([I-D.ietf-ipsecme-oob-pubkey]) adds a
adds new format to allow any types of Raw Public Keys to IKEv2. This new format to allow using any types of Raw Public Keys with IKEv2.
document only specifies how to use the new format. This document only specifies how to use the new format.
In these setups it might be possible that the authentication of the In these setups it might be possible that authenticating the server
server is not needed at all. If the minimal device is sending for is not needed at all. If a minimal device is sending, for example,
example sensor information to the server, the server wants to verify sensor information to the server, the server wants to verify that the
that the sensor is who he claims to be using raw public keys, but sensor is who it claims to be using raw public keys, but the sensor
sensor does not really care who the server is. In such cases the does not really care who the server is. In such cases the NULL
NULL authentication method ([RFC7619]) would be useful, as it allows authentication method ([RFC7619]) would be useful, as it allows
devices to do single-sided authentication. devices to do one-way authentication.
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. 64 change blocks. 
189 lines changed or deleted 218 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/