idnits 2.17.00 (12 Aug 2021) /tmp/idnits31198/draft-guthrie-ipsecme-ikev2-hybrid-auth-00.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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (25 March 2022) is 50 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) == Missing Reference: 'AUTH' is mentioned on line 137, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2IANA' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Guthrie 3 Internet-Draft NSA 4 Intended status: Standards Track 25 March 2022 5 Expires: 26 September 2022 7 Hybrid Non-Composite Authentication in IKEv2 8 draft-guthrie-ipsecme-ikev2-hybrid-auth-00 10 Abstract 12 This document describes how to extend the Internet Key Exchange 13 Protocol Version 2 (IKEv2) to allow hybrid non-composite 14 authentication. The intended purpose for this extension is to enable 15 the use of a Post-Quantum (PQ) digital signature and X.509 16 certificate in addition to the use of a traditional authentication 17 method. This document enables peers to signify support for hybrid 18 non-composite authentication, and send additional CERTREQ, AUTH, and 19 CERT payloads to perform multiple authentications. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 26 September 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 56 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1.1. Exchanges using IKE_INTERMEDIATE . . . . . . . . . . 4 59 3.2. SUPPORTED_AUTH_METHODS Notify Payload . . . . . . . . . . 6 60 3.3. HYBRID_AUTH Notify Payload . . . . . . . . . . . . . . . 7 61 3.4. CERTREQ Payload . . . . . . . . . . . . . . . . . . . . . 9 62 3.5. Additional AUTH Payload . . . . . . . . . . . . . . . . . 9 63 3.6. Additional CERT Payload . . . . . . . . . . . . . . . . . 9 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 6.2. Informative References . . . . . . . . . . . . . . . . . 12 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 71 1. Introduction 73 This document describes how to extend the Internet Key Exchange 74 Protocol Version 2 (IKEv2) to allow negotiation of authentication 75 methods, including hybrid authentication. The intended purpose for 76 this extension is to enable the use of a Post-Quantum (PQ) digital 77 signature and X.509 certificate in addition to the use of a 78 traditional authentication method. This document is motivated by 79 [I-D.draft-becker-guthrie-noncomposite-hybrid-auth] and the multiple 80 authentication mechanism for IKEv2 introduced in [RFC4739], and 81 specifies how to perform multiple authentications, with each 82 authentication using its own CERT AND AUTH payloads. This document 83 also leverages the supported authentication method announcement 84 specified in [I-D.draft-ietf-ipsecme-ikev2-auth-announce]. 86 2. Terminology and Notation 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119] [RFC8174] 91 when, and only when, they appear in capitals, as shown here. 93 3. Protocol Details 95 3.1. Exchanges 97 If the responder is willing to use this extension, it includes a new 98 HYBRID_AUTH Notify payload in the response message of the IKE_SA_INIT 99 exchange. The inclusion of N(HYBRID_AUTH) in the responder's 100 IKE_SA_INIT message indicates to the initiator that the responder can 101 perform multiple authentications using multiple AUTH and CERT 102 payloads. Additionally, the responder includes in IKE_SA_INIT a 103 SUPPORTED_AUTH_METHODS Notify payload as defined in 104 [I-D.draft-ietf-ipsecme-ikev2-auth-announce]. If a peer sends 105 N(HYBRID_AUTH), it MUST also send N(SUPPORTED_AUTH_METHODS). If the 106 initiator does not support this extension and the extension indicated 107 through inclusion of N(SUPPORTED_AUTH_METHODS), it MUST ignore the 108 received N(HYBRID_AUTH) notification. If the initiator supports this 109 extension, it MAY include N(HYBRID_AUTH) and 110 N(SUPPORTED_AUTH_METHODS) in its IKE_AUTH message, indicating to the 111 responder that it can perform multiple authentications using multiple 112 AUTH and CERT payloads. Additionally, the initiator MAY send in the 113 IKE_AUTH message additional AUTH and CERT payloads based on 114 information conveyed in the responder's SUPPORTED_AUTH_METHODS Notify 115 payload, in order for the responder to perform multiple 116 authentications. If the initiator includes N(HYBRID_AUTH) and 117 N(SUPPORTED_AUTH_METHODS) in its IKE_AUTH message, the responder MAY 118 also send additional AUTH and CERT payloads based on these, in order 119 for the initiator to perform multiple authentications. Note that 120 Figure 1 illustrates the scenario where both initiator and responder 121 support N(HYBRID_AUTH) and both choose to do a single additional 122 authentication. Section 3.5 illustrates what the responder IKE_AUTH 123 message looks like in the case that more than two AUTH payloads and 124 corresponding CERT payloads are sent. 126 Initiator Responder 127 ----------- ----------- 128 HDR, SAi1, KEi, Ni --> 130 <-- HDR, SAr1, KEr, Nr, 131 [CERTREQ,],[N(HYBRID_AUTH),] 132 [N(SUPPORTED_AUTH_METHODS)] 133 HDR, SK {IDi, [CERT,] 134 [CERTREQ,] [IDr,] AUTH, 135 SAi2, TSi, TSr, [N(HYBRID_AUTH),] 136 N(SUPPORTED_AUTH_METHODS),] 137 [CERT,] [AUTH] --> 138 <-- HDR, SK {IDr, [CERT,] AUTH, 139 SAr2, TSi, TSr, [CERT,] [AUTH]} 141 Figure 1: IKE_SA_INIT and IKE_AUTH Exchanges 143 Figure 1 145 If the responder sends N(HYBRID_AUTH) in IKE_SA_INIT or the initiator 146 sends N(HYBRID_AUTH) in IKE_AUTH but N(SUPPORTED_AUTH_METHODS) is 147 missing from the message, the responding peer SHOULD ignore the 148 N(HYBRID_AUTH) Notify Payload and proceed as if the other peer does 149 not support this extension. 151 3.1.1. Exchanges using IKE_INTERMEDIATE 153 When PQ cryptography is incorporated into IKEv2, either during the 154 key establishment phase or for authentication, it is suspected that 155 the increased size of PQ KEMs and digital signatures will cause IP 156 fragmentation. Though [RFC7383] mitigates this issue for the 157 IKE_AUTH exchange through deploying fragmentation at the IKEv2 layer 158 instead, its fragmentation mechanism functions only on encrypted 159 payloads, and therefore does not extend to the IKE_SA_INIT exchange. 161 [I-D.draft-ietf-ipsecme-ikev2-intermediate] introduces an 162 IKE_INTERMEDIATE exchange that follows IKE_SA_INIT and precedes 163 IKE_AUTH. IKE_INTERMEDIATE leverages the key establishment of the 164 IKE_SA_INIT exchange and can be used to send larger data that would 165 not fit in an IKE_SA_INIT message without causing IP fragmentation. 167 In the case that N(SUPPORTED_AUTH_METHODS) is large enough to cause 168 fragmentation of the responder's IKE_SA_INIT message, or in the case 169 that the peers are using IKE_INTERMEDIATE for some other purpose, the 170 responder will send the data from N(SUPPORTED_AUTH_METHODS) in 171 IKE_INTERMEDIATE instead of IKE_SA_INIT, as described in 172 [I-D.draft-ietf-ipsecme-ikev2-auth-announce]. In this case, the 173 responder sends an empty N(SUPPORTED_AUTH_METHODS) payload in 174 IKE_SA_INIT, which signals to the initiator to begin the 175 IKE_INTERMEDIATE. In the responder's IKE_INTERMEDIATE response, it 176 will again send N(SUPPORTED_AUTH_METHODS), but with a non-empty 177 Notification Data field, where it lists supported authentication 178 methods announcements. 180 When IKE_INTERMEDIATE is used, the responder MUST use it to send 181 N(HYBRID_AUTH) in the same manner as N(SUPPORTED_AUTH_METHODS). That 182 is, the responder will send an empty HYBRID_AUTH Notify Payload in 183 IKE_SA_INIT, and then send a non-empty N(HYBRID_AUTH) in its 184 IKE_INTERMEDIATE response message. 186 Figure 2 shows the IKE_SA_INIT, IKE_INTERMEDIATE, and IKE_AUTH 187 exchanges when N(HYBRID_AUTH) and N(SUPPORTED_AUTH_METHODS) are sent 188 using IKE_INTERMEDIATE. Note that both Notify Payloads in the 189 responder's IKE_SA_INIT message are empty, and both Notify Payload's 190 in the responder's IKE_INTERMEDIATE message contain data. 192 Initiator Responder 193 ----------- ----------- 194 HDR, SAi1, KEi, Ni --> 195 <-- HDR, SAr1, KEr, Nr, 196 [CERTREQ,] 197 [N(HYBRID_AUTH),] 198 [N(SUPPORTED_AUTH_METHODS)] 199 HDR, SK {…} --> 200 <-- HDR, SK{… 201 [N(HYBRID_AUTH),] 202 [N(SUPPORTED_AUTH_METHODS)} 203 HDR, SK {IDi, [CERT,] 204 [CERTREQ,] [IDr,] AUTH, 205 SAi2, TSi, TSr,[N(HYBRID_AUTH),] 206 [N(SUPPORTED_AUTH_METHODS),] 207 [CERT,] [AUTH]} --> 208 <-- HDR, SK {IDr, [CERT,] AUTH, 209 SAr2, TSi, TSr, [CERT,] [AUTH]} 211 Figure 2: IKE_SA_INIT, IKE_INTERMEDIATE, and IKE_AUTH Exchanges 213 Figure 2 215 Furthermore, the use of IKE_INTERMEDIATE alters IKEv2's 216 authentication mechanism, as specified in 217 [I-D.draft-ietf-ipsecme-ikev2-intermediate]. If the IKE_INTERMEDIATE 218 exchange is used, care must be taken to apply this modified 219 authentication mechanism to all authentications that are performed 220 with this extension. 222 3.2. SUPPORTED_AUTH_METHODS Notify Payload 224 The SUPPORTED_AUTH_METHODS Notify payload as defined in 225 [I-D.draft-ietf-ipsecme-ikev2-auth-announce] is a status notification 226 payload with type TBA; it has a protocol ID of 0 and no Security 227 Parameter Index (SPI). The Notification Data field is defined in 228 [I-D.draft-ietf-ipsecme-ikev2-auth-announce], and is called List of 229 Supported Auth Methods Announcements. It contains the list of 230 supported authentication methods, where each item in the list is 231 called an announcement. Each announcement is a variable-sized blob, 232 whose format depends on the announced authentication method. 233 Authentication methods are represented as values from the "IKEv2 234 Authentication Method" registry defined in [IKEV2IANA]. 235 [I-D.draft-ietf-ipsecme-ikev2-auth-announce] defines three formats 236 for announcements, each of different lengths. The shortest (2 237 octets) is used for authentication methods "Shared Key Message 238 Integrity Code" (2) and "NULL Authentication" (13). The second (3 239 octets) is used for "RSA Digital Signature" (1), "DSS Digital 240 Signature" (3), "ECDSA with SHA-256 on the P-256 curve" (9), "ECDSA 241 with SHA-384 on the P-384 curve" (10) and "ECDSA with SHA-512 on the 242 P-521 curve (11). The last (multi-octet) is used with the "Digital 243 Signature" (14) authentication method defined in [RFC7427]. 245 If a peer sends N(HYBRID_AUTH), it MUST also send 246 N(SUPPORTED_AUTH_METHODS). The peer includes announcements for all 247 supported authentication methods in N(SUPPORTED_AUTH_METHODS), and 248 the data in N(HYBRID_AUTH) provides the context necessary for the 249 receiving peer to parse the authentication methods presented in 250 N(SUPPORTED_AUTH_METHODS) in the context of performing multiple 251 authentications. 253 N(SUPPORTED_AUTH_METHODS) contains a list of authentication methods 254 the sender supports. For each authentication the sender would like 255 performed, the options for that authentication should be listed 256 consecutively. The options for that authentication should also be 257 listed in order of most preferred to least preferred. The sets of 258 options should themselves appear in order of most preferred 259 authentication to least preferred authentication (i.e., options for 260 the authentication that would be most preferable if only one 261 authentication would occur should be listed first, and so on). 263 For example, if a peer would like two authentications to be 264 performed, where options for the first authentication are "ECDSA with 265 SHA-384 on the P-384 curve (10)" or "ECDSA with SHA-512 on the P-521 266 curve (11) (where ECDSA with SHA-512 on the P-521 curve is most 267 preferred) and options for the second authentication are three 268 choices of PQ digital signature: PQ_a, PQ_b, PQ_c (where PQ_b is most 269 preferred, followed by PQ_c, then PQ_a), and with a preference for PQ 270 authentication over traditional authentication in the case that the 271 receiving peer only performs a single authentication, the 272 announcements for these methods should appear in the following order: 273 PQ_b, PQ_c, PQ_a, ECDSA with SHA-512 on the P-521 curve, ECDSA with 274 SHA-384 on the P-384 curve. 276 Author's Note: What authentication method will be used for PQ 277 signatures? Will a new IANA value be defined, or will PQ signatures 278 use the Digital Signature (14) Authentication Method value? If it is 279 the former, announcements for PQ authentication may fit into the 3 280 octet announcement template (along with the other certificate-based 281 authentication methods). 283 3.3. HYBRID_AUTH Notify Payload 285 The HYBRID_AUTH Notify payload is a status notification payload with 286 the type TBA. It has a protocol ID of 0 and no Security Parameter 287 Index (SPI). Data consists of two fields. The first is one octet 288 and is used to indicate how many authentications a peer would prefer 289 the other peer select from the supported authentication methods it 290 lists in the N(SUPPORTED_AUTH_METHODS) payload. The second field 291 tells a peer how to select authentication methods from the list of 292 announcements made in N(SUPPORTED_AUTH_METHODS). 294 The value of the # of Auths field MUST be at least two. If the value 295 of this field is 0 of 1, this Notify Payload SHOULD be ignored and 296 the receiving peer should proceed as if the sending peer does not 297 support this extension. In the case that the receiving peer decides 298 not to ignore this Notify Payload, it MUST check the Indices field 299 and determine whether the Indices field is a reasonable length (i.e., 300 contains between one and seven indices). If the Indices field is a 301 reasonable length, the receiving peer MAY ignore only the # of Auths 302 field and proceed based on the values in the Indices field. 303 Otherwise, the receiving peer MUST ignore the Notify Payload. 305 The value(s) in the subsequent Indices field tells the peer which 306 authentication methods it may select from N(SUPPORTED_AUTH_METHODS) 307 if it agrees to using this extension. It works as follows: for each 308 authentication the sending peer would like to have performed, the 309 Indices field lists the index of the top choice for each 310 authentication, with the exception of the top choice for the first 311 authentication (which will always coincide with the first 312 announcement). Then, for each authentication that the receiving peer 313 agrees to, it can appropriately select an authentication method from 314 each sub-list. If a peer receives the list enumerated in the 315 previous section, the # of Auths field in the corresponding 316 HYBRID_AUTH Notify Payload will be two, and the Indices field will be 317 3. Then, if this peer agrees to perform two authentications and 318 supports at least one authentication method presented for each 319 authentication, it will select one authentication method from the 320 first sub-list, which is announcements 0, 1, and 2, and one 321 authentication method from the second sub-list, which is 322 announcements 3 and 4. If the receiving peer does not support at 323 least one authentication method from each sub-list or does not wish 324 to perform the number of authentications preferred by the sending 325 peer, it MAY select an authentication method from a subset of these 326 sub-lists, rather than an authentication method from each. If the 327 receiving peer wishes to perform only one authentication, it can 328 perform, for example, only the PQ_b authentication, rather than the 329 PQ_a/b/c authentication in conjunction with either ECDSA with SHA-512 330 on the P-521 curve or ECDSA with SHA-384 on the P-384 curve. If the 331 receiving peer does not support at least one authentication method 332 from each sub-list or does not wish to perform as many 333 authentications as preferred by the sending peer, it SHOULD attempt 334 to choose an authentication method that is preferred by the sending 335 peer. 337 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Next Payload |C| RESERVED | Payload Length | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type (=16404) | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | # of Auths | | 345 +-+-+-+-+-+-+-+-+ | 346 ~ Indices ~ 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Figure 3: HYBRID_AUTH Notify Payload Format 352 Figure 3 354 3.4. CERTREQ Payload 356 The CERTREQ payload contains the IKE header, the certificate encoding 357 being requested, and the encoding of an acceptable certification 358 authority (CA) for the type of certificate requested [RFC7296]. The 359 CA field is a concatenated list of hashes of the public keys of 360 trusted CAs, where each is encoded as the SHA-1 hash of the Subject 361 Public Key Info element from each Trust Anchor certificate. Subject 362 Public Key Info contains signatureAlgorithm which identifies the 363 cryptographic algorithm used by the CA to sign the certificate. 364 Multiple CERTREQ payloads MAY be sent in order to accommodate 365 multiple values for certificate encodings, but a single CERTREQ 366 payload can contain requests corresponding to certificates used with 367 both traditional and PQ authentication, provided that they use the 368 same certificate encoding. 370 3.5. Additional AUTH Payload 372 The AUTH payload, as specified in [RFC7296], contains an IKE header, 373 the authentication method, reserved bits, and authentication data. 374 Additional AUTH payloads MUST use the same AUTH payload format as is 375 defined in [RFC7296]. AUTH payloads MAY use the same authentication 376 method. AUTH payloads sent by a peer SHOULD use authentication 377 methods announced by the other peer in N(SUPPORTED_AUTH_METHODS). 378 For each AUTH payload a peer sends that is using an authentication 379 method that requires a CERT payload, there MUST be at least one CERT 380 payload accompanying that AUTH payload. There may be more than one 381 CERT payload per AUTH payload if certificate chains are sent. 383 When additional AUTH and CERT payloads are sent in support of 384 multiple authentications, all additional AUTH and CERT payloads MUST 385 be sent at the end of the IKE_AUTH message. Each additional AUTH 386 payload MUST be directly preceded by the CERT payloads that are used 387 during that authentication. 389 When a peer receives multiple sets of AUTH and CERT payloads, they 390 SHOULD perform all authentications. It is left to the individual 391 implementation to decide whether or not to proceed if some but not 392 all authentications are performed, or some but not all 393 authentications succeed. If no authentications succeed, the 394 connection MUST be dropped. 396 3.6. Additional CERT Payload 398 The CERT payload contains the IKE header, the certificate encoding, 399 and the certificate data [RFC7296]. 401 Though this document refers to a single traditional CERT payload and 402 a single PQ CERT payload, it is often the case that multiple CERT 403 payloads are sent in response to a single CERTREQ in order to provide 404 a certificate chain. 406 [RFC7296] states that if more than one CERT payload is used for 407 authentication, the first CERT payload MUST contain the public key 408 used to verify the AUTH payload. The remaining CERT payloads need 409 not be in any particular order. 411 If additional AUTH and CERT payloads are sent in support of multiple 412 authentications, all additional AUTH and CERT payloads MUST be sent 413 at the end of the IKE_AUTH message. Each set of CERT payloads used 414 in a single authentication MUST be listed consecutively, beginning 415 with the end entity certificate, and be immediately followed by the 416 relevant AUTH payload. If more than two sets of AUTH and CERT 417 payloads are sent, each additional AUTH payload acts as a delimiter 418 which groups together CERT payloads containing certificates that 419 belong to the same certificate chain. 421 For example, if the responder sent three sets of AUTH and CERT 422 payloads, the responder's IKE_AUTH message appear as shown in 423 Figure 4. 425 Initiator Responder 426 ----------- ----------- 427 <-- HDR, SK {IDr, [CERT,] AUTH, 428 SAr2, TSi, TSr, [CERT,] [AUTH,] 429 [CERT,] [AUTH]} 431 Figure 4: Responder's IKE_AUTH message with three authentications 433 Figure 4 435 In the case that more than one authentication uses X.509 436 certificates, the peer in receipt of these certificates MUST confirm 437 that the SANs match in all end entity certificates. 439 For guidance on performing validation of multiple certificate chains, 440 refer to [I-D.draft-becker-guthrie-noncomposite-hybrid-auth]. 442 4. Security Considerations 444 It is likely that the Post-Quantum AUTH and CERT payloads will cause 445 the IKE_AUTH message to exceed the supported message size, requiring 446 use of [RFC7383]. Thus, this document inherits the security concerns 447 of both [RFC7296] and [RFC7383]. This document also incorporates 448 [I-D.draft-ietf-ipsecme-ikev2-intermediate] and 449 [I-D.draft-ietf-ipsecme-ikev2-auth-announce], so it inherits these 450 security considerations as well. 452 All hybrid implementations are vulnerable to a downgrade attack in 453 which a malicious peer does not express support for PQ algorithms, 454 resulting in an exchange that can only rely upon traditional 455 algorithms for security. Other concerns may arise through the use of 456 multiple certificate chains and digital signatures, as considered in 457 [I-D.draft-becker-guthrie-noncomposite-hybrid-auth]. 459 Last, it is worth noting that a DoS attack could be conducted through 460 this document's use of the N(SUPPORTED_AUTH_METHODS) sent in the 461 IKE_SA_INIT exchange, where a malicious responder could send a long 462 list of authentication announcements. 464 5. IANA Considerations 466 This document defines a new Notify Message Type in the "IKEv2 Notify 467 Message Types - Status Types" registry [IKEV2IANA]: 469 HYBRID_AUTH 471 6. References 473 6.1. Normative References 475 [I-D.draft-ietf-ipsecme-ikev2-auth-announce] 476 Smyslov, V., "Announcing Supported Authentication Methods 477 in IKEv2", draft-ietf-ipsecme-ikev2-auth-announce-00 (work 478 in progress), February 2022, 479 . 482 [I-D.draft-ietf-ipsecme-ikev2-intermediate] 483 Smyslov, V., "Intermediate Exchange in the IKEv2 484 Protocol", draft-ietf-ipsecme-ikev2-intermediate-10 (work 485 in progress), March 2022, 486 . 489 [IKEV2IANA] 490 IANA, "Internet Key Exchange Version 2 (IKEv2) 491 Parameters", 492 . 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, 496 DOI 10.17487/RFC2119, March 1997, 497 . 499 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 500 Kivinen, "Internet Key Exchange Protocol Version 2 501 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 502 2014, . 504 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 505 (IKEv2) Message Fragmentation", RFC 7383, 506 DOI 10.17487/RFC7383, November 2014, 507 . 509 [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in 510 the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, 511 DOI 10.17487/RFC7427, January 2015, 512 . 514 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 515 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 516 May 2017, . 518 6.2. Informative References 520 [I-D.draft-becker-guthrie-noncomposite-hybrid-auth] 521 Becker, A., Guthrie, R., and M. Jenkins, "Non-Composite 522 Hybrid Authentication in PKIX and Applications to Internet 523 Protocols", draft-becker-guthrie-noncomposite-hybrid- 524 auth-00 (work in progress), March 2022, 525 . 529 [RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication 530 Exchanges in the Internet Key Exchange (IKEv2) Protocol", 531 RFC 4739, DOI 10.17487/RFC4739, November 2006, 532 . 534 Author's Address 535 Rebecca Guthrie 536 National Security Agency 537 Email: rmguthr@uwe.nsa.gov