Announcing Supported Authentication Methods in IKEv2

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 20 October 2024.¶

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

The Internet Key Exchange version 2 (IKEv2) protocol, defined in [RFC7296], performs authenticated key exchange in IPsec. IKEv2, unlike its predecessor IKEv1, defined in [RFC2409], doesn't include a mechanism to negotiate an authentication method that the peers would use to authenticate each other. It is assumed that each peer selects whatever authentication method it thinks is appropriate, depending on authentication credentials it has.¶

This approach generally works well when there is no ambiguity in selecting authentication credentials. SA establishment failure between peers may arise when there are several credentials of different types configured on one peer, while only some of them are supported on the other peer. Another problem situation is when a single credential may be used to produce different types of authentication tokens (e.g. signatures of different formats). Since IKEv2 requires that each peer uses exactly one authentication method and doesn't provide means for peers to indicate to the other side which authentication methods they support, it is possible that in these situations the peer that supports wider range of authentication methods (or authentication token formats) improperly selects the method (or format) which is not supported by the other side.¶

Emerging post-quantum signature algorithms may bring additional challenges for implementations, especially if so-called hybrid schemes are used (e.g. see [I-D.ounsworth-pq-composite-sigs]).¶

This specification defines an extension to the IKEv2 protocol that allows peers to announce their supported authentication methods, thus decreasing risks of SA establishment failure in situations when there are several ways for the peers to authenticate themselves.¶

2. Terminology and Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Protocol Details

When establishing IKE SA each party may send a list of authentication methods it supports and is configured to use to its peer. For this purpose this specification introduces a new Notify Message Type SUPPORTED_AUTH_METHODS. The Notify payload with this Notify Message Type is utilized to convey the supported authentication methods of the party sending it. The sending party may additionally specify that some of the authentication methods are only for use with the particular trust anchors. The receiving party may take this information into consideration when selecting an algorithm for its authentication (i.e., the algorithm used for calculation of the AUTH payload) if several alternatives are available. To simplify the receiver's task of linking the announced authentication methods with the trust anchors, the protocol ensures that the SUPPORTED_AUTH_METHODS notification is always co-located with the CERTREQ payload in the same message.¶

Initiator                              Responder
-----------                            -----------
HDR, SAi1, KEi, Ni -->
                                   <-- HDR, SAr1, KEr, Nr, [CERTREQ,]
                                     [N(SUPPORTED_AUTH_METHODS)(...)]

Initiator                              Responder
-----------                            -----------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr,
[N(SUPPORTED_AUTH_METHODS)(...)] }  -->
                                   <-- HDR, SK {IDr, [CERT,]
                                            AUTH, SAr2, TSi, TSr }

Initiator                              Responder
-----------                            -----------
HDR, SAi1, KEi, Ni -->
                                   <-- HDR, SAr1, KEr, Nr, [CERTREQ,]
                                       [N(SUPPORTED_AUTH_METHODS)()]

HDR, SK {..., [IDi, [IDr,]]}  -->
                                   <-- HDR, SK {..., [CERTREQ,]
                                   [N(SUPPORTED_AUTH_METHODS)(...)] }

HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr,
[N(SUPPORTED_AUTH_METHODS)(...)] }  -->
                                   <-- HDR, SK {IDr, [CERT,]
                                            AUTH, SAr2, TSi, TSr }

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Protocol ID  |   SPI Size    |      Notify Message Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~          List of Supported Auth Methods Announcements         ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Length (=2)  |  Auth Method  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     1                   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Length (=3)  |  Auth Method  |   Cert Link   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Length (>3)  |  Auth Method  |   Cert Link   |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
|                                                               |
~                AlgorithmIdentifier ASN.1 object               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4. Interaction with IKEv2 Extensions concerning Authentication

Generally in IKEv2 each party independently determines the way it authenticates itself to the peer. In other words, authentication methods selected by the peers need not be the same. However, some IKEv2 extensions break this rule.¶

