Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS Intended status: Standards Track February 21, 2022 Expires: August 25, 2022 Announcing Supported Authentication Methods in IKEv2 draft-ietf-ipsecme-ikev2-auth-announce-00 Abstract This specification defines a mechanism that allows the Internet Key Exchange version 2 (IKEv2) implementations to indicate the list of supported authentication methods to their peers while establishing IKEv2 Security Association (SA). This mechanism improves interoperability when IKEv2 partners are configured with multiple different credentials to authenticate each other. 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 August 25, 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 Simplified BSD License text as described in Section 4.e of Smyslov Expires August 25, 2022 [Page 1] Internet-Draft Announcing Supported Auth Methods February 2022 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. SUPPORTED_AUTH_METHODS Notify . . . . . . . . . . . . . . 4 3.2.1. 2-octet Announcement . . . . . . . . . . . . . . . . 5 3.2.2. 3-octet Announcement . . . . . . . . . . . . . . . . 6 3.2.3. Multi-octet Announcement . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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. The problem may arise when there are several credentials of different type 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). 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. Smyslov Expires August 25, 2022 [Page 2] Internet-Draft Announcing Supported Auth Methods February 2022 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 The idea is that each party sends a list of authentication methods it supports to its peer. In addition, the sending party may optionally specify that some of the authentication methods are only to be used with particular trust anchors. Upon receiving this information the peer may take it into account while selecting an algorithm for its authentication if several methods are available. 3.1. Exchanges If the responder is willing to use this extension, it includes a new notification SUPPORTED_AUTH_METHODS in a response message of the IKE_SA_INIT exchange. This notification contains a list of authentication methods supported by the responder. Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ,] [N(SUPPORTED_AUTH_METHODS)] Figure 1: IKE_SA_INIT Exchange If the initiator doesn't support this extension, it will ignore the received notification as an unknown status notify. Otherwise, it MAY send the SUPPORTED_AUTH_METHODS notification in the IKE_AUTH request message, with a list of authentication methods supported by the initiator. Initiator Responder ----------- ----------- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr, [N(SUPPORTED_AUTH_METHODS)] } --> <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr } Figure 2: IKE_AUTH Exchange Smyslov Expires August 25, 2022 [Page 3] Internet-Draft Announcing Supported Auth Methods February 2022 Since the responder sends the SUPPORTED_AUTH_METHODS notification in the IKE_SA_INIT exchange, it must take care that the size of the response message wouldn't grow too much so that IP fragmentation takes place. If the following conditions are met: o the SUPPORTED_AUTH_METHODS notification to be included is so large, that the responder suspects that IP fragmentation of the resulting IKE_SA_INIT response message may happen; o both peers support the IKE_INTERMEDIATE exchange, defined in [I-D.ietf-ipsecme-ikev2-intermediate] (i.e. the responder has received and is going to send the INTERMEDIATE_EXCHANGE_SUPPORTED notification); then the responder may choose not to send actual list of the supported authentication methods in the IKE_SA_INIT exchange and instead ask the initiator to start the IKE_INTERMEDIATE exchange for the list to be sent in. In this case the responder includes SUPPORTED_AUTH_METHODS notification containing no data in the IKE_SA_INIT response. If the initiator receives the empty SUPPORTED_AUTH_METHODS notification in the IKE_SA_INIT exchange, it means that the responder is going to send the list of the supported authentication methods in the IKE_INTERMEDIATE exchange. If this exchange is to be initiated anyway for some other reason, then the responder MUST use it to send the SUPPORTED_AUTH_METHODS notification. Otherwise, the initiator MAY start the IKE_INTERMEDIATE exchange just for this sole purpose by sending an empty request message. Initiator Responder ----------- ----------- HDR, SK {...} --> <-- HDR, SK {... [N(SUPPORTED_AUTH_METHODS)] } Figure 3: IKE_INTERMEDIATE Exchange Note, that sending the SUPPORTED_AUTH_METHODS notification and using information obtained from it is optional for both the initiator and the responder. 3.2. SUPPORTED_AUTH_METHODS Notify The format of the SUPPORTED_AUTH_METHODS notification is shown below. Smyslov Expires August 25, 2022 [Page 4] Internet-Draft Announcing Supported Auth Methods February 2022 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: SUPPORTED_AUTH_METHODS Notify The Notify payload format is defined in Section 3.10 of [RFC7296]. When a Notify payload of type SUPPORTED_AUTH_METHODS is sent, the Protocol ID field is set to 0, the SPI Size is set to 0, meaning there is no SPI field, and the Notify Message Type is set to . The Notification Data field contains the list of supported authentication methods announcements. Each individual announcement is a variable-size data blob, which format depends on the announced authentication method. The blob always starts with an octet containing the length of the blob followed by an octet containing the authentication method. Authentication methods are represented as values from the "IKEv2 Authentication Method" registry defined in [IKEV2-IANA]. The meaning of the remaining octets of the blob, if any, depends on the authentication method and is defined below. Note, that for the currently defined authentication methods the length octet fully defines both the format and the semantics of the blob. If more authentication methods are defined in future, the corresponding documents must describe the semantics of the announcements for these methods. Implementations MUST skip announcements which semantics they don't understand. 3.2.1. 2-octet Announcement If the announcement contains an authentication method that is not concerned with public key cryptography, then the following format is used. Smyslov Expires August 25, 2022 [Page 5] Internet-Draft Announcing Supported Auth Methods February 2022 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (=2) | Auth Method | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Supported Authentication Method o Length - Length of the blob, must be 2 for this case. o Auth Method - Announced authentication method. This format is applicable for the authentication methods "Shared Key Message Integrity Code" (2) and "NULL Authentication" (13). Note, that authentication method "Generic Secure Password Authentication Method" (12) would also fall in this category, however it is negotiated separately (see [RFC6467] and for this reason there is no point to announce it via this mechanism. 3.2.2. 3-octet Announcement If the announcement contains an authentication method that is concerned with public key cryptography, then the following format is used. This format allows to link the announcement with a particular trust anchor from the Certificate Request payload. 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 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (=3) | Auth Method | Cert Link | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Supported Authentication Method o Length - Length of the blob, must be 3 for this case. o Auth Method - Announced authentication method. o Cert Link - Link this announcement to a particular CA. If the Cert Link field contains non-zero value N, it means that the announced authentication method is intended to be used only with the N-th trust anchor (CA certificate) from the Certificate Request payload(s) sent by this peer. If it is zero, then this authentication method may be used with any of CAs, that are not linked to any other announcement. If multiple CERTREQ payloads were sent, the CAs from all of them are treated as a single list for the purpose of the linking. If no Certificate Request payload were Smyslov Expires August 25, 2022 [Page 6] Internet-Draft Announcing Supported Auth Methods February 2022 receives, the content of this field MUST be ignored and treated as zero. This format is applicable for the authentication methods "RSA Digital Signature" (1), "DSS Digital Signature" (3), "ECDSA with SHA-256 on the P-256 curve" (9), "ECDSA with SHA-384 on the P-384 curve" (10) and "ECDSA with SHA-512 on the P-512 curve" (11). Note however, that these authentication methods are currently superseded by the "Digital Signature" (14) authentication method, which has a different announcement format, described below. 3.2.3. Multi-octet Announcement The following format is currently used only with the "Digital Signature" (14) authentication method. 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Supported Authentication Method o Length - Length of the blob, must be greater than 3 for this case. o Auth Method - Announced authentication method, currently may only be 14 ("Digital Signature"). o Cert Link - Link this announcement to a particular CA; see Section 3.2.2 for details. o AlgorithmIdentifier ASN.1 object - DER-encoded ASN.1 object AlgorithmIdentifier. The "Digital Signature" authentication method, defined in [RFC7427], supersedes previously defined signature authentication methods. In this case the real authentication algorithm is identified via AlgorithmIdentifier ASN.1 object. Appendix A in [RFC7427] contains examples of Commonly Used ASN.1 Objects. Smyslov Expires August 25, 2022 [Page 7] Internet-Draft Announcing Supported Auth Methods February 2022 4. Security Considerations Security considerations for IKEv2 protocol are discussed in [RFC7296]. It is believed that this extension of the IKEv2 doesn't add new vulnerabilities to the protocol. 5. IANA Considerations This document defines a new Notify Message Types in the "Notify Message Types - Status Types" registry: SUPPORTED_AUTH_METHODS 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, DOI 10.17487/RFC7427, January 2015, . [I-D.ietf-ipsecme-ikev2-intermediate] Smyslov, V., "Intermediate Exchange in the IKEv2 Protocol", draft-ietf-ipsecme-ikev2-intermediate-08 (work in progress), February 2022. [IKEV2-IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", . Smyslov Expires August 25, 2022 [Page 8] Internet-Draft Announcing Supported Auth Methods February 2022 6.2. Informative References [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, . [RFC6467] Kivinen, T., "Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)", RFC 6467, DOI 10.17487/RFC6467, December 2011, . [I-D.ounsworth-pq-composite-sigs] Ounsworth, M. and M. Pala, "Composite Signatures For Use In Internet PKI", draft-ounsworth-pq-composite-sigs-06 (work in progress), February 2022. Author's Address Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 RU Phone: +7 495 276 0211 Email: svan@elvis.ru Smyslov Expires August 25, 2022 [Page 9]