[要約] RFC 9242 introduces the "Intermediate Exchange" in IKEv2 for transferring large data during SA establishment, especially for Quantum Computer-resistant key exchange. It enables using IKE fragmentation mechanism to prevent IP fragmentation of large IKE messages before SA establishment.
Internet Engineering Task Force (IETF) V. Smyslov
Request for Comments: 9242 ELVIS-PLUS
Category: Standards Track May 2022
ISSN: 2070-1721
Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)
インターネットでの中間交換キーエクスチェンジプロトコルバージョン2（IKEV2）
Abstract
概要
This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment. The Intermediate Exchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established.
このドキュメントでは、インターネットキーエクスチェンジプロトコルバージョン2（IKEV2）の「中間取引所」と呼ばれる新しい交換を定義しています。この交換は、IKEV2セキュリティ協会（SA）施設のプロセスで大量のデータを転送するために使用できます。これを行う必要性の例は、IKE SAの確立に量子コンピューター（QC）に耐性のある主要な交換方法を使用することです。中間交換により、既存のIKE断片化メカニズム（初期IKEV2交換では使用できません）を使用することができ、IKEV2 SAが確立される前に送信する必要がある場合は、大きなIKEメッセージのIP断片化を回避できます。
Status of This Memo
本文書の位置付け
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/rfc9242.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9242で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Terminology and Notation
3. Intermediate Exchange Details
3.1. Support for Intermediate Exchange Negotiation
3.2. Using Intermediate Exchange
3.3. The IKE_INTERMEDIATE Exchange Protection and Authentication
3.3.1. Protection of IKE_INTERMEDIATE Messages
3.3.2. Authentication of IKE_INTERMEDIATE Exchanges
3.4. Error Handling in the IKE_INTERMEDIATE Exchange
4. Interaction with Other IKEv2 Extensions
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Example of IKE_INTERMEDIATE Exchange
Acknowledgements
Author's Address
The Internet Key Exchange Protocol Version 2 (IKEv2) defined in [RFC7296] uses UDP as a transport for its messages. If the size of a message is larger than the Path MTU (PMTU), IP fragmentation takes place, which has been shown to cause operational challenges in certain network configurations and devices. The problem is described in more detail in [RFC7383], which also defines an extension to IKEv2 called "IKE fragmentation". This extension allows IKE messages to be fragmented at the IKE level, eliminating possible issues caused by IP fragmentation. However, IKE fragmentation cannot be used in the initial IKEv2 exchange (IKE_SA_INIT). In most cases, this limitation is not a problem, since the IKE_SA_INIT messages are usually small enough not to cause IP fragmentation.
[RFC7296]で定義されているインターネットキー交換プロトコルバージョン2（IKEV2）は、メッセージのトランスポートとしてUDPを使用しています。メッセージのサイズがPATH MTU（PMTU）よりも大きい場合、IPフラグメンテーションが行われます。これは、特定のネットワーク構成とデバイスで運用上の課題を引き起こすことが示されています。この問題は、[RFC7383]でより詳細に説明されています。これは、「IKE断片化」と呼ばれるIKEV2の拡張も定義しています。この拡張機能により、IKEメッセージをIKEレベルで断片化することができ、IPの断片化によって引き起こされる可能な問題を排除します。ただし、IKEの断片化は、初期のIKEV2 Exchange（IKE_SA_INIT）では使用できません。ほとんどの場合、IKE_SA_INITメッセージは通常、IP断片化を引き起こさないほど十分に小さいため、この制限は問題ではありません。
However, the situation has been changing recently. One example of the need to transfer large amounts of data before an IKE SA is created is using the QC-resistant key exchange methods in IKEv2. Recent progress in quantum computing has led to concern that classical Diffie-Hellman key exchange methods will become insecure in the relatively near future and should be replaced with QC-resistant ones. Currently, most QC-resistant key exchange methods have large public keys. If these keys are exchanged in the IKE_SA_INIT exchange, then IP fragmentation will probably take place; therefore, all the problems caused by it will become inevitable.
しかし、状況は最近変化しています。IKE SAが作成される前に大量のデータを転送する必要性の1つの例は、IKEV2のQC耐性キー交換方法を使用することです。量子コンピューティングの最近の進歩は、古典的なDiffie-Hellmanの主要な交換方法が比較的近い将来に不安定になり、QC耐性の方法に置き換えるべきであるという懸念につながりました。現在、ほとんどのQC耐性キー交換方法には大きな公開キーがあります。これらのキーがIKE_SA_INIT Exchangeで交換されている場合、IPフラグメンテーションがおそらく行われます。したがって、それによって引き起こされるすべての問題は避けられません。
A possible solution to this problem would be to use TCP as a transport for IKEv2, as defined in [RFC8229]. However, this approach has significant drawbacks and is intended to be a last resort when UDP transport is completely blocked by intermediate network devices.
この問題の可能な解決策は、[RFC8229]で定義されているように、TCPをIKEV2の輸送として使用することです。ただし、このアプローチには重要な欠点があり、UDPトランスポートが中間ネットワークデバイスによって完全にブロックされている場合の最後の手段として意図されています。
This specification describes a way to transfer a large amount of data in IKEv2 using UDP transport. For this purpose, the document defines a new exchange for IKEv2 called "Intermediate Exchange" or "IKE_INTERMEDIATE". One or more of these exchanges may take place right after the IKE_SA_INIT exchange and prior to the IKE_AUTH exchange. The IKE_INTERMEDIATE exchange messages can be fragmented using the IKE fragmentation mechanism, so these exchanges may be used to transfer large amounts of data that don't fit into the IKE_SA_INIT exchange without causing IP fragmentation.
この仕様は、UDPトランスポートを使用してIKEV2で大量のデータを転送する方法を説明しています。この目的のために、このドキュメントは、「中間交換」または「IKE_INTERMEDIATE」と呼ばれるIKEV2の新しい交換を定義しています。これらの交換の1つ以上は、IKE_SA_INIT Exchangeの直後およびIKE_AUTH Exchangeの直前に行われる場合があります。IKE_INTERMEDIATEED EXCERNGメッセージは、IKEフラグメンテーションメカニズムを使用して断片化できます。そのため、これらの交換は、IPフラグメンテーションを引き起こすことなくIKE_SA_INIT Exchangeに収まらない大量のデータを転送するために使用できます。
The Intermediate Exchange can be used to transfer large public keys of QC-resistant key exchange methods, but its application is not limited to this use case. This exchange can also be used whenever some data needs to be transferred before the IKE_AUTH exchange and for some reason the IKE_SA_INIT exchange is not suited for this purpose. This document defines the IKE_INTERMEDIATE exchange without tying it to any specific use case. It is expected that separate specifications will define for which purposes and how the IKE_INTERMEDIATE exchange is used in IKEv2. Some considerations must be taken into account when designing such specifications:
中間交換は、QC耐性のキー交換方法の大きなパブリックキーを転送するために使用できますが、そのアプリケーションはこのユースケースに限定されません。この交換は、IKE_AUTH Exchangeの前にいくつかのデータを転送する必要があり、何らかの理由でIKE_SA_INIT Exchangeがこの目的に適していない場合にも使用できます。このドキュメントでは、特定のユースケースに縛られることなく、IKE_INTERMEDIATE Exchangeを定義します。IKEV2では、IKE_INTERMEDIATEEDETEMERCEDの使用方法とIKE_INTERMEDIATEEDの使用方法を定義する別の仕様が定義されることが期待されています。そのような仕様を設計する際には、いくつかの考慮事項を考慮する必要があります。
* The IKE_INTERMEDIATE exchange is not intended for bulk transfer. This document doesn't set a hard cap on the amount of data that can be safely transferred using this mechanism, as it depends on its application. However, in most cases, it is anticipated that the amount of data will be limited to tens of kilobytes (a few hundred kilobytes in extreme cases), which is believed to cause no network problems (see [RFC6928] as an example of experiments with sending similar amounts of data in the first TCP flight). See also Section 5 for the discussion of possible DoS attack vectors when the amount of data sent in the IKE_INTERMEDIATE exchange is too large.
* ike_intermediate Exchangeは、バルク転送を意図したものではありません。このドキュメントは、アプリケーションに依存するため、このメカニズムを使用して安全に転送できるデータの量にハードキャップを設定しません。ただし、ほとんどの場合、データの量は数十キロバイト（極端な場合は数百キロバイト）に制限されることが予想されています。最初のTCPフライトで同様の量のデータを送信します）。IKE_INTERMEDIATE Exchangeで送信されたデータの量が大きすぎる場合のDOS攻撃ベクターの議論については、セクション5も参照してください。
* It is expected that the IKE_INTERMEDIATE exchange will only be used for transferring data that is needed to establish IKE SA and not for data that can be sent later when this SA is established.
* ike_intermediate取引所は、IKE SAを確立するために必要なデータの転送にのみ使用されることが予想されます。この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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
It is expected that readers are familiar with the terms used in the IKEv2 specification [RFC7296]. Notation for the payloads contained in IKEv2 messages is defined in Section 1.2 of [RFC7296].
読者は、IKEV2仕様[RFC7296]で使用される用語に精通していることが期待されています。IKEV2メッセージに含まれるペイロードの表記は、[RFC7296]のセクション1.2で定義されています。
The initiator indicates its support for Intermediate Exchange by including a notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in the IKE_SA_INIT request message. If the responder also supports this exchange, it includes this notification in the response message.
イニシエーターは、IKE_SA_INITリクエストメッセージに型型intermediate_exchange_supportedの通知を含めることにより、中間交換のサポートを示します。Responderがこの交換もサポートしている場合、応答メッセージにこの通知が含まれています。
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni,
[N(INTERMEDIATE_EXCHANGE_SUPPORTED)] -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ],
[N(INTERMEDIATE_EXCHANGE_SUPPORTED)]
The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2 notification with Notify Message Type 16438. When it is sent, the Protocol ID and SPI Size fields in the Notify payload are both set to 0. This specification doesn't define any data that this notification may contain, so the Notification Data is left empty. However, future enhancements to this specification may override this. Implementations MUST ignore non-empty Notification Data if they don't understand its purpose.
Intermediate_exchange_supportedは、通知メッセージタイプ16438を使用したステータスタイプIKEV2通知です。送信されると、通知ペイロードのプロトコルIDとSPIサイズフィールドは両方とも0に設定されていません。したがって、通知データは空のままになります。ただし、この仕様の将来の強化はこれをオーバーライドする可能性があります。実装は、その目的を理解していない場合、空でない通知データを無視する必要があります。
If both peers indicated their support for the Intermediate Exchange, the initiator may use one or more these exchanges to transfer additional data. Using the Intermediate Exchange is optional; the initiator may find it unnecessary even when support for this exchange has been negotiated.
両方のピアが中間交換のサポートを示した場合、イニシエーターはこれらの交換を1つ以上使用して追加データを転送することができます。中間交換の使用はオプションです。イニシエーターは、この交換のサポートが交渉された場合でも、それが不要であると感じるかもしれません。
The Intermediate Exchange is denoted as IKE_INTERMEDIATE; its Exchange Type is 43.
中間交換はike_intermediateとして示されます。その交換タイプは43です。
Initiator Responder
----------- -----------
HDR, ..., SK {...} -->
<-- HDR, ..., SK {...}
The initiator may use several IKE_INTERMEDIATE exchanges if necessary. Since window size is initially set to 1 for both peers (Section 2.3 of [RFC7296]), these exchanges MUST be sequential and MUST all be completed before the IKE_AUTH exchange is initiated. The IKE SA MUST NOT be considered as established until the IKE_AUTH exchange is successfully completed.
イニシエーターは、必要に応じていくつかのIKE_INTERMEDIATE EXCHANGEを使用する場合があります。ウィンドウサイズは最初は両方のピア（[RFC7296]のセクション2.3）に対して1に設定されるため、これらの交換は順次必要であり、IKE_Auth Exchangeが開始される前にすべて完了する必要があります。IKE SAは、IKE_AUTH Exchangeが正常に完了するまで確立されていると見なされてはなりません。
The Message IDs for IKE_INTERMEDIATE exchanges MUST be chosen according to the standard IKEv2 rule, described in Section 2.2 of [RFC7296], i.e., it is set to 1 for the first IKE_INTERMEDIATE exchange, 2 for the next (if any), and so on. Implementations MUST verify that Message IDs in the IKE_INTERMEDIATE messages they receive actually follow this rule. The Message ID for the first pair of IKE_AUTH messages is one more than the value used in the last IKE_INTERMEDIATE exchange.
ike_intermediate取引所のメッセージIDは、[rfc7296]のセクション2.2で説明されている標準のikev2ルールに従って選択する必要があります。。実装は、受信したike_intermediateメッセージのメッセージIDが実際にこのルールに従うことを確認する必要があります。IKE_AUTHメッセージの最初のペアのメッセージIDは、最後のIKE_INTERMEDIATE Exchangeで使用されている値よりも1つです。
If the presence of NAT is detected in the IKE_SA_INIT exchange via NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notifications, then the peers switch to port 4500 in the first IKE_INTERMEDIATE exchange and use this port for all subsequent exchanges, as described in Section 2.23 of [RFC7296].
NAT_DETECTION_SOURCE_IPおよびNAT_DETECTION_DESTINATION_IP通知を介してIKE_SA_INIT ExchangeでNATの存在が検出された場合、ピアは[RFC7296]のセクション2.23に記載されているように、最初のIKE_インターメディーエクスチェンジでこのポートを最初のIKE_INTERMEDIATE Exchangeでポート4500に切り替え、その後のすべての交換にこのポートを使用します。
The content of the IKE_INTERMEDIATE exchange messages depends on the data being transferred and will be defined by specifications utilizing this exchange. However, since the main motivation for the IKE_INTERMEDIATE exchange is to avoid IP fragmentation when large amounts of data need to be transferred prior to the IKE_AUTH exchange, the Encrypted payload MUST be present in the IKE_INTERMEDIATE exchange messages, and payloads containing large amounts of data MUST be placed inside it. This will allow IKE fragmentation [RFC7383] to take place, provided it is supported by the peers and negotiated in the initial exchange.
ike_intermediate Exchangeメッセージのコンテンツは、転送されるデータに依存し、この交換を利用する仕様によって定義されます。ただし、IKE_INTERMEDIATE Exchangeの主な動機は、IKE_AUTH Exchangeの前に大量のデータを転送する必要がある場合、IPフラグメンテーションを回避することであるため、暗号化されたペイロードはIKE_INTERMEDIATE Exchangeメッセージに存在する必要があります。その中に置かれます。これにより、ピアによってサポートされ、最初の交換で交渉されていれば、IKEフラグメンテーション[RFC7383]が行われます。
Appendix A contains an example of using an IKE_INTERMEDIATE exchange in creating an IKE SA.
付録Aには、IKE SAの作成でIKE_INTERMEDIATE Exchangeを使用する例が含まれています。
The keys SK_e[i/r] and SK_a[i/r] for the protection of IKE_INTERMEDIATE exchanges are computed in the standard fashion, as defined in Section 2.14 of [RFC7296].
ike_intermediate取引所の保護のためのkeys sk_e [i/r]およびsk_a [i/r]は、[RFC7296]のセクション2.14で定義されているように、標準的な方法で計算されます。
Every subsequent IKE_INTERMEDIATE exchange uses the most recently calculated IKE SA keys before this exchange is started. So, the first IKE_INTERMEDIATE exchange always uses SK_e[i/r] and SK_a[i/r] keys that were computed as a result of the IKE_SA_INIT exchange. If additional key exchange is performed in the first IKE_INTERMEDIATE exchange, resulting in the update of SK_e[i/r] and SK_a[i/r], then these updated keys are used for protection of the second IKE_INTERMEDIATE exchange. Otherwise, the original SK_e[i/r] and SK_a[i/r] keys are used again, and so on.
その後のIKE_INTERMEDIATE EXCHANGEは、この交換が開始される前に、最近計算されたIKE SAキーを使用します。したがって、最初のike_intermediate Exchangeは、ike_sa_init Exchangeの結果として計算されたSK_E [I/R]とSK_A [I/R]キーを常に使用します。最初のIKE_INTERMEDIATE Exchangeで追加のキー交換が実行され、SK_E [I/R]とSK_A [I/R]の更新が行われた場合、これらの更新されたキーは、2番目のIKE_INTERMEDIATE Exchangeの保護に使用されます。それ以外の場合、元のSK_E [I/R]およびSK_A [I/R]キーが再び使用されます。
Once all the IKE_INTERMEDIATE exchanges are completed, the most recently calculated SK_e[i/r] and SK_a[i/r] keys are used for protection of the IKE_AUTH exchange and all subsequent exchanges.
すべてのIKE_INTERMEDIATE EXCHANGEが完了すると、最近計算されたSK_E [I/R]およびSK_A [I/R]キーがIKE_AUTH交換とその後のすべての交換の保護に使用されます。
The IKE_INTERMEDIATE messages must be authenticated in the IKE_AUTH exchange, which is performed by adding their content into the AUTH payload calculation. It is anticipated that in many use cases, IKE_INTERMEDIATE messages will be fragmented using the IKE fragmentation [RFC7383] mechanism. According to [RFC7383], when IKE fragmentation is negotiated, the initiator may first send a request message in unfragmented form, but later turn on IKE fragmentation and resend it fragmented if no response is received after a few retransmissions. In addition, peers may resend a fragmented message using different fragment sizes to perform simple PMTU discovery.
ike_intermediateメッセージは、IKE_AUTH Exchangeで認証される必要があります。これは、コンテンツをAUTHペイロード計算に追加することで実行されます。多くのユースケースでは、IKE断片化[RFC7383]メカニズムを使用してIKE_INTERMEDIATメッセージが断片化されることが予想されます。[RFC7383]によると、IKEの断片化が交渉されると、最初にイニシオンが要求メッセージをフラージュされていない形式で送信することがありますが、後でIKEフラグメンテーションをオンにし、いくつかの再送信後に応答がない場合は断片化します。さらに、ピアは、さまざまなフラグメントサイズを使用して断片化されたメッセージを再送信して、単純なPMTU発見を実行する場合があります。
The requirement to support this behavior makes authentication challenging: it is not appropriate to add on-the-wire content of the IKE_INTERMEDIATE messages into the AUTH payload calculation, because implementations are generally unaware of which form these messages are received by peers. Instead, a more complex scheme is used; authentication is performed by adding the content of these messages before their encryption and possible fragmentation, so that the data to be authenticated doesn't depend on the form the messages are delivered in.
この動作をサポートするための要件により、認証が困難になります。IKE_INTERMEDIATEメッセージのオンザワイヤコンテンツをAUTHペイロード計算に追加することは適切ではありません。これは、実装がピアによって受信される形式を実装することを一般に認識していないためです。代わりに、より複雑なスキームが使用されます。認証は、暗号化と可能な断片化の前にこれらのメッセージのコンテンツを追加することで実行され、認証されるデータはメッセージが配信される形式に依存しません。
If one or more IKE_INTERMEDIATE exchanges took place, the definition of the blob to be signed (or MACed) from Section 2.15 of [RFC7296] is modified as follows:
1つ以上のIKE_INTERMEDIATEED Exchangeが行われた場合、[RFC7296]のセクション2.15から署名される（またはマケッド）署名されるBLOBの定義が次のように変更されます。
InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI | IntAuth ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR | IntAuth
initiatationignedoctets = remumsg1 |非セルダタ|macedidfori |intauth ResponserSigneDoctets = remolmsg2 |非セイダタ|macedidforr |intauth
IntAuth = IntAuth_iN | IntAuth_rN | IKE_AUTH_MID
intauth = intauth_in |intauth_rn |ike_auth_mid
IntAuth_i1 = prf(SK_pi1, IntAuth_i1A [| IntAuth_i1P])
IntAuth_i2 = prf(SK_pi2, IntAuth_i1 | IntAuth_i2A [| IntAuth_i2P])
IntAuth_i3 = prf(SK_pi3, IntAuth_i2 | IntAuth_i3A [| IntAuth_i3P])
...
IntAuth_iN = prf(SK_piN, IntAuth_iN-1 | IntAuth_iNA [| IntAuth_iNP])
IntAuth_r1 = prf(SK_pr1, IntAuth_r1A [| IntAuth_r1P])
IntAuth_r2 = prf(SK_pr2, IntAuth_r1 | IntAuth_r2A [| IntAuth_r2P])
IntAuth_r3 = prf(SK_pr3, IntAuth_r2 | IntAuth_r3A [| IntAuth_r3P])
...
IntAuth_rN = prf(SK_prN, IntAuth_rN-1 | IntAuth_rNA [| IntAuth_rNP])
The essence of this modification is that a new chunk called "IntAuth" is appended to the string of octets that is signed (or MACed) by the peers. IntAuth consists of three parts: IntAuth_iN, IntAuth_rN, and IKE_AUTH_MID.
この修正の本質は、「intauth」と呼ばれる新しいチャンクが、ピアによって署名された（またはマッキングされた）一連のオクテットに追加されることです。intauthは、intauth_in、intauth_rn、およびike_auth_midの3つの部分で構成されています。
The IKE_AUTH_MID chunk is a value of the Message ID field from the IKE Header of the first round of the IKE_AUTH exchange. It is represented as a four-octet integer in network byte order (in other words, exactly as it appears on the wire).
IKE_AUTH_MID CHUNKは、IKE_AUTH Exchangeの最初のラウンドのIKEヘッダーからのメッセージIDフィールドの値です。ネットワークバイトの順序で4オクテットの整数として表されます（つまり、ワイヤーに表示されるのとまったく同じです）。
The IntAuth_iN and IntAuth_rN chunks represent the cumulative result of applying the negotiated Pseudorandom Function (PRF) to all IKE_INTERMEDIATE exchange messages sent during IKE SA establishment by the initiator and the responder, respectively. After the first IKE_INTERMEDIATE exchange is complete, peers calculate the IntAuth_i1 value by applying the negotiated PRF to the content of the request message from this exchange and calculate the IntAuth_r1 value by applying the negotiated PRF to the content of the response message. For every subsequent IKE_INTERMEDIATE exchange (if any), peers recalculate these values as follows: after the nth exchange is complete, they compute IntAuth_[i/r]n by applying the negotiated PRF to the concatenation of IntAuth_[i/r](n-1) (computed for the previous IKE_INTERMEDIATE exchange) and the content of the request (for IntAuth_in) or response (for IntAuth_rn) messages from this exchange. After all IKE_INTERMEDIATE exchanges are over, the resulted IntAuth_[i/r]N values (assuming N exchanges took place) are used in computing the AUTH payload.
Intauth_inおよびintauth_rnチャンクは、それぞれ開始者とレスポンダーによってIKE SA SAの確立中に送信されたすべてのIKE_INTERMEDIATE Exchangeメッセージに交渉済みの疑似ランダム関数（PRF）を適用した累積的な結果を表しています。最初のike_intermediate Exchangeが完了した後、ピアは、この交換からの要求メッセージのコンテンツにネゴシエートされたPRFを適用してINTAUTH_I1値を計算し、交渉済みのPRFを応答メッセージのコンテンツに適用してINTAUTH_R1値を計算します。その後のIKE_INTERMEDIATE EXCHANGE（もしあれば）ごとに、ピアは次のようにこれらの値を再計算します。NTHExchangeが完了した後、intauth_ [i/r] nを計算します。 -1）（以前のike_intermediate Exchange）およびリクエストのコンテンツ（intauth_in）またはこの交換からの応答（intauth_rnの）メッセージ。すべてのIKE_intermediate交換が終了した後、結果のintauth_ [i/r] n値（n交換が行われたと仮定）が認証ペイロードの計算に使用されます。
For the purpose of calculating the IntAuth_[i/r]* values, the content of the IKE_INTERMEDIATE messages is represented as two chunks of data: mandatory IntAuth_[i/r]*A, optionally followed by IntAuth_[i/ r]*P.
intauth_ [i/r]*値を計算するために、ike_intermediateメッセージのコンテンツは2つのデータとして表されます：必須intauth_ [i/r]*a、オプションでintauth_ [i/r]*pが続きます。
The IntAuth_[i/r]*A chunk consists of the sequence of octets from the first octet of the IKE Header (not including the prepended four octets of zeros, if UDP encapsulation or TCP encapsulation of ESP packets is used) to the last octet of the generic header of the Encrypted payload. The scope of IntAuth_[i/r]*A is identical to the scope of Associated Data defined for the use of AEAD algorithms in IKEv2 (see Section 5.1 of [RFC5282]), which is stressed by using the "A" suffix in its name. Note that calculation of IntAuth_[i/r]*A doesn't depend on whether an AEAD algorithm or a plain cipher is used in IKE SA.
intauth_ [i/r]*チャンクは、IKEヘッダーの最初のオクテットからのオクテットのシーケンスで構成されています（UDPのカプセル化またはESPパケットのTCPカプセル化が使用されている場合、ゼロの4オクテットの4オクテットを含まない）。暗号化されたペイロードの一般的なヘッダーの。Intauth_ [I/R]*Aの範囲は、IKEV2のAEADアルゴリズムの使用のために定義された関連データの範囲と同一です（[RFC5282]のセクション5.1を参照）。名前。INTAUTH_ [I/R]*の計算は、AEADアルゴリズムまたはプレーン暗号がIKE SAで使用されているかどうかに依存しないことに注意してください。
The IntAuth_[i/r]*P chunk is present if the Encrypted payload is not empty. It consists of the content of the Encrypted payload that is fully formed but not yet encrypted. The Initialization Vector, Padding, Pad Length, and Integrity Checksum Data fields (see Section 3.14 of [RFC7296]) are not included into the calculation. In other words, the IntAuth_[i/r]*P chunk is the inner payloads of the Encrypted payload in plaintext form, which is stressed by using the "P" suffix in its name.
暗号化されたペイロードが空でない場合、intauth_ [i/r]*pチャンクが存在します。これは、完全に形成されているがまだ暗号化されていない暗号化されたペイロードのコンテンツで構成されています。初期化ベクトル、パディング、パッドの長さ、および整合性チェックサムデータフィールド（[RFC7296]のセクション3.14を参照）は計算に含まれていません。言い換えれば、intauth_ [i/r]*p chunkは、暗号化されたペイロードの内側のペイロードであり、その名前の「p」接尾辞を使用して強調されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^
| IKE SA Initiator's SPI | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I |
| IKE SA Responder's SPI | K |
| | E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Next Payload | MjVer | MnVer | Exchange Type | Flags | H |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d |
| Message ID | r A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| Adjusted Length | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v |
| | |
~ Unencrypted payloads (if any) ~ |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |
| Next Payload |C| RESERVED | Adjusted Payload Length | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v
| | |
~ Initialization Vector ~ E
| | E
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^
| | r |
~ Inner payloads (not yet encrypted) ~ P
| | P |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v
| Padding (0-255 octets) | Pad Length | d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
~ Integrity Checksum Data ~ |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
Figure 1: Data to Authenticate in the IKE_INTERMEDIATE Exchange Messages
図1：IKE_INTERMEDIATE Exchangeメッセージで認証するデータ
Figure 1 illustrates the layout of the IntAuth_[i/r]*A (denoted as A) and the IntAuth_[i/r]*P (denoted as P) chunks in case the Encrypted payload is not empty.
図1は、暗号化されたペイロードが空になっていない場合に、intauth_ [i/r]*a（aとして示される）およびintauth_ [i/r]*p（p（pとして示される）チャンクのレイアウトを示しています。
For the purpose of prf calculation, the Length field in the IKE Header and the Payload Length field in the Encrypted payload header are adjusted so that they don't count the lengths of Initialization Vector, Integrity Checksum Data, Padding, and Pad Length fields. In other words, the Length field in the IKE Header (denoted as Adjusted Length in Figure 1) is set to the sum of the lengths of IntAuth_[i/ r]*A and IntAuth_[i/r]*P, and the Payload Length field in the Encrypted payload header (denoted as Adjusted Payload Length in Figure 1) is set to the length of IntAuth_[i/r]*P plus the size of the Encrypted payload header (four octets).
PRF計算を目的として、IKEヘッダーの長さフィールドと暗号化されたペイロードヘッダーのペイロード長フィールドは、初期化ベクトル、整合性チェックサムデータ、パディング、およびパッドの長さフィールドの長さをカウントしないように調整されます。言い換えれば、IKEヘッダーの長さフィールド（図1の調整された長さとして表）は、intauth_ [i/ r]*aおよびintauth_ [i/ r]*pの長さの合計とペイロードに設定されます。暗号化されたペイロードヘッダーの長さフィールド（図1の調整されたペイロード長として表）は、INTAUTH_ [I/R]*Pの長さに設定され、暗号化されたペイロードヘッダー（4オクテット）のサイズに設定されます。
The prf calculations MUST be applied to whole messages only, before possible IKE fragmentation. This ensures that the IntAuth will be the same regardless of whether or not IKE fragmentation takes place. If the message was received in fragmented form, it MUST be reconstructed before calculating the prf as if it were received unfragmented. While reconstructing, the RESERVED field in the reconstructed Encrypted payload header MUST be set to the value of the RESERVED field in the Encrypted Fragment payload header from the first fragment (with the Fragment Number field set to 1).
PRF計算は、IKEの断片化の可能性がある前に、メッセージ全体にのみ適用する必要があります。これにより、Ikeの断片化が行われるかどうかに関係なく、Intauthが同じになることが保証されます。メッセージが断片化された形式で受信された場合、PRFを計算する前に再構築する前に再構築する必要があります。再構築中、再構築された暗号化されたペイロードヘッダーの予約済みフィールドは、最初のフラグメントから（フラグメント番号フィールドを1に設定して）、暗号化されたフラグメントペイロードヘッダーの予約フィールドの値に設定する必要があります。
Note that it is possible to avoid actual reconstruction of the message by incrementally calculating prf on decrypted (or ready to be encrypted) fragments. However, care must be taken to properly replace the content of the Next Header and the Length fields so that the result of computing the prf is the same as if it were computed on the reconstructed message.
復号化された（または暗号化される可能性がある）フラグメントでPRFを徐々に計算することにより、メッセージの実際の再構築を回避することが可能であることに注意してください。ただし、PRFを計算した結果が再構築されたメッセージで計算された場合と同じように、次のヘッダーと長さフィールドのコンテンツを適切に交換するように注意する必要があります。
Each calculation of IntAuth_[i/r]* uses its own keys SK_p[i/r]*, which are the most recently updated SK_p[i/r] keys available before the corresponded IKE_INTERMEDIATE exchange is started. The first IKE_INTERMEDIATE exchange always uses the SK_p[i/r] keys that were computed in the IKE_SA_INIT exchange as SK_p[i/r]1. If the first IKE_INTERMEDIATE exchange performs additional key exchange resulting in an SK_p[i/r] update, then these updated SK_p[i/r] keys are used as SK_p[i/r]2; otherwise, the original SK_p[i/r] keys are used, and so on. Note that if keys are updated, then for any given IKE_INTERMEDIATE exchange, the keys SK_e[i/r] and SK_a[i/r] used for protection of its messages (see Section 3.3.1) and the key SK_p[i/r] for its authentication are always from the same generation.
intauth_ [i/r]*の各計算は、対応するIKE_intermediate Exchangeが開始される前に利用可能な最近更新されたSK_P [I/R]キーである独自のキーSK_P [I/R]*を使用します。最初のike_intermediate Exchangeは、ike_sa_init ExchangeでSK_P [I/R] 1として計算されたSK_P [I/R]キーを常に使用します。最初のike_intermediate Exchangeが追加のキーエクスチェンジを実行してSK_P [I/R]アップデートを実行すると、これらの更新されたSK_P [I/R]キーはSK_P [I/R] 2として使用されます。それ以外の場合、元のSK_P [I/R]キーが使用されます。キーが更新されている場合、特定のIKE_INTERMEDIATE EXCHENDSについて、キーSK_E [I/R]およびSK_A [I/R]がメッセージの保護に使用されること（セクション3.3.1を参照）とキーSK_P [I/R]]その認証は常に同じ世代のものです。
Since messages of the IKE_INTERMEDIATE exchange are not authenticated until the IKE_AUTH exchange successfully completes, possible errors need to be handled with care. There is a trade-off between providing better diagnostics of the problem and risk of becoming part of a DoS attack. Sections 2.21.1 and 2.21.2 of [RFC7296] describe how errors are handled in initial IKEv2 exchanges; these considerations are also applied to the IKE_INTERMEDIATE exchange with the qualification that not all error notifications may appear in the IKE_INTERMEDIATE exchange (for example, errors concerning authentication are generally only applicable to the IKE_AUTH exchange).
IKE_INTERMEDIATEEST Exchangeのメッセージは、IKE_AUTH Exchangeが正常に完了するまで認証されていないため、可能なエラーを注意して処理する必要があります。問題のより良い診断とDOS攻撃の一部になるリスクを提供することとの間にトレードオフがあります。[RFC7296]のセクション2.21.1および2.21.2は、初期のIKEV2交換でのエラーの処理方法について説明します。これらの考慮事項は、すべてのエラー通知がIKE_INTERMEDIATE Exchangeに表示されるわけではないという資格とともに、IKE_INTERMEDIATEエクスチェンジにも適用されます（たとえば、認証に関するエラーは一般にIKE_AUTH Exchangeにのみ適用されます）。
The IKE_INTERMEDIATE exchanges MAY be used during the IKEv2 Session Resumption [RFC5723] between the IKE_SESSION_RESUME and the IKE_AUTH exchanges. To be able to use it, peers MUST negotiate support for Intermediate Exchange by including INTERMEDIATE_EXCHANGE_SUPPORTED notifications in the IKE_SESSION_RESUME messages. Note that a flag denoting whether peers supported the IKE_INTERMEDIATE exchange is not stored in the resumption ticket and is determined each time from the IKE_SESSION_RESUME exchange.
ike_intermediate交換は、ike_session_resumeとIKE_AUTH交換の間のIKEV2セッション再開[RFC5723]で使用できます。それを使用できるようにするには、ピアはIKE_SESSION_RESUMEメッセージにIntermediate_Exchange_Supported通知を含めることにより、中間交換のサポートを交渉する必要があります。ピアがike_intermediate Exchangeをサポートしているかどうかを示すフラグは、再開チケットに保存されず、ike_session_resume Exchangeから毎回決定されることに注意してください。
The data that is transferred by means of the IKE_INTERMEDIATE exchanges is not authenticated until the subsequent IKE_AUTH exchange is complete. However, if the data is placed inside the Encrypted payload, then it is protected from passive eavesdroppers. In addition, the peers can be certain that they receive messages from the party they performed the IKE_SA_INIT exchange with if they can successfully verify the Integrity Checksum Data of the Encrypted payload.
IKE_INTERMEDIATE Exchangesによって転送されるデータは、後続のIKE_AUTH Exchangeが完了するまで認証されません。ただし、データが暗号化されたペイロード内に配置されている場合、パッシブ盗聴者から保護されます。さらに、ピアは、暗号化されたペイロードの整合性チェックサムデータを正常に確認できる場合、IKE_SA_INIT Exchangeを実行したパーティーからメッセージを受信することを確認できます。
The main application for the Intermediate Exchange is to transfer large amounts of data before an IKE SA is set up, without causing IP fragmentation. For that reason, it is expected that IKE fragmentation will be employed in IKE_INTERMEDIATE exchanges in most cases. Section 5 of [RFC7383] contains security considerations for IKE fragmentation.
中間交換の主なアプリケーションは、IP断片化を引き起こすことなく、IKE SAがセットアップされる前に大量のデータを転送することです。そのため、ほとんどの場合、IKE_INTERMEDIATE EXTCANESでIKEの断片化が採用されることが予想されます。[RFC7383]のセクション5には、IKE断片化に関するセキュリティ上の考慮事項が含まれています。
Since authentication of peers occurs only in the IKE_AUTH exchange, a malicious initiator may use the Intermediate Exchange to mount a DoS attack on the responder. In this case, it starts creating an IKE SA, negotiates using the Intermediate Exchanges, and transfers a lot of data to the responder that may also require computationally expensive processing. Then, it aborts the SA establishment before the IKE_AUTH exchange. Specifications utilizing the Intermediate Exchange MUST NOT allow an unlimited number of these exchanges to take place at the initiator's discretion. It is recommended that these specifications be defined in such a way that the responder would know (possibly via negotiation with the initiator) the exact number of these exchanges that need to take place. In other words, after the IKE_SA_INIT exchange is complete, it is preferred that both the initiator and the responder know the exact number of IKE_INTERMEDIATE exchanges they have to perform; it is possible that some IKE_INTERMEDIATE exchanges are optional and are performed at the initiator's discretion, but if a specification defines optional use of IKE_INTERMEDIATE, then the maximum number of these exchanges must be hard capped by the corresponding specification. In addition, [RFC8019] provides guidelines for the responder of how to deal with DoS attacks during IKE SA establishment.
ピアの認証はIKE_AUTH Exchangeでのみ発生するため、悪意のあるイニシエーターは中間交換を使用してResponderにDOS攻撃を行うことができます。この場合、IKE SAの作成を開始し、中間交換を使用して交渉し、計算上の高価な処理も必要とする可能性のある多くのデータをレスポンダーに転送します。その後、IKE_AUTH Exchangeの前にSA施設を中止します。中間交換を利用する仕様は、これらの交換の無制限の数をイニシエーターの裁量で行うことを許可してはなりません。これらの仕様は、レスポンダーが（おそらくイニシエーターとの交渉を介して）、行う必要があるこれらの交換の正確な数を知るような方法で定義することをお勧めします。言い換えれば、IKE_SA_INIT交換が完了した後、イニシエーターとレスポンダーの両方が、実行しなければならないIKE_INTERMEDIATE Exchangeの正確な数を知っていることが推奨されます。一部のIKE_INTERMEDIATEED EXTERAGEはオプションであり、イニシエーターの裁量で実行される可能性がありますが、仕様がike_intermediateのオプションの使用を定義する場合、これらの交換の最大数は対応する仕様によってハードキャップされなければなりません。さらに、[RFC8019]は、IKE SAの設立中にDOS攻撃に対処する方法のレスポンダーに関するガイドラインを提供します。
Note that if an attacker was able to break the key exchange in real time (e.g., by means of a quantum computer), then the security of the IKE_INTERMEDIATE exchange would degrade. In particular, such an attacker would be able to both read data contained in the Encrypted payload and forge it. The forgery would become evident in the IKE_AUTH exchange (provided the attacker cannot break the employed authentication mechanism), but the ability to inject forged IKE_INTERMEDIATE exchange messages with a valid Integrity Check Value (ICV) would allow the attacker to mount a DoS attack. Moreover, in this situation, if the negotiated PRF was not secure against a second preimage attack with known key, then the attacker could forge the IKE_INTERMEDIATE exchange messages without later being detected in the IKE_AUTH exchange. To do this, the attacker would find the same IntAuth_[i/r]* value for the forged message as for the original.
攻撃者がキーエクスチェンジをリアルタイムで（たとえば、量子コンピューターによって）破壊できた場合、IKE_INTERMEDIATE Exchangeのセキュリティが低下することに注意してください。特に、そのような攻撃者は、暗号化されたペイロードに含まれるデータを読み取り、それを偽造することができます。偽造はIKE_AUTH Exchangeで明らかになります（攻撃者が採用された認証メカニズムを破ることができない場合）が、Forged IKE_INTERMEDIATE Exchangeメッセージを有効な整合性チェック値（ICV）で注入する能力により、攻撃者はDOS攻撃を取り付けることができます。さらに、この状況では、ネゴシエートされたPRFが既知のキーを使用した2回目のプリイメージ攻撃に対して安全でない場合、攻撃者はIKE_AUTH Exchangeで後で検出されることなくIKE_INTERMEDIATE Exchangeメッセージを偽造できます。これを行うために、攻撃者は、オリジナルと同じ鍛造メッセージの同じintauth_ [i/r]*値を見つけます。
This document defines a new Exchange Type in the "IKEv2 Exchange Types" registry:
このドキュメントでは、「IKEV2 Exchangeタイプ」レジストリの新しいExchangeタイプを定義します。
+=======+==================+===========+
| Value | Exchange Type | Reference |
+=======+==================+===========+
| 43 | IKE_INTERMEDIATE | RFC 9242 |
+-------+------------------+-----------+
Table 1: IKEv2 Exchange Types
表1：IKEV2交換タイプ
This document also defines a new Notify Message Type in the "IKEv2 Notify Message Types - Status Types" registry:
このドキュメントでは、「IKEV2通知メッセージタイプ - ステータスタイプ」レジストリの新しい通知メッセージタイプも定義します。
+=======+=================================+===========+
| Value | NOTIFY MESSAGES - STATUS TYPES | Reference |
+=======+=================================+===========+
| 16438 | INTERMEDIATE_EXCHANGE_SUPPORTED | RFC 9242 |
+-------+---------------------------------+-----------+
Table 2: IKEv2 Notify Message Types - Status Types
表2：IKEV2メッセージタイプの通知 - ステータスタイプ
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P.、およびT. Kivinen、「インターネットキー交換プロトコルバージョン2（IKEV2）」、STD 79、RFC 7296、DOI 10.17487/RFC7296、2014年10月、<https://www.rfc-editor.org/info/rfc7296>。
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, <https://www.rfc-editor.org/info/rfc7383>.
[RFC7383] Smyslov、V。、「インターネットキー交換プロトコルバージョン2（IKEV2）メッセージフラグメンテーション」、RFC 7383、DOI 10.17487/RFC7383、2014年11月、<https://www.rfc-editor.org/info/rfc7383>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, DOI 10.17487/RFC5282, August 2008, <https://www.rfc-editor.org/info/rfc5282>.
[RFC5282] Black、D。およびD. McGrew、「Internet Key Exchangeバージョン2（IKEV2）プロトコルの暗号化されたペイロードを使用した認証された暗号化アルゴリズムを使用して」、RFC 5282、DOI 10.17487/RFC5282、2008年8月、<HTTPS：//www.rfc-editor.org/info/rfc5282>。
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, DOI 10.17487/RFC5723, January 2010, <https://www.rfc-editor.org/info/rfc5723>.
[RFC5723] Sheffer、Y。およびH. Tschofenig、「Internet Key Exchange Protocolバージョン2（IKEV2）セッション再開」、RFC 5723、DOI 10.17487/RFC5723、2010年1月、<https：//www.rfc-editor.org/情報/RFC5723>。
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/RFC6928, April 2013, <https://www.rfc-editor.org/info/rfc6928>.
[RFC6928] Chu、J.、Dukkipati、N.、Cheng、Y.、およびM. Mathis、「TCPの初期ウィンドウの増加」、RFC 6928、DOI 10.17487/RFC6928、2013年4月、<https：//www.rfc-editor.org/info/rfc6928>。
[RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks", RFC 8019, DOI 10.17487/RFC8019, November 2016, <https://www.rfc-editor.org/info/rfc8019>.
[RFC8019] NIR、Y。およびV. SMYSLOV、「分散拒否拒否攻撃からのインターネットキーエクスチェンジプロトコル2（IKEV2）の実装の保護」、RFC 8019、DOI 10.17487/RFC8019、2016年11月、<https：//www.rfc-editor.org/info/rfc8019>。
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[RFC8229] Pauly、T.、Touati、S。、およびR. Mantha、「IKEおよびIPSECパケットのTCPカプセル化」、RFC 8229、DOI 10.17487/RFC8229、2017年8月、<https：//www.rfc-editor。org/info/rfc8229>。
Appendix A. Example of IKE_INTERMEDIATE Exchange
付録A. ike_intermediate Exchangeの例
This appendix contains an example of the messages using IKE_INTERMEDIATE exchanges. This appendix is purely informative; if it disagrees with the body of this document, the other text is considered correct.
この付録には、ike_intermediate取引所を使用したメッセージの例が含まれています。この付録は純粋に有益です。このドキュメントの本文に同意しない場合、他のテキストは正しいと見なされます。
In this example, there is one IKE_SA_INIT exchange and two IKE_INTERMEDIATE exchanges, followed by the IKE_AUTH exchange to authenticate all initial exchanges. The xxx in the HDR(xxx,MID=yyy) indicates the Exchange Type, and yyy indicates the Message ID used for that exchange. The keys used for each SK {} payload are indicated in the parenthesis after the SK. Otherwise, the payload notation is the same as is used in [RFC7296].
この例では、1つのIKE_SA_INIT Exchangeと2つのIKE_INTERMEDIATE Exchangeがあり、その後にIKE_AUTH Exchangeが続き、すべての初期交換を認証します。HDR（xxx、mid = yyy）のxxxは交換タイプを示し、yyyはその交換に使用されるメッセージIDを示します。各SK {}ペイロードに使用されるキーは、SKの後に括弧内に示されています。それ以外の場合、ペイロード表記は[RFC7296]で使用されるのと同じです。
Initiator Responder
----------- -----------
HDR(IKE_SA_INIT,MID=0),
SAi1, KEi, Ni,
N(INTERMEDIATE_EXCHANGE_SUPPORTED) -->
<-- HDR(IKE_SA_INIT,MID=0), SAr1, KEr, Nr, [CERTREQ], N(INTERMEDIATE_EXCHANGE_SUPPORTED)
<-hdr（ike_sa_init、mid = 0）、sar1、ker、nr、[certreq]、n（intermediate_exchange_supported）
At this point, peers calculate SK_* and store them as SK_*1. SK_e[i/ r]1 and SK_a[i/r]1 will be used to protect the first IKE_INTERMEDIATE exchange, and SK_p[i/r]1 will be used for its authentication.
この時点で、ピアはsk_*を計算し、それらをsk_* 1として保存します。SK_E [I/R] 1およびSK_A [I/R] 1は、最初のIKE_INTERMEDIATE Exchangeを保護するために使用され、SK_P [I/R] 1は認証に使用されます。
Initiator Responder
----------- -----------
HDR(IKE_INTERMEDIATE,MID=1),
SK(SK_ei1,SK_ai1) {...} -->
<Calculate IntAuth_i1 = prf(SK_pi1, ...)>
<-- HDR(IKE_INTERMEDIATE,MID=1),
SK(SK_er1,SK_ar1) {...}
<Calculate IntAuth_r1 = prf(SK_pr1, ...)>
If the SK_*1 keys are updated (e.g., as a result of a new key exchange) after completing this IKE_INTERMEDIATE exchange, then the peers store the updated keys as SK_*2; otherwise, they use SK_*1 as SK_*2. SK_e[i/r]2 and SK_a[i/r]2 will be used to protect the second IKE_INTERMEDIATE exchange, and SK_p[i/r]2 will be used for its authentication.
このike_intermediate Exchangeを完了した後、SK_*1キーが更新された場合（たとえば、新しいキー交換の結果として）、ピアは更新されたキーをSK_ 2として保存します。それ以外の場合、SK_ 1をSK_*2として使用します。SK_E [I/R] 2およびSK_A [I/R] 2は、2番目のIKE_INTERMEDIATE Exchangeを保護するために使用され、SK_P [I/R] 2は認証に使用されます。
Initiator Responder
----------- -----------
HDR(IKE_INTERMEDIATE,MID=2),
SK(SK_ei2,SK_ai2) {...} -->
<Calculate IntAuth_i2 = prf(SK_pi2, ...)>
<-- HDR(IKE_INTERMEDIATE,MID=2),
SK(SK_er2,SK_ar2) {...}
<Calculate IntAuth_r2 = prf(SK_pr2, ...)>
If the SK_*2 keys are updated (e.g., as a result of a new key exchange) after completing the second IKE_INTERMEDIATE exchange, then the peers store the updated keys as SK_*3; otherwise, they use SK_*2 as SK_*3. SK_e[i/r]3 and SK_a[i/r]3 will be used to protect the IKE_AUTH exchange, SK_p[i/r]3 will be used for authentication, and SK_d3 will be used for derivation of other keys (e.g., for Child SAs).
Sk_*2キーが2番目のIKE_INTERMEDIATE Exchangeを完了した後にSK_ 2キーが更新された場合（たとえば、新しいキーエクスチェンジの結果として）、ピアは更新されたキーをSK_ 3として保存します。それ以外の場合、SK_ 2をSK_*3として使用します。SK_E [I/R] 3およびSK_A [I/R] 3はIKE_AUTH Exchangeを保護するために使用されます。SK_P[I/R] 3は認証に使用され、SK_D3は他のキーの導出に使用されます（例えば、子SASの場合）。
Initiator Responder
----------- -----------
HDR(IKE_AUTH,MID=3),
SK(SK_ei3,SK_ai3)
{IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr} -->
<-- HDR(IKE_AUTH,MID=3),
SK(SK_er3,SK_ar3)
{IDr, [CERT,] AUTH, SAr2, TSi, TSr}
In this example, two IKE_INTERMEDIATE exchanges took place; therefore, SK_*3 keys would be used as SK_* keys for further cryptographic operations in the context of the created IKE SA, as defined in [RFC7296].
この例では、2つのike_intermediate取引所が行われました。したがって、[RFC7296]で定義されているように、SK_* 3キーは、作成されたIKE SAのコンテキストでさらに暗号化操作のためのSK_*キーとして使用されます。
Acknowledgements
謝辞
The idea to use an Intermediate Exchange between the IKE_SA_INIT and IKE_AUTH exchanges was first suggested by Tero Kivinen. He also helped to write the example IKE_INTERMEDIATE exchange shown in Appendix A. Scott Fluhrer and Daniel Van Geest identified a possible problem with authentication of the IKE_INTERMEDIATE exchange and helped to resolve it. The author is grateful to Tobias Brunner, who raised good questions concerning authentication of the IKE_INTERMEDIATE exchange and proposed how to make the size of authentication chunks constant regardless of the number of exchanges. The author is also grateful to Paul Wouters and Benjamin Kaduk, who suggested a lot of text improvements for the document.
IKE_SA_INITとIKE_AUTH交換の間の中間交換を使用するというアイデアは、最初にTero Kivinenによって提案されました。彼はまた、付録Aに示されているIKE_インターメディーエクスチェンジの例を書くのを手伝いました。ScottFlurerとDaniel Van Geestは、IKE_INTERMEDIATE Exchangeの認証に関する問題を特定し、それを解決するのに役立ちました。著者はTobias Brunnerに感謝しています。TobiasBrunnerは、IKE_INTERMEDIATE Exchangeの認証に関する良い質問を提起し、取引所の数に関係なく認証チャンクのサイズを一定にする方法を提案しました。著者は、ポール・ウーターズとベンジャミン・カドゥクにも感謝しています。
Author's Address
著者の住所
Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation Phone: +7 495 276 0211 Email: svan@elvis.ru
Valery Smyslov Elvis-Plus PO Box 81 Moscow（Zelenograd）124460ロシア連邦電話：7 495 276 0211メール：svan@elvis.ru