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="true" 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="July" 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> <keyword>signature</keyword>
<t> This specification defines a mechanism that allows the Internet <keyword>digital signature</keyword>
Key Exchange version 2 (IKEv2) <keyword>credentials</keyword>
implementations to indicate the list of supported authentication met <keyword>intermediate exchange</keyword>
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> <abstract>
<section anchor="intro" title="Introduction"> <t> This specification defines a mechanism that allows implementations
<t> The Internet Key Exchange version 2 (IKEv2) protocol, defined in of the Internet Key Exchange Protocol Version 2 (IKEv2) to indicate the li
<xref target="RFC7296" />, 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 types for authenticating 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
method and doesn't provide means for peers to indicate
to the other side which authentication methods they support, it is p
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
challenges for implementations,
especially if so-called hybrid schemes are used (e.g. see <xref targ
et="I-D.ounsworth-pq-composite-sigs" />).
</t>
<t> 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.
</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 to its peer a list 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>
<t> Since the responder sends the SUPPORTED_AUTH_METHODS notific
ation in the IKE_SA_INIT exchange,
it must take care that the size of the response message wouldn't
grow too much so that IP fragmentation takes place.
If both of the following conditions are met:
<list style="symbols"> <t>
<t>the SUPPORTED_AUTH_METHODS notification to be included is Because the responder sends the SUPPORTED_AUTH_METHODS notification in
so large, that the responder suspects the IKE_SA_INIT exchange, it must take into account that the
response message could grow so much that the IP fragmentation might take place
.
</t>
<ul spacing="normal">
<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 al
lways fulfilled for the IKE_SA_INIT and IKE_AUTH exchanges). ways 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 Message Type</name>
<t> The format of the SUPPORTED_AUTH_METHODS notification is sho <t> The format of the SUPPORTED_AUTH_METHODS Notify payload is shown bel
wn below. ow.
<figure align="center" anchor="notify" title="SUPPORTED_AUTH_MET </t>
HODS Notify"> <figure anchor="notify">
<artwork align="left"><![CDATA[ <name>SUPPORTED_AUTH_METHODS Notify Payload Format</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>2-Octet Announcement Format</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>3-Octet Announcement Format</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 a 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>Multi-octet Announcement Format</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 ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></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:</dt> <dd>The variable-length ASN.1 object
<t>AlgorithmIdentifier ASN.1 object - the AlgorithmI that is encoded using Distinguished Encoding Rules (DER) <xref target="X.690"/>
dentifier of PKIX (see Section 4.1.1.2 of <xref target="RFC5280" />), and identifies the signature algorithm (see <xref target="RFC5280" section="4.1
encoded using distinguished encoding rules (DER) <xr .1.2" sectionFormat="of" />).
ef target="X.690" />. </dd>
</t> </dl>
</list> <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>
<t> The prominent example is "Secure Password Framework for Internet Key E
<t> The prominent example is <xref target="RFC6467" />, (Secure Passwo xchange Version 2" <xref target="RFC6467"/>,
rd Framework for Internet Key Exchange Version 2), which defines a framework for using secure password authentication in
which defines a framework for using Password-authenticated key exchang IKEv2.
es (PAKE) in IKEv2. With this framework, peers negotiate using one of the secure password
With this framework peers negotiate using one of PAKE methods in the I methods in the IKE_SA_INIT exchange --
KE_SA_INIT exchange - the initiator sends a list of supported methods in the request, and th
the initiator sends a list of supported PAKE methods in the request an e responder picks one of them and sends it back
d the responder picks one of them and sends it back
in the response. in the response.
</t> </t>
<t> If peers negotiate secure password authentication, then the selected m
<t> If peers negotiate PAKE for authentication, then the selected PAKE ethod 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
supported authentication methods in this case. Thus, if the peers choo se to go with secure password authentication,
se to go with PAKE, they <bcp14>MUST NOT</bcp14> send the SUPPORTED_AUTH_METHODS notificat
they MUST NOT send the SUPPORTED_AUTH_METHODS notification. ion.
</t> </t>
<t>In the situation when peers are going to use Multiple Authentication Ex
<t> If peers are going to use Multiple Authentication Exchanges <xref changes <xref target="RFC4739"/>,
target="RFC4739" />, they <bcp14>MAY</bcp14> include multiple SUPPORTED_AUTH_METHODS notifi
then they MAY include multiple SUPPORTED_AUTH_METHODS notifications in cations (instead of one), each containing authentication methods
stead 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.
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 <reference anchor="X.690">
unced authentication methods online, <front>
then the attacker can encourage peers to use one of these weaker met <title>Information Technology - ASN.1 encoding rules: Specification
hods of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
by removing all other announcements, and if this succeeds, then perf Encoding Rules (DER)</title>
orm person-in-the-middle attack. <author>
</t> <organization>ITU-T</organization>
</section> </author>
<date month="February" year="2021"/>
</front>
<seriesInfo name="ISO/IEC" value="8825-1:2021 (E)"/>
<seriesInfo name="ITU-T Recommendation" value="X.690"/>
</reference>
<section anchor="iana" title="IANA Considerations"> <reference anchor="IKEV2-IANA" target="https://www.iana.org/assignments/
<t>This document defines a new Notify Message Type in the "IKEv2 Not ikev2-parameters/">
ify Message Status Types" registry referencing this RFC:</t> <front>
<figure align="center"> <title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
<artwork align="left"><![CDATA[ <author>
<TBA> SUPPORTED_AUTH_METHODS [RFCXXXX] <organization>IANA</organization>
]]></artwork> </author>
</figure> <date/>
</section> </front>
</reference>
<section title="Acknowledgments"> </references>
<t>The author would like to thank Paul Wouters for his valuable comm <references>
ents and proposals.
The author is also grateful to Daniel Van Geest, who made proposals
for protocol improvement.
Reese Enghardt and Rifaat Shekh-Yusef contributed to the clarity of
the document.
</t>
</section>
</middle>
<back> <name>Informative References</name>
<references title='Normative References'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. 409.xml"/>
RFC.2119.xml" ?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. 739.xml"/>
RFC.8174.xml" ?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. 467.xml"/>
RFC.7296.xml" ?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. 383.xml"/>
RFC.7427.xml" ?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.
RFC.5280.xml" ?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/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="I-D.ietf-lamps-pq-composite-sigs" target="https://datatracker
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. .ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs-01">
RFC.2409.xml" ?> <front>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <title>Composite Signatures For Use In Internet PKI</title>
RFC.4739.xml" ?> <author initials="M." surname="Ounsworth" fullname="Mike Ounsworth">
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <organization>Entrust Limited</organization>
RFC.6467.xml" ?> </author>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <author initials="J." surname="Gray" fullname="John Gray">
RFC.7383.xml" ?> <organization>Entrust Limited</organization>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference </author>
.I-D.ounsworth-pq-composite-sigs.xml" ?> <author initials="M." surname="Pala" fullname="Massimiliano Pala">
</references> <organization>CableLabs</organization>
</author>
<author initials="J." surname="Klaussner" fullname="Jan Klaussner">
<organization>D-Trust GmbH</organization>
</author>
<date month="May" day="24" year="2024" />
<section anchor="examples" title="Examples of Announcing Supported Authe </front>
ntication Methods"> <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-sigs-0
<t> This appendix shows some examples of announcing authentication met 1" />
hods.
</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 payload 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 560
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>
</section> </back>
</back>
</rfc> </rfc>
 End of changes. 73 change blocks. 
458 lines changed or deleted 495 lines changed or added

This html diff was produced by rfcdiff 1.48.