RFC4746 日本語訳
4746 Extensible Authentication Protocol (EAP) Password AuthenticatedExchange. T. Clancy, W. Arbaugh. November 2006. (Format: TXT=63471 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Clancy
Request for Comments: 4746 LTS
Category: Informational W. Arbaugh
UMD
November 2006
コメントを求めるワーキンググループT.クランシー要求をネットワークでつないでください: 4746年のLTSカテゴリ: 情報のW.Arbaugh UMD2006年11月
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).
IETFが信じる著作権(C)(2006)。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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(パスワードAuthenticated eXchange)と呼ばれる拡張認証プロトコル(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
1. 序論…2 1.1. 言語要件…3 1.2. 用語…3 2. 概要…5 2.1. 接吻礼_STDは議定書を作ります…6 2.2. 接吻礼_SECプロトコル…7 2.3. データ交換を認証します…9 2.4. キー派生…10 2.5. 検証要件…11 2.6. 接吻礼の主要な派生機能…12 3. 仕様を議定書の中で述べてください…13 3.1. ヘッダー仕様…13 3.1.1. 演算コード…13 3.1.2. 旗…14
Clancy & Arbaugh Informational [Page 1] RFC 4746 EAP-PAX November 2006
[1ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
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
3.1.3. MAC ID…14 3.1.4. DHはIDを分類します…14 3.1.5. 公開鍵ID…15 3.1.6. 実装するために義務的…15 3.2. 有効搭載量形式…16 3.3. 認証されたデータは(ADE)を交換します…18 3.4. 保全チェック価値(ICV)…19 4. セキュリティ問題…19 4.1. サーバ証明書…20 4.2. サーバセキュリティ…20 4.3. EAPセキュリティクレーム…21 4.3.1. Ciphersuite交渉を保護します…21 4.3.2. 互いの認証…21 4.3.3. 保全保護…21 4.3.4. 保護を再演してください…21 4.3.5. 秘密性…21 4.3.6. キー派生…21 4.3.7. 主要な強さ…22 4.3.8. 辞書攻撃抵抗…22 4.3.9. 速く再接続してください…22 4.3.10. セッション独立…22 4.3.11. 断片化…23 4.3.12. 拘束力があった状態で、精神を集中してください…23 4.3.13. 暗号の結合…23 4.3.14. 交渉攻撃防止…23 5. IANA問題…23 6. 承認…24 7. 参照…24 7.1. 標準の参照…24 7.2. 有益な参照…25 パスワードからの付録A.キー生成… 27 付録B.実装提案… 27 B.1。 WiFi企業網… 27 B.2。 携帯電話ネットワーク… 28
1. Introduction
1. 序論
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(パスワードAuthenticated eXchange)は認証のために共有されたキーを使用することで設計された拡張認証プロトコル(EAP)メソッド[RFC3748]です。 それは2の別々の「副-プロトコル」、PAX_STD、およびPAX_SECを利用します。 PAX_STDはAuthenticated Data Exchange(ADE)をサポートして、共有されたキーを使用する互いの認証のための簡単で、軽量のプロトコルです。 PAX_SECは、サーバサイド公開鍵を使用することで共有されて主要な食糧を供給するのとアイデンティティ保護のサポートを提供することによって、PAX_STDの補足となります。
Clancy & Arbaugh Informational [Page 2] RFC 4746 EAP-PAX November 2006
[2ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
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を動機づける考えは簡単なパーソナルIdentification Number(暗証番号)によって独力で進まれたデバイス認証に関する願望です。 弱いキーが使用されているか、または満了の期間が経過したなら、認証サーバは主要なアップデートを強制します。 対称鍵交換を使用するよりむしろ、クライアントとサーバはディフィーのヘルマンのキー交換を実行します。(それは、前進の秘密保持を提供します)。
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サーバが信じられた認証局(カリフォルニア)によって署名された証明書を使用するのを必要とします。 より弱いモードで、PAX_に食糧を供給する間、SECは中央の男性への被害を受け易い辞書攻撃です。 最も強いモードで、EAP-PAXはRandomの下でオラクルがモデルであると証明可能に機密保護することです。
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は強い主要な材料の世代をサポートします。 互いの認証。 脱同期化への抵抗、辞書、および介入者攻撃。 保護された交渉があるciphersuite伸展性。 アイデンティティ保護。 そして、チャンネルに結合を実装することの役に立つデータの認証された交換。 これらの特徴は無線LAN[RFC4017]のためのEAPメソッド要件を満たします、EAP-PAXをIEEE802.11など[IEEE.80211]のワイヤレスの環境に理想的にして。
1.1. Language Requirements
1.1. 言語要件
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.2. Terminology
1.2. 用語
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
Network Access Identifier(NAI)[RFC4282]として指定されたCID Userによって供給されたクライアントIDは八重奏を65535に制限しました。
g
public Diffie-Hellman generator, typically the integer 2 [RFC2631]
g公共のディフィー-ヘルマンジェネレータ、通常整数2[RFC2631]
Clancy & Arbaugh Informational [Page 3] RFC 4746 EAP-PAX November 2006
[3ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
M
128-bit random integer generated by the server
128ビットの無作為の整数がサーバで生成したM
N
128-bit random integer generated by the client
クライアントによって生成されたN128ビットの無作為の整数
X
256-bit random integer generated by the server
サーバによって生成されたX256ビットの無作為の整数
Y
256-bit random integer generated by the client
クライアントによって生成されたY256ビットの無作為の整数
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
MKから生成されて、AKに関する知識を立証するのに認証の間に使用されるCK Confirmation Key
EMSK
Extended Master Session Key also generated from the MK and
containing additional keying material
また、EMSK Extended Master Session Keyは、MKと追加合わせることを含むので、材料を生成しました。
IV
Initialization Vector used to seed ciphers; exported to the
authenticator
IV初期設定Vectorは以前はよく暗号に種を蒔いていました。 固有識別文字にエクスポートされます。
MID
Method ID used to construct the EAP Session ID and consequently
name all the exported keys [IETF.KEY]
MID Method IDは、EAP Session 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 Master Key
MSK
Master Session Key generated from the MK and exported by the EAP
method to the authenticator
MKから生成されて、EAPメソッドで固有識別文字にエクスポートされたMSK Master Session Key
Clancy & Arbaugh Informational [Page 4] RFC 4746 EAP-PAX November 2006
[4ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
PK
EAP server's public key
PK EAPサーバの公開鍵
Operations:
操作:
enc_X(Y)
encryption of message Y with public key X
公開鍵XがあるメッセージYのenc_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
秘密X、識別子Y、および種子Zを使用して、出力のW八重奏を起こしながら計算されたPAX-KDF-W(X、Y、Z)PAX Key Derivation Function
||
string or binary data concatenation
|| ストリングかバイナリ・データ連結
2. Overview
2. 概要
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ステップを定義します。第1段階(発見)は基本的なリンク層プロトコルによって扱われます。 認証フェーズはここで定義されます。 主要な分配と安全な協会フェーズについて、基本的なプロトコルに異なってよって、扱われて、本書では議論しません。
+--------+ +--------+
| | EAP-Request/Identity | |
| CLIENT |<------------------------------------| SERVER |
| | | |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-PAX (STD or SEC) | |
| |<----------------------------------->| |
| | ... ... | |
| |<----------------------------------->| |
| | | |
| | EAP-Success or EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
+--------+ +--------+ | | EAP-要求/アイデンティティ| | | クライアント|<------------------------------------| サーバ| | | | | | | EAP-応答/アイデンティティ| | | |------------------------------------>| | | | | | | | EAP-接吻礼(STDかSEC)| | | |<----------------------------------->| | | | ... ... | | | |<----------------------------------->| | | | | | | | EAP-成功かEAP-失敗| | | |<------------------------------------| | +--------+ +--------+
Figure 1: EAP-PAX Packet Exchanges
図1: EAP-接吻礼パケット交換
Clancy & Arbaugh Informational [Page 5] RFC 4746 EAP-PAX November 2006
[5ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
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つの異なった「副-プロトコル」があります。 1(PAX_STD)番目は典型的な認証の間、使用されます。 2番目(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アップデートがサーバ交換ディフィー-ヘルマン解説者の実行されて、クライアントと、g^Xとg^Yであるときに(Pか楕円曲線乗法群の上で主要な計算された法です)。 アップデートを全く実行していなくて、セッションキーだけを引き出しているとき、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は可能なディフィー-ヘルマンの交換以外の純粋に左右対称の操作を使用します。
Each of the protocols is now defined.
それぞれのプロトコルは現在、定義されます。
2.1. PAX_STD Protocol
2.1. 接吻礼_STDプロトコル
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 =X o B=Y o 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 g^Y=g^X o B=o 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
ここで、AとBはディフィー-ヘルマングループサイズに従って長さが決定しているディフィー-ヘルマン解説者です。 値Aは送られたデータです。
Clancy & Arbaugh Informational [Page 6] RFC 4746 EAP-PAX November 2006
[6ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
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.
クライアント、およびサーバから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 _接吻礼STD-1: クライアント<サーバ: ○PAX_STD-2: クライアント->サーバ: B、CID、MAC_CK(A、B、CID)、[任意のADE]o PAX_STD-3: クライアント<サーバ: 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を見てください。
2.2. PAX_SEC Protocol
2.2. 接吻礼_SECプロトコル
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 接吻礼_SEC-1: クライアント<サーバ: M、PKまたはCertPK o PAX_SEC-2: クライアント->サーバ: Enc_PK(M、N、CID)o PAX_SEC-3: クライアント<サーバ: A、MAC(A、CID)o PAX_SEC-4: クライアント->サーバ: 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.
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を使用するとき伴われる危険について説明します。
Clancy & Arbaugh Informational [Page 7] RFC 4746 EAP-PAX November 2006
[7ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
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
証明書| 食糧を供給すること| アイデンティティモード| | 保護==================+=====================+====================== 証明書がありません。| MiTM、オフライン| IDは攻撃を明らかにします。| 辞書攻撃| ------------------+---------------------+--------------------- 自己に署名されます。| MiTM、オフライン| IDは攻撃Certificateを明らかにします。| 辞書攻撃| ------------------+---------------------+--------------------- 証明書/PK| MiTM、オフライン| IDは攻撃Cachingを明らかにします。| 辞書攻撃| 最初に、authの間------------------+---------------------+--------------------- カリフォルニアによって署名されます。| 安全である、互い| 安全な互いのCertificate| 認証| 認証
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を使用するとき、カリフォルニア-署名入りの証書の使用はRECOMMENDEDです。 カリフォルニア-署名入りの証書を使用しないとき、初期の認証は中央のオフライン男性(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を使用するとき、カリフォルニア-署名入りの証書か主要なキャッシュのどちらかの使用はRECOMMENDEDです。 キャッシュはEAPサーバの公開鍵を記録して、セッションSecure SHellと同様(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トランスポート・プロトコルが知られているなら、クライアントはこれらの値を区別しなければなりません。 例えば、IEEE802.11に、哀願者SHOULDは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.
Wireless LANがあるEAP-PAXを使用するクライアントSHOULDがそれを有効にするとき、証明書の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.
開いているClientsはPKの使用とCertPKの両方をサポートします。 CertPKが使用されているなら、クライアントはKeyPurposeIDを有効にしなければなりません。
Clancy & Arbaugh Informational [Page 8] RFC 4746 EAP-PAX November 2006
[8ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
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.
Clientsをキャッシュして、それが遭遇する1回目の間のそれぞれのEAPサーバのためのPKにサーバを保存してください。そうすれば、SHOULD NOTは公開鍵が変えられたサーバを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.
厳しいIn厳しいモード、クライアントは、信じられたカリフォルニアによって署名された有効な証明書を提示するためにサーバを必要とします。 他のモードで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.
サーバSHOULDは、PAX_がSEC運転モードであるとサポートします、そして、SHOULDはPAX_SECと共に両方がPKとCertPKの使用であるとサポートします。 クライアントは、PAX_がSECであるとサポートしなければならなくて、サーバから生の公開鍵と証明書の両方を受け入れることができなければなりません。ローカルの安全保障政策は、どの形式のキーか証明書認証が許されているかを定義するでしょう。 デフォルト設定SHOULDが厳しい状態で最小キャッシュ安全保障政策を必要として、必要であるかもしれません。
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にかぎ管理を実行する能力では、EAP- PAXにAKの使用で建てられます'。 しかしながら、サーバ公開鍵のかぎ管理はこのドキュメントの範囲を超えています。 自己署名入りの証書が使用されているなら、デプロイヤはキャッシュしているセキュリティモードが使用されているとき、満期の証明書は取り替えるのが難しいかもしれないのを意識しているべきです。
See Section 4 for further discussion on security considerations.
セキュリティ問題のさらなる議論に関してセクション4を見てください。
2.3. Authenticated Data Exchange
2.3. 認証されたデータ交換
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.
チャンネル結合の実装を含むさまざまな方法で、Authenticated Data Exchanged(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が暗号化されていないことに注意するのは、どんなデータも含んでいるのが秘密でないように重要です。 しかしながら、これらのパケットがIntegrity Check Value(ICV)によってすべて保護されるので、信憑性は保証されます。
Clancy & Arbaugh Informational [Page 9] RFC 4746 EAP-PAX November 2006
[9ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
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にメッセージを送り続けることができます。 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 | |
| |<------------------------------------| |
+--------+ +--------+
+--------+ +--------+ | | 接吻礼_STD-1| | | |<------------------------------------| | | | 接吻礼_STD-2、(アデ[1])| | | |------------------------------------>| | | | 接吻礼_STD-3、(アデ[2])| | | |<------------------------------------| | | | 接吻礼_ACK、(アデ[3])| | | |------------------------------------>| | | | 接吻礼_ACK、(アデ[4])| | | |<------------------------------------| | | | | | | | ... | | | | | | | | 接吻礼_ACK、(ADE[i])| | | |------------------------------------>| | | | 接吻礼_ACK(ADE[i+1])| | | |<------------------------------------| | | | | | | | ... | | | | | | | | EAP-成功かEAP-失敗| | | |<------------------------------------| | +--------+ +--------+
Figure 3: Extended Diagram of EAP-PAX Packet Exchanges
図3: EAP-接吻礼パケット交換の拡張ダイヤグラム
2.4. Key Derivation
2.4. 主要な派生
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 'AK'=PAX-KDF-16(AK、「認証キー」、E)o MKはPAX-KDF-16と等しいです。(AK、「マスターキー」、E)
Clancy & Arbaugh Informational [Page 10] RFC 4746 EAP-PAX November 2006
[10ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
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 CK=PAX-KDF-16(MK、「確認キー」、E)o ICK=PAX-KDF-16(MK、「保全チェックキー」、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と等しいです。(0×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 Method IDは32の16進キャラクタとしてコロンかダッシュなどの少しも八重奏デリミタなしで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 Key Management Framework[IETF.KEY]は名前と範囲をキーの指定に推薦します。 EAP-PAX Method-IDは上で説明されるように計算されたMID値です。 EAP同輩名はPAX_STD-2とPAX_SEC-2で交換されたCID値です。 EAPサーバー名は空のストリングです。
2.5. Verification Requirements
2.5. 検証要件
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が安全であるように、方法について各ステップで適切にMACsについて確かめなければなりません。 静かに合法化に失敗する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.
サーバは含まれているMACを有効にしなければなりません、サーバにクライアントを認証するのに役立つとき。PAX_STD-2、この合法化が失敗するなら、サーバは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 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-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 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-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 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.
Clancy & Arbaugh Informational [Page 11] RFC 4746 EAP-PAX November 2006
Clancy & Arbaugh Informational [Page 11] RFC 4746 EAP-PAX November 2006
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 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-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 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-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 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-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 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.
2.6. PAX Key Derivation Function
2.6. PAX Key Derivation Function
The PAX-KDF is a secure key derivation function used to generate various keys from the provided entropy and shared key.
The PAX-KDF is a secure key derivation function used to generate various keys from the provided entropy and shared key.
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 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
Let's define some variables and functions:
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), where i is an 8-bit unsigned integer o L = ceiling(W/16) o F(A, B) = first A octets of binary data B
We define PAX-KDF-W(X, Y, Z) = F(W, M_1 || M_2 || ... || M_L).
We define 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:
Consequently for the two values of W used in this document, we have:
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)
Clancy & Arbaugh Informational [Page 12] RFC 4746 EAP-PAX November 2006
Clancy & Arbaugh Informational [Page 12] RFC 4746 EAP-PAX November 2006
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.
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.
3. Protocol Specification
3. Protocol Specification
In this section, the packet format and content for the EAP-PAX messages are defined.
In this section, the packet format and content for the EAP-PAX messages are defined.
EAP-PAX packets have the following structure:
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 ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- 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
Figure 4: EAP-PAX Packet Structure
3.1. Header Specification
3.1. Header Specification
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.
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.
3.1.1. Op-Code
3.1.1. Op-Code
The OP-Code field is one of the following values:
The OP-Code field is one of the following values:
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 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
Clancy & Arbaugh Informational [Page 13] RFC 4746 EAP-PAX November 2006
Clancy & Arbaugh Informational [Page 13] RFC 4746 EAP-PAX November 2006
o 0x15 : PAX_SEC-5 o 0x21 : PAX-ACK
o 0x15 : PAX_SEC-5 o 0x21 : PAX-ACK
3.1.2. Flags
3.1.2. Flags
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:
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:
o 0x01 : more fragments (MF) o 0x02 : certificate enabled (CE) o 0x04 : ADE Included (AI) o 0x08 - 0x80 : reserved
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.
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.
When a payload requires fragmentation, each fragment is transmitted, and the receiving party responds with a PAX-ACK packet for each received fragment.
When a payload requires fragmentation, each fragment is transmitted, and the receiving party responds with a PAX-ACK packet for each received fragment.
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.
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.
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.
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.
3.1.3. MAC ID
3.1.3. MAC ID
The MAC field specifies the cryptographic hash used to generate the keyed hash value. The following are currently supported:
The MAC field specifies the cryptographic hash used to generate the keyed hash value. The following are currently supported:
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]
3.1.4. DH Group ID
3.1.4. DH Group ID
The Diffie-Hellman group field specifies the group used in the Diffie-Hellman computations. The following are currently supported:
The Diffie-Hellman group field specifies the group used in the Diffie-Hellman computations. The following are currently supported:
Clancy & Arbaugh Informational [Page 14] RFC 4746 EAP-PAX November 2006
Clancy & Arbaugh Informational [Page 14] RFC 4746 EAP-PAX November 2006
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]
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.
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.
3.1.5. Public Key ID
3.1.5. Public Key ID
The Public Key ID field specifies the cipher used to encrypt the client's EAP-Response in PAX_SEC-2.
The Public Key ID field specifies the cipher used to encrypt the client's EAP-Response in PAX_SEC-2.
The following are currently supported:
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 (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.
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.
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.
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.
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.
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.
3.1.6. Mandatory to Implement
3.1.6. Mandatory to Implement
The following ciphersuite is mandatory to implement and achieves roughly 112 bits of security:
The following ciphersuite is mandatory to implement and achieves roughly 112 bits of security:
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 Group 14 (2048 bits) o RSA-PKCS1-V1_5 (RECOMMEND 2048-bit public key)
The following ciphersuite is RECOMMENDED and achieves 128 bits of security:
The following ciphersuite is RECOMMENDED and achieves 128 bits of security:
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 Group 15 (3072 bits) o RSAES-OAEP (RECOMMEND 3072-bit public key)
Clancy & Arbaugh Informational [Page 15] RFC 4746 EAP-PAX November 2006
Clancy & Arbaugh Informational [Page 15] RFC 4746 EAP-PAX November 2006
3.2. Payload Formatting
3.2. Payload Formatting
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.
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.
--- octet offset --->
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---------------------
|len| value ....
+---+--------
--- 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
Figure 5: Length Encoding for Data Elements
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.
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].
Public keys and certificates SHALL be in X.509 format [RFC3280] encoded using the Distinguished Encoding Rules (DER) format [X.690].
Strings are not null-terminated and are encoded using UTF-8. Binary data, such as message authentication codes, are transmitted as-is.
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.
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.
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.
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.
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.
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.
Clancy & Arbaugh Informational [Page 16] RFC 4746 EAP-PAX November 2006
Clancy & Arbaugh Informational [Page 16] RFC 4746 EAP-PAX November 2006
--- 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 ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- 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
||
\/
|| || 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- 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
Figure 6: Example Encoding of PAX_STD-2 MAC Data
With this, we can now create the encoded payload:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- 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
Figure 7: Example Encoding of PAX_STD-2 Packet
Clancy & Arbaugh Informational [Page 17] RFC 4746 EAP-PAX November 2006
Clancy & Arbaugh Informational [Page 17] RFC 4746 EAP-PAX November 2006
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).
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).
3.3. Authenticated Data Exchange (ADE)
3.3. Authenticated Data Exchange (ADE)
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.
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.
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:
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:
--- 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... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- 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
Figure 8: Encoding of ADE Components
The following type values have been allocated:
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 : Vendor Specific o 0x02 : Client Channel Binding Data o 0x03 : Server Channel Binding Data
Clancy & Arbaugh Informational [Page 18] RFC 4746 EAP-PAX November 2006
Clancy & Arbaugh Informational [Page 18] RFC 4746 EAP-PAX November 2006
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:
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:
--- 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 ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- 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
Figure 9: Encoding of Vendor-specific ADE
Channel binding subADEs have yet to be defined. Future IETF documents will specify the format for these subADE fields.
Channel binding subADEs have yet to be defined. Future IETF documents will specify the format for these subADE fields.
3.4. Integrity Check Value (ICV)
3.4. Integrity Check Value (ICV)
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.
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.
If the ICV field is incorrect, the receiver MUST silently discard the packet.
If the ICV field is incorrect, the receiver MUST silently discard the packet.
4. Security Considerations
4. Security Considerations
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.
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.
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.
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.
Clancy & Arbaugh Informational [Page 19] RFC 4746 EAP-PAX November 2006
Clancy & Arbaugh Informational [Page 19] RFC 4746 EAP-PAX November 2006
4.1. Server Certificates
4.1. Server Certificates
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 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.
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.
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.
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.
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.
4.2. Server Security
4.2. Server Security
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.
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.
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.
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.
Clancy & Arbaugh Informational [Page 20] RFC 4746 EAP-PAX November 2006
Clancy & Arbaugh Informational [Page 20] RFC 4746 EAP-PAX November 2006
4.3. EAP Security Claims
4.3. EAP Security Claims
This section describes EAP-PAX in terms of specific security terminology as required by [RFC3748].
This section describes EAP-PAX in terms of specific security terminology as required by [RFC3748].
4.3.1. Protected Ciphersuite Negotiation
4.3.1. Protected Ciphersuite Negotiation
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.
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.
4.3.2. Mutual Authentication
4.3.2. Mutual Authentication
Both PAX_STD and PAX_SEC authenticate the client and the server, and consequently achieve explicit mutual authentication.
Both PAX_STD and PAX_SEC authenticate the client and the server, and consequently achieve explicit mutual authentication.
4.3.3. Integrity Protection
4.3.3. Integrity Protection
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.
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.
4.3.4. Replay Protection
4.3.4. Replay Protection
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 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.
4.3.5. Confidentiality
4.3.5. Confidentiality
With identity protection enabled, PAX_SEC provides full confidentiality.
With identity protection enabled, PAX_SEC provides full confidentiality.
4.3.6. Key Derivation
4.3.6. Key Derivation
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 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
Clancy & Arbaugh Informational [Page 21] RFC 4746 EAP-PAX November 2006
Clancy & Arbaugh Informational [Page 21] RFC 4746 EAP-PAX November 2006
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.
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.
4.3.7. Key Strength
4.3.7. Key Strength
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.
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.
Future ciphersuites defined for EAP-PAX MUST contain a minimum of 128 bits of security.
Future ciphersuites defined for EAP-PAX MUST contain a minimum of 128 bits of security.
4.3.8. Dictionary Attack Resistance
4.3.8. Dictionary Attack Resistance
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 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.
4.3.9. Fast Reconnect
4.3.9. Fast Reconnect
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.
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.
4.3.10. Session Independence
4.3.10. Session Independence
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.
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.
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.
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.
Session keys are independently generated using fresh nonces for each session, and therefore the sessions are independent.
Session keys are independently generated using fresh nonces for each session, and therefore the sessions are independent.
Clancy & Arbaugh Informational [Page 22] RFC 4746 EAP-PAX November 2006
Clancy & Arbaugh Informational [Page 22] RFC 4746 EAP-PAX November 2006
4.3.11. Fragmentation
4.3.11. Fragmentation
Fragmentation and reassembly is supported through the fragmentation flag in the header.
断片化と再アセンブリはヘッダーの断片化旗でサポートされます。
4.3.12. Channel Binding
4.3.12. チャンネル結合
EAP-PAX can be extended to support channel bindings through the use of its subADE fields.
subADE分野の使用でサポートチャンネル結合にEAP-PAXを広げることができます。
4.3.13. Cryptographic Binding
4.3.13. 暗号の結合
EAP-PAX does not include any cryptographic binding. This is relevant only for tunneled methods.
EAP-PAXは少しの暗号の結合も含んでいません。 トンネルを堀られたメソッドだけにおいて、これは関連しています。
4.3.14. Negotiation Attack Prevention
4.3.14. 交渉攻撃防止
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クライアントとサーバに納得させるNAKsを使用するところで攻撃に影響されやすく、NAKメッセージでメソッド特有の保全保護を使用することで防ぐことができます。 EAP-PAXがPAXの会話の始めにこの保全保護のために適当なキーを引き出させないので、これは含まれていません。
5. IANA Considerations
5. IANA問題
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 Group Public Key ID(ID)、およびADEはタイプします。 初期の名前空間人口は以下の通りです。
MAC ID Namespace:
MAC ID名前空間:
o 0x01 : HMAC_SHA1_128 o 0x02 : HMAC_SHA256_128
o 0×01: HMAC_SHA1_128o0x02: 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 0×00: NONE o0x01: IANA DH Group14o0x02: IANA DH Group15o0x03: NIST ECCグループP-256
Clancy & Arbaugh Informational [Page 23] RFC 4746 EAP-PAX November 2006
[23ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
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 0×00: NONE o0x01: RSAES-OAEP o0x02: RSA-PKCS1-V1_5o0x03: NIST ECCグループP-256の上の高架鉄道-Gamal
ADE Type Namespace:
ADEは名前空間をタイプします:
o 0x01 : Vendor Specific o 0x02 : Client Channel Binding Data o 0x03 : Server Channel Binding Data
o 0×01: ベンダーSpecific o0x02: クライアントChannel Binding Data o0x03: サーバのチャンネルの拘束力があるデータ
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によって任命されたDesignated Expertによって見直されるものとします。 Designated ExpertはコメントとレビューのためのEAP WGメーリングリスト(または、Designated Expertによって任命された後継者)に要求を掲示するでしょう、インターネット草稿を含んでいて。 30日間の期間が経過する前に、Designated Expertは登録要求を承認するか、または否定して、EAP WGメーリングリストとの決定の通知かIANAに知らせることと同様にその後継者を発表するでしょう。 説明で否定通知を正当化しなければなりません、そして、可能であることで、それがそうである場合では、提案は具体的であってください。許容できるようになるようにどう要求を変更できるかに関して。
6. Acknowledgments
6. 承認
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、およびフィードバックと提案のためのフローラン・ベルサニに関してジョナサン・キャッツに感謝したがっています。 最終的に、作者は、この仕事に資金を供給しながら、初めはについて防衛情報システム庁に感謝したがっています。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[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がそうするかもしれません。
[FIPS198] National Institute for Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", Federal
Information Processing Standard 198, March 2002.
2002年3月の規格と技術の[FIPS198]国家の研究所、「合わせられたハッシュメッセージ立証コード(HMAC)」連邦情報処理基準198。
Clancy & Arbaugh Informational [Page 24] RFC 4746 EAP-PAX November 2006
[24ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[RFC3232] レイノルズ、J.、「数は割り当てられました」。 「RFC1700はOn-系列DatabaseによるReplacedです」、RFC3232、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.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(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インチ、RFC3447、2月2003日
[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、「より多くのModular Exponential(MODP)ディフィー-ヘルマンはインターネット・キー・エクスチェンジ(IKE)のために分類します」、RFC3526、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.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
2005年12月の[RFC4282]AbobaとB.と用務員とM.とArkko、J.とP.Eronen、「ネットワークアクセス識別子」RFC4282。
[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)であるとサポートする拡大と属性を証明します」、RFC4334、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]国際Telecommunications Union、「情報技術--ASN.1コード化は以下を統治します」。 「基本的な符号化規則(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)の仕様」、データ網、およびオープンシステムコミュニケーション推薦X.690(2002年7月)。
7.2. Informative References
7.2. 有益な参照
[IETF.KEY] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H.
Levkowetz, "Extensible Authentication Protocol (EAP) Key
Management Framework", Work in Progress.
B.、サイモン、D.、Arkko、J.、Eronen、P.、およびH.Levkowetz、「拡張認証プロトコル(EAP)Key Managementフレームワーク」という[IETF.KEY]Abobaは進行中で働いています。
Clancy & Arbaugh Informational [Page 25] RFC 4746 EAP-PAX November 2006
[25ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
[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] 米国電気電子技術者学会、「情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--特定のRequirements Part11:、」 「ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様」、IEEE規格802.11-1997、1997。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, June 1999.
[RFC2631] レスコラ、E.、「ディフィー-ヘルマンの主要な協定メソッド」、RFC2631、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.ホフマン、「対称鍵を交換するのに使用される公開鍵のために強さを測定する」BCP86、RFC3766、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)メソッド要件」、RFC4017(2005年3月)。
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006.
[RFC4252] YlonenとT.とC.Lonvick、「セキュア・シェル(セキュアシェル (SSH))認証プロトコル」、RFC4252、2006年1月。
Clancy & Arbaugh Informational [Page 26] RFC 4746 EAP-PAX November 2006
[26ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
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ビットのキーが認証過程を独力で進むために利用可能でないなら、ある種の弱い前共有されたキーから生成しなければなりません。 論じ尽くすプロセスのセキュリティが重要でないことに注意してください、パスワードのエントロピーをかなり減少させない限り。 辞書攻撃への抵抗はPAX_SECによって提供されます。 その結果、パスワードのSHA-1を計算して、128ビットに出力に先端を切らせるのは、弱いパスワードを食糧を供給するキーに変換する手段としてRECOMMENDEDです。
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.
使用される前にケルベロスデータ暗号化規格(DES)キー、またはMD4によって論じ尽くされたマイクロソフトチャレンジハンドシェイク式認証プロトコル(MSCHAP)パスワードなどの他の前共有された資格証明書を支給クライアント、これらのキーSHOULDに使用するのが、まだいつかがSHA-1を通します。 これは、可能な感染から資格証明書を保護するのに役立って、また、事態を一定に保ちます。 例として、食糧を供給すると既存のケルベロス資格証明書を使用することで考えてください。 初期の主要な計算はSHA1_128であるかもしれません(string2key(パスワード))。 また、string2key(パスワード)を保存して、KDCはこの初期のキー値を計算できるでしょう。
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つの実装戦略について議論します。 1番目は、IEEE 802.11i認証のためにどのようにEAP-PAXを企業網で最もよく実装して、配布するかを説明します。 2番目はデバイス認証に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ドメインかケルベロス分野です。
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
2つの企業WiFiネットワークで最も大きい挑戦は、複数のデバイスの主要な食糧を供給するのとサポートです。 その結果、クライアントのNetwork Access Identifier(NAI)がお勧めであったのはお勧めです。
Clancy & Arbaugh Informational [Page 27] RFC 4746 EAP-PAX November 2006
[27ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
the format username/KID@realm, where KID is a key ID that can be used to distinguish between different devices.
形式 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.
クライアントの哀願者は、自動的にKIDを生成するのにさまざまなソースを使用できます。 2つのより良い選択が、おそらくコンピュータの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のための哀願者は、サーバで証明可能なキーを生成するのにマイクロソフトの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個のキーが存在していると、サーバは、伝えられたパケットの上でMACsを有効にするのに両方を使用するのを試みるべきです。 クライアントがいったん首尾よく新しいキー、サーバが認証するべきである使用を認証する後、古いキーを捨ててください。 これは脱同期化攻撃を防ぎます。
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.
携帯電話システムでは、私たちはもう複数の1アイデンティティあたりのキーを支えるのを心配する必要はありません。 おそらく、各モバイル機器には、ユニークなアイデンティティがあります。 しかしながら、複数の1アイデンティティあたりのデバイスが望まれているなら、セクションB.1に提示されたそれと同様のメソッドは使用されるかもしれません。
Provisioning could easily be accomplished by issuing customers a 6- digit PIN they could type into their phone's keypad.
彼らが彼らの電話のキーパッドにタイプできた6ケタ暗証番号を顧客に発行することによって、容易に食糧を供給することを達成できるでしょう。
Clancy & Arbaugh Informational [Page 28] RFC 4746 EAP-PAX November 2006
[28ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
Authors' Addresses
作者のアドレス
T. Charles Clancy DoD Laboratory for Telecommunications Sciences 8080 Greenmeade Drive College Park, MD 20740 USA
テレコミュニケーション科学8080Greenmeade Drive MD20740カレッジパーク(米国)へのT.チャールズクランシーDoD研究所
EMail: clancy@ltsnet.net
メール: clancy@ltsnet.net
William A. Arbaugh University of Maryland Department of Computer Science College Park, MD 20742 USA
ウィリアム・A.Arbaughメリーランド大学コンピュータサイエンス学部MD20742カレッジパーク(米国)
EMail: waa@cs.umd.edu
メール: waa@cs.umd.edu
Clancy & Arbaugh Informational [Page 29] RFC 4746 EAP-PAX November 2006
[29ページ]RFC4746EAP-接吻礼2006年11月の情報のクランシーとArbaugh
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信頼、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Clancy & Arbaugh Informational [Page 30]
クランシーとArbaugh情報です。[30ページ]
一覧
スポンサーリンク
