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.
著作権(C)2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書(http://trustee.ietf.org/license-info)の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者(複数可)材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者(単数または複数)から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
IESG Note
IESG注意
EAP-FAST has been implemented by many vendors and it is used in the Internet. Publication of this specification is intended to promote interoperability by documenting current use of existing EAP methods within EAP-FAST.
EAP-FASTは、多くのベンダーによって実装されており、それがインターネットで使用されています。この仕様書の発行は、EAP-FAST内に存在するEAPメソッドの現在の使用を文書化することにより、相互運用性を促進することを意図しています。
The EAP method EAP-FAST-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(6)に割り当てられたEAPタイプコードを再利用します。 RFC 3748で定義されるように以前に割り当てられたEAPタイプコードの再利用は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トンネル内で使用される場合、EAP-FAST-GTCを使用することが暗示されます。この動作は、他のベンダーの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.
セキュアなトンネリング拡張認証プロトコル(EAP-FAST)メソッドを介してフレキシブル認証は、相互認証されたトンネルを確立するために、トランスポート層セキュリティ(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-FAST内部EAPメソッド、EAP-FAST-GTCを、説明しています。 EAP-FAST-GTCは、パスワードの変更を容易にするため、従来のユーザーデータベースへの認証にクリアテキストのパスワードを使用してサポートするために、そのような新しいピンモードとして、ワンタイムパスワード機能をサポートするために開発されました。ユーザ認証情報を含むメッセージ交換は、暗号化されたTLSトンネル内で転送クリアテキスト文字列であり、従って、セキュアであると考えられます。歴史的な理由のために、EAP-FAST-GTCは、元々EAP-GTC [RFC3748]に割り当てられたEAPタイプ6を使用します。 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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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:
空の確認応答パケット以外のEAP-FAST内部のすべてのEAP-FAST-GTCパケットは、「LABEL =値」の形式に従わなければなりません。すべてのラベルは、ASCIIテキストであり、空白文字を含んではなりません。現在、3つのラベルが定義されています。
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「CHALLENGE」、サーバ要求パケットは、「パスワードを入力してください」などの値は、サーバのチャレンジである「CHALLENGE =値」の形式でなければなりません。
o "RESPONSE", the peer response packet MUST be in the form of "RESPONSE=Value", where Value is the peer response.
「応答」O、ピア応答パケット値は、ピア応答である「RESPONSE =値」の形式でなければなりません。
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 =値」の形式でなければなりません。
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.
ピアまたはサーバが上記指定された形式ではないEAP-FAST-GTC要求または応答を受信した場合、それは失敗で結果TLVを送信することによって認証を失敗します。
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.
TLS暗号化トンネルが確立され、EAP-FAST認証段階2が開始された後、EAPサーバは、サーバチャレンジを含んEAP-FAST-GTC要求を送信します。サーバのチャレンジは、ユーザにプロンプトを表示するために、ピアで使用するための表示可能メッセージです。
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:
ピアは、ユーザーの資格情報の入力をユーザーに求めるか、ユーザーにメッセージを表示せずに他の手段を通じて得られたユーザーの資格情報を使用することもできます。ピアは次の形式を使用してEAP-FAST-GTC応答に戻ってユーザーの資格情報を送信します。
"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」は、実際のユーザ名と「秘密」であることは、実際のパスワードです。 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.
ユーザ名とパスワードは、余分なラウンドトリップを保存するために内部方式EAP-アイデンティティ交換を排除することによって最適化などの最初の応答パケット内の単一のメッセージに含まれています。
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-不透明(保護アクセス資格)におけるイニシエータ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サーバは、このようなエラーを示すために、次のトークンやワンタイムパスワードの場合、新しいPINの要求、またはサーバ障害パケットなどの追加情報については、ピアを促す新たな課題を、送信することがあります。ピアは再びユーザーにプロンプトを表示し、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>"
"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
646 ERROR_RESTRICTED_LOGON_HOURS O
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
648 ERROR_PASSWD_EXPIRED O
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
649 ERROR_NO_DIALIN_PERMISSION O
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
691 ERROR_AUTHENTICATION_FAILURE O
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
709 ERROR_CHANGING_PASSWORD O
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
755 ERROR_PAC_I-ID_NO_MATCH O
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.
PACは、EAP-FASTセッションは、このユーザーアカウントの認証に使用することはできません確立するために使用されることを示します。後述のリトライフラグに基づいて、ピア実装は、ユーザー名とパスワードの新しいセットのために再びユーザを促したり、単に障害を認識し、認証セッションの終了段階に入るために、空の確認応答パケットを送り返します。
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」、および「0」でない場合に設定された単一文字のASCIIフラグです。サーバが「1」にこのフラグを設定すると、それは新しい資格情報をユーザーに促すため、応答を再送信するためにピアを期待して、短いタイムアウトを無効にします。サーバが「0」にこのフラグを設定すると、ピアは新しい資格情報が最初からEAP-FAST認証を再起動せずに再試行するためにユーザーに要求すべきではありません。
The <msg> is human-readable ASCII text. Current implementations only support ASCII text.
<MSG>は、人間が読める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の交換を配布しているのであれば、それは単にバックエンド内部方式サーバが少ないサーバーチャレンジを返すものを返すことができます。ワンタイムパスワードまたはLDAP(Lightweight Directory Access Protocol)[RFC4511]サーバに接続する場合は、EAP-FASTサーバは、この形式にエラーメッセージを翻訳することができます。再試行回数の追加により、ピアは潜在的に最初からEAP-FAST認証を再起動せずに再試行する新しい資格情報の入力をユーザーに求めることができます。ピアは、受信確認のための空の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]に記載されているように、それは保護終了に進みます。保護終了の結果TLVとともに、上述したように、回復不能なEAP-FAST-GTC認証失敗の場合には、EAPサーバは、EAP-FAST-GTCエラーコードを送信することができます。このように、余分なラウンドトリップは発生しません。ピアは、EAP-FAST-GTCの障害だけでなく、同じEAP-FASTパケット内の結果TLVを確認することができます。サーバが確認応答を受信すると、TLSトンネルが切断され、クリアテキストEAP-失敗が送信されます。
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
ユーザー名とパスワードだけでなく、サーバー上の課題は、非ASCII文字をサポートするかもしれません。この場合、国際ユーザー名、パスワード、およびメッセージがUTF-8としてエンコードされたUnicode文字の使用は、[RFC3629]に基づいており、特定のアルゴリズムで処理されます
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].
標準的な表現を確保。ユーザー名とパスワードの入力は、[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ビットの暗号化またはNULL暗号として、使用してはいけません。また、ピアはその資格情報を開示する前に、サーバーを認証する必要があります。 EAP-FASTサーバ認証なしの提供モードがサーバを認証しないので、EAP-FAST-GTCは、このモードでは内部方式として使用することはできません。 EAP-FAST-GTCは、サーバーが認証されたEAP-FAST認証およびサーバー認証のプロビジョニングモード[RFC5422]で使用することができます。 EAP-FAST-GTCは、実際の認証秘密へのアクセス権を持っているサーバーを必要とするので、一つの場所でのサーバーの妥協は他人を損なわないように、ドメインによって格納されている認証検証データを変更することをお勧めします。
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.
認証。メカニズム:パスワードベース。暗号スイートネゴシエーション:号しかしながら、このような交渉は、外側認証のためにEAP-FASTによって提供されます。相互認証:号しかしながら、EAP-FASTは、サーバ側の認証を提供します。完全性保護:号しかしながら、EAP-FASTトンネル内で実行される任意の方法は、保護されています。リプレイ保護:上記を参照してください。機密性:上記を参照してください。鍵導出:キーが生成されていないが、しかし、2節を参照してくださいEAP-FAST内部で使用する場合、外側のメソッドは、キーを提供します。これらのキーのプロパティの[RFC4851]を参照してください。キー強度:上記を参照してください。 EAP-FASTトンネル内で使用される場合、辞書攻撃PROT:号しかしながら、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 GTCエラーコードを」という名前の、EAP-FAST内部で実行されている場合は、この文書では、EAP-FAST-GTCエラーコードのレジストリを定義します。 [RFC5226]で定義されるように、それは、仕様が必要によって割り当てられてもよいです。これまでに定義されたエラーコードの概要は以下の通りであります:
o 646 ERROR_RESTRICTED_LOGON_HOURS
646 ERROR_RESTRICTED_LOGON_HOURS O
o 647 ERROR_ACCT_DISABLED
O 647 ERROR_ACCT_DISABLED
o 648 ERROR_PASSWD_EXPIRED
648 ERROR_PASSWD_EXPIRED O
o 649 ERROR_NO_DIALIN_PERMISSION
649 ERROR_NO_DIALIN_PERMISSION O
o 691 ERROR_AUTHENTICATION_FAILURE
691 ERROR_AUTHENTICATION_FAILURE O
o 709 ERROR_CHANGING_PASSWORD
709 ERROR_CHANGING_PASSWORD O
o 755 ERROR_PAC_I-ID_NO_MATCH
755 ERROR_PAC_I-ID_NO_MATCH O
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.
現在の実装でのみサポートされ、この文書と新しいラベルで定義されたラベルが期待されていないとして、何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.
作者はこのドキュメントを再検討するために、ジョーSaloweyとアミールNaftali問題空間の彼らの貢献のため、およびJouni Malinen、パシEronen、ヤリArkko、およびクリスニューマンに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル(EAP)"、RFC 3748、2004年6月。
[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]カムウィンゲット、N.、マグリュー、D.、Salowey、J.、およびH.周、RFC 4851、2007年5月 "(EAP-FAST)セキュアなトンネリング拡張認証プロトコル方法を介してフレキシブル認証"。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J.とM. Padlipsky、 "ネットワークインターチェンジのUnicodeフォーマット"、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]ソーン、G.、 "マイクロソフトPPP CHAP拡張、Version 2"、RFC 2759、2000年1月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、 "ライトウェイトディレクトリアクセスプロトコル(LDAP):プロトコル"、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]、RFC 5422、2009年3月 "(EAP-FAST)セキュアなトンネリング拡張認証プロトコルを介して柔軟な認証の使用動的プロビジョニング" CAM-ウィンゲット、N.、マグリュー、D.、Salowey、J.、およびH.周。
Authors' Addresses
著者のアドレス
Nancy Cam-Winget Cisco Systems 3625 Cisco Way San Jose, CA 95134 US
ナンシー・カム・ウィンゲットシスコシステムズ3625のCiscoウェイサンノゼ、CA 95134米国
EMail: ncamwing@cisco.com
メールアドレス:ncamwing@cisco.com
Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US
ハオ周シスコシステムズ4125ハイランダーパークウェイリッチフィールド、オハイオ州44286米国
EMail: hzhou@cisco.com
メールアドレス:hzhou@cisco.com