[要約] RFC 7055は、拡張認証プロトコルのためのGSS-APIメカニズムに関する規格です。このRFCの目的は、セキュアな認証メカニズムを提供し、拡張認証プロトコルの実装を促進することです。
Internet Engineering Task Force (IETF) S. Hartman, Ed.
Request for Comments: 7055 Painless Security
Category: Standards Track J. Howlett
ISSN: 2070-1721 JANET(UK)
December 2013
A GSS-API Mechanism for the Extensible Authentication Protocol
拡張認証プロトコルのGSS-APIメカニズム
Abstract
概要
This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Extensible Authentication Protocol mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL) applications use the Extensible Authentication Protocol.
このドキュメントでは、拡張認証プロトコルメカニズムを使用するときに、Generic Security Service Application Program Interface（GSS-API）を実装するピアが使用するプロトコル、手順、および規則を定義します。これらのプロトコルは、RFC 5801で定義されているGS2ファミリーのメカニズムを通じて、Simple Authentication and Security Layer（SASL）アプリケーションがExtensible Authentication Protocolを使用する方法も定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7055.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7055で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Discovery ..................................................4
1.2. Authentication .............................................4
1.3. Secure Association Protocol ................................6
2. Requirements Notation ...........................................6
3. EAP Channel Binding and Naming ..................................6
3.1. Mechanism Name Format ......................................7
3.2. Internationalization of Names .............................10
3.3. Exported Mechanism Names ..................................10
3.4. Acceptor Name RADIUS AVP ..................................11
3.5. Proxy Verification of Acceptor Name .......................11
4. Selection of EAP Method ........................................12
5. Context Tokens .................................................13
5.1. Mechanisms and Encryption Types ...........................14
5.2. Processing Received Tokens ................................15
5.3. Error Subtokens ...........................................16
5.4. Initial State .............................................16
5.4.1. Vendor Subtoken ....................................17
5.4.2. Acceptor Name Request ..............................17
5.4.3. Acceptor Name Response .............................18
5.5. Authenticate State ........................................18
5.5.1. EAP Request Subtoken ...............................19
5.5.2. EAP Response Subtoken ..............................19
5.6. Extensions State ..........................................20
5.6.1. Flags Subtoken .....................................20
5.6.2. GSS Channel Bindings Subtoken ......................20
5.6.3. MIC Subtoken .......................................21
5.7. Example Token .............................................22
5.8. Context Options ...........................................23
6. Acceptor Services ..............................................23
6.1. GSS-API Channel Binding ...................................24
6.2. Per-Message Security ......................................24
6.3. Pseudorandom Function .....................................24
7. IANA Considerations ............................................25
7.1. OID Registry ..............................................25
7.2. RFC 4121 Token Identifiers ................................26
7.3. GSS-EAP Subtoken Types ....................................26
7.4. RADIUS Attribute Assignments ..............................27
7.5. Registration of the EAP-AES128 SASL Mechanisms ............28
7.6. GSS-EAP Errors ............................................28
7.7. GSS-EAP Context Flags .....................................30
8. Security Considerations ........................................30
9. Acknowledgements ...............................................32
10. References ....................................................32
Appendix A. Pre-publication RADIUS VSA ............................33
The Application Bridging for Federated Access Beyond Web (ABFAB) document [ABFAB-ARCH] describes an architecture for providing federated access management to applications using the Generic Security Service Application Programming Interface (GSS-API) [RFC2743] and Simple Authentication and Security Layer (SASL) [RFC4422]. This specification provides the core mechanism for bringing federated authentication to these applications.
フェデレーテッドアクセスビヨンドウェブ（ABFAB）ドキュメントのアプリケーションブリッジング（ABFAB-ARCH）は、Generic Security Serviceアプリケーションプログラミングインターフェイス（GSS-API）[RFC2743]およびSimple Authentication and Security Layer（ SASL）[RFC4422]。この仕様は、これらのアプリケーションに統合認証をもたらすためのコアメカニズムを提供します。
The Extensible Authentication Protocol (EAP) [RFC3748] defines a framework for authenticating a network access client and server in order to gain access to a network. A variety of different EAP methods are in wide use; one of EAP's strengths is that for most types of credentials in common use, there is an EAP method that permits the credential to be used.
拡張認証プロトコル（EAP）[RFC3748]は、ネットワークにアクセスするためにネットワークアクセスクライアントとサーバーを認証するためのフレームワークを定義しています。さまざまなEAP方式が広く使用されています。 EAPの強みの1つは、一般的に使用されているほとんどの種類の資格情報に、資格情報の使用を許可するEAPメソッドがあることです。
EAP is often used in conjunction with a backend Authentication, Authorization and Accounting (AAA) server via RADIUS [RFC3579] or Diameter [RFC4072]. In this mode, the Network Access Server (NAS) simply tunnels EAP packets over the backend authentication protocol to a home EAP/AAA server for the client. After EAP succeeds, the backend authentication protocol is used to communicate key material to the NAS. In this mode, the NAS need not be aware of or have any specific support for the EAP method used between the client and the home EAP server. The client and EAP server share a credential that depends on the EAP method; the NAS and AAA server share a credential based on the backend authentication protocol in use. The backend authentication server acts as a trusted third party, enabling network access even though the client and NAS may not actually share any common authentication methods. As described in the architecture document [ABFAB-ARCH], using AAA proxies, this mode can be extended beyond one organization to provide federated authentication for network access.
EAPは、RADIUS [RFC3579]またはDiameter [RFC4072]を介して、バックエンドの認証、承認、アカウンティング（AAA）サーバーと組み合わせて使用されることがよくあります。このモードでは、ネットワークアクセスサーバー（NAS）は、クライアントのホームEAP / AAAサーバーにバックエンド認証プロトコルを介してEAPパケットをトンネリングするだけです。 EAPが成功すると、バックエンド認証プロトコルを使用して、キーマテリアルをNASに通信します。このモードでは、NASはクライアントとホームEAPサーバー間で使用されるEAP方式を認識する必要も、特定のサポートも必要ありません。クライアントとEAPサーバーは、EAPメソッドに依存する資格情報を共有します。 NASとAAAサーバーは、使用中のバックエンド認証プロトコルに基づいて資格情報を共有します。バックエンド認証サーバーは信頼できるサードパーティとして機能し、クライアントとNASが実際に共通の認証方法を共有していない場合でも、ネットワークアクセスを可能にします。アーキテクチャドキュメント[ABFAB-ARCH]で説明されているように、AAAプロキシを使用して、このモードを1つの組織を超えて拡張し、ネットワークアクセスにフェデレーション認証を提供できます。
The GSS-API provides a generic framework for applications to use security services including authentication and per-message data security. Between protocols that support GSS-API directly or protocols that support SASL [RFC4422], many application protocols can use GSS-API for security services. However, with the exception of Kerberos [RFC4121], few GSS-API mechanisms are in wide use on the Internet. While GSS-API permits an application to be written independent of the specific GSS-API mechanism in use, there is no facility to separate the server from the implementation of the mechanism as there is with EAP and backend authentication servers.
GSS-APIは、アプリケーションが認証やメッセージごとのデータセキュリティなどのセキュリティサービスを使用するための一般的なフレームワークを提供します。 GSS-APIを直接サポートするプロトコル間またはSASL [RFC4422]をサポートするプロトコル間で、多くのアプリケーションプロトコルはセキュリティサービスにGSS-APIを使用できます。ただし、Kerberos [RFC4121]を除いて、インターネットで広く使用されているGSS-APIメカニズムはほとんどありません。 GSS-APIでは、使用中の特定のGSS-APIメカニズムとは無関係にアプリケーションを作成できますが、EAPおよびバックエンド認証サーバーのように、メカニズムの実装からサーバーを分離する機能はありません。
The goal of this specification is to combine GSS-API's support for application protocols with EAP/AAA's support for common credential types and for authenticating to a server without requiring that server to specifically support the authentication method in use. In addition, this specification supports the architectural goal of transporting attributes about subjects to relying parties. Together this combination will provide federated authentication and authorization for GSS-API applications. This specification meets the applicability requirements for EAP to application authentication [RFC7057].
この仕様の目的は、GSS-APIのアプリケーションプロトコルのサポートと、一般的な資格情報の種類のEAP / AAAのサポートを組み合わせ、サーバーが使用中の認証方法を特別にサポートすることなく、サーバーに対する認証を行うことです。さらに、この仕様は、サブジェクトに関する属性を証明書利用者に転送するというアーキテクチャ上の目標をサポートしています。この組み合わせにより、GSS-APIアプリケーションに連携認証および許可が提供されます。この仕様は、EAPからアプリケーションへの認証[RFC7057]の適用要件を満たしています。
This mechanism is a GSS-API mechanism that encapsulates an EAP conversation. From the perspective of RFC 3748, this specification defines a new lower-layer protocol for EAP. From the perspective of the application, this specification defines a new GSS-API mechanism.
このメカニズムは、EAP会話をカプセル化するGSS-APIメカニズムです。 RFC 3748の観点から、この仕様はEAPの新しい下位層プロトコルを定義しています。アプリケーションの観点からは、この仕様は新しいGSS-APIメカニズムを定義しています。
Section 1.3 of [RFC5247] outlines the typical conversation between EAP peers where an EAP key is derived:
[RFC5247]のセクション1.3は、EAPキーが生成されるEAPピア間の一般的な会話の概要を示しています。
Phase 0: Discovery Phase 1: Authentication 1a: EAP authentication 1b: AAA Key Transport (optional) Phase 2: Secure Association Protocol 2a: Unicast Secure Association 2b: Multicast Secure Association (optional)
フェーズ0：検出フェーズ1：認証1a：EAP認証1b：AAAキートランスポート（オプション）フェーズ2：セキュアアソシエーションプロトコル2a：ユニキャストセキュアアソシエーション2b：マルチキャストセキュアアソシエーション（オプション）
GSS-API peers discover each other and discover support for GSS-API in an application-dependent mechanism. SASL [RFC4422] describes how discovery of a particular SASL mechanism such as a GSS-API EAP mechanism is conducted. The Simple and Protected Negotiation mechanism (SPNEGO) [RFC4178] provides another approach for discovering what GSS-API mechanisms are available. The specific approach used for discovery is out of scope for this mechanism.
GSS-APIピアはお互いを検出し、アプリケーション依存のメカニズムでGSS-APIのサポートを検出します。 SASL [RFC4422]は、GSS-API EAPメカニズムなどの特定のSASLメカニズムの検出がどのように行われるかを説明しています。シンプルで保護された交渉メカニズム（SPNEGO）[RFC4178]は、利用可能なGSS-APIメカニズムを発見するための別のアプローチを提供します。検出に使用される特定のアプローチは、このメカニズムの範囲外です。
GSS-API authenticates a party called the "GSS-API initiator" to the GSS-API acceptor, optionally providing authentication of the acceptor to the initiator. Authentication starts with a mechanism-specific message called a "context token" sent from the initiator to the acceptor. The acceptor responds, followed by the initiator, and so on until authentication succeeds or fails. GSS-API context tokens are reliably delivered by the application using GSS-API. The application is responsible for in-order delivery and retransmission.
GSS-APIは、「GSS-APIイニシエーター」と呼ばれるパーティをGSS-APIアクセプターに対して認証し、オプションでアクセプターの認証をイニシエーターに提供します。認証は、開始者から受け入れ者に送信される「コンテキストトークン」と呼ばれるメカニズム固有のメッセージから始まります。アクセプターが応答し、イニシエーターが続き、認証が成功または失敗するまで続きます。 GSS-APIコンテキストトークンは、GSS-APIを使用するアプリケーションによって確実に配信されます。アプリケーションは、順序どおりの配信と再送信を担当します。
EAP authenticates a party called a "peer" to a party called the "EAP server". A third party called an "EAP pass-through authenticator" may decapsulate EAP messages from a lower layer and re-encapsulate them into a AAA protocol. The term EAP authenticator refers to whichever of the pass-through authenticator or EAP server receives the lower-layer EAP packets. The first EAP message travels from the authenticator to the peer; a GSS-API message is sent from the initiator to acceptor to prompt the authenticator to send the first EAP message. The EAP peer maps onto the GSS-API initiator. The role of the GSS-API acceptor is split between the EAP authenticator and the EAP server. When these two entities are combined, the division resembles GSS-API acceptors in other mechanisms. When a more typical deployment is used and there is a pass-through authenticator, most context establishment takes place on the EAP server and per-message operations take place on the authenticator. EAP messages from the peer to the authenticator are called responses; messages from the authenticator to the peer are called requests.
EAPは、「ピア」と呼ばれる当事者を「EAPサーバー」と呼ばれる当事者に認証します。 「EAPパススルー認証システム」と呼ばれるサードパーティは、下位層からEAPメッセージをカプセル化解除し、AAAプロトコルに再カプセル化する場合があります。 EAPオーセンティケーターという用語は、パススルーオーセンティケーターまたはEAPサーバーのどちらが下位層のEAPパケットを受信するかを指します。最初のEAPメッセージは、オーセンティケーターからピアに送信されます。 GSS-APIメッセージがイニシエーターからアクセプターに送信され、オーセンティケーターに最初のEAPメッセージの送信を促します。 EAPピアはGSS-APIイニシエーターにマップします。 GSS-APIアクセプターの役割は、EAPオーセンティケーターとEAPサーバーの間で分割されます。これらの2つのエンティティを組み合わせると、部門は他のメカニズムのGSS-APIアクセプターに似ています。より一般的な展開が使用され、パススルー認証システムがある場合、ほとんどのコンテキスト確立はEAPサーバーで行われ、メッセージごとの操作は認証システムで行われます。ピアから認証システムへのEAPメッセージは応答と呼ばれます。オーセンティケータからピアへのメッセージはリクエストと呼ばれます。
Because GSS-API applications provide guaranteed delivery of context tokens, the EAP retransmission timeout MUST be infinite and the EAP layer MUST NOT retransmit a message.
GSS-APIアプリケーションはコンテキストトークンの保証された配信を提供するため、EAP再送信タイムアウトは無限でなければならず（MUST）、EAPレイヤーはメッセージを再送信してはなりません（MUST NOT）。
This specification permits a GSS-API acceptor to hand off the processing of the EAP packets to a remote EAP server by using AAA protocols such as RADIUS, Transport Layer Security (TLS) Encryption thereof [RFC6929], or Diameter. In this case, the GSS-API acceptor acts as an EAP pass-through authenticator. The pass-through authenticator is responsible for retransmitting AAA messages if a response is not received from the AAA server. If a response cannot be received, then the authenticator generates an error at the GSS-API level. If EAP authentication is successful, and where the chosen EAP method supports key derivation, EAP keying material may also be derived. If a AAA protocol is used, this can also be used to replicate the EAP Key from the EAP server to the EAP authenticator.
この仕様により、GSS-APIアクセプターは、RADIUS、トランスポートレイヤーセキュリティ（TLS）暗号化[RFC6929]、DiameterなどのAAAプロトコルを使用して、EAPパケットの処理をリモートEAPサーバーにハンドオフできます。この場合、GSS-APIアクセプターはEAPパススルー認証システムとして機能します。パススルー認証システムは、AAAサーバーから応答を受信しなかった場合にAAAメッセージを再送信します。応答を受信できない場合、オーセンティケーターはGSS-APIレベルでエラーを生成します。 EAP認証が成功し、選択したEAP方式がキーの導出をサポートしている場合、EAPキー生成情報も導出できます。 AAAプロトコルが使用されている場合、これを使用して、EAPキーをEAPサーバーからEAPオーセンティケーターに複製することもできます。
See Section 5 for details of the authentication exchange.
認証交換の詳細については、セクション5を参照してください。
After authentication succeeds, GSS-API provides a number of per-message security services that can be used:
認証が成功した後、GSS-APIは、使用可能なメッセージごとのセキュリティサービスをいくつか提供します。
GSS_Wrap() provides integrity and optional confidentiality for a message.
GSS_Wrap()は、メッセージの整合性とオプションの機密性を提供します。
GSS_GetMIC() provides integrity protection for data sent independently of the GSS-API
GSS_GetMIC()は、GSS-APIとは無関係に送信されるデータの整合性保護を提供します
GSS_Pseudo_random [RFC4401] provides key derivation functionality.
GSS_Pseudo_random [RFC4401]は、主要な派生機能を提供します。
These services perform a function similar to secure association protocols in network access. Like secure association protocols, these services need to be performed near the authenticator/acceptor even when a AAA protocol is used to separate the authenticator from the EAP server. The key used for these per-message services is derived from the EAP key; the EAP peer and authenticator derive this key as a result of a successful EAP authentication. In the case that the EAP authenticator is acting as a pass-through, it obtains it via the AAA protocol. See Section 6 for details.
これらのサービスは、ネットワークアクセスにおけるセキュアアソシエーションプロトコルと同様の機能を実行します。安全な関連付けプロトコルと同様に、これらのサービスは、AAAプロトコルを使用してオーセンティケーターをEAPサーバーから分離する場合でも、オーセンティケーター/アクセプターの近くで実行する必要があります。これらのメッセージごとのサービスに使用されるキーは、EAPキーから派生します。 EAPピアとオーセンティケータは、EAP認証が成功した結果としてこのキーを導出します。 EAPオーセンティケーターがパススルーとして機能している場合は、AAAプロトコルを介して取得します。詳細については、セクション6を参照してください。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
EAP authenticates a user to a realm. The peer knows that it has exchanged authentication with an EAP server in a given realm. Today, the peer does not typically know which NAS it is talking to securely. That is often fine for network access. However, privileges to delegate to a chat server seem very different than privileges for a file server or trading site. Also, an EAP peer knows the identity of the home realm, but perhaps not even the visited realm.
EAPは、ユーザーをレルムに対して認証します。ピアは、特定のレルム内のEAPサーバーと認証を交換したことを知っています。今日、ピアは通常、どのNASが安全に通信しているのかを知りません。多くの場合、ネットワークアクセスには問題ありません。ただし、チャットサーバーに委任する特権は、ファイルサーバーまたは取引サイトの特権とは非常に異なります。また、EAPピアはホームレルムのIDを知っていますが、訪問したレルムさえも知りません。
In contrast, GSS-API takes a name for both the initiator and acceptor as inputs to the authentication process. When mutual authentication is used, both parties are authenticated. The granularity of these names is somewhat mechanism dependent. In the case of the Kerberos mechanism, the acceptor name typically identifies both the protocol in use (such as IMAP) and the specific instance of the service being connected to. The acceptor name almost always identifies the administrative domain providing service.
対照的に、GSS-APIは、認証プロセスへの入力として、イニシエーターとアクセプターの両方の名前を取ります。相互認証を使用すると、両方の当事者が認証されます。これらの名前の細分性は、多少メカニズムに依存します。 Kerberosメカニズムの場合、アクセプター名は通常、使用中のプロトコル（IMAPなど）と接続されているサービスの特定のインスタンスの両方を識別します。アクセプター名は、ほとんどの場合、サービスを提供する管理ドメインを識別します。
A GSS-API EAP mechanism needs to provide GSS-API naming semantics in order to work with existing GSS-API applications. EAP channel binding [RFC6677] is used to provide GSS-API naming semantics. Channel binding sends a set of attributes from the peer to the EAP server either as part of the EAP conversation or as part of a secure association protocol. In addition, attributes are sent in the backend authentication protocol from the authenticator to the EAP server. The EAP server confirms the consistency of these attributes. Confirming attribute consistency also involves checking consistency against a local policy database as discussed in Section 3.5. In particular, the peer sends the name of the acceptor it is authenticating to as part of channel binding. The acceptor sends its full name as part of the backend authentication protocol. The EAP server confirms consistency of the names.
GSS-API EAPメカニズムは、既存のGSS-APIアプリケーションと連携するために、GSS-API命名セマンティクスを提供する必要があります。 EAPチャネルバインディング[RFC6677]は、GSS-APIネーミングセマンティクスを提供するために使用されます。チャネルバインディングは、EAP会話の一部として、または安全な関連付けプロトコルの一部として、ピアからEAPサーバーに一連の属性を送信します。さらに、属性は、認証システムからEAPサーバーにバックエンド認証プロトコルで送信されます。 EAPサーバーは、これらの属性の整合性を確認します。属性の整合性の確認には、セクション3.5で説明するように、ローカルポリシーデータベースに対する整合性のチェックも含まれます。特に、ピアは、チャネルバインディングの一部として、認証するアクセプターの名前を送信します。アクセプターは、バックエンド認証プロトコルの一部としてフルネームを送信します。 EAPサーバーは名前の整合性を確認します。
EAP channel binding is easily confused with a facility in GSS-API also called "channel binding". GSS-API channel binding provides protection against man-in-the-middle attacks when GSS-API is used as authentication inside some tunnel; it is similar to a facility called "cryptographic binding" in EAP. See [RFC5056] for a discussion of the differences between these two facilities and Section 6.1 for how GSS-API channel binding is handled in this mechanism.
EAPチャネルバインディングは、GSS-APIの「チャネルバインディング」とも呼ばれる機能と簡単に混同されます。 GSS-APIチャネルバインディングは、GSS-APIがいくつかのトンネル内の認証として使用されている場合、中間者攻撃に対する保護を提供します。これは、EAPの「暗号化バインディング」と呼ばれる機能に似ています。これら2つの機能の違いの説明については[RFC5056]を参照し、GSS-APIチャネルバインディングがこのメカニズムでどのように処理されるかについてはセクション6.1を参照してください。
Before discussing how the initiator and acceptor names are validated in the AAA infrastructure, it is necessary to discuss what composes a name for an EAP GSS-API mechanism. GSS-API permits several types of generic names to be imported using GSS_Import_name(). Once a mechanism is chosen, these names are converted into a mechanism-specific name called a "Mechanism Name". Note that a Mechanism Name is the name of an initiator or acceptor, not of a GSS-API mechanism. This section first discusses the mechanism name form and then discusses what name forms are supported.
AAAインフラストラクチャでイニシエータとアクセプタの名前がどのように検証されるかを説明する前に、EAP GSS-APIメカニズムの名前を構成するものについて説明する必要があります。 GSS-APIでは、GSS_Import_name()を使用して、いくつかのタイプの総称名をインポートできます。メカニズムが選択されると、これらの名前は「メカニズム名」と呼ばれるメカニズム固有の名前に変換されます。メカニズム名は、GSS-APIメカニズムではなく、イニシエーターまたはアクセプターの名前であることに注意してください。このセクションでは、最初にメカニズム名の形式について説明し、次にサポートされている名前の形式について説明します。
The string representation of the GSS-EAP mechanism name has the following ABNF [RFC5234] representation:
GSS-EAPメカニズム名の文字列表現には、次のABNF [RFC5234]表現があります。
char-normal = %x00-2E/%x30-3F/%x41-5B/%x5D-FF
char-escaped = "\" %x2F / "\" %x40 / "\" %x5C
name-char = char-normal / char-escaped
name-string = 1*name-char
user-or-service = name-string
host = [name-string]
realm = name-string
service-specific = name-string
service-specifics = service-specific 0*("/" service-specifics)
name = user-or-service ["/" host [ "/" service-specifics]] [ "@"
realm ]
Special characters appearing in a name can be backslash escaped to avoid their special meanings. For example, "\\" represents a literal backslash. This escaping mechanism is a property of the string representation; if the components of a name are transported in some mechanism that will keep them separate without backslash escaping, then backslash SHOULD have no special meaning.
名前に表示される特殊文字は、その特別な意味を回避するためにバックスラッシュでエスケープできます。たとえば、「\\」はリテラルのバックスラッシュを表します。このエスケープメカニズムは、文字列表現のプロパティです。名前のコンポーネントがバックスラッシュのエスケープなしにそれらを分離する何らかのメカニズムで転送される場合、バックスラッシュは特別な意味を持つべきではありません。
The user-or-service component is similar to the portion of a network access identifier (NAI) before the '@' symbol for initiator names and the service name from the registry of GSS-API host-based services in the case of acceptor names [GSS-IANA]. The NAI specification provides rules for encoding and string preparation in order to support internationalization of NAIs; implementations of this mechanism MUST NOT prepare the user-or-service according to these rules; see Section 3.2 for internationalization of this mechanism. The host portion is empty for initiators and typically contains the domain name of the system on which an acceptor service is running. Some services MAY require additional parameters to distinguish the entity being authenticated against. Such parameters are encoded in the service-specifics portion of the name. The EAP server MUST reject authentication of any acceptor name that has a non-empty service-specifics component unless the EAP server understands the service-specifics and authenticates them. The interpretation of the service-specifics is scoped by the user-or-service portion. The realm is similar to the realm portion of a NAI for initiator names; again the NAI specification's internationalization rules MUST NOT be applied to the realm. The realm is the administrative realm of a service for an acceptor name.
user-or-serviceコンポーネントは、イニシエーター名の「@」記号の前のネットワークアクセス識別子（NAI）の部分と、アクセプター名の場合はGSS-APIホストベースのサービスのレジストリからのサービス名に似ています。 [GSS-IANA]。 NAI仕様は、NAIの国際化をサポートするためのエンコードと文字列の準備に関する規則を提供します。このメカニズムの実装は、これらの規則に従ってユーザーまたはサービスを準備してはなりません（MUST NOT）。このメカニズムの国際化については、セクション3.2を参照してください。イニシエーターのホスト部分は空であり、通常、アクセプターサービスが実行されているシステムのドメイン名が含まれています。一部のサービスでは、認証対象のエンティティを区別するために追加のパラメーターが必要になる場合があります。このようなパラメーターは、名前のサービス固有の部分にエンコードされます。 EAPサーバーは、サービス固有の内容を理解して認証しない限り、空でないサービス固有のコンポーネントを持つアクセプター名の認証を拒否する必要があります。サービス固有の解釈の範囲は、ユーザーまたはサービスの部分です。レルムは、イニシエーター名のNAIのレルム部分に似ています。この場合も、NAI仕様の国際化規則をレルムに適用してはなりません（MUST NOT）。レルムは、アクセプター名のサービスの管理レルムです。
The string representation of this name form is designed to be generally compatible with the string representation of Kerberos names defined in [RFC1964].
この名前形式の文字列表現は、[RFC1964]で定義されているKerberos名の文字列表現と一般的に互換性があるように設計されています。
The GSS_C_NT_USER_NAME form represents the name of an individual user. From the standpoint of this mechanism, it may take the form of either an undecorated user name or a name semantically similar to a network access identifier (NAI) [RFC4282]. The name is split at the first at-sign ('@') into the part preceding the realm, which is the user-or-service portion of the mechanism name, and the realm portion, which is the realm portion of the mechanism name.
GSS_C_NT_USER_NAMEフォームは、個々のユーザーの名前を表します。このメカニズムの観点からは、装飾されていないユーザー名、またはネットワークアクセス識別子（NAI）[RFC4282]と意味的に類似した名前のいずれかの形式をとることがあります。名前は、最初のアットマーク（ '@'）で、メカニズム名のユーザーまたはサービス部分であるレルムの前の部分と、メカニズム名のレルム部分であるレルム部分に分割されます。 。
The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running on a host; it is textually represented as "service@host". This name form is required by most SASL profiles and is used by many existing applications that use the Kerberos GSS-API mechanism. While support for this name form is critical, it presents an interesting challenge in terms of EAP channel binding. Consider a case where the server communicates with a "server proxy," or a AAA server near the server. That server proxy communicates with the EAP server. The EAP server and server proxy are in different administrative realms. The server proxy is in a position to verify that the request comes from the indicated host. However, the EAP server cannot make this determination directly. So, the EAP server needs to determine whether to trust the server proxy to verify the host portion of the acceptor name. This trust decision depends both on the host name and the realm of the server proxy. In effect, the EAP server decides whether to trust that the realm of the server proxy is the right realm for the given hostname and then makes a trust decision about the server proxy itself. The same problem appears in Kerberos: there, clients decide what Kerberos realm to trust for a given hostname. The service portion of this name is imported into the user-or-service portion of the mechanism name; the host portion is imported into the host portion of the mechanism name. The realm portion is empty. However, authentication will typically fail unless some AAA component indicates the realm to the EAP server. If the application server knows its realm, then it should be indicated in the outgoing AAA request. Otherwise, a proxy SHOULD add the realm. An alternate form of this name type MAY be used on acceptors; in this case, the name form is "service" with no host component. This is imported with the service as user-or-service and an empty host and realm portion. This form is useful when a service is unsure which name an initiator knows it by.
GSS_C_NT_HOSTBASED_SERVICE名前形式は、ホストで実行されているサービスを表します。テキストでは「service @ host」として表されます。この名前形式は、ほとんどのSASLプロファイルで必要であり、Kerberos GSS-APIメカニズムを使用する多くの既存のアプリケーションで使用されます。この名前形式のサポートは重要ですが、EAPチャネルバインディングの面で興味深い課題があります。サーバーが「サーバープロキシ」またはサーバーの近くにあるAAAサーバーと通信する場合を考えます。そのサーバープロキシはEAPサーバーと通信します。 EAPサーバーとサーバープロキシは、異なる管理領域にあります。サーバープロキシは、要求が指定されたホストからのものであることを確認する立場にあります。ただし、EAPサーバーはこの決定を直接行うことはできません。そのため、EAPサーバーは、サーバープロキシを信頼してアクセプター名のホスト部分を検証するかどうかを決定する必要があります。この信頼の決定は、ホスト名とサーバープロキシの領域の両方に依存します。実際には、EAPサーバーは、サーバープロキシのレルムが特定のホスト名の正しいレルムであることを信頼するかどうかを決定し、サーバープロキシ自体に関する信頼の決定を行います。同じ問題がKerberosでも発生します。そこで、クライアントは、特定のホスト名に対して信頼するKerberos領域を決定します。この名前のサービス部分は、メカニズム名のユーザーまたはサービス部分にインポートされます。ホスト部分は、メカニズム名のホスト部分にインポートされます。レルム部分が空です。ただし、一部のAAAコンポーネントがEAPサーバーにレルムを示す場合を除いて、認証は通常失敗します。アプリケーションサーバーがそのレルムを知っている場合、それは発信AAA要求で示される必要があります。それ以外の場合、プロキシはレルムを追加する必要があります（SHOULD）。この名前タイプの代替形式をアクセプターで使用できます。この場合、名前の形式は「サービス」であり、ホストコンポーネントはありません。これは、user-or-serviceとしてのサービスと空のホストおよびレルム部分とともにインポートされます。この形式は、サービスがイニシエーターがそれを知っている名前がわからない場合に役立ちます。
If the null name type or the GSS_EAP_NT_EAP_NAME (OID 1.3.6.1.5.5.15.2.1) (see Section 7.1 ) is imported, then the string representation above should be directly imported. Mechanisms MAY support the GSS_KRB5_NT_KRB5_PRINCIPAL_NAME name form with the OID {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) krb5(2) krb5_name(1)}. In many circumstances, Kerberos GSS-API mechanism names will behave as expected when used with the GSS-API EAP mechanism, but there are some differences that may cause some confusion. If an implementation does support importing Kerberos names it SHOULD fail the import if the Kerberos name is not syntactically a valid GSS-API EAP mechanism name as defined in this section.
nullの名前タイプまたはGSS_EAP_NT_EAP_NAME（OID 1.3.6.1.5.5.15.2.1）（セクション7.1を参照）をインポートする場合、上記の文字列表現を直接インポートする必要があります。メカニズムは、GSS_KRB5_NT_KRB5_PRINCIPAL_NAME名前形式をOID {iso（1）member-body（2）United States（840）mit（113554）infosys（1）gssapi（2）krb5（2）krb5_name（1）}でサポートする場合があります。多くの状況で、Kerberos GSS-APIメカニズム名は、GSS-API EAPメカニズムで使用すると期待どおりに動作しますが、いくつかの違いがあり、混乱を招く可能性があります。実装がKerberos名のインポートをサポートしている場合、Kerberos名がこのセクションで定義されている有効なGSS-API EAPメカニズム名ではないため、インポートを失敗させる必要があります（SHOULD）。
For the most part, GSS-EAP names are transported in other protocols; those protocols define the internationalization semantics. For example, if a AAA server wishes to communicate the user-or-service portion of the initiator name to an acceptor, it does so using existing mechanisms in the AAA protocol. Existing internationalization rules are applied. Similarly, within an application, existing specifications such as [RFC5178] define the encoding of names that are imported and displayed with the GSS-API.
ほとんどの場合、GSS-EAP名は他のプロトコルで転送されます。これらのプロトコルは、国際化のセマンティクスを定義します。たとえば、AAAサーバーがイニシエーター名のユーザーまたはサービスの部分をアクセプターに通信する場合、AAAプロトコルの既存のメカニズムを使用して通信します。既存の国際化ルールが適用されます。同様に、アプリケーション内で、[RFC5178]などの既存の仕様は、GSS-APIでインポートおよび表示される名前のエンコーディングを定義します。
This mechanism does introduce a few cases where name components are sent. In these cases, the encoding of the string is UTF-8. Senders SHOULD NOT normalize or map strings before sending. These strings include RADIUS attributes introduced in Section 3.4.
このメカニズムでは、名前コンポーネントが送信されるいくつかのケースが発生します。これらの場合、文字列のエンコーディングはUTF-8です。送信者は、送信前に文字列を正規化またはマップしないでください。これらの文字列には、セクション3.4で導入されたRADIUS属性が含まれます。
When comparing the host portion of a GSS-EAP acceptor name supplied in EAP channel binding by a peer to that supplied by an acceptor, EAP servers SHOULD prepare the host portion according to [RFC5891] prior to comparison. Applications MAY prepare domain names prior to importing them into this mechanism.
ピアによってEAPチャネルバインディングで提供されるGSS-EAPアクセプター名のホスト部分を、アクセプターによって提供される名前と比較する場合、EAPサーバーは、比較の前に[RFC5891]に従ってホスト部分を準備する必要があります。アプリケーションは、このメカニズムにドメイン名をインポートする前に、ドメイン名を準備してもよい（MAY）。
GSS-API provides the GSS_Export_name call. This call can be used to export the binary representation of a name. This name form can be stored on access control lists for binary comparison.
GSS-APIはGSS_Export_name呼び出しを提供します。この呼び出しを使用して、名前のバイナリ表現をエクスポートできます。この名前形式は、バイナリー比較のためにアクセス制御リストに保管できます。
The exported name token MUST use the format described in Section 3.2 of RFC 2743. The mechanism specific portion of this name token is the string format of the mechanism name described in Section 3.1.
エクスポートされた名前トークンは、RFC 2743のセクション3.2で説明されている形式を使用する必要があります。この名前トークンのメカニズム固有の部分は、セクション3.1で説明されているメカニズム名の文字列形式です。
RFC 2744 [RFC2744] places the requirement that the result of importing a name, canonicalizing it to a Mechanism Name and then exporting it needs to be the same as importing that name, obtaining credentials for that principal, initiating a context with those credentials and exporting the name on the acceptor. In practice, GSS mechanisms often, but not always, meet this requirement. For names expected to be used as initiator names, this requirement is met. However, permitting empty host and realm components when importing host-based services may make it possible for an imported name to differ from the exported name actually used. Other mechanisms such as Kerberos have similar situations where imported and exported names may differ.
RFC 2744 [RFC2744]は、名前をインポートし、メカニズム名に正規化してからエクスポートした結果が、その名前のインポート、そのプリンシパルの資格情報の取得、それらの資格情報によるコンテキストの開始およびエクスポートと同じである必要があるという要件を課しています。アクセプターの名前。実際には、GSSメカニズムは、常にではありませんが、多くの場合、この要件を満たしています。イニシエーター名として使用されることが予想される名前の場合、この要件は満たされます。ただし、ホストベースのサービスをインポートするときに空のホストおよびレルムコンポーネントを許可すると、インポートされた名前が実際に使用されるエクスポートされた名前と異なる可能性があります。 Kerberosなどの他のメカニズムでも、インポートされた名前とエクスポートされた名前が異なる場合がある同様の状況があります。
See Section 7.4 for registrations of RADIUS attribute types to carry the acceptor service name. All the attribute types registered in that section are strings. See Section 3.1 for details of the values in a name.
アクセプターサービス名を伝送するためのRADIUS属性タイプの登録については、セクション7.4を参照してください。そのセクションに登録されているすべての属性タイプは文字列です。名前の値の詳細については、セクション3.1を参照してください。
If RADIUS is used as a AAA transport, the acceptor MUST send the acceptor name in these attribute types. That is, the acceptor decomposes its name and sends any non-empty portion as a RADIUS attribute. With the exception of the service-specifics portion of the name, the backslash escaping mechanism is not used in RADIUS attributes; backslash has no special meaning. In the service-specifics portion, a literal "/" separates components. In this one attribute, "\/" indicates a slash character that does not separate components and "\\" indicates a literal backslash character.
RADIUSをAAAトランスポートとして使用する場合、アクセプターはこれらの属性タイプでアクセプター名を送信する必要があります。つまり、アクセプターはその名前を分解し、空でない部分をRADIUS属性として送信します。名前のサービス固有の部分を除いて、バックスラッシュエスケープメカニズムはRADIUS属性では使用されません。バックスラッシュには特別な意味はありません。サービス固有の部分では、リテラル「/」でコンポーネントを区切ります。この1つの属性では、「\ /」はコンポーネントを区切らないスラッシュ文字を示し、「\\」はリテラルのバックスラッシュ文字を示します。
The initiator MUST require that the EAP method in use support channel binding and MUST send the acceptor name as part of the channel binding data. The client MUST NOT indicate mutual authentication in the result of GSS_Init_sec_context unless all name elements that the client supplied are in a successful channel binding response. For example, if the client supplied a hostname in channel binding data, the hostname MUST be in a successful channel binding response.
イニシエーターは、使用中のEAPメソッドがチャネルバインディングをサポートしていることを必須とし、チャネルバインディングデータの一部としてアクセプター名を送信する必要があります。クライアントが提供したすべての名前要素が正常なチャネルバインディング応答に含まれていない限り、クライアントはGSS_Init_sec_contextの結果で相互認証を示してはなりません（MUST NOT）。たとえば、クライアントがチャネルバインディングデータにホスト名を提供した場合、そのホスト名は正常なチャネルバインディング応答に含まれている必要があります。
If an empty target name is supplied to GSS_Init_sec_context, the initiator MUST fail context establishment unless the acceptor supplies the acceptor name response (Section 5.4.3). If a null target name is supplied, the initiator MUST use this response to populate EAP channel bindings.
空のターゲット名がGSS_Init_sec_contextに提供されている場合、アクセプターがアクセプター名の応答を提供しない限り、イニシエーターはコンテキストの確立に失敗する必要があります（セクション5.4.3）。 nullターゲット名が指定されている場合、イニシエーターはこの応答を使用してEAPチャネルバインディングを設定する必要があります。
Proxies may play a role in verification of the acceptor identity. For example, a AAA proxy near the acceptor may be in a position to verify the acceptor hostname, while the EAP server is likely to be too distant to reliably verify this on its own.
プロキシは、アクセプターの身元の確認に役割を果たす場合があります。たとえば、アクセプターの近くのAAAプロキシは、アクセプターのホスト名を検証する立場にあるかもしれませんが、EAPサーバーは、これを単独で確実に検証するには遠すぎる可能性があります。
The EAP server or some proxy trusted by the EAP server is likely to be in a position to verify the acceptor realm. In effect, this proxy is confirming that the right AAA credential is used for the claimed realm and thus that the acceptor is in the organization it claims to be part of. This proxy is also typically trusted by the EAP server to make sure that the hostname claimed by the acceptor is a reasonable hostname for the realm of the acceptor.
EAPサーバーまたはEAPサーバーによって信頼されているいくつかのプロキシは、アクセプターのレルムを検証する立場にある可能性があります。実際、このプロキシは、要求されたレルムに適切なAAAクレデンシャルが使用されていること、したがってアクセプターが所属していると主張している組織にいることを確認しています。また、このプロキシは通常、EAPサーバーによって信頼され、アクセプターが要求するホスト名がアクセプターのレルムの適切なホスト名であることを確認します。
A proxy close to the EAP server is unlikely to be in a position to confirm that the acceptor is claiming the correct hostname. Instead, this is typically delegated to a proxy near the acceptor. That proxy is typically expected to verify the acceptor hostname and to verify the appropriate AAA credential for that host is used. Such a proxy may insert the acceptor realm if it is absent, permitting realm configuration to be at the proxy boundary rather than on acceptors.
EAPサーバーの近くにあるプロキシが、アクセプターが正しいホスト名を要求していることを確認する立場にある可能性は低いです。代わりに、これは通常、アクセプターの近くのプロキシに委任されます。そのプロキシは通常、アクセプターのホスト名を検証し、そのホストに適切なAAA資格が使用されていることを検証することが期待されています。そのようなプロキシーは、アクセプター・レルムがない場合はそれを挿入し、レルム構成がアクセプターではなくプロキシー境界にあることを許可します。
Ultimately, specific proxy behavior is a matter for deployment. The EAP server MUST assure that the appropriate validation has been done before including acceptor name attributes in a successful channel binding response. If the acceptor service is included, the EAP server asserts that the service is plausible for the acceptor. If the acceptor hostname is included, the EAP server asserts that the acceptor hostname is verified. If the realm is included the EAP server asserts that the realm has been verified, and if the hostname was also included, that the realm and hostname are consistent. Part of this verification MAY be delegated to proxies, but the EAP server configuration MUST guarantee that the combination of proxies meets these requirements. Typically, such delegation will involve business or operational measures such as cross-organizational agreements as well as technical measures.
最終的に、特定のプロキシの動作は展開の問題です。 EAPサーバーは、正常なチャネルバインディング応答にアクセプター名属性を含める前に、適切な検証が行われていることを確認する必要があります。アクセプターサービスが含まれている場合、EAPサーバーは、そのサービスがアクセプターにとって妥当であるとアサートします。アクセプターのホスト名が含まれている場合、EAPサーバーはアクセプターのホスト名が検証されたことをアサートします。レルムが含まれている場合、EAPサーバーは、レルムが検証されていることをアサートし、ホスト名も含まれている場合は、レルムとホスト名が一致していることをアサートします。この検証の一部はプロキシに委任される場合がありますが、EAPサーバー構成は、プロキシの組み合わせがこれらの要件を満たすことを保証する必要があります。通常、このような委任には、組織間の合意などのビジネス上または運用上の対策や技術的な対策が含まれます。
It is likely that future technical work will be needed to communicate what verification has been done by proxies along the path. Such technical measures will not release the EAP server from its responsibility to decide whether proxies on the path should be trusted to perform checks delegated to them. However, technical measures could prevent misconfigurations and help to support diverse environments.
パスに沿ってプロキシによって行われた検証を伝えるために、将来の技術的な作業が必要になる可能性があります。このような技術的対策によって、EAPサーバーは、パス上のプロキシに委任されたチェックを実行するために信頼すべきかどうかを決定する責任から解放されません。ただし、技術的な対策により、設定ミスを防ぎ、さまざまな環境のサポートに役立ちます。
EAP does not provide a facility for an EAP server to advertise what methods are available to a peer. Instead, a server starts with its preferred method selection. If the peer does not accept that method, the peer sends a NAK response containing the list of methods supported by the client.
EAPは、EAPサーバーがピアが使用できる方法を通知する機能を提供しません。代わりに、サーバーは優先するメソッドを選択して起動します。ピアがそのメソッドを受け入れない場合、ピアはクライアントがサポートするメソッドのリストを含むNAK応答を送信します。
Providing multiple facilities to negotiate which security mechanism to use is undesirable. Section 7.3 of [RFC4462]describes the problem referencing the Secure Shell (SSH) Protocol key exchange negotiation and the SPNEGO GSS-API mechanism. If a client preferred an EAP method A, a non-EAP authentication mechanism B, and then an EAP method C, then the client would have to commit to using EAP before learning whether A is actually supported. Such a client might end up using C when B is available.
使用するセキュリティメカニズムをネゴシエートする複数の機能を提供することは望ましくありません。 [RFC4462]のセクション7.3は、Secure Shell（SSH）プロトコルの鍵交換ネゴシエーションとSPNEGO GSS-APIメカニズムを参照する問題について説明しています。クライアントがEAP方式A、非EAP認証メカニズムB、次にEAP方式Cを選択した場合、クライアントは、Aが実際にサポートされているかどうかを知る前に、EAPの使用をコミットする必要があります。そのようなクライアントは、Bが使用可能な場合にCを使用することになります。
The standard solution to this problem is to perform all the negotiation at one layer. In this case, rather than defining a single GSS-API mechanism, a family of mechanisms should be defined. Each mechanism corresponds to an EAP method. The EAP method type should be part of the GSS-API OID. Then, a GSS-API rather than EAP facility can be used for negotiation.
この問題の標準的な解決策は、すべてのネゴシエーションを1つの層で実行することです。この場合、単一のGSS-APIメカニズムを定義するのではなく、メカニズムのファミリーを定義する必要があります。各メカニズムはEAP方式に対応しています。 EAPメソッドタイプはGSS-API OIDの一部である必要があります。次に、EAP機能ではなくGSS-APIをネゴシエーションに使用できます。
Unfortunately, using a family of mechanisms has a number of problems. First, GSS-API assumes that both the initiator and acceptor know the entire set of mechanisms that are available. Some negotiation mechanisms are driven by the client; others are driven by the server. With EAP GSS-API, the acceptor does not know what methods the EAP server implements. The EAP server that is used depends on the identity of the client. The best solution so far is to accept the disadvantages of multi-layer negotiation and commit to using EAP GSS-API before a specific EAP method. This has two main disadvantages. First, authentication may fail when other methods might allow authentication to succeed. Second, a non-optimal security mechanism may be chosen.
残念ながら、一連のメカニズムを使用することには多くの問題があります。まず、GSS-APIは、イニシエーターとアクセプターの両方が使用可能なメカニズムのセット全体を知っていると想定しています。一部の交渉メカニズムはクライアントによって駆動されます。その他はサーバーによって駆動されます。 EAP GSS-APIを使用すると、受け入れ側はEAPサーバーが実装するメソッドを認識できません。使用されるEAPサーバーは、クライアントのIDによって異なります。これまでの最善の解決策は、マルチレイヤーネゴシエーションの欠点を受け入れ、特定のEAPメソッドの前にEAP GSS-APIを使用することを約束することです。これには2つの主な欠点があります。まず、他の方法で認証が成功する可能性がある場合、認証が失敗することがあります。第二に、最適ではないセキュリティメカニズムが選択される可能性があります。
All context establishment tokens emitted by the EAP mechanism SHALL have the framing described in Section 3.1 of [RFC2743], as illustrated by the following pseudo-ASN.1 structures:
EAPメカニズムによって発行されたすべてのコンテキスト確立トークンは、[RFC2743]のセクション3.1で説明されているフレーミングを持っている必要があります。これは、次の擬似ASN.1構造で示されています。
GSS-API DEFINITIONS ::=
BEGIN
MechType ::= OBJECT IDENTIFIER
-- representing EAP mechanism
GSSAPI-Token ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
END
The innerToken field starts with a 16-bit network byte order token type identifier. The remainder of the innerToken field is a set of type-length-value subtokens. The following figure describes the structure of the inner token:
innerTokenフィールドは、16ビットのネットワークバイトオーダートークンタイプ識別子で始まります。 innerTokenフィールドの残りの部分は、type-length-valueサブトークンのセットです。次の図は、内部トークンの構造を示しています。
+----------------+---------------------------+
| Octet Position | Description |
+----------------+---------------------------+
| 0..1 | token ID |
| | |
| 2..5 | first subtoken type |
| | |
| 6..9 | length of first subtoken |
| | |
| 10..10+n-1 | first subtoken body |
| | |
| 10+n..10+n+3 | second subtoken type |
+----------------+---------------------------+
Structure of Inner Token
内部トークンの構造
The inner token continues with length, second subtoken body, and so forth. If a subtoken type is present, its length and body MUST be present.
内部トークンは、長さ、2番目のサブトークンボディなどで続きます。サブトークンタイプが存在する場合、その長さと本文が存在する必要があります。
The length is a four-octet length of the subtoken body in network byte order. The length does not include the length of the type field or the length field; the length only covers the body.
長さは、サブバイトボディの4オクテット長で、ネットワークバイト順です。長さには、タイプフィールドまたは長さフィールドの長さは含まれません。長さは体のみをカバーします。
Tokens from the initiator to acceptor use an inner token type with ID 06 01; tokens from acceptor to initiator use an inner token type with ID 06 02. These token types are registered in the registry of RFC 4121 token types; see Section 7.2.
イニシエーターからアクセプターへのトークンは、ID 06 01の内部トークンタイプを使用します。アクセプターからイニシエーターへのトークンは、ID 06 02の内部トークンタイプを使用します。これらのトークンタイプは、RFC 4121トークンタイプのレジストリに登録されています。セクション7.2を参照してください。
See Section 5.7 for the encoding of a complete token. The following sections discuss how mechanism OIDs are chosen and the state machine that defines what subtokens are permitted at each point in the context establishment process.
完全なトークンのエンコーディングについては、セクション5.7を参照してください。次のセクションでは、メカニズムOIDが選択される方法と、コンテキスト確立プロセスの各ポイントで許可されるサブトークンを定義するステートマシンについて説明します。
This mechanism family uses the security services of the Kerberos cryptographic framework [RFC3961]. The root of the OID ARC for mechanisms described in this document is 1.3.6.1.5.5.15.1.1; a Kerberos encryption type number [RFC3961] is appended to that root OID to form a mechanism OID. As such, a particular encryption type needs to be chosen. By convention, there is a single object identifier arc for the EAP family of GSS-API mechanisms. A specific mechanism is chosen by adding the numeric Kerberos encryption type number to the root of this arc. However, in order to register the SASL name, the specific usage with a given encryption type needs to be registered. This document defines the EAP-AES128 GSS-API mechanism.
このメカニズムファミリは、Kerberos暗号化フレームワーク[RFC3961]のセキュリティサービスを使用します。このドキュメントで説明されているメカニズムのOID ARCのルートは1.3.6.1.5.5.15.1.1です。 Kerberos暗号化タイプ番号[RFC3961]がそのルートOIDに追加され、メカニズムOIDを形成します。そのため、特定の暗号化タイプを選択する必要があります。慣例により、GSS-APIメカニズムのEAPファミリには単一のオブジェクト識別子アークがあります。このアークのルートに数値のKerberos暗号化タイプ番号を追加することにより、特定のメカニズムが選択されます。ただし、SASL名を登録するには、特定の暗号化タイプでの特定の使用法を登録する必要があります。このドキュメントでは、EAP-AES128 GSS-APIメカニズムを定義しています。
Whenever a context token is received, the receiver performs the following checks. First, the receiver confirms the object identifier is that of the mechanism being used. The receiver confirms that the token type corresponds to the role of the peer: acceptors will only process initiator tokens and initiators will only process acceptor tokens.
コンテキストトークンが受信されるたびに、受信者は次のチェックを実行します。最初に、受信者はオブジェクト識別子が使用されているメカニズムのものであることを確認します。レシーバーは、トークンタイプがピアの役割に対応していることを確認します。アクセプターはイニシエータートークンのみを処理し、イニシエーターはアクセプタートークンのみを処理します。
Implementations of this mechanism maintain a state machine for the context establishment process. Both the initiator and acceptor start out in the initial state; see Section 5.4 for a description of this state. Associated with each state are a set of subtoken types that are processed in that state and rules for processing these subtoken types. The receiver examines the subtokens in order, processing any that are appropriate for the current state. Unknown subtokens or subtokens that are not expected in the current state are ignored if their critical bit (see below) is clear.
このメカニズムの実装は、コンテキスト確立プロセスの状態マシンを維持します。イニシエーターとアクセプターの両方が初期状態で開始します。この状態の説明については、セクション5.4を参照してください。各状態には、その状態で処理される一連のサブトークンタイプと、これらのサブトークンタイプを処理するためのルールが関連付けられています。レシーバーはサブトークンを順番に調べ、現在の状態に適切なサブトークンを処理します。不明なサブトークン、または現在の状態で予期されていないサブトークンは、クリティカルビット（以下を参照）がクリアされている場合は無視されます。
A state may have a set of required subtoken types. If a subtoken type is required by the current state but no subtoken of that type is present, then the context establishment MUST fail.
状態には、必要なサブトークンタイプのセットがある場合があります。現在の状態でサブトークンタイプが必要であるが、そのタイプのサブトークンが存在しない場合、コンテキストの確立は失敗する必要があります。
The most significant bit (0x80000000) in a subtoken type is the critical bit. If a subtoken with this bit set in the type is received, the receiver MUST fail context establishment unless the subtoken is understood and processed for the current state.
サブトークンタイプの最上位ビット（0x80000000）はクリティカルビットです。タイプにこのビットが設定されたサブトークンを受信した場合、サブトークンが理解され、現在の状態で処理されない限り、レシーバーはコンテキストの確立に失敗する必要があります。
The subtoken type MUST be unique within a given token.
サブトークンタイプは、特定のトークン内で一意である必要があります。
The acceptor may always end the exchange by generating an error subtoken. The error subtoken has the following format:
アクセプターは、エラーサブトークンを生成することにより、常に交換を終了できます。エラーサブトークンの形式は次のとおりです。
+--------+----------------------------------------------------------+
| Pos | Description |
+--------+----------------------------------------------------------+
| 0..3 | 0x80 00 00 01 |
| | |
| 4..7 | length of error token |
| | |
| 8..11 | major status from RFC 2744 as 32-bit network byte order |
| | |
| 12..15 | GSS-EAP error code as 32-bit network byte order; see |
| | Section 7.6 |
+--------+----------------------------------------------------------+
Initiators MUST ignore octets beyond the GSS-EAP error code for future extensibility. As indicated, the error token is always marked critical.
イニシエータは、将来の拡張性のために、GSS-EAPエラーコードを超えるオクテットを無視する必要があります。示されているように、エラートークンは常にクリティカルとマークされます。
Both the acceptor and initiator start the context establishment process in the initial state.
アクセプターとイニシエーターの両方が、初期状態でコンテキスト確立プロセスを開始します。
The initiator sends a token to the acceptor. It MAY be empty; no subtokens are required in this state. Alternatively, the initiator MAY include a vendor ID subtoken or an acceptor name request subtoken.
イニシエーターはトークンをアクセプターに送信します。空の場合があります。この状態ではサブトークンは必要ありません。あるいは、イニシエーターは、ベンダーIDサブトークンまたはアクセプター名要求サブトークンを含めることができます。
The acceptor responds to this message. It MAY include an acceptor name response subtoken. It MUST include a first EAP request; this is an EAP request/identity message (see Section 5.5.1 for the format of this subtoken).
アクセプターはこのメッセージに応答します。アクセプター名の応答サブトークンを含めることができます。最初のEAP要求を含める必要があります。これはEAP要求/識別メッセージです（このサブトークンの形式については、セクション5.5.1を参照してください）。
The initiator and acceptor then transition to authenticate state.
その後、イニシエーターとアクセプターは認証状態に移行します。
The vendor ID subtoken has type 0x0000000B and the following structure:
ベンダーIDサブトークンのタイプは0x0000000Bで、構造は次のとおりです。
+-------------+------------------------+
| Pos | Description |
+-------------+------------------------+
| 0..3 | 0x0000000B |
| | |
| 4..7 | length of vendor token |
| | |
| 8..8+length | Vendor ID string |
+-------------+------------------------+
The vendor ID string is an UTF-8 string describing the vendor of this implementation. This string is unstructured and for debugging purposes only.
ベンダーID文字列は、この実装のベンダーを説明するUTF-8文字列です。この文字列は構造化されておらず、デバッグのみを目的としています。
The acceptor name request token is sent from the initiator to the acceptor indicating that the initiator wishes a particular acceptor name. This is similar to Transport Layer Security (TLS) Server Name Indication [RFC6066] that permits a client to indicate which one of a number of virtual services to contact. The structure is as follows:
アクセプター名要求トークンは、イニシエーターからアクセプターに送信され、イニシエーターが特定のアクセプター名を希望していることを示します。これは、トランスポート層セキュリティ（TLS）サーバー名表示[RFC6066]に似ており、クライアントは、多数の仮想サービスのどれに接続するかを指定できます。構造は次のとおりです。
+------+------------------------------+
| Pos | Description |
+------+------------------------------+
| 0..3 | 0x00000002 |
| | |
| 4..7 | length of subtoken |
| | |
| 8..n | string form of acceptor name |
+------+------------------------------+
It is likely that channel binding and thus authentication will fail if the acceptor does not choose a name that is a superset of this name. That is, if a hostname is sent, the acceptor needs to be willing to accept this hostname.
アクセプターがこの名前のスーパーセットである名前を選択しない場合、チャネルバインディングと認証が失敗する可能性があります。つまり、ホスト名が送信される場合、アクセプターはこのホスト名を受け入れる用意がある必要があります。
The acceptor name response subtoken indicates what acceptor name is used. This is useful, for example, if the initiator supplied no target name to the context initialization. This allows the initiator to learn the acceptor name. EAP channel bindings will provide confirmation that the acceptor is accurately naming itself.
アクセプター名の応答サブトークンは、使用されるアクセプター名を示します。これは、例えば、イニシエーターがコンテキスト初期化にターゲット名を提供しなかった場合に役立ちます。これにより、イニシエーターはアクセプター名を知ることができます。 EAPチャネルバインディングは、アクセプターが自分自身を正確に命名していることの確認を提供します。
This token is sent from the acceptor to initiator. In the Initial state, this token would typically be sent if the acceptor name request is absent, because if the initiator already sent an acceptor name, then the initiator knows what acceptor it wishes to contact. This subtoken is also sent in Extensions state Section 5.6, so the initiator can protect against a man-in-the-middle modifying the acceptor name request subtoken.
このトークンは、アクセプターからイニシエーターに送信されます。初期状態では、イニシエーターが既にアクセプター名を送信している場合、イニシエーターはどのアクセプターに接続したいかを知っているため、このトークンは通常、アクセプター名要求がない場合に送信されます。このサブトークンは拡張機能のセクション5.6でも送信されるため、イニシエーターは中間者がアクセプター名リクエストのサブトークンを変更することから保護できます。
+------+------------------------------+
| Pos | Description |
+------+------------------------------+
| 0..3 | 0x00000003 |
| | |
| 4..7 | length of subtoken |
| | |
| 8..n | string form of acceptor name |
+------+------------------------------+
In this state, the acceptor sends EAP requests to the initiator and the initiator generates EAP responses. The goal of the state is to perform a successful EAP authentication. Since the acceptor sends an identity request at the end of the initial state, the first half-round-trip in this state is a response to that request from the initiator.
この状態では、アクセプターはEAP要求をイニシエーターに送信し、イニシエーターはEAP応答を生成します。この状態の目標は、EAP認証を正常に実行することです。アクセプターは初期状態の最後にID要求を送信するため、この状態の最初の半ラウンドトリップは、イニシエーターからの要求への応答です。
The EAP conversation can end in a number of ways:
EAP会話は、いくつかの方法で終了します。
o If the EAP state machine generates an EAP Success message, then the EAP authenticator believes the authentication is successful. The acceptor MUST confirm that a key has been derived (Section 7.10 of [RFC3748]). The acceptor MUST confirm that this success indication is consistent with any protected result indication for combined authenticators and with AAA indication of success for pass-through authenticators. If any of these checks fail, the acceptor MUST send an error subtoken and fail the context establishment. If these checks succeed, the acceptor sends the Success message using the EAP Request subtoken type and transitions to Extensions state. If the initiator receives an EAP Success message, it confirms that a key has been derived and that the EAP Success is consistent with any protected result indication. If so, it transitions to Extensions state. Otherwise, it returns an error to the caller of GSS_Init_sec_context without producing an output token.
o EAPステートマシンがEAP成功メッセージを生成した場合、EAPオーセンティケーターは認証が成功したと信じます。アクセプターは、キーが派生したことを確認する必要があります（[RFC3748]のセクション7.10）。アクセプターは、この成功の表示が、複合認証システムの保護された結果表示およびパススルー認証システムの成功のAAA表示と一致していることを確認する必要があります。これらのチェックのいずれかが失敗した場合、アクセプターはエラーサブトークンを送信し、コンテキストの確立に失敗する必要があります。これらのチェックが成功すると、アクセプターはEAP要求サブトークンタイプを使用して成功メッセージを送信し、拡張状態に移行します。イニシエーターがEAP成功メッセージを受信した場合、キーが生成されたこと、およびEAP成功が保護された結果表示と一致していることを確認します。その場合、拡張状態に移行します。それ以外の場合は、出力トークンを生成せずに、GSS_Init_sec_contextの呼び出し元にエラーを返します。
o If the acceptor receives an EAP failure, then the acceptor sends this in the EAP Request subtoken type. If the initiator receives an EAP Failure, it returns GSS failure.
o アクセプターがEAP障害を受信した場合、アクセプターはこれをEAP要求サブトークンタイプで送信します。イニシエータがEAP障害を受信すると、GSS障害を返します。
o If there is some other error, the acceptor MAY return an error subtoken.
o 他のエラーがある場合、アクセプターはエラーサブトークンを返す場合があります。
The EAP Request subtoken is sent from the acceptor to the initiator. This subtoken is always critical and is REQUIRED in the authentication state.
EAP Requestサブトークンは、アクセプターからイニシエーターに送信されます。このサブトークンは常に重要であり、認証状態では必須です。
+-------------+-----------------------+
| Pos | Description |
+-------------+-----------------------+
| 0..3 | 0x80000005 |
| | |
| 4..7 | length of EAP message |
| | |
| 8..8+length | EAP message |
+-------------+-----------------------+
This subtoken is REQUIRED in authentication state messages from the initiator to the acceptor. It is always critical.
このサブトークンは、イニシエーターからアクセプターへの認証状態メッセージで必須です。それは常に重要です。
+-------------+-----------------------+
| Pos | Description |
+-------------+-----------------------+
| 0..3 | 0x80000004 |
| | |
| 4..7 | length of EAP message |
| | |
| 8..8+length | EAP message |
+-------------+-----------------------+
After EAP Success, the initiator sends a token to the acceptor including additional subtokens that negotiate optional features or provide GSS-API channel binding (see Section 6.1). The acceptor then responds with a token to the initiator. When the acceptor produces its final token, it returns GSS_S_COMPLETE; when the initiator consumes this token, it returns GSS_S_COMPLETE if no errors are detected.
EAP成功後、イニシエーターは、オプション機能をネゴシエートするか、GSS-APIチャネルバインディングを提供する追加のサブトークンを含むトークンをアクセプターに送信します（セクション6.1を参照）。次に、アクセプターはトークンでイニシエーターに応答します。アクセプターが最終トークンを生成すると、GSS_S_COMPLETEを返します。イニシエーターがこのトークンを使用するときに、エラーが検出されない場合は、GSS_S_COMPLETEを返します。
The acceptor SHOULD send an acceptor name response (Section 5.4.3) so that the initiator can get a copy of the acceptor name protected by the Message Integrity Check (MIC) subtoken.
アクセプターは、イニシエーターがMessage Integrity Check（MIC）サブトークンによって保護されたアクセプター名のコピーを取得できるように、アクセプター名応答（セクション5.4.3）を送信する必要があります（SHOULD）。
Both the initiator and acceptor MUST include and verify a MIC subtoken to protect the extensions exchange.
イニシエーターとアクセプターの両方が、拡張の交換を保護するためにMICサブトークンを含めて検証する必要があります。
This subtoken is sent to convey initiator flags to the acceptor. The flags are sent as a 32-bit integer in network byte order. The only flag defined so far is GSS_C_MUTUAL_FLAG, indicating that the initiator successfully performed mutual authentication of the acceptor. This flag is communicated to the acceptor because some protocols [RFC4462] require the acceptor to know whether the initiator has confirmed its identity. This flag has the value 0x2 to be consistent with RFC 2744.
このサブトークンは、イニシエーターフラグをアクセプターに伝えるために送信されます。フラグは、ネットワークバイトオーダーの32ビット整数として送信されます。これまでに定義された唯一のフラグはGSS_C_MUTUAL_FLAGであり、イニシエーターがアクセプターの相互認証を正常に実行したことを示します。一部のプロトコル[RFC4462]は、イニシエーターがIDを確認したかどうかをアクセプターに知らせる必要があるため、このフラグはアクセプターに通知されます。このフラグの値は0x2で、RFC 2744に準拠しています。
+-------+-----------------------+
| Pos | Description |
+-------+-----------------------+
| 0..3 | 0x0000000C |
| | |
| 4..7 | length of flags token |
| | |
| 8..11 | flags |
+-------+-----------------------+
Initiators MUST send 4 octets of flags. Acceptors MUST ignore flag octets beyond the first 4 and MUST ignore flag bits other than GSS_C_MUTUAL_FLAG. Initiators MUST send undefined flag bits as zero.
イニシエーターは4オクテットのフラグを送信する必要があります。アクセプターは、最初の4つを超えるフラグオクテットを無視する必要があり、GSS_C_MUTUAL_FLAG以外のフラグビットを無視する必要があります。イニシエーターは、未定義のフラグビットをゼロとして送信する必要があります。
This subtoken is always critical when sent. It is sent from the initiator to the acceptor. The contents of this token are an RFC 3961 get_mic token of the application data from the GSS channel bindings structure passed into the context establishment call.
このサブトークンは、送信時に常に重要です。イニシエーターからアクセプターに送信されます。このトークンの内容は、コンテキスト確立呼び出しに渡されるGSSチャネルバインディング構造からのアプリケーションデータのRFC 3961 get_micトークンです。
+-------------+-----------------------------------------------+
| Pos | Description |
+-------------+-----------------------------------------------+
| 0..3 | 0x80000006 |
| | |
| 4..7 | length of token |
| | |
| 8..8+length | get_mic of channel binding application data |
+-------------+-----------------------------------------------+
Again, only the application data is sent in the channel binding. Any initiator and acceptor addresses passed by an application into context establishment calls are ignored and not sent over the wire. The checksum type of the get_mic token SHOULD be the mandatory-to-implement checksum type of the Context Root Key (CRK). The key to use is the CRK and the key usage is 60 (KEY_USAGE_GSSEAP_CHBIND_MIC). An acceptor MAY accept any MIC in the channel bindings subtoken if the channel bindings input to GSS_Accept_sec_context is not provided. If the channel binding input to GSS_Accept_sec_context is provided, the acceptor MUST return failure if the channel binding MIC in a received channel binding subtoken fails to verify.
ここでも、アプリケーションデータのみがチャネルバインディングで送信されます。アプリケーションからコンテキスト確立呼び出しに渡されたイニシエーターとアクセプターのアドレスは無視され、ネットワーク経由で送信されません。 get_micトークンのチェックサムタイプは、コンテキストルートキー（CRK）の実装に必須のチェックサムタイプである必要があります（SHOULD）。使用する鍵はCRKで、鍵の使用法は60（KEY_USAGE_GSSEAP_CHBIND_MIC）です。 GSS_Accept_sec_contextへのチャネルバインディング入力が提供されていない場合、アクセプターはチャネルバインディングサブトークン内のすべてのMICを受け入れることができます。 GSS_Accept_sec_contextへのチャネルバインディング入力が提供されている場合、受信したチャネルバインディングサブトークン内のチャネルバインディングMICが検証に失敗すると、アクセプターは失敗を返す必要があります。
The initiator MUST send this token if channel bindings including application data are passed into GSS_Init_sec_context and MUST NOT send this token otherwise.
イニシエーターは、アプリケーションデータを含むチャネルバインディングがGSS_Init_sec_contextに渡される場合はこのトークンを送信する必要があり、そうでない場合はこのトークンを送信してはなりません（MUST NOT）。
This subtoken MUST be the last subtoken in the tokens sent in Extensions state. This subtoken is sent both by the initiator and acceptor.
このサブトークンは、拡張状態で送信されるトークンの最後のサブトークンである必要があります。このサブトークンは、イニシエーターとアクセプターの両方から送信されます。
+-------------+--------------------------------------------------+
| Pos | Description |
+-------------+--------------------------------------------------+
| 0..3 | 0x8000000D for initiator 0x8000000E for acceptor |
| | |
| 4..7 | length of RFC 3961 MIC token |
| | |
| 8..8+length | RFC 3961 result of get_mic |
+-------------+--------------------------------------------------+
As with any call to get_mic, a token is produced as described in RFC 3961 using the CRK (Section 6) as the key and the mandatory checksum type for the encryption type of the CRK as the checksum type. The key usage is 61 (KEY_USAGE_GSSEAP_ACCTOKEN_MIC) for the subtoken from the acceptor to the initiator and 62 (KEY_USAGE_GSSEAP_INITTOKEN_MIC) for the subtoken from the initiator to the acceptor. The input is as follows:
get_micの呼び出しと同様に、CRK（セクション6）をキーとして使用し、CRKの暗号化タイプの必須チェックサムタイプをチェックサムタイプとして使用して、RFC 3961に記述されているようにトークンが生成されます。キーの使用法は、アクセプターからイニシエーターへのサブトークンの場合は61（KEY_USAGE_GSSEAP_ACCTOKEN_MIC）で、イニシエーターからアクセプターへのサブトークンの場合は62（KEY_USAGE_GSSEAP_INITTOKEN_MIC）です。入力は次のとおりです。
1. The DER-encoded object identifier of the mechanism in use; this value starts with 0x06 (the tag for object identifier). When encoded in an RFC 2743 context token, the object identifier is preceded by the tag and length for [Application 0] SEQUENCE. This tag and the length of the overall token is not included; only the tag, length, and value of the object identifier itself.
1. 使用中のメカニズムのDERエンコードされたオブジェクト識別子。この値は0x06（オブジェクト識別子のタグ）で始まります。 RFC 2743コンテキストトークンでエンコードされている場合、オブジェクト識別子の前には、[Application 0] SEQUENCEのタグと長さが続きます。このタグとトークン全体の長さは含まれていません。オブジェクト識別子自体のタグ、長さ、および値のみ。
2. A 16-bit token type in network byte order of the RFC 4121 token identifier (0x0601 for initiator, 0x0602 for acceptor).
2. RFC 4121トークン識別子のネットワークバイトオーダーの16ビットトークンタイプ（イニシエーターは0x0601、アクセプターは0x0602）。
3. For each subtoken, other than the MIC subtoken itself, the order the subtokens appear in the token is as follows:
3. MICサブトークン自体以外のサブトークンごとに、トークンにサブトークンが表示される順序は次のとおりです。
4.
４。
1. A four-octet subtoken type in network byte order
1. ネットワークバイトオーダーの4オクテットサブトークンタイプ
2. A four-byte length in network byte order
2. ネットワークバイトオーダーの4バイト長
3. Length octets of value from that subtoken
3. そのサブトークンからの値の長さオクテット
+----+------+----+------+-----+-------------------------+
| 60 | 23 | 06 | 09 | 2b | 06 01 05 05 0f 01 01 11 |
+----+------+----+------+-----+-------------------------+
|App0|Token |OID |OID | 1 3 | 6 1 5 5 15 1 1 17 |
|Tag |length|Tag |length| Mechanism object ID |
+----+------+----+------+-------------------------------+
+----------+-------------+-------------+
| 06 01 | 00 00 00 02 | 00 00 00 0e |
+----------+-------------|-------------|
|Initiator | Acceptor | Length |
|context | name | (14 octets) |
|token ID | request | |
+----------+-------------+-------------+
+-------------------------------------------+
| 68 6f 73 74 2f 6c 6f 63 61 6c 68 6f 73 74 |
+-------------------------------------------+
| String form of acceptor name |
| "host/localhost" |
+-------------------------------------------+
Example Initiator Token
イニシエータートークンの例
GSS-API provides a number of optional per-context services requested by flags on the call to GSS_Init_sec_context and indicated as outputs from both GSS_Init_sec_context and GSS_Accept_sec_context. This section describes how these services are handled. Which services the client selects in the call to GSS_Init_sec_context controls what EAP methods MAY be used by the client. Section 7.2 of RFC 3748 describes a set of security claims for EAP. As described below, the selected GSS options place requirements on security claims that MUST be met.
GSS-APIは、GSS_Init_sec_contextの呼び出しのフラグによって要求され、GSS_Init_sec_contextとGSS_Accept_sec_contextの両方からの出力として示される、オプションのコンテキストごとのサービスをいくつか提供します。このセクションでは、これらのサービスの処理方法について説明します。クライアントがGSS_Init_sec_contextへの呼び出しで選択するサービスは、クライアントが使用できるEAPメソッドを制御します。 RFC 3748のセクション7.2は、EAPの一連のセキュリティ要求について説明しています。以下で説明するように、選択されたGSSオプションは、満たさなければならないセキュリティ要求に要件を課します。
This GSS mechanism MUST only be used with EAP methods that provide dictionary-attack resistance. Typically, dictionary-attack resistance is obtained by using an EAP tunnel method to tunnel an inner method in TLS.
このGSSメカニズムは、辞書攻撃耐性を提供するEAPメソッドでのみ使用する必要があります。通常、辞書攻撃耐性は、EAPトンネル方式を使用してTLSの内部方式をトンネルすることによって取得されます。
The EAP method MUST support key derivation. Integrity, confidentiality, sequencing, and replay detection MUST be indicated in the output of GSS_Init_sec_context and GSS_Accept_sec_context regardless of which services are requested.
EAP方式はキーの派生をサポートする必要があります。完全性、機密性、順序付け、およびリプレイ検出は、どのサービスが要求されているかに関係なく、GSS_Init_sec_contextおよびGSS_Accept_sec_contextの出力で示されなければなりません（MUST）。
The PROT_READY service defined in Section 1.2.7 of [RFC2743] is never available with this mechanism. Implementations MUST NOT offer this flag or permit per-message security services to be used before context establishment.
[RFC2743]のセクション1.2.7で定義されているPROT_READYサービスは、このメカニズムでは利用できません。実装は、このフラグを提供してはならず、コンテキスト確立の前に使用されるメッセージごとのセキュリティサービスを許可してはなりません。
The EAP method MUST support mutual authentication and channel binding. See Section 3.4 for details on what is required for successful mutual authentication. Regardless of whether mutual authentication is requested, the implementation MUST include channel bindings in the EAP authentication. If mutual authentication is requested and successful mutual authentication takes place as defined in Section 3.4, the initiator MUST send a flags subtoken Section 5.6.1 in Extensions state.
EAPメソッドは、相互認証とチャネルバインディングをサポートする必要があります。相互認証を成功させるために必要なことの詳細については、セクション3.4を参照してください。相互認証が要求されているかどうかに関係なく、実装はEAP認証にチャネルバインディングを含める必要があります。相互認証が要求され、セクション3.4の定義に従って相互認証が成功した場合、イニシエーターはセクション5.6.1のフラグサブトークンを拡張状態で送信する必要があります。
The context establishment process may be passed through to an EAP server via a backend authentication protocol. However, after the EAP authentication succeeds, security services are provided directly by the acceptor.
コンテキスト確立プロセスは、バックエンド認証プロトコルを介してEAPサーバーに渡されます。ただし、EAP認証が成功した後、セキュリティサービスはアクセプターによって直接提供されます。
This mechanism uses an RFC 3961 cryptographic key called the Context Root Key (CRK). The CRK is derived from the GMSK (GSS-API Master Session Key). The GMSK is the result of the random-to-key [RFC3961] operation of the encryption type of this mechanism consuming the appropriate number of bits from the EAP MSK. For example, for aes128-cts-hmac-sha1-96, the random-to-key operation consumes 16 octets of key material; thus, the first 16 bytes of the MSK are input to random-to-key to form the GMSK. If the MSK is too short, authentication MUST fail.
このメカニズムでは、コンテキストルートキー（CRK）と呼ばれるRFC 3961暗号化キーを使用します。 CRKはGMSK（GSS-APIマスターセッションキー）から派生します。 GMSKは、このメカニズムの暗号化タイプのランダムからキーへの[RFC3961]操作の結果であり、EAP MSKから適切なビット数を消費します。たとえば、aes128-cts-hmac-sha1-96の場合、ランダムからキーへの操作は16オクテットのキーマテリアルを消費します。したがって、MSKの最初の16バイトはランダムにキーに入力され、GMSKを形成します。 MSKが短すぎる場合、認証は失敗する必要があります。
In the following, pseudorandom is the RFC 3961 pseudorandom operation for the encryption type of the GMSK and random-to-key is the RFC 3961 random-to-key operation for the enctype of the mechanism. The truncate function takes the initial l bits of its input. The goal in constructing a CRK is to call the pseudorandom function enough times to produce the right number of bits of output and discard any excess bits of output.
以下では、疑似ランダムはGMSKの暗号化タイプのRFC 3961疑似ランダム操作であり、ランダムキーはメカニズムのenctypeのRFC 3961ランダムキー操作です。 truncate関数は、その入力の最初のlビットを取ります。 CRKを構築する目的は、出力の正しいビット数を生成し、余分な出力ビットを破棄するのに十分な回数、擬似ランダム関数を呼び出すことです。
The CRK is derived from the GMSK using the following procedure:
CRKは、次の手順を使用してGMSKから派生します。
Tn = pseudorandom(GMSK, n || "rfc4121-gss-eap")
CRK = random-to-key(truncate(L, T0 || T1 || .. || Tn))
L = random-to-key input size
Where n is a 32-bit integer in network byte order starting at 0 and incremented to each call to the pseudo_random operation.
ここで、nはネットワークバイトオーダーの32ビット整数で、0から始まり、pseudo_random操作の呼び出しごとに増分されます。
GSS-API channel binding [RFC5554] is a protected facility for exchanging a cryptographic name for an enclosing channel between the initiator and acceptor. The initiator sends channel binding data and the acceptor confirms that channel binding data has been checked.
GSS-APIチャネルバインディング[RFC5554]は、イニシエーターとアクセプターの間で囲んでいるチャネルの暗号名を交換するための保護された機能です。イニシエーターはチャネルバインディングデータを送信し、アクセプターはチャネルバインディングデータがチェックされたことを確認します。
The acceptor SHOULD accept any channel binding provided by the initiator if null channel bindings are passed into gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559] depend on this behavior of some Kerberos implementations.
nullチャネルバインディングがgss_accept_sec_contextに渡された場合、アクセプターはイニシエーターによって提供されたチャネルバインディングを受け入れる必要があります（SHOULD）。 HTTP Negotiate [RFC4559]などのプロトコルは、一部のKerberos実装のこの動作に依存しています。
As discussed, the GSS channel bindings subtoken is sent in the Extensions state.
説明したように、GSSチャネルバインディングサブトークンは、拡張状態で送信されます。
The per-message tokens of Section 4 of RFC 4121 are used. The CRK SHALL be treated as the initiator sub-session key, the acceptor sub-session key and the ticket session key.
RFC 4121のセクション4のメッセージごとのトークンが使用されます。 CRKは、イニシエーターサブセッションキー、アクセプターサブセッションキー、およびチケットセッションキーとして扱われる必要があります。
The pseudorandom function defined in [RFC4402] is used to provide GSS_Pseudo_Random functionality to applications.
[RFC4402]で定義されている擬似ランダム関数は、GSS_Pseudo_Random機能をアプリケーションに提供するために使用されます。
This specification creates a number of IANA registries.
この仕様は、多くのIANAレジストリを作成します。
IANA has created a registry of ABFAB object identifiers titled "Object Identifiers for Application Bridging for Federated Access". The initial contents of the registry are specified below. The registration policy is IETF Review or IESG Approval [RFC5226]. Early allocation is permitted. IANA has updated the reference for the root of this OID delegation to point to the newly created registry.
IANAは、「フェデレーテッドアクセスのアプリケーションブリッジングのオブジェクト識別子」というタイトルのABFABオブジェクト識別子のレジストリを作成しました。レジストリの初期内容は次のとおりです。登録ポリシーはIETFレビューまたはIESG承認[RFC5226]です。早期割り当てが許可されています。 IANAは、新しく作成されたレジストリを指すように、このOID委任のルートの参照を更新しました。
Decimal Name Description References
------- ---- ---------------------------------- ----------
0 Reserved Reserved RFC 7055
1 mechanisms A sub-arc containing ABFAB RFC 7055
mechanisms
2 nametypes A sub-arc containing ABFAB RFC 7055
GSS-API Name Types
Prefix: iso.org.dod.internet.security.mechanisms.abfab (1.3.6.1.5.5.15)
プレフィックス：iso.org.dod.internet.security.mechanisms.abfab（1.3.6.1.5.5.15）
NOTE: the following mechanisms registry is the root of the OID for the mechanism in question. As discussed in Section 5.1, a Kerberos encryption type number [RFC3961] is appended to the mechanism version OID below to form the OID of a specific mechanism.
注：次のメカニズムレジストリは、問題のメカニズムのOIDのルートです。セクション5.1で説明したように、Kerberos暗号化タイプ番号[RFC3961]が以下のメカニズムバージョンOIDに追加され、特定のメカニズムのOIDを形成します。
Prefix: iso.org.dod.internet.security.mechanisms.abfab.mechanisms (1.3.6.1.5.5.15.1)
プレフィックス：iso.org.dod.internet.security.mechanisms.abfab.mechanisms（1.3.6.1.5.5.15.1）
Decimal Name Description References
------- ---- ------------------------------- ----------
0 Reserved Reserved RFC 7055
1 gss-eap-v1 The GSS-EAP mechanism RFC 7055
Prefix: iso.org.dod.internet.security.mechanisms.abfab.nametypes (1.3.6.1.5.5.15.2)
プレフィックス：iso.org.dod.internet.security.mechanisms.abfab.nametypes（1.3.6.1.5.5.15.2）
Decimal Name Description References
------- ---- --------------------- ----------
0 Reserved Reserved RFC 7055
1 GSS_EAP_NT_EAP_NAME RFC 7055, Section 3.1
In the top-level registry titled "Kerberos V GSS-API Mechanism Parameters", a subregistry called "Kerberos GSS-API Token Type Identifiers" was created; the references for this subregistry are RFC 4121 and this document. The allocation procedure is Expert Review [RFC5226]. The Expert's primary job is to make sure that token type identifiers are requested by an appropriate requester for the RFC 4121 mechanism in which they will be used and that multiple values are not allocated for the same purpose. For RFC 4121 and this mechanism, the Expert is currently expected to make allocations for token identifiers from documents in the IETF stream; effectively, for these mechanisms, the Expert currently confirms the allocation meets the requirements of the IETF Review process.
「Kerberos V GSS-APIメカニズムパラメータ」というタイトルのトップレベルレジストリに、「Kerberos GSS-APIトークンタイプ識別子」というサブレジストリが作成されました。このサブレジストリのリファレンスはRFC 4121とこのドキュメントです。割り当て手順はExpert Review [RFC5226]です。エキスパートの主な仕事は、トークンタイプ識別子が、それらが使用されるRFC 4121メカニズムの適切なリクエスタによってリクエストされ、複数の値が同じ目的で割り当てられないことを確認することです。 RFC 4121とこのメカニズムの場合、エキスパートは現在、IETFストリームのドキュメントからトークン識別子の割り当てを行うことが期待されています。事実上、これらのメカニズムについて、専門家は現在、割り当てがIETFレビュープロセスの要件を満たしていることを確認しています。
The ID field is a hexadecimal token identifier specified in network byte order.
IDフィールドは、ネットワークバイトオーダーで指定された16進数のトークン識別子です。
The initial registrations are as follows:
初期登録は次のとおりです。
+-------+-------------------------------+---------------------------+
| ID | Description | Reference |
+-------+-------------------------------+---------------------------+
| 01 00 | KRB_AP_REQ | RFC 4121, Section 4.1 |
| | | |
| 02 00 | KRB_AP_REP | RFC 4121, Section 4.1 |
| | | |
| 03 00 | KRB_ERROR | RFC 4121, Section 4.1 |
| | | |
| 04 04 | MIC tokens | RFC 4121, Section 4.2.6.1 |
| | | |
| 05 04 | wrap tokens | RFC 4121, Section 4.2.6.2 |
| | | |
| 06 01 | GSS-EAP initiator context | RFC 7055, Section 5 |
| | token | |
| | | |
| 06 02 | GSS EAP acceptor context | RFC 7055, Section 5 |
| | token | |
+-------+-------------------------------+---------------------------+
This document creates a top-level registry called "The Extensible Authentication Protocol Mechanism for the Generic Security Service Application Programming Interface (GSS-EAP) Parameters". In any short form of that name, including any URI for this registry, it is important that the string GSS come before the string EAP; this will help to distinguish registries if EAP methods for performing GSS-API authentication are ever defined.
このドキュメントでは、「汎用セキュリティサービスアプリケーションプログラミングインターフェース（GSS-EAP）パラメータの拡張認証プロトコルメカニズム」と呼ばれるトップレベルのレジストリを作成します。このレジストリのURIを含む、その名前の短い形式では、文字列GSSが文字列EAPの前に来ることが重要です。これは、GSS-API認証を実行するためのEAPメソッドが定義されている場合に、レジストリを区別するのに役立ちます。
In this registry is a subregistry of subtoken types. Identifiers are 32-bit integers; the upper bit (0x80000000) is reserved as a critical flag and should not be indicated in the registration. Assignments of GSS-EAP subtoken types are made by Expert Review [RFC5226]. The Expert is expected to require a public specification of the subtoken similar in detail to registrations given in this document. The security of GSS-EAP depends on making sure that subtoken information has adequate protection and that the overall mechanism continues to be secure. Examining the security and architectural consistency of the proposed registration is the primary responsibility of the Expert.
このレジストリには、サブトークンタイプのサブレジストリがあります。識別子は32ビット整数です。上位ビット（0x80000000）はクリティカルフラグとして予約されており、登録では示されません。 GSS-EAPサブトークンタイプの割り当ては、Expert Review [RFC5226]によって行われます。専門家は、このドキュメントに記載されている登録と同様に、サブトークンの公開仕様を要求することが期待されています。 GSS-EAPのセキュリティは、サブトークン情報が適切に保護されていること、およびメカニズム全体が引き続き安全であることを確認することに依存しています。提案された登録のセキュリティとアーキテクチャの一貫性を調べることは、専門家の主な責任です。
+------------+--------------------------+---------------+
| Type | Description | Reference |
+------------+--------------------------+---------------+
| 0x00000001 | Error | Section 5.3 |
| | | |
| 0x0000000B | Vendor | Section 5.4.1 |
| | | |
| 0x00000002 | Acceptor name request | Section 5.4.2 |
| | | |
| 0x00000003 | Acceptor name response | Section 5.4.3 |
| | | |
| 0x00000005 | EAP request | Section 5.5.1 |
| | | |
| 0x00000004 | EAP response | Section 5.5.2 |
| | | |
| 0x0000000C | Flags | Section 5.6.1 |
| | | |
| 0x00000006 | GSS-API channel bindings | Section 5.6.2 |
| | | |
| 0x0000000D | Initiator MIC | Section 5.6.3 |
| | | |
| 0x0000000E | Acceptor MIC | Section 5.6.3 |
+------------+--------------------------+---------------+
The following RADIUS attribute type values [RFC3575] are assigned. The allocation instructions in Section 10.3 of [RFC6929] have been followed.
次のRADIUS属性タイプ値[RFC3575]が割り当てられます。 [RFC6929]のセクション10.3の割り当て手順に従いました。
+--------------------------------+-------+--------------------------+
| Description | Value | More Information |
+--------------------------------+-------+--------------------------+
| GSS-Acceptor-Service-Name | 164 | user-or-service portion |
| | | of name |
| | | |
| GSS-Acceptor-Host-Name | 165 | host portion of name |
| | | |
| GSS-Acceptor-Service-Specifics | 166 | service-specifics |
| | | portion of name |
| | | |
| GSS-Acceptor-Realm-Name | 167 | Realm portion of name |
+--------------------------------+-------+--------------------------+
Subject: Registration of SASL mechanisms EAP-AES128 and EAP-AES128-PLUS
件名：SASLメカニズムEAP-AES128およびEAP-AES128-PLUSの登録
SASL mechanism names: EAP-AES128 and EAP-AES128-PLUS
SASLメカニズム名：EAP-AES128およびEAP-AES128-PLUS
Security considerations: See RFC 5801 and RFC 7055
セキュリティに関する考慮事項：RFC 5801およびRFC 7055を参照してください
Published specification (recommended): RFC 7055
公開された仕様（推奨）：RFC 7055
Person & email address to contact for further information: Abfab Working Group, abfab@ietf.org
詳細について連絡する人と電子メールアドレス：Abfabワーキンググループ、abfab @ ietf.org
Intended usage: common
使用目的：一般
Owner/Change controller: iesg@ietf.org
Note: This mechanism describes the GSS-EAP mechanism used with the aes128-cts-hmac-sha1-96 enctype. The GSS-API OID for this mechanism is 1.3.6.1.5.5.15.1.1.17.
注：このメカニズムは、aes128-cts-hmac-sha1-96 enctypeで使用されるGSS-EAPメカニズムについて説明しています。このメカニズムのGSS-API OIDは1.3.6.1.5.5.15.1.1.17です。
As described in RFC 5801, a PLUS variant of this mechanism is also required.
RFC 5801で説明されているように、このメカニズムのPLUSバリアントも必要です。
A new subregistry is created in the GSS-EAP parameters registry titled "GSS-EAP Error Codes". The error codes in this registry are unsigned 32-bit numbers. Values less than or equal to 127 are assigned by Standards Action [RFC5226]. Values 128 through 255 are assigned with the Specification Required assignment policy [RFC5226].
「GSS-EAPエラーコード」というタイトルのGSS-EAPパラメータレジストリに新しいサブレジストリが作成されます。このレジストリのエラーコードは、署名されていない32ビットの数値です。 127以下の値は、標準アクション[RFC5226]によって割り当てられます。 128〜255の値は、Specification Required割り当てポリシー[RFC5226]で割り当てられます。
Values greater than 255 are reserved; updates to registration policy may make these values available for assignment and implementations MUST be prepared to receive them.
255より大きい値は予約されています。登録ポリシーの更新により、これらの値を割り当てに使用できるようになる場合があり、実装はそれらを受け取る準備をする必要があります。
This table provides the initial contents of the registry.
この表は、レジストリの初期コンテンツを提供します。
+-------+------------------------------------------------+
| Value | Description |
+-------+------------------------------------------------+
| 0 | Reserved |
| | |
| 1 | Buffer is incorrect size |
| | |
| 2 | Incorrect mechanism OID |
| | |
| 3 | Token is corrupted |
| | |
| 4 | Token is truncated |
| | |
| 5 | Packet received by direction that sent it |
| | |
| 6 | Incorrect token type identifier |
| | |
| 7 | Unhandled critical subtoken received |
| | |
| 8 | Missing required subtoken |
| | |
| 9 | Duplicate subtoken type |
| | |
| 10 | Received unexpected subtoken for current state |
| | |
| 11 | EAP did not produce a key |
| | |
| 12 | EAP key too short |
| | |
| 13 | Authentication rejected |
| | |
| 14 | AAA returned an unexpected message type |
| | |
| 15 | AAA response did not include EAP request |
| | |
| 16 | Generic AAA failure |
+-------+------------------------------------------------+
A new subregistry is created in the GSS-EAP parameters registry. This registry holds registrations of flag bits sent in the flags subtoken (Section 5.6.1). There are 32 flag bits available for registration represented as hexadecimal numbers from the most significant bit 0x80000000 to the least significant bit 0x1. The registration policy for this registry is IETF Review or, in exceptional cases, IESG Approval. The following table indicates initial registrations; all other values are available for assignment.
新しいサブレジストリがGSS-EAPパラメータレジストリに作成されます。このレジストリは、フラグサブトークンで送信されるフラグビットの登録を保持します（5.6.1節）。最上位ビット0x80000000から最下位ビット0x1までの16進数として表される、登録に使用できる32のフラグビットがあります。このレジストリの登録ポリシーはIETFレビュー、または例外的な場合はIESG承認です。次の表は、初期登録を示しています。他のすべての値は割り当てに使用できます。
+------+-------------------+---------------+
| Flag | Name | Reference |
+------+-------------------+---------------+
| 0x2 | GSS_C_MUTUAL_FLAG | Section 5.6.1 |
+------+-------------------+---------------+
RFC 3748 discusses security issues surrounding EAP. RFC 5247 discusses the security and requirements surrounding key management that leverages the AAA infrastructure. These documents are critical to the security analysis of this mechanism.
RFC 3748は、EAPを取り巻くセキュリティの問題について説明しています。 RFC 5247では、AAAインフラストラクチャを活用するキー管理に関連するセキュリティと要件について説明しています。これらのドキュメントは、このメカニズムのセキュリティ分析に不可欠です。
RFC 2743 discusses generic security considerations for the GSS-API. RFC 4121 discusses security issues surrounding the specific per-message services used in this mechanism.
RFC 2743では、GSS-APIの一般的なセキュリティの考慮事項について説明しています。 RFC 4121は、このメカニズムで使用される特定のメッセージごとのサービスを取り巻くセキュリティの問題について説明しています。
As discussed in Section 4, this mechanism may introduce multiple layers of security negotiation into application protocols. Multiple layer negotiations are vulnerable to a bid-down attack when a mechanism negotiated at the outer layer is preferred to some but not all mechanisms negotiated at the inner layer; see Section 7.3 of [RFC4462] for an example. One possible approach to mitigate this attack is to construct security policy such that the preference for all mechanisms negotiated in the inner layer falls between preferences for two outer-layer mechanisms or falls at one end of the overall ranked preferences including both the inner and outer layer. Another approach is to only use this mechanism when it has specifically been selected for a given service. The second approach is likely to be common in practice because one common deployment will involve an EAP supplicant interacting with a user to select a given identity. Only when an identity is successfully chosen by the user will this mechanism be attempted.
セクション4で説明したように、このメカニズムにより、アプリケーションプロトコルにセキュリティネゴシエーションの複数のレイヤーが導入される場合があります。複数層のネゴシエーションは、外層でネゴシエートされたメカニズムが、内層でネゴシエートされたすべてのメカニズムではなく一部のメカニズムよりも優先される場合、ビッドダウン攻撃に対して脆弱です。例については、[RFC4462]のセクション7.3を参照してください。この攻撃を緩和する1つの可能なアプローチは、内層でネゴシエートされたすべてのメカニズムの設定が2つの外層メカニズムの設定の間にあるか、内層と外層の両方を含む全体的なランク設定の一方の端にあるようにセキュリティポリシーを構築することです。別のアプローチは、特定のサービスに対して特別に選択されている場合にのみこのメカニズムを使用することです。 2番目のアプローチは、1つの一般的な展開に、特定のIDを選択するためにユーザーと対話するEAPサプリカントが含まれるため、実際には一般的である可能性があります。 IDがユーザーによって正常に選択された場合にのみ、このメカニズムが試行されます。
EAP channel binding is used to give the GSS-API initiator confidence in the identity of the GSS-API acceptor. Thus, the security of this mechanism depends on the use and verification of EAP channel binding.
EAPチャネルバインディングを使用して、GSS-APIイニシエーターがGSS-APIアクセプターのIDを信頼できるようにします。したがって、このメカニズムのセキュリティは、EAPチャネルバインディングの使用と検証に依存します。
Today, EAP channel binding is in very limited deployment. If EAP channel binding is not used, then the system may be vulnerable to phishing attacks where a user is diverted from one service to another. If the EAP method in question supports mutual authentication then users can only be diverted between servers that are part of the same AAA infrastructure. For deployments where membership in the AAA infrastructure is limited, this may serve as a significant limitation on the value of phishing as an attack. For other deployments, use of EAP channel binding is critical to avoid phishing. These attacks are possible with EAP today although not typically with common GSS-API mechanisms. For this reason, implementations are required to implement and use EAP channel binding; see Section 3 for details.
現在、EAPチャネルバインディングの展開は非常に限定されています。 EAPチャネルバインディングが使用されていない場合、システムがユーザーをあるサービスから別のサービスに誘導するフィッシング攻撃に対して脆弱になる可能性があります。問題のEAP方式が相互認証をサポートしている場合、ユーザーは同じAAAインフラストラクチャの一部であるサーバー間でのみ転送できます。 AAAインフラストラクチャのメンバーシップが制限されている展開では、これが攻撃としてのフィッシングの価値に対する重大な制限となる場合があります。その他の展開では、フィッシングを回避するためにEAPチャネルバインディングを使用することが重要です。これらの攻撃は今日のEAPで可能ですが、一般的なGSS-APIメカニズムでは一般的ではありません。このため、EAPチャネルバインディングを実装して使用するには実装が必要です。詳細については、セクション3を参照してください。
The security considerations of EAP channel binding [RFC6677] describe the security properties of channel binding. Two attacks are worth calling out here. First, when a tunneled EAP method is used, it is critical that the channel binding be performed with an EAP server trusted by the peer. With existing EAP methods, this typically requires validating the certificate of the server tunnel endpoint back to a trust anchor and confirming the name of the entity who is a subject of that certificate. EAP methods may suffer from bid-down attacks where an attacker can cause a peer to think that a particular EAP server does not support channel binding. This does not directly cause a problem because mutual authentication is only offered at the GSS-API level when channel binding to the server's identity is successful. However, when an EAP method is not vulnerable to these bid-down attacks, additional protection is available. This mechanism will benefit significantly from new strong EAP methods such as [TEAP].
EAPチャネルバインディングのセキュリティに関する考慮事項[RFC6677]では、チャネルバインディングのセキュリティプロパティについて説明しています。ここで、2つの攻撃を呼び出す価値があります。まず、トンネルEAP方式を使用する場合、ピアが信頼するEAPサーバーでチャネルバインディングを実行することが重要です。既存のEAP方式では、通常、サーバートンネルエンドポイントの証明書を検証してトラストアンカーに戻し、その証明書のサブジェクトであるエンティティの名前を確認する必要があります。 EAP方式は、攻撃者が特定のEAPサーバーがチャネルバインディングをサポートしていないとピアに思わせることができる、ビッドダウン攻撃の影響を受ける可能性があります。相互認証はサーバーのIDへのチャネルバインドが成功した場合にのみGSS-APIレベルで提供されるため、これが直接問題を引き起こすことはありません。ただし、EAPメソッドがこれらのビッドダウン攻撃に対して脆弱でない場合は、追加の保護を利用できます。このメカニズムは、[TEAP]などの新しい強力なEAPメソッドから大きなメリットを得ます。
Every proxy in the AAA chain from the authenticator to the EAP server needs to be trusted to help verify channel bindings and to protect the integrity of key material. GSS-API applications may be built to assume a trust model where the acceptor is directly responsible for authentication. However, GSS-API is definitely used with trusted-third-party mechanisms such as Kerberos.
オーセンティケーターからEAPサーバーへのAAAチェーン内のすべてのプロキシーは、チャネルバインディングの検証を支援し、キーマテリアルの整合性を保護するために信頼される必要があります。 GSS-APIアプリケーションは、アクセプターが認証を直接担当する信頼モデルを想定して構築されている場合があります。ただし、GSS-APIは、Kerberosなどの信頼できるサードパーティのメカニズムで確実に使用されます。
RADIUS does provide a weak form of hop-by-hop confidentiality of key material based on using MD5 as a stream cipher. Diameter can use TLS or IPsec but has no mandatory-to-implement confidentiality mechanism. Operationally, protecting key material as it is transported between the Identity Provider (IdP) and Relying Party (RP) is critical to per-message security and verification of GSS-API channel binding [RFC5056]. Mechanisms such as RADIUS over TLS [RFC6614] provide significantly better protection of key material than the base RADIUS specification.
RADIUSは、MD5をストリーム暗号として使用することに基づいて、鍵素材のホップバイホップの機密性の弱い形式を提供します。 DiameterはTLSまたはIPsecを使用できますが、実装に必須の機密性メカニズムはありません。運用上、キーマテリアルがアイデンティティプロバイダー（IdP）と証明書利用者（RP）の間で転送されるときにそれを保護することは、メッセージごとのセキュリティとGSS-APIチャネルバインディングの検証[RFC5056]にとって重要です。 RADIUS over TLS [RFC6614]などのメカニズムは、基本のRADIUS仕様よりもはるかに優れた鍵素材の保護を提供します。
Luke Howard, Jim Schaad, Alejandro Perez Mendez, Alexey Melnikov, and Sujing Zhou provided valuable reviews of this document.
Luke Howard、Jim Schaad、Alejandro Perez Mendez、Alexey Melnikov、およびSujing Zhouがこのドキュメントの貴重なレビューを提供しました。
Rhys Smith provided the text for the OID registry section. Sam Hartman's work on this document has been funded by JANET.
Rhys SmithがOIDレジストリセクションにテキストを提供しました。このドキュメントに関するSam Hartmanの作業は、JANETから資金提供を受けています。
[GSS-IANA] IANA, "GSS-API Service Name Registry", <http://www.iana.org/assignments/gssapi-service-names>.
[GSS-IANA] IANA、「GSS-APIサービス名レジストリ」、<http://www.iana.org/assignments/gssapi-service-names>。
[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月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743] Linn、J。、「Generic Security Service Application Program Interface Version 2、Update 1」、RFC 2743、2000年1月。
[RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.
[RFC2744] Wray、J。、「Generic Security Service API Version 2：C-bindings」、RFC 2744、2000年1月。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC3575] Aboba、B。、「RADIUS（リモート認証ダイヤルインユーザーサービス）に関するIANAの考慮事項」、RFC 3575、2003年7月。
[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、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3961] Raeburn、K。、「Kerberos 5の暗号化とチェックサムの仕様」、RFC 3961、2005年2月。
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
[RFC4121] Zhu、L.、Jaganathan、K。、およびS. Hartman、「The Kerberos Version 5 Generic Security Service Application Program Interface（GSS-API）Mechanism：Version 2」、RFC 4121、2005年7月。
[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、「The Network Access Identifier」、RFC 4282、2005年12月。
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)", RFC 4401, February 2006.
[RFC4401]ウィリアムズN。、「Generic Security Service Application Program Interface（GSS-API）用の疑似ランダム関数（PRF）API拡張」、RFC 4401、2006年2月。
[RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism", RFC 4402, February 2006.
[RFC4402]ウィリアムズN。、「Kerberos V汎用セキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）メカニズム用の疑似ランダム関数（PRF）」、RFC 4402、2006年2月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]ウィリアムズN.、「セキュアチャネルへのチャネルバインディングの使用について」、RFC 5056、2007年11月。
[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、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5554] Williams, N., "Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings", RFC 5554, May 2009.
[RFC5554]ウィリアムズN.、「チャネルバインディングを使用するためのGeneric Security Serviceアプリケーションプログラムインターフェイス（GSS-API）の説明と拡張」、RFC 5554、2009年5月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、2010年8月。
[RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, July 2012.
[RFC6677] Hartman、S.、Clancy、T。、およびK. Hoeper、「拡張可能認証プロトコル（EAP）メソッドのチャネルバインディングサポート」、RFC 6677、2012年7月。
[RFC7057] Winter, S. and J. Salowey, "Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB)", RFC 7057, December 2013.
[RFC7057] Winter、S.およびJ. Salowey、「Webを超えたフェデレーテッドアクセスのアプリケーションブリッジングに関する拡張認証プロトコル（EAP）の適用に関する声明（ABFAB）の更新」、RFC 7057、2013年12月。
[ABFAB-ARCH] Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. Schaad, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Work in Progress, July 2013.
[ABFAB-ARCH] Howlett、J.、Hartman、S.、Tschofenig、H.、Lear、E。、およびJ. Schaad、「Webを超えるフェデレーテッドアクセス（ABFAB）アーキテクチャのアプリケーションブリッジング」、Work in Progress、2013年7月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964] Linn、J。、「The Kerberos Version 5 GSS-API Mechanism」、RFC 1964、1996年6月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B。およびP. Calhoun、「RADIUS（Remote Authentication Dial In User Service）Support For Extensible Authentication Protocol（EAP）」、RFC 3579、2003年9月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.、Hiller、T。、およびG. Zorn、「Diameter Extensible Authentication Protocol（EAP）Application」、RFC 4072、2005年8月。
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism", RFC 4178, October 2005.
[RFC4178] Zhu、L.、Leach、P.、Jaganathan、K。、およびW. Ingersoll、「The Simple and Protected Generic Security Service Application Program Interface（GSS-API）Negotiation Mechanism」、RFC 4178、2005年10月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] Melnikov、A。およびK. Zeilenga、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, May 2006.
[RFC4462] Hutzelman、J.、Salowey、J.、Galbraith、J。、およびV. Welch、「Generic Security Service Application Program Interface（GSS-API）Authentication and Key Exchange for the Secure Shell（SSH）Protocol」、RFC 4462、2006年5月。
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows", RFC 4559, June 2006.
[RFC4559] Jaganathan、K.、Zhu、L。、およびJ. Brezak、「Microsoft WindowsでのSPNEGOベースのKerberosおよびNTLM HTTP認証」、RFC 4559、2006年6月。
[RFC5178] Williams, N. and A. Melnikov, "Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type", RFC 5178, May 2008.
[RFC5178]ウィリアムズN.およびA.メルニコフ、「Generic Security Service Application Program Interface（GSS-API）Internationalization and Domain-Based Service Names and Name Type」、RFC 5178、2008年5月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247] Aboba、B.、Simon、D。、およびP. Eronen、「Extensible Authentication Protocol（EAP）Key Management Framework」、RFC 5247、2008年8月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066] Eastlake、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、2011年1月。
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012.
[RFC6614] Winter、S.、McCauley、M.、Venaas、S.、and K. Wierenga、 "Transport Layer Security（TLS）Encryption for RADIUS"、RFC 6614、May 2012。
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013.
[RFC6929] DeKok、A。およびA. Lior、「Remote Authentication Dial In User Service（RADIUS）Protocol Extensions」、RFC 6929、2013年4月。
[TEAP] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel EAP Method (TEAP) Version 1", Work in Progress, September 2013.
[TEAP] Zhou、H.、Cam-Winget、N.、Salowey、J。、およびS. Hanna、「Tunnel EAP Method（TEAP）Version 1」、Work in Progress、2013年9月。
As described in Section 3.4, RADIUS attributes are used to carry the acceptor name when this family of mechanisms is used with RADIUS. Prior to the publication of this specification, a vendor-specific RADIUS attribute was used. This non-normative appendix documents that attribute as it may be seen from older implementations.
セクション3.4で説明されているように、このメカニズムのメカニズムがRADIUSで使用される場合、RADIUS属性を使用してアクセプター名が保持されます。この仕様が公開される前は、ベンダー固有のRADIUS属性が使用されていました。この非規範的な付録は、古い実装から見られる可能性があるため、その属性を文書化しています。
Prior to IANA assignment, GSS-EAP used a RADIUS vendor-specific attribute for carrying the acceptor name. The Vendor-Specific Attribute (VSA) with enterprise ID 25622 is formatted as a VSA according to the recommendation in the RADIUS specification. The following sub-attributes are defined:
IANA割り当ての前は、GSS-EAPはRADIUSベンダー固有の属性を使用してアクセプター名を伝達していました。エンタープライズID 25622のベンダー固有属性（VSA）は、RADIUS仕様の推奨に従ってVSAとしてフォーマットされます。次のサブ属性が定義されています。
+--------------------------------+-----------+----------------------+
| Name | Attribute | Description |
+--------------------------------+-----------+----------------------+
| GSS-Acceptor-Service-Name | 128 | user-or-service |
| | | portion of name |
| | | |
| GSS-Acceptor-Host-Name | 129 | host portion of name |
| | | |
| GSS-Acceptor-Service-Specifics | 130 | service-specifics |
| | | portion of name |
| | | |
| GSS-Acceptor-Realm-Name | 131 | Realm portion of |
| | | name |
+--------------------------------+-----------+----------------------+
Authors' Addresses
著者のアドレス
Sam Hartman (editor) Painless Security
サムハートマン（編集者）痛みのないセキュリティ
EMail: hartmans-ietf@mit.edu
Josh Howlett JANET(UK)
ジョシュハウレットジャネット（英国）
EMail: josh.howlett@ja.net