RFC4793 日本語訳
4793 The EAP Protected One-Time Password Protocol (EAP-POTP). M.Nystroem. February 2007. (Format: TXT=172575 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Nystroem Request for Comments: 4793 RSA Security Category: Informational February 2007
Nystroemがコメントのために要求するワーキンググループM.をネットワークでつないでください: 4793年のRSAセキュリティカテゴリ: 情報の2007年2月
The EAP Protected One-Time Password Protocol (EAP-POTP)
EAPはワンタイムパスワードプロトコルを保護しました。(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).
IETFが信じる著作権(C)(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).
このドキュメントは、One-時間Password(OTP)トークンによって使用に適した一般的な拡張認証プロトコル(EAP)メソッドを説明して、ダイレクト電子インタフェースがあるトークンのために彼らの関連クライアントに特定の利点を示します。 一方的であるか互いの認証、および主要な材料を供給するのにメソッドを使用できます、EAPを利用するプロトコルで、PPPや、IEEE 802.1Xや、インターネット・キー・エクスチェンジプロトコルバージョン2など(IKEv2)のように。
Nystroem Informational [Page 1] RFC 4793 EAP-POTP February 2007
[1ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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
1. 序論…4 1.1. 範囲…4 1.2. バックグラウンド…4 1.3. デザインの後ろの原理…4 1.4. RFC3748のEAPメソッドとの関係…5 2. このドキュメントで中古のコンベンション…5 3. 認証モデル…5 4. EAP-POTPメソッドの記述…6 4.1. 概要…6 4.2. バージョン交渉…9 4.3. 暗号アルゴリズム交渉…10 4.4. セッション再開…11 4.5. 主要な派生とセッション識別子…13 4.6. エラー処理と結果指摘…13 4.7. EAP通知メソッドの使用…14 4.8. ブルートフォースに対する保護は攻撃されます…14 4.9. EAP-POTPのMAC計算…16 4.9.1. 序論…16 4.9.2. MAC計算…16 4.9.3. メッセージハッシュアルゴリズム…16 4.9.4. 原理を設計してください…17 4.9.5. 実装問題…17 4.10. EAP-POTPパケット・フォーマット…17 4.11. EAP-POTP TLVは反対します…20 4.11.1. バージョンTLV…20 4.11.2. サーバインフォメーションTLV…21 4.11.3. OTP TLV…23 4.11.4. NAK TLV…33 4.11.5. 新しい暗証番号TLV…35 4.11.6. TLVを確認してください…38 4.11.7. ベンダー特有のTLV…41 4.11.8. TLVを再開してください…43 4.11.9. ユーザ識別子TLV…46 4.11.10. トークンの主要な識別子TLV…47 4.11.11. タイムスタンプTLV…48 4.11.12. TLVを打ち返してください…49 4.11.13. TLVに挑戦してください…50 4.11.14. TLVを生かしてください…51 4.11.15. TLVを保護します…52 4.11.16. 暗号アルゴリズムTLV…54 5. EAP Key Managementフレームワーク問題…57 6. セキュリティ問題…57 6.1. セキュリティクレーム…57 6.2. 受け身の、そして、活発な攻撃…58 6.3. サービス不能攻撃…59 6.4. コショウの使用…59
Nystroem Informational [Page 2] RFC 4793 EAP-POTP February 2007
[2ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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
6.5. レース攻撃…60 7. IANA問題…60 7.1. 一般…60 7.2. 暗号アルゴリズム識別子八重奏…61 8. 知的所有権問題…61 9. 承認…61 10. 参照…62 10.1. 標準の参照…62 10.2. 有益な参照…RSA SecurIDのためのEAP-POTPの62付録A.プロフィール…64 EAP-POTP交換に関する付録B.の例…65 B.1。 基本のモード、一方的な認証…65 B.2。 基本のモード、セッション再開…66 B.3。 セッション再開のない互いの認証…67 B.4。 コショウの転送との互いの認証…69 B.5。 互いの認証に失敗します…70 B.6。 セッション再開…71 B.7。 セッション再開に失敗します…73 B.8。 互いの認証、および要求された新しい暗証番号…75 B.9。 次のOTPモードの使用…78 MPPE発信している/キーを受信している半径属性の付録C.使用…80 C.1。 序論…80 C.2。 MPPEの主要な属性人口…80 付録のD.の主要な強さ問題…80 D.1。 序論…80 D.2。 例1: 6ケタのワンタイムパスワード…81 D.3。 例2: 8ケタのワンタイムパスワード…81
Nystroem Informational [Page 3] RFC 4793 EAP-POTP February 2007
[3ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
1. Introduction
1. 序論
1.1. Scope
1.1. 範囲
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].
このドキュメントは、One-時間Password(OTP)トークンで使用に適した拡張認証プロトコル(EAP)[1]メソッドを説明して、電子的にユーザのコンピュータに接続されるトークンのために特定の利点を示します、例えば、USBインターフェースを通して。 一方的であるか互いの認証、および主要な材料を供給するのにメソッドを使用できます、EAPを利用するプロトコルで、PPP[10]や、IEEE 802.1X[11]や、IKEv2[12]などのように。
1.2. Background
1.2. バックグラウンド
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]).
A One-時間Password(OTP)トークンはハンドヘルドのハードウェアデバイスであるかもしれません(USB、または何らかのサービスに向かってユーザを認証するのに使用されるかもしれないワンタイムパスワードを生成するパーソナルコンピュータの上のソフトウェア・モジュールの居住者などの電子インタフェースを通してパーソナルコンピュータに接続されたハードウェアデバイス)。 このドキュメントは、EAPの上でユーザを認証するために共同利用できる方法でOTPトークンを使用したがっている組織の需要を満たすことを意図する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メソッドに混乱させないものとします。
1.3. Rationale behind the Design
1.3. デザインの後ろの原理
EAP-POTP has been designed with the intent that its messages and data elements be easily parsed by EAP implementations. This makes it easier to programmatically use the EAP method in the peer and the authenticator, reducing the need for user interactions and allowing for local generation of user prompts, when needed. In contrast, the Generic Token Card (GTC) method from [1], which uses text strings
EAP実装によって分析されて、EAP-POTPはメッセージとデータ要素が容易にそうである意図をもって設計されています。 これで、同輩と固有識別文字にプログラムに基づいてEAPメソッドを使用するのは、より簡単になります、ユーザ相互作用の必要性を減少させて、ユーザプロンプトの地方の世代を考慮して、必要であると。 対照的に、[1]からのGeneric Token Card(GTC)メソッド。([1]はテキスト文字列を使用します)。
Nystroem Informational [Page 4] RFC 4793 EAP-POTP February 2007
[4ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
generated by the EAP server, is intended to be interpreted and acted upon by humans. Furthermore, EAP-POTP allows for mutual authentication and establishment of keying material, which GTC does not. To retain the generic nature of GTC, the EAP-POTP method has been designed to support a wide range of OTP algorithms, with profiling expected for specific such algorithms. This document provides a profile of EAP-POTP for RSA SecurID tokens.
EAPサーバによって生成されて、解釈されることを意図して、人間によって作用されます。 その上、EAP-POTPは合わせることの互いの認証と設立のために、材料を許容します。(GTCはそれを許容しません)。 EAP-POTPメソッドはさまざまなOTPアルゴリズムをサポートするように設計されています、GTCのジェネリック自然を保有するならプロフィールが特定のそのようなアルゴリズムのために予想されている状態で。このドキュメントはEAP-POTPのプロフィールをRSA SecurIDトークンに提供します。
1.4. Relationship with EAP Methods in RFC 3748
1.4. RFC3748のEAPメソッドとの関係
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].
メソッドが[1]で定義したEAP OTP([14]に建てる)は特定のOTPアルゴリズムに関する例であり、本書では定義されたEAPメソッドに関連しません、EAP- POTPのプロフィールがOTPアルゴリズムのために[14]から作成されるかもしれないのを除いて。
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]で定義されたGeneric Token Card EAPメソッドはさまざまなOTPアルゴリズムで働くつもりです。EAP-POTPに、同じくらいは本当です、ここに定義されたEAPメソッド。 EAP GTCを使用すると比べて、EAP-POTPとの使用のための特定のOTPアルゴリズムの輪郭を描く利点はセクション1.3で説明されます。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY", in this document are to be interpreted as described in RFC 2119 [2].
キーワード“MUST"、「必須NOT」“SHALL"、「」、“SHOULD"、「」、「推薦された」、および「5月」はRFC2119[2]で説明されるように本書では解釈されることになっているべきであるものとします。
3. Authentication Model
3. 認証モデル
The EAP-POTP method provides user authentication as defined below. Additionally, it may provide mutual authentication (authenticating the EAP server to the EAP client) and establish keying material.
EAP-POTPメソッドは以下で定義されるようにユーザー認証を提供します。 さらに、それは、互いの認証(EAPクライアントにEAPサーバを認証する)を提供して、合わせることの材料を確立するかもしれません。
There are basically three entities in the authentication method described here:
基本的に、ここで説明された認証方法には3つの実体があります:
o A client, or "peer", using EAP terminology, acting on behalf of a
user possessing an OTP token;
o クライアント、またはOTPトークンを持っているユーザを代表して行動して、EAP用語を使用する「同輩」。
o A server, or "authenticator", using EAP terminology, to which the
user needs to authenticate; and
o サーバ、またはユーザが認証する必要があるものにEAP用語を使用する「固有識別文字」。 そして
o A backend authentication server, providing an authentication
service to the authenticator.
o 固有識別文字への認証サービスを提供するバックエンド認証サーバ。
The term "EAP server" is used here with the same meaning as in [1]. Any protocol used between the authenticator and the backend authentication server is outside the scope of this document, although
「EAPサーバ」という用語は[1]のように意味する同じくらいと共にここで使用されます。 このドキュメントの範囲の外に固有識別文字とバックエンド認証サーバの間で使用されるどんなプロトコルもあります。
Nystroem Informational [Page 5] RFC 4793 EAP-POTP February 2007
[5ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
RADIUS [15] is a typical choice. It is assumed that the EAP client and the peer are located on the same host, and hence only the term "peer" is used in the following for these entities.
RADIUS[15]は典型的な選択です。 EAPクライアントと同輩が同じホストの上に位置していると思われて、したがって、「同輩」という用語だけがこれらの実体に以下で使用されます。
The EAP-POTP method assumes the use of a shared secret key, or "seed", which is known both by the user and the backend authentication server. The secret seed is stored on an OTP token that the user possesses, as well as on the authentication server.
EAP-POTPメソッドはユーザとバックエンド認証サーバによって知られている共有された秘密鍵、または「種子」の使用を仮定します。秘密の種子はユーザが持っているOTPトークンの上と、そして、認証サーバの上に保存されます。
In its most basic variant, the EAP-POTP method provides only one Service (namely, user authentication) where the user provides information to the authentication server so that the server can authenticate the user. A more advanced variant provides mutual authentication, protection against eavesdropping, and establishment of authenticated keying material.
最も基本的な異形では、EAP-POTPメソッドは、サーバがユーザを認証できるように、1Service(すなわち、ユーザー認証)だけをユーザが認証サーバに情報を提供するところに提供します。 より高度な異形は盗聴、および認証された合わせることの材料の設立に対して互いの認証、保護を提供します。
4. Description of the EAP-POTP Method
4. EAP-POTPメソッドの記述
4.1. Overview
4.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(Appendix 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。 RFC3748[1]に従って任意のEAP Identity Request/応答を交換します。 ここに提供されたアイデンティティは後で交換で以下で定義された「ユーザ識別子」か「トークンの主要な識別子」三つ子(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-要求を送ります。 バージョンTLVはサーバによってサポートされたこのメソッドの最も高くて最も低いバージョンを示します。また、EAPサーバはEAP-要求にOTP TLVを通常含んでいます。 OTP TLVは現在のOTPと共に応じるよう同輩に命令して(ことによると保護されたフォームで)、挑戦とある他の情報を含むかもしれません、サーバ方針のように。 EAPサーバは、また、要求にServer-インフォメーションTLVを含むべきであり、セッション再開をサポートするなら、そうしなければなりません。 Server-インフォメーションTLVは、認証サーバを特定して、この(新しい)のセッションのために識別子を含んでいて、EAPサーバとの既に既存のセッションを見つけるのに同輩によって使用されるかもしれません。
Nystroem Informational [Page 6] RFC 4793 EAP-POTP February 2007
[6ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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。 (3) POTP-Xをサポートしないか、またはまた、サーバによってサポートされるこのメソッドのバージョンをサポートしないなら、同輩はタイプNakのEAP-応答で応じます、サーバのバージョンTLVにみられるように。
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はサーバによって提供されたバージョンの範囲の中に示します中で同輩のサポートしているバージョン最も高い)。このバージョン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サーバについてServer-インフォメーションTLVを送った同輩の最も高いサポートしているバージョン同輩であるなら、それがEAPサーバとの保存しているセッションを過すかどうかチェックします。サーバとの既存のセッションが見つけられて、セッション再開が可能であるなら(Server-インフォメーションTLVは明らかにそれを禁じるかもしれません)、同輩は、新しいセッションキー(セッションがプロテクトモードセッションであるなら)について計算して、Resume 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-要求メッセージがOTP TLVを含んでいるなら、同輩は、受信されたEAP-要求メッセージ(例えば、挑戦を運ぶことができた)の情報に基づくワンタイムパスワードについて計算するようOTPトークンに要求します(ことによるとユーザ相互作用で); 現在のトークン状態(例えば、トークン時間)、共有秘密キー(「種子」)、およびユーザによって提供された暗証番号(OTPトークンタイプに頼っていて、EAP-要求における何らかの情報がOTP計算に使用されないかもしれなくて、また、暗証番号も任意であるかもしれないことに注意します)。 容認されたOTP TLVがPビットを設定させるなら(以下を見てください)、同輩は、次に、トークンに提供されたOTPを他の情報に結合して、主要な派生機能に結合したデータを提供します。 主要な派生機能は受信されたメッセージでどれがメッセージ立証コードについて計算するのに使用されるかに関する数個のキーを生成します(MAC)、ある他の情報と共に。 次に、結果として起こるMACは何らかの追加情報と共にEAPサーバへの応答で送られるOTP TLV(Pビットがセットしたことでの)に置かれます、バージョンTLVと共に。 Pビットが容認されたOTP TLVに設定されないなら、同輩は代わりに計算されたOTP値を直接OTP TLVに挿入します。(次に、OTP TLVはバージョンTLVと共にEAPサーバに送られます)。
Nystroem Informational [Page 7] RFC 4793 EAP-POTP February 2007
[7ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
* 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以外に少しのTLVsも提供しなかったなら同輩の最も高いサポートしているバージョンがサーバのものと異なっているなら、同輩は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サーバは同輩のサポートしているバージョンをチェックします。 同輩がサーバによってサポートされる中で最も高いバージョンをサポートしなかったなら、TLVsがそのバージョンのために調整されている状態で、サーバは新しいEAP要求を送るでしょう。 さもなければ、EAPサーバが初期のEAP要求で追加TLVsを送ったと仮定すると、EAPサーバは、c)に提供された応答に基づく同輩を認証するのを試みるでしょう。 この認証の結果によって、EAPサーバは以下の1つをするかもしれません:
* 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-要求にセッション再開が可能でなかったのを示させてください、そして、新しいOTPを求めてください(同輩がResume TLVと共に応じたとき、これはそうでしょう、そして、Resume TLVで示されたセッションは有効ではありませんでした)。
* send a new EAP-Request of type POTP-X to the peer (e.g., to
ask for the next OTP),
* 同輩(例えば次のOTPを求める)にタイプPOTP-Xの新しいEAP-要求を送ってください。
* 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ビットがあるなら同輩にConfirm TLVを含むのが、セットするか、保護されたモードセッション再開へのうまくいっている試みであったというEAP-要求メッセージを送ってください; さもなければ、EAP-成功メッセージを同輩に送ってください)。
* fail the authentication (and send an EAP-Failure message --
possibly preceded by an EAP-Request message of type
Notification (2) -- to the peer).
* 認証に失敗してください(EAP-失敗メッセージ(ことによると、タイプNotification(2)に関する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-成功かEAP-失敗メッセージを受け取るなら、プロトコル走行は終わっています。 同輩がタイプNotificationのEAP-要求を受け取るなら、それはRFC3748[1]によって指定されるように応じます。 同輩がConfirm TLVとのタイプPOTP-XのEAP-要求を受け取るなら、それは、提供されたデータを使用することでEAPサーバを認証するのを試みます。 認証がうまくいくなら、同輩はConfirm TLVとのタイプPOTP-XのEAP-応答で応じます。 それが失敗しているなら、同輩はタイプPOTP-Xの空のEAP応答で応じます。 同輩がある他のTLVsを含むタイプPOTP-XのEAP-要求を受け取るなら、それは上(バージョン交渉は全くこの場合行われないでしょうが)のc)かそれらのTLVsのために説明されるように指定されるように続きます。
Nystroem Informational [Page 8] RFC 4793 EAP-POTP February 2007
[8ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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。 EAPサーバ(Confirm TLVとのタイプPOTP-XのEAP-要求を送った)がConfirm TLVが存在しているタイプPOTP-XのEAP-応答を受けるとき、2つの方法の1つで続くことができます: それを検出したなら、タイプPOTP-Xの追加EAP-要求を送る必要があって、それは「保護された状態」に入るものとします。そこでは、それ以来、すべてのPOTP-X TLVsが暗号化していなければならなくて、送る前に保全は保護されました(ここに、パーティーがセクション4.5で説明されるようにマスターセッションキーについて計算するものとしました)。 Confirm TLVの交換の後にPOTP-Xの会話を続ける1つの理由はユーザが、彼女のOTP PINをアップデートする必要があるということであるかもしれません。 したがって、EAPサーバは、New PIN TLVを送る必要があります。 その時、握手は上(バージョン交渉とすべてのTLVsの保護を除いて)でステップc)に戻っています。 追加EAP-リクエスト・パケットを送る必要は全くなければ、EAPサーバが、うまくいっているプロトコル完成を示すために代わりにEAP-成功メソッドを同輩に送るものとします。 Confirm TLVでそうする意図を示さない場合、EAPサーバは会話を続けないかもしれません。
An EAP server, which has sent an EAP-Request of type POTP-X with
a Confirm TLV and receives an EAP-Response of type POTP-X, which
is empty (i.e., does not contain any TLVs), shall respond with an
EAP-Failure and terminate the handshake.
EAPサーバ(Confirm TLVとのタイプPOTP-XのEAP-要求を送って、空の(すなわち、少しのTLVsも含んでいません)タイプPOTP-XのEAP-応答を受ける)は、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).
記述で含意されるように、f)を通したステップc)が交換の完成の何回も前に行われるかもしれません。 この1つの例が認証サーバが初めは、OTPを要求して、同輩から応答を受け入れて、(仲介者)を実行する時です。 TLV交換(最終的に新しい暗証番号を選択する同輩が新しい暗証番号(再び最終的なConfirm TLV交換で続かれる)に基づくOTPと共に認証するように同輩に頼む要求)を確認してください。
4.2. Version Negotiation
4.2. バージョン交渉
The EAP-POTP method provides a version negotiation mechanism that enables implementations to be backward compatible with previous versions of the protocol. This specification documents the EAP-POTP protocol version 1. Version negotiation proceeds as follows:
EAP-POTPメソッドは実装がプロトコルの旧バージョンと互換性があった状態で後方であることを可能にするバージョン交渉メカニズムを提供します。 この仕様はEAP-POTPプロトコルバージョン1を記録します。 バージョン交渉は以下の通り続きます:
a. In the first EAP-Request of type POTP-X, the EAP server MUST send
a Version TLV in which it sets the "Highest" field to its highest
supported version number, and the "Lowest" field to its lowest
supported version number. The EAP server MAY include other TLV
triplets, as described below, that are compatible with the
"Highest" supported version number to optimize the number of
round-trips in the case of a peer supporting the server's
"Highest" version number.
a。 タイプPOTP-Xの最初のEAP-要求では、EAPサーバはそれが最も大きいサポートしているバージョン番号の、そして、「最も低い」分野に「最も高い」分野を設定するバージョンTLVを最も下位のサポートしているバージョン番号に送らなければなりません。 EAPサーバは以下で説明されるとしての他のサーバの「最も高い」バージョン番号をサポートする同輩の場合における、周遊旅行の数を最適化するためにバージョン番号であるとサポートされる「最も高さ」と互換性があるTLV三つ子を含むかもしれません。
Nystroem Informational [Page 9] RFC 4793 EAP-POTP February 2007
[9ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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-応答で同輩によってサポートされた中で最も高いバージョンに応じなければなりません。 また、EAP-要求に三つ子を含んでいて、同輩はどんなTLVにも応じなければなりません、サーバのバージョン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.
(3) 範囲の中に下がるバージョンをサポートしないなら、EAP同輩はタイプNakの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。 同輩からのバージョンTLVを含んでいて、EAPサーバがEAP-応答を受けますが、TLVにおける「最も高い」サポートしているバージョン分野がバージョンがものが元々EAPサーバで提案したのと同じですが、EAPサーバが初期の要求におけるどんなTLV三つ子も含んでいなかったときEAPサーバによって送られた「最も高い」サポートしているバージョン野原と異なっていると、EAPサーバはここに望まれていて、説明されるように交渉されたバージョンとTLV三つ子とのタイプPOTP-Xの新しいEAP-要求を送ります。
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バージョンを受け入れるだけであるのは、重要です。
4.3. Cryptographic Algorithm Negotiation
4.3. 暗号アルゴリズム交渉
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の使用で交渉されます。 EAP-POTPはデフォルトダイジェストアルゴリズム(SHA-256)[3]、デフォルト暗号化アルゴリズム(AES-CBC)[4]、およびデフォルトMACアルゴリズム(HMAC)[5]を提供します、そして、すべてのEAP-POTP実装でこれらのアルゴリズムをサポートしなければなりません。 もの必要性がCrypto Algorithm TLVを送らないデフォルトよりいかなる他のアルゴリズムも利用したがっていないEAPサーバ。 Pビットがセットした状態で、ある他のアルゴリズムの使用を交渉したがっているEAPサーバはまた、OTP TLVを含むタイプPOTP-Xの初期のEAP-要求でCrypto Algorithm TLVを送らなければなりません。 TLV MUST NOT、セッションにおけるいかなる他のEAP-要求にも存在してください。 (これへの2つの例外が1です) クライアントは、失敗したセッション再開を試みて、したがって、1か)2送られたCrypto Algorithm TLVを評価しませんでした。
Nystroem Informational [Page 10] RFC 4793 EAP-POTP February 2007
[10ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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.)
暗号Algorithm TLVはEAPサーバからの初期のメッセージの一部でした、そして、クライアントはEAPサーバによってサポートされる中で最も高い方より別のEAP-POTPバージョンを交渉しました。これらのケースのどちらかが適用されるとき、サーバはまた、失敗したセッション再開/プロトコルバージョン交渉へのその後のP噛み付いているセットがあるOTP TLVを含む最初のEAP-要求にCrypto Algorithm TLVを含まなければなりません)。 Crypto Algorithm 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.
同輩がEAP-応答でCrypto Algorithm TLVを入れなければならない、そのEAP-要求に、Crypto Algorithm TLVを含んでいて、タイプPOTP-XのEAP-要求を受け取った場合にだけ、Crypto Algorithm TLVを含むのが法的であり、同輩は既存のセッションを再開しようとしないで、同輩とEAPサーバはデフォルト1でない少なくとも1つのアルゴリズムに同意します。 同輩が応じるCrypto Algorithm TLVの特定のクラスのアルゴリズムに値を供給しないなら、デフォルトアルゴリズムはそのクラスに申し込みます。 既存のセッション(次のセクションを見る)を再開するとき、セッションが既に1セットのアルゴリズムに関連しているので同輩が交渉する必要は全くありません。彼らがResume TLVとCrypto Algorithm 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サーバと同輩はそれらが自己の方針で使用できるものよりいかなる他のアルゴリズムも勧めてはいけません。 方針はそうするかもしれません、また、暗号アルゴリズムの組み合わせがものであることを制限してください。許容できる。
4.4. Session Resumption
4.4. セッション再開
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.
このメソッドは中の改良された効率のために許容するセッション識別子とaが繰り返してじっと見るこの件が短期間以内にEAPサーバに認証するのを試みるサーバ識別子を利用します。 この能力は特にワイヤレスのローミングのサポートの役に立ちます。
In order to help the peer find a session associated with the EAP server, an EAP server that supports session resumption MUST send a Server-Info TLV containing a server identifier in its initial EAP- Request of type POTP-X that also contains an OTP TLV. The identifier may then be used by the peer for lookup purposes.
同輩が、セッションがEAPサーバに関連しているのがわかるのを助けるために、セッション再開をサポートするEAPサーバはまた、OTP TLVを含むタイプPOTP-Xの初期のEAP要求におけるサーバ識別子を含むServer-インフォメーション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
前のセッションを続けて、試みてくださいか否かに関係なく、それは同輩に残されて、その結果、交渉を短くします。 以来、経過時間に基づいて同輩の決定を通常、するでしょう。
Nystroem Informational [Page 11] RFC 4793 EAP-POTP February 2007
[11ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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サーバとのセッションを再開するのを試みると決めるなら、Resume TLVはそれで選ばれたセッションと他のコンテンツを特定します、以下で説明されるように、EAPサーバに。
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サーバが、以前に確立したセッションを再開しても構わないと思っているなら、それはResume TLVのコンテンツに基づく同輩を認証しなければなりません。 認証が成功すると、握手は2つの方法の1つで続くでしょう:
* 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.
* セッションがプロテクトモードセッションであるなら、要求がConfirm TLVを含んでいて、サーバは反応しなければなりません。 Confirm TLVがEAPサーバを認証するなら、同輩は空のConfirm TLVと共に応じます。(EAPサーバはEAP-成功メッセージでConfirm TLVに反応します)。 Confirm 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サーバSHOULDはOTP TLVを含む別のEAP-要求を送ります、そして、NビットがあるServer-インフォメーションTLVはどんなセッション再開も可能でないことを示すためにセットしました。 また、EAPサーバはタイプNotification(2)のEAP-要求でことによると先行されたEAP-失敗メッセージを送るかもしれません、その場合、EAP走行が終わるでしょう。
o If the EAP server is not willing or able to resume a previously
established session, it will respond with another EAP-Request
containing an OTP TLV and a Server-Info TLV with the N bit set
(indicating no session resumption).
o EAPサーバが望まないで、以前に確立したセッションを再開できないと、別のEAP-要求がOTP TLVを含んでいて、NビットがあるServer-インフォメーションTLVが用意ができていて、それは応じるでしょう(セッション再開を全く示さないで)。
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.
セッションSHOULD NOT、セッションを作成した交換のセキュリティが可能にするより長い間、維持されてください。 例えば、攻撃者が24時間後にOTPのブルートフォースの探すのに成功しているかもしれないと見積もられているなら、EAP-POTPセッション寿命はこの値明確に以下であるべきです。
Nystroem Informational [Page 12] RFC 4793 EAP-POTP February 2007
[12ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
4.5. Key Derivation and Session Identifiers
4.5. 主要な派生とセッション識別子
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 SHALL、交渉されたMACアルゴリズムに設定されてください。 デフォルトMACアルゴリズム(サポートしなければならない)はHMAC-SHA256です。 HMACは[5]で定義されます、そして、SHA-256は[3]で定義されます。 HMAC-SHA256はハッシュ関数H.としてのSHA-256と[5]からのHMAC構造物です。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 そしてMSK、[1]で定義されるMaster Session Key。
o EMSK, an Extended Master Session Key, also as defined in [1].
o EMSK、[1]の定義されるとしてもExtended Master Session Key。
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 SHALLに関しては、16の八重奏になってください。 他のケースのために. MSKとEMSK SHALLがそれぞれ64の八重奏であることを交渉されたアルゴリズムで決定する順応にはキー長が[1]をもってあるでしょう。 したがって、デフォルトアルゴリズムの場合における"dkLen"パラメタ、[6] SHALLのセクション5.2から、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の使用法を定義します。また、使用がケースに入れる事項に関して、Appendix Cを見てください。
4.6. Error Handling and Result Indications
4.6. エラー処理と結果指摘
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-応答組を交換した([1]を見てください、セクション2.1)後にEAPはメソッドの中でタイプNak(3)のEAP-応答の発信を考慮しません。 同輩がEAP-POTPセッションを続けることができないとき、代わりに、同輩は、すぐに会話を終えるよりむしろタイプPOTP-Xの空のEAP-応答を送ることによって、傑出しているEAP-要求に応じるかもしれません。 これで、EAPサーバは誤りの原因を登録できます。
Nystroem Informational [Page 13] RFC 4793 EAP-POTP February 2007
[13ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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-応答を受けるのを保証するために、同輩SHOULDは、会話を終える前に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がプロテクトモードに立候補することであるときに、Confirm TLV(セクション4.11.6)の交換は成功結果指示として機能します。 同輩がConfirm TLVを受け取るとき、それは、EAPサーバが首尾よくそれを認証したのを知っています。 EAPサーバが同輩からConfirm TLV応答を受けるとき、同様に、それは、同輩がそれを認証したのを知っています。 プロテクトモードでは、Confirm TLVを受けて、有効にしていないと、同輩はEAP-成功パケットを受け入れないでしょう。 EAPサーバから同輩に送られたConfirm TLVは[1]で定義されるように「保護された結果指示」です、それを保護された保全であり、再演できないとき。 しかしながら、同輩からEAPサーバに送られたConfirm TLVは保護された結果指示ではありません。 同輩からEAPサーバに送られた空のEAP-POTP応答は失敗結果指示として機能します。
4.7. Use of the EAP Notification Method
4.7. EAP通知メソッドの使用
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 Notificationメソッドを使用してはいけません。 EAP NotificationメソッドはEAP-POTPセッション以内に以下の状況で使用されるかもしれません:
o The EAP server MAY send an EAP-Request of type Notification (2)
when it has received an EAP-Response containing an OTP TLV and is
unable to authenticate the user. In this case, once the EAP-
Response of type Notification is received, the EAP server MAY
retry the authentication and send a new EAP-Request containing an
OTP TLV, or it MAY fail the session and send an EAP-Failure
message.
o EAPサーバは、(2) OTP TLVを含んでいて、それがEAP-応答を受けたとき、タイプNotificationのEAP-要求を送るかもしれなくて、ユーザを認証できません。 EAPサーバがこの場合、認証を再試行して、タイプNotificationのEAP応答がいったん受け取られているようになるとOTP TLVを含む新しいEAP-要求を送るかもしれないか、それは、セッションに失敗して、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 (2) それが容認できないNew PIN TLVを受けたとき、EAPサーバはタイプNotificationのEAP-要求を送るかもしれません。 EAPサーバがこの場合、New PIN TLVと共に暗証番号最新版を再試行して、タイプNotificationのEAP-応答がいったん受け取られているようになると新しいEAP-要求を送るかもしれないか、それは、セッションに失敗して、EAP-失敗メッセージを送るかもしれません。
4.8. Protection against Brute-Force Attacks
4.8. 全数探索法に対する保護
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
OTPsが比較的短いかもしれないので、攻撃者を十分減速させるのが重要であって、それはOTPのブルートフォース検索に経済的につまらないです、プロテクトモードにおける観測されたEAP-POTP握手を考えて。 これをする1つの方法はPBKDF2機能における、大きい数の繰り返されたハッシュをすることです。 クライアントは別のものがハッシュに攻撃者にとっての、未知の値(「コショウ」)を含むことになっています。
Nystroem Informational [Page 14] RFC 4793 EAP-POTP February 2007
[14ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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:
計算。 明確で通常伝統的な「塩」値を送りますが、この「コショウ」値を明確で送りませんが、代わりに暗号化されたフォームでEAPサーバに移すかもしれません。 実際には、手順は以下の通りです:
a. The EAP server indicates in its OTP TLV whether it supports
pepper searching. Additionally, it may indicate to the peer that
a new pepper shall be chosen.
a。 EAPサーバは、OTP TLVでそれがコショウの探すことをサポートするかどうかを示します。 さらに、それは、新しいコショウが選ばれるのを同輩に示すかもしれません。
b. If the peer supports the use of pepper, the peer checks whether
it already has established a shared pepper with this server:
b。 同輩がコショウの使用をサポートするなら、同輩は、それがこのサーバで既に共有されたコショウを設立したかどうかチェックします:
If it does have a pepper stored for this server, and the server
did not indicate that a new pepper shall be generated, then it
uses the existing pepper value, as specified in Section 4.11.3
below, to calculate an OTP TLV response. In this case, the
iteration count shall be kept to a minimum, as the security of
the scheme is provided through the pepper, and efficiency
otherwise is lost.
このサーバのためにそれでコショウを保存して、サーバが、新しいコショウが生成されるのを示さなかったなら、既存のコショウ値を使用します、OTP TLV応答について計算するためにセクション4.11.3未満で指定されるように。 この場合、繰り返しカウントは最小限に保たれるものとします、コショウを通して体系のセキュリティを提供して、そうでなければ、効率が無くなるとき。
If the peer does not have a pepper stored for this server, but
the server indicated support for pepper searching, or the server
indicated that a new pepper shall be generated, then the peer
generates a random and uniformly distributed pepper of sufficient
length (the maximum length supported by the server is provided in
the server's OTP TLV), and includes the new pepper in the PBKDF2
computation.
同輩がこのサーバのためにコショウを保存させませんが、サーバがコショウの探すことのサポートを示したか、またはサーバが、新しいコショウが生成されるのを示したなら、同輩は、十分な長さ(サーバによってサポートされた最大の長さをサーバのOTP TLVに提供する)の無作為の、そして、一様に分配されたコショウを生成して、PBKDF2計算で新しいコショウを入れます。
If the peer does not have a pepper stored for this server, and
the server did not indicate support for pepper searching, then a
pepper will not be used in the response computation.
同輩がこのサーバのためにコショウを保存させないで、またサーバがコショウの探すことのサポートを示さなかったなら、コショウは応答計算に使用されないでしょう。
Clearly, if the peer itself does not support the use of pepper,
then a pepper will not be used in the response computation.
明確に、同輩自身がコショウの使用をサポートしないと、コショウは応答計算に使用されないでしょう。
c. The EAP server may, in its subsequent Confirm TLV, provide a
pepper to the peer for later use. In this case, the pepper will
be substantially longer than a peer-chosen pepper, and encrypted
with a key derived from the PBKDF2 computation.
c。 その後のConfirm TLVでは、EAPサーバは後の使用のためにコショウを同輩に提供するかもしれません。 この場合、コショウは、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
それが認証している各ユーザのためにコショウ値を保存できないEAPサーバはまだコショウの使用をサポートしているかもしれません。 これのための費用はコショウ検索をする付加的な計算時間になるでしょう。 この費用は費用よりまだ実質的に低いです。
Nystroem Informational [Page 15] RFC 4793 EAP-POTP February 2007
[15ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
an attacker, however, since the server already knows the underlying OTP.
しかしながら、攻撃者、サーバが既に基本的なOTPを知るので。
4.9. MAC Calculations in EAP-POTP
4.9. EAP-POTPのMAC計算
4.9.1. Introduction
4.9.1. 序論
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は、認証目的、プロトコルセッションの保全を確実にするのにMACsを使用します。 このセクションはデザインのためにMACsが計算されていてどう原理であるかを定義します。
4.9.2. MAC Calculation
4.9.2. 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:
プロテクトモードと直接、資格証明書(ワンタイムパスワードか共有されたキーなどの)を認証しながら発信するよりむしろ前のセッションを再開して、いつ資格証明書に関する知識に関する証拠を送るかとき。 この証拠がハッシュのMACである、(ある部分、)、EAP- POTPメッセージは主要なK_MACを使用することで中と今までのところ、セッションを交換しました:
mac = MAC(K_MAC, msg_hash(msg_1, msg_2, ..., msg_n))
macはMACと等しいです。(K_MAC、msg_ハッシュ(msg_1、msg_2、…、msg))
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_ハッシュ(msg_1、msg_2、…、msg)」は以下でメッセージmsg_1、msg_2について定義されたメッセージハッシュです…, msg。
4.9.3. Message Hash Algorithm
4.9.3. メッセージハッシュアルゴリズム
To compute a message hash for the MAC, given a sequence of EAP messages msg_1, msg_2, ..., msg_n, the following operations shall be carried out:
EAPメッセージmsg_1、msg_2の系列を考えて、MACのためにメッセージハッシュを計算するために…, msg、以下の操作が行われるものとします:
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 RequestとEAP Responseメッセージの交互の系列であるに違いありません。
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。 各メッセージ、msg_1、msg_2のコンテンツ(すなわち、EAP「タイプ」分野とEAP「コード」、「識別子」、および「長さ」分野を除くことをきっかけに)…, msgして、一緒に連結されます。
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。 ハッシュにユーザ識別子TLVsを含んではいけません(これは個々のユーザ名に関して知らないバックエンドサービスを考慮するためのものです)、すなわち、どんなそのようなTLVもそれが現れたメッセージから取り外されます。
Nystroem Informational [Page 16] RFC 4793 EAP-POTP February 2007
[16ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
d. The resulting string is hashed using the negotiated hash
algorithm.
d。 結果として起こるストリングは、交渉されたハッシュアルゴリズムを使用することで論じ尽くされます。
4.9.4. Design Rationale
4.9.4. デザイン原理
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メソッド層に知られているというわけではないということです。 「長さ」分野を除く理由は容認された応答を認証サーバに通過する前に仲介者がUsername TLV(例えば、匿名かサービス理由による)を取り外すか、または取り替える可能性を許容することです。表面のこれが悪いセキュリティ実践として現れているかもしれない間、実際にはサービスの否定をもたらすだけであるかもしれません、いつもトランジットにおけるメッセージを変更するのにおいて有能な攻撃者によって達成されるかもしれない何か。 「コード」分野を除くことによって、ハッシュは適切な送られて受信されたメッセージ内容で単に計算されます。 「コード」分野を除くのはハッシュがPOTP-Xメッセージの系列で作られていることであるので、無害であると見なされます、すなわち、交互(知られている)のコード値、1(要求する)と2をすべて持っていて(応答)。
4.9.5. Implementation Considerations
4.9.5. 実装問題
To save on storage space, each EAP entity may partially hash messages as they are sent and received (e.g., HashInit(); HashUpdate(message 1); ...; HashUpdate(message n-1); HashFinal(message n)). This reduces the amount of state needed for this purpose to the internal state required for the negotiated hash algorithm.
集積スペースで節約するために、それぞれのEAP実体はそれらを送って、受け取るように(例えば、HashInit()(HashUpdate(1を通信させる))… HashUpdate(n-1を通信させる); HashFinal(メッセージn))メッセージを部分的に論じ尽くすかもしれません。 これはこのために交渉されたハッシュアルゴリズムに必要である内部の状態に必要である状態の量を減少させます。
4.10. EAP-POTP Packet Format
4.10. EAP-POTPパケット・フォーマット
A summary of the EAP-POTP packet format is shown below. The fields are transmitted from left to right.
EAP-POTPパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | TLV-based EAP-POTP message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 予約されます。| TLVベースのEAP-POTPメッセージ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
1 - Request
1--要求
2 - Response
2--応答
Nystroem Informational [Page 17] RFC 4793 EAP-POTP February 2007
[17ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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].
Identifier分野は、要求に応答に合うことにおいて1つの八重奏と援助です。 この分野とどうそれを使用するかに関する、より詳細な記述に関しては、[1]を見てください。
Length
長さ
The Length field is 2 octets and indicates the length of the EAP
packet including the Code, Identifier, Length, Type, Version,
Flags, and TLV-based EAP-POTP message fields.
Length分野は、2つの八重奏であり、Code、Identifier、Length、Type、バージョン、Flags、およびTLVベースのEAP-POTPメッセージ分野を含むEAPパケットの長さを示します。
Type
タイプ
Identifies use of a particular OTP algorithm with EAP-POTP.
特定のOTPアルゴリズムの使用をEAP-POTPと同一視します。
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.
この八重奏は今後の使用のために控えられます。 それ、SHALL、このバージョンのためにゼロに設定されてください。 受取人SHALLは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つ以上のType長さの価値(これはPEAPv2[17]で定義されたEAP-TLV TLVsと同様です、そして、そのドキュメントからジェネリック分野に関する説明を借ります)。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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の中のTLVsは、EAP同輩とEAPサーバの間のパラメタを運ぶのに使用されます。EAP同輩は必ずEAPサーバによってサポートされたすべてのTLVsを実装するかもしれないというわけではありません、そして、相互運用性を考慮するために、特別なTLVはEAPサーバが、TLVがEAP同輩によってサポートされるかどうか発見するのを許容します。
Nystroem Informational [Page 18] RFC 4793 EAP-POTP February 2007
[18ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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を送らなければならないのを示します。 メッセージの他のすべてのTLVsを無視しなければなりません。 EAP同輩かサーバが非義務的(すなわち、任意の)としてマークされるサポートされないTLVを見つけるなら、それはこの地面だけにNAK TLVを送ってはいけません。
The mandatory bit does not imply that the peer or server is
required to understand the contents of the TLV. The appropriate
response to a supported TLV with content that is not understood is
defined by the specification of the particular TLV.
義務的なビットは、同輩かサーバがTLVのコンテンツを理解するのに必要であることを含意しません。 理解されていない内容があるサポートしているTLVへの適切な応答は特定のTLVの仕様で定義されます。
R
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version. Recipients SHALL ignore this bit for this version
of the EAP-POTP.
今後の使用のために、予約されます。 これはゼロへのセットがこのバージョンのための(0)であったならSHALLに噛み付きました。 受取人SHALLはEAP-POTPのこのバージョンのためにこのビットを無視します。
TLV Type
TLVはタイプします。
The following TLV types are defined for use with EAP-POTP:
以下のTLVタイプはEAP-POTPとの使用のために定義されます:
0 - Reserved for future use
1 - Version
2 - Server-Info
3 - OTP
4 - NAK
5 - New PIN
6 - Confirm
7 - Vendor-Specific
8 - Resume
9 - User Identifier
10 - Token Key Identifier
11 - Time Stamp
12 - Counter
13 - Keep-Alive
14 - Protected
15 - Crypto Algorithm
16 - Challenge
0--今後の使用1のために、予約されます--バージョン2--サーバインフォメーション3--OTP4--NAK5(新しい暗証番号6)は、7--ベンダー特有の8--履歴書9--ユーザIdentifier10--トークンKey Identifier11(Stamp12(カウンタ13)が14を生かす時)が15--暗号Algorithm16--挑戦を保護したと確認します。
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.
これらのTLVsは以下で定義されます。 NAK TLV以外に、特定のTLVタイプはタイプPOTP-Xに関するメッセージで一度より多く見えてはいけません。
Length
長さ
The length of the Value field in octets.
八重奏における、Value分野の長さ。
Nystroem Informational [Page 19] RFC 4793 EAP-POTP February 2007
[19ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
Value
値
The value of the TLV.
TLVの値。
4.11. EAP-POTP TLV Objects
4.11. EAP-POTP TLVオブジェクト
4.11.1. Version TLV
4.11.1. バージョン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 MUST、EAPサーバからのタイプPOTP-Xの初期のEAP-要求と同輩からのタイプPOTP-Xの初期の応答では、存在してください。 それはセッションにおけるどんなその後のEAP-要求やEAP-応答でも存在しているはずがありません。 バージョンTLV MUSTにすべての同輩、およびこの仕様に従うすべての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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| 最も高い| 最も低い| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)であったならSHALLに噛み付きました。 受取人SHALLはEAP-POTPのこのバージョンのためにこのビットを無視します。
TLV Type
TLVはタイプします。
1
1
Length
長さ
3 in EAP-Requests, 2 in EAP-Responses
3 EAP-要求、EAP-応答における2で
Nystroem Informational [Page 20] RFC 4793 EAP-POTP February 2007
[20ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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.
今後の使用のために、予約されます。 このバージョンのためにこの八重奏をゼロに設定しなければなりません。 受取人SHALLはEAP-POTPのこのバージョンのためのこの八重奏を無視します。
Highest
最も高い
This field contains an unsigned integer representing the highest
protocol version supported by the sender. If a value provided by
a peer to an EAP server falls between the server's "Highest" and
"Lowest" supported version (inclusive), then that value will be
the negotiated version for the authentication session.
この分野は表す中で送付者によってサポートされた中でプロトコルバージョン最も高い符号のない整数を含んでいます。 同輩によってEAPサーバに提供された値がサーバの「最も高く」て「最も低い」サポートしているバージョンで(包括的)で下落すると、その値は認証セッションのために交渉されたバージョンになるでしょう。
Lowest
最も低い
This field contains an unsigned integer representing the lowest
version acceptable by the EAP server. The field MUST be present
in an EAP-Request. The field MUST NOT be present in an EAP-
Response. A peer SHALL respond to an EAP-Request of type POTP-X
with an EAP-Response of type Nak (3) if the peer's highest
supported version is lower than the value of this field.
この分野は表す中でEAPサーバで許容できるバージョン最も低い符号のない整数を含んでいます。分野はEAP-要求に存在していなければなりません。 分野はEAP応答で存在しているはずがありません。 (3) 同輩の最も高いサポートしているバージョンがこの分野の値より低いなら、SHALLがEAP-要求に応じる同輩はタイプNakのEAP-応答でPOTP-Xをタイプします。
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を定義します。 したがって、このドキュメントSHALLに従うEAPサーバ実現は「最も高い」分野を1に設定します。 このドキュメントSHALLに従う同輩実現は「最も高い」分野を1に設定します。
4.11.2. Server-Info TLV
4.11.2. サーバインフォメーションTLV
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.
Server-インフォメーション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 SHOULDは同輩が認証されていない限り、また、OTP TLVを運ぶタイプPOTP-XのEAP-要求にいつも存在していて、サーバがセッション再開を支持するなら、そのような要求に存在していなければなりません。 それはタイプPOTP-Xのいかなる他のEAP-要求かどんなEAP-応答パケットにも存在しているはずがありません。 このTLVタイプにこの仕様に従うすべての同輩が支持しなければならなくて、NAK TLVと共に応じてはいけません(これはすべての同輩が、セッション再開を支持する必要があって、彼らがNAK TLVと共にこのTLVにこたえることができるだけではないと言わないためのものです)。
Nystroem Informational [Page 21] RFC 4793 EAP-POTP February 2007
[21ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|N| セッション識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッション識別子(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sess.Id(cont。)| 一回だけ… (16の八重奏) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバ識別子… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)であったならSHALLに噛み付きました。 受取人SHALLはEAP-POTPのこのバージョンのためにこのビットを無視します。
TLV Type
TLVはタイプします。
2
2
Length
長さ
25 + length of Server Identifier field
25 + Server Identifier分野の長さ
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ビットをゼロに設定しなければなりません。 受取人SHALLは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ビットの信号はこのサーバと交際しました。
Nystroem Informational [Page 22] RFC 4793 EAP-POTP February 2007
[22ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
Session Identifier
セッション識別子
An 8-octet identifier for the session about to be negotiated.
Note that, in the case of session resumption, this session
identifier will not be used (the session identifier for the
resumed session will continue to be used).
交渉されようとしているセッションのための8八重奏の識別子。 このセッション識別子がセッション再開の場合に使用されないことに注意してください(再開しているセッションのためのセッション識別子は、使用され続けるでしょう)。
Nonce
一回だけ
A 16-octet nonce chosen by the server. During session resumption,
this nonce is used when calculating new K_ENC, K_MAC, SRK, MSK,
and EMSK keys as specified below.
サーバによって選ばれた16八重奏の一回だけ. 以下で指定されるとして新しいK_ENC、K_MAC、SRK、MSK、およびEMSKキーについて計算するとき、セッション再開の間、この一回だけは使用されています。
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).
. 同輩が格納されたセッションのために捜すのにこの識別子を使用するかもしれない認証サーバのための識別子がサーバと交渉されるためにこのサーバか、仲間にセッションを関連づけた、値、識別子SHOULDでは、他の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の八重奏より長いはずがありません。 識別子SHALL、UTF-8[7]が印刷可能なキャラクタ(いずれもNULLキャラクタを終えることのない)のストリングをコード化したということになってください。
4.11.3. OTP TLV
4.11.3. OTP TLV
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-要求では、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:
サーバがこの仕様に従って、NAK TLVと共に反応してはいけないすべての同輩とすべてのEAPがこのTLVタイプを支持しなければなりません。 OTP TLV MUST NOT、New PIN TLVを含むタイプPOTP-XのEAP-要求に存在してください。 一層、OTP TLV MUST NOT、タイプPOTP-XのEAP-応答では、タイプPOTP-Xの前のEAP要求がOTP TLVを含んで、そうするのが有効でなかったなら、存在してください。 最終的にOTP TLV MUST NOT、また、Resume TLVを含むタイプPOTP-XのEAP応答では、存在してください。 OTP TLVは以下の通り定義されます:
Nystroem Informational [Page 23] RFC 4793 EAP-POTP February 2007
[23ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|A|P|C|N|T|E|S| コショウの長さ|繰り返しカウント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 繰り返しカウント(cont。) | Auth。 データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証データ(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)であったならSHALLに噛み付きました。 受取人SHALLはEAP-POTPのこのバージョンのためにこのビットを無視します。
TLV Type
TLVはタイプします。
3
3
Length
長さ
7 + length of Authentication Data field
7 + Authentication Data分野の長さ
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ビットのSHALL、このバージョンのための(0)のゼロを合わせるように設定されてください。 受取人SHALLは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.
要求である場合にだけ、New PIN TLVを含むタイプPOTP-XのEAP-応答はすぐに続きました、そして、(セクション4.11.5を見てください)EAPサーバで応答における新しい暗証番号を受け入れました。そして、EAP-要求にAビットを設定しなければならない、この場合、Aビットは、EAP-サーバが暗証番号を受け入れて、応答について計算するとき(適切であるときに)同輩SHALLが新設された暗証番号を使用するのを示します。 Sビットが設定されるなら、Aビットを設定してはいけません。 要求でSビットとAビットの両方を設定するなら、同輩SHALLは要求が無効であるとみなして、空のPOTP-X EAP応答メッセージを返します。
Nystroem Informational [Page 24] RFC 4793 EAP-POTP February 2007
[24ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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-応答では、設定されると、Aビットは、OTPが新たに選択されたユーザ暗証番号の使用で計算されたのを示します。 そして、応答でAビットを設定しなければならない、応答の引き金となったEAP-要求がAビットがあるOTP TLVを含んだ場合にだけ、セットしてください。
P
P
In an EAP-Request, the P bit indicates that the OTP in the
response MUST be protected. Use of this bit also indicates that
mutual authentication will take place, as well as generation of
keying material. It is RECOMMENDED to always set the P bit. If a
peer receives an EAP-Request with an OTP TLV that does not have
the P bit set, and the peer's policy dictates protected mode, the
peer MUST respond with an empty POTP-X EAP-Response message. All
peers MUST support protected mode.
EAP-要求では、Pビットは、応答におけるOTPを保護しなければならないのを示します。 また、このビットの使用は、互いの認証が材料を合わせる世代と同様に行われるのを示します。 それはいつもPビットを設定するRECOMMENDEDです。 同輩がPビットを設定させないOTP TLVとのEAP-要求を受け取って、同輩の方針がプロテクトモードを決めるなら、同輩は空の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が保護されたのを示します(以下を見てください)。 そして、応答でPビットを設定しなければならない、(したがって、OTP MUST、保護されてください、)、応答の引き金となったEAP要求がPビットがあるOTP TLVを含んだ場合にだけ、セットしてください。
In an 802.1x EAP over LAN (EAPOL) environment (this includes
wireless LAN environments), the P bit MUST be set, or,
alternatively, the EAP-POTP method MUST be carried out inside an
authenticated tunnel that provides a cryptographic binding with
inner EAP methods such as the one provided by PEAPv2 [17].
LAN(EAPOL)環境(これは無線LAN環境を含んでいる)の上の802.1x EAPでは、Pビットを設定しなければなりませんか、またはあるいはまた、PEAPv2[17]によって提供されたものなどの内側のEAP方法を暗号の結合に提供する認証されたトンネルの中でEAP-POTP方法を行わなければなりません。
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.
問題のOTPアルゴリズムがサーバ挑戦を利用するときだけ、Cビットは意味を運びます。 他のOTPに関して、アルゴリズム、CはいつもSHALLに噛み付きました。ゼロに、用意ができています。
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-要求では、Cビット(「結合する」)は、OTP SHALLが提供された挑戦と内部の状態の両方(例えば、現在の象徴時間)を使用することで計算されるのを示します。 OTP SHALL、Cビットが設定されないで、挑戦が存在しているなら、提供された挑戦(そして、共有秘密キー)だけに基づいた状態で計算されてください。 いつもOTP SHALLを返して、どんな挑戦も存在していないなら、同輩の現状(そして、共有秘密キー)に基づいて計算されてください。 Cビットを設定しますが、挑戦を全く提供しないなら、同輩SHALLは要求が無効であるとみなして、空のPOTP-X EAP-応答メッセージを返します。
Nystroem Informational [Page 25] RFC 4793 EAP-POTP February 2007
[25ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
In an EAP response, this bit indicates that the provided OTP has
been calculated using a provided challenge and the token state.
The C bit MUST be set in a response if and only if the EAP-Request
that triggered the response contained an OTP TLV with the C bit
set and a challenge.
EAP応答では、このビットは、提供されたOTPが提供された挑戦と象徴状態を使用することで計算されたのを示します。 そして、応答でCビットを設定しなければならない、応答の引き金となったEAP-要求がCビットがセットしたことでのOTP TLVと挑戦を含んだ場合にだけ。
N
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-要求では、設定されると、Nビットは、SHALLについて計算するOTPが現在のものではなく、次の象徴「状態」に基づいているのを示します。 例として、時間ベースの象徴に関して、これは次の時間帯を意味します。 イベントベースの象徴に関しては、対価が使用されているなら、これは次の対価を意味するかもしれません。 このビットは、初期のEAP-要求メッセージに通常設定されませんが、その後のもので設定されるかもしれません。 さらに、挑戦が存在しているか、そして、Cビットが設定されないというEAP-要求、およびSHALLで0に設定されるように意味しながら、Nビットはいいえを運びます、この場合。 Nビットを設定する要求でも挑戦を含んでいますが、Cビットを設定しないなら、同輩SHALLは要求が無効であるとみなして、空のPOTP-X EAP-応答メッセージを返します。 EAP-要求にNビットをはめ込むと通常、象徴の内部の状態が進められることに注意してください。
In an EAP-Response, the N bit, when set, indicates that the OTP
was calculated based on the next token "state" (as explained
above), and not the current one. The N bit MUST be set in a
response if and only if the EAP-Request that triggered the
response contained an OTP TLV with the N bit set.
EAP-応答では、設定されると、Nビットは、OTPが現在のものではなく、次の象徴「状態」(上で説明されるように)に基づいて計算されたのを示します。 そして、応答でNビットを設定しなければならない、応答の引き金となったEAP-要求がNビットがあるOTP TLVを含んだ場合にだけ、セットしてください。
T
T
The T bit only carries meaning for OTP methods normally
incorporating a user PIN in the OTP computation.
Tビットは通常、ユーザ暗証番号をOTP計算に取り入れるOTP方法のために意味を運ぶだけです。
In an EAP-Request, the T bit, when set, indicates that the OTP to
calculate MUST NOT include a user PIN.
EAP-要求では、設定されると、Tビットは、計算する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ビットは、OTPがユーザ暗証番号の使用なしで計算されたのを示します。 そして、応答でTビットを設定しなければならない、応答の引き金となったEAP-要求がTビットがあるOTP TLVを含んだ場合にだけ、セットしてください。 クライアント方針が暗証番号なしの計算を禁止するかもしれないことに注意してください。 これらの場合では、クライアントは空のPOTP-X EAP応答メッセージで応じるかもしれません。
Nystroem Informational [Page 26] RFC 4793 EAP-POTP February 2007
[26ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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-要求では、設定されると、Eビットは、同輩がPBKDF2計算にこのサーバに関連している少しの格納されたコショウ値も使用してはいけないのを示します。 むしろ、それは、新しいコショウ(同輩によって支持されるなら)を発生させる、そして/または、OTPを保護するのに繰り返しカウントパラメタを使用しなければなりません(サーバのマックスPepper Lengthが0歳であるなら、同輩は繰り返しカウントに依存しなければなりませんOTPを保護する)。 このビットは、初期のEAP-要求メッセージに通常設定されませんが、その後のもので設定されるかもしれなくて、例えば、サーバがコショウ識別子があるOTP TLVを受け取り次第それを検出するなら、それはその識別子と共に格納にコショウを持っていません。 Pビットが設定されないとき、このビットを意味でないのを運んで、ゼロに設定しなければなりません。 要求がPビット、同輩SHALLではなく、Eビットセットが要求が無効であるとみなして、空のPOTP-X EAP-応答メッセージを返すのをさせるなら。
In an EAP-Response, the E bit indicates that the response has been
calculated without use of any stored pepper value.
EAP-応答では、Eビットは、どんな格納されたコショウ価値の使用なしでも応答について計算してあるのを示します。
S
S
In an EAP-Request, the S bit ("Same"), when set, indicates that
the peer SHOULD calculate its response based on the same OTP value
as was used for the preceding response. This bit MAY be set when
the EAP server has received an OTP TLV from the peer protected
with a pepper, of which the server is no longer in possession.
Since the server has not attempted validation of the provided
data, there is no need for the EAP peer to retrieve a new OTP
value. This bit carries no meaning, and MUST be set to zero, when
the E bit is not set. A peer SHALL regard a request where the S
bit is set, but not the E bit, as invalid, and return an empty
POTP-X EAP-Response message. Further, the S bit MUST NOT be set
when the A bit also is set; see above.
EAP-要求では、設定されると、Sビット(「同じ」)は、同輩SHOULDが前の応答に使用されたのと同じOTP値に基づく応答について計算するのを示します。 EAPサーバがサーバがもう所有されていないコショウで保護された同輩からOTP TLVを受けたとき、このビットは設定されるかもしれません。 サーバが提供されたデータの合法化を試みていないので、EAP同輩が新しいOTP値を検索する必要は全くありません。 Eビットが設定されないとき、このビットを意味でないのを運んで、ゼロに設定しなければなりません。 同輩SHALLはEビットではなく、Sビットが設定される要求を病人と見なして、空のPOTP-X EAP-応答メッセージを返します。 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.
そして、この八重奏SHALL、存在してください、Pビットが設定される場合にだけ。 存在しているとき、0と255の間の値を(包括的)であるのに持っていて、それは符号のない整数を含んでいます。 EAP-要求では、整数はサーバが捜し求めるように準備されるクライアントが発生しているコショウの最大の長さ(ビットの)を表します。 同輩はこの値より長い間、コショウを発生させてはいけません。 値がゼロに設定されるなら、それは、同輩がPBKDF2計算のためにコショウを発生させてはいけないことを意味します。 EAP-応答では、それは中古のコショウの長さを示します。
Nystroem Informational [Page 27] RFC 4793 EAP-POTP February 2007
[27ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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八重奏SHALL、存在してください、Pビットが設定される場合にだけ。 存在しているとき、それらはネットワークバイトオーダーにおける無記名の、そして、4八重奏の整数を含んでいます。 EAP-要求では、整数は同輩が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.
Pepper Lengthを見なして、Iteration Countパラメタに注意してください: 同輩は、EAPサーバによってローカルの方針に提供されたこれらの方針パラメタを比較しなければならなくて、EAPサーバの使用が、パラメタがクライアントの許容できる方針より低いセキュリティをもたらすと示唆したなら、握手を続けてはいけません。 EAPサーバの提供された方針パラメタによって与えられたセキュリティが同輩のローカルの方針で与えられたセキュリティー・レベルを凌ぐなら、クライアントSHOULDはサーバのパラメタを使用します(理由を条件として--活発な攻撃者はそうでなければ、同輩かサーバに対して簡単なサービス不能攻撃を仕掛けることができました、例えば、無分別に高い値を繰り返しカウントに提供することによって)。 サーバで提供されたパラメタが同輩が以前に提供されたサーバ提供されたコショウを使用するか、または持つことができるケースに適用されるだけであることに注意してください。 同輩がサーバの容認できない方針に握手を続けることができないなら、それは空のPOTP-X EAP-応答メッセージを返さなければなりません。
Authentication Data
認証データ
EAP-Request: In an EAP-Request, the Authentication Data field, when
present, contains an optional "challenge". The challenge is an
octet string that SHOULD be uniquely generated for each request in
which it is present (i.e., it is a "nonce"), and SHOULD be 8
octets or longer. To avoid fragmentation (i.e., EAP messages
longer than the minimum EAP MTU size; see [1]), the challenge MUST
NOT be longer than 64 octets. When the challenge is not present,
the OTP will be calculated on the current token state only. The
peer MAY ignore a provided challenge if and only if the OTP token
the peer is interacting with is not capable of including a
challenge in the OTP calculation. In this case, EAP server
policies will determine whether or not to accept a provided OTP
value.
EAP-要求: 存在しているとき、EAP-要求では、Authentication Data分野は任意の「挑戦」を含んでいます。 挑戦は八重奏ストリングです。SHOULDがそれぞれのために唯一発生するのがそれがどれであるかでプレゼント(すなわち、それは「一回だけ」である)、およびSHOULDが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-応答におけるAuthentication Data分野に適用されます:
* When the P bit is not set, the peer SHALL directly place the
OTP value calculated by the token in the Authentication Data
field. In this case, the EAP server MUST NOT send a Confirm
* Pビットが設定されないとき、同輩SHALLは直接Authentication Data分野での象徴によって計算されたOTP値を置きます。 この場合、EAPサーバはConfirmを送ってはいけません。
Nystroem Informational [Page 28] RFC 4793 EAP-POTP February 2007
[28ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
TLV upon successful authentication of the peer (instead, it
sends an EAP-Success message).
同輩(代わりに、それはEAP-成功メッセージを送る)のうまくいっている認証でのTLV。
* When the P bit is set, the peer SHALL populate this field as
follows. After the token has calculated the OTP value, the
peer SHALL compute:
* Pビットが設定されるとき、同輩SHALLは以下のこの分野に居住します。 象徴がOTP値について計算した後に、同輩SHALLは計算します:
K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(otp, salt | pepper
| auth_id, iteration_count, key_length)
K_Mac| K_ENC| MSK| EMSK| SRKはPBKDF2と等しいです。(otp、塩|コショウ|auth_イド、繰り返し_カウント、主要な_の長さ)
where
どこ
"|" denotes concatenation,
"|「連結を指示します」
"otp" is the already computed OTP value,
"otp"は既に計算されたOTP値です。
"salt" is a 16-octet nonce,
「塩」は16八重奏の一回だけです。
"pepper" is an optional nonce (at most, 255 bits long, and,
if necessary, padded to be a multiple of 8 bits long; see
below) included to complicate the task of finding a matching
"otp" value for an attacker,
「コショウ」は攻撃者のために合っている"otp"が値であることがわかるタスクを複雑にするために含まれていた、任意の一回だけ(大部分、長さ255ビット、長い間の8ビットの倍数になるように必要ならそっと歩くところで; 以下を見る)です。
"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_イド」は下層であって以下で指定にされるとして報告されるように固有識別文字(すなわち、ネットワークアクセス・サーバー)のための識別子(大部分の長さにおける255の八重奏)です。
"iteration_count" is an iteration count chosen such that the
computation time on the peer is acceptable (based on the
server's indicated policy and the peer's local policy),
while an attacker, having observed the response and
initiating a search for a matching OTP, will be sufficiently
slowed down. The "iteration_count" value MUST be chosen to
provide a suitable level of protection (e.g., at least
100,000) unless a server-provided pepper is being used, in
which case, it SHOULD be 1.
「繰り返し_カウント」は応答を観測した攻撃者と合っているOTPの検索を開始するのが、十分、そうである間の同輩の計算時間が許容できるような(サーバの示された方針と同輩のローカルの方針に基づいています)ものが選ばれた繰り返しカウントが減速したということです。 サーバで提供されたコショウがどの場合の中古である存在でないかなら適当なレベルの保護を提供するために「繰り返し_カウント」値を選ばなければならなくて(例えば、少なくとも10万)、それはSHOULDです。1になってください。
"key_length" is the combined length of the desired key
material, in octets. When the default algorithms are used,
key_length is 176.
「主要な_の長さ」は八重奏における必要な主要な材料の結合した長さです。 デフォルトアルゴリズムが使用されているとき、主要な_の長さは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
「コショウ」値をPBKDF2計算で含めるだけであり、EAPサーバに決して送りません(同輩はビットの彼らの長さを送りますが)。 同輩を減速させていない間、攻撃者の合っているOTPの検索を減速させるために上に言及されるようにある、コショウの目的が、評価する(どれ、繰り返し、論じ尽くすか、) コショウが同輩によって発生して、ビットの選ばれたコショウの長さがaでないなら
Nystroem Informational [Page 29] RFC 4793 EAP-POTP February 2007
[29ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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.
次に、8の倍数、コショウはSHALLを評価します。左にそっと歩いてください、PBKDF2計算に使用される前の8の最も近い倍数への'0'ビットで。 これは、計算への入力が全体の八重奏だけから成るのを保証するためのものです。 例として、コショウ値は選ばれたコショウの長さが4であるなら、4で左に'0'ビット水増しされて、PBKDF2計算に使用される前に八重奏を形成するでしょう。
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の馬鹿力検索につまらない計算上実行不可能な/であるように方法で選ばれているRECOMMENDEDです。
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計算を行わなければなりません(一層のAppendix 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).
以前のセッションのときに、サーバはコショウ値をConfirm TLVの同輩に移したかもしれません(以下を見てください)。 これがそうであり、同輩がこのサーバのためにそのコショウ値をまだ格納させているとき、同輩は、新しいコショウを発生させてはいけませんが、代わりにPBKDF2計算にこのわたっているコショウ値を使用しなければなりません。 これへの唯一の例外がローカルの方針(例えば、タイマ)が、同輩が新しいコショウに切り替わらなければならないと決める(サーバはコショウの探すことのサポートを示しました)時です。
The following applies to the auth_id component:
以下はauth_イドコンポーネントに適用されます:
- 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).
- ダイヤルアップのために「呼ばれる空のストリングか電話番号のどちらかが同輩であったなら」 _イドSHALLをauthします。 電話番号SHALL、RFC3966[8]とconformant、例えば、「tel:+16175550101」という1つのURLの形で指定されてください。 RFC3966とconformant(これは、"tel"URIが256の八重奏より短くなると仮定する)になってください容認された電話番号SHALLを処理して。通常、八重奏はケースでしょう。
- 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).
- 空のストリングかMACのどちらかが正準なバイナリフォーマット(6つの八重奏)の固有識別文字のアドレスであったならIEEE 802.1X、「auth_イド」SHALLと共に使用します。
Nystroem Informational [Page 30] RFC 4793 EAP-POTP February 2007
[30ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
- 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のために「固有識別文字の空のストリングかIPv4かIPv6アドレスのどちらかが同輩とバイナリフォーマット(それぞれ4か16の八重奏)で目にふれたなら、」 _イドSHALLをauthします。 例、IPv4アドレス、「192.0 .2 0.5インチが(十六進法における)C0 00 02 05として表されるだろう、IPv6アドレス、「2001 : DB8:、:、」「101」は(十六進法における)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.
以下に注意してください。 計算の中の固有識別文字の身元が分かる情報の使用が中の男性に対する保護で支援される、-、-、中央、凶暴な固有識別文字が正統の固有識別文字で同輩をまねるためにAuthentication Dataを妨害して、進めようとする(また、セクション6のだまされた固有識別文字アドレスの周りで議論を見てください)ところでの攻撃。 これらの理由で、それが固有識別文字に関する身元が分かる情報を学ばないことができないなら、同輩SHOULD NOTはauth_イドコンポーネントを空のストリングに設定しました。 これらの場合では、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):
「12345678」(塩の=0x54434534543445435465768789099880)が浴びせるotp=が使用されていないとき、例として、auth_イドは「192.0に、.2の0.5インチ、繰り返し_カウント=2000(小数)、およびキー_の長さが176(小数)と等しく、PBKDF2計算への入力は(十六進法における最初の2つのパラメタ、読み易さのための線包装)でしょう」と等しいです。
(3132333435363738, 54434534543445435465768789099880 |
c0000205, 2000, 176)
(3132333435363738、54434534543445435465768789099880| c0000205、2000、176)
As described, when the default algorithms are used, K_MAC is
the first 16 octets of the output from PBKDF2, K_ENC the
next 16 octets, MSK the following 64 octets, EMSK the next
64 octets, and SRK the final 16 octets. Using K_MAC, the
peer calculates:
デフォルトアルゴリズムが使用されているとき、K_MACが説明されるようにPBKDF2からの出力の最初の16の八重奏であり、K_ENCが次の16の八重奏であり、MSKが以下の64の八重奏であり、EMSKが次の64の八重奏であり、SRKはベスト16八重奏です。 K_MACを使用して、同輩は計算します:
mac = MAC(K_MAC, msg_hash(msg_1, msg_2, ..., msg_n))
macはMACと等しいです。(K_MAC、msg_ハッシュ(msg_1、msg_2、…、msg))
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はこのセッションのときに今までのところ交換されているタイプPOTP-Xに関するすべてのEAPメッセージの系列です、同輩によって送られて、受け取られるように(同輩の初期のMACを求めて、それはちょうど1つのメッセージ: EAPサーバのタイプPOTP-Xの通常初期の要求にEAP-なるでしょう)。
Nystroem Informational [Page 31] RFC 4793 EAP-POTP February 2007
[31ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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.
次に、同輩は「塩」値があとに続いたAuthentication Data分野での"mac"の最初の16の八重奏を置きます(同輩が以前にEAPサーバによって提供されたコショウ値を利用したときだけ)、二部形式の実際の「auth_イド」値があとに続いた八重奏における、「auth_イド」価値の長さを表す1つの八重奏があとに続いていて、任意に続いてコショウ識別子を置きます。 存在しているとき、いつもコショウ識別子は4つの八重奏です。 すべての変数SHALL、現在のコネがフォームであったなら、それらはPBKDF2アルゴリズムに入力されました。 これは長さにおいて33の+(八重奏における、auth_イドの長さ)+(コショウ識別子、現在のいつの間の4)八重奏であるAuthentication Data分野をもたらすでしょう。
Continuing the previous example, the Authentication Data
field will be populated with (in hex, line wrap for
readability):
前の例、分野が居住されるAuthentication Data(読み易さのための十六進法における系列包装)を続けています:
< 16 octets of mac > | 54434534543445435465768789099880 |
04 | c0000205
mac>の<16八重奏| 54434534543445435465768789099880 | 04 | c0000205
Note: Since in this case (i.e., when the P bit is set)
successful authentication of the peer by the EAP server will
be followed by the transmission of an EAP-Request of type
POTP-X containing a Confirm TLV for mutual authentication,
the peer MUST save either all the input parameters to the
PBKDF2 computation or the keys K_MAC, K_ENC, SRK, MSK, and
EMSK (recommended, since they will be used later). This is
because the peer cannot be guaranteed to be able to generate
the same OTP value again. For the same reason (the Confirm-
TLV from the EAP server), the peer MUST also store either
the hash of the contents of the sent EAP-Response or the
EAP-Response itself (but see the note above about not
including any User Identifier TLVs in the hash computation).
以下に注意してください。 互いの認証のためのConfirm TLVを含むタイプPOTP-XのEAP-要求の伝達がこの場合(すなわち、Pビットはいつ設定されますか)EAPサーバによる同輩のうまくいっている認証のあとに続くので、同輩はキーのK_MACと、K_ENCと、SRKと、MSKと、PBKDF2計算へのすべての入力パラメタかEMSK(それらが後で使用されるので、推薦される)のどちらかを保存しなければなりません。 これは再び同じOTPが値であると生成することができるように同輩を保証できないからです。 同じ理由から(EAPサーバからのConfirm- TLV)、また、同輩は送られたEAP-応答のコンテンツのハッシュかEAP-応答自体のどちらかを保存しなければなりません(ハッシュ計算に少しのUser Identifier TLVsも含まないことに関する上記を注意見てください)。
Given a set of possible OTP values, the authentication
server verifies an authentication request from the peer by
computing
1セットの可能なOTP値を考えて、認証サーバはコンピューティングで同輩からの認証要求について確かめます。
K_MAC' | K_ENC' | MSK' | EMSK' | SRK' = PBKDF2 (otp',
salt | pepper' | auth_id, iteration_count, key_length)
'K_Mac'| 'K_ENC'| 'MSK'| 'EMSK'| 'SRK'はPBKDF2と等しいです。'、('塩| otpに、'| auth_イド、_が数える繰り返し、主要な_の長さを浴びせてください、)
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
'それぞれに関して、可能なOTPはotpと'それぞれの可能なコショウ値のコショウ'を評価します、そして、塩、固有識別文字のアイデンティティ、および繰り返しのための提供された値は重要です、適切なキー長(デフォルト: 176)と同様に。 以下に注意してください。 それぞれの可能なコショウ値のために計算するのは本書ではほかの場所に言及されたコショウ検索を実装します。 また、EAPサーバが1つ以上のOTP値を受け入れるかもしれないことに注意してください。
Nystroem Informational [Page 32] RFC 4793 EAP-POTP February 2007
[32ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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.
一時に、例えば、トークンにおける時計ドリフトのため。 与えられたコショウの長さが8の倍数でないなら、それぞれのテストされたコショウ値は左に8の最も近い倍数に水増しされるでしょう、同輩によって行われたのと同じ方法で。 サーバが既に秘密のコショウ値をこの同輩と共有すると、1つの可能なコショウ値しか明らかにないでしょう、そして、サーバは同輩によって提供されたコショウ_識別子に基づいてそれを見つけるでしょう。 サーバSHALLは同輩がサーバにおける、未知のコショウ識別子を提供したなら設定されたEビットでOTP TLVとのタイプPOTP-Xの新しいEAP-要求を送ります。
For each K_MAC', the EAP server computes
'各K_MAC'に関して、EAPサーバは計算されます。
mac' = MAC(K_MAC', msg_hash(msg_1', msg_2', ..., msg_n'))
'mac'はMACと等しいです。'、(K_MAC、'msg_は(msg_1、'msg_2'、…、msg')を論じ尽くします。
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.
msg_ハッシュはMACが交渉されたMACアルゴリズムであることのセクション4.9で定義されたメッセージハッシュアルゴリズムです、そして、msg_1、'msg_2'、…msg'は同輩がメッセージハッシュについて計算した同じメッセージ、しかし、今回です、EAPサーバで送って、受け取るように。''macの最初の16の八重奏であるなら、Authentication Dataの最初の16の八重奏がさばく問題のEAP-応答のマッチ、および提供された固有識別文字のアイデンティティはそうです。許容できます(例えば、固有識別文字のアイデンティティに関する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).
認証がうまくいくなら、認証サーバは、Confirm TLVの使用で同輩にそれ自体を認証するのを試みます(以下を見てください)。 認証が失敗するなら、EAPサーバが同輩にOTP TLVを含むタイプPOTP-Xの別のEAP-要求を送るかもしれませんか、またはそれはEAP-失敗メッセージ(どちらの場合も、ことによるとタイプNotificationのEAP-要求で先行されている)を送るかもしれません。
4.11.4. NAK TLV
4.11.4. NAK TLV
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 MUSTにこの仕様に従うすべての同輩とすべてのEAPサーバでサポートして、NAK TLVと共に応じてはいけません。 EAPサーバによるNAK TLVの領収書で、失敗する認証、およびEAPサーバはEAP-失敗メッセージを同輩に送るかもしれません。
Nystroem Informational [Page 33] RFC 4793 EAP-POTP February 2007
[33ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダーイド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAK-タイプ| 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)であったならSHALLに噛み付きました。 受取人SHALLはEAP-POTPのこのバージョンのためにこのビットを無視します。
TLV Type
TLVはタイプします。
4
4
Length
長さ
6 + cumulative total length of embedded TLVs
6 + 埋め込まれたTLVsの累積している全長
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.
Vendor-イド分野は、4つの八重奏であり、サポートされなかったTLVのVendor-イドを含んでいます。 高位八重奏は0です、そして、下位の3つの八重奏がネットワークバイトオーダーにおけるVendorのManagement情報(SMI)ネットワークManagement兵士のエンタープライズCodeのStructureです。 Vendor-イド分野はVendor特有のTLVsでないTLVsのためのゼロでなければなりません。 Vendor特有のTLVsにおいて、Vendor-IDをSMIコードに設定しなければなりません。
NAK-Type
NAK-タイプ
The type of the unsupported TLV. The TLV MUST have been included in the most recently received EAP message.
サポートされないTLVのタイプ。 TLV MUSTは最も最近受信されたEAPメッセージに含まれています。
Nystroem Informational [Page 34] RFC 4793 EAP-POTP February 2007
[34ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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.
この分野はTLVsのリストを含んでいます。それはそれぞれ義務的なビットを設定してはいけません。 将来、怒っているTLVがなぜサポートされないと決心していたかを伝えるのにこれらの任意のTLVsを使用できます。
4.11.5. New PIN TLV
4.11.5. 新しい暗証番号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-要求では、New PIN TLVは、同輩から新しいユーザ暗証番号を要求するのに使用されます。 EAPサーバは以下で説明されるように新しい暗証番号を提供するかもしれません。 EAP-応答では、New PIN TLVは選ばれた新しいユーザ暗証番号を運びます。 方針が、同輩(ユーザ)が、OTP Tokenに関連している暗証番号を変える必要であると決めるとき、このTLVはEAPサーバによって使用されるかもしれません。
This TLV type SHOULD be supported by peers and EAP servers conforming to this specification. The New PIN TLV MUST NOT be sent by an EAP server unless the peer has been authenticated. If the peer was authenticated in protected mode, then the New PIN TLV MUST NOT be present in an EAP-Request until after the exchange of the Confirm TLV (i.e., until after mutual authentication has occurred and keys are in place to protect the TLV). The New PIN TLV MUST be sent by a peer if and only if the EAP-Request that triggered the response contained a New PIN TLV, it was valid for the EAP server to send such a TLV in that request, and the TLV is supported by the peer.
このTLVはSHOULDをタイプします。同輩とEAPサーバで、この仕様に従いながら、サポートされてください。 New PIN TLV MUST NOT、EAPサーバで、同輩を認証していない場合、送ってください。 同輩であるなら、現在のコネがConfirm TLV(すなわち、互いの認証が起こって、TLVを保護するためにキーが適所にあった後の)の交換の後のEAP-要求であったなら、認証されたコネはプロテクトモード、そして、New PIN TLV MUST NOTでしたか? そして、New PIN TLV MUST、同輩によって送られてください、応答の引き金となったEAP-要求がNew 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|Q|A| 長さをピンで止めてください。| ピンで止めます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |分 長さをピンで止めてください。|マックス。 長さをピンで止めてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)であったならSHALLに噛み付きました。 受取人SHALLはEAP-POTPのこのバージョンのためにこのビットを無視します。
TLV Type
TLVはタイプします。
5
5
Nystroem Informational [Page 35] RFC 4793 EAP-POTP February 2007
[35ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
Length
長さ
2 + length of the PIN field (as specified in the PIN Length field)
+ (0, 1, or 2)
暗証番号の2+長さは(暗証番号Length分野で指定されるように)+をさばきます。(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 任意のMinのいずれであるならも、そうしません。 /最大。 暗証番号Length分野はTLVに存在しています。--1 Minだけであるなら。 暗証番号Length分野は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.
今後の使用のために、予約されます。 すべての6ビットのSHALL、このバージョンのためにゼロに設定されてください。 受取人SHALLはEAP-POTPのこのバージョンのためにこれらのビットを無視します。
Q
Q
The Q bit, when set in an EAP-Request, indicates that an
accompanying PIN is required, i.e., the peer (user) is not free to
choose another PIN. When the Q bit is set, there MUST be an
accompanying PIN and the provided PIN MUST be used in subsequent
OTP generations. A peer SHALL respond with an empty POTP-X EAP-
Response message if the Q bit is set but there is not any
accompanying PIN. When the Q bit is not set, any provided PIN is
suggested only, and the peer is free to choose another PIN,
subject to local policy.
EAP-要求に設定されると、Qビットは、付随の暗証番号が必要であることを示します、すなわち、同輩(ユーザ)は自由に別の暗証番号を選ぶことができません。 Qビットが設定されるとき、付随の暗証番号があるに違いありません、そして、その後のOTP世代に提供された暗証番号を使用しなければなりません。 Qに噛み付いたなら、SHALLが空のPOTP-X EAP応答メッセージで反応させる同輩は用意ができていますが、どんな付随の暗証番号もありません。 Qビットが設定されないとき、どんな提供された暗証番号も示される、唯一、同輩は自由に、別の暗証番号(ローカルの方針への対象)を選ぶことができます。
The Q bit carries no meaning, and SHALL be set to zero, in an EAP-
Response.
Qビットはセットがゼロ、コネへのEAP応答であったなら意味、およびSHALLを全く運びません。
A
A
This bit allows methods that distinguish between two different PIN
types (e.g., decimal vs. alphanumeric) to designate whether the
augmented set is to be used (when set) or not (when not set). The
A bit carries no meaning, and SHALL be set to zero, in an EAP-
Response.
このビットは増大しているセットが使用されていることになっている(設定されると)(設定されないと)か否かに関係なく、任命する2つの異なった暗証番号タイプ(例えば、小数対英数字)を見分けるメソッドを許容します。 Aビットはセットがゼロ、コネへのEAP応答であったなら意味、およびSHALLを全く運びません。
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の八重奏になるのを含意します)。
Nystroem Informational [Page 36] RFC 4793 EAP-POTP February 2007
[36ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
PIN
暗証番号
In an EAP-Request, subject to the setting of the Q bit, the PIN
field MAY be empty. If empty, the peer (user) will need to choose
a PIN subject to local and (any) provided policy. When the PIN
field is not empty, it MUST consist of UTF-8 encoded printable
characters without a terminating NULL character.
EAP-要求では、Qビットの設定を条件として、暗証番号分野は人影がないかもしれません。 空であるなら、同輩(ユーザ)は、地方を条件とした暗証番号と(いずれ)の提供された方針を選ぶ必要があるでしょう。 暗証番号分野が人影がなくないときに、コード化されて、それはUTF-8から成らなければなりません。終わっているNULLキャラクタのない印刷可能なキャラクタ。
In an EAP-Response, the PIN value SHALL consist of a UTF-8 encoded
string of printable characters without a terminating NULL
character.
EAP-応答、SHALLが成る暗証番号値では、UTF-8は終わっているNULLキャラクタなしで印刷可能なキャラクタのストリングをコード化しました。
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サーバによって同じ暗証番号で返答することによって示された暗証番号を受け入れますが、それを別の1つに取り替えるかもしれません、サーバのQビットの設定によって。 暗証番号の長さは暗証番号のためのいかなる他の要件、例えば、許容キャラクタのようにもアプリケーション依存しています。 同輩は新しい暗証番号に関する繰り返された要求を受け取る用意ができていなければなりません、上で説明されるように、EAPサーバであるなら、何らかの理由が受信された暗証番号を受け入れないので。 タイプNotification(2)のEAP-要求でそのような要求は、拒絶のために理由に関して情報をユーザに提供しながら、先行されるかもしれません。 このドキュメントの範囲の外に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-要求に存在しているかもしれません。 この分野はEAP-応答で存在しているはずがありません。 それ、SHALL、最小の長さを表すネットワークバイトオーダーにおける符号のない整数が新しい暗証番号を考慮したので、解釈されてください。
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-要求に存在しているはずがない、Min。 暗証番号Length分野が存在している、その場合、それは存在しているかもしれません。 分野はEAP-応答で存在しているはずがありません。 それ、SHALL、最大の長さを表すネットワークバイトオーダーにおける符号のない整数が新しい暗証番号を考慮したので、解釈されてください。 存在しているとき、この分野の値が等しいか、または、より大きいに違いない、Minの値。 暗証番号Length分野。
Nystroem Informational [Page 37] RFC 4793 EAP-POTP February 2007
[37ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
4.11.6. Confirm TLV
4.11.6. TLVを確認してください。
Presence of this TLV in a request indicates that the EAP server has successfully authenticated the peer and now attempts to authenticate itself to the peer. Presence of this TLV in a response indicates that the peer successfully authenticated the EAP server, and that calculated keys (K_MAC, K_ENC, MSK, EMSK, and SRK) now become available for use.
要求における、このTLVの存在は、EAPサーバが、首尾よく同輩を認証して、現在同輩にそれ自体を認証するのを試みるのを示します。 応答における、このTLVの存在は同輩が首尾よくEAPサーバを認証して、現在計算されたキー(K_Mac、K_ENC、MSK、EMSK、およびSRK)が使用に利用可能になるのを示します。
The Confirm TLV MUST NOT appear together with any other TLV in an EAP-Request message of type POTP-X and MUST NOT be sent unless the peer has been authenticated through an OTP TLV with the P bit set or through a Resume TLV for which the underlying session was established in protected mode. The Confirm TLV MUST be present in an EAP- Response if and only if the request that triggered the response contained a Confirm TLV, it was legal for it to do so, and the Confirm TLV authenticated the EAP server to the peer. If the peer was not able to authenticate the server, then it MUST send an empty (i.e., no TLVs present) EAP-Response of type POTP-X.
Confirm TLVはいかなる他のTLVと共にもタイプPOTP-Xに関するEAP-要求メッセージに現れてはいけなくて、PビットがセットしたことでのOTP TLVを通して、または、基本的なセッションがプロテクトモードに確立されたResume TLVを通して同輩を認証していない場合、送ってはいけません。 そして、Confirm TLVがEAP応答で存在していなければならない、応答の引き金となった要求がConfirm TLVを含んだ場合にだけ、そうするのが法的であり、Confirm TLVはEAPサーバを同輩に認証しました。 同輩がサーバを認証できなかったなら、それはタイプPOTP-Xの空(すなわち、TLVsプレゼントがない)の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.
Cビットが設定されなかったConfirm TLVを含んでいて、EAP-要求に対応して送られた有効なConfirm TLVを含むタイプPOTP-XのEAP-応答を受けた後に、EAPサーバはEAP-成功メッセージを送らなければなりません。 それがEAPサーバから許容できるConfirm 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.
サーバがこの仕様に従って、NAK TLVと共に反応してはいけないすべての同輩とEAPはこの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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|C| 認証データ… (16の八重奏) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コショウ識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コショウを暗号化します… (16の八重奏) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1--義務的なTLV
Nystroem Informational [Page 38] RFC 4793 EAP-POTP February 2007
[38ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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)であったならSHALLに噛み付きました。 受取人SHALLはEAP-POTPのこのバージョンのためにこのビットを無視します。
TLV Type
TLVはタイプします。
6
6
Length
長さ
17 or 37 + length of IV in requests, 1 in responses.
要求、応答における1におけるIVの17か37+長さ。
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ビットのSHALL、このバージョンのための(0)のゼロを合わせるように設定されてください。 受取人SHALLはEAP-POTPのこのバージョンのためにこれらのビットを無視します。
C
C
The C bit, when set in an EAP-Request, indicates that the EAP
server intends to send more EAP-Requests of type POTP-X in this
session, after receipt of a Confirm TLV from the peer.
EAP-要求に設定されると、Cビットは、EAPサーバがこのセッションにおける、タイプPOTP-Xの、より多くのEAP-要求を送るつもりであるのを示します、同輩からのConfirm TLVの領収書の後に。
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.
以下に注意してください。 握手を結論づけるEAPサーバからのEAP-成功メッセージはCビットを設定させなかったConfirm TLVを含むEAP-要求に対応して送られたConfirm TLVを含むEAP-応答のあとに続かなければなりません。 しかしながら、CビットがEAP-要求に設定されたとき、EAPサーバはEAP-成功メッセージよりむしろ別のEAP-要求(例えば、New PIN TLVがProtected TLVで包装した含有)を送るかもしれません。 したがって、同輩は、Confirm TLVを含むタイプPOTP-XのEAP-応答に続く唯一のEAPメッセージがEAP-成功であると仮定してはいけません。 Cビットは、より多くの要求でConfirm TLVに続く彼らの意図を示す方法をEAPサーバに与えて、同輩の州のマシンがこれに順応するのを許容します。
Authentication Data
認証データ
EAP-Request:
EAP-要求:
In a request, this field consists of the first 16 octets of
(see also Section 4.11.3):
要求では、この分野が最初の16の八重奏から成る、(また、セクション4.11.3を見ます):
Nystroem Informational [Page 39] RFC 4793 EAP-POTP February 2007
[39ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
mac_a = MAC(K_MAC', msg_hash(trig_msg))
macはMACと等しいです。'、(K_MAC、'msg_は(輪止め_msg)を論じ尽くします。
where
どこ
MAC is the negotiated MAC algorithm,
MACは交渉されたMACアルゴリズムです。
"K_MAC'" has been calculated as described in Section 4.11.3 or
(in the case of session resumption) Section 4.11.8, and
そしてセクション4.11.3か(セッション再開の場合における)セクション4.11.8で説明されるように「'K_MAC'」について計算してある。
"msg_hash" is the message hash algorithm defined in Section
4.9, and "trig_msg" the latest EAP-Response of type POTP-X
received from the peer (the one which triggered this request).
「msg_ハッシュ」はセクション4.9で定義されたメッセージハッシュアルゴリズムです、そして、タイプPOTP-Xの最新のEAP-応答は同輩(この要求の引き金となったもの)から「_msgとこぎれいにしてください。」と受けました。
Given a saved or recomputed value for K_MAC, the peer
authenticates the EAP server by computing
K_MACのための保存しているか再計算された値を考えて、同輩はコンピューティングでEAPサーバを認証します。
mac'' = MAC(K_MAC, msg_hash(trig_msg'))
"mac"はMACと等しいです。'、(K_MAC、msg_ハッシュ、(_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_ハッシュ、(こぎれいである、_msgに、')」が同輩のそれがサーバに送ったEAP応答メッセージのハッシュであるか、(そして、サーバはメッセージハッシュを当てにしました) 「macの最初の16の八重奏であるなら」Authentication Dataの最初の16の八重奏がさばく問題のEAP-要求のマッチ、そして、EAPサーバは認証されます。
EAP-Response:
EAP-応答:
Not used in this version, and SHALL NOT be present in EAP-
Responses.
このバージョン、およびSHALL NOTでは、現在のコネ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-要求、端が欠けているMAC MAY、暗号化されたコショウとその識別子は任意に支えてください。 この初期の、そして、4八重奏の分野はサーバによって生成されたコショウを特定します。
For this version of EAP-POTP, this field SHALL NOT be present in
EAP-Responses.
EAP-POTPのこのバージョンのために、これは現在のコネがEAP-応答であったならSHALL NOTをさばきます。
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のためにそれ、SHALL、16の八重奏になってください。 コショウが存在している場合にだけ、IVは存在しています、そして、交渉された暗号化アルゴリズムはIVを利用します。 これはこれのためのEAP-応答メッセージにおけるプレゼントがEAP-POTPのバージョンであったならSHALL NOTをさばきます。
Nystroem Informational [Page 40] RFC 4793 EAP-POTP February 2007
[40ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
Encrypted Pepper
暗号化されたコショウ
When present in an EAP-Request, this will be a uniformly
distributed and randomly chosen 16-octet pepper generated by the
EAP server and encrypted with the negotiated encryption algorithm,
using K_ENC as the encryption key and possibly (depending on the
encryption algorithm) using an IV (stored in the IV field). This
field MUST be present if and only if the Pepper Identifier field
is present.
EAP-要求に存在しているとき、これはコショウがEAPサーバで生成して、交渉された暗号化アルゴリズムで暗号化した一様に分配されて、手当たりしだいに選ばれた16八重奏になるでしょう、IV(IV分野では、保存される)を使用することで暗号化キーとことによると(暗号化アルゴリズムによります)としてのK_ENCを使用して。 そして、この分野が存在していなければならない、Pepper Identifier分野が存在している場合にだけ。
EAP servers are RECOMMENDED to include a freshly generated
encrypted pepper (and a corresponding Pepper Identifier) in every
Confirm TLV.
EAPサーバはあらゆるConfirm TLVに新たに生成している暗号化されたコショウ(そして、対応するPepper Identifier)を含むRECOMMENDEDです。
This field SHALL NOT be present in EAP-Response messages for this
version of EAP-POTP.
これはこれのためのEAP-応答メッセージにおけるプレゼントがEAP-POTPのバージョンであったならSHALL NOTをさばきます。
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.
新しいコショウをサーバで生成して、暗号化されたフォームで同輩に移すと、同輩からのConfirm TLV、識別子で保存されて、EAPサーバに関連づけられたSHOULD、および同輩という現在のユーザを受け取り次第EAP成功メッセージを受け取り次第EAPサーバでこの新しいコショウ値を保存するでしょう。 同輩はEAPサーバのためにコショウを既に保存させました、それ。SHALLはそれを新たに受け取られたものに取り替えます。
4.11.7. Vendor-Specific TLV
4.11.7. ベンダー特有のTLV
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.
Vendor特有のTLVは、ベンダーがそれら自身の一般的な用法に適していない拡張属性をサポートするのを許容するために利用可能です。 Vendor特有のTLVはVendor TLVsと呼ばれた1内側のTLVsを含むことができます。 Vendor TLVのTLV-タイプはベンダーによって定義されるでしょう。 独身のVendor特有のTLV SHALLの中のすべてのVendor TLVsが同じベンダーのものです。
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サーバ、および同輩によって送られるかもしれなくて、この仕様に従うすべての実体でサポートしなければなりません。 しかしながら、実装を従わせる場合、特定のVendor TLVsはVendor特有のTLVの中でサポートしないかもしれません。NAK TLVが適切なVendor-IDを含んでいて、彼らはこの場合Vendor TLVsに応じるかもしれません、そして、Vendor 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
タイプPOTP-X MUST NOTのEAP-要求かEAP応答における、Vendor特有のTLVの存在はそのような要求か応答における、TLVsの共存のためのどんな既存の規則にも違反します。 そうすると、それはEAP-失敗(同輩が違反をしたとき)か空のEAP-POTP応答をもたらすでしょう(EAP-サーバが違反をしたとき)。 彼らが現れることができるとき、それがさらに抑制するのが特定のVendor特有のTLVsの定義に残されます。 コネ
Nystroem Informational [Page 41] RFC 4793 EAP-POTP February 2007
[41ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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).
特定です、EAP-POTP実装には、プロテクトモードの互いの認証が起こる(次に、すべてのTLVsを保護するのに、Protected TLV(セクション4.11.15)を使用できるので)前にVendor特有のTLVの使用を完全に禁じる方針があるかもしれません。
Note: This TLV type has the same definition and TLV type number as the Vendor-Specific TLV in [17], and the description of it is largely borrowed from that document.
以下に注意してください。 このTLVタイプはVendor特有のTLVとして[17]に同じ定義とTLV形式数を持っています、そして、そのドキュメントからそれの記述を主に借ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダーイド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダー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)であったならSHALLに噛み付きました。 受取人SHALLはEAP-POTPのこのバージョンのためにこのビットを無視します。
TLV Type
TLVはタイプします。
7
7
Length
長さ
4 + cumulative total length of inner Vendor TLVs
4 + 内側のVendor TLVsの累積している全長
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.
Vendor-イド分野は4つの八重奏です。 SMI Network Managementへのセットが兵士のエンタープライズCodeであったなら3八重奏SHALLを安値で注文してください。そして、高位八重奏SHALL、0に設定されてください、(ネットワークバイトオーダーでVendorの[18])を見てください。
Nystroem Informational [Page 42] RFC 4793 EAP-POTP February 2007
[42ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
Vendor TLVs
ベンダーTLVs
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.
この分野はベンダーによって定義された書式にベンダー特有のTLVsを含むものとします。 断片化(すなわち、最小のEAP MTUサイズより長いEAPメッセージ)、分野SHOULD NOTを避けるには、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.
ベンダーBから受取人EAP実体に解釈されないベンダー特有のTLV(受取人からのNAK TLVを受け取り次第ベンダーA実体SHALL)がベンダーAからのEAP実体(同輩かサーバ)が発信するとき、相互運用性を確実にするために、握手の残りのために問題のベンダー特有のTLVの使用法を控えて、Vendor TLVのためにNAK TLVの領収書によるセッションに失敗してはいけない、(すなわち、それ、まるでベンダー特有のTLVが送られないかのようにSHALLが続く、) さらに、このドキュメントSHOULDとすべての実装conformantが構成でベンダー特有の拡張子の使用をオフにさせます。
4.11.8. Resume TLV
4.11.8. TLVを再開してください。
The Resume TLV MAY be sent by a peer to an authentication server to attempt session resumption.
Resume 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.
セッション再開を許すServer-インフォメーションTLVを含むタイプPOTP-XのEAP-要求に対応してこのTLVタイプを送るだけでよいです。 ServerインフォメーションTLVがセッション再開を許すすべてのEAPサーバでResume 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 | Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sess.Id (cont.)| Authentication Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| セッション識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッション識別子(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sess.Id(cont。)| 認証データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証データ(cont。) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Non-mandatory TLV
0--非義務的なTLV
Nystroem Informational [Page 43] RFC 4793 EAP-POTP February 2007
[43ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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)であったならSHALLに噛み付きました。 受取人SHALLはEAP-POTPのこのバージョンのためにこのビットを無視します。
TLV Type
TLVはタイプします。
8
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.
今後の使用のために、予約されます。 この八重奏SHALL、このバージョンのための(0)のゼロを合わせるように設定されてください。 受取人SHALLは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-インフォメーションTLVとNビットが設定されないかどうかを受け取り次第、同輩はServer Name分野によって特定されるサーバに関連しているどんな保存されたセッションのためにも探します。 保存されたセッションが見つけられるなら、同輩は、無作為の、そして、16八重奏の一回だけ、「c_一回だけ」を生成して、計算します:
K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(base_key, c_nonce |
s_nonce, iteration_count, key_length)
K_Mac| K_ENC| MSK| EMSK| SRKはPBKDF2と等しいです。(_主要なc_一回だけを基礎づけてください| s_一回だけ、繰り返し_カウント、主要な_の長さ)
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),
「ベース_キー」は、セッション(セッションがプロテクトモードで作成されたなら)のための現在のSRKかセッションが作成されたとき(セッションが基本のモードで作成されたなら)使用されるOTPのどちらかです。
"c_nonce" is the generated 16-octet nonce,
「c_一回だけ」は発生している16八重奏の一回だけです。
"s_nonce" is the server nonce from the Server-Info TLV,
「s_一回だけ」はServer-インフォメーションTLVからのサーバ一回だけです。
Nystroem Informational [Page 44] RFC 4793 EAP-POTP February 2007
[44ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
"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.
「主要な_の長さ」は八重奏における必要な主要な材料の結合した長さです。 デフォルトアルゴリズムが使用されているとき、主要な_の長さは176です。
The iteration count need only be 1 (one) when resuming a session
established in protected mode, but MUST be chosen to provide a
suitable level of protection when resuming a session established
in basic mode (see also Section 4.11.3).
繰り返しカウントをプロテクトモードで確立したセッションを再開するときの1であるだけでよいのです(1)が、基本のモードで確立したセッションを再開するとき、適当なレベルの保護を提供するために選ばなければなりません(また、セクション4.11.3を見てください)。
Note: Session resumption for basic mode MUST only be carried out
in a server-authenticated and protected tunnel that also provides
a cryptographic binding for inner EAP methods.
以下に注意してください。 また、内側のEAPメソッドのための暗号の結合を提供するサーバで認証されて保護されたトンネルで基本のモードのためのセッション再開を行うだけでよいです。
The peer then calculates:
次に、同輩は計算します:
mac = MAC(K_MAC, msg_hash(resume_req))
macはMACと等しいです。(K_MAC、msg_ハッシュ(履歴書_req))
where
どこ
"MAC" is the negotiated MAC algorithm, and
そして"MAC"が交渉されたMACアルゴリズムである。
"msg_hash(resume_req) is the message hash algorithm defined in
Section 4.9 applied on resume_req, the EAP server's EAP-Request of
type POTP-X containing the Server-Info TLV that allowed session
resumption.
「msg_ハッシュ(履歴書_req)は履歴書_reqに適用されたセクション4.9で定義されたメッセージハッシュアルゴリズムです、EAPサーバのセッション再開を許したServer-インフォメーションTLVを含むタイプPOTP-XのEAP-要求。」
The peer then places the first 16 octets of the MAC value,
followed by the c_nonce value, followed by the iteration count
value (as a 4-byte unsigned integer in network byte order), in the
Authentication Data field. As an example, when c_nonce =
0x2b3b1b12babdebebfb43bd7bdfbeb8df and iteration_count = 1, the
Authentication Data field will be populated with (in hex):
次に、同輩は繰り返しカウント価値(ネットワークバイトオーダーにおける4バイトの符号のない整数としての)があとに続いたc_一回だけ価値があとに続いたMAC価値の最初の16の八重奏を置きます、Authentication Data分野で。 例として、c_一回だけがいつ0x2b3b1b12babdebebfb43bd7bdfbeb8dfと等しいか、そして、繰り返し_は=1を数えます、分野が居住されるAuthentication Data(十六進法で):
< 16 octets of mac > | 2b3b1b12babdebebfb43bd7bdfbeb8df | 00000001
mac>の<16八重奏| 2b3b1b12babdebebfb43bd7bdfbeb8df| 00000001
The server authenticates the peer by performing the corresponding
calculations. If the authentication is successful, the server
MUST send an EAP-Request of type POTP-X containing a Confirm TLV
to the peer. If the authentication fails, the server MUST either
send an EAP-Request of type POTP-X containing an OTP TLV and a
Server-Info TLV, where the Server-Info TLV indicates that session
resumption is not possible, or send an EAP-Failure.
サーバは、対応する計算を実行することによって、同輩を認証します。 認証がうまくいくなら、サーバは同輩にConfirm TLVを含むタイプPOTP-XのEAP-要求を送らなければなりません。 認証が失敗するなら、サーバは、OTP TLVを含むタイプPOTP-XとServer-インフォメーションTLVのEAP-要求を送らなければならないか、またはEAP-失敗を送らなければなりません。(そこで、Server-インフォメーションTLVはセッション再開が可能でないことを示します)。
Nystroem Informational [Page 45] RFC 4793 EAP-POTP February 2007
[45ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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が計算された後に捨てられて、確かめられたキーSHALLについて計算しました。 プロテクトモードで再開するとき、新しいSRKは保存されたSRKを取り替えるでしょう、そして、新しいMSKとEMSKはメソッドの無事終了のときにエクスポートされるでしょう。
4.11.9. User Identifier TLV
4.11.9. ユーザ識別子TLV
The User Identifier TLV carries an identifier, typically the username, for the holder of the OTP token used to generate the OTP.
User Identifier 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.
少なくともUser Identifier TLVとToken Key Identifier TLV SHOULDの1つは、セッションのまた、a適当なアイデンティティがタイプIdentity(1)の前のEAP-応答に提供されていない場合OTP TLVを運ぶタイプPOTP-Xの最初のEAP-応答で存在しているか、またはある他の手段で決定します([1]を見てください、セクション2)。 タイプIdentity(1)のEAP-応答を送ったときさえ、User Identifier TLV、そして/または、Token Key Identifier TLVの使用はRECOMMENDEDです。 同輩がUser Identifier TLVとToken Key Identifier TLVの両方を送るなら、EAPサーバSHALLは与えられたユーザにとって、主要な特定のトークンを指定するとToken Key Identifier 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サーバでサポートしなければなりません。 User Identifier 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ユーザ識別子… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)であったならSHALLに噛み付きました。 受取人SHALLはEAP-POTPのこのバージョンのためにこのビットを無視します。
Nystroem Informational [Page 46] RFC 4793 EAP-POTP February 2007
[46ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
TLV Type
TLVはタイプします。
9
9
Length
長さ
Length of User Identifier, >= 1
ユーザ識別子、>=1の長さ
User Identifier
ユーザ識別子
The value SHALL be an UTF-8 encoded string representing the holder
of the token (MUST NOT be NULL-terminated). The string MUST be
less than 128 octets in length.
UTF-8がトークン(NULLによって終えられるはずがない)の所有者の代理をするコード化されたストリングであったならSHALLを評価してください。 ストリングは長さが128未満の八重奏であるに違いありません。
4.11.10. Token Key Identifier TLV
4.11.10. トークンの主要な識別子TLV
The Token Key Identifier TLV carries an identifier for the token key used to generate the OTP.
Token Key Identifier TLVはOTPを生成するのに使用されるトークンキーのための識別子を運びます。
At least one of the User Identifier TLV and the Token Key Identifier TLV SHOULD be present in the session's first EAP-Response of type POTP-X, which also carries the OTP TLV unless a suitable identity has been provided in a preceding EAP-Response of type Identity (1) or is determined by some other means (see [1], Section 2). Use of the User Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED even when an EAP-Response of type Identity (1) has been sent. If a peer sends both a User Identifier TLV and a Token Key Identifier TLV, then the EAP server SHALL interpret the Token Key Identifier TLV as specifying a particular token key for the given user. The EAP server MUST respond with an EAP-Failure if it cannot find a token key corresponding to the provided token key identifier.
少なくともUser Identifier TLVとToken Key Identifier TLV SHOULDの1つは、セッションのまた、適当なアイデンティティがタイプIdentity(1)の前のEAP-応答に提供されていない場合OTP TLVを運ぶタイプPOTP-Xの最初のEAP-応答で存在しているか、またはある他の手段で決定します([1]を見てください、セクション2)。 タイプIdentity(1)のEAP-応答を送ったときさえ、User Identifier TLV、そして/または、Token Key Identifier TLVの使用はRECOMMENDEDです。 同輩がUser Identifier TLVとToken Key Identifier TLVの両方を送るなら、EAPサーバSHALLは与えられたユーザにとって、主要な特定のトークンを指定するとToken Key Identifier 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サーバでサポートしなければなりません。 Token Key Identifier 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トークンの主要な識別子… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1--義務的なTLV
Nystroem Informational [Page 47] RFC 4793 EAP-POTP February 2007
[47ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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)であったならSHALLに噛み付きました。 受取人SHALLは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未満の八重奏であるに違いありません。
4.11.11. Time Stamp TLV
4.11.11. タイムスタンプTLV
The Time Stamp TLV MAY be sent by peers to simplify authentications. When present, it carries the time as reported by the OTP Token.
Time Stamp TLVは、認証を簡素化するために同輩によって送られるかもしれません。 存在しているとき、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.
すなわち、この仕様SHOULDサポートがあるEAPサーバconformant、(認識、)、それに処理するか、または影響する必要はないことができるのを除いたこのTLV。 このTLVをサポートしませんが、TLVが存在していた状態でEAP-応答を受けるEAPサーバは値を無視するかもしれません。 Time Stamp TLVはそれら以外のまた、OTP TLVを運ぶタイプPOTP-XのどんなEAP-応答でも存在しているはずがありません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 時間スタンプ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)であったならSHALLに噛み付きました。 受取人SHALLはEAP-POTPのこのバージョンのためにこのビットを無視します。
Nystroem Informational [Page 48] RFC 4793 EAP-POTP February 2007
[48ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
TLV Type
TLVはタイプします。
11
11
Length
長さ
Length of Time Stamp field, >= 20 (depending on precision)
Time Stamp分野、>=20の長さ(精度に依存します)
Time Stamp
タイムスタンプ
The time, as reported by the OTP token, at which the OTP used for
the accompanying OTP TLV was calculated. The field SHALL contain
a UTF-8 encoded value of the XML simple type "dateTime", with time
zone information and precision down to at least seconds, e.g.,
"2004-06-16T15:20:02Z".
付随のOTP TLVに使用されるOTPがOTPトークンによって報告されるどれであったかで計算された時間。 コード化されて、分野SHALLはUTF-8を含んでいます。時間帯の情報と精度でXMLの純真なタイプに"dateTime"を少なくとも秒、例えば、「2004-06-16T15:20:02Z」まで評価してください。
4.11.12. Counter TLV
4.11.12. カウンタTLV
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.
Counter TLVは、認証を簡素化するために同輩によって送られるかもしれません。 存在しているとき、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.
すなわち、この仕様SHOULDサポートがあるEAPサーバconformant、(認識、)、それに処理するか、または影響する必要はないことができるのを除いたこのTLV。 このTLVをサポートしませんが、TLVが存在していた状態でEAP-応答を受けるEAPサーバは値を無視するかもしれません。 Counter 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 反対してください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)であったならSHALLに噛み付きました。 受取人SHALLはEAP-POTPのこのバージョンのためにこのビットを無視します。
Nystroem Informational [Page 49] RFC 4793 EAP-POTP February 2007
[49ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
TLV Type
TLVはタイプします。
12
12
Length
長さ
Length of Counter field, >= 1 (depending on precision)
Counter分野、>=1の長さ(精度に依存します)
Counter
カウンタ
The counter value, as reported by the OTP token, at which the OTP
used for the accompanying OTP TLV was calculated. The counter
value SHALL be represented as an unsigned integer in network-byte
order, e.g., a counter value of 1030 may be sent as the 2 octets
(in hex) 04 06.
付随のOTP TLVに使用されるOTPがOTPトークンによって報告されるどれであったかで計算された対価。 対価SHALLがネットワークバイトオーダーにおける符号のない整数として表されて、2つの八重奏(十六進法における)04 06として例えば1030年の対価を送るかもしれません。
4.11.13. Challenge TLV
4.11.13. 挑戦TLV
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).
Challenge TLVはトークンによって使用される、OTPについて計算する挑戦を運びます、トークンによって同輩に報告されるように。 同輩がChallenge 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.
すなわち、この仕様SHOULDサポートがあるEAPサーバconformant、(認識、)、それに処理するか、または影響する必要はないことができるのを除いたこのTLV。 このTLVをサポートしませんが、TLVが存在していた状態でEAP-応答を受けるEAPサーバは値を無視するかもしれません。 Challenge 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 挑戦してください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)であったならSHALLに噛み付きました。 受取人SHALLはEAP-POTPのこのバージョンのためにこのビットを無視します。
Nystroem Informational [Page 50] RFC 4793 EAP-POTP February 2007
[50ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
TLV Type
TLVはタイプします。
16
16
Length
長さ
Length of Challenge field, >= 1
Challenge分野、>=1の長さ
Challenge
挑戦
The challenge value that was used to calculate the OTP used for
the accompanying OTP TLV.
付随のOTP TLVに使用されるOTPについて計算するのに使用された挑戦値。
4.11.14. Keep-Alive TLV
4.11.14. TLVを生かしてください。
The Keep-Alive is used to avoid EAP-POTP timeouts.
生きているKeepは、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.
生きているKeep TLV MAYはOTP TLVかNew PIN TLVを含んで、同輩がEAP-要求を受け取ったとき、タイムアウトを避けるために同輩によって送られて、ユーザから応答を待っています。
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 TLVを含んでいて、サーバがEAP-応答を受けて、サーバに生きているKeep TLVを含まなかった傑出している要求があるときには生きているKeep TLV MUSTを含んで、EAPサーバによって送られるようEAP要求してください。 この状況で、サーバは最新の傑出している要求を再送する必要はありませんが、EAPの同期自然のため、それは、別の要求を送る必要があります。 要求は新しいIdentifier値を得るでしょう、したがって、最新の傑出している要求の再伝達が同輩のために混乱させられることができました。 生きているKeep TLV MAYもサーバがそれを検出するとEAPサーバで送って、処理時間が何らかの局所的に構成された敷居を超えるということであり、ネットワークタイムアウトを引き起こすかもしれません。 この場合、同輩はEAP-応答が生きているKeepを含んでいるTLVを反応させなければなりません。
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].
サーバがこの仕様に従って、NAK TLVと共に反応してはいけないすべての同輩とすべてのEAPがこのTLVタイプをサポートしなければなりません。 生きているKeep TLV MUST NOT、上で説明されたものよりいかなる他の状況でも、送ってください。 生きているKeep TLV MUST NOT、ここに定義されたいかなる他のTLVsと共にも送ってください。 また、実装SHOULDは[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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nystroem Informational [Page 51] RFC 4793 EAP-POTP February 2007
[51ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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)であったならSHALLに噛み付きました。 受取人SHALLはEAP- POTPのこのバージョンのためにこのビットを無視します。
TLV Type
TLVはタイプします。
13
13
Length
長さ
0
0
4.11.15. Protected TLV
4.11.15. 保護されたTLV
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.
Protected TLV SHALL、使用されて(計算されたキーが確認されるとすぐにすなわち、)、Confirm TLVのうまくいっている交換の後に個々であるか複数のTLVsを暗号化してください。 したがって、Protected TLVは「普通」のTLVsを包装します。
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サーバと同輩によって送られるかもしれなくて、この仕様に従うすべての同輩がサポートしなければなりません。 それ、SHOULD、この仕様に従うすべてのEAPサーバで、サポートされてください(サーバにConfirm 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 通報認証コード… (16の八重奏) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVsを暗号化します… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1--義務的なTLV
Nystroem Informational [Page 52] RFC 4793 EAP-POTP February 2007
[52ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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)であったならSHALLに噛み付きました。 受取人SHALLは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 SHALL、IVとEncrypted TLVs分野に関して、以下の方法で計算されてください:
mac = MAC(K_MAC, iv | encrypted_tlvs)
macはMACと等しいです。(iv| _K MAC、暗号化された_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フィールドの値です、そして、「暗号化された_tlvs」はEncrypted 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について確かめなければなりません。 検証は失敗します、会話SHALL。終えられてください(すなわち、同輩は空のPOTP-X EAP-応答メッセージを送ります、そして、EAPサーバはタイプNotificationの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
暗号化されたTLVs
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
この分野SHALLは1暗号化されたPOTP-X TLVsを含んでいます。 暗号化アルゴリズムSHALLは交渉されるとしてそうです。 暗号化キーとしてK_ENCを使用してください、そして、初期化ベクトルとしてIV分野を使用してください。
Nystroem Informational [Page 53] RFC 4793 EAP-POTP February 2007
[53ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
(when applicable), to encrypt the concatenation of all the TLVs to
be protected.
(適切であるときに)、保護されるためにすべてのTLVsの連結を暗号化するために。
4.11.16. Crypto Algorithm TLV
4.11.16. 暗号アルゴリズムTLV
The Crypto Algorithm TLV allows for negotiation of cryptographic algorithms. Cryptographic Algorithm negotiation is described in detail in Section 4.3.
Crypto Algorithm TLVは暗号アルゴリズムの交渉を考慮します。暗号のAlgorithm交渉はセクション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 MUST、また、プロテクトモードを示すOTP TLVを運ぶタイプPOTP-Xの初期のEAP-要求に存在してください、EAPサーバがいかなる他のアルゴリズムの使用も交渉したがっていると仮定してデフォルト、もの また、それもいつ失敗したセッション再開(この場合、同輩はまだこのTLVに応じていない)の結果かそれともCrypto Algorithm TLVがEAPサーバからの初期のメッセージの一部であり、クライアントがEAPサーバによってサポートされる中で最も高い方より別のEAP- POTPバージョンを交渉したかとして送られるOTP TLVを運ぶタイプPOTP-XのEAP-要求に存在しているかもしれません。Crypto Algorithm TLVはいかなる他のEAP-要求にも存在しているはずがありません。 さらに、また、前のEAP-要求がそれを含んで、そうするのが法的でなかったなら、Crypto Algorithm TLVはタイプPOTP-XのEAP応答で存在しているはずがありません。 このTLV MUSTにこの仕様に従うすべての同輩とすべての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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はタイプします。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|ハッシュAlg.Length| アルゴリズムを論じ尽くしてください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Encr.Alg.Length| 暗号化アルゴリズム… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MAC Alg。 長さ| MACアルゴリズム… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)であったならSHALLに噛み付きました。 受取人SHALLはEAP-POTPのこのバージョンのためにこのビットを無視します。
Nystroem Informational [Page 54] RFC 4793 EAP-POTP February 2007
[54ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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.
今後の使用のために、予約されます。 このバージョンのためにこの八重奏をゼロに設定しなければなりません。 受取人SHALLはEAP-POTPのこのバージョンのためのこの八重奏を無視します。
Hash Alg. Length
Algを論じ尽くしてください。 長さ
The length of the Hash Algorithms field in octets.
八重奏における、Hash Algorithms分野の長さ。
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サーバはハッシュアルゴリズムのためのいくつかの提案を供給するかもしれません。各アルゴリズムは一度だけ現れなければなりません。 アルゴリズムSHALL、優先権の順に、供給してください。 同輩は大部分で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)
値のOctet1Octet2Hashアルゴリズム------- ------- ---------------------------------- 0×00の0×00の予約された0×00 0×01SHA-1 0x00 0×02SHA-224 0x00 0×03SHA-256(デフォルト)0×00 0×04SHA-384 0x00 0×05SHA-512 0x80--ベンダー詳細(実験的)
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.
より高いのは、独占ベンダー特有のアルゴリズムのためのそうです。そして、示されて、0×8000を評価する. 範囲0x0006の値--0x7fffはIANAを通して割り当てられることになっています。 セクション7を見てください。
Encr Alg. Length
Encr Alg。 長さ
The length of the Encryption Algorithms field in octets.
八重奏における、Encryption Algorithms分野の長さ。
Nystroem Informational [Page 55] RFC 4793 EAP-POTP February 2007
[55ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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サーバは暗号化アルゴリズムのためのいくつかの提案を供給するかもしれません。各アルゴリズムは一度だけ現れなければなりません。 アルゴリズムSHALL、優先権の順に、供給してください。 同輩は大部分で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
値のOctet1Octet2Encryptionアルゴリズム------- ------- ------------------------ 128ビットのキーと16八重奏のIVsと0×00の0×00の予約された0×00 0×01AES-CBC(デフォルト)、0×00、0×02 3DES-CBC、112ビットのキーと8八重奏のIVs0x80と共に--、ベンダー特有
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.
より高いのは、ベンダー特有の独占アルゴリズムのためのそうです。そして、示されて、0×8000を評価する. 範囲0x0003の値--0x7fffはIANAを通して割り当てられることになっています。 セクション7を見てください。
MAC Alg. Length
MAC Alg。 長さ
The length of the MAC Algorithms field in octets.
八重奏における、MAC Algorithms分野の長さ。
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アルゴリズムのためのいくつかの提案を供給するかもしれません。各アルゴリズムは一度だけ現れなければなりません。 アルゴリズムSHALL、優先権の順に、供給してください。 同輩は大部分で1つのアルゴリズムを供給しなければなりません(なにも存在していないなら、デフォルトは適用されます)。 定義された値は以下の通りです。
Value
Octet 1 Octet 2 MAC algorithm
------- ------- -----------------
0x00 0x00 Reserved
0x00 0x01 HMAC (default)
0x80 - Vendor-specific
値のOctet1Octet2MACアルゴリズム------- ------- ----------------- 0×00の0×00の予約された0×00 0×01HMAC(デフォルト)0×80--ベンダー詳細
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.
より高いのは、ベンダー特有の独占アルゴリズムのためのそうです。そして、示されて、0×8000を評価する. 範囲0x0002の値--0x7fffはIANAを通して割り当てられることになっています。 セクション7を見てください。
When HMAC is negotiated, the hash algorithm used for HMAC SHALL be
the negotiated hash algorithm.
HMACが交渉されるとき、HMAC SHALLが交渉であったので、使用されるハッシュアルゴリズムはアルゴリズムを論じ尽くします。
Nystroem Informational [Page 56] RFC 4793 EAP-POTP February 2007
[56ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
5. EAP Key Management Framework Considerations
5. EAP Key Managementフレームワーク問題
In line with recommendations made in [16], EAP-POTP defines the following identifiers to be associated with generated key material:
[16]でされた推薦状に沿って、EAP-POTPは発生している主要な材料に関連しているように以下の識別子を定義します:
Peer-ID: The combined contents of the User Identifier TLV and the
Token Key Identifier TLV.
同輩ID: User Identifier TLVとToken Key Identifier TLVの結合したコンテンツ。
Server-ID: The contents of the Server Identifier field of the
Server-Info TLV.
Server ID: Server-インフォメーションTLVのServer Identifier分野のコンテンツ。
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: 確立したセッション(すなわち、セッションを定義したServer-インフォメーションTLVのSession Identifier分野のコンテンツ)に関する識別子。
6. Security Considerations
6. セキュリティ問題
6.1. Security Claims
6.1. セキュリティクレーム
In conformance with RFC 3748 [1], the following security claims are made for the EAP-POTP method:
RFC3748[1]がある順応では、EAP-POTPメソッドのために以下のセキュリティクレームをします:
Authentication mechanism: Generic OTP
Ciphersuite negotiation: Yes (No in basic variant)
Mutual authentication: Yes (No in basic variant)
Integrity protection: Yes (No in basic variant)
Replay protection: Yes (see below)
Confidentiality: Only in the OTP protection variant, and
then only OTP values and any information
sent after exchange of the Confirm TLV
Key derivation: Yes (No in basic variant)
Key strength: Depends on size of OTP value, strength of
underlying shared secret, strength and
characteristics of OTP algorithm, pepper
length, iteration count, and whether the
method is used within a tunnel such as
PEAPv2. For some illustrative examples,
and a further discussion of this, see
Appendix D.
Dictionary attack prot.: N/A (Human-selected passwords not used)
Fast reconnect: Yes
Crypt. binding: N/A (EAP-POTP is not a tunnel method)
Session independence: Yes
Fragmentation: N/A (Packets shall not exceed MTU of 1020)
Channel binding: Yes (No in basic variant)
Acknowledged S/F: Yes
State Synchronization: Yes (No in basic variant)
認証機構: ジェネリックOTP Ciphersuite交渉: はい(基本的な異形でいいえ)の互いの認証: はい(基本的な異形でいいえ)、保全保護: はい(基本的な異形でいいえ)、反復操作による保護: はい(以下を見る)、秘密性: OTP保護異形、および次に、OTPだけの値とどんな情報もConfirm TLV Key派生の交換の後に発信しました: はい(基本的な異形でいいえ)の主要な強さ: カウントとメソッドがPEAPv2などのトンネルの中で使用されるかどうかOTPアルゴリズムのOTP値、基本的な共有秘密キーの強さ、強さ、および特性のサイズ、コショウの長さ、繰り返しによります。 いくつかの説明に役立つ実例、およびこのさらなる議論に関しては、Appendix D.Dictionary攻撃protを見てください、: N/A(使用されない人間によって選択されたパスワード)は速く再接続されます: はい、Crypt結合: N/A(EAP-POTPはトンネルメソッドでない)セッション独立: はい断片化: N/は以下を縛る(パケットは1020年のMTUを超えていないものとします)チャンネルです。 はい(基本的な異形でいいえ)はS/Fを承認しました: はい州の同期: はい(基本的な異形でいいえ)
Nystroem Informational [Page 57] RFC 4793 EAP-POTP February 2007
[57ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
6.2. Passive and Active Attacks
6.2. 受け身の、そして、活発な攻撃
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メソッドの基本的な異形(すなわち、OTPsと互いの認証の保護が使用されていないとき)は活発な攻撃からセッションプライバシー、セッション保全、サーバ証明、または保護を提供しません。 攻撃者が有効な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メソッドはOTPs、新しい暗証番号、暗号アルゴリズムの交渉、互いの認証、反射攻撃に対する保護、およびプロトコルバージョンダウングレードにプライバシーを供給します。 また、中央の与えられている有効なOTPのために解決する男性のための「不-実行可能性」ではなく、介入者攻撃に対する保護にOTP TLVを提供しますが、それはそれが有効である限られた期間にOTPを見つけるコンピュータの費用のためそうします(トークンに、これは主に本当です、彼らのOTP計算における現在の時間かそれともいつ、送られた挑戦には、ある寿命があるかを含んでいて)。 しかしながら、「古く」無効であっても検索されたOTPがまだユーザの暗証番号の何らかの情報を明かしているかもしれないことに注意されるべきです。 また、明確に、基本的な異形には、これも本当です。 したがって、このEAPメソッドの実装は暗証番号変化を愛用者に保証するユーザ暗証番号がOTPsと共に送られるところのRECOMMENDEDです、保護された異形か基本的な異形が採用しているかどうかにかかわらず。
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
プロテクトモードは双方がこのモードで伝えるHMACによるバージョンダウングレード攻撃から守ります。 説明されるように、各当事者は送られて受信されたEAP-POTP握手メッセージでHMACについて計算します。 攻撃者がバージョンTLVを変更するなら、これは反映されるでしょうに。
Nystroem Informational [Page 58] RFC 4793 EAP-POTP February 2007
[58ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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.
計算されたMACs(バージョン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保護異形の使用はRECOMMENDEDです。
However, it should be noted that not even the OTP protection variant provides privacy for user names and/or token key identifiers. EAP- POTP MUST be used within a secure tunnel such as the one provided by PEAPv2 [17] if privacy for these parameters is required.
しかしながら、OTP保護異形さえユーザ名、そして/または、トークンの主要な識別子にプライバシーを提供しないことに注意されるべきです。 EAP- POTP MUST、[17] これらのパラメタのためのプライバシーが必要であるならPEAPv2によって提供されたものなどの安全なトンネルの中で使用されてください。
When resuming sessions created in the basic variant (which MUST only take place within a protected tunnel), the peer is authenticated by demonstrating knowledge of not just a valid session identifier, but also the OTP used when the session was created. Server nonces prevent replay attacks, but there still remains some likelihood of an attacker guessing the correct combination of session identifier and OTP value. Assuming OTPs with entropy about 32 bits, this means that the likelihood of succeeding with such an attack is about 1/2^48 due to the birthday paradox. Servers allowing session resumption for the basic variant MUST protect against such attacks, e.g., by keeping track of the rate of failed resumption attempts.
基本的な異形(保護されたトンネルの中で行われるだけでよい)で作成されて、再開するとき、同輩は、有効なセッション識別子だけではなく、セッションが作成されたとき使用されるOTPに関して知識を示すことによって、認証されます。 サーバ一回だけは反射攻撃を防ぎますが、攻撃者がセッション識別子とOTP価値の正しい組み合わせを推測するという何らかの見込みがまだ残っています。 およそ32ビットのエントロピーがあるOTPsを仮定して、これは、そのような攻撃で成功するという見込みが誕生日のパラドックスへのおよそ1/2^48支払われるべきものであることを意味します。 基本的な異形のためのセッション再開を許すサーバはそのような攻撃から守らなければなりません、例えば、失敗した再開試みの速度の動向をおさえることによって。
6.3. Denial-of-Service Attacks
6.3. サービス不能攻撃
An active attacker may replace the iteration count value in OTP TLVs sent by the peer to slow down an authentication server. Authentication servers SHOULD protect against this, e.g., by disregarding OTP TLVs with an iteration count value higher than some number that is preset or dynamically set (depending on load).
活発な攻撃者は認証サーバを減速させるために同輩によって送られたOTP TLVsで繰り返しカウント価値を置き換えるかもしれません。認証サーバSHOULDはこれから守ります、例えば、繰り返しカウント価値があらかじめセットされるか、またはダイナミックに設定される何らかの数より高い状態でOTP TLVsを無視することによって(負荷によって)。
6.4. The Use of Pepper
6.4. コショウの使用
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
セクション4.8で説明されるように、コショウの使用は攻撃者の合っているOTPの検索を減速させるでしょう。 暗号化されたフォームでEAPサーバから同輩までコショウ値を移す能力は、EAPサーバが同輩を認証する初期のコンピュータの費用があるかもしれませんが、その後の認証が効率的になることを意味します、値はあらかじめ共有されて、長さ128ビットのコショウ以来、より安全な同時に攻撃者によって容易に見つけられないでしょうが。 同輩によって選ばれたコショウを使用することで計算されたOTP TLVを含むEAP-要求を観測して、攻撃者は、しかしながら、利用可能資源によって、その特定のEAP-POTPセッションのときに首尾よく攻撃できるかもしれません、たぶんaに基づくので
Nystroem Informational [Page 59] RFC 4793 EAP-POTP February 2007
[59ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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.
比較的短いコショウ値か繰り返しカウントだけ。 正しいOTPがいったん見つけられると、EAPサーバのConfirm TLVを立ち聞きすると、より長いことへの攻撃者アクセスは潜在的に与えられるでしょう、とサーバがそのコショウ価値の残っている生涯のためのコショウを前提としました。 この理由で、EAPサーバSHOULDとの初期の交換は安全な環境(例えば、内側のEAPメソッドで暗号の結合を提供するPEAPv2トンネルの)で起こります。 初期の交換が安全な環境で起こらないなら、繰り返しカウントはあらかじめ共有されたコショウが使用されているメッセージよりかなり高くなければなりません。 また、念頭でこれで共有されたコショウの生涯について計算しなければなりません。 最終的に、同輩とEAPサーバは、しっかりとコショウ値を保存しなければならなくて、ユーザと交際しました。
6.5. The Race Attack
6.5. レース攻撃
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]から借ります。 実装は、このアプローチを使用するか、または代替防衛を選択するかもしれません。 説明されたディフェンスが初期のIdentity EAP要求に対応してアイデンティティを提供するユーザに頼ることに注意してください。
One possible defense is to prevent a user from starting multiple simultaneous authentication sessions. This means that once the legitimate user has initiated authentication, an attacker would be blocked until the first authentication process has completed. In this approach, a timeout is necessary to thwart a denial-of-service attack.
1つの可能なディフェンスはユーザが複数の同時の認証セッションに始めるのを防ぐことです。 これは、正統のユーザがいったん認証を開始すると、攻撃者が認証過程が完成した1日まで妨げられることを意味します。 このアプローチでは、タイムアウトが、サービス不能攻撃を阻むのに必要です。
7. IANA Considerations
7. IANA問題
7.1. General
7.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 TLVsのセットかEAP-POTP暗号アルゴリズムのセットを広げるのは、プロトコルの改正と考えられて、したがって、このドキュメントをアップデートするか、または時代遅れにするRFCを必要とするものとします。
Nystroem Informational [Page 60] RFC 4793 EAP-POTP February 2007
[60ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
7.2. Cryptographic Algorithm Identifier Octets
7.2. 暗号アルゴリズム識別子八重奏
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).
「仕様が必要であっ」て、「IESG承認」があるIANAを通してCrypto Algorithm TLVのハッシュアルゴリズム、暗号化アルゴリズム、およびMACアルゴリズムのための新しい値の課題をしなければなりません(これらの用語の意味のための[9]を見てください)。
8. Intellectual Property Considerations
8. 知的所有権問題
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.の登録商標か商標のどちらかです。 他の製品の、そして、言及されたサービスの名前は彼らのそれぞれの所有者の商標であるかもしれません。
9. Acknowledgments
9. 承認
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 Security従業員。 サイモンJosefssonはRSA研究所に働いている間、RSA SecurID EAPメソッドの初期のバージョンを作成しました。 TLV-情報の種類交換のためのインスピレーションは[17]から来ます。 頻繁な役に立つコメントと提案を提供したFunk SoftwareのオリバーTavakoli、セッション再開領域での良い提案のためのランディアルーバ町Networks、およびインスピレーションをProtected TLVに供給したMeetinghouseのジム・バーンズへの特別な感謝。 ドキュメントを改良するのを助けた洞察に満ちたコメントと、徹底的な社説のためのアルフレッドHoenesへのIESG評論家(パシEronen)のデヴィッドBlack、およびユリ・ブルーメンソルにも感謝は論評します。
Nystroem Informational [Page 61] RFC 4793 EAP-POTP February 2007
[61ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[1]BlunkとL.とVollbrechtとJ.とAbobaとB.とカールソン、J.とH.Levkowetz、エド、「拡張認証プロトコル(EAP)」、RFC3748(2004年6月)
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS 180-2, February 2004.
[3]米国商務省標準技術局、「安全なハッシュ規格」、FIPS180-2、2004年2月。
[4] National Institute of Standards and Technology, "Specification
for the Advanced Encryption Standard (AES)", FIPS 197, November
2001.
[4] 米国商務省標準技術局、「エー・イー・エス(AES)のための仕様」、FIPS197、2001年11月。
[5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[5]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[6] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification
Version 2.0", RFC 2898, September 2000.
[6]Kaliski、B.、「PKCS#5:」 パスワードベースの暗号仕様バージョン2インチ、RFC2898、2000年9月。
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[7]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変換形式
[8] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[8]Schulzrinne、2004年12月のH.、「Telephone民数記のためのtel URI」RFC3966。
[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問題部に書くためのガイドライン」、RFC2434、1998年10月。
10.2. Informative References
10.2. 有益な参照
[10] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[10] シンプソン、W.、エド、「二地点間プロトコル(ppp)」、STD51、RFC1661、7月1994日
[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] 米国電気電子技術者学会Inc.、「LocalとメトロポリタンエリアネットワークのためのIEEE Standard--Network Access Controlをポートで基礎づける」IEEE 802.1X-2001(2001年7月)。
[12] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[12] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
Nystroem Informational [Page 62] RFC 4793 EAP-POTP February 2007
[62ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
[13] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for Wireless
LANs", RFC 4017, March 2005.
[13] スタンリー、D.、ウォーカー、J.、およびB.Aboba、「ワイヤレスのLANのための拡張認証プロトコル(EAP)メソッド要件」、RFC4017(2005年3月)。
[14] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time
Password System", STD 61, RFC 2289, February 1998.
[14] ハラー、N.、メス、C.、Nesser、P.、およびM.わら、「A One-時間パスワードシステム」、STD61、RFC2289、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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(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.とサイモンとD.とEronen、P.とLevkowetz(エド)「拡張認証プロトコル(EAP)Key Managementフレームワーク」というが進行中で扱うH.、2006年10月。
[17] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H., and S.
Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in
Progress, October 2004.
[17] Palekar、A.、サイモン、D.、ゾルン、G.、Salowey、J.、周、H.、およびS.Josefsson、「保護されたEAPプロトコル(PEAP)バージョン2インチ、進歩、2004年10月に働いてください。」
[18] Internet Assigned Numbers Authority, "Private Enterprise
Numbers", December 2006.
[18] インターネットは数の権威、「私企業番号」に2006年12月を割り当てました。
[19] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
2548, March 1999.
[19] ゾルン、G.、「マイクロソフトのベンダー特有の半径属性」、RFC2548、1999年3月。
Nystroem Informational [Page 63] RFC 4793 EAP-POTP February 2007
[63ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
Appendix A. Profile of EAP-POTP for RSA SecurID
RSA SecurIDのためのEAP-POTPの付録A.プロフィール
Note: The RSA SecurID product is a hardware token card (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication.
以下に注意してください。 RSA SecurID製品はエンドユーザ認証に使用されるRSA 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 SHALLのSecurIDプロフィールを実装する同輩とEAPサーバがこのDocumentですべてのEAP-POTPに標準の要件を従わせます。 さらに、同輩はNew PIN TLVとProtected TLVをサポートしなければなりません。
Nystroem Informational [Page 64] RFC 4793 EAP-POTP February 2007
[64ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
Appendix B. Examples of EAP-POTP Exchanges
EAP-POTP交換に関する付録B.の例
This appendix is non-normative. In the examples, "V1", "V2", "V3", etc., stand for arbitrary values of the correct type.
この付録は非規範的です。 例で「V1"、「V2"、「V3"などは正しいタイプの任意の値を表します」。
B.1. Basic Mode, Unilateral Authentication
B.1。 基本のモード、一方的な認証
This mode should only be used within a secured tunnel. The peer identifies itself with a User Identifier TLV.
このモードは機密保護しているトンネルの中で使用されるだけであるべきです。 同輩はそれ自体をUser Identifier TLVと同一視します。
Peer EAP server
同輩EAPサーバ
<- EAP-Request
Type=Identity
<EAP-要求タイプはアイデンティティと等しいです。
EAP-Response -> Type=Identity
EAP-応答->は=アイデンティティをタイプします。
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Version TLV:
Highest=0,Lowest=0
バージョンTLV: 最も高い=0、最も低い=0
OTP TLV:
P=0,C=0,N=0,T=0,E=0,R=0
OTP TLV: P=0、C=0、N=0、T=0、E=0、R=0
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Version TLV: Highest=0
バージョンTLV: 最も高い=0
OTP TLV: P=0,C=0,N=0,T=0,E=0,R=0 Authentication Data=V1
OTP TLV: P=0、C=0、N=0、T=0、E=0、R=0認証データはV1と等しいです。
User Identifier TLV: User Identifier=V2
ユーザ識別子TLV: ユーザ識別子=V2
<- EAP-Success
<EAP-成功
Nystroem Informational [Page 65] RFC 4793 EAP-POTP February 2007
[65ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
B.2. Basic Mode, Session Resumption
B.2。 基本のモード、セッション再開
This example illustrates successful resumption of a basic mode session. It must be carried out only in a protected tunnel.
この例は基本的なモードセッションのうまくいっている再開を例証します。 保護されたトンネルだけでそれを行わなければなりません。
Peer EAP server
同輩EAPサーバ
<- EAP-Request
Type=Identity
<EAP-要求タイプはアイデンティティと等しいです。
EAP-Response -> Type=Identity
EAP-応答->は=アイデンティティをタイプします。
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Version TLV:
Highest=0,Lowest=0
バージョンTLV: 最も高い=0、最も低い=0
OTP TLV:
P=0,C=0,N=0,T=0,E=0,R=0
OTP TLV: P=0、C=0、N=0、T=0、E=0、R=0
Server-Info TLV:
N=0
Session Identifier=V1
Server Identifier=V2
Nonce=V3
EAP-Response ->
Type=OTP-X
サーバインフォメーションTLV: N=0セッション識別子=V1サーバ識別子=V2一回だけ=V3 EAP-応答->は=OTP-Xをタイプします。
Version TLV: Highest=0
バージョンTLV: 最も高い=0
Resume TLV: Session Identifier=V4 (indicating earlier, basic mode, session) Authentication Data=V5
TLVを再開してください: セッションIdentifier=V4(より早くて、基本のモード、セッションを示す)認証Data=V5
<- EAP-Success
<EAP-成功
Nystroem Informational [Page 66] RFC 4793 EAP-POTP February 2007
[66ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
B.3. Mutual Authentication without Session Resumption
B.3。 セッション再開のない互いの認証
In this case, the peer uses the token key identifier, in addition to the user identifier. The initial EAP-Identity exchange may also provide user information, or may be restricted to only general domain information. Pepper is not used, but will be used in a subsequent session since the server provides the peer with an encrypted pepper in its Confirm TLV. Absence of the Crypto Algorithm TLV indicates use of default cryptographic algorithms.
この場合、同輩はユーザ識別子に加えたトークンの主要な識別子を使用します。 初期のEAP-アイデンティティ交換は、また、ユーザー情報を提供するか、または一般的なドメイン情報だけに制限されるかもしれません。 コショウは、使用されていませんが、サーバがConfirm TLVの暗号化されたコショウを同輩に提供するので、その後のセッションのときに使用されるでしょう。 Crypto Algorithm TLVの不在はデフォルト暗号アルゴリズムの使用を示します。
Peer EAP server
同輩EAPサーバ
<- EAP-Request
Type=Identity
<EAP-要求タイプはアイデンティティと等しいです。
EAP-Response -> Type=Identity
EAP-応答->は=アイデンティティをタイプします。
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Version TLV:
Highest=0,Lowest=0
バージョンTLV: 最も高い=0、最も低い=0
Server-Info TLV:
N=0
Session Identifier=V1
Server Identifier=V2
Nonce=V3
サーバインフォメーションTLV: N=0セッション識別子=V1サーバ識別子=V2一回だけ=V3
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=0
Iteration Count=V4
OTP TLV: P=1、C=0、N=0、T=0、E=0、R=0コショウ長さ=0繰り返しは=V4を数えます。
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Version TLV: Highest=0
バージョンTLV: 最も高い=0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=0 Iteration Count=V4 Authentication Data=V5
OTP TLV: P=1、C=0、N=0、T=0、E=0、R=0コショウ長さ=0繰り返しは=V4認証データ=V5を数えます。
Nystroem Informational [Page 67] RFC 4793 EAP-POTP February 2007
[67ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
User Identifier TLV: User Identifier=V6
ユーザ識別子TLV: ユーザ識別子=V6
Token Key Identifier TLV: Token Key Identifier=V7
トークンの主要な識別子TLV: トークンの主要な識別子=V7
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Confirm TLV:
C=0
Authentication Data=V8
Pepper Identifier=V9
Encrypted Pepper=V10
TLVを確認してください: 0認証データ=V8コショウ識別子=C=V9はコショウ=V10を暗号化しました。
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Confirm TLV: (no data)
TLVを確認してください: (データがありません)
<- EAP-Success
<EAP-成功
Nystroem Informational [Page 68] RFC 4793 EAP-POTP February 2007
[68ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
B.4. Mutual Authentication with Transfer of Pepper
B.4。 コショウの転送との互いの認証
The difference between this example and the previous one is that the peer makes use of an existing pepper in the PBKDF2 computation. The EAP server provides a new pepper to the peer in the Confirm TLV. Note that the peer had not been able to use a pepper in the response calculation unless it had found the existing pepper, since the server specified a maximum (new) pepper length of zero.
この例と前のものの違いは同輩がPBKDF2計算で既存のコショウを利用するということです。 EAPサーバは新しいコショウをConfirm TLVの同輩に提供します。 既存のコショウを見つけていなかったなら同輩が応答計算にコショウを使用できなかったことに注意してください、サーバが最大(新しい)のコショウの長さのゼロを指定したので。
Peer EAP server
同輩EAPサーバ
<- EAP-Request
Type=Identity
<EAP-要求タイプはアイデンティティと等しいです。
EAP-Response -> Type=Identity
EAP-応答->は=アイデンティティをタイプします。
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Version TLV:
Highest=0,Lowest=0
バージョンTLV: 最も高い=0、最も低い=0
Server-Info TLV:
N=0
Session Identifier=V1
Server Identifier=V2
Nonce=V3
サーバインフォメーションTLV: N=0セッション識別子=V1サーバ識別子=V2一回だけ=V3
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=0
Iteration Count=V4
OTP TLV: P=1、C=0、N=0、T=0、E=0、R=0コショウ長さ=0繰り返しは=V4を数えます。
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Version TLV: Highest=0
バージョンTLV: 最も高い=0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V5 Iteration Count=V6 Authentication Data=V7 (includes a pepper identifier)
OTP TLV: P=1、C=0、N=0、T=0、E=0、V5R=0コショウの長さ=繰り返しは=V6認証データ=V7を数えます。(コショウ識別子を含んでいます)
Nystroem Informational [Page 69] RFC 4793 EAP-POTP February 2007
[69ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
User Identifier TLV: User Identifier=V8
ユーザ識別子TLV: ユーザ識別子=V8
Token Key Identifier TLV: Token Key Identifier=V9
トークンの主要な識別子TLV: トークンの主要な識別子=V9
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Confirm TLV:
C=0
Authentication Data=V10
Pepper Identifier=V11
Encrypted Pepper=V12
TLVを確認してください: 0認証データ=V10コショウ識別子=C=V11はコショウ=V12を暗号化しました。
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Confirm TLV: (no data)
TLVを確認してください: (データがありません)
<- EAP-Success
B.5. Failed Mutual Authentication
<EAP-成功B.5。 失敗した互いの認証
This example differs from the previous one in that the peer is not able to authenticate the server. Therefore, it sends an empty EAP- Response of type POTP-X, which the EAP server acknowledges by responding with an EAP-Failure. Pepper is not used.
この例は同輩がサーバを認証できないという点において前のものと異なっています。したがって、それはタイプPOTP-Xの空のEAP応答を送ります。(EAPサーバは、EAP-失敗で応じることによって、POTP-Xを承認します)。 コショウは使用されていません。
Peer EAP server
同輩EAPサーバ
<- EAP-Request
Type=Identity
<EAP-要求タイプはアイデンティティと等しいです。
EAP-Response -> Type=Identity
EAP-応答->は=アイデンティティをタイプします。
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Version TLV:
Highest=0,Lowest=0
バージョンTLV: 最も高い=0、最も低い=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
OTP TLV: P=1、C=0、N=0、T=0、E=0、V1R=0コショウの長さ=繰り返しは=V2を数えます。
Nystroem Informational [Page 70] RFC 4793 EAP-POTP February 2007
[70ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
Server-Info TLV:
N=0
Session Identifier=V3
Server Identifier=V4
Nonce=V5
サーバインフォメーションTLV: N=0セッション識別子=V3サーバ識別子=V4一回だけ=V5
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Version TLV: Highest=0
バージョンTLV: 最も高い=0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V1 Iteration Count=V2 Authentication Data=V6
OTP TLV: P=1、C=0、N=0、T=0、E=0、V1R=0コショウの長さ=繰り返しは=V2認証データ=V6を数えます。
User Identifier TLV: User Identifier=V7
ユーザ識別子TLV: ユーザ識別子=V7
Token Key Identifier TLV: Token Key Identifier=V8
トークンの主要な識別子TLV: トークンの主要な識別子=V8
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Confirm TLV:
C=0
Authentication Data=V9
TLVを確認してください: Cは0認証データ=V9と等しいです。
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
(no data)
(データがありません)
<- EAP-Failure
<のEAP-故障
B.6. Session Resumption
B.6。 セッション再開
This example illustrates successful session resumption.
この例はうまくいっているセッション再開を例証します。
Peer EAP server
同輩EAPサーバ
<- EAP-Request
Type=Identity
<EAP-要求タイプはアイデンティティと等しいです。
Nystroem Informational [Page 71] RFC 4793 EAP-POTP February 2007
[71ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
EAP-Response -> Type=Identity
EAP-応答->は=アイデンティティをタイプします。
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Version TLV:
Highest=0,Lowest=0
バージョンTLV: 最も高い=0、最も低い=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
OTP TLV: P=1、C=0、N=0、T=0、E=0、V1R=0コショウの長さ=繰り返しは=V2を数えます。
Server-Info TLV:
N=0
Session Identifier=V3
Server Identifier=V4
Nonce=V5
サーバインフォメーションTLV: N=0セッション識別子=V3サーバ識別子=V4一回だけ=V5
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Version TLV: Highest=0
バージョンTLV: 最も高い=0
Resume TLV: Session Identifier=V6 (indicating earlier, protected mode, session) Authentication Data=V7
TLVを再開してください: セッションIdentifier=V6(より早いのを示すプロテクトモード、セッション)認証Data=V7
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Confirm TLV:
C=0
Authentication Data=V8
TLVを確認してください: Cは0認証データ=V8と等しいです。
EAP-Response -> Type=OTP-X Confirm TLV: (no data)
EAP-応答->タイプ=OTP-XはTLVを確認します: (データがありません)
<- EAP-Success
<EAP-成功
Nystroem Informational [Page 72] RFC 4793 EAP-POTP February 2007
[72ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
B.7. Failed Session Resumption
B.7。 失敗したセッション再開
This example illustrates a failed session resumption, followed by a complete mutual authentication. The user is identified through the User Identifier TLV. The client is able to reuse an older pepper. The server sends a new pepper for subsequent use in its Confirm TLV. The server suggests some non-default cryptographic algorithms, but the client only supports the default ones.
この例は失敗したセッション再開を例証します、続いて、完全な互いの認証を例証します。 ユーザはUser Identifier TLVを通して特定されます。 クライアントは、より古いコショウを再利用できます。 サーバはConfirm TLVにおけるその後の使用のために新しいコショウを送ります。 サーバはいくつかの非デフォルト暗号アルゴリズムを示しますが、クライアントはデフォルトにものをサポートするだけです。
Peer EAP server
同輩EAPサーバ
<- EAP-Request
Type=Identity
<EAP-要求タイプはアイデンティティと等しいです。
EAP-Response -> Type=Identity
EAP-応答->は=アイデンティティをタイプします。
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Version TLV:
Highest=0,Lowest=0
バージョンTLV: 最も高い=0、最も低い=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
OTP TLV: P=1、C=0、N=0、T=0、E=0、V1R=0コショウの長さ=繰り返しは=V2を数えます。
Server-Info TLV:
N=0
Session Identifier=V3
Server Identifier=V4
Nonce=V5
サーバインフォメーションTLV: N=0セッション識別子=V3サーバ識別子=V4一回だけ=V5
Crypto Algorithm TLV:
Hash Alg. Length=V6
Hash Algorithms=V7
Encr. Alg. Length=V8
Encr. Algorithms=V9
MAC Alg. Length=V10
MAC Algorithms=V11
暗号アルゴリズムTLV: Algを論じ尽くしてください。 V6ハッシュ長さ=アルゴリズムはV7 Encrと等しいです。 Alg。 長さはV8 Encrと等しいです。 アルゴリズムはV9 MAC Algと等しいです。 V10 MAC長さ=アルゴリズムはV11と等しいです。
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Version TLV: Highest=0
バージョンTLV: 最も高い=0
Nystroem Informational [Page 73] RFC 4793 EAP-POTP February 2007
[73ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
Resume TLV: Session Identifier=V12 (indicating earlier session) Authentication Data=V13
TLVを再開してください: セッションIdentifier=V12(以前のセッションを示す)認証Data=V13
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V14
Iteration Count=V15
OTP TLV: P=1、C=0、N=0、T=0、E=0、V14R=0コショウの長さ=繰り返しは=V15を数えます。
Server-Info TLV:
N=1 (no resumption)
Session Identifier=V3
Server Identifier=V4
Nonce=V16
サーバインフォメーションTLV: N=1(再開がない)セッションIdentifier=V3 Server Identifier=V4 Nonce=V16
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
OTP TLV: P=1,C=0,N=1,T=1,E=0,R=0 Pepper Length=V17 Iteration Count=V18 Authentication Data=V19 (with pepper identifier)
OTP TLV: P=1、C=0、N=1、T=1、E=0、V17R=0コショウの長さ=繰り返しは=V18認証データ=V19を数えます。(コショウ識別子がある)
User Identifier TLV: User Identifier=V20
ユーザ識別子TLV: ユーザ識別子=V20
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Confirm TLV:
C=0
Authentication Data=V21
Pepper Identifier=V22
Encrypted Pepper=V23
EAP-Response ->
Type=OTP-X
TLVを確認してください: V21コショウ識別子=V22暗号化されたコショウ=V23 EAP0つのC=認証データ=応答->は=OTP-Xをタイプします。
Confirm TLV: (no data)
TLVを確認してください: (データがありません)
<- EAP-Success
<EAP-成功
Nystroem Informational [Page 74] RFC 4793 EAP-POTP February 2007
[74ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
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 TLVをEAPサーバに含むEAP応答を送ります。生きているKeep TLVを同輩に含んで戻していて、EAPサーバは、EAP-要求を送ることによって、反応します。 Confirm TLV交換の後に交換されたすべてのTLVsがProtected TLVで包装されることに注意してください。 Crypto Algorithm TLVの不在はデフォルト暗号アルゴリズムの使用を示します。
Peer EAP server
同輩EAPサーバ
<- EAP-Request
Type=Identity
<EAP-要求タイプはアイデンティティと等しいです。
EAP-Response -> Type=Identity
EAP-応答->は=アイデンティティをタイプします。
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Version TLV:
Highest=0,Lowest=0
バージョンTLV: 最も高い=0、最も低い=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
OTP TLV: P=1、C=0、N=0、T=0、E=0、V1R=0コショウの長さ=繰り返しは=V2を数えます。
Server-Info TLV:
N=0
Session Identifier=V3
Server Identifier=V4
Nonce=V5
サーバインフォメーションTLV: N=0セッション識別子=V3サーバ識別子=V4一回だけ=V5
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Version TLV: Highest=0
バージョンTLV: 最も高い=0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V6
OTP TLV: P=1、C=0、N=0、T=0、E=0、R=0コショウの長さはV6と等しいです。
Nystroem Informational [Page 75] RFC 4793 EAP-POTP February 2007
[75ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
Iteration Count=V7 Authentication Data=V8 (with pepper identifier)
繰り返しカウント=V7認証データはV8と等しいです。(コショウ識別子がある)
User Identifier TLV: User Identifier=V9
ユーザ識別子TLV: ユーザ識別子=V9
Token Key Identifier TLV: Token Key Identifier=V10
トークンの主要な識別子TLV: トークンの主要な識別子=V10
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Confirm TLV:
C=1
Authentication Data=V11
TLVを確認してください: Cは1認証データ=V11と等しいです。
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Confirm TLV: (no data)
TLVを確認してください: (データがありません)
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Protected TLV:
MAC=V12
IV=V13
Encrypted TLVs=V14
(Contains:
New PIN TLV:
Q=0,A=1
PIN=V15
Min. PIN Length=6)
保護されたTLV: MAC=V12IV=V13はTLVs=V14を暗号化しました。(: 新しい暗証番号TLV: Q=0、暗証番号の長さが6と等しいA=1暗証番号=V15分を含んでいます)
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Protected TLV: MAC=V16 IV=V17 Encrypted TLVs=V18 (Contains: Keep-Alive TLV: (no data))
保護されたTLV: MAC=V16IV=V17はTLVs=V18を暗号化しました。(: 生きている生活費TLV: (データがありません)を含んでいます)
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Nystroem Informational [Page 76] RFC 4793 EAP-POTP February 2007
[76ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
Protected TLV:
MAC=V19
IV=V20
Encrypted TLVs=V21
(Contains:
Keep-Alive TLV:
(no data))
保護されたTLV: MAC=V19IV=V20はTLVs=V21を暗号化しました。(: 生きている生活費TLV: (データがありません)を含んでいます)
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Protected TLV: MAC=V22 IV=V23 Encrypted TLVs=V24 (Contains: New PIN TLV: Q=0,A=0 PIN=V25)
保護されたTLV: MAC=V22IV=V23はTLVs=V24を暗号化しました。(: 新しい暗証番号TLV: Q=0、A=0暗証番号=V25を含んでいます)
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Protected TLV:
MAC=V26
IV=V27
Encrypted TLVs=V28
(Contains:
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2)
保護されたTLV: MAC=V26IV=V27はTLVs=V28を暗号化しました。(V1繰り返しカウント=: OTP TLV: P=1、C=0、N=0、T=0、E=0、R=0コショウの長さ=V2を含んでいます)
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Protected TLV MAC=V29 IV=V30 Encrypted TLVs=V31 (Contains: OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V6 Iteration Count=V7 Authentication Data=V31)
保護されたTLV MAC=V29IV=V30はTLVs=V31を暗号化しました。(: OTP TLV: P=1、C=0、N=0、T=0、E=0、V6繰り返しカウント=V7認証データ=R=0コショウの長さ=V31を含んでいます)
Nystroem Informational [Page 77] RFC 4793 EAP-POTP February 2007
[77ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Protected TLV
MAC=V32
IV=V33
Encrypted TLVs=V34
(Contains:
Confirm TLV:
C=0
Authentication Data=V35)
保護されたTLV MAC=V32IV=V33はTLVs=V34を暗号化しました。(含んでいます:、確認、0認証データ=TLV: C=V35)
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Protected TLV MAC=V36 IV=V37 Encrypted TLVs=V38 (Contains: Confirm TLV: (no data))
保護されたTLV MAC=V36IV=V37はTLVs=V38を暗号化しました。(含んでいます:、TLV: (データがありません)を確認してください。
<- EAP-Success
<EAP-成功
B.9. Use of Next OTP Mode
B.9。 次のOTPモードの使用
In this example, the peer is requested to provide a second OTP to the EAP server.
この例では、同輩が第2のOTPをEAPサーバに提供するよう要求されています。
Peer EAP server
同輩EAPサーバ
<- EAP-Request
Type=Identity
<EAP-要求タイプはアイデンティティと等しいです。
EAP-Response -> Type=Identity
EAP-応答->は=アイデンティティをタイプします。
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Version TLV:
Highest=0,Lowest=0
バージョンTLV: 最も高い=0、最も低い=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
OTP TLV: P=1、C=0、N=0、T=0、E=0、V1R=0コショウの長さ=繰り返しは=V2を数えます。
Nystroem Informational [Page 78] RFC 4793 EAP-POTP February 2007
[78ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
Server-Info TLV:
N=0
Session Identifier=V3
Server Identifier=V4
Nonce=V5
サーバインフォメーションTLV: N=0セッション識別子=V3サーバ識別子=V4一回だけ=V5
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Version TLV: Highest=0
バージョンTLV: 最も高い=0
OTP TLV: P=1,C=0,N=0,T=0,E=0,R=0 Pepper Length=V6 Iteration Count=V7 Authentication Data=V8
OTP TLV: P=1、C=0、N=0、T=0、E=0、V6R=0コショウの長さ=繰り返しは=V7認証データ=V8を数えます。
User Identifier TLV: User Identifier=V9
ユーザ識別子TLV: ユーザ識別子=V9
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
OTP TLV:
P=1,C=0,N=1,T=1,E=0,R=0
Pepper Length=V1
Iteration Count=V2
OTP TLV: P=1、C=0、N=1、T=1、E=0、V1R=0コショウの長さ=繰り返しは=V2を数えます。
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
OTP TLV: P=1,C=0,N=1,T=1,E=0,R=0 Pepper Length=V6 Iteration Count=V7 Authentication Data=V10
OTP TLV: P=1、C=0、N=1、T=1、E=0、V6R=0コショウの長さ=繰り返しは=V7認証データ=V10を数えます。
<- EAP-Request
Type=OTP-X
<EAP-要求タイプはOTP-Xと等しいです。
Confirm TLV:
C=0
Authentication Data=V11
TLVを確認してください: Cは0認証データ=V11と等しいです。
EAP-Response -> Type=OTP-X
EAP-応答->は=OTP-Xをタイプします。
Nystroem Informational [Page 79] RFC 4793 EAP-POTP February 2007
[79ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
Confirm TLV: (no data)
TLVを確認してください: (データがありません)
<- EAP-Success
<EAP-成功
Appendix C. Use of the MPPE-Send/Receive-Key RADIUS Attributes
MPPE発信している/キーを受信している半径属性の付録C.使用
C.1. Introduction
C.1。 序論
This section describes how to populate the MPPE-Send-Key and the MPPE-Receive-Key RADIUS attributes defined in [19], using an MSK established in EAP-POTP.
このセクションはMPPEがキーを送って、属性が[19]で定義したMPPEがキーを受けているRADIUSに居住する方法を説明します、EAP-POTPに設立されたMSKを使用して。
C.2. MPPE Key Attribute Population
C.2。 MPPEの主要な属性人口
Once the EAP-POTP MSK has been generated, it is used as follows to populate the MPPE-Send-Key and the MPPE-Receive-Key attributes:
EAP-POTP MSKがいったん生成されると、それはMPPEがキーを送って、MPPEがキーを受けている属性に居住するのに以下の通り使用されます:
Use the initial 32 octets of the MSK as the value for the "Key" sub- field in the plaintext "String" field of the MPPE-Send-Key attribute, and use the final 32 octets of the MSK as the "Key" sub-field in the plaintext "String" field of the MPPE-Receive-Key attribute (Note: "Send" and "Receive" here refer to the Authenticator; for the peer, they are reversed).
MPPEがキーを送っている属性の平文「ストリング」分野の「主要な」サブ分野に値としてMSKの初期の32の八重奏を使用してください、そして、「主要な」サブ分野としてMPPEがキーを受けている属性の平文「ストリング」分野でMSKの最終的な32の八重奏を使用してください(注意: 「発信してください」とここの「受信してください」はAuthenticatorを示します; 同輩に関して、それらは逆にされます)。
Appendix D. Key Strength Considerations
付録のD.の主要な強さ問題
D.1. Introduction
D.1。 序論
As described in Section 6, the strength of keys generated in EAP-POTP protected mode depends on a number of factors. This appendix provides examples of actual key strengths achieved under various assumptions.
セクション6で説明されるように、EAP-POTPプロテクトモードで生成されたキーの強さは多くの要因に依存します。 この付録は様々な仮定で達成された実際のキーの強さに関する例を提供します。
It should be noted that, while some of the examples indicate that the strength of generated keys is relatively weak, the strength applies only to those EAP-POTP sessions between a peer and an EAP server that do not share a pepper. Once a pepper, provided by an EAP server to a peer, has been established, future sessions using this pepper will provide full-strength keys.
例のいくつかが、発生しているキーの強さが比較的弱いのを示しますが、強さがコショウを共有しない同輩とEAPサーバの間でそれらのEAP-POTPセッションだけに適用されることに注意されるべきです。 EAPサーバによって同輩に提供されたコショウがいったん設立されると、このコショウを使用する今後のセッションが定員キーを提供するでしょう。
Nystroem Informational [Page 80] RFC 4793 EAP-POTP February 2007
[80ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
D.2. Example 1: 6-Digit One-Time Passwords
D.2。 例1: 6ケタのワンタイムパスワード
In this example we assume the following:
この例では、私たちは以下を仮定します:
OTPs are six decimal digits long;
長い間、OTPsは6つの10進数字です。
4-digit PINs are added to generated OTPs; and
4ケタの暗証番号は発生しているOTPsに加えられます。 そして
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つの方法は繰り返しが100万に用意ができているPBKDF2で重要にすることです。
The effective key strength then becomes roughly:
次に、有効な主要な強さはおよそなります:
log_2(10**6) + log_2(10**4) + log_2(2**10) = 43 bits
_2(10**6)+ログ_2(10**4)を43+ ログ_2(2**10)=ビット登録してください。
The above assumes that the entropy of the underlying shared secret is >43 bits and that there are no other weaknesses in the OTP algorithm.
上記は基本的な共有秘密キーのエントロピーが43ビット>であり、OTPアルゴリズムには他の弱点が全くないと仮定します。
D.3. Example 2: 8-Digit One-Time Passwords
D.3。 例2: 8ケタのワンタイムパスワード
In this example we assume the following:
この例では、私たちは以下を仮定します:
OTPs are eight decimal digits long;
長い間、OTPsは8つの10進数字です。
4-character alphanumeric PINs are added to generated OTPs; and
英数字の4キャラクタの暗証番号は発生しているOTPsに加えられます。 そして
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
_2(10**8)+ログ_2(26**4)を55+ ログ_2(2**10)=ビット登録してください。
The above assumes that the entropy of the underlying shared secret is >55 bits and that there are no other weaknesses in the OTP algorithm.
上記は基本的な共有秘密キーのエントロピーが55ビット>であり、OTPアルゴリズムには他の弱点が全くないと仮定します。
Author's Address
作者のアドレス
Magnus Nystroem RSA Security
マグヌスNystroem RSA Security
EMail: magnus@rsa.com
メール: magnus@rsa.com
Nystroem Informational [Page 81] RFC 4793 EAP-POTP February 2007
[81ページ]RFC4793EAP-POTP2007年2月の情報のNystroem
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Nystroem Informational [Page 82]
Nystroem情報です。[82ページ]
一覧
スポンサーリンク