The prominent example is [RFC6467], (Secure Password Framework for Internet Key Exchange Version 2), which defines a framework for using Password-authenticated key exchanges (PAKE) in IKEv2. With this framework peers negotiate using one of PAKE methods in the IKE_SA_INIT exchange - the initiator sends a list of supported PAKE methods in the request and the responder picks one of them and sends it back in the response.¶

If peers negotiate PAKE for authentication, then the selected PAKE method is used by both initiator and responder and no other authentication methods are involved. For this reason there is no point to announce supported authentication methods in this case. Thus, if the peers choose to go with PAKE, they MUST NOT send the SUPPORTED_AUTH_METHODS notification.¶

If peers are going to use Multiple Authentication Exchanges [RFC4739], then they MAY include multiple SUPPORTED_AUTH_METHODS notifications instead of one, each containing authentication methods appropriate for each authentication round. The notifications are included in the order of the preference of performing authentication rounds.¶

5. Security Considerations

Security considerations for IKEv2 protocol are discussed in [RFC7296]. Security properties of different authentication methods varies. Refer to corresponding documents, listed in [IKEV2-IANA] for discussion of security properties of each authentication method.¶

Announcing authentication methods gives an eavesdropper additional information about peers' capabilities. If a peer advertises NULL authentication along with other methods, then active attacker on the path can encourage peers to use NULL authentication by removing all other announcements. Note, that this is not a real "downgrade" attack, since authentication methods in IKEv2 are not negotiated and in this case NULL authentication should be allowed by local security policy.¶

Similarly, if an attacker on the path can break some of the announced authentication methods online, then the attacker can encourage peers to use one of these weaker methods by removing all other announcements, and if this succeeds, then perform person-in-the-middle attack.¶

6. IANA Considerations

This document defines a new Notify Message Type in the "IKEv2 Notify Message Status Types" registry referencing this RFC:¶

  <TBA>       SUPPORTED_AUTH_METHODS    [RFCXXXX]

Appendix A. Examples of Announcing Supported Authentication Methods

This appendix shows some examples of announcing authentication methods. This appendix is purely informative; if it disagrees with the body of this document, the other text is considered correct. Note that some payloads that are not relevant to this specification may be omitted for brevity.¶

Initiator                              Responder
-----------                            -----------
                     IKE_SA_INIT
HDR, SAi1, KEi, Ni -->
                                   <-- HDR, SAr1, KEr, Nr,
                                       N(SUPPORTED_AUTH_METHODS(
                                       PSK, NULL))

                      IKE_AUTH
HDR, SK {IDi,
AUTH, SAi2, TSi, TSr,
N(SUPPORTED_AUTH_METHODS(PSK))}  -->
                                   <-- HDR, SK {IDr,
                                       AUTH, SAr2, TSi, TSr}

Initiator                              Responder
-----------                            -----------
                     IKE_SA_INIT
HDR, SAi1, KEi, Ni,
N(SIGNATURE_HASH_ALGORITHMS) -->
                                   <-- HDR, SAr1, KEr, Nr,
                                       CERTREQ(CA1, CA2, CA3),
                                       N(SIGNATURE_HASH_ALGORITHMS),
                                       N(SUPPORTED_AUTH_METHODS())

                   IKE_INTERMEDIATE
HDR, SK {..., IDi]}  -->
                                   <-- HDR, SK {...,
                                       CERTREQ(CA1, CA2, CA3),
                                       N(SUPPORTED_AUTH_METHODS(
                                       SIGNATURE(RSASSA-PSS:1),
                                       SIGNATURE(RSASSA-PSS:2),
                                       SIGNATURE(ECDSA:3)))}

                      IKE_AUTH
HDR, SK {IDi, CERT, CERTREQ(CA2),
AUTH, SAi2, TSi, TSr,
N(SUPPORTED_AUTH_METHODS(
SIGNATURE(RSASSA-PSS:0)))}  -->
                                   <-- HDR, SK {IDr, CERT,
                                       AUTH, SAr2, TSi, TSr}

Author's Address