[要約] RFC 4793は、EAP-POTPプロトコルに関する仕様であり、ワンタイムパスワードの保護を目的としています。このプロトコルは、認証のためのセキュアな方法を提供します。
Network Working Group M. Nystroem
Request for Comments: 4793 RSA Security
Category: Informational February 2007
The EAP Protected One-Time Password Protocol (EAP-POTP)
EAPは1回限りのパスワードプロトコル（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）The IETF Trust（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).
このドキュメントでは、1回限りのパスワード（OTP）トークンでの使用に適した一般的な拡張可能な認証プロトコル（EAP）メソッドについて説明し、関連するクライアントに直接電子インターフェイスを備えたトークンに特別な利点を提供します。この方法は、PPP、IEEE 802.1x、Internet Key Exchange Protocolバージョン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].
このドキュメントでは、1回限りのパスワード（OTP）トークンでの使用に適した拡張可能な認証プロトコル（EAP）[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]).
1回限りのパスワード（OTP）トークンは、ハンドヘルドハードウェアデバイス、USBなどの電子インターフェイスを介してパーソナルコンピューターに接続されたハードウェアデバイス、またはパーソナルコンピューターのソフトウェアモジュール居住者である場合があります。ユーザーを何らかのサービスに認証するために使用されます。このドキュメントでは、OTPトークンを相互運用可能な方法で使用してユーザーをEAPで認証することを希望する組織のニーズを満たすことを目的としたEAPメソッドについて説明します。この方法は、特定のOTPアルゴリズムから独立しており、最新のEAPメソッドに関する要件を満たすように設計されています（[13]を参照）。
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 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-POTPは、メッセージとデータ要素がEAP実装によって簡単に解析されることを目的として設計されています。これにより、ピアと認証機のEAPメソッドをプログラム的に使用しやすくなり、ユーザーインタラクションの必要性が減り、必要に応じてローカル生成のユーザープロンプトが可能になります。対照的に、EAPサーバーによって生成されたテキスト文字列を使用する[1]の汎用トークンカード（GTC）メソッドは、人間によって解釈され、行動することを目的としています。さらに、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メソッドは、特定の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メソッドであるEAP-POTPにも当てはまります。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].
このドキュメントの「必須」、「そうしない」、「そうしない」、「そうしない」、「そうしない」、「そうではない」、「はない」、「推奨」、「5月」は、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 Authenticatorに認証サービスを提供するバックエンド認証サーバー。
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 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.
「EAPサーバー」という用語は、[1]と同じ意味でここで使用されます。AuthenticatorとBackEnd Authentication Serverの間で使用されるプロトコルは、このドキュメントの範囲外ですが、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メソッドは、ユーザーがユーザーを認証できるように認証サーバーに情報を提供する1つのサービス（つまり、ユーザー認証）のみを提供します。より高度なバリアントは、相互認証、盗聴に対する保護、および認証されたキーイング材料の確立を提供します。
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メソッドタイプ識別子のプレースホルダーとして以下で使用され、EAP-POTPを使用した特定のOTPアルゴリズムの使用を識別します。例として、EAP-POTP内でRSA Securidトークンを使用する場合、EAPメソッドタイプは32でなければなりません（付録Aを参照）。
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. RFC 3748 [1]に従って、オプションのEAP IDリクエスト/応答が交換されます。ここで提供される身元は、「ユーザー識別子」または「トークンキー識別子」トリプレット（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-RequestにOTP TLVも含まれます。OTP TLVは、現在のOTP（おそらく保護された形式）で応答するようにピアに指示し、サーバーポリシーなどの課題やその他の情報を含む場合があります。EAPサーバーには、リクエストにサーバーINFO TLVも含める必要があり、セッション再開をサポートする場合はそうする必要があります。Server-INFO 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. ピアは、POTP-Xをサポートしていない場合、またはサーバーのバージョンTLVに示されているように、サーバーによってサポートされているこのメソッドのバージョンをサポートしていない場合、型NAK（3）のEAP応答で応答します。
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:
ピアがEAPサーバーによってもサポートされているこのメソッドのバージョンをサポートする場合、ピアは次のように型POTP-XのEAP応答を生成します。
* 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サーバーがサーバーINFO TLVを送信した場合、ピアはEAPサーバーで保存されたセッションがあるかどうかをチェックします。サーバーとの既存のセッションが見つかり、セッション再開が可能である場合（サーバーとFO 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 TLVが含まれている場合、ピアリクエスト（ユーザーインタラクションによる）OTPトークンは、情報に基づいて1回限りのパスワードを計算します受信したEAP-Requestメッセージ（たとえば、挑戦する可能性がある）では、現在のトークン状態（トークン時間など）、共有秘密（「シード」）、およびユーザーが提供するピン（それに注意してください。OTPトークンタイプに応じて、EAP-Requestの情報の一部はOTP計算では使用されず、PINもオプションである場合があります）。受信したOTP TLVにPビットセットがある場合（以下を参照）、ピアはトークンが提供するOTPと他の情報を組み合わせて、組み合わせたデータをキー派生関数に提供します。キー派生関数はいくつかのキーを生成します。このキーは、受信したメッセージのメッセージ認証コード（MAC）を計算するために使用され、他の情報と一緒に生成されます。結果のMACは、いくつかの追加情報とともに、バージョンTLVとともに、EAPサーバーへの応答で送信されるOTP TLV（Pビットセット）に配置されます。受信したOTP TLVでPビットが設定されていない場合、ピアは代わりに計算されたOTP値をOTP TLVに直接挿入し、バージョンTLVと一緒にEAPサーバーに送信されます。
* 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サーバーがタイプNAK（3）のEAP応答を受信した場合、セッションのネゴシエーションは失敗し、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),
* セッションの再開が不可能であることを示すタイプPOTP-Xの新しいEAP-Requestをピアに送信し、新しいOTPを要求します（これは、ピアが履歴書TLVで応答し、履歴書に示されたセッションが示された場合に当てはまります。TLVは無効でした）、
* send a new EAP-Request of type POTP-X to the peer (e.g., to ask for the next OTP),
* タイプPOTP-Xの新しいEAP-Requestをピアに送信します（例：次のOTPを求める）、
* 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ビットセットがある場合、または保護されたモードセッション再開で成功した試みであった場合、PEERにTLVを確認するEAP-Requestメッセージを送信します。ピア）、または
* fail the authentication (and send an EAP-Failure message -- possibly preceded by an EAP-Request message of type Notification (2) -- to the peer).
* 認証に失敗します（そして、Peerにタイプ通知（2）のEAP-Requestメッセージの前にEAPフェイルメッセージを送信してください）。
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.
e. ピアがEAP-SUCSESSまたはEAP-Failureメッセージを受け取った場合、プロトコルの実行が終了します。ピアがタイプ通知のEAP-Requestを受け取った場合、RFC 3748 [1]で指定されているように応答します。ピアが確認TLVを使用してタイプPOTP-XのEAP-Requestを受信した場合、提供されたデータを使用してEAPサーバーを認証しようとします。認証が成功した場合、ピアは、確認TLVを使用してPOTP-XタイプのEAP応答で応答します。失敗した場合、ピアはPOTP-Xタイプの空のEAP応答で応答します。ピアが他のいくつかのTLVを含むタイプPOTP-XのEAP-Requestを受け取った場合、上記（この場合はバージョンの交渉は行われませんが）またはそれらのTLVについて説明されているように、それはcで指定されているように継続します。
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リクエストを送信したEAPサーバーが、確認TLV存在の確認型POTP-XのEAP応答を受信すると、2つの方法のいずれかで進行できます。タイプPOTP-Xの追加のEAP要求を送信する必要があることを検出し、それは「保護された状態」に入り、それ以降、すべてのPOTP-X TLVを暗号化して整合性保護する必要があります（で送信する必要があります（この点、当事者は、セクション4.5で説明されているように、マスターセッションキーを計算するものとします。確認TLVの交換後にPOTP-X会話を続ける理由の1つは、ユーザーがOTPピンを更新する必要があることです。したがって、EAPサーバーは新しいPIN TLVを送信する必要があります。その時点で、握手はステップc）上に戻っています（バージョンの交渉とすべてのTLVの保護を除く）。追加のEAP-Requestパケットを送信する必要がない場合、EAPサーバーは代わりにPEERにEAP-SUSCESSメソッドを送信して、プロトコルの完了が成功することを示します。EAPサーバーは、確認TLVでそうするつもりであることを示さない限り、会話を続けることはできません。
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.
確認TLVを使用してPOTP-XタイプのEAPリクエストを送信し、空の型POTP-XのEAP反応を受信したEAPサーバーは、空の（つまり、TLVを含む）、EAPで応答するものとします。 - 握手と握手を終了します。
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).
説明で暗示されているように、手順c）からf）からf）は、交換が完了する前に何度も実行できます。この例の例は、認証サーバーが最初にOTPを要求し、ピアからの応答を受け入れ、（仲介者）の確認TLV交換を実行し、ピアに新しいピンを選択するように要求し、最終的にピアにOTPベースの認証を求めるときです。新しいピン（再び最終的な確認TLV交換が続きます）。
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-Requestでは、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に示されている「最高の」サポートされているバージョンをサポートしている場合、EAP-Requestに含まれるTLVトリプレットにも応答する必要があります。
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.
EAPピアは、EAPサーバーが示すバージョンの範囲内にあるバージョンをサポートしていない場合、型NAK（3）のEAP応答で応答する必要があります。これにより、EAPサーバーは別のEAPメソッドをピア認証に使用できます。
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 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-POTPは、デフォルトのダイジェストアルゴリズム（SHA-256）[3]、デフォルトの暗号化アルゴリズム（AES-CBC）[4]、およびデフォルトのMACアルゴリズム（HMAC）[5]を提供し、これらのアルゴリズムはすべてによってサポートされる必要があります。EAP-POTP実装。デフォルトのアルゴリズムよりも他のアルゴリズムを使用したくないEAPサーバーは、暗号アルゴリズムTLVを送信する必要はありません。他のいくつかのアルゴリズムの使用を交渉したいEAPサーバーは、PビットセットのOTP TLVも含むタイプPOTP-Xの最初のEAP要求で暗号アルゴリズムTLVを送信する必要があります。TLVは、セッションの他のEAP-Requestに存在してはなりません。（これの2つの例外は、1）クライアントが失敗したため、送信された暗号アルゴリズムTLVを評価しなかったセッション再開を試みた場合、または2）暗号アルゴリズムTLVがEAPサーバーからの最初のメッセージの一部であり、クライアントは、EAPサーバーでサポートされている最高のバージョンよりも別のEAP-POTPバージョンを交渉しました。これらのケースのいずれかが適用される場合、サーバーは、Cryptoアルゴリズム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.
ピアは、Crypto Algorithm TLVを含むタイプPOTP-XのEAP-Requestが受信された場合にのみ、EAP応答に暗号アルゴリズムTLVを含める必要があります。ピアは既存のセッションを再開しようとせず、ピアとEAPサーバーは、少なくとも1つのアルゴリズムがデフォルトのものではないことに同意します。ピアが、応答する暗号アルゴリズム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.
PeerがEAPサーバーに関連付けられたセッションを見つけるのを支援するために、セッション再開をサポートするEAPサーバーは、OTP TLVを含むタイプPOTP-Xの最初のEAP-Requestにサーバー識別子を含むサーバーINFO TLVを送信する必要があります。。識別子は、ルックアップの目的でピアによって使用される場合があります。
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:
o EAPサーバーが以前に確立されたセッションを再開することをいとわない場合、履歴書TLVの内容に基づいてピアを認証する必要があります。認証が成功した場合、握手は2つの方法のいずれかで続きます。
* 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サーバーを認証すると、PEERは空の確認TLVで応答し、EAPサーバーはEAPサクセスメッセージで応答します。確認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サクセスメッセージで応答する必要があります。
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ビットセットを備えたサーバーINFO TLVを含む別のEAPレクストを送信して、セッション再開が不可能であることを示すように設定する必要があります。EAPサーバーは、EAPフェイルメッセージを送信する場合があります。これは、おそらくタイプ通知（2）の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).
o EAPサーバーが以前に確立されたセッションを喜んで再開または再開することができない場合、OTP TLVとnビットセットを備えたサーバーINFO 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は[5]のHMACコンストラクトです。SHA-256はハッシュ関数Hです。PBKDF2のPRFとして使用する場合、HMAC-SHA256の出力長は32オクテット（つまり、フル出力長）です。
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,
o K_ENC、認証中に特定のデータを保護するために使用される暗号化キー、
o SRK, a session resumption key only used for session resumption purposes,
o SRK、セッション再開目的でのみ使用されるセッション再開キー、
o MSK, a Master Session Key, as defined in [1], and
o [1]で定義されているマスターセッションキーであるMSKと
o EMSK, an Extended Master Session Key, also as defined in [1].
o [1]で定義されているように、拡張マスターセッションキーであるEMSK。
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オクテットでなければなりません。したがって、デフォルトアルゴリズムの場合、[6]のセクション5.2の「dklen」パラメーターは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）のEAP応答を送信することはできません（[1]、セクション2.1を参照）。代わりに、ピアが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-POTPセッション内でEAP通知方法を使用してはなりません。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サーバーは、OTP TLVを含むEAP応答を受信し、ユーザーを認証できない場合に、EAP-Requestのタイプ通知（2）を送信する場合があります。この場合、タイプ通知のEAP応答が受信されると、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を受信したときに、EAP-Requestのタイプ通知（2）を送信する場合があります。この場合、タイプ通知のEAP応答が受信されると、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:
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.
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.
このサーバーにペッパーが保管されており、サーバーが新しいペッパーが生成されることを示していない場合、以下のセクション4.11.3で指定されているように、OTP TLV応答を計算するために既存のコショウ値を使用します。この場合、スキームのセキュリティがコショウを通じて提供され、それ以外の場合は効率が失われるため、反復カウントは最小限に抑えられます。
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.
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を使用し、プロトコルセッションの整合性を確保します。このセクションでは、Macの計算方法と設計の理論的根拠を定義します。
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:
保護されたモードで、および認証資格情報（1回限りのパスワードや共有キーなど）を直接送信するのではなく、前のセッションを再開する場合、資格情報の知識の証拠が送信されます。この証拠は、キーK_MACを使用してセッションでこれまでに交換された（特定の部分の）EAP-POTPメッセージのハッシュ上のMACです。
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_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:
MACのメッセージハッシュを計算するには、EAPメッセージMSG_1、MSG_2、...、MSG_Nのシーケンスを考慮して、次の操作を実行するものとします。
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.
注：結果のメッセージのシーケンスは、EAP要求とEAP応答メッセージの交互のシーケンスでなければなりません。
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（応答）を備えているため、無害と見なされます。
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.
A summary of the EAP-POTP packet format is shown below. The fields are transmitted from left to right.
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
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.
長さフィールドは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).
このフィールドには、次のように定義された0、1、またはより多くのタイプ長値のトリプレットが含まれます（これは、PEAPV2 [17]で定義されたEAP-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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により、EAPサーバーはTLVが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.
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.
TLV Type
TLVタイプ
The following TLV types are defined for use with 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-将来の使用のために予約1-バージョン2 -Server -INFO 3 -OTP 4 -NAK 5-新しいピン6-確認7-ベンダー固有の8-履歴書9-ユーザー識別子10-トークンキー識別子11-タイムスタンプ12-カウンター13-キープアライブ14-保護された15-暗号アルゴリズム16-チャレンジ
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の最初のEAP-Requestと、ピアからのタイプPOTP-Xの最初の応答に存在する必要があります。セッションのその後のEAP-RequestまたはEAP-Responseに存在してはなりません。バージョン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
1
Length
長さ
3 in EAP-Requests, 2 in EAP-Responses
3 eap-requests、2回の応答で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-Requestに存在する必要があります。フィールドは、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.
サーバーINFO TLVには、EAPサーバーとセッションに関する情報が含まれています（該当する場合）。速いセッション再開のためのフレームワークの1つのピースを提供します。
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応答パケットに存在してはなりません。このTLVタイプは、この仕様に準拠しているすべてのピアによってサポートされている必要があり、NAK TLVで応答してはなりません（これは、すべてのピアがセッション再開をサポートする必要があるということではなく、NAK 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
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
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
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オクテットのノンセ。セッション再開中、このNonCEは、以下に指定するように、新しいK_ENC、K_MAC、SRK、MSK、およびEMSKキーを計算するときに使用されます。
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サーバー識別子との衝突のリスクを可能な限り減らすために選択する必要があります。1つの可能性は、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オクテットを超えてはなりません。識別子は、印刷可能な文字列のエンコードされた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は、新しいピンTLVを含むタイプPOTP-XのEAP-Requestに存在してはなりません。さらに、型POTP-Xの前のEAP-Requestが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
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.
リクエストが新しいPIN TLVを含むタイプPOTP-XのEAP応答をすぐに実行する場合にのみ、EAP-Requestで少し設定する必要があり（セクション4.11.5を参照）、応答の新しいピンが受け入れられましたEAPサーバーによって。この場合、AはEAPサーバーがピンを受け入れ、ピアが応答を計算するときに新しく確立されたピンを使用することを少し示します（該当する場合）。Sビットが設定されている場合、少し設定しないでください。リクエストにSビットとビットセットの両方がある場合、ピアはリクエストを無効と見なし、空の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応答では、設定されたときに少し回答して、新しく選択されたユーザーPINを使用してOTPが計算されたことを示します。応答をトリガーしたEAP-Requestが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応答メッセージで応答する必要があります。すべてのピアは保護モードをサポートする必要があります。
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が保護されていることを示しています（以下を参照）。応答をトリガーしたEAP-RequestがPビットセットを含むOTP TLVをトリガーした場合にのみ、Pビットを応答（したがってOTPを保護する必要があります）に設定する必要があります。
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].
LAN（Eapol）環境上の802.1x EAP（これにはワイヤレス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ビット（ "Combine"）は、OTPが提供された課題と内部状態（例：現在のトークン時間）の両方を使用して計算されることを示します。OTPは、Cビットが設定されておらず、課題が存在しない場合にのみ、提供された課題（および共有秘密）にのみ基づいて計算されます。返されたOTPは、課題が存在しない場合、ピアの現在の状態（および共有秘密）に基づいて常に計算されます。Cビットが設定されているが課題が提供されない場合、ピアは要求を無効と見なし、空のPOTP-X EAP応答メッセージを返します。
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-RequestがCビットセットと課題を備えたOTP TLVを含む場合にのみ、応答で設定する必要があります。
N
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ビットが設定されていない場合、nビットはEAP-Requestで意味を持ち、この場合は0に設定されます。nビットセットがあるリクエストにチャレンジも含まれているが、Cビットセットがない場合、ピアはリクエストを無効と見なし、空のPOTP-X EAP応答メッセージを返します。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-Requestが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計算にユーザーピンを組み込んだ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 BITは、設定すると、計算するOTPにユーザーピンを含めてはならないことを示します。
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 BITは、設定されたときに、OTPがユーザーPINを使用せずに計算されたことを示します。TビットをトリガーしたEAP-RequestがTビットセットでOTP TLVを含む場合にのみ、応答で設定する必要があります。クライアントポリシーは、ピンレスの計算を禁止する可能性があることに注意してください。これらの場合、クライアントは空のPOTP-X EAP応答メッセージで応答する場合があります。
E
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計算でこのサーバーに関連付けられた保存されたペッパー値を使用してはならないことを示します。むしろ、新しいペッパーを生成し（ピアによってサポートされている場合）、/または反復カウントパラメーターを使用してOTPを保護する必要があります（サーバーの最大ペッパーの長さが0の場合、ピアは反復カウントに依存する必要があります。OTP）。このビットは通常、最初のEAP-Requestメッセージで設定されませんが、たとえば、サーバーがペッパー識別子を備えたOTP TLVを受信すると、後続のメッセージで設定される場合があります。ストレージ。このビットには意味がなく、Pビットが設定されていない場合はゼロに設定する必要があります。リクエストにeビットが設定されているがpビットがない場合、ピアはリクエストを無効と見なし、空のpotp-x eap応答メッセージを返します。
In an EAP-Response, the E bit indicates that the response has been calculated without use of any stored pepper value.
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を受信したときに設定される場合があります。サーバーは提供されたデータの検証を試みていないため、EAPピアが新しいOTP値を取得する必要はありません。このビットには意味がなく、eビットが設定されていない場合はゼロに設定する必要があります。ピアは、sビットが設定されている場所ではなく、eビットではない場所を無効と見なし、空のpotp-x eap responseメッセージを返します。さらに、aビットも設定されている場合は、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.
これらの4つのオクテットは、pビットが設定されている場合にのみ存在します。存在する場合、ネットワークバイトの順序で署名されていない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.
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-Request：EAP-Requestでは、認証データフィールドには、存在する場合、オプションの「チャレンジ」が含まれています。課題は、それが存在するリクエストごとに一意に生成する必要があるオクテット文字列（つまり、「ノンセ」）であり、8オクテット以上である必要があります。断片化（つまり、最小EAP MTUサイズよりも長いEAPメッセージ; [1]を参照）を避けるために、課題は64オクテットを超えてはなりません。課題が存在しない場合、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 TLV upon successful authentication of the peer (instead, it sends an EAP-Success message).
* Pビットが設定されていない場合、ピアは認証データフィールドにトークンによって計算されたOTP値を直接配置するものとします。この場合、EAPサーバーは、ピアの認証を成功させたときに確認TLVを送信してはなりません（代わりに、EAP-SUCSESSメッセージを送信します）。
* 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ビットが設定されている場合、ピアは次のようにこのフィールドに入力します。トークンが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、salt | pepper | auth_id、iteration_count、key_length）
where
ただし
"|" denotes concatenation,
"|"連結を示します、
"otp" is the already computed OTP value,
"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.
「iteration_count」は、ピアの計算時間が許容できるように選択された反復カウントです（サーバーの指定されたポリシーとピアのローカルポリシーに基づいています）。十分に遅くなります。サーバーが提供するペッパーが使用されていない限り、適切なレベルの保護（少なくとも100,000など）を提供するには、「iteration_count」値を選択する必要があります。その場合、1でなければなりません。
"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の倍数ではない場合、ペッパー値は左にパッドで埋められ、「0」ビットが8の最寄りの倍数に埋められ、その後に使用される前に、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 [8]、たとえば「Tel：16175550101」に準拠したURLの形式で指定するものとします。受信した電話番号の処理は、RFC 3966に準拠するものとします（これは、「Tel」URIが256オクテットよりも短くなると仮定しますが、通常はそうです）。
- 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で使用するには、「auth_id」は、標準的なバイナリ形式（6オクテット）の空の文字列または認証器のMACアドレスのいずれかです。
- 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」は（16進数）C0 00 02 05として表されますが、IPv6アドレス "2001：db8 :: 101"は（hex）20 01 0d b8 00として表されます。00 00 00 00 00 00 00 00 00 01 01。
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.
注：正当な認証データを傍受して転送しようとする中間の認証装置が正当な認証装置になりすましていることを認めることを目指している中間攻撃に対する保護において、計算機の識別情報を計算機の識別情報を使用します（ただしセクション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"、SALT = 0x5443453454345435465768789099880、Pepperは使用されていません。BE（ヘックスの最初の2つのパラメーター、読みやすさのためのラインラップ）：
(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:
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およびMSG_1、MSG_2、...で指定されているように、MSG_Nは、このセッションでこれまでに交換されたタイプPOTP-XのすべてのEAPメッセージのシーケンスであり、ピアが送信および受信します（ピアの最初のMacについては、通常、EAPサーバーのタイプPOTP-Xの最初のEAP要求というメッセージが1つだけです。
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.
ピアは、認証データフィールドに「Mac」の最初の16オクテットを配置し、その後に「塩」値を使用し、その後、オクテットの「auth_id」値の長さを表す1つのオクテットが続き、その後に実際の「auth_id」値が続きます。バイナリ形式で、オプションでペッパー識別子が続きます（ピアが以前に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
<16オクテットのMac> |5443453454344543546576878909880 |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).
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'、salt | pepper '| auth_id、iteration_count、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の最も近い倍数にパッドでパッドになります。サーバーがすでにこのピアと秘密のペッパー値を共有している場合、明らかに1つの可能なペッパー値があり、サーバーはピアが提供するPepper_Identifierに基づいて見つけます。サーバーは、ピアがサーバーに不明なペッパー識別子を提供した場合、eビットセットを備えたOTP TLVを使用して、タイプPOTP-Xの新しいEAP-RequestをOTP TLVで送信するものとします。
For each K_MAC', the EAP server computes
各k_mac 'について、EAPサーバーは計算します
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サーバーによって受信されました。MACの最初の16オクテットが、問題のEAP応答の認証データフィールドの最初の16オクテットと一致し、提供された認証機のアイデンティティが許容される場合（たとえば、認証者のIDの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).
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
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.
TLV Type
TLVタイプ
4
4
Length
長さ
6 + cumulative total length of embedded TLVs
埋め込まれたTLVの累積総長さ
Vendor-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.
NAK-Type
Nakタイプ
The type of the unsupported TLV. The TLV MUST have been included in the most recently received EAP message.
TLVs
TLVS
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-Requestでは、新しいPIN TLVを使用して、ピアから新しいユーザーピンをリクエストします。EAPサーバーは、以下で説明するように、新しいピンを提供する場合があります。EAP応答では、新しいPIN TLVには、選択した新しいユーザーピンが搭載されています。このTLVは、Peer（ユーザー）がOTPトークンに関連付けられたPINを変更する必要があることをポリシーが決定する場合、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の交換後（つまり、相互認証が発生し、TLVを保護するためにキーが配置されるまで）までEAP-Requestに存在してはなりません）。新しいピンTLVは、応答をトリガーしたEAP-Requestが新しいPIN TLVをトリガーした場合にのみ、ピアによって送信されなければなりません。EAPサーバーがその要求でそのような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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
TLV Type
TLVタイプ
5
5
Length
長さ
2 + length of the PIN field (as specified in the PIN Length field) + (0, 1, or 2)
ピンフィールドの2つの長さ（ピンの長さフィールドで指定）（0、1、または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です。/ max。PINの長さフィールドはTLVに存在します。TLVにはピンの長さフィールドが存在します。2これらのオプションフィールドの両方が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.
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.
Qビットは、EAP-Requestに設定されている場合、付随するピンが必要であることを示しています。つまり、ピア（ユーザー）が別のピンを自由に選択できないことを示します。Qビットが設定されている場合、付随するピンが必要であり、後続のOTP世代で提供されたピンを使用する必要があります。ピアは、Qビットが設定されているが、ピンが付随する場合は、空のPOTP-X EAP応答メッセージで応答するものとします。Qビットが設定されていない場合、提供されたピンのみが提案され、ピアはローカルポリシーに従って別のピンを自由に選択できます。
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.
PIN Length
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).
このフィールドには、提供されたピンの長さを表す署名されていない整数が含まれています（これは、ピンの最大長が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.
Qビットの設定に従って、EAP-Requestでは、PINフィールドが空になる場合があります。空の場合、ピア（ユーザー）は、ローカルおよび（任意の）提供されたポリシーの対象となるPINを選択する必要があります。ピンフィールドが空でない場合、ヌル文字を終了することなく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.
ピアは、同じピンで応答することでEAPサーバーによって提案されたピンを受け入れますが、サーバーのqビットの設定に応じて、別のピンに置き換えることができます。ピンの長さはアプリケーションに依存しており、ピンの他の要件、たとえば許可された文字も同様です。ピアは、EAPサーバーが何らかの理由で受信したピンを受け入れない場合、上記のように、新しいピンの繰り返しのリクエストを受信する準備をする必要があります。このようなリクエストの前に、拒否の理由について情報をユーザーに提供するタイプ通知のEAP-Request（2）が先行する場合があります。PIN要件に関する知識をEAPサーバーからピアに転送するためのメカニズム（このTLVに指定されたものを超えて、最大および最小ピンの長さなど）は、このドキュメントの範囲外です。ただし、上記のように、EAPサーバーからピアに転送された通知メッセージでいくつかの情報が提供される場合があります。
Min. PIN Length
分ピンの長さ
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-Requestに存在する場合があります。このフィールドは、EAP応答で存在してはなりません。これは、新しいピンに許可されている最小長を表すネットワークバイト順序で署名されていない整数として解釈されるものとします。
Max. PIN Length
マックス。ピンの長さ
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に存在してはなりません。ピンの長さフィールドが存在します。その場合、存在する場合があります。フィールドは、EAP応答で存在してはなりません。これは、新しいピンに許可された最大長を表すネットワークバイト順序で署名されていない整数として解釈されるものとします。このフィールドの値は、存在する場合、minの値に等しい、または大きくなければなりません。ピンの長さフィールド。
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.
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応答で存在する必要があります。ピアがサーバーを認証できなかった場合、タイプPOTP-Xの空の（つまり、TLVが存在しない）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-Requestに応じて送信された有効な確認TLVを含む型POTP-XのEAP応答を受信した後、EAPサクセスメッセージを送信する必要があります。ピアは、EAPサーバーから許容可能な確認TLVを受け取っていない限り、PビットセットでOTP TLVを送信した場合、EAPサクセスメッセージを受け入れてはなりません。
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.
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
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
6
6
Length
長さ
17 or 37 + length of IV in requests, 1 in responses.
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.
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.
Authentication Data
EAP-Request:
eap-request：
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))
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
「k_mac '」は、セクション4.11.3または（セッション再開の場合）セクション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).
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'))
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応答メッセージのピアのハッシュです（およびサーバーがメッセージハッシュを計算したこと）。MACの最初の16オクテットが、問題のEAP-Requestの認証データフィールドの最初の16オクテットと一致する場合、EAPサーバーは認証されます。
EAP-Response:
eap-response：
Not used in this version, and SHALL NOT be present in EAP-Responses.
このバージョンでは使用されておらず、EAP応答には存在しません。
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-OCTETフィールドは、サーバーによって生成されたコショウを識別します。
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-Requestに存在する場合、これは均一に分布し、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サーバーは、すべての確認TLVに新たに生成された暗号化されたコショウ（および対応するコショウ識別子）を含めることをお勧めします。
This field SHALL NOT be present in EAP-Response messages for this version of EAP-POTP.
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サクセスメッセージを受信したときにピアにあります。ピアがすでに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と呼ばれる1つまたは複数の内部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をサポートしない場合があります。この場合、適切なベンダーIDおよびベンダーTLVタイプを含むNAK 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).
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.
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
7
Length
長さ
4 + cumulative total length of inner Vendor TLVs
内側ベンダーTLVの累積総長さ
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オクテットは、ネットワークバイト順序でベンダーのSMIネットワーク管理プライベートエンタープライズコード（[18]を参照）に設定するものとします。
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エンティティ（ピアまたはサーバー）がベンダー固有のTLVを送信した場合の相互運用性を確保するために、ベンダーBから受信者EAPエンティティによって理解されないベンダー固有のTLVを送信するために、ベンダーAエンティティは、受信者からNAK TLVを受領すると、問題のベンダー固有のTLVの使用を控えてください。残りの握手は、ベンダーTLVのNak TLVの受領のためにセッションに失敗してはなりません（つまり、ベンダー固有の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-Requestに応じてのみ送信する必要があります。履歴書TLVは、セッションの再開を可能にするサーバーINFO 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
0 - Non-mandatory TLV
0-非監視TLV
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
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:
Server-INFO TLVを受信すると、nビットが設定されていない場合、ピアはサーバー名フィールドによって識別されたサーバーに関連付けられた保存されたセッションを検索します。保存されたセッションが見つかった場合、ピアはランダムな16オクテットのnonce、「C_NONCE」を生成し、計算します。
K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(base_key, c_nonce | s_nonce, iteration_count, 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オクテットのnonceです。
"s_nonce" is the server nonce from the Server-Info TLV,
「s_nonce」は、サーバーとfo 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.
The peer then calculates:
ピアは計算します。
mac = MAC(K_MAC, msg_hash(resume_req))
where
ただし
"MAC" is the negotiated MAC algorithm, and
"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）は、セッション再開を許可するサーバーINFO TLVを含むEAPサーバーのEAP-XのEAP-RequestであるResume_Reqに適用されるセクション4.9で定義されたメッセージのハッシュアルゴリズムです。
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):
ピアは、MAC値の最初の16オクテットを配置し、次にC_NONCE値を配置し、その後、認証データフィールドに反復カウント値（ネットワークバイト順序で4バイトの署名整数として）が続きます。例として、c_nonce = 0x2b3b1b12babdebebbbb43bd7bdfbeb8dfおよびiteration_count = 1の場合、認証データフィールドに（hex）が入力されます。
< 16 octets of mac > | 2b3b1b12babdebebfb43bd7bdfbeb8df | 00000001
<16オクテットのMac> |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を含むタイプPOTP-XのEAP-Requestを送信する必要があります。ここでは、サーバーINFO TLVはセッションの再開が不可能であることを示します。。
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とトークンキー識別子TLVの少なくとも1つは、セッションの最初のEAP応答タイプPOTP-Xの最初のEAP反応に存在する必要があります。アイデンティティ（1）または他の手段によって決定されます（[1]、セクション2を参照）。ユーザー識別子TLVおよび/またはトークンキー識別子TLVの使用は、タイプID（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
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.
TLV Type
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エンコードされた文字列でなければなりません（ヌル終了してはなりません）。文字列の長さは128オクテット未満でなければなりません。
The Token Key Identifier TLV carries an identifier for the token key used to generate the 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の少なくとも1つは、セッションのタイプPOTP-Xの最初のEAP応答に存在する必要があります。ID（1）を入力するか、他の手段によって決定されます（[1]、セクション2を参照）。ユーザー識別子TLVおよび/またはトークンキー識別子TLVの使用は、タイプID（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
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
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.
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.
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
11
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トークンによって報告されているように、添付のOTP TLVに使用されたOTPが計算されました。フィールドには、XMLシンプルタイプ「DateTime」のUTF-8エンコード値が含まれ、タイムゾーン情報と精度は少なくとも秒、「2004-06-16T15：20：02Z」などになります。
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.
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をサポートしていないが、TLV存在とEAP応答を受信する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
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
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トークンによって報告されたカウンター値は、添付のOTP TLVに使用されたOTPが計算されました。カウンター値は、ネットワークバイトの順序で署名されていない整数として表されるものとします。たとえば、1030のカウンター値は2オクテット（16進数）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を計算するために使用する課題を伝えています。チャレンジTLVは、課題がEAPサーバーに知られていない場合にのみ、ピアによって送信されなければなりません（たとえば、トークンやピアが受信したチャレンジを変更するか、独自の課題を生成しました）。
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をサポートしていないが、TLV存在とEAP応答を受信する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
16
Length
長さ
Length of Challenge field, >= 1
Challenge
チャレンジ
The challenge value that was used to calculate the OTP used for the accompanying OTP TLV.
添付のOTP TLVに使用されるOTPを計算するために使用された課題値。
The Keep-Alive is used to avoid EAP-POTP timeouts.
Keep-Aliveは、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.
キープアライブTLVは、ピアがOTP TLVまたは新しいPIN TLVを含むEAP-Requestを受け取り、ユーザーからの応答を待っているときにタイムアウトを避けるためにピアによって送信される場合があります。
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.
サーバーがKeep-Alive TLVを含むEAP応答を受信した場合、Keep-Alive TLVを含むEAP-Alive TLVをEAPサーバーによって送信する必要があり、サーバーにはKeep-Alive TLVが含まれていない未解決のリクエストがあります。この状況では、サーバーは最新の未解決のリクエストを再送信する必要はありませんが、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
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
13
Length
長さ
0
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
14
Length
長さ
>32
> 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および暗号化されたTLVSフィールドで次の方法で計算されます。
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」は暗号化されたTLVSフィールドの値です。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.
このフィールドには、1つ以上の暗号化されたPOTP-X TLVが含まれている必要があります。暗号化アルゴリズムは交渉されているものとします。K_ENCを暗号化キーとして使用し、IVフィールドを初期化ベクトル（該当する場合）として使用して、保護するすべてのTLVの連結を暗号化します。
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サーバーがデフォルトのアルゴリズムよりも他のアルゴリズムの使用を交渉したいと仮定して、POTP-Xタイプの最初のEAP-Requestに存在する必要があります。また、セッションの再開の結果として送信されるOTP TLVを運ぶタイプPOTP-XのEAP-Requestに存在する場合があります（この場合、ピアはまだこのTLVに応答していません）、またはCryptoアルゴリズムTLVは、EAPサーバーからの最初のメッセージの一部であり、クライアントはEAPサーバーでサポートされている最高のバージョンよりも別のEAP-POTPバージョンをネゴシエートしました。暗号アルゴリズムTLVは、他のEAP要求に存在してはなりません。さらに、Crypto Algorithm TLVは、前のEAP-Requestにも含まれていない限り、型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.
TLV Type
TLVタイプ
15
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
ハッシュアルグ。長さ
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-0x7fffの値は、IANAを介して割り当てられます。セクション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-0x7fffの値は、IANAを介して割り当てられます。セクション7を参照してください。
MAC Alg. Length
Mac Alg。長さ
The length of the MAC Algorithms field in octets.
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以上はベンダー固有の独自のアルゴリズムの場合です。範囲0x0002-0x7fffの値は、IANAを介して割り当てられます。セクション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.
PEER-ID：ユーザー識別子TLVとトークンキー識別子TLVの組み合わせコンテンツ。
Server-ID: The contents of the Server Identifier field of the Server-Info TLV.
サーバーID：サーバーINFO 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).
Method-ID：確立されたセッションの識別子（つまり、セッションを定義したサーバーINFO TLVのセッション識別子フィールドの内容）。
In conformance with RFC 3748 [1], the following security claims are made for the EAP-POTP method:
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)
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を取得するために認証者として行動する中間の攻撃が可能です。
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メソッドの基本的なバリアントは、認証後に行われるセッションハイジャックから保護しません。また、それ自体は、攻撃者が以前の有効なリクエストを再生することでアクセスを獲得するリプレイ攻撃から保護しませんが、次のサブセクションも参照してください。ピンコードが送信されると、それらは保護なしで送信され、リプレイ攻撃の対象となります。
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と新しいピンのプライバシー、暗号化アルゴリズムの交渉、相互認証、およびリプレイ攻撃およびプロトコルバージョンのダウングレードに対する保護を提供します。また、中間者がOTP TLVを与えられた有効なOTPを解決するための無効性のためではなく、OTPを見つけるという計算費用のために、中間の攻撃に対する保護を提供します。有効な限られた期間（これは主にトークンに当てはまります。これには、OTP計算の現在の時間、または送信チャレンジが一定の寿命がある場合を含む）。ただし、「古い」および無効であっても、検索されたOTPは、ユーザーのピンに関する情報を漏らしている可能性があることに注意する必要があります。明らかに、これは基本的なバリアントにも当てはまります。したがって、ユーザーピンが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アドレスをクローンするため、したがって中程度の攻撃をマウントすることは可能ですが、そのようなアクセスポイントはセッションキーを計算できないことに注意してください。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がこのモードで送信するため、バージョンのダウングレード攻撃から保護します。説明されているように、各当事者は送信されたHMACを計算し、EAP-POTPハンドシェイクメッセージを受信します。攻撃者がバージョンTLVを変更した場合、これは計算されたMacの違いに反映されます（TLVの受信者は送信者とは異なる値を受信したため）。攻撃者が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 Protectionバリアントでさえ、ユーザー名やトークンキーの識別子にプライバシーを提供しないことに注意する必要があります。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の知識を示すことによって認証されます。サーバーのNoncesはリプレイ攻撃を防ぎますが、攻撃者がセッション識別子と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).
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.
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のほとんどを聴き、残りを推測し、正当なユーザーに競争して認証を完了することが可能です（この方法の基本的なバリアントで）可能です。適合バックエンド認証サーバーの実装は、このレース条件から保護する必要があります。この攻撃に対する1つの防御は、[14]から以下に概説され、借用されています。実装は、このアプローチを使用するか、代替防御を選択する場合があります。記載されている防御は、初期のアイデンティティEAP-Requestに応じてIDを提供するユーザーに依存していることに注意してください。
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.
考えられる防御の1つは、ユーザーが複数の同時認証セッションを開始できないようにすることです。これは、正当なユーザーが認証を開始すると、最初の認証プロセスが完了するまで攻撃者がブロックされることを意味します。このアプローチでは、サービス拒否攻撃を阻止するためにタイムアウトが必要です。
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).
Cryptoアルゴリズムのハッシュアルゴリズム、暗号化アルゴリズム、およびMACアルゴリズムの新しい値の割り当てTLVは、「仕様が必要」と「IESG承認」を使用してIANAを通じて行う必要があります（これらの用語の意味については[9]を参照）。
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 Security、および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セキュリティ従業員からのコメントと議論によって改善されました。Simon Josefssonは、RSA研究所で働いている間、RSA Securid EAPメソッドの初期バージョンを起草しました。情報交換のTLVタイプのインスピレーションは[17]から来ています。ファンクソフトウェアのOliver Tavakoliに感謝します。これは、セッション再開エリアでの良い提案のために、多くの有用なコメントと提案を提供し、アルバネットワークのRandy Chou、および保護されたTLVのインスピレーションを提供したMeethouseのJim Burnsに感謝します。IESGレビュアー、Pasi Eronen、David Black、およびUri Blumenthalにも感謝します。ドキュメントの改善に役立った洞察に富んだコメントと、徹底的な編集レビューのためにAlfred Hoenesに感謝します。
[1] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[1]
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, February 2004.
[3]
[4] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197, November 2001.
[4] 国立標準技術研究所、「高度な暗号化標準（AES）の仕様」、FIPS 197、2001年11月。
[5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[5]
[6] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[6]
[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] Simpson、W.、ed。、「ポイントツーポイントプロトコル（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]
[12] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[12] Kaufman、C.、ed。、「Internet Key Exchange（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] Stanley、D.、Walker、J。、およびB. Aboba、「ワイヤレスLANSの拡張可能な認証プロトコル（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] Haller、N.、Metz、C.、Nesser、P。、およびM. Straw、「1回限りのパスワードシステム」、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.
[15] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[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.、Simon、D.、Eronen、P。、およびH. Levkowetz、ed。、「拡張可能な認証プロトコル（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.、Simon、D.、Zorn、G.、Salowey、J.、Zhou、H。、およびS. Josefsson、「Protected EAP Protocol（PEAP）バージョン2」、Work in Progress、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] Zorn、G。、「Microsoft Vendor固有のRADIUS属性」、RFC 2548、1999年3月。
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 Security Inc.が生産するハードウェアトークンカード（またはそのソフトウェアエミュレーション）であり、エンドユーザー認証に使用されます。
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は、ピアによってサポートされる必要があります。
This appendix is non-normative. In the examples, "V1", "V2", "V3", etc., stand for arbitrary values of the correct type.
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-request type = ID
EAP-Response -> Type=Identity
eap -response-> type = ID
<- EAP-Request Type=OTP-X
<-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
EAP-Response -> Type=OTP-X
eap-response-> type = 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
User Identifier TLV: User Identifier=V2
ユーザー識別子TLV：ユーザー識別子= V2
<- EAP-Success
<-eap-success
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-request type = ID
EAP-Response -> Type=Identity
eap -response-> type = ID
<- EAP-Request Type=OTP-X
<-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
Server-Info TLV: N=0 Session Identifier=V1 Server Identifier=V2 Nonce=V3 EAP-Response -> Type=OTP-X
server-info tlv：n = 0セッション識別子= v1サーバー識別子= v2 nonce = v3 eap-response-> type = 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-success
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-request type = ID
EAP-Response -> Type=Identity
eap -response-> type = ID
<- EAP-Request Type=OTP-X
<-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
Server-INFO TLV：n = 0セッション識別子= V1サーバー識別子= V2 NonCe = V3
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=0
Iteration Count=V4
EAP-Response -> Type=OTP-X
eap-response-> type = 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
User Identifier TLV:
User Identifier=V6
Token Key Identifier TLV: Token Key Identifier=V7
トークンキー識別子TLV：トークンキー識別子= V7
<- EAP-Request Type=OTP-X
<-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-response-> type = otp-x
Confirm TLV: (no data)
TLVを確認する：（データなし）
<- EAP-Success
<-eap-success
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-request type = ID
EAP-Response -> Type=Identity
eap -response-> type = ID
<- EAP-Request Type=OTP-X
<-eap-request type = otp-x
Version TLV: Highest=0,Lowest=0
Server-Info TLV: N=0 Session Identifier=V1 Server Identifier=V2 Nonce=V3
Server-INFO TLV：n = 0セッション識別子= V1サーバー識別子= V2 NonCe = V3
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=0
Iteration Count=V4
EAP-Response -> Type=OTP-X
eap-response-> type = 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)
User Identifier TLV:
User Identifier=V8
Token Key Identifier TLV: Token Key Identifier=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-response-> type = otp-x
Confirm TLV: (no data)
TLVを確認する：（データなし）
<- EAP-Success B.5. Failed Mutual Authentication
<-eap-success 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.
Peer EAP server
ピアEAPサーバー
<- EAP-Request Type=Identity
<-eap-request type = ID
EAP-Response -> Type=Identity
eap -response-> type = ID
<- EAP-Request Type=OTP-X
<-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
Server-Info TLV:
N=0
Session Identifier=V3
Server Identifier=V4
Nonce=V5
EAP-Response -> Type=OTP-X
eap-response-> type = 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
User Identifier TLV: User Identifier=V7
ユーザー識別子TLV：ユーザー識別子= V7
Token Key Identifier TLV: Token Key Identifier=V8
トークンキー識別子TLV：トークンキー識別子= V8
<- EAP-Request Type=OTP-X
<-eap-request type = otp-x
Confirm TLV: C=0 Authentication Data=V9
TLVの確認：C = 0認証データ= V9
EAP-Response -> Type=OTP-X
eap-response-> type = otp-x
(no data)
（データなし）
<- EAP-Failure
<-eap-failure
This example illustrates successful session resumption.
この例は、セッションの再開の成功を示しています。
Peer EAP server
ピアEAPサーバー
<- EAP-Request Type=Identity
<-eap-request type = ID
EAP-Response -> Type=Identity
eap -response-> type = ID
<- EAP-Request Type=OTP-X
<-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
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5
Server-INFO TLV：n = 0セッション識別子= V3サーバー識別子= V4 NonCe = V5
EAP-Response -> Type=OTP-X
eap-response-> type = 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
<-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-response-> type = otp-x確認tlv ：（データなし）
<- EAP-Success
<-eap-success
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-request type = ID
EAP-Response -> Type=Identity
eap -response-> type = ID
<- 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
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5
Server-INFO TLV：n = 0セッション識別子= V3サーバー識別子= V4 NonCe = 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：ハッシュアルグ。長さ= V6ハッシュアルゴリズム= v7 encr。アルグ。length = v8 encr。アルゴリズム= V9 Mac Alg。length = v10 mac algorithms = v11
EAP-Response -> Type=OTP-X
eap-response-> type = otp-x
Version TLV: Highest=0 Resume TLV: Session Identifier=V12 (indicating earlier session) Authentication Data=V13
バージョンTLV：最高= 0履歴書TLV：セッション識別子= V12（以前のセッションを示す）認証データ= V13
<- EAP-Request Type=OTP-X
<-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
Server-Info TLV: N=1 (no resumption) Session Identifier=V3 Server Identifier=V4 Nonce=V16
Server-INFO TLV：n = 1（再開なし）セッション識別子= V3サーバー識別子= V4 NonCe = V16
EAP-Response -> Type=OTP-X
eap-response-> type = 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)
User Identifier TLV: User Identifier=V20
ユーザー識別子TLV：ユーザー識別子= V20
<- EAP-Request Type=OTP-X
<-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-Response-> Type = OTP-X
Confirm TLV: (no data)
TLVを確認する：（データなし）
<- EAP-Success
<-eap-success
B.8. Mutual Authentication, and New PIN Requested.
B.8. 相互認証、および新しいピンが要求されました。
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.
この例では、ユーザーは新しいピンを選択するように要求されます。新しいピンは英数字であることが許可されており、少なくとも6文字の長さでなければなりません。ユーザーは、サーバーが提案したピンよりも別のピンを選択します。トークンキーは、ユーザー識別子とトークンキー識別子の組み合わせによって識別されます。ユーザーの入力を待っている間、ネットワークタイムアウトを避けるために、ピアはKeep-Alive TLVを含むEAP応答をEAPサーバーに送信します。EAPサーバーは、キープアライブTLVを含むEAP-Requestをピアに戻すことで応答します。確認TLV交換後に交換されたすべてのTLVは、保護されたTLVに包まれていることに注意してください。暗号アルゴリズムTLVの欠如は、デフォルトの暗号化アルゴリズムの使用を示しています。
Peer EAP server
ピアEAPサーバー
<- EAP-Request Type=Identity
<-eap-request type = ID
EAP-Response -> Type=Identity
eap -response-> type = ID
<- EAP-Request Type=OTP-X
<-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
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5
Server-INFO TLV：n = 0セッション識別子= V3サーバー識別子= V4 NonCe = V5
EAP-Response -> Type=OTP-X
eap-response-> type = 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 (with pepper identifier)
User Identifier TLV: User Identifier=V9
ユーザー識別子TLV：ユーザー識別子= V9
Token Key Identifier TLV: Token Key Identifier=V10
トークンキー識別子TLV：トークンキー識別子= V10
<- EAP-Request Type=OTP-X
<-eap-request type = otp-x
Confirm TLV: C=1 Authentication Data=V11
TLVの確認：C = 1認証データ= V11
EAP-Response -> Type=OTP-X
eap-response-> type = otp-x
Confirm TLV: (no data)
<- EAP-Request Type=OTP-X
<-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)
EAP-Response -> Type=OTP-X
eap-response-> type = otp-x
Protected TLV: MAC=V16 IV=V17 Encrypted TLVs=V18 (Contains: Keep-Alive TLV: (no data))
保護されたTLV：MAC = V16 IV = V17暗号化されたTLVS = V18（contains：Keep-Alive TLV ：（データなし））
<- EAP-Request Type=OTP-X Protected TLV: MAC=V19 IV=V20 Encrypted TLVs=V21 (Contains: Keep-Alive TLV: (no data))
<-eap-request type = otp-x保護されたtlv：mac = v19 iv = v20暗号化されたtlvs = v21（contains：Keep-Alive TLV ：（データなし））
EAP-Response -> Type=OTP-X
eap-response-> type = otp-x
Protected TLV:
MAC=V22
IV=V23
Encrypted TLVs=V24
(Contains:
New PIN TLV:
Q=0,A=0
PIN=V25)
<- EAP-Request Type=OTP-X
<-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)
EAP-Response -> Type=OTP-X
eap-response-> type = 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)
<- EAP-Request Type=OTP-X
<-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暗号化されたTLVS = V34（contains：確認：C = 0認証データ= V35）
EAP-Response -> Type=OTP-X
eap-response-> type = otp-x
Protected TLV MAC=V36 IV=V37 Encrypted TLVs=V38 (Contains: Confirm TLV: (no data))
保護されたTLV MAC = V36 IV = V37暗号化されたTLVS = V38（contain：確認：（データなし））
<- EAP-Success
<-eap-success
In this example, the peer is requested to provide a second OTP to the EAP server.
この例では、ピアはEAPサーバーに2番目のOTPを提供するように要求されます。
Peer EAP server
ピアEAPサーバー
<- EAP-Request Type=Identity
<-eap-request type = ID
EAP-Response -> Type=Identity
eap -response-> type = ID
<- EAP-Request Type=OTP-X
<-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
Server-Info TLV:
N=0
Session Identifier=V3
Server Identifier=V4
Nonce=V5
EAP-Response -> Type=OTP-X
eap-response-> type = 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
User Identifier TLV: User Identifier=V9
ユーザー識別子TLV：ユーザー識別子= V9
<- EAP-Request Type=OTP-X
<-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
EAP-Response -> Type=OTP-X
eap-response-> type = 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
<- EAP-Request Type=OTP-X
<-eap-request type = otp-x
Confirm TLV: C=0 Authentication Data=V11
TLVの確認：C = 0認証データ= V11
EAP-Response ->
Type=OTP-X
Confirm TLV:
(no data)
<- EAP-Success
<-eap-success
Appendix C. Use of the MPPE-Send/Receive-Key RADIUS Attributes
付録C. MPPE-SEND/受信キーRADIUS属性の使用
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.
このセクションでは、EAP-POTPで確立されたMSKを使用して、[19]で定義されているMPPE-Send-KeyおよびMppe-Receive-Key Radius属性を埋める方法について説明します。
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-Receive-Keyの属性を埋めるために次のように使用されます。
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).
MPPEセンドキー属性のプレーンテキスト「文字列」フィールドの「キー」サブフィールドの値としてMSKの最初の32オクテットを使用し、MSKの最後の32オクテットを「キー」サブとして使用します。-Mppe-Receive-Key属性の平文「文字列」フィールドのフィールド（注： "send" and "ここでは、認証者を参照します。ピアについては、逆転します）。
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サーバーからピアに提供されるコショウが確立されると、このペッパーを使用した将来のセッションはフルストレングキーを提供します。
In this example we assume the following:
この例では、以下を想定しています。
OTPs are six decimal digits long;
OTPは6桁の長さ6桁です。
4-digit PINs are added to generated OTPs; and
生成されたOTPに4桁のピンが追加されます。と
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ビットのエントロピーを効果的に追加します。ペッパー検索を使用せずにこれを達成する1つの方法は、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
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アルゴリズムに他の弱点はないと想定しています。
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
生成されたOTPに4文字の英数字ピンが追加されます。と
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
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.
Author's Address
著者の連絡先
Magnus Nystroem RSA Security
Magnus Nystroem RSAセキュリティ
EMail: magnus@rsa.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
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.
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。