Internet DRAFT - draft-guthrie-ipsecme-ikev2-hybrid-auth
draft-guthrie-ipsecme-ikev2-hybrid-auth
Network Working Group R. Guthrie
Internet-Draft NSA
Intended status: Standards Track 25 March 2022
Expires: 26 September 2022
Hybrid Non-Composite Authentication in IKEv2
draft-guthrie-ipsecme-ikev2-hybrid-auth-00
Abstract
This document describes how to extend the Internet Key Exchange
Protocol Version 2 (IKEv2) to allow hybrid non-composite
authentication. The intended purpose for this extension is to enable
the use of a Post-Quantum (PQ) digital signature and X.509
certificate in addition to the use of a traditional authentication
method. This document enables peers to signify support for hybrid
non-composite authentication, and send additional CERTREQ, AUTH, and
CERT payloads to perform multiple authentications.
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 26 September 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Guthrie Expires 26 September 2022 [Page 1]
Internet-Draft Hybrid Non-Composite Auth in IKEv2 March 2022
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. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Exchanges using IKE_INTERMEDIATE . . . . . . . . . . 4
3.2. SUPPORTED_AUTH_METHODS Notify Payload . . . . . . . . . . 6
3.3. HYBRID_AUTH Notify Payload . . . . . . . . . . . . . . . 7
3.4. CERTREQ Payload . . . . . . . . . . . . . . . . . . . . . 9
3.5. Additional AUTH Payload . . . . . . . . . . . . . . . . . 9
3.6. Additional CERT Payload . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
This document describes how to extend the Internet Key Exchange
Protocol Version 2 (IKEv2) to allow negotiation of authentication
methods, including hybrid authentication. The intended purpose for
this extension is to enable the use of a Post-Quantum (PQ) digital
signature and X.509 certificate in addition to the use of a
traditional authentication method. This document is motivated by
[I-D.draft-becker-guthrie-noncomposite-hybrid-auth] and the multiple
authentication mechanism for IKEv2 introduced in [RFC4739], and
specifies how to perform multiple authentications, with each
authentication using its own CERT AND AUTH payloads. This document
also leverages the supported authentication method announcement
specified in [I-D.draft-ietf-ipsecme-ikev2-auth-announce].
Guthrie Expires 26 September 2022 [Page 2]
Internet-Draft Hybrid Non-Composite Auth in IKEv2 March 2022
2. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] [RFC8174]
when, and only when, they appear in capitals, as shown here.
3. Protocol Details
3.1. Exchanges
If the responder is willing to use this extension, it includes a new
HYBRID_AUTH Notify payload in the response message of the IKE_SA_INIT
exchange. The inclusion of N(HYBRID_AUTH) in the responder's
IKE_SA_INIT message indicates to the initiator that the responder can
perform multiple authentications using multiple AUTH and CERT
payloads. Additionally, the responder includes in IKE_SA_INIT a
SUPPORTED_AUTH_METHODS Notify payload as defined in
[I-D.draft-ietf-ipsecme-ikev2-auth-announce]. If a peer sends
N(HYBRID_AUTH), it MUST also send N(SUPPORTED_AUTH_METHODS). If the
initiator does not support this extension and the extension indicated
through inclusion of N(SUPPORTED_AUTH_METHODS), it MUST ignore the
received N(HYBRID_AUTH) notification. If the initiator supports this
extension, it MAY include N(HYBRID_AUTH) and
N(SUPPORTED_AUTH_METHODS) in its IKE_AUTH message, indicating to the
responder that it can perform multiple authentications using multiple
AUTH and CERT payloads. Additionally, the initiator MAY send in the
IKE_AUTH message additional AUTH and CERT payloads based on
information conveyed in the responder's SUPPORTED_AUTH_METHODS Notify
payload, in order for the responder to perform multiple
authentications. If the initiator includes N(HYBRID_AUTH) and
N(SUPPORTED_AUTH_METHODS) in its IKE_AUTH message, the responder MAY
also send additional AUTH and CERT payloads based on these, in order
for the initiator to perform multiple authentications. Note that
Figure 1 illustrates the scenario where both initiator and responder
support N(HYBRID_AUTH) and both choose to do a single additional
authentication. Section 3.5 illustrates what the responder IKE_AUTH
message looks like in the case that more than two AUTH payloads and
corresponding CERT payloads are sent.
Guthrie Expires 26 September 2022 [Page 3]
Internet-Draft Hybrid Non-Composite Auth in IKEv2 March 2022
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr,
[CERTREQ,],[N(HYBRID_AUTH),]
[N(SUPPORTED_AUTH_METHODS)]
HDR, SK {IDi, [CERT,]
[CERTREQ,] [IDr,] AUTH,
SAi2, TSi, TSr, [N(HYBRID_AUTH),]
N(SUPPORTED_AUTH_METHODS),]
[CERT,] [AUTH] -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr, [CERT,] [AUTH]}
Figure 1: IKE_SA_INIT and IKE_AUTH Exchanges
Figure 1
If the responder sends N(HYBRID_AUTH) in IKE_SA_INIT or the initiator
sends N(HYBRID_AUTH) in IKE_AUTH but N(SUPPORTED_AUTH_METHODS) is
missing from the message, the responding peer SHOULD ignore the
N(HYBRID_AUTH) Notify Payload and proceed as if the other peer does
not support this extension.
3.1.1. Exchanges using IKE_INTERMEDIATE
When PQ cryptography is incorporated into IKEv2, either during the
key establishment phase or for authentication, it is suspected that
the increased size of PQ KEMs and digital signatures will cause IP
fragmentation. Though [RFC7383] mitigates this issue for the
IKE_AUTH exchange through deploying fragmentation at the IKEv2 layer
instead, its fragmentation mechanism functions only on encrypted
payloads, and therefore does not extend to the IKE_SA_INIT exchange.
[I-D.draft-ietf-ipsecme-ikev2-intermediate] introduces an
IKE_INTERMEDIATE exchange that follows IKE_SA_INIT and precedes
IKE_AUTH. IKE_INTERMEDIATE leverages the key establishment of the
IKE_SA_INIT exchange and can be used to send larger data that would
not fit in an IKE_SA_INIT message without causing IP fragmentation.
In the case that N(SUPPORTED_AUTH_METHODS) is large enough to cause
fragmentation of the responder's IKE_SA_INIT message, or in the case
that the peers are using IKE_INTERMEDIATE for some other purpose, the
responder will send the data from N(SUPPORTED_AUTH_METHODS) in
IKE_INTERMEDIATE instead of IKE_SA_INIT, as described in
[I-D.draft-ietf-ipsecme-ikev2-auth-announce]. In this case, the
Guthrie Expires 26 September 2022 [Page 4]
Internet-Draft Hybrid Non-Composite Auth in IKEv2 March 2022
responder sends an empty N(SUPPORTED_AUTH_METHODS) payload in
IKE_SA_INIT, which signals to the initiator to begin the
IKE_INTERMEDIATE. In the responder's IKE_INTERMEDIATE response, it
will again send N(SUPPORTED_AUTH_METHODS), but with a non-empty
Notification Data field, where it lists supported authentication
methods announcements.
When IKE_INTERMEDIATE is used, the responder MUST use it to send
N(HYBRID_AUTH) in the same manner as N(SUPPORTED_AUTH_METHODS). That
is, the responder will send an empty HYBRID_AUTH Notify Payload in
IKE_SA_INIT, and then send a non-empty N(HYBRID_AUTH) in its
IKE_INTERMEDIATE response message.
Figure 2 shows the IKE_SA_INIT, IKE_INTERMEDIATE, and IKE_AUTH
exchanges when N(HYBRID_AUTH) and N(SUPPORTED_AUTH_METHODS) are sent
using IKE_INTERMEDIATE. Note that both Notify Payloads in the
responder's IKE_SA_INIT message are empty, and both Notify Payload's
in the responder's IKE_INTERMEDIATE message contain data.
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr,
[CERTREQ,]
[N(HYBRID_AUTH),]
[N(SUPPORTED_AUTH_METHODS)]
HDR, SK {…} -->
<-- HDR, SK{…
[N(HYBRID_AUTH),]
[N(SUPPORTED_AUTH_METHODS)}
HDR, SK {IDi, [CERT,]
[CERTREQ,] [IDr,] AUTH,
SAi2, TSi, TSr,[N(HYBRID_AUTH),]
[N(SUPPORTED_AUTH_METHODS),]
[CERT,] [AUTH]} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr, [CERT,] [AUTH]}
Figure 2: IKE_SA_INIT, IKE_INTERMEDIATE, and IKE_AUTH Exchanges
Figure 2
Guthrie Expires 26 September 2022 [Page 5]
Internet-Draft Hybrid Non-Composite Auth in IKEv2 March 2022
Furthermore, the use of IKE_INTERMEDIATE alters IKEv2's
authentication mechanism, as specified in
[I-D.draft-ietf-ipsecme-ikev2-intermediate]. If the IKE_INTERMEDIATE
exchange is used, care must be taken to apply this modified
authentication mechanism to all authentications that are performed
with this extension.
3.2. SUPPORTED_AUTH_METHODS Notify Payload
The SUPPORTED_AUTH_METHODS Notify payload as defined in
[I-D.draft-ietf-ipsecme-ikev2-auth-announce] is a status notification
payload with type TBA; it has a protocol ID of 0 and no Security
Parameter Index (SPI). The Notification Data field is defined in
[I-D.draft-ietf-ipsecme-ikev2-auth-announce], and is called List of
Supported Auth Methods Announcements. It contains the list of
supported authentication methods, where each item in the list is
called an announcement. Each announcement is a variable-sized blob,
whose format depends on the announced authentication method.
Authentication methods are represented as values from the "IKEv2
Authentication Method" registry defined in [IKEV2IANA].
[I-D.draft-ietf-ipsecme-ikev2-auth-announce] defines three formats
for announcements, each of different lengths. The shortest (2
octets) is used for authentication methods "Shared Key Message
Integrity Code" (2) and "NULL Authentication" (13). The second (3
octets) is used for "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-521 curve (11). The last (multi-octet) is used with the "Digital
Signature" (14) authentication method defined in [RFC7427].
If a peer sends N(HYBRID_AUTH), it MUST also send
N(SUPPORTED_AUTH_METHODS). The peer includes announcements for all
supported authentication methods in N(SUPPORTED_AUTH_METHODS), and
the data in N(HYBRID_AUTH) provides the context necessary for the
receiving peer to parse the authentication methods presented in
N(SUPPORTED_AUTH_METHODS) in the context of performing multiple
authentications.
N(SUPPORTED_AUTH_METHODS) contains a list of authentication methods
the sender supports. For each authentication the sender would like
performed, the options for that authentication should be listed
consecutively. The options for that authentication should also be
listed in order of most preferred to least preferred. The sets of
options should themselves appear in order of most preferred
authentication to least preferred authentication (i.e., options for
the authentication that would be most preferable if only one
authentication would occur should be listed first, and so on).
Guthrie Expires 26 September 2022 [Page 6]
Internet-Draft Hybrid Non-Composite Auth in IKEv2 March 2022
For example, if a peer would like two authentications to be
performed, where options for the first authentication are "ECDSA with
SHA-384 on the P-384 curve (10)" or "ECDSA with SHA-512 on the P-521
curve (11) (where ECDSA with SHA-512 on the P-521 curve is most
preferred) and options for the second authentication are three
choices of PQ digital signature: PQ_a, PQ_b, PQ_c (where PQ_b is most
preferred, followed by PQ_c, then PQ_a), and with a preference for PQ
authentication over traditional authentication in the case that the
receiving peer only performs a single authentication, the
announcements for these methods should appear in the following order:
PQ_b, PQ_c, PQ_a, ECDSA with SHA-512 on the P-521 curve, ECDSA with
SHA-384 on the P-384 curve.
Author's Note: What authentication method will be used for PQ
signatures? Will a new IANA value be defined, or will PQ signatures
use the Digital Signature (14) Authentication Method value? If it is
the former, announcements for PQ authentication may fit into the 3
octet announcement template (along with the other certificate-based
authentication methods).
3.3. HYBRID_AUTH Notify Payload
The HYBRID_AUTH Notify payload is a status notification payload with
the type TBA. It has a protocol ID of 0 and no Security Parameter
Index (SPI). Data consists of two fields. The first is one octet
and is used to indicate how many authentications a peer would prefer
the other peer select from the supported authentication methods it
lists in the N(SUPPORTED_AUTH_METHODS) payload. The second field
tells a peer how to select authentication methods from the list of
announcements made in N(SUPPORTED_AUTH_METHODS).
The value of the # of Auths field MUST be at least two. If the value
of this field is 0 of 1, this Notify Payload SHOULD be ignored and
the receiving peer should proceed as if the sending peer does not
support this extension. In the case that the receiving peer decides
not to ignore this Notify Payload, it MUST check the Indices field
and determine whether the Indices field is a reasonable length (i.e.,
contains between one and seven indices). If the Indices field is a
reasonable length, the receiving peer MAY ignore only the # of Auths
field and proceed based on the values in the Indices field.
Otherwise, the receiving peer MUST ignore the Notify Payload.
The value(s) in the subsequent Indices field tells the peer which
authentication methods it may select from N(SUPPORTED_AUTH_METHODS)
if it agrees to using this extension. It works as follows: for each
authentication the sending peer would like to have performed, the
Indices field lists the index of the top choice for each
authentication, with the exception of the top choice for the first
Guthrie Expires 26 September 2022 [Page 7]
Internet-Draft Hybrid Non-Composite Auth in IKEv2 March 2022
authentication (which will always coincide with the first
announcement). Then, for each authentication that the receiving peer
agrees to, it can appropriately select an authentication method from
each sub-list. If a peer receives the list enumerated in the
previous section, the # of Auths field in the corresponding
HYBRID_AUTH Notify Payload will be two, and the Indices field will be
3. Then, if this peer agrees to perform two authentications and
supports at least one authentication method presented for each
authentication, it will select one authentication method from the
first sub-list, which is announcements 0, 1, and 2, and one
authentication method from the second sub-list, which is
announcements 3 and 4. If the receiving peer does not support at
least one authentication method from each sub-list or does not wish
to perform the number of authentications preferred by the sending
peer, it MAY select an authentication method from a subset of these
sub-lists, rather than an authentication method from each. If the
receiving peer wishes to perform only one authentication, it can
perform, for example, only the PQ_b authentication, rather than the
PQ_a/b/c authentication in conjunction with either ECDSA with SHA-512
on the P-521 curve or ECDSA with SHA-384 on the P-384 curve. If the
receiving peer does not support at least one authentication method
from each sub-list or does not wish to perform as many
authentications as preferred by the sending peer, it SHOULD attempt
to choose an authentication method that is preferred by the sending
peer.
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(=0)| SPI Size (=0) | Notify Message Type (=16404) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of Auths | |
+-+-+-+-+-+-+-+-+ |
~ Indices ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: HYBRID_AUTH Notify Payload Format
Figure 3
Guthrie Expires 26 September 2022 [Page 8]
Internet-Draft Hybrid Non-Composite Auth in IKEv2 March 2022
3.4. CERTREQ Payload
The CERTREQ payload contains the IKE header, the certificate encoding
being requested, and the encoding of an acceptable certification
authority (CA) for the type of certificate requested [RFC7296]. The
CA field is a concatenated list of hashes of the public keys of
trusted CAs, where each is encoded as the SHA-1 hash of the Subject
Public Key Info element from each Trust Anchor certificate. Subject
Public Key Info contains signatureAlgorithm which identifies the
cryptographic algorithm used by the CA to sign the certificate.
Multiple CERTREQ payloads MAY be sent in order to accommodate
multiple values for certificate encodings, but a single CERTREQ
payload can contain requests corresponding to certificates used with
both traditional and PQ authentication, provided that they use the
same certificate encoding.
3.5. Additional AUTH Payload
The AUTH payload, as specified in [RFC7296], contains an IKE header,
the authentication method, reserved bits, and authentication data.
Additional AUTH payloads MUST use the same AUTH payload format as is
defined in [RFC7296]. AUTH payloads MAY use the same authentication
method. AUTH payloads sent by a peer SHOULD use authentication
methods announced by the other peer in N(SUPPORTED_AUTH_METHODS).
For each AUTH payload a peer sends that is using an authentication
method that requires a CERT payload, there MUST be at least one CERT
payload accompanying that AUTH payload. There may be more than one
CERT payload per AUTH payload if certificate chains are sent.
When additional AUTH and CERT payloads are sent in support of
multiple authentications, all additional AUTH and CERT payloads MUST
be sent at the end of the IKE_AUTH message. Each additional AUTH
payload MUST be directly preceded by the CERT payloads that are used
during that authentication.
When a peer receives multiple sets of AUTH and CERT payloads, they
SHOULD perform all authentications. It is left to the individual
implementation to decide whether or not to proceed if some but not
all authentications are performed, or some but not all
authentications succeed. If no authentications succeed, the
connection MUST be dropped.
3.6. Additional CERT Payload
The CERT payload contains the IKE header, the certificate encoding,
and the certificate data [RFC7296].
Guthrie Expires 26 September 2022 [Page 9]
Internet-Draft Hybrid Non-Composite Auth in IKEv2 March 2022
Though this document refers to a single traditional CERT payload and
a single PQ CERT payload, it is often the case that multiple CERT
payloads are sent in response to a single CERTREQ in order to provide
a certificate chain.
[RFC7296] states that if more than one CERT payload is used for
authentication, the first CERT payload MUST contain the public key
used to verify the AUTH payload. The remaining CERT payloads need
not be in any particular order.
If additional AUTH and CERT payloads are sent in support of multiple
authentications, all additional AUTH and CERT payloads MUST be sent
at the end of the IKE_AUTH message. Each set of CERT payloads used
in a single authentication MUST be listed consecutively, beginning
with the end entity certificate, and be immediately followed by the
relevant AUTH payload. If more than two sets of AUTH and CERT
payloads are sent, each additional AUTH payload acts as a delimiter
which groups together CERT payloads containing certificates that
belong to the same certificate chain.
For example, if the responder sent three sets of AUTH and CERT
payloads, the responder's IKE_AUTH message appear as shown in
Figure 4.
Initiator Responder
----------- -----------
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr, [CERT,] [AUTH,]
[CERT,] [AUTH]}
Figure 4: Responder's IKE_AUTH message with three authentications
Figure 4
In the case that more than one authentication uses X.509
certificates, the peer in receipt of these certificates MUST confirm
that the SANs match in all end entity certificates.
For guidance on performing validation of multiple certificate chains,
refer to [I-D.draft-becker-guthrie-noncomposite-hybrid-auth].
Guthrie Expires 26 September 2022 [Page 10]
Internet-Draft Hybrid Non-Composite Auth in IKEv2 March 2022
4. Security Considerations
It is likely that the Post-Quantum AUTH and CERT payloads will cause
the IKE_AUTH message to exceed the supported message size, requiring
use of [RFC7383]. Thus, this document inherits the security concerns
of both [RFC7296] and [RFC7383]. This document also incorporates
[I-D.draft-ietf-ipsecme-ikev2-intermediate] and
[I-D.draft-ietf-ipsecme-ikev2-auth-announce], so it inherits these
security considerations as well.
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. Other concerns may arise through the use of
multiple certificate chains and digital signatures, as considered in
[I-D.draft-becker-guthrie-noncomposite-hybrid-auth].
Last, it is worth noting that a DoS attack could be conducted through
this document's use of the N(SUPPORTED_AUTH_METHODS) sent in the
IKE_SA_INIT exchange, where a malicious responder could send a long
list of authentication announcements.
5. IANA Considerations
This document defines a new Notify Message Type in the "IKEv2 Notify
Message Types - Status Types" registry [IKEV2IANA]:
<TBA> HYBRID_AUTH
6. References
6.1. Normative References
[I-D.draft-ietf-ipsecme-ikev2-auth-announce]
Smyslov, V., "Announcing Supported Authentication Methods
in IKEv2", draft-ietf-ipsecme-ikev2-auth-announce-00 (work
in progress), February 2022,
<https://datatracker.ietf.org/doc/draft-ietf-ipsecme-
ikev2-auth-announce/>.
[I-D.draft-ietf-ipsecme-ikev2-intermediate]
Smyslov, V., "Intermediate Exchange in the IKEv2
Protocol", draft-ietf-ipsecme-ikev2-intermediate-10 (work
in progress), March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
ikev2-intermediate-10>.
Guthrie Expires 26 September 2022 [Page 11]
Internet-Draft Hybrid Non-Composite Auth in IKEv2 March 2022
[IKEV2IANA]
IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters",
<https://www.iana.org/assignments/ikev2-parameters/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383,
DOI 10.17487/RFC7383, November 2014,
<https://www.rfc-editor.org/info/rfc7383>.
[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in
the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
DOI 10.17487/RFC7427, January 2015,
<https://www.rfc-editor.org/info/rfc7427>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References
[I-D.draft-becker-guthrie-noncomposite-hybrid-auth]
Becker, A., Guthrie, R., and M. Jenkins, "Non-Composite
Hybrid Authentication in PKIX and Applications to Internet
Protocols", draft-becker-guthrie-noncomposite-hybrid-
auth-00 (work in progress), March 2022,
<https://www.ietf.org/id/draft-becker-guthrie-
noncomposite-hybrid-auth-
00.html?msclkid=8114e302aa0611ecbea583d810632940>.
[RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication
Exchanges in the Internet Key Exchange (IKEv2) Protocol",
RFC 4739, DOI 10.17487/RFC4739, November 2006,
<https://www.rfc-editor.org/info/rfc4739>.
Author's Address
Guthrie Expires 26 September 2022 [Page 12]
Internet-Draft Hybrid Non-Composite Auth in IKEv2 March 2022
Rebecca Guthrie
National Security Agency
Email: rmguthr@uwe.nsa.gov
Guthrie Expires 26 September 2022 [Page 13]
