draft-ietf-lwig-ikev2-minimal-04.txt   draft-ietf-lwig-ikev2-minimal-05.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 28, 2015 Intended status: Informational November 23, 2015
Expires: March 31, 2016 Expires: May 26, 2016
Minimal IKEv2 Initiator Implementation Minimal IKEv2 Initiator Implementation
draft-ietf-lwig-ikev2-minimal-04.txt draft-ietf-lwig-ikev2-minimal-05.txt
Abstract Abstract
This document describes a minimal initiator version of the Internet This document describes a minimal initiator version of the Internet
Key Exchange version 2 (IKEv2) protocol. IKEv2 is a component of Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2
IPsec used for performing mutual authentication and establishing and is a component of IPsec used for performing mutual authentication and
maintaining Security Associations (SAs). IKEv2 includes several establishing and maintaining Security Associations (SAs). IKEv2
optional features, which are not needed in minimal implementations. includes several optional features, which are not needed in minimal
This document describes what is required from the minimal implementations. This document describes what is required from the
implementation, and also describes various optimizations which can be minimal implementation, and also describes various optimizations
done. The protocol described here is interoperable with a full IKEv2 which can be done. The protocol described here is interoperable with
implementation using shared secret authentication (IKEv2 does not a full IKEv2 implementation using shared secret authentication (IKEv2
require the use of certificate authentication). This minimal does not require the use of certificate authentication). This
initiator implementation can only talk to a full IKEv2 implementation minimal initiator implementation can only talk to a full IKEv2
acting as responder, thus two minimal initiator implementations implementation 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 47 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 31, 2016. This Internet-Draft will expire on May 26, 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 3, line 25 skipping to change at page 3, line 25
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 describes a minimal IKEv2 implementation that is The Internet Protocol Suite is increasingly used on small devices
interoperable with Internet Key Exchange Protocol Version 2 (IKEv2) with severe constraints on power, memory, and processing resources.
[RFC7296]. This document describes a minimal IKEv2 implementation designed for
use on such constrained nodes that is interoperable with Internet Key
Exchange Protocol Version 2 (IKEv2) [RFC7296].
A minimal IKEv2 implementation only supports the initiator end of the A minimal IKEv2 implementation only supports the initiator end of the
protocol. It only supports the initial IKE_SA_INIT and IKE_AUTH protocol. It only supports the initial IKE_SA_INIT and IKE_AUTH
exchanges and does not initiate any other exchanges. It also replies exchanges and does not initiate any other exchanges. It also replies
with empty (or error) message to all incoming requests. with 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 the limited set of Some optimizations can be done because of the limited set of
supported features, and this text should not be considered for supported features, and this text should not be considered for
generic IKEv2 implementations (for example Message IDs can be done as generic IKEv2 implementations (for example Message IDs can be done as
specified because minimal implementation is only sending out specified because minimal implementation is only sending out
IKE_SA_INIT and IKE_AUTH request, and do not send any other request). IKE_SA_INIT and IKE_AUTH request, and do not send any other request).
This document is inteded to be stand-alone, meaning everything needed This document is intended to be stand-alone, meaning everything
to implement IKEv2 is copied here except the description of the needed to implement IKEv2 is copied here except the description of
cryptographic algorithms. The IKEv2 specification has lots of the 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 a 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 IKEv2, as it is easiest to implement. In some authentication in IKEv2, as it is easiest to implement. In some
cases that is not enough and Appendix B.2 describes how to use Raw cases that is not enough and Appendix B.2 describes how to use Raw
Public keys instead of shared secret authentication. Public keys instead of shared secret authentication.
For more information check the full IKEv2 specification in RFC 7296 For more information check the full IKEv2 specification in 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]. The term
"Constrained Node" is defined in the Terminology for Constrained-Node
Networks document [RFC7228].
1.1. Use Cases 1.1. Use Cases
One use case for this kind of minimal implementation is in small One use case for this kind of minimal implementation is in small
devices doing machine-to-machine communication. In such environments devices doing machine-to-machine communication. In such environments
the node initiating connections can be very small and the other end the node initiating connections can be very small and the other 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 a remote garage door An example of the small initiating node could be a remote garage door
opener device, i.e., a device having buttons which open and close a opener device, i.e., a device having buttons 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 such a device is some kind of sensor device, for Another example of such a device is some kind of sensor device, for
example a room temperature sensor, which sends periodic temperature example a room temperature sensor, which sends periodic temperature
data to some centralized node. data to some centralized node.
Those devices are usually sleeping for a long time, and only wake up Those devices 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 that sleeping node when they wale up and after always initiated from that sleeping node when they wake up and after
they send packets there might be ACKs or other packets coming back they send packets there might be ACKs or other packets coming back
before they go back to sleep. If some data needs to be transferred before they go back to sleep. If some data needs to be transferred
from a server node to the small device, it can be implemented by from a server node to the small device, it can be implemented by
polling, i.e. the small node periodically polls for the server to see polling, i.e. the small node periodically polls for the server to see
if it for example has some configuration changes or similar. While if it for example has some configuration changes or similar. While
the device is sleeping it will not maintain the IKEv2 SA. That is, the device is sleeping it will not maintain the IKEv2 SA. That is,
it will always create the IKEv2 SA again when it wakes up. This it will always create the IKEv2 SA again when it wakes up. This
means there is no need to do liveness checks for the server, as after means there is no need to do liveness checks for the server, as after
the device wakes up again the minimal implementation will start from the device wakes up again the minimal implementation will start from
the beginning again. the beginning again.
skipping to change at page 13, line 10 skipping to change at page 13, line 10
PKIX certificates are left out from the minimal implementation as PKIX certificates are left out from the minimal implementation as
those would add quite a lot of complexity to the implementation. The those would add quite a lot of complexity to the implementation. The
actual code changes needed in the IKEv2 protocol are small, but the actual code changes needed in the IKEv2 protocol are small, but the
certificate validation code would be more complex than the whole certificate validation code would be more complex than the whole
minimal IKEv2 implementation itself. If public key based minimal IKEv2 implementation itself. If public key based
authentication is needed for scalability reasons, then raw public authentication is needed for scalability reasons, then raw public
keys would probably be the best compromise (see Appendix B.2). keys would probably be the best compromise (see Appendix B.2).
4. Implementation Status 4. Implementation Status
This document describes minimal implementation written by the author This document describes a minimal implementation written by the
of this document. This minimal implementation supported the base author of this document. The minimal implementation supported the
IKE_SA_INIT and IKE_AUTH exchanges, and successfully interoperated base IKE_SA_INIT and IKE_AUTH exchanges, and successfully
with full IKEv2 server. This minimal implementation was presented in interoperated with a full IKEv2 server. This minimal implementation
the Interconnecting Smart Objects with Internet Workshop in Prague was presented in the Interconnecting Smart Objects with Internet
March 2011 ([Kiv11]). This implementation was written as proof of Workshop in Prague March 2011 ([Kiv11]). This implementation was
concept in perl. written as proof of concept in perl.
There was also another proof of concept implementation written in There was another proof of concept implementation written in python,
python, which also interoperated with full IKEv2 server. which also interoperated with a full IKEv2 server.
Both implementations were written just for demonstration purposes, Both implementations were written just for demonstration purposes,
and included fixed configuration built in to the code, and both also 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 implemented ESP, ICMP and IP layers to the level that was needed to
to send and receive one ICMP echo packet. Both implementations were send and receive one ICMP echo packet. Both implementations were
about 1000 lines of code excluding cryptographic libraries but about 1000 lines of code excluding cryptographic libraries but
including ESP, ICMP and IP layers. including ESP, ICMP and IP layers.
5. Security Considerations 5. Security Considerations
As this implements same protocol as RFC 7296 this means all security As this implements 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.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 14, line 12 skipping to change at page 14, line 12
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>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-ipsecme-oob-pubkey] [I-D.kivinen-ipsecme-oob-pubkey]
Kivinen, T., Wouters, P., and H. Tschofenig, "More Raw Kivinen, T., Wouters, P., and H. Tschofenig, "Generic Raw
Public Keys for IKEv2", draft-ietf-ipsecme-oob-pubkey-00 Public Key Support for IKEv2", draft-kivinen-ipsecme-oob-
(work in progress), April 2013. pubkey-14 (work in progress), October 2015.
[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, [Kiv11] Kivinen, T., "IKEv2 and Smart Objects", March 2011,
<https://www.iab.org/wp-content/IAB-uploads/2011/04/ <https://www.iab.org/wp-content/IAB-uploads/2011/04/
Kivinen.pdf>. Kivinen.pdf>.
[MODES] National Institute of Standards and Technology, U.S. [MODES] National Institute of Standards and Technology, U.S.
Department of Commerce, "Recommendation for Block Cipher Department of Commerce, "Recommendation for Block Cipher
Modes of Operation", SP 800-38A, 2001. Modes of Operation", SP 800-38A, 2001.
[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>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, DOI 10.17487/
RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
Method in the Internet Key Exchange Protocol Version 2 Method in the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
<http://www.rfc-editor.org/info/rfc7619>. <http://www.rfc-editor.org/info/rfc7619>.
Appendix A. Header and Payload Formats Appendix A. Header and Payload Formats
This appendix describes actual packet payload formats. This is This appendix describes actual packet payload formats. This is
required to make the document self contained. The descriptions are required to make the document self contained. The descriptions are
mostly copied from the RFC7296 and more information can be found from mostly copied from the RFC7296 and more information can be found from
skipping to change at page 27, line 28 skipping to change at page 27, line 28
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 simple ASN.1 object which contains mostly static parts quite simple ASN.1 object which contains mostly static parts
before the actual public key values. See before the actual public key values. See
[I-D.ietf-ipsecme-oob-pubkey] for more information. [I-D.kivinen-ipsecme-oob-pubkey] for more information.
A.7. Certificate Request Payload A.7. Certificate Request Payload
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | | | Cert Encoding | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
skipping to change at page 38, line 26 skipping to change at page 38, line 26
SK {IDr, CERT, AUTH, SAr2, TSi, TSr} SK {IDr, CERT, AUTH, SAr2, TSi, TSr}
The CERT payloads contains the Raw Public Keys used to sign the hash The CERT payloads contains the Raw Public Keys used to sign the hash
of the InitiatorSignedOctects/ResponderSignedOctects when generating of the InitiatorSignedOctects/ResponderSignedOctects when generating
an AUTH payload. Minimal implementations should use SHA-1 as the an AUTH payload. Minimal implementations should use SHA-1 as the
hash function as that is the "SHOULD" support algorithm specified in hash function as that is the "SHOULD" support algorithm specified in
RFC 7296, so it is the most likely one that is supported by all RFC 7296, so it is the most likely one that is supported by all
devices. devices.
Note, that RFC 7296 already obsoleted the old Raw RSA Key method, and Note, that RFC 7296 already obsoleted the old Raw RSA Key method, and
More Raw Public Keys for IKEv2 ([I-D.ietf-ipsecme-oob-pubkey]) adds a More Raw Public Keys for IKEv2 ([I-D.kivinen-ipsecme-oob-pubkey])
new format to allow using any types of Raw Public Keys with IKEv2. adds a new format to allow using any types of Raw Public Keys with
This document only specifies how to use the new format. IKEv2. This document only specifies how to use the new format.
In these setups it might be possible that authenticating the server In these setups it might be possible that authenticating the server
is not needed at all. If a minimal device is sending, for example, is not needed at all. If a minimal device is sending, for example,
sensor information to the server, the server wants to verify that the sensor information to the server, the server wants to verify that the
sensor is who it claims to be using raw public keys, but the sensor sensor is who it claims to be using raw public keys, but the sensor
does not really care who the server is. In such cases the NULL does not really care who the server is. In such cases the NULL
authentication method ([RFC7619]) would be useful, as it allows authentication method ([RFC7619]) would be useful, as it allows
devices to do one-way authentication. devices to do one-way authentication.
Author's Address Author's Address
 End of changes. 16 change blocks. 
44 lines changed or deleted 53 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/