RFC4284 日本語訳
4284 Identity Selection Hints for the Extensible AuthenticationProtocol (EAP). F. Adrangi, V. Lortz, F. Bari, P. Eronen. January 2006. (Format: TXT=30322 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Adrangi
Request for Comments: 4284 V. Lortz
Category: Informational Intel
F. Bari
Cingular Wireless
P. Eronen
Nokia
January 2006
Adrangiがコメントのために要求するワーキンググループF.をネットワークでつないでください: 4284年のV.ロルツカテゴリ: 情報のワイヤレスのインテルのCingular P.EronenノキアF.バリ2006年1月
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)インターネット協会(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 Identity Selectionは3GPPによって開発されました。 情報としてドキュメンテーションをインターネットコミュニティに提供します。 EAP WGは、この仕様がRFC3748で定義されるようにEAPと互換性があることを確かめました。 必要な3GPPクライアントの振舞いは3GPP TS24.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)はRFC3748で定義されます。 このドキュメントはアクセスネットワークがアイデンティティ選択ヒントをEAP同輩に提供できるメカニズムを定義します--固有識別文字に応じるリンクの端。 目的は適切なNetwork Access Identifier(NAI)を選択するのにEAP同輩を助けることです。 これは同輩がどんなネットワークに接続しているか、そして、またはいつ、アクセスネットワークと同輩のホームネットワークとのどんなダイレクトローミング関係もないか下層しるしを受けないところで状況で役に立ちます。 後者の場合では、認証はローミング共同体かブローカーなどの仲介ネットワークを通して通常実行されます。
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.
本書では定義されたメカニズムはスケーラビリティが制限されます。 それはaをダイレクトローミングパートナーの数を加減するために小さくするアクセスネットワークのために意図します。
Adrangi, et al. Informational [Page 1] RFC 4284 Identity Selection Hints for EAP January 2006
Adrangi、他 情報[1ページ]のRFC4284アイデンティティ選択は2006年1月にEAPのために暗示します。
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
1. 序論…2 1.1. 他の仕様との関係…3 1.2. 適用性…3 1.3. 用語…4 2. 実装要件…4 2.1. パケット形式…5 3. セキュリティ問題…6 4. 承認…7 5. 付録--配送オプション…8 6. 参照…12 6.1. 標準の参照…12 6.2. 有益な参照…12
1. Introduction
1. 序論
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-応答/アイデンティティにどのNetwork Access Identifier(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-要求/アイデンティティメッセージの同輩にこの情報を送ります。
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.
このメカニズムは資格証明の、そして、関連しているNAIを選択するか、またはAuthenticationのルーティング、Authorizationを容易にするために、NAI[RFC4282]をフォーマットすることにおける同輩とホームAAAサーバへのAccounting(AAA)メッセージを補助するかもしれません。利用可能ないくつかの仲介ネットワークがあれば、同輩は使用されたものに影響を及ぼすことができます。
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].
選択が同輩によってちょうどどうされるかは主に同輩のローカルの方針と構成に依存して、このドキュメントの範囲の外にあります。 例えば、同輩は、他のアイデンティティの1つを使用すると決めるか、別のアクセスネットワークに切り替わると決めるか、または適切なAAAルーティングを助けるために、NAI[RFC4282]を再フォーマットに試みることができました。 正確なクライアントの振舞いは、標準のボディーによって3GPP[TS-24.234]などのこの仕様を使用することで説明されます。
Section 2 describes the required behavior of implementations, including the format for identity hints.
セクション2はアイデンティティヒントのための形式を含む実装の必要な振舞いについて説明します。
Adrangi, et al. Informational [Page 2] RFC 4284 Identity Selection Hints for EAP January 2006
Adrangi、他 情報[2ページ]のRFC4284アイデンティティ選択は2006年1月にEAPのために暗示します。
1.1. Relationship with Other Specifications
1.1. 他の仕様との関係
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メッセージを扱う中のRemote Authentication Dial User Service(RADIUS)プロキシの振舞いを指定します。 これは1つ以上のEAP-メッセージ属性を含むAccess-要求のUser名前(1)属性の中の未知の分野に対応してプロキシの振舞いの仕様を含んでいます。 [RFC4282]の指定されるとしてのNAI「デコレーション」を必要としながらシナリオで使用されるなら、このドキュメントは、ローミング関係経路の決断のためにソースルーティングモデルに就いて、したがって、ローミング状況でRADIUSプロキシの振舞いに影響します。
1.2. Applicability
1.2. 適用性
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]を使用して。 提案されたメカニズムの即座の利用が、WLANsと共に[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によって制限されます。 例えば、1ヒントあたり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-要求/アイデンティティパケットに提供された情報を当てにするので、アイデンティティを得る接着点前に同輩がヒントを選択するのが必要です。 利用可能な複数のポイントの付属があるところでは、この仕様に基づき定義されたメカニズムで、同輩はどの接着点を選択したらよいかに関して決定する際にアイデンティティヒントを利用できません。 ローミング状況で、コンパチブルものを見つける前にこれは、同輩が複数のポイントの付属を試みるのを必要とすることができます、移管潜在を増強して。
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
このドキュメントは[netsel-問題]で説明された一般的なネットワーク発見と選択問題に関連します。 本書では説明された提案されたメカニズムは[netsel-問題]における問題の一部だけを解決します。 また、IEEE802.11は以上を調べています。
Adrangi, et al. Informational [Page 3] RFC 4284 Identity Selection Hints for EAP January 2006
Adrangi、他 情報[3ページ]のRFC4284アイデンティティ選択は2006年1月にEAPのために暗示します。
comprehensive and long-term solutions for network discovery and selection.
ネットワーク発見と選択のための包括的で長期のソリューション。
1.3. Terminology
1.3. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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部分。
2. Implementation Requirements
2. 実装要件
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固有識別文字は初期のEAP-要求/アイデンティティでアイデンティティヒントを同輩に送るかもしれません。 アイデンティティヒントが初めは(固有識別文字がこの仕様をサポートしない時としてのそのようなもの)送られないなら、EAP同輩は間違ったNAIを選択するかもしれません。 地元のAAAプロキシがデフォルトルートを構成させないなら、それは、要求におけるUser名前(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."
「プロキシは状況に移動する際に政策を実施するのに頻繁に使用されます。」 要求を転送しないで、政策を実施するプロキシは直接Access-要求に答えるかもしれません。 直接Access-要求に答えるとき、プロキシはAccess-廃棄物かAccess-挑戦パケットで返答しなければなりません。 「プロキシが直接返答してはいけない、Access受け入れてください、」
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プロキシはAccess-廃棄物を通常送るでしょう。 しかしながら、要求が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-メッセージ属性でAccess-要求を受け取ります、そして、aは、未知の分野を含むと(1) 属性をUser命名します、そして、それはEAP-メッセージ属性があるAccess-挑戦がEAP-要求/アイデンティティをカプセル化しているAccess-廃棄物よりむしろアイデンティティヒントを含むSHOULD回答パケットです。 「メッセージフローチャートのための付録のオプション3インチ」を見てください。
Adrangi, et al. Informational [Page 4] RFC 4284 Identity Selection Hints for EAP January 2006
Adrangi、他 情報[4ページ]のRFC4284アイデンティティ選択は2006年1月にEAPのために暗示します。
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プロキシがアイデンティティヒントを送った後にEAP-応答/アイデンティティが未知の分野を含んでいて同輩が応じるなら、この仕様を履行するローカルのAAAプロキシ/サーバは結局、EAP-失敗を含むAccess-廃棄物を送らなければなりません。 そうする前に、EAP-通知を含むAccess-挑戦を送るかもしれません、失敗のための説明を提供するために。 以前にアイデンティティヒントを送ったかどうか決定するために、[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-要求/アイデンティティメッセージの断片化をサポートしないので、アイデンティティヒント情報の最大の長さはリンクMTUによって制限されます。
2.1. Packet Format
2.1. パケット・フォーマット
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.
アイデンティティヒント情報は「ディスプレイ-可能」ストリングとNULキャラクタの後にEAP-要求/アイデンティティに置かれます。 以下のABNF[RFC4234]は、アイデンティティヒント情報を提示するためにNAIRealms属性を定義します。 属性の値はセミコロンによって切り離された1セットの分野名から成ります。
identity-request-data = [ displayable-string ] %x00 [ Network-Info ]
[「ディスプレイ-可能」ストリング]のアイデンティティ要求データ=%x00[ネットワークインフォメーション]
displayable-string = *CHAR
「ディスプレイ-可能」-ストリング=*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
」 「ネットワークインフォメーション=「NAIRealmsは」 分野リストNetwork-インフォメーション=/1*OCTETと等しい」NAIRealms=」 分野リストNetwork-インフォメーション=/「NAIRealms=」は分野で記載します」、1*八重奏ネットワークインフォメーション=/1*八重奏、」、NAIRealmsが」 分野リストと等しい、」、」 1*八重奏
realm-list = realm /
( realm-list ";" realm )
分野リスト=分野/「(分野リスト、」、;、」、分野)
The "OCTET" and "CHAR" rules are defined in [RFC4234] and the "realm" rule is defined in [RFC4282].
「八重奏」と「炭」規則は[RFC4234]で定義されます、そして、「分野」規則は[RFC4282]で定義されます。
Adrangi, et al. Informational [Page 5] RFC 4284 Identity Selection Hints for EAP January 2006
Adrangi、他 情報[5ページ]のRFC4284アイデンティティ選択は2006年1月にEAPのために暗示します。
A sample hex dump of an EAP-Request/Identity packet is shown below.
EAP-要求/アイデンティティパケットのサンプル十六進法ダンプは以下に示されます。
01 ; Code: Request 00 ; Identifier: 0 00 3f ; Length: 63 octets 01 ; Type: Identity 48 65 6c 6c 6f 21 00 4e ; "Hello!%%BODY%%NAIRealms=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。 以下をタイプしてください。 アイデンティティ48 65 6c 6c 6f21 00 4e。 「こんにちは、%%BODY%%NAIRealms=example.com; mnc014。」 41 49 52 65 61 6c 6d73。 "mcc310.3gppnetwork.org"3d65 78 61 6d70 6c65 2e63 6f 6d 3b 6d 6e63 30 31 34 2e 6d63 63 33 31 30 2e33 67 70 70 6e65 74 77 6f72 6b 2e 6f72 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-インフォメーションは知的財産情報に加えてNAIRealmsリストを含むことができます。 NAIRealmsリストの前または後に知的財産情報を置くことができます。 「NAIRealmsリストを抜粋するために、実装は、NUL直後「NAIRealms=」を見つけるか、または見つけるフォワードを探すことができます」、NAIRealms。」 ストリングのどこか。 「分野データは1番目で終わる」、」 ストリングの端で。(ストリングは一番になります)。
3. Security Considerations
3. セキュリティ問題
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-要求/アイデンティティで提供されます。 したがって、攻撃者はそれを変更できます。 したがって、同輩は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.
Unauthenticatedヒントはうっかり追加アイデンティティを明らかにする、その結果、プライバシーに感染する同輩をもたらすかもしれません。 明確でEAP-応答/アイデンティティを送るので、この脆弱性は既に存在しています。 メソッド特有のアイデンティティ交換でこの脆弱性を扱うことができます。
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.11SSIDsなどの保護のないリンクレイヤ広告に関して既に存在しています。
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.
アイデンティティヒントが仲介ネットワークを選択するのに使用されるなら、既存のEAPメソッドはホームAAAサーバが、同輩によって選択された仲介ネットワークが実際に使用されたことを確かめる方法を提供しないかもしれません。
Adrangi, et al. Informational [Page 6] RFC 4284 Identity Selection Hints for EAP January 2006
Adrangi、他 情報[6ページ]のRFC4284アイデンティティ選択は2006年1月にEAPのために暗示します。
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.
認証が起こる前にネットワークかクライアント側から明らかにされたどんな情報もセキュリティリスクと考えることができます。 例えば、弱い認証方法を使用するネットワークの存在を明らかにするのに、攻撃者が、そのようなネットワークがアクセスしやすいと発見するのが、より簡単になる場合があります。 したがって、そのようなヒントを送ることができる前にヒントの広告に掲載されているネットワークの同意を必要とします。
4. Acknowledgements
4. 承認
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.
作者は、問題を見ることにおける彼らの助けと、進行中のドキュメントを再検討して、それへの改良を示して頂いて、ヤリArkko、バーナードAboba、およびGlenゾルンに特に感謝したがっています。 この仕事の様々なステージの間、彼らのサポート、フィードバック、および指導についてエードリアン・バックリー、ブレアBullock、ホセPuthenkulam、ヨハンナWild、ジョーSalowey、マルコSpini、シモンRuffino、マーク・グレーソン、マーク・ワトソン、およびアヴィLiorに承認して、また、作者は感謝したがっています。
Adrangi, et al. Informational [Page 7] RFC 4284 Identity Selection Hints for EAP January 2006
Adrangi、他 情報[7ページ]のRFC4284アイデンティティ選択は2006年1月にEAPのために暗示します。
5. Appendix - Delivery Options
5. 付録--配送オプション
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.
配送オプションはアクセスがネットワークでつなぐIEEE802.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プロトコルがRADIUS[RFC2865]であると仮定します。 しかしながら、また、重要な建築違いを導入することのないRADIUSの代わりにDiameter[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-要求/アイデンティティを作成するかということです。 例えば、EAP固有識別文字(初期のEAP-要求/アイデンティティがアイデンティティヒントと共に送られるところ)かRADIUSプロキシ/サーバ(NAIRealmが推進に使用されるところ)によってEAPサーバの役割は果たされるかもしれません。
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 User名前(1)属性だけに影響して、EAP-メッセージ属性を分析する必要はありません。
Adrangi, et al. Informational [Page 8] RFC 4284 Identity Selection Hints for EAP January 2006
Adrangi、他 情報[8ページ]のRFC4284アイデンティティ選択は2006年1月にEAPのために暗示します。
Option 1: Initial EAP-Request/Identity from the access point
オプション1: アクセスポイントからの初期のEAP-要求/アイデンティティ
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の無線LANであり、アクセスポイント(すなわち、EAP固有識別文字)で初期のEAP-要求/アイデンティティを送ります。 最も簡単な場合では、アイデンティティヒント情報は以下に示されるようにこの要求に単に含まれています。
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 ----------------------->|
EAP Access PointのローカルのRADIUSホームRADIUS Peerプロキシ/サーバサーバ| 1. EAP| | | | 要求/アイデンティティ| | | | (NAIRealms) | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 2. EAP| | | | 応答/アイデンティティ| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 3. アクセス要求| | | | (EAP| | | | 応答/アイデンティティ)| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 4. アクセス要求| | | | (EAP| | | | 応答/アイデンティティ) | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--EAPの会話----------------------->|
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.
現在のアクセスポイントがこのメカニズムをサポートしないので、別の選択肢は望ましいかもしれません。 また、このオプションは、潜在的に多くのアクセスポイントでアイデンティティヒント情報を構成するのを必要とすることができます。(情報がしばしば変化するなら、アクセスポイントは問題が多いかもしれません)。
Option 2: Initial EAP-Request/Identity from the local RADIUS proxy/ server
オプション2: ローカルのRADIUSプロキシ/サーバからの初期のEAP-要求/アイデンティティ
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.
これはOption1と同様ですが、初期のEAP-要求/アイデンティティはアクセスポイントの代わりにローカルのRADIUSプロキシ/サーバによって作成されます。 同輩がいったんIEEEを使用するアクセスネットワークAPに802.11の手順を関連づけると、APはRADIUS Access-要求の中でEAP-開始メッセージ[RFC3579]を送ります。 そして、アクセスネットワークRADIUSサーバはアイデンティティヒント情報を含むEAP-要求/アイデンティティを送ることができます。
Adrangi, et al. Informational [Page 9] RFC 4284 Identity Selection Hints for EAP January 2006
Adrangi、他 情報[9ページ]のRFC4284アイデンティティ選択は2006年1月にEAPのために暗示します。
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 ---------------------->|
EAP Access PointのローカルのRADIUSホームRADIUS Peerプロキシ/サーバサーバ| | 1. アクセス要求| | | | (EAP-始め) | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 2. アクセス挑戦| | | | (EAP| | | | 要求/アイデンティティ|、|、|、|、NAIRealms) | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 3. EAP| | | | 要求/アイデンティティ| | | | (NAIRealms) | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 4. EAP| | | | 応答/アイデンティティ| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 5. アクセス要求| | | | (EAP| | | | 応答/アイデンティティ) | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 6. アクセス要求| | | | (EAP| | | | 応答/アイデンティティ) | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- EAPの会話---------------------->|
This option can work with current access points if they support the EAP-Start message.
EAP-開始メッセージをサポートするなら、このオプションは現在のアクセスポイントで働くことができます。
Option 3: Subsequent EAP-Request/Identity from local RADIUS proxy/ server
オプション3: ローカルのRADIUSプロキシ/サーバからのその後のEAP-要求/アイデンティティ
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-要求/アイデンティティを送ります。 次に、同輩はEAP-応答/アイデンティティで応じます。(それは、ローカルのRADIUSプロキシ/サーバに送られます)。RADIUSプロキシ/サーバが同輩によって提供されたアイデンティティに基づくメッセージを発送できないなら、それはアイデンティティヒント情報を含む第2EAP-要求/アイデンティティを送ります。
Adrangi, et al. Informational [Page 10] RFC 4284 Identity Selection Hints for EAP January 2006
Adrangi、他 情報[10ページ]のRFC4284アイデンティティ選択は2006年1月にEAPのために暗示します。
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 --------------------->|
EAP Access PointのローカルのRADIUS家のRADIUS Peerプロキシ/サーバサーバ| | | | | 1. EAP| | | | 要求/アイデンティティ| | | | (NAIRealmsのない) | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 2. EAP| | | | 応答/アイデンティティ| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 3. アクセス要求| | | | (EAP| | | | 応答/アイデンティティ) | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 4. アクセス挑戦| | | | (EAP| | | | 要求/アイデンティティ|、|、|、|、NAIRealms) | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 5. EAP| | | | 要求/アイデンティティ| | | | (NAIRealms) | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 6. EAP| | | | 応答/アイデンティティ| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 7. アクセス要求| | | | (EAP| | | | 応答/アイデンティティ) | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| ======================未知の分野による失敗============= | | | | | | 7a。 アクセス廃棄物| | | | (EAP-失敗) | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 7b。 EAP| | | | 失敗| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| ================================================================ | | | | | | | 8. アクセス要求| | | | (EAP| | | | 応答/アイデンティティ) | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- EAPの会話--------------------->|
Adrangi, et al. Informational [Page 11] RFC 4284 Identity Selection Hints for EAP January 2006
Adrangi、他 情報[11ページ]のRFC4284アイデンティティ選択は2006年1月にEAPのために暗示します。
This option does not require changes to existing NASes, so it may be preferable in many environments.
このオプションが既存のNASesへの変化を必要としないので、それは多くの環境で望ましいかもしれません。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen,
"The Network Access Identifier", RFC 4282, December
2005.
2005年12月の[RFC4282]AbobaとB.と用務員とM.とArkko、J.とP.Eronen、「ネットワークアクセス識別子」RFC4282。
[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.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October
2005.
[RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and
Policy Implementation in Roaming", RFC 2607, June
1999.
[RFC2607] Aboba、B.、J.Vollbrecht、および「ローミングにおけるプロキシ推論と政策の実施」、RFC2607、6月1999日
6.2. Informative References
6.2. 有益な参照
[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.カルフーン、「拡張認証プロトコル(EAP)の半径(ユーザサービスにおけるリモート認証ダイヤル)サポート」RFC3579(2003年9月)。
[netsel-problem] Arkko, J. and B. Aboba, "Network Discovery and
Selection Problem", Work in Progress, October 2005.
「ネットワーク発見と選択問題」という[netsel-問題]の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 TS23.234V6.6.0、「Wirelessローカル・エリア・ネットワーク(WLAN)の織り込むことへの3GPP System」。 2005年9月の「システム記述(リリース6)。」
[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 TS24.234V6.4.0、「Wirelessローカル・エリア・ネットワーク(WLAN)の織り込むことへの3GPP System」。 ネットワーク・プロトコルへのユーザEquipment(UE)。 2005年9月の「ステージ3(リリース6)。」
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G.,
and J. Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[RFC3588] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
Adrangi, et al. Informational [Page 12] RFC 4284 Identity Selection Hints for EAP January 2006
Adrangi、他 情報[12ページ]のRFC4284アイデンティティ選択は2006年1月にEAPのために暗示します。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
Authors' Addresses
作者のアドレス
Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA
ファリドAdrangiインテル社2111Avenueヒースボロー、または25番目の97124の東北米国
Phone: +1 503-712-1791 EMail: farid.adrangi@intel.com
以下に電話をしてください。 +1 503-712-1791 メールしてください: farid.adrangi@intel.com
Victor Lortz Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA
ビクタロルツインテル社2111Avenueヒースボロー、または25番目の97124の東北米国
Phone: +1 503-264-3253 EMail: victor.lortz@intel.com
以下に電話をしてください。 +1 503-264-3253 メールしてください: victor.lortz@intel.com
Farooq Bari Cingular Wireless 7277 164th Avenue N.E. Redmond, WA 98052 USA
第164ファルークバリCingular Wireless7277アベニュー東北ワシントン98052レッドモンド(米国)
Phone: +1 425-580-5526 EMail: farooq.bari@cingular.com
以下に電話をしてください。 +1 425-580-5526 メールしてください: farooq.bari@cingular.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
パシEronenノキアリサーチセンター私書箱407フィン-00045Nokia Groupフィンランド
EMail: pasi.eronen@nokia.com
メール: pasi.eronen@nokia.com
Adrangi, et al. Informational [Page 13] RFC 4284 Identity Selection Hints for EAP January 2006
Adrangi、他 情報[13ページ]のRFC4284アイデンティティ選択は2006年1月にEAPのために暗示します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Adrangi, et al. Informational [Page 14]
Adrangi、他 情報[14ページ]
一覧
スポンサーリンク
