[要約] RFC 4284は、EAPでの識別子の選択ヒントに関するガイドラインです。その目的は、EAPフレーム内の識別子の選択方法を標準化し、セキュリティと効率性を向上させることです。
Network Working Group F. Adrangi
Request for Comments: 4284 V. Lortz
Category: Informational Intel
F. Bari
Cingular Wireless
P. Eronen
Nokia
January 2006
Identity Selection Hints for the Extensible Authentication Protocol (EAP)
拡張可能な認証プロトコル（EAP）のアイデンティティ選択ヒント
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
IESG Note:
IESGノート：
EAP Identity Selection was developed by 3GPP. Documentation is provided as information to the Internet community. The EAP WG has verified that this specification is compatible with EAP as defined in RFC 3748. Required 3GPP client behavior is described in 3GPP TS 24.234.
EAP IDの選択は、3GPPによって開発されました。ドキュメントは、インターネットコミュニティへの情報として提供されます。EAP WGは、この仕様がRFC 3748で定義されているEAPと互換性があることを確認しました。必要な3GPPクライアントの動作は、3GPP TS 24.234で説明されています。
Abstract
概要
The Extensible Authentication Protocol (EAP) is defined in RFC 3748. This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer -- the end of the link that responds to the authenticator. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier (NAI). This is useful in situations where the peer does not receive a lower-layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker.
拡張可能な認証プロトコル（EAP）はRFC 3748で定義されています。このドキュメントは、アクセスネットワークがEAPピアにアイデンティティ選択ヒントを提供できるメカニズムを定義します。目的は、EAPピアが適切なネットワークアクセス識別子（NAI）の選択を支援することです。これは、ピアがどのネットワークに接続しているか、またはアクセスネットワークとピアのホームネットワークの間に直接のローミング関係がない場合、ピアが低層の兆候を受け取らない状況で有用です。後者の場合、認証は通常、ローミングコンソーシアムやブローカーなどの調停ネットワークを介して達成されます。
The mechanism defined in this document is limited in its scalability. It is intended for access networks that have a small to moderate number of direct roaming partners.
このドキュメントで定義されているメカニズムは、そのスケーラビリティが制限されています。これは、小規模から中程度の数の直接ローミングパートナーを持つアクセスネットワークを対象としています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Relationship with Other Specifications .....................3
1.2. Applicability ..............................................3
1.3. Terminology ................................................4
2. Implementation Requirements .....................................4
2.1. Packet Format ..............................................5
3. Security Considerations .........................................6
4. Acknowledgements ................................................7
5. Appendix - Delivery Options .....................................8
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................12
The Extensible Authentication Protocol (EAP) is defined in [RFC3748]. An EAP peer (hereafter, also referred to as the peer) may have multiple credentials. Where the lower layer does not provide an indication of which network it is connecting to, or where its home network may have roaming relationships with several mediating networks, the peer may be uncertain of which Network Access Identifier (NAI) to include in an EAP-Response/Identity.
拡張可能な認証プロトコル（EAP）は[RFC3748]で定義されています。EAPピア（以下、ピアとも呼ばれる）には、複数の資格情報がある場合があります。下層がどのネットワークに接続しているか、またはそのホームネットワークがいくつかの媒介ネットワークとローミング関係を持っている可能性がある場合、ピアは、EAP応答/アイデンティティに含まれるネットワークアクセス識別子（NAI）が不確実である可能性があります。
This document defines a mechanism that allows the access network to provide an EAP peer with identity selection hints, including information about its roaming relationships. This information is sent to the peer in an EAP-Request/Identity message by appending it after the displayable message and a NUL character.
このドキュメントは、アクセスネットワークがEAPピアに、そのローミング関係に関する情報を含むアイデンティティ選択ヒントを提供できるようにするメカニズムを定義しています。この情報は、表示可能なメッセージとnul文字の後に追加することにより、EAP-Request/Identityメッセージでピアに送信されます。
This mechanism may assist the peer in selecting a credential and associated NAI, or in formatting the NAI [RFC4282] to facilitate routing of Authentication, Authorization, and Accounting (AAA) messages to the home AAA server. If there are several mediating networks available, the peer can influence which one is used.
このメカニズムは、認証、承認、およびHome AAAサーバーへの会計（AAA）メッセージのルーティングを容易にするために、資格情報と関連するNAIを選択するか、NAI [RFC4282]をフォーマットするのに役立ちます。利用可能ないくつかの媒介ネットワークがある場合、ピアは使用するものに影響を与える可能性があります。
Exactly how the selection is made by the peer depends largely on the peer's local policy and configuration, and is outside the scope of this document. For example, the peer could decide to use one of its other identities, decide to switch to another access network, or attempt to reformat its NAI [RFC4282] to assist in proper AAA routing. The exact client behavior is described by standard bodies using this specification such as 3GPP [TS-24.234].
ピアによって選択される方法は、ピアのローカルポリシーと構成に大きく依存し、このドキュメントの範囲外です。たとえば、ピアは他のIDの1つを使用するか、別のアクセスネットワークに切り替えることを決定するか、適切なAAAルーティングを支援するためにNAI [RFC4282]を再フォーマットすることを決定することができます。正確なクライアントの動作は、3GPP [TS-24.234]などのこの仕様を使用して標準体によって説明されます。
Section 2 describes the required behavior of implementations, including the format for identity hints.
セクション2では、IDのヒントの形式を含む、実装の必要な動作について説明します。
This document specifies behavior of Remote Authentication Dial-In User Service (RADIUS) proxies that handle EAP messages. This includes the specification of the behavior of proxies in response to an unknown realm within the User-Name(1) attribute of an Access-Request containing one or more EAP-Message attributes. This document, if used in a scenario requiring NAI "decoration" as specified in [RFC4282], assumes a source-routing model for determination of the roaming relationship path, and therefore affects the behavior of RADIUS proxies in roaming situations.
このドキュメントは、EAPメッセージを処理するリモート認証ダイヤルインユーザーサービス（RADIUS）プロキシの動作を指定します。これには、1つ以上のEAPメッセージ属性を含むアクセスリケストのユーザー（1）属性内の未知の領域に応答したプロキシの動作の仕様が含まれます。このドキュメントは、[RFC4282]で指定されているNAIの「装飾」を必要とするシナリオで使用されている場合、ローミング関係パスを決定するためのソースルーティングモデルを想定しているため、ローミング状況における半径プロキシの挙動に影響します。
Identity hints are useful in situations where the peer cannot determine which credentials to use, or where there may be multiple alternative routes by which an access network can reach a home network. This can occur when access networks support multiple roaming consortiums but do not have a full list of the home networks reachable through them.
アイデンティティのヒントは、ピアがどの資格情報を使用するか、またはアクセスネットワークがホームネットワークに到達できる複数の代替ルートがある可能性がある場合に、ピアが決定できない状況で役立ちます。これは、アクセスネットワークが複数のローミングコンソーシアムをサポートしている場合に発生する可能性がありますが、到達可能なホームネットワークの完全なリストはありません。
In such scenarios, identity hints (e.g., a list of roaming partners of the access network) can be provided to enable the EAP peer to influence route selection, using the NAI [RFC4282] to specify the desired source route. The immediate application of the proposed mechanism is in 3GPP systems interworking with WLANs [TS-23.234] and [TS-24.234].
このようなシナリオでは、アイデンティティのヒント（たとえば、アクセスネットワークのローミングパートナーのリスト）を提供して、EAPピアがNAI [RFC4282]を使用して目的のソースルートを指定することを可能にすることができます。提案されたメカニズムの即時の適用は、WLAN [TS-23.234]および[TS-24.234]と互換性がある3GPPシステムにあります。
The number of hints that can be provided by this mechanism is limited by the EAP MTU. For example, assuming 20 octets per hint and an EAP MTU of 1096, a maximum of 50 roaming partners can be advertised. Scaling limitations imposed by the EAP MTU should be taken into account when deploying this solution.
このメカニズムで提供できるヒントの数は、EAP MTUによって制限されます。たとえば、ヒントあたり20オクテットと1096のEAP MTUを想定すると、最大50人のローミングパートナーを宣伝できます。EAP MTUによって課されるスケーリング制限は、このソリューションを展開する際に考慮する必要があります。
Since this mechanism relies on information provided in the EAP-Request/Identity packet, it is necessary for the peer to select a point of attachment prior to obtaining identity hints. Where there are multiple points of attachment available, the mechanism defined in this specification does not allow the peer to utilize the identity hints in making a decision about which point of attachment to select. In roaming situations, this can require the peer to try multiple points of attachment before it finds a compatible one, increasing handoff latency.
このメカニズムは、EAP-Request/Identityパケットで提供される情報に依存しているため、ピアがIDのヒントを取得する前に添付ファイルのポイントを選択する必要があります。利用可能な添付ファイルの複数のポイントがある場合、この仕様で定義されているメカニズムでは、ピアが選択するための添付ファイルのポイントを決定する際のアイデンティティのヒントを利用することはできません。ローミングの状況では、これにより、互換性のあるものを見つける前に、ピアが複数の添付ポイントを試す必要があります。
This document is related to the general network discovery and selection problem described in [netsel-problem]. The proposed mechanism described in this document solves only a part of the problem in [netsel-problem]. IEEE 802.11 is also looking into more comprehensive and long-term solutions for network discovery and selection.
このドキュメントは、[Netsel-Problem]で説明されている一般的なネットワークの発見と選択の問題に関連しています。このドキュメントで説明されている提案されたメカニズムは、[Netsel-Problem]の問題の一部のみを解決します。IEEE 802.11は、ネットワークの発見と選択のためのより包括的で長期的なソリューションも検討しています。
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].
「必須」、「必須」、「必須」、「「しなければ」、「そうしない」、「そうではない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されていると解釈されます。
NAI Network Access Identifier [RFC4282].
NAIネットワークアクセス識別子[RFC4282]。
Decorated NAI An NAI specifying a source route. See [RFC4282] Section 2.7 for more information.
ソースルートを指定するnai an naiを装飾しました。詳細については、[RFC4282]セクション2.7を参照してください。
NAI Realm Realm portion of an NAI [RFC4282].
Nai [RFC4282]のNai Realm Realm部分。
The EAP authenticator MAY send an identity hint to the peer in the initial EAP-Request/Identity. If the identity hint is not sent initially (such as when the authenticator does not support this specification), then the EAP peer may select the wrong NAI. If the local AAA proxy does not have a default route configured, then it may find that the User-Name(1) attribute in the request contains a realm for which there is no corresponding route.
EAP Authenticatorは、最初のEAP-Request/Identityでピアにアイデンティティのヒントを送信する場合があります。アイデンティティのヒントが最初に送信されない場合（認証者がこの仕様をサポートしていない場合など）、EAPピアは間違ったNAIを選択できます。ローカルAAAプロキシにデフォルトのルートが構成されていない場合、リクエストのユーザー名（1）属性には、対応するルートがない領域が含まれていることがわかります。
As noted in [RFC2607], Section 5.1:
[RFC2607]に記載されているように、セクション5.1：
"Proxies are frequently used to implement policy in roaming situations. Proxies implementing policy MAY reply directly to Access-Requests without forwarding the request. When replying directly to an Access-Request, the proxy MUST reply either with an Access-Reject or an Access-Challenge packet. A proxy MUST NOT reply directly with an Access-Accept."
「プロキシは、ローミングの状況でポリシーを実装するために頻繁に使用されます。プロキシの実装ポリシーは、リクエストを転送せずにアクセスリケストに直接返信する場合があります。アクセスリケストに直接返信する場合、プロキシはアクセスrejectまたはアクセスチャレンジパケットのいずれかで返信する必要があります。
Where no route is found, existing AAA proxies will typically send an Access-Reject. However, where the request contains an EAP-Message attribute, AAA proxies implementing this specification should instead reply with a challenge including an identity hint.
ルートが見つからない場合、既存のAAAプロキシは通常、アクセス拒否を送信します。ただし、リクエストにEAPメッセージ属性が含まれている場合、この仕様を実装するAAAプロキシは、代わりにアイデンティティのヒントを含む課題で返信する必要があります。
For example, if a RADIUS proxy receives an Access-Request with an EAP-Message attribute and a User-Name(1) attribute containing an unknown realm, it SHOULD reply with an Access-Challenge with an EAP-Message attribute encapsulating an EAP-Request/Identity packet containing an identity hint, rather than an Access-Reject. See "Option 3" in the appendix for the message flow diagram.
たとえば、RADIUSプロキシがEAPメッセージ属性と未知の領域を含むユーザー名（1）の属性を持つアクセスリケストを受信する場合、アクセスのヒントではなく、アイデンティティのヒントを含むEAP-Request/Identityパケットをカプセル化するEAPメッセージの属性を持つアクセスチャレンジで返信する必要があります。メッセージフロー図については、付録の「オプション3」を参照してください。
If the peer responds with an EAP-Response/Identity containing an unknown realm after the local AAA proxy sends an identity hint, then a local AAA proxy/server implementing this specification MUST eventually send an Access-Reject containing an EAP-Failure. Prior to doing so, it MAY send an Access-Challenge containing an EAP-Notification, in order to provide an explanation for the failure. In order to determine whether an identity hint had been previously sent, the State(24) attribute defined in [RFC2865] can be used.
ピアがローカルAAAプロキシがIDのヒントを送信した後に未知の領域を含むEAP応答/アイデンティティで応答する場合、この仕様を実装するローカルAAAプロキシ/サーバーは、最終的にEAPファイルを含むアクセス除去を送信する必要があります。そうする前に、障害の説明を提供するために、EAPノーテーションを含むアクセスチャレンジを送信する場合があります。アイデンティティのヒントが以前に送信されたかどうかを判断するために、[RFC2865]で定義されている状態（24）属性を使用できます。
As noted in [RFC3748], Section 3.1, the minimum EAP MTU size is 1020 octets. EAP does not support fragmentation of EAP-Request/Identity messages, so the maximum length of the identity hint information is limited by the link MTU.
[RFC3748]、セクション3.1に記載されているように、最小EAP MTUサイズは1020オクテットです。EAPは、EAP-Request/IDメッセージの断片化をサポートしていないため、IDヒント情報の最大長はLink MTUによって制限されます。
The identity hint information is placed after the displayable string and a NUL character in the EAP-Request/Identity. The following ABNF [RFC4234] defines an NAIRealms attribute for presenting the identity hint information. The attribute's value consists of a set of realm names separated by a semicolon.
アイデンティティヒント情報は、EAP-Request/IDの表示可能な文字列とNUL文字の後に配置されます。次のABNF [RFC4234]は、IDヒント情報を提示するためのNaireAlms属性を定義しています。属性の値は、セミコロンで区切られた一連のレルム名で構成されています。
identity-request-data = [ displayable-string ] %x00 [ Network-Info ]
displayable-string = *CHAR
Network-Info = "NAIRealms=" realm-list
Network-Info =/ 1*OCTET ",NAIRealms=" realm-list
Network-Info =/ "NAIRealms=" realm-list "," 1*OCTET
Network-Info =/ 1*OCTET ",NAIRealms=" realm-list "," 1*OCTET
realm-list = realm / ( realm-list ";" realm )
Realm-list = Realm /（Realm-List ";" Realm）
The "OCTET" and "CHAR" rules are defined in [RFC4234] and the "realm" rule is defined in [RFC4282].
「Octet」および「Char」ルールは[RFC4234]で定義されており、「Realm」ルールは[RFC4282]で定義されています。
A sample hex dump of an EAP-Request/Identity packet is shown below.
EAP-Request/Identityパケットのサンプルダンプを以下に示します。
01 ; Code: Request 00 ; Identifier: 0 00 3f ; Length: 63 octets 01 ; Type: Identity 48 65 6c 6c 6f 21 00 4e ; "Hello!\0NAIRealms=example.com;mnc014. 41 49 52 65 61 6c 6d 73 ; mcc310.3gppnetwork.org" 3d 65 78 61 6d 70 6c 65 2e 63 6f 6d 3b 6d 6e 63 30 31 34 2e 6d 63 63 33 31 30 2e 33 67 70 70 6e 65 74 77 6f 72 6b 2e 6f 72 67
01;コード：リクエスト00;識別子：0 00 3F;長さ：63オクテット01;タイプ：ID 48 65 6C 6C 6F 21 00 4E;"Hello！\ 0naireAlms = Example.com;MNC014。4149 52 65 61 6C 6D 73; MCC310.3GPPNETWORK.ORG" 3D 65 78 61 6D 70 6C 65 2E 63 6F 6D 3B 6D 6E 63 30 31 6B 2E 6F 72 67
The Network-Info can contain an NAIRealms list in addition to proprietary information. The proprietary information can be placed before or after the NAIRealms list. To extract the NAIRealms list, an implementation can either find the "NAIRealms=" immediately after the NUL or seek forward to find ",NAIRealms" somewhere in the string. The realms data ends either at the first "," or at the end of the string, whichever comes first.
Network-INFOには、独自の情報に加えてNaireAlmsリストを含めることができます。独自の情報は、NaireAlmsリストの前後に配置できます。NaireAlmsリストを抽出するために、実装は「NaireAlms =」を見つけるか、NULの直後に検索しようとするか」、NaireAlms "を文字列のどこかに見つけることができます。Realmsデータは、最初の「」、または文字列の最後で終了します。
Identity hint information is delivered inside an EAP-Request/Identity before the authentication conversation begins. Therefore, it can be modified by an attacker. The NAIRealms attribute therefore MUST be treated as a hint by the peer. That is, the peer must treat the hint as an unreliable indication
アイデンティティのヒント情報は、認証会話が始まる前に、EAP-Request/Identity内で配信されます。したがって、攻撃者によって変更できます。したがって、NaireAlmsの属性は、ピアによってヒントとして扱わなければなりません。つまり、ピアはヒントを信頼できない兆候として扱わなければなりません
Unauthenticated hints may result in peers inadvertently revealing additional identities, thus compromising privacy. Since the EAP-Response/Identity is sent in the clear, this vulnerability already exists. This vulnerability can be addressed via method-specific identity exchanges.
無慈悲なヒントは、ピアが誤って追加のアイデンティティを明らかにし、プライバシーを損なう可能性があります。EAP応答/アイデンティティは明確に送信されるため、この脆弱性はすでに存在しています。この脆弱性は、メソッド固有のID交流を介して対処できます。
Similarly, in a situation where the peer has multiple identities to choose from, an attacker can use a forged hint to convince the peer to choose an identity bound to a weak EAP method. Requiring the use of strong EAP methods can protect against this. A similar issue already exists with respect to unprotected link-layer advertisements such as 802.11 SSIDs.
同様に、ピアが複数のアイデンティティから選択できる状況では、攻撃者は偽造ヒントを使用して、ピアに弱いEAPメソッドにバインドされたアイデンティティを選択するよう説得できます。強力なEAPメソッドを使用することは、これに対して保護することができます。802.11 SSIDなどの保護されていないリンク層広告に関して、同様の問題がすでに存在しています。
If the identity hint is used to select a mediating network, existing EAP methods may not provide a way for the home AAA server to verify that the mediating network selected by the peer was actually used.
IDのヒントを使用して調停ネットワークを選択する場合、既存のEAPメソッドは、ホームAAAサーバーがピアによって選択された媒介ネットワークが実際に使用されたことを確認する方法を提供しない場合があります。
Any information revealed either from the network or client sides before authentication has occurred can be seen as a security risk. For instance, revealing the existence of a network that uses a weak authentication method can make it easier for attackers to discover that such a network is accessible. Therefore, the consent of the network being advertised in the hints is required before such hints can be sent.
認証が発生する前に、ネットワークまたはクライアント側から明らかにされた情報は、セキュリティリスクと見なすことができます。たとえば、弱い認証方法を使用するネットワークの存在を明らかにすると、攻撃者がそのようなネットワークにアクセスできることを容易にすることができます。したがって、このようなヒントを送信する前に、ヒントで宣伝されているネットワークの同意が必要です。
The authors would especially like to thank Jari Arkko, Bernard Aboba, and Glen Zorn for their help in scoping the problem, and for reviewing the document in progress and suggesting improvements to it. The authors would also like to acknowledge and thank Adrian Buckley, Blair Bullock, Jose Puthenkulam, Johanna Wild, Joe Salowey, Marco Spini, Simone Ruffino, Mark Grayson, Mark Watson, and Avi Lior for their support, feedback, and guidance during the various stages of this work.
著者は特に、Jari Arkko、Bernard Aboba、およびGlen Zornに、問題のスコーピングを支援し、進行中の文書をレビューして改善を提案してくれたことに感謝したいと思います。著者はまた、この作業のさまざまな段階でのサポート、フィードバック、およびガイダンスについて、エイドリアン・バックリー、ブレア・ブロック、ホセ・パトレック、ジョー・サロウィー、ジョー・サロウィー、マルコ・スピノ、マーク・グレイソン、マーク・ワトソン、アヴィ・リオールに感謝し、感謝したいと思います。
Although the delivery options are described in the context of IEEE 802.11 access networks, they are also applicable to other access networks that use EAP [RFC3748] for authentication and use the NAI format [RFC4282] for identifying users.
配信オプションはIEEE 802.11アクセスネットワークのコンテキストで説明されていますが、認証にEAP [RFC3748]を使用する他のアクセスネットワークにも適用され、ユーザーを識別するためにNAI形式[RFC4282]を使用します。
The options assume that the AAA protocol in use is RADIUS [RFC2865]. However, Diameter [RFC3588] could also be used instead of RADIUS without introducing significant architectural differences.
オプションは、使用中のAAAプロトコルが半径[RFC2865]であると仮定します。ただし、直径[RFC3588]は、重大なアーキテクチャの違いを導入することなく、半径の代わりに使用することもできます。
The main difference amongst the options is which entity in the access network creates the EAP-Request/Identity. For example, the role of the EAP server may be played by the EAP authenticator (where an initial EAP-Request/Identity is sent with an identity hint) or a RADIUS proxy/server (where the NAIRealm is used for forwarding).
オプションの主な違いは、アクセスネットワーク内のエンティティがEAP-Request/IDを作成するかです。たとえば、EAPサーバーの役割は、EAP認証器（初期のEAP-Request/IDがIDのヒントで送信される）またはRADIUSプロキシ/サーバー（NaiReAlmが転送に使用される）によって再生される場合があります。
The RADIUS proxy/server acts only on the RADIUS User-Name(1) attribute and does not have to parse the EAP-Message attribute.
RADIUSプロキシ/サーバーは、RADIUSユーザー名（1）属性でのみ動作し、EAPメッセージ属性を解析する必要はありません。
Option 1: Initial EAP-Request/Identity from the access point
オプション1：アクセスポイントからの初期EAP-Request/ID
In typical IEEE 802.11 wireless LANs, the initial EAP-Request/ Identity is sent by the access point (i.e., EAP authenticator). In the simplest case, the identity hint information is simply included in this request, as shown below.
典型的なIEEE 802.11ワイヤレスLANSでは、最初のEAP-Request/ IDがアクセスポイント（つまり、EAP認証器）によって送信されます。最も簡単な場合、以下に示すように、IDヒント情報はこの要求に単純に含まれています。
EAP Access Point local RADIUS home RADIUS
Peer proxy/server server
| 1. EAP | | |
| Request/Identity | | |
| (NAIRealms) | | |
|<------------------| | |
| 2. EAP | | |
| Response/Identity| | |
|------------------>| | |
| | 3. Access-Request | |
| | (EAP | |
| | Response/Identity)| |
| |------------------->| |
| | | 4. Access-Request |
| | | (EAP |
| | | Response/Identity) |
| | |------------------->|
| | | |
|<-------------------EAP conversation ----------------------->|
Current access points do not support this mechanism, so other options may be preferable. This option can also require configuring the identity hint information in a potentially large number of access points, which may be problematic if the information changes often.
現在のアクセスポイントはこのメカニズムをサポートしていないため、他のオプションが望ましい場合があります。このオプションは、潜在的に多数のアクセスポイントにIDヒント情報を構成する必要があります。これは、情報が頻繁に変更された場合に問題がある場合があります。
Option 2: Initial EAP-Request/Identity from the local RADIUS proxy/ server
オプション2：ローカルRADIUSプロキシ/サーバーからの初期EAP-Request/ ID
This is similar to Option 1, but the initial EAP-Request/Identity is created by the local RADIUS proxy/server instead of the access point. Once a peer associates with an access network AP using IEEE 802.11 procedures, the AP sends an EAP-Start message [RFC3579] within a RADIUS Access-Request. The access network RADIUS server can then send the EAP-Request/Identity containing the identity hint information.
これはオプション1に似ていますが、最初のEAP-Request/IDは、アクセスポイントの代わりにローカルRADIUSプロキシ/サーバーによって作成されます。ピアがIEEE 802.11手順を使用してアクセスネットワークAPに関連すると、APはRADIUS Access-Request内でEAP-STARTメッセージ[RFC3579]を送信します。アクセスネットワークRADIUSサーバーは、IDヒント情報を含むEAP-Request/IDを送信できます。
EAP Access Point local RADIUS home RADIUS
Peer proxy/server server
| | 1. Access-Request | |
| | (EAP-Start) | |
| |------------------->| |
| | 2. Access-Challenge| |
| | (EAP | |
| | Request/Identity | |
| | with NAIRealms) | |
| |<-------------------| |
| 3. EAP | | |
| Request/Identity | | |
| (NAIRealms) | | |
|<------------------| | |
| 4. EAP | | |
| Response/Identity | | |
|------------------>| | |
| | 5. Access-Request | |
| | (EAP | |
| | Response/Identity) | |
| |------------------->| |
| | | 6. Access-Request |
| | | (EAP |
| | | Response/Identity) |
| | |------------------->|
| | | |
|<------------------- EAP conversation ---------------------->|
This option can work with current access points if they support the EAP-Start message.
このオプションは、EAP-STARTメッセージをサポートする場合、現在のアクセスポイントで動作できます。
Option 3: Subsequent EAP-Request/Identity from local RADIUS proxy/ server
オプション3：ローカルRADIUSプロキシ/サーバーからの後続のEAP-Request/ ID
In the third option, the access point sends the initial EAP-Request/ Identity without any hint information. The peer then responds with an EAP-Response/Identity, which is forwarded to the local RADIUS proxy/server. If the RADIUS proxy/server cannot route the message based on the identity provided by the peer, it sends a second EAP-Request/Identity containing the identity hint information.
3番目のオプションでは、アクセスポイントがヒント情報なしで最初のEAP-Request/ IDを送信します。次に、ピアはEAP応答/アイデンティティで応答し、ローカルRadiusプロキシ/サーバーに転送されます。RADIUSプロキシ/サーバーがピアから提供されたIDに基づいてメッセージをルーティングできない場合、IDヒント情報を含む2番目のEAP-Request/IDを送信します。
EAP Access Point local RADIUS home RADIUS
Peer proxy/server server
| | | |
| 1. EAP | | |
| Request/Identity | | |
| (w/o NAIRealms) | | |
|<------------------| | |
| 2. EAP | | |
| Response/Identity | | |
|------------------>| | |
| | 3. Access-Request | |
| | (EAP | |
| | Response/Identity) | |
| |------------------->| |
| | 4. Access-Challenge| |
| | (EAP | |
| | Request/Identity | |
| | with NAIRealms) | |
| |<-------------------| |
| 5. EAP | | |
| Request/Identity | | |
| (NAIRealms) | | |
|<------------------| | |
| 6. EAP | | |
| Response/Identity | | |
|------------------>| | |
| | 7. Access-Request | |
| | (EAP | |
| | Response/Identity) | |
| |------------------->| |
| | | |
======================Failure due to unknown realm=============
| | | |
| | 7a. Access-Reject | |
| | (EAP-Failure) | |
| |<-------------------| |
| 7b. EAP | | |
| Failure | | |
|<------------------| | |
================================================================
| | | |
| | | 8. Access-Request |
| | | (EAP |
| | | Response/Identity) |
| | |------------------->|
| | | |
|<-------------------- EAP conversation --------------------->|
This option does not require changes to existing NASes, so it may be preferable in many environments.
このオプションでは、既存のnaseの変更は必要ないため、多くの環境で望ましい場合があります。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「ネットワークアクセス識別子」、RFC 4282、2005年12月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[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月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607] Aboba、B。およびJ. Vollbrecht、「ローミングにおけるプロキシチェーンと政策の実施」、RFC 2607、1999年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（リモート認証ダイヤルインユーザーサービス）拡張可能な認証プロトコル（EAP）のサポート」、RFC 3579、2003年9月。
[netsel-problem] Arkko, J. and B. Aboba, "Network Discovery and Selection Problem", Work in Progress, October 2005.
[Netsel-Problem] Arkko、J。およびB. Aboba、「ネットワークの発見と選択の問題」、2005年10月の作業。
[TS-23.234] 3GPP TS 23.234 V6.6.0, "3GPP System to Wireless Local Area Network (WLAN) interworking; System description (Release 6)", September 2005.
[TS-23.234] 3GPP TS 23.234 V6.6.0、「3GPPシステムからワイヤレスローカルエリアネットワーク（WLAN）インターワーキング、システム説明（リリース6）」、2005年9月。
[TS-24.234] 3GPP TS 24.234 V6.4.0, "3GPP System to Wireless Local Area Network (WLAN) interworking; User Equipment (UE) to network protocols; Stage 3 (Release 6)", September 2005.
[TS-24.234] 3GPP TS 24.234 V6.4.0、「3GPPシステムからワイヤレスローカルエリアネットワーク（WLAN）インターワーキング、ユーザー機器（UE）からネットワークプロトコル、ステージ3（リリース6）」、2005年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
Authors' Addresses
著者のアドレス
Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA
ファリッド・アドラギ・インテル・コーポレーション2111 N.E.25th Avenue Hillsboro、または97124 USA
Phone: +1 503-712-1791
EMail: farid.adrangi@intel.com
Victor Lortz Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA
Victor Lortz Intel Corporation 2111 N.E.25th Avenue Hillsboro、または97124 USA
Phone: +1 503-264-3253
EMail: victor.lortz@intel.com
Farooq Bari Cingular Wireless 7277 164th Avenue N.E. Redmond, WA 98052 USA
Farooq Bari Cingular Wireless 7277 164th Avenue N.E.ワシントン州レドモンド98052 USA
Phone: +1 425-580-5526
EMail: farooq.bari@cingular.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen Nokia Research Center P.O.Box 407 Fin-00045 Nokia Group Finland
EMail: pasi.eronen@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用、またはそのような権利に基づくライセンスに基づくライセンスが利用可能である可能性がある範囲に関連すると主張される可能性のある他の権利の範囲に関してはありません。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.ietf.org/IPRでIETFオンラインIPRリポジトリから取得できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。