[要約] RFC 4746は、EAPを使用したパスワード認証交換の拡張に関する規格です。このRFCの目的は、EAPを使用して安全なパスワード認証を実現するためのフレームワークを提供することです。
Network Working Group T. Clancy
Request for Comments: 4746 LTS
Category: Informational W. Arbaugh
UMD
November 2006
Extensible Authentication Protocol (EAP) Password Authenticated Exchange
拡張可能な認証プロトコル（EAP）パスワード認証された交換
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).
Copyright（c）The IETF Trust（2006）。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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パックス（パスワード認証された交換）と呼ばれる拡張可能な認証プロトコル（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（パスワード認証されたExchange）は、共有キーを使用して認証用に設計された拡張可能な認証プロトコル（EAP）メソッド[RFC3748]です。2つの個別のサブプロトコル、PAX_STDとPAX_SECを使用します。PAX_STDは、共有キーを使用した相互認証のためのシンプルで軽量なプロトコルであり、認証されたデータ交換（ADE）をサポートしています。PAX_SECは、サーバー側の公開キーを使用した共有キープロビジョニングとID保護のサポートを提供することにより、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パックスを動機付けるアイデアは、単純な個人識別番号（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は、中間の辞書攻撃に対して脆弱です。最も強力なモードでは、EAPパックスはランダムオラクルモデルの下で確実に安全であることが証明されています。
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パックスは、強力な重要な資料の生成をサポートします。相互認証;非同期、辞書、および中間攻撃に対する抵抗。保護された交渉を伴うciphersuiteの拡張性。アイデンティティ保護;そして、チャネルバインディングの実装に役立つデータの認証された交換。これらの機能は、ワイヤレスLANS [RFC4017]のEAPメソッド要件を満たしており、IEAE 802.11 [IEEE.80211]などのワイヤレス環境に最適です。
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].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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パックスプロトコルで使用されるさまざまな変数と関数について説明します。それらは後のセクションで頻繁に参照されます。
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 Public 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
Y 256-bit random integer generated by the client
y 256ビットクライアントが生成したランダム整数
Keys:
キー：
AK authentication key shared between the client and EAP server
クライアントとEAPサーバーの間で共有されるAK認証キー
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
MKから生成され、AKの知識を証明するために認証中に使用されたCK確認キー
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初期化ベクトルcifersに使用されるベクトル。Authenticatorにエクスポートされました
MID Method ID used to construct the EAP Session ID and consequently name all the exported keys [IETF.KEY]
EAPセッションIDを構築し、その結果、すべてのエクスポートキーに名前を付けるために使用されるMIDメソッド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
MKから生成され、EAPメソッドによってエクスポートされたMSKマスターセッションキー
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
Mac_x（y）キー付きメッセージ認証コード対称キー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）Secret X、Identifier Y、およびSeed Zを使用して計算され、出力のWオクテットを生成したPAXキー派生関数
|| 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会話の実行中に発生する4つの基本的な手順を定義します。最初のフェーズであるディスカバリーは、基礎となるリンク層プロトコルによって処理されます。認証フェーズはここで定義されています。主要な分布と安全な関連フェーズは、基礎となるプロトコルに応じて異なる方法で処理され、このドキュメントでは説明されていません。
+--------+ +--------+
| | 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パックスパケット交換
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は、典型的な認証中に使用されます。2番目のPAX_SECは、キープロビジョニングやID保護などのより安全な機能を提供します。
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 Exponents g^xおよびg^yは、Modulo Prime Pまたは楕円曲線乗算グループで計算されます。更新が実行されず、セッションキーのみが導出されている場合、xとyが交換されます。キーアップデート中にdiffie-hellmanを使用すると、フォワードの秘密が提供され、弱いプロビジョニングキーが使用された場合にキー派生を確保します。
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は、強力な長期キーを使用した単純なノンセベースの認証です。クライアントとサーバーはそれぞれ256ビットのランダムデータを交換します。これは、セッションキーの生成のためにPAX-KDFをシードするために使用されます。プロトコル内のランダムに交換されたデータは、キーアップデートが実行されているかどうかによって異なります。キーアップデートが実行されていない場合は、次のようにしましょう。
o A = X o B = Y o E = X || Y
o a = x o b = y e e = x ||y
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 a = g^x o b = g^y e 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：クライアント< - サーバー：A O PAX_STD-2：クライアント - >サーバー：B、CID、MAC_CK（A、B、CID）、[オプションADE] O Pax_Std-3：クライアント<-Server：MAC_CK（B（B）、cid）、[オプションade] o pax -ack：client-> server：[Optional 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.
ADEコンポーネントの詳細については、セクション2.3を参照し、CKの導出を含むキー派生プロセスについてはセクション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：クライアント< - サーバー：M、PKまたはCERTPK O PAX_SEC-2：クライアント - >サーバー：ENC_PK（M、N、CID）O PAX_SEC-3：クライアント<-Server：A、MAC_N（A、CID）o Pax_Sec-4：クライアント - >サーバー：B、Mac_CK（A、B、CID）、[オプションADE] O PAX_SEC-5：クライアント<-Server：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.
ADEコンポーネントの詳細については、セクション2.3を参照し、CKの導出を含むキー派生プロセスについてはセクション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に署名した証明書を使用していない場合、初期認証は、オフラインマンインザミドル（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サーバーの公開鍵を記録し、セッション間のセッション間の一貫性を確認するクライアントが含まれます。それ以外の場合、攻撃者はセッション中にEAPサーバーをスプーフィングし、クライアントのIDの知識を得ることができます。
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.
厳格なモードでは、クライアントはサーバーが信頼できる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操作モードをサポートし、PKとCERTPKのPAX_SECの使用の両方をサポートする必要があります。クライアントは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パックスに組み込まれています。ただし、サーバーの公開キーのキー管理は、このドキュメントの範囲を超えています。自己署名証明書を使用している場合、展開者は、キャッシュセキュリティモードを使用する場合、期限切れの証明書を交換するのが難しい場合があることに注意する必要があります。
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:
EAPパックス内で特定の認証されたプロトコルを実行するには、1.5以上のラウンドトリップが必要になる場合があることに注意してください。この場合、PAX_ACKを受信した後にEAP-SUCSESSを送信する代わりに、サーバーは添付要素を持つPAX_ACKメッセージの送信を続けることができます。クライアントは、これらのPAX_ACKメッセージに、より多くのADE要素を含む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パックスパケット交換の拡張図
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、 "authentication key"、e）o mk = pax-kdf-16（ak、 "master key"、e）o ck = pax-kdf-16（mk、 "確認キー"、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、「マスターセッションキー」、e）o EMSK = PAX-KDF-64（MK、 "拡張マスターセッションキー"、e）o iv = pax-kdf-64（0x00^16、 "initialization vector"、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は、ASCIIでは、コロンやダッシュなどのオクテットデリミターがない32の16進数文字として表されます。
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 Method-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パックスを安全にするためには、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_STD-3またはPAX_SEC-5に応じてPAX-ackが受信された場合、サーバーはEAP-SUCSESSメッセージを送信する必要があります。これは、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)
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交換されたキーであるキーのパブリック識別子を保護するために使用されるsecretキー
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
o m_i = mac_x（y || z || i）、私は8ビットの符号なし整数o l =天井（w/16）o f（a、b）=バイナリデータの最初のaオクテットですb
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の2つの値については、次のようになります。
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）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）
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パックスヘッダーで指定されています。
In this section, the packet format and content for the EAP-PAX messages are defined.
このセクションでは、EAPパックスメッセージのパケット形式とコンテンツが定義されています。
EAP-PAX packets have the following structure:
--- 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パックスパケット構造
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パックスにEAPメソッドタイプ46を割り当てました。したがって、EAPヘッダーのタイプフィールドは46でなければなりません。
The OP-Code field is one of the following values:
OPコードフィールドは、次の値の1つです。
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
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ビットに分割されています。フィールドは、論理または次の値のとして定義されます。
o 0x01 : more fragments (MF)
o 0x02 : certificate enabled (CE)
o 0x04 : ADE Included (AI)
o 0x08 - 0x80 : reserved
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要素の存在を示します。AIは、ADE要素が含まれている場合は、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：hmac_sha1_128 [fips198] [fips180] o 0x02：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]
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]
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を使用する場合、使用されるハッシュアルゴリズムとマスク生成アルゴリズムは、All-Zeroキーを使用してキー付きMAC IDで指定されたMACでなければなりません。ラベルはヌルでなければならない。
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:
次のCiphersuiteは、実装するために必須であり、約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グループ14（2048ビット）O RSA-PKCS1-V1_5（2048ビット公開キーをお勧めします）
The following ciphersuite is RECOMMENDED and achieves 128 bits of security:
次のCiphersuiteが推奨され、128ビットのセキュリティを実現します。
o HMAC_SHA256_128 o IANA DH Group 15 (3072 bits) o RSAES-OAEP (RECOMMEND 3072-bit public key)
o hmac_sha256_128 o iana dhグループ15（3072ビット）o rsaes-oaep（推奨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は、フィールドを定義し、どの順序で連結するかを定義します。簡単にし、多くのフィールドの長さはCiphersuiteによって変化する可能性があるため、各値は、以下に説明するように整数としてエンコードされた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.
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のペイロードのエンコードです。3つの基本的な手順は、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を作成するには、まずマケッドになるバッファーを形成する必要があります。この例では、キーアップデートが行われておらず、結果が16オクテット値になるようにhmac_sha1_128が使用されていると仮定します。
--- 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
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はパケットヘッダーとペイロードをマッキングして計算され、ペイロード後に追加されます（セクション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要素の前には、2オクセットの長さLがあります。各サブレメントには、最初に2オクセットの長さのLIが続いて2オクテット型TIが続きます。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 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:
o 0x01：ベンダー固有のo 0x02：クライアントチャネルバインディングデータo 0x03：サーバーチャネルバインディングデータタイプコードを使用したサブードの最初の3オクテット0x01は、IANAに登録されているベンダーのエンタープライズ番号[RFC3232]でなければなりません。このようなサブードの形式は次のとおりです。
--- 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.
チャネルバインディングサブデはまだ定義されていません。将来のIETFドキュメントでは、これらのサブードフィールドの形式を指定します。
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パックスヘッダー、EAPパックスペイロードなど、EAPパケット全体のMacとして計算されます。MACは、EAPパックスヘッダーのMac IDで指定されたMacタイプを使用して、16オクテットのICKを使用してキー化されています。タイプPAX_STD-1、PAX_SEC-1、PAX_SEC-2、およびPAX_SEC-3のパケットの場合、MKはまだ導出されていません。
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つは、敵が多くの能力を持っていると想定する必要があります。一般に、クライアントとサーバー間のすべてのメッセージが敵を介して配信されると想定する必要があります。これにより、受動的な攻撃者はすべてのトラフィックを盗聴できますが、アクティブな攻撃者は配達前に何らかの方法でデータを変更できます。
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_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.
ID保護のためにPAX_SECを使用し、CAに署名した証明書を使用しない場合、攻撃者はクライアントに自分のユーザー名を明らかにするよう説得できます。これを達成するために、攻撃者は単に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パケットを妨害することによりキー状態を非同期化する攻撃を防ぐ必要があります。主要な非同期攻撃を防ぐ、より提案された実装戦略については、付録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.
This section describes EAP-PAX in terms of specific security terminology as required by [RFC3748].
このセクションでは、[RFC3748]で要求される特定のセキュリティ用語の観点からEAPパックスについて説明します。
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.
サーバーからの最初のパケットで、サーバーはパケットヘッダーのciphersuiteを指定します。サーバーは、Ciphersuiteを完全に制御しています。したがって、指定されたCiphersuiteをサポートしていないクライアントは認証できません。さらに、各クライアントのローカルセキュリティポリシーでは、クライアントが受け入れる安全な暗号スーツを指定する必要があります。PAX_STD-1およびPAX_SEC-1で指定されたCipherSuiteは、同じ認証セッション内の連続したパケットで同じままでなければなりません。後のパケットはICKでキー付きICVでカバーされているため、サーバーは元々送信されたCiphersuiteが敵によって変更されていないことを確認できます。
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パックスは、各パケットを前のパケットに暗号化することにより、攻撃を再生することを避けるように本質的に設計されています。また、EAPシーケンス番号はICVでカバーされ、攻撃を再生するための抵抗をさらに強化します。
With identity protection enabled, PAX_SEC provides full confidentiality.
ID保護が有効になっているため、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.
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パックスでは、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パックス用に定義されている将来のCiphersuitesには、最低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パックスは、弱いパスワードが最初に使用され、サーバーが認証のために証明書を使用していない場合を除き、辞書攻撃に耐性があります。辞書攻撃に対する抵抗の詳細については、セクション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を発見できる場合、その値はその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パックスを拡張して、サブードフィールドを使用してチャネルバインディングをサポートできます。
EAP-PAX does not include any cryptographic binding. This is relevant only for tunneled methods.
EAPパックスには、暗号化の結合は含まれていません。これは、トンネルメソッドにのみ関連します。
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は、攻撃者がNAKSを使用してEAPクライアントとサーバーに安全性の低いメソッドを使用するよう説得し、NAKメッセージのメソッド固有の整合性保護を使用して防止できる攻撃の影響を受けやすくなります。EAPパックスには、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：hmac_sha1_128 o 0x02：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
Public Key ID Namespace:
o 0x00 : NONE
o 0x01 : RSAES-OAEP
o 0x02 : RSA-PKCS1-V1_5
o 0x03 : El-Gamal Over NIST ECC Group P-256
ADE Type Namespace:
ADEタイプ名空間：
o 0x01 : Vendor Specific o 0x02 : Client Channel Binding Data o 0x03 : Server Channel Binding Data
o 0x01：ベンダー固有のo 0x02：クライアントチャネルバインディングデータo 0x03：サーバーチャネルバインディングデータ
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日間が経過する前に、指定された専門家は登録要求を承認または拒否し、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.
著者は、ジョナサン・カッツが証明可能なセキュリティ、技術ガイダンスについてはバーナード・アボバ、彼の専門家レビューのためのジャリ・アークコ、フィードバックと提案についてはフローレント・ベルサニに感謝します。最後に、著者は、この作業に最初に資金を提供してくれた防衛情報システム機関に感謝したいと思います。
[FIPS180] National Institute for Standards and Technology, "Secure Hash Standard", Federal Information Processing Standard 180-2, August 2002.
[FIPS180]国立標準技術研究所、「Secure Hash Standard」、連邦情報処理標準180-2、2002年8月。
[FIPS186] National Institute for Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standard 186, May 1994.
[FIPS186]国立標準技術研究所、「デジタル署名標準（DSS）」、1994年5月、連邦情報処理標準186。
[FIPS198] National Institute for Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", Federal Information Processing Standard 198, March 2002.
[FIPS198]国立標準技術研究所、「キードハッシュメッセージ認証コード（HMAC）」、2002年3月、連邦情報処理標準198。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Reynolds、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.、Polk、W.、Ford、W.、およびD. Solo、「インターネット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] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（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. Kojo、「インターネットキーエクスチェンジ（IKE）のためのよりモジュラー指数（MODP）Diffie-Hellmanグループ」、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.、Blunk、L.、Vollbrecht、J.、Carlson、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.
[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. Moore、「ポイントツーポイントプロトコル（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.
[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.、Simon、D.、Arkko、J.、Eronen、P。、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）キー管理フレームワーク」、進行中の作業。
[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 Standard 802.11-1997、1997。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631] Rescorla、E。、「Diffie-Hellman Key Asmatement Method」、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] Orman、H。およびP. Hoffman、「対称キーの交換に使用される公共キーの強度の決定」、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] Stanley、D.、Walker、J。、およびB. Aboba、「ワイヤレスLANSの拡張可能な認証プロトコル（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、「The Secure Shell（SSH）認証プロトコル」、RFC 4252、2006年1月。
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ビットキーが認証プロセスをブートストラップするために使用できない場合、何らかの弱いプレッシャーキーから生成する必要があります。ハッシュプロセスのセキュリティは、パスワードのエントロピーを大幅に減少させない限り、重要ではないことに注意してください。辞書攻撃に対する抵抗は、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 Data暗号化標準（DES）キーやMD4ハッシュされたMicrosoftチャレンジハンドシェイク認証プロトコル（MSCHAP）パスワードなど、他のPreshared資格情報を使用する場合、クライアントをプロビジョニングする前に、これらのキーを使用する前にSHA-1に配置する必要があります。。これは、資格情報を妥協の可能性から保護するのに役立ち、物事を均一に保ちます。例として、既存のKerberos資格情報を使用してプロビジョニングを検討してください。最初のキー計算はSHA1_128（String2Key（パスワード））です。string2key（パスワード）を保存するKDCも、この初期キー値を計算することができます。
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つの実装戦略について説明します。1つ目は、IEEE 802.11i認証のエンタープライズネットワークにEAPパックスを実装および展開する最善の方法について説明します。2番目は、3Gスタイルの携帯電話ネットワークでデバイス認証にEAPパックスを使用する方法について説明しています。
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 既存の認証フレームワークは、たとえば、Microsoft 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ネットワークの2つの最大の課題は、複数のデバイスの重要なプロビジョニングとサポートです。したがって、クライアントのネットワークアクセス識別子（NAI）には、Format Username/Kid@Realmを持つことをお勧めします。ここでは、KIDは異なるデバイスを区別するために使用できるキーIDです。
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.
クライアントのサプリカントは、さまざまなソースを使用して子供を自動的に生成できます。より良い選択の2つは、おそらくコンピューターのNetBios名、またはローカルイーサネットアダプターのMACアドレスです。ユーザーは複数のシステム用のPCCARDアダプターが1つしかない可能性があるため、ワイヤレスアダプターのアドレスは最適ではない場合があります。
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.
認証システムが既に導入されている場合、プロビジョニングされたキーには自然な選択があります。クライアントは、既存のパスワードを使用して認証できます。サーバーが新しい子供と一緒に表示されると、サーバーに新しいキーレコードを作成し、プロビジョニングされたキーとしてユーザーの現在のパスワードを使用できます。たとえば、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を検証するために両方を使用しようとする必要があります。クライアントが新しいキーを使用して正常に認証すると、サーバーは古いキーを破棄する必要があります。これにより、非同期攻撃が防止されます。
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桁のピンを顧客に発行することで簡単に実現できます。
Authors' Addresses
著者のアドレス
T. Charles Clancy DoD Laboratory for Telecommunications Sciences 8080 Greenmeade Drive College Park, MD 20740 USA
T. Charles Clancy Dod Laboratory for Telecommunications Sciences 8080 Greenmeade Drive College Park、MD 20740 USA
EMail: clancy@ltsnet.net
William A. Arbaugh University of Maryland Department of Computer Science College Park, MD 20742 USA
ウィリアムA.アーボーメリーランド大学コンピュータサイエンスカレッジパーク、メリーランド州20742米国
EMail: waa@cs.umd.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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.
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。