[要約] RFC 7057は、ABFABに関するEAPの適用性文書の更新であり、ABFABの目的は、Webを超えた連携アクセスのためのアプリケーションブリッジングを可能にすることです。
Internet Engineering Task Force (IETF) S. Winter
Request for Comments: 7057 RESTENA
Updates: 3748 J. Salowey
Category: Standards Track Cisco
ISSN: 2070-1721 December 2013
Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB)
Webを超えたフェデレーションアクセスのアプリケーションブリッジング（ABFAB）の拡張認証プロトコル（EAP）の適用に関する声明の更新
Abstract
概要
This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC 3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture.
このドキュメントでは、RFC 3748の拡張認証プロトコル（EAP）の適用に関する声明を更新して、Web経由のフェデレーションアクセスのアプリケーションブリッジング（ABFAB）アーキテクチャでのEAPプロトコルの最近の使用を反映します。
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/rfc7057.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7057で入手できます。
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 ....................................................2
1.1. Requirements Language ......................................2
2. Uses of EAP for Application-Layer Access ........................2
2.1. Retransmission .............................................4
2.2. Re-authentication ..........................................5
3. Revised EAP Applicability Statement .............................5
4. Security Considerations .........................................6
5. Acknowledgements ................................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
The EAP applicability statement in [RFC3748] defines the scope of the Extensible Authentication Protocol to be "for use in network access authentication, where IP layer connectivity may not be available", and states that "Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED".
[RFC3748]のEAP適用性ステートメントは、Extensible Authentication Protocolの範囲を「IP層の接続が利用できないネットワークアクセス認証で使用する」と定義し、「バルクなどの他の目的でのEAPの使用」と述べていますデータ転送は推奨されません。」
While some of the reasons for the recommendation against usage of EAP for bulk data transport are still valid, some of the other provisions in the applicability statement have turned out to be too narrow. Section 2 describes the example where EAP is used to authenticate application-layer access. Section 3 provides new text to update Section 1.3., "Applicability", in [RFC3748].
バルクデータ転送にEAPを使用しないことを推奨する理由の一部は依然として有効ですが、適用性ステートメントの他の規定の一部は狭すぎることが判明しています。セクション2では、アプリケーション層のアクセスを認証するためにEAPが使用される例について説明します。セクション3は、[RFC3748]のセクション1.3。「適用性」を更新するための新しいテキストを提供します。
In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
Ongoing work in the IETF specifies the use of EAP over Generic Security Service Application Program Interface (GSS-API) for generic application layer access [RFC7055]. In the past, using EAP in this context has met resistance due to the lack of channel bindings [RFC6677]. Without channel bindings, a peer cannot verify if an authenticator is authorized to provide an advertised service.
IETFでの進行中の作業では、汎用アプリケーションレイヤーアクセス[RFC7055]に対するEAP over Generic Security Serviceアプリケーションプログラムインターフェイス（GSS-API）の使用を指定しています。過去には、このコンテキストでのEAPの使用は、チャネルバインディングがないために抵抗に遭っていました[RFC6677]。チャネルバインディングがないと、ピアはオーセンティケータがアドバタイズされたサービスを提供することを許可されているかどうかを確認できません。
However, as additional services use EAP for authentication, the distinction of which service is being contacted becomes more important. Application services might have different properties. Consider an environment with multiple printers, some of which provide a confidential service to output documents to a controlled location. If a peer sent a document to the wrong service, then potentially sensitive information might be printed in an uncontrolled location and be disclosed. In addition, it might be more likely that a low-value service is compromised than some high-value service. If the high-value service could be impersonated by a low-value service then the security of the overall system would be limited by the security of the lower-value service.
ただし、追加のサービスは認証にEAPを使用するため、どのサービスにアクセスするかの区別はより重要になります。アプリケーションサービスには異なるプロパティがある場合があります。複数のプリンターが存在する環境について考えてみます。そのうちのいくつかは、ドキュメントを管理された場所に出力する機密サービスを提供します。ピアがドキュメントを間違ったサービスに送信した場合、潜在的に機密情報が管理されていない場所に印刷され、開示される可能性があります。さらに、価値の低いサービスは、価値の高いサービスよりも危険にさらされる可能性が高くなります。高価値のサービスが低価値のサービスによって偽装される可能性がある場合、システム全体のセキュリティは低価値のサービスのセキュリティによって制限されます。
This distinction is present in any environment where peers' security depends on which service they reach. However, it is particularly acute in a federated environment where multiple organizations are involved. It is very likely that these organizations will have different security policies and practices. It is very likely that the goals of these organizations will not entirely be aligned. In many situations, one organization could gain value by being able to impersonate another. In this environment, authenticating the EAP server is insufficient: the peer must also validate that the contacted host is authorized to provide the requested service.
この違いは、ピアのセキュリティが到達するサービスに依存している環境に存在します。ただし、複数の組織が関与するフェデレーション環境では特に深刻です。これらの組織には異なるセキュリティポリシーと実践がある可能性が非常に高いです。これらの組織の目標が完全には一致しない可能性が非常に高いです。多くの状況で、ある組織は別の組織になりすますことができることで価値を得ることができます。この環境では、EAPサーバーの認証では不十分です。ピアは、接続されたホストが要求されたサービスを提供することを承認されていることも検証する必要があります。
In environments where EAP is used for purposes other than network access authentication:
EAPがネットワークアクセス認証以外の目的で使用される環境では、次のようになります。
o All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support channel bindings.
o すべてのEAPサーバーとすべてのアプリケーションアクセスEAPピアは、チャネルバインディングをサポートする必要があります。すべてのネットワークアクセスEAPピアは、チャネルバインディングをサポートする必要があります（SHOULD）。
o Channel binding MUST be used for all application authentication. The EAP server MUST require that either the correct EAP lower-layer attribute or another attribute indicating the purpose of the authentication be present in the channel binding data for application authentication.
o チャネルバインディングは、すべてのアプリケーション認証に使用する必要があります。 EAPサーバーは、正しいEAP下位層属性または認証の目的を示す別の属性のいずれかが、アプリケーション認証のチャネルバインディングデータに存在することを要求する必要があります。
o Channel binding SHOULD be used for all network access authentication, and when channel binding data is present, the EAP server MUST require that it contain the correct EAP lower-layer attribute to explicitly identify the reason for authentication.
o チャネルバインディングはすべてのネットワークアクセス認証に使用する必要があります（SHOULD）。チャネルバインディングデータが存在する場合、EAPサーバーは、認証の理由を明示的に識別するために、正しいEAP下位層属性を含む必要があります。
o Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage.
o EAPの新しい使用では、ネットワークアクセスの使用との混乱を防ぐために、EAP下位層属性を含むチャネルバインディングを使用する必要があります。
Operators need to carefully consider the security implications before relaxing these requirements. One potentially serious attack exists when channel binding is not required and EAP authentication is introduced into an existing service other than network access. A device can be created that impersonates a Network Access Service (NAS) to peers, but actually proxies the authentication to the new application service that accepts EAP authentications. This may decrease the security of this service even for users who previously used non-EAP means of authentication to the service.
オペレーターは、これらの要件を緩和する前に、セキュリティへの影響を慎重に検討する必要があります。チャネルバインディングが不要で、ネットワークアクセス以外の既存のサービスにEAP認証が導入されている場合、重大な攻撃の可能性があります。ネットワークアクセスサービス（NAS）をピアに偽装しながら、実際にはEAP認証を受け入れる新しいアプリケーションサービスに認証をプロキシするデバイスを作成できます。これにより、以前にサービスに対して非EAP認証手段を使用したユーザーであっても、このサービスのセキュリティが低下する可能性があります。
It is REQUIRED for the application layer to prove that both the EAP peer and EAP authenticator possess the EAP Master Session Key (MSK). Failing to validate the possession of the EAP MSK can allow an attacker to insert himself into the conversation and impersonate the peer or authenticator. In addition, the application should define channel binding attributes that are sufficient to validate that the application service is being correctly represented to the peer.
アプリケーション層は、EAPピアとEAPオーセンティケーターの両方がEAPマスターセッションキー（MSK）を所有していることを証明する必要があります。 EAP MSKの所有権を検証できない場合、攻撃者が自分を会話に挿入し、ピアまたは認証者になりすます可能性があります。さらに、アプリケーションは、アプリケーションサービスがピアに正しく表現されていることを検証するのに十分なチャネルバインディング属性を定義する必要があります。
In EAP, the authenticator is responsible for retransmission. By default, EAP assumes that the lower layer (the application in this context) is unreliable. The authenticator can send a packet whenever its retransmission timer triggers. In this mode, applications need to be able to receive and process EAP messages at any time during the authentication conversation.
EAPでは、オーセンティケータが再送信を担当します。デフォルトでは、EAPは下位層（このコンテキストのアプリケーション）は信頼できないと見なします。オーセンティケーターは、再送信タイマーがトリガーされるたびにパケットを送信できます。このモードでは、アプリケーションは認証会話中にいつでもEAPメッセージを受信して処理できる必要があります。
Alternatively, EAP permits a lower layer to set the retransmission timer to infinite. When this happens, the lower layer becomes responsible for reliable delivery of EAP messages. Applications that use a lock-step or client-driven authentication protocol might benefit from this approach.
または、EAPは、下位層が再送信タイマーを無限に設定することを許可します。これが発生すると、下位層がEAPメッセージの信頼できる配信を担当します。ロックステップまたはクライアント主導の認証プロトコルを使用するアプリケーションは、このアプローチの恩恵を受ける可能性があります。
In addition to retransmission behavior, applications need to deal with discarded EAP messages. For example, whenever some EAP methods receive erroneous input, these methods discard the input rather than generating an error response. If the erroneous input was generated by an attacker, legitimate input can sometimes be received after the erroneous input. Applications MUST handle discarded EAP messages, although the specific way in which discarded messages will be handled depends on the characteristics of the application. Options include failing the authentication at the application level, requesting an EAP retransmit and waiting for additional EAP input.
再送信動作に加えて、アプリケーションは破棄されたEAPメッセージを処理する必要があります。たとえば、一部のEAPメソッドが誤った入力を受信すると、これらのメソッドはエラー応答を生成するのではなく、入力を破棄します。誤った入力が攻撃者によって生成された場合、誤った入力の後に正当な入力が受信されることがあります。アプリケーションは破棄されたEAPメッセージを処理する必要がありますが、破棄されたメッセージが処理される特定の方法はアプリケーションの特性によって異なります。オプションには、アプリケーションレベルでの認証の失敗、EAP再送信の要求、追加のEAP入力の待機などがあります。
Applications designers that incorporate EAP into their application need to determine how retransmission and message discards are handled.
アプリケーションにEAPを組み込むアプリケーション設計者は、再送信とメッセージ破棄の処理方法を決定する必要があります。
EAP lower layers MAY provide a mechanism for re-authentication to happen within an existing session [RFC3748]. Re-authentication permits security associations to be updated without establishing a new session. For network access, this can be important because interrupting network access can disrupt connections and media.
EAP下位層は、既存のセッション[RFC3748]内で発生する再認証のメカニズムを提供する場合があります。再認証により、新しいセッションを確立せずにセキュリティアソシエーションを更新できます。ネットワークアクセスの場合、ネットワークアクセスを中断すると接続とメディアが中断される可能性があるため、これは重要な場合があります。
Some applications might not need re-authentication support. For example, if sessions are relatively short-lived or if sessions can be replaced without significant disruption, re-authentication might not provide value. Protocols like HyperText Transfer Protocol (HTTP) [RFC2616] and Simple Mail Transport Protocol (SMTP) [RFC5321] are examples of protocols where establishing a new connection to update security associations is likely to be sufficient.
一部のアプリケーションは、再認証サポートを必要としない場合があります。たとえば、セッションの存続期間が比較的短い場合、またはセッションを大幅に中断することなく置き換えることができる場合、再認証は価値を提供しない可能性があります。ハイパーテキスト転送プロトコル（HTTP）[RFC2616]やシンプルメールトランスポートプロトコル（SMTP）[RFC5321]などのプロトコルは、セキュリティアソシエーションを更新するための新しい接続の確立で十分である可能性が高いプロトコルの例です。
Re-authentication is likely to be valuable if sessions or connections are long-lived or if there is a significant cost to disrupting them.
再認証は、セッションまたは接続が長命である場合、またはそれらを中断するためにかなりのコストがかかる場合に価値がある可能性があります。
Another factor may make re-authentication important. Some protocols only permit one party in a protocol (for example, the client) to establish a new connection. If another party in the protocol needs the security association refreshed, then re-authentication can provide a mechanism to do so.
別の要因により、再認証が重要になる場合があります。一部のプロトコルでは、プロトコルの1つのパーティ（クライアントなど）のみが新しい接続を確立できます。プロトコルの別の関係者がセキュリティアソシエーションを更新する必要がある場合、再認証によりそのメカニズムが提供されます。
Application designers need to determine whether re-authentication support is needed and which parties can initiate it.
アプリケーション設計者は、再認証サポートが必要かどうか、およびどの当事者がそれを開始できるかを決定する必要があります。
The following text is appended to the EAP applicability statement in [RFC3748].
次のテキストは、[RFC3748]のEAP適用性ステートメントに追加されます。
In cases where EAP is used for application authentication, support for EAP channel bindings is REQUIRED on the EAP peer and EAP server to validate that the host is authorized to provide the services requested. In addition, the application MUST define channel binding attributes that are sufficient to validate that the application service is being correctly represented to the peer. The protocol carrying EAP MUST prove possession of the EAP MSK between the EAP peer and EAP authenticator. In the context of EAP for application access the application is providing the EAP lower layer. Applications protocols vary so their specific behavior and transport characteristics needs to be considered when determining their retransmission and re-authentication behavior. Circumstances might require that applications need to perform conversion of identities from an application specific character set to UTF-8 or another character set required by a particular EAP method. See also [RADEXT-NAI], Section 2.6, for information about normalization of identifiers.
EAPがアプリケーション認証に使用される場合、ホストが要求されたサービスを提供することを承認されていることを検証するために、EAPピアとEAPサーバーでEAPチャネルバインディングのサポートが必要です。さらに、アプリケーションは、アプリケーションサービスがピアに正しく表現されていることを検証するのに十分なチャネルバインディング属性を定義する必要があります。 EAPを伝送するプロトコルは、EAPピアとEAPオーセンティケーター間のEAP MSKの所有を証明する必要があります。アプリケーションアクセスのEAPのコンテキストでは、アプリケーションはEAPの下位層を提供しています。アプリケーションプロトコルはさまざまであるため、再送信と再認証の動作を決定する際には、特定の動作とトランスポートの特性を考慮する必要があります。状況によっては、アプリケーションがIDをアプリケーション固有の文字セットからUTF-8または特定のEAPメソッドで必要な別の文字セットに変換する必要がある場合があります。識別子の正規化については、[RADEXT-NAI]、セクション2.6も参照してください。
In addition to the requirements discussed in the main sections of the document, applications should take into account how server authentication is achieved. Some deployments may allow for weak server authentication that is then validated with an additional existing exchange that provides mutual authentication. In order to fully mitigate the risk of NAS impersonation when these mechanisms are used, it is RECOMMENDED that mutual channel bindings be used to bind the authentications together as described in [RFC7029]. When doing channel binding it is REQUIRED that the authenticator is not able to modify the channel binding data passed between the peer to the authenticator as part of the authentication process.
このドキュメントのメインセクションで説明されている要件に加えて、アプリケーションでは、サーバー認証の実現方法を考慮する必要があります。一部の展開では、弱いサーバー認証が可能で、相互認証を提供する追加の既存の交換で検証されます。 [RFC7029]で説明されているように、これらのメカニズムが使用されている場合にNASの偽装のリスクを完全に軽減するために、相互チャネルバインディングを使用して認証をバインドすることをお勧めします。チャネルバインディングを行う場合、オーセンティケータが、認証プロセスの一環としてピアとオーセンティケータの間で渡されるチャネルバインディングデータを変更できないことが必要です。
Large amounts of helpful text and insightful thoughts were contributed by Sam Hartman, Painless Security. David Black contributed to the text clarifying channel bindings usage.
有用なテキストと洞察に満ちた考えが大量に提供されたのは、無痛セキュリティのサムハートマン氏です。 David Blackは、チャネルバインディングの使用法を明確にするテキストに貢献しました。
[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月。
[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月。
[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月。
[RADEXT-NAI] DeKok, A., "The Network Access Identifier", Work in Progress, November 2013.
[RADEXT-NAI] DeKok、A。、「The Network Access Identifier」、Work in Progress、2013年11月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding", RFC 7029, October 2013.
[RFC7029] Hartman、S.、Wasserman、M。、およびD. Zhang、「Extensible Authentication Protocol（EAP）Mutual Cryptographic Binding」、RFC 7029、2013年10月。
[RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for the Extensible Authentication Protocol", RFC 7055, December 2013.
[RFC7055]ハートマン、S。、エド。およびJ.ハウレット、「Extensible Authentication ProtocolのGSS-APIメカニズム」、RFC 7055、2013年12月。
Authors' Addresses
著者のアドレス
Stefan Winter Fondation RESTENA 6, rue Richard Coudenhove-Kalergi Luxembourg 1359 LUXEMBOURG
Stefan Winter Foundation RESTENA 6、rue Richard Coudenhove-Kalergi Luxembourg 1359 LUXEMBOURG
Phone: +352 424409 1 Fax: +352 422473 EMail: stefan.winter@restena.lu URI: http://www.restena.lu.
電話：+352 424409 1ファックス：+352 422473メール：stefan.winter@restena.lu URI：http://www.restena.lu。
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, Washington 98121 USA
Joseph Salowey Cisco Systems 2901 3rd Aveシアトル、ワシントン98121米国
EMail: jsalowey@cisco.com