Difference between revisions of "Intermediate Exchange"

From Libreswan
Jump to: navigation, search
Line 2: Line 2:
 
= Introduction =
 
= Introduction =
  
The Intermediate Exchange, or IKE_INTERMEDIATE, is an addition to the IKEv2 protocol to enable the use of quantum computer (QC) resistant algorithms. It is expected that these algorithms require the transfer of large amounts of data before the peer's can complete a quantum safe encryption and authentication. However, the IKE_SA_INIT exchange does not allow fragmentation and thus cannot carry this additional data. And the IKE_AUTH exchange already requires a working encryption algorithm. The IETF draft proposal is to add support for an unlimited number of INTERMEDIATE exchanges that take place between the IKE_SA_INIT and the IKE_AUTH exchange. These new INTERMEDIATE exchanges enable message fragmentation via the standaerd IKEv2 Fragmentation mechanism specified in RFC 7383. All data required to setup a quantum safe encryption algorithm can then be transferred before the IKE_AUTH exchange.
+
The Intermediate Exchange, or IKE_INTERMEDIATE, is an addition to the IKEv2 protocol to enable the use of quantum computer (QC) resistant algorithms. It is expected that these algorithms require the transfer of large amounts of data before the peers can complete a quantum safe encryption and authentication. However, the IKE_SA_INIT exchange does not allow fragmentation and thus cannot carry this additional data. And the IKE_AUTH exchange already requires a working encryption algorithm. The IETF draft proposal is to add support for an unlimited number of INTERMEDIATE exchanges that take place between the IKE_SA_INIT and the IKE_AUTH exchange. These new INTERMEDIATE exchanges enable message fragmentation via the standard IKEv2 Fragmentation mechanism specified in RFC 7383. All data required to setup a quantum safe encryption algorithm can then be transferred before the IKE_AUTH exchange.
  
 
While the Intermediate Exchange was originally designed to support new Quantum Safe algorithms, it can also be used for other large amounts of data that might need to be exchanged. Another such example is the data required for Remote Attestation of VPN clients before these are allowed to connect to VPN servers and the remote network.
 
While the Intermediate Exchange was originally designed to support new Quantum Safe algorithms, it can also be used for other large amounts of data that might need to be exchanged. Another such example is the data required for Remote Attestation of VPN clients before these are allowed to connect to VPN servers and the remote network.
Line 14: Line 14:
 
To allow the use of Intermediate Exchange in libreswan, the following modifications were made:
 
To allow the use of Intermediate Exchange in libreswan, the following modifications were made:
  
