[要約] RFC 6467は、IKEv2のための安全なパスワードフレームワークを提供し、認証のセキュリティを向上させることを目的としています。
Internet Engineering Task Force (IETF) T. Kivinen
Request for Comments: 6467 AuthenTec
Category: Informational December 2011
ISSN: 2070-1721
Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)
インターネットキーエクスチェンジバージョン2の安全なパスワードフレームワーク（IKEV2）
Abstract
概要
This document defines a generic way for Internet Key Exchange version 2 (IKEv2) to use any of the symmetric secure password authentication methods. Multiple methods are already specified in other documents, and this document does not add any new one. This document specifies a way to agree on which method is to be used in the current connection. This document also provides a common way to transmit, between peers, payloads that are specific to secure password authentication methods.
このドキュメントでは、インターネットキーエクスチェンジバージョン2（IKEV2）が対称的な安全なパスワード認証方法を使用する一般的な方法を定義しています。他のドキュメントでは複数のメソッドがすでに指定されており、このドキュメントでは新しいドキュメントは追加されていません。このドキュメントは、現在の接続で使用する方法について同意する方法を指定します。また、このドキュメントは、パスワード認証方法を保護するために固有のペアロードを送信するための一般的な方法を提供します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc6467.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6467で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Method Negotiation ..............................................4
3. Generic Secure Password Method Payload ..........................6
4. IKE_AUTH Exchange ...............................................7
5. Security Considerations .........................................9
6. IANA Considerations .............................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
The IPsecME working group was chartered to provide for IKEv2 ([RFC5996]) a symmetric secure password authentication protocol that supports the use of low-entropy shared secrets, and to protect against off-line dictionary attacks without requiring the use of certificates or the Extensible Authentication Protocol (EAP). There are multiple such methods, and the working group was to pick one. Unfortunately, the working group failed to pick one protocol, and there are multiple candidates going forward as separate documents. As each of those older versions of those documents used a different technique to negotiate the use of the method and also used different payload formats, it is very hard to try to make an implementation where multiple such systems could co-exist.
IPSECMEワーキンググループは、IKEV2（[RFC5996]）を提供するためにチャーターされました。認証プロトコル（EAP）。そのような方法は複数あり、ワーキンググループは1つを選択することでした。残念ながら、ワーキンググループは1つのプロトコルを選択することができず、別のドキュメントとして今後複数の候補者がいます。これらのドキュメントのこれらの古いバージョンのそれぞれは、メソッドの使用を交渉するために異なる手法を使用し、異なるペイロード形式を使用したため、複数のそのようなシステムが共存できる実装を作成しようとするのは非常に困難です。
Current document versions ([SPSK-AUTH], [PACE], and [PAKE]) use the method described in this document.
現在のドキュメントバージョン（[spsk-auth]、[pace]、および[pake]）は、このドキュメントで説明されている方法を使用します。
This document describes IKEv2 payload formats that can be used for multiple secure password methods to negotiate and transmit data so each different method can easily co-exist in the same implementation.
このドキュメントでは、複数の安全なパスワードメソッドに使用してデータをネゴシエートおよび送信するために使用できるIKEV2ペイロード形式について説明します。
This document consists of two major parts:
このドキュメントは、2つの主要な部分で構成されています。
o How to negotiate which secure password method negotiation is used.
o どの安全なパスワード方法交渉が使用されるかを交渉する方法。
o How to transmit data, between peers, that is specific to secure password methods.
o ピア間でデータを送信する方法は、パスワードメソッドの保護に固有のものです。
The secure password methods are not usually meant to be used in the normal end user (remote access VPN) cases. In such cases, EAP-based authentication works fine, and the asymmetric nature of EAP does not matter. In such scenarios, the authentication is usually backed up with the back-end Authentication, Authorization, and Accounting (AAA) servers and other infrastructure. That is, in such scenarios, neither of the IKEv2 peers really knows the secret, as on one end it is typed in by the user when it is needed, and on the other end it is authenticated by the back-end AAA server.
安全なパスワードメソッドは、通常、通常のエンドユーザー（リモートアクセスVPN）ケースで使用されることを意図していません。そのような場合、EAPベースの認証は正常に機能し、EAPの非対称性は重要ではありません。このようなシナリオでは、認証は通常、バックエンド認証、承認、会計（AAA）サーバーおよびその他のインフラストラクチャでバックアップされます。つまり、そのようなシナリオでは、IKEV2ピアのどちらも秘密を実際に知らないことです。一方の端では、必要なときにユーザーによって入力され、他方でバックエンドAAAサーバーによって認証されます。
The new secure password methods are meant to be used, for example, in the authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either end can initiate an IKEv2 connection. Note that such a model could also be supported by EAP when an EAP method that can run in symmetric fashion is in use, and the EAP method is directly implemented on both peers and no AAA is in use.
新しいセキュアパスワードメソッドは、たとえば2つのサーバーまたはルーター間の認証で使用されることを目的としています。これらのシナリオは通常対称です。両方のピアは共有秘密を知っており、バックエンド認証サーバーは関与していません。このようなモデルは、対称的に実行できるEAPメソッドが使用されている場合、EAPによってもサポートされ、EAPメソッドは両方のピアに直接実装され、AAAは使用されていないことに注意してください。
In many cases, each implementation will use only one of the proposed secure password authentication methods but can include support for multiple methods even when only one of them will be used. For example, a general-purpose operating system running IPsec and IKEv2 and supporting secure password authentication methods to protect services provided by the system might need to implement support for several methods. It is then up to the administrator which one is to be used. As the server might need to connect to multiple other servers, each implementing a different set of methods, it may not be possible to pick one method that would serve all cases.
多くの場合、各実装では、提案された安全なパスワード認証方法の1つのみを使用しますが、それらの1つだけが使用される場合でも、複数の方法のサポートを含めることができます。たとえば、IPSECとIKEV2を実行し、システムが提供するサービスを保護するための安全なパスワード認証方法をサポートする汎用オペレーティングシステムは、いくつかの方法のサポートを実装する必要がある場合があります。その後、どの使用者が使用されるかが管理者次第です。サーバーは、他の複数のサーバーに接続する必要があるため、それぞれが異なるメソッドセットを実装しているため、すべてのケースに対応する1つのメソッドを選択することはできない場合があります。
The secure password methods mostly keep the existing IKEv2 IKE_SA_INIT exchange and modify the IKE_AUTH authentication step. As those methods do not want to add new round trips, negotiating which of the secure password methods to use needs to happen during the IKE_SA_INIT. As the identity of the other end is only provided inside IKE_AUTH, the responder needs to select the list of supported methods based only on the IP address of the initiator. This could lead to problems if only certain methods would be acceptable for certain identified peers. Fortunately, as the authentication is done based on the secret shared between both peers, the shared secret should be usable in all of the methods; thus, a remote peer usually
安全なパスワードメソッドは、主に既存のIKEV2 IKE_SA_INIT Exchangeを保持し、IKE_AUTH認証ステップを変更します。これらの方法では新しいラウンド旅行を追加したくないため、IKE_SA_INIT中に使用する安全なパスワード方法を交渉する必要があります。もう一方の端の身元はIKE_AUTH内でのみ提供されるため、レスポンダーは、イニシエーターのIPアドレスのみに基づいてサポートされているメソッドのリストを選択する必要があります。特定の特定のピアで特定の方法のみが受け入れられる場合、これは問題につながる可能性があります。幸いなことに、認証は両方のピア間で共有される秘密に基づいて行われるため、共有された秘密はすべての方法で使用できるはずです。したがって、通常、リモートピア
does not need to restrict selection of the method based on the initiator's identity but only based on the supported methods and the administrative policy.
イニシエーターのIDに基づいてメソッドの選択を制限する必要はありませんが、サポートされている方法と管理ポリシーにのみ基づいています。
Also, as the initiator already knows which peer it is connecting with, it can limit which methods it proposes to the other peer. And as secure password methods are meant to be used in symmetric cases, both ends should have similar configuration; i.e., they have the same shared secret and, most likely, also a list of acceptable authentication methods to be used. This could also be interpreted so that there is no need to support method negotiation, as both ends can already see this from the configuration. On the other hand, in most cases, either end does not really care which method is used but is willing to use any secure method that the other end supports. In such cases, the automatic negotiation provides a way to make the configuration easy, i.e., no need to pick one method to be used between the peers.
また、イニシエーターは、どのピアと接続しているかをすでに知っているため、他のピアに提案する方法を制限できます。また、安全なパスワードメソッドは対称性の場合に使用されることを意図しているため、両端は同様の構成が必要です。つまり、それらは同じ共有秘密を持っており、おそらく、使用する許容可能な認証方法のリストもあります。これは、メソッドネゴシエーションをサポートする必要がないように解釈することもできます。一方、ほとんどの場合、いずれかの端はどの方法を使用するかを実際には気にしませんが、他方の端がサポートする安全な方法を使用する意思があります。そのような場合、自動交渉は、構成を簡単にする方法を提供します。つまり、ピア間で使用する1つの方法を選択する必要はありません。
The reason for using the common IKEv2 payload to transmit, between peers, data that is specific to the secure password method is that the payload type field in the IKEv2 is only an 8-bit field, and 62.5% of the range is already reserved (50% to the private use numbers, and 12.5% to the IKEv1 payload numbers). This leaves 95 usable numbers, out of which 16 are already in use. Initially, it was proposed that five payload type numbers be consumed. Those five new payload types would already represent a 31% increase in the number of currently allocated payload types.
一般的なIKEV2ペイロードを使用して、ピア間で、安全なパスワード方法に固有のデータを送信する理由は、IKEV2のペイロードタイプフィールドが8ビットフィールドのみであり、範囲の62.5％がすでに予約されているためです（プライベート使用数の50％、IKEV1ペイロード番号の12.5％）。これにより、95の使用可能な数字が残り、そのうち16はすでに使用されています。当初、5つのペイロードタイプ数を消費することが提案されていました。これらの5つの新しいペイロードタイプは、現在割り当てられているペイロードタイプの数が31％増加することをすでに表しています。
Because all of the methods modify the IKE_AUTH exchange, the negotiation of the secure password method to be used needs to happen during the IKE_SA_INIT exchange. The secure password negotiation exchange would be:
すべての方法がIKE_AUTH Exchangeを変更するため、使用する安全なパスワード方法の交渉は、IKE_SA_INIT Exchange中に発生する必要があります。安全なパスワード交渉交換は次のとおりです。
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=0, IKE_SA_INIT,
Flags: Initiator, Message ID=0),
SAi1, KEi, Ni, [N(SECURE_PASSWORD_METHODS)] -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT,
Flags: Response, Message ID=0),
SAr1, KEr, Nr, [CERTREQ],
[N(SECURE_PASSWORD_METHODS)]
If the N(SECURE_PASSWORD_METHODS) Notify payload is missing, then normal IKEv2 authentication methods are used. If the Notify payloads are included, then the negotiation of the secure password methods happens inside those payloads.
n（secure_password_methods）通知ペイロードが欠落している場合、通常のIKEV2認証方法が使用されます。通知のペイロードが含まれている場合、安全なパスワードメソッドの交渉はそれらのペイロード内で発生します。
As it might be possible that future secure password methods will modify the IKE_AUTH payload in a more substantial way, it is better that as an end result of the negotiation we have exactly one secure password method that will be used. The initiator will know which methods are usable when talking to that responder, so the initiator will send a list of acceptable methods in its IKE_SA_INIT request. The responder will pick exactly one method and put that in its response.
将来の安全なパスワードメソッドがIKE_AUTHペイロードをより実質的な方法で変更する可能性があるため、ネゴシエーションの最終結果として、使用される安全なパスワードメソッドが1つだけあることが優れています。イニシエーターは、そのレスポンダーと話すときに使用可能な方法を知っているため、イニシエーターはIKE_SA_INITリクエストで許容可能なメソッドのリストを送信します。レスポンダーは正確に1つの方法を選択し、それをその応答に入れます。
The secure password methods are identified by the 16-bit IANA-allocated numbers stored in the Notify payload notification data field. If a method supports multiple different password preprocessing methods, each of those may be allocated a separate number from this space, or the method might do its own negotiation of the preprocessing method later. As the initiator has already selected the shared secret it will be using, it will also know which preprocessing it might need, so it should propose only those preprocessing methods suitable for the selected shared secret. This means that it is recommended that separate IANA numbers be allocated for different preprocessing methods.
安全なパスワードメソッドは、通知ペイロード通知データフィールドに保存されている16ビットIANAに割り当てられた数値によって識別されます。メソッドが複数の異なるパスワード前処理方法をサポートする場合、それらのそれぞれにこのスペースから個別の数字を割り当てるか、メソッドが後で前処理方法の独自の交渉を行う可能性があります。イニシエーターは、使用する共有秘密をすでに選択しているため、どの前処理が必要かがわかっているため、選択した共有秘密に適した前処理方法のみを提案する必要があります。これは、異なる前処理方法に個別のIANA番号を割り当てることをお勧めすることを意味します。
The actual Notify payload will look like this:
実際の通知のペイロードは次のようになります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol ID will be zero, and the SPI Size will also be zero, meaning that the SPI field will be empty. The Notify Message Type will be 16424.
プロトコルIDはゼロになり、SPIサイズもゼロになります。つまり、SPIフィールドは空になります。Notifyメッセージタイプは16424になります。
The Notification Data contains the list of the 16-bit secure password method numbers:
通知データには、16ビットの安全なパスワード方法番号のリストが含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secure Password Method #1 | Secure Password Method #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secure Password Method #3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The response Notify payload contains exactly one 16-bit secure password method number inside the Notification Data field.
応答通知ペイロードには、通知データフィールド内に1つの16ビットの安全なパスワードメソッド番号が含まれています。
This payload will contain the data that is specific to the secure password payload. The IKE_AUTH exchanges might have a number of these inside, depending on what is required and specified by the secure password method. As the secure password method is already selected during IKE_SA_INIT, there is no need to repeat the information of the selected secure password method; thus, this payload only contains the method-specific data. As some secure password methods require multiple different payloads, they are assumed to include their method-specific payload type inside the payload -- for example, inside the first octet of the data. However, this is method-specific, and a method is free to format the payload data as it wants.
このペイロードには、安全なパスワードペイロードに固有のデータが含まれます。IKE_AUTH交換には、安全なパスワード方法で必要なものと指定されているものに応じて、これらの内部がいくつかある場合があります。IKE_SA_INITでは、安全なパスワードメソッドが既に選択されているため、選択したセキュアパスワードメソッドの情報を繰り返す必要はありません。したがって、このペイロードにはメソッド固有のデータのみが含まれています。一部の安全なパスワードメソッドには複数の異なるペイロードが必要であるため、データの最初のオクテット内には、ペイロード内にメソッド固有のペイロードタイプを含めると想定されています。ただし、これはメソッド固有であり、メソッドは必要に応じてペイロードデータを自由にフォーマットできます。
The Generic Secure Password Method (GSPM) payload will look like this:
ジェネリックセキュアパスワードメソッド（GSPM）ペイロードは次のようになります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Data Specific to the Secure Password Method ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Payload Type for this payload is 49, and the name used in this document is "GSPM payload."
このペイロードのペイロードタイプは49で、このドキュメントで使用される名前は「GSPMペイロード」です。
If the method uses payload subtypes (which are specific to the secure password method) inside the GSPM payload, the format will be like this:
メソッドがGSPMペイロード内でペイロードサブタイプ（安全なパスワードメソッドに固有）を使用する場合、形式は次のようになります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype* | |
+-+-+-+-+-+-+-+-+ +
| |
~ Data Specific to the Secure Password Method ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* method-specific subtype field
* メソッド固有のサブタイプフィールド
This representation is here only for illustrative purposes; the secure password method will define the exact format of the payload contents.
この表現は、説明のためにのみここにあります。安全なパスワードメソッドは、ペイロードコンテンツの正確な形式を定義します。
As the negotiation takes place during IKE_SA_INIT, the secure password methods may modify the IKE_AUTH exchange if needed. To easily enable implementing multiple methods, it is recommended that IKE_AUTH exchange not be modified unnecessarily. Adding zero, one, or multiple GSPM payloads to each exchange is needed, as is the modification to how the AUTH payload is calculated, but all other changes should be kept minimal.
IKE_SA_INIT中に交渉が行われるため、安全なパスワードメソッドは、必要に応じてIKE_AUTH Exchangeを変更する場合があります。複数の方法を簡単に実装できるようにするには、IKE_AUTH Exchangeを不必要に変更しないことをお勧めします。AUTHペイロードの計算方法の変更と同様に、各交換にゼロ、1つ、または複数のGSPMペイロードを追加する必要がありますが、他のすべての変更を最小限に抑える必要があります。
The IKE_AUTH exchange should look similar to when EAP is used, meaning that the first request includes IDi, SAi2, TSi, TSr, and some number of GSPM payloads. The response should include IDr and, again, a number of GSPM payloads. There may be multiple exchanges, each consisting of some number of GSPM payloads; finally, when authentication is done, there should be one final exchange where the request includes the AUTH payload (along with some number of GSPM payloads) and the response contains AUTH, SAr2, TSi, TSr, and some number of GSPM payloads. The number of GSPM payloads is up to the secure password method but usually will be less than 3. However, depending on the method, it might be more.
IKE_AUTH Exchangeは、EAPが使用される場合と同様に見える必要があります。つまり、最初の要求にはIDI、SAI2、TSI、TSR、およびいくつかのGSPMペイロードが含まれます。応答には、IDRと再び、多くのGSPMペイロードが含まれている必要があります。複数の交換があり、それぞれがいくつかのGSPMペイロードで構成されています。最後に、認証が完了した場合、リクエストにAUTHペイロード（いくつかのGSPMペイロードとともに）を含む最後の交換が1つあり、応答にはAuth、SAR2、TSI、TSR、およびいくつかのGSPMペイロードが含まれています。GSPMペイロードの数は安全なパスワード方法次第ですが、通常は3未満になります。ただし、メソッドによっては、それ以上の場合があります。
The AUTH payload calculation should include all the data that would normally be included, in addition to the extra data needed by the secure password method. The secure password method needs to define how the AUTH payload is calculated.
Auth Payload計算には、安全なパスワード方法で必要な追加データに加えて、通常含まれるすべてのデータを含める必要があります。安全なパスワード方法は、認証ペイロードの計算方法を定義する必要があります。
As the AUTH payload calculation is changed, the secure payload method should not use any of the existing authentication method numbers in the AUTH Payload Auth Method field but instead should use the number allocated in this document. This number is meant to be used by all secure password authentication methods.
Auth Payload計算が変更されるため、Secure Payloadメソッドは、Auth Payload Authメソッドメソッドフィールドの既存の認証メソッド番号を使用しないでください。代わりに、このドキュメントで割り当てられた数値を使用する必要があります。この番号は、すべての安全なパスワード認証方法で使用されることを意図しています。
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1),
SK {IDi, [CERTREQ,]
GSPM, [GSPM, ...,]
[IDr,] SAi2,
TSi, TSr} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1),
SK {IDr, [CERT,]
GSPM, [GSPM, ...]}
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=2),
SK {GSPM, [GSPM, ...,]} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=2),
SK {GSPM, [GSPM, ...]}
...
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=x),
SK {[GSPM, ...,], AUTH} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=x),
SK {[GSPM, ...,] AUTH, SAr2,
TSi, TSr}
Note that the number of the GSPM payloads and other payloads in each packet will be defined only by the secure password method documentation, and representations in this document are only for illustrative purposes.
各パケットのGSPMペイロードおよびその他のペイロードの数は、安全なパスワードメソッドドキュメントによってのみ定義されることに注意してください。このドキュメントの表現は、説明のみを目的としています。
As this document does not describe an exact protocol, the security considerations are not relevant. Any secure password method documentation using payload types described here needs to also describe the security properties of the protocol it defines or discusses.
このドキュメントは正確なプロトコルを説明していないため、セキュリティ上の考慮事項は関連していません。ここで説明するペイロードタイプを使用した安全なパスワードメソッドドキュメントは、定義または議論するプロトコルのセキュリティプロパティも説明する必要があります。
This document allocates one new IKEv2 message type in the "Notify Messages Types - Status Types" registry:
このドキュメントは、「メッセージタイプの通知 - ステータスタイプ」レジストリに1つの新しいIKEV2メッセージタイプを割り当てます。
16424 SECURE_PASSWORD_METHODS
16424 secure_password_methods
This document also allocates one new number in the "IKEv2 Authentication Method" registry:
このドキュメントは、「IKEV2認証方法」レジストリに1つの新しい番号を割り当てます。
12 Generic Secure Password Authentication Method
12一般的な安全なパスワード認証方法
This document also adds one new payload type to the "IKEv2 Payload Types" registry:
このドキュメントでは、「IKEV2ペイロードタイプ」レジストリに1つの新しいペイロードタイプを追加します。
49 Generic Secure Password Method GSPM
49ジェネリックセキュアパスワードメソッドGSPM
This document creates a new IANA registry -- "IKEv2 Secure Password Methods":
このドキュメントは、新しいIANAレジストリを作成します - 「IKEV2セキュアパスワードメソッド」：
0 Reserved
0予約
Values 1-1023 are unassigned. Values 1024-65535 are for private use among mutually consenting parties. Changes and additions to this registry are done by Expert Review.
値1-1023は割り当てられていません。値1024-65535は、相互に同意する当事者の間で私的に使用するためのものです。このレジストリの変更と追加は、専門家のレビューによって行われます。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン2（IKEV2）」、RFC 5996、2010年9月。
[PACE] Kuegler, D. and Y. Sheffer, "Password Authenticated Connection Establishment with IKEv2", Work in Progress, September 2011.
[Pace] Kuegler、D。およびY. Sheffer、「IKEV2とのパスワード認証接続確立」、2011年9月に進行中の作業。
[PAKE] Shin, S. and K. Kobara, "Most Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2", Work in Progress, July 2011.
[Pake] Shin、S。およびK. Kobara、「最も効率的なパスワードのみの認証とIKEV2の重要な交換」は、2011年7月に進行中です。
[SPSK-AUTH] Harkins, D., "Secure PSK Authentication for IKE", Work in Progress, July 2011.
[SPSK-Auth] Harkins、D。、「IKEのSecure PSK Authentication」、2011年7月の作業。
Author's Address
著者の連絡先
Tero Kivinen AuthenTec Eerikinkatu 28 HELSINKI FI-00180 Finland
Tero Kivinen Aedencec Eerikinkatu 28 Helsinki FI-00180フィンランド
EMail: kivinen@iki.fi