[要約] RFC 5421は、EAP-FAST内の基本的なパスワード交換に関する仕様であり、EAP-FASTプロトコルのセキュアなトンネリング拡張認証プロトコルとしての目的を持つ。要約: EAP-FAST内のパスワード交換の仕様 目的: EAP-FASTプロトコルのセキュアなトンネリング拡張認証プロトコルとしての目的
Network Working Group N. Cam-Winget
Request for Comments: 5421 H. Zhou
Category: Informational Cisco Systems
March 2009
Basic Password Exchange within the 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-GTC reuses the EAP type code assigned to EAP-GTC (6). The reuse of previously assigned EAP Type Codes is incompatible with EAP method negotiation as defined in RFC 3748.
EAPメソッドEAP-Fast-GTCは、EAP-GTCに割り当てられたEAPタイプコードを再利用します（6）。以前に割り当てられたEAPタイプコードの再利用は、RFC 3748で定義されているEAPメソッドネゴシエーションと互換性がありません。
Since EAP-GTC does not support method-specific version negotiation, the use of EAP-FAST-GTC is implied when used inside the EAP-FAST tunnel during authentication. This behavior may cause problems in implementations where the use of another vendor's EAP-GTC is required. 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-GTCはメソッド固有のバージョンのネゴシエーションをサポートしていないため、EAP-Fast-GTCの使用は、認証中にEAP-Fastトンネル内で使用すると暗示されます。この動作は、別のベンダーのEAP-GTCの使用が必要な実装に問題を引き起こす可能性があります。このようなサポートには、トンネル内のメソッドの特別なケース実行が必要なため、トンネルメソッドの内外で同じメソッドコードを使用する実装も複雑になります。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. Within this tunnel, a basic password exchange, based on the Generic Token Card method (EAP-GTC), may be executed to authenticate the peer.
Secure Tunneling拡張可能な認証プロトコル（EAP-FAST）メソッドを介した柔軟な認証により、Transport Layer Security（TLS）を使用して相互に認証されたトンネルを確立することにより、ピアとサーバー間の安全な通信が可能になります。このトンネル内では、一般的なトークンカード法（EAP-GTC）に基づく基本的なパスワード交換を実行して、ピアを認証することができます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification Requirements .................................3
2. EAP-FAST GTC Authentication .....................................3
3. Security Considerations .........................................7
3.1. Security Claims ............................................7
4. IANA Considerations .............................................8
5. Acknowledgments .................................................9
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References .....................................9
EAP-FAST [RFC4851] is an EAP method that can be used to mutually authenticate a peer and server. This document describes the EAP-FAST inner EAP method, EAP-FAST-GTC, which is used to authenticate the peer through a basic password exchange. EAP-FAST-GTC was developed to support using cleartext passwords to authenticate to legacy user databases, to facilitate password change, and to support one time password features such as new pin mode. Message exchanges, including user credentials, are cleartext strings transferred within the encrypted TLS tunnel and thus are considered secure. For historical reasons, EAP-FAST-GTC uses EAP Type 6, originally allocated to EAP-GTC [RFC3748]. Note that EAP-FAST-GTC payloads used in EAP-FAST require specific formatting and therefore will not necessarily be compatible with EAP-GTC mechanisms used outside of EAP-FAST. To avoid interference between these two methods, EAP-FAST-GTC MUST NOT be used outside an EAP-FAST tunnel, and EAP-GTC MUST NOT be used inside an EAP-FAST tunnel. All EAP-FAST-GTC packets sent within the TLS tunnel must be encapsulated in EAP Payload TLVs, described in [RFC4851].
EAP-FAST [RFC4851]は、ピアとサーバーを相互に認証するために使用できるEAPメソッドです。このドキュメントでは、基本的なパスワード交換を介してピアを認証するために使用されるEAP高速の内側EAPメソッドEAP-Fast-GTCについて説明します。EAP-Fast-GTCは、ClearTextパスワードを使用してレガシーユーザーデータベースに認証し、パスワードの変更を容易にし、新しいPINモードなどの1回限りのパスワード機能をサポートするために開発されました。ユーザー資格情報を含むメッセージ交換は、暗号化されたTLSトンネル内で転送されるクリアテキスト文字列であるため、安全であると見なされます。歴史的な理由で、EAP-Fast-GTCは、元々EAP-GTCに割り当てられたEAPタイプ6を使用します[RFC3748]。EAP-FASTで使用されるEAP-Fast-GTCペイロードには、特定の書式が必要であるため、EAP-Fast以外で使用されるEAP-GTCメカニズムと必ずしも互換性があるとは限りません。これら2つの方法間の干渉を避けるために、EAP-Fast-GTCはEAP-Fastトンネルの外で使用してはなりません。EAP-GTCはEAP-Fastトンネル内で使用してはなりません。TLSトンネル内で送信されるすべてのEAP-Fast-GTCパケットは、[RFC4851]で説明されているEAPペイロードTLVにカプセル化する必要があります。
It is assumed that a reader of this document is familiar with EAP-FAST [RFC4851].
このドキュメントの読者は、EAP-FAST [RFC4851]に精通していると想定されています。
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]に記載されているように解釈される。
All EAP-FAST-GTC packets inside EAP-FAST other than the empty acknowledgment packet MUST follow the "LABEL=Value" format. All Labels are in ASCII text and SHALL NOT contain the space character. Currently, three Labels are defined:
o "CHALLENGE", the server request packet MUST be in the form of "CHALLENGE=Value", where Value is the server challenge, such as "please enter your password".
o
o "RESPONSE", the peer response packet MUST be in the form of "RESPONSE=Value", where Value is the peer response.
o 「応答」、ピアレスポンスパケットは、「応答=値」の形でなければなりません。ここで、値はピア応答です。
o "E", the server failure packet MUST be in the form of "E=Value", where Value is the error message generated by the server.
o 「e」、サーバー障害パケットは「e = value」の形式でなければなりません。ここで、値はサーバーによって生成されるエラーメッセージです。
If the peer or the server receives an EAP-FAST-GTC request or response that is not in the format specified above, it SHOULD fail the authentication by sending a Result TLV with a failure.
After the TLS encryption tunnel is established and EAP-FAST Authentication phase 2 starts, the EAP server sends an EAP-FAST-GTC Request, which contains a server challenge. The server challenge is a displayable message for use by the peer to prompt the user.
A peer MAY prompt the user for the user credentials, or decide to use the user credentials gained through some other means without prompting the user. The peer sends the user credentials back in the EAP-FAST-GTC Response using the following format:
"RESPONSE=user@example.com\0secret"
「Response=user@example.com \ 0Secret」
where "user@example.com" is the actual username and "secret" is the actual password. The NULL character "\0" is used to separate the username and password.
「user@example.com」は実際のユーザー名であり、「secret」が実際のパスワードです。null文字「\ 0」は、ユーザー名とパスワードを分離するために使用されます。
The username and password are included in a single message in the first response packet as an optimization by eliminating the inner method EAP-Identity exchange to save an extra round trip.
ユーザー名とパスワードは、最適化として、最初の応答パケットの単一のメッセージに含まれています。
Once the EAP-FAST server receives the user credentials, it SHOULD first validate the user identity with the Initiator ID (I-ID) [RFC5422] in the PAC-Opaque (Protected Access Credential) and if it matches, it will continue to authenticate the user with internal or external user databases.
EAP-Fastサーバーがユーザー資格情報を受信したら、最初にPAC-Opaque（Protected Access Credential）のInitiator ID（I-ID）[RFC5422]でユーザーIDを検証する必要があります。内部または外部のユーザーデータベースを持つユーザー。
Additional exchanges MAY occur between the EAP-FAST server and peer to facilitate various user authentications. The EAP-FAST server might send additional challenges to prompt the peer for additional information, such as a request for the next token or a new pin in the one time password case, or a server failure packet to indicate an error. The peer displays the prompt to the user again and sends back the needed information in an EAP-FAST-GTC Response. The exchange ends when a Result TLV is received.
さまざまなユーザー認証を容易にするために、EAP-Fastサーバーとピアの間で追加の交換が発生する場合があります。EAP-Fastサーバーは、次のトークンのリクエストやワンタイムパスワードケースの新しいピン、またはエラーを示すサーバー障害パケットなど、追加情報を求める追加の課題を送信する可能性があります。ピアは、プロンプトを再度ユーザーに表示し、EAP-Fast-GTC応答で必要な情報を返送します。結果TLVを受信すると、交換は終了します。
An EAP-FAST-GTC server implementation within EAP-FAST uses the following format to indicate an error if an authentication fails:
EAP-FAST内のEAP-Fast-GTCサーバーの実装は、次の形式を使用して、認証が故障した場合にエラーを示します。
"E=eeeeeeeeee R=r M=<msg>"
where:
ただし：
The "eeeeeeeeee" is the ASCII representation of a decimal error code corresponding to one of those listed below, though peer implementations SHOULD deal with codes not on this list gracefully.
「eeeeeeeeee」は、以下にリストされているものの1つに対応する10進エラーコードのASCII表現ですが、ピアの実装はこのリストではないコードを優雅に扱う必要があります。
The error code need not be 10 digits long.
エラーコードは10桁の長さである必要はありません。
Below is a complete list of predefined error codes:
以下は、事前定義されたエラーコードの完全なリストです。
o 646 ERROR_RESTRICTED_LOGON_HOURS
o 646 ERROR_RESTRICTED_LOGON_HOURS
Indicates that access is attempted outside the allowed hours. Peer implementations SHOULD display the error message to the user and ask the user to try at a later time.
アクセスが許可された時間以外で試行されることを示します。ピアの実装は、ユーザーにエラーメッセージを表示し、後で試してみるようにユーザーに依頼する必要があります。
o 647 ERROR_ACCT_DISABLED
o 647 error_acct_disabled
Indicates that the requested account is disabled. Peer implementations SHOULD display the error message to the user, which helps the user to resolve the issue with the administrator.
要求されたアカウントが無効になっていることを示します。ピアの実装は、ユーザーにエラーメッセージを表示する必要があります。これにより、ユーザーが管理者との問題を解決できるようになります。
o 648 ERROR_PASSWD_EXPIRED
o 648 error_passwd_expired
Indicates that the password has expired and a password change is required. Peer implementations SHOULD prompt the user for a new password and send back the new password in the peer response packet.
パスワードの有効期限が切れており、パスワードの変更が必要であることを示します。ピアの実装では、ユーザーに新しいパスワードを求めて、ピアレスポンスパケットの新しいパスワードを送信する必要があります。
o 649 ERROR_NO_DIALIN_PERMISSION
o 649 error_no_dialin_permission
Indicates that access has been denied due to lack of dial-in permission. Peer implementations SHOULD display the error message to the user, which helps the user to resolve the issue with the administrator.
ダイヤルイン許可がないためにアクセスが拒否されたことを示します。ピアの実装は、ユーザーにエラーメッセージを表示する必要があります。これにより、ユーザーが管理者との問題を解決できるようになります。
o 691 ERROR_AUTHENTICATION_FAILURE
o 691 error_authentication_failure
Indicates that there was authentication failure due to an incorrect username or password. Based on the retry flag described below, peer implementations MAY prompt the user again for a new set of username and password or simply send back an empty acknowledgment packet to acknowledge the failure and go into the termination phase of the authentication session.
誤ったユーザー名またはパスワードのために認証障害があったことを示します。以下に説明する再生フラグに基づいて、ピアの実装は、ユーザー名とパスワードの新しいセットについてユーザーに再度促すか、単に空の確認パケットを送り返して失敗を確認し、認証セッションの終了フェーズに移動する場合があります。
o 709 ERROR_CHANGING_PASSWORD
o 709 error_changing_password
Indicates that the password change failed, most likely because the new password fails to meet the password complexity policy. Peer implementations SHOULD display the error message and prompt the user again for the new password.
新しいパスワードがパスワードの複雑さポリシーを満たしていない可能性が高いため、パスワードの変更が失敗したことを示します。ピアの実装は、エラーメッセージを表示し、新しいパスワードのユーザーに再度プロンプトする必要があります。
o 755 ERROR_PAC_I-ID_NO_MATCH
o 755 ERROR_PAC_I-ID_NO_MATCH
Indicates that the PAC used to establish the EAP-FAST session cannot be used to authenticate to this user account. Based on the retry flag described below, peer implementations MAY prompt the user again for a new set of username and password or simply send back an empty acknowledgment packet to acknowledge the failure and go into the termination phase of the authentication session.
EAP-FASTセッションの確立に使用されるPACを使用して、このユーザーアカウントに認証できないことを示します。以下に説明する再生フラグに基づいて、ピアの実装は、ユーザー名とパスワードの新しいセットについてユーザーに再度促すか、単に空の確認パケットを送り返して失敗を確認し、認証セッションの終了フェーズに移動する場合があります。
The "r" is a single character ASCII flag set to '1' if a retry is allowed, and '0' if not. When the server sets this flag to '1', it disables short timeouts, expecting the peer to prompt the user for new credentials and to resubmit the response. When the server sets this flag to '0', the peer SHOULD NOT prompt the user for new credentials to try again without restarting the EAP-FAST authentication from the beginning.
「R」は、再試行が許可されている場合は「1」に設定された単一の文字ASCIIフラグ、およびそうでない場合は「0」です。サーバーがこのフラグを「1」に設定すると、短いタイムアウトを無効にし、ピアがユーザーに新しい資格情報を求めて応答を再提出することを期待します。サーバーがこのフラグを「0」に設定した場合、ピアは、最初からEAP高速認証を再起動せずに、新しい資格情報をユーザーに再試行するように促すべきではありません。
The <msg> is human-readable ASCII text. Current implementations only support ASCII text.
<sg>は、人間が読み取ることができるASCIIテキストです。現在の実装は、ASCIIテキストのみをサポートしています。
The server failure packet can be broken into Label/Value pairs using the space character as the separator. The only value that may contain the space character is the <msg> value, which is always the last value pair in the failure packet. The peer SHOULD ignore any unknown label/value pair in the failure packet.
サーバー障害パケットは、スペース文字をセパレーターとして使用して、ラベル/値のペアに分割できます。スペース文字を含む可能性のある唯一の値は<msg>値です。これは、故障パケットの常に最後の値ペアです。ピアは、故障パケットの未知のラベル/値ペアを無視する必要があります。
The error format described above is similar to what is defined in the Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2) [RFC2759], except for the omission of a server challenge. So if the EAP-FAST server is distributing MSCHAPv2 exchanges to the backend inner method server, it can simply return what the backend inner method server returns less the server challenge. In the case of connecting to a one time password or Lightweight Directory Access Protocol (LDAP) [RFC4511] server, the EAP-FAST server can translate the error message into this format. With the addition of the retry count, the peer can potentially prompt the user for new credentials to try again without restarting the EAP-FAST authentication from the beginning. The peer will respond to the error code with another EAP-FAST-GTC Response packet with both the new username and password, or in case of other unrecoverable failures, an empty EAP-FAST-GTC packet for acknowledgement. The peer uses empty EAP-FAST-GTC payload as an acknowledgment of the unrecoverable failure.
上記のエラー形式は、Microsoftチャレンジハンドシェイク認証プロトコルバージョン2（MSCHAPV2）[RFC2759]で定義されているものと類似しています。したがって、EAP-FastサーバーがMSCHAPV2交換をバックエンドInnerメソッドサーバーに配布している場合、バックエンドインナーメソッドサーバーがサーバーチャレンジを返すものを返すだけです。ワンタイムパスワードまたは軽量ディレクトリアクセスプロトコル（LDAP）[RFC4511]サーバーに接続する場合、EAP-Fastサーバーはエラーメッセージをこの形式に変換できます。再試行カウントを追加すると、ピアは、初めからEAPファスト認証を再起動せずに、新しい資格情報をユーザーに再試行するように促す可能性があります。ピアは、新しいユーザー名とパスワードの両方を使用して、別のEAP-Fast-GTC応答パケットでエラーコードに応答します。また、他の回復不可能な障害の場合、承認用の空のEAP-Fast-GTCパケット。ピアは、回復不可能な障害の認識として、空のEAP-Fast-GTCペイロードを使用します。
If the EAP-FAST server finishes authentication for the EAP-FAST-GTC inner method, it will proceed to Protected Termination as described in [RFC4851]. In the case of an unrecoverable EAP-FAST-GTC authentication failure, the EAP server can send an EAP-FAST-GTC error code as described above, along with the Result TLV for protected termination. This way, no extra round trips will occur. The peer can acknowledge the EAP-FAST-GTC failure as well as the Result TLV within the same EAP-FAST packet. Once the server receives the acknowledgement, the TLS tunnel will be torn down and a clear text EAP-Failure will be sent.
EAP-FastサーバーがEAP-Fast-GTC内部法の認証を完了すると、[RFC4851]で説明されているように、保護された終了に進みます。回復不可能なEAP-FAST-GTC認証障害の場合、EAPサーバーは、上記のようにEAP-Fast-GTCエラーコードを送信し、保護された終了の結果TLVを送信できます。これにより、余分な往復は発生しません。ピアは、同じEAP-FASTパケット内の結果TLVと同様に、EAP-Fast-GTC障害と結果を認めることができます。サーバーが確認を受信すると、TLSトンネルが取り壊され、明確なテキストが送信されます。
The username and password, as well as server challenges, MAY support non-ASCII characters. In this case, international username, password, and messages are based on the use of Unicode characters, encoded as UTF-8 [RFC3629] and processed with a certain algorithm to ensure a canonical representation. The username and password input SHOULD be processed according to Section 2.4 of [RFC4282], and the server challenges SHOULD be processed according to [RFC5198].
ユーザー名とパスワード、およびサーバーの課題は、非ASCII文字をサポートする場合があります。この場合、国際的なユーザー名、パスワード、およびメッセージは、UTF-8 [RFC3629]としてエンコードされ、特定のアルゴリズムで処理されて標準表現を確保するために特定のアルゴリズムで処理されるUnicode文字の使用に基づいています。ユーザー名とパスワードの入力は[RFC4282]のセクション2.4に従って処理する必要があり、サーバーの課題は[RFC5198]に従って処理する必要があります。
Since EAP-FAST-GTC does not generate session keys, the MSKi (Master Session Key) used for crypto-binding for EAP-FAST will be filled with all zeros.
EAP-Fast-GTCはセッションキーを生成しないため、EAP-FASTの暗号結合に使用されるMSKI（マスターセッションキー）はすべてのゼロで満たされます。
The EAP-FAST-GTC method sends password information in the clear and MUST NOT be used outside of a protected tunnel providing strong protection, such as the one provided by EAP-FAST. Weak encryption, such as 40-bit encryption or NULL cipher, MUST NOT be used. In addition, the peer MUST authenticate the server before disclosing its credentials. Since EAP-FAST Server-Unauthenticated Provisioning Mode does not authenticate the server, EAP-FAST-GTC MUST NOT be used as the inner method in this mode. EAP-FAST-GTC MAY be used in EAP-FAST authentication and Server-Authenticated Provisioning Mode [RFC5422], where the server is authenticated. Since EAP-FAST-GTC requires the server to have access to the actual authentication secret, it is RECOMMENDED to vary the stored authentication validation data by domain so that a compromise of a server at one location does not compromise others.
EAP-Fast-GTCメソッドは、パスワード情報をクリアに送信し、EAP-Fastが提供するような強力な保護を提供する保護されたトンネルの外で使用してはなりません。40ビット暗号化やヌルコイなどの弱い暗号化は使用しないでください。さらに、ピアは資格情報を開示する前にサーバーを認証する必要があります。EAP-FAST Server-UnAuthenticated Provisioningモードはサーバーを認証しないため、EAP-Fast-GTCをこのモードの内部方法として使用する必要はありません。EAP-Fast-GTCは、EAP-FAST認証およびサーバー認証プロビジョニングモード[RFC5422]で使用できます。ここで、サーバーが認証されています。EAP-Fast-GTCはサーバーが実際の認証シークレットにアクセスする必要があるため、1つの場所でサーバーの妥協が他のものを妥協しないように、ドメインごとに保存された認証検証データを変更することをお勧めします。
This section provides the needed security claim requirement for EAP [RFC3748].
このセクションでは、EAP [RFC3748]に必要なセキュリティ請求要件を提供します。
Auth. mechanism: Password based. Ciphersuite negotiation: No. However, such negotiation is provided by EAP-FAST for the outer authentication. Mutual authentication: No. However, EAP-FAST provides server-side authentication. Integrity protection: No. However, any method executed within the EAP-FAST tunnel is protected. Replay protection: See above. Confidentiality: See above. Key derivation: Keys are not generated, see Section 2. However, when used inside EAP-FAST, the outer method will provide keys. See [RFC4851] for the properties of those keys. Key strength: See above. Dictionary attack prot.: No. However, when used inside the EAP-FAST tunnel, the protection provided by the TLS tunnel prevents an off-line dictionary attack.
認証。メカニズム：パスワードベース。Ciphersuiteの交渉：いいえ。ただし、そのような交渉は、外部認証のためにEAP-FASTによって提供されます。相互認証：いいえ。ただし、EAP-FASTはサーバー側の認証を提供します。整合性保護：いいえ。ただし、EAP-Fastトンネル内で実行されるすべての方法は保護されています。リプレイ保護：上記を参照してください。機密性：上記を参照してください。キー派生：キーは生成されません。セクション2を参照してください。ただし、EAP-FAST内で使用すると、外側の方法はキーを提供します。これらのキーのプロパティについては、[RFC4851]を参照してください。重要な強さ：上記を参照してください。辞書攻撃PROT。：いいえ。ただし、EAP-Fastトンネル内で使用すると、TLSトンネルによって提供される保護は、オフライン辞書攻撃を防ぎます。
Fast reconnect: No. However, EAP-FAST provides a fast reconnect capability that allows the reuse of an earlier session authenticated by EAP-FAST-GTC. Cryptographic binding: No. Given that no keys are generated, EAP-FAST-GTC or its use within EAP-FAST cannot provide a cryptographic assurance that no binding attack has occurred. EAP-FAST-GTC is required only to run within a protected tunnel, but even the use of the same credentials in some other, unprotected context might lead to a vulnerability. As a result, credentials used in EAP-FAST-GTC SHOULD NOT be used in other unprotected authentication mechanisms. Session independence: No. However, EAP-FAST provides session independence. Fragmentation: No. However, EAP-FAST provides support for this. Key Hierarchy: Not applicable. Channel binding: No, though EAP-FAST can be extended for this.
高速再接続：いいえ。ただし、EAP-FASTは、EAP-Fast-GTCによって認証された以前のセッションの再利用を可能にする高速再接続機能を提供します。暗号化の結合：いいえ。キーが生成されていないことを考えると、EAP-FAST-GTCまたはEAP-FAST内での使用は、結合攻撃が発生していないという暗号化の保証を提供することはできません。EAP-Fast-GTCは、保護されたトンネル内でのみ実行するために必要ですが、他のいくつかの保護されていないコンテキストで同じ資格情報を使用することでさえ、脆弱性につながる可能性があります。その結果、EAP-Fast-GTCで使用される資格情報は、他の保護されていない認証メカニズムで使用されるべきではありません。セッションの独立性：いいえ。ただし、EAP-FASTはセッションの独立性を提供します。断片化：いいえ。ただし、EAP-FASTはこれをサポートしています。キー階層：該当なし。チャネルバインディング：いいえ、このためにEAP-FASTを拡張できます。
EAP-FAST-GTC uses the assigned value of 6 (EAP-GTC) for the EAP Type in [RFC3748].
EAP-Fast-GTCは、[RFC3748]のEAPタイプに割り当てられた値6（EAP-GTC）を使用します。
This document defines a registry for EAP-FAST-GTC error codes when running inside EAP-FAST, named "EAP-FAST GTC Error Codes". It may be assigned by Specification Required as defined in [RFC5226]. A summary of the error codes defined so far is given below:
このドキュメントでは、EAP-FASTの「EAP-FAST GTCエラーコード」と呼ばれるEAP-FAST内で実行される場合のEAP-FAST-GTCエラーコードのレジストリを定義します。[RFC5226]で定義されているように必要な仕様によって割り当てられる場合があります。これまでに定義されたエラーコードの概要を以下に示します。
o 646 ERROR_RESTRICTED_LOGON_HOURS
o 646 ERROR_RESTRICTED_LOGON_HOURS
o 647 ERROR_ACCT_DISABLED
o 647 error_acct_disabled
o 648 ERROR_PASSWD_EXPIRED
o 648 error_passwd_expired
o 649 ERROR_NO_DIALIN_PERMISSION
o 649 error_no_dialin_permission
o 691 ERROR_AUTHENTICATION_FAILURE
o 691 error_authentication_failure
o 709 ERROR_CHANGING_PASSWORD
o 709 error_changing_password
o 755 ERROR_PAC_I-ID_NO_MATCH No IANA registry will be created for Labels, as current implementations only support the Labels defined in this document and new Labels are not expected; if necessary, new Labels can be defined in documents updating this document.
o 755 ERROR_PAC_I-ID_NO_MATCH IANAレジストリはラベル用に作成されます。現在の実装は、このドキュメントで定義されているラベルのみをサポートしており、新しいラベルは予想されないためです。必要に応じて、このドキュメントを更新するドキュメントで新しいラベルを定義できます。
The authors would like thank Joe Salowey and Amir Naftali for their contributions of the problem space, and Jouni Malinen, Pasi Eronen, Jari Arkko, and Chris Newman for reviewing this document.
著者は、この文書をレビューしてくれたJoe SaloweyとAmir Naftaliが問題スペースの貢献をしてくれたことに感謝します。
[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月。
[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月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「ネットワークアクセス識別子」、RFC 4282、2005年12月。
[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月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J。およびM. Padlipsky、「ネットワークインターチェンジのユニコード形式」、RFC 5198、2008年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月。
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.
[RFC2759] Zorn、G。、「Microsoft PPP Chap Extensions、バージョン2」、RFC 2759、2000年1月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J。、「Lightweight Directory Access Protocol（LDAP）：The Protocol」、RFC 4511、2006年6月。
[RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", RFC 5422, March 2009.
[RFC5422] Cam-Winget、N.、McGrew、D.、Salowey、J。、およびH. Zhou、「安全なトンネル拡張可能な認証プロトコル（EAP-FAST）を介した柔軟な認証を使用した動的プロビジョニング」、RFC 5422、2009年3月。
Authors' Addresses
著者のアドレス
Nancy Cam-Winget Cisco Systems 3625 Cisco Way San Jose, CA 95134 US
ナンシーカムウィンギットシスコシステム3625シスコウェイサンノゼ、カリフォルニア95134米国
EMail: ncamwing@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