* The Early Code point allocations of the draft (value 43 for the new exchange type IKE_INTERMEDIATE, and the value 16438 for the new Notify payoad INTERMEDIATE_EXCHANGE_SUPPORTED were added.
+
* The Early Code point allocations of the draft (value 43 for the new exchange type IKE_INTERMEDIATE, and the value 16438 for the new Notify payload INTERMEDIATE_EXCHANGE_SUPPORTED) were added.
  
* Changes were made to the source files (programs/pluto/''ikev2_*.c'') where IKEv2 is implemented. For now, only a single round of Intermediate Exchanges is supported,
+
* Changes were made to the source files (programs/pluto/''ikev2_*.c'') where IKEv2 is implemented. For now, only a single round of Intermediate Exchanges is supported.
  
 
* New state transitions were added in programs/pluto/''ikev2.c'' to support the Intermediate Exchange.
 
* New state transitions were added in programs/pluto/''ikev2.c'' to support the Intermediate Exchange.
Line 29: Line 29:
  
 
* The authentication of the intermediate exchange packets is very complicated. All packets must be hashed into a PRF for authenticating. Fragmented packets are encrypted separately. Thus, the PRF outcome would be different if one peer accepted the unfragmented or fragmented packet. Therefore, the current draft requires pulling only certain payloads from the packet to add to the PRF. To create an AUTH payload, and to verify the peer's AUTH payload, all these payloads have to used separately even after the packet has been sent (and received). This is very complicated to do with the libreswan code base.
 
* The authentication of the intermediate exchange packets is very complicated. All packets must be hashed into a PRF for authenticating. Fragmented packets are encrypted separately. Thus, the PRF outcome would be different if one peer accepted the unfragmented or fragmented packet. Therefore, the current draft requires pulling only certain payloads from the packet to add to the PRF. To create an AUTH payload, and to verify the peer's AUTH payload, all these payloads have to used separately even after the packet has been sent (and received). This is very complicated to do with the libreswan code base.
 
 
 
 
  
 
= Current issues =
 
= Current issues =

Revision as of 10:35, 31 August 2020

Introduction

The Intermediate Exchange, or IKE_INTERMEDIATE, is an addition to the IKEv2 protocol to enable the use of quantum computer (QC) resistant algorithms. It is expected that these algorithms require the transfer of large amounts of data before the peers can complete a quantum safe encryption and authentication. However, the IKE_SA_INIT exchange does not allow fragmentation and thus cannot carry this additional data. And the IKE_AUTH exchange already requires a working encryption algorithm. The IETF draft proposal is to add support for an unlimited number of INTERMEDIATE exchanges that take place between the IKE_SA_INIT and the IKE_AUTH exchange. These new INTERMEDIATE exchanges enable message fragmentation via the standard IKEv2 Fragmentation mechanism specified in RFC 7383. All data required to setup a quantum safe encryption algorithm can then be transferred before the IKE_AUTH exchange.

While the Intermediate Exchange was originally designed to support new Quantum Safe algorithms, it can also be used for other large amounts of data that might need to be exchanged. Another such example is the data required for Remote Attestation of VPN clients before these are allowed to connect to VPN servers and the remote network.

Both NIST and the IETF have not yet defined any quantum safe algorithms to use. So any implementation of the intermediate exchange cannot yet support any specific post-quantum algorithm.

The Intermediate Exchange draft document is available at draft-ietf-ipsecme-ikev2-intermediate.

Implementation

To allow the use of Intermediate Exchange in libreswan, the following modifications were made:

  • The Early Code point allocations of the draft (value 43 for the new exchange type IKE_INTERMEDIATE, and the value 16438 for the new Notify payload INTERMEDIATE_EXCHANGE_SUPPORTED) were added.
  • Changes were made to the source files (programs/pluto/ikev2_*.c) where IKEv2 is implemented. For now, only a single round of Intermediate Exchanges is supported.
  • New state transitions were added in programs/pluto/ikev2.c to support the Intermediate Exchange.
  • A new connection option intermediate=yes was added that allows or disallows the intermediate exchange. This option is mainly used for testing and might be removed later as the intermediate exchange has not exchanged any ID yet, it cannot be correctly mapped to one of many connections loaded. And thus, the intermediate exchange cannot be enabled or disabled as a per-connection option.
  • Test suite changes.

Issues encountered

  • Incorporating new exchange into existing implementation caused significant problems (Paul: please detail a few of the big issues you encountered and resolved)
  • The authentication of the intermediate exchange packets is very complicated. All packets must be hashed into a PRF for authenticating. Fragmented packets are encrypted separately. Thus, the PRF outcome would be different if one peer accepted the unfragmented or fragmented packet. Therefore, the current draft requires pulling only certain payloads from the packet to add to the PRF. To create an AUTH payload, and to verify the peer's AUTH payload, all these payloads have to used separately even after the packet has been sent (and received). This is very complicated to do with the libreswan code base.

Current issues

  • IDr payload is currently NOT always sent: This is an error for RSA/ECDSA at the Initiator. This error has to be debugged further.
  • Test suite errors have to be debugged further.

Future work

  • Keep track of changes of the current draft and keep the code up to date with the latest draft (and finally with the RFC)
  • Interoperability test with Elvis Plus.
  • IDr payload and authentication issues should be fixed.

Source code

Code commit: https://github.com/yulia-kuz/libreswan/commit/db53cc9352fa58e9525b84f7641a8db95c3420da

Testing commit: https://github.com/yulia-kuz/libreswan/commit/b54297280b4edad39fd734c5bf6fc7f5dc72ecbc

The implementation for this project is done by Yulia Kuzovkova (ukuzovkova@gmail.com) under the mentorship of Sahana Prasad and Paul Wouters and sponsored by Google as part of Google Summer of Code 2020 Program.

The code is not yet merged as it is a POC (proof of concept). The code will be reviewed and merged after some issues are fixed and interoperability tests work. This is tentatively scheduled for libreswan version 4.1.