idnits 2.17.1 draft-smyslov-ipsecme-ikev2-auth-announce-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2021) is 1142 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-ipsecme-ikev2-intermediate-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2-IANA' -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) == Outdated reference: A later version (-13) exists of draft-ounsworth-pq-composite-sigs-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Smyslov 3 Internet-Draft ELVIS-PLUS 4 Intended status: Standards Track March 9, 2021 5 Expires: September 10, 2021 7 Announcing Supported Authentication Methods in IKEv2 8 draft-smyslov-ipsecme-ikev2-auth-announce-03 10 Abstract 12 This specification defines a mechanism that allows the Internet Key 13 Exchange version 2 (IKEv2) implementations to indicate the list of 14 supported authentication methods to their peers while establishing 15 IKEv2 Security Association (SA). This mechanism improves 16 interoperability when IKEv2 partners are configured with multiple 17 different credentials to authenticate each other. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 10, 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 55 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. SUPPORTED_AUTH_METHODS Notify . . . . . . . . . . . . . . 4 58 3.2.1. 2-octet Announcement . . . . . . . . . . . . . . . . 5 59 3.2.2. 3-octet Announcement . . . . . . . . . . . . . . . . 6 60 3.2.3. Multi-octet Announcement . . . . . . . . . . . . . . 7 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 6.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 The Internet Key Exchange version 2 (IKEv2) protocol, defined in 71 [RFC7296], performs authenticated key exchange in IPsec. IKEv2, 72 unlike its predecessor IKEv1, defined in [RFC2409], doesn't include a 73 mechanism to negotiate an authentication method that the peers would 74 use to authenticate each other. It is assumed that each peer selects 75 whatever authentication method it thinks is appropriate, depending on 76 authentication credentials it has. 78 This approach generally works well when there is no ambiguity in 79 selecting authentication credentials. The problem may arise when 80 there are several credentials of different type configured on one 81 peer, while only some of them are supported on the other peer. 82 Another problem situation is when a single credential may be used to 83 produce different types of authentication tokens (e.g. signatures of 84 different formats). Emerging post-quantum signature algorithms may 85 bring additional challenges for implementations, especially if so 86 called hybrid schemes are used (e.g. see 87 [I-D.ounsworth-pq-composite-sigs]). 89 This specification defines an extension to the IKEv2 protocol that 90 allows peers to announce their supported authentication methods, thus 91 decreasing risks of SA establishment failure in situations when there 92 are several ways for the peers to authenticate themselves. 94 2. Terminology and Notation 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 3. Protocol Details 104 The idea is that each party sends a list of authentication methods it 105 supports to its peer. In addition, the sending party may optionally 106 specify that some of the authentication methods are only to be used 107 with particular trust anchors. Upon receiving this information the 108 peer may take it into account while selecting an algorithm for its 109 authentication if several methods are available. 111 3.1. Exchanges 113 If the responder is willing to use this extension, it includes a new 114 notification SUPPORTED_AUTH_METHODS in a response message of the 115 IKE_SA_INIT exchange. This notification contains a list of 116 authentication methods supported by the responder. 118 Initiator Responder 119 ----------- ----------- 120 HDR, SAi1, KEi, Ni --> 121 <-- HDR, SAr1, KEr, Nr, [CERTREQ,] 122 [N(SUPPORTED_AUTH_METHODS)] 124 Figure 1: IKE_SA_INIT Exchange 126 If the initiator doesn't support this extension, it will ignore the 127 received notification as an unknown status notify. Otherwise, it MAY 128 send the SUPPORTED_AUTH_METHODS notification in the IKE_AUTH request 129 message, with a list of authentication methods supported by the 130 initiator. 132 Initiator Responder 133 ----------- ----------- 134 HDR, SK {IDi, [CERT,] [CERTREQ,] 135 [IDr,] AUTH, SAi2, TSi, TSr, 136 [N(SUPPORTED_AUTH_METHODS)] } --> 137 <-- HDR, SK {IDr, [CERT,] 138 AUTH, SAr2, TSi, TSr } 140 Figure 2: IKE_AUTH Exchange 142 Since the responder sends the SUPPORTED_AUTH_METHODS notification in 143 the IKE_SA_INIT exchange, it must take care that the size of the 144 response message wouldn't grow too much so that IP fragmentation 145 takes place. If the following conditions are met: 147 o the SUPPORTED_AUTH_METHODS notification to be included is so 148 large, that the responder suspects that IP fragmentation of the 149 resulting IKE_SA_INIT response message may happen; 151 o both peers support the IKE_INTERMEDIATE exchange, defined in 152 [I-D.ietf-ipsecme-ikev2-intermediate] (i.e. the responder has 153 received and is going to send the INTERMEDIATE_EXCHANGE_SUPPORTED 154 notification); 156 then the responder may choose not to send actual list of the 157 supported authentication methods in the IKE_SA_INIT exchange and 158 instead ask the initiator to start the IKE_INTERMEDIATE exchange for 159 the list to be sent in. In this case the responder includes 160 SUPPORTED_AUTH_METHODS notification containing no data in the 161 IKE_SA_INIT response. 163 If the initiator receives the empty SUPPORTED_AUTH_METHODS 164 notification in the IKE_SA_INIT exchange, it means that the responder 165 is going to send the list of the supported authentication methods in 166 the IKE_INTERMEDIATE exchange. If this exchange is to be initiated 167 anyway for some other reason, then the responder MUST use it to send 168 the SUPPORTED_AUTH_METHODS notification. Otherwise, the initiator 169 MAY start the IKE_INTERMEDIATE exchange just for this sole purpose by 170 sending an empty request message. 172 Initiator Responder 173 ----------- ----------- 174 HDR, SK {...} --> 175 <-- HDR, SK {... 176 [N(SUPPORTED_AUTH_METHODS)] } 178 Figure 3: IKE_INTERMEDIATE Exchange 180 Note, that sending the SUPPORTED_AUTH_METHODS notification and using 181 information obtained from it is optional for both the initiator and 182 the responder. 184 3.2. SUPPORTED_AUTH_METHODS Notify 186 The format of the SUPPORTED_AUTH_METHODS notification is shown below. 188 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Next Payload |C| RESERVED | Payload Length | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Protocol ID | SPI Size | Notify Message Type | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | | 196 ~ List of Supported Auth Methods Announcements ~ 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Figure 4: SUPPORTED_AUTH_METHODS Notify 202 The Notify payload format is defined in Section 3.10 of [RFC7296]. 203 When a Notify payload of type SUPPORTED_AUTH_METHODS is sent, the 204 Protocol ID field is set to 0, the SPI Size is set to 0, meaning 205 there is no SPI field, and the Notify Message Type is set to . 208 The Notification Data field contains the list of supported 209 authentication methods announcements. Each individual announcement 210 is a variable-size data blob, which format depends on the announced 211 authentication method. The blob always starts with an octet 212 containing the length of the blob followed by an octet containing the 213 authentication method. Authentication methods are represented as 214 values from the "IKEv2 Authentication Method" registry defined in 215 [IKEV2-IANA]. The meaning of the remaining octets of the blob, if 216 any, depends on the authentication method and is defined below. 217 Note, that for the currently defined authentication methods the 218 length octet fully defines both the format and the semantics of the 219 blob. 221 If more authentication methods are defined in future, the 222 corresponding documents must describe the semantics of the 223 announcements for these methods. Implementations MUST skip 224 announcements which semantics they don't understand. 226 3.2.1. 2-octet Announcement 228 If the announcement contains an authentication method that is not 229 concerned with public key cryptography, then the following format is 230 used. 232 1 233 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Length (=2) | Auth Method | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 5: Supported Authentication Method 240 o Length - Length of the blob, must be 2 for this case. 242 o Auth Method - Announced authentication method. 244 This format is applicable for the authentication methods "Shared Key 245 Message Integrity Code" (2) and "NULL Authentication" (13). Note, 246 that authentication method "Generic Secure Password Authentication 247 Method" (12) would also fall in this category, however it is 248 negotiated separately (see [RFC6467] and for this reason there is no 249 point to announce it via this mechanism. 251 3.2.2. 3-octet Announcement 253 If the announcement contains an authentication method that is 254 concerned with public key cryptography, then the following format is 255 used. This format allows to link the announcement with a particular 256 trust anchor from the Certificate Request payload. 258 1 2 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Length (=3) | Auth Method | Cert Link | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 6: Supported Authentication Method 266 o Length - Length of the blob, must be 3 for this case. 268 o Auth Method - Announced authentication method. 270 o Cert Link - Link this announcement to a particular CA. 272 If the Cert Link field contains non-zero value N, it means that the 273 announced authentication method is intended to be used only with the 274 N-th trust anchor (CA certificate) from the Certificate Request 275 payload(s) sent by this peer. If it is zero, then this 276 authentication method may be used with any of CAs, that are not 277 linked to any other announcement. If multiple CERTREQ payloads were 278 sent, the CAs from all of them are treated as a single list for the 279 purpose of the linking. If no Certificate Request payload were 280 receives, the content of this field MUST be ignored and treated as 281 zero. 283 This format is applicable for the authentication methods "RSA Digital 284 Signature" (1), "DSS Digital Signature" (3), "ECDSA with SHA-256 on 285 the P-256 curve" (9), "ECDSA with SHA-384 on the P-384 curve" (10) 286 and "ECDSA with SHA-512 on the P-512 curve" (11). Note however, that 287 these authentication methods are currently superseded by the "Digital 288 Signature" (14) authentication method, which has a different 289 announcement format, described below. 291 3.2.3. Multi-octet Announcement 293 The following format is currently used only with the "Digital 294 Signature" (14) authentication method. 296 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Length (>3) | Auth Method | Cert Link | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 301 | | 302 ~ AlgorithmIdentifier ASN.1 object ~ 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Figure 7: Supported Authentication Method 308 o Length - Length of the blob, must be greater than 3 for this case. 310 o Auth Method - Announced authentication method, currently may only 311 be 14 ("Digital Signature"). 313 o Cert Link - Link this announcement to a particular CA; see 314 Section 3.2.2 for details. 316 o AlgorithmIdentifier ASN.1 object - DER-encoded ASN.1 object 317 AlgorithmIdentifier. 319 The "Digital Signature" authentication method, defined in [RFC7427], 320 supersedes previously defined signature authentication methods. In 321 this case the real authentication algorithm is identified via 322 AlgorithmIdentifier ASN.1 object. Appendix A in [RFC7427] contains 323 examples of Commonly Used ASN.1 Objects. 325 4. Security Considerations 327 Security considerations for IKEv2 protocol are discussed in 328 [RFC7296]. It is assumed that this extension of the IKEv2 doesn't 329 add new vulnerabilities to the protocol. 331 5. IANA Considerations 333 This document defines a new Notify Message Types in the "Notify 334 Message Types - Status Types" registry: 336 SUPPORTED_AUTH_METHODS 338 6. References 340 6.1. Normative References 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, 344 DOI 10.17487/RFC2119, March 1997, 345 . 347 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 348 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 349 May 2017, . 351 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 352 Kivinen, "Internet Key Exchange Protocol Version 2 353 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 354 2014, . 356 [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in 357 the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, 358 DOI 10.17487/RFC7427, January 2015, 359 . 361 [I-D.ietf-ipsecme-ikev2-intermediate] 362 Smyslov, V., "Intermediate Exchange in the IKEv2 363 Protocol", draft-ietf-ipsecme-ikev2-intermediate-05 (work 364 in progress), September 2020. 366 [IKEV2-IANA] 367 IANA, "Internet Key Exchange Version 2 (IKEv2) 368 Parameters", . 371 6.2. Informative References 373 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 374 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 375 . 377 [RFC6467] Kivinen, T., "Secure Password Framework for Internet Key 378 Exchange Version 2 (IKEv2)", RFC 6467, 379 DOI 10.17487/RFC6467, December 2011, 380 . 382 [I-D.ounsworth-pq-composite-sigs] 383 Ounsworth, M. and M. Pala, "Composite Keys and Signatures 384 For Use In Internet PKI", draft-ounsworth-pq-composite- 385 sigs-03 (work in progress), July 2020. 387 Author's Address 389 Valery Smyslov 390 ELVIS-PLUS 391 PO Box 81 392 Moscow (Zelenograd) 124460 393 RU 395 Phone: +7 495 276 0211 396 Email: svan@elvis.ru