rfc9593xml2.original.xml   rfc9593.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<rfc category="std" submissionType="IETF" ipr="trust200902" docName="draft-ietf- <!DOCTYPE rfc [
ipsecme-ikev2-auth-announce-10"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" submissionType="I ETF" ipr="trust200902" docName="draft-ietf-ipsecme-ikev2-auth-announce-10" numbe r="9593" updates="" obsoletes="" consensus="true" tocInclude="true" symRefs="tru e" sortRefs="false" version="3" xml:lang="en">
<?rfc toc="yes" ?> <front>
<?rfc symrefs="yes" ?> <title abbrev="Announcing Supported Auth Methods">Announcing Supported Authe
<?rfc sortrefs="no"?> ntication Methods in the Internet Key Exchange Protocol Version 2 (IKEv2)</title
<?rfc iprnotified="no" ?> >
<?rfc strict="yes" ?> <seriesInfo name="RFC" value="9593"/>
<author initials="V." surname="Smyslov" fullname="Valery Smyslov">
<organization>ELVIS-PLUS</organization>
<address>
<postal>
<street>PO Box 81</street>
<city>Moscow (Zelenograd)</city>
<code>124460</code>
<country>Russian Federation</country>
</postal>
<phone>+7 495 276 0211</phone>
<email>svan@elvis.ru</email>
</address>
</author>
<date month="June" year="2024"/>
<front> <area>SEC</area>
<title abbrev="Announcing Supported Auth Methods">Announcing Supported A <workgroup>ipsecme</workgroup>
uthentication Methods in IKEv2</title>
<author initials='V.' surname="Smyslov" fullname='Valery Smyslov'>
<organization>ELVIS-PLUS</organization>
<address>
<postal>
<street>PO Box 81</street>
<city>Moscow (Zelenograd)</city>
<code>124460</code>
<country>RU</country>
</postal>
<phone>+7 495 276 0211</phone>
<email>svan@elvis.ru</email>
</address>
</author>
<date/>
<abstract> <!--[rfced] Please insert any keywords (beyond those that appear in
<t> This specification defines a mechanism that allows the Internet the title) for use on https://www.rfc-editor.org/search. -->
Key Exchange version 2 (IKEv2)
implementations to indicate the list of supported authentication met
hods to their peers while establishing
IKEv2 Security Association (SA). This mechanism improves interoperab
ility when IKEv2 partners
are configured with multiple credentials of different type to authen
ticate each other.
</t>
</abstract>
</front>
<middle> <keyword>example</keyword>
<section anchor="intro" title="Introduction">
<t> The Internet Key Exchange version 2 (IKEv2) protocol, defined in <!--[rfced] Please clarify this sentence. What part of the sentence
<xref target="RFC7296" />, does "to authenticate each other" connect with?
Original:
This mechanism improves
interoperability when IKEv2 partners are configured with multiple
credentials of different type to authenticate each other.
Perhaps:
This mechanism improves
interoperability when IKEv2 partners are configured with multiple
credentials (of different types) for authenticating each other.
-->
<abstract>
<t> This specification defines a mechanism that allows implementations
of the Internet Key Exchange Protocol Version 2 (IKEv2) to indicate the li
st of
supported authentication methods to their peers while establishing IKEv2
Security Associations (SAs). This mechanism improves interoperability when
IKEv2 partners are configured with multiple credentials of different
type to authenticate each other.
</t>
</abstract>
</front>
<middle>
<section anchor="intro">
<name>Introduction</name>
<t> The Internet Key Exchange Protocol Version 2 (IKEv2), defined in <xref
target="RFC7296"/>,
performs authenticated key exchange in IPsec. IKEv2, unlike its pred ecessor IKEv1, performs authenticated key exchange in IPsec. IKEv2, unlike its pred ecessor IKEv1,
defined in <xref target="RFC2409" />, doesn't include a mechanism to defined in <xref target="RFC2409"/>, doesn't include a mechanism to
negotiate an authentication negotiate an authentication
method that the peers would use to authenticate each other. It is as method that the peers would use to authenticate each other. It is as
sumed that each peer selects whatever sumed that each peer selects whichever
authentication method it thinks is appropriate, depending on authent ication credentials it has. authentication method it thinks is appropriate, depending on authent ication credentials it has.
</t> </t>
<t> This approach generally works well when there is no ambiguity in selec
<t> This approach generally works well when there is no ambiguity in ting authentication credentials.
selecting authentication credentials. SA establishment failure between peers may occur when there are seve
SA establishment failure between peers may arise when there are seve ral credentials of different types configured on one peer,
ral credentials of different types configured on one peer,
while only some of them are supported on the other peer. Another pro blem situation is when a single while only some of them are supported on the other peer. Another pro blem situation is when a single
credential may be used to produce different types of authentication credential may be used to produce different types of authentication
tokens (e.g. signatures of different formats). tokens (e.g., signatures of different formats).
Since IKEv2 requires that each peer uses exactly one authentication <!--[rfced] Does "could" adequately convey the intent of "it is possible
method and doesn't provide means for peers to indicate that" here? Also, should "the method" be "a method" (i.e., in this example, is
to the other side which authentication methods they support, it is p there more than one method that is not supported by the other side)?
ossible that in these situations the peer that supports
wider range of authentication methods (or authentication token forma
ts) improperly selects
the method (or format) which is not supported by the other side.
</t>
<t> Emerging post-quantum signature algorithms may bring additional Original:
challenges for implementations, Since IKEv2 requires that each peer uses exactly one authentication method
especially if so-called hybrid schemes are used (e.g. see <xref targ and doesn't provide means for peers to indicate to the other side
et="I-D.ounsworth-pq-composite-sigs" />). which authentication methods they support, it is possible that in
</t> 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.
<t> Perhaps:
Since IKEv2 requires that each peer use exactly one authentication method,
and it doesn't provide means for peers to indicate to the other side
which authentication methods they support, the peer that supports a
wider range of authentication methods (or authentication token
formats) could improperly select a method (or format) that is not
supported by the other side.
-->
Since IKEv2 requires that each peer use exactly one authentication m
ethod, and it doesn't provide means for peers to indicate
to the other side which authentication methods they support, the pee
r that supports
a wider range of authentication methods (or authentication token for
mats) could improperly select
the method (or format) that is not supported by the other side.
</t>
<t> Emerging post-quantum signature algorithms may bring additional challe
nges for implementations,
especially if so-called hybrid schemes are used (e.g., see <xref tar
get="I-D.ietf-lamps-pq-composite-sigs"/>).
</t>
<t>
This specification defines an extension to the IKEv2 protocol that a llows peers to This specification defines an extension to the IKEv2 protocol that a llows peers to
announce their supported authentication methods, thus decreasing ris ks of SA establishment announce their supported authentication methods, thus decreasing ris ks of SA establishment
failure in situations when there are several ways for the peers to a uthenticate themselves. failure in situations when there are several ways for the peers to a uthenticate themselves.
</t> </t>
</section> </section>
<section anchor="mustshouldmay">
<section anchor="mustshouldmay" title="Terminology and Notation"> <name>Terminology and Notation</name>
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NO <t>
T", "SHOULD", "SHOULD NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this docu "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
ment are to be interpreted ",
as described in BCP 14 <xref target="RFC2119" /> <xref target="RFC81 "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
74" /> when, and only when, "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
they appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</t> be
</section> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
<section anchor="protocol" title="Protocol Details"> shown here.
<t>When establishing IKE SA each party may send a list of authentica </t>
tion methods it supports and is configured to use to its peer. </section>
For this purpose this specification introduces a new Notify Message <section anchor="protocol">
Type SUPPORTED_AUTH_METHODS. <name>Protocol Details</name>
<t>When establishing an IKE SA, each party may send a list to its peer of
the authentication methods it supports and is configured to use.
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 conv ey the supported The Notify payload with this Notify Message Type is utilized to conv ey the supported
authentication methods of the party sending it. The sending party ma y authentication methods of the party sending it. The sending party ma y
additionally specify that some of the authentication methods are onl y for use with additionally specify that some of the authentication methods are onl y for use with
the particular trust anchors. The receiving party may take this info rmation into consideration the particular trust anchors. The receiving party may take this info rmation into consideration
when selecting an algorithm for its authentication (i.e., the algori thm used for calculation of the AUTH payload) when selecting an algorithm for its authentication (i.e., the algori thm used for calculation of the AUTH payload)
if several alternatives are available. if several alternatives are available.
To simplify the receiver's task of linking the announced authenticat ion methods with the trust anchors, To simplify the receiver's task of linking the announced authenticat ion methods with the trust anchors,
the protocol ensures that the SUPPORTED_AUTH_METHODS notification is always co-located the protocol ensures that the SUPPORTED_AUTH_METHODS notification is always co-located
with the CERTREQ payload in the same message. with the CERTREQ payload in the same message.
</t> </t>
<section anchor="exchange">
<section anchor="exchange" title="Exchanges"> <name>Exchanges</name>
<t> The initiator starts the IKE_SA_INIT exchange as usual. If t <t> The initiator starts the IKE_SA_INIT exchange as usual. If the respo
he responder is willing to use this extension, it includes a new notification SU nder is willing to use this extension, it includes a new notification SUPPORTED_
PPORTED_AUTH_METHODS AUTH_METHODS
in the IKE_SA_INIT response message. This notification contains a list of authentication methods supported by the responder, ordered by their pr eference. in the IKE_SA_INIT response message. This notification contains a list of authentication methods supported by the responder, ordered by their pr eference.
</t> </t>
<figure align="center" anchor="ikesainit" title="The IKE_SA_INIT <figure anchor="ikesainit">
Exchange"> <name>The IKE_SA_INIT Exchange</name>
<artwork align="left"><![CDATA[ <artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ,] <-- HDR, SAr1, KEr, Nr, [CERTREQ,]
[N(SUPPORTED_AUTH_METHODS)(...)] [N(SUPPORTED_AUTH_METHODS)(...)]
]]></artwork> ]]></artwork>
</figure> </figure>
<t> If the initiator doesn't support this extension, it ignores the rece
<t> If the initiator doesn't support this extension, it ignores ived notification as an unknown status notify.
the received notification as an unknown status notify. </t>
</t> <t> Regardless of whether the notification is received, if the initiator
supports and is willing to use this extension,
<t> Regardless of whether the notification is received, if the i
nitiator supports and is willing to use this extension,
it includes the SUPPORTED_AUTH_METHODS notification in the IKE_A UTH request message, it includes the SUPPORTED_AUTH_METHODS notification in the IKE_A UTH request message,
with a list of authentication methods supported by the initiator , ordered by their preference. with a list of authentication methods supported by the initiator , ordered by their preference.
</t> </t>
<figure anchor="ikeauth">
<figure align="center" anchor="ikeauth" title="The IKE_AUTH Exch <name>The IKE_AUTH Exchange</name>
ange"> <artwork align="left"><![CDATA[
<artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SK {IDi, [CERT,] [CERTREQ,] HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr, [IDr,] AUTH, SAi2, TSi, TSr,
[N(SUPPORTED_AUTH_METHODS)(...)] } --> [N(SUPPORTED_AUTH_METHODS)(...)] } -->
<-- HDR, SK {IDr, [CERT,] <-- HDR, SK {IDr, [CERT,]
AUTH, SAr2, TSi, TSr } AUTH, SAr2, TSi, TSr }
]]></artwork> ]]></artwork>
</figure> </figure>
<!--[rfced] May this be rephrased as follows for clarity, in particular
the phrase "it must take care that the size ... wouldn't grow"?
<t> Since the responder sends the SUPPORTED_AUTH_METHODS notific Original:
ation in the IKE_SA_INIT exchange, 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.
Perhaps:
Because the responder sends the SUPPORTED_AUTH_METHODS notification in
the IKE_SA_INIT exchange, it must prevent the size of the
response message from growing so much that IP fragmentation occurs.
-->
<t> 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. it must take care that the size of the response message wouldn't grow too much so that IP fragmentation takes place.
If both of the following conditions are met: If both of the following conditions are met:
<list style="symbols"> </t>
<t>the SUPPORTED_AUTH_METHODS notification to be included is <ul spacing="normal">
so large, that the responder suspects <li>
<t>the SUPPORTED_AUTH_METHODS notification to be included is so larg
e, that the responder suspects
that IP fragmentation of the resulting IKE_SA_INIT response message may happen;</t> that IP fragmentation of the resulting IKE_SA_INIT response message may happen;</t>
<t>both peers support the IKE_INTERMEDIATE exchange, defined </li>
in <xref target="RFC9242" /> (i.e. <li>
<t>both peers support the IKE_INTERMEDIATE exchange, defined in <xre
f target="RFC9242"/> (i.e.,
the responder has received and is going to send the INTERMED IATE_EXCHANGE_SUPPORTED notification);</t> the responder has received and is going to send the INTERMED IATE_EXCHANGE_SUPPORTED notification);</t>
</list> </li>
</ul>
<t>
then the responder MAY choose not to send actual list of the sup ported authentication then the responder <bcp14>MAY</bcp14> choose not to send an actu al list of the supported authentication
methods in the IKE_SA_INIT exchange and instead ask the initiato r to start the IKE_INTERMEDIATE methods in the IKE_SA_INIT exchange and instead ask the initiato r to start the IKE_INTERMEDIATE
exchange for the list to be sent in. This would allow using IKE fragmentation <xref target="RFC7383" /> for long messages exchange for the list to be sent in. This would allow using IKE fragmentation <xref target="RFC7383"/> for long messages
(which cannot be used in the IKE_SA_INIT exchange), thus avoidin g IP fragmentation. (which cannot be used in the IKE_SA_INIT exchange), thus avoidin g IP fragmentation.
In this case the responder includes SUPPORTED_AUTH_METHODS notif In this case, the responder includes a SUPPORTED_AUTH_METHODS no
ication containing no data in the IKE_SA_INIT response. tification containing no data in the IKE_SA_INIT response.
</t> </t>
<t> If the initiator receives the empty SUPPORTED_AUTH_METHODS notificat
<t> If the initiator receives the empty SUPPORTED_AUTH_METHODS n ion in the IKE_SA_INIT exchange,
otification in the IKE_SA_INIT exchange,
it means that the responder is going to send the list of the sup ported authentication methods in the it means that the responder is going to send the list of the sup ported authentication methods in the
IKE_INTERMEDIATE exchange. If this exchange is to be initiated a nyway for some other reason, then IKE_INTERMEDIATE exchange. If this exchange is to be initiated a nyway for some other reason, then
the responder MAY use it to send the SUPPORTED_AUTH_METHODS noti the responder <bcp14>MAY</bcp14> use it to send the SUPPORTED_AU
fication. Otherwise, the initiator TH_METHODS notification. Otherwise, the initiator
MAY start the IKE_INTERMEDIATE exchange just for this sole purpo <bcp14>MAY</bcp14> start the IKE_INTERMEDIATE exchange for this
se by sending an empty IKE_INTERMEDIATE request. sole purpose by sending an empty IKE_INTERMEDIATE request.
The initiator MAY also indicate its identity (and possibly the p The initiator <bcp14>MAY</bcp14> also indicate its identity (and
erceived responder's identity too) possibly the perceived responder's identity too)
by including the IDi payload (possibly along with the IDr payloa by including the IDi payload (possibly along with the IDr payloa
d) into the IKE_INTERMEDIATE request. d) in the IKE_INTERMEDIATE request.
This information could help the responder to send back only thos This information could help the responder to send back only thos
e authentication methods, e authentication methods
that are configured to be used for authentication of this partic ular initiator. that are configured to be used for authentication of this partic ular initiator.
If these payloads are sent, they MUST be identical to the IDi/ID If these payloads are sent, they <bcp14>MUST</bcp14> be identica
r payloads sent later in the IKE_AUTH request. l to the IDi/IDr payloads sent later in the IKE_AUTH request.
</t> </t>
<t>If the responder has sent any CERTREQ payload in the IKE_SA_INIT, the
<t>If the responder has sent any CERTREQ payload in the IKE_SA_I n it <bcp14>SHOULD</bcp14> resend the same
NIT, then it SHOULD re-send the same
payload(s) in the IKE_INTERMEDIATE response containing the SUPPO RTED_AUTH_METHODS notification payload(s) in the IKE_INTERMEDIATE response containing the SUPPO RTED_AUTH_METHODS notification
if any of the included Announcements has a non-zero Cert Link fi eld (see <xref target="ann-3" /> and <xref target="ann-m" />). if any of the included Announcements has a non-zero Cert Link fi eld (see Sections <xref target="ann-3" format="counter"/> and <xref target="ann- m" format="counter"/>).
This requirement allows peers to have a list of Announcements an d a list of CAs in the same message, This requirement allows peers to have a list of Announcements an d a list of CAs in the same message,
which simplifies their linking (note, that this requirement is a which simplifies their linking. (Note that this requirement is a
lways fulfilled for the IKE_SA_INIT and IKE_AUTH exchanges). lways fulfilled for the IKE_SA_INIT and IKE_AUTH exchanges.)
However, if for any reason the responder doesn't re-send CERTREQ However, if for any reason the responder doesn't resend CERTREQ
payload(s) in the IKE_INTERMEDIATE exchange, then payload(s) in the IKE_INTERMEDIATE exchange, then
the initiator MUST NOT abort negotiation. Instead, the initiator the initiator <bcp14>MUST NOT</bcp14> abort negotiation. Instead
MAY either link the Announcements to the CAs received in the IKE_SA_INIT respon , the initiator <bcp14>MAY</bcp14> either link the Announcements to the CAs rece
se, ived in the IKE_SA_INIT response,
or MAY ignore the Announcements containing links to CAs. or it <bcp14>MAY</bcp14> ignore the Announcements containing lin
</t> ks to CAs.
</t>
<t>If multiple IKE_INTERMEDIATE exchanges take place during IKE <t>If multiple IKE_INTERMEDIATE exchanges take place during IKE SA estab
SA establishments, it is RECOMMENDED that the responder lishments, it is <bcp14>RECOMMENDED</bcp14> that the responder
use the last IKE_INTERMEDIATE exchange (the one just before IKE_ use the last IKE_INTERMEDIATE exchange (the one just before IKE_
AUTH) to send the list of supported auth methods. AUTH) to send the list of supported authentication methods.
However, it is not always possible for the responder to know how many IKE_INTERMEDIATE exchanges However, it is not always possible for the responder to know how many IKE_INTERMEDIATE exchanges
the initiator will use. In this case the responder MAY send the the initiator will use. In this case the responder <bcp14>MAY</b
list in any IKE_INTERMEDIATE exchange. cp14> send the list in any IKE_INTERMEDIATE exchange.
If the initiator sends IDi/IDr in an IKE_INTERMEDIATE request, t If the initiator sends IDi/IDr in an IKE_INTERMEDIATE request, t
hen it is RECOMMENDED that the responder hen it is <bcp14>RECOMMENDED</bcp14> that the responder
sends back the list of authentication methods in the response. sends back the list of authentication methods in the response.
</t> </t>
<figure anchor="ikeint">
<figure align="center" anchor="ikeint" title="Using the IKE_INTE <name>Using the IKE_INTERMEDIATE Exchange for Sending Authentication M
RMEDIATE Exchange for sending auth methods"> ethods</name>
<artwork align="left"><![CDATA[ <artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ,] <-- HDR, SAr1, KEr, Nr, [CERTREQ,]
[N(SUPPORTED_AUTH_METHODS)()] [N(SUPPORTED_AUTH_METHODS)()]
HDR, SK {..., [IDi, [IDr,]]} --> HDR, SK {..., [IDi, [IDr,]]} -->
<-- HDR, SK {..., [CERTREQ,] <-- HDR, SK {..., [CERTREQ,]
[N(SUPPORTED_AUTH_METHODS)(...)] } [N(SUPPORTED_AUTH_METHODS)(...)] }
HDR, SK {IDi, [CERT,] [CERTREQ,] HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr, [IDr,] AUTH, SAi2, TSi, TSr,
[N(SUPPORTED_AUTH_METHODS)(...)] } --> [N(SUPPORTED_AUTH_METHODS)(...)] } -->
<-- HDR, SK {IDr, [CERT,] <-- HDR, SK {IDr, [CERT,]
AUTH, SAr2, TSi, TSr } AUTH, SAr2, TSi, TSr }
]]></artwork>
]]></artwork> </figure>
</figure> <t> Note that sending the SUPPORTED_AUTH_METHODS notification and using
information obtained from it
<t> Note, that sending the SUPPORTED_AUTH_METHODS notification a are optional for both the initiator and the responder. If multip
nd using information obtained from it le SUPPORTED_AUTH_METHODS notifications are included
is optional for both the initiator and the responder. If multipl
e SUPPORTED_AUTH_METHODS notifications are included
in a message, all their announcements form a single ordered list , unless overridden by other extension in a message, all their announcements form a single ordered list , unless overridden by other extension
(see <xref target="interaction" />). (see <xref target="interaction"/>).
</t> </t>
</section> </section>
<section anchor="format">
<section anchor="format" title="SUPPORTED_AUTH_METHODS Notify"> <name>SUPPORTED_AUTH_METHODS Notify</name>
<t> The format of the SUPPORTED_AUTH_METHODS notification is sho <t> The format of the SUPPORTED_AUTH_METHODS notification is shown below
wn below. .
<figure align="center" anchor="notify" title="SUPPORTED_AUTH_MET </t>
HODS Notify"> <figure anchor="notify">
<artwork align="left"><![CDATA[ <name>SUPPORTED_AUTH_METHODS Notify</name>
<artwork align="left"><![CDATA[
1 2 3 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 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 | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type | | Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ List of Supported Auth Methods Announcements ~ ~ List of Supported Auth Methods Announcements ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
The Notify payload format is defined in Section 3.10 of <xref tar get="RFC7296" />. The Notify payload format is defined in <xref target="RFC7296" se ction="3.10" sectionFormat="of" />.
When a Notify payload of type SUPPORTED_AUTH_METHODS is sent, the 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 Protocol ID field is set to 0, the SPI Size is set to 0 (meaning
there is no SPI field, there is no SPI field),
and the Notify Message Type is set to &lt;TBA by IANA&gt;. and the Notify Message Type is set to 16443.
</t> </t>
<t> Notification data contains the list of supported authentication meth
<t> Notification data contains the list of supported authenticati ods announcements.
on methods announcements. Each individual announcement is a variable-size data blob whose f
Each individual announcement is a variable-size data blob, which ormat depends
format depends
on the announced authentication method. The blob always starts wi th an octet containing the length of the blob on the announced authentication method. The blob always starts wi th an octet containing the length of the blob
followed by an octet containing the authentication method. Authen tication methods are represented followed by an octet containing the authentication method. Authen tication methods are represented
as values from the "IKEv2 Authentication Method" registry defined in <xref target="IKEV2-IANA" />. as values from the "IKEv2 Authentication Method" registry defined in <xref target="IKEV2-IANA"/>.
The meaning of the remaining octets of the blob, if any, depends on the authentication method. The meaning of the remaining octets of the blob, if any, depends on the authentication method.
Note, that for the currently defined authentication methods the l ength octet Note that, for the currently defined authentication methods, the length octet
fully defines both the format and the semantics of the blob. fully defines both the format and the semantics of the blob.
</t> </t>
<t> If more authentication methods are defined in the future, the corres
<t> If more authentication methods are defined in the future, the ponding documents
corresponding documents
must describe the semantics of the announcements for these method s. Implementations must describe the semantics of the announcements for these method s. Implementations
MUST ignore announcements whose semantics they don't understand. <bcp14>MUST</bcp14> ignore announcements whose semantics they don
</t> 't understand.
</t>
<section anchor="ann-2" title="2-octet Announcement"> <section anchor="ann-2">
<t> If the announcement contains an authentication method tha <name>2-Octet Announcement</name>
t is not concerned <t> If the announcement contains an authentication method that is not
concerned
with public key cryptography, then the following format is us ed. with public key cryptography, then the following format is us ed.
<figure align="center" anchor="authmethod1" title="Supported </t>
Authentication Method"> <figure anchor="authmethod1">
<artwork align="left"><![CDATA[ <name>Supported Authentication Method</name>
<artwork align="left"><![CDATA[
1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (=2) | Auth Method | | Length (=2) | Auth Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl spacing="normal">
<list style="symbols"> <dt>Length:</dt> <dd>Length of the blob in octets; must be 2 for t
<t>Length - Length of the blob in octets, must be 2 for his case.</dd>
this case.</t> <dt>Auth Method:</dt> <dd>Announced authentication method.</dd>
<t>Auth Method - Announced authentication method.</t> </dl>
</list> <t>
This format is applicable for the authentication methods "Sh ared Key Message Integrity Code" (2) and "NULL Authentication" (13). This format is applicable for the authentication methods "Sh ared Key Message Integrity Code" (2) and "NULL Authentication" (13).
Note, that authentication method "Generic Secure Password Au Note that the authentication method "Generic Secure Password
thentication Method" (12) would also Authentication Method" (12) would also
fall in this category, however it is negotiated separately ( fall in this category; however, it is negotiated separately
see <xref target="RFC6467" />) and (see <xref target="RFC6467"/>), and
for this reason there is no point to announce it via this me for this reason there is no point to announce it via this me
chanism. See also <xref target="interaction" />. chanism. See also <xref target="interaction"/>.
</t> </t>
</section> </section>
<section anchor="ann-3">
<section anchor="ann-3" title="3-octet Announcement"> <name>3-Octet Announcement</name>
<t> If the announcement contains an authentication method th <t> If the announcement contains an authentication method that is conc
at is concerned erned
with public key cryptography, then the following format is u sed. This format with public key cryptography, then the following format is u sed. This format
allows linking the announcement with a particular trust anch or from the allows linking the announcement with a particular trust anch or from the
Certificate Request payload. Certificate Request payload.
<figure align="center" anchor="authmethod2" title="Supported </t>
Authentication Method"> <figure anchor="authmethod2">
<artwork align="left"><![CDATA[ <name>Supported Authentication Method</name>
<artwork align="left"><![CDATA[
1 2 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 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 | | Length (=3) | Auth Method | Cert Link |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl spacing="normal">
<list style="symbols"> <dt>Length:</dt> <dd>Length of the blob in octets; must be 3 for t
<t>Length - Length of the blob in octets, must be 3 his case.</dd>
for this case.</t> <dt>Auth Method:</dt> <dd>Announced authentication method.</dd>
<t>Auth Method - Announced authentication method.</t <dt>Cert Link:</dt> <dd>Links this announcement with particular CA
> .</dd>
<t>Cert Link - Links this announcement with particul </dl>
ar CA.</t> <t>
</list>
If the Cert Link field contains non-zero value N, it means t hat the announced authentication method is intended to be used If the Cert Link field contains a 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 Ce rtificate Request payload(s) sent by this peer. If it is zero, only with the N-th trust anchor (CA certificate) from the Ce rtificate Request payload(s) sent by this peer. If it is zero,
then this authentication method may be used with any CA. then this authentication method may be used with any CA.
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 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 received, the content If no Certificate Request payload were received, the content
of this field MUST be ignored and treated as zero. of this field <bcp14>MUST</bcp14> be ignored and treated as zero.
</t> </t>
<t> This format is applicable for the authentication methods "RSA Digi
<t> This format is applicable for the authentication methods tal Signature" (1),
"RSA Digital Signature" (1),
"DSS Digital Signature" (3), "ECDSA with SHA-256 on the P-25 6 curve" (9), "DSS Digital Signature" (3), "ECDSA with SHA-256 on the P-25 6 curve" (9),
"ECDSA with SHA-384 on the P-384 curve" (10) and "ECDSA with SHA-512 on the P-521 curve" (11). "ECDSA with SHA-384 on the P-384 curve" (10) and "ECDSA with SHA-512 on the P-521 curve" (11).
Note however, that these authentication methods are currentl y superseded by Note, however, that these authentication methods are current ly superseded by
the "Digital Signature" (14) authentication method, which ha s a different announcement format, the "Digital Signature" (14) authentication method, which ha s a different announcement format,
described below. described below.
</t> </t>
</section> </section>
<section anchor="ann-m">
<section anchor="ann-m" title="Multi-octet Announcement"> <name>Multi-octet Announcement</name>
<t> The following format is currently used only with the "Di <t> The following format is currently used only with the "Digital Sign
gital Signature" (14) authentication method. ature" (14) authentication method.
<figure align="center" anchor="authmethod3" title="Suppo </t>
rted Authentication Method"> <figure anchor="authmethod3">
<artwork align="left"><![CDATA[ <name>Supported Authentication Method</name>
<artwork align="left"><![CDATA[
1 2 3 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 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 | | | Length (>3) | Auth Method | Cert Link | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
~ AlgorithmIdentifier ASN.1 object ~ ~ AlgorithmIdentifier ASN.1 object ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl spacing="normal">
<list style="symbols"> <dt>Length:</dt> <dd>Length of the blob in octets; must be greater
<t>Length - Length of the blob in octets, must be gr than 3 for this case.</dd>
eater than 3 for this case.</t> <dt>Auth Method:</dt> <dd>Announced authentication method. At the
<t>Auth Method - Announced authentication method, at time of writing this document, only value 14 ("Digital Signature") is allowed.</
the time of writing this document only value 14 ("Digital Signature") is allowe dd>
d.</t> <dt>Cert Link:</dt> <dd>Links this announcement with a particular
<t>Cert Link - Links this announcement with particul CA; see <xref target="ann-3"/> for details.</dd>
ar CA; see <xref target="ann-3" /> for details.</t> <dt>AlgorithmIdentifier ASN.1 object:</dt> <dd>The AlgorithmIdenti
<t>AlgorithmIdentifier ASN.1 object - the AlgorithmI fier of PKIX (see <xref target="RFC5280" section="4.1.1.2" sectionFormat="of" />
dentifier of PKIX (see Section 4.1.1.2 of <xref target="RFC5280" />), ),
encoded using distinguished encoding rules (DER) <xr encoded using Distinguished Encoding Rules (DER) <xr
ef target="X.690" />. ef target="X.690"/>.
</t> </dd>
</list> </dl>
<t>
The "Digital Signature" authentication method, defined in <x The "Digital Signature" authentication method, defined in <x
ref target="RFC7427" />, ref target="RFC7427"/>,
supersedes previously defined signature authentication metho supersedes previously defined signature authentication metho
ds. In this case ds. In this case,
the real authentication algorithm is identified via Algorith mIdentifier ASN.1 object. the real authentication algorithm is identified via Algorith mIdentifier ASN.1 object.
Appendix A in <xref target="RFC7427" /> contains examples of <xref target="RFC7427" section="A" sectionFormat="of"/> cont
Commonly Used ASN.1 Objects. ains examples of commonly used ASN.1 objects.
</t> </t>
</section>
</section>
</section> </section>
</section>
<section title="Interaction with IKEv2 Extensions concerning Authenticat </section>
ion" anchor="interaction"> <section anchor="interaction">
<t> Generally in IKEv2 each party independently determines the way it <name>Interaction with IKEv2 Extensions concerning Authentication</name>
authenticates itself to the peer. <t> Generally in IKEv2 each party independently determines the way it auth
enticates itself to the peer.
In other words, authentication methods selected by the peers need not be the same. In other words, authentication methods selected by the peers need not be the same.
However, some IKEv2 extensions break this rule. However, some IKEv2 extensions break this rule.
</t> </t>
<!--[rfced] Will the term "PAKE method" (3 instances) be clear to the
reader? We see zero instances of this term in RFCs. We see usage of
"PAKE scheme" and "PAKE protocol" in RFC 8125.
<t> The prominent example is <xref target="RFC6467" />, (Secure Passwo Original:
rd Framework for Internet Key Exchange Version 2), With this
which defines a framework for using Password-authenticated key exchang framework peers negotiate using one of PAKE methods in the
es (PAKE) in IKEv2. IKE_SA_INIT exchange - the initiator sends a list of supported PAKE
With this framework peers negotiate using one of PAKE methods in the I methods in the request and the responder picks one of them and sends
KE_SA_INIT exchange - it back in the response.
the initiator sends a list of supported PAKE methods in the request an [...]
d the responder picks one of them and sends it back then the selected PAKE method is used ...
-->
<t> The prominent example is "Secure Password Framework for Internet Key E
xchange Version 2" <xref target="RFC6467"/>,
which defines a framework for using password-authenticated key exchang
es (PAKEs) in IKEv2.
With this framework, peers negotiate using one of the PAKE methods in
the IKE_SA_INIT exchange --
the initiator sends a list of supported PAKE methods in the request, a
nd the responder picks one of them and sends it back
in the response. in the response.
</t> </t>
<t> If peers negotiate PAKE for authentication, then the selected PAKE met
<t> If peers negotiate PAKE for authentication, then the selected PAKE hod is used by both initiator and responder,
method is used by both initiator and responder and no other authentication methods are involved. For this reason, the
and no other authentication methods are involved. For this reason ther re is no point to announce
e is no point to announce
supported authentication methods in this case. Thus, if the peers choo se to go with PAKE, supported authentication methods in this case. Thus, if the peers choo se to go with PAKE,
they MUST NOT send the SUPPORTED_AUTH_METHODS notification. they <bcp14>MUST NOT</bcp14> send the SUPPORTED_AUTH_METHODS notificat
</t> ion.
</t>
<t> If peers are going to use Multiple Authentication Exchanges <xref <t> If then peers are going to use Multiple Authentication Exchanges <xref
target="RFC4739" />, target="RFC4739"/>,
then they MAY include multiple SUPPORTED_AUTH_METHODS notifications in then they <bcp14>MAY</bcp14> include multiple SUPPORTED_AUTH_METHODS n
stead of one, each containing authentication methods otifications (instead of one), each containing authentication methods
appropriate for each authentication round. The notifications are inclu ded in the order appropriate for each authentication round. The notifications are inclu ded in the order
of the preference of performing authentication rounds. of the preference of performing authentication rounds.
</t> </t>
</section> </section>
<section anchor="iana">
<name>IANA Considerations</name>
<t>This document defines a new type in the "IKEv2 Notify Message Status Ty
pes" registry:</t>
<section anchor="sec" title="Security Considerations"> <table anchor="notify_msg_status_type">
<t> Security considerations for IKEv2 protocol are discussed in <xre <thead>
f target="RFC7296" />. <tr>
Security properties of different authentication methods varies. <th>Value</th>
Refer to corresponding documents, listed in <xref target="IKEV2-IANA <th>Notify Message Status Type</th>
" /> for discussion <th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>16443</td>
<td>SUPPORTED_AUTH_METHODS</td>
<td>RFC 9593</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sec">
<name>Security Considerations</name>
<t> Security considerations for the IKEv2 protocol are discussed in <xref
target="RFC7296"/>.
Security properties of different authentication methods vary.
Refer to corresponding documents, listed in the "IKEv2 Authenticatio
n Method" registry on <xref target="IKEV2-IANA"/> for discussion
of security properties of each authentication method. of security properties of each authentication method.
</t> </t>
<t> Announcing authentication methods gives an eavesdropper additional inf
ormation about peers' capabilities.
<!--[rfced] FYI, for readability, "attacker on the path" has been changed to
"on-path attacker" (2 instances). Please review whether this is correct.
-->
If a peer advertises "NULL Authentication" along with other methods,
then an active on-path attacker 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 thi
s case NULL authentication should be allowed by local security policy.
</t>
<t> Similarly, if an on-path attacker can break some of the announced auth
entication methods online,
then the attacker can encourage peers to use one of these weaker met
hods
by removing all other announcements, and if this succeeds, then perf
orm a person-in-the-middle attack.
</t>
</section>
<t> Announcing authentication methods gives an eavesdropper addition </middle>
al information about peers' capabilities. <back>
If a peer advertises NULL authentication along with other methods, t <displayreference target="I-D.ietf-lamps-pq-composite-sigs" to="COMPOSITE-SI
hen active attacker on the path can encourage peers GS"/>
to use NULL authentication by removing all other announcements. Note <references>
, that this is not a real "downgrade" attack, <name>References</name>
since authentication methods in IKEv2 are not negotiated and in this <references>
case NULL authentication should be allowed by local security policy. <name>Normative References</name>
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
296.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
427.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
242.xml"/>
<t> Similarly, if an attacker on the path can break some of the anno <!--[rfced] FYI, for [X.690] we have updated the reference from the 2002 to
unced authentication methods online, 2021 version because the 2002 is superseded. Please review and let us
then the attacker can encourage peers to use one of these weaker met know if this is acceptable. (Please see https://www.itu.int/rec/T-REC-X.690
hods for the list of documents that are "Superseded" vs. "In force".)
by removing all other announcements, and if this succeeds, then perf
orm person-in-the-middle attack.
</t>
</section>
<section anchor="iana" title="IANA Considerations"> Original:
<t>This document defines a new Notify Message Type in the "IKEv2 Not [X.690] "ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
ify Message Status Types" registry referencing this RFC:</t> Information technology – ASN.1 encoding rules:
<figure align="center"> Specification of Basic Encoding Rules (BER), Canonical
<artwork align="left"><![CDATA[ Encoding Rules (CER) and Distinguished Encoding Rules
<TBA> SUPPORTED_AUTH_METHODS [RFCXXXX] (DER)", July 2002.
]]></artwork>
</figure>
</section>
<section title="Acknowledgments"> Current:
<t>The author would like to thank Paul Wouters for his valuable comm [X.690] ITU-T, "Information Technology - ASN.1 encoding rules:
ents and proposals. Specification of Basic Encoding Rules (BER), Canonical
The author is also grateful to Daniel Van Geest, who made proposals Encoding Rules (CER) and Distinguished Encoding Rules
for protocol improvement. (DER)", ISO/IEC 8825-1:2021 (E), ITU-T
Reese Enghardt and Rifaat Shekh-Yusef contributed to the clarity of Recommendation X.690, February 2021.
the document. -->
</t>
</section>
</middle>
<back> <reference anchor="X.690">
<references title='Normative References'> <front>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <title>Information Technology - ASN.1 encoding rules: Specification
RFC.2119.xml" ?> of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. Encoding Rules (DER)</title>
RFC.8174.xml" ?> <author>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <organization>ITU-T</organization>
RFC.7296.xml" ?> </author>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <date month="February" year="2021"/>
RFC.7427.xml" ?> </front>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <seriesInfo name="ISO/IEC" value="8825-1:2021 (E)"/>
RFC.5280.xml" ?> <seriesInfo name="ITU-T Recommendation" value="X.690"/>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. </reference>
RFC.9242.xml" ?>
<reference anchor="X.690">
<front>
<title>ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:20
02,
Information technology – ASN.1 encoding rules: Specification
of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Encoding Ru
les (DER)
</title>
<author>
<organization></organization>
</author>
<date month="July" year="2002" />
</front>
</reference>
<reference anchor="IKEV2-IANA" target="https://www.iana.org/assignme
nts/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12">
<front>
<title>Internet Key Exchange Version 2 (IKEv2) Parameters</t
itle>
<author>
<organization>IANA</organization>
</author>
<date />
</front>
</reference>
</references>
<references title='Informative References'> <reference anchor="IKEV2-IANA" target="https://www.iana.org/assignments/
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. ikev2-parameters/">
RFC.2409.xml" ?> <front>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
RFC.4739.xml" ?> <author>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <organization>IANA</organization>
RFC.6467.xml" ?> </author>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <date/>
RFC.7383.xml" ?> </front>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference </reference>
.I-D.ounsworth-pq-composite-sigs.xml" ?>
</references>
<section anchor="examples" title="Examples of Announcing Supported Authe </references>
ntication Methods"> <references>
<t> This appendix shows some examples of announcing authentication met <!--[rfced] May we put the references in alphanumeric order (i.e.,
hods. may we change sortRefs="false" to "true" in the XML file)?-->
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
409.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
739.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
467.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
383.xml"/>
<!--[rfced] FYI, draft-ounsworth-pq-composite-sigs was replaced by
draft-ietf-lamps-pq-composite-sigs. We have updated the reference
accordingly; please review.
Original:
[I-D.ounsworth-pq-composite-sigs]
Ounsworth, M., Gray, J., Pala, M., and J. Klaußner,
"Composite ML-DSA for use in Internet PKI", Work in
Progress, Internet-Draft, draft-ounsworth-pq-composite-
sigs-13, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ounsworth-pq-
composite-sigs-13>.
Current:
[COMPOSITE-SIGS]
Ounsworth, M., Gray, J., Pala, M., and J. Klaussner,
"Composite Signatures For Use In Internet PKI", Work in
Progress, Internet-Draft, draft-ietf-lamps-pq-composite-
sigs-00, 24 May 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-00>.
-->
<!-- FYI, used the long form so that the author's name matches the header of
the I-D (which shows Klaussner not Klaußner).
-->
<reference anchor="I-D.ietf-lamps-pq-composite-sigs" target="https://datatracker
.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs-00">
<front>
<title>Composite Signatures For Use In Internet PKI</title>
<author initials="M." surname="Ounsworth" fullname="Mike Ounsworth">
<organization>Entrust Limited</organization>
</author>
<author initials="J." surname="Gray" fullname="John Gray">
<organization>Entrust Limited</organization>
</author>
<author initials="M." surname="Pala" fullname="Massimiliano Pala">
<organization>CableLabs</organization>
</author>
<author initials="J." surname="Klaußner" fullname="Jan Klaussner">
<organization>D-Trust GmbH</organization>
</author>
<date month="May" day="24" year="2024" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-sigs-0
0" />
</reference>
</references>
</references>
<section anchor="examples">
<name>Examples of Announcing Supported Authentication Methods</name>
<t> 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. 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 ma y be omitted for brevity. Note that some payloads that are not relevant to this specification ma y be omitted for brevity.
</t> </t>
<section anchor="no_intermediate_example">
<section anchor="no_intermediate_example" title="No Need to Use the IK <name>No Need to Use the IKE_INTERMEDIATE Exchange</name>
E_INTERMEDIATE Exchange" > <t> This example illustrates the situation when the SUPPORTED_AUTH_METHO
<t> This example illustrates the situation when the SUPPORTED_AUTH_M DS notify fits into the IKE_SA_INIT
ETHODS notify fits into the IKE_SA_INIT message, and thus the IKE_INTERMEDIATE exchange is not needed. In th
message and thus the IKE_INTERMEDIATE exchange is not needed. In thi is scenario, the responder
s scenario the responder
announces that it supports the "Shared Key Message Integrity Code" a nd the "NULL Authentication" announces that it supports the "Shared Key Message Integrity Code" a nd the "NULL Authentication"
authentication methods. The initiator informs the responder that it supports authentication methods. The initiator informs the responder that it supports
only the "Shared Key Message Integrity Code" authentication method. only the "Shared Key Message Integrity Code" authentication method.
<figure align="center"> </t>
<artwork align="left"><![CDATA[ <artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
IKE_SA_INIT IKE_SA_INIT
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, <-- HDR, SAr1, KEr, Nr,
N(SUPPORTED_AUTH_METHODS( N(SUPPORTED_AUTH_METHODS(
PSK, NULL)) PSK, NULL))
IKE_AUTH IKE_AUTH
HDR, SK {IDi, HDR, SK {IDi,
AUTH, SAi2, TSi, TSr, AUTH, SAi2, TSi, TSr,
N(SUPPORTED_AUTH_METHODS(PSK))} --> N(SUPPORTED_AUTH_METHODS(PSK))} -->
<-- HDR, SK {IDr, <-- HDR, SK {IDr,
AUTH, SAr2, TSi, TSr} AUTH, SAr2, TSi, TSr}
]]></artwork> ]]></artwork>
</figure> </section>
<section anchor="intermediate_example">
</t> <name>With Use of the IKE_INTERMEDIATE Exchange</name>
</section> <t>This example illustrates the situation when the IKE_INTERMEDIATE
exchange is used. In this scenario, the responder announces that
<section anchor="intermediate_example" title="With Use of the IKE_INTE
RMEDIATE Exchange" >
<t>This example illustrates the situation when the IKE_INTERMEDIATE
exchange is used. In this scenario the responder announces that
it supports the "Digital signature" authentication method using the RSASSA-PSS algorithm it supports the "Digital signature" authentication method using the RSASSA-PSS algorithm
with CA1 and CA2 and the same method using the ECDSA algorithm with CA3. with CA1 and CA2 and the same method using the ECDSA algorithm with CA3.
The initiator supports only the "Digital signature" authentication m ethod using the RSASSA-PSS algorithm The initiator supports only the "Digital signature" authentication m ethod using the RSASSA-PSS algorithm
with no link to a particular CA. with no link to a particular CA.
<figure align="center"> </t>
<artwork align="left"><![CDATA[ <artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
IKE_SA_INIT IKE_SA_INIT
HDR, SAi1, KEi, Ni, HDR, SAi1, KEi, Ni,
N(SIGNATURE_HASH_ALGORITHMS) --> N(SIGNATURE_HASH_ALGORITHMS) -->
<-- HDR, SAr1, KEr, Nr, <-- HDR, SAr1, KEr, Nr,
CERTREQ(CA1, CA2, CA3), CERTREQ(CA1, CA2, CA3),
N(SIGNATURE_HASH_ALGORITHMS), N(SIGNATURE_HASH_ALGORITHMS),
N(SUPPORTED_AUTH_METHODS()) N(SUPPORTED_AUTH_METHODS())
skipping to change at line 513 skipping to change at line 667
SIGNATURE(RSASSA-PSS:2), SIGNATURE(RSASSA-PSS:2),
SIGNATURE(ECDSA:3)))} SIGNATURE(ECDSA:3)))}
IKE_AUTH IKE_AUTH
HDR, SK {IDi, CERT, CERTREQ(CA2), HDR, SK {IDi, CERT, CERTREQ(CA2),
AUTH, SAi2, TSi, TSr, AUTH, SAi2, TSi, TSr,
N(SUPPORTED_AUTH_METHODS( N(SUPPORTED_AUTH_METHODS(
SIGNATURE(RSASSA-PSS:0)))} --> SIGNATURE(RSASSA-PSS:0)))} -->
<-- HDR, SK {IDr, CERT, <-- HDR, SK {IDr, CERT,
AUTH, SAr2, TSi, TSr} AUTH, SAr2, TSi, TSr}
]]></artwork> ]]></artwork>
</figure> </section>
</section>
</t> <section numbered="false">
</section> <name>Acknowledgments</name>
<t>The author would like to thank <contact fullname="Paul Wouters" /> for
his valuable comments and proposals.
The author is also grateful to <contact fullname="Daniel Van Geest"
/>, who made proposals for protocol improvement.
<contact fullname="Reese Enghardt"/> and <contact fullname="Rifaat
Shekh-Yusef"/> contributed to the clarity of the document.
</t>
</section>
<!--[rfced] These terms seem to be used interchangeably. Would you like any
instances to be updated for consistency (e.g., change 'notify' to 'notification'
)?
</section> a) SUPPORTED_AUTH_METHODS notification (11 instances)
</back> b) SUPPORTED_AUTH_METHODS notify (3 instances; capitalized in titles as needed)
(in the titles of Section 3.2 and Figure 4, as well as Appendix A.1:
"the SUPPORTED_AUTH_METHODS notify fits into...")
c) "a Notify payload of type SUPPORTED_AUTH_METHODS" (1 instance)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Note that our script did not flag
any words in particular, but this should still be reviewed as a best practice.
-->
</back>
</rfc> </rfc>
 End of changes. 76 change blocks. 
449 lines changed or deleted 613 lines changed or added

This html diff was produced by rfcdiff 1.48.