Internet Engineering Task Force (IETF) V. Smyslov
Request for Comments: 9593 ELVIS-PLUS
Category: Standards Track July 2024
ISSN: 2070-1721
This specification defines a mechanism that allows implementations of the Internet Key Exchange Protocol Version 2 (IKEv2) to indicate the list 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.
この仕様は、IKEV2セキュリティアソシエーション（SAS）を確立しながら、インターネットキーエクスチェンジプロトコルバージョン2（IKEV2）の実装が仲間にサポートされている認証方法のリストを示すことを可能にするメカニズムを定義します。このメカニズムは、IKEV2パートナーが異なるタイプの複数の資格情報で構成されている場合、相互の認証のために相互運用性を向上させます。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9593.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9593で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology and Notation
3. Protocol Details
3.1. Exchanges
3.2. SUPPORTED_AUTH_METHODS Notify Message Type
3.2.1. 2-Octet Announcement
3.2.2. 3-Octet Announcement
3.2.3. Multi-octet Announcement
4. Interaction with IKEv2 Extensions concerning Authentication
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Examples of Announcing Supported Authentication
Methods
A.1. No Need to Use the IKE_INTERMEDIATE Exchange
A.2. With Use of the IKE_INTERMEDIATE Exchange
Acknowledgments
Author's Address
The Internet Key Exchange Protocol Version 2 (IKEv2), defined in [RFC7296], performs authenticated key exchange in IPsec. IKEv2, unlike its predecessor IKEv1, defined in [RFC2409], doesn't include a mechanism to negotiate an authentication method that the peers would use to authenticate each other. It is assumed that each peer selects whichever authentication method it thinks is appropriate, depending on authentication credentials it has.
[RFC7296]で定義されているインターネットキー交換プロトコルバージョン2（IKEV2）は、IPSECで認証されたキー交換を実行します。IKEV2は、[RFC2409]で定義されている前身のIKEV1とは異なり、ピアが互いに認証するために使用する認証方法を交渉するメカニズムを含めていません。各ピアは、認証資格情報に応じて、適切であると思われる認証方法を選択すると想定されています。
This approach generally works well when there is no ambiguity in selecting authentication credentials. SA establishment failure between peers may occur when there are several credentials of different types configured on one peer, while only some of them are supported on the other peer. Another problem situation is when a single credential may be used to produce different types of authentication tokens (e.g., signatures of different formats). 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.
一般に、このアプローチは、認証資格情報を選択する際に曖昧さがない場合にうまく機能します。SAの確立の故障は、1つのピアで構成された異なるタイプのいくつかの資格情報がある場合に発生する可能性がありますが、その一部のみが他のピアでサポートされています。別の問題の状況は、単一の資格情報を使用して、異なるタイプの認証トークン（例：異なる形式の署名）を生成する場合です。IKEV2は、各ピアが正確に1つの認証方法を使用することを必要としているため、ピアがサポートする認証方法を反対側に示す手段を提供するものではないため、より範囲の認証方法（または認証トークン形式）をサポートするピアは反対側によってサポートされていないメソッド（または形式）を不適切に選択します。
Emerging post-quantum signature algorithms may bring additional challenges for implementations, especially if so-called hybrid schemes are used (e.g., see [COMPOSITE-SIGS]).
特に、いわゆるハイブリッドスキームが使用されている場合は、実装に追加の課題をもたらす可能性があります（例：[Composite-Sigs]を参照）。
This specification defines an extension to the IKEv2 protocol that allows peers to announce their supported authentication methods, thus decreasing risks of SA establishment failure in situations when there are several ways for the peers to authenticate themselves.
この仕様では、ピアがサポートされている認証方法を発表できるIKEV2プロトコルの拡張を定義します。これにより、ピアが自分自身を認証する方法がいくつかある場合、SAの確立障害のリスクが減少します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
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 convey the supported authentication methods of the party sending it. The sending party may additionally specify that some of the authentication methods are only for use with the particular trust anchors. The receiving party may take this information into consideration when selecting an algorithm for its authentication (i.e., the algorithm used for calculation of the AUTH payload) if several alternatives are available. To simplify the receiver's task of linking the announced authentication methods with the trust anchors, the protocol ensures that the SUPPORTED_AUTH_METHODS notification is always co-located with the CERTREQ payload in the same message.
IKE SAを確立するとき、各当事者は、サポートし、使用するように構成されている認証方法のリストをピアに送信できます。この目的のために、この仕様では、新しいNotifyメッセージタイプのsupported_auth_methodsを導入します。このNotifyメッセージタイプを使用したNotify Payloadは、それを送信する当事者のサポートされている認証方法を伝えるために使用されます。送信当事者は、認証方法の一部が特定の信頼アンカーでのみ使用するためのものであることをさらに指定する場合があります。受信者は、いくつかの選択肢が利用可能な場合、認証のためにアルゴリズム（つまり、認証ペイロードの計算に使用されるアルゴリズム）を選択する際に、この情報を考慮することができます。発表された認証方法をトラストアンカーとリンクするという受信者のタスクを簡素化するために、プロトコルは、Supported_Auth_Methods通知が常に同じメッセージのCertreqペイロードと共同で共同住宅されることを保証します。
The initiator starts the IKE_SA_INIT exchange as usual. If the responder is willing to use this extension, it includes a new notification SUPPORTED_AUTH_METHODS in the IKE_SA_INIT response message. This notification contains a list of authentication methods supported by the responder, ordered by their preference.
イニシエーターは、通常どおりIKE_SA_INIT Exchangeを開始します。Responderがこの拡張機能を使用する意思がある場合、IKE_SA_INIT応答メッセージに新しい通知をサポートしている_Auth_Methodsが含まれています。この通知には、レスポンダーによってサポートされている認証方法のリストが含まれており、その好みによって命じられています。
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ,]
[N(SUPPORTED_AUTH_METHODS)(...)]
Figure 1: The IKE_SA_INIT Exchange
図1：IKE_SA_INIT Exchange
If the initiator doesn't support this extension, it ignores the received notification as an unknown status notify.
イニシエーターがこの拡張機能をサポートしていない場合、未知のステータスが通知されたため、受信された通知を無視します。
Regardless of whether the notification is received, if the initiator supports and is willing to use this extension, it includes the SUPPORTED_AUTH_METHODS notification in the IKE_AUTH request message, with a list of authentication methods supported by the initiator, ordered by their preference.
通知が受信されたかどうかに関係なく、イニシエーターがこの拡張機能をサポートし、意欲的に使用する場合、IKE_AUTH要求メッセージにsupported_auth_methods通知が含まれ、イニシエーターがサポートする認証メソッドのリストが順序付けられた認証メソッドのリストが含まれています。
Initiator Responder
----------- -----------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr,
[N(SUPPORTED_AUTH_METHODS)(...)] } -->
<-- HDR, SK {IDr, [CERT,]
AUTH, SAr2, TSi, TSr }
Figure 2: The IKE_AUTH Exchange
図2：IKE_AUTH Exchange
Because the responder sends the SUPPORTED_AUTH_METHODS notification in 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.
ResponderはIKE_SA_INIT Exchangeでsupported_auth_methods通知を送信するため、応答メッセージが非常に大きく成長してIP断片化が行われる可能性があることを考慮する必要があります。
* the SUPPORTED_AUTH_METHODS notification to be included is so large, that the responder suspects that IP fragmentation of the resulting IKE_SA_INIT response message may happen;
* 含まれるサポートされた_AUTH_METHODS通知は非常に大きいため、Responderは、結果のIKE_SA_INIT応答メッセージのIP断片化が発生する可能性があると疑います。
* both peers support the IKE_INTERMEDIATE exchange, defined in [RFC9242] (i.e., the responder has received and is going to send the INTERMEDIATE_EXCHANGE_SUPPORTED notification);
* 両方のピアは、[rfc9242]で定義されているike_intermediate取引所をサポートしています（つまり、レスポンダーが受信し、中間diate_exchange_supported通知を送信します）。
then the responder MAY choose not to send an actual list of the supported authentication methods in the IKE_SA_INIT exchange and instead ask the initiator to start the IKE_INTERMEDIATE exchange for the list to be sent in. This would allow using IKE fragmentation [RFC7383] for long messages (which cannot be used in the IKE_SA_INIT exchange), thus avoiding IP fragmentation. In this case, the responder includes a SUPPORTED_AUTH_METHODS notification containing no data in the IKE_SA_INIT response.
その場合、レスポンダーは、IKE_SA_INIT Exchangeでサポートされている認証方法の実際のリストを送信しないことを選択し、代わりにイニシエーターに送信されるリストのIKE_INTERMEDIATE Exchangeを開始するように依頼する場合があります。（IKE_SA_INIT Exchangeで使用することはできません）したがって、IPの断片化を回避します。この場合、レスポンダーには、IKE_SA_INIT応答にデータが含まれていないSupported_Auth_Methods通知が含まれています。
If the initiator receives the empty SUPPORTED_AUTH_METHODS notification in the IKE_SA_INIT exchange, it means that the responder is going to send the list of the supported authentication methods in the IKE_INTERMEDIATE exchange. If this exchange is to be initiated anyway for some other reason, then the responder MAY use it to send the SUPPORTED_AUTH_METHODS notification. Otherwise, the initiator MAY start the IKE_INTERMEDIATE exchange for this sole purpose by sending an empty IKE_INTERMEDIATE request. The initiator MAY also indicate its identity (and possibly the perceived responder's identity too) by including the IDi payload (possibly along with the IDr payload) in the IKE_INTERMEDIATE request. This information could help the responder to send back only those authentication methods that are configured to be used for authentication of this particular initiator. If these payloads are sent, they MUST be identical to the IDi/IDr payloads sent later in the IKE_AUTH request.
イニシエーターがIKE_SA_INIT Exchangeで空のsupported_auth_methods通知を受信した場合、Responderがike_intermediate Exchangeでサポートされている認証方法のリストを送信することを意味します。とにかく他の理由でこの交換が開始される場合、レスポンダーはそれを使用してsupported_auth_methods通知を送信することができます。それ以外の場合、イニシエーターは、空のike_intermediateリクエストを送信することにより、この唯一の目的のためにike_intermediate Exchangeを開始する場合があります。イニシエーターはまた、IKE_INTERMEDIATEリクエストにIDIペイロード（おそらくIDRペイロードとともに）を含めることにより、そのアイデンティティ（およびおそらく認識されたレスポンダーのアイデンティティ）を示している場合があります。この情報は、レスポンダーがこの特定のイニシエーターの認証に使用されるように構成された認証方法のみを送り返すのに役立ちます。これらのペイロードが送信される場合、IKE_AUTHリクエストの後半で送信されたIDI/IDRペイロードと同一である必要があります。
If the responder has sent any CERTREQ payload in the IKE_SA_INIT, then it SHOULD resend the same payload(s) in the IKE_INTERMEDIATE response containing the SUPPORTED_AUTH_METHODS notification if any of the included Announcements has a non-zero Cert Link field (see Sections 3.2.2 and 3.2.3). This requirement allows peers to have a list of Announcements and a list of CAs in the same message, which simplifies their linking. Note that this requirement is always fulfilled for the IKE_SA_INIT and IKE_AUTH exchanges. However, if for any reason the responder doesn't resend CERTREQ payload(s) in the IKE_INTERMEDIATE exchange, then the initiator MUST NOT abort negotiation. Instead, the initiator MAY either link the Announcements to the CAs received in the IKE_SA_INIT response, or it MAY ignore the Announcements containing links to CAs.
ResponderがIKE_SA_INITでCertreqペイロードを送信した場合、サポートされている_AUTH_METHODS通知を含むIKE_INTERMEDIATE応答で同じペイロードを再送信する必要があります。および3.2.3）。この要件により、ピアは、同じメッセージのアナウンスメントのリストと同じメッセージのCAのリストを持つことができ、リンクを簡素化できます。この要件は、IKE_SA_INITおよびIKE_AUTH交換のために常に満たされていることに注意してください。ただし、何らかの理由で、ResponderがIKE_INTERMEDIATE ExchangeでCertreqペイロードを再送信しない場合、イニシエーターは交渉を中止してはなりません。代わりに、イニシエーターは、IKE_SA_INIT応答で受信したCASに発表をリンクするか、CASへのリンクを含むアナウンスメントを無視する場合があります。
If multiple IKE_INTERMEDIATE exchanges take place during IKE SA establishments, it is RECOMMENDED that the responder use the last IKE_INTERMEDIATE exchange (the one just before IKE_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 the initiator will use. In this case the responder MAY send the list in any IKE_INTERMEDIATE exchange. If the initiator sends IDi/IDr in an IKE_INTERMEDIATE request, then it is RECOMMENDED that the responder sends back the list of authentication methods in the response.
IKE SA施設中に複数のIKE_INTERMEDIATE EXCHANGEが行われる場合、レスポンダーが最後のIKE_INTERMEDIATE Exchange（IKE_AUTHの直前のもの）を使用して、サポートされている認証方法のリストを送信することをお勧めします。ただし、Responderがイニシエーターが使用するike_intermediate交換の数を常に知ることができるとは限りません。この場合、ResponderはIKE_INTERMEDIATE EXCHERNGYでリストを送信する場合があります。イニシエーターがIKE/IDRをIKE_INTERMEDIATEリクエストで送信する場合、応答者が応答の認証方法のリストを送信することをお勧めします。
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ,]
[N(SUPPORTED_AUTH_METHODS)()]
HDR, SK {..., [IDi, [IDr,]]} -->
<-- HDR, SK {..., [CERTREQ,]
[N(SUPPORTED_AUTH_METHODS)(...)] }
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr,
[N(SUPPORTED_AUTH_METHODS)(...)] } -->
<-- HDR, SK {IDr, [CERT,]
AUTH, SAr2, TSi, TSr }
Figure 3: Using the IKE_INTERMEDIATE Exchange for Sending Authentication Methods
図3：認証方法を送信するためにike_intermediate Exchangeを使用する
Note that sending the SUPPORTED_AUTH_METHODS notification and using information obtained from it are optional for both the initiator and the responder. If multiple SUPPORTED_AUTH_METHODS notifications are included in a message, all their announcements form a single ordered list, unless overridden by other extension (see Section 4).
supported_auth_methods通知とそれから取得した情報を使用することは、イニシエーターとレスポンダーの両方でオプションであることに注意してください。複数のsupported_auth_methods通知がメッセージに含まれている場合、他の拡張機能によって無効にされない限り、すべての発表が単一の順序リストリストを形成します（セクション4を参照）。
The format of the SUPPORTED_AUTH_METHODS Notify payload is shown below.
supported_auth_methodsのフォーマットはペイロードを通知します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ List of Supported Auth Methods Announcements ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SUPPORTED_AUTH_METHODS Notify Payload Format
図4：supported_auth_methodsはペイロード形式に通知します
The Notify payload format is defined in Section 3.10 of [RFC7296]. 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 there is no SPI field), and the Notify Message Type is set to 16443.
通知ペイロード形式は、[RFC7296]のセクション3.10で定義されています。supported_auth_methodsの型の通知のペイロードが送信されると、プロトコルIDフィールドは0に設定され、SPIサイズは0に設定され（SPIフィールドがないことを意味します）、Notifyメッセージタイプは16443に設定されます。
Notification data contains the list of supported authentication methods announcements. Each individual announcement is a variable-size data blob whose format depends on the announced authentication method. The blob always starts with an octet containing the length of the blob followed by an octet containing the authentication method. Authentication methods are represented as values from the "IKEv2 Authentication Method" registry defined in [IKEV2-IANA]. 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 length octet fully defines both the format and the semantics of the blob.
通知データには、サポートされている認証方法のアナウンスのリストが含まれています。個々の発表は、発表された認証方法に依存する可変サイズのデータブロブです。ブロブは常に、ブロブの長さを含むオクテットから始まり、その後に認証方法を含むオクテットが続きます。認証方法は、[IKEV2-AINA]で定義されている「IKEV2認証方法」レジストリの値として表されます。BLOBの残りのオクテットの意味は、もしあれば、認証方法に依存します。現在定義されている認証方法では、長さのオクテットは、BLOBの形式とセマンティクスの両方を完全に定義することに注意してください。
If more authentication methods are defined in the future, the corresponding documents must describe the semantics of the announcements for these methods. Implementations MUST ignore announcements whose semantics they don't understand.
より多くの認証方法が将来定義されている場合、対応するドキュメントは、これらの方法の発表のセマンティクスを説明する必要があります。実装は、彼らが理解していないセマンティクスの発表を無視する必要があります。
If the announcement contains an authentication method that is not concerned with public key cryptography, then the following format is used.
発表に、公開キー暗号化に関係のない認証方法が含まれている場合、次の形式が使用されます。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (=2) | Auth Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: 2-Octet Announcement Format
図5：2-OCTETアナウンスフォーマット
Length:
長さ：
Length of the blob in octets; must be 2 for this case.
オクテットのブロブの長さ。この場合は2でなければなりません。
Auth Method:
AUTHメソッド：
Announced authentication method.
発表された認証方法。
This format is applicable for the authentication methods "Shared Key Message Integrity Code" (2) and "NULL Authentication" (13). Note that the authentication method "Generic Secure Password Authentication Method" (12) would also fall in this category; however, it is negotiated separately (see [RFC6467]), and for this reason there is no point to announce it via this mechanism. See also Section 4.
この形式は、認証メソッド「共有キーメッセージの整合性コード」（2）および「null認証」（13）に適用されます。認証方法「一般的な安全なパスワード認証方法」（12）もこのカテゴリに分類されることに注意してください。ただし、それは個別に交渉されており（[RFC6467]を参照）、このため、このメカニズムを介してそれを発表する意味はありません。セクション4も参照してください。
If the announcement contains an authentication method that is concerned with public key cryptography, then the following format is used. This format allows linking the announcement with a particular trust anchor from the Certificate Request payload.
発表に、公開キーの暗号化に関係する認証方法が含まれている場合、次の形式が使用されます。この形式により、証明書リクエストのペイロードからの特定のトラストアンカーと発表をリンクできます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (=3) | Auth Method | Cert Link |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: 3-Octet Announcement Format
図6：3-OCTETアナウンスフォーマット
Length:
長さ：
Length of the blob in octets; must be 3 for this case.
オクテットのブロブの長さ。この場合は3でなければなりません。
Auth Method:
AUTHメソッド：
Announced authentication method.
発表された認証方法。
Cert Link:
CERTリンク：
Links this announcement with a particular CA.
この発表を特定のCAにリンクします。
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 Certificate Request payload(s) sent by this peer. If it is zero, 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 no Certificate Request payload were received, the content of this field MUST be ignored and treated as zero.
CERTリンクフィールドにゼロ以外の値nが含まれている場合、発表された認証方法は、このピアが送信した証明書リクエストペイロードからのn番目の信頼アンカー（CA証明書）でのみ使用することを目的としています。ゼロの場合、この認証方法は任意のCAで使用できます。複数のCertreqペイロードが送信された場合、それらのすべてのCASは、リンクの目的のために単一のリストとして扱われます。証明書リクエストのペイロードが受信されない場合、このフィールドのコンテンツは無視され、ゼロとして扱わなければなりません。
This format is applicable for the authentication methods "RSA Digital Signature" (1), "DSS Digital Signature" (3), "ECDSA with SHA-256 on the P-256 curve" (9), "ECDSA with SHA-384 on the P-384 curve" (10) and "ECDSA with SHA-512 on the P-521 curve" (11). Note, however, that these authentication methods are currently superseded by the "Digital Signature" (14) authentication method, which has a different announcement format, described below.
この形式は、認証方法「RSAデジタル署名」（1）、「DSSデジタル署名」（3）、「P-256曲線にSHA-256を搭載したECDSA」（9）に適用できます。p-384曲線 "（10）および「p-521曲線にSHA-512を備えたECDSA」（11）。ただし、これらの認証方法は現在、以下で説明する別のアナウンス形式がある「デジタル署名」（14）認証方法に取って代わられていることに注意してください。
The following format is currently used only with the "Digital Signature" (14) authentication method.
次の形式は現在、「デジタル署名」（14）認証方法でのみ使用されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (>3) | Auth Method | Cert Link | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ AlgorithmIdentifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Multi-octet Announcement Format
図7：マルチオクテットアナウンスフォーマット
Length:
長さ：
Length of the blob in octets; must be greater than 3 for this case.
オクテットのブロブの長さ。この場合、3を超える必要があります。
Auth Method:
AUTHメソッド：
Announced authentication method. At the time of writing this document, only value 14 ("Digital Signature") is allowed.
発表された認証方法。このドキュメントを書く時点では、値14（「デジタル署名」）のみが許可されています。
Cert Link:
CERTリンク：
Links this announcement with a particular CA; see Section 3.2.2 for details.
この発表を特定のCAにリンクします。詳細については、セクション3.2.2を参照してください。
AlgorithmIdentifier:
algorithmidentifier：
The variable-length ASN.1 object that is encoded using Distinguished Encoding Rules (DER) [X.690] and identifies the signature algorithm (see Section 4.1.1.2 of [RFC5280]).
Distinguished Encodingルール（der）[x.690]を使用してエンコードされ、署名アルゴリズムを識別する変数ASN.1オブジェクト（[RFC5280]のセクション4.1.1.2を参照）を識別します。
The "Digital Signature" authentication method, defined in [RFC7427], supersedes previously defined signature authentication methods. In this case, the real authentication algorithm is identified via AlgorithmIdentifier ASN.1 object. Appendix A of [RFC7427] contains examples of commonly used ASN.1 objects.
[RFC7427]で定義されている「デジタル署名」認証方法は、以前に定義された署名認証方法に取って代わりました。この場合、実際の認証アルゴリズムは、アルゴリズムのIdentifier ASN.1オブジェクトを介して識別されます。[RFC7427]の付録Aには、一般的に使用されるASN.1オブジェクトの例が含まれています。
Generally in IKEv2 each party independently determines the way it authenticates itself to the peer. In other words, authentication methods selected by the peers need not be the same. However, some IKEv2 extensions break this rule.
一般に、IKEV2では、各当事者は、それがピアに認証する方法を独立して決定します。言い換えれば、ピアによって選択された認証方法は同じである必要はありません。ただし、一部のIKEV2拡張機能はこのルールを破ります。
The prominent example is "Secure Password Framework for Internet Key Exchange Version 2" [RFC6467], which defines a framework for using secure password authentication in IKEv2. With this framework, peers negotiate using one of the secure password methods in the IKE_SA_INIT exchange -- the initiator sends a list of supported methods in the request, and the responder picks one of them and sends it back in the response.
顕著な例は、「Internet Key Exchangeバージョン2の安全なパスワードフレームワーク」[RFC6467]です。これは、IKEV2で安全なパスワード認証を使用するためのフレームワークを定義しています。このフレームワークを使用すると、ピアはIKE_SA_INIT Exchangeの安全なパスワードメソッドのいずれかを使用して交渉します - イニシエーターはリクエストでサポートされているメソッドのリストを送信し、レスポンダーはそれらのいずれかを選択して応答に戻します。
If peers negotiate secure password authentication, then the selected method is used by both initiator and responder, and no other authentication methods are involved. For this reason, there is no point to announce supported authentication methods in this case. Thus, if the peers choose to go with secure password authentication, they MUST NOT send the SUPPORTED_AUTH_METHODS notification.
ピアが安全なパスワード認証を交渉する場合、選択した方法はイニシエーターとレスポンダーの両方で使用され、他の認証方法は含まれていません。このため、この場合、サポートされている認証方法を発表する意味はありません。したがって、ピアが安全なパスワード認証を使用することを選択した場合、supported_auth_methods通知を送信してはなりません。
In the situation when peers are going to use Multiple Authentication Exchanges [RFC4739], they MAY include multiple SUPPORTED_AUTH_METHODS notifications (instead of one), each containing authentication methods appropriate for each authentication round. The notifications are included in the order of the preference of performing authentication rounds.
ピアが複数の認証交換[RFC4739]を使用する状況では、それぞれが各認証ラウンドに適した認証方法を含む複数のsupported_auth_methods通知を含む場合があります。通知は、認証ラウンドを実行するという好みの順序に含まれています。
This document defines a new type in the "IKEv2 Notify Message Status Types" registry:
このドキュメントは、「IKEV2通知メッセージステータスタイプ」レジストリの新しいタイプを定義します。
+=======+============================+===========+
| Value | Notify Message Status Type | Reference |
+=======+============================+===========+
| 16443 | SUPPORTED_AUTH_METHODS | RFC 9593 |
+-------+----------------------------+-----------+
Table 1
Security considerations for the IKEv2 protocol are discussed in [RFC7296]. Security properties of different authentication methods vary. Refer to corresponding documents, listed in the "IKEv2 Authentication Method" registry on [IKEV2-IANA] for discussion of security properties of each authentication method.
IKEV2プロトコルのセキュリティ上の考慮事項については、[RFC7296]で説明しています。さまざまな認証方法のセキュリティプロパティは異なります。各認証方法のセキュリティプロパティの議論については、[IKEV2-AINA]の「IKEV2認証方法」レジストリにリストされている対応するドキュメントを参照してください。
Announcing authentication methods gives an eavesdropper additional information 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 this case NULL authentication should be allowed by local security policy.
認証方法を発表すると、盗聴者の能力に関する追加情報が得られます。ピアが他の方法とともに「null認証」を宣伝する場合、アクティブなオンパス攻撃者は、他のすべてのアナウンスを削除することにより、ピアにnull認証を使用するように促すことができます。IKEV2の認証方法はネゴシエートされておらず、この場合はヌル認証がローカルセキュリティポリシーで許可される必要があるため、これは実際の「ダウングレード」攻撃ではないことに注意してください。
Similarly, if an on-path attacker can break some of the announced authentication methods online, then the attacker can encourage peers to use one of these weaker methods by removing all other announcements, and if this succeeds, then perform a person-in-the-middle attack.
同様に、パス上の攻撃者が発表された認証方法の一部をオンラインで破ることができる場合、攻撃者は他のすべてのアナウンスを削除することにより、これらの弱い方法のいずれかを使用するようにピアを奨励できます。- 中間攻撃。
[IKEV2-IANA]
IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters",
<https://www.iana.org/assignments/ikev2-parameters/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in
the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
DOI 10.17487/RFC7427, January 2015,
<https://www.rfc-editor.org/info/rfc7427>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9242] Smyslov, V., "Intermediate Exchange in the Internet Key
Exchange Protocol Version 2 (IKEv2)", RFC 9242,
DOI 10.17487/RFC9242, May 2022,
<https://www.rfc-editor.org/info/rfc9242>.
[X.690] ITU-T, "Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2021 (E), ITU-T
Recommendation X.690, February 2021.
[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-01, 24 May 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-01>.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998,
<https://www.rfc-editor.org/info/rfc2409>.
[RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication
Exchanges in the Internet Key Exchange (IKEv2) Protocol",
RFC 4739, DOI 10.17487/RFC4739, November 2006,
<https://www.rfc-editor.org/info/rfc4739>.
[RFC6467] Kivinen, T., "Secure Password Framework for Internet Key
Exchange Version 2 (IKEv2)", RFC 6467,
DOI 10.17487/RFC6467, December 2011,
<https://www.rfc-editor.org/info/rfc6467>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383,
DOI 10.17487/RFC7383, November 2014,
<https://www.rfc-editor.org/info/rfc7383>.
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. Note that some payloads that are not relevant to this specification may be omitted for brevity.
この付録は、認証方法を発表する例を示しています。この付録は純粋に有益です。このドキュメントの本文に同意しない場合、他のテキストは正しいと見なされます。この仕様に関連していないペイロードは、簡潔に省略される場合があることに注意してください。
This example illustrates the situation when the SUPPORTED_AUTH_METHODS Notify payload fits into the IKE_SA_INIT message, and thus the IKE_INTERMEDIATE exchange is not needed. In this scenario, the responder announces that it supports the "Shared Key Message Integrity Code" and the "NULL Authentication" authentication methods. The initiator informs the responder that it supports only the "Shared Key Message Integrity Code" authentication method.
この例は、supported_auth_methodsがペイロードフィットにike_sa_initメッセージに通知する場合、ike_intermediate交換が必要ない状況を示しています。このシナリオでは、Responderは、「共有キーメッセージの整合性コード」と「Null認証」認証方法をサポートすることを発表します。イニシエーターは、「共有キーメッセージ整合性コード」認証方法のみをサポートすることをレスポンダーに通知します。
Initiator Responder
----------- -----------
IKE_SA_INIT
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr,
N(SUPPORTED_AUTH_METHODS(
PSK, NULL))
IKE_AUTH
HDR, SK {IDi,
AUTH, SAi2, TSi, TSr,
N(SUPPORTED_AUTH_METHODS(PSK))} -->
<-- HDR, SK {IDr,
AUTH, SAr2, TSi, TSr}
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 with CA1 and CA2 and the same method using the ECDSA algorithm with CA3. The initiator supports only the "Digital signature" authentication method using the RSASSA-PSS algorithm with no link to a particular CA.
この例は、IKE_INTERMEDIATE Exchangeが使用される状況を示しています。このシナリオでは、Responderは、CA1およびCA2を使用したRSASSA-PSSアルゴリズムを使用して「デジタル署名」認証方法をサポートし、CA3を使用したECDSAアルゴリズムを使用して同じ方法をサポートすることを発表しました。イニシエーターは、特定のCAへのリンクなしで、RSassa-PSSアルゴリズムを使用して「デジタル署名」認証方法のみをサポートします。
Initiator Responder
----------- -----------
IKE_SA_INIT
HDR, SAi1, KEi, Ni,
N(SIGNATURE_HASH_ALGORITHMS) -->
<-- HDR, SAr1, KEr, Nr,
CERTREQ(CA1, CA2, CA3),
N(SIGNATURE_HASH_ALGORITHMS),
N(SUPPORTED_AUTH_METHODS())
IKE_INTERMEDIATE
HDR, SK {..., IDi]} -->
<-- HDR, SK {...,
CERTREQ(CA1, CA2, CA3),
N(SUPPORTED_AUTH_METHODS(
SIGNATURE(RSASSA-PSS:1),
SIGNATURE(RSASSA-PSS:2),
SIGNATURE(ECDSA:3)))}
IKE_AUTH
HDR, SK {IDi, CERT, CERTREQ(CA2),
AUTH, SAi2, TSi, TSr,
N(SUPPORTED_AUTH_METHODS(
SIGNATURE(RSASSA-PSS:0)))} -->
<-- HDR, SK {IDr, CERT,
AUTH, SAr2, TSi, TSr}
The author would like to thank Paul Wouters for his valuable comments 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.
著者は、彼の貴重なコメントと提案についてPaul Woutersに感謝したいと思います。著者は、プロトコルの改善の提案をしたダニエル・ヴァン・ジストにも感謝しています。Reese EnghardtとRifaat Shekh-Yusefは、文書の明確さに貢献しました。
Valery Smyslov
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd)
124460
Russian Federation
Phone: +7 495 276 0211
Email: svan@elvis.ru