Intermediate Exchange: Difference between revisions

From Libreswan
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:


== Introduction ==
= Introduction =


Intermediate Exchange, or IKE_INTERMEDIATE, is an addition to the IKEv2 protocol to enable the usage of quantum computer (QC) resistant algorithms which require transfer of large public keys. A series of these exchanges take place between IKE_SA_INIT and IKE_AUTH phases and enable message fragmentation via IKE Fragmentation mechanism. Hence large keys can be transferred without causing IP fragmentation.
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 is specified in [https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04 draft-ietf-ipsecme-ikev2-intermediate].
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.


== Implementation  ==
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.


To allow the use of Intermediate Exchange in libreswan, the following options were added:
The Intermediate Exchange draft document is available at [https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04 draft-ietf-ipsecme-ikev2-intermediate].


* The value 43 was picked to define a new exchange type, IKE_INTERMEDIATE. The value 16438 defines INTERMEDIATE_EXCHANGE_SUPPORTED Notify messages. The numbers were assigned by IANA.
= Implementation  =


* Changes were made in source files (programs/pluto/''ikev2_*.c'') where IKEv2 is implemented. For now, only a single round of Intermediate Exchanges is supported, since the post-quantum cryptographic algorithms are not yet a part of NSS API.
To allow the use of Intermediate Exchange in libreswan, the following modifications were made:


* New state transitions were added in programs/pluto/''ikev2.c'' to support Intermediate Exchange.
* 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.


* New connection option was added which can be configured with '''intermediate=yes'''.
* 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.
* Test suite changes.
Line 22: Line 26:
== Issues encountered ==
== Issues encountered ==


* Incorporating new exchange into existing implementation caused significant problems.
* Incorporating new exchange into existing implementation caused significant problems (Paul: please detail a few of the big issues you encountered and resolved)


* IDr payload will NOT be sent: error for RSA/ECDSA at Initiator. This error has to be debugged further.
* 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.
* Test suite errors have to be debugged further.


== Future work ==
= 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.
* Interoperability test with Elvis Plus.
Line 34: Line 48:
* IDr payload and authentication issues should be fixed.
* IDr payload and authentication issues should be fixed.


== Source code ==
= Source code =


Code commit RSA/ECDSA: https://github.com/yulia-kuz/libreswan/commit/3af9f006f3f3150d66e8144cb243c00ae9ff3eb0
Code commit RSA/ECDSA: https://github.com/yulia-kuz/libreswan/commit/3af9f006f3f3150d66e8144cb243c00ae9ff3eb0
Line 42: Line 56:
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 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.
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.

Revision as of 05:29, 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 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.

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 payoad 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 RSA/ECDSA: https://github.com/yulia-kuz/libreswan/commit/3af9f006f3f3150d66e8144cb243c00ae9ff3eb0

Code commit PSK: https://github.com/yulia-kuz/libreswan/commit/615a94316d0acd164b1bae3f23df6ad3ff8f7749

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.