[要約] RFC 5422は、EAP-FASTを使用した柔軟な認証による動的プロビジョニングに関する規格です。このRFCの目的は、セキュアなトンネリング拡張認証プロトコルを使用して、柔軟な認証を実現することです。
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)
安全なトンネリング拡張可能な認証プロトコル（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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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-Fastトンネル内で変更されていないEAP-MSCHAPV2の使用が必要な実装に問題を引き起こす可能性があります。このようなサポートには、トンネル内のメソッドの特別なケース実行が必要なため、トンネルメソッドの内外で同じメソッドコードを使用する実装も複雑になります。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.
Secure Tunneling拡張可能な認証プロトコル（EAP-FAST）メソッドを介した柔軟な認証により、Transport Layer Security（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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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
トンネルパック
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の代わりにマシン認証PACを使用して、TLSトンネルを確立して、マシン認証と承認情報を提供することができます。マシン認証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. Server -unAuthenticatedプロビジョニングモード - 匿名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の間に確立された安全なTLSトンネル内でEAP-FASTフェーズ2を使用します[RFC4851]は、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サーバーをEAPファーストフェーズ1（つまり、TLSトンネルの確立）の一部として正常に認証しました。情報をプロビジョニングする前に、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.
Server-unAuthenticated Provisioningモードでは、EAP-Fastフェーズ1に認可されていないTLSトンネルが確立されます。ピアは、TLS匿名のDiffie-HellmanベースのCipherSuiteを交渉して、サーバーを認定したプロビジョニングモードを使用することを示す必要があります。このプロビジョニングモードにより、ピアには、サーバーでの相互認証のために使用可能な強い資格情報が不足しているピアのブートストラップが可能になります。
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メソッドを交渉し、正常に完了する必要があります。ピアは、暗号結合TLVを使用してTLSトンネルの完全性を検証します。これにより、交換が中間の攻撃の対象ではないことを確認しました。
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.
サーバーと認識されたプロビジョニングモードは、中間の攻撃から保護します。ただし、サーバーを認証するために必要な資格情報をピアにプロビジョニングする必要があります。展開を容易にするために、中間の攻撃のセキュリティリスクを除去することをいとわない環境は、Server-Unauthenticated Provisioningモードを使用することを選択できます。
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を使用して共有キーやサーバーのトラストRootを使用してサーバーの信頼できる証明書ルートなどの資格情報を提供します。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 Challenge Handshake Authentication Protocolバージョン2）などの内部EAPメソッドがEAP-Fast Phase 2 TLSトンネル内で実行され、フェーズ1 TLS交換から派生した課題を使用してクライアントを認証します。成功した認証と暗号結合TLV交換に続いて、サーバーはピアにSecret Pac-KeyやPAC-OpaqueなどのPAC情報を提供します。最後に、EAPファストの会話は、RFC 4851で定義された結果TLV交換で完了します。エクスポートされたEAPマスターセッションキー（MSK）と拡張MSK（EMSK）は、内側のEAPメソッドのトンネルキーとキー材料の組み合わせから派生しています。交換。
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 Exchangeは、EAP-Fast認証フェーズ1と同じシーケンスを使用して、保護されたTLSトンネルを確立します。このバージョンの重度認定プロビジョニングモードをサポートする実装は、[RFC5246]で定義されている次のTLS暗号をサポートする必要があります。
TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA
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]:
このバージョンのSEVE-UNAUTHENTICTED PROVISIONモードをサポートする実装は、[RFC5246]で定義されている次のTLS ciphersuiteをサポートする必要があります。
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_ANON_WITH_AES_128_CBC_SHA
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.
匿名のciphersuitesは、EAP-Fast Server-Unauthenticated Provisioningモード以外では許可されないでください。Server-Unauthenticated Provisioningモードに使用されるCiphersuitesは、両当事者が貢献した重要な契約を提供する必要があります。したがって、RSAキートランスポートに基づくcipherSuitesは、このモードに使用してはなりません。プロビジョニングに使用されるciphersuitesは、暗号化を提供する必要があります。
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がプロビジョニングされている場合はPAC TLV Exchangeを使用し、信頼できるルート証明書がプロビジョニングされている場合はサーバーに支持されたルートTLVを使用します。プロビジョニングは、ピアによって募集される場合があります。PAC TLV交換は、対応するPAC TLVのPACをピアに配布するサーバーと、最終的なPAC TLV確認メッセージで領収書を確認するピアで構成されています。ピアは、PAC TLVを使用して、サーバーがPACを送信するように要求する場合もあります。プロビジョニングTLVは、結果TLVにピギーバックされる場合があります。多くの実装は、受信される順序でTLVを処理します。したがって、適切なプロビジョニングを行うには、結果TLVがプロビジョニングするTLVの前に（トンネルPAC、マシン認証PAC、ユーザー認証PAC）に先行する必要があります。暗号化された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 TLVメカニズムを介しています。PACを更新するかどうかの決定は、サーバーによって決定されます。PAC-opaque情報に基づいて、サーバーは、パックキーの有効期限が切れていても、ピアの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.
サーバーを認識したプロビジョニングモードが使用されている場合、TLSトンネル内でEAPメソッドを使用して、ピアのポリシーで許可されているピアを認証することができます。
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.
Server-Unauthenticated Provisioning Modeが使用されている場合、Peerはサーバーを認証し、サーバーはトンネル内のピアを認証します。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）は、RFC 3079 [RFC3079]に従って導出された128ビットマスターキーを組み合わせて、EAP-Fast-MSChapv2から生成され、MasterSendKeyは最初の16オクテットを取り、MassReceiveKeyは最後の16オクテットを取得します。。
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 Server-UnAuthentected Provisioningモードの実装は、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.
o MSCHAPV2などのチャレンジ応答プロトコルを使用すると、サーバーを認識していないプロビジョニングモード中に、中間攻撃を検出する能力が提供されます。
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.
匿名のdiffie-hellman（DH）キー契約を使用する場合、セクション3.3で定義されているように、課題を生成する必要があります。これにより、トンネルとEAP-Fast-MSChapv2交換の結合が形成され、EAP-Fastトンネル設立中に生成されたキーイング材料を使用して、EAP-Fast-MSChapv2の課題として、プロトコル自体内で交換される課題を使用する代わりに課題になります。交換された課題は、送信時にゼロにされ、受信時に無視され、TLSキー交換から派生した課題は計算で使用されます。EAP-Fast-MSChapv2が匿名のキー契約を提供するもの以外のCiphersuiteを使用して確立されたトンネル内で使用される場合、ランダムに生成された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 Exchangeは、サーバーに有効な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.
保護されたトンネルが確立されると、通常、ピアはサーバーがピアをプロビジョニングできる前にサーバーに認証します。認証メカニズムが相互認証と中間攻撃からの保護をサポートしていない場合、サーバーを認めるプロビジョニングモードを使用する必要があります。サーバー側では、EAP-Fast-GTC（汎用トークンカード）[RFC5421]などの認証されたトンネル認証メカニズムを使用できます。これにより、パスワードデータベースや1回限りのパスワードなどの他の認証メカニズムを使用して、同様にバンド内でプロビジョニングできるようになります。
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交換は、EAP-Fast-MSChapv2を実行する前にサーバーの信頼性を確認することにより、潜在的なアクティブMITM攻撃から保護します。サーバー容認されたプロビジョニングモードは、推奨されるプロビジョニングモードです。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 Exchangeのランダムな課題として使用されます。
To generate the key material, compute:
重要な資料を生成するには、計算します。
key_block = PRF(master_secret, "key expansion", server_random + client_random);
key_block = prf（master_secret、 "key拡張"、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.
余分な重要な資料では、session_key_seedはEAPファーストクリプトバインディングTLV交換に使用され、ServerChallengeとClientChallengeは、認証サーバーのEAP-FAST-MSCHAPV2チャレンジとピアのEAP-FAST-MSCHAPV2チャレンジにそれぞれ対応しています。ServerChallengeとClientChallengeは、Diffie-Hellman Anonymous Key契約がEAP-Fastトンネル施設で使用される場合にのみ、EAP-Fast-MSChapv2 Exchangeに使用されます。
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のプロビジョニングモードは、一般的なEAP-FASTプロトコルを変更しません。したがって、Peer-ID、Server-ID、およびSession-IDが[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では、Peer-IDとServer-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でプロビジョニングした後にアクセスを許可できます（つまり、EAPファストトンネルを相互に認証および確立するために使用されるPAC）。さらに、ピアポリシーは、現在のプロビジョニング接続を切断し、新しく提供された情報を利用して認証との新しいEAP高速交換を開始するようピアに指示する場合があります。Server-Unauthenticated Provisioningモードの最後に、この会話はプロビジョニングのみを目的としているため、ネットワークアクセスが許可されないため、ネットワークアクセスを許可する必要はありません。サーバーは、成功したサーバー認証プロビジョニング交換の終了時にアクセスを付与する場合があります。
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高速認証へのスムーズな遷移を実現することができます。認証用の相互に認証された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ファーストフェーズ1トンネルを確立するために使用されるトンネルPACです。トンネルPACに加えて、他のタイプの資格情報と情報もEAP-FASTを通じてプロビジョニングできます。これらには、信頼できるルート証明書、特定の目的のためのPAC、およびユーザーのアイデンティティが含まれる場合があります。通常、プロビジョニングは、ピアとサーバーの両方が互いに認証された後、そして暗号結合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情報が特定されています。このドキュメントでは、3つのタイプのPACを定義します。トンネルPAC、マシン認証PAC、ユーザー認証PACです。
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.
サーバーは、トンネルPACをピアに配布します。これは、サーバーで安全なEAP-FAST TLSトンネルを確立しようとするその後の試みで使用します。トンネルPACには、シークレットキー（PAC-Key）、ピア（PAC-Opaque）に不透明なデータ、およびピアが解釈できるその他の情報（PAC-INFO）が含まれます。不透明データはサーバーによって生成され、暗号化された保護されているため、ピアによって変更または解釈することはできません。トンネルPACは、保護されたフェーズ2トンネルで発生しなければならないもののサーバーポリシーを伝えます。後続のTLSハンドシェイクでポリシーを実施するためにPACオパクに必要なものを含めることは、サーバーポリシー次第です。たとえば、ユーザーID、I-IDは、サーバーポリシーの一部として含めることができます。このI-ID情報は、指定されたユーザーIDに対してのみ運ばれる内部EAPメソッドを制限します。どのEAPメソッドやどのTLS暗号が許可されているかなど、他のタイプの情報も含めることができます。サーバーポリシーがPACオパークに含まれていない場合、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.
ピアは、マシン認証PACをトンネルPACとして使用して、TLSトンネルを確立できます。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-Opaque部分は、保護されたEAP-FAST TLSトンネル内に提示され、ユーザー認証がスキップされる可能性があるため、Stateless Session履歴書中にユーザー情報を提供します。ユーザー認証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のStateless Session Resumeと呼ばれます。この場合、サーバーは結果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サーバーを正常に認証し、暗号バインディングTLVを検証してTLSトンネルの完全性が無傷であることを確認した後に発行される場合があります。匿名のDH CiphersuitesはトンネルPACのプロビジョニングのみを許可されているため、匿名のciphersuiteが交渉された場合、トンネル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.
Tunnel PACの受領を確認するために、PAC-COCKNOWLEDGE属性を含むPAC-COCKNOWLEDGE属性を含むPAC-COCKNOWLEDGE属性をピアから送信する必要があります。PAC-COCKNOWLEDGE 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
0-非監視TLV 1-必須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.
OctetsのPAC属性フィールドの長さを含む2つのオクテット。
PAC Attributes
PAC属性
A list of PAC attributes in the TLV format.
TLV形式のPAC属性のリスト。
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:
タイプフィールドは2オクテットで、属性タイプを示します。割り当てられたタイプは次のとおりです。
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
1 -PAC -KEY 2 -PAC -OPAQUE 3 -PAC -LIFETIME 4 -A -ID 5 -I -ID 6 -RESERVED 7 -A -ID -ID -ID -ID 8 -PAC -cookNowledgement 9 -Pac -info 10 -Pac -Type
Length
長さ
Two octets containing the length of the Value field in octets.
オクテットの値フィールドの長さを含む2つのオクテット。
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-Keyの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-パックキー
Length
長さ
2-octet length indicating a 32-octet key
32-OCTETキーを示す2-OCTET長
Key
鍵
The value of the PAC-Key.
パックキーの価値。
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-Opaque属性は、サーバーが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-opaqueはピアにとって不透明であるため、ピアはそれを解釈しようとしてはなりません。サーバーによってPACオパクを発行されたピアは、そのデータを保存し、PACタイプに応じてサーバーに提示します。トンネルPACは、[RFC5077]で定義されているClientHello SessionTicket拡張フィールドで使用されます。ピアが複数のサーバーによって発行された不透明なデータがある場合、各サーバーが発行したデータをA-IDに従って個別に保存します。この要件により、ピアは、A-IDによって識別されたPAC-opaqueへのPACキーマッピングにより、各不透明なデータムを独立したPACペアリングとして維持および使用できます。Pac-KeyとPac-Opaqueの間に1対1の対応があるため、ピアはEAP-Fast/StartメッセージとA Aに提供されるA-IDに基づいて、PACキーと対応するPAC-Opaqueを決定します。-IDは、PAC-INFOがPACオパークでプロビジョニングされたときに提供されました。
The PAC-Opaque attribute format is summarized as follows:
PAC-Opaque属性形式は次のように要約されています。
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 -Opaque
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.
値フィールドには、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-INFOは、セクション4.2.1で定義されている一連のPAC属性で構成されています。PAC-INFO属性には、A-ID、A-ID-INFO、およびPACタイプの属性を含める必要があります。他の属性をPAC-INFOに含めて、ピアにより多くの情報を提供することができます。PAC-INFO属性には、PAC-Key、PAC-COCKNOWLEDGEMENT、PAC-INFO、またはPAC-Opaque属性を含めてはなりません。PAC-INFO属性は、サーバーが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 -INFO
Length
長さ
2-octet Length field containing the length of the attributes field in octets.
オクテットの属性フィールドの長さを含む2-OCTET長さフィールド。
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.
これは、1970年1月1日の真夜中のUTC以降、左秒を除く秒数として表される資格情報の有効期限を表す4オクテット数量です。この属性は、PAC-INFOの一部としてピアに提供される場合があります。
4 - A-ID
4 -a -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を生成する1つの方法は、高品質の乱数ジェネレーターを使用して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交換またはトンネル設立中のクライアント側認証から導き出されます。サーバーは、EAP-Fastフェーズ2の会話でI-IDを使用して、EAP-Fastフェーズ1の実行に使用される同じピアアイデンティティがEAP-Fastフェーズ2の最小1つの内側EAPメソッドでも使用されていることを検証します。内側のEAPメソッドでI-ID検証を実施すると、I-IDをPAC-IDに含めて、ピアがユニークなユーザーごとに一意のPACを実施できるようにする必要があります。I-IDがPAC-INFOから欠落している場合、トンネルPACは複数のユーザーに使用できると想定され、ピアはユニークなトンネルPACパーセルユーザーポリシーを実施しません。
7 - A-ID-Info
7-a-id-info
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-INFOに含める必要があります。
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タイプは、PACの種類を提供することを目的としています。この属性は、PAC-INFOに含める必要があります。PACタイプが存在しない場合、デフォルトはトンネル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-NOWLEDGEMENTは、ピアによるトンネルPACの受領を認めるために使用されます。ピアには、サーバーに送信されたPAC-NowledGement TLVが含まれており、新しくプロビジョニングされたトンネルPACの処理と保存の結果を示します。このTLVは、Tunnel 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
8 - PAC-Acknowledgement
8 -PAC -NOWLEDGEMENT
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
1-成功2-失敗
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-OCTET長さフィールド
PAC Type
PACタイプ
This 2-octet field defines the type of PAC being requested or provisioned. The following values are defined:
この2-OCTETフィールドは、要求またはプロビジョニングされているPACのタイプを定義します。次の値が定義されています。
1 - Tunnel PAC 2 - Machine Authentication PAC 3 - User Authorization PAC
1-トンネルPAC 2-マシン認証PAC 3-ユーザー承認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).
Server-Trusted-Root 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サーバーは、Server-Trusted-Root 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.
Server-Trusted-Root 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-Server-Certificate-Rootに設定する場合、サーバーに信頼されたルート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.
Server-Trusted-Root 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-Server-Trusted-Root TLV [RFC4851]
Length
長さ
>=2 octets
> = 2オクテット
Credential-Format
資格情報形式
The Credential-Format field is two octets. Values include:
資格情報のフィールドは2オクテットです。値は次のとおりです。
1 - PKCS#7-Server-Certificate-Root
1-PKCS＃7-Server-Certificate-Root
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.
このフィールドは無期限の長さです。資格情報形式に関連付けられたTLVが含まれています。ピアは、このTLVを使用してサーバートラストルーツを要求するときに、このフィールドを空にしたままにすることができます。
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は、EAPサーバーからサーバーに支持されたルートTLV内のピアに送信されます。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].
このセクションでは、IANAがPAC属性のタイプ値の割り当て、PACタイプTLVのPACタイプ値、およびサーバートラストルート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
1 -PAC -KEY 2 -PAC -OPAQUE 3 -PAC -LIFETIME 4 -A -ID 5 -I -ID 6 -RESERVED 7 -A -ID -ID -ID -ID 8 -PAC -cookNowledgement 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の値は、Ciscoによって管理のために割り当てられます。値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タイプの値に対して作成されています。レジストリに登録する初期値は次のとおりです。
1 - Tunnel PAC 2 - Machine Authentication PAC 3 - User Authorization PAC
1-トンネルPAC 2-マシン認証PAC 3-ユーザー承認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の値は、Ciscoによって管理のために割り当てられます。値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 Server-Trusted-Root-Root Credential Format Type」という名前の値のレジストリは、サーバーに支えられたルートTLVで使用される資格情報形式の値に対して作成されました。レジストリに登録する初期値は次のとおりです。
1 - PKCS#7-Server-Certificate-Root
1-PKCS＃7-Server-Certificate-Root
Values from 2 to 63 are allocated for management by Cisco. Values 64 to 255 are assigned with a "Specification Required" policy.
2〜63の値は、Ciscoによる管理のために割り当てられます。値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は、Server-Authenticated Provisioning ModeとServer-Unauthenticated Provisioningモードの2つの異なるプロビジョニングモードで呼び出すことができます。各モードは、中間の攻撃に対して異なるレベルの抵抗を提供します。次のリストは、中間の攻撃に関連する問題のいくつかを識別します。
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 サービス拒否
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ハンドシェイクは、ピアがハンドシェーク中にサーバーを認証するために必要な信頼のルーツおよび/またはその他の認証情報でしっかりと事前に生成されているに違いないため、サーバーとの保護された通信を保証します。この事前のプロビジョニングステップにより、攻撃者は自分自身をコミュニケーションの中間者として挿入することを防ぎます。残念ながら、多くの環境では、事前に保護された事前把握を達成するのは難しい場合があります。
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トンネルへの内部認証メカニズムの暗号化結合は、認証メカニズムのトンネルに起因する中間の攻撃からの追加の保護を提供します。
Server-Authenticated Provisioning Mode provides a high degree of protection from man-in-the-middle attacks.
Server-Authenticated Provisioningモードは、中間の攻撃から高度な保護を提供します。
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.
Server-Unauthenticated Provisioningモードでは、TLSハンドシェイクは、匿名のハンドシェイクが交渉されるか、ピアにサーバーの認証を完了するために必要な情報がないため、サーバーとの保護された通信を保証しません。これにより、攻撃者はTLS通信の真ん中に自分自身を挿入できます。
EAP-FAST Server-Unauthenticated Provisioning Mode mitigates the man-in-the-middle attack through the following techniques:
EAP-FAST SERVER-UNAUTHENTICTEDプロビジョニングモードは、次の手法を通じて中間の攻撃を軽減します。
o Binding the phase 2 authentication method to secret values derived from the phase 1 TLS exchange:
o フェーズ2認証方法を、フェーズ1 TLS交換から派生した秘密値に結合します。
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.
匿名のdiffie-hellman ciphersuiteで使用されるEAP-Fast-MSChapv2の場合、EAP-Fast-MSChapv2交換の課題はTLSの握手に由来し、EAP-Fast-MSChapv2 Exchange内で送信されません。中間の攻撃はこれらの課題を知らないため、ピアがタイムを出す前にピアからの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: 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.
o フェーズ2認証交換から派生した秘密の値の暗号化結合フェーズ1 TLS交換から派生した秘密値を使用します。これは、EAP-FAST内で定義された暗号化結合交換を使用して、中間の攻撃の存在を発見するフェーズ2のEAP-Fast-MSChapv2交換から得られた秘密情報を、フェーズ1 TLS交換からの秘密情報と結合することにより。
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を緩和するために暗号化結合のみをサポートするだけで十分でしょうが、EAP-Fast-MSCHAPV2ランダムチャレンジ派生のTLSキー契約プロトコルへの結合により、ミドル攻撃の早期検出が可能になります。これは、それ以外の場合は真のピアとサーバーの間で内側の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.
Server-Unauthedected Provisioningモードのフェーズ1を確立するために使用されるCiphersuiteは、ピアとサーバーの両方が派生したTLSマスターキーに貢献するものでなければなりません。RSAキートランスポートを使用するCiphersuitesは、この要件を満たしていません。認証された匿名の短命のディフェルマンのシファースーツは、このタイプの重要な合意を提供します。
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を内部認証交換として指定しています。ただし、トンネルを認証する他の内部認証メカニズムが将来開発される可能性があります。中間の保護の強さは内部法の強さに直接依存しているため、使用される内部方法は、少なくともEAP-Fast-MSChapv2と同じくらい攻撃に対する抵抗を提供することをお勧めします。ClearTextパスワードは、Server-unAuthenticatedプロビジョニングモードで使用しないでください。積極的な中間攻撃は、ピアが認証メカニズムが失敗するか中止されると判断するまで、フェーズ2認証方法交換を観察する可能性があることに注意してください。これにより、IDまたは認証プロトコル交換などの機密情報が中間攻撃との交換を開示できます。
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.
オフラインの辞書攻撃では、攻撃者はパスワードを回復するためにオフラインで処理できる情報をキャプチャします。Server-Authenticated Provisioningモードは、フェーズ1の間にサーバーを最初に認証せずにフェーズ2認証に従事しないため、緩和の実施を提供します。Server-UnAuthedのプロビジョニングモードは、このタイプの攻撃に対して脆弱です。フェーズ2認証中に、ピアがサーバーから応答や無効な応答を受け取らない場合、進行中の中間攻撃がある可能性があります。実装はこれらのイベントを記録し、可能であればユーザーに警告を提供する必要があります。また、環境に適したコントロールを提供することも実装されています。このコントロールは、サーバーと認知のプロビジョニングモードを実行する方法と場所を制限します。たとえば、実装は、このモードを特定のインターフェイスでのみ使用するか、過去にプロビジョニングが成功した場合にこのモードを許可する前にユーザーの介入を必要とする場合があります。
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.
見落とすべきではないもう1つの緩和手法は、十分な複雑さと長さを持つ優れたパスワードの選択と、定期的なパスワードの変更を必要とするパスワードを変更するポリシーです。
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.
Server-Authenticated Provisioningモードは、サーバーと認識されたプロビジョニングモードよりも攻撃からのはるかに優れた保護を提供するため、可能な限りサーバーを認めるプロビジョニングモードを使用する必要があります。Server-unAuthected Provisioningモードは、プロビジョニング中にデバイスを物理的に限定できる展開、またはアクティブな辞書攻撃のリスクを喜んで受け入れることができるため、実行可能なオプションを提供します。さらに、これがゼロタッチプロビジョニングを有効にし、ピア構成をほとんどまたはまったく必要としない単純な展開を容易にする唯一のオプションです。ピアは、サーバーの未認定プロビジョニングモードよりも優れたセキュリティを提供するPACプロビジョニングに、代替の安全な帯域外メカニズムを使用することを選択できます。
To encourage interoperability implementations of EAP-FAST, anonymous provisioning modes MUST support the 2048-bit group "14" in [RFC3526].
EAP-FASTの匿名プロビジョニングモードの相互運用性の実装を奨励するには、[RFC3526]の2048ビットグループ「14」をサポートする必要があります。
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 Tunnel PACには、特定のトンネルPACが他のピアのフェーズ2認証を実行できるトンネルを確立するために使用されるのを防ぐために、ピアの身元に関する情報が含まれている場合があります。サーバーがピアの認証としてトンネルPACを受け入れることは可能ですが、多くの現在の実装はこれを行いません。PACを使用してピアを認証し、承認を提供する機能は、将来の文書の対象となります。[RFC5077]は、推奨されるチケット構築セクションのパック透過形式の例を示しています。
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として使用できます。パックキーは、ピアによって秘密にされなければなりません。
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は、所有権を認証するために使用されるキーがないように、Bearer Credentialenceです。このため、このタイプのPACを明確に送信してはなりません。追加の保護のために、PACはTLSトンネルを確立するために使用されるトンネルPACにバインドされる場合があります。ピアでは、ユーザー認証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-KeyとPac-opaqueの両方を安全に保存する必要がありますが、サーバーは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.
キー発見攻撃は通常、プライベートセキュアソケットレイヤー（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.
キーがピアまたはサーバーのいずれかで攻撃者にアクセスできるようになると、それらは3つの形式の攻撃に分類されます：キーの重複、キー代替、キー変更。最初のオプションは最も一般的なものであり、攻撃者が問題のユーザーを装って装っています。2番目のオプションは、攻撃者がサーバーに実装できる場合に使用することができます。あるいは、攻撃者は、ピアまたはサーバーのいずれかに対する後者の2つの攻撃のいずれかを使用してPACのキーを強制し、EAP-Fast Server-Unauthentected Provisioningモードの潜在的な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.
もう1つの考慮事項は、特定のデバイスが提供する安全なメカニズムの使用です。たとえば、一部のラップトップは、特別なチップを介して安全なキーストレージを可能にします。このようなメカニズムの使用を実装することは価値があります。
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-MSCHAPV2会話の始まりをキャプチャすることが可能であるため、オフラインの辞書攻撃のリスクが高くなります。ただし、前述のように、中間の攻撃を検出することが可能です。
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ファーストのデザインとプロトコルの仕様は、パッドジャッカハリ、マーククリスチャー、ダグスミス、イランフレンケル、マックスプリチキン、ヤンヴィルフーバー、ジェレミーシュタイグリッツのアイデアと貢献に基づいています。著者はまた、この文書をレビューしてくれたJouni Malinen、Pasi Eronen、Jari Arkko、Chris Newman、Ran Canetti、Vijay 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] Microsoft Corporation、「MS-Chap：Microsoftチャレンジハンドシェイク認証プロトコル（Chap）仕様の拡張可能な認証プロトコル法」、2009年1月。ASPX
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「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.、Hoffman、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：Cryptographic Message Syntaxバージョン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] Zorn、G。、「Microsoft Point-to-Point暗号化（MPPE）で使用するための導入キー」、RFC 3079、2001年3月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526] Kivinen、T。およびM. Kojo、「インターネットキーエクスチェンジ（IKE）のためのよりモジュラー指数（MODP）Diffie-Hellmanグループ」、RFC 3526、2003年5月。
[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.、Blunk、L.、Vollbrecht、J.、Carlson、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] Cam-Winget、N.、McGrew、D.、Salowey、J。、およびH. Zhou、「安全なトンネリング拡張可能な認証プロトコル法（EAP-FAST）を介した柔軟な認証」、RFC 4851、2007年5月。
[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.、Zhou、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン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] Cam-Winget、N。およびH. Zhou、「Secure Tunneling拡張可能な認証プロトコル（EAP-FAST）を介した柔軟な認証内の基本的なパスワード交換」、RFC 5421、2009年3月。
[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月。
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-response/eap-fast（TLS Client hello hello sessionticket extensionで - > - >
<- EAP-Request/EAP-FAST (TLS Server Hello, TLS Server Key Exchange TLS Server Hello Done)
<-eap-request/eap-fast（TLSサーバーこんにちは、TLSサーバーキーエクスチェンジTLSサーバーHello done）
EAP-Response/EAP-FAST (TLS Client Key Exchange TLS Change Cipher Spec TLS Finished) ->
eap-response/eap-fast（TLSクライアントキーエクスチェンジTLS CIPHES SPEC TLS完成） - >
<- EAP-Request/EAP-FAST ( TLS change_cipher_spec, TLS finished, EAP-Payload-TLV (EAP-Request/Identity))
<-eap-request/eap-fast（tls change_cipher_spec、tls finishing、eap-payload-tlv（eap-request/diente））
// 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 -Response/Identity） - >
<- EAP Payload TLV (EAP-Request/EAP-FAST-MSCHAPv2 (Challenge))
<-EAPペイロードTLV（eap-request/eap-fast-mschapv2（課題））
EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Response)) ->
EAPペイロードTLV（EAP-Response/EAP-FAST-MSCHAPV2（Response）） - >
<- 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-Request/EAP-FAST-MSCHAPV2）（成功））EAPペイロードTLV（EAP-Response/EAP-FAST-MSCHAPV2（成功）） - > <-tlv（version = 1、eap-fast version = 1、nonce、commpoidmac）
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（成功）Crypto Binding-TLV（バージョン= 1、EAP-FASTバージョン= 1、NONCE、COMPUTERMAC）PAC-TLV（TYPE = 1）<結果TLV（成功）PAC TLV
Result TLV (Success) PAC Acknowledgment ->
結果TLV（成功）PAC承認 - >
TLS channel torn down (messages sent in cleartext)
TLSチャンネルが取り壊される（cleartextで送信されたメッセージ）
<- EAP-Failure
<-eap-failure
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-response/eap-fast（TLS Client Hello hello withe 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-request/eap-fast（TLSサーバーハローTLSサーバーキーエクスチェンジTLSサーバーHello Done）
<- EAP-Request/EAP-FAST ( TLS change_cipher_spec, TLS finished, EAP-Payload-TLV (EAP-Request/Identity))
<-eap-request/eap-fast（tls change_cipher_spec、tls finishing、eap-payload-tlv（eap-request/diente））
// 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-Response/Identity） - >
<- EAP Payload TLV (EAP-Request/EAP-FAST-MSCHAPv2 (Challenge))
<-EAPペイロードTLV（eap-request/eap-fast-mschapv2（課題））
EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Response)) ->
EAPペイロードTLV（EAP-Response/EAP-FAST-MSCHAPV2（Response）） - >
<- EAP Payload TLV (EAP-Request EAP-FAST-MSCHAPv2 (Success))
<-EAPペイロード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-Response/EAP-FAST-MSCHAPV2（障害）） - >
<- Result TLV (Failure)
< - 結果TLV（失敗）
Result TLV (Failure) -> TLS channel torn down (messages sent in cleartext)
結果TLV（障害） - > TLSチャンネルが取り壊される（クリアテキストで送信されたメッセージ）
<- EAP-Failure
<-eap-failure
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 Exchangeを使用したサーバー信頼されたルート証明書のプロビジョニングの成功を示しています。会話は次のように表示されます。
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-response/eap-fast（セッションチケット拡張機能なしでクライアントハロー） - > < - 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-response/eap-fast（TLSクライアントキーエクスチェンジTLS CIPHES SPEC、TLS完成） - >
<- EAP-Request/EAP-FAST (TLS Change Cipher Spec TLS Finished) (EAP-Payload-TLV( EAP-Request/Identity))
<-eap-request/eap-fast（tls Change cipher spec tls endsing）（eap-payload-tlv（eap-request/diention））
// 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-PAYLOAD TLV（EAP-Response/IDINTING） - >
<- EAP Payload TLV (EAP-Request/EAP-FAST-MSCHAPv2 (Challenge))
<-EAPペイロードTLV（eap-request/eap-fast-mschapv2（課題））
EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Response)) ->
EAPペイロードTLV（EAP-Response/EAP-FAST-MSCHAPV2（Response）） - >
<- EAP Payload TLV (EAP-Request/EAP-FAST-MSCHAPv2 (success))
<-EAPペイロードTLV（eap-request/eap-fast-mschapv2（success））
EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Success) ->
EAPペイロードTLV（EAP-Response/EAP-FAST-MSCHAPV2（成功） - >
<- Intermediate Result TLV(Success) Crypto-Binding TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC),
< - 中間結果TLV（成功）暗号結合TLV（バージョン= 1、EAP-FASTバージョン= 1、NONCE、COMPUTERMAC）、
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、NonCe、CommoneMac）Server-Trusted-Root TLV（Type = PKCS＃7） - > <結果TLV（Success）Server-Trusteded-RootTLV（PKCS＃7 TLV）
Result TLV (Success) ->
結果TLV（成功） - >
// TLS channel torn down (messages sent in cleartext)
// TLSチャンネルが取り壊される（ClearTextで送信されたメッセージ）
<- EAP-Failure
<-eap-failure
Authors' Addresses
著者のアドレス
Nancy Cam-Winget Cisco Systems 3625 Cisco Way San Jose, CA 95134 US
ナンシーカムウィンギットシスコシステム3625シスコウェイサンノゼ、カリフォルニア95134米国
EMail: ncamwing@cisco.com
David McGrew Cisco Systems 3625 Cisco Way San Jose, CA 95134 US
David McGrew Cisco Systems 3625 Cisco Way San Jose、CA 95134 US
EMail: mcgrew@cisco.com
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US
ジョセフ・サロウィ・シスコ・システム2901 3番目のアベニュー・シアトル、ワシントン州98121米国
EMail: jsalowey@cisco.com
Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US
Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield、Oh 44286 US
EMail: hzhou@cisco.com