[要約] RFC 7619は、IKEv2におけるNULL認証メソッドについての仕様です。目的は、認証の必要性がない場合にセキュアな通信を確立するための方法を提供することです。
Internet Engineering Task Force (IETF) V. Smyslov
Request for Comments: 7619 ELVIS-PLUS
Updates: 4301 P. Wouters
Category: Standards Track Red Hat
ISSN: 2070-1721 August 2015
The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)
インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）のNULL認証方法
Abstract
概要
This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for Internet Key Exchange Protocol version 2 (IKEv2). This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity.
このドキュメントでは、インターネット認証交換プロトコルバージョン2（IKEv2）のNULL認証方法とID_NULL識別ペイロードIDタイプを指定します。これにより、2つのIKEピアが、ピアが自分自身を認証または識別したくない、またはできない場合の使用例に対して、片側の認証済みまたは相互の非認証IKEセッションを確立できます。これにより、IKEv2を日和見セキュリティ（日和見暗号化とも呼ばれます）に使用して、匿名性を犠牲にすることなくPervasive Monitoring攻撃を防ぐことができます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7619.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7619で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Using the NULL Authentication Method . . . . . . . . . . . . 4
2.1. Authentication Payload . . . . . . . . . . . . . . . . . 4
2.2. Identification Payload . . . . . . . . . . . . . . . . . 4
2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . 5
2.4. Interaction with the Peer Authorization Database (PAD) . 5
2.5. Traffic Selectors . . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
3.1. Audit Trail and Peer Identification . . . . . . . . . . . 7
3.2. Resource Management and Robustness . . . . . . . . . . . 8
3.3. IKE Configuration Selection . . . . . . . . . . . . . . . 8
3.4. Networking Topology Changes . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . 9
5.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Update of PAD processing in RFC 4301 . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Internet Key Exchange Protocol version 2 (IKEv2), specified in [RFC7296], provides a way for two parties to perform an authenticated key exchange. While the authentication methods used by the peers can be different, there is no method for one or both parties to remain unauthenticated and anonymous. This document extends the authentication methods to support unauthenticated and anonymous IKE sessions.
[RFC7296]で指定されているインターネットキーエクスチェンジプロトコルバージョン2（IKEv2）は、2つのパーティが認証されたキー交換を実行する方法を提供します。ピアが使用する認証方法は異なる場合がありますが、一方または両方の当事者が認証されずに匿名のままでいる方法はありません。このドキュメントでは、認証方法を拡張して、認証されていない匿名のIKEセッションをサポートします。
In some situations, mutual authentication is undesirable, superfluous, or impossible. The following three examples illustrate these unauthenticated use cases:
状況によっては、相互認証が望ましくない、不必要、または不可能である場合があります。次の3つの例は、これらの認証されていない使用例を示しています。
o A user wants to establish an anonymous secure connection to a server. In this situation, the user should be able to authenticate the server without presenting or authenticating to the server with their own identity. This case uses a single-sided authentication of the responder.
o ユーザーがサーバーへの匿名の安全な接続を確立したいと考えています。この状況では、ユーザーはサーバーに自分のIDを提示したり認証したりすることなく、サーバーを認証できる必要があります。このケースでは、レスポンダの片面認証を使用します。
o A sensor that periodically wakes up from a suspended state wants to send a measurement (e.g., temperature) to a collecting server. The sensor must be authenticated by the server to ensure authenticity of the measurement, but the sensor does not need to authenticate the server. This case uses a single-sided authentication of the initiator.
o 一時停止状態から定期的にウェイクアップするセンサーは、測定値（温度など）を収集サーバーに送信したいと考えています。測定の信頼性を確保するために、センサーはサーバーによって認証される必要がありますが、センサーはサーバーを認証する必要はありません。このケースでは、イニシエーターの片側認証を使用します。
o Two peers without any trust relationship wish to defend against widespread pervasive monitoring attacks as described in [RFC7258]. Without a trust relationship, the peers cannot authenticate each other. Opportunistic Security [RFC7435] states that unauthenticated encrypted communication is preferred over cleartext communication. The peers want to use IKE to setup an unauthenticated encrypted connection that gives them protection against pervasive monitoring attacks. An attacker that is able and willing to send packets can still launch a man-in-the-middle (MITM) attack to obtain a copy of the unencrypted communication. This case uses a fully unauthenticated key exchange.
o [RFC7258]で説明されているように、信頼関係のない2つのピアは、広範囲にわたる広範囲にわたる監視攻撃から防御したいと考えています。信頼関係がないと、ピアは相互に認証できません。 Opportunistic Security [RFC7435]は、認証されていない暗号化通信がクリアテキスト通信よりも優先されると述べています。ピアは、IKEを使用して、広範囲にわたる監視攻撃に対する保護を提供する認証されていない暗号化接続をセットアップしたいと考えています。パケットを送信する能力があり、喜んで攻撃者が中間者（MITM）攻撃を仕掛けて、暗号化されていない通信のコピーを取得する可能性があります。このケースでは、完全に認証されていないキー交換を使用します。
To meet these needs, this document introduces the NULL Authentication method and the ID_NULL ID type. This allows an IKE peer to explicitly indicate that it is unwilling or unable to certify its identity.
これらのニーズを満たすために、このドキュメントではNULL認証方式とID_NULL IDタイプを紹介しています。これにより、IKEピアは、アイデンティティを証明する意思がない、または証明できないことを明示的に示すことができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
In IKEv2, each peer independently selects the method to authenticate itself to the other side. A peer may choose to refrain from authentication by using the NULL Authentication method. If a host's local policy requires that the identity of its peer be (non-null) authenticated, and if that host receives an AUTH payload containing the NULL Authentication method type, it MUST return an AUTHENTICATION_FAILED notification. If an initiator uses the Extensible Authentication Protocol (EAP), the responder MUST NOT use the NULL Authentication method (in conformance with Section 2.16 of [RFC7296]).
IKEv2では、各ピアは、相手側に対して自身を認証する方法を個別に選択します。ピアは、NULL認証メソッドを使用して認証を控えることを選択できます。ホストのローカルポリシーで、ピアのIDが（null以外の）認証を受ける必要があり、そのホストがNULL認証メソッドタイプを含むAUTHペイロードを受信した場合、AUTHENTICATION_FAILED通知を返す必要があります。イニシエーターが拡張認証プロトコル（EAP）を使用する場合、レスポンダーはNULL認証方法を使用してはなりません（[RFC7296]のセクション2.16に準拠）。
NULL authentication affects how the Authentication and the Identification payloads are formed in the IKE_AUTH exchange.
NULL認証は、IKE AUTH交換での認証ペイロードと識別ペイロードの形成方法に影響します。
NULL authentication still requires a properly formed AUTH payload to be present in the IKE_AUTH exchange messages, as the AUTH payload cryptographically links the IKE_SA_INIT exchange messages with the other messages sent over this IKE Security Association (SA).
AUTHペイロードはIKE_SA_INIT交換メッセージをこのIKE Security Association（SA）経由で送信される他のメッセージと暗号でリンクするため、NULL認証では、適切に形成されたAUTHペイロードがIKE_AUTH交換メッセージに存在する必要があります。
When using NULL authentication, the content of the AUTH payload is computed using the syntax of pre-shared secret authentication, described in Section 2.15 of [RFC7296]. The value of SK_pi for the initiator and SK_pr for the responder is used as the shared secret for the content of the AUTH payload. Implementers should note this means that authentication keys used by the two peers are different in each direction. This is identical to how the contents of the two last AUTH payloads are generated for the non-key-generating EAP methods (see Section 2.16 of [RFC7296] for details).
NULL認証を使用する場合、AUTHペイロードのコンテンツは、[RFC7296]のセクション2.15で説明されている事前共有秘密認証の構文を使用して計算されます。イニシエーターのSK_piとレスポンダーのSK_prの値は、AUTHペイロードのコンテンツの共有シークレットとして使用されます。実装者は、これは、2つのピアが使用する認証キーが各方向で異なることを意味することに注意する必要があります。これは、最後の2つのAUTHペイロードの内容が非キー生成EAPメソッドに対して生成される方法と同じです（詳細については、[RFC7296]のセクション2.16を参照してください）。
The IKEv2 Authentication Method value for NULL Authentication is 13.
NULL認証のIKEv2認証方式の値は13です。
When a remote peer is not authenticated, any ID presented in the Identification Data field of the ID payload cannot be validated. To avoid the need of sending a bogus ID Type with placeholder data, this specification defines a new ID Type, ID_NULL. The Identification Data field of the ID payload for this ID Type MUST be empty.
リモートピアが認証されていない場合、IDペイロードのIdentification Dataフィールドに表示されるIDは検証できません。プレースホルダーデータと共に偽のIDタイプを送信する必要を回避するために、この仕様では新しいIDタイプID_NULLを定義しています。このIDタイプのIDペイロードの識別データフィールドは空でなければなりません。
If NULL authentication is in use and anonymity is a concern, then ID_NULL SHOULD be used in the Identification payload. Some examples of cases where a non-null identity type and value with NULL authentication can be used are logging, troubleshooting, and in scenarios where authentication takes place out of band after the IKE SA is created (like in [AUTOVPN]). The content of the Identification payload MUST NOT be used for any trust and policy checking in IKE_AUTH exchange when NULL authentication is employed (see Section 2.4 for details).
NULL認証が使用されており、匿名性が懸念される場合は、IDペイロードでID_NULL SHOULDを使用する必要があります。 NULL認証の非null IDタイプと値を使用できるケースのいくつかの例は、ロギング、トラブルシューティング、およびIKE SAの作成後に帯域外で認証が行われるシナリオ（[AUTOVPN]など）です。識別ペイロードの内容は、NULL認証が採用されている場合のIKE_AUTH交換での信頼およびポリシーチェックに使用してはなりません（詳細については、セクション2.4を参照）。
ID_NULL is primarily intended to be used with NULL authentication but could be used in other situations where the content of the Identification payload is not used. For example, ID_NULL could be used when authentication is performed via raw public keys and the identities are the keys themselves. These alternative uses of ID_NULL should be described in their own respective documents.
ID_NULLは、主にNULL認証で使用することを目的としていますが、IDペイロードのコンテンツが使用されない他の状況でも使用できます。たとえば、ID_NULLは、生の公開鍵を介して認証が実行され、ID自体が鍵である場合に使用できます。 ID_NULLのこれらの代替使用法は、それぞれのドキュメントで説明する必要があります。
The IKEv2 Identification Payload ID Type for ID_NULL is 13.
ID_NULLのIKEv2識別ペイロードIDタイプは13です。
The identity of a peer using NULL authentication cannot be used to find existing IKE SAs created by the same peer, as the peer identity is not authenticated. For that reason, the INITIAL_CONTACT notifications MUST NOT be used to delete any other IKE SAs based on the same peer identity without additional verification that the existing IKE SAs with matching identity are actually stale.
ピアIDは認証されないため、NULL認証を使用するピアのIDを使用して、同じピアによって作成された既存のIKE SAを見つけることはできません。そのため、一致するIDを持つ既存のIKE SAが実際に古くなっているという追加の検証なしに、INITIAL_CONTACT通知を使用して、同じピアIDに基づく他のIKE SAを削除することはできません。
The standard IKE Liveness Check procedure, described in Section 2.4 of [RFC7296], can be used to detect stale IKE SAs created by peers using NULL authentication. Inactive, unauthenticated IKE SAs should be checked periodically. Additionally, the event of creating a new unauthenticated IKE SA can be used to trigger an out-of-order check on existing unauthenticated IKE SAs possibly limited to identical or close-by IP addresses or to identical identities of the just created IKE SA.
[RFC7296]のセクション2.4で説明されている標準のIKE活性チェック手順を使用して、NULL認証を使用するピアによって作成された古いIKE SAを検出できます。非アクティブで認証されていないIKE SAは定期的にチェックする必要があります。さらに、新しい非認証IKE SAを作成するイベントを使用して、既存の非認証IKE SAの順序が乱れたチェックをトリガーできます。これは、同一または近接IPアドレス、または作成したばかりのIKE SAの同一IDに制限される可能性があります。
Implementations should weigh the resource consumption of sending Liveness Checks against the memory usage of possible orphaned IKE SAs. Implementations may choose to handle situations with thousands of unauthenticated IKE SAs differently from situations with very few such SAs.
実装では、生存チェックを送信するリソース消費と、孤立したIKE SAのメモリ使用量を比較検討する必要があります。実装では、認証されていない数千のIKE SAがある状況を、そのようなSAが非常に少ない状況とは異なる方法で処理することを選択できます。
Section 4.4.3 of [RFC4301] defines the Peer Authorization Database (PAD), which provides the link between the Security Policy Database (SPD) and IKEv2. The PAD contains an ordered list of records with peers' identities along with corresponding authentication data and Child SA authorization data. When the IKE SA is being established, the PAD is consulted to determine how the peer should be authenticated and what Child SAs it is authorized to create.
[RFC4301]のセクション4.4.3は、ピア認証データベース（PAD）を定義しています。これは、セキュリティポリシーデータベース（SPD）とIKEv2の間のリンクを提供します。 PADには、対応する認証データと子SA承認データとともに、ピアのIDを含むレコードの順序付きリストが含まれています。 IKE SAが確立されると、PADが参照され、ピアの認証方法と、ピアの作成が許可されている子SAが決定されます。
When using NULL authentication, the peer identity is not authenticated and cannot be trusted. If ID_NULL is used with NULL authentication, there is no ID at all. The processing of the PAD described in Section 4.4.3 of [RFC4301] is updated for NULL authentication as follows.
NULL認証を使用する場合、ピアIDは認証されず、信頼できません。 ID_NULLがNULL認証で使用される場合、IDはまったくありません。 [RFC4301]のセクション4.4.3で説明されているPADの処理は、NULL認証用に次のように更新されています。
NULL authentication is added as one of the supported authentication methods. This method does not have any authentication data. ID_NULL is included into the list of allowed ID types. The matching rule for ID_NULL consists only of whether this type is used, i.e., no actual ID matching is done as ID_NULL contains no identity data.
サポートされている認証方法の1つとしてNULL認証が追加されました。このメソッドには認証データがありません。 ID_NULLは、許可されるIDタイプのリストに含まれています。 ID_NULLの一致ルールは、このタイプが使用されているかどうかのみで構成されます。つまり、ID_NULLにはIDデータが含まれていないため、実際のIDの一致は行われません。
When using the NULL Authentication method, those matching rules MUST include matching of a new flag in the SPD entry specifying whether unauthenticated users are allowed to use that entry. That is, each SPD entry needs to be augmented to have a flag specifying whether it can be used with NULL authentication or not, and only those rules that explicitly have that flag turned on can be used with unauthenticated connections.
NULL認証方式を使用する場合、これらの一致ルールには、認証されていないユーザーがそのエントリを使用できるかどうかを指定するSPDエントリの新しいフラグの一致を含める必要があります。つまり、各SPDエントリは、NULL認証で使用できるかどうかを指定するフラグを持つように拡張する必要があり、そのフラグが明示的にオンになっているルールのみが非認証接続で使用できます。
The specific updates of text in Section 4.4.3 of [RFC4301] are listed in Appendix A.
[RFC4301]のセクション4.4.3のテキストの具体的な更新は、付録Aにリストされています。
Traffic Selectors and narrowing allow two IKE peers to mutually agree on a traffic range for an IPsec SA. An unauthenticated peer must not be allowed to use this mechanism to steal traffic that an IKE peer intended to be for another host. This is especially problematic when supporting anonymous IKE peers behind NAT, as such IKE peers build an IPsec SA using their pre-NAT IP address that is different from the source IP of their IKE packets. A rogue IKE peer could use malicious Traffic Selectors to trick a remote host into giving it IP traffic that the remote host never intended to be sent to remote IKE peers. For example, if the remote host uses 192.0.2.1 as the DNS server, a rogue IKE peer could set its Traffic Selector to 192.0.2.1 in an attempt to receive the remote peer's DNS traffic. Implementations SHOULD restrict and isolate all anonymous IKE peers from each other and itself and only allow it access to itself and possibly its intended network ranges.
トラフィックセレクターとナローイングにより、2つのIKEピアがIPsec SAのトラフィック範囲について相互に合意できます。認証されていないピアは、このメカニズムを使用して、IKEピアが別のホストを対象としたトラフィックを盗むことを許可してはなりません。 NATの背後にある匿名のIKEピアをサポートする場合、IKEパケットのソースIPとは異なるNAT前のIPアドレスを使用してIPsec SAを構築するため、これは特に問題になります。不正なIKEピアは、悪意のあるトラフィックセレクターを使用して、リモートホストをだまして、リモートホストがリモートIKEピアに送信することを意図していないIPトラフィックを与えます。たとえば、リモートホストがDNSサーバーとして192.0.2.1を使用している場合、不正なIKEピアは、リモートピアのDNSトラフィックを受信しようとして、そのトラフィックセレクターを192.0.2.1に設定できます。実装は、すべての匿名IKEピアを相互およびそれ自体から制限および分離し、それ自体および場合によってはその意図されたネットワーク範囲へのアクセスのみを許可する必要があります（SHOULD）。
One method to achieve this is to always assign internal IP addresses to unauthenticated IKE clients, as described in Section 2.19 of [RFC7296]. Implementations may also use other techniques such as internal NAT and connection tracking.
これを実現する1つの方法は、[RFC7296]のセクション2.19で説明されているように、認証されていないIKEクライアントに常に内部IPアドレスを割り当てることです。実装では、内部NATや接続追跡などの他の手法も使用できます。
Implementations MAY force unauthenticated IKE peers to single host-to-host IPsec SAs. When using IPv6, this is not always possible, so implementations MUST be able to assign a full /64 address block to the peer as described in [RFC5739], even if it is not authenticated.
実装は、認証されていないIKEピアを単一のホスト間IPsec SAに強制する場合があります。 IPv6を使用する場合、これは常に可能であるとは限らないため、[RFC5739]で説明されているように、実装は完全な/ 64アドレスブロックをピアに割り当てることができなければなりません（認証されていない場合でも）。
If authenticated IKE sessions are possible for a certain Traffic Selector range between the peers, then unauthenticated IKE SHOULD NOT be allowed for that Traffic Selector range. When mixing authenticated and unauthenticated IKE with the same peer, policy rules should ensure the highest level of security will be used to protect the communication between the two peers. See [RFC7435] for details.
認証されたIKEセッションがピア間の特定のトラフィックセレクター範囲で可能である場合、認証されていないIKEはそのトラフィックセレクター範囲で許可されるべきではありません。認証されたIKEと認証されていないIKEを同じピアで混在させる場合、ポリシールールは、2つのピア間の通信を保護するために最高レベルのセキュリティが使用されるようにする必要があります。詳細については、[RFC7435]を参照してください。
If both peers use NULL authentication, the entire key exchange becomes unauthenticated. This makes the IKE session vulnerable to active MITM attacks.
両方のピアがNULL認証を使用する場合、キー交換全体が認証されなくなります。これにより、IKEセッションがアクティブなMITM攻撃に対して脆弱になります。
Using an ID Type other than ID_NULL with the NULL Authentication method may compromise the client's anonymity in case of an active MITM attack.
NULL認証方式でID_NULL以外のIDタイプを使用すると、アクティブなMITM攻撃の場合にクライアントの匿名性が損なわれる可能性があります。
IKE implementations without NULL authentication have always performed mutual authentication and were not designed for use with unauthenticated IKE peers. Implementations might have made assumptions that remote peers are identified. With NULL authentication, these assumptions are no longer valid. Furthermore, the host itself might have made trust assumptions or may not be aware of the network topology changes that resulted from IPsec SAs from unauthenticated IKE peers.
NULL認証のないIKE実装は常に相互認証を実行しており、認証されていないIKEピアで使用するようには設計されていません。実装では、リモートピアが識別されていると想定されている場合があります。 NULL認証では、これらの前提は無効になります。さらに、ホスト自体が信頼を前提としている場合や、認証されていないIKEピアからのIPsec SAに起因するネットワークトポロジの変更を認識していない場合があります。
With NULL authentication, an established IKE session is no longer guaranteed to provide a verifiable (authenticated) entity known to the system or network. Any logging of unproven ID payloads that were not authenticated should be clearly marked and treated as "untrusted" and possibly accompanied by logging the remote IP address of the IKE session. Rate limiting of logging might be required to prevent excessive resource consumption causing system damage.
NULL認証では、確立されたIKEセッションは、システムまたはネットワークに認識されている検証可能な（認証された）エンティティを提供することが保証されなくなります。認証されなかった証明されていないIDペイロードのロギングはすべて明確にマークされ、「信頼できない」ものとして扱われ、IKEセッションのリモートIPアドレスのロギングも伴う可能性があります。システムの損傷を引き起こす過度のリソース消費を防ぐために、ロギングのレート制限が必要になる場合があります。
Section 2.6 of [RFC7296] provides guidance for mitigation of denial-of-service (DoS) attacks by issuing COOKIES in response to resource consumption of half-open IKE SAs. Furthermore, [DDOS-PROTECTION] offers additional countermeasures in an attempt to distinguish attacking IKE packets from legitimate IKE peers.
[RFC7296]のセクション2.6は、ハーフオープンIKE SAのリソース消費に応じてCOOKIESを発行することにより、サービス拒否（DoS）攻撃を軽減するためのガイダンスを提供します。さらに、[DDOS-PROTECTION]は、攻撃しているIKEパケットを正当なIKEピアから区別するための追加の対策を提供します。
These defense mechanisms do not take into account IKE systems that allow unauthenticated IKE peers. An attacker using NULL authentication is a fully legitimate IKE peer that is only distinguished from authenticated IKE peers by having used NULL authentication.
これらの防御メカニズムでは、認証されていないIKEピアを許可するIKEシステムは考慮されません。 NULL認証を使用する攻撃者は完全に正当なIKEピアであり、NULL認証を使用したことによって認証済みIKEピアとのみ区別されます。
Implementers that implement NULL authentication should ensure their implementation does not make any assumptions that depend on IKE peers being "friendly", "trusted", or "identifiable". While implementations should have been written to account for abusive authenticated clients, any omission or error in handling abusive clients may have gone unnoticed because abusive clients have been a rare or nonexistent problem. When adding support for unauthenticated IKE peers, these implementation omissions and errors will be found and abused by attackers. For example, an unauthenticated IKE peer could send an abusive amount of Liveness probes or Delete requests.
NULL認証を実装する実装者は、IKEピアが「フレンドリ」、「信頼できる」、または「識別可能」であることに依存する想定を実装が行わないようにする必要があります。悪用される認証済みクライアントを考慮して実装を作成する必要がありましたが、悪用されるクライアントがまれまたは存在しない問題であったため、悪用されるクライアントの処理の省略やエラーが気付かれなかった可能性があります。認証されていないIKEピアのサポートを追加すると、これらの実装の省略やエラーが見つかり、攻撃者によって悪用されます。たとえば、認証されていないIKEピアが、大量の活性プローブまたは削除要求を送信する可能性があります。
Combining authenticated and unauthenticated IKE peers on a single host can be dangerous, assuming the authenticated IKE peer gains more or different access from unauthenticated peers (otherwise, why not only allow unauthenticated peers). An unauthenticated IKE peer MUST NOT be able to reach resources only meant for authenticated IKE peers and MUST NOT be able to replace the Child SAs of an authenticated IKE peer.
認証されたIKEピアが認証されていないピアからより多くのまたは異なるアクセスを取得すると想定すると、認証されたIKEピアと認証されていないIKEピアを組み合わせることは危険です（そうでない場合、認証されていないピアのみを許可しない理由）認証されていないIKEピアは、認証されたIKEピア専用のリソースに到達できてはならず、認証されたIKEピアの子SAを置き換えることはできません。
When a host relies on packet filters or firewall software to protect itself, establishing an IKE SA and installing an IPsec SA might accidentally circumvent these packet filters and firewall restrictions, as the Encapsulating Security Payload (ESP, protocol 50) or ESPinUDP (UDP port 4500) packets of the encrypted traffic do not match the packet filters defined for unencrypted traffic. IKE peers supporting unauthenticated IKE MUST pass all decrypted traffic through the same packet filters and security mechanisms as incoming plaintext traffic.
ホストが自身を保護するためにパケットフィルターまたはファイアウォールソフトウェアに依存している場合、IKE SAを確立してIPsec SAをインストールすると、カプセル化セキュリティペイロード（ESP、プロトコル50）またはESPinUDP（UDPポート4500）として、これらのパケットフィルターとファイアウォールの制限が誤って回避される可能性があります。 ）暗号化されたトラフィックのパケットは、暗号化されていないトラフィック用に定義されたパケットフィルターと一致しません。非認証IKEをサポートするIKEピアは、受信したプレーンテキストトラフィックと同じパケットフィルターとセキュリティメカニズムを介して、すべての復号化されたトラフィックを渡す必要があります。
Per this document, IANA has added a new entry in the "IKEv2 Authentication Method" registry:
このドキュメントに従って、IANAは「IKEv2 Authentication Method」レジストリに新しいエントリを追加しました。
13 NULL Authentication
13 NULL認証
Per this document, IANA has added a new entry in the "IKEv2 Identification Payload ID Types" registry:
このドキュメントに従って、IANAは「IKEv2識別ペイロードIDタイプ」レジストリに新しいエントリを追加しました。
13 ID_NULL
13 ID_NULL
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5739, DOI 10.17487/RFC5739, February 2010, <http://www.rfc-editor.org/info/rfc5739>.
[RFC5739] Eronen、P.、Laganier、J。、およびC. Madson、「IPv6 Configuration in Internet Key Exchange Protocol Version 2（IKEv2）」、RFC 5739、DOI 10.17487 / RFC5739、2010年2月、<http：// www .rfc-editor.org / info / rfc5739>。
[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, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「Internet Key Exchange Protocol Version 2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<http://www.rfc-editor.org/info/rfc7296>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258 >。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見セキュリティ：ほとんどの場合はある程度の保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<http://www.rfc-editor.org/info/rfc7435>。
[AUTOVPN] Sheffer, Y. and Y. Nir, "The AutoVPN Architecture", Work in Progress, draft-sheffer-autovpn-00, February 2014.
[AUTOVPN] Sheffer、Y。およびY. Nir、「AutoVPNアーキテクチャ」、進行中の作業、draft-sheffer-autovpn-00、2014年2月。
[DDOS-PROTECTION] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange (IKE) Implementations from Distributed Denial of Service Attacks", Work in Progress, draft-ietf-ipsecme-ddos-protection-02, July 2015.
[DDOS-PROTECTION] Nir、Y.、V。Smyslov、「分散型サービス拒否攻撃からのインターネットキー交換（IKE）実装の保護」、作業中、draft-ietf-ipsecme-ddos-protection-02、2015年7月。
This appendix lists the specific updates of the text in Section 4.4.3 of [RFC4301] that should be followed when implementing NULL authentication.
この付録には、[RFC4301]のセクション4.4.3に記載されている、NULL認証を実装する際に従う必要のあるテキストの特定の更新がリストされています。
A new item is added to the list of supported ID types in Section 4.4.3.1 of [RFC4301]
[RFC4301]のセクション4.4.3.1のサポートされているIDタイプのリストに新しいアイテムが追加されました
o NULL ID (matches ID type only)
o NULL ID（IDタイプのみに一致）
and the following text is added at the end of the section:
次のテキストがセクションの最後に追加されます。
Added text: The NULL ID type is defined as having no data. For this name type, the matching function is defined as comparing the ID type only.
追加されたテキスト：NULL IDタイプはデータがないと定義されています。この名前タイプの場合、マッチング関数はIDタイプのみを比較するものとして定義されます。
A new item is added to the list of authentication data types in Section 4.4.3.2 of [RFC4301]:
[RFC4301]のセクション4.4.3.2の認証データタイプのリストに新しい項目が追加されました。
- NULL authentication
- NULL認証
and the next paragraph is updated as follows:
次の段落は次のように更新されます。
Old: For authentication based on an X.509 certificate [...] For authentication based on a pre-shared secret, the PAD contains the pre-shared secret to be used by IKE.
旧：X.509証明書に基づく認証の場合[...]事前共有秘密に基づく認証の場合、PADにはIKEが使用する事前共有秘密が含まれています。
New: For authentication based on an X.509 certificate [...] For authentication based on a pre-shared secret, the PAD contains the pre-shared secret to be used by IKE. For NULL authentication the PAD contains no data.
新規：X.509証明書に基づく認証の場合[...]事前共有秘密に基づく認証の場合、PADにはIKEが使用する事前共有秘密が含まれています。 NULL認証の場合、PADにはデータが含まれていません。
In addition, the following text is added at the end of Section 4.4.3.4 of [RFC4301]:
さらに、[RFC4301]のセクション4.4.3.4の最後に次のテキストが追加されます。
Added text: When using the NULL Authentication method, implementations MUST make sure that they do not mix authenticated and unauthenticated SPD rules, i.e., implementations need to keep them separately; for example, by adding a flag in the SPD to tell whether NULL authentication can be used or not for the entry. That is, each SPD entry needs to be augmented to have a flag specifying whether it can be used with NULL authentication or not, and only those rules that explicitly have that flag set can be used with unauthenticated connections.
追加されたテキスト：NULL認証方式を使用する場合、実装では、認証済みのSPDルールと未認証のSPDルールを混在させないようにする必要があります。つまり、実装はそれらを個別に保持する必要があります。たとえば、SPDにフラグを追加して、エントリにNULL認証を使用できるかどうかを示します。つまり、各SPDエントリを拡張して、NULL認証で使用できるかどうかを指定するフラグを設定し、そのフラグセットが明示的に設定されているルールのみを非認証接続で使用できるようにする必要があります。
Acknowledgments
謝辞
The authors would like to thank Yaron Sheffer and Tero Kivinen for their reviews, valuable comments, and contributed text.
著者は、レビュー、貴重なコメント、寄稿文を提供してくれたYaron ShefferとTero Kivinenに感謝します。
Authors' Addresses
著者のアドレス
Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation
Valery Smyslov ELVIS-PLUS PO Boxing 81モスクワ（ゼレノグラード）124460ロシア連邦
Phone: +7 495 276 0211
Email: svan@elvis.ru
Paul Wouters Red Hat
ポール・ウーターズレッドハット
Email: pwouters@redhat.com