Network Working Group M. Nystroem
Request for Comments: 4793 RSA Security
Category: Informational February 2007
The EAP Protected One-Time Password Protocol (EAP-POTP)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document describes a general Extensible Authentication Protocol (EAP) method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens with direct electronic interfaces to their associated clients. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet Key Exchange Protocol Version 2 (IKEv2).
この文書では、ワンタイムパスワード（OTP）トークンと共に使用するための一般的な拡張認証プロトコル（EAP）メソッドは、適切な説明、およびそれらに関連するクライアントに直接電子インタフェースを持つトークンの特定の利点を提供します。この方法は、PPP、IEEE 802.1X、およびインターネット鍵交換プロトコルバージョン2（IKEv2の）としてEAPを利用したプロトコルで、一方的または相互認証、およびキーマテリアルを提供するために使用することができます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Background .................................................4
1.3. Rationale behind the Design ................................4
1.4. Relationship with EAP Methods in RFC 3748 ..................5
2. Conventions Used in This Document ...............................5
3. Authentication Model ............................................5
4. Description of the EAP-POTP Method ..............................6
4.1. Overview ...................................................6
4.2. Version Negotiation ........................................9
4.3. Cryptographic Algorithm Negotiation .......................10
4.4. Session Resumption ........................................11
4.5. Key Derivation and Session Identifiers ....................13
4.6. Error Handling and Result Indications .....................13
4.7. Use of the EAP Notification Method ........................14
4.8. Protection against Brute-Force Attacks ....................14
4.9. MAC Calculations in EAP-POTP ..............................16
4.9.1. Introduction .......................................16
4.9.2. MAC Calculation ....................................16
4.9.3. Message Hash Algorithm .............................16
4.9.4. Design Rationale ...................................17
4.9.5. Implementation Considerations ......................17
4.10. EAP-POTP Packet Format ...................................17
4.11. EAP-POTP TLV Objects .....................................20
4.11.1. Version TLV .......................................20
4.11.2. Server-Info TLV ...................................21
4.11.3. OTP TLV ...........................................23
4.11.4. NAK TLV ...........................................33
4.11.5. New PIN TLV .......................................35
4.11.6. Confirm TLV .......................................38
4.11.7. Vendor-Specific TLV ...............................41
4.11.8. Resume TLV ........................................43
4.11.9. User Identifier TLV ...............................46
4.11.10. Token Key Identifier TLV .........................47
4.11.11. Time Stamp TLV ...................................48
4.11.12. Counter TLV ......................................49
4.11.13. Challenge TLV ....................................50
4.11.14. Keep-Alive TLV ...................................51
4.11.15. Protected TLV ....................................52
4.11.16. Crypto Algorithm TLV .............................54
5. EAP Key Management Framework Considerations ....................57
6. Security Considerations ........................................57
6.1. Security Claims ...........................................57
6.2. Passive and Active Attacks ................................58
6.3. Denial-of-Service Attacks .................................59
6.4. The Use of Pepper .........................................59
6.5. The Race Attack ...........................................60
7. IANA Considerations ............................................60
7.1. General ...................................................60
7.2. Cryptographic Algorithm Identifier Octets .................61
8. Intellectual Property Considerations ...........................61
9. Acknowledgments ................................................61
10. References ....................................................62
10.1. Normative References .....................................62
10.2. Informative References ...................................62
Appendix A. Profile of EAP-POTP for RSA SecurID ...................64
Appendix B. Examples of EAP-POTP Exchanges ........................65
B.1. Basic Mode, Unilateral Authentication .....................65
B.2. Basic Mode, Session Resumption ............................66
B.3. Mutual Authentication without Session Resumption ..........67
B.4. Mutual Authentication with Transfer of Pepper .............69
B.5. Failed Mutual Authentication ..............................70
B.6. Session Resumption ........................................71
B.7. Failed Session Resumption .................................73
B.8. Mutual Authentication, and New PIN Requested ..............75
B.9. Use of Next OTP Mode ......................................78
Appendix C. Use of the MPPE-Send/Receive-Key RADIUS Attributes ....80
C.1. Introduction ..............................................80
C.2. MPPE Key Attribute Population .............................80
Appendix D. Key Strength Considerations ...........................80
D.1. Introduction ..............................................80
D.2. Example 1: 6-Digit One-Time Passwords .....................81
D.3. Example 2: 8-Digit One-Time Passwords .....................81
This document describes an Extensible Authentication Protocol (EAP) [1] method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens that are electronically connected to a user's computer, e.g., through a USB interface. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP [10], IEEE 802.1X [11], and IKEv2 [12].
この文書では、拡張認証プロトコル（EAP）ワンタイムパスワード（OTP）トークンと共に使用するのに適した[1]の方法を説明し、電子的にUSBインタフェースを介して、例えば、ユーザのコンピュータに接続されているトークンの特定の利点を提供します。方法は、PPP [10]、IEEE 802.1X [11]、およびIKEv2の[12]などのEAPを利用するプロトコルでは、一方的または相互認証、鍵材料を提供するために使用することができます。
A One-Time Password (OTP) token may be a handheld hardware device, a hardware device connected to a personal computer through an electronic interface such as USB, or a software module resident on a personal computer, which generates one-time passwords that may be used to authenticate a user towards some service. This document describes an EAP method intended to meet the needs of organizations wishing to use OTP tokens in an interoperable manner to authenticate users over EAP. The method is designed to be independent of particular OTP algorithms and to meet the requirements on modern EAP methods (see [13]).
ワンタイムパスワード（OTP）トークンは、ハンドヘルド、ハードウェアデバイス、例えばUSB等の電子インタフェースを介してパーソナルコンピュータに接続されたハードウェア装置、またはワンタイムパスワードを生成するパーソナルコンピュータ上のソフトウェアモジュール常駐することができることをしてもよいですいくつかのサービスに対する利用者を認証するために使用されます。この文書では、EAPを超えるユーザーを認証するために、相互運用可能な方法でOTPトークンを使用することを希望する企業のニーズを満たすことを意図したEAP方法を説明します。この方法は、特定のOTPアルゴリズムとは無関係であることと（[13]参照）現代のEAPメソッドの要件を満たすように設計されています。
The basic variant of this method provides client authentication only. This mode is only to be used within a secured tunnel. A more advanced variant provides mutual authentication, integrity protection of the exchange, protection against eavesdroppers, and establishment of authenticated keying material. Both variants allow for fast session resumption.
この方法の基本的な変種は、クライアント認証のみを提供します。このモードは、セキュアトンネル内で使用されるべきです。より高度な変形は、相互認証、為替の完全性保護、盗聴者に対する保護、および認証された鍵素材の確立を提供します。両方の変異体は、高速セッション再開を許可します。
While this document also includes a profile of the general method for the RSA SecurID(TM) mechanism, it is described in terms of general constructions. It is therefore intended that the document will also serve as a framework for use with other OTP algorithms.
この文書はまた、RSA SecurIDの（TM）メカニズムのための一般的な方法のプロファイルを含むが、それは一般的な構成の観点から説明されています。したがって、文書はまた、他のOTPアルゴリズムで使用するためのフレームワークとして機能することを意図しています。
Note: The term "OTP" as used herein shall not be confused with the EAP OTP method defined in [1].
注：本明細書で使用する用語「OTP」は、[1]で定義されたEAP OTP方式と混同してはなりません。
EAP-POTP has been designed with the intent that its messages and data elements be easily parsed by EAP implementations. This makes it easier to programmatically use the EAP method in the peer and the authenticator, reducing the need for user interactions and allowing for local generation of user prompts, when needed. In contrast, the Generic Token Card (GTC) method from [1], which uses text strings
EAP-POTPは、そのメッセージおよびデータ要素を容易にEAP実装によって解析されることを意図して設計されています。これは、簡単にプログラムで必要なときに、ユーザーとの対話の必要性を削減し、ユーザープロンプトのローカル世代を可能にし、ピアとオーセンティケータにEAPメソッドを使用することができます。テキスト文字列を使用して、[1]から対照的に、一般的なトークンカード（GTC）法、
generated by the EAP server, is intended to be interpreted and acted upon by humans. Furthermore, EAP-POTP allows for mutual authentication and establishment of keying material, which GTC does not. To retain the generic nature of GTC, the EAP-POTP method has been designed to support a wide range of OTP algorithms, with profiling expected for specific such algorithms. This document provides a profile of EAP-POTP for RSA SecurID tokens.
EAPサーバによって生成され、解釈され、人間によって作用されることを意図しています。また、EAP-POTPは、相互認証及びGTCがない鍵材料の確立を可能にします。 GTCの一般的な性質を保持するために、EAP-POTP方法は、特定のそのようなアルゴリズムのために予想されるプロファイルと、OTPアルゴリズムの広い範囲をサポートするように設計されています。この文書では、RSA SecurIDトークンのためのEAP-POTPのプロファイルを提供します。
The EAP OTP method defined in [1], which builds on [14], is an example of a particular OTP algorithm and is not related to the EAP method defined in this document, other than that a profile of EAP-POTP may be created for the OTP algorithm from [14].
[14]上に構築[1]で定義されたEAP OTP方式は、EAP-POTPのプロフィールが作成されてもよいこと以外、特定のOTPアルゴリズムの一例であり、本文書で定義されたEAPメソッドに関連しません[14]からOTPアルゴリズムの。
The Generic Token Card EAP method defined in [1] is intended to work with a variety of OTP algorithms. The same is true for EAP-POTP, the EAP method defined herein. Advantages of profiling a particular OTP algorithm for use with EAP-POTP, compared to using EAP GTC, are described in Section 1.3.
[1]で定義された一般的なトークンカードEAPメソッドはOTPアルゴリズムの多様で動作するように意図されています。同じことが、EAP-POTP、本明細書で定義されるEAP方式についても同様です。 EAP GTCを使用する場合に比べ、EAP-POTPと共に使用するための特定のOTPアルゴリズムをプロファイリングの利点は、セクション1.3に記載されています。
The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY", in this document are to be interpreted as described in RFC 2119 [2].
キーワード「MUST」、「MUST NOT」、「SHALL」は、「NOT SHALL」、「推奨」、「すべきではない」「べきである」、および「MAY」、この文書では、RFCで説明したように解釈されるべきです2119 [2]。
The EAP-POTP method provides user authentication as defined below. Additionally, it may provide mutual authentication (authenticating the EAP server to the EAP client) and establish keying material.
以下に定義されるようにEAP-POTP方法は、ユーザ認証を提供します。さらに、それは、相互認証（EAPクライアントにEAPサーバを認証）を提供し、鍵材料を確立することができます。
There are basically three entities in the authentication method described here:
ここで説明した認証方法では3つのエンティティは、基本的にあります。
o A client, or "peer", using EAP terminology, acting on behalf of a user possessing an OTP token;
クライアント、または「ピア」O、OTPトークンを所有するユーザのために働く、EAPの用語を使用しました。
o A server, or "authenticator", using EAP terminology, to which the user needs to authenticate; and
ユーザが認証する必要があるにOサーバ、または「オーセンティケータ」、EAPの用語を使用して、。そして
o A backend authentication server, providing an authentication service to the authenticator.
Oバックエンド認証サーバ、オーセンティケータに認証サービスを提供します。
The term "EAP server" is used here with the same meaning as in [1]. Any protocol used between the authenticator and the backend authentication server is outside the scope of this document, although
用語「EAPサーバは」と同じ意味で、ここで使用されている[1]。オーセンティケータとバックエンド認証サーバとの間で使用される任意のプロトコルがあるが、この文書の範囲外であります
RADIUS [15] is a typical choice. It is assumed that the EAP client and the peer are located on the same host, and hence only the term "peer" is used in the following for these entities.
RADIUS [15]は、一般的な選択肢です。 EAPクライアントとピアが同じホスト上に配置され、ひいてはのみ用語「ピア」は、これらの事業体のために、以下のに使用されているものとします。
The EAP-POTP method assumes the use of a shared secret key, or "seed", which is known both by the user and the backend authentication server. The secret seed is stored on an OTP token that the user possesses, as well as on the authentication server.
EAP-POTP方法は、ユーザとバックエンド認証サーバの両方によって知られている共有秘密鍵、または「シード」の使用を想定しています。秘密のシードは、ユーザが所有するOTPトークン上だけでなく、認証サーバ上に格納されています。
In its most basic variant, the EAP-POTP method provides only one Service (namely, user authentication) where the user provides information to the authentication server so that the server can authenticate the user. A more advanced variant provides mutual authentication, protection against eavesdropping, and establishment of authenticated keying material.
その最も基本的な変形例では、EAP-POTP方法は、サーバがユーザを認証できるようにユーザが認証サーバに情報を提供する唯一のサービス（すなわち、ユーザ認証）を提供します。より高度な変形は、相互認証、盗聴に対する保護、および認証された鍵素材の確立を提供します。
Note: Since the EAP-POTP method is general in nature, the term "POTP-X" is used below as a placeholder for an EAP method type identifier, identifying the use of a particular OTP algorithm with EAP-POTP. As an example, in the case of using RSA SecurID tokens within EAP-POTP, the EAP method type shall be 32 (see Appendix A).
注：EAP-POTP方法は本質的に一般的であるので、用語「POTP-X」は、EAP-POTPを有する特定のOTPアルゴリズムの使用を識別する、EAPメソッドタイプ識別子のプレースホルダとして以下で使用されます。一例として、EAP-POTP内RSA SecurIDトークンを使用する場合には、EAPメソッドタイプ（付録A参照）32でなければなりません。
A typical EAP-POTP authentication is performed as follows (Appendix B provides more detailed examples):
次のように一般的なEAP-POTP認証が（付録Bは、より詳細な例を提供する）が行われます。
a. The optional EAP Identity Request/Response is exchanged, as per RFC 3748 [1]. An identity provided here may alleviate the need for a "User Identifier" or a "Token Key Identifier" triplet (TLV), defined below, later in the exchange.
A。オプションのEAPアイデンティティリクエスト/応答RFC 3748に従って、交換される[1]。ここで提供されるアイデンティティは、後の交換では、以下に定義され、「ユーザ識別子」または「トークンキー識別子」トリプレット（TLV）の必要性を緩和することができます。
b. The EAP server sends an EAP-Request of type POTP-X with a Version TLV. The Version TLV indicates the highest and lowest version of this method supported by the server. The EAP server typically also includes an OTP TLV in the EAP-Request. The OTP TLV instructs the peer to respond with the current OTP (possibly in protected form), and may contain a challenge and some other information, like server policies. The EAP server should also include a Server-Info TLV in the request, and must do so if it supports session resumption. The Server-Info TLV identifies the authentication server, contains an identifier for this (new) session, and may be used by the peer to find an already existing session with the EAP server.
B。 EAPサーバはバージョンTLVとのタイプPOTP-XのEAP-Requestを送信します。バージョンTLVは、サーバでサポートされているこの方法の最高と最低バージョンを示します。 EAPサーバは、一般的にも、EAP-要求でOTP TLVを含んでいます。 OTP TLVは（おそらく保護された形で）現在のOTPで応答するピアを指示し、サーバ・ポリシーのような課題や他のいくつかの情報を含んでいてもよいです。 EAPサーバは、サーバ情報要求でTLVを含める必要があり、それがセッション再開をサポートしている場合は、そうしなければなりません。サーバー情報TLVは、認証サーバを特定し、この（新しい）セッションの識別子が含まれており、EAPサーバとの既存のセッションを見つけるためにピアが使用することができます。
c. The peer responds with an EAP-Response of type Nak (3) if it does not support POTP-X or if it does not support a version of this method that is also supported by the server, as indicated in the server's Version TLV.
C。ピアタイプのEAP-応答NAK応答（3）は、サーバのバージョンTLVに示されるように、また、サーバによってサポートされているこの方法のバージョンをサポートしない場合、それはまたはPOTP-Xをサポートしていない場合。
If the peer supports a version of this method that is also
supported by the EAP server, the peer generates an EAP-Response
of type POTP-X as follows:
* First, it generates a Version TLV, which indicates the peer's highest supported version within the range of versions offered by the server. This Version TLV will be part of the EAP-Response to the EAP server.
*第一に、それは、サーバによって提供されるバージョンの範囲内で、ピアの最高のサポートバージョンを示しバージョンTLVを生成します。このバージョンTLVはEAPサーバへのEAP-レスポンスの一環となります。
* Next, if the peer's highest supported version equals that of the EAP server, and the EAP server sent a Server-Info TLV, the peer checks if it has a saved session with the EAP server. If an existing session with the server is found, and session resumption is possible (the Server-Info TLV may explicitly disallow it), the peer calculates new session keys (if the session is a protected-mode session) and responds with a Resume TLV and the Version TLV.
*次に、ピアの最高のサポートしているバージョンは、EAPサーバで保存されたセッションを持っている場合、EAPサーバ、およびEAPサーバのサーバ情報TLV、ピアチェックを送っていることと等しい場合。サーバーとの既存のセッションが見つかった、とセッションの再開が可能である場合（セッションがプロテクトモードのセッションである場合）と再開TLVで応答し、ピアは新しいセッション鍵を算出する（サーバ情報TLVは、明示的に許可しない場合があります）そしてバージョンTLV。
* Otherwise, if the peer's highest supported version equals that of the EAP server, and the received EAP-Request message contains an OTP TLV, the peer requests (possibly through user interaction) the OTP token to calculate a one-time password based on the information in the received EAP-Request message (which could, for example, carry a challenge), the current token state (e.g., token time), a shared secret (the "seed"), and a user-provided PIN (note that, depending on the OTP token type, some of the information in the EAP-Request may not be used in the OTP calculation, and the PIN may be optional too). If the received OTP TLV has the P bit set (see below), the peer then combines the token-provided OTP with other information, and provides the combined data to a key derivation function. The key derivation function generates several keys, of which one is used to calculate a Message Authentication Code (MAC) on the received message, together with some other information. The resulting MAC, together with some additional information, is then placed in an OTP TLV (with the P bit set) that is sent in a response to the EAP server, together with the Version TLV. If the P bit is not set in the received OTP TLV, the peer instead inserts the calculated OTP value directly in an OTP TLV, which then is sent to the EAP server together with the Version TLV.
*それ以外の場合は、ピアの最高のサポートしているバージョンは、EAPサーバの等しい、と受け取ったEAP-Requestメッセージは、に基づいて、ワンタイムパスワードを計算するOTPトークンをOTP TLV、（おそらくユーザーの相互作用を介して）ピアの要求が含まれている場合（例えば、チャレンジを運ぶことができる）を受信EAP-Requestメッセージ内の情報、現在のトークンの状態（例えば、トークン時間）、共有秘密（「シード」）、およびユーザ提供のPIN（なお、OTPトークンのタイプに応じて、EAP-要求における情報の一部は、OTPの計算に使用されなくてもよい、及びPIN）も任意です。受信されたOTP TLV（下記参照）のPビットがセットされている場合、ピアは、他の情報をトークン提供OTPを組み合わせ、および鍵導出関数に結合されたデータを提供します。鍵導出関数は、1つが一緒にいくつかの他の情報と、受信したメッセージにメッセージ認証コード（MAC）を計算するために使用されたいくつかのキーを生成します。一緒にいくつかの追加情報を得られたMACは、その後一緒にバージョンTLVを有する、EAPサーバに応答して送信された（Pビットがセットされた）OTP TLVに配置されます。 Pビットを受信したOTP TLVに設定されていない場合、ピアは、代わりに[バージョンTLVと共にEAPサーバに送信されるOTP TLVに直接計算OTP値を挿入します。
* Finally, if the peer's highest supported version differs from the server's, or if the server did not provide any TLVs besides the Version TLV in its initial request, the peer just sends back the generated Version TLV as an EAP-Response to the EAP server.
*最後に、ピアの最高のサポートしているバージョンは、サーバーのとは異なり、またはサーバーがその最初の要求におけるバージョンTLV以外の任意のTLVを提供しなかった場合、ピアは、単にEAPサーバへのEAP-応答として生成されたバージョンTLVを返送した場合。
d. If the EAP server receives an EAP-Response of type Nak (3), the session negotiation failed and the EAP server may try with another EAP method. Otherwise, the EAP server checks the peer's supported version. If the peer did not support the highest version supported by the server, the server will send a new EAP-Request with TLVs adjusted for that version. Otherwise, assuming the EAP server did send additional TLVs in its initial EAP-Request, the EAP server will attempt to authenticate the peer based on the response provided in c). Depending on the result of this authentication, the EAP server may do one of the following:
D。 EAPサーバは、タイプナックのEAP-応答を受信した場合（3）、セッションのネゴシエーションに失敗しましたし、EAPサーバは、別のEAP方式をしようとします。それ以外の場合は、EAPサーバは、ピアがサポートしているバージョンをチェックします。ピアは、サーバでサポートされている最も高いバージョンをサポートしていなかった場合、サーバーはそのバージョンの調整のTLVと新しいEAP-Requestを送信します。それ以外の場合は、EAPサーバと仮定すると、その最初のEAP-Requestに追加のTLVを送っていた、EAPサーバは、cに提供された応答）に基づいてピアを認証しようとします。この認証の結果に応じて、EAPサーバは、次のいずれかを行うことができます。
* send a new EAP-Request of type POTP-X to the peer indicating
that session resumption was not possible, and ask for a new
OTP (this would be the case when the peer responded with a
Resume TLV, and the session indicated in the Resume TLV was
not valid),
* send a new EAP-Request of type POTP-X to the peer (e.g., to ask for the next OTP),
*（例えば、次のOTPを要求する）ピアにタイプPOTP-Xの新しいEAP-Requestを送信し、
* accept the authentication (and send an EAP-Request message containing a Confirm TLV to the peer if the received response has the P bit set or was a successful attempt at a protected-mode session resumption; otherwise, send an EAP-Success message to the peer), or
*認証を受け付ける（受信した応答が設定されたPビットを有するか、またはプロテクトモードセッションの再開に成功した試みであった場合、ピアに確認TLVを含むEAP-Requestメッセージを送信し、そうでない場合にEAP-Successメッセージを送信しますピア）、または
* fail the authentication (and send an EAP-Failure message -- possibly preceded by an EAP-Request message of type Notification (2) -- to the peer).
*認証に失敗した（ピアへとEAP-失敗メッセージを送信する - - おそらく（2）タイプの通知のEAP-Requestメッセージが先行します）。
e. If the peer receives an EAP-Success or an EAP-Failure message the protocol run is finished. If the peer receives an EAP-Request of type Notification, it responds as specified by RFC 3748 [1]. If the peer receives an EAP-Request of type POTP-X with a Confirm TLV, it attempts to authenticate the EAP server using the provided data. If the authentication is successful, the peer responds with an EAP-Response of type POTP-X with a Confirm TLV. If it is unsuccessful, the peer responds with an empty EAP-Response of type POTP-X. If the peer receives an EAP-Request of type POTP-X containing some other TLVs, it continues as specified in c) above (though no version negotiation will take place in this case) or as described for those TLVs.
電子。ピアは、EAP-成功またはEAP失敗メッセージを受信した場合、プロトコルの実行が終了します。ピアが種別通知のEAP-Requestを受信した場合、RFC 3748で指定され、それは、[1]に応答します。ピアが確認TLVを持つタイプPOTP-XのEAP-Requestを受信した場合、提供されたデータを使用して、EAPサーバを認証することを試みます。認証が成功した場合、ピアは確認TLVとのタイプPOTP-XのEAP-応答で応答します。それが失敗した場合、ピアはタイプPOTP-Xの空のEAP-レスポンスで応答します。ピアがいくつかの他のTLVを含むタイプPOTP-XのEAP-Requestを受信した場合、Cで指定されるように、上記（noバージョンネゴシエーションが、この場合に行われないであろうが）、またはそれらのTLVについて記載したように）継続します。
f. When an EAP server, which has sent an EAP-Request of type POTP-X with a Confirm TLV, receives an EAP-Response of type POTP-X with a Confirm TLV present, it can proceed in one of two ways: If it has detected that there is a need to send additional EAP-Requests of type POTP-X, it shall enter a "protected state", where, from then on, all POTP-X TLVs must be encrypted and integrity-protected before being sent (at this point, the parties shall have calculated a master session key as described in Section 4.5). One reason to continue the POTP-X conversation after exchange of the Confirm TLV could be that the user needs to update her OTP PIN; hence, the EAP server needs to send a New PIN TLV. At that point, the handshake is back at step c) above (except for the version negotiation and the protection of all TLVs). If there is no need to send additional EAP-Request packets, the EAP server shall instead send an EAP-Success method to the peer to indicate successful protocol completion. The EAP server may not continue the conversation unless it indicates its intent to do so in the Confirm TLV.
F。確認TLVとのタイプPOTP-XのEAP-Requestを送信したEAPサーバは、確認TLVの存在とタイプPOTP-XのEAP-応答を受信すると、次のいずれかの方法で進めることができます：それは持っている場合タイプPOTP-Xの追加のEAP-リクエストを送信する必要があることを検出し、それはその後、上から（で送信される前に、すべてのPOTP-XのTLVは暗号化されなければならないとの整合性で保護された、「保護された状態」と、入力しなければなら）4.5節で説明したように、この時点では、当事者は、マスターセッションキーを計算していなければなりません。確認TLVの交換後POTP-Xの会話を継続する理由の1つは、ユーザーが自分のOTP PINを更新する必要があるということである可能性があります。したがって、EAPサーバは、新しいPIN TLVを送信する必要があります。その時点で、握手はバックステップcで）上記（バージョン交渉とすべてのTLVの保護）を除いてです。追加のEAP-Requestパケットを送信する必要がない場合は、EAPサーバは、代わりに成功したプロトコルが完了したことを示すために、ピアにEAP-成功法を送付しなければなりません。それが確認TLVでそうする意向を示していない限りEAPサーバは、会話を継続しないことがあります。
An EAP server, which has sent an EAP-Request of type POTP-X with
a Confirm TLV and receives an EAP-Response of type POTP-X, which
is empty (i.e., does not contain any TLVs), shall respond with an
EAP-Failure and terminate the handshake.
As implied by the description, steps c) through f) may be carried out a number of times before completion of the exchange. One example of this is when the authentication server initially requests an OTP, accepts the response from the peer, performs an (intermediary) Confirm TLV exchange, requests the peer to select a new PIN, and finally asks the peer to authenticate with an OTP based on the new PIN (which again will be followed with a final Confirm TLV exchange).
説明によって暗示されるように、Fを介してステップc））は交換が完了する前に数回行うことができます。認証サーバは、最初に、OTPを要求するピアからの応答を受け付け、（中間）を確認TLV交換を行い、新たなPINを選択するためにピアを要求し、最終的に基づいてOTPを使用して認証するピアを要求したときにその一例です（再び最終確認TLV交換を用いて追跡される）新しいPINに。
The EAP-POTP method provides a version negotiation mechanism that enables implementations to be backward compatible with previous versions of the protocol. This specification documents the EAP-POTP protocol version 1. Version negotiation proceeds as follows:
EAP-POTP方法は、プロトコルの以前のバージョンと下位互換性があるように実装を可能バージョンネゴシエーションメカニズムを提供します。次のようにこの仕様はEAP-POTPプロトコルバージョン1バージョン交渉が進行を文書化：
a. In the first EAP-Request of type POTP-X, the EAP server MUST send a Version TLV in which it sets the "Highest" field to its highest supported version number, and the "Lowest" field to its lowest supported version number. The EAP server MAY include other TLV triplets, as described below, that are compatible with the "Highest" supported version number to optimize the number of round-trips in the case of a peer supporting the server's "Highest" version number.
A。タイプPOTP-Xの最初のEAP-要求では、EAPサーバは、その最高のサポートされているバージョン番号、およびその最低のサポートされるバージョン番号に「最低」フィールドに「最高」フィールドを設定するにはバージョンTLVを送らなければなりません。 EAPサーバは、サーバの「最高」バージョン番号をサポートするピアの場合にはラウンドトリップの数を最適化する「最高」サポートされているバージョン番号と互換性があり、以下に記載されるように、他のTLVトリプレットを含むことができます。
b. If the peer supports a version of the protocol that falls within the range of versions indicated by the EAP server, it MUST respond with an EAP-Response of type POTP-X that contains a Version TLV with the "Highest" field set to the highest version supported by the peer. The peer MUST also respond to any TLV triplets included in the EAP-Request, if it supported the "Highest" supported version indicated in the server's Version TLV.
B。ピアは、EAPサーバによって示されたバージョンの範囲内にあるプロトコルのバージョンをサポートしている場合、それは最高に設定し、「最高」フィールドでバージョンTLVが含まれているタイプPOTP-XのEAP-応答で応じなければなりませんピアによってサポートされているバージョン。ピアはまた、任意のTLV三つ子に反応しなければなりません、それはサーバのバージョンTLVに示されている「最高」サポートされているバージョンをサポートしている場合、EAP-Requestに含まれています。
The EAP peer MUST respond with an EAP-Response of type Nak (3) if
it does not support a version that falls within the range of
versions indicated by the EAP server. This will allow the EAP
server to use another EAP method for peer authentication.
c. When the EAP server receives an EAP-Response containing a Version TLV from the peer, but the "Highest" supported version field in the TLV differs from the "Highest" supported version field sent by the EAP server, or when the version is the same as the one originally proposed by the EAP server, but the EAP server did not include any TLV triplets in the initial request, the EAP server sends a new EAP-Request of type POTP-X with the negotiated version and TLV triplets as desired and described herein.
C。 EAPサーバは、ピアからバージョンTLVを含むEAPレスポンスを受信するが、TLVにおける「最高」サポートされているバージョンフィールドは、「最高」サポートされているバージョンのEAPサーバから送信されたフィールド、または場合バージョンが同じであると異なる場合元々EAPサーバによって提案された一つが、EAPサーバは、最初の要求で任意TLVトリプレットが含まれていなかったとして所望と記載されているように、EAPサーバがネゴシエートバージョンとTLVのトリプレットとタイプPOTP-Xの新しいEAP-Requestを送信します。ここ。
The version negotiation procedure guarantees that the EAP peer and server will agree to the highest version supported by both parties. If version negotiation fails, use of EAP-POTP will not be possible, and another mutually acceptable EAP method will need to be negotiated if authentication is to proceed.
バージョン交渉手順は、EAPピアとサーバは、両当事者によってサポートされる最高のバージョンに同意することを保証します。バージョン交渉が失敗した場合、EAP-POTPの使用ができなくなり、認証が進むのであれば、別の相互に受け入れ可能なEAP方式がネゴシエートする必要があります。
The EAP-POTP version field may be modified in transit by an attacker. It is therefore important that EAP entities only accept EAP-POTP versions according to an explicit policy.
EAP-POTPバージョンフィールドは、攻撃者がトランジットで変更することができます。 EAPエンティティは明示的なポリシーに従ってEAP-POTPバージョンを受け入れることが重要です。
Cryptographic algorithms are negotiated through the use of the Crypto Algorithm TLV. EAP-POTP provides a default digest algorithm (SHA-256) [3], a default encryption algorithm (AES-CBC) [4] , and a default MAC algorithm (HMAC) [5], and these algorithms MUST be supported by all EAP-POTP implementations. An EAP server that does not want to make use of any other algorithms than the default ones need not send a Crypto Algorithm TLV. An EAP server that does want to negotiate use of some other algorithms MUST send the Crypto Algorithm TLV in the initial EAP-Request of type POTP-X that also contains an OTP TLV with the P bit set. The TLV MUST NOT be present in any other EAP-Request in the session. (The two exceptions to this are 1) if the client attempted a session resumption that failed and therefore did not evaluate a sent Crypto Algorithm TLV, or 2) if the
暗号化アルゴリズムは、暗号アルゴリズムTLVを使用してネゴシエートされます。 EAP-POTPはデフォルトダイジェストアルゴリズム（SHA-256）[3]、デフォルト暗号化アルゴリズム（AES-CBC）[4]、及びデフォルトMACアルゴリズム（HMAC）が[5]、およびこれらのアルゴリズムは、すべてをサポートしなければなりませんを提供しますEAP-POTPの実装。暗号化アルゴリズムTLVを送信する必要はないデフォルトのもの以外のアルゴリズムを使用することを望んでいないEAPサーバ。また、PビットがセットでOTP TLVが含まれているタイプPOTP-Xの最初のEAP-Requestに暗号化アルゴリズムTLVを送らなければなりませんいくつかの他のアルゴリズムの使用を交渉したいんEAPサーバ。 TLVは、セッション内の他のEAP-要求中に存在してはなりません。 （これには、2つの例外が1されている）クライアントが失敗したため、送信された暗号化アルゴリズムTLVを評価していなかったセッションの再開を試みた場合、または2）の場合
Crypto Algorithm TLV was part of the initial message from the EAP server, and the client negotiated another EAP-POTP version than the highest one supported by the EAP server. When either of these cases apply, the server MUST include the Crypto Algorithm TLV in the first EAP-Request that also contains an OTP TLV with the P bit set subsequent to the failed session resumption / protocol version negotiation.) In the Crypto Algorithm TLV, the EAP server suggests some combination of digest, encryption, and MAC algorithms. (If the server only wants to negotiate a particular class of algorithms, then suggestions for the other classes need not be present, since the default applies.)
暗号アルゴリズムTLVはEAPサーバからの最初のメッセージの一部で、クライアントがEAPサーバでサポートされている最高のものよりも、別のEAP-POTPバージョンを交渉しました。これらのケースのいずれかが当てはまる場合、サーバはまた、失敗したセッション再開/プロトコルバージョンネゴシエーションの後に設定してください。）暗号化アルゴリズムTLVのPビットとOTP TLVを含む最初のEAP-Requestに暗号化アルゴリズムTLVを含まなければなりません、 EAPサーバは、ダイジェスト、暗号化、およびMACアルゴリズムのいくつかの組み合わせを示唆しています。 （サーバーが唯一のアルゴリズムの特定のクラスを交渉したい場合は、他のクラスのための提案は、デフォルトが適用されているので、存在する必要はありません。）
The peer MUST include a Crypto Algorithm TLV in an EAP-Response if and only if an EAP-Request of type POTP-X has been received containing a Crypto Algorithm TLV, it was legal for that EAP-Request to contain a Crypto Algorithm TLV, the peer does not try to resume an existing session, and the peer and the EAP server agree on at least one algorithm not being the default one. If the peer does not supply a value for a particular class of algorithms in a responding Crypto Algorithm TLV, then the default algorithm applies for that class. When resuming an existing session (see the next section), there is no need for the peer to negotiate since the session already is associated with a set of algorithms. Servers MUST fail a session (i.e., send an EAP-Failure) if they receive an EAP-Response TLV containing both a Resume TLV and a Crypto Algorithm TLV.
タイプPOTP-XのEAP-要求は、暗号アルゴリズムTLVを含む受信された場合にのみ、それは暗号化アルゴリズムTLVを含有することEAP-要求の法的た場合、ピアは、EAP-応答で暗号化アルゴリズムTLVを含まなければなりませんピアは、既存のセッションを再開しようとしない、とピアとEAPサーバはデフォルトのものではない少なくとも一つのアルゴリズムに同意するものとします。ピアが応答して暗号化アルゴリズムTLVにおけるアルゴリズムの特定のクラスの値を指定しない場合は、デフォルトのアルゴリズムは、そのクラスに適用されます。 （次のセクションを参照）、既存のセッションを再開するときに、セッションが既にアルゴリズムのセットに関連付けられているので、ピアがネゴシエートする必要がありません。彼らは再開TLVと暗号アルゴリズムTLVの両方を含むEAP応答TLV受信した場合、サーバーがセッションを（すなわち、EAP-失敗を送って）失敗しなければなりません。
Clearly, EAP servers and peers MUST NOT suggest any other algorithms than the ones their policy allows them to use. Policies may also restrict what combinations of cryptographic algorithms are acceptable.
明らかに、EAPサーバおよびピアは、そのポリシーがそれらを使用することができますもの以外のアルゴリズムを提案してはなりません。ポリシーはまた、暗号アルゴリズムの組み合わせが許容されているものを制限することができます。
This method makes use of session identifiers and server identifiers to allow for improved efficiency in the case where a peer repeatedly attempts to authenticate to an EAP server within a short period of time. This capability is particularly useful for support of wireless roaming.
この方法は、ピアが繰り返し時間の短い期間内にEAPサーバに対して認証しようとした場合に改善された効率を可能にするために、セッション識別子とサーバ識別子を利用します。この機能は、ワイヤレスローミングのサポートのために特に有用です。
In order to help the peer find a session associated with the EAP server, an EAP server that supports session resumption MUST send a Server-Info TLV containing a server identifier in its initial EAP-Request of type POTP-X that also contains an OTP TLV. The identifier may then be used by the peer for lookup purposes.
ピアは、EAPサーバに関連付けられたセッションを見つけるためには、セッション再開をサポートしているEAPサーバは、サーバ・インフォメーションTLVもOTP TLVが含まれているタイプPOTP-Xのその最初のEAP-Requestにサーバ識別子を含むを送らなければなりません。識別子は、次いで、ルックアップのためにピアによって使用されてもよいです。
It is left to the peer whether or not to attempt to continue a previous session, thus shortening the negotiation. Typically, the peer's decision will be made based on the time elapsed since the previous authentication attempt to that EAP server. If the peer decides to attempt to resume a session with the EAP server, it sends a Resume TLV identifying the chosen session and other contents, as described below, to the EAP server.
このように交渉を短縮し、前のセッションを継続しようとするかどうかを相手に委ねられています。一般的に、ピアの決定は、EAPサーバへの以前の認証の試行からの経過時間に基づいて行われます。ピアがEAPサーバとのセッションを再開しようとすることを決定した場合、それはEAPサーバに、以下に説明するように再開TLVは、選択されたセッションおよび他のコンテンツを識別送ります。
Based on the session identifier chosen by the peer, and the time elapsed since the previous authentication, the EAP server will decide whether to allow the session resumption, or continue with a new session.
ピアによって選ばれたセッション識別子、および以前の認証からの経過時間に基づいて、EAPサーバは、セッション再開を許可するかどうかを決定する、または新しいセッションを続行します。
o If the EAP server is willing to resume a previously established session, it MUST authenticate the peer based on the contents of the Resume TLV. If the authentication succeeds, the handshake will continue in one of two ways:
EAPサーバは、以前に確立したセッションを再開する意志がある場合は、O、それは再開TLVの内容に基づいてピアを認証しなければなりません。認証が成功した場合、ハンドシェークは、次のいずれかの方法で継続されます：
* If the session is a protected-mode session, then the server MUST respond with a request containing a Confirm TLV. If the Confirm TLV authenticates the EAP server, then the peer responds with an empty Confirm TLV, to which the EAP server responds with an EAP-Success message. If the Confirm TLV does not authenticate the EAP server, the peer responds with an empty EAP-Response of type POTP-X.
*セッションがプロテクトモードセッションであれば、サーバは確認TLVを含む要求で応じなければなりません。確認TLVはEAPサーバを認証した場合、ピアは、EAPサーバがEAP-Successメッセージで応答するために、空の確認TLVで応答します。確認TLVはEAPサーバを認証しない場合、ピアはタイプPOTP-Xの空のEAP-レスポンスで応答します。
* If the session is not a protected-mode session, i.e., it is a session created from a basic-mode peer authentication, then the server MUST respond with an EAP-Success message.
セッションがプロテクトモードセッションでない場合は*、すなわち、それは、サーバがEAP-Successメッセージで応じなければなりません、基本モードのピア認証から作成されたセッションです。
If the authentication of the peer fails, the EAP server SHOULD send another EAP-Request containing an OTP TLV and a Server-Info TLV with the N bit set to indicate that no session resumption is possible. The EAP server MAY also send an EAP-Failure message, possibly preceded by an EAP-Request of type Notification (2), in which case, the EAP run will terminate.
ピアの認証に失敗した場合は、EAPサーバは、セッションの再開が可能でないことを示すためにビットセットOTP TLVとNとサーバー情報TLVを含む別のEAP-Requestを送るべきです。 EAPサーバは、また、（2）、その場合には、EAPの実行が終了する可能性種別通知のEAP-要求により先行EAP-失敗メッセージを送信してもよいです。
o If the EAP server is not willing or able to resume a previously established session, it will respond with another EAP-Request containing an OTP TLV and a Server-Info TLV with the N bit set (indicating no session resumption).
EAPサーバが喜んまたは以前に確立したセッションを再開することができない場合には、O、それは（ないセッション再開を示さない）NビットがセットでOTP TLVおよびサーバー情報TLVを含む別のEAP-要求に応答します。
Sessions SHOULD NOT be maintained longer than the security of the exchange which created the session permits. For example, if it is estimated that an attacker could be successful in brute-force searching for the OTP in 24 hours, then EAP-POTP session lifetimes should be clearly less than this value.
セッションは、セッション許可証を作成した為替のセキュリティよりも長く維持されるべきではありません。それは攻撃者が24時間以内にOTPを探して力ずくで成功する可能性があると推定されている場合、その後、EAP-POTPセッションの寿命は、この値よりも明らかに小さくする必要があります。
The EAP-POTP method described herein makes use of a key derivation function denoted "PBKDF2". PBKDF2 is described in [6], Section 5.2. The PBKDF2 PRF SHALL be set to the negotiated MAC algorithm. The default MAC algorithm, which MUST be supported, is HMAC-SHA256. HMAC is defined in [5], and SHA-256 is defined in [3]. HMAC-SHA256 is the HMAC construct from [5] with SHA-256 as the hash function H. The output length of HMAC-SHA256, when used as a PRF for PBKDF2, shall be 32 octets (i.e., the full output length).
本明細書に記載のEAP-POTP法「PBKDF2」表記キー導出関数を利用します。 PBKDF2は、[6]、セクション5.2に記載されています。 PBKDF2 PRFは、交渉されたMACアルゴリズムを設定しなければなりません。サポートしなければならないデフォルトMACアルゴリズムは、HMAC-SHA256です。 HMACは、[5]で定義されており、SHA-256 [3]で定義されています。 HMAC-SHA256はHMACから構築物である[5] 32個のオクテット（すなわち、完全な出力長）でなければならない、PBKDF2用PRFとして使用されるハッシュ関数HとしてSHA256 HMAC-SHA256の出力長さを有します。
The output from PBKDF2 as described here will consist of five keys (see Section 4.11.3 for details on how to calculate these keys):
ここで説明したようにPBKDF2からの出力は、5つのキー（これらのキーを計算する方法の詳細については、セクション4.11.3を参照）で構成されます：
o K_MAC, a MAC key used for mutual authentication and integrity protection,
O K_MAC、相互認証と完全性保護のために使用されるMACキー、
o K_ENC, an encryption key used to protect certain data during the authentication,
K_ENC、認証中に特定のデータを保護するために使用する暗号鍵、O
o SRK, a session resumption key only used for session resumption purposes,
SRK O、唯一のセッション再開のために使用されるセッション再開キー、
o MSK, a Master Session Key, as defined in [1], and
[1]で定義されているMSK、マスターセッションキー、およびO
o EMSK, an Extended Master Session Key, also as defined in [1].
で定義されているとしても、O EMSK、拡張マスタセッションキー、[1]。
For the default algorithms, K_MAC, K_ENC, and SRK SHALL be 16 octets. For other cases, the key lengths will be as determined by the negotiated algorithms. The MSK and the EMSK SHALL each be 64 octets, in conformance with [1]. Therefore, in the case of default algorithms, the "dkLen" parameter from Section 5.2 of [6] SHALL be set to 176 (the combined length of K_MAC, K_ENC, SRK, MSK, and EMSK).
デフォルトのアルゴリズムについて、K_MAC、K_ENC、およびSRKは16個のオクテットでなければなら。ネゴシエートされたアルゴリズムによって決定されるような他のケースでは、キーの長さになります。 MSK及びEMSKは、それぞれ、[1]に準拠して、64個のオクテットでなければなりません。したがって、セクション5.2からデフォルトのアルゴリズム、「dkLen」パラメータの場合には、[6] 176（K_MAC、K_ENC、SRK、MSK及びEMSKの結合した長さ）に設定されなければなりません。
[1] and [16] define usage of the MSK and the EMSK . For a particular use case, see also Appendix C.
[1]及び[16] MSK及びEMSKの使用を定義します。特定のユースケースについては、付録C.も見
EAP does not allow for the sending of an EAP-Response of type Nak (3) within a method after the initial EAP-Request and EAP-Response pair of that particular method has been exchanged (see [1], Section 2.1). Instead, when a peer is unable to continue an EAP-POTP session, the peer MAY respond to an outstanding EAP-Request by sending an empty EAP-Response of type POTP-X rather than immediately terminating the conversation. This allows the EAP server to log the cause of the error.
EAPは、その特定のメソッドの最初のEAP-要求とEAPレスポンス対が交換された後にNAKを（3）メソッド内（[1]参照、セクション2.1）タイプのEAP-応答の送信を可能にしません。ピアは、EAP-POTPセッションを継続することができないとき代わりに、ピアはタイプPOTP-Xの空のEAP-応答を送信するのではなく、すぐに会話を終了することによって、優れたEAP-要求に応答することができます。これは、EAPサーバがエラーの原因をログに記録することができます。
To ensure that the EAP server receives the empty EAP-Response, the peer SHOULD wait for the EAP server to reply before terminating the conversation. The EAP server MUST reply with an EAP-Failure.
EAPサーバは、空のEAP-応答を受け取ることを保証するために、ピアは、会話を終了する前に返信するEAPサーバを待つべき。 EAPサーバは、EAP-失敗と返答しなければなりません。
When EAP-POTP is run in protected mode, the exchange of the Confirm TLV (Section 4.11.6) serves as a success result indication; when the peer receives a Confirm TLV, it knows that the EAP server has successfully authenticated it. Similarly, when the EAP server receives the Confirm TLV response from the peer, it knows that the peer has authenticated it. In protected mode, the peer will not accept an EAP-Success packet unless it has received and validated a Confirm TLV. The Confirm TLV sent from the EAP server to the peer is a "protected result indication" as defined in [1], as it is integrity protected and cannot be replayed. The Confirm TLV sent from the peer to the EAP server is, however, not a protected result indication. An empty EAP-POTP response sent from the peer to the EAP server serves as a failure result indication.
EAP-POTPを保護モードで実行されると、確認TLV（セクション4.11.6）の交換は成功結果指示として働きます。ピアが確認TLVを受信したとき、それはEAPサーバが正常に認証したことを知っています。 EAPサーバは、ピアから確認TLV応答を受信したとき同様に、それは相手がそれを認証したことを知っています。それは受信の確認TLVを検証していない限り、保護モードでは、ピアは、EAP-Successパケットを受け付けません。で定義されるようにピアにEAPサーバから送信された確認TLVは「保護結果指示」である[1]、それは完全性保護および再生することができないからです。 EAPサーバにピアから送信された確認TLVは、しかしながら、保護された結果を示すものではありません。 EAPサーバにピアから送信された空のEAP-POTP応答が失敗結果指示として働きます。
Except where explicitly allowed in the following, the EAP Notification method MUST NOT be used within an EAP-POTP session. The EAP Notification method MAY be used within an EAP-POTP session in the following situations:
明示的に次のように許可されている場合を除き、EAP通知方法は、EAP-POTPセッション内で使用してはいけません。 EAP通知方法は、以下の状況でEAP-POTPセッション内で使用されることがあります。
o The EAP server MAY send an EAP-Request of type Notification (2) when it has received an EAP-Response containing an OTP TLV and is unable to authenticate the user. In this case, once the EAP-Response of type Notification is received, the EAP server MAY retry the authentication and send a new EAP-Request containing an OTP TLV, or it MAY fail the session and send an EAP-Failure message.
O EAPサーバは、タイプ通知（2）は、OTP TLVを含むEAP-応答を受信し、ユーザを認証することができないしたときのEAP-要求を送信することができます。タイプの通知のEAP-Responseが受信されると、この場合、EAPサーバが認証を再試行し、OTP TLVを含む新しいEAP-Requestを送ったり、セッションを失敗し、EAP失敗メッセージを送信する場合があります。
o The EAP server MAY send an EAP-Request of type Notification (2) when it has received an unacceptable New PIN TLV. In this case, once the EAP-Response of type Notification is received, the EAP server MAY retry the PIN update and send a new EAP-Request with a New PIN TLV, or it MAY fail the session and send an EAP-Failure message.
O EAPサーバは、それが受け入れられない新しいPIN TLVを受信したタイプの通知（2）のEAP-要求を送信することができます。この場合、タイプの通知のEAP-Responseが受信されると、EAPサーバは、PINの更新を再試行するかもしれなくて、新しいPIN TLVと新しいEAP-Requestを送ったり、セッションを失敗し、EAP-失敗メッセージを送信することができます。
Since OTPs may be relatively short, it is important to slow down an attacker sufficiently so that it is economically unattractive to brute-force search for an OTP, given an observed EAP-POTP handshake in protected mode. One way to do this is to do a high number of iterated hashes in the PBKDF2 function. Another is for the client to include a value ("pepper") unknown to the attacker in the hash computation. Whereas a traditional "salt" value normally is sent in the clear, this "pepper" value will not be sent in the clear, but may instead be transferred to the EAP server in encrypted form. In practice, the procedure is as follows:
OTPは、比較的短いかもしれないので、OTPの検索力ブルートすることは経済的に魅力的であるように、保護モードで観察されたEAP-POTPハンドシェーク与え、十分に攻撃を遅くすることが重要です。これを行う1つの方法は、PBKDF2機能に反復ハッシュの高い数を行うことです。もう一つは、ハッシュ計算では、攻撃者に未知の値（「コショウ」）を含めるように、クライアントのためです。通常は平文で送信され、伝統的な「塩」値に対し、この「コショウ」値は平文で送信されることはありませんが、代わりに暗号化された形でEAPサーバに転送することができます。次のように実際には、手順は次のとおりです。
a. The EAP server indicates in its OTP TLV whether it supports pepper searching. Additionally, it may indicate to the peer that a new pepper shall be chosen.
A。 EAPサーバは、それが唐辛子検索をサポートしているかどうか、そのOTP TLVに示します。さらに、それは新しいコショウが選択されなければならない相手に示すことができます。
b. If the peer supports the use of pepper, the peer checks whether it already has established a shared pepper with this server:
B。ピアは、唐辛子の使用をサポートしている場合、ピアチェックし、それがすでにこのサーバーと共有コショウを確立しているかどうか：
If it does have a pepper stored for this server, and the server
did not indicate that a new pepper shall be generated, then it
uses the existing pepper value, as specified in Section 4.11.3
below, to calculate an OTP TLV response. In this case, the
iteration count shall be kept to a minimum, as the security of
the scheme is provided through the pepper, and efficiency
otherwise is lost.
If the peer does not have a pepper stored for this server, but the server indicated support for pepper searching, or the server indicated that a new pepper shall be generated, then the peer generates a random and uniformly distributed pepper of sufficient length (the maximum length supported by the server is provided in the server's OTP TLV), and includes the new pepper in the PBKDF2 computation.
ピアは、このサーバの記憶されたコショウを持っていないが、サーバはコショウ検索のサポートを示し、またはサーバが新しいコショウが生成されなければならないことを示し、次いで、ピアは十分な長さのランダム及び均一に分布コショウ（最大値が発生した場合サーバーでサポートされている長さ）は、サーバのOTP TLVに設けられ、PBKDF2計算で新しいコショウが含まれています。
If the peer does not have a pepper stored for this server, and the server did not indicate support for pepper searching, then a pepper will not be used in the response computation.
ピアがこのサーバーの保存コショウを持っていない、とサーバがコショウの検索のためのサポートを示すものではありませんでした場合は、唐辛子は、応答計算に使用されることはありません。
Clearly, if the peer itself does not support the use of pepper, then a pepper will not be used in the response computation.
ピア自体は唐辛子の使用をサポートしない場合、明らかに、その後、コショウは、応答計算に使用されません。
c. The EAP server may, in its subsequent Confirm TLV, provide a pepper to the peer for later use. In this case, the pepper will be substantially longer than a peer-chosen pepper, and encrypted with a key derived from the PBKDF2 computation.
C。 EAPサーバは、その後の確認TLVに、後で使用するためにピアに唐辛子を提供することができます。この場合には、唐辛子はピア選択コショウよりも実質的に長くなり、PBKDF2計算から導出鍵で暗号化。
The above procedure allows for pepper updates to be initiated by either side, e.g., based on policy. Since the pepper can be seen as a MAC key, its lifetime should be limited.
コショウ更新がポリシーに基づいて、例えば、いずれかの側によって開始されるために、上記手順が可能になります。唐辛子は、MACキーとして見ることができるので、その寿命を制限する必要があります。
An EAP server that is not capable of storing pepper values for each user it is authenticating may still support the use of pepper; the cost for this will be the extra computation time to do pepper searches. This cost is still substantially lower than the cost for an attacker, however, since the server already knows the underlying OTP.
それでもコショウの使用をサポートすることができる認証されたユーザ毎コショウ値を格納することができないEAPサーバ。このための費用は、唐辛子の検索を行うために余分な計算時間になります。サーバはすでに基本的なOTPを知っているので、このコストは、しかし、まだ攻撃者のためのコストよりも実質的に低いです。
In protected mode, EAP-POTP uses MACs for authentication purposes, as well as to ensure the integrity of protocol sessions. This section defines how the MACs are calculated and the rationale for the design.
保護モードでは、EAP-POTPは、認証目的のためにMACを使用するだけでなく、プロトコルセッションの整合性を確保します。このセクションでは、MACSを計算し、設計の根拠する方法を定義します。
In protected mode, and when resuming a previous session, rather than sending authenticating credentials (such as one-time passwords or shared keys) directly, evidence of knowledge of the credentials is sent. This evidence is a MAC on the hash of (certain parts of) EAP-POTP messages exchanged so far in a session using a key K_MAC:
保護モードで、むしろ認証資格証明を送信するよりも、前のセッションを再開するときに直接、資格情報の知識の証拠が送信される（例えば、ワンタイムパスワードまたは共有キーのような）。この証拠は、EAP-POTPメッセージはキーK_MACを使用してセッションでこれまでに交換（の特定の部分）のハッシュにMACを次のとおりです。
mac = MAC(K_MAC, msg_hash(msg_1, msg_2, ..., msg_n))
MAC = MAC（K_MAC、msg_hash（msg_1、msg_2、...、msg_n））
where
どこ
"MAC" is the negotiated MAC algorithm, "K_MAC" is a key derived as specified in Section 4.5, and "msg_hash(msg_1, msg_2, ..., msg_n)" is the message hash defined below of messages msg_1, msg_2, ..., msg_n.
「MAC」とネゴシエートMACアルゴリズムである、「K_MAC」はセクション4.5で指定されるように誘導されたキー、及び「msg_hash（msg_1、msg_2、...、msg_n）」であるメッセージmsg_1、msg_2の下に定義されたメッセージのハッシュです。 .. msg_n。
To compute a message hash for the MAC, given a sequence of EAP messages msg_1, msg_2, ..., msg_n, the following operations shall be carried out:
EAPメッセージmsg_1、msg_2、...、msg_nのシーケンス与えられ、MACのメッセージのハッシュを計算するには、以下の操作を行わなければなりません。
a. Re-transmitted messages are removed from the sequence of messages.
A。再送信されたメッセージは、メッセージのシーケンスから削除されます。
Note: The resulting sequence of messages must be an alternating
sequence of EAP Request and EAP Response messages.
b. The contents (i.e., starting with the EAP "Type" field and excluding the EAP "Code", "Identifier", and "Length" fields) of each message, msg_1, msg_2, ..., msg_n, is concatenated together.
B。コンテンツ（即ち、EAP「タイプ」フィールドで開始し、EAP「コード」、「識別子」、および「長さ」フィールドを除く）各メッセージの、msg_1、msg_2、...、msg_nは、一緒に連結されています。
c. User identifier TLVs MUST NOT be included in the hash (this is to allow for a backend service that does not know about individual user names), i.e., any such TLV is removed from the message in which it appeared.
C。ユーザ識別子のTLV（これは、個々のユーザ名について知らないバックエンドサービスを可能にするためである）ハッシュに含まれてはいけません、すなわち、任意のこのようなTLVは、それが出現したメッセージから除去されます。
d. The resulting string is hashed using the negotiated hash algorithm.
D。結果の文字列は、交渉されたハッシュアルゴリズムを使用してハッシュされます。
The reason for excluding the "Identifier" field is that the actual, transmitted "Identifier" field is not always known to the EAP method layer. The reason for excluding the "Length" field is to allow the possibility for an intermediary to remove or replace a Username TLV (e.g., for anonymity or service reasons) before passing a received response on to an authentication server. While this on the surface may appear as bad security practice, it may in practice only result in denial of service, something which always may be achieved by an attacker able to modify messages in transit. By excluding the "Code" field, the hash is simply calculated on applicable sent and received message contents. Excluding the "Code" field is regarded as harmless since the hash is to be made on the sequence of POTP-X messages, all having alternating (known) Code values, namely 1 (Request) and 2 (Response).
「識別子」フィールドを除く理由は、実際、送信された「識別子」フィールドは常にEAPメソッド層には知られていないということです。 「長さ」フィールドを除く理由は、削除または認証サーバーに受信した応答を渡す前に、ユーザー名TLVを（例えば、匿名性やサービスの理由で）交換する仲介のための可能性を可能にすることです。これは、表面に悪いセキュリティの実践を表示されることがありますが、それは実際にのみ、サービス拒否が常に輸送中のメッセージを変更することが攻撃者によって達成することができる何かをすることがあります。 「コード」フィールドを除外することによって、ハッシュは、単純に適用送信され、受信したメッセージの内容に基づいて計算されます。ハッシュは、POTP-Xのメッセージのシーケンスのすべての交番（既知の）コード値、すなわち、1（要求）及び2（Response）を行うことがあるため、「コード」フィールドを除く無害と見なされます。
To save on storage space, each EAP entity may partially hash messages as they are sent and received (e.g., HashInit(); HashUpdate(message 1); ...; HashUpdate(message n-1); HashFinal(message n)). This reduces the amount of state needed for this purpose to the internal state required for the negotiated hash algorithm.
ストレージスペースを節約するために、各EAPエンティティは、部分的にハッシュメッセージは、それらが送受信されることができる（例えば、HashInit（）; HashUpdate（メッセージ1）; ...; HashUpdate（メッセージN-1）; HashFinal（メッセージn））を。これは、交渉されたハッシュアルゴリズムのために必要な内部状態に、この目的のために必要な状態の量を減少させます。
A summary of the EAP-POTP packet format is shown below. The fields are transmitted from left to right.
EAP-POTPパケットフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | TLV-based EAP-POTP message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
1 - Request
1 - 要求
2 - Response
2 - レスポンス
Identifier
識別
The Identifier field is 1 octet and aids in matching responses with requests. For a more detailed description of this field and how to use it, see [1].
識別子フィールドは1つのオクテットと要求と応答のマッチングを助けるです。このフィールドの詳細については、それを使用する方法、[1]を参照してください。
Length
長さ
The Length field is 2 octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, Version, Flags, and TLV-based EAP-POTP message fields.
Lengthフィールドは、2つのオクテットであり、コード、識別子、長さ、タイプ、バージョン、フラグ、TLVベースのEAP-POTPメッセージフィールドを含むEAPパケットの長さを示します。
Type
タイプ
Identifies use of a particular OTP algorithm with EAP-POTP.
EAP-POTPを持つ特定のOTPアルゴリズムの使用を識別します。
Reserved
予約済み
This octet is reserved for future use. It SHALL be set to zero for this version. Recipients SHALL ignore this octet for this version of EAP-POTP.
このオクテットは、将来の使用のために予約されています。これは、このバージョンのためにゼロに設定しなければなりません。受信者は、EAP-POTPのこのバージョンのために、このオクテットを無視しなければなりません。
TLV-based EAP-POTP message
TLVベースのEAP-POTPメッセージ
This field will contain 0, 1, or more Type-Length-Value triplets defined as follows (this is similar to the EAP-TLV TLVs defined in PEAPv2 [17], and the explanation of the generic fields is borrowed from that document).
次のようにこのフィールドには、（これはPEAPv2 [17]で定義されたEAP-TLVのTLVと同様であり、一般的なフィールドの説明は、そのドキュメントから借用されている）定義0、1、または複数のタイプレングス値のトリプレットを含むであろう。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Non-mandatory TLV
0 - 非必須TLV
1 - Mandatory TLV
1 - 必須TLV
The TLVs within EAP POTP-X are used to carry parameters between the EAP peer and the EAP server. An EAP peer may not necessarily implement all the TLVs supported by an EAP server, and to allow for interoperability, a special TLV allows an EAP server to discover if a TLV is supported by the EAP peer.
EAP POTP-X内のTLVはEAPピアとEAPサーバ間でパラメータを搬送するために使用されます。 EAPピアが必ずしもEAPサーバでサポートされているすべてのTLVを実装していないこと、および相互運用性を確保するために、特別なTLVは、TLVがEAPピアによってサポートされている場合、EAPサーバを発見することができます。
The mandatory bit in a TLV indicates that if the peer or server does not support the TLV, it MUST send a NAK TLV in response; all other TLVs in the message MUST be ignored. If an EAP peer or server finds an unsupported TLV that is marked as non-mandatory (i.e., optional), it MUST NOT send a NAK TLV on this ground only.
TLVで必須のビットはピアまたはサーバがTLVをサポートしていない場合、それが応答でNAK TLVを送らなければなりませんことを示しています。メッセージ内の他のすべてのTLVを無視しなければなりません。 EAPピアまたはサーバが非必須（すなわち、オプション）としてマークされ、サポートされていないTLV見つけた場合、それだけでこの地上でNAK TLVを送ってはいけません。
The mandatory bit does not imply that the peer or server is required to understand the contents of the TLV. The appropriate response to a supported TLV with content that is not understood is defined by the specification of the particular TLV.
必須ビットは、ピアまたはサーバがTLVの内容を理解することが必要であることを意味するものではありません。理解されていないコンテンツでサポートTLVへの適切な応答は、特定のTLVの仕様によって定義されます。
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of the EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
The following TLV types are defined for use with EAP-POTP:
以下のTLVタイプは、EAP-POTPで使用するために定義されています。
0 - Reserved for future use 1 - Version 2 - Server-Info 3 - OTP 4 - NAK 5 - New PIN 6 - Confirm 7 - Vendor-Specific 8 - Resume 9 - User Identifier 10 - Token Key Identifier 11 - Time Stamp 12 - Counter 13 - Keep-Alive 14 - Protected 15 - Crypto Algorithm 16 - Challenge
0 - バージョン2 - - サーバ情報3 - OTP 4 - NAK 5 - 新ピン6 - 7確認 - ベンダー固有8 - 再開9 - ユーザ識別子10 - トークン鍵識別子11 - タイムスタンプ12将来の使用の1のために予約します - カウンター13 - キープアライブ14 - 暗号アルゴリズム16 - - 15保護チャレンジ
These TLVs are defined in the following. With the exception of the NAK TLV, a particular TLV type MUST NOT appear more than once in a message of type POTP-X.
これらのTLVは、以下に定義されています。 NAK TLVを除いて、特定のTLVタイプはタイプPOTP-Xのメッセージに複数回現れてはなりません。
Length
長さ
The length of the Value field in octets.
オクテットで値フィールドの長さ。
Value
値
The value of the TLV.
TLVの値。
The Version TLV carries information about the supported EAP-POTP method version.
バージョンTLVは、サポートされているEAP-POTPメソッドのバージョンについての情報を運びます。
This TLV MUST be present in the initial EAP-Request of type POTP-X from the EAP server and in the initial response of type POTP-X from the peer. It MUST NOT be present in any subsequent EAP-Request or EAP-Response in the session. The Version TLV MUST be supported by all peers, and all EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV. The version negotiation procedure is described in detail in Section 4.2.
このTLVはEAPサーバからピアからタイプPOTP-Xの初期応答でタイプPOTP-Xの初期EAP-要求に存在していなければなりません。これは、セッション内の後続EAP要求またはEAP-応答中に存在してはなりません。バージョンTLVは、すべてのピアによってサポートしなければならない、とすべてのEAPサーバは、この仕様に準拠し、NAK TLVで応答してはなりません。バージョン交渉手順は4.2節に詳細に記載されています。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Highest | Lowest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1 - 必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
1
１
Length
長さ
3 in EAP-Requests, 2 in EAP-Responses
EAP-要求で3、EAP-応答で2
Reserved
予約済み
Reserved for future use. This octet MUST be set to zero for this version. Recipients SHALL ignore this octet for this version of EAP-POTP.
将来の使用のために予約されています。このオクテットは、このバージョンのためにゼロに設定する必要があります。受信者は、EAP-POTPのこのバージョンのために、このオクテットを無視しなければなりません。
Highest
最高
This field contains an unsigned integer representing the highest protocol version supported by the sender. If a value provided by a peer to an EAP server falls between the server's "Highest" and "Lowest" supported version (inclusive), then that value will be the negotiated version for the authentication session.
このフィールドは、送信側でサポートされている最上位のプロトコルバージョンを表す符号なし整数が含まれています。 EAPサーバへのピアによって提供された値は、サーバーの「最高」と「最低」サポートされているバージョン（包括的）の間にある場合、その値は、認証セッションのために交渉されたバージョンになります。
Lowest
最低
This field contains an unsigned integer representing the lowest version acceptable by the EAP server. The field MUST be present in an EAP-Request. The field MUST NOT be present in an EAP-Response. A peer SHALL respond to an EAP-Request of type POTP-X with an EAP-Response of type Nak (3) if the peer's highest supported version is lower than the value of this field.
このフィールドはEAPサーバによって許容される最小バージョンを表す符号なし整数を含んでいます。フィールドには、EAP-要求中に存在しなければなりません。フィールドには、EAP-応答中に存在してはなりません。ピアの最高サポートされているバージョンは、このフィールドの値よりも低い場合、ピアは、種類のNak（3）のEAP-応答でタイプPOTP-XのEAP-要求に応答しなければなりません。
This document defines version 1 of the protocol. Therefore, EAP server implementations conforming to this document SHALL set the "Highest" field to 1. Peer implementations conforming to this document SHALL set the "Highest" field to 1.
この文書は、プロトコルのバージョン1を定義します。したがって、本文書に準拠EAPサーバの実装は、「最高」フィールドを1に設定するものとし、この文書に準拠1.ピア実装に「最高」フィールドを設定しなければなりません。
The Server-Info TLV carries information about the EAP server and the session (when applicable). It provides one piece in the framework for fast session resumption.
サーバー情報TLVはEAPサーバとのセッション（該当する場合）についての情報を運びます。これは、高速セッション再開のための枠組みの中で一枚を提供します。
This TLV SHOULD always be present in an EAP-Request of type POTP-X that also carries an OTP TLV, as long as the peer has not been authenticated, and MUST be present in such a request if the server supports session resumption. It MUST NOT be present in any other EAP-Request of type POTP-X or in any EAP-Response packets. This TLV type MUST be supported by all peers conforming to this specification and MUST NOT be responded to with a NAK TLV (this is not to say that all peers need to support session resumption, only that they cannot respond to this TLV with a NAK TLV).
このTLVは、常にもあればピアが認証されていない、及びサーバがセッション再開をサポートする場合、このような要求に存在しなければならないように、OTP TLVを運ぶタイプPOTP-XのEAP-Requestに存在すべきです。これは、タイプPOTP-Xまたは任意のEAP-応答パケット内の他のEAP-Requestに存在してはなりません。このTLVタイプは、これは彼らがNAK TLVでこのTLVに応答しないことができる唯一のことを、すべてのピアがセッション再開をサポートする必要があるということではありません（この仕様に準拠するすべてのピアによってサポートしなければならないとNAK TLVで応答してはなりません）。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |N| Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sess.Id (cont.)| Nonce ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1 - 必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
2
２
Length
長さ
25 + length of Server Identifier field
25 +サーバ識別子フィールドの長さ
Reserved
予約済み
Reserved for future use. All 7 bits MUST be set to zero for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。すべての7ビットは、このバージョンのためにゼロに設定しなければなりません。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
N
ん
The N bit signals that the peer MUST NOT attempt to resume any session it has stored associated with this server.
ピアは、それがこのサーバに関連付けられて記憶されている任意のセッションを再開しようとしてはいけませんNビット信号。
Session Identifier
セッション識別子
An 8-octet identifier for the session about to be negotiated. Note that, in the case of session resumption, this session identifier will not be used (the session identifier for the resumed session will continue to be used).
交渉されようとしてセッションのための8オクテット識別子。セッションの再開の場合には、このセッション識別子が使用されないことに留意されたい（再開セッションのセッション識別子が使用され続けます）。
Nonce
使節
A 16-octet nonce chosen by the server. During session resumption, this nonce is used when calculating new K_ENC, K_MAC, SRK, MSK, and EMSK keys as specified below.
サーバによって選択された16オクテットナンス。下記の指定された新しいK_ENC、K_MAC、SRK、MSK、およびEMSKキーを計算するときにセッションの再開時には、このnonceが使用されています。
Server Identifier
サーバー識別子
An identifier for the authentication server. The peer MAY use this identifier to search for a stored session associated with this server, or to associate the session to be negotiated with the server. The value of the identifier SHOULD be chosen so as to reduce the risk of collisions with other EAP server identifiers as much as possible. One possibility is to use the DNS name of the EAP server. The identifier MAY also be used by the peer to select a suitable key on the OTP token (when there are multiple keys available).
認証サーバの識別子。ピアは、このサーバに関連付けられて記憶されたセッションを検索するための識別子を使用してもよいし、サーバとネゴシエートするセッションを関連付けます。可能な限り、他のEAPサーバ識別子との衝突の危険性を低減するように識別子の値が選択されるべきです。一つの可能性は、EAPサーバのDNS名を使用することです。識別子は、（利用可能な複数のキーがある）OTPトークンに適切なキーを選択するためにピアによって使用されてもよいです。
The identifier MUST NOT be longer than 128 octets. The identifier SHALL be a UTF-8 [7] encoded string of printable characters (without any terminating NULL character).
識別子は128オクテットよりも長くてはなりません。識別子は、（任意の終端NULL文字なし）印刷可能文字のUTF-8 [7]エンコードされた文字列でなければなりません。
In an EAP-Request, the OTP TLV is used to request an OTP (or a value derived from an OTP) from the peer. In an EAP-Response, the OTP TLV carries an OTP or a value derived from an OTP.
EAP-Requestに、OTP TLVは、ピアからOTP（またはOTPから導出される値）を要求するために使用されます。 EAP-応じて、OTP TLVはOTPまたはOTPから導出された値を運びます。
This TLV type MUST be supported by all peers and all EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV. The OTP TLV MUST NOT be present in an EAP-Request of type POTP-X that contains a New PIN TLV. Further, the OTP TLV MUST NOT be present in an EAP-Response of type POTP-X unless the preceding EAP-Request of type POTP-X contained an OTP TLV and it was valid for it to do so. Finally, an OTP TLV MUST NOT be present in an EAP-Response of type POTP-X that also contains a Resume TLV. The OTP TLV is defined as follows:
このTLVタイプはこの仕様に準拠するすべてのピアと、すべてのEAPサーバでサポートしなければならないとNAK TLVで応答してはなりません。 OTP TLVは、新しいPIN TLVが含まれているタイプPOTP-XのEAP-要求中に存在してはなりません。タイプPOTP-Xの前のEAP-要求がOTP TLVを含んでおり、それがそうすることが有効であった場合を除きさらに、OTP TLVはタイプPOTP-XのEAP-応答に存在してはなりません。最後に、OTP TLVも再開TLVが含まれているタイプPOTP-XのEAP-応答中に存在してはなりません。次のようにOTP TLVが定義されています。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |A|P|C|N|T|E|S| Pepper Length |Iteration Count|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Iteration Count (cont.) | Auth. Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1 - 必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
3
３
Length
長さ
7 + length of Authentication Data field
認証データフィールドの7 +長さ
Reserved
予約済み
Reserved for future use. All 9 bits SHALL be set to zero (0) for this version. Recipients SHALL ignore these bits for this version of EAP-POTP.
将来の使用のために予約されています。すべての9ビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのためにこれらのビットを無視しなければなりません。
A
A
The A bit MUST be set in an EAP-Request if and only if the request immediately follows an EAP-Response of type POTP-X containing a New PIN TLV (see Section 4.11.5), and the new PIN in the response was accepted by the EAP server. In this case, the A bit signals that the EAP-server has accepted the PIN, and that the peer SHALL use the newly established PIN when calculating the response (when applicable). The A bit MUST NOT be set if the S bit is set. If a request has both the S bit and the A bit set, the peer SHALL regard the request as invalid, and return an empty POTP-X EAP-Response message.
ビットがあれば、EAP-Requestに設定しなければならないと要求は直ちに新しいPIN TLVを含むタイプPOTP-X（セクション4.11.5を参照）のEAP-応答を、以下、それに応答して、新しいPINが受け入れられた場合にのみEAPサーバによって。この場合、Aは、EAPサーバがPINを受け付けた信号をビット、および応答を（該当する場合）算出する際にピアが新たに確立されたPINを使用しなければならないこと。 Sビットがセットされている場合、Aビットがセットされてはなりません。要求は、両方のSビットを有し、Aビットがセットした場合、ピアは、要求は無効としてみなし、そして空のPOTP-X EAP-Responseメッセージを返します。
In an EAP-Response, the A bit, when set, indicates that the OTP was calculated with the use of the newly selected user PIN. The A bit MUST be set in a response if and only if the EAP-Request which triggered the response contained an OTP TLV with the A bit set.
設定されたときにEAP-応答して、ビットは、OTPは、新たに選択されたユーザPINを用いて計算したことを示しています。応答の引き金EAP-要求がAとOTP TLVが含まれている場合にのみ場合にビットがセットビット応じて設定されなければなりません。
P
P
In an EAP-Request, the P bit indicates that the OTP in the response MUST be protected. Use of this bit also indicates that mutual authentication will take place, as well as generation of keying material. It is RECOMMENDED to always set the P bit. If a peer receives an EAP-Request with an OTP TLV that does not have the P bit set, and the peer's policy dictates protected mode, the peer MUST respond with an empty POTP-X EAP-Response message. All peers MUST support protected mode.
EAP-Requestに、Pビットは応答OTPを保護しなければならないことを示しています。このビットの使用は、相互認証が行われ、同様に材料をキーイングの世代を取ることを示しています。常にPビットを設定することを推奨します。ピアは、Pビットが設定されていないOTP TLVとEAP-Requestを受信して、ピアのポリシーが保護モードを指示した場合、ピアは空のPOTP-X EAP-Responseメッセージで応じなければなりません。すべてのピアは、保護モードをサポートしなければなりません。
In an EAP-Response, this bit indicates that the provided OTP has been protected (see below). The P bit MUST be set in a response (and hence the OTP MUST be protected) if and only if the EAP-Request that triggered the response contained an OTP TLV with the P bit set.
EAP-応答では、このビットは、（下記参照）が設けられてOTPが保護されていることを示しています。 Pビットが対応して設定されなければならない（従って、OTPは保護されなければならない）場合、応答をトリガEAP-要求は、PビットセットとOTP TLVを含んでいた場合にのみ。
In an 802.1x EAP over LAN (EAPOL) environment (this includes wireless LAN environments), the P bit MUST be set, or, alternatively, the EAP-POTP method MUST be carried out inside an authenticated tunnel that provides a cryptographic binding with inner EAP methods such as the one provided by PEAPv2 [17].
802.1X LAN上EAP（EAPOL）環境（これは無線LAN環境を含む）、Pビットを設定する必要があり、または、代替的に、EAP-POTP方法は、内側との結合暗号化を提供する認証されたトンネルの内部に行わなければなりませんそのようなPEAPv2 [17]によって提供されるものとEAPメソッド。
C
C
The C bit carries meaning only when the OTP algorithm in question makes use of server challenges. For other OTP algorithms, the C bit SHALL always be set to zero.
Cビットは、問題のOTPアルゴリズムは、サーバ上の課題を使用するときにだけ意味を運びます。他のOTPアルゴリズムのために、Cビットは常にゼロに設定されなければなりません。
In an EAP-Request, the C bit ("Combine") indicates that the OTP SHALL be calculated using both the provided challenge and internal state (e.g., current token time). The OTP SHALL be calculated based only on the provided challenge (and the shared secret) if the C bit is not set, and a challenge is present. The returned OTP SHALL always be calculated based on the peer's current state (and the shared secret) if no challenge is present. If the C bit is set but no challenge is provided, the peer SHALL regard the request as invalid, and return an empty POTP-X EAP-Response message.
EAP-Requestに、Cビット（「結合」）OTPを提供課題と内部状態（例えば、現在のトークン時間）の両方を使用して計算しなければならないことを示しています。 Cビットが設定され、課題が存在していない場合OTPのみ提供さチャレンジ（および共有秘密）に基づいて計算します。何の課題が存在しない場合に返さOTPは、常に、ピアの現在の状態（および共有秘密）に基づいて計算しなければなりません。 Cビットが設定されていないチャレンジが提供されない場合、ピアは無効として要求を捉え、そして空のPOTP-X EAP-Responseメッセージを返します。
In an EAP response, this bit indicates that the provided OTP has been calculated using a provided challenge and the token state. The C bit MUST be set in a response if and only if the EAP-Request that triggered the response contained an OTP TLV with the C bit set and a challenge.
EAP応答では、このビットは、提供OTPを設けチャレンジトークン状態を使用して計算されたことを示します。 Cビットがあれば対応して設定しなければならなくて、応答の引き金EAP-要求は、CとOTP TLVを含んでいた場合にのみ、設定されたビットと挑戦。
N
ん
In an EAP-Request, the N bit, when set, indicates that the OTP to calculate SHALL be based on the next token "state", and not the current one. As an example, for a time-based token, this means the next time slot. For an event-based token, this could mean the next counter value, if counter values are used. This bit will normally not be set in initial EAP-Request messages, but may be set in subsequent ones. Further, the N bit carries no meaning in an EAP-Request if a challenge is present and the C bit is not set, and SHALL be set to 0, in this case. If a request that has the N bit set also contains a challenge, but does not have the C bit set, the peer SHALL regard the request as invalid, and return an empty POTP-X EAP-Response message. Note that setting the N bit in an EAP-Request will normally advance the internal state of the token.
EAP-Requestに、Nビット、セットは、OTPは、次のトークン「状態」ではなく現在の一方に基づかなければならない計算することを示しています。一例として、時間ベースのトークンのために、これが次のタイムスロットを意味します。カウンタ値が使用される場合、イベントベースのトークンの場合、これは、次のカウンタ値を意味し得ます。このビットは、通常、最初のEAP-Requestメッセージ内に設定されませんが、それ以降のものに設定することができます。課題が存在し、Cビットがセットされておらず、この場合には、0に設定されなければならない場合、更に、NビットはEAP-Requestには意味を運びません。 Nを持つ要求ビットが設定されている場合も挑戦が含まれていますが、Cビットが設定されていない、ピアは無効として、要求を捉え、そして空のPOTP-X EAP-Responseメッセージを返します。 EAP-RequestにNビットを設定すると、通常トークンの内部状態を進めることに留意されたいです。
In an EAP-Response, the N bit, when set, indicates that the OTP was calculated based on the next token "state" (as explained above), and not the current one. The N bit MUST be set in a response if and only if the EAP-Request that triggered the response contained an OTP TLV with the N bit set.
EAP-応答では、Nビット、セットは、OTPは、現在のいずれかを（上述したように）次のトークン「状態」に基づいて算出し、されなかったことを示しています。 Nビットがあれば対応して設定しなければならなくて、応答の引き金EAP-要求は、NビットセットとOTP TLVを含んでいた場合にのみ。
T
T
The T bit only carries meaning for OTP methods normally incorporating a user PIN in the OTP computation.
Tビットは、通常、OTP計算におけるユーザPINを組み込んだOTP方法に意味運びます。
In an EAP-Request, the T bit, when set, indicates that the OTP to calculate MUST NOT include a user PIN.
EAP-Requestに、Tビット、セットは、OTPは、ユーザPINを含めることはできません計算することを示しています。
In an EAP-Response, the T bit, when set, indicates that the OTP was calculated without the use of a user PIN. The T bit MUST be set in a response if and only if the EAP-Request that triggered the response contained an OTP TLV with the T bit set. Note that client policy may prohibit PIN-less calculations; in these cases, the client MAY respond with an empty POTP-X EAP response message.
EAP-応答して、Tビット、セットは、OTPは、ユーザPINを使用せずに計算したことを示しています。 Tビットがあれば対応して設定しなければならなくて、応答の引き金EAP-要求は、TビットセットとOTP TLVを含んでいた場合にのみ。クライアントポリシーは、PIN-以下の計算を禁止することができることに注意してください。これらのケースでは、クライアントは空のPOTP-X EAP応答メッセージで応答することができます。
E
絵
In an EAP-Request, the E bit, when set, indicates that the peer MUST NOT use any stored pepper value associated with this server in the PBKDF2 computation. Rather, it MUST generate a new pepper (if supported by the peer) and/or use the iteration count parameter to protect the OTP (if the server's Max Pepper Length is 0, then the peer MUST rely on the iteration count only to protect the OTP). This bit will usually not be set in initial EAP-Request messages, but may be set in subsequent ones, e.g., if the server, upon receipt of an OTP TLV with a pepper identifier, detects that it does not have a pepper with that identifier in storage. This bit carries no meaning, and MUST be set to zero, when the P bit is not set. If a request has the E bit set but not the P bit, a peer SHALL regard the request as invalid, and return an empty POTP-X EAP-Response message.
EAP-Requestに、Eビット、セットは、ピアがPBKDF2計算で、このサーバに関連付けられた任意の格納されたコショウ値を使用してはならないことを示しています。むしろ、それは（ピアでサポートされている場合）は、新しいコショウを生成および/またはサーバの最大ペッパーの長さが0の場合（OTPを保護するために、反復回数パラメータを使用する必要があり、その後、ピアが唯一保護するために、反復回数に依存しなければなりませんOTP）。サーバは、コショウ識別子とOTP TLVを受け取ると、それはその識別子とコショウを持っていないことを検出した場合、このビットは、例えば、通常は最初のEAP-Requestメッセージ内に設定されませんが、それ以降のものに設定することができますストレージインチこのビットは意味を運ばない、とPビットがセットされていない場合、ゼロに設定しなければなりません。要求がEに設定されたビットではなく、Pビットを有する場合、ピアは、要求は無効としてみなし、そして空のPOTP-X EAP-Responseメッセージを返します。
In an EAP-Response, the E bit indicates that the response has been calculated without use of any stored pepper value.
EAP-応答では、Eビットは、応答は、任意の格納されたコショウ値を使用せずに計算されていることを示しています。
S
S
In an EAP-Request, the S bit ("Same"), when set, indicates that the peer SHOULD calculate its response based on the same OTP value as was used for the preceding response. This bit MAY be set when the EAP server has received an OTP TLV from the peer protected with a pepper, of which the server is no longer in possession. Since the server has not attempted validation of the provided data, there is no need for the EAP peer to retrieve a new OTP value. This bit carries no meaning, and MUST be set to zero, when the E bit is not set. A peer SHALL regard a request where the S bit is set, but not the E bit, as invalid, and return an empty POTP-X EAP-Response message. Further, the S bit MUST NOT be set when the A bit also is set; see above.
EAP-Requestに、Sビット（「同じ」）、セットは、ピアが先行する反応のために使用したのと同じOTP値に基づいて応答を計算する必要があることを示します。 EAPサーバは、サーバが所有しなくなったそのコショウ、で保護ピアからOTP TLVを受信したとき、このビットを設定することができます。サーバが提供されたデータの検証をしようとしていないので、新しいOTP値を取得するために、EAPピアの必要はありません。このビットは意味を運ばない、とEビットがセットされていない場合、ゼロに設定しなければなりません。ピアは、Sビットが設定されているリクエストを考えたが、Eビット、無効ではない、空のPOTP-X EAP-Responseメッセージを返します。ビットも設定されている場合、さらに、Sビットが設定されてはいけません。上記を参照。
In an EAP-Response, the S bit is never set.
EAP-応答では、Sビットがセットされることはありません。
Pepper Length
ペッパーの長さ
This octet SHALL be present if and only if the P bit is set. When present, it contains an unsigned integer, having a value between 0 and 255 (inclusive). In an EAP-Request, the integer represents the maximum length (in bits) of a client-generated pepper the server is prepared to search for. Peers MUST NOT generate peppers longer than this value. If the value is set to zero, it means the peer MUST NOT generate a pepper for the PBKDF2 calculation. In an EAP-Response, it indicates the length of the used pepper.
Pビットが設定されている場合にのみ場合、このオクテットが存在しなければなりません。存在する場合、それは0から255（両端を含む）の間の値を持つ、符号なし整数を含んでいます。 EAP-Requestに、整数（ビットで）サーバを検索するために用意されているクライアントで生成された胡椒の最大長さを表します。ピアはこの値より長いピーマンを生成してはなりません。値がゼロに設定されている場合は、ピアがPBKDF2計算のためにコショウを生成しないなければならないことを意味します。 EAP-応答して、それが使用されるコショウの長さを示します。
Iteration Count
反復回数
These 4 octets SHALL be present if and only if the P bit is set. When present, they contain an unsigned, 4-octet integer in network byte order. In an EAP-Request, the integer represents the maximum iteration count the peer may use in the PBKDF2 computation. Peers MUST NOT use iteration counts higher than this value. In an EAP-Response, it indicates the actual iteration count used.
Pビットがセットされている場合にのみ場合、これらの4つのオクテットが存在しなければなりません。存在する場合、それらはネットワークバイト順に符号のない、4オクテットの整数を含みます。 EAP-Requestに、整数は、最大反復がピアがPBKDF2計算に使用することがカウントを表します。ピアはこの値よりも高い反復カウントを使用してはなりません。 EAP-応答では、それが使用される実際の反復回数を示します。
Note regarding the Pepper Length and Iteration Count parameters: A peer MUST compare these policy parameters provided by the EAP server with local policy and MUST NOT continue the handshake if use of the EAP server's suggested parameters would result in a lower security than the client's acceptable policy. If the security given by the EAP server's provided policy parameters surpasses the security level given by the peer's local policy, the client SHOULD use the server's parameters (subject to reason - active attackers could otherwise mount simple denial-of-service attacks against peers or servers, e.g., by providing unreasonably high values for the iteration count). Note that the server-provided parameters only apply to the case where the peer cannot use or does not have a previously provided server-provided pepper. If a peer cannot continue the handshake due to the server's policy being unacceptable, it MUST return an empty POTP-X EAP-Response message.
ペッパーの長さと反復に関する注記は、パラメータを数：ピアがローカルポリシーでEAPサーバが提供するこれらのポリシーのパラメータを比較しなければならないとEAPサーバの提案パラメータの使用は、クライアントの許容可能な政策よりも低いセキュリティにつながる場合は握手を続けてはなりません。そうでない場合は、ピアまたはサーバに対して、単純なDoS攻撃をマウントすることができ、アクティブ攻撃者 - EAPサーバの提供ポリシーパラメータによって与えられたセキュリティは、ピアのローカルポリシーによって与えられたセキュリティレベルを超えた場合、クライアントは、サーバのパラメータ（理由の対象を使用すべきです例えば、）反復カウントのために不当に高い値を提供することもできます。サーバーが提供するパラメータのみピアが使用できないか、以前に提供され、サーバが提供するコショウを持っていない場合に適用されることに注意してください。ピアは、サーバのポリシーが受け入れられないことに起因するハンドシェイクを続けることができない場合は、空のPOTP-X EAP-Responseメッセージを返さなければなりません。
Authentication Data
認証データ
EAP-Request: In an EAP-Request, the Authentication Data field, when present, contains an optional "challenge". The challenge is an octet string that SHOULD be uniquely generated for each request in which it is present (i.e., it is a "nonce"), and SHOULD be 8 octets or longer. To avoid fragmentation (i.e., EAP messages longer than the minimum EAP MTU size; see [1]), the challenge MUST NOT be longer than 64 octets. When the challenge is not present, the OTP will be calculated on the current token state only. The peer MAY ignore a provided challenge if and only if the OTP token the peer is interacting with is not capable of including a challenge in the OTP calculation. In this case, EAP server policies will determine whether or not to accept a provided OTP value.
EAP-要求：EAP-要求、認証データフィールドには、存在する場合、オプションの「挑戦」が含まれています。チャレンジ（すなわち、それは「一回だけ」である）を一意それが存在する各要求に対して生成されるべきオクテットストリングであり、8オクテット以上であるべきです。断片化を回避するために、チャレンジは、64オクテットよりも長くてはいけません（すなわち、最小EAP MTUサイズより長いEAPメッセージ[1]参照します）。課題が存在しない場合は、OTPは、現在のトークンの状態に基づいて計算されます。ピアは、ピアがと相互作用しているOTPトークンはOTP計算にチャレンジを含むことができない場合にのみ提供されるチャレンジを無視してもよいです。この場合、EAPサーバのポリシーが提供さOTP値を受け入れるかどうかを決定します。
EAP-Response: The following applies to the Authentication Data field in an EAP-Response:
EAP-応答：以下は、EAP-応答した認証データフィールドに適用されます。
* When the P bit is not set, the peer SHALL directly place the OTP value calculated by the token in the Authentication Data field. In this case, the EAP server MUST NOT send a Confirm
Pビットがセットされていない場合*、ピアは直接認証データフィールド内のトークンによって算出OTP値を配置するものとします。この場合、EAPサーバは確認を送ってはいけません
TLV upon successful authentication of the peer (instead, it sends an EAP-Success message).
TLVは、ピアの認証が成功すると（その代わり、それはEAP-Successメッセージを送信します）。
* When the P bit is set, the peer SHALL populate this field as follows. After the token has calculated the OTP value, the peer SHALL compute:
* Pビットがセットされると、次のように、ピアはこのフィールドをポピュレートSHALL。トークンはOTP値を計算した後、ピアが計算しなければなりません。
K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(otp, salt | pepper
| auth_id, iteration_count, key_length)
where
どこ
"|" denotes concatenation,
"|"連結を意味し、
"otp" is the already computed OTP value,
「OTP」は、すでに計算されたOTP値であり、
"salt" is a 16-octet nonce,
「塩」、16オクテットナンスです
"pepper" is an optional nonce (at most, 255 bits long, and, if necessary, padded to be a multiple of 8 bits long; see below) included to complicate the task of finding a matching "otp" value for an attacker,
「ペッパー」は任意ノンスである（255ビット長せいぜい、および、必要に応じて、8ビット長の倍数になるようにパディング;下記参照）攻撃者マッチング「OTP」値を求める作業を複雑にするために含まれ、
"auth_id" is an identifier (at most, 255 octets in length) for the authenticator (i.e., the network access server) as reported by lower layers and as specified below,
識別子である「AUTH_ID」（最大で、長さが255オクテット）オーセンティケータのために（すなわち、ネットワークアクセスサーバ）下位層によって報告下記指定されたように、
"iteration_count" is an iteration count chosen such that the computation time on the peer is acceptable (based on the server's indicated policy and the peer's local policy), while an attacker, having observed the response and initiating a search for a matching OTP, will be sufficiently slowed down. The "iteration_count" value MUST be chosen to provide a suitable level of protection (e.g., at least 100,000) unless a server-provided pepper is being used, in which case, it SHOULD be 1.
攻撃者は、レスポンスと一致するOTPの検索を開始を観察しながら「繰返しの回数は」（サーバの指示されたポリシーとピアのローカルポリシーに基づいて）ピアの計算時間が許容可能であるように選択された反復回数が意志、あります十分に遅くなります。 「繰返しの回数」の値は、サーバーが提供するコショウが使用されていない限り、その場合、それは1であるべきである（例えば、少なくとも100,000個）の保護の適切なレベルを提供するように選択されなければなりません。
"key_length" is the combined length of the desired key material, in octets. When the default algorithms are used, key_length is 176.
「key_length」はオクテットで、所望のキー材料の組み合わせた長さです。デフォルトのアルゴリズムが使用されている場合は、key_lengthは176です。
The "pepper" values are only included in PBKDF2 calculations and are never sent to EAP servers (though the peers do send their length, in bits). The purpose of the pepper values are, as mentioned above, to slow down an attacker's search for a matching OTP, while not slowing down the peer (which iterated hashes do). If the pepper has been generated by the peer, and the chosen pepper length in bits is not a multiple of 8, then the pepper value SHALL be padded to the left, with '0' bits to the nearest multiple of 8 before being used in the PBKDF2 calculation. This is to ensure the input to the calculation consists only of whole octets. As an example, if the chosen pepper length is 4, the pepper value will be padded to the left, with 4 '0' bits to form an octet before being used in the PBKDF2 calculation.
「コショウ」値のみがPBKDF2計算に含まれており、（ピアはビットで、その長さを送ってやるが）EAPサーバに送信されることはありません。 （ハッシュが行う反復）ピアを遅くないが、一致するOTPのための攻撃者の検索を遅くするために、上述したようにコショウ値の目的は、です。唐辛子は、ピアによって生成され、そしてビットで選択されたコショウの長さが8の倍数でない場合、コショウ値に使用される前に8の最も近い倍数に「0」ビットで、左側に埋められる場合PBKDF2計算。これは、計算への入力だけで、全体のオクテットで構成されて保証することです。選択されたコショウの長さが4である場合の例として、コショウ値がPBKDF2計算に使用される前にオクテットを形成する4と、左側に「0」のビットをパディングします。
When pepper is used, it is RECOMMENDED that the length of the pepper and the iteration count are chosen in such a way that it is computationally infeasible/unattractive for an attacker to brute-force search for the given OTP within the lifetime of that OTP.
唐辛子を使用する場合には、コショウの長さと繰り返し回数は、それがそのOTPの寿命内所定のOTPの検索力ブルートする攻撃者にとって魅力/計算上不可能であるように選択することをお勧めします。
As mentioned previously, a peer MUST NOT include a newly generated pepper value in the PBKDF2 computation if the server did not indicate its support for pepper searching in this session. If the server did not indicate support for pepper searching, then the PBKDF2 computation MUST be carried out with a sufficiently higher number of iterations so as to compensate for the lack of pepper (see further Appendix D).
前述したように、サーバはこのセッションで検索唐辛子の支持を示すものではありませんでした場合、ピアはPBKDF2計算で新たに発生したコショウ値を含んではいけません。サーバはコショウの検索のためのサポートを示すものではありませんでした場合はコショウの不足を補うように、その後、PBKDF2計算は、（さらに、付録Dを参照してください）反復十分に高い数字で行わなければなりません。
A server may, in an earlier session, have transferred a pepper value to the peer in a Confirm TLV (see below). When this is the case, and the peer still has that pepper value stored for this server, the peer MUST NOT generate a new pepper but MUST, instead, use this transferred pepper value in the PBKDF2 calculations. The only exception to this is when a local policy (e.g., timer) dictates that the peer must switch to a new pepper (and the server indicated support for pepper searching).
サーバは、以前のセッションで、確認TLV（下記参照）内のピアにコショウ値を転送してもよいです。このような場合は、ピアは、まだこのサーバーに格納されているコショウ値を持っている場合、ピアは新しいコショウを発生させてはいけませんけど、その代わり、PBKDF2計算で、この転送コショウ値を使用しなければなりません。ローカルポリシー（例えば、タイマ）ピアが新しいコショウ（コショウ検索用サーバ示さサポート）に切り替える必要があることを指示した場合にこれに対する唯一の例外はあります。
The following applies to the auth_id component:
以下はAUTH_IDコンポーネントに適用されます。
- For dial-up, "auth_id" SHALL be either the empty string or the phone number called by the peer. The phone number SHALL be specified in the form of a URL conformant with RFC 3966 [8], e.g., "tel:+16175550101". Processing of received phone numbers SHALL be conformant with RFC 3966 (this assumes that "tel" URIs will be shorter than 256 octets, which would normally be the case).
- ダイヤルアップの場合は、空の文字列またはピアによって呼び出された電話番号のいずれかでなければならない「AUTH_ID」。電話番号は、RFC 3966に準拠URLの形で規定されなければならない[8]、例えば、「TEL：16175550101」。受け取った電話番号の処理は、（これは「TEL」URIは通常のケースであると思われる、256オクテットよりも短くなることを想定して）RFC 3966に準拠するものとします。
- For use with IEEE 802.1X, "auth_id" SHALL be either the empty string or the MAC address of the authenticator in canonical binary format (6 octets).
- IEEE 802.1Xで使用する場合、空の文字列または正規バイナリ形式（6つのオクテット）でオーセンティケータのMACアドレスのいずれかでなければならない「AUTH_ID」。
- For IP-based EAP, "auth_id" SHALL be either the empty string or the IPv4 or IPv6 address of the authenticator as seen by the peer and in binary format (4 or 16 octets, respectively). As an example, the IPv4 address "192.0.2.5" would be represented as (in hex) C0 00 02 05, whereas the IPv6 address "2001:DB8::101" would be represented as (in hex) 20 01 0D B8 00 00 00 00 00 00 00 00 00 00 01 01.
- IPベースのEAPについては、「AUTH_ID」空の文字列またはピアによって、バイナリ形式（それぞれ4つのまたは16オクテット）に見られるように、オーセンティケータのIPv4またはIPv6アドレスのいずれかでなければなりません。一例として、IPv4アドレス "192.0.2.5" は、IPv6アドレスのに対し（16進数）C0 00 02 05、として表されることになる "2001：DB8 :: 101" は、20 01 0DのB8 00（16進数）として表現されます00 00 00 00 01 01 00 00 00 00 00。
Note: Use of the authenticator's identifying information within the computation aids in protection against man-in-the-middle attacks, where a rogue authenticator seeks to intercept and forward the Authentication Data in order to impersonate the peer at a legitimate authenticator (but see also the discussion around spoofed authenticator addresses in Section 6). For these reasons, a peer SHOULD NOT set the auth_id component to the empty string unless it is unable to learn the identifying information of the authenticator. In these cases, the EAP server's policy will determine whether or not the session may continue.
注意：不正なオーセンティケータは、認証データを傍受して転送しようとするman-in-the-middle攻撃、防御における演算補助内のオーセンティケータの識別情報の使用して、正当な認証システムでピアになりすます（だけでなく、参照するために、議論は周り）第6節では、オーセンティケータアドレスを偽装されました。オーセンティケータの識別情報を知ることができない場合を除き、これらの理由のために、ピアは、空の文字列にAUTH_IDコンポーネントを設定しないでください。これらのケースでは、EAPサーバの方針は、セッションが継続しているか否かを判断します。
As an example, when otp = "12345678", salt = 0x54434534543445435465768789099880, pepper is not used, auth_id = "192.0.2.5", iteration_count = 2000 (decimal), and key_length = 176 (decimal), the input to the PBKDF2 calculation will be (first two parameters in hex, line wrap for readability):
例えば、ように、OTP = "12345678"、塩= 0x54434534543445435465768789099880、コショウが使用されていない、AUTH_ID = "192.0.2.5"、繰返しの回数= 2000（10進数）、及びkey_length = 176（10進数）、PBKDF2計算への入力は、意志（16進数での最初の2つのパラメータ、読みやすくするために行の折り返し）すること：
(3132333435363738, 54434534543445435465768789099880 | c0000205, 2000, 176)
（3132333435363738、54434534543445435465768789099880 | c0000205、2000、176）
As described, when the default algorithms are used, K_MAC is the first 16 octets of the output from PBKDF2, K_ENC the next 16 octets, MSK the following 64 octets, EMSK the next 64 octets, and SRK the final 16 octets. Using K_MAC, the peer calculates:
説明したように、デフォルトのアルゴリズムが使用される場合、K_MACはPBKDF2、K_ENC次の16オクテット、MSK次の64オクテット、EMSK次の64オクテット、及びSRK最後の16個のオクテットからの出力の最初の16オクテットです。 K_MACを使用して、ピアは計算します。
mac = MAC(K_MAC, msg_hash(msg_1, msg_2, ..., msg_n))
MAC = MAC（K_MAC、msg_hash（msg_1、msg_2、...、msg_n））
as specified in Section 4.9 and where msg_1, msg_2, ..., msg_n is a sequence of all EAP messages of type POTP-X exchanged so far in this session, as sent and received by the peer (for the peer's initial MAC, it will typically be just one message: the EAP server's initial EAP-Request of type POTP-X).
4.9節で指定され、それは、ピアの初期MAC用（ピアによって送受信された通りであるmsg_1、msg_2、...、msg_nは、このセッションでは、これまでのタイプPOTP-XのすべてのEAPメッセージのシーケンスで交換されますタイプPOTP-XのEAPサーバの初期EAP-要求）：一般的に一つだけのメッセージになります。
The peer then places the first 16 octets of "mac" in the Authentication Data field, followed by the "salt" value, followed by one octet representing the length of the "auth_id" value in octets, followed by the actual "auth_id" value in binary form, and optionally followed by a pepper identifier (only when the peer made use of a pepper value previously provided by the EAP server). Pepper identifiers, when present, are always 4 octets. All variables SHALL be present in the form they were input to the PBKDF2 algorithm. This will result in the Authentication Data field being 33 + (length of auth_id in octets) + (4, for pepper identifier, when present) octets in length.
ピアは、実際の「AUTH_ID」値が続くオクテット「AUTH_ID」の値の長さを表す1つのオクテットに続く「塩」値、続いて、認証データフィールドに「MAC」の最初の16個のオクテットを配置しますバイナリ形式で、及び任意に（ピアが以前にEAPサーバによって提供されるコショウ値を使用したときのみ）コショウ識別子が続きます。ペッパー識別子は、存在する場合、常に4つのオクテットです。すべての変数は、彼らがPBKDF2アルゴリズムに入力された形で存在しなければなりません。これは、33 +（オクテットでAUTH_IDの長さ）+である認証データフィールド（コショウ識別子4を、存在する）長のオクテットをもたらすであろう。
Continuing the previous example, the Authentication Data field will be populated with (in hex, line wrap for readability):
前の例を続けると、認証データフィールドは、（16進数、読みやすくするためのラインラップで）が移入されます。
< 16 octets of mac > | 54434534543445435465768789099880 | 04 | c0000205
<MACの16オクテット> | 54434534543445435465768789099880 | 04 | c0000205
Note: Since in this case (i.e., when the P bit is set) successful authentication of the peer by the EAP server will be followed by the transmission of an EAP-Request of type POTP-X containing a Confirm TLV for mutual authentication, the peer MUST save either all the input parameters to the PBKDF2 computation or the keys K_MAC, K_ENC, SRK, MSK, and EMSK (recommended, since they will be used later). This is because the peer cannot be guaranteed to be able to generate the same OTP value again. For the same reason (the Confirm-TLV from the EAP server), the peer MUST also store either the hash of the contents of the sent EAP-Response or the EAP-Response itself (but see the note above about not including any User Identifier TLVs in the hash computation).
注：この場合のため（すなわち、Pビットがセットされている）EAPサーバによってピアの成功した認証は、相互認証のための確認TLVを含むタイプPOTP-XのEAP-要求の送信が続きます、ピアは全てPBKDF2計算への入力パラメータまたはキーK_MAC、K_ENC、SRK、MSK及びEMSK（これらは後に使用されるため、推奨）のいずれかを保存する必要があります。ピアが再び同じOTP値を生成することができるように保証することができないためです。同じ理由（EAPサーバから確認-TLV）のために、ピアはまた、いずれかの送信されたEAP-応答またはEAP-応答自体の内容のハッシュを格納しなければならない（ただし、約任意のユーザ識別子を含まない上に注を参照しますハッシュ計算でのTLV）。
Given a set of possible OTP values, the authentication server verifies an authentication request from the peer by computing
可能なOTP値のセットが与えられると、認証サーバは、計算することによって、ピアからの認証要求を検証します
K_MAC' | K_ENC' | MSK' | EMSK' | SRK' = PBKDF2 (otp', salt | pepper' | auth_id, iteration_count, key_length)
K_MAC」| K_ENC」| MSK」| EMSK」| SRK '= PBKDF2（OTP'、塩|コショウ」| AUTH_ID、繰返しの回数、key_length）
for each possible OTP value otp' and each possible pepper value pepper' , and the provided values for salt, authenticator identity, and iteration count, as well as the applicable key length (default: 176). Note: Doing the computation for each possible pepper value implements the pepper search mentioned elsewhere in this document. Note also that the EAP server may accept more than one OTP value at a given time, e.g., due to clock drift in the token. If the given pepper length is not a multiple of 8, each tested pepper value will be padded to the left to the nearest multiple of 8, in the same manner as was done by the peer. If the server already shares a secret pepper value with this peer, then obviously there will only be one possible pepper value, and the server will find it based on the pepper_identifier provided by the peer. The server SHALL send a new EAP-Request of type POTP-X with an OTP TLV with the E bit set if the peer provided a pepper identifier unknown to the server.
それぞれの可能なOTP値OTP「とそれぞれの可能コショウ値コショウ」、および塩、オーセンティケータのアイデンティティ、および反復回数のため提供される値と同様に、該当するキーの長さ（：176デフォルト）。注：それぞれの可能コショウ値の計算を行うが、この文書の他の場所で言及した唐辛子の検索を実装しています。 EAPサーバが原因トークンにおけるクロックドリフトを、例えば、所与の時間に複数のOTP値を受け入れることもあることに注意してください。所与コショウの長さが8の倍数でない場合、各試験コショウ値は、ピアによって行われたと同様に、8の最も近い倍数に左側にパディングされます。サーバがすでにこのピアとの秘密のコショウ値を共有する場合は、明らかにそこに一つだけの可能なコショウ値となり、サーバは、ピアが提供するpepper_identifierに基づいて、それを見つけるでしょう。ピアはサーバに未知コショウ識別子を提供された場合、Eは、ビットセットとサーバがOTP TLVとタイプPOTP-Xの新しいEAP-Requestを送信しなければなりません。
For each K_MAC', the EAP server computes
各K_MAC」、EAPサーバを計算するために
mac' = MAC(K_MAC', msg_hash(msg_1', msg_2', ..., msg_n'))
MAC '= MAC（K_MAC'、msg_hash（msg_1' 、msg_2' 、...、msg_n '））
where MAC is the negotiated MAC algorithm, msg_hash is the message hash algorithm defined in Section 4.9, and msg_1', msg_2', ... msg_n' are the same messages on which the peer calculated its message hash, but this time, as sent and received by the EAP server. If the first 16 octets of mac' matches the first 16 octets in the Authentication Data field of the EAP-Response in question, and the provided authenticator identity is acceptable (e.g., matches the EAP server's view of the authenticator's identity), then the peer is authenticated.
送信されたとしてMACは交渉さMACアルゴリズムであり、msg_hashは、4.9節、およびmsg_1' 、msg_2' で定義されたメッセージのハッシュアルゴリズムである... msg_n」、ピアがそのメッセージのハッシュを計算したのと同じメッセージですが、今回はどこそして、EAPサーバが受信しました。マックの最初の16個のオクテットは、」問題のEAP-応答の認証データフィールドの最初の16個のオクテットに一致し、提供するオーセンティケータのアイデンティティが受け入れ可能である場合（例えば、オーセンティケータのアイデンティティのEAPサーバのビューと一致した）、その後、ピア認証されます。
If the authentication is successful, the authentication server then attempts to authenticate itself to the peer by use of the Confirm TLV (see below). If the authentication fails, the EAP server MAY send another EAP-Request of type POTP-X containing an OTP TLV to the peer, or it MAY send an EAP-Failure message (in both cases, possibly preceded by an EAP-Request of type Notification).
認証が成功した場合、認証サーバは、（下記参照）の確認TLVを使用してピアに対して自分自身を認証しようとします。認証が失敗した場合、EAPサーバはピアにOTP TLVを含むタイプPOTP-Xの別のEAP-要求を送信することができる、またはそれは（両方の場合において、おそらくタイプのEAPリクエストが先行EAP-失敗メッセージを送信することができます通知）。
Presence of this TLV indicates that the peer did not support a received TLV with the M bit set. This TLV may occur 0, 1, or more times in an EAP-Response of type POTP-X. Each occurrence flags the non-support of a particular received TLV.
このTLVの存在は、ピアがMビットセットで受信TLVをサポートしていないことを示しています。このTLVはタイプPOTP-XのEAP-応答で0、1、または複数回発生する可能性があります。各出現フラグは、特定の非サポートは、TLVを受けました。
The NAK TLV MUST be supported by all peers and all EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV. Receipt of a NAK TLV by an EAP server MAY cause an authentication to fail, and the EAP server to send an EAP-Failure message to the peer.
NAK TLVは、すべてのピアとこの仕様に準拠するすべてのEAPサーバでサポートしなければならないとNAK TLVで応答してはなりません。 EAPサーバによってNAK TLVの領収書は、認証が失敗する可能性があり、およびEAPサーバは、ピアへのEAP失敗メッセージを送信します。
Note: The definition of the NAK TLV herein matches the definition made in [17], and has the same type number. Field descriptions are copied from that document, with some minor modifications.
注：NAK TLVの定義は、本明細書[17]で行った定義と一致し、同じタイプの番号を有しています。フィールドの説明は、いくつかのマイナーな修正を加えて、そのドキュメントからコピーされます。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK-Type | TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1 - 必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
4
４
Length
長さ
6 + cumulative total length of embedded TLVs
埋め込みのTLVの6 +累計長さ
Vendor-Id
ベンダーID
The Vendor-Id field is 4 octets, and contains the Vendor-Id of the TLV that was not supported. The high-order octet is 0 and the low-order 3 octets are the Structure of Management Information (SMI) Network Management Private Enterprise Code of the Vendor in network byte order. The Vendor-Id field MUST be zero for TLVs that are not Vendor-Specific TLVs. For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI code.
ベンダーIDフィールドは4つのオクテットで、サポートされていなかったTLVのベンダーIDが含まれています。上位オクテットは0で、下位3つのオクテットはネットワークバイトオーダーにベンダーの経営情報の構造（SMI）ネットワーク管理プライベートエンタープライズコードです。ベンダーIDフィールドは、ベンダー固有のTLVがないTLVのためのゼロでなければなりません。ベンダー固有のTLVのために、ベンダーIDは、SMIコードに設定しなければなりません。
NAK-Type
NAK-タイプ
The type of the unsupported TLV. The TLV MUST have been included in the most recently received EAP message.
サポートされていないTLVのタイプ。 TLVは、最近受信EAPメッセージに含まれている必要があります。
TLVs
TLV
This field contains a list of TLVs, each of which MUST NOT have the mandatory bit set. These optional TLVs can be used in the future to communicate why the offending TLV was determined to be unsupported.
このフィールドは必須ビットセットを持ってはいけませんそれぞれのTLVのリストが含まれています。これらの任意のTLVは、TLV問題がサポートされていないことが決定された理由を通信するために、将来的に使用することができます。
In an EAP-Request, the New PIN TLV is used to request a new user PIN from the peer. The EAP server MAY provide a new PIN, as described below. In an EAP-Response, the New PIN TLV carries a chosen new user PIN. This TLV may be used by an EAP server when policy dictates that the peer (user) needs to change a PIN associated with the OTP Token.
EAP-要求では、新しいPIN TLVは、ピアから新しいユーザPINを要求するために使用されます。後述のようにEAPサーバは、新しいPINを提供することができます。 EAP-応答では、新しいPIN TLVは、選択された新しいユーザPINを運びます。ポリシーは、ピア（ユーザ）OTPトークンに関連付けられたPINを変更する必要があることを指示したとき、このTLVはEAPサーバによって使用されてもよいです。
This TLV type SHOULD be supported by peers and EAP servers conforming to this specification. The New PIN TLV MUST NOT be sent by an EAP server unless the peer has been authenticated. If the peer was authenticated in protected mode, then the New PIN TLV MUST NOT be present in an EAP-Request until after the exchange of the Confirm TLV (i.e., until after mutual authentication has occurred and keys are in place to protect the TLV). The New PIN TLV MUST be sent by a peer if and only if the EAP-Request that triggered the response contained a New PIN TLV, it was valid for the EAP server to send such a TLV in that request, and the TLV is supported by the peer.
このTLVタイプはこの仕様に準拠したピアとEAPサーバによってサポートされる必要があります。ピアが認証されていない限り、新しいPIN TLVはEAPサーバによって送ってはいけません。ピアが保護モードで認証された場合は、[新しいPIN TLVを確認TLVの交換後まで、EAP-要求中に存在してはならない（すなわち、相互認証が発生しているとキーがTLVを保護するために整備されている後まで） 。応答の引き金とEAP-要求が新しいPIN TLVが含まれている場合にのみ、それはEAPサーバは、その要求に、このようなTLVを送信するために有効であり、TLVがでサポートされている場合は、新しいPIN TLVは、ピアによって送らなければなりませんピア。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Q|A| PIN Length | PIN ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Min. PIN Length|Max. PIN Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1 - 必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
5
５
Length
長さ
2 + length of the PIN field (as specified in the PIN Length field) + (0, 1, or 2)
PINフィールド（PIN長フィールドで指定）+（0、1、又は2）の2 +長さ
Note: The final term above is - 0 if none of the optional Min. / Max. PIN Length fields is present in the TLV, - 1 if only the Min. PIN Length field is present in the TLV, - 2 if both of these optional fields are present in the TLV.
注：上記の最後の項は、 - 0オプション分のどれ場合。 /マックス。 PIN長フィールド、TLVに存在している - 1分場合にのみ。これらのオプションフィールドの両方がTLVに存在する場合、2 - PIN長フィールドはTLVで存在します。
Reserved
予約済み
Reserved for future use. All six bits SHALL be set to zero for this version. Recipients SHALL ignore these bits for this version of EAP-POTP.
将来の使用のために予約されています。すべての6つのビットは、このバージョンのためにゼロに設定されます。受信者は、EAP-POTPのこのバージョンのためにこれらのビットを無視しなければなりません。
Q
Q
The Q bit, when set in an EAP-Request, indicates that an accompanying PIN is required, i.e., the peer (user) is not free to choose another PIN. When the Q bit is set, there MUST be an accompanying PIN and the provided PIN MUST be used in subsequent OTP generations. A peer SHALL respond with an empty POTP-X EAP-Response message if the Q bit is set but there is not any accompanying PIN. When the Q bit is not set, any provided PIN is suggested only, and the peer is free to choose another PIN, subject to local policy.
EAP-Requestに設定Qビットは、即ち、ピア（ユーザ）が、別のPINを選択することが自由ではない、添付のPINが必要であることを示しています。 Qビットがセットされている場合、そこ添付PINなければならず、提供されるPINは、後続のOTP世代で使用されなければなりません。 Qビットが設定されている場合、ピアは空のPOTP-X EAP-Responseメッセージで応答するが、任意の添付PINはありません。 Qビットがセットされていない場合は、任意の提供PINのみが提案され、ピアは、ローカルポリシーの対象別のPINを、自由に選択することができます。
The Q bit carries no meaning, and SHALL be set to zero, in an EAP-Response.
Qビットは意味を運ばないし、EAP-応答では、ゼロに設定されなければなりません。
A
A
This bit allows methods that distinguish between two different PIN types (e.g., decimal vs. alphanumeric) to designate whether the augmented set is to be used (when set) or not (when not set). The A bit carries no meaning, and SHALL be set to zero, in an EAP-Response.
このビットは、2つの異なるピンタイプを区別する方法を可能にする（例えば、英数字対小数）が拡張セットが（場合セット）か否か（設定されていない場合）に使用されるべきかどうかを指定します。 Aビットは意味を運ばない、およびEAP-応答では、ゼロに設定されなければなりません。
PIN Length
PINの長さ
This field contains an unsigned integer representing the length of the provided PIN (this implies that the maximum length of a PIN will be 255 octets).
このフィールドは、提供されるPIN（これはPINの最大長さが255個のオクテットであろうことを意味する）の長さを示す符号なし整数を含んでいます。
PIN
ピン
In an EAP-Request, subject to the setting of the Q bit, the PIN field MAY be empty. If empty, the peer (user) will need to choose a PIN subject to local and (any) provided policy. When the PIN field is not empty, it MUST consist of UTF-8 encoded printable characters without a terminating NULL character.
EAP-Requestに、Qビットの設定に従う、PINフィールドが空であってもよいです。空の場合は、ピア（ユーザ）がローカルにPINの件名と（任意の）提供されるポリシーを選択する必要があります。 PINフィールドが空でない場合は、終端NULL文字なしUTF-8でエンコードされた印刷可能な文字で構成する必要があります。
In an EAP-Response, the PIN value SHALL consist of a UTF-8 encoded string of printable characters without a terminating NULL character.
EAP-応答では、PIN値は、終端NULL文字なしの印刷可能文字のUTF-8でエンコードされた文字列で構成されなければなりません。
The peer accepts a PIN suggested by the EAP server by replying with the same PIN, but MAY replace it with another one, depending on the server's setting of the Q bit. The length of the PIN is application-dependent, as are any other requirements for the PIN, e.g., allowed characters. The peer MUST be prepared to receive a repeated request for a new PIN, as described above, if the EAP server, for some reason does not accept the received PIN. Such a request MAY be preceded by an EAP-Request of type Notification (2) providing information to the user about the reason for the rejection. Mechanisms for transferring knowledge about PIN requirements from the EAP server to the peer (beyond those specified for this TLV, such as maximal and minimal PIN length) are outside the scope of this document. However, some information MAY be provided in notification messages transferred from the EAP server to the peer, as per above.
ピアは、同じPINを返信することで、EAPサーバによって提案されたPINを受け入れますが、Qビットのサーバーの設定に応じて、別のものと交換してもよい（MAY）。 PIN、例えば、許可された文字のための他の要件は、ピンの長さは、アプリケーションに依存しています。上述したようにEAPサーバは、何らかの理由で受信されたPINを受け入れない場合、ピアは、新しいPINについて繰り返し要求を受信するように準備しなければなりません。そのような要求は、拒絶の理由に関する情報をユーザに提供するタイプの通知のEAP-要求（2）によって先行されるかもしれません。 （例えば、最大と最小のPINの長さとして、このTLVに指定されたものを超えて）ピアにEAPサーバからPINの要件に関する知識を転送するための機構は、この文書の範囲外です。しかし、いくつかの情報は、上記の通り、ピアにEAPサーバから転送された通知メッセージで提供されてもよいです。
Min. PIN Length
ミン。 PINの長さ
This field MAY be present in an EAP-Request. This field MUST NOT be present in an EAP-Response. It SHALL be interpreted as an unsigned integer in network byte order representing the minimum length allowed for a new PIN.
このフィールドは、EAP-要求に存在してもよいです。このフィールドは、EAP-応答中に存在してはなりません。これは、新しいPINの許容される最小長さを表すネットワークバイト順に符号のない整数として解釈されるものとします。
Max. PIN Length
マックス。 PINの長さ
This field MUST NOT be present in an EAP-Request unless the Min. PIN Length field is present, in which case it MAY be present. The field MUST NOT be present in an EAP-Response. It SHALL be interpreted as an unsigned integer in network byte order representing the maximum length allowed for a new PIN. The value of this field, when present, MUST be equal to, or larger than, the value of the Min. PIN Length field.
このフィールドは、ミンない限り、EAP-Requestに存在してはなりません。 PIN長フィールドは、それが存在し得る場合には、存在しています。フィールドには、EAP-応答中に存在してはなりません。これは、新しいPINの最大許容長さを表すネットワークバイト順に符号のない整数として解釈されるものとします。このフィールドの値は、存在する場合、最小の値に等しい、またはそれより大きくなければなりません。 PINの長さフィールド。
Presence of this TLV in a request indicates that the EAP server has successfully authenticated the peer and now attempts to authenticate itself to the peer. Presence of this TLV in a response indicates that the peer successfully authenticated the EAP server, and that calculated keys (K_MAC, K_ENC, MSK, EMSK, and SRK) now become available for use.
リクエストでこのTLVの存在は、EAPサーバが正常にピアを認証し、今ピアに対して自分自身を認証しようとしていることを示しています。応答でこのTLVの存在は、ピアが正常EAPサーバを認証したことを示し、そして計算キー（K_MAC、K_ENC、MSK、EMSK、およびSRK）は、現在使用可能になること。
The Confirm TLV MUST NOT appear together with any other TLV in an EAP-Request message of type POTP-X and MUST NOT be sent unless the peer has been authenticated through an OTP TLV with the P bit set or through a Resume TLV for which the underlying session was established in protected mode. The Confirm TLV MUST be present in an EAP-Response if and only if the request that triggered the response contained a Confirm TLV, it was legal for it to do so, and the Confirm TLV authenticated the EAP server to the peer. If the peer was not able to authenticate the server, then it MUST send an empty (i.e., no TLVs present) EAP-Response of type POTP-X.
TLVはタイプPOTP-XのEAP-Requestメッセージ内の任意の他のTLVと一緒に現れてはいけませんとピアがPとOTP TLVを介して認証されていない限り、送信されてはいけません確認を設定または再開するためのTLVを介してビット根本的なセッションは、保護モードで設立されました。応答をトリガし、要求が確認TLVが含まれている場合にのみ、それがそうすることが法的だった、と確認TLVはピアにEAPサーバを認証されたかどうかを確認TLVはEAP-応答中に存在しなければなりません。ピアがサーバを認証することができなかった場合、それは送信しなければならない空の（すなわち、存在しないのTLV）タイプPOTP-XのEAP-応答。
An EAP server MUST send an EAP-Success message after receiving an EAP-Response of type POTP-X containing a valid Confirm TLV, sent in response to an EAP-Request containing a Confirm TLV where the C bit was not set. A peer MUST NOT accept an EAP-Success message when it has sent an OTP TLV with the P bit set unless it has received an acceptable Confirm TLV from the EAP server.
EAPサーバは、Cビットが設定されていないことを確認TLVを含むEAP-要求に応答して送信された有効な確認TLVを含むタイプPOTP-XのEAP-応答を受信した後、EAP-Successメッセージを送らなければなりません。それはPとOTP TLVを送信した場合、ピアはEAP-Successメッセージを受け入れてはいけません、それはEAPサーバから許容されることを確認TLVを受信していない限り、設定ビット。
This TLV type MUST be supported by all peers and EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV.
このTLVタイプはこの仕様に準拠するすべてのピアとEAPサーバによってサポートしなければならないとNAK TLVで応答してはなりません。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |C| Authentication Data ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pepper Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Pepper ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1 - 必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
6
６
Length
長さ
17 or 37 + length of IV in requests, 1 in responses.
17または37 +リクエスト、レスポンス1におけるIVの長さ。
Reserved
予約済み
Reserved for future use. These 7 bits SHALL be set to zero (0) for this version. Recipients SHALL ignore these bits for this version of EAP-POTP.
将来の使用のために予約されています。これらの7ビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのためにこれらのビットを無視しなければなりません。
C
C
The C bit, when set in an EAP-Request, indicates that the EAP server intends to send more EAP-Requests of type POTP-X in this session, after receipt of a Confirm TLV from the peer.
EAP-Requestに設定Cビットは、EAPサーバはピアから確認TLVを受信した後、このセッションのタイプPOTP-XのよりEAP-リクエストを送信しようとしていることを示しています。
The C bit carries no meaning in EAP-Responses, and MUST NOT be set within them.
Cビットは、EAP-応答では意味を運ばないし、それらの中に設定してはいけません。
Note: An EAP-Response containing a Confirm TLV, sent in response to an EAP-Request containing a Confirm TLV that did not have the C bit set, MUST be followed by an EAP-Success message from the EAP server concluding the handshake. However, when the C bit was set in an EAP-Request, the EAP server MAY send another EAP-Request (containing, for example, a New PIN TLV wrapped in a Protected TLV) rather than an EAP-Success message. Therefore, peers MUST NOT assume that the only EAP message following an EAP-Response of type POTP-X containing a Confirm TLV is EAP-Success. The C bit gives EAP servers a way to indicate their intent to follow the Confirm TLV with more requests, and allows the peer's state machine to adapt to this.
注：Cビットが設定されていませんでした確認TLVを含むEAP-要求に応答して送信されたことを確認TLVを含むEAP-応答は、握手を締結EAPサーバからのEAP-Successメッセージが続かなければなりません。 CビットがEAP-Requestに設定されたときしかし、EAPサーバは別のEAP-要求送るかもしれ（例えば、含有する、保護されたTLVでラップされた新しいPIN TLV）よりもむしろEAP-Successメッセージ。したがって、ピアは確認TLVを含むタイプPOTP-XのEAP-応答以下のみのEAPメッセージはEAP-成功であると仮定してはいけません。 CビットはEAPサーバに多くの要求を確認TLVに従うように自分の意思を示すための方法を提供し、ピアのステートマシンは、このに適応することができます。
Authentication Data
認証データ
EAP-Request:
EAP-要求：
In a request, this field consists of the first 16 octets of
(see also Section 4.11.3):
mac_a = MAC(K_MAC', msg_hash(trig_msg))
MAC_A = MAC（K_MAC」、msg_hash（trig_msg））
where
どこ
MAC is the negotiated MAC algorithm,
MACは、交渉されたMACアルゴリズムであり、
"K_MAC'" has been calculated as described in Section 4.11.3 or (in the case of session resumption) Section 4.11.8, and
（セッションの再開の場合）セクション4.11.3、またはに記載されているように「K_MAC '」は、セクション4.11.8を計算された、及び
"msg_hash" is the message hash algorithm defined in Section 4.9, and "trig_msg" the latest EAP-Response of type POTP-X received from the peer (the one which triggered this request).
「msg_hash」は、セクション4.9で定義されたメッセージのハッシュアルゴリズムであり、「trig_msg」はタイプPOTP-Xの最新EAP-応答ピア（この要求をトリガしたもの）から受け取りました。
Given a saved or recomputed value for K_MAC, the peer authenticates the EAP server by computing
K_MACのための保存または再計算値を考えると、ピアは、計算することによってEAPサーバを認証します
mac'' = MAC(K_MAC, msg_hash(trig_msg'))
MAC '' = MAC（K_MAC、msg_hash（trig_msg '））
where "msg_hash(trig_msg')" is the peer's hash of the EAP-Response message that it sent to the server (and that the server calculated its message hash on). If the first 16 octets of mac'' matches the first 16 octets in the Authentication Data field of the EAP-Request in question, then the EAP server is authenticated.
ここで、「msg_hash（trig_msg '）は、」それがサーバーに送信されたEAP-Responseメッセージのピアのハッシュである（とサーバーが上にそのメッセージのハッシュを計算していること）。マック「の最初の16個のオクテットは、」問題のEAP-要求の認証データフィールドの最初の16個のオクテットが一致した場合、EAPサーバが認証されます。
EAP-Response:
EAP-対応：
Not used in this version, and SHALL NOT be present in EAP-
Responses.
Pepper Identifier
ペッパー識別子
In an EAP-Request, the truncated MAC MAY optionally be followed by an encrypted pepper and its identifier. This initial, 4-octet field identifies a pepper generated by the server.
EAP-Requestに、短縮MACは、必要に応じて暗号化された胡椒とその識別子が続いてもよいです。この初期、4オクテットのフィールドは、サーバーによって生成されたコショウを識別します。
For this version of EAP-POTP, this field SHALL NOT be present in EAP-Responses.
EAP-POTPのこのバージョンでは、このフィールドには、EAP-応答中に存在してはなりません。
IV (Initialization Vector)
IV（初期ベクトル）
An initialization vector for the encryption. The length of the vector is dependent on the negotiated encryption algorithm. For example, for AES-CBC, it SHALL be 16 octets. The IV is only present if a pepper is present, and the negotiated encryption algorithm makes use of an IV. This field SHALL NOT be present in EAP-Response messages for this version of EAP-POTP.
暗号化のための初期化ベクトル。ベクトルの長さは交渉した暗号化アルゴリズムに依存しています。例えば、AES-CBCのために、それは16個のオクテットでなければなら。唐辛子が存在している、と交渉した暗号化アルゴリズムがIVを使用する場合はIVは唯一の存在です。このフィールドは、EAP-POTPのこのバージョンのためのEAP-応答メッセージ中に存在してはなりません。
Encrypted Pepper
暗号化されたペッパー
When present in an EAP-Request, this will be a uniformly distributed and randomly chosen 16-octet pepper generated by the EAP server and encrypted with the negotiated encryption algorithm, using K_ENC as the encryption key and possibly (depending on the encryption algorithm) using an IV (stored in the IV field). This field MUST be present if and only if the Pepper Identifier field is present.
場合EAP-要求中に存在する、これは使用（暗号化アルゴリズムに依存する）EAPサーバによって生成及び交渉された暗号化アルゴリズムで暗号化し、暗号化キーとしてK_ENCを使用して、おそらく均一に分布し、ランダムに選択された16オクテットコショウなり（IVフィールドに格納されている）IV。このフィールドは、ペッパー識別子フィールドが存在している場合にのみ存在しなければなりません。
EAP servers are RECOMMENDED to include a freshly generated encrypted pepper (and a corresponding Pepper Identifier) in every Confirm TLV.
EAPサーバは、すべてで新たに生成した暗号化コショウ（および対応するペッパーIdentifier）を含むことが推奨されているTLVを確認します。
This field SHALL NOT be present in EAP-Response messages for this version of EAP-POTP.
このフィールドは、EAP-POTPのこのバージョンのためのEAP-応答メッセージ中に存在してはなりません。
When a new pepper is generated by the server and transferred in encrypted form to the peer, then this new pepper value will be stored in the EAP server upon receipt of the Confirm TLV from the peer, and SHOULD be stored with its identifier and associated with the EAP server and the current user in the peer upon receipt of the EAP-Success message. If the peer already had a pepper stored for the EAP server, it SHALL replace it with the newly received one.
新しいコショウがサーバーによって生成され、ピアに暗号化された形式で転送される場合、この新しいコショウ値は、ピアから確認TLVを受信すると、EAPサーバに保存され、その識別子と共に格納され、関連付けられている必要がありEAPサーバとEAP-Successメッセージを受信すると、ピアにおける現在のユーザー。ピアがすでにEAPサーバのために保存された唐辛子を持っていた場合、それは、新たに受信したものと交換しないものとします。
The Vendor-Specific TLV is available to allow vendors to support their own extended attributes not suitable for general usage. A Vendor-Specific TLV can contain one or more inner TLVs, referred to as Vendor TLVs. The TLV-type of a Vendor TLV will be defined by the vendor. All the Vendor TLVs inside a single Vendor-Specific TLV SHALL belong to the same vendor.
ベンダー固有のTLVは、ベンダーが一般的な使用には適さない独自の拡張属性をサポートすることを可能にするために利用可能です。ベンダー固有のTLVのTLVは、ベンダーと呼ばれる一つまたはそれ以上の内側TLVを含むことができます。ベンダーTLVのTLVタイプは、ベンダーによって定義されます。単一ベンダー固有のTLV内のすべてのベンダーのTLVは、同じベンダーに帰属するものとします。
This TLV type MAY be sent by EAP servers, as well as by peers, and MUST be supported by all entities conforming to this specification. Conforming implementations may not support specific Vendor TLVs inside a Vendor-Specific TLV, however. They MAY, in this case, respond to the Vendor TLVs with a NAK TLV containing the appropriate Vendor-ID and Vendor TLV type.
このTLVタイプは、ピアによってだけでなく、EAPサーバによって送信され、この仕様に準拠するすべてのエンティティによってサポートしなければなりません。適合実装は、しかし、ベンダー固有のTLV内の特定ベンダーのTLVをサポートしないかもしれません。彼らは、この場合には、NAK TLVは、適切なベンダーIDとベンダーTLVタイプを含むとベンダーのTLVに応答することができます。
The presence of a Vendor-Specific TLV in an EAP-Request or EAP-Response of type POTP-X MUST NOT violate any existing rules for coexistence of TLVs in such requests or responses. If it does, then it will result in an EAP-Failure (when the peer made the violation) or an empty EAP-POTP response (when the EAP-server made the violation). It is left to the definition of specific Vendor-Specific TLVs to further constrain when they are allowed to appear. In particular, EAP-POTP implementations may have policies that completely disallow use of the Vendor-Specific TLV before protected mode mutual authentication has occurred (since the Protected TLV, Section 4.11.15, then can be used to protect all TLVs).
タイプPOTP-XのEAP-要求またはEAP-応答におけるベンダー固有のTLVの存在は、そのような要求や応答でのTLVの共存のための既存のルールに違反してはなりません。それがない場合（EAPサーバが違反した場合）、それはEAP-障害（ピアが違反した場合）または空のEAP-POTP応答をもたらすであろう。それらが表示されるように許可されているとき、さらに制限するために、特定のベンダー固有のTLVの定義に残されています。具体的には、EAP-POTPの実装は、完全に（保護TLV、第4.11.15は、すべてのTLVを保護するために使用することができるので）前に保護モードで相互認証が発生したベンダー固有のTLVの使用を許可しないポリシーを有することができます。
Note: This TLV type has the same definition and TLV type number as the Vendor-Specific TLV in [17], and the description of it is largely borrowed from that document.
注：このTLVのタイプは、[17]にベンダー固有のTLVと同じ定義とTLVのタイプ番号を有しており、それについての説明は、主にその文書から借用されます。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1 - 必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
7
７
Length
長さ
4 + cumulative total length of inner Vendor TLVs
インナーベンダーのTLVの4 +累計長さ
Vendor-ID
ベンダーID
The Vendor-Id field is 4 octets. The high-order octet SHALL be set to 0, and the low-order 3 octets SHALL be set to the SMI Network Management Private Enterprise Code (see [18]) of the Vendor in network byte order.
ベンダーIDフィールドは4つのオクテットです。上位オクテットは0に設定されなければならない、と下位3つのオクテットは、ネットワークバイト順でベンダー（[18]参照）SMIネットワーク管理プライベートエンタープライズコードに設定されなければなりません。
Vendor TLVs
ベンダーのTLV
This field shall contain vendor-specific TLVs, in a format defined by the vendor. To avoid fragmentation (i.e., EAP messages longer than the minimum EAP MTU size), the field SHOULD NOT be longer than 256 octets.
このフィールドは、ベンダーによって定義されたフォーマットで、ベンダー固有のTLVを含まなければなりません。断片化を避けるために（すなわち、最小EAP MTUサイズより長いEAPメッセージ）は、フィールドが長い256オクテットよりべきではありません。
To ensure interoperability when an EAP entity (peer or server) from vendor A sends a vendor-specific TLV that is not understood by the recipient EAP entity from vendor B, the vendor A entity SHALL, upon receipt of the NAK TLV from the recipient, refrain from usage of the vendor-specific TLV in question for the rest of the handshake, and MUST NOT fail the session due to the receipt of the NAK TLV for the Vendor TLV (i.e., it SHALL continue as if the vendor-specific TLV had not been sent). Additionally, all implementations conformant with this document SHOULD allow use of vendor-specific extensions to be turned off via configuration.
相互運用性を保証するために、ベンダーAからEAPエンティティ（ピアまたはサーバ）が、受信者からのNAK TLVを受信すると、エンティティのベンダー、ベンダー固有のTLVベンダーBから受信者EAPエンティティによって理解されていないものと送信した場合ベンダー固有のTLVが持っていたかのように（すなわち、それが継続するものと握手の残りの問題のベンダー固有のTLVの使用を控える、とによるベンダーTLVのためのNAK TLVの領収書にセッションを失敗してはなりません）送信されていません。また、この文書に準拠し、すべての実装は、ベンダー固有の拡張機能の使用は、構成を経由してオフにすることができるようにする必要があります。
The Resume TLV MAY be sent by a peer to an authentication server to attempt session resumption.
再開TLVは、セッション再開を試行する認証サーバにピアによって送られるかもしれません。
This TLV type MUST only be sent in response to an EAP-Request of type POTP-X containing a Server-Info TLV allowing session resumption. The Resume TLV MUST be supported by all EAP servers that send a Server-Info TLV allowing session resumption.
このTLVタイプは、セッション再開を許可するサーバ情報TLVを含むタイプPOTP-XのEAP-要求に応答して送らなければなりません。再開TLVは、サーバー情報TLVセッション再開を許可を送信するすべてのEAPサーバでサポートしなければなりません。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sess.Id (cont.)| Authentication Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Non-mandatory TLV
0 - 非必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
8
８
Length
長さ
45
４５
Reserved
予約済み
Reserved for future use. This octet SHALL be set to zero (0) for this version. Recipients SHALL ignore this octet for this version of EAP-POTP.
将来の使用のために予約されています。このオクテットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このオクテットを無視しなければなりません。
Session Identifier
セッション識別子
An 8-octet identifier for the session the peer is trying to resume.
セッションのための8オクテットの識別子は、ピアが再開しようとしています。
Authentication Data
認証データ
Upon receipt of the Server-Info TLV, and if the N bit is not set, the peer searches for any stored sessions associated with the server identified by the Server Name field. If a stored session is found, the peer generates a random, 16-octet nonce, "c_nonce", and calculates:
Nビットがセットされていない場合、サーバ情報TLVを受信すると、そして、任意の保存されたセッションのピア探索は、サーバ名フィールドによって識別されるサーバに関連付けられています。保存されたセッションが見つかった場合、ピアはランダム、16オクテットのナンス、「c_nonce」を生成し、計算します。
K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(base_key, c_nonce | s_nonce, iteration_count, key_length)
K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2（base_key、c_nonce |たs_nonce、繰返しの回数、key_length）
where
どこ
"|" denotes concatenation,
"|"連結を意味し、
"base_key" is either the current SRK for the session (if the session was created in protected mode) or the OTP used when the session was created (if the session was created in basic mode),
「base_key」のいずれかのセッションの現在のSRK（セッションが保護モードで作成された場合）またはOTPは、（セッションが基本モードで作成された場合）セッションが作成されたときに使用されます、
"c_nonce" is the generated 16-octet nonce,
「c_nonceは、」生成された16オクテットナンスで、
"s_nonce" is the server nonce from the Server-Info TLV,
「s_nonceが」サーバー情報TLVからサーバーのnonceがあり、
"iteration_count" is the iteration count as determined by local policy, and
「繰返しの回数は、」ローカルポリシーによって決定された繰り返し回数であり、
"key_length" is the combined length of the desired key material, in octets. When the default algorithms are used, key_length is 176.
「key_length」はオクテットで、所望のキー材料の組み合わせた長さです。デフォルトのアルゴリズムが使用されている場合は、key_lengthは176です。
The iteration count need only be 1 (one) when resuming a session established in protected mode, but MUST be chosen to provide a suitable level of protection when resuming a session established in basic mode (see also Section 4.11.3).
繰り返し回数はわずか1は（1）保護モードで確立したセッションを再開するが、基本的なモードで確立したセッションを再開するときの保護の適切なレベルを提供するように選択されなければならない（セクション4.11.3参照）であればよいです。
Note: Session resumption for basic mode MUST only be carried out in a server-authenticated and protected tunnel that also provides a cryptographic binding for inner EAP methods.
注：基本モードのセッションの再開は、また、内部EAPメソッドのバインディングの暗号化を提供するサーバ認証および保護されたトンネル内で行わなければなりません。
The peer then calculates:
ピアはその後、計算します。
mac = MAC(K_MAC, msg_hash(resume_req))
MAC = MAC（K_MAC、msg_hash（resume_req））
where
どこ
"MAC" is the negotiated MAC algorithm, and
「MACは」交渉したMACアルゴリズムであり、かつ
"msg_hash(resume_req) is the message hash algorithm defined in Section 4.9 applied on resume_req, the EAP server's EAP-Request of type POTP-X containing the Server-Info TLV that allowed session resumption.
「msg_hash（resume_req）はresume_reqに適用され、セクション4.9で定義されたメッセージのハッシュアルゴリズム、セッション再開を許可されるサーバー情報TLVを含むタイプPOTP-XのEAPサーバのEAP-要求です。
The peer then places the first 16 octets of the MAC value, followed by the c_nonce value, followed by the iteration count value (as a 4-byte unsigned integer in network byte order), in the Authentication Data field. As an example, when c_nonce = 0x2b3b1b12babdebebfb43bd7bdfbeb8df and iteration_count = 1, the Authentication Data field will be populated with (in hex):
ピアは、次いで、認証データフィールドに、（ネットワークバイト順における4バイトの符号なし整数として）の反復カウント値が続くc_nonce値続くMAC値の最初の16個のオクテットを置きます。 c_nonce = 0x2b3b1b12babdebebfb43bd7bdfbeb8dfと繰返しの回数= 1、認証データフィールドは（16進数）が移入される例として：
< 16 octets of mac > | 2b3b1b12babdebebfb43bd7bdfbeb8df | 00000001
<MACの16オクテット> | 2b3b1b12babdebebfb43bd7bdfbeb8df | 00000001
The server authenticates the peer by performing the corresponding calculations. If the authentication is successful, the server MUST send an EAP-Request of type POTP-X containing a Confirm TLV to the peer. If the authentication fails, the server MUST either send an EAP-Request of type POTP-X containing an OTP TLV and a Server-Info TLV, where the Server-Info TLV indicates that session resumption is not possible, or send an EAP-Failure.
サーバは、対応する計算を実行することによって、ピアを認証します。認証に成功すると、サーバーは、ピアに確認TLVを含むタイプPOTP-XのEAP-Requestを送らなければなりません。認証が失敗した場合、サーバは、OTP TLVおよびサーバー情報TLVは、セッション再開が不可能であることを示している、またはEAP-失敗を送信するサーバ情報TLVを含むタイプPOTP-XのEAP-Requestを送らなければなりませんどちらか。
When resuming in basic mode, all calculated keys SHALL be discarded after the MAC has been calculated and verified. When resuming in protected mode, the new SRK will replace the stored SRK, and the new MSK and EMSK will be exported upon successful completion of the method.
基本モードで再開するときにMACが計算され、検証された後、すべての計算キーが破棄されるものとします。プロテクトモードで再開するときは、新しいSRKは、格納されたSRKを交換し、新しいMSKとEMSKは、メソッドが正常に完了時にエクスポートされます。
The User Identifier TLV carries an identifier, typically the username, for the holder of the OTP token used to generate the OTP.
ユーザ識別子TLVはOTPを生成するために使用されるOTPトークンの所有者の識別子、典型的にはユーザ名を、運びます。
At least one of the User Identifier TLV and the Token Key Identifier TLV SHOULD be present in the session's first EAP-Response of type POTP-X that also carries an OTP TLV unless a suitable identity has been provided in a preceding EAP-Response of type Identity (1) or is determined by some other means (see [1], Section 2). Use of the User Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED even when an EAP-Response of type Identity (1) has been sent. If a peer sends both a User Identifier TLV and a Token Key Identifier TLV, then the EAP server SHALL interpret the Token Key Identifier TLV as specifying a particular token key for the given user. The EAP server MUST respond with an EAP-Failure if it cannot find a token key for the provided user.
少なくともユーザ識別子TLVの一つと適当同一タイプの先行EAP-応答して提供されていない限り、トークン鍵識別子TLVはまた、OTP TLVを運ぶタイプPOTP-Xのセッションの最初のEAP-応答で存在すべきですアイデンティティ（1）またはいくつかの他の手段によって決定される（[1]のセクション2を参照）。ユーザ識別子TLVおよび/またはトークンキー識別子TLVの使用は型アイデンティティ（1）のEAP-応答が送信された場合にも推奨されます。ピアは、ユーザ識別子TLVとトークンキー識別子TLVの両方を送信した場合、EAPサーバは、そのユーザの特定のトークンキーを指定すると、トークンキー識別子TLVを解釈するものとします。それは提供されたユーザーのトークンキーを見つけることができない場合は、EAPサーバは、EAP-失敗で応じなければなりません。
This TLV type is sent by peers and MUST be supported by all EAP servers conforming to this specification. The User Identifier TLV MUST NOT be present in a response that does not also carry an OTP TLV.
このTLVタイプは、ピアによって送信され、この仕様に準拠するすべてのEAPサーバでサポートしなければなりません。ユーザ識別子TLVはまた、OTP TLVを運ばない応答中に存在してはなりません。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1 - 必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
9
９
Length
長さ
Length of User Identifier, >= 1
ユーザ識別子の長さは、> = 1
User Identifier
ユーザ識別子
The value SHALL be an UTF-8 encoded string representing the holder of the token (MUST NOT be NULL-terminated). The string MUST be less than 128 octets in length.
値は、トークンの保持者を表すUTF-8でエンコードされた文字列でなければならない（NULLで終了してはいけません）。文字列の長さは128個の未満のオクテットでなければなりません。
The Token Key Identifier TLV carries an identifier for the token key used to generate the OTP.
トークン鍵識別子TLVはOTPを生成するために使用されるトークン鍵の識別子を運びます。
At least one of the User Identifier TLV and the Token Key Identifier TLV SHOULD be present in the session's first EAP-Response of type POTP-X, which also carries the OTP TLV unless a suitable identity has been provided in a preceding EAP-Response of type Identity (1) or is determined by some other means (see [1], Section 2). Use of the User Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED even when an EAP-Response of type Identity (1) has been sent. If a peer sends both a User Identifier TLV and a Token Key Identifier TLV, then the EAP server SHALL interpret the Token Key Identifier TLV as specifying a particular token key for the given user. The EAP server MUST respond with an EAP-Failure if it cannot find a token key corresponding to the provided token key identifier.
ユーザ識別子TLV及びトークン鍵識別子TLVの少なくとも一方は、適切なアイデンティティが前のEAP-応答して提供されていない場合もOTP TLVを運ぶタイプPOTP-Xのセッションの最初のEAP-応答で存在すべきですアイデンティティ（1）を入力するか、他の手段（、[1]のセクション2を参照）によって決定されます。ユーザ識別子TLVおよび/またはトークンキー識別子TLVの使用は型アイデンティティ（1）のEAP-応答が送信された場合にも推奨されます。ピアは、ユーザ識別子TLVとトークンキー識別子TLVの両方を送信した場合、EAPサーバは、そのユーザの特定のトークンキーを指定すると、トークンキー識別子TLVを解釈するものとします。それが提供するトークンキー識別子に対応するトークンキーを見つけることができない場合は、EAPサーバは、EAP-失敗で応じなければなりません。
This TLV type is sent by peers and MUST be supported by all EAP servers conforming to this specification. The Token Key Identifier TLV MUST NOT be present in a response that does not also carry an OTP TLV.
このTLVタイプは、ピアによって送信され、この仕様に準拠するすべてのEAPサーバでサポートしなければなりません。トークンキー識別子TLVはまた、OTP TLVを運ばない応答中に存在してはなりません。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Key Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1 - 必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
10
１０
Length
長さ
Length of Token Key Identifier, >= 1
トークンキー識別子の長さは、> = 1
Token Key Identifier
トークンキー識別子
An identifier for the OTP token key used to generate the OTP. The field MUST be less than 128 octets in length.
OTPを生成するために使用されるOTPトークン鍵の識別子。フィールドの長さは128個の未満のオクテットでなければなりません。
The Time Stamp TLV MAY be sent by peers to simplify authentications. When present, it carries the time as reported by the OTP Token.
タイムスタンプTLVは、認証を簡素化するために、ピアによって送信されるかもしれません。存在する場合、それはOTPトークンによって報告されるように時間を運びます。
An EAP server conformant with this specification SHOULD support (i.e., recognize) this TLV, but need not be able to process or act on it. An EAP server that does not support this TLV, but receives an EAP-Response with the TLV present, MAY ignore the value. The Time Stamp TLV MUST NOT be present in any EAP-Responses of type POTP-X other than those that also carries an OTP TLV.
この仕様に準拠EAPサーバは（すなわち、認識）このTLVをサポートしていますが、処理したり、それに基づいて行動することはできません必要がある場合。このTLVをサポートしていないEAPサーバが、TLVの存在とEAP-応答を受信し、値を無視するかもしれません。タイムスタンプTLVはまた、OTP TLVを運ぶもの以外のタイプPOTP-Xの任意のEAP-応答に存在してはなりません。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Non-mandatory TLV
0 - 非必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
11
１１
Length
長さ
Length of Time Stamp field, >= 20 (depending on precision)
タイムスタンプフィールドの長さは、> = 20（精度に依存します）
Time Stamp
タイムスタンプ
The time, as reported by the OTP token, at which the OTP used for the accompanying OTP TLV was calculated. The field SHALL contain a UTF-8 encoded value of the XML simple type "dateTime", with time zone information and precision down to at least seconds, e.g., "2004-06-16T15:20:02Z".
時間、添付OTP TLVを算出したためにOTPを使用れるOTPトークンによって報告されているように。フィールドは、XML単純型「のdateTime」、少なくとも秒までの時間帯情報と精度で、例えば、「：20：02Z 2004-06-16T15」のUTF-8でエンコードされた値を含まなければなりません。
The Counter TLV MAY be sent by peers to simplify authentications. When present, it carries the token counter value, as reported by the OTP Token.
カウンターTLVは、認証を簡素化するために、ピアによって送信されるかもしれません。 OTPトークンによって報告されているように存在する場合、それは、トークンカウンタ値を運びます。
An EAP server conformant with this specification SHOULD support (i.e., recognize) this TLV, but need not be able to process or act on it. An EAP server that does not support this TLV, but receives an EAP-Response with the TLV present, MAY ignore the value. The Counter TLV MUST NOT be present in any EAP-Responses of type POTP-X other than those that also carries an OTP TLV.
この仕様に準拠EAPサーバは（すなわち、認識）このTLVをサポートしていますが、処理したり、それに基づいて行動することはできません必要がある場合。このTLVをサポートしていないEAPサーバが、TLVの存在とEAP-応答を受信し、値を無視するかもしれません。カウンタTLVはまた、OTP TLVを運ぶもの以外のタイプPOTP-Xの任意のEAP-応答に存在してはなりません。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Non-mandatory TLV
0 - 非必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
12
１２
Length
長さ
Length of Counter field, >= 1 (depending on precision)
カウンタフィールドの長さは、> = 1（精度に依存します）
Counter
カウンタ
The counter value, as reported by the OTP token, at which the OTP used for the accompanying OTP TLV was calculated. The counter value SHALL be represented as an unsigned integer in network-byte order, e.g., a counter value of 1030 may be sent as the 2 octets (in hex) 04 06.
カウンタ値、添付OTP TLVを算出したためにOTPを使用れるOTPトークンによって報告されているように。カウンタ値は、ネットワークバイト順に符号のない整数として表現されるべきであり、例えば、1030のカウンタ値が（16進数）2つのオクテット04 06として送信されてもよいです。
The Challenge TLV carries the challenge used by the token to calculate the OTP, as reported by the token to the peer. The Challenge TLV MUST be sent by a peer if and only if the challenge otherwise would be unknown to the EAP server (e.g., the token or peer modified a received challenge or generated its own challenge).
チャレンジTLVピアにトークンによって報告されているように、OTPを計算するためにトークンが使用するチャレンジを運びます。課題は、そうでない場合はEAPサーバに未知であろう場合にのみ、および（例えば、トークンまたはピアが受信したチャレンジを変更または独自の挑戦を生成された）場合にチャレンジTLVピアによって送信されなければなりません。
An EAP server conformant with this specification SHOULD support (i.e., recognize) this TLV, but need not be able to process or act on it. An EAP server that does not support this TLV, but receives an EAP-Response with the TLV present, MAY ignore the value. The Challenge TLV MUST NOT be present in any EAP-Responses of type POTP-X other than those that also carry an OTP TLV.
この仕様に準拠EAPサーバは（すなわち、認識）このTLVをサポートしていますが、処理したり、それに基づいて行動することはできません必要がある場合。このTLVをサポートしていないEAPサーバが、TLVの存在とEAP-応答を受信し、値を無視するかもしれません。チャレンジTLVはまた、OTP TLVを運ぶもの以外のタイプPOTP-Xの任意のEAP-応答に存在してはなりません。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Non-mandatory TLV
0 - 非必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
16
１６
Length
長さ
Length of Challenge field, >= 1
チャレンジフィールドの長さ、> = 1
Challenge
チャレンジ
The challenge value that was used to calculate the OTP used for the accompanying OTP TLV.
OTPを計算するために使用されたチャレンジ値は、添付のOTP TLVに使用しました。
The Keep-Alive is used to avoid EAP-POTP timeouts.
キープアライブは、EAP-POTPのタイムアウトを回避するために使用されます。
The Keep-Alive TLV MAY be sent by a peer to avoid timeouts when the peer has received an EAP-Request containing an OTP TLV or a New PIN TLV and is waiting for a response from the user.
ピアは、OTP TLVまたは新しいPIN TLVを含むEAP-Requestを受信し、ユーザからの応答を待っているとき、キープアライブTLVは、タイムアウトを避けるために、ピアによって送信されるかもしれません。
An EAP-Request containing a Keep-Alive TLV MUST be sent by an EAP server when the server receives an EAP-Response containing a Keep-Alive TLV, and the server has an outstanding request that did not contain a Keep-Alive TLV. In this situation, the server does not need to re-transmit its latest outstanding request, but, due to the synchronous nature of EAP, it needs to send another request. Re-transmission of the latest outstanding request could be confusing for the peer since the request would get a new Identifier value. The Keep-Alive TLV MAY also be sent by an EAP server when the server detects that its processing time will exceed some locally configured threshold and may cause a network timeout. In this case, the peer MUST respond with an EAP-Response containing a Keep-Alive TLV.
サーバがキープアライブTLVを含むEAP-レスポンスを受信して、サーバがキープアライブTLVが含まれていなかった未処理の要求がある場合にキープアライブTLVを含むEAP-RequestがEAPサーバによって送らなければなりません。このような状況では、サーバーが原因EAPの同期性質のために、その最新の未処理の要求を再送信する必要がありますが、しない、それは別の要求を送信する必要があります。要求が新しい識別子の値を取得しますので、再伝送最新の未処理の要求のピアのために混乱することができます。サーバーは、その処理時間は、いくつかのローカルに設定されたしきい値を超えると、ネットワークのタイムアウトを引き起こす可能性があることを検出した場合、キープアライブTLVはまた、EAPサーバによって送信されるかもしれません。この場合、ピアはキープアライブTLVを含むEAP-で応答する必要があります。
This TLV type MUST be supported by all peers and all EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV. The Keep-Alive TLV MUST NOT be sent in any other situations than the ones described above. The Keep-Alive TLV MUST NOT be sent together with any other TLVs defined herein. Implementations SHOULD also follow recommendations made in Section 4.3 of [1].
このTLVタイプはこの仕様に準拠するすべてのピアと、すべてのEAPサーバでサポートしなければならないとNAK TLVで応答してはなりません。キープアライブTLVは、上述のもの以外の状況で送ってはいけません。キープアライブTLVは、本明細書で定義された他のTLVと一緒に送ってはいけません。また、実装は、[1]のセクション4.3で行われた勧告に従うべきです。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1 - 必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
13
１３
Length
長さ
0
０
The Protected TLV SHALL be used to encrypt individual or multiple TLVs after successful exchange of the Confirm TLV (i.e., as soon as calculated keys have been confirmed). The Protected TLV therefore wraps "ordinary" TLVs.
保護されたTLVを確認TLVの交換が成功した後、個別または複数のTLVを暗号化するために使用されなければならない（すなわち、とすぐに計算キーが確認されているとおり）。保護されたTLVは、したがって、「普通」のTLVをラップします。
This TLV type may be sent by EAP servers as well as by peers and MUST be supported by all peers conforming to this specification. It SHOULD be supported by all EAP servers conforming to this specification (it need not be supported if a server never will have a need to continue a POTP-X conversation after exchange of the Confirm TLV).
このTLVタイプは、EAPサーバによって送信されるだけでなく、仲間で、この仕様に準拠するすべてのピアによってサポートしなければなりません。これは、この仕様に準拠するすべてのEAPサーバによってサポートされる必要があります（サーバが確認TLVの交換後POTP-Xの会話を継続する必要性もありませんでした場合は、サポートする必要はありません）。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1 - 必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
14
１４
Length
長さ
>32
＞３２
Message Authentication Code (MAC)
メッセージ認証コード（MAC）
This field integrity-protects the TLV. The MAC SHALL be calculated over the IV and the Encrypted TLVs field in the following manner:
このフィールドはTLVは、整合性保護されます。 MACは次のようにIVと暗号化のTLVフィールド上で計算しなければなりません。
mac = MAC(K_MAC, iv | encrypted_tlvs)
MAC = MAC（K_MAC、IV | encrypted_tlvs）
where
どこ
MAC is the negotiated MAC algorithm, "iv" is the IV field's value, and "encrypted_tlvs" is the value of the Encrypted TLVs field. The first 16 octets of the MAC is placed in the Message Authentication Code field.
MACが交渉MACアルゴリズムであり、「IV」はIVフィールドの値であり、そして「encrypted_tlvs」暗号化のTLVフィールドの値です。 MACの最初の16個のオクテットは、メッセージ認証コードフィールドに置かれます。
Recipients MUST verify the MAC. If the verification fails, the conversation SHALL be terminated (i.e., peers send an empty POTP-X EAP-Response message, and EAP servers send an EAP-Failure message possibly preceded by an EAP-Request of type Notification).
受信者はMACを確かめなければなりません。検証が失敗した場合、会話は（すなわち、ピアは空のPOTP-X EAP-Responseメッセージを送信し、EAPサーバは、おそらくタイプの通知のEAP-要求が先行EAP失敗メッセージを送る）終了するもの。
IV
IV
An initialization vector for the encryption; see below. The length of the vector is dependent on the negotiated encryption algorithm, e.g., for AES-CBC, it shall be 16 octets. For some encryption algorithms, there may not be any initialization vector. An IV, when present, shall be randomly chosen and non-predictable.
暗号化のための初期化ベクトル。下記参照。ベクトルの長さは、例えば、AES-CBCのために、それは16個のオクテットでなければならない、ネゴシエートされた暗号化アルゴリズムに依存しています。いくつかの暗号化アルゴリズムの場合は、任意の初期化ベクトルがない可能性があります。 IV、現在、ランダムに選択されなければならないと予測不可能。
Encrypted TLVs
暗号化されたTLV
This field SHALL contain one or more encrypted POTP-X TLVs. The encryption algorithm SHALL be as negotiated; use K_ENC as the encryption key, and use the IV field as the initialization vector (when applicable), to encrypt the concatenation of all the TLVs to be protected.
このフィールドは、一つ以上の暗号化POTP-X TLVを含まなければなりません。暗号化アルゴリズムは、として交渉しなければなりません。暗号化キーとしてK_ENCを使用して、保護されるべきすべてのTLVの連結を暗号化するために、初期化ベクトル（該当する場合）などのIVフィールドを使用します。
The Crypto Algorithm TLV allows for negotiation of cryptographic algorithms. Cryptographic Algorithm negotiation is described in detail in Section 4.3.
暗号アルゴリズムTLVは、暗号アルゴリズムのネゴシエーションが可能になります。暗号アルゴリズムのネゴシエーションは4.3節に詳細に記載されています。
This TLV MUST be present in the initial EAP-Request of type POTP-X that also carries an OTP TLV indicating protected mode, assuming the EAP server wants to negotiate use of any other algorithms than the default ones. It MAY also be present in an EAP-Request of type POTP-X that carries an OTP TLV that is sent as a result of a failed session resumption (in this case, the peer has not yet responded to this TLV), or when the Crypto Algorithm TLV was part of the initial message from the EAP server, and the client negotiated another EAP-POTP version than the highest one supported by the EAP server. The Crypto Algorithm TLV MUST NOT be present in any other EAP-Requests. Further, the Crypto Algorithm TLV MUST NOT be present in an EAP-Response of type POTP-X unless the preceding EAP-Request also contained it, and it was legal for it to do so. This TLV MUST be supported by all peers and all EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV.
このTLVはEAPサーバがデフォルトのもの以外のアルゴリズムの使用を交渉したいと仮定し、また、保護されたモードを示すOTP TLVを運ぶタイプPOTP-Xの初期EAP-要求に存在していなければなりません。それはまた、失敗したセッションの再開の結果として送信されるOTP TLVを運ぶタイプPOTP-XのEAP-要求（この場合、ピアは、まだこのTLVに応答していない）で存在する場合、またはMAY暗号アルゴリズムTLVはEAPサーバからの最初のメッセージの一部で、クライアントがEAPサーバでサポートされている最高のものよりも、別のEAP-POTPバージョンを交渉しました。暗号アルゴリズムTLVは、他のEAP-のリクエストで存在してはなりません。さらに、前述のEAP-要求にもそれが含まれていない限り、暗号化アルゴリズムTLVはタイプPOTP-XのEAP-応答に存在してはならない、それはそうすることが法的でした。このTLVは、この仕様に準拠するすべてのピアと、すべてのEAPサーバでサポートしなければならないとNAK TLVで応答してはなりません。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Hash Alg.Length| Hash Algorithms ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Encr.Alg.Length| Encryption Algorithms ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MAC Alg. Length| MAC Algorithms ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1 - 必須TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
将来の使用のために予約されています。このビットは、このバージョンのためにゼロ（0）に設定します。受信者は、EAP-POTPのこのバージョンのために、このビットを無視しなければなりません。
TLV Type
TLVタイプ
15
１５
Length
長さ
>=4 (at least one class of algorithms and one algorithm for that class needs to be present)
> = 4（アルゴリズムの少なくとも1つのクラスおよびそのクラスのための1つのアルゴリズムが存在する必要があります）
Reserved
予約済み
Reserved for future use. This octet MUST be set to zero for this version. Recipients SHALL ignore this octet for this version of EAP-POTP.
将来の使用のために予約されています。このオクテットは、このバージョンのためにゼロに設定する必要があります。受信者は、EAP-POTPのこのバージョンのために、このオクテットを無視しなければなりません。
Hash Alg. Length
ALGをハッシュ。長さ
The length of the Hash Algorithms field in octets.
オクテットでハッシュアルゴリズムフィールドの長さ。
Hash Algorithms
ハッシュアルゴリズム
Each octet pair of this field represents a hash algorithm as follows. An EAP server MAY supply several suggestions for hash algorithms. Each algorithm MUST appear only once. The algorithms SHALL be supplied in order of priority. Peers MUST supply, at most, one algorithm (if none is present, the default applies). The defined values are:
次のようにこのフィールドの各オクテットのペアは、ハッシュアルゴリズムを表します。 EAPサーバは、ハッシュアルゴリズムのためのいくつかの提案を供給することができます。各アルゴリズムは一度だけ現れなければなりません。アルゴリズムは、優先度の順に供給されるものとします。ピアは（何も存在しない場合、デフォルトが適用されます）、最大で、1つのアルゴリズムを供給しなければなりません。定義された値は次のとおりです。
Value
Octet 1 Octet 2 Hash algorithm
------- ------- ----------------------------------
0x00 0x00 Reserved
0x00 0x01 SHA-1
0x00 0x02 SHA-224
0x00 0x03 SHA-256 (default)
0x00 0x04 SHA-384
0x00 0x05 SHA-512
0x80 - Vendor-specific (or experimental)
As indicated, values 0x8000 and higher are for proprietary vendor-specific algorithms. Values in the range 0x0006 - 0x7fff are to be assigned through IANA; see Section 7.
示されるように、0x8000のより高いが、独自のベンダー固有のアルゴリズムのための値です。範囲0x0006の値 - IANAを通して割り当てられるは0x7FFF。セクション7を参照してください。
Encr Alg. Length
ENCR ALG。長さ
The length of the Encryption Algorithms field in octets.
オクテットでの暗号化アルゴリズムフィールドの長さ。
Encryption Algorithms
暗号化アルゴリズム
Each octet pair of this field represents an encryption algorithm as follows. An EAP server MAY supply several suggestions for encryption algorithms. Each algorithm MUST appear only once. The algorithms SHALL be supplied in order of priority. Peers MUST supply, at most, one algorithm (if none is present, the default applies). The defined values are:
次のようにこのフィールドの各オクテットのペアは、暗号化アルゴリズムを表します。 EAPサーバは、暗号化アルゴリズムのためのいくつかの提案を供給することができます。各アルゴリズムは一度だけ現れなければなりません。アルゴリズムは、優先度の順に供給されるものとします。ピアは（何も存在しない場合、デフォルトが適用されます）、最大で、1つのアルゴリズムを供給しなければなりません。定義された値は次のとおりです。
Value
Octet 1 Octet 2 Encryption algorithm
------- ------- ------------------------
0x00 0x00 Reserved
0x00 0x01 AES-CBC (default) with 128-bit keys and 16-octet IVs
0x00 0x02 3DES-CBC with 112-bit keys and 8-octet IVs
0x80 - Vendor-specific
As indicated, values 0x8000 and higher are for vendor-specific proprietary algorithms. Values in the range 0x0003 - 0x7fff are to be assigned through IANA; see Section 7.
示されるように、0x8000の、およびベンダー固有の独自のアルゴリズムのためのものより高い値。範囲0x0003の値 - IANAを通して割り当てられるは0x7FFF。セクション7を参照してください。
MAC Alg. Length
MAC ALG。長さ
The length of the MAC Algorithms field in octets.
オクテットMACアルゴリズムフィールドの長さ。
MAC Algorithms
MACアルゴリズム
Each octet pair of this field represents a MAC algorithm as follows. An EAP server MAY supply several suggestions for MAC algorithms. Each algorithm MUST appear only once. The algorithms SHALL be supplied in order of priority. Peers MUST supply, at most, one algorithm (if none is present, the default applies). The defined values are:
次のようにこのフィールドの各オクテットのペアは、MACアルゴリズムを表します。 EAPサーバはMACアルゴリズムのためのいくつかの提案を供給することができます。各アルゴリズムは一度だけ現れなければなりません。アルゴリズムは、優先度の順に供給されるものとします。ピアは（何も存在しない場合、デフォルトが適用されます）、最大で、1つのアルゴリズムを供給しなければなりません。定義された値は次のとおりです。
Value
Octet 1 Octet 2 MAC algorithm
------- ------- -----------------
0x00 0x00 Reserved
0x00 0x01 HMAC (default)
0x80 - Vendor-specific
As indicated, values 0x8000 and higher are for vendor-specific proprietary algorithms. Values in the range 0x0002 - 0x7fff are to be assigned through IANA; see Section 7.
示されるように、0x8000の、およびベンダー固有の独自のアルゴリズムのためのものより高い値。範囲0×0002の値 - IANAを通して割り当てられるは0x7FFF。セクション7を参照してください。
When HMAC is negotiated, the hash algorithm used for HMAC SHALL be the negotiated hash algorithm.
HMACがネゴシエートされると、HMACのために使用されるハッシュアルゴリズムがネゴシエートハッシュアルゴリズムでなければなりません。
In line with recommendations made in [16], EAP-POTP defines the following identifiers to be associated with generated key material:
[16]に勧告に沿って、EAP-POTPは、生成された鍵材料に関連付けられる次の識別子を定義しています。
Peer-ID: The combined contents of the User Identifier TLV and the Token Key Identifier TLV.
ピアID：ユーザ識別子TLVとトークンキー識別子TLVの組み合わせ内容。
Server-ID: The contents of the Server Identifier field of the Server-Info TLV.
サーバーID：サーバー情報TLVのサーバー識別子フィールドの内容。
Method-ID: The identifier of the established session (i.e., the contents of the Session Identifier field of the Server-Info TLV that defined the session).
方法-ID：確立されたセッションの識別子（すなわち、セッションを定義したサーバ情報TLVのセッション識別子フィールドの内容）。
In conformance with RFC 3748 [1], the following security claims are made for the EAP-POTP method:
RFC 3748に準拠した[1]、次のセキュリティの特許請求の範囲は、EAP-POTP方法のために作られます。
Authentication mechanism: Generic OTP Ciphersuite negotiation: Yes (No in basic variant) Mutual authentication: Yes (No in basic variant) Integrity protection: Yes (No in basic variant) Replay protection: Yes (see below) Confidentiality: Only in the OTP protection variant, and then only OTP values and any information sent after exchange of the Confirm TLV Key derivation: Yes (No in basic variant) Key strength: Depends on size of OTP value, strength of underlying shared secret, strength and characteristics of OTP algorithm, pepper length, iteration count, and whether the method is used within a tunnel such as PEAPv2. For some illustrative examples, and a further discussion of this, see Appendix D. Dictionary attack prot.: N/A (Human-selected passwords not used) Fast reconnect: Yes Crypt. binding: N/A (EAP-POTP is not a tunnel method) Session independence: Yes Fragmentation: N/A (Packets shall not exceed MTU of 1020) Channel binding: Yes (No in basic variant) Acknowledged S/F: Yes State Synchronization: Yes (No in basic variant)
認証メカニズム：一般的なOTPたciphersuite交渉：はい相互認証（基本的なバリアントではありません）：はい（ノー基本的なバリアントで）完全性保護：リプレイ保護（基本的なバリアントではありません）：はい（下記参照）機密性：のみOTP保護でバリアント、その後、唯一のOTP値と確認TLV鍵導出の交換の後に送信されるすべての情報：はい（ノー基本的なバリアントで）主要な強さは：、OTP値の大きさ、根本的な共有秘密の強さ、強度およびOTPアルゴリズムの特性に依存しますコショウ長、繰り返し回数、及び方法は、例えばPEAPv2としてトンネル内で使用されているかどうか。いくつかの例示的な実施例、及びその詳細な説明については、付録D.辞書攻撃PROT参照：N / A（使用していない人間選択パスワード）高速再接続：はいクリプト。結合：N / Aセッション独立（EAP-POTPがトンネル方式ではない）：はいフラグメンテーション：N / A結合チャネル（パケット1020のMTUを超えてはならない）：はい（基本的な変異体でNo）に認めS / Fは：はい状態同期：（基本的なバリアントではありません）はい
The basic variant (i.e., when the protection of OTPs and mutual authentication is not used) of this EAP method does not provide session privacy, session integrity, server authentication, or protection from active attacks. In particular, man-in-the-middle attacks, where an attacker acts as an authenticator in order to acquire a valid OTP, are possible.
このEAP方式の基本的な変種（すなわち、のOTPと相互認証の保護を使用しない場合）は、セッションのプライバシー、セッションの整合性、サーバー認証、または能動的な攻撃からの保護を提供していません。特に、攻撃者は有効なOTPを取得するために、オーセンティケータとして機能し、man-in-the-middle攻撃、可能です。
Similarly, the basic variant of this EAP method does not protect against session hijacking taking place after authentication. Nor does it, in itself, protect against replay attacks, where the attacker gains access by replaying a previous valid request, but see also the next subsection. When PIN codes are transmitted, they are sent without protection and are also subject to replay attacks.
同様に、このEAP方式の基本的な変種は、認証後に行わセッションハイジャックを防ぐことはできません。また、それは、それ自体が、前の有効な要求を再生することにより、攻撃者がアクセスリプレイ攻撃から保護するだけでなく、次のサブセクションを参照してくださいありません。 PINコードが送信されると、彼らは保護なしで送信され、また、リプレイ攻撃の対象とされています。
In order to protect against these attacks, the peer MUST only use the basic variant of this method over a server-authenticated and confidentiality-protected connection. This can be achieved via use of, PEAPv2 [17], for example.
これらの攻撃から保護するために、ピアは、サーバ認証および機密保護された接続を介して、この方法の基本的なバリアントを使用しなければなりません。これは、例えば、PEAPv2 [17]の使用を介して達成することができます。
When the OTP protection variant is used, however, the EAP method provides privacy for OTPs and new PINs, negotiation of cryptographic algorithms, mutual authentication, and protection against replay attacks and protocol version downgrades. It also provides protection against man-in-the-middle attacks, not due to the infeasibility for a man-in-the-middle to solve for a valid OTP given an OTP TLV, but due to the computational expense of finding the OTP in the limited time period during which it is valid (this is mainly true for tokens, including the current time in their OTP calculations, or when a sent challenge has a certain lifetime). It should be noted, however, that a retrieved OTP, even if "old" and invalid, still may divulge some information about the user's PIN. Clearly, this is also true for the basic variant. Implementations of this EAP method, where user PINs are sent with OTPs, are therefore RECOMMENDED to ensure regular user PIN changes, regardless of whether the protected variant or the basic variant is employed.
OTP保護バリアントを使用する場合は、しかし、EAP方法は、OTPをして、新しいPINのためのプライバシー、暗号アルゴリズムの交渉、相互認証、およびリプレイ攻撃とプロトコルバージョンのダウングレードに対する保護を提供します。それはまたのman-in-the-middle有効なOTPのために解決するためにOTP TLV与えられたために実行不可能性によるman-in-the-middle攻撃ではなくに対する保護を提供していますが、原因でOTPを見つけるの計算コストにそれが有効である間の限られた時間は、（これは彼らのOTP計算で現在の時間を含む、トークンの主に真である、または送信されるチャレンジは、特定の寿命を持っている場合）。それも、「古い」と、無効な場合は、OTPを取得し、まだユーザーのPINに関するいくつかの情報を漏らすこと、しかし、注意すべきです。明らかに、これは基本的な変異体についても同様です。ユーザピンはOTP;ワンタイムで送信され、このEAP方法の実装は、それゆえにかかわらず保護変異体又は塩基性変異体が使用されるかどうか、定期的にユーザPINの変更を確実にするために推奨されています。
It should also be noted that, while it is possible for a rogue access point, e.g., to clone MAC addresses, and hence mount a man-in-the-middle attack, such an access point will not be able to calculate the session keys MSK and EMSK. This demonstrates the importance of using the derived key material properly to protect a subsequent session.
また、それが不正なアクセスポイント、例えば、MACアドレスのクローンを作成し、ひいてはman-in-the-middle攻撃、そのようなアクセスポイントはセッションキーを計算することができませんマウントすることが可能であるが、ことに留意すべきですMSKとEMSK。これは後続のセッションを保護するために適切に派生鍵素材を使用することの重要性を示しています。
Protected mode protects against version downgrade attacks due to the HMAC both parties transmit in this mode. As described, each party calculates the HMAC on sent and received EAP-POTP handshake messages. If an attacker were to modify a Version TLV, this would be reflected in a difference between the calculated MACs (since the recipient of the Version TLV received a different value than the sender sent). Unless the attacker knows K_MAC, he cannot calculate the correct MAC, and hence the difference will be detected.
保護モードは、両当事者がこのモードで送信によるHMACにバージョンダウン攻撃から保護します。このように、各当事者は、送受信されたEAP-POTPのハンドシェイクメッセージでHMACを計算します。攻撃者はバージョンTLVを変更した場合（バージョンTLVの受信者は、送信された送信者とは異なる値を受信してから）、これは、計算MACの間の差に反映されます。攻撃者はK_MACを知っていない限り、彼は正しいMACを計算することはできません、したがって、違いが検出されます。
The OTP protection variant also protects against session hijacking, if the derived key material is used (directly or indirectly) to protect a subsequent session. For these reasons, use of the OTP protection variant is RECOMMENDED.
派生鍵素材は、その後のセッションを保護するために（直接的または間接的に）使用される場合、OTP保護変異体はまた、セッションハイジャックから保護します。これらの理由から、OTP保護変異体の使用が推奨されます。
However, it should be noted that not even the OTP protection variant provides privacy for user names and/or token key identifiers. EAP-POTP MUST be used within a secure tunnel such as the one provided by PEAPv2 [17] if privacy for these parameters is required.
しかし、そうではないにもOTP保護バリアントは、ユーザ名および/またはトークンキー識別子のプライバシーを提供することに留意されたいです。 EAP-POTPは、これらのパラメータのプライバシーが必要な場合PEAPv2 [17]によって提供されるものと安全なトンネル内で使用されなければなりません。
When resuming sessions created in the basic variant (which MUST only take place within a protected tunnel), the peer is authenticated by demonstrating knowledge of not just a valid session identifier, but also the OTP used when the session was created. Server nonces prevent replay attacks, but there still remains some likelihood of an attacker guessing the correct combination of session identifier and OTP value. Assuming OTPs with entropy about 32 bits, this means that the likelihood of succeeding with such an attack is about 1/2^48 due to the birthday paradox. Servers allowing session resumption for the basic variant MUST protect against such attacks, e.g., by keeping track of the rate of failed resumption attempts.
（のみ保護されたトンネル内で行わなければならない）基本的なバリアントで作成されたセッションを再開すると、ピアがないだけで、有効なセッション識別子の知識を実証することによって認証されますが、セッションが作成されたときにもOTPを使用しました。サーバのナンスは、リプレイ攻撃を防ぐため、まだセッション識別子とOTP値の正しい組み合わせを推測攻撃のいくつかの可能性が残されています。 32ビット約エントロピとのOTPを仮定すると、これはそのような攻撃に成功する可能性は1/2 ^ 48による誕生日パラドックスであることを意味します。基本的なバリアントのセッションの再開を許可するサーバは失敗再開試行の割合を追跡することによって、例えば、このような攻撃から保護しなければなりません。
An active attacker may replace the iteration count value in OTP TLVs sent by the peer to slow down an authentication server. Authentication servers SHOULD protect against this, e.g., by disregarding OTP TLVs with an iteration count value higher than some number that is preset or dynamically set (depending on load).
アクティブな攻撃者は、認証サーバを遅くするために、ピアによって送信されたOTPのTLVでの反復カウント値を置き換えることができます。認証サーバは、予め設定されたまたは動的に設定され、いくつかの数（負荷に応じて）より高い反復カウント値とOTP TLVを無視することによって、例えば、このから保護すべきです。
As described in Section 4.8, the use of pepper will slow down an attacker's search for a matching OTP. The ability to transfer a pepper value in encrypted form from the EAP server to the peer means that, even though there may be an initial computational cost for the EAP server to authenticate the peer, subsequent authentications will be efficient, while at the same time more secure, since a pre-shared, 128-bit-long pepper value will not be easily found by an attacker. An attacker, observing an EAP-Request containing an OTP TLV calculated using a pepper chosen by the peer, may, however, depending on available resources, be able to successfully attack that particular EAP-POTP session, since it most likely will be based on a relatively short pepper value or only an iteration count. Once the correct OTP has been found, eavesdropping on the EAP server's Confirm TLV will potentially give the attacker access to the longer, server-provided pepper for the remaining lifetime of that pepper value. For this reason, initial exchanges with EAP servers SHOULD occur in a secure environment (e.g., in a PEAPv2 tunnel offering cryptographic binding with inner EAP methods). If initial exchanges do not occur in a secure environment, the iteration count MUST be significantly higher than for messages where a pre-shared pepper is used. The lifetime of the shared pepper must also be calculated with this in mind. Finally, the peer and the EAP server MUST store the pepper value securely and associated with the user.
4.8節で述べたように、唐辛子の使用は、一致OTPのための攻撃者の検索が遅くなります。一方、同時に複数のピアにEAPサーバから暗号化された形式でコショウ値を転送する能力は、ピアを認証するためのEAPサーバのための初期計算コストがあっても、後続の認証が効率的であろう、ということを意味します事前共有、128ビット長コショウ値は容易に攻撃者によって発見されないので、セキュア。ピアによって選択された唐辛子を使用して計算OTP TLVを含むEAP-Requestを観察する攻撃者は、しかし、利用可能なリソースに応じて、それが最も可能性が高いに基づくことになるので、正常に、その特定のEAP-POTPセッションを攻撃することができるかもしれません比較的短いコショウ値のみ反復カウント。正しいOTPが発見された後、EAPサーバの確認TLV上の盗聴は、潜在的にそのコショウ値の残りの寿命のために、攻撃者は長く、サーバーが提供するコショウへのアクセスを提供します。この理由のために、EAPサーバとの最初の交換（例えば、PEAPv2トンネルに内部EAPメソッドと結合暗号提供）セキュアな環境で起こるべきです。最初の交換は、安全な環境で発生していない場合は、反復回数は、事前共有唐辛子を使用したメッセージのためよりも有意に高くなければなりません。共有唐辛子の寿命も念頭に置いてこれを計算する必要があります。最後に、ピアとEAPサーバが確実にユーザに関連付けられたコショウ値を格納しなければなりません。
In the case of fragmentation of EAP messages, it is possible (in the basic variant of this method) for an attacker to listen to most of an OTP, guess the remainder, and then race the legitimate user to complete the authentication. Conforming backend authentication server implementations MUST protect against this race condition. One defense against this attack is outlined below and borrowed from [14]; implementations MAY use this approach or MAY select an alternative defense. Note that the described defense relies on the user providing the identity in response to an initial Identity EAP-Request.
EAPメッセージの断片化の場合には、それは、OTPのほとんどに耳を傾け、残りを推測して、認証を完了するために、正当なユーザーにレースをする攻撃者のために（この方法の基本的なバリアントで）可能です。準拠したバックエンド認証サーバの実装は、この競合状態から保護しなければなりません。この攻撃に対する防御一つは、以下に概説して[14]から借用されます。実装は、このアプローチを使用したり、代わりの防衛を選択することができます。説明防衛が最初のアイデンティティEAP-の要求に応じて、身元を提供するユーザーに依存していることに注意してください。
One possible defense is to prevent a user from starting multiple simultaneous authentication sessions. This means that once the legitimate user has initiated authentication, an attacker would be blocked until the first authentication process has completed. In this approach, a timeout is necessary to thwart a denial-of-service attack.
一つの可能な防衛は複数の同時認証セッションを開始するからユーザーを防ぐためです。これは、正当なユーザーが認証を開始した後、最初の認証処理が完了するまで、攻撃者がブロックされることを意味しています。このアプローチでは、タイムアウトは、サービス拒否攻撃を阻止する必要があります。
This document is a description of a general EAP method for OTP tokens. It also defines EAP method 32 as a profile of the general method. Extending the set of EAP-POTP TLVs or the set of EAP-POTP cryptographic algorithms shall be seen as revisions of the protocol and hence shall require an RFC that updates or obsoletes this document.
この文書では、OTPトークンのための一般的なEAP方式の説明です。それはまた、一般的な方法のプロファイルとしてEAPメソッド32を画定します。 EAP-POTPのTLVのセットを拡張またはEAP-POTP暗号アルゴリズムのセットは、プロトコルの改訂として見なければならない、したがって、この文書を更新または廃止RFCを要求しなければなりません。
A new registry for EAP-POTP cryptographic algorithm identifier octets has been created. The initial contents of this registry are as specified in Section 4.11.16.
EAP-POTP暗号アルゴリズム識別子のオクテットのための新しいレジストリが作成されています。セクション4.11.16に指定されているこの登録の初期の内容は。
Assignment of new values for hash algorithms, encryption algorithms, and MAC algorithms in the Crypto Algorithm TLV MUST be done through IANA with "Specification Required" and "IESG Approval" (see [9] for the meaning of these terms).
暗号化アルゴリズムTLVで新しいハッシュアルゴリズムの値、暗号化アルゴリズム、およびMACアルゴリズムの割り当ては、「仕様が必要」と「IESG承認」（これらの用語の意味については、[9]を参照）でIANAを介して行う必要があります。
RSA, RSA Security, and SecurID are either registered trademarks or trademarks of RSA Security Inc. in the United States and/or other countries. The names of other products and services mentioned may be the trademarks of their respective owners.
RSA、RSAセキュリティ、およびSecurIDは米国およびその他の国における登録商標または商標ですRSA Security Inc.の米国および/またはその他の国のいずれかです。言及した他の製品およびサービスの名称はそれぞれの所有者の商標である場合があります。
This document was improved by comments from, and discussion with, a number of RSA Security employees. Simon Josefsson drafted the initial versions of an RSA SecurID EAP method while working for RSA Laboratories. The inspiration for the TLV-type of information exchange comes from [17]. Special thanks to Oliver Tavakoli of Funk Software who provided numerous useful comments and suggestions, Randy Chou of Aruba Networks for good suggestions in the session resumption area, and Jim Burns of Meetinghouse who provided inspiration for the Protected TLV. Thanks also to the IESG reviewers, Pasi Eronen, David Black, and Uri Blumenthal, for insightful comments that helped to improve the document, and to Alfred Hoenes for a thorough editorial review.
この文書はからのコメント、およびRSAセキュリティ従業員の数、との話し合いにより改善されました。 RSA研究所に勤務しながら、サイモンJosefsson氏は、RSA SecurIDのEAPメソッドの初期バージョンを起草しました。情報交換のTLVタイプのためのインスピレーションは、[17]から来ています。数多くの有益なコメントや提案を提供ファンク・ソフトウェアのオリバーTavakoli、セッション再開エリアの良い提案のためのアルバネットワークスのランディ・チョウ、および保護されたTLVのためのインスピレーションを提供集会所のジム・バーンズに感謝します。徹底した編集レビューのためにも、IESGの審査、パシEronen、デビッド・ブラック、およびウリブルーメンソールに、文書を改善するために役立った洞察に満ちたコメント、およびアルフレッドHoenesに感謝します。
[1] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[1]ブルンク、L.、Vollbrecht、J.、Aboba、B.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, February 2004.
[3]アメリカ国立標準技術研究所を、「ハッシュ標準セキュア」、2004年2月、180-2をFIPS。
[4] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197, November 2001.
[4]アメリカ国立標準技術研究所、「高度暗号化標準（AES）のための仕様」には、2001年11月、197 FIPS。
[5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[5] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[6] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[6] Kaliski、B.、 "PKCS＃5：パスワードベースの暗号化仕様バージョン2.0"、RFC 2898、2000年9月。
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[7] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[8] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[8] Schulzrinneと、H.、 "電話番号については、TEL URI"、RFC 3966、2004年12月に。
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
[9] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、RFC 2434、1998年10月。
[10] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[10]シンプソン、W.、編、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[11] The Institute of Electrical and Electronics Engineers, Inc., "IEEE Standard for Local and metropolitan area networks -- Port-Based Network Access Control", IEEE 802.1X-2001, July 2001.
[11]電気電子技術者協会、「ローカルおよびメトロポリタンエリアネットワークのためのIEEE規格 - ポートベースのネットワークアクセス制御」、IEEE 802.1X-2001、2001年7月。
[12] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[12]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[13] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[13]スタンレー、D.、ウォーカー、J.、およびB. Aboba、 "無線LANのための拡張認証プロトコル（EAP）メソッド要件"、RFC 4017、2005年3月。
[14] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time Password System", STD 61, RFC 2289, February 1998.
[14]ハラー、N.、メス、C.、Nesser、P.、およびM.わら、 "ワンタイムパスワードシステム"、STD 61、RFC 2289、1998年2月。
[15] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤルイン" [15] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン。
[16] Aboba, B., Simon, D., Eronen, P., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, October 2006.
[16] Aboba、B.、サイモン、D.、Eronen、P.、およびH. Levkowetz、エド。、 "拡張認証プロトコル（EAP）鍵管理フレームワーク"、進歩、2006年10月に作業。
[17] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
[17] Palekar、A.、サイモン、D.、ゾルン、G.、Salowey、J.、周、H.、およびS. Josefsson氏、 "保護されたEAPプロトコル（PEAP）バージョン2"、進歩、2004年10月作業は。
[18] Internet Assigned Numbers Authority, "Private Enterprise Numbers", December 2006.
[18]インターネット割り当て番号機関、「民間企業番号」、2006年12月。
[19] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[19]ツォルン、G.は、 "マイクロソフトのベンダー固有のRADIUSアトリビュート"、RFC 2548、1999年3月。
Appendix A. Profile of EAP-POTP for RSA SecurID
RSA SecurIDのEAP-POTPの付録A.プロフィール
Note: The RSA SecurID product is a hardware token card (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication.
注：RSA SecurIDの製品は、エンドユーザの認証のために使用されるRSAセキュリティ社によって製造ハードウェアトークンカード（またはそのソフトウェアエミュレーション）です。
The EAP method type identifier for the RSA SecurID profile of EAP-POTP is 32.
EAP-POTPのRSA SecurIDのプロファイルのEAPメソッドタイプ識別子は32です。
Peers and EAP servers implementing the SecurID profile of EAP-POTP SHALL conform to all EAP-POTP normative requirements in this Document. In addition, the New PIN TLV and the Protected TLV MUST be supported by peers.
EAP-POTPのSecurIDのプロファイルを実装するピアとEAPサーバは、このドキュメント内のすべてのEAP-POTP規範的要件に適合しなければなりません。また、新しいPIN TLVと保護されたTLVは、ピアによってサポートしなければなりません。
Appendix B. Examples of EAP-POTP Exchanges
EAP-POTPの交流の付録B.例
This appendix is non-normative. In the examples, "V1", "V2", "V3", etc., stand for arbitrary values of the correct type.
この付録は非規範的です。実施例では、「V1」、「V2」、「V3」、等は、正しい型の任意の値を表します。
B.1. Basic Mode, Unilateral Authentication
B.1。基本モード、片側認証
This mode should only be used within a secured tunnel. The peer identifies itself with a User Identifier TLV.
このモードは、セキュアトンネル内で使用されるべきです。ピアユーザー識別子TLVで自身を識別する。
Peer EAP server
ピアEAPサーバ
<- EAP-Request
Type=Identity
EAP-Response -> Type=Identity
EAP-レスポンス - >タイプ=アイデンティティ
<- EAP-Request
Type=OTP-X
Version TLV: Highest=0,Lowest=0
バージョンTLV：最高= 0、最低= 0
OTP TLV: P=0,C=0,N=0,T=0,E=0,R=0
OTP TLV：P = 0、C = 0、N = 0、T = 0、E = 0、R = 0
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Version TLV: Highest=0
バージョンTLV：最高= 0
OTP TLV: P=0,C=0,N=0,T=0,E=0,R=0 Authentication Data=V1
OTP TLV：P = 0、C = 0、N = 0、T = 0、E = 0、R = 0認証データ= V1
User Identifier TLV: User Identifier=V2
ユーザ識別子TLV：ユーザ識別子= V2
<- EAP-Success
< - EAP-成功
B.2. Basic Mode, Session Resumption
B.2。基本モード、セッション再開
This example illustrates successful resumption of a basic mode session. It must be carried out only in a protected tunnel.
この例では、基本的なモードセッションの成功の再開を示しています。それだけで保護されたトンネルで行われなければなりません。
Peer EAP server
ピアEAPサーバ
<- EAP-Request
Type=Identity
EAP-Response -> Type=Identity
EAP-レスポンス - >タイプ=アイデンティティ
<- EAP-Request
Type=OTP-X
Version TLV: Highest=0,Lowest=0
バージョンTLV：最高= 0、最低= 0
OTP TLV: P=0,C=0,N=0,T=0,E=0,R=0
OTP TLV：P = 0、C = 0、N = 0、T = 0、E = 0、R = 0
Server-Info TLV: N=0 Session Identifier=V1 Server Identifier=V2 Nonce=V3 EAP-Response -> Type=OTP-X
サーバー情報TLV：N = 0セッション識別子= V1サーバー識別子= V2ナンス= V3 EAP-レスポンス - >タイプ= OTP-X
Version TLV: Highest=0
バージョンTLV：最高= 0
Resume TLV: Session Identifier=V4 (indicating earlier, basic mode, session) Authentication Data=V5
TLVを再開する：セッション識別子= V4（以前、基本モードを示す、セッション）認証データ= V5
<- EAP-Success
< - EAP-成功
B.3. Mutual Authentication without Session Resumption
B.3。セッション再開せずに相互認証
In this case, the peer uses the token key identifier, in addition to the user identifier. The initial EAP-Identity exchange may also provide user information, or may be restricted to only general domain information. Pepper is not used, but will be used in a subsequent session since the server provides the peer with an encrypted pepper in its Confirm TLV. Absence of the Crypto Algorithm TLV indicates use of default cryptographic algorithms.
この場合、ピアは、ユーザ識別子に加えて、トークンキー識別子を使用します。最初のEAP-アイデンティティ交換は、ユーザ情報を提供することができる、または唯一の一般的なドメイン情報に制限することができます。コショウが使用されず、サーバーが確認TLVで暗号化された胡椒ピアを提供するので、その後のセッションで使用されるであろう。暗号アルゴリズムTLVの不在は、デフォルトの暗号化アルゴリズムを使用することを示します。
Peer EAP server
ピアEAPサーバ
<- EAP-Request
Type=Identity
EAP-Response -> Type=Identity
EAP-レスポンス - >タイプ=アイデンティティ
<- EAP-Request
Type=OTP-X
Version TLV: Highest=0,Lowest=0
バージョンTLV：最高= 0、最低= 0
Server-Info TLV: N=0 Session Identifier=V1 Server Identifier=V2 Nonce=V3
サーバ情報TLV：N = 0セッション識別子= V1サーバ識別子= V2 = V3ノンス
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=0 Iteration Count=V4
OTP TLV：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= 0繰り返し回数= V4
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Version TLV: Highest=0
バージョンTLV：最高= 0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=0 Iteration Count=V4 Authentication Data=V5
OTP TLV：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= 0繰り返し回数= V4認証データ= V5
User Identifier TLV: User Identifier=V6
ユーザ識別子TLV：ユーザ識別子= V6
Token Key Identifier TLV: Token Key Identifier=V7
トークンキー識別子TLV：トークンキー識別子= V7
<- EAP-Request
Type=OTP-X
Confirm TLV: C=0 Authentication Data=V8 Pepper Identifier=V9 Encrypted Pepper=V10
TLVを確認：C = 0認証データ= V8ペッパー識別子= V9暗号化ペッパー= V10
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Confirm TLV: (no data)
TLVを確認します（データなし）
<- EAP-Success
< - EAP-成功
B.4. Mutual Authentication with Transfer of Pepper
B.4。ペッパーの譲渡との間で相互認証
The difference between this example and the previous one is that the peer makes use of an existing pepper in the PBKDF2 computation. The EAP server provides a new pepper to the peer in the Confirm TLV. Note that the peer had not been able to use a pepper in the response calculation unless it had found the existing pepper, since the server specified a maximum (new) pepper length of zero.
この例と前の違いは、ピアがPBKDF2計算における既存のコショウを利用することです。 EAPサーバは確認TLVでのピアに新しいコショウを提供します。それは既存のコショウを発見していない限り、サーバがゼロの最大値（新しい）コショウの長さを指定するので、ピアは、応答計算に唐辛子を使用することができていなかったことに留意されたいです。
Peer EAP server
ピアEAPサーバ
<- EAP-Request
Type=Identity
EAP-Response -> Type=Identity
EAP-レスポンス - >タイプ=アイデンティティ
<- EAP-Request
Type=OTP-X
Version TLV: Highest=0,Lowest=0
バージョンTLV：最高= 0、最低= 0
Server-Info TLV: N=0 Session Identifier=V1 Server Identifier=V2 Nonce=V3
サーバ情報TLV：N = 0セッション識別子= V1サーバ識別子= V2 = V3ノンス
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=0 Iteration Count=V4
OTP TLV：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= 0繰り返し回数= V4
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Version TLV: Highest=0
バージョンTLV：最高= 0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V5 Iteration Count=V6 Authentication Data=V7 (includes a pepper identifier)
OTP TLV：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= V5反復回数= V6認証データ= V7（コショウ識別子を含みます）
User Identifier TLV: User Identifier=V8
ユーザ識別子TLV：ユーザ識別子= V8
Token Key Identifier TLV: Token Key Identifier=V9
トークンキー識別子TLV：トークンキー識別子= V9
<- EAP-Request
Type=OTP-X
Confirm TLV: C=0 Authentication Data=V10 Pepper Identifier=V11 Encrypted Pepper=V12
TLVを確認：C = 0認証データ= V10ペッパー識別子= V11暗号化ペッパー= V12
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Confirm TLV: (no data)
TLVを確認します（データなし）
<- EAP-Success B.5. Failed Mutual Authentication
< - EAP-成功B.5。失敗した相互認証
This example differs from the previous one in that the peer is not able to authenticate the server. Therefore, it sends an empty EAP-Response of type POTP-X, which the EAP server acknowledges by responding with an EAP-Failure. Pepper is not used.
この例では、ピアがサーバを認証することができないという点で、以前のものとは異なります。したがって、それはEAPサーバがEAP-失敗で応答によって認めタイプPOTP-Xの空のEAP-応答を送信します。ペッパーは使用されません。
Peer EAP server
ピアEAPサーバ
<- EAP-Request
Type=Identity
EAP-Response -> Type=Identity
EAP-レスポンス - >タイプ=アイデンティティ
<- EAP-Request
Type=OTP-X
Version TLV: Highest=0,Lowest=0
バージョンTLV：最高= 0、最低= 0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V1 Iteration Count=V2
OTP TLV：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= V1繰り返し回数= V2
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5
サーバー情報TLV：N = 0セッション識別子= V3サーバー識別子= V4ナンス= V5
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Version TLV: Highest=0
バージョンTLV：最高= 0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V1 Iteration Count=V2 Authentication Data=V6
OTP TLV：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= V1繰り返し回数= V2認証データ= V6
User Identifier TLV: User Identifier=V7
ユーザ識別子TLV：ユーザ識別子= V7
Token Key Identifier TLV: Token Key Identifier=V8
トークンキー識別子TLV：トークンキー識別子= V8
<- EAP-Request
Type=OTP-X
Confirm TLV: C=0 Authentication Data=V9
TLVを確認：C = 0認証データ= V9
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
(no data)
（データなし）
<- EAP-Failure
< - EAP-失敗
B.6. Session Resumption
B.6。セッション再開
This example illustrates successful session resumption.
この例では、成功したセッションの再開を示しています。
Peer EAP server
ピアEAPサーバ
<- EAP-Request
Type=Identity
EAP-Response -> Type=Identity
EAP-レスポンス - >タイプ=アイデンティティ
<- EAP-Request
Type=OTP-X
Version TLV: Highest=0,Lowest=0
バージョンTLV：最高= 0、最低= 0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V1 Iteration Count=V2
OTP TLV：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= V1繰り返し回数= V2
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5
サーバー情報TLV：N = 0セッション識別子= V3サーバー識別子= V4ナンス= V5
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Version TLV: Highest=0
バージョンTLV：最高= 0
Resume TLV: Session Identifier=V6 (indicating earlier, protected mode, session) Authentication Data=V7
TLVを再開する：セッション識別子= V6（先に示し、保護モード、セッション）認証データ= V7
<- EAP-Request
Type=OTP-X
Confirm TLV: C=0 Authentication Data=V8
TLVの確認：C = 0認証データ= V8
EAP-Response -> Type=OTP-X Confirm TLV: (no data)
EAP-レスポンス - >タイプ= OTP-X TLVを確認します（データなし）
<- EAP-Success
< - EAP-成功
B.7. Failed Session Resumption
B.7。失敗したセッション再開
This example illustrates a failed session resumption, followed by a complete mutual authentication. The user is identified through the User Identifier TLV. The client is able to reuse an older pepper. The server sends a new pepper for subsequent use in its Confirm TLV. The server suggests some non-default cryptographic algorithms, but the client only supports the default ones.
この例では、完全な相互認証に続く失敗したセッションの再開を、示しています。ユーザーは、ユーザー識別子TLVによって識別されます。クライアントは、古いコショウを再利用することができます。サーバーは、その確認TLVにおけるその後の使用のための新しいコショウを送信します。サーバーは、いくつかの非デフォルトの暗号化アルゴリズムを提案しているが、クライアントは、デフォルトのものをサポートしています。
Peer EAP server
ピアEAPサーバ
<- EAP-Request
Type=Identity
EAP-Response -> Type=Identity
EAP-レスポンス - >タイプ=アイデンティティ
<- EAP-Request
Type=OTP-X
Version TLV: Highest=0,Lowest=0
バージョンTLV：最高= 0、最低= 0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V1 Iteration Count=V2
OTP TLV：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= V1繰り返し回数= V2
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5
サーバー情報TLV：N = 0セッション識別子= V3サーバー識別子= V4ナンス= V5
Crypto Algorithm TLV: Hash Alg. Length=V6 Hash Algorithms=V7 Encr. Alg. Length=V8 Encr. Algorithms=V9 MAC Alg. Length=V10 MAC Algorithms=V11
暗号アルゴリズムTLV：ハッシュALG。長さ= V6ハッシュアルゴリズム= V7 ENCR。 ALG。長さ= V8 ENCR。アルゴリズム= V9 MAC ALG。長さ= V10 MACアルゴリズム= V11
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Version TLV: Highest=0
バージョンTLV：最高= 0
Resume TLV: Session Identifier=V12 (indicating earlier session) Authentication Data=V13
再開TLV：（以前のセッションを示す）セッション識別子= V12認証データ= V13
<- EAP-Request
Type=OTP-X
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V14 Iteration Count=V15
OTP TLV：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= V14繰り返し回数= V15
Server-Info TLV: N=1 (no resumption) Session Identifier=V3 Server Identifier=V4 Nonce=V16
サーバ情報TLV：N = 1（なし再開）セッション識別子= V3サーバ識別子= V4ノンス= V16
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
OTP TLV: P=1,C=0,N=1,T=1,E=0,R=0 Pepper Length=V17 Iteration Count=V18 Authentication Data=V19 (with pepper identifier)
OTP TLV：P = 1、C = 0、N = 1、T = 1、E = 0、R = 0ペッパー長= V17繰り返し回数= V18認証データ= V19（コショウ識別子を有します）
User Identifier TLV: User Identifier=V20
ユーザ識別子TLV：ユーザ識別子= V20
<- EAP-Request
Type=OTP-X
Confirm TLV: C=0 Authentication Data=V21 Pepper Identifier=V22 Encrypted Pepper=V23 EAP-Response -> Type=OTP-X
確認TLV：C = 0認証データ= V21ペッパー識別子= V22暗号化ペッパー= V23 EAP-応答 - >タイプ= OTP-X
Confirm TLV: (no data)
TLVを確認します（データなし）
<- EAP-Success
< - EAP-成功
B.8. Mutual Authentication, and New PIN Requested.
B.8。相互認証、および新しいPINを要求しました。
In this example, the user is also requested to select a new PIN. The new PIN is allowed to be alphanumeric, and must be at least 6 characters long. The user selects another PIN than the one suggested by the server. The token key is identified through a combination of the user identifier and the token key identifier. While waiting for the user input, to avoid network timeouts, the peer sends an EAP-Response containing a Keep-Alive TLV to the EAP server. The EAP server responds by sending an EAP-Request containing a Keep-Alive TLV back to the peer. Note that all TLVs exchanged after the Confirm TLV exchange are wrapped in the Protected TLV. Absence of the Crypto Algorithm TLV indicates use of default cryptographic algorithms.
この例では、ユーザーは新しいPINを選択するように要求されています。新しいPINは、英数字であることを許可され、少なくとも6つの文字でなければなりません。ユーザーはサーバーによって提案されたものよりも、別のPINを選択します。トークンキーは、ユーザ識別子及びトークンキー識別子の組み合わせによって識別されます。ネットワークのタイムアウトを回避するために、ユーザーの入力を待っている間、ピアはEAPサーバにキープアライブTLVを含むEAP-応答を送信します。 EAPサーバはバックピアにキープアライブTLVを含むEAP-Requestを送信して応答します。すべてのTLVが確認TLV交換が保護TLVでラップされた後に交換することに注意してください。暗号アルゴリズムTLVの不在は、デフォルトの暗号化アルゴリズムを使用することを示します。
Peer EAP server
ピアEAPサーバ
<- EAP-Request
Type=Identity
EAP-Response -> Type=Identity
EAP-レスポンス - >タイプ=アイデンティティ
<- EAP-Request
Type=OTP-X
Version TLV: Highest=0,Lowest=0
バージョンTLV：最高= 0、最低= 0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V1 Iteration Count=V2
OTP TLV：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= V1繰り返し回数= V2
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5
サーバー情報TLV：N = 0セッション識別子= V3サーバー識別子= V4ナンス= V5
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Version TLV: Highest=0
バージョンTLV：最高= 0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V6
OTP TLV：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= V6
Iteration Count=V7 Authentication Data=V8 (with pepper identifier)
（コショウ識別子を有する）繰り返し回数= V7認証データ= V8
User Identifier TLV: User Identifier=V9
ユーザ識別子TLV：ユーザ識別子= V9
Token Key Identifier TLV: Token Key Identifier=V10
トークンキー識別子TLV：トークンキー識別子= V10
<- EAP-Request
Type=OTP-X
Confirm TLV: C=1 Authentication Data=V11
TLVを確認：C = 1認証データ= V11
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Confirm TLV: (no data)
TLVを確認します（データなし）
<- EAP-Request
Type=OTP-X
Protected TLV: MAC=V12 IV=V13 Encrypted TLVs=V14 (Contains: New PIN TLV: Q=0,A=1 PIN=V15 Min. PIN Length=6)
保護されたTLV：MAC = V12のIV = V13暗号化されたTLV = V14は（含まれています：新しいPIN TLV：Q = 0、A = 1 PIN = V15分PINの長さ= 6）
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Protected TLV: MAC=V16 IV=V17 Encrypted TLVs=V18 (Contains: Keep-Alive TLV: (no data))
保護されたTLV：MAC = V16のIV = V17暗号化されたTLV = V18は（含まれています：キープアライブない-TLVを：（データを））
<- EAP-Request
Type=OTP-X
Protected TLV: MAC=V19 IV=V20 Encrypted TLVs=V21 (Contains: Keep-Alive TLV: (no data))
保護されたTLV：MAC = V19のIV = V20暗号化されたTLV = V21は（含まれています：キープアライブない-TLVを：（データを））
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Protected TLV: MAC=V22 IV=V23 Encrypted TLVs=V24 (Contains: New PIN TLV: Q=0,A=0 PIN=V25)
保護されたTLV：MAC = V22のIV = V23暗号化されたTLV = V24は（含まれています：新しいPIN TLV：Q = 0、A = 0 PIN = V25）
<- EAP-Request
Type=OTP-X
Protected TLV: MAC=V26 IV=V27 Encrypted TLVs=V28 (Contains: OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V1 Iteration Count=V2)
保護されたTLV：MAC = V26のIV = V27暗号化のTLV = V28は、（含ま：OTP TLV：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= V1繰り返し回数= V2 ）
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Protected TLV MAC=V29 IV=V30 Encrypted TLVs=V31 (Contains: OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V6 Iteration Count=V7 Authentication Data=V31)
保護されたTLV MAC = V29のIV = V30暗号化のTLV = V31は、（含ま：OTP TLVを：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= V6繰り返し回数= V7認証データ= V31）
<- EAP-Request
Type=OTP-X
Protected TLV MAC=V32 IV=V33 Encrypted TLVs=V34 (Contains: Confirm TLV: C=0 Authentication Data=V35)
保護されたTLV MAC = V32 IVは= V33暗号化のTLV = V34は、（含まれています：TLVを確認：C = 0認証データ= V35）
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Protected TLV MAC=V36 IV=V37 Encrypted TLVs=V38 (Contains: Confirm TLV: (no data))
保護されたTLV MAC = V36のIV = V37暗号化されたTLVが（：TLVを確認します（データなし）を含みます）V38を=
<- EAP-Success
< - EAP-成功
B.9. Use of Next OTP Mode
B.9。次OTPモードの使用
In this example, the peer is requested to provide a second OTP to the EAP server.
この例では、ピアはEAPサーバに第二OTPを提供するために要求されます。
Peer EAP server
ピアEAPサーバ
<- EAP-Request
Type=Identity
EAP-Response -> Type=Identity
EAP-レスポンス - >タイプ=アイデンティティ
<- EAP-Request
Type=OTP-X
Version TLV: Highest=0,Lowest=0
バージョンTLV：最高= 0、最低= 0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V1 Iteration Count=V2
OTP TLV：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= V1繰り返し回数= V2
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5
サーバー情報TLV：N = 0セッション識別子= V3サーバー識別子= V4ナンス= V5
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Version TLV: Highest=0
バージョンTLV：最高= 0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V6 Iteration Count=V7 Authentication Data=V8
OTP TLV：P = 1、C = 0、N = 0、T = 0、E = 0、R = 0ペッパー長= V6繰り返し回数= V7認証データ= V8
User Identifier TLV: User Identifier=V9
ユーザ識別子TLV：ユーザ識別子= V9
<- EAP-Request
Type=OTP-X
OTP TLV: P=1,C=0,N=1,T=1,E=0,R=0 Pepper Length=V1 Iteration Count=V2
OTP TLV：P = 1、C = 0、N = 1、T = 1、E = 0、R = 0ペッパー長= V1繰り返し回数= V2
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
OTP TLV: P=1,C=0,N=1,T=1,E=0,R=0 Pepper Length=V6 Iteration Count=V7 Authentication Data=V10
OTP TLV：P = 1、C = 0、N = 1、T = 1、E = 0、R = 0ペッパー長= V6繰り返し回数= V7認証データ= V10
<- EAP-Request
Type=OTP-X
Confirm TLV: C=0 Authentication Data=V11
TLVを確認：C = 0認証データ= V11
EAP-Response -> Type=OTP-X
EAP-レスポンス - >タイプ= OTP-X
Confirm TLV: (no data)
TLVを確認します（データなし）
<- EAP-Success
< - EAP-成功
Appendix C. Use of the MPPE-Send/Receive-Key RADIUS Attributes
MPPE-送信/受信キーRADIUS属性の付録C.使用
C.1. Introduction
C.1。前書き
This section describes how to populate the MPPE-Send-Key and the MPPE-Receive-Key RADIUS attributes defined in [19], using an MSK established in EAP-POTP.
このセクションでは、MPPE-Send-KeyおよびMPPE-受信キーRADIUSは、EAP-POTPに設立されたMSKを使用して、[19]で定義された属性を移入する方法について説明します。
C.2. MPPE Key Attribute Population
C.2。 MPPEキー属性の人口
Once the EAP-POTP MSK has been generated, it is used as follows to populate the MPPE-Send-Key and the MPPE-Receive-Key attributes:
EAP-POTP MSKが生成されると、MPPE-Send-KeyおよびMPPE-受信キー属性を移入するために、次のように使用されます。
Use the initial 32 octets of the MSK as the value for the "Key" sub-field in the plaintext "String" field of the MPPE-Send-Key attribute, and use the final 32 octets of the MSK as the "Key" sub-field in the plaintext "String" field of the MPPE-Receive-Key attribute (Note: "Send" and "Receive" here refer to the Authenticator; for the peer, they are reversed).
MSKの最初の32個のオクテットは平文で「キー」サブフィールドの値としてMPPE-SEND-Key属性の「文字列」フィールドを使用して、「キー」サブとしてMSKの最終32個のオクテットを使用します-fieldの平文「文字列」フィールドにMPPE-受信-Key属性（注：認証を参照してくださいここでは、「受信」「送信」と、ピアのために、彼らは逆になっています）。
Appendix D. Key Strength Considerations
付録D.強みの考慮事項
D.1. Introduction
D.1。前書き
As described in Section 6, the strength of keys generated in EAP-POTP protected mode depends on a number of factors. This appendix provides examples of actual key strengths achieved under various assumptions.
第6節で説明したように、EAP-POTP保護モードで生成されたキーの強度は、多数の要因に依存します。この付録では、様々な仮定の下で達成される実際の強みの例を提供します。
It should be noted that, while some of the examples indicate that the strength of generated keys is relatively weak, the strength applies only to those EAP-POTP sessions between a peer and an EAP server that do not share a pepper. Once a pepper, provided by an EAP server to a peer, has been established, future sessions using this pepper will provide full-strength keys.
実施例のいくつかは、生成されたキーの強度が比較的弱いことを示しているが、強度のみピアと胡椒を共有していないEAPサーバとの間のものEAP-POTPセッションに適用されることに留意すべきです。ピアにEAPサーバによって提供さコショウは、確立された後、この唐辛子を使用して、将来のセッションでは、フル強度キーを提供します。
D.2. Example 1: 6-Digit One-Time Passwords
D.2。例1：6桁ワンタイムパスワード
In this example we assume the following:
この例では、次のことを前提としています。
OTPs are six decimal digits long;
OTPを、6つの桁の長さです。
4-digit PINs are added to generated OTPs; and
4桁のPINを生成のOTPに添加されます。そして
OTP hardening (iteration count and pepper searching combined) effectively adds 10 bits of entropy. One way of achieving this without use of pepper searching is to have the iteration count in PBKDF2 set to 1,000,000.
OTP硬化（反復回数とコショウ合わせ検索は）効果的エントロピーの10ビットを追加します。唐辛子の検索を使用せずにこれを達成する一つの方法はPBKDF2における反復回数が1,000,000に設定されていることです。
The effective key strength then becomes roughly:
実効キー強度は、おおよそ次のようになります。
log_2(10**6) + log_2(10**4) + log_2(2**10) = 43 bits
log_2（10 ** 6）+ log_2（10 ** 4）+ log_2（2 ** 10）= 43ビット
The above assumes that the entropy of the underlying shared secret is >43 bits and that there are no other weaknesses in the OTP algorithm.
上記下にある共有秘密のエントロピーは> 43ビットであり、OTPアルゴリズムにおける他の弱点が存在しないことと仮定しています。
D.3. Example 2: 8-Digit One-Time Passwords
D.3。例2：8桁のワンタイムパスワード
In this example we assume the following:
この例では、次のことを前提としています。
OTPs are eight decimal digits long;
OTPをは8桁の長さです。
4-character alphanumeric PINs are added to generated OTPs; and
4文字の英数字PINは発生のOTPに添加されます。そして
OTP hardening (iteration count and pepper searching combined) effectively adds 10 bits of entropy.
OTP硬化（反復回数とコショウ合わせ検索は）効果的エントロピーの10ビットを追加します。
The effective key strength then becomes roughly:
実効キー強度は、おおよそ次のようになります。
log_2(10**8) + log_2(26**4) + log_2(2**10) = 55 bits
log_2（10 ** 8）+ log_2（26 ** 4）+ log_2（2 ** 10）= 55ビット
The above assumes that the entropy of the underlying shared secret is >55 bits and that there are no other weaknesses in the OTP algorithm.
上記下にある共有秘密のエントロピーは> 55ビットであり、OTPアルゴリズムにおける他の弱点が存在しないことと仮定しています。
Author's Address
著者のアドレス
Magnus Nystroem RSA Security
マグナスNystroem RSAセキュリティ
EMail: magnus@rsa.com
メールアドレス：magnus@rsa.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。