| Internet-Draft | Non-composite hybrid auth | March 2022 |
| Becker, et al. | Expires 23 September 2022 | [Page] |
The advent of cryptographically relevant quantum computers (CRQC) will threaten the public key cryptography that is currently in use in today's secure internet protocol infrastructure. To address this, organizations such as the National Institute of Standards and Technology (NIST) will standardize new post-quantum cryptography (PQC) that is resistant to attacks by both classical and quantum computers. After PQC algorithms are standardized, the widespread implementation of this cryptography will be contingent upon adapting current protocols to accommodate PQC. Hybrid solutions are one way to facilitate the transition between traditional and PQ algorithms: they use both a traditional and a PQ algorithm in order to perform encryption or authentication, with the guarantee that the given security property will still hold in the case that one algorithm fails. Hybrid solutions can be constructed in many ways, and the cryptographic community has already begun to explore this space. This document introduces non-composite hybrid authentication, which requires updates at the protocol level and limits impact to the certificate-issuing infrastructure.¶
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 23 September 2022.¶
Copyright (c) 2022 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.¶
The advent of cryptographically relevant quantum computers (CRQC) threatens the public key cryptography that is currently in use in today's secure internet protocol infrastructure. To address this, organizations such as the National Institute of Standards and Technology (NIST) will standardize new post-quantum cryptography (PQC) that is resistant to attacks by both classical and quantum computers. After PQC algorithms are standardized, the widespread implementation of this cryptography will be contingent upon adapting current protocols to accommodate PQC. Hybrid solutions are one way to facilitate the transition between traditional and PQ algorithms: they use both a traditional and a PQ algorithm in order to perform encryption or authentication, with the guarantee that the given security property will still hold in the case that one algorithm fails. Hybrid solutions can be constructed in many ways, and the cryptographic and Internet engineering communities have already begun to explore this space. This document provides background on the current hybrid solution space, introducing a framework within which to view these solutions with a focus on authentication. It defines a new solution for a hybrid authentication, and considers changes that would be required in PKIX and Internet protocols in order to accommodate this solution.¶
This work is complementary to, and an extension of, other efforts, such as those as documented in [X509] and [I-D.draft-ounsworth-pq-composite-sigs]. Where existing hybrid authentication solutions attempt to leave protocol logic unaffected and instead invoke changes to cryptographic structures (e.g. certificate format) and processes (certificate validation), non-composite hybrid authentication takes the opposite approach: it minimizes changes required to PKIX and cryptographic libraries, instead limiting the scope of major changes to protocol logic in order to accommodate multiple authentications, each with separate signature and certificate objects.¶
There are unique challenges to migration efforts poised at updating current infrastructure to be quantum-secure, and hybrid designs are emerging as a common solution in this space [I-D.draft-ietf-tls-hybrid-design], [I-D.draft-ounsworth-pq-composite-sigs], [I-D.draft-ounsworth-pq-composite-keys], [I-D.draft-ietf-ipsecme-ikev2-multiple-ke]. A hybrid solution is the use of two or more algorithms simultaneously such that the desired security property (e.g., encryption or authentication) still holds in the event that a component algorithm is broken. Hybrid designs can generally be sorted into two categories:¶
These categories are meant to be broad, and are applicable to any type of cryptographic process. However, the remainder of this document focuses on authentication. In the context of hybrid authentication, composite solutions employ single signature and certificate objects with cryptographic structures that are modified in order to encode multiple algorithms. Non-composite solutions use separate signatures and certificates for each algorithm, and protocol logic is modified instead of signature and certificate structure, in order to accommodate the sending, processing, and receiving of multiple signature and certificate objects.¶
In practice, the authentication context will be a determining factor in which approach is considered optimal. Applications with a small or closed user community may be more apt to undertake composite solutions (because the number of libraries and amount of hardware affected is limited). On the other hand, contexts where verifiers have the ability to express their capabilities and preferences lend themselves to non-composite solutions. Additionally, non-composite solutions are well-suited toward protocols that can already handle multiple certificate chains and/or digital signatures. Last, non-composite solutions offer forward compatibility to implementations that are difficult to update or that employ certificates with long lifetimes.¶
In non-composite hybrid authentication, multiple authentications are performed, where each authentication uses a digital signature with a distinct certificate chain. The use of multiple end-entity certificates introduces new security considerations. In particular, a peer that authenticates another peer via non-composite hybrid authentication may desire, in addition to the typical certificate validity checks that are performed, some form of assurance that the end-entity certificates used in each authentication are owned by the same entity. This assurance can be accomplished at the protocol level, through an additional check that compares Subjects or SANs of each end-entity certificate, or more strongly at the PKI level, through a certificate extension defined in [draft-becker-guthrie-cert-binding-for-multi-auth-00] .¶
The main use case for non-composite hybrid authentication is a circumstance that may arise during the PQ migration period. In particular, an entity may decide to pursue non-composite hybrid authentication, in which authentication is performed once with a traditional signature and certificate chain that it already possesses, and then again with a PQ signature and certificate chain it obtains in order to migrate to PQC.¶
In order to provide the security promised by hybrid authentication, protocols should validate all digital signatures received before communication is considered authenticated. There may be exceptions where communication can still be considered authenticated if a subset of authentications is either not performed or not successful. For example, if peers are using this approach to facilitate the transition between traditional algorithms and PQ algorithms, the peers may agree that successful validation of the PQ digital signature is sufficient to provide authentication.¶
The solutions posed in the following sections are backwards compatible with currently existing traditional algorithms-based certificates. Additionally, these solutions allow the PQ-based certificates used for this hybrid solution to also be used for future authentication solutions when users may choose to rely upon PQ signatures and certificates unaccompanied by traditional cryptography, i.e., without needing to issue new PQ certificates when users no longer wish to support or deploy hybrid solutions for authentication. Note that, while these solutions are broad, they are presented in this document with respect to the PQ migration use case, in which a single traditional algorithm and a single PQ algorithm are used simultaneously.¶
End-entity certificates used in non-composite hybrid authentication should only be used in the same protocol if they are owned by the same entity. It may be sufficient to check the ownership of each certificate at the protocol level by verifying that the Subject or SAN is the same on every certificate, prior to validating the signatures. This check provides a low cost, flexible mechanism with which to indicate that end-entity certificates used in a given protocol belong to the same entity.¶
However, there are scenarios where this method is not sufficient to determine ownership. For example, if the Subject or SAN of an end-entity certificate has changed between the issuance of certificates, the Subject or SAN certificate fields may not match even though the end entity is the same.¶
In the event described in the previous section, or in any event when an endpoint involved in authentication desires additional assurance of certificate ownership, users can support the bindingRequest CSR attribute and the X.509v3 certificate extension, BoundCertificates, as defined in [draft-becker-guthrie-cert-binding-for-multi-auth-00]. These mechanisms provide additional assurance at the PKI level that multiple end-entity certificates each belong to the same entity.¶
For example, when an end entity is already in possession of a traditional algorithm-based certificate and wishes to obtain a PQ certificate, it submits a CSR containing the bindingRequest attribute. The CA that receives the CSR validates the signature field in the attribute using the public key of the traditional certificate. The CA can then issue the PQ certificate containing the BoundCertificates extension, which contains information identifying the traditional certificate that the PQ certificate is being bound to.¶
If the receiving peer does not support the BoundCertificates extension, it can ignore the extension (as it is non-critical), and fall back to protocol-level enforcement of certificate ownership.¶
In order to extend the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296] to support non-composite hybrid authentication, peers must be able to send multiple AUTH payloads, which contain signed bits, and corresponding CERT payloads, which contain certificates. Because IKEv2 currently supports use of only a single AUTH payload by each peer, this approach requires the introduction of a Notify Payload that indicates to the receiving peer that the sender:¶
To achieve the initial set of requirements and the following set of desired outcomes, the Notify Payload, N(SUPPORTED_AUTH_METHODS), defined in [I-D.draft-smyslov-ipsecme-ikev2-auth-announce] can be leveraged. N(SUPPORTED_AUTH_METHODS), which is first sent by the responder in IKE_SA_INIT, announces the authentication methods that the sender supports. This, in conjunction with a new Notify Payload that alerts the receiver of the sender's intent to do multiple authentications, along with information about how many authentications can be performed and instructions for how to delineate the list of announcements into choices for each authentication, provides sufficient information for both peers to perform multiple authentications with dually supported algorithms. After the responder sends these Notify Payloads in IKE_SA_INIT, the initiator can choose to oblige the responder's request for multiple authentications by sending additional AUTH payloads and corresponding CERT payloads in its IKE_AUTH message. If the initiator would also like for the responder to authenticate itself multiple times, it sends the same set of Notify Payloads. The responder can then also opt in and send additional AUTH payloads and corresponding CERT payloads in its IKE_AUTH message.¶
A peer that supports the BoundCertificates extension, upon receipt of certificates, will check to see if the BoundCertificates extension is present in the end-entity certificate corresponding to the PQ digital signature algorithm. If the extension is present, the peer will perform the check specified in [draft-becker-guthrie-cert-binding-for-multi-auth-00]. If the extension is not present or not supported, the peer should check that the Subjects/SANs listed in each end-entity certificate match. It may be possible to use the PAD [RFC4301] to assist with this check.¶
In order to facilitate non-composite hybrid authentication in TLS 1.3 [RFC8446], several alterations are necessary. First, the Key Exchange messages must be enabled to negotiate the use of multiple certificates (for simplicity, this description focuses on two certificates). To indicate its request for hybrid authentication, the client can include a flag via the "tls_flags" extension [I-D.draft-ietf-tls-tlsflags] in the ClientHello that alerts the server to its desire to use two certificate chains for authentication.¶
The client can include two extensions that effect negotiation of multiple signature algorithms; for example, the "signature_algorithms" extension and an appropriately named duplicate of this extension, where each list negotiates a different type of algorithm. (Similarly, client can optionally include the "signature_algorithms_cert" extension and it's appropriately named duplicate for PQ algorithms.) Note that TLS 1.3 implementations are currently designed to only send, receive, and process a single "signature_algorithms" extension and a single "signature_algorithms_cert" extension, so the use of additional "signature_algorithms(_cert)" extensions will require renaming any additional "signature_algorithms(_cert)" extensions so that they are distinct from the original "signature_algorithms(_cert)" extensions.¶
If the server is willing to use non-composite hybrid authentication for this connection, it responds by sending the "tls_flags" extension with the bit set for the hybrid_auth flag in the ServerHello to acknowledge its support for this feature. This flag extension can also be used in a CertificateRequest message from the server, and if it is requesting hybrid authentication from the client, then the CertificateRequest must also include the two extensions for negotiating signature algorithms.¶
The Authentication Messages also require changes to accommodate non-composite hybrid authentication, namely via duplication of several existing extensions. If non-composite hybrid authentication is negotiated, then the server sends two Certificate messages, where each conveys a distinct certificate chain to the peer (i.e., one traditional chain and one PQ chain). This requires the server to send two individual CertificateVerify messages to the client, where the signature algorithms used in each CertificateVerify message are selected from the "signature_algorithm" extensions sent by the client. The content covered under the signature is the same in each CertificateVerify message, but the Transcript-Hash is computed once for each signature with the corresponding Certificate included in the appropriate hash.¶
If the implementation requires the BoundCertificates extension, then the server must check that the BoundCertificates extension is present in the appropriate end-entity certificate, and verify ownership as detailed in [draft-becker-guthrie-cert-binding-for-multi-auth-00]. If the implementation does not require this certificate extension, then the server should check that the Subject/SAN listed in each end-entity certificate is the same.¶
The Finished message contains verification data built from a hash of all handshake messages, which includes both sets of Certificate and CertificateVerify messages in the case of non-composite hybrid authentication.¶
The use of non-composite hybrid authentication introduces an additional security consideration, in that peers in receipt of multiple end-entity certificates need to confirm that each certificate is owned by the sender. This document outlines two schemes to perform such a check, one at the protocol level, and the other at the PKI level. Technical details for the latter approach can be found in [draft-becker-guthrie-cert-binding-for-multi-auth-00].¶
It is worth noting that any hybrid solution introduces complexity into a protocol. This complexity can manifest in different ways, including but not limited to: extensions to protocols, changes to public key infrastructure, or modifications to cryptographic libraries. Depending on the implementation, it may be advantageous to limit the areas in which alterations are made, in order to mitigate increases in complexity and streamline further security assessments that may be required as a result of such changes.¶
All hybrid implementations are vulnerable to a downgrade attack in which a malicious peer does not express support for PQ algorithms, resulting in an exchange that can only rely upon traditional algorithms for security.¶