Network Working Group                                          A. Becker
Internet-Draft                                                R. Guthrie
Intended status: Informational                                M. Jenkins
Expires: 23 September 2022                                           NSA
                                                           22 March 2022


Non-Composite Hybrid Authentication in PKIX and Applications to Internet
                               Protocols
            draft-becker-guthrie-noncomposite-hybrid-auth-00

Abstract

   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.

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 23 September 2022.



Becker, et al.          Expires 23 September 2022               [Page 1]


Internet-Draft          Non-composite hybrid auth             March 2022


Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Hybrid Solution Space . . . . . . . . . . . . . . . . . . . .   3
   3.  General Considerations for Non-Composite Hybrid
           Authentication  . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  PQ Migration Use Case . . . . . . . . . . . . . . . . . .   4
     3.2.  Protocol-Level Ownership Assertion  . . . . . . . . . . .   5
     3.3.  PKI-Level Ownership Assertion . . . . . . . . . . . . . .   5
   4.  Non-Composite Hybrid Authentication in Internet Protocols . .   6
     4.1.  IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  TLS 1.3 . . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   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



Becker, et al.          Expires 23 September 2022               [Page 2]


Internet-Draft          Non-composite hybrid auth             March 2022


   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.

2.  Hybrid Solution Space

   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:

   *  Composite solutions are those in which both algorithms function
      together within a protocol, as one entity.  Composite solutions
      alter cryptographic structures and processes (certificate
      structures, digital signature structures, key share structure,
      validation processes, etc.) in order to minimize changes to
      protocol logic.

   *  Non-composite solutions are those in which each algorithm
      functions discretely within a protocol, as an individual entity.
      Non-composite solutions effect changes at the protocol level in
      order to minimize changes to cryptographic structures and
      processes.

   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



Becker, et al.          Expires 23 September 2022               [Page 3]


Internet-Draft          Non-composite hybrid auth             March 2022


   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.

3.  General Considerations for Non-Composite Hybrid Authentication

   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] .

3.1.  PQ Migration Use Case

   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.





Becker, et al.          Expires 23 September 2022               [Page 4]


Internet-Draft          Non-composite hybrid auth             March 2022


   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.

3.2.  Protocol-Level Ownership Assertion

   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.

3.3.  PKI-Level Ownership Assertion

   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



Becker, et al.          Expires 23 September 2022               [Page 5]


Internet-Draft          Non-composite hybrid auth             March 2022


   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.

4.  Non-Composite Hybrid Authentication in Internet Protocols

4.1.  IKEv2

   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:

   1  how many authentications it would like to perform, and

   2  what algorithms it would support and/or prefer using for each
      authentication.

   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



Becker, et al.          Expires 23 September 2022               [Page 6]


Internet-Draft          Non-composite hybrid auth             March 2022


   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.

4.2.  TLS 1.3

   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



Becker, et al.          Expires 23 September 2022               [Page 7]


Internet-Draft          Non-composite hybrid auth             March 2022


   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.

5.  Security Considerations

   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].










Becker, et al.          Expires 23 September 2022               [Page 8]


Internet-Draft          Non-composite hybrid auth             March 2022


   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.

6.  References

   [draft-becker-guthrie-cert-binding-for-multi-auth-00]
              Becker, A., Guthrie, R., Jenkins, M., and D. Nisbeth,
              "Binding Certificates for Multiple Authentications within
              a Protocol", March 2022.

   [I-D.draft-ietf-ipsecme-ikev2-multiple-ke]
              Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
              Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
              Key Exchanges in IKEv2", September 2021,
              <https://datatracker.ietf.org/doc/draft-ietf-ipsecme-
              ikev2-multiple-ke/04/>.

   [I-D.draft-ietf-tls-hybrid-design]
              Stebila, D., Fluhrer, S., Gueron, S., and U. Haifa,
              "Hybrid key exchange in TLS 1.3", January 2022,
              <https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-
              design/04/>.

   [I-D.draft-ietf-tls-tlsflags]
              Nir, Y., "A Flags Extension for TLS 1.3", March 2022,
              <https://datatracker.ietf.org/doc/draft-ietf-tls-
              tlsflags/>.

   [I-D.draft-ounsworth-pq-composite-keys]
              Ounsworth, M. and M. Pala, "Composite Public and Private
              Keys For Use In Internet PKI", February 2022,
              <https://datatracker.ietf.org/doc/draft-ounsworth-pq-
              composite-keys/>.







Becker, et al.          Expires 23 September 2022               [Page 9]


Internet-Draft          Non-composite hybrid auth             March 2022


   [I-D.draft-ounsworth-pq-composite-sigs]
              Ounsworth, M. and M. Pala, "Composite Signatures For Use
              In Internet PKI", February 2022,
              <https://datatracker.ietf.org/doc/draft-ounsworth-pq-
              composite-sigs/06/>.

   [I-D.draft-smyslov-ipsecme-ikev2-auth-announce]
              Smyslov, V., "Announcing Supported Authentication Methods
              in IKEv2", August 2021, <https://datatracker.ietf.org/doc/
              draft-smyslov-ipsecme-ikev2-auth-announce/>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [X509]     ITU-T, "Information technology – Open Systems
              Interconnection - The Directory: Public-key and attribute
              certificate frameworks", October 2019,
              <https://www.itu.int/rec/T-REC-X.509>.

Authors' Addresses

   Alison Becker
   National Security Agency
   Email: aebecke@uwe.nsa.gov


   Rebecca Guthrie
   National Security Agency
   Email: rmguthr@uwe.nsa.gov


   Michael Jenkins
   National Security Agency
   Email: mjjenki@cyber.nsa.gov







Becker, et al.          Expires 23 September 2022              [Page 10]