Secure Key Integration Protocol (SKIP)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 3 March 2025.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Many existing secure channel protocols such as the Internet Key Exchange Protocol Version 2 (IKEv2) and Transport Layer Security (TLS) utilize public key cryptography that is vulnerable to Cryptographically Relevant Quantum Computers (CRQC)[PQCRYPTO]. One solution to mitigate this threat is to replace the vulnerable public key algorithms with different algorithms that are believed to be resistant to quantum computers. An alternate solution is to augment the original protocol by providing each protocol principal with a pre-shared key. If the pre-shared key has sufficient entropy and is mixed into the protocol's key derivation process in a quantum-resistant manner (such as via a pseudorandom function (PRF) instantiated using symmetric cryptography primitives), and other encryption and authentication algorithms are quantum-resistant, then the whole system is considered to be quantum-resistant. Many secure channel protocols already support the ability to mix a pre-shared key into their key derivation process. For example, [RFC8784] specifies an IKEv2 extension that utilizes a post-quantum pre-shared key (PPK) in order to provide quantum resistance to the IKEv2 handshake and the resulting IPsec session.¶

One common solution to distributing these pre-shared keys is to use out of band mechanism. This approach, however, has a number of drawbacks. For one, the administrative burden of installing the keys scales quadratically with the number of peers. Second, key management best practices suggests periodic rotation of keys, which requires additional and recurring support. Lastly, manual administration increases the likelihood that a low entropy key (e.g,. a password) is chosen. This misconfiguration would degrade any quantum resistance security benefits that we hope to achieve by mixing in the key in the first place. Instead, a more dynamic and automated source of key provisioning should be preferred [RFC4107].¶

This document describes the Secure Key Integration Protocol (SKIP), a protocol designed to facilitate the dynamic provisioning of keys to protocol principals. SKIP operates in a model where the two principals, called encryptors, are situated at each end of a point-to-point connection. Each encryptor is associated and co-located with a Key Provider (KP). Each KP is capable of producing the same key upon request from its associated encryptor, allowing this key to function as a pre-shared key between the two encryptors. For example, when integrated with the IKEv2 PPK extension (refer Section 5), SKIP can be used to provide each peer with a fresh PPK per session. Furthermore, SKIP defines a method by which a KP can provide entropy to an encryptor.¶

SKIP defines a modular and extensible security architecture. The keys provided to encryptors can be used to provide quantum-resistance to vulnerable secure channel protocols without reducing security guarantees against classical (i.e., non-quantum) adversaries, provide an additional layer of security to an already quantum-resistant secure channel protocol for a defense-in-depth strategy, and/or enforce key management policies. It imposes no restriction on the means by which two KPs synchronize a key. KPs may employ one or more technologies believed to be quantum-resistant, including, but not limited to post-quantum cryptography (PQC), quantum key distribution (QKD), a trusted third-party protocol, or a one-time pad (OTP) [CSFC]. The KPs can be upgraded, replaced, or reconfigured independent of the underlying encryptors, supporting goals such as cryptographic agility, defense-in-depth, and high availability. Moreover, SKIP can help enforce key management and rotation policies for any protocol that supports the use of a pre-shared key, such as Media Access Control Security (MACsec).¶

2. Protocol Overview

SKIP defines the interface through which two encryptors can obtain a key from their co-located Key Providers. The diagram Figure 2 provides an overview of the steps involved.¶

1. Encryptor Alice initiates a request to KP Alice for a key.¶

2. KP Alice generates a key and a unique identifier keyId, synchronizes the key and keyId with KP Bob through an arbitrary protocol, returns the key and keyId to encryptor Alice, and finally zeroizes the local copy of the key.¶

3. Encryptor Alice establishes a connection with encryptor Bob and exchanges the keyId.¶

4. Encryptor Bob initiates a request to KP Bob for the key associated with the keyId provided by encryptor Alice.¶

5. KP Bob responds with the key associated with the keyId and zeroizes its local copy.¶

At the end of this exchange, encryptors Alice and encryptor Bob possess the same key, which can be utilized as a pre-shared key in another protocol, thereby enhancing its security against potential quantum threats.¶

