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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
新しい安全なパスワードの方法は、二つのサーバやルータ間の認証には、例えば、使用されることを意図しています。これらのシナリオは、通常は対称ではない：両方のピアは共有の秘密を知って、何のバックエンド認証サーバが関与しており、どちらかの端がIKEv2の接続を開始することができます。対称的に実行可能なEAP方式が使用され、そしてEAPメソッドを直接両方のピア上に実装されないAAAが使用されていない場合、そのようなモデルはまた、EAPによってサポートすることができることに留意されたいです。
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.
多くの場合、各実装が提案されている安全なパスワード認証方式の一つだけを使用しますが、それらの一方のみが使用されますでも、複数のメソッドのサポートを含めることができます。例えば、汎用オペレーティングシステムの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 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.
安全なパスワードの方法は、主に既存のIKEv2 IKE_SA_INIT交換を維持し、IKE_AUTH認証ステップを変更します。これらの方法は、新たなラウンドトリップ、IKE_SA_INIT中に発生するニーズを使用するための安全なパスワード方式の交渉を追加したくないので。もう一方の端のアイデンティティが唯一IKE_AUTHの内部に設けられている通り、レスポンダはイニシエータのみのIPアドレスに基づいて、サポートされている方法のリストを選択する必要があります。唯一の特定の方法は、ある特定されたピアのために許容可能である場合、これは問題につながる可能性があります。認証が両方のピアとの間で共有される秘密に基づいて行われているように幸いなことに、共有秘密は、方法の全てにおいて使用可能であるべきです。このように、リモートピアは通常、イニシエータのアイデンティティに基づく方法の選択を制限する必要はありませんが、サポートされる唯一の方法と管理ポリシーに基づいて。
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％）。これは、16がすでに使用されているうちそのうち95の使用可能な番号を、残します。最初は、それは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交換を修正するので、使用する安全なパスワードの方法の交渉は、IKE_SA_INIT交換中に発生する必要があります。安全なパスワードの交渉交換は次のようになります。
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ペイロードを変更することが可能かもしれないとして、交渉の最終結果として、我々が使用される正確に一つの安全なパスワードの方法を持っている方がよいです。イニシエータは、レスポンダに話したときに使用可能などの方法を知っているだろう、そうイニシエータは、その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フィールドが空になることを意味し、ゼロになります。通知メッセージタイプは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交換を変更することがあります。簡単に複数のメソッドを実装可能にするために、IKE_AUTH交換が不必要に変更しないことをお勧めします。 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交換は、最初の要求は、IDI、SAI2、をTSiとTSR、およびGSPMペイロードをいくつか含まれていることを意味し、EAPを使用した場合のようになります。応答が再びIDRと、GSPMペイロードの数を含める必要があります。各々がGSPMペイロードのいくつかの数からなる、複数の交換があってもよいです。認証が完了したとき、最後に、AUTH、SAR2、をTSiとTSR、およびGSPMペイロードの一部の数を要求（GSPMペイロードの一部番号と共に）AUTHペイロードを含み、応答に含まれる1つの最終交換がなければなりません。 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ペイロードの計算は、通常、安全なパスワード方式によって必要な追加データに加えて、含まれることになるすべてのデータを含める必要があります。安全なパスワード方式は、AUTHペイロードを計算する方法を定義する必要があります。
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ペイロード計算が変更されるように、安全なペイロード方法は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、フラグ：イニシエータ、メッセージ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、フラグ：応答、メッセージ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、フラグ：イニシエータ、メッセージ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]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン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.シェファー、 "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]伸、S.とK. Kobara、「ほとんどの効率的な拡張パスワードのみの認証およびIKEv2のための鍵交換」、進歩、2011年7月での作業。
[SPSK-AUTH] Harkins, D., "Secure PSK Authentication for IKE", Work in Progress, July 2011.
[SPSK-AUTH]ハーキンズ、D.、進歩、2011年7月における作業 "IKEのためにPSK認証をセキュア"。
Author's Address
著者のアドレス
Tero Kivinen AuthenTec Eerikinkatu 28 HELSINKI FI-00180 Finland
TERO Kivinen AuthenTecのEerikinkatu 28 FI-00180フィンランドヘルシンキ
EMail: kivinen@iki.fi
メールアドレス：kivinen@iki.fi