Network Working Group N. Cam-Winget
Request for Comments: 5422 D. McGrew
Category: Informational J. Salowey
H. Zhou
Cisco Systems
March 2009
Dynamic Provisioning Using Flexible Authentication via
Secure Tunneling Extensible Authentication Protocol (EAP-FAST)
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
IESG Note
IESG注意
EAP-FAST has been implemented by many vendors and it is used in the Internet. Publication of this specification is intended to promote interoperability by documenting current use of existing EAP methods within EAP-FAST.
EAP-FASTは、多くのベンダーによって実装されており、それがインターネットで使用されています。この仕様書の発行は、EAP-FAST内に存在するEAPメソッドの現在の使用を文書化することにより、相互運用性を促進することを意図しています。
The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type code assigned to EAP-MSCHAPv2 (26) for authentication within an anonymous TLS tunnel. In order to minimize the risk associated with an anonymous tunnel, changes to the method were made that are not interoperable with EAP-MSCHAPv2. Since EAP-MSCHAPv2 does not support method-specific version negotiation, the use of EAP-FAST-MSCHAPv2 is implied by the use of an anonymous EAP-FAST tunnel. This behavior may cause problems in implementations where the use of unaltered EAP-MSCHAPv2 is needed inside an anonymous EAP-FAST tunnel. Since such support requires special case execution of a method within a tunnel, it also complicates implementations that use the same method code both within and outside of the tunnel method. If EAP-FAST were to be designed today, these difficulties could be avoided by utilization of unique EAP Type codes. Given these issues, assigned method types must not be re-used with different meaning inside tunneled methods in the future.
EAP方式EAP-FAST-MSCHAPv2を匿名TLSトンネル内認証のためにEAP-MSCHAPv2の（26）に割り当てられたEAPタイプコードを再利用します。匿名トンネルに関連するリスクを最小限にするために、方法への変更は、EAP-MSCHAPv2をと相互運用可能ではないことを行いました。 EAP-MSCHAPv2のメソッド固有のバージョンネゴシエーションをサポートしていないので、EAP-FAST-MSCHAPv2をの使用は匿名EAP-FASTトンネルの使用によって暗示されています。この動作は変更されていないEAP-MSCHAPv2をの使用は匿名EAP-FASTトンネル内で必要とされている実装で問題が発生することがあります。そのような支持体は、トンネル内の方法の特別なケースの実行を必要とするので、それはまた、内部に、トンネル方式の外に、両方同じ方法コードを使用する実装を複雑にします。 EAP-FASTは、今日に設計されるならば、これらの困難は、固有のEAPタイプコードを利用して回避することが可能です。これらの問題を考えると、割り当てられた方法の種類は、将来的にトンネリングされたメソッド内の別の意味で再使用することはできません。
Abstract
抽象
The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP-FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning.
セキュアなトンネリング拡張認証プロトコル（EAP-FAST）メソッドを介してフレキシブル認証は、相互認証されたトンネルを確立するために、トランスポート層セキュリティ（TLS）を使用して、ピアとサーバ間でセキュアな通信を可能にします。 EAP-FASTは、この保護されたトンネルを介してプロビジョニング資格情報または他の情報を可能にします。この文書では、動的なプロビジョニングのためのEAP-FASTの使用を記載しています。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Specification Requirements .................................4
1.2. Terminology ................................................4
2. EAP-FAST Provisioning Modes .....................................5
3. Dynamic Provisioning Using EAP-FAST Conversation ................6
3.1. Phase 1 TLS Tunnel .........................................7
3.1.1. Server-Authenticated Tunnel .........................7
3.1.2. Server-Unauthenticated Tunnel .......................7
3.2. Phase 2 - Tunneled Authentication and Provisioning .........7
3.2.1. Server-Authenticated Tunneled Authentication ........8
3.2.2. Server-Unauthenticated Tunneled Authentication ......8
3.2.3. Authenticating Using EAP-FAST-MSCHAPv2 ..............8
3.2.4. Use of Other Inner EAP Methods for EAP-FAST
Provisioning ........................................9
3.3. Key Derivations Used in the EAP-FAST Provisioning
Exchange ..................................................10
3.4. Peer-Id, Server-Id, and Session-Id ........................11
3.5. Network Access after EAP-FAST Provisioning ................11
4. Information Provisioned in EAP-FAST ............................12
4.1. Protected Access Credential ...............................12
4.1.1. Tunnel PAC .........................................13
4.1.2. Machine Authentication PAC .........................13
4.1.3. User Authorization PAC .............................13
4.1.4. PAC Provisioning ...................................14
4.2. PAC TLV Format ............................................15
4.2.1. Formats for PAC Attributes .........................16
4.2.2. PAC-Key ............................................16
4.2.3. PAC-Opaque .........................................17
4.2.4. PAC-Info ...........................................18
4.2.5. PAC-Acknowledgement TLV ............................20
4.2.6. PAC-Type TLV .......................................21
4.3. Trusted Server Root Certificate ...........................21
4.3.1. Server-Trusted-Root TLV ............................22
4.3.2. PKCS#7 TLV .........................................23
5. IANA Considerations ............................................24
6. Security Considerations ........................................25
6.1. Provisioning Modes and Man-in-the-Middle Attacks ..........25
6.1.1. Server-Authenticated Provisioning Mode and
Man-in-the-Middle Attacks ..........................26
6.1.2. Server-Unauthenticated Provisioning Mode
and Man-in-the-Middle Attacks ......................26
6.2. Dictionary Attacks ........................................27
6.3. Considerations in Selecting a Provisioning Mode ...........28
6.4. Diffie-Hellman Groups .....................................28
6.5. Tunnel PAC Usage ..........................................28
6.6. Machine Authentication PAC Usage ..........................29
6.7. User Authorization PAC Usage ..............................29
6.8. PAC Storage Considerations ................................29
6.9. Security Claims ...........................................31
7. Acknowledgements ...............................................31
8. References .....................................................31
8.1. Normative References ......................................31
8.2. Informative References ....................................32
Appendix A. Examples .............................................33
A.1. Example 1: Successful Tunnel PAC Provisioning .............33
A.2. Example 2: Failed Provisioning ............................35
A.3. Example 3: Provisioning an Authentication Server's
Trusted Root Certificate ..................................37
EAP-FAST [RFC4851] is an EAP method that can be used to mutually authenticate the peer and server. Credentials such as a pre-shared key, certificate trust anchor, or a Protected Access Credential (PAC) must be provisioned to the peer before it can establish mutual authentication with the server. In many cases, the provisioning of such information presents deployment hurdles. Through the use of the protected TLS [RFC5246] tunnel, EAP-FAST can enable dynamic in-band provisioning to address such deployment obstacles.
EAP-FAST [RFC4851]は互いにピア及びサーバを認証するために使用することができるEAP方法です。それは、サーバとの相互認証を確立する前に、このような事前共有鍵、証明書のトラストアンカー、または保護アクセス資格情報（PAC）などの資格情報は、ピアにプロビジョニングする必要があります。多くの場合、そのような情報の提供を展開ハードルを提示します。保護されたTLS [RFC5246]トンネルの使用を介して、EAP-FASTは、展開の障害に対処するために、動的帯域内プロビジョニングを可能にすることができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Much of the terminology used in this document comes from [RFC3748]. The terms "peer" and "server" are used interchangeably with the terms "EAP peer" and "EAP server", respectively. Additional terms are defined below:
このドキュメントで使用される用語の多くは、[RFC3748]から来ています。用語「ピア」と「サーバ」は、それぞれ、用語「EAPピア」および「EAPサーバ」と互換的に使用されます。追加の用語を以下に定義されています。
Man in the Middle (MITM)
中間者（MITM）
An adversary that can successfully inject itself between a peer and EAP server. The MITM succeeds by impersonating a valid peer or server.
成功したピアとEAPサーバの間自体を注入することができます敵。 MITMは、有効なピアまたはサーバを偽装することで成功しています。
Provisioning
プロビジョニング
Providing a peer with a trust anchor, shared secret, or other appropriate information needed to establish a security association.
トラストアンカー、共有秘密、またはセキュリティアソシエーションを確立するために必要な他の適切な情報を持つピアを提供します。
Protected Access Credential (PAC)
保護アクセス資格情報（PAC）
Credentials distributed to a peer for future optimized network authentication. The PAC consists of at most three components: a shared secret, an opaque element, and optional information. The shared secret part contains the secret key shared between the peer and server. The opaque part contains the shared secret encrypted by a private key only known to the server. It is provided to the peer and is presented back to the server when the peer wishes to obtain access to network resources. Finally, a PAC may optionally include other information that may be useful to the peer.
資格情報は、将来の最適化されたネットワーク認証のためにピアに配布します。共有秘密、不透明要素、およびオプションの情報：PACは、最大で3つのコンポーネントで構成されています。共有秘密の部分は、ピアとサーバの間で共有秘密鍵が含まれています。不透明な部分のみをサーバーに知られている秘密鍵で暗号化された共有秘密が含まれています。これは、ピアに提供され、ピアがネットワークリソースへのアクセスを得たいときにサーバーに戻って提示されます。最後に、PACは、必要に応じて、ピアに有用であり得る他の情報を含むことができます。
Tunnel PAC
トンネルPAC
A set of credentials stored by the peer and consumed by both the peer and the server to establish a TLS tunnel.
資格情報のセットは、ピアにより記憶されたピアとTLSトンネルを確立するためにサーバの両方によって消費されます。
User Authorization PAC
ユーザー認証PAC
A User Authorization PAC is server-encrypted data containing authorization information associated with a previously authenticated user. The User Authorization PAC does not contain a key, but rather it is generally bound to a Tunnel PAC, which is used with the User Authorization PAC.
ユーザー認証PACは、以前に認証されたユーザに関連付けられた認証情報を含むサーバー、暗号化されたデータです。ユーザー認証PACは、キーが含まれていませんが、むしろそれは、一般的にユーザー認証PACで使用されるトンネルPAC、にバインドされています。
Machine Authentication PAC
マシン認証PAC
A Machine Authentication PAC contains server-encrypted data containing authorization information associated with a device. A Machine Authentication PAC may be used instead of a Tunnel PAC to establish the TLS tunnel to provide machine authentication and authorization information. The Machine Authentication PAC is useful in cases where the machine needs to be authenticated and authorized to access a network before a user has logged in.
マシン認証PACは、デバイスに関連付けられた認証情報を含むサーバーで暗号化されたデータが含まれています。マシン認証PACは、マシン認証および認可情報を提供するためにTLSトンネルを確立する代わりにトンネルPACを用いてもよいです。マシン認証PACは、マシンが認証され、ユーザーがログインする前にネットワークへのアクセスを許可する必要がある場合に便利です。
EAP-FAST supports two modes for provisioning:
EAP-FASTは、プロビジョニングのための2つのモードをサポートしています。
1. Server-Authenticated Provisioning Mode - Provisioning inside a TLS tunnel that provides server-side authentication.
1.サーバ認証プロビジョニングモード - サーバ側の認証を提供するTLSトンネル内プロビジョニング。
2. Server-Unauthenticated Provisioning Mode - Provisioning inside an anonymous TLS tunnel.
2.サーバー非認証のプロビジョニングモード - 匿名TLSトンネル内でのプロビジョニング。
The EAP-FAST provisioning modes use EAP-FAST phase 2 inside a secure TLS tunnel established during phase 1. [RFC4851] describes the EAP-FAST phases in greater detail.
EAP-FASTプロビジョニングモードは、位相1 RFC4851]の間に確立された安全なTLSトンネル内部EAP-FASTフェーズ2を使用して、より詳細にEAP-FASTフェーズを記述する。
In the Server-Authenticated Provisioning Mode, the peer has successfully authenticated the EAP server as part of EAP-FAST phase 1 (i.e., TLS tunnel establishment). Additional exchanges MAY occur inside the tunnel to allow the EAP server to authenticate the EAP peer before provisioning any information.
サーバ認証プロビジョニングモードでは、ピアが正常にEAP-FASTフェーズ1（すなわち、TLSトンネル確立）の一部として、EAPサーバを認証しました。追加の交換は、EAPサーバが任意の情報をプロビジョニングする前に、EAPピアを認証することを可能にするトンネル内起こるかもしれ。
In the Server-Unauthenticated Provisioning Mode, an unauthenticated TLS tunnel is established in the EAP-FAST phase 1. The peer MUST negotiate a TLS anonymous Diffie-Hellman-based ciphersuite to signal that it wishes to use Server-Unauthenticateded Provisioning Mode. This provisioning mode enables the bootstrapping of peers where the peer lacks strong credentials usable for mutual authentication with the server.
サーバー非認証プロビジョニング・モードでは、認証されていないTLSトンネルは、EAP-FASTフェーズ1で確立され、それはサーバUnauthenticatededプロビジョニングモードを使用したいことを知らせるためにTLS匿名のディフィー - ヘルマンベースの暗号スイートをネゴシエートする必要があり、ピア。このプロビジョニング・モードでは、ピアがサーバとの相互認証のために使用可能な強力な資格情報が欠如しているピアのブートストラップを可能にします。
Since the server is not authenticated in the Server-Unauthenticated Provisioning Mode, it is possible that an attacker may intercept the TLS tunnel. If an anonymous tunnel is used, then the peer and server MUST negotiate and successfully complete an EAP method supporting mutual authentication and key derivation as described in Section 6. The peer then uses the Crypto-Binding TLV to validate the integrity of the TLS tunnel, thereby verifying that the exchange was not subject to a man-in-the-middle attack.
サーバーはサーバー認証されていないプロビジョニング・モードで認証されていないので、攻撃者は、TLSトンネルを傍受する可能性があります。匿名トンネルが使用される場合、ピア及びサーバはネゴシエートする必要があり、正常にセクション6内のピアに記載されているように、相互認証および鍵導出を支援するEAPメソッドを完了し、次にTLSトンネルの完全性を検証するために暗号バインディングTLVを使用して、これにより、交換がman-in-the-middle攻撃の対象ではなかったことを確認します。
Server-Authenticated Provisioning Mode protects against the man-in-the-middle attack; however, it requires provisioning the peer with the credentials necessary to authenticate the server. Environments willing to trade off the security risk of a man-in-the-middle attack for ease of deployment can choose to use the Server-Unauthenticated Provisioning Mode.
サーバー認証済みのプロビジョニングモードは、man-in-the-middle攻撃から保護します。しかし、それはサーバを認証するために必要な資格情報を使用してピアのプロビジョニングが必要です。展開を容易にするためにman-in-the-middle攻撃のセキュリティリスクをトレードオフするために喜ん環境では、サーバー非認証のプロビジョニングモードを使用するように選択することができます。
Assuming that an inner EAP method and Crypto-Binding TLV exchange is successful, the server will subsequently provide credential information, such as a shared key using a PAC TLV or the trusted certificate root(s) of the server using a Server-Trusted-Root TLV. Once the EAP-FAST Provisioning conversation completes, the peer is expected to use the provisioned credentials in subsequent EAP-FAST authentications.
内部EAPメソッドと暗号バインディングTLV交換が成功したと仮定すると、サーバはその後、そのようなPAC TLVまたはサーバー信頼されたルートを使用して、サーバの信頼された証明書のルート（複数可）を使用して共有キーとして、資格情報を提供しますTLV。 EAP-FASTプロビジョニング会話が完了すると、ピアは、後続のEAP-FAST認証でプロビジョニングされた資格情報を使用することが期待されます。
The provisioning occurs in the following steps, which are detailed in the subsequent sections and in RFC 4851. First, the EAP-FAST phase 1 TLS tunnel is established. During this process, extra material is extracted from the TLS key derivation for use as challenges in the subsequent authentication exchange. Next, an inner EAP method, such as EAP-FAST-MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2), is executed within the EAP-FAST phase 2 TLS tunnel to authenticate the client using the challenges derived from the phase 1 TLS exchange. Following successful authentication and Crypto-Binding TLV exchange, the server provisions the peer with PAC information including the secret PAC-Key and the PAC-Opaque. Finally, the EAP-FAST conversation completes with Result TLV exchanges defined in RFC 4851. The exported EAP Master Session Key (MSK) and Extended MSK (EMSK) are derived from a combination of the tunnel key material and key material from the inner EAP method exchange.
プロビジョニングは、後続のセクションおよびRFC 4851最初に詳述されている次のステップで発生、EAP-FASTフェーズ1 TLSトンネルが確立されます。このプロセスの間に、余分な材料は、後続の認証交換の課題として使用するためのTLS鍵導出から抽出されます。次に、このようなEAP-FAST-MSCHAPv2の（Microsoftチャレンジハンドシェイク認証プロトコルバージョン2）のような内部EAPメソッドは、フェーズ1 TLS交換に由来する課題を使用してクライアントを認証するためにEAP-FASTフェーズ2 TLSトンネル内で実行されます。認証に成功し、暗号バインディングTLV交換の後、サーバー条項秘密のPACキーとPAC-不透明含むPAC情報とのピア。最後に、EAP-FAST会話エクスポートEAPマスターセッションキー（MSK）及び拡張MSK（EMSK）は内部EAPメソッドからトンネル鍵材料及び鍵材料の組み合わせから誘導されるRFC 4851で定義された結果TLV交換で完了します交換。
The provisioning EAP-FAST exchange uses the same sequence as the EAP-FAST authentication phase 1 to establish a protected TLS tunnel. Implementations supporting this version of the Sever-Authenticated Provisioning Mode MUST support the following TLS ciphersuites defined in [RFC5246]:
プロビジョニングEAP-FAST交換は、保護されたTLSトンネルを確立するために、EAP-FAST認証フェーズ1と同じ配列を使用します。断絶-認証プロビジョニングモードのこのバージョンをサポートする実装は、[RFC5246]で定義された以下のTLS暗号スイートをサポートしなければなりません。
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
Other TLS ciphersuites that provide server authentication and encryption MAY be supported. The server MAY authenticate the peer during the TLS handshake in Server-Authenticated Provisioning Mode. To adhere to best security practices, the peer MUST validate the server's certificate chain when performing server-side authentication to obtain the full security benefits of Server-Authenticated provisioning.
サーバー認証と暗号化を提供する他のTLS暗号群をサポートすることができます。サーバーは、サーバー認証のプロビジョニングモードでTLSハンドシェイク中にピアを認証することができます。サーバー認証プロビジョニングの完全なセキュリティ上の利点を得るために、サーバー側の認証を実行する際のベストプラクティスセキュリティに準拠するために、ピアは、サーバの証明書チェーンを検証する必要があります。
Implementations supporting this version of the Sever-Unauthenticated Provisioning Mode MUST support the following TLS ciphersuite defined in [RFC5246]:
Severを、非認証プロビジョニングモードのこのバージョンをサポートする実装は、[RFC5246]で定義された以下のTLS暗号スイートをサポートしなければなりません。
TLS_DH_anon_WITH_AES_128_CBC_SHA
Talasadhaarnonavithaesa128sibisisa
Anonymous ciphersuites SHOULD NOT be allowed outside of EAP-FAST Server-Unauthenticated Provisioning Mode. Any ciphersuites that are used for Server-Unauthenticated Provisioning Mode MUST provide a key agreement contributed by both parties. Therefore, ciphersuites based on RSA key transport MUST NOT be used for this mode. Ciphersuites that are used for provisioning MUST provide encryption.
匿名暗号スイートは、EAP-FASTサーバ認証なしの提供モードの外に許されるべきではありません。サーバー非認証プロビジョニング・モードで使用されているすべての暗号スイートは、両当事者が寄与する鍵合意を提供しなければなりません。そのため、RSAキー・トランスポートに基づいた暗号スイートは、このモードのために使用してはいけません。プロビジョニングに使用されている暗号スイートは、暗号化を提供しなければなりません。
Once a protected tunnel is established and the server is unauthenticated, the peer and server MUST execute additional authentication and perform integrity checks of the TLS tunnel. Even if both parties are authenticated during TLS tunnel establishment, the peer and server MAY wish to perform additional authentication within the tunnel. As defined in [RFC4851], the authentication exchange will be followed by an Intermediate-Result TLV and a Crypto-Binding TLV, if the EAP method succeeded. The Crypto-Binding TLV provides a check on the integrity of the tunnel with respect to the endpoints of the EAP method. If the preceding is successful, then a provisioning exchange MAY take place. The provisioning exchange will use a PAC TLV exchange if a PAC is being provisioned and a Server-Trusted-Root TLV if a trusted root certificate is being provisioned. The provisioning MAY be solicited by the peer or it MAY be unsolicited. The PAC TLV exchange consists of the server distributing the PAC in a corresponding PAC TLV to the peer and the peer confirming its receipt in a final PAC TLV Acknowledgement message. The peer may also use the PAC TLV to request that the server send a PAC. The provisioning TLVs MAY be piggybacked onto the Result TLV. Many implementations process TLVs in the order they are received; thus, for proper provisioning to occur, the Result TLV MUST precede the TLVs to be provisioned (e.g., Tunnel PAC, Machine Authentication PAC, and User Authorization PAC). A PAC TLV MUST NOT be accepted if it is not encapsulated in an encrypted TLS tunnel.
保護されたトンネルが確立され、サーバが認証されたら、ピア及びサーバは、追加の認証を実行し、TLSトンネルの完全性チェックを実行しなければなりません。両当事者は、TLSトンネル確立時に認証された場合でも、ピアおよびサーバは、トンネル内で追加の認証を実行することを望むかもしれません。 [RFC4851]で定義されるようにEAPメソッドが成功した場合、認証交換は、中間結果のTLVと暗号バインディングTLVが続きます。暗号バインディングTLVはEAP方法のエンドポイントに対してトンネルの完全性のチェックを提供します。前のが成功した場合、プロビジョニング交換が行われてもよいです。 PACプロビジョニングおよびサーバー信頼されたルートされている場合TLV信頼されたルート証明書がプロビジョニングされている場合、プロビジョニング交換はPAC TLV交換を使用します。プロビジョニングは、ピアによって募集され得るか、またはそれは迷惑かもしれ。 PAC TLV交換はピアと最終PAC TLV肯定応答メッセージで、その受信を確認ピアに対応するPAC TLVにPACを配信サーバから成ります。ピアはまた、サーバがPACを送信することを要求するPAC TLVを使用することができます。プロビジョニングのTLVは、結果TLVにピギーバックされるかもしれません。多くの実装では、受信された順にTLVを処理します。従って、発生する適切なプロビジョニングのために、結果は、TLV（例えば、トンネルPAC、マシン認証PAC、およびユーザ認可PAC）プロビジョニングするTLVを先行しなければなりません。それは暗号化されたTLSトンネル内にカプセル化されていない場合、PAC TLVを受け入れてはいけません。
A fresh PAC MAY be distributed if the server detects that the PAC is expiring soon. In-band PAC refreshing is through the PAC TLV mechanism. The decision of whether or not to refresh the PAC is determined by the server. Based on the PAC-Opaque information, the server MAY determine not to refresh a peer's PAC, even if the PAC-Key has expired.
サーバはPACが間もなく期限切れになることを検出した場合、新鮮なPACを配布することができます。インバンドPACリフレッシュはPAC TLV機構を介してです。 PACをリフレッシュするかどうかの決定は、サーバによって決定されます。 PAC-不透明情報に基づいて、サーバは、PAC-キーの期限が切れた場合でも、ピアのPACを更新しないことを決定してもよいです。
If Server-Authenticated Provisioning Mode is in use, then any EAP method may be used within the TLS tunnel to authenticate the peer that is allowed by the peer's policy.
サーバ認証プロビジョニングモードが使用中である場合、任意のEAPメソッドは、ピアのポリシーで許可されるピアを認証するためにTLSトンネル内で使用することができます。
If Server-Unauthenticated Provisioning Mode is in use, then peer authenticates the server and the server authenticates the peer within the tunnel. The only method for performing authentication defined in this version of EAP-FAST is EAP-FAST-MSCHAPv2 (in a special way as described in the following section). It is possible for other methods to be defined to perform this authentication in the future.
サーバ認証されていないプロビジョニングモードが使用中である場合、ピアはサーバを認証し、サーバは、トンネル内のピアを認証します。 EAP-FASTのこのバージョンで定義された認証を行うための唯一の方法は、（次のセクションで説明したように特別な方法で）、EAP-FAST-MSCHAPv2のです。他の方法は、将来的にこの認証を実行するために定義することが可能です。
EAP-FAST-MSCHAPv2 is a specific instantiation of EAP-MSCHAPv2 [EAP-MSCHAPv2] defined for use within EAP-FAST. The 256-bit inner session key (ISK) is generated from EAP-FAST-MSCHAPv2 by combining the 128-bit master keys derived according to RFC 3079 [RFC3079], with the MasterSendKey taking the first 16 octets and MasterReceiveKey taking the last 16 octets.
EAP-FAST-MSCHAPv2のは、EAP-FAST内で使用するために定義されたEAP-MSCHAPv2の[EAP-MSCHAPv2の]特定のインスタンスです。 256ビットの内のセッション鍵（ISK）はMasterSendKeyは最初の16個のオクテットを取り、MasterReceiveKeyが最後の16個のオクテットを取ると、RFC 3079 [RFC3079]に従って導出さ128ビットのマスタ鍵を組み合わせることによって、EAP-FAST-MSCHAPv2とから生成されます。
Implementations of this version of the EAP-FAST Server-Unauthenticated Provisioning Mode MUST support EAP-FAST-MSCHAPv2 as the inner authentication method. While other authentication methods exist, EAP-FAST-MSCHAPv2 was chosen for several reasons:
EAP-FASTサーバ認証なしの提供モードのこのバージョンの実装は内部認証方式としてEAP-FAST-MSCHAPv2をサポートしなければなりません。他の認証方法が存在するが、EAP-FAST-MSCHAPv2のは、いくつかの理由のために選択しました。
o It provides the ability to slow an active attack by using a hash-based challenge-response protocol.
Oそれは、ハッシュベースのチャレンジレスポンスプロトコルを使用して、アクティブな攻撃を遅くする能力を提供します。
o Its use of a challenge-response protocol, such as MSCHAPv2, provides some ability to detect a man-in-the-middle attack during Server-Unauthenticated Provisioning Mode.
このようMSCHAPv2のようチャレンジレスポンスプロトコルの使用、O、サーバー非認証のプロビジョニングモード時のman-in-the-middle攻撃を検出するためのいくつかの機能を提供します。
o It is already supported by a large deployed base.
Oそれは、すでに大規模な展開ベースでサポートされています。
o It allows support for password change during the EAP-FAST provisioning modes.
Oそれは、EAP-FASTプロビジョニングモード時にパスワードの変更をサポートすることができます。
When using an anonymous Diffie-Hellman (DH) key agreement, the challenges MUST be generated as defined in Section 3.3. This forms a binding between the tunnel and the EAP-FAST-MSCHAPv2 exchanges by using keying material generated during the EAP-FAST tunnel establishment as the EAP-FAST-MSCHAPv2 challenges instead of using the challenges exchanged within the protocol itself. The exchanged challenges are zeroed upon transmission, ignored upon reception, and the challenges derived from the TLS key exchange are used in the calculations. When EAP-FAST-MSCHAPv2 is used within a tunnel established using a ciphersuite other than one that provides anonymous key agreement, the randomly generated EAP-FAST-MSCHAPv2 challenges MUST be exchanged and used.
匿名のディフィー・ヘルマン（DH）鍵共有を使用する場合は、セクション3.3で定義されるように、問題が発生しなければなりません。この代わりに、プロトコル自体の中で交換課題を使用しての挑戦EAP-FAST-MSCHAPv2のようなEAP-FASTトンネル確立時に発生するキーイング材料を使用してトンネルとEAP-FAST-MSCHAPv2の交換の間の結合を形成します。交換の課題は、受信時に無視され、送信時にゼロにされ、およびTLSの鍵交換に由来する課題は、計算に使用されます。 EAP-FAST-MSCHAPv2を、トンネル内で使用される場合、匿名鍵合意を提供する以外の暗号スイート、ランダムに生成されたEAP-FAST-MSCHAPv2の課題を交換して使用しなければなりませんを使用して確立しました。
The EAP-FAST-MSCHAPv2 exchange forces the server to provide a valid ServerChallengeResponse, which must be a function of the server challenge, peer challenge, and password as part of its response. This reduces the window of vulnerability of a man-in-the-middle attack spoofing the server by requiring the attacker to successfully break the password within the peer's challenge-response time limit.
EAP-FAST-MSCHAPv2の交換は、その応答の一部として、サーバのチャレンジの機能、ピアチャレンジ、およびパスワードでなければならない有効なServerChallengeResponseを、提供するために、サーバーを強制します。これが成功したピアのチャレンジ・レスポンス制限時間内にパスワードを破るために、攻撃者に要求することによって、サーバをスプーフィング、中間者攻撃の脆弱性の窓を低減します。
Once a protected tunnel is established, typically the peer authenticates itself to the server before the server can provision the peer. If the authentication mechanism does not support mutual authentication and protection from man-in-the-middle attacks, then Server-Authenticated Provisioning Mode MUST be used. Within a server side, authenticated tunnel authentication mechanisms such as EAP-FAST-GTC (Generic Token Card) [RFC5421] MAY be used. This will enable peers using other authentication mechanisms such as password database and one-time passwords to be provisioned in-band as well.
保護されたトンネルが確立されると、典型的には、ピアはサーバ缶提供ピア前にサーバに対して自身を認証します。認証メカニズムは、man-in-the-middle攻撃から相互認証と保護をサポートしていない場合は、サーバー認証のプロビジョニングモードを使用する必要があります。サーバ側内部に、そのようなEAP-FAST-GTC（汎用トークンカード）[RFC5421]として認証されたトンネルの認証メカニズムを使用することができます。これは、同様に、バンドプロビジョニングするためにこのようなパスワードデータベースとワンタイムパスワードなど他の認証メカニズムを使用してピアを有効にします。
This version of the EAP-FAST provisioning mode implementation MUST support both EAP-FAST-GTC and EAP-FAST-MSCHAPv2 within the tunnel in Server-Authenticated Provisioning Mode.
EAP-FASTプロビジョニングモード実装のこのバージョンは、サーバ認証プロビジョニングモードでトンネル内のEAP-FAST-GTCおよびEAP-FAST-MSCHAPv2の両方をサポートしなければなりません。
It should be noted that Server-Authenticated Provisioning Mode provides significant security advantages over Server-Unauthenticated Provisioning Mode even when EAP-FAST-MSCHAPv2 is being used as the inner method. It protects the EAP-FAST-MSCHAPv2 exchanges from potential active MITM attacks by verifying the server's authenticity before executing EAP-FAST-MSCHAPv2. Server-Authenticated Provisioning Mode is the recommended provisioning mode. The EAP-FAST peer MUST use the Server- Authenticated Provisioning Mode whenever it is configured with a valid trust root for a particular server.
サーバー認証プロビジョニングモードがEAP-FAST-MSCHAPv2のは、内側の方法として使用されている場合でも、サーバー認証されていないプロビジョニングモード上重大なセキュリティ上の利点を提供することに留意すべきです。これは、EAP-FAST-MSCHAPv2のを実行する前に、サーバーの信頼性を検証することにより、潜在的なアクティブなMITM攻撃からのEAP-FAST-MSCHAPv2の交換を保護します。サーバー認証済みのプロビジョニングモードを推奨プロビジョニングモードです。 EAP-FASTピアは、それが特定のサーバーの有効な信頼のルートが設定されている時はいつでもサーバー - 認証されたプロビジョニングモードを使用する必要があります。
The TLS tunnel key is calculated according to the TLS version with an extra 72 octets of key material derived from the end of the key_block. Portions of the extra 72 octets are used for the EAP-FAST provisioning exchange session key seed and as the random challenges in the EAP-FAST-MSCHAPv2 exchange.
TLSトンネルキーがなkey_blockの端から派生鍵素材の余分な72オクテットとTLSバージョンに従って計算されます。余分な72オクテットの一部は、EAP-FASTプロビジョニング交換セッションキーシードのためにと、EAP-FAST-MSCHAPv2の交換でランダムチャレンジとして使用されています。
To generate the key material, compute:
、キーマテリアルを生成するために計算します：
key_block = PRF(master_secret,
"key expansion",
server_random +
client_random);
until enough output has been generated.
まで十分な出力が生成されています。
For example, the key_block for TLS 1.0 [RFC2246] is partitioned as follows:
例えば以下のように、TLS 1.0 [RFC2246]のためなkey_blockが区画されています。
client_write_MAC_secret[hash_size]
server_write_MAC_secret[hash_size]
client_write_key[Key_material_length]
server_write_key[key_material_length]
client_write_IV[IV_size]
server_write_IV[IV_size]
session_key_seed[40]
ServerChallenge[16]
ClientChallenge[16]
and the key_block for subsequent versions is partitioned as follows:
次のように、後続バージョンのなkey_blockが区画されています。
client_write_MAC_secret[hash_size]
server_write_MAC_secret[hash_size]
client_write_key[Key_material_length]
server_write_key[key_material_length]
session_key_seed[40]
ServerChallenge[16]
ClientChallenge[16]
In the extra key material, session_key_seed is used for the EAP-FAST Crypto-Binding TLV exchange while the ServerChallenge and ClientChallenge correspond to the authentication server's EAP-FAST-MSCHAPv2 challenge and the peer's EAP-FAST-MSCHAPv2 challenge, respectively. The ServerChallenge and ClientChallenge are only used for the EAP-FAST-MSCHAPv2 exchange when Diffie-Hellman anonymous key agreement is used in the EAP-FAST tunnel establishment.
ServerChallengeとClientChallenge認証サーバのEAP-FAST-MSCHAPv2のチャレンジとピアのEAP-FAST-MSCHAPv2の課題に対応しながら、余分なキー材料において、session_key_seedは、それぞれ、EAP-FAST暗号バインディングTLV交換のために使用されます。ディフィー・ヘルマン匿名鍵合意は、EAP-FASTトンネル確立に使用される場合ServerChallengeとClientChallengeは、EAP-FAST-MSCHAPv2の交換のために使用されます。
The provisioning modes of EAP-FAST do not change the general EAP-FAST protocol and thus how the Peer-Id, Server-Id, and Session-Id are determined is based on the [RFC4851] techniques.
EAP-FASTピアID、サーバID、およびセッションIDが決定される方法こうして一般的なEAP-FASTプロトコルを変更しないのプロビジョニングモードは、[RFC4851]の手法に基づいています。
Section 3.4 of [RFC4851] describes how the Peer-Id and Server-Id are determined; Section 3.5 describes how the Session-Id is generated.
[RFC4851]の3.4節には、ピアIDとサーバIDを決定する方法を説明します。 3.5節は、セッションIDが生成される方法を説明します。
After successful provisioning, network access MAY be granted or denied depending upon the server policy. For example, in the Server-Authenticated Provisioning Mode, access can be granted after the EAP server has authenticated the peer and provisioned it with a Tunnel PAC (i.e., a PAC used to mutually authenticate and establish the EAP-FAST tunnel). Additionally, peer policy MAY instruct the peer to disconnect the current provisioning connection and initiate a new EAP-FAST exchange for authentication utilizing the newly provisioned information. At the end of the Server-Unauthenticated Provisioning Mode, network access SHOULD NOT be granted as this conversation is intended for provisioning only and thus no network access is authorized. The server MAY grant access at the end of a successful Server-Authenticated provisioning exchange.
成功したプロビジョニングした後、ネットワークアクセスは、サーバーポリシーによって許可または拒否されることがあります。 EAPサーバはピアを認証し、トンネルPAC（すなわち、PACが相互認証とEAP-FASTトンネルを確立するために使用される）と、それをプロビジョニングした後、例えば、サーバ認証プロビジョニングモードでは、アクセスが許可されることができます。また、ピアポリシーは、現在のプロビジョニングの接続を切断するピアに指示し、新しくプロビジョニングされた情報を利用した認証用の新しいEAP-FAST交換を開始することができます。この会話は、プロビジョニングのみを対象とし、したがって、何のネットワークアクセスが許可されていないなどのサーバー認証なしの提供モードの終了時に、ネットワークアクセスが許可されるべきではありません。サーバーは、成功したサーバー認証済みプロビジョニング交換の終わりにアクセスを許可することができます。
If after successful provisioning access to the network is denied, the EAP Server SHOULD conclude with an EAP Failure. The EAP server SHALL NOT grant network access or distribute any session keys to the Network Access Server (NAS) if this exchange is not intended to provide network access. Even though the provisioning mode completes with a successful inner termination (e.g., a successful Result TLV), the server policy defines whether or not the peer gains network access. Thus, it is feasible that the server, while providing a successful Result TLV, may conclude that its authentication policy was not satisfied and terminate the conversation with an EAP Failure.
ネットワークへの後に成功したプロビジョニングのアクセスが拒否された場合、EAPサーバは、EAPの失敗で締結すべきです。この交換は、ネットワークアクセスを提供することを目的とされていない場合、EAPサーバは、ネットワークアクセスを許可またはネットワークアクセスサーバ（NAS）に任意のセッションキーの分配をしてはなりません。プロビジョニングモードが成功した内部終端（例えば、成功した結果TLV）で完了しても、サーバのポリシーは、ピア・ゲイン・ネットワーク・アクセスか否かを定義します。したがって、サーバは、成功した結果TLVを提供しながら、その認証ポリシーを満たしていなかったと結論することができ、EAPの失敗との会話を終了することが可能です。
Denying network access after EAP-FAST Provisioning may cause disruption in scenarios such as wireless devices (e.g., in IEEE 802.11 devices, an EAP Failure may trigger a full 802.11 disassociation). While a full EAP restart can be performed, a smooth transition to the subsequent EAP-FAST authentications to enable network access can be achieved by the peer or server initiating TLS renegotiation, where the newly provisioned credentials can be used to establish a server-authenticated or mutually authenticated TLS tunnel for authentication. Either the peer or server may reject the request for TLS renegotiation. Upon completion of the TLS negotiation and subsequent authentication, normal network access policy on EAP-FAST authentication can be applied.
EAP-FASTプロビジョニング後のネットワークアクセスを拒否することは、無線デバイス（例えば、IEEE 802.11デバイスは、EAP失敗がフル802.11解離をトリガすることができる）のようなシナリオで混乱を引き起こす可能性があります。完全なEAPの再起動を行うことができるが、ネットワーク・アクセスを可能にするため、後続のEAP-FAST認証へのスムーズな移行が新たにプロビジョニングされた認証情報がサーバ認証又は確立するために使用することができるTLS再ネゴシエーションを開始ピアまたはサーバによって達成することができます相互認証のためにTLSトンネルを認証。どちらのピアまたはサーバがTLSの再交渉の要求を拒否することができます。 TLSネゴシエーションおよびその後の認証が完了すると、EAP-FAST認証の通常のネットワークアクセスポリシーを適用することができます。
Multiple types of credentials MAY be provisioned within EAP-FAST. The most common credential is the Tunnel PAC that is used to establish the EAP-FAST phase 1 tunnel. In addition to the Tunnel PAC, other types of credentials and information can also be provisioned through EAP-FAST. They may include trusted root certificates, PACs for specific purposes, and user identities, to name a few. Typically, provisioning is invoked after both the peer and server authenticate each other and after a successful Crypto-Binding TLV exchange. However, depending on the information being provisioned, mutual authentication MAY not be needed.
複数の種類の認証情報は、EAP-FAST内でプロビジョニングされるかもしれません。最も一般的な信用証明書は、EAP-FASTフェーズ1トンネルを確立するために使用されるトンネルPACです。トンネルPACに加えて、資格情報および他のタイプの情報もまた、EAP-FASTを介してプロビジョニングすることができます。彼らは少数を示すために、信頼されたルート証明書が、特定の目的のためのPAC、およびユーザーIDを含むことができます。典型的には、プロビジョニングは、ピアとサーバの両方が互いを認証した後に、成功した暗号バインディングTLV交換の後に呼び出されます。しかし、プロビジョニングされている情報に応じて、相互認証が必要とされないことがあります。
At a minimum, either the peer or server must prove authenticity before credentials are provisioned to ensure that information is not freely provisioned to or by adversaries. For example, the EAP server may not need to authenticate the peer to provision it with trusted root certificates. However, the peer SHOULD authenticate the server before it can accept a trusted server root certificate.
資格情報が情報を自由にプロビジョニングまたは敵でないことを確実にするためにプロビジョニングされる前に、最低でも、ピアまたはサーバのいずれかが本物であることを証明しなければなりません。例えば、EAPサーバは、信頼されたルート証明書を使用して提供することをピアを認証する必要がないかもしれません。それが信頼されたサーバーのルート証明書を受け入れることができます前に、しかし、ピアはサーバを認証すべきです。
A Protected Access Credential (PAC) is a security credential generated by the server that holds information specific to a peer. The server distributes all PAC information through the use of a PAC TLV. Different types of PAC information are identified through the PAC Type and other PAC attributes defined in this section. This document defines three types of PACs: a Tunnel PAC, a Machine Authentication PAC, and a User Authorization PAC.
保護されたアクセス資格情報（PAC）は、ピアに固有の情報を保持しているサーバによって生成されたセキュリティ証明書です。サーバは、PAC TLVを使用して、すべてのPAC情報を配信します。 PACの異なる種類の情報は、PACタイプと、このセクションで定義された他のPAC属性によって識別されます。トンネルPAC、マシン認証PAC、およびユーザー認証PAC：この文書では、PACの3つのタイプを定義します。
The server distributes the Tunnel PAC to the peer, which uses it in subsequent attempts to establish a secure EAP-FAST TLS tunnel with the server. The Tunnel PAC includes a secret key (PAC-Key), data that is opaque to the peer (PAC-Opaque), and other information (PAC-Info) that the peer can interpret. The opaque data is generated by the server and cryptographically protected so it cannot be modified or interpreted by the peer. The Tunnel PAC conveys the server policy of what must and can occur in the protected phase 2 tunnel. It is up to the server policy to include what is necessary in a PAC-Opaque to enforce the policy in subsequent TLS handshakes. For example, user identity, I-ID, can be included as the part of the server policy. This I-ID information limits the inner EAP methods to be carried only on the specified user identity. Other types of information can also be included, such as which EAP method(s) and which TLS ciphersuites are allowed. If the server policy is not included in a PAC-Opaque, then there is no limitation imposed by the PAC on the usage of the inner EAP methods or user identities inside the tunnel established by the use of that PAC.
サーバは、サーバとの安全なEAP-FAST TLSトンネルを確立する後続の試みでそれを使用するピアへのトンネルPACを分配します。トンネルPACは、ピアが解釈可能な秘密鍵（PAC-キー）、（PAC-不透明）ピアに対して不透明なデータ、およびその他の情報（PAC-情報）が含まれます。不透明なデータは、サーバによって生成され、それが修飾またはピアによって解釈することができないように暗号で保護されています。トンネルPACは、保護フェーズ2トンネル内で発生することができなければならないもののサーバポリシーを伝達します。それは、その後のTLSハンドシェイク中にポリシーを適用するためにPAC-不透明で必要なものを含めるようにサーバーポリシー次第です。例えば、ユーザアイデンティティ、I-ID、サーバーポリシーの一部として含めることができます。このI-ID情報は、指定されたユーザIDに搬送される内部EAPメソッドを制限します。他のタイプの情報はまた、そのEAPメソッド（複数可）とそのTLSの暗号スイートが許可されているように、含めることができます。サーバポリシーがPAC不透明に含まれていない場合は、そのPACを使用することによって確立されたトンネル内の内部EAPメソッドまたはユーザIDの使用にPACによって課される制限はありません。
The Machine Authentication PAC contains information in the PAC-Opaque that identifies the machine. It is meant to be used by a machine when network access is required and no user is logged in. Typically, a server will only grant the minimal amount of access required for a machine without a user present based on the Machine Authentication PAC. The Machine Authentication PAC MAY be provisioned during the authentication of a user. It SHOULD be stored by the peer in a location that is only accessible to the machine. This type of PAC typically persists across sessions.
マシン認証PACは、マシンを識別するPAC-不透明で情報が含まれています。ネットワーク・アクセスが必要とされないユーザがログインしていない場合、マシンによって使用されることを意味する。典型的には、サーバのみマシン認証PACに基づいてユーザが存在しないマシンに必要なアクセスの最小量を与えるであろう。マシン認証PACは、ユーザの認証時にプロビジョニングされるかもしれません。それはマシンにのみアクセスできる場所にピアによって保存されるべきです。 PACのこのタイプは通常、セッション間で持続します。
The peer can use the Machine Authentication PAC as the Tunnel PAC to establish the TLS tunnel. The EAP server MAY have a policy to bypass additional inner EAP method and grant limited network access based on information in the Machine Authentication PAC. The server MAY request additional exchanges to validate machine's other authorization criteria, such as posture information etc., before granting network access.
ピアは、TLSトンネルを確立するトンネルPACとしてマシン認証PACを使用することができます。 EAPサーバは、追加の内部EAPメソッドをバイパスし、マシン認証PAC内の情報に基づいて制限されたネットワークアクセスを許可するポリシーを持っているかもしれません。サーバーは、ネットワークアクセスを許可する前に、など姿勢情報として、マシンの他の認証基準を検証するために追加の交換を要求することができます。
The User Authorization PAC contains information in the PAC-Opaque that identifies a user and provides authorization information. This type of PAC does not contain a PAC-Key. The PAC-Opaque portion of the User Authorization PAC is presented within the protected EAP-FAST TLS tunnel to provide user information during stateless session resume so user authentication MAY be skipped. The User Authorization PAC MAY be provisioned after user authentication. It is meant to be short lived and not persisted across logon sessions. The User Authorization PAC SHOULD only be available to the user for which it is provisioned. The User Authorization PAC SHOULD be deleted from the peer when the local authorization state of a user's session changes, such as upon the user logs out.
ユーザー認証PACは、ユーザを識別し、認証情報を提供してPAC-不透明で情報が含まれています。 PACのこのタイプは、PAC-キーが含まれていません。ユーザ認可PACのPAC-遮光部は、ユーザ認証をスキップすることができるように、ステートレスセッション再開時にユーザー情報を提供するために、保護されたEAP-FAST TLSトンネル内に提示されます。ユーザー認証PACは、ユーザ認証後にプロビジョニングされるかもしれません。短命とのログオンセッション間で保持されないことを意味しています。ユーザー認証PACは、それがプロビジョニングされたユーザーに利用可能であるべきです。ユーザー認証PACは、ピア、ユーザーがログアウト時になど、ユーザーのセッションの変更、のローカル許可状態から削除する必要があります。
Once the EAP-FAST phase 1 TLS tunnel is established, the peer MAY present a User Authorization PAC to the server in a PAC TLV. This is sent as TLS application data, but it MAY be included in the same message as the Finished Handshake message sent by the peer. The User Authorization PAC MUST only be sent within the protection of an encrypted tunnel to an authenticated entity. The server will decrypt the PAC and evaluate the contents. If the contents are valid and the server policy allows the session to be resumed based on this information, then the server will complete the session resumption and grant access to the peer without requiring an inner authentication method. This is called stateless session resume in EAP-FAST. In this case, the server sends the Result TLV indicating success without the Crypto-Binding TLV and the peer sends back a Result TLV indicating success. If the User Authorization PAC fails the server validation or the server policy, the server MAY either reject the request or continue with performing full user authentication within the tunnel.
EAP-FASTフェーズ1 TLSトンネルが確立されると、ピアはPAC TLVにおけるサーバへのユーザ認証PACを提示することができます。これは、TLSアプリケーションデータとして送信され、それは、ピアによって送信された仕上がりハンドシェイクのメッセージと同じメッセージに含まれるかもしれません。ユーザー認証PACは認証されたエンティティに暗号化されたトンネルの保護範囲内送らなければなりません。サーバは、PACを復号化し、内容を評価します。コンテンツが有効であるとサーバポリシーは、セッションがこの情報に基づいて再開されることを可能にする場合、サーバは、セッション再開を完了し、内部認証方式を必要とせず、ピアへのアクセスを許可します。これは、EAP-FASTのステートレスセッション再開と呼ばれています。この場合、サーバは暗号バインディングTLVなしの成功を示す結果TLVを送信し、ピアが成功を示す結果TLVを送り返します。ユーザー認証PACは、サーバーの検証やサーバーポリシーを失敗した場合、サーバーは要求を拒否するか、トンネル内の完全なユーザー認証を実行し続けるかもしれないどちらか。
To request provisioning of a PAC, a peer sends a PAC TLV containing a PAC attribute of PAC Type set to the appropriate value. For a Tunnel PAC, the value is '1'; for a Machine Authentication PAC, the value is '2'; and for a User Authorization PAC, the value is '3'. The request MAY be issued after the peer has determined that it has successfully authenticated the EAP server and validated the Crypto-Binding TLV to ensure that the TLS tunnel's integrity is intact. Since anonymous DH ciphersuites are only allowed for provisioning a Tunnel PAC, if an anonymous ciphersuite is negotiated, the Tunnel PAC MAY be provisioned automatically by the server. The peer MUST send separate PAC TLVs for each type of PAC it wants to provision. Multiple PAC TLVs can be sent in the same packet or different packets. When requesting the Machine Authentication PAC, the peer SHOULD include an I-ID TLV containing the machine name prefixed by "host/". The EAP server will send the PACs after its internal policy has been satisfied, or it MAY ignore the request or request additional authentications if its policy dictates. If a peer receives a PAC with an unknown type, it MUST ignore it.
PACのプロビジョニングを要求するために、ピアが適切な値に設定PACタイプのPACの属性を含むPAC TLVを送信します。トンネルPACのために、値が「1」です。マシン認証PACのために、値が「2」です。そして、ユーザー認証PACのために、値が「3」です。ピアは、それが成功したEAPサーバを認証され、TLSトンネルの健全性が損なわれていないことを保証するために、暗号バインディングTLVを検証したと判断した後に要求を発行することができます。匿名DH暗号群のみトンネルPACをプロビジョニングするために許可されているので、匿名の暗号スイートが交渉されている場合、トンネルPACは、サーバーによって自動的にプロビジョニングされるかもしれません。ピアは、それが提供したいPACの種類ごとに別々のPAC TLVを送らなければなりません。複数のPACのTLVは、同じパケットまたは異なるパケットで送信することができます。マシン認証PACを要求する場合、ピアは、「ホスト/」で始まるマシン名を含むI-ID TLVを含むべきです。 EAPサーバは、その内部の方針が満たされた後にPACを送信します、またはそれは、要求を無視するか、そのポリシーのおもむくままであれば、追加の認証を要求することができます。ピアが未知のタイプでPACを受信した場合、それを無視しなければなりません。
A PAC-TLV containing PAC-Acknowledge attribute MUST be sent by the peer to acknowledge the receipt of the Tunnel PAC. A PAC-Acknowledge TLV MUST NOT be used by the peer to acknowledge the receipt of other types of PACs.
PAC-アクノリッジ属性を含むPAC-TLVは、トンネルPACの受信を確認するために、ピアによって送らなければなりません。 PAC-アクノリッジTLVは、PACを、他のタイプの受信を確認するために、ピアで使用してはいけません。
Please see Appendix A.1 for an example of packet exchanges to provision a Tunnel PAC.
規定トンネルPACへのパケット交換の例については、付録A.1を参照してください。
The PAC TLV provides support for provisioning the Protected Access Credential (PAC) defined within [RFC4851]. The PAC TLV carries the PAC and related information within PAC attribute fields. Additionally, the PAC TLV MAY be used by the peer to request provisioning of a PAC of the type specified in the PAC Type PAC attribute. The PAC TLV MUST only be used in a protected tunnel providing encryption and integrity protection. A general PAC TLV format is defined as follows:
PAC TLVは[RFC4851]内で定義された保護されたアクセス資格情報（PAC）をプロビジョニングするためのサポートを提供します。 PAC TLVは、PACとPACの属性フィールド内の関連情報を運びます。また、PAC TLVはPACタイプPAC属性で指定されたタイプのPACのプロビジョニングを要求するピアによって使用されてもよいです。 PAC TLVは唯一の暗号化と整合性の保護を提供する保護されたトンネルで使用されなければなりません。次のように一般的なPAC TLV形式が定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAC Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Non-mandatory TLV
1 - Mandatory TLV
R
R
Reserved, set to zero (0)
ゼロに設定され、予約済み（0）
TLV Type
TLVタイプ
11 - PAC TLV
11 - PAC TLV
Length
長さ
Two octets containing the length of the PAC attributes
field in octets.
PAC Attributes
PAC属性
A list of PAC attributes in the TLV format.
PACのリストは、TLV形式の属性。
Each PAC attribute in a PAC TLV is formatted as a TLV defined as follows:
PAC TLV内の各PAC属性は以下のように定義されるTLVとしてフォーマットされています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
The Type field is two octets, denoting the attribute type.
Allocated Types include:
1 - PAC-Key
2 - PAC-Opaque
3 - PAC-Lifetime
4 - A-ID
5 - I-ID
6 - Reserved
7 - A-ID-Info
8 - PAC-Acknowledgement
9 - PAC-Info
10 - PAC-Type
Length
長さ
Two octets containing the length of the Value field in
octets.
Value
値
The value of the PAC attribute.
PAC属性の値。
The PAC-Key is a secret key distributed in a PAC attribute of type PAC-Key. The PAC-Key attribute is included within the PAC TLV whenever the server wishes to issue or renew a PAC that is bound to a key such as a Tunnel PAC. The key is a randomly generated octet string, which is 32 octets in length. The generator of this key is the issuer of the credential, which is identified by the Authority Identifier (A-ID).
PAC-KeyがタイプPAC-キーのPAC属性に分布する秘密鍵です。サーバは、このようなトンネルPACなどのキーにバインドされているPACを発行したり更新したい時はいつでもPAC-Key属性は、PAC TLV内に含まれています。鍵の長さは32個のオクテットでランダムに生成されたオクテットストリングです。このキーの発生は、認証局識別子（A-ID）によって識別されるクレデンシャルの発行者です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1 - PAC-Key
1 - PAC-キー
Length
長さ
2-octet length indicating a 32-octet key
32オクテットのキーを示す2オクテット長
Key
キー
The value of the PAC-Key.
PAC-キーの値。
The PAC-Opaque attribute is included within the PAC TLV whenever the server wishes to issue or renew a PAC or the client wishes to present a User Authorization PAC to the server.
サーバがPACを発行したり更新を希望するか、クライアントがサーバーにユーザー認証PACを提示することを希望する時はいつでもPAC-不透明な属性は、PAC TLV内に含まれています。
The PAC-Opaque is opaque to the peer and thus the peer MUST NOT attempt to interpret it. A peer that has been issued a PAC-Opaque by a server stores that data and presents it back to the server according to its PAC Type. The Tunnel PAC is used in the ClientHello SessionTicket extension field defined in [RFC5077]. If a peer has opaque data issued to it by multiple servers, then it stores the data issued by each server separately according to the A-ID. This requirement allows the peer to maintain and use each opaque datum as an independent PAC pairing, with a PAC-Key mapping to a PAC-Opaque identified by the A-ID. As there is a one-to-one correspondence between the PAC-Key and PAC-Opaque, the peer determines the PAC-Key and corresponding PAC-Opaque based on the A-ID provided in the EAP-FAST/Start message and the A-ID provided in the PAC-Info when it was provisioned with a PAC-Opaque.
PAC-不透明ピアに対して不透明であるため、ピアはそれを解釈しようと試みてはなりません。データサーバーに格納することによってPAC-不透明を発行し、そのPACタイプに応じて、サーバーに戻ってそれを提示してきた仲間。トンネルPACは、[RFC5077]で定義されたClientHello SessionTicket拡張フィールドで使用されています。ピアが複数のサーバによってそれに発行した不透明なデータを持っている場合、それはA-IDに応じて個別に各サーバによって発行されたデータを格納します。この要件は、ピアがA-IDによって識別されるPAC-不透明にPAC-キーマッピングを用いて、独立したPACのペアとして各々不透明な基準を維持し、使用することを可能にします。 PACキーとPAC-不透明との間に1対1の対応が存在するように、ピアはEAP-FAST /開始メッセージで提供A-ID及びAに基づくPACキーと対応するPAC不透明を決定しますそれはPAC-不透明でプロビジョニングされたとき、PAC-Infoで提供-ID。
The PAC-Opaque attribute format is summarized as follows:
次のようにPAC-不透明属性の形式は要約されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
2 - PAC-Opaque
2 - PAC-不透明
Length
長さ
The Length filed is two octets, which contains the length of the Value field in octets.
提出された長さはオクテットで値フィールドの長さが含まれている2つのオクテット、です。
Value
値
The Value field contains the actual data for the PAC-Opaque. It is specific to the server implementation.
Valueフィールドは、PAC-不透明の実際のデータが含まれています。これは、サーバーの実装に固有のものです。
The PAC-Info is comprised of a set of PAC attributes as defined in Section 4.2.1. The PAC-Info attribute MUST contain the A-ID, A-ID-Info, and PAC-Type attributes. Other attributes MAY be included in the PAC-Info to provide more information to the peer. The PAC-Info attribute MUST NOT contain the PAC-Key, PAC-Acknowledgement, PAC-Info, or PAC-Opaque attributes. The PAC-Info attribute is included within the PAC TLV whenever the server wishes to issue or renew a PAC.
PAC-情報は、PACのセットで構成されている4.2.1項で定義された属性。 PAC-情報属性は、A-ID、-ID-情報、およびPAC-タイプの属性を含まなければなりません。他の属性は、ピアへのより多くの情報を提供するために、PAC-情報に含まれるかもしれません。 PAC-情報属性は、PAC-キー、PAC-謝辞、PAC-情報、またはPAC-不透明な属性を含んではなりません。サーバがPACを発行したり更新したい時はいつでもPAC-情報属性は、PAC TLV内に含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
9 - PAC-Info
9 - PAC-情報
Length
長さ
2-octet Length field containing the length of the attributes field in octets.
オクテット内の属性フィールドの長さを含む2オクテットの長さフィールド。
Attributes
属性
The attributes field contains a list of PAC attributes. Each mandatory and optional field type is defined as follows:
属性フィールドは、PAC属性のリストが含まれています。次のようにそれぞれの必須およびオプションのフィールドタイプが定義されます。
3 - PAC-LIFETIME
3 - PAC-LIFETIME
This is a 4-octet quantity representing the expiration time of the credential expressed as the number of seconds, excluding leap seconds, after midnight UTC, January 1, 1970. This attribute MAY be provided to the peer as part of the PAC-Info.
うるう秒を除いた秒数が、真夜中のUTCの後、1970年1月1日この属性は、PAC-情報の一部として、ピアに提供することができるように、これは表現資格の有効期限を表す4オクテットの量です。
4 - A-ID
4 - -ID
The A-ID is the identity of the authority that issued the PAC. The A-ID is intended to be unique across all issuing servers to avoid namespace collisions. The A-ID is used by the peer to determine which PAC to employ. The A-ID is treated as an opaque octet string. This attribute MUST be included in the PAC-Info attribute. The A-ID MUST match the A-ID the server used to establish the tunnel. Since many existing implementations expect the A-ID to be 16 octets in length, it is RECOMMENDED that the length of an A-ID be 16 octets for maximum interoperability. One method for generating the A-ID is to use a high-quality random number generator to generate a 16-octet random number. An alternate method would be to take the hash of the public key or public key certificate belonging a server represented by the A-ID.
A-IDは、PACを発行した機関のアイデンティティです。 A-IDは、名前空間の衝突を避けるために、すべての発行するサーバー全体で一意であることを意図しています。 A-IDは、PACを使用するかを決定するためにピアによって使用されます。 A-IDは、不透明なオクテット文字列として扱われます。この属性は、PAC-info属性に含まれなければなりません。 A-IDをA-IDトンネルを確立するために使用されるサーバが一致しなければなりません。多くの既存の実装がA-IDの長さは16個のオクテットであることを期待するので、A-IDの長さが最大の相互運用性のために16個のオクテットであることが推奨されます。 A-IDを生成するための一つの方法は、16オクテットの乱数を生成するために、高品質の乱数発生器を使用することです。別の方法は、公開鍵又はA-IDで示されるサーバに属する公開鍵証明書のハッシュを取ることであろう。
5 - I-ID
5 - I-ID
Initiator identifier (I-ID) is the peer identity associated with the credential. This identity is derived from the inner EAP exchange or from the client-side authentication during tunnel establishment if inner EAP method authentication is not used. The server employs the I-ID in the EAP-FAST phase 2 conversation to validate that the same peer identity used to execute EAP-FAST phase 1 is also used in at minimum one inner EAP method in EAP-FAST phase 2. If the server is enforcing the I-ID validation on the inner EAP method, then the I-ID MUST be included in the PAC-Info, to enable the peer to also enforce a unique PAC for each unique user. If the I-ID is missing from the PAC-Info, it is assumed that the Tunnel PAC can be used for multiple users and the peer will not enforce the unique-Tunnel-PAC-per-user policy.
イニシエータ識別子（I-ID）は、信任状に関連付けられているピアのアイデンティティです。内部EAPメソッド認証が使用されていない場合は、この同一性は、トンネル確立中に内部EAP交換から、またはクライアント側の認証に由来します。サーバは、同じピアIDがサーバ場合も、EAP-FASTフェーズ2で最小つの内部EAPメソッドでで使用されるEAP-FASTフェーズ1を実行するために使用されることを検証するためにEAP-FASTフェーズ2会話にI-IDを使用します内部EAPメソッドにI-IDの検証を実施し、次いでI-IDは、各固有のユーザに一意のPACを実施するピアを可能にするために、PAC-情報に含まれなければなりません。 I-IDは、PAC-情報から欠落している場合は、トンネルPACは、複数のユーザーとのピアのために使用することができるものとするユニークな-トンネルPAC-、ユーザーごとのポリシーを強制しません。
7 - A-ID-Info
7 - A-ID-情報
Authority Identifier Information is intended to provide a user-friendly name for the A-ID. It may contain the enterprise name and server name in a human-readable format. This TLV serves as an aid to the peer to better inform the end-user about the A-ID. The name is encoded in UTF-8 [RFC3629] format. This attribute MUST be included in the PAC-Info.
権限識別子情報は、A-IDのためのユーザーフレンドリーな名前を提供することを意図しています。それは、人間が読める形式で、企業名とサーバー名が含まれていてもよいです。このTLVは、より良好なA-IDについてエンドユーザーに知らせるためにピアへの補助として機能します。名前は、UTF-8 [RFC3629]の形式で符号化されます。この属性は、PAC-情報に含まれなければなりません。
10 - PAC-type
10 - PAC-タイプ
The PAC-Type is intended to provide the type of PAC. This attribute SHOULD be included in the PAC-Info. If the PAC-Type is not present, then it defaults to a Tunnel PAC (Type 1).
PAC-TypeはPACの種類を提供することを意図しています。この属性は、PAC-情報に含まれるべきです。 PAC-Typeが存在しない場合、トンネルPAC（タイプ1）にデフォルト設定。
The PAC-Acknowledgement is used to acknowledge the receipt of the Tunnel PAC by the peer. The peer includes the PAC-Acknowledgement TLV in a PAC-TLV sent to the server to indicate the result of the processing and storing of a newly provisioned Tunnel PAC. This TLV is only used when Tunnel PAC is provisioned.
PAC-肯定応答がピアによってトンネルPACの受信を確認するために使用されます。ピアは、新たにプロビジョニングされたトンネルPACの処理及び格納の結果を示すためにサーバに送信されたPAC-TLVにおけるPAC-肯定応答TLVを含みます。トンネルPACがプロビジョニングされたとき、このTLVにのみ使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
8 - PAC-Acknowledgement
8 - PAC-謝辞
Length
長さ
The length of this field is two octets containing a value of 2.
このフィールドの長さは2の値を含む2つのオクテットです。
Result
結果
The resulting value MUST be one of the following:
得られた値は、次のいずれかである必要があります
1 - Success
2 - Failure
The PAC-Type TLV is a TLV intended to specify the PAC type. It is included in a PAC-TLV sent by the peer to request PAC provisioning from the server. Its format is described below:
PAC-タイプTLVは、PACのタイプを指定することを目的とTLVです。これは、サーバからPACプロビジョニングを要求するためにピアによって送信されたPAC-TLVに含まれています。その形式は以下の通りであります：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAC Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
10 - PAC-Type
10 - PAC-タイプ
Length
長さ
2-octet Length field with a value of 2
2の値を有する2オクテットの長さフィールド
PAC Type
PACタイプ
This 2-octet field defines the type of PAC being requested or provisioned. The following values are defined:
この2オクテットフィールドは、要求またはプロビジョニングされるPACのタイプを定義します。次の値が定義されています。
1 - Tunnel PAC
2 - Machine Authentication PAC
3 - User Authorization PAC
Server-Trusted-Root TLV facilitates the request and delivery of a trusted server root certificate. The Server-Trusted-Root TLV can be exchanged in regular EAP-FAST authentication mode or provisioning mode. The Server-Trusted-Root TLV is always marked as optional, and cannot be responded to with a Negative Acknowledgement (NAK) TLV. The Server-Trusted-Root TLV MUST only be sent as an inner TLV (inside the protection of the tunnel).
サーバー・ルート信頼TLVは、信頼できるサーバのルート証明書の要求と配信を容易にします。サーバー信頼されたルート-TLVは、定期的なEAP-FAST認証モードまたはプロビジョニングモードで交換することができます。サーバー信頼されたルート-TLVは、常にオプションとしてマークされ、否定応答（NAK）TLVで応答することはできません。サーバ信頼ルートTLVのみ（トンネルの保護内部）内TLVとして送信しなければなりません。
After the peer has determined that it has successfully authenticated the EAP server and validated the Crypto-Binding TLV, it MAY send one or more Server-Trusted-Root TLVs (marked as optional) to request the trusted server root certificates from the EAP server. The EAP server MAY send one or more root certificates with a Public Key Cryptographic System #7 (PKCS#7) TLV inside Server-Trusted-Root TLV. The EAP server MAY also choose not to honor the request. Please see Appendix A.3 for an example of a server provisioning a server trusted root certificate.
ピアは、それが成功したEAPサーバを認証され、暗号バインディングTLVを検証していることを決定した後、それはEAPサーバから信頼されたサーバーのルート証明書を要求する（オプションとしてマーク）は、1つまたは複数のサーバー・信頼・ルートTLVを送るかもしれません。 EAPサーバは、サーバ・信頼されたルート-TLV内の公開鍵暗号システム＃7（PKCS＃7）TLVを持つ1つ以上のルート証明書を送信することができます。 EAPサーバは、要求を受け入れないかもしれません。サーバー信頼されたルート証明書をプロビジョニングサーバーの例については、付録A.3を参照してください。
The Server-Trusted-Root TLV allows the peer to send a request to the EAP server for a list of trusted roots. The server may respond with one or more root certificates in PKCS#7 [RFC2315] format.
サーバー・ルート信頼TLVは、ピアが信頼されたルートのリストについては、EAPサーバに要求を送信することができます。サーバーは、PKCS＃7 [RFC2315]形式で1つ以上のルート証明書で応答することができます。
If the EAP server sets the credential format to PKCS#7-Server-Certificate-Root, then the Server-Trusted-Root TLV should contain the root of the certificate chain of the certificate issued to the EAP server packaged in a PKCS#7 TLV. If the Server certificate is a self-signed certificate, then the root is the self-signed certificate.
EAPサーバは、PKCS＃7 - サーバー証明書のルートに資格情報のフォーマットを設定した場合、[サーバー-信頼ルートTLVは、PKCS＃7 TLVにパッケージEAPサーバに発行された証明書の証明書チェーンのルートが含まれている必要があります。サーバー証明書が自己署名証明書の場合、ルートは、自己署名証明書です。
If the Server-Trusted-Root TLV credential format contains a value unknown to the peer, then the EAP peer should ignore the TLV.
サーバー信頼されたルート-TLV資格情報のフォーマットは、ピアへの未知の値が含まれている場合、EAPピアはTLVを無視すべきです。
The Server-Trusted-Root TLV is defined as follows:
次のようにサーバー信頼されたルート-TLVが定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credential-Format | Cred TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
M
0 - Non-mandatory TLV
0 - 非必須TLV
R
R
Reserved, set to zero (0)
ゼロに設定され、予約済み（0）
TLV Type
TLVタイプ
18 - Server-Trusted-Root TLV [RFC4851]
18 - サーバ信頼ルートTLV [RFC4851]
Length
長さ
>=2 octets
> = 2つのバイト
Credential-Format
資格・フォーマット
The Credential-Format field is two octets.
Values include:
1 - PKCS#7-Server-Certificate-Root
1 - PKCS＃7 - サーバー証明書のルート
Cred TLVs
私のTLV
This field is of indefinite length. It contains TLVs
associated with the credential format. The peer may
leave this field empty when using this TLV to request
server trust roots.
The PKCS#7 TLV is sent by the EAP server to the peer inside the Server-Trusted-Root TLV. It contains PKCS#7-wrapped [RFC2315] X.509 certificates. The format consists of a certificate or certificate chain in a Certificates-Only PKCS#7 SignedData message as defined in [RFC2311].
PKCS＃7 TLVは、サーバー信頼されたルート-TLV内部ピアにEAPサーバによって送信されます。これは、PKCS＃7 - 包まれた[RFC2315] X.509証明書が含まれています。 [RFC2311]で定義されるようにフォーマットは、証明書のみのPKCS＃7のSignedDataメッセージに証明書または証明書チェーンで構成されています。
The PKCS#7 TLV is always marked as optional, which cannot be responded to with a NAK TLV. EAP-FAST server implementations that claim to support the dynamic provisioning defined in this document SHOULD support this TLV. EAP-FAST peer implementations MAY support this TLV.
PKCS＃7は、TLVは、常にNAK TLVで応答することができない、オプションとしてマークされています。この文書で定義された動的プロビジョニングをサポートするために主張するEAP-FASTサーバの実装は、このTLVをサポートしなければなりません。 EAP-FASTピア実装は、このTLVをサポートするかもしれません。
If the PKCS#7 TLV contains a certificate or certificate chain that is not acceptable to the peer, then the peer MUST ignore the TLV.
PKCS＃7 TLVピアに許容されない証明書または証明書チェーンが含まれている場合、ピアはTLVを無視しなければなりません。
The PKCS#7 TLV is defined as follows:
次のようにPKCS＃7 TLVが定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS #7 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
M
0 - Optional TLV
0 - オプションTLV
R
R
Reserved, set to zero (0)
ゼロに設定され、予約済み（0）
TLV Type
TLVタイプ
20 - PKCS#7 TLV [RFC4851]
20 - PKCS＃7 TLV [RFC4851]
Length
長さ
The length of the PKCS #7 Data field.
PKCS＃7データフィールドの長さ。
PKCS #7 Data
PKCS＃7データ
This field contains the X.509 certificate or certificate chain in a Certificates-Only PKCS#7 SignedData message.
このフィールドは、証明書のみのPKCS＃7のSignedDataメッセージにX.509証明書または証明書チェーンが含まれています。
This section explains the criteria to be used by the IANA for assignment of Type value in the PAC attribute, the PAC Type value in the PAC- Type TLV, and the Credential-Format value in the Server-Trusted-Root TLV. The "Specification Required" policy is used here with the meaning defined in BCP 26 [RFC5226].
このセクションでは、PAC属性にType値の割り当てのためにIANAが使用する基準、PAC-タイプTLVでPAC Type値、およびサーバー信頼されたルート-TLVでの資格・フォーマット値を説明しています。 「仕様が必要である」というポリシーは、BCP 26 [RFC5226]で定義された意味で、ここで使用されています。
A registry of values, named "EAP-FAST PAC Attribute Types", has been created for the PAC attribute types. The initial values that populate the registry are:
名前付きの値のレジストリ、「EAP-FAST PAC属性の型は」、PACの属性タイプのために作成されています。レジストリを移入初期値は次のとおりです。
1 - PAC-Key
2 - PAC-Opaque
3 - PAC-Lifetime
4 - A-ID
5 - I-ID
6 - Reserved
7 - A-ID-Info
8 - PAC-Acknowledgement
9 - PAC-Info
10 - PAC-Type
Values from 11 to 63 are allocated for management by Cisco. Values 64 to 255 are assigned with a "Specification Required" policy.
11から63までの値は、シスコによる管理のために割り当てられています。 64 255には、「仕様が必要」ポリシーに割り当てられている値。
A registry of values, named "EAP-FAST PAC Types", has been created for PAC-Type values used in the PAC-Type TLV. The initial values that populate the registry are:
「EAP-FAST PACのタイプ」という名前の値のレジストリは、PAC-タイプTLVで使用されるPAC-Type値のために作成されています。レジストリを移入初期値は次のとおりです。
1 - Tunnel PAC
2 - Machine Authentication PAC
3 - User Authorization PAC
Values from 4 to 63 are allocated for management by Cisco. Values 64 to 255 are assigned with a "Specification Required" policy.
4から63までの値は、シスコによる管理のために割り当てられています。 64 255には、「仕様が必要」ポリシーに割り当てられている値。
A registry of values, named "EAP-FAST Server-Trusted-Root Credential Format Types", has been created for Credential-Format values used in the Server-Trusted-Root TLV. The initial values that populate the registry are:
「EAP-FASTサーバの信頼ルート資格フォーマットタイプ」という名前の値のレジストリは、サーバー信頼されたルートTLVで使用される資格・フォーマット値のために作成されています。レジストリを移入初期値は次のとおりです。
1 - PKCS#7-Server-Certificate-Root
1 - PKCS＃7 - サーバー証明書のルート
Values from 2 to 63 are allocated for management by Cisco. Values 64 to 255 are assigned with a "Specification Required" policy.
2から63までの値は、シスコによる管理のために割り当てられています。 64 255には、「仕様が必要」ポリシーに割り当てられている値。
The Dynamic Provisioning EAP-FAST protocol shares the same security considerations outlined in [RFC4851]. Additionally, it also has its unique security considerations described below:
ダイナミックプロビジョニングEAP-FASTプロトコルは、[RFC4851]に概説同じセキュリティ上の考慮事項を共有しています。さらに、それはまた、独自のセキュリティ上の考慮事項を以下に記載しています：
EAP-FAST can be invoked in two different provisioning modes: Server-Authenticated Provisioning Mode and Server-Unauthenticated Provisioning Mode. Each mode provides different levels of resistance to man-in-the-middle attacks. The following list identifies some of the problems associated with a man-in-the-middle attack:
サーバー認証のプロビジョニングモードおよびサーバー非認証のプロビジョニングモード：EAP-FAST二つの異なるプロビジョニング・モードで呼び出すことができます。各モードは、man-in-the-middle攻撃に対する耐性の異なるレベルを提供します。以下のリストは、man-in-the-middle攻撃に関連した問題のいくつかを識別します。
o Disclosure of secret information such as keys, identities, and credentials to an attacker
こうした攻撃のキー、アイデンティティ、および資格情報など秘密情報のO開示
o Spoofing of a valid server to a peer and the distribution of false credentials
Oピアに有効なサーバのなりすまし、偽の資格情報の配布
o Spoofing of a valid peer and receiving credentials generated for that peer
有効なピアのなりすましOとその仲間のために生成された資格情報を受け取ります
o Denial of service
サービス拒否O
6.1.1. Server-Authenticated Provisioning Mode and Man-in-the-Middle Attacks
6.1.1. サーバー認証済みのプロビジョニングモードやman-in-the-middle攻撃
In Server-Authenticated Provisioning Mode, the TLS handshake assures protected communications with the server because the peer must have been securely pre-provisioned with the trust roots and/or other authentication information necessary to authenticate the server during the handshake. This pre-provisioning step prevents an attacker from inserting themselves as a man-in-the-middle of the communications. Unfortunately, secure pre-provisioning can be difficult to achieve in many environments.
ピアは、しっかりと信頼の根および/またはハンドシェイク中にサーバを認証するために必要な他の認証情報が事前にプロビジョニングされている必要がありますので、サーバー認証済みのプロビジョニングモードでは、TLSハンドシェイクは、サーバーとの保護された通信を保証します。この事前プロビジョニングステップは通信のman-in-the-middleとして自分自身を挿入する攻撃者を防ぎます。残念ながら、安全な事前プロビジョニングは、多くの環境で達成することが困難な場合があります。
Cryptographic binding of inner authentication mechanisms to the TLS tunnel provides additional protection from man-in-the-middle attacks resulting from the tunneling of authentication mechanisms.
TLSトンネルに内部認証メカニズムの結合暗号は、認証メカニズムのトンネリングに起因するman-in-the-middle攻撃からの追加保護を提供します。
Server-Authenticated Provisioning Mode provides a high degree of protection from man-in-the-middle attacks.
サーバー認証済みのプロビジョニングモードは、man-in-the-middle攻撃からの保護の高度を提供します。
6.1.2. Server-Unauthenticated Provisioning Mode and Man-in-the-Middle Attacks
6.1.2. サーバー非認証のプロビジョニングモードやman-in-the-middle攻撃
In Server-Unauthenticated Provisioning Mode, the TLS handshake does not assure protected communications with the server because either an anonymous handshake is negotiated or the peer lacks the necessary information to complete the authentication of the server. This allows an attacker to insert itself in the middle of the TLS communications.
匿名握手どちらかが交渉されるか、ピアがサーバの認証を完了するために必要な情報が欠けているため、サーバー非認証プロビジョニング・モードでは、TLSハンドシェイクは、サーバーで保護された通信を保証するものではありません。これにより、攻撃者はTLS通信の途中で自分自身を挿入することを可能にします。
EAP-FAST Server-Unauthenticated Provisioning Mode mitigates the man-in-the-middle attack through the following techniques:
EAP-FASTサーバ認証なしの提供モードは、以下の技術によりman-in-the-middle攻撃を軽減します：
o Binding the phase 2 authentication method to secret values derived from the phase 1 TLS exchange:
フェーズ1 TLS交換に由来する秘密値にフェーズ2認証方式をバインディング（O）
In the case of EAP-FAST-MSCHAPv2 used with an anonymous Diffie-Hellman ciphersuite, the challenges for the EAP-FAST-MSCHAPv2 exchange are derived from the TLS handshake and are not transmitted within the EAP-FAST-MSCHAPv2 exchange. Since the man-in-the-middle attack does not know these challenges, it cannot successfully impersonate the server without cracking the EAP-FAST-MSCHAPv2 message from the peer before the peer times out.
EAP-FAST-MSCHAPv2の匿名のDiffie-Hellman暗号スイートと一緒に使用する場合に、EAP-FAST-MSCHAPv2の交換のための課題は、TLSハンドシェイクに由来し、EAP-FAST-MSCHAPv2の交換内で送信されません。 man-in-the-middle攻撃は、これらの課題を認識していないので、それが成功したピア時間前にピアからのEAP-FAST-MSCHAPv2のメッセージを割れずにサーバーを偽装することはできません。
o Cryptographic binding of secret values derived from the phase 2 authentication exchange with secret values derived from the phase 1 TLS exchange:
暗号化は、位相1 TLS交換に由来する秘密値を用いて位相2認証情報の交換に由来する秘密値の結合（O）
This makes use of the cryptographic binding exchange defined within EAP-FAST to discover the presence of a man-in-the-middle attack by binding secret information obtained from the phase 2 EAP-FAST-MSCHAPv2 exchange with secret information from the phase 1 TLS exchange.
これは、フェーズ2 EAP-FAST-MSCHAPv2のフェーズ1 TLSから秘密情報との交換から得られた秘密情報を結合することによって、中間者攻撃の存在を発見するためにEAP-FAST内で定義された暗号結合交換を利用します交換。
While it would be sufficient to only support the cryptographic binding to mitigate the MITM, the binding of the EAP-FAST-MSCHAPv2 random challenge derivations to the TLS key agreement protocol enables early detection of a man-in-the-middle attack. This guards against adversaries who may otherwise relay the inner EAP authentication messages between the true peer and server, and it enforces that the adversary successfully respond with a valid challenge response.
それだけMITMを軽減するために、暗号化バインディングをサポートするのに十分であろうが、TLSキー合意プロトコルにEAP-FAST-MSCHAPv2をランダムチャレンジ派生の結合は、man-in-the-middle攻撃の早期発見を可能にします。これは、そうでなければ、真のピアとサーバ間の内部EAP認証メッセージを中継することができる敵に対してガード、そして、それは敵が正常に有効なチャレンジレスポンスで応答することを強制します。
The ciphersuite used to establish phase 1 of the Server-Unauthenticated Provisioning Mode MUST be one in which both the peer and server provide contribution to the derived TLS master key. Ciphersuites that use RSA key transport do not meet this requirement. The authenticated and anonymous ephemeral Diffie-Hellman ciphersuites provide this type of key agreement.
サーバー非認証プロビジョニングモードの位相1を確立するために使用される暗号スイートは、ピアとサーバの両方が導出TLSマスターキーへの寄与を提供したものでなければなりません。 RSAキー・トランスポートを使用する暗号スイートは、この要件を満たしていません。認証され、匿名の短命のDiffie-Hellman暗号スイートは、鍵合意のこのタイプを提供しています。
This document specifies EAP-FAST-MSCHAPv2 as the inner authentication exchange; however, it is possible that other inner authentication mechanisms to authenticate the tunnel may be developed in the future. Since the strength of the man-in-the-middle protection is directly dependent on the strength of the inner method, it is RECOMMENDED that any inner method used provide at least as much resistance to attack as EAP-FAST-MSCHAPv2. Cleartext passwords MUST NOT be used in Server-Unauthenticated Provisioning Mode. Note that an active man-in-the-middle attack may observe phase 2 authentication method exchange until the point that the peer determines that authentication mechanism fails or is aborted. This allows for the disclosure of sensitive information such as identity or authentication protocol exchanges to the man-in-the-middle attack.
この文書では、内部認証交換などのEAP-FAST-MSCHAPv2のを指定します。しかし、トンネルを認証するための他の内部認証メカニズムは、将来開発される可能性があります。 man-in-the-middle保護の強度は、内部方式の強さに直接依存しているので、使用される任意の内部メソッドがEAP-FAST-MSCHAPv2のように攻撃する少なくとも同じくらいの抵抗を提供することが推奨されます。クリアテキストのパスワードは、サーバー非認証のプロビジョニングモードで使用してはいけません。アクティブman-in-the-middle攻撃は、ピアが認証メカニズムが失敗または中断されていると判断時点までフェーズ2認証方式の交換を観察することができることに留意されたいです。これは、man-in-the-middle攻撃の識別または認証プロトコル交換などの機密情報の開示を可能にします。
It is often the case that phase 2 authentication mechanisms are based on password credentials. These exchanges may be vulnerable to both online and off-line dictionary attacks. The two provisioning modes provide various degrees of protection from these attacks.
それは多くの場合、フェーズ2認証メカニズムがパスワードの資格情報に基づいている場合です。これらの交換は、オンラインとオフラインの辞書攻撃の両方に対して脆弱である可能性があります。 2つのプロビジョニングモードは、これらの攻撃からの保護の様々な程度を提供しています。
In online dictionary attacks, the attacker attempts to discover the password by repeated attempts at authentication using a guessed password. Neither mode prevents this type of attack by itself. Implementations should provide controls that limit how often an attacker can execute authentication attempts.
オンライン辞書攻撃では、攻撃者が推測パスワードを使用した認証で繰り返す試みでパスワードを発見しようとします。どちらのモードでは、それ自体で、このタイプの攻撃を防ぐことができます。実装は、攻撃者が認証試行を実行できる頻度を制限制御を提供する必要があります。
In off-line dictionary attacks, the attacker captures information that can be processed off-line to recover the password. Server-Authenticated Provisioning Mode provides effecting mitigation because the peer will not engage in phase 2 authentication without first authenticating the server during phase 1. Server-Unauthenticated Provisioning Mode is vulnerable to this type of attack. If, during phase 2 authentication, a peer receives no response or an invalid response from the server, then there is a possibility there is a man-in-the-middle attack in progress. Implementations SHOULD log these events and, if possible, provide warnings to the user. Implementations are also encouraged to provide controls, which are appropriate to their environment, that limit how and where Server-Unauthenticated Provisioning Mode can be performed. For example, an implementation may limit this mode to be used only on certain interfaces or require user intervention before allowing this mode if provisioning has succeeded in the past.
オフライン辞書攻撃では、攻撃者がパスワードを回復するためにオフラインで処理できる情報を取得します。ピアは最初のフェーズ1サーバー非認証プロビジョニング・モード中にサーバを認証することなく、フェーズ2認証に関与しないので、サーバー認証プロビジョニングモードは、このタイプの攻撃に対して脆弱である行う緩和を提供します。フェーズ2認証中に、ピアが無応答またはサーバから無効な応答を受信しない、場合には、進行中のman-in-the-middle攻撃が存在する可能性があります。実装は、これらのイベントをログに記録して、可能な場合、ユーザーに警告を提供する必要があります。実装はまた、どのように、どこサーバー非認証のプロビジョニングモードを実行することができる制限自分の環境に適切な制御を、提供することが奨励されています。例えば、実装は、特定のインターフェイスで使用される、このモードを制限することができる、またはプロビジョニングが過去に成功した場合、このモードを許可する前にユーザの介入を必要とします。
Another mitigation technique that should not be overlooked is the choice of good passwords that have sufficient complexity and length and a password-changing policy that requires regular password changes.
見落としてはならないもう一つの緩和技術は、十分な複雑さと長さと定期的なパスワードの変更を要求するパスワード変更ポリシーを持っている良いパスワードの選択です。
Since Server-Authenticated Provisioning Mode provides much better protection from attacks than Server-Unauthenticated Provisioning Mode, Server-Authenticated Provisioning Mode SHOULD be used whenever possible. The Server-Unauthenticated Provisioning Mode provides a viable option as there may be deployments that can physically confine devices during the provisioning or are willing to accept the risk of an active dictionary attack. Further, it is the only option that enables zero-touch provisioning and facilitates simpler deployments requiring little to no peer configuration. The peer MAY choose to use alternative secure out-of-band mechanisms for PAC provisioning that afford better security than the Server Unauthenticated Provisioning Mode.
サーバー認証のプロビジョニングモードは、サーバー非認証のプロビジョニングモードより攻撃からはるかに優れた保護を提供するので、サーバー認証済みのプロビジョニングモードは、可能な限り使用されるべきです。サーバー非認証のプロビジョニングモードは、物理的にプロビジョニング中のデバイスを閉じ込めるか、アクティブな辞書攻撃のリスクを受け入れることを喜んでいることができます展開があるかもしれないとして、実行可能な選択肢を提供します。また、ゼロタッチプロビジョニングを可能にしないピア設定に少しを必要とする単純な展開を容易にする唯一のオプションです。ピアは、サーバー認証なしの提供モードよりも優れたセキュリティを買う余裕PACプロビジョニングのための代替の安全なアウトオブバンドメカニズムを使用することもできます。
To encourage interoperability implementations of EAP-FAST, anonymous provisioning modes MUST support the 2048-bit group "14" in [RFC3526].
[RFC3526]に2048ビットグループ「14」をサポートしなければならないEAP-FAST、匿名プロビジョニングモードの相互運用性の実装を促進します。
The basic usage of the Tunnel PAC is to establish the TLS tunnel. In this operation, it does not have to provide user authentication as user authentication is expected to be carried out in phase 2 of EAP-FAST. The EAP-FAST Tunnel PAC MAY contain information about the identity of a peer to prevent a particular Tunnel PAC from being used to establish a tunnel that can perform phase 2 authentication other peers. While it is possible for the server to accept the Tunnel PAC as authentication for the peer, many current implementations do not do this. The ability to use PAC to authenticate peers and provide authorizations will be the subject of a future document. [RFC5077] gives an example PAC-Opaque format in the Recommended Ticket Construction section.
トンネルPACの基本的な使い方は、TLSトンネルを確立することです。この操作では、ユーザ認証がEAP-FASTのフェーズ2で行うことが予想されるようなユーザ認証を提供する必要はありません。 EAP-FASTトンネルPACは、フェーズ2認証他のピアを行うことができるトンネルを確立するために使用されることから特定のトンネルPACを防止するために、ピアのアイデンティティに関する情報を含むことができます。サーバはピアの認証としてトンネルPACを受け入れるすることは可能ですが、多くの現在の実装では、これをしません。ピアを認証し、認証を提供するために、PACを使用する機能は、将来の文書の対象となります。 [RFC5077]は推奨チケット建設セクションの例PAC不透明フォーマットを与えます。
In general, the Machine Authorization PAC is expected to provide the minimum access required by a machine without a user. This will typically be a subset of the privilege a registered user has. The server provisioning the PAC should include information necessary to validate it at a later point in time. This would include expiration information. The Machine Authentication PAC includes a key so it can be used as a Tunnel PAC. The PAC-Key MUST be kept secret by the peer.
一般的に、マシンの認可PACは、ユーザがなく、マシンによって必要な最低限のアクセスを提供することが期待されます。これは通常、登録ユーザーが持っている権限のサブセットになります。 PACをプロビジョニングサーバは、後の時点でそれを検証するために必要な情報を含むべきです。これは、有効期限の情報が含まれます。マシン認証PACは、それがトンネルPACとして使用できるようにキーが含まれています。 PAC-Keyがピアによって秘密にしなければなりません。
The User Authorization PAC provides the privilege associated with a user. The server provisioning the PAC should include the information necessary to validate it at a later point in time. This includes expiration and other information associated with the PAC. The User Authorization PAC is a bearer credential such that it does not have a key that used to authenticate its ownership. For this reason, this type of PAC MUST NOT be sent in the clear. For additional protection, the PAC MAY be bound to a Tunnel PAC used to establish the TLS tunnel. On the peer, the User Authorization PAC SHOULD only be accessible by the user for which it is provisioned.
ユーザー認証PACには、ユーザーに関連付けられている権限を提供します。 PACをプロビジョニングサーバは、後の時点でそれを検証するために必要な情報を含むべきです。これは、有効期限とPACに関連する他の情報を含みます。ユーザー認証PACは、その所有権を認証するために使用するキーを持っていないようなベアラ資格です。このため、PACのこのタイプは明確に送ってはいけません。追加の保護のために、PACは、PACがTLSトンネルを確立するために使用されるトンネルに結合させることができます。ピアでは、ユーザー認証PACは、それがプロビジョニングされているため、ユーザがアクセスできる必要があります。
The main goal of EAP-FAST is to protect the authentication stream over the media link. However, host security is still an issue. Some care should be taken to protect the PAC on both the peer and server. The peer must securely store both the PAC-Key and PAC-Opaque, while the server must secure storage of its security association context used to consume the PAC-Opaque. Additionally, if alternate provisioning is employed, the transportation mechanism used to distribute the PAC must also be secured.
EAP-FASTの主な目的は、メディアリンク上での認証の流れを保護することです。ただし、ホストセキュリティは依然として問題です。いくつかの注意がピアとサーバーの両方にPACを保護するために取られるべきです。サーバは、PAC-不透明を消費するために使用されるそのセキュリティアソシエーションコンテキストの記憶を保護する必要がありながら、ピアが確実に、PACキーとPAC-不透明の両方を格納しなければなりません。代替プロビジョニングが使用される場合に加えて、PACを配布するために使用される搬送機構も確保しなければなりません。
Most of the attacks described here would require some level of effort to execute: conceivably greater than their value. The main focus therefore, should be to ensure that proper protections are used on both the peer and server. There are a number of potential attacks that can be considered against secure key storage such as:
ここで説明された攻撃のほとんどは、実行するための努力のいくつかのレベルが必要になります。その値よりも大きいものと考えられます。したがって、主な焦点は、適切な保護がピアとサーバの両方で使用されるようにすべきです。セキュアな鍵ストレージなどに対して考えることができる潜在的な攻撃の数があります。
o Weak Passphrases
O弱いパスフレーズ
On the peer side, keys are usually protected by a passphrase. In some environments, this passphrase may be associated with the user's password. In either case, if an attacker can obtain the encrypted key for a range of users, he may be able to successfully attack a weak passphrase. The tools are already in place today to enable an attacker to easily attack all users in an enterprise environment through the use of email viruses and other techniques.
ピア側では、キーは通常、パスフレーズで保護されています。一部の環境では、このパスフレーズは、ユーザーのパスワードを関連付けることができます。攻撃者はユーザーの範囲のための暗号化キーを取得することができればいずれの場合も、彼は成功し、弱いパスフレーズを攻撃することができるかもしれません。ツールは、簡単に電子メールのウイルスやその他の技術を使用して、エンタープライズ環境ですべてのユーザーを攻撃する攻撃を可能にするための場所ですでに今日です。
o Key Finding Attacks
重要な発見攻撃O
Key finding attacks are usually mentioned in reference to web servers where the private Secure Socket Layer (SSL) key may be stored securely, but at some point, it must be decrypted and stored in system memory. An attacker with access to system memory can actually find the key by identifying their mathematical properties. To date, this attack appears to be purely theoretical and primarily acts to argue strongly for secure access controls on the server itself to prevent such unauthorized code from executing.
重要な発見の攻撃は通常、民間のSecure Socket Layer（SSL）キーを安全に保存することができるWebサーバへの参照に記載されているが、いくつかの点で、それが解読されなければならないと、システムメモリに保存されています。システムメモリへのアクセス権を持つ攻撃者は、実際に彼らの数学的な性質を特定することにより、鍵を見つけることができます。現在までに、この攻撃は純粋に理論的なように見えるし、主に実行するから、このような不正なコードを防ぐために、サーバー自体にセキュアなアクセス制御のために強く主張するように作用します。
o Key duplication, Key substitution, Key modification
Oキー複製、キー置換、キー変更
Once keys are accessible to an attacker on either the peer or server, they fall under three forms of attack: key duplication, key substitution, and key modification. The first option would be the most common, allowing the attacker to masquerade as the user in question. The second option could have some use if an attacker could implement it on the server. Alternatively, an attacker could use one of the latter two attacks on either the peer or server to force a PAC re-key, and take advantage of the potential MITM/dictionary attack vulnerability of the EAP-FAST Server-Unauthenticated Provisioning Mode.
キーの重複、キー置換、およびキーの変更：キーは、ピアまたはサーバ上の攻撃者にアクセス可能であるならば、彼らは攻撃の三つの形式に該当します。最初のオプションは、攻撃者は、問題のユーザーになりすましすることができ、最も一般的だろう。攻撃者は、サーバー上でそれを実装することができれば2番目のオプションは、いくつかの用途を持つことができます。また、攻撃者は、PACの再キーを強制し、EAP-FASTサーバ認証なしの提供モードの潜在的なMITM /辞書攻撃の脆弱性を利用するために、ピアまたはサーバ上で後者の二つの攻撃のいずれかを使用することができます。
Another consideration is the use of secure mechanisms afforded by the particular device. For instance, some laptops enable secure key storage through a special chip. It would be worthwhile for implementations to explore the use of such a mechanism.
別の考慮事項は、特定の装置によって与えられる安全なメカニズムを使用することです。例えば、一部のラップトップは、特別なチップを通じてセキュアなキーストレージを有効にします。実装は、このようなメカニズムの使用を検討することは価値があるだろう。
The [RFC3748] security claims for EAP-FAST are given in Section 7.8 of [RFC4851]. When using anonymous provisioning mode, there is a greater risk of off-line dictionary attack since it is possible for a man-in-the-middle attack to capture the beginning of the inner EAP-FAST-MSCHAPv2 conversation. However, as noted previously, it is possible to detect the man-in-the-middle attack.
EAP-FASTのための[RFC3748]のセキュリティの特許請求の範囲は、[RFC4851]のセクション7.8に示されています。匿名のプロビジョニング・モードを使用する場合、それは内部EAP-FAST-MSCHAPv2の会話の始まりをキャプチャするman-in-the-middle攻撃のためにできるので、オフライン辞書攻撃の大きなリスクがあります。前述のようにしかし、man-in-the-middle攻撃を検出することが可能です。
The EAP-FAST design and protocol specification is based on the ideas and contributions from Pad Jakkahalli, Mark Krischer, Doug Smith, Ilan Frenkel, Max Pritikin, Jan Vilhuber, and Jeremy Steiglitz. The authors would also like to thank Jouni Malinen, Pasi Eronen, Jari Arkko, Chris Newman, Ran Canetti, and Vijay Gurbani for reviewing this document.
EAP-FASTの設計およびプロトコルの仕様は、パッドJakkahalli、マーク・Krischer、ダグ・スミス、宜蘭フレンケル、マックスPritikin、ヤンVilhuber、そしてジェレミーSteiglitzからのアイデアや貢献度に基づいています。著者らはまた、この文書をレビューするJouni Malinen、パシEronen、ヤリArkko、クリス・ニューマン、カネッティを走り、ビジェイGurbaniに感謝したいと思います。
[EAP-MSCHAPv2] Microsoft Corporation, "MS-CHAP: Extensible Authentication Protocol Method for Microsoft Challenge Handshake Authentication Protocol (CHAP) Specification", January 2009. http://msdn2.microsoft.com/ en-us/library/cc224612.aspx
[EAP-MSCHAPv2の]マイクロソフトコーポレーション、 "MS-CHAP：Microsoftチャレンジハンドシェイク認証プロトコル（CHAP）仕様のための拡張認証プロトコル方法"、2009年1月http://msdn2.microsoft.com/ EN-US /ライブラリ/ cc224612が。 ASPX
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
[RFC2311] Dusse、S.、ホフマン、P.、Ramsdell、B.、Lundblade、L.、及びL. Repka、 "S / MIMEバージョン2メッセージ仕様"、RFC 2311、1998年3月。
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[RFC2315] Kaliski、B.、 "PKCS＃7：暗号メッセージ構文バージョン1.5"、RFC 2315、1998年3月。
[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)", RFC 3079, March 2001.
[RFC3079]ソーン、G.、RFC 3079、2001年3月 "Microsoft Point-to-Point暗号化（MPPE）を使用するための鍵を導出"。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526] Kivinen、T.およびM.古城、 "インターネット鍵交換のためのより多くのモジュラー指数（MODP）のDiffie-Hellmanグループ（IKE）"、RFC 3526、2003年5月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007.
[RFC4851]カムウィンゲット、N.、マグリュー、D.、Salowey、J.、およびH.周、RFC 4851、2007年5月 "（EAP-FAST）セキュアなトンネリング拡張認証プロトコル方法を介してフレキシブル認証"。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077] Salowey、J.、周、H.、Eronen、P.、およびH. Tschofenig、 "サーバー側の状態なしのトランスポート層セキュリティ（TLS）セッション再開"、RFC 5077、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5421] Cam-Winget, N. and H. Zhou, "Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", RFC 5421, March 2009.
[RFC5421]カム・ウィンゲット、N.およびH.周、RFC 5421、2009月 "セキュアなトンネリング拡張認証プロトコル（EAP-FAST）を介して柔軟な認証内の基本的なパスワードの交換"。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
Appendix A. Examples
付録A.例
A.1. Example 1: Successful Tunnel PAC Provisioning
A.1。例1：成功トンネルPACプロビジョニング
The following exchanges show anonymous DH with a successful EAP-FAST-MSCHAPv2 exchange within phase 2 to provision a Tunnel PAC. The conversation will appear as follows:
以下の交換は規定トンネルPACへの相2内に成功したEAP-FAST-MSCHAPv2を交換して、匿名DHを示しました。次のように会話が表示されます。
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST,
(S=1, A-ID)
EAP-Response/EAP-FAST (TLS Client Hello without PAC-Opaque in SessionTicket extension)->
EAP応答/ EAP-FAST（TLSクライアントこんにちはPAC-不透明SessionTicket拡張になし） - >
<- EAP-Request/EAP-FAST
(TLS Server Hello,
TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/EAP-FAST (TLS Client Key Exchange TLS Change Cipher Spec TLS Finished) ->
EAP応答/ EAP-FAST（TLSクライアント鍵交換TLS暗号仕様変更TLSは完成しました） - >
<- EAP-Request/EAP-FAST
( TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
// TLS channel established (Subsequent messages sent within the TLS channel, encapsulated within EAP-FAST)
確立された// TLSチャネル（EAP-FAST内に封入TLSチャネル内で送信された後続のメッセージ）
// First EAP Payload TLV is piggybacked on the TLS Finished as Application Data and protected by the TLS tunnel
//最初のEAPペイロードTLVは、アプリケーションデータとして完成TLSにピギーバックし、TLSトンネルによって保護されています
EAP Payload TLV (EAP-Response/Identity) ->
EAPペイロードTLV（EAP応答/アイデンティティ） - >
<- EAP Payload TLV
(EAP-Request/EAP-FAST-MSCHAPv2
(Challenge))
EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Response)) ->
EAPペイロードTLV（EAP応答/ EAP-FAST-MSCHAPv2を（レスポンス）） - >
<- EAP Payload TLV (EAP-Request/EAP-FAST-MSCHAPv2) (Success)) EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Success)) -> <- Intermediate Result TLV(Success) Crypto-Binding-TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC)
< - EAPペイロードTLV（EAP要求/ EAP-FAST-MSCHAPv2を）（成功））EAPペイロードTLV（EAP応答/ EAP-FAST-MSCHAPv2を（成功）） - > < - 中間結果TLV（成功）暗号バインディング-TLV（バージョン= 1、EAP-FAST版= 1、ノンス、CompoundMAC）
Intermediate Result TLV (Success) Crypto-Binding-TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC) PAC-TLV (Type=1) <- Result TLV (Success) PAC TLV
中間結果TLV（成功）暗号バインディング-TLV（バージョン= 1、EAP-FAST版= 1、ノンス、CompoundMAC）PAC-TLV（タイプ= 1）< - 結果TLV（成功）PAC TLV
Result TLV (Success) PAC Acknowledgment ->
結果TLV（成功）PAC謝辞 - >
TLS channel torn down (messages sent in cleartext)
取り壊さTLSチャネル（クリアテキストで送信されたメッセージ）
<- EAP-Failure
< - EAP-失敗
A.2. Example 2: Failed Provisioning
A.2。例2：失敗したプロビジョニング
The following exchanges show a failed EAP-FAST-MSCHAPv2 exchange within phase 2, where the peer failed to authenticate the server. The conversation will appear as follows:
次の交換は、ピアがサーバを認証するのに失敗したフェーズ2、内失敗したEAP-FAST-MSCHAPv2の交換を示します。次のように会話が表示されます。
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(s=1, A-ID)
EAP-Response/EAP-FAST (TLS Client Hello without SessionTicket extension)->
EAP応答/ EAP-FAST（TLSクライアントこんにちはSessionTicket拡張子なし） - >
<- EAP-Request/EAP-FAST (TLS Server Hello TLS Server Key Exchange TLS Server Hello Done) EAP-Response/EAP-FAST (TLS Client Key Exchange TLS Change Cipher Spec, TLS Finished) ->
< - EAP要求/ EAP-FAST（TLSサーバこんにちはTLSサーバ鍵交換TLSサーバーこんにちは完了）EAP応答/ EAP-FAST（TLSクライアント鍵交換TLS暗号仕様変更、TLS完成） - >
<- EAP-Request/EAP-FAST
( TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
// TLS channel established (Subsequent messages sent within the TLS channel, encapsulated within EAP-FAST)
確立された// TLSチャネル（EAP-FAST内に封入TLSチャネル内で送信された後続のメッセージ）
// First EAP Payload TLV is piggybacked on the TLS Finished as Application Data and protected by the TLS tunnel
//最初のEAPペイロードTLVは、アプリケーションデータとして完成TLSにピギーバックし、TLSトンネルによって保護されています
EAP Payload TLV (EAP-Response/Identity)->
EAPペイロードTLV（EAP応答/アイデンティティ） - >
<- EAP Payload TLV
(EAP-Request/EAP-FAST-MSCHAPv2
(Challenge))
EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Response)) ->
EAPペイロードTLV（EAP応答/ EAP-FAST-MSCHAPv2を（レスポンス）） - >
<- EAP Payload TLV
(EAP-Request EAP-FAST-MSCHAPv2
(Success))
// peer failed to verify server MSCHAPv2 response EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Failure)) ->
//ピアは、サーバMSCHAPv2の応答EAPペイロードTLV（EAP応答/ EAP-FAST-MSCHAPv2を（失敗））を検証するために失敗しました - >
<- Result TLV (Failure)
< - 結果TLV（失敗）
Result TLV (Failure) -> TLS channel torn down (messages sent in cleartext)
結果TLV（失敗） - 取り壊さ> TLSチャネル（クリアテキストで送信されたメッセージ）
<- EAP-Failure
< - EAP-失敗
A.3. Example 3: Provisioning an Authentication Server's Trusted Root Certificate
A.3。例3：認証サーバーの信頼されたルート証明書をプロビジョニング
The following exchanges show a successful provisioning of a server trusted root certificate using anonymous DH and EAP-FAST-MSCHAPv2 exchange within phase 2. The conversation will appear as follows:
以下の交換は、次のように会話が表示されますフェーズ2内の匿名DHおよびEAP-FAST-MSCHAPv2の交換を使用して、サーバー信頼されたルート証明書の成功のプロビジョニングを示しています。
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Requese/EAP-FAST
(s=1, A-ID)
EAP-Response/EAP-FAST (TLS Client Hello without SessionTicket extension)-> <- EAP-Request/EAP-FAST (TLS Server Hello, (TLS Server Key Exchange TLS Server Hello Done)
EAP応答/ EAP-FAST（TLSクライアントこんにちはSessionTicket拡張子なし） - > < - EAP要求/ EAP-FAST（TLSサーバこんにちは、（TLSサーバ鍵交換TLSサーバこんにちは完了）
EAP-Response/EAP-FAST (TLS Client Key Exchange TLS Change Cipher Spec, TLS Finished) ->
EAP応答/ EAP-FAST（TLSクライアント鍵交換TLS暗号仕様変更、TLS完成） - >
<- EAP-Request/EAP-FAST
(TLS Change Cipher Spec
TLS Finished)
(EAP-Payload-TLV(
EAP-Request/Identity))
// TLS channel established (messages sent within the TLS channel)
設立// TLSチャネル（TLSチャネル内で送信されるメッセージ）
// First EAP Payload TLV is piggybacked on the TLS Finished as Application Data and protected by the TLS tunnel
//最初のEAPペイロードTLVは、アプリケーションデータとして完成TLSにピギーバックし、TLSトンネルによって保護されています
EAP-Payload TLV (EAP-Response/Identity) ->
EAP-ペイロードTLV（EAP応答/アイデンティティ） - >
<- EAP Payload TLV
(EAP-Request/EAP-FAST-MSCHAPv2
(Challenge))
EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Response)) ->
EAPペイロードTLV（EAP応答/ EAP-FAST-MSCHAPv2を（レスポンス）） - >
<- EAP Payload TLV
(EAP-Request/EAP-FAST-MSCHAPv2
(success))
EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Success) ->
EAPペイロードTLV（EAP応答/ EAP-FAST-MSCHAPv2を（成功） - >
<- Intermediate Result TLV(Success)
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Intermediate Result TLV(Success) Crypto-Binding TLV (Version=1 EAP-FAST Version=1, Nonce, CompoundMAC) Server-Trusted-Root TLV (Type = PKCS#7) -> <- Result TLV (Success) Server-Trusted-Root TLV (PKCS#7 TLV)
中間結果TLV（成功）暗号バインディングTLV（バージョン= 1 EAP-FASTバージョン= 1、ノンス、CompoundMAC）サーバー - 信頼されたルートTLV（タイプ= PKCS＃7） - > < - 結果TLV（成功）サーバー、信頼できます-root TLV（PKCS＃7 TLV）
Result TLV (Success) ->
結果TLV（成功） - >
// TLS channel torn down (messages sent in cleartext)
取り壊さ// TLSチャネル（クリアテキストで送信されたメッセージ）
<- EAP-Failure
< - EAP-失敗
Authors' Addresses
著者のアドレス
Nancy Cam-Winget Cisco Systems 3625 Cisco Way San Jose, CA 95134 US
ナンシー・カム・ウィンゲットシスコシステムズ3625のCiscoウェイサンノゼ、CA 95134米国
EMail: ncamwing@cisco.com
メールアドレス：ncamwing@cisco.com
David McGrew Cisco Systems 3625 Cisco Way San Jose, CA 95134 US
デビッドマグリューシスコシステムズ3625のCiscoウェイサンノゼ、CA 95134米国
EMail: mcgrew@cisco.com
メールアドレス：mcgrew@cisco.com
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US
ジョセフSaloweyシスコシステムズ2901年第三アベニューシアトル、WA 98121米国
EMail: jsalowey@cisco.com
メールアドレス：jsalowey@cisco.com
Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US
ハオ周シスコシステムズ4125ハイランダーパークウェイリッチフィールド、オハイオ州44286米国
EMail: hzhou@cisco.com
メールアドレス：hzhou@cisco.com