3. SKIP Interface

The connection between the Key Provider and the encryptor is established using IP over Ethernet. The communication protocol used is Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as per [RFC9110], with TLS versions 1.2 [RFC5246] or 1.3 [RFC8446]. The table below lists supported TLS ciphersuites and authentication modes.¶

4. SKIP Methods and Status Codes

An encryptor uses the following methods to interact with a Key Provider:¶

The host-identifier is an IPv4/v6 address or a hostname providing HTTPS services on standard port 443 or any port in the user-defined range. A KP SHOULD return one of the following HTTP status codes in response to a request made by an encryptor:¶

Data in the HTTP response from a KP to an encryptor is encoded in JSON format as described in [RFC8259].¶

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "entropy": {
      "type": "boolean"
    },
    "key": {
      "type": "boolean"
    },
    "algorithm": {
      "type": "string"
    },
    "localSystemID": {
      "type": "string"
    },
    "remoteSystemID": {
      "type": "array",
      "items": [
        {
          "type": "string"
        },
        {
          "type": "string"
        }
      ]
    }
  },
  "required": [
    "entropy",
    "key",
    "algorithm",
    "localSystemID",
    "remoteSystemID"
  ]
}

{
  "entropy" : true,
  "key" : true,
  "algorithm": "PRF",
  "localSystemID": "Alice",
  "remoteSystemID": [
    "Bob",
    "Eve"
  ]
}

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "keyId": {
      "type": "string"
    },
    "key": {
      "type": "string"
    }
  },
  "required": [
    "keyId",
    "key"
  ]
}

{
   "keyId" : "1726e9AE76234FB1dd1283d4dca1911e1f93864d70f3069e",
   "key" : "ad229dfb8a276e74c1f3b6c09349a69fb2fed73c541270663f0e5cbbfb031670"
}

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "randomStr": {
      "type": "string"
    },
    "minentropy": {
      "type": "integer"
    }
  },
  "required": [
    "randomStr",
    "minentropy"
  ]
}

{
   "randomStr" : "AD229DFB8A276E74C1F3B6C09349A69FB2FED73C541270663F0E5CBBFB031670",
   "minentropy" : 256
}

5. SKIP with IKEv2

SKIP can be used to dynamically supply post-quantum pre-shared keys (PPKs) in the IKEv2 PPK protocol extension [RFC8784]. The process of how SKIP is utilized in this context is outlined below.¶

(1) Each encryptor establishes a secure TLS connection with its corresponding Key Provider and retrieves the capabilities of the co-located Key Provider using the get capabilities method (refer Section 4.1).¶

(2) The Key Provider responds with its capabilities. For simplicity, only the localSystemID and remoteSystemID fields are shown in the capabilities response in the diagram.¶

(3) As part of IKE_SA_INIT exchange, encryptors propose the use of IKEv2 PPK extension by including USE_PPK notification payload, having type 16435, protocol ID of 0, no Security Parameter Index (SPI), and the localSystemID of its co-located Key Provider as notification data.¶

(4) Encryptor Alice invokes the get key method with Key Provider Alice to obtain a (keyId, key) pair (refer Section 4.2). The key request URL is encoded as https://{host-identifier:port}/key?remoteSystemID=Bob.¶

(5) Key Provider Alice responds with a key and its associated keyId.¶

(6) Encryptor Alice transmits the keyId to the peer encryptor Bob as part of IKE_AUTH request message using PPK_IDENTITY notification payload, having type 16436, protocol ID of 0, no SPI, and PPK_ID Type as 2 (PPK_ID_FIXED) followed by keyId as notification data.¶

(7) Encryptor Bob invokes the get key method with Key Provider Bob to retrieve the key associated with the keyId. The key request URL is encoded as https://{host-identifier:port}/key/{keyId}?remoteSystemID=Alice.¶

(8) Key Provider Bob responds with the key associated with the keyId.¶

At the end of this exchange, both encryptors possess the identical key, which is utilized to create key material for the IKEv2/IPsec Security Associations (SAs). [QRIPSEC]¶

Although this document uses IKEv2 with SKIP as an example, it's important to note that SKIP is a generic protocol that can be integrated with any existing security protocols by adding suitable extensions to provide quantum resistance.¶

6. SKIP Use Cases

This section of the document describes the use cases where SKIP can be leveraged and deployed, particularly in scenarios requiring robust network encryption across a wide range of industries.¶

7. IANA Considerations

This document updates the use of the PPK_IDENTITY (16435) notify message as defined in [RFC8784] to include the localSystemID of the Key Provider as notification data.¶

8. Security Considerations

SKIP is designed to facilitate the secure distribution of keys over a network. Its security depends primarily on two considerations: the strength of keys generated by the Key Provider (KP) and the secure delivery of keys from KPs to encryptors.¶

For the first consideration, this document does not impose any restrictions on the mechanism used by a KP to generate the key. In general, the same security considerations for generating a post-quantum pre-shared key (PPK) outlined in [RFC8784] apply equally here. In particular, it is strongest practice to ensure that a key generated by a KP has at least 256 bits of entropy, which will provide 128 bits of post-quantum security when Grover's algorithm [GROVER] is taken into account.¶

For the secure delivery of keys within SKIP, there are three different links (physical or logical) to consider: (1) the link between the two KPs, (2) the link between the two encryptors, and (3) the link between a KP and an encryptor. We will address each in turn. For (1), the mechanism by which two KPs synchronize a key is intentionally out-of-scope for SKIP, such that it can interoperate with various hardware or software technologies. It should be clear, however, that this key synchronization mechanism should be quantum-resistant if the key is intended to upgrade an existing protocol to quantum resistance. To this end, KPs can employ one or more technologies believed to be quantum-resistant, including, but not limited to: post-quantum cryptography (PQC), quantum key distribution (QKD), a trusted third-party protocol, or a one-time pad (OTP). For (2), this document makes no assumptions about the security of this link. Indeed, the primary purpose of SKIP is to augment an existing protocol between the two encryptors in the face of future quantum computing or other cryptanalytic advances. As such, the only SKIP-related piece of data to traverse this link is an opaque key identifier, from which it MUST be infeasible to derive the corresponding key. After the SKIP exchange completes, the two encryptors can use the key as a pre-shared key. The link in (3) between the KP and encryptor is specified in Table 1 to be HTTP over TLS v1.2 or v1.3, with support for both certificate and pre-shared key (PSK) authentication modes of TLS. The inclusion of certificates based on Rivest-Shamir-Adelman (RSA) and elliptic curve cryptography (ECC) that are known to have vulnerabilities to quantum computers recognizes the reality of interoperating with encryptors that do not yet have access to post-quantum cryptography, in addition to the the lack of post-quantum x509 certificates at the time of writing. The use of PSK-based authentication is RECOMMENDED since it is believed to be quantum-resistant, though the use of PSKs can introduce the same administrative challenges that SKIP is trying to solve for the encryptor-to-encryptor link. To mitigate these issues, an implementor SHOULD seek to limit the exposure of the KP-to-encryptor link by co-locating the KP and encryptor, and employ techniques such as network segmentation. Where feasible, running the KP on the same physical device as the encryptor as a co-process or hosted application can also significantly reduce the exposure of this link.¶

Finally, there is an additional security consideration that the identifier scheme used for KPs can potentially leak information about the larger network topology or about specific software or hardware versions in use. In particular, access to the remoteSystemID list in the KP capabilities response may help an adversary in finding lateral compromises within a network or new insertion points into the network. To mitigate this threat, an identifier scheme based on random pseudonyms can remove any correspondence between the KP and its location or underlying technology. The use of the glob patterns in the remoteSystemID field can also conceal specific details about the KP network by collapsing groups of KPs into a single entry in the remoteSystemID list.¶

9. References

Acknowledgements

David McGrew, Scott Fluher, Lionel Florit, and Amjad Inamdar made significant contributions to this work.¶

Contributors

Authors' Addresses