IKEv2 based lightweight secure data communication

IKEv2 based lightweight secure data communication Cisco Systems India Pvt. Ltd.

SEZ Unit, Cessna Business Park Sarjapur Marathahalli Outer Ring Road Bangalore Karnataka 560087 India +91 80 4426 4834 amjads@cisco.com

Cisco Systems India Pvt. Ltd.

SEZ Unit, Cessna Business Park Sarjapur Marathahalli Outer Ring Road Bangalore Karnataka 560087 India +91 80 4426 2731 rsj@cisco.com

Security Area Internet-Draft The Internet Key Exchange (IKEv2) protocol provides authentication, confidentiality, integrity, data-origin authentication and anti-replay. Currently, IKEv2 is mainly used as a control channel to negotiate IPsec SA(s). IPsec is not well suited to provide transport layer security for applications as it resides at the network layer and most of the IPsec implementations require integration into operating systems making it difficult to deploy. IPsec uses different sessions for control and data traffic which is not NAT and load balancer friendly. TLS/DTLS, the other popular security mechanism to provide the above security services does not mandate mutual peer authentication and Diffie Hellman exchange. This document describes an IKEv2 based lightweight secure data communication protocol and a way to provide transport layer security for UDP client/server applications. The protocol provides integrity protected encryption and integrity-only protection based on application needs. As most of the IoT applications are UDP based, IKEv2 can be used for key management as well secure data communication in IoT due to its simplicity, scalability, lightweightedness and ease of deployment.

The Internet Key Exchange Protocol version 2 (IKEv2), specified in RFC5996 , is a UDP based protocol that provides a secure communication channel similar to ESP defined in RFC4303 . IKEv2 defines mechanisms for mutual authentication of peers, key management, SA management and exchange of configuration information. IKEv2 is mainly used as a secure control channel to negotiate child IPsec SAs. As IKEv2 provides encryption, integrity protection, data origin authenication and replay protection similar to ESP, IKEv2 can be leveraged for secure data communication. This document defines an IKEv2 based secure data communication mechanism (henceforth referred to as D-IKE) and describes a way to secure UDP applications with D-IKE. While the IKE control channel is always encryption and integrity protected, the IKE data channel can provide encryption and integrity protection as well as integrity-only protection depending on the needs of the application.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

D-IKE being UDP based is easier to deploy as it resides in the operating system application space and does not require integration with the operating system kernel unlike most of the IPsec implementations D-IKE is lighter with fewer keys and protocol exchanges as it uses the same channel for control messages and data D-IKE is simpler as it does not involve programming the Security Policy Database (SPD) D-IKE being at transport layer is better suited to provide granular and end-to-end security to applications than IPsec which provides network layer security suitable for site to site D-IKE control and data channels run over a single UDP port and hence D-IKE is load balancer friendly

D-IKE provides better enforcement of security through mandatory mutual peer authentication and Diffie Hellman key exchange D-IKE supports comprehensive authentication methods and has built-in support for mobility, DOS attack mitigation and load balancing

Each UDP application using D-IKE for security will use different UDP port numbers. So with D-IKE, IKEv2 packets are no longer identified by UDP ports 500 and 4500. D-IKE will use a different UDP port number for each UDP application to carry the D-IKE control messages for IKEv2 negotiation as well as application data. The first octet in the UDP payload will identify D-IKE control and data packets. D-IKE control packets will carry the IKEv2 header and payloads as defined in RFC5996 and will be used to negotiate a childless IKEv2 session between UDP client and server. D-IKE data packets will carry encrypted and authenticated UDP application data. The following diagram depicts the format of UDP encapsulated D-IKE control and Data packets.

+------------+------+----------+---------------------------+ | UDP Header | Type | RESERVED | D-IKE Control/Data Packet | +------------+------+----------+---------------------------+ |<---------------- UDP Payload -------------->| D-IKE can provide integrity-only protection in addition to integrity protected encryption. D-IKE does not negotiate child IPsec SAs in the IKEv2 initial exchange and subsequently as depicted in D-IKE Negotiation section, similar to Childless IKEv2 defined in RFC6023. Please refer the appendix section of this document for details on the alternative mechanisms that were considered for data communication over IKEv2 and their drawbacks.

This document introduces the concept of D-IKE sockets to secure communication between UDP client/server applications. D-IKE socket is an IKEv2 session between a UDP client and server uniquely identified by the 4 tuple of client and server IP addresses and UDP ports.

+--------------+ +--------------+ | UDP Client | | UDP Service | +--------------+ +--------------+ | D-IKE socket | | D-IKE socket | +--------------+ +--------------+ | UDP | | UDP | +--------------+ +--------------+ | IP |<------------>| IP | +--------------+ +--------------+ A UDP service will register with D-IKE socket specifying the UDP port it wants to listen to. D-IKE will listen on the UDP port number on behalf of the application A UDP client will open a D-IKE socket specifying the server IP address and the UDP port number. D-IKE will open a UDP socket to the server on behalf of the client D-IKE will initiate an IKEv2 session without any child SA from UDP client to the server After successful negotiation of IKEv2 session, the client and server can securely exchange data over D-IKE socket

UDP Client UDP Server ---------- ---------- | | |<-------- IKE negotiation --------->| | | |<----- Secure Data Transfer ------->| | | For a node running multiple UDP applications(Clients and/or Services), each UDP application will have a unique D-IKE socket

+----------------+----------------+----------------+ | UDP App 1 | UDP App 2 | UDP App N | +----------------+----------------+----------------+ | D-IKE socket 1 | D-IKE socket 2 | D-IKE socket N | +----------------+----------------+----------------+ | UDP | +--------------------------------------------------+ | IP | +--------------------------------------------------+ A well known UDP service can simultaneously open a UDP socket as well as D-IKE socket.

Lightweight, scalable and simpler with fewer keys and protocol exchanges Support for integrity-only protection, in addition to integrity protected encryption Works seamlessly with load balancers and PAT devices as D-IKE uses the same UDP port as the IKEv2 control channel

This document proposes following extensions to IKEv2 protocol for data communication: IKEv2 Notify type 'D-IKE_SUPPORTED' to negotiate the use of IKEv2 for data communication D-IKE packet formats

D-IKE will support the following data protection modes: Encryption and Integrity protection Integrity only protection

This protection mode provides encryption and integrity protection of D-IKE packets similar to the IKEv2 Encrypted payload as defined in RFC5996 The UDP app data and D-IKE trailer are encrypted and the D-IKE header, UDP app data and D-IKE trailer are integrity protected.

This protection mode provides integrity protection of IKEv2 data packets and no encryption similar to ESP null encryption as described in RFC4303. This is suitable for applications that just need data integrity and not confidentiality such as routing protocol exchanges. It may be noted that integrity only protection applies only to D-IKE packets and that D-IKE control packets will always use integrity protected encryption. The UDP app data and D-IKE trailer are encrypted and the D-IKE header, UDP app data and D-IKE trailer are integrity protected.

IKEv2 nodes can negotiate to use D-IKE and its capabilities by exchanging D-IKE_SUPPORTED Notify type in IKE_SA_INIT exchange. IKEv2 initiator can communicate its intent to use D-IKE by including a notify payload of type D-IKE_SUPPORTED along with the proposed capabilities in IKE_SA_INIT request IKEv2 responder can indicate its willingness to use D-IKE with the proposed capabilities by including a notify payload of type D-IKE_SUPPORTED along with the same capabilities in IKE_SA_INIT response If the capabilities proposed by IKEv2 Initiator are not acceptable to IKEv2 responder, it MUST NOT include D-IKE_SUPPORTED Notify type in IKE_SA_INIT response The absence of Notify payload of type D-IKE_SUPPORTED in IKE_SA_INIT response indicates the incapability or unwillingness of the IKEv2 responder to use D-IKE If IKEv2 responder does not include the same capabilities as proposed by IKEv2 initiator, IKEv2 initiator MUST treat this as unsuccessful negotiation of D-IKE On unsuccessful negotiation of D-IKE, IKEv2 initiator and responder MUST NOT use D-IKE for data transfer. However rest of the IKEv2 negotiation can proceed as normal On successful negotiation of D-IKE, IKEv2 Initiator and Responder MUST exclude any payloads related to Child SA negotiation in IKE_AUTH exchange and can use D-IKE for data transfer

Initiator Responder ------------------------------------------------------ HDR, SAi1, KEi, Ni [N(D-IKE_SUPPORTED)] --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] N(D-IKE_SUPPORTED) HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, [CP(CFG_REQUEST)] --> <-- HDR, SK {IDr, [CERT,] AUTH, [CP(CFG_REPLY)]

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol ID ! SPI Size ! Notify Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Flags ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protocol ID (1 octet): MUST be 1, as this message is related to an IKEv2 SA SPI Size (1 octet): MUST be zero, in conformance with section 3.10 of [RFC5996] Notify Message Type (2 octets): MUST be xxxxx, the value assigned for D-IKE_SUPPORTED by IANA Flags (8 bits): Specify the IKEv2 Data channel properties bit 0: 0 - Encryption and Integrity protection 1 - Integrity-only protection bit 1-7: Reserved, sender MUST set these bits to zero and receiver MUST ignore it

The first octet in the UDP payload will identify D-IKE control and data packets. D-IKE control packets will carry the IKEv2 header and payloads as defined in RFC 5996 and will be used to negotiate a childless IKEv2 session between UDP client and server. D-IKE data packets will carry encrypted and authenticated UDP application data.

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ IKEv2 Header and payloads ~ | or | | D-IKE data payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (1 octet, unsigned integer): Identifies D-IKE control and data packet 0 - D-IKE control packet 1 - D-IKE data packet 2 - 7 - RESERVED

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initialization Vector | | (length is block size for encryption algorithm) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Encrypted/Cleartext Data ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (0-255 octets) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | | Pad Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Integrity Checksum Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length (2 octets, unsigned integer): Length in octets of the entire IKEv2 Data packet Reserved (2 octets): Sender MUST set these bits to zero and receiver MUST ignore these bits SPI (8 octets): A value used by receiver to lookup the session associated with the packet in order to verify integrity and decrypt the data packet. This value is usually the data packet receiver's IKE SPI Sequence Number (4 octets): This field identifies the D-IKE packet sequence numbers, used for anti-replay checks

This protocol variation inherits all the security properties of regular IKEv2 as described in [RFC5996]. The new notification carried in the initial exchange advertises the capability, and cannot be forged or added by an adversary without being detected, because the response to the initial exchange is authenticated with the AUTH payload of the IKE_AUTH exchange. IKEv2 data payload inherits all security properties of ESP protocol defined in [RFC4303].

This document introduces one new IKEv2 Notification Message types as described in . The new Notify Message Types must be assigned values between 16429 and 40959. D-IKE_SUPPORTED For UDP applications that need a well known port number to secure the application using D-IKE (for example, CoAP over D-IKE), the port number MUST be reserved from IANA.

We would like to thank following people (in alphabetical order) for their review comments and valuable suggestions for idea and initial version of the document: Amit Phadnis, Arif Shouqi, Balaji B L, Brian Weis, Cheryl Madson, Frederic Detienne, J P Vasseur, Kalyani Garigipati, Mike Sullenberger, Naresh Sunkara, Nick Doyle, Paul Hoffman, Rajiv Shankar Daulath, Ramesh Nethi, Sandeep Rao, Scott Fluhrer, and Thamil Kandasamy.

This section lists all the changes in this document. NOTE TO RFC EDITOR: Please remove this section in before final RFC publication.

Reworked the draft with more focus on UDP application security. Updated the problem statement. Added comparision with IPsec and TLS/DTLS. Updated D-IKE Notify and Data payloads. Added possible extensions.

Internet Key Exchange Protocol Version 2: IKEv2 Microsoft VPN Consortium Check Point Nokia IP Encapsulating Security Payload (ESP) BBN Technologies A Childless Initiation of IKEv2 SA Check Point NSN China Mobile Cisco IKEv2 Fragmentation ELVIS-PLUS Group Key Management using IKEv2 Cisco Cisco Cisco Check Point Minimal IKEv2 INSIDE Secure Key words for use in RFCs to Indicate Requirement Levels Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword Redirect Mechanism for IKEv2 WiChorus

This section describes the alternative mechanisms for data communication over IKEv2 that were considered and their drawbacks.

The existing IKEv2 control channel can be used for data transfer using a new IKEv2 exchange type DATA exchange similar to INFORMATIONAL exchange, and a new payload type to encapsulate cleartext data that will be protected by Encrypted payload. A drawback with this approach is that the data packets will incur the overhead of IKEv2 header (28 octets) and a minimum of two generic payload headers (4 octets each) with a total protocol overhead of 36 octets per data packet. Also, it is difficult to support unacknowledged data transfer and integrity-only protection for data packets.

IKEv2 header can be modified to allow differentiation between control and data packets using the first four bytes of the header and the rest of the header can be different for control and data packets. A possible way to accomplish this is to move the Exchange type field to the beginning of IKEv2 header. The obvious drawback with this approach is that it is not backward compatible with existing IKEv2 protocol. Also, it makes it difficult to support unacknowledged data transfer and integrity-only protection for data packets.

A separate UDP port e.g 501 can be used for IKEv2 data channel that allows to leverage the IKEv2 protocol's security and reliability mechanisms and security parameters for data communication while avoiding the overhead of IKEv2 header and generic payload headers for data packets. Use of a fixed UDP port for data channel instead of dynamically negotiated UDP ports has the advantage of not requiring the firewalls to snoop the IKEv2 control channel to be able to determine and allow the traffic on data channel UDP port. A drawback with this approach is that the use of different ports for IKEv2 control and data channels makes it difficult for load balancers to associate an IKEv2 control channel with its data channel when there are multiple IKEv2 initiators behind a PAT device. Also when IKEv2 initiator is behind a PAT device, the data packets from responder will be dropped by the PAT device as port 501 will not be open unless there is data traffic from initiator.

This section describes the possible extensions to D-IKE protocol.

D-IKE can be used to secure TCP applications using one of the following methods. While IKE control channel can run over UDP, the IKE data channel can negotiate and run over a TCP session carring D-IKE protected application data. A drawback with this approach is that using differnet sessions for control and data may not be friendly with load balancers If IKEv2 were to run over TCP, IKEv2 over TCP can be used to secure TCP applications D-IKE tunnel mode can be defined that can encapsulate TCP or any other protocol over D-IKE tunnel