Network Working Group T. Clancy
Request for Comments: 4746 LTS
Category: Informational W. Arbaugh
UMD
November 2006
Extensible Authentication Protocol (EAP)
Password Authenticated Exchange
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 (2006).
著作権（C）IETFトラスト（2006）。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document defines an Extensible Authentication Protocol (EAP) method called EAP-PAX (Password Authenticated eXchange). This method is a lightweight shared-key authentication protocol with optional support for key provisioning, key management, identity protection, and authenticated data exchange.
この文書では、EAP-PAX（パスワード認証取引所）と呼ばれる拡張認証プロトコル（EAP）メソッドを定義します。この方法は、キーのプロビジョニング、キー管理、アイデンティティ保護、および認証されたデータ交換のためのオプションをサポートする軽量共有鍵認証プロトコルです。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Language Requirements ......................................3
1.2. Terminology ................................................3
2. Overview ........................................................5
2.1. PAX_STD Protocol ...........................................6
2.2. PAX_SEC Protocol ...........................................7
2.3. Authenticated Data Exchange ................................9
2.4. Key Derivation ............................................10
2.5. Verification Requirements .................................11
2.6. PAX Key Derivation Function ...............................12
3. Protocol Specification .........................................13
3.1. Header Specification ......................................13
3.1.1. Op-Code ............................................13
3.1.2. Flags ..............................................14
3.1.3. MAC ID .............................................14
3.1.4. DH Group ID ........................................14
3.1.5. Public Key ID ......................................15
3.1.6. Mandatory to Implement .............................15
3.2. Payload Formatting ........................................16
3.3. Authenticated Data Exchange (ADE) .........................18
3.4. Integrity Check Value (ICV) ...............................19
4. Security Considerations ........................................19
4.1. Server Certificates .......................................20
4.2. Server Security ...........................................20
4.3. EAP Security Claims .......................................21
4.3.1. Protected Ciphersuite Negotiation ..................21
4.3.2. Mutual Authentication ..............................21
4.3.3. Integrity Protection ...............................21
4.3.4. Replay Protection ..................................21
4.3.5. Confidentiality ....................................21
4.3.6. Key Derivation .....................................21
4.3.7. Key Strength .......................................22
4.3.8. Dictionary Attack Resistance .......................22
4.3.9. Fast Reconnect .....................................22
4.3.10. Session Independence ..............................22
4.3.11. Fragmentation .....................................23
4.3.12. Channel Binding ...................................23
4.3.13. Cryptographic Binding .............................23
4.3.14. Negotiation Attack Prevention .....................23
5. IANA Considerations ............................................23
6. Acknowledgments ................................................24
7. References .....................................................24
7.1. Normative References ......................................24
7.2. Informative References ....................................25
Appendix A. Key Generation from Passwords ........................ 27
Appendix B. Implementation Suggestions ........................... 27
B.1. WiFi Enterprise Network ................................... 27
B.2. Mobile Phone Network ...................................... 28
EAP-PAX (Password Authenticated eXchange) is an Extensible Authentication Protocol (EAP) method [RFC3748] designed for authentication using a shared key. It makes use of two separate subprotocols, PAX_STD and PAX_SEC. PAX_STD is a simple, lightweight protocol for mutual authentication using a shared key, supporting Authenticated Data Exchange (ADE). PAX_SEC complements PAX_STD by providing support for shared-key provisioning and identity protection using a server-side public key.
EAP-PAX（パスワード認証交換は）共有鍵を用いて認証のために設計された拡張認証プロトコル（EAP）メソッド[RFC3748]です。これは、2つの別々のサブプロトコル、PAX_STDとPAX_SECを使用しています。 PAX_STDは、認証されたデータ交換（ADE）をサポートする共有キーを使用して、相互認証のためのシンプルで軽量なプロトコルです。 PAX_SECは、サーバ側の公開鍵を使用して共有キーのプロビジョニングとアイデンティティ保護のためのサポートを提供することにより、PAX_STDを補完します。
The idea motivating EAP-PAX is a desire for device authentication bootstrapped by a simple Personal Identification Number (PIN). If a weak key is used or a expiration period has elapsed, the authentication server forces a key update. Rather than using a symmetric key exchange, the client and server perform a Diffie-Hellman key exchange, which provides forward secrecy.
EAP-PAXの動機アイデアは、単純な個人識別番号（PIN）によるブートストラップデバイス認証のための欲求です。弱い鍵が使用されているか、有効期限が経過した場合、認証サーバは、鍵の更新を強制します。むしろ、対称鍵交換を使用するよりも、クライアントとサーバは、前進の秘密保持を提供したDiffie-Hellman鍵交換を行います。
Since implementing a Public Key Infrastructure (PKI) can be cumbersome, PAX_SEC defines multiple client security policies, selectable based on one's threat model. In the weakest mode, PAX_SEC allows the use of raw public keys completely eliminating the need for a PKI. In the strongest mode, PAX_SEC requires that EAP servers use certificates signed by a trusted Certification Authority (CA). In the weaker modes, during provisioning PAX_SEC is vulnerable to a man-in-the-middle dictionary attack. In the strongest mode, EAP-PAX is provably secure under the Random Oracle model.
煩雑になる可能性があり、公開鍵インフラストラクチャ（PKI）を導入して以来、PAX_SEC一の脅威モデルに基づいて、複数のクライアントのセキュリティポリシー、選択を定義します。最も弱いモードでは、PAX_SECは、生の公開鍵の使用が完全にPKIの必要性を排除することができます。最強モードでは、PAX_SECは、EAPサーバは、信頼できる認証局（CA）によって署名された証明書を使用する必要があります。弱いモードでは、プロビジョニング中にPAX_SECはなman-in-the-middle辞書攻撃に対して脆弱です。最強モードでは、EAP-PAXは、ランダムオラクルモデルの下で証明可能安全です。
EAP-PAX supports the generation of strong key material; mutual authentication; resistance to desynchronization, dictionary, and man-in-the-middle attacks; ciphersuite extensibility with protected negotiation; identity protection; and the authenticated exchange of data, useful for implementing channel binding. These features satisfy the EAP method requirements for wireless LANs [RFC4017], making EAP-PAX ideal for wireless environments such as IEEE 802.11 [IEEE.80211].
EAP-PAXは、強力なキーマテリアルの生成をサポートしています。相互認証;非同期化、辞書、およびman-in-the-middle攻撃への耐性;保護された交渉での暗号スイートの拡張。アイデンティティ保護。そして、データのやり取り、認証、結合チャネルを実装するために有用。これらの機能は、IEEE 802.11 [IEEE.80211]などの無線環境のためにEAP-PAXの理想を行う、無線LAN [RFC4017]のためのEAPメソッド要件を満たします。
In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This section describes the various variables and functions used in the EAP-PAX protocol. They will be referenced frequently in later sections.
このセクションでは、EAP-PAXプロトコルで使用される各種変数や機能を説明しています。彼らは、後のセクションで頻繁に参照されます。
Variables:
変数：
CID User-supplied client ID, specified as a Network Access Identifier (NAI) [RFC4282], restricted to 65535 octets
65535個のオクテットに制限されたネットワークアクセス識別子（NAI）[RFC4282]として指定されたCIDユーザー指定のクライアントID、
g public Diffie-Hellman generator, typically the integer 2 [RFC2631]
G公共のDiffie-Hellmanジェネレータ、典型的には整数2 [RFC2631]
M 128-bit random integer generated by the server
サーバによって生成されたM 128ビットのランダムな整数
N 128-bit random integer generated by the client
Nクライアントによって生成された128ビットのランダムな整数
X 256-bit random integer generated by the server
サーバによって生成されたX 256ビットのランダムな整数
Y 256-bit random integer generated by the client
クライアントによって生成されたY 256ビットのランダムな整数
Keys:
キー：
AK authentication key shared between the client and EAP server
AK認証キーは、クライアントとEAPサーバの間で共有しました
AK' new authentication key generated during a key update
AKの新しい認証キーは、キーの更新中に発生しました
CertPK EAP server's certificate containing public key PK
公開鍵PKを含むCertPK EAPサーバの証明書
CK Confirmation Key generated from the MK and used during authentication to prove knowledge of AK
CK確認キーMKから生成され、AKの知識を証明するために認証時に使用
EMSK Extended Master Session Key also generated from the MK and containing additional keying material
EMSKはMKから生成され、追加のキーイング材料を含むものマスターセッションキーを拡張します
IV Initialization Vector used to seed ciphers; exported to the authenticator
IV初期化ベクトルは、暗号をシードするために使用しました。オーセンティケータにエクスポート
MID Method ID used to construct the EAP Session ID and consequently name all the exported keys [IETF.KEY]
MIDメソッドIDは、EAPセッションIDを構築するために使用され、その結果、すべてのエクスポートされたキー[IETF.KEY]を名前
MK Master Key between the client and EAP server from which all other EAP method session keys are derived
他のすべてのEAPメソッドのセッションキーが導出されるクライアントとEAPサーバ間のMKマスターキー
MSK Master Session Key generated from the MK and exported by the EAP method to the authenticator
MSKマスターセッションキーMKから生成され、オーセンティケータにEAP方式によってエクスポート
PK EAP server's public key
PK EAPサーバの公開鍵
Operations:
オペレーション：
enc_X(Y) encryption of message Y with public key X
enc_X（Y）は、公開鍵XとYのメッセージの暗号化
MAC_X(Y) keyed message authentication code computed over message Y with symmetric key X
対称鍵XとメッセージYにわたって計算MAC_X（Y）キー付きメッセージ認証コード
PAX-KDF-W(X, Y, Z) PAX Key Derivation Function computed using secret X, identifier Y, and seed Z, and producing W octets of output
PAX-KDF-W（X、Y、Z）秘密Xを使用して計算PAX鍵導出関数、識別子Y、及び種子Z、及び出力のWオクテットの製造
|| string or binary data concatenation
||文字列またはバイナリデータの連結
The EAP framework [RFC3748] defines four basic steps that occur during the execution of an EAP conversation between client and server. The first phase, discovery, is handled by the underlying link-layer protocol. The authentication phase is defined here. The key distribution and secure association phases are handled differently depending on the underlying protocol, and are not discussed in this document.
EAPフレームワーク[RFC3748]は、クライアントとサーバとの間のEAP対話の実行中に発生する四つの基本的な手順を定義します。第一相、発見は、下層のリンク層プロトコルによって処理されます。認証フェーズはここで定義されています。鍵配布および安全な関連相は、基礎となるプロトコルに応じて異なる方法で処理され、この文書で説明していません。
+--------+ +--------+
| | EAP-Request/Identity | |
| CLIENT |<------------------------------------| SERVER |
| | | |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-PAX (STD or SEC) | |
| |<----------------------------------->| |
| | ... ... | |
| |<----------------------------------->| |
| | | |
| | EAP-Success or EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 1: EAP-PAX Packet Exchanges
図1：EAP-PAXパケット交換
There are two distinct subprotocols that can be executed. The first, PAX_STD, is used during typical authentications. The second, PAX_SEC, provides more secure features such as key provisioning and identity protection.
実行可能な2つの異なるサブプロトコルがあります。まず、PAX_STDは、一般的な認証中に使用されます。二、PAX_SECは、そのようなキーのプロビジョニングとアイデンティティ保護など、よりセキュアな機能を提供します。
PAX_STD and PAX_SEC have two modes of operation. When an AK update is being performed, the client and server exchange Diffie-Hellman exponents g^X and g^Y, which are computed modulo prime P or over an elliptic curve multiplicative group. When no update is being performed, and only session keys are being derived, X and Y are exchanged. Using Diffie-Hellman during the key update provides forward secrecy, and secure key derivation when a weak provisioned key is used.
PAX_STDとPAX_SECは、2つの動作モードがあります。 AK更新が行われているとき、クライアントとサーバ交換のDiffie-Hellmanはモジュロ素数Pを計算または楕円曲線乗法群上れるG ^ Xとg ^ Yを指数部。全く更新が実行されていない、とだけセッションキーが導出されているとき、XとYが交換されます。鍵更新時にディフィー - ヘルマンを使用する弱プロビジョニングキーが使用されている転送秘密、および安全な鍵導出を提供します。
The main deployment difference between PAX_STD and PAX_SEC is that PAX_SEC requires a server-side public key. More specifically, that means a private key known only to the server with corresponding public key being transmitted to the client during each PAX_SEC session. For every authentication, the client is required to compute computationally intensive public-key operations. PAX_STD, on the other hand, uses purely symmetric operations, other than a possible Diffie-Hellman exchange.
PAX_STDとPAX_SECの間の主な展開の差がPAX_SECは、サーバー側の公開鍵を必要とすることです。具体的には、それは各PAX_SECセッション中にクライアントに送信された公開鍵に対応して、サーバーにのみ知られている秘密鍵を意味します。すべての認証の場合、クライアントは、計算集約的な公開鍵操作を計算するために必要とされます。 PAX_STDは、他方、可能のDiffie-Hellman交換以外の純粋に対称的な動作を、使用します。
Each of the protocols is now defined.
プロトコルのそれぞれについて定義されます。
PAX_STD is a simple nonce-based authentication using the strong long-term key. The client and server each exchange 256 bits of random data, which is used to seed the PAX-KDF for generation of session keys. The randomly exchanged data in the protocol differs depending on whether a key update is being performed. If no key update is being performed, then let:
PAX_STDは強い長期キーを使用して、簡単なナンスベースの認証です。クライアントとサーバの各交換セッション鍵を生成するためにPAX-KDFを播種するために使用されるランダムデータの256ビット。プロトコルにおけるランダム交換されるデータは、鍵更新が行われているかに応じて異なります。何のキー更新が実行されていない場合は、してみましょう：
o A = X o B = Y o E = X || Y
又はA = B = X又はY又はE = X ||と
Thus, A and B are 256-bit values and E is their 512-bit concatenation. To provide forward secrecy and security, let the following be true when a key update is being performed:
したがって、A及びBは、256ビットの値であり、Eは、それらの512ビット連結です。前進の秘密保持とセキュリティを提供するために、鍵の更新が行われているときに次のことが真でみましょう：
o A = g^X o B = g^Y o E = g^(XY)
O = G ^ X B Y = G ^ E = G ^（XY）
Here A and B are Diffie-Hellman exponents whose length is determined by the Diffie-Hellman group size. The value A is data transmitted from the server to the client, and B is data transmitted from the client to the server. The value E is the entropy computed by each that is used in Section 2.4 to perform key derivation.
ここでAとBは、その長さのDiffie-Hellmanグループのサイズによって決定されるのDiffie-Hellman指数です。値Aは、サーバからクライアントに送信されるデータであり、Bは、クライアントからサーバへ送信されるデータです。値Eは、鍵導出を実行するために、セクション2.4で使用される各によって計算エントロピーです。
The full protocol is as follows:
次のように完全なプロトコルは以下のとおりです。
o PAX_STD-1 : client <- server : A o PAX_STD-2 : client -> server : B, CID, MAC_CK(A, B, CID), [optional ADE] o PAX_STD-3 : client <- server : MAC_CK(B, CID), [optional ADE] o PAX-ACK : client -> server : [optional ADE]
O PAX_STD-1：クライアント< - サーバー：PAX_STD-2 O A：クライアント - >サーバ：B、CID、MAC_CK（A、B、CID）、PAX_STD-3 O [オプションADE]：クライアント< - サーバ：MAC_CK（ PAX-ACK O B、CID）、[オプションADE]：クライアント - >サーバ：[オプションADE]
See Section 2.3 for more information on the ADE component, and Section 2.4 for the key derivation process, including derivation of CK.
CKの派生を含むADEコンポーネントの詳細については、セクション2.3、およびキー導出過程については、セクション2.4を参照してください。
PAX_SEC is the high-security protocol designed to provide identity protection and support for provisioning. PAX_SEC requires a server-side public key, and public-key operations for every authentication.
PAX_SECは、プロビジョニングのためのアイデンティティの保護とサポートを提供するように設計された高セキュリティプロトコルです。 PAX_SECは、すべての認証のためのサーバ側の公開鍵、および公開鍵の操作が必要です。
PAX_SEC can be performed with and without key update. Let A, B, and E be defined as in the previous section.
PAX_SECはで、キー更新せずに行うことができます。 A、B、及びEは、前のセクションのように定義することができます。
The exchanges for PAX_SEC are as follows:
次のようにPAX_SECのための交換は、次のとおりです。
o PAX_SEC-1 : client <- server : M, PK or CertPK o PAX_SEC-2 : client -> server : Enc_PK(M, N, CID) o PAX_SEC-3 : client <- server : A, MAC_N(A, CID) o PAX_SEC-4 : client -> server : B, MAC_CK(A, B, CID), [optional ADE] o PAX_SEC-5 : client <- server : MAC_CK(B, CID), [optional ADE] o PAX-ACK : client -> server : [optional ADE]
O PAX_SEC-1：クライアント< - サーバー：PAX_SEC-2 O M、PKまたはCertPK：クライアント - >サーバ：PAX_SEC-3 O Enc_PK（M、N、CID）：クライアント< - サーバ：A、MAC_N（A、CID ）PAX_SEC-4 O：クライアント - >サーバ：B、MAC_CK（A、B、CID）、[オプションADE] O PAX_SEC-5：クライアント< - サーバ：MAC_CK（B、CID）、[オプションADE] O PAX- ACK：クライアント - >サーバー：[オプションADE]
See Section 2.3 for more information on the ADE component, and Section 2.4 for the key derivation process, including derivation of CK.
CKの派生を含むADEコンポーネントの詳細については、セクション2.3、およびキー導出過程については、セクション2.4を参照してください。
Use of CertPK is optional in PAX_SEC; however, careful consideration should be given before omitting the CertPK. The following table describes the risks involved when using PAX_SEC without a certificate.
CertPKの使用はPAX_SECにオプションです。しかし、慎重な検討がCertPKを省略する前に与えられるべきです。次の表は、証明書なしPAX_SECを使用するときに伴うリスクについて説明します。
Certificate | Provisioning | Identity
Mode | | Protection
==================+=====================+======================
No Certificate | MiTM offline | ID reveal attack
| dictionary attack |
------------------+---------------------+---------------------
Self-Signed | MiTM offline | ID reveal attack
Certificate | dictionary attack |
------------------+---------------------+---------------------
Certificate/PK | MiTM offline | ID reveal attack
Caching | dictionary attack | during first auth
------------------+---------------------+---------------------
CA-Signed | secure mutual | secure mutual
Certificate | authentication | authentication
Figure 2: Table of Different Security Modes
図2：異なるセキュリティモードの表
When using PAX_SEC to support provisioning with a weak key, use of a CA-signed certificate is RECOMMENDED. When not using a CA-signed certificate, the initial authentication is vulnerable to an offline man-in-the-middle (MiTM) dictionary attack.
弱いキーでプロビジョニングをサポートするためにPAX_SECを使用する場合、CA署名付き証明書の使用が推奨されます。 CA署名証明書を使用しない場合は、最初の認証は、オフラインのman-in-the-middle（MITM）辞書攻撃に対して脆弱です。
When using PAX_SEC to support identity protection, use of either a CA-signed certificate or key caching is RECOMMENDED. Caching involves a client recording the public key of the EAP server and verifying its consistency between sessions, similar to Secure SHell (SSH) Protocol [RFC4252]. Otherwise, an attacker can spoof an EAP server during a session and gain knowledge of a client's identity.
アイデンティティ保護をサポートするためにPAX_SECを使用する場合は、CA署名証明書またはキーのキャッシングのいずれかを使用することが推奨されます。キャッシングは、クライアントEAPサーバの公開鍵を記録し、シェル（SSH）プロトコル[RFC4252]を確保するために同様のセッション、間の整合性を検証することを含みます。そうしないと、攻撃者はセッション中にEAPサーバを偽装して、クライアントのアイデンティティの知識を得ることができます。
Whenever certificates are used, clients MUST validate that the certificate's extended key usage, KeyPurposeID, is either "eapOverPPP" or "eapOverLAN" [RFC3280][RFC4334]. If the underlying EAP transport protocol is known, then the client MUST differentiate between these values. For example, an IEEE 802.11 supplicant SHOULD require KeyPurposeID == eapOverLAN. By not distinguishing, a client could accept as valid an unauthorized server certificate.
証明書が使用されているときはいつでも、クライアントは証明書の拡張キー使用法、KeyPurposeIDは、いずれかの「eapOverPPP」または「eapOverLAN」[RFC3280] [RFC4334]であることを検証しなければなりません。基本的なEAPトランスポートプロトコルが知られている場合、クライアントはこれらの値を区別しなければなりません。例えば、IEEE 802.11サプリカントはKeyPurposeID == eapOverLANを要求すべきです。区別しないことにより、クライアントは有効なものとして、不正サーバ証明書を受け入れることができます。
When using EAP-PAX with Wireless LAN, clients SHOULD validate that the certificate's wlanSSID extension matches the SSID of the network to which it is currently authenticating.
無線LANでEAP-PAXを使用する場合、クライアントは、証明書のwlanSSID拡張子が現在認証されているネットワークのSSIDと一致することを検証する必要があります。
In order to facilitate discussion of packet validations, three client security policies for PAX_SEC are defined.
パケットの検証の議論を容易にするために、PAX_SECのための3つのクライアントのセキュリティポリシーが定義されています。
open Clients support both use of PK and CertPK. If CertPK is used, the client MUST validate the KeyPurposeID.
オープンクライアントは、PKとCertPKの両方の使用をサポートしています。 CertPKを使用する場合、クライアントはKeyPurposeIDを検証する必要があります。
caching Clients save PK for each EAP server the first time it encounters the server, and SHOULD NOT authenticate to EAP servers whose public key has been changed. If CertPK is used, the client MUST validate the KeyPurposeID.
キャッシュクライアントは、各EAPサーバは、サーバに遭遇した初めてのPKをセーブし、その公開鍵が変更されたEAPサーバへの認証をすべきではありません。 CertPKを使用する場合、クライアントはKeyPurposeIDを検証する必要があります。
strict In strict mode, clients require servers to present a valid certificate signed by a trusted CA. As with the other modes, the KeyPurposeID MUST be validated.
strictモードで厳しい、クライアントは信頼できるCAによって署名された有効な証明書を提示するサーバーが必要他のモードと同様に、KeyPurposeIDを検証する必要があります。
Servers SHOULD support the PAX_SEC mode of operation, and SHOULD support both the use of PK and CertPK with PAX_SEC. Clients MUST support PAX_SEC, and MUST be capable of accepting both raw public keys and certificates from the server. Local security policy will define which forms of key or certificate authentications are permissible. Default configurations SHOULD require a minimum of the caching security policy, and MAY require strict.
サーバーは操作のPAX_SECモードをサポートすべきである、とPAX_SECとのPKとCertPKの使用の両方をサポートする必要があります。クライアントはPAX_SECをサポートしなければならないし、サーバからの生公開鍵と証明書の両方を受け入れることができなければなりません。ローカルセキュリティポリシーは、鍵や証明書認証の形式が許容されるかを定義します。デフォルトの設定は、キャッシングのセキュリティポリシーの最小値を必要とすべきである、と厳格な必要な場合があります。
The ability to perform key management on the AK is built in to EAP-PAX through the use of AK'. However, key management of the server public key is beyond the scope of this document. If self-signed certificates are used, the deployers should be aware that expired certificates may be difficult to replace when the caching security mode is used.
AKに鍵管理を実行する機能を「AKを使用してEAP-PAXに内蔵されています。ただし、サーバーの公開鍵の鍵管理は、このドキュメントの範囲を超えています。自己署名証明書が使用されている場合、デプロイヤは、期限切れの証明書は、キャッシュセキュリティモードを使用する場合に置き換えることは困難であり得ることを認識すべきです。
See Section 4 for further discussion on security considerations.
セキュリティの考慮事項についてさらなる議論については、セクション4を参照してください。
Messages PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and PAX_ACK contain optional component ADE. This component is used to convey authenticated data between the client and server during the authentication.
メッセージPAX_STD-2、PAX_STD-3、PAX_SEC-4、PAX_SEC-5、及びPAX_ACKは任意成分のADEを含みます。このコンポーネントは、認証時に、クライアントとサーバの間で認証されたデータを伝達するために使用されます。
The Authenticated Data Exchanged (ADE) can be used in a variety of ways, including the implementation of channel bindings. Channel bindings allow link-layer network properties to be securely validated by the EAP client and server during the authentication session.
交換し認証されたデータ（ADE）は、チャネルバインディングの実装を含む様々な方法で使用することができます。チャネルバインディングは、リンク層ネットワークのプロパティがしっかり認証セッション中にEAPクライアントとサーバによって検証することができます。
It is important to note that ADE is not encrypted, so any data included will not be confidential. However, since these packets are all protected by the Integrity Check Value (ICV), authenticity is guaranteed.
ADEが暗号化されていないため、含まれるすべてのデータが機密ではないことに注意することが重要です。これらのパケットはすべて完全性により保護されているので、値（ICV）を確認し、信頼性が保証されています。
The ADE element consists of an arbitrary number of subelements, each with length and type specified. If the number and size of subelements is too large, packet fragmentation will be necessary. Vendor-specific options are supported. See Section 3.3.
ADE要素は、サブ要素、指定された長さおよびタイプを有するそれぞれの任意の数で構成されています。サブ要素の数とサイズが大きすぎる場合は、パケットの断片化が必要となります。ベンダー固有のオプションがサポートされています。 3.3節を参照してください。
Note that more than 1.5 round-trips may be necessary to execute a particular authenticated protocol within EAP-PAX. In this case, instead of sending an EAP-Success after receiving the PAX_ACK, the server can continue sending PAX_ACK messages with attached elements. The client responds to these PAX_ACK messages with PAX_ACK messages possibly containing more ADE elements. Such an execution could look something like the following:
以上1.5ラウンドトリップがEAP-PAX内の特定の認証プロトコルを実行する必要があるかもしれないことに留意されたいです。この場合は、代わりにPAX_ACKを受けた後にEAP-成功を送信すると、サーバーは接続要素とPAX_ACKメッセージを送り続けることができます。クライアントは、おそらくより多くのADE要素を含むPAX_ACKメッセージでこれらPAX_ACKメッセージに応答します。このような実行は、次のようになります：
+--------+ +--------+
| | PAX_STD-1 | |
| |<------------------------------------| |
| | PAX_STD-2(ADE[1]) | |
| |------------------------------------>| |
| | PAX_STD-3(ADE[2]) | |
| |<------------------------------------| |
| | PAX_ACK(ADE[3]) | |
| |------------------------------------>| |
| | PAX_ACK(ADE[4]) | |
| |<------------------------------------| |
| | | |
| | ... | |
| | | |
| | PAX_ACK(ADE[i]) | |
| |------------------------------------>| |
| | PAX_ACK(ADE[i+1]) | |
| |<------------------------------------| |
| | | |
| | ... | |
| | | |
| | EAP-Success or EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 3: Extended Diagram of EAP-PAX Packet Exchanges
図3：EAP-PAXパケット交換の拡張ダイアグラム
Keys are derived independently of which authentication mechanism was used. The process uses the entropy value E computed as described above. Session and authentication keys are computed as follows:
キーは、独立して使用した認証メカニズムの誘導されます。プロセスは、上記のように計算されたエントロピー値Eを使用します。次のようにセッションと認証キーが計算されます。
o AK' = PAX-KDF-16(AK, "Authentication Key", E) o MK = PAX-KDF-16(AK, "Master Key", E) o CK = PAX-KDF-16(MK, "Confirmation Key", E) o ICK = PAX-KDF-16(MK, "Integrity Check Key", E) o MID = PAX-KDF-16(MK, "Method ID", E) o MSK = PAX-KDF-64(MK, "Master Session Key", E) o EMSK = PAX-KDF-64(MK, "Extended Master Session Key", E) o IV = PAX-KDF-64(0x00^16, "Initialization Vector", E)
O AK」= PAX-KDF-16（AK、 "認証キー"、E）O MK = PAX-KDF-16（AK、 "マスターキー"、E）O CK = PAX-KDF-16（MK、「確認MSK = PAX-KDF-64 OメソッドID "E） "MID = PAX-KDF-16（MK、O、E）を" キー」、E）O ICK = PAX-KDF-16（MK、" 整合性がキーをチェック（MK、 "マスターセッションキー"、E）O EMSK = PAX-KDF-64（MK、 "拡張マスターセッションキー"、Eは）IV 0 = PAX-KDF-64（$ 00 ^ 16、 "初期化ベクトル"、E ）
The IV is computed using a 16-octet NULL key. The value of AK' is only used to replace AK if a key update is being performed. The EAP Method ID is represented in ASCII as 32 hexadecimal characters without any octet delimiters such as colons or dashes.
IVは、16オクテットのNULLキーを使用して計算されます。 AK」の値は唯一の鍵の更新が実行されている場合はAKを置き換えるために使用されます。 EAPメソッドIDは、コロンまたはダッシュなどの任意のオクテットの区切り文字なしの32進数文字としてASCIIで表されています。
The EAP Key Management Framework [IETF.KEY] recommends specification of key names and scope. The EAP-PAX Method-ID is the MID value computed as described above. The EAP peer name is the CID value exchanged in PAX_STD-2 and PAX_SEC-2. The EAP server name is an empty string.
EAP鍵管理フレームワーク[IETF.KEY]キーの名前と範囲の仕様を推奨しています。 EAP-PAX方法-IDは、上述したように計算されたMID値です。 EAPピア名PAX_STD-2及びPAX_SEC-2で交換CID値です。 EAPサーバ名が空の文字列です。
In order for EAP-PAX to be secure, MACs must be properly verified each step of the way. Any packet with an ICV (see Section 3.4) that fails validation must be silently discarded. After ICV validation, the following checks must be performed:
EAP-PAXは安全であるために、MACは適切な方法の各ステップを検証しなければなりません。検証は黙って廃棄しなければならない障害が発生したICVと任意のパケット（セクション3.4を参照してください）。 ICV検証した後、以下のチェックを実行する必要があります。
PAX_STD-2 The server MUST validate the included MAC, as it serves to authenticate the client to the server. If this validation fails, the server MUST send an EAP-Failure message.
それは、サーバーへのクライアントを認証するのに役立つようPAX_STD-2サーバは、含まれるMACを検証する必要があります。この検証が失敗した場合、サーバーは、EAP失敗メッセージを送らなければなりません。
PAX_STD-3 The client MUST validate the included MAC, as it serves to authenticate the server to the client. If this validation fails, the client MUST send an EAP-Failure message.
それはクライアントにサーバを認証するのに役立つようPAX_STD-3クライアントは、含まれるMACを検証する必要があります。この検証が失敗した場合、クライアントは、EAP失敗メッセージを送らなければなりません。
PAX_SEC-1 The client MUST validate PK or CertPK in a manner specified by its local security policy (see Section 2.2). If this validation fails, the client MUST send an EAP-Failure message.
PAX_SEC-1のローカルセキュリティポリシーで指定された方法で、PKやCertPKを検証しなければならないクライアント（2.2節を参照してください）。この検証が失敗した場合、クライアントは、EAP失敗メッセージを送らなければなりません。
PAX_SEC-2 The server MUST verify that the decrypted value of M matches the value transmitted in PAX_SEC-1. If this validation fails, the server MUST send an EAP-Failure message.
PAX_SEC-2サーバは、M個の復号化された値はPAX_SEC-1で送信された値と一致することを確認しなければなりません。この検証が失敗した場合、サーバーは、EAP失敗メッセージを送らなければなりません。
PAX_SEC-3 The client MUST validate the included MAC, as it serves to prevent replay attacks. If this validation fails, the client MUST send an EAP-Failure message.
それはリプレイ攻撃を防ぐのに役立つようPAX_SEC-3クライアントは、含まれるMACを検証する必要があります。この検証が失敗した場合、クライアントは、EAP失敗メッセージを送らなければなりません。
PAX_SEC-4 The server MUST validate the included MAC, as it serves to authenticate the client to the server. If this validation fails, the server MUST send an EAP-Failure message.
それは、サーバーへのクライアントを認証するのに役立つようPAX_SEC-4サーバーは、含まれるMACを検証する必要があります。この検証が失敗した場合、サーバーは、EAP失敗メッセージを送らなければなりません。
PAX_SEC-5 The client MUST validate the included MAC, as it serves to authenticate the server to the client. If this validation fails, the client MUST send an EAP-Failure message.
それはクライアントにサーバを認証するのに役立つようPAX_SEC-5クライアントは、含まれるMACを検証する必要があります。この検証が失敗した場合、クライアントは、EAP失敗メッセージを送らなければなりません。
PAX-ACK If PAX-ACK is received in response to a message fragment, the receiver continues the protocol execution. If PAX-ACK is received in response to PAX_STD-3 or PAX_SEC-5, then the server MUST send an EAP-Success message. This indicates a successful execution of PAX.
PAX-ACKメッセージフラグメントに応答して受信されるPAX-ACK場合、受信機はプロトコルの実行を継続します。 PAX-ACKがPAX_STD-3またはPAX_SEC-5に応答して受信された場合、サーバーは、EAP-Successメッセージを送らなければなりません。これはPAXの実行が成功を示しています。
The PAX-KDF is a secure key derivation function used to generate various keys from the provided entropy and shared key.
PAX-KDFを提供エントロピーと共有鍵からの各種キーを生成するために使用される安全な鍵導出関数です。
PAX-KDF-W(X, Y, Z)
PAX-KDF-W（X、Y、Z）
W length, in octets, of the desired output X secret key used to protect the computation Y public identifier for the key being derived Z exchanged entropy used to seed the KDF
Wの長さは、オクテット単位で、所望の出力のX秘密鍵はKDFを播種するために使用Z交換エントロピーを導出される鍵の計算Y公開識別子を保護するために使用します
Let's define some variables and functions:
のは、いくつかの変数と関数を定義してみましょう：
o M_i = MAC_X(Y || Z || i), where i is an 8-bit unsigned integer o L = ceiling(W/16) o F(A, B) = first A octets of binary data B
iがL O 8ビットの符号なし整数である= F（A、B）O天井（W / 16）第1の2値データBのオクテット= O M_I = MAC_X（Y || Z || I）、
We define PAX-KDF-W(X, Y, Z) = F(W, M_1 || M_2 || ... || M_L).
我々は、PAX-KDF-W（X、Y、Z）= Fを（W、M_1 || M_2 || ... || M_L）を定義します。
Consequently for the two values of W used in this document, we have:
結果的にこの文書で使用さWの二つの値のために、我々は持っています：
o PAX-KDF-16(X, Y, Z) = MAC_X(Y || Z || 0x01) o PAX-KDF-64(X, Y, Z) = MAC_X(Y || Z || 0x01) || MAC_X(Y || Z || 0x02) || MAC_X(Y || Z || 0x03) || MAC_X(Y || Z || 0x04)
O PAX-KDF-16（X、Y、Z）= MAC_X（Y || Z || 0x01の）PAX-KDF-64（X、Y、Z）= MAC_X O（Y || Z || 0x01の）|| MAC_X（Y || Z || 0x02の）|| MAC_X（Y || Z || 0x03の）|| MAC_X（Y || Z || 0x04の）
The MAC used in the PRF is extensible and is the same MAC used in the rest of the protocol. It is specified in the EAP-PAX header.
PRFで使用されるMACは、拡張可能であり、同じMACプロトコルの残りの部分に使用されます。これはEAP-PAXヘッダで指定されています。
In this section, the packet format and content for the EAP-PAX messages are defined.
このセクションでは、EAP-PAXメッセージのパケットフォーマットと内容が定義されています。
EAP-PAX packets have the following structure:
EAP-PAXパケットは、以下の構造を有します：
--- bit offset --->
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 | OP-Code | Flags | MAC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH Group ID | Public Key ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ICV ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EAP-PAX Packet Structure
図4：EAP-PAXのパケット構造
The Code, Identifier, Length, and Type fields are all part of the EAP header, and defined in [RFC3748]. IANA has allocated EAP Method Type 46 for EAP-PAX; thus, the Type field in the EAP header MUST be 46.
コード、識別子、長さ、タイプフィールドはEAPヘッダーのすべての部分であり、[RFC3748]で定義されます。 IANAはEAP-PAXのためにEAPメソッドタイプ46を割り当てました。従って、EAPヘッダーのタイプフィールドが46でなければなりません。
The OP-Code field is one of the following values:
OP-Codeフィールドには、次のいずれかの値です。
o 0x01 : PAX_STD-1 o 0x02 : PAX_STD-2 o 0x03 : PAX_STD-3 o 0x11 : PAX_SEC-1 o 0x12 : PAX_SEC-2 o 0x13 : PAX_SEC-3 o 0x14 : PAX_SEC-4 o 0x15 : PAX_SEC-5 o 0x21 : PAX-ACK
Oは0x01：PAX_STD-1 O 0×02：PAX_STD-2 O 0×03：PAX_STD-3 O 0x11を：PAX_SEC-1 O 0x12を：PAX_SEC-2 O 0x13に：PAX_SEC-3 O 0x14の：PAX_SEC-4 O 0x15の：PAX_SEC-5 O 0x21で：PAX-ACK
The flags field is broken up into 8 bits each representing a binary flag. The field is defined as the Logical OR of the following values:
フラグフィールドは、バイナリフラグを表す8ビットずつに分割されています。フィールドは論理としてOR以下の値で定義されています。
o 0x01 : more fragments (MF) o 0x02 : certificate enabled (CE) o 0x04 : ADE Included (AI) o 0x08 - 0x80 : reserved
0x01のO：複数の断片0x02のO（MF）：証明書（CE）が有効O 0x04の：ADEが含まれて（AI）は、O 0x08に - 0x80から：予約します
The MF flag is set if the current packet required fragmentation, and further fragments need to be transmitted. If a packet does not require fragmentation, the MF flag is not set.
現在のパケットが断片化を必要に応じて、MFフラグがセットされ、さらにフラグメントが送信される必要があります。パケットが断片化を必要としない場合は、MFフラグが設定されていません。
When a payload requires fragmentation, each fragment is transmitted, and the receiving party responds with a PAX-ACK packet for each received fragment.
ペイロードがフラグメント化を必要とするとき、各フラグメントが送信され、受信側は受信した各断片用PAX-ACKパケットで応答します。
When using PAX_STD, the CE flag MUST be zero. When using PAX_SEC, the CE flag MUST be set if PAX_SEC-1 includes CertPK. It MUST NOT be set if PAX_SEC-1 includes PK. If CE is set in PAX_SEC-1, it MUST be set in PAX_SEC-2, PAX_SEC-3, PAX_SEC-4, and PAX_SEC-5. If either party detects an inconsistent value of the CE flag, he MUST send an EAP-Failure message and discontinue the session.
PAX_STDを使用する場合、CEフラグがゼロでなければなりません。 PAX_SECを使用する場合PAX_SEC-1はCertPKを含む場合、CEフラグを設定しなければなりません。 PAX_SEC-1は、PKが含まれている場合は設定してはいけません。 CEはPAX_SEC-1に設定されている場合、それはPAX_SEC-2、PAX_SEC-3、PAX_SEC-4、およびPAX_SEC-5に設定されなければなりません。いずれかの当事者は、CEフラグの一貫性のない値を検出した場合、彼はEAP失敗メッセージを送信し、セッションを中止しなければなりません。
The AI flag indicates the presence of an ADE element. AI MUST only be set on packets PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and PAX_ACK if an ADE element is included. On packets of other types, ADE elements MUST be silently discarded as they cannot be authenticated.
AIフラグがADE要素の存在を示します。 ADE要素が含まれている場合AIのみパケットPAX_STD-2、PAX_STD-3、PAX_SEC-4、PAX_SEC-5、及びPAX_ACKに設定しなければなりません。彼らは認証できないように、他のタイプのパケットには、ADE要素は黙って捨てなければなりません。
The MAC field specifies the cryptographic hash used to generate the keyed hash value. The following are currently supported:
MACフィールドは、鍵付きハッシュ値を生成するために使用される暗号化ハッシュを指定します。以下は、現在サポートされています。
o 0x01 : HMAC_SHA1_128 [FIPS198] [FIPS180] o 0x02 : HMAC_SHA256_128 [FIPS180]
Oは0x01：0x02のO HMAC_SHA1_128 [FIPS198] [FIPS180]：HMAC_SHA256_128 [FIPS180]
The Diffie-Hellman group field specifies the group used in the Diffie-Hellman computations. The following are currently supported: o 0x00 : NONE (iff not performing a key update) o 0x01 : 2048-bit MODP Group (IANA DH Group 14) [RFC3526] o 0x02 : 3072-bit MODP Group (IANA DH Group 15) [RFC3526] o 0x03 : NIST ECC Group P-256 [FIPS186]
Diffie-Hellmanグループフィールドは、のDiffie-Hellman計算に使用されるグループを特定します。現在サポートされている以下：0x00のO：NONE 0x01のO（鍵更新を行っていないIFF）：2048ビットMODPグループ（IANA DHグループ14）[RFC3526] O 0×02：3072ビットMODPグループ（IANA DHグループ15）[ RFC3526] 0x03のO：NIST ECCグループP-256 [FIPS186]
If no key update is being performed, the DH Group ID field MUST be zero. Otherwise, the DH Group ID field MUST NOT be zero.
何のキー更新が実行されていない場合は、DHグループIDフィールドはゼロでなければなりません。それ以外の場合は、DHグループIDフィールドはゼロであるはずがありません。
The Public Key ID field specifies the cipher used to encrypt the client's EAP-Response in PAX_SEC-2.
公開鍵IDフィールドはPAX_SEC-2で、クライアントのEAP-応答を暗号化するために使用される暗号を指定します。
The following are currently supported:
以下は、現在サポートされています。
o 0x00 : NONE (if using PAX_STD) o 0x01 : RSAES-OAEP [RFC3447] o 0x02 : RSA-PKCS1-V1_5 [RFC3447] o 0x03 : El-Gamal Over NIST ECC Group P-256 [FIPS186]
Oは0x00：NONE（PAX_STDを使用している場合）Oが0x01：RSAES-OAEP [RFC3447] 0x02のO：RSA-PKCS1-v1_5の[RFC3447] O 0×03：エル・ガマル以上NIST ECCグループP-256 [FIPS186]
If PAX_STD is being executed, the Public Key ID field MUST be zero. If PAX_SEC is being executed, the Public Key ID field MUST NOT be zero.
PAX_STDが実行されている場合は、公開鍵IDフィールドはゼロでなければなりません。 PAX_SECが実行されている場合は、公開鍵IDフィールドはゼロであるはずがありません。
When using RSAES-OAEP, the hash algorithm and mask generation algorithm used SHALL be the MAC specified by the MAC ID, keyed using an all-zero key. The label SHALL be null.
RSAES-OAEPを使用する場合、使用されるハッシュアルゴリズムとマスク生成アルゴリズムは、すべてゼロのキーを使用してキー入力MAC IDによって指定されたMACでなければなりません。ラベルはnullにされなければなりません。
The RSA-based schemes specified here do not dictate the length of the public keys. DER encoding rules will specify the key size in the key or certificate [X.690]. Key sizes SHOULD be used that reflect the desired level of security.
ここで指定したRSAベースのスキームは、公開鍵の長さを決定していません。 DERエンコーディング規則は、キーまたは証明書[X.690]にキーサイズを指定します。キーサイズは、セキュリティの所望のレベルを反映している、使用されてください。
The following ciphersuite is mandatory to implement and achieves roughly 112 bits of security:
次の暗号スイートを実装するために必須であり、セキュリティの約112ビットを達成します。
o HMAC_SHA1_128 o IANA DH Group 14 (2048 bits) o RSA-PKCS1-V1_5 (RECOMMEND 2048-bit public key)
O HMAC_SHA1_128 O IANA DHグループRSA-PKCS1-v1_5のO 14（2048ビット）（2048ビットの公開鍵を勧め）
The following ciphersuite is RECOMMENDED and achieves 128 bits of security:
次の暗号スイートが推奨およびセキュリティの128ビットを達成しています。
o HMAC_SHA256_128 o IANA DH Group 15 (3072 bits) o RSAES-OAEP (RECOMMEND 3072-bit public key)
RSAES-OAEP（3072ビットの公開鍵を勧め）O O IANA DH O群HMAC_SHA256_128 15（3072ビット）
This section describes how to format the payload field. Depending on the packet type, different values are transmitted. Sections 2.1 and 2.2 define the fields, and in what order they are to be concatenated. For simplicity and since many field lengths can vary with the ciphersuite, each value is prepended with a 2-octet length value encoded as an integer as described below. This length field MUST equal the length in octets of the subsequent value field.
このセクションでは、ペイロードフィールドの書式を設定する方法について説明します。パケットの種類に応じて、異なる値が送信されます。セクション2.1と2.2は、フィールドを定義し、どのような順序でそれらを連結することになっています。簡単にするために、多くのフィールド長は、暗号スイートを用いて変えることができるので、各値は、以下に記載されるように整数としてエンコード2オクテットの長さの値と付加されています。この長さフィールドは、後続の値フィールドのオクテットの長さを等しくなければなりません。
--- octet offset --->
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---------------------
|len| value ....
+---+--------
Figure 5: Length Encoding for Data Elements
図5：データ要素のためのレングス符号化
All integer values are stored as octet arrays in network-byte order, with the most significant octet first. Integers are padded on the most significant end to reach octet boundaries.
すべての整数値は、最初の最も重要なオクテットと、ネットワークバイト順のオクテット配列として格納されています。整数はオクテット境界に到達するために最も重要な先端に埋め込まれます。
Public keys and certificates SHALL be in X.509 format [RFC3280] encoded using the Distinguished Encoding Rules (DER) format [X.690].
公開鍵および証明書は、識別符号化規則（DER）フォーマット[X.690]を使用して符号化X.509形式[RFC3280]でなければなりません。
Strings are not null-terminated and are encoded using UTF-8. Binary data, such as message authentication codes, are transmitted as-is.
文字列は、NULLで終了ではなく、UTF-8を使用してエンコードされています。そのようなメッセージ認証コードなどのバイナリデータは、そのままで送信されます。
MACs are computed by concatenating the specified values in the specified order. Note that for MACs, length fields are not included, though the resulting MAC will itself have a length field. Values are encoded as described above, except that no length field is specified.
MACは、指定された順序で指定された値を連結することによって計算されます。結果としてMAC自体が長さフィールドを持っているでしょうが、Mac用、長さフィールドが含まれていないことに注意してください。いかなる長さフィールドが指定されていないことを除いて、上記のように値が符号化されます。
To illustrate this process, an example is presented. What follows is the encoding of the payload for PAX_STD-2. The three basic steps will be computing the MAC, forming the payload, and encrypting the payload.
このプロセスを説明するために、例が提示されます。以下はPAX_STD-2のペイロードのエンコーディングです。三つの基本的な手順は、MACを計算するペイロードを形成し、ペイロードを暗号化します。
To create the MAC, we first need to form the buffer that will be MACed. For this example, assume that no key update is being done and HMAC_SHA1_128 is used such that the result will be a 16-octet value.
MACを作成するには、まずMACedされるバッファを形成する必要があります。この例では、何の鍵更新が行わされていないとHMAC_SHA1_128結果は、16オクテットの値となるように使用されると仮定する。
--- octet offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-octet integer A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-octet integer B |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... variable length CID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
||
||
CK --> MAC
||
\/
--- octet offset --->
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-octet MAC output |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example Encoding of PAX_STD-2 MAC Data
図6：PAX_STD-2 MACデータの例エンコード
With this, we can now create the encoded payload:
これにより、我々は今、エンコードされたペイロードを作成することができます。
--- octet offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|32 | 32-octet integer B
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L | |
+-+-+-+-+ +
| |
... L-octet CID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|16 | MAC computed above |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Example Encoding of PAX_STD-2 Packet
図7：PAX_STD-2パケットの例エンコード
These 52+L octets are then attached to the packet as the payload. The ICV is then computed by MACing the packet headers and payload, and appended after the payload (see Section 3.4).
これら52個の+ Lオクテットは、その後、ペイロードとしてパケットに付与されています。 ICVは、パケットヘッダとペイロードをMACingによって計算され、ペイロードの後に添付される（セクション3.4参照）。
This section describes the formatting of the ADE elements. ADE elements can only occur on packets of type PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and PAX_ACK. Values included in other packets MUST be silently ignored.
このセクションでは、ADE要素の書式設定を説明します。 ADE要素は、型PAX_STD-2、PAX_STD-3、PAX_SEC-4、PAX_SEC-5、及びPAX_ACKのパケットで発生することができます。他のパケットに含まれる値は黙って無視しなければなりません。
The ADE element is preceded by its 2-octet length L. Each subelement has first a 2-octet length Li followed by a 2-octet type Ti. The entire ADE element looks as follows:
ADE要素は、各サブエレメントは、Li 2オクテットのタイプのTi、続いて第2オクテットの長さを有し、その2オクテットの長さLが先行します。次のように全体ADE要素が見えます：
--- octet offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L |L1 |T1 | |
+-+-+-+-+-+-+ +
| |
... subADE-1, type T1, length L1 ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |L2 |T2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... subADE-2, type T2, length L2 ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | more subADE elements... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Encoding of ADE Components
図8：ADEコンポーネントのエンコード
The following type values have been allocated:
以下のタイプの値が割り当てられています：
o 0x01 : Vendor Specific o 0x02 : Client Channel Binding Data o 0x03 : Server Channel Binding Data
Oが0x01：0x02のOベンダー固有：クライアントチャンネルが0x03のOデータバインディング：サーバーチャンネルのデータのバインド
The first three octets of a subADE utilizing type code 0x01 must be the vendor's Enterprise Number [RFC3232] as registered with IANA. The format for such a subADE is as follows:
IANAに登録されているようなタイプのコードは0x01を利用subADEの最初の3つのオクテットは、ベンダーのエンタープライズ番号[RFC3232]でなければなりません。以下のようなsubADEの形式は次のとおりです。
--- octet offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Li | 1 | ENi | |
+-+-+-+-+-+-+-+ +
| |
... subADE-i, type Vendor Specific, length Li, vendor ENi ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Encoding of Vendor-specific ADE
図9：ベンダー固有ADEのエンコーディング
Channel binding subADEs have yet to be defined. Future IETF documents will specify the format for these subADE fields.
チャネル結合subADEsが定義されていません。今後のIETF文書は、これらのsubADEフィールドの形式を指定します。
The ICV is computed as the MAC over the entire EAP packet, including the EAP header, the EAP-PAX header, and the EAP-PAX payload. The MAC is keyed using the 16-octet ICK, using the MAC type specified by the MAC ID in the EAP-PAX header. For packets of type PAX_STD-1, PAX_SEC-1, PAX_SEC-2, and PAX_SEC-3, where the MK has not yet been derived, the MAC is keyed using a zero-octet NULL key.
ICVは、EAPヘッダ、EAP-PAXヘッダ、及びEAP-PAXのペイロードを含む全体のEAPパケット上MACとして計算されます。 MACはEAP-PAXヘッダ内のMAC IDによって指定されたMACタイプを使用して、16オクテットICKを使用してキー止めされています。 MKはまだ得られていないタイプPAX_STD-1、PAX_SEC-1、PAX_SEC-2、及びPAX_SEC-3のパケットのために、MACは、ゼロオクテットNULLキーを用いてキー止めされています。
If the ICV field is incorrect, the receiver MUST silently discard the packet.
ICVフィールドが正しくない場合、受信機は静かにパケットを捨てなければなりません。
Any authentication protocol, especially one geared for wireless environments, must assume that adversaries have many capabilities. In general, one must assume that all messages between the client and server are delivered via the adversary. This allows passive attackers to eavesdrop on all traffic, while active attackers can modify data in any way before delivery.
任意の認証プロトコル、ワイヤレス環境のために連動特に1は、敵は、多くの機能を持っていることを前提としなければなりません。一般的に、1は、クライアントとサーバー間のすべてのメッセージが敵を介して配信されていることを前提としなければなりません。これは、アクティブな攻撃者が出荷前にどのような方法でデータを変更することができますが、受動攻撃者は、すべてのトラフィックを盗聴することができます。
In this section, we discuss the security properties and requirements of EAP-PAX with respect to this threat model. Also note that the security of PAX can be proved using under the Random Oracle model.
このセクションでは、この脅威モデルに対するセキュリティプロパティおよびEAP-PAXの要件を議論します。また、PAXのセキュリティはランダムオラクルモデルの下で使用して証明することができることに注意してください。
PAX_SEC can be used in several configurations. It can be used with or without a server-side certificate. Section 2.2 details the possible modes and the resulting security risk.
PAX_SECは、いくつかの構成で使用することができます。これは、サーバー側の証明書の有無にかかわらず使用することができます。 2.2節は、可能なモードと結果のセキュリティリスクを詳述します。
When using PAX_SEC for identity protection and not using a CA-signed certificate, an attacker can convince a client to reveal his username. To achieve this, an attacker can simply forge a PAX_SEC-1 message and send it to the client. The client would respond with a PAX_SEC-2 message containing his encrypted username. The attacker can then use his associated private key to decrypt the client's username. Use of key caching can reduce the risk of identity revelation by allowing clients to detect when the EAP server to which they are accustom has a different public key.
CA署名証明書を使用して、ID保護のためPAX_SECを使用していない場合は、攻撃者が彼の名を明らかにし、クライアントを説得することができます。これを実現するために、攻撃者は単にPAX_SEC-1のメッセージを偽造し、それをクライアントに送信することができます。クライアントは自分の暗号化されたユーザー名を含むPAX_SEC-2メッセージで応答することになります。攻撃者は、その後、クライアントのユーザー名を復号化するために彼の関連する秘密鍵を使用することができます。キーキャッシュの使用は、彼らが慣らすであるにEAPサーバが異なる公開鍵を持っている場合、クライアントが検出できるようにすることで、アイデンティティの啓示のリスクを減らすことができます。
When provisioning with PAX_SEC and not using a CA-signed certificate, an attacker could first forge a PAX_SEC-1 message and send it to the client. The client would respond with a PAX_SEC-2 message. Using the decrypted value of N, an attacker could forge a PAX_SEC-3 message. Once the client responds with a PAX_SEC-4 message, an attacker can guess values of the weak AK and compute CK = PAX-KDF(AK, "Confirmation Key", g^XY). Given enough time, the attacker can obtain both the old AK and new AK' and forge a responding PAX_SEC-5.
PAX_SECでプロビジョニングおよびCA署名付き証明書を使用しない場合、攻撃者はまずPAX_SEC-1のメッセージを偽造し、それをクライアントに送信することができます。クライアントはPAX_SEC-2メッセージで応答することになります。 Nの復号化された値を使用して、攻撃者はPAX_SEC-3メッセージを偽造することができました。クライアントはPAX_SEC-4メッセージで応答すると、攻撃者が弱いAKの値を推測し、CK = PAX-KDF（AK、「確定キー」、G ^ XY）を計算することができます。十分な時間を考えると、攻撃者は古いAKと新しいAKの両方を得る」と応答PAX_SEC-5を偽造することができます。
In order to maintain a reasonable security policy, the server should manage five pieces of information concerning each user, most obviously, the username and current key. In addition, the server must keep a bit that indicates whether the current key is weak. Weak keys must be updated prior to key derivation. Also, the server should track the date of last key update. To implement the coarse-grained forward secrecy, the authentication key must be updated on a regular basis, and this field can be used to expire keys. Last, the server should track the previous key, to prevent attacks where an adversary desynchronizes the key state by interfering with PAX-ACK packets. See Appendix B for more suggested implementation strategies that prevent key desynchronization attacks.
合理的なセキュリティポリシーを維持するために、サーバーはほとんど明らかに、各ユーザに関する5つの情報、ユーザ名と現在の鍵を管理する必要があります。また、サーバは、現在のキーが弱いかどうかを示すビットを保持する必要があります。弱い鍵は鍵導出する前に更新する必要があります。また、サーバは、最後のキーの更新の日付を追跡する必要があります。粒度の粗い転送秘密を実装するには、認証キーは定期的に更新する必要があり、このフィールドは、キーを期限切れにするために使用することができます。敵対者がPAX-ACKパケットを妨害することにより、キーの状態をdesynchronizesどこ最後に、サーバが攻撃を防ぐために、前のキーを追跡する必要があります。キー非同期化攻撃を防ぐ複数の推奨実装戦略については、付録Bを参照してください。
Since the client keys are stored in plaintext on the server, special care should be given to the overall security of the authentication server. An operating system-level attack yielding root access to an intruder would result in the compromise of all client credentials.
クライアントキーがサーバー上に平文で保存されているので、特別なケアは、認証サーバのセキュリティ全体に与えられるべきです。侵入者へのrootアクセスをもたらすオペレーティングシステムレベルの攻撃は、すべてのクライアントの資格情報の妥協につながります。
This section describes EAP-PAX in terms of specific security terminology as required by [RFC3748].
このセクションでは、[RFC3748]によって必要とされる特定のセキュリティ用語の点でEAP-PAXを記載しています。
In the initial packet from the server, the server specifies the ciphersuite in the packet header. The server is in total control of the ciphersuite; thus, a client not supporting the specified ciphersuite will not be able to authenticate. In addition, each client's local security policy should specify secure ciphersuites the client will accept. The ciphersuite specified in PAX_STD-1 and PAX_SEC-1 MUST remain the same in successive packets within the same authentication session. Since later packets are covered by an ICV keyed with the ICK, the server can verify that the originally transmitted ciphersuite was not altered by an adversary.
サーバからの最初のパケットでは、サーバは、パケットヘッダ内の暗号スイートを指定します。サーバは、暗号スイートの総制御です。このように、指定された暗号スイートをサポートしていないクライアントは認証できません。また、各クライアントのローカルセキュリティポリシーでは、クライアントが受け入れる安全な暗号スイートを指定する必要があります。 PAX_STD-1及びPAX_SEC-1で指定された暗号スイートは、同じ認証セッション内の連続するパケットにおいて同じままでなければなりません。後でパケットはICKとキーイングICVで覆われているので、サーバは、最初に送信さ暗号スイートは、敵によって変化しなかったことを確認することができます。
Both PAX_STD and PAX_SEC authenticate the client and the server, and consequently achieve explicit mutual authentication.
PAX_STDとPAX_SECの両方が、クライアントとサーバーを認証し、その結果、明示的な相互認証を実現します。
The ICV described in Section 3.4 provides integrity protection once the integrity check key has been derived. The header values in the unprotected packets can be verified when an ICV is received later in the session.
整合性チェックキーが導出された後、3.4節で説明したICVは、完全性保護を提供します。 ICVは、セッションの後半で受信されたときに保護されていないパケットのヘッダ値を検証することができます。
EAP-PAX is inherently designed to avoid replay attacks by cryptographically binding each packet to the previous one. Also the EAP sequence number is covered by the ICV to further strengthen resistance to replay attacks.
EAP-PAXは、本質的に、暗号前の1に各パケットを結合することにより、リプレイ攻撃を回避するように設計されています。また、EAPシーケンス番号はさらにリプレイ攻撃に対する耐性を強化するためにICVで覆われています。
With identity protection enabled, PAX_SEC provides full confidentiality.
アイデンティティ保護を有効にすると、PAX_SECは完全な機密性を提供します。
Session keys are derived using the PAX-KDF and fresh entropy supplied by both the client and the server. Since the key hierarchy is derived from the shared password, only someone with knowledge of that password or the capability of guessing it is capable of deriving the session keys. One of the main benefits of PAX_SEC is that it allows you to bootstrap a strong shared secret using a weak password while preventing offline dictionary attacks.
セッションキーは、PAX-KDFと、クライアントとサーバの両方から供給される新鮮なエントロピーを使用して導出されています。キー階層は共有パスワードから導出されているので、そのパスワードを知ったり、それを推測する能力を持つ唯一の誰かがセッションキーを導出することが可能です。 PAX_SECの主な利点の1つは、それはあなたがオフライン辞書攻撃を防ぎながら、弱いパスワードを使用して強力な共有秘密をブートストラップすることを可能にするということです。
Authentication keys are 128 bits. The key generation is protected by a Diffie-Hellman key exchange. It is believed that a 3000-bit MODP public-key scheme is roughly equivalent [RFC3766] to a 128-bit symmetric-key scheme. Consequently, EAP-PAX requires the use of a Diffie-Hellman group with modulus larger than 3000. Also, the exponent used as the private DH parameter must be at least twice as large as the key eventually generated. Consequently, EAP-PAX uses 256-bit DH exponents. Thus, the authentication keys contain the full 128 bits of security.
認証キーは128ビットです。鍵生成はのDiffie-Hellman鍵交換によって保護されています。 3000ビットのMODP公開鍵方式は、128ビット対称キー方式と[RFC3766]とほぼ同等であると考えられます。したがって、EAP-PAXはまた、3000よりも大きい弾性率を有するのDiffie-Hellmanグループを使用する必要があり、プライベートDHパラメータとして使用される指数は、最終的に生成された鍵と少なくとも2倍でなければなりません。したがって、EAP-PAXは、256ビットのDH指数を使用します。このように、認証キーは、セキュリティの完全な128ビットを含みます。
Future ciphersuites defined for EAP-PAX MUST contain a minimum of 128 bits of security.
EAP-PAXのために定義された将来の暗号スイートは、セキュリティの128ビットの最小値を含まなければなりません。
EAP-PAX is resistant to dictionary attacks, except for the case where a weak password is initially used and the server is not using a certificate for authentication. See Section 4.1 for more information on resistance to dictionary attacks.
EAP-PAXは、脆弱なパスワードが最初に使用され、サーバが認証用の証明書を使用していない場合を除いて、辞書攻撃に耐性があります。辞書攻撃への耐性についての詳細は、4.1節を参照してください。
Although a specific fast reconnection option is not included, execution of PAX_STD requires very little computation time and is therefore bound primarily by the latency of the Authentication, Authorization, and Accounting (AAA) server.
特定の高速再接続オプションが含まれていないが、PAX_STDの実行は非常に少ない計算時間を要するため、認証、認可、アカウンティング（AAA）サーバーのレイテンシーによって主にバインドされています。
This protocol easily achieves backward secrecy through, among other things, use of the PAX-KDF. Given a current session key, attackers can discover neither the entropy used to generate it nor the key used to encrypt that entropy as it was transmitted across the network.
このプロトコルは、簡単に、とりわけ、通過PAX-KDFの使用を後方秘密を実現しています。現在のセッションキーを考えると、攻撃者はそれを生成するために使用されるエントロピーまたそれがネットワーク経由で送信されたように、そのエントロピーを暗号化するために使用されるキーのいずれを発見することができます。
This protocol has coarse-grained forward secrecy. Compromised session keys are only useful on data for that session, and one cannot derive AK from them. If an attacker can discover AK, that value can only be used to compromise session keys derived using that AK. Reasonably frequent password updates will help mitigate such attacks.
このプロトコルは、粗粒度の転送秘密を持っています。妥協セッションキーはそのセッションのためのデータでのみ有用であり、一つは彼らからAKを導き出すことはできません。攻撃者はAKを発見することができた場合は、その値は、それだけでAKを使用して得られたセッション鍵を侵害するために使用することができます。合理的に頻繁にパスワードの更新は、このような攻撃を緩和するのに役立ちます。
Session keys are independently generated using fresh nonces for each session, and therefore the sessions are independent.
セッションキーが独立して、セッションごとに新鮮なナンスを使用して生成されているので、セッションは独立しています。
Fragmentation and reassembly is supported through the fragmentation flag in the header.
断片化と再アセンブリは、ヘッダ内のフラグメント化フラグを介して支持されています。
EAP-PAX can be extended to support channel bindings through the use of its subADE fields.
EAP-PAXは、そのsubADEフィールドを使用してチャネルバインディングをサポートするように拡張することができます。
EAP-PAX does not include any cryptographic binding. This is relevant only for tunneled methods.
EAP-PAXは、任意の暗号の結合が含まれていません。これは、トンネル化方法に関連しています。
EAP is susceptible to an attack where an attacker uses NAKs to convince an EAP client and server to use a less secure method, and can be prevented using method-specific integrity protection on NAK messages. Since EAP-PAX does not have suitable keys derived for this integrity protection at the beginning of a PAX conversation, this is not included.
EAPは、攻撃者が安全性の低いメソッドを使用するEAPクライアントとサーバを納得させるためにNAKを使用する攻撃を受けやすい、とNAKメッセージにメソッド固有の完全性保護を使用して防止することができます。 EAP-PAXがPAXの会話の初めに、この完全性保護のために由来する適切なキーを持っていないので、これは含まれていません。
This document requires IANA to maintain the namespace for the following header fields: MAC ID, DH Group ID, Public Key ID, and ADE type. The initial namespace populations are as follows.
このドキュメントは以下のヘッダフィールドの名前空間を維持するために、IANAが必要です：MAC ID、DHグループID、公開鍵ID、およびADEタイプを。次のように最初の名前空間の集団です。
MAC ID Namespace:
MAC ID名前空間：
o 0x01 : HMAC_SHA1_128 o 0x02 : HMAC_SHA256_128
Oが0x01：0x02のO HMAC_SHA1_128：HMAC_SHA256_128
DH Group ID Namespace:
DHグループID名前空間：
o 0x00 : NONE o 0x01 : IANA DH Group 14 o 0x02 : IANA DH Group 15 o 0x03 : NIST ECC Group P-256
Oは0x00：0x01のO NONE：IANA DHグループ14 O 0×02：IANA DHグループ15 O 0x03の：NIST ECCグループP-256
Public Key ID Namespace:
公開鍵IDの名前空間：
o 0x00 : NONE o 0x01 : RSAES-OAEP o 0x02 : RSA-PKCS1-V1_5 o 0x03 : El-Gamal Over NIST ECC Group P-256
Oは0x00：NONE Oは0x01：RSAES-OAEP 0x02のO：RSA-PKCS1-v1_5の0x03のO：エル・ガマルオーバーNIST ECCグループP-256
ADE Type Namespace:
ADEタイプの名前空間：
o 0x01 : Vendor Specific o 0x02 : Client Channel Binding Data o 0x03 : Server Channel Binding Data
Oが0x01：0x02のOベンダー固有：クライアントチャンネルが0x03のOデータバインディング：サーバーチャンネルのデータのバインド
Allocation of values for these namespaces shall be reviewed by a Designated Expert appointed by the IESG. The Designated Expert will post a request to the EAP WG mailing list (or a successor designated by the Designated Expert) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the EAP WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable.
これらの名前空間の値の配分はIESGによって任命指名専門家によって審査されなければなりません。指定専門家は、インターネットドラフトを含め、コメントやレビューのためのEAP WGメーリングリストへの要求（または指定エキスパートによって指定された後継）を掲載します。 30日間の期間が経過する前に、指定Expertは承認または登録要求を拒否し、EAP WGメーリングリストやその後継者に決定の通知を発行するだけでなく、IANAに通知しますか。拒否通知は説明によって正当化や、許容なるように要求を変更することができますどのようにそれが可能である場合に、具体的な提案されなければなりません。
The authors would like to thank Jonathan Katz for discussion with respect to provable security, Bernard Aboba for technical guidance, Jari Arkko for his expert review, and Florent Bersani for feedback and suggestions. Finally, the authors would like to thank the Defense Information Systems Agency for initially funding this work.
著者は、フィードバックや提案のための彼の専門家レビューのための証明可能安全性、技術指導のためのバーナードAboba、ヤリArkkoに関して議論のためのジョナサン・カッツに感謝したい、とフロランBersaniでしょう。最後に、筆者は当初、この作品に資金を供給するために国防情報システム局に感謝したいと思います。
[FIPS180] National Institute for Standards and Technology, "Secure Hash Standard", Federal Information Processing Standard 180-2, August 2002.
[FIPS180]標準技術研究所、「セキュアハッシュ標準」、連邦情報処理規格180-2、2002年8月。
[FIPS186] National Institute for Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standard 186, May 1994.
[FIPS186]標準技術研究所、「デジタル署名標準（DSS）」、連邦情報処理標準186、1994年5月。
[FIPS198] National Institute for Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", Federal Information Processing Standard 198, March 2002.
[FIPS198]標準技術研究所、「鍵付きハッシュメッセージ認証コード（HMAC）」、連邦情報処理標準198、2002年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232]レイノルズ、J.、 "番号が割り当てられ：RFC 1700は、オンラインデータベースで置き換えられる"、RFC 3232、2002年1月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]ジョンソン、J.とB. Kaliski、 "公開鍵暗号規格（PKCS）＃1：RSA暗号仕様バージョン2.1"、RFC 3447、2003年2月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526] Kivinen、T.およびM.古城、 "インターネット鍵交換のためのより多くのモジュラー指数（MODP）のDiffie-Hellmanグループ（IKE）"、RFC 3526、2003年5月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", RFC 4334, February 2006.
[RFC4334] Housley氏、R.とT.ムーア、「証明書の拡張機能と属性で認証のサポートポイントツーポイントプロトコル（PPP）とワイヤレスローカルエリアネットワーク（WLAN）」、RFC 4334、2006年2月。
[X.690] International Telecommunications Union, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", Data Networks and Open System Communication Recommendation X.690, July 2002.
[X.690]国際電気通信連合、「情報技術 - ASN.1エンコーディング規則：基本符号化規則（BER）の仕様、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）」、データネットワークとオープンシステムコミュニケーション勧告X.690、2002年7月。
[IETF.KEY] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. Levkowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress.
【IETF.KEY] Aboba、B.、サイモン、D.、Arkko、J.、Eronen、P.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）鍵管理フレームワーク"、ProgressのWork。
[IEEE.80211] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11-1997, 1997.
[IEEE.80211]電気電子技術者協会、「情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 固有の要件パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様」 、IEEE規格802.11から1997、1997。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631]レスコラ、E.、 "ディフィー・ヘルマン鍵共有方式"、RFC 2631、1999年6月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]オーマン、H.、およびP.ホフマン、 "対称鍵を交換するために使用公開鍵の強さを測定"、BCP 86、RFC 3766、2004年4月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]スタンレー、D.、ウォーカー、J.、およびB. Aboba、 "無線LANのための拡張認証プロトコル（EAP）メソッド要件"、RFC 4017、2005年3月。
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[RFC4252] Ylonenと、T.とC. Lonvick、 "セキュアシェル（SSH）認証プロトコル"、RFC 4252、2006年1月。
Appendix A. Key Generation from Passwords
パスワードの付録A.鍵生成
If a 128-bit key is not available to bootstrap the authentication process, then one must be generated from some sort of weak preshared key. Note that the security of the hashing process is unimportant, as long as it does not significantly decrease the password's entropy. Resistance to dictionary attacks is provided by PAX_SEC. Consequently, computing the SHA-1 of the password and truncating the output to 128 bits is RECOMMENDED as a means of converting a weak password to a key for provisioning.
128ビットの鍵は、認証プロセスをブートストラップするために利用できない場合、1は弱い事前共有キーのいくつかの並べ替えから生成されなければなりません。それが大幅にパスワードのエントロピーを減少させない限り、ハッシュプロセスのセキュリティが重要でないことに注意してください。辞書攻撃への抵抗はPAX_SECによって提供されます。結果として、SHA-1パスワードを計算し、128ビットの出力を切り捨てるが、プロビジョニングのためのキーに弱いパスワードを変換する手段として推奨されています。
When using other preshared credentials, such as a Kerberos Data Encryption Standard (DES) key, or an MD4-hashed Microsoft Challenge Handshake Authentication Protocol (MSCHAP) password, to provision clients, these keys SHOULD still be put through SHA-1 before being used. This serves to protect the credentials from possible compromise, and also keeps things uniform. As an example, consider provisioning using an existing Kerberos credential. The initial key computation could be SHA1_128(string2key(password)). The KDC, storing string2key(password), would also be able to compute this initial key value.
このようKerberosのデータ暗号化規格（DES）キー、またはMD4ハッシュMicrosoftチャレンジハンドシェイク認証プロトコル（MSCHAP）パスワードなどの他の事前共有の資格情報を使用する場合、プロビジョニングクライアントに、これらのキーは、まだ使用される前に、SHA-1によって配置する必要があります。これは、可能な妥協案から資格情報を保護するためのものであり、また、均一なものを保持します。例として、既存のKerberos資格情報を使用してプロビジョニングを検討してください。最初の鍵計算はSHA1_128（string2key（パスワード））である可能性があります。 KDCは、string2key（パスワード）を格納し、また、この初期キー値を計算することができるだろう。
Appendix B. Implementation Suggestions
付録B.実装の提案
In this section, two implementation strategies are discussed. The first describes how best to implement and deploy EAP-PAX in an enterprise network for IEEE 802.11i authentication. The second describes how to use EAP-PAX for device authentication in a 3G-style mobile phone network.
このセクションでは、2つの実装戦略が議論されています。最初は、実装したIEEE 802.11i認証のための企業ネットワークでEAP-PAXを展開する最善の方法について説明します。第二は、3G-スタイルの携帯電話ネットワーク内のデバイス認証にEAP-PAXを使用する方法について説明します。
B.1. WiFi Enterprise Network
B.1。 WiFiのエンタープライズネットワーク
For the purposes of this section, a wireless enterprise network is defined to have the following characteristics:
このセクションの目的のために、無線企業ネットワークは、以下の特性を有するように定義されます。
o Users wish to obtain network access through IEEE 802.11 access points.
Oユーザーは、IEEE 802.11アクセスポイントを介してネットワークアクセスを取得したいです。
o Users can possibly have multiple devices (laptops, PDAs, etc.) they wish to authenticate.
Oユーザーは、おそらく、彼らが認証を希望する複数のデバイス（ラップトップ、PDAなど）を持つことができます。
o A preexisting authentication framework already exists, for example, a Microsoft Active Directory domain or a Kerberos realm.
O既存の認証フレームワークは、すでにマイクロソフトのActive DirectoryドメインまたはKerberosレルム、例えば、存在します。
Two of the biggest challenges in an enterprise WiFi network is key provisioning and support for multiple devices. Consequently, it is recommended that the client's Network Access Identifier (NAI) have the format username/KID@realm, where KID is a key ID that can be used to distinguish between different devices.
企業WiFiネットワークにおける最大の課題の二つは、複数のデバイスのためのキーのプロビジョニングとサポートです。したがって、クライアントのネットワークアクセス識別子（NAI）はKIDが異なるデバイスを区別するために使用することができ、キーIDである形式のユーザー名/ KID @ realmのを、持っていることをお勧めします。
The client's supplicant can use a variety of sources to automatically generate the KID. Two of the better choices would likely be the computer's NETBIOS name, or local Ethernet adapter's MAC address. The wireless adapter's address may be a suboptimal choice, as the user may only have one PCCARD adapter for multiple systems.
クライアントのサプリカントは自動的にKIDを生成するために、さまざまなソースを使用することができます。より良い選択の二つは、おそらくコンピュータのNETBIOS名、またはローカル・イーサネットアダプタのMACアドレスになります。ユーザーは唯一の複数のシステムに1つのPCCARDアダプタを有することができるよう、ワイヤレスアダプタのアドレスは、次善の選択かもしれません。
With an authentication system already in place, there is a natural choice for the provisioned key. Clients can authenticate using their preexisting password. When the server is presented with a new KID, it can create a new key record on the server and use the user's current password as the provisioned key. For example, for Active Directory, the supplicant could use Microsoft's NtPasswordHash function to generate a key verifiable by the server. It is suggested that this key then be fed through SHA1_128 before being used in a non-Microsoft authentication protocol.
すでに場所での認証システムでは、プロビジョニングされたキーのための自然な選択があります。クライアントは、既存のパスワードを使用して認証することができます。サーバが新しいKIDを提示しているときは、サーバー上で新しいキーレコードを作成し、プロビジョニングキーとして、ユーザの現在のパスワードを使用することができます。たとえば、Active Directoryのために、サプリカントは、サーバがキー検証を生成するために、MicrosoftのNtPasswordHash機能を使用することができます。このキーは、その後、マイクロソフト以外の認証プロトコルで使用される前にSHA1_128を介して供給することが示唆されます。
After a key update, the server should keep track of both the old and new authentication keys. When two keys exist, the server should attempt to use both to validate the MACs on transmitted packets. Once a client successfully authenticates using the new key, the server should discard the old key. This prevents desynchronization attacks.
鍵の更新後、サーバーは、新旧両方の認証キーを追跡する必要があります。 2つのキーが存在する場合、サーバが送信するパケットにMACを検証するために、両方を使用しようとする必要があります。クライアントが正常に新しいキーを使用して認証すると、サーバは古い鍵を破棄しなければなりません。これは、非同期化攻撃を防ぐことができます。
B.2. Mobile Phone Network
B.2。携帯電話ネットワーク
In a mobile phone system, we no longer need to worry about supporting multiple keys per identity. Presumably, each mobile device has a unique identity. However, if multiple devices per identity are desired, a method similar to that presented in Section B.1 could be used.
携帯電話システムでは、我々はもはやアイデンティティごとに複数のキーをサポートする心配する必要はありません。おそらく、各モバイルデバイスは、独自のアイデンティティを持っています。アイデンティティごとに複数のデバイスが所望される場合は、セクションB.1に提示したのと同様の方法を使用することができます。
Provisioning could easily be accomplished by issuing customers a 6- digit PIN they could type into their phone's keypad.
プロビジョニングは、簡単に顧客に、彼らは自分の携帯電話のキーパッドに入力することができ、6-桁のPINを発行することによって達成することができます。
Authors' Addresses
著者のアドレス
T. Charles Clancy DoD Laboratory for Telecommunications Sciences 8080 Greenmeade Drive College Park, MD 20740 USA
テレコミュニケーション科学T.チャールズ・クランシー国防総省研究所8080 Greenmeadeドライブカレッジパーク、MD 20740 USA
EMail: clancy@ltsnet.net
メールアドレス：clancy@ltsnet.net
William A. Arbaugh University of Maryland Department of Computer Science College Park, MD 20742 USA
コンピュータサイエンスカレッジパークのメリーランド州省のウィリアムA. Arbaugh大学、MD 20742 USA
EMail: waa@cs.umd.edu
メールアドレス：waa@cs.umd.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。