Network Working Group H. Tschofenig, Ed.
Request for Comments: 5580 Nokia Siemens Networks
Category: Standards Track F. Adrangi
Intel
M. Jones
A. Lior
Bridgewater
B. Aboba
Microsoft Corporation
August 2009
Carrying Location Objects in RADIUS and Diameter
Abstract
抽象
This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service (RADIUS) and Diameter.
この文書では、リモート認証ダイヤルインユーザーサービス（RADIUS）、直径が市民と地理空間位置フォーマットに基づいて、アクセスネットワークの所有権及び位置情報を伝達するための手順を記載しています。
The distribution of location information is a privacy-sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed in this document.
位置情報の分布がプライバシーに敏感なタスクです。ユーザーのプライバシーを保護するためのメカニズムに対処することが重要であり、この文書で扱われています。
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Delivery Methods for Location Information .......................3
3.1. Location Delivery Based on Out-of-Band Agreements ..........4
3.2. Location Delivery Based on Initial Request .................5
3.3. Location Delivery Based on Mid-Session Request .............6
3.4. Location Delivery in Accounting Messages ..................10
4. Attributes .....................................................11
4.1. Operator-Name Attribute ...................................12
4.2. Location-Information Attribute ............................14
4.3. Location-Data Attribute ...................................16
4.3.1. Civic Location Profile .............................17
4.3.2. Geospatial Location Profile ........................17
4.4. Basic-Location-Policy-Rules Attribute .....................18
4.5. Extended-Location-Policy-Rules Attribute ..................20
4.6. Location-Capable Attribute ................................21
4.7. Requested-Location-Info Attribute .........................23
5. Table of Attributes ............................................28
6. Diameter RADIUS Interoperability ...............................30
7. Security Considerations ........................................31
7.1. Communication Security ....................................31
7.2. Privacy Considerations ....................................32
7.2.1. RADIUS Client ......................................33
7.2.2. RADIUS Server ......................................34
7.2.3. RADIUS Proxy .......................................34
7.3. Identity Information and Location Information .............34
8. IANA Considerations ............................................36
8.1. New Registry: Operator Namespace Identifier ...............36
8.2. New Registry: Location Profiles ...........................37
8.3. New Registry: Location-Capable Attribute ..................38
8.4. New Registry: Entity Types ................................39
8.5. New Registry: Privacy Flags ...............................39
8.6. New Registry: Requested-Location-Info Attribute ...........39
9. Acknowledgments ................................................40
10. References ....................................................42
10.1. Normative References .....................................42
10.2. Informative References ...................................42
Appendix A. Matching with GEOPRIV Requirements ...................45
A.1. Distribution of Location Information at the User's
Home Network ..............................................45
A.2. Distribution of Location Information at the Visited
Network ...................................................46
A.3. Requirements Matching .....................................47
This document defines attributes within RADIUS and Diameter that can be used to convey location-related information within authentication and accounting exchanges.
この文書は、認証およびアカウンティング交流内の位置関連情報を伝達するために使用することができるRADIUSと径内の属性を定義します。
Location information may be useful in a number of scenarios. Wireless networks (including wireless LAN) are being deployed in public places such as airports, hotels, shopping malls, and coffee shops by a diverse set of operators such as cellular network operators, Wireless Internet Service Providers (WISPs), and fixed broadband operators. In these situations, the home network may need to know the location of the user in order to enable location-aware billing, location-aware authorization, or other location-aware services. Location information can also prove useful in other situations (such as wired networks) where operator-network ownership and location information may be needed by the home network.
位置情報は、多くのシナリオにおいて有用であり得ます。 （無線LANを含む）無線ネットワークは、セルラーネットワークオペレータ、ワイヤレスインターネットサービスプロバイダ（切れ間）、および固定ブロードバンド事業者として事業者の多様なセットで、空港、ホテル、ショッピングモール、コーヒーショップなどの公共の場所で展開されています。このような状況では、ホーム・ネットワークは、位置認識課金、位置認識の承認、または他の位置認識サービスを可能にするために、ユーザの位置を知る必要があるかもしれません。位置情報は、オペレータネットワークの所有権及び位置情報がホームネットワークによって必要とされるかもしれない（例えば、有線ネットワークのような）他の状況で有用であることを証明することができます。
In order to preserve user privacy, location information needs to be protected against unauthorized access and distribution. Requirements for access to location information are defined in [RFC3693]. The model includes a Location Generator (LG) that creates location information, a Location Server (LS) that authorizes access to location information, a Location Recipient (LR) that requests and receives information, and a Rule Maker (RM) that provides authorization policies to the LS, which enforces access-control policies on requests to location information. In Appendix A, the requirements for a GEOPRIV using protocol [RFC3693] are compared to the functionality provided by this document.
ユーザーのプライバシーを維持するために、位置情報は、不正アクセスや配布から保護する必要があります。位置情報へのアクセスのための要件は[RFC3693]で定義されています。モデルは、位置情報、位置情報へのアクセスを許可ロケーションサーバ（LS）、所在地の受信者（LR）の要求を作成し、情報を受け取る場所ジェネレーター（LG）、および認可ポリシーを提供し、ルールメーカー（RM）を含み位置情報への要求にアクセス制御ポリシーを適用LSへ。付録Aに、プロトコル[RFC3693]を使用GEOPRIVための要件は、この文書によって提供される機能と比較されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
RADIUS-specific terminology is borrowed from [RFC2865] and [RFC2866].
RADIUS固有の用語は[RFC2865]及び[RFC2866]から借用されます。
Terminology related to privacy issues, location information, and authorization policy rules is taken from [RFC3693].
プライバシーの問題、位置情報、および許可ポリシールールに関連する用語は[RFC3693]から取られます。
The following exchanges show how location information is conveyed in RADIUS. In describing the usage scenarios, we assume that privacy policies allow location to be conveyed in RADIUS; however, as noted in Section 6, similar exchanges can also take place within Diameter. Privacy issues are discussed in Section 7.2.
次の交換は、位置情報がRADIUSで搬送される様子を示しています。使用シナリオを記述する際に、我々は、プライバシーポリシーは場所がRADIUSで搬送することを可能にすることを前提としています。第6節で述べたようしかし、同様の交換はまた、直径内で行うことができます。プライバシーの問題は、セクション7.2で説明されています。
Figure 1 shows an example message flow for delivering location information during the network-access authentication and authorization procedure. Upon a network-authentication request from an access-network client, the Network Access Server (NAS) submits a RADIUS Access-Request message that contains Location-Information Attributes among other required attributes. In this scenario, location information is attached to the Access-Request message without an explicit request from the RADIUS server. Note that such an approach with a prior agreement between the RADIUS client and the RADIUS server is only applicable in certain environments, such as in situations where the RADIUS client and server are within the same administrative domain. The Basic-Location-Policy-Rules Attribute is populated based on the defaults described in Section 4.4, unless it has been explicitly configured otherwise.
図1は、ネットワークアクセス認証および許可手順の間に位置情報を配信するための例示的なメッセージフローを示します。アクセス・ネットワーククライアントからネットワーク認証要求に応じて、ネットワークアクセスサーバ（NAS）は、位置情報が含まれている他の必要な属性の間で属性のRADIUS Access-Requestメッセージを送信します。このシナリオでは、位置情報は、RADIUSサーバからの明示的な要求なしでAccess-Requestメッセージに取り付けられています。 RADIUSクライアントとRADIUSサーバ間の事前の合意と、このようなアプローチは、このようなRADIUSクライアントとサーバが同じ管理ドメイン内にある状況のように、特定の環境でのみ適用可能であることに注意してください。それが明示的に設定されていない限り、基本-場所-ポリシールールの属性は、セクション4.4で説明したデフォルト値に基づいて設定されます。
+---------+ +---------+ +---------+
| | | Network | | RADIUS |
| User | | Access | | Server |
| | | Server | | |
+---------+ +---------+ +---------+
| | |
| Authentication phase | |
| begin | |
|---------------------->| |
| | |
| | Access-Request |
| | + Location-Information |
| | + Location-Data |
| | + Basic-Location-Policy-Rules|
| | + Operator-Name |
| |----------------------------->|
| | |
| | Access-Accept |
| |<-----------------------------|
| Authentication | |
| Success | |
|<----------------------| |
| | |
Figure 1: Location Delivery Based on Out-of-Band Agreements
図1：アウトオブバンド協定に基づいて、場所配達
If the RADIUS client provides a Location-Capable Attribute in the Access-Request, then the RADIUS server MAY request location information from the RADIUS client if it requires that information for authorization and if location information was not provided in the Access-Request. This exchange is shown in Figure 2. The inclusion of the Location-Capable Attribute in an Access-Request message indicates that the NAS is capable of providing location data in response to an Access-Challenge. The subsequent Access-Challenge message sent from the RADIUS server to the NAS provides a hint regarding the type of desired Location-Information Attributes. The NAS treats the Basic-Location-Policy-Rules and Extended-Location-Policy-Rules Attributes as opaque data (e.g., it echoes these rules provided by the server within the Access-Challenge back in the Access-Request). In the shown message flow, the location attributes are then provided in the subsequent Access-Request message. When evaluating this Access-Request message, the authorization procedure at the RADIUS server might be based on a number of criteria, including the newly defined attributes listed in Section 4.
RADIUSクライアントがアクセス要求における位置対応の属性を提供している場合、それは認可のために、位置情報がアクセス要求で提供されていなかった場合、その情報を必要とする場合は、RADIUSサーバは、RADIUSクライアントからの位置情報を要求することができます。この交換は、図2に示されているAccess-Requestメッセージで所在地対応項目を含めることは、NASは、アクセス・チャレンジに応答して、位置データを提供することが可能であることを示しています。 NASにRADIUSサーバから送信された後続のアクセスチャレンジメッセージは、所望の位置情報属性のタイプに関するヒントを提供します。 NASは基本-ロケーションポリシールールを扱いおよび拡張ロケーションポリシールールなどの不透明なデータ属性（例えば、アクセス・チャレンジバックアクセス要求における内のサーバーによって提供されるこれらの規則をエコー）。示すメッセージフローでは、位置属性は、後続のアクセス要求メッセージで提供されます。このAccess-Requestメッセージを評価する場合、RADIUSサーバでの認証手順は、セクション4に記載されている、新たに定義された属性を含む多くの基準に基づいてされる可能性があります。
+---------+ +---------+ +---------+
| | | Network | | RADIUS |
| User | | Access | | Server |
| | | Server | | |
+---------+ +---------+ +---------+
| | |
| Authentication phase | |
| begin | |
|---------------------->| |
| | |
| | Access-Request |
| | + Location-Capable |
| |--------------------------------->|
| | |
| | Access-Challenge |
| | + Basic-Location-Policy-Rules |
| | + Extended-Location-Policy-Rules|
| | + Requested-Location-Info |
| |<---------------------------------|
| | |
| | Access-Request |
| | + Location-Information |
| | + Location-Data |
| | + Basic-Location-Policy-Rules |
| | + Extended-Location-Policy-Rules|
| |--------------------------------->|
| | |
: : :
: Multiple Protocol Exchanges to perform :
: Authentication, Key Exchange, and Authorization :
: ...continued... :
: : :
| | |
| | Access-Accept |
| |<---------------------------------|
| Authentication | |
| Success | |
|<----------------------| |
| | |
Figure 2: Location Delivery Based on Initial Request
図2：初期の要求に基づいて、場所の配達
The on-demand, mid-session location-delivery method utilizes the Change-of-Authorization Request (CoA-Request) message and the CoA-NAK (CoA-Negative Acknowledgement), defined in [RFC5176]. At any time
オンデマンド、ミッドセッション場所配信方法は[RFC5176]で定義され、変更-の認可リクエスト（COA-要求）メッセージとCoA-NAK（COA-否定応答）を利用します。いつでも
during the session, the Dynamic Authorization Client MAY send a CoA-Request containing session-identification attributes to the NAS (i.e., Dynamic Authorization Server).
セッション中に、ダイナミックな承認クライアントがNASに属性をセッション識別を含むアシルCoA-要求を送信することができる（すなわち、ダイナミックな承認サーバ）。
In order to enable the on-demand, mid-session location-delivery method, the RADIUS server MUST return an instance of the Requested-Location-Info Attribute with the 'FUTURE_REQUESTS' flag set and instances of the Basic-Location-Policy-Rules and Extended-Location-Policy-Rules Attributes in the Access-Accept message for the session. Upon receipt of a CoA-Request message containing a Service-Type Attribute with value "Authorize Only" for the same session, the NAS MUST include location information and echo the previously received Basic-Location-Policy-Rules and Extended-Location-Policy-Rules Attributes in the subsequent Access-Request message.
オンデマンド、ミッドセッションの場所の配信方法を有効にするためには、RADIUSサーバが基本 - ロケーション-ポリシールールの「FUTURE_REQUESTS」フラグセットとインスタンスと属性要求-ロケーション情報のインスタンスを返さなければなりませんそして、拡張 - ロケーション-ポリシールールは、セッションのためのAccess-Acceptメッセージの属性。値のservice-type属性を含むアシルCoA-Requestメッセージを受信すると、「唯一の認可」と同じセッションのために、NASは、位置情報が含まれており、エコーしなければならない以前に受信したベーシック・場所・ポリシー・ルールと拡張 - ロケーション-政策ルールは、後続のアクセス要求メッセージの属性。
Upon receiving the Access-Request message containing the Service-Type Attribute with a value of Authorize-Only from the NAS, the RADIUS server responds with either an Access-Accept or an Access-Reject message.
NASからの承認のみの値を持つservice-type属性を含むAccess-Requestメッセージを受信すると、RADIUSサーバは、アクセスが、受け入れるか、またはアクセス拒否メッセージのいずれかで応答します。
The use of dynamic authorization [RFC5176] is necessary when location information is needed on-demand and cannot be obtained from accounting information in a timely fashion.
位置情報がオンデマンドで必要とされ、タイムリーに情報を会計から得ることができない場合、動的認可[RFC5176]の使用が必要です。
Figure 3 shows the above-described approach graphically.
図3は、グラフ上記のアプローチを示しています。
+---------------+ +---------------+ +------+
| Dynamic | | Dynamic | |RADIUS|
| Authorization | | Authorization | |Server|
| Server/NAS | | Client | | |
+---------------+ +---------------+ +------+
| | |
| Access-Request | |
| + Location-Capable | |
|----------------------------------------------------------->|
| | |
| Access-Challenge | |
| + Basic-Location-Policy-Rules | |
| + Extended-Location-Policy-Rules | |
| + Requested-Location-Info | |
|<-----------------------------------------------------------|
| | |
| Access-Request | |
| + Location-Information | |
| + Location-Data | |
| + Basic-Location-Policy-Rules | |
| + Extended-Location-Policy-Rules | |
|----------------------------------------------------------->|
| | |
| | |
: | :
: Multiple Protocol Exchanges to perform :
: Authentication, Key Exchange, and Authorization :
: ...continued... | :
: | :
| | |
| | |
| Access-Accept | |
| + Requested-Location-Info | |
(FUTURE_REQUESTS,...) | |
| + Basic-Location-Policy-Rules | |
| + Extended-Location-Policy-Rules | |
|<-----------------------------------------------------------|
| | |
: : :
: <<Some time later>> : :
: : :
| | |
| CoA + Service-Type "Authorize Only" + State | |
|<--------------------------------------------| |
| | |
| CoA NAK + Service-Type "Authorize Only" | |
| + State | |
| + Error-Cause "Request Initiated" | |
|-------------------------------------------->| |
| | |
| Access-Request | |
| + Service-Type "Authorize Only" | |
| + State | |
| + Location-Information | |
| + Location-Data | |
| + Basic-Location-Policy-Rules | |
| + Extended-Location-Policy-Rules | |
|----------------------------------------------------------->|
| Access-Accept | |
|<-----------------------------------------------------------|
| | |
Figure 3: Location Delivery Based on CoA with
Service-Type 'Authorize Only'
When the Dynamic Authorization Client wants to change the values of the requested location information, or set the values of the requested location information for the first time, it may do so without triggering a reauthorization. Assuming that the NAS had previously sent an Access-Request containing a Location-Capable
ダイナミックな承認クライアントが要求された位置情報の値を変更したり、初めて要求された位置情報の値を設定したい場合は、再認証をトリガーすることなく、そうすることができます。 NASが以前の場所対応を含むアクセス要求を送っていたと仮定すると、
Attribute, the Dynamic Authorization Client (DAC) can send a CoA-Request to the NAS without a Service-Type Attribute, but include the NAS identifiers and session identifiers as per [RFC5176] and the Requested-Location-Info, Basic-Location-Policy-Rules, and Extended-Location-Policy-Rules Attributes. The Requested-Location-Info, Basic-Location-Policy-Rules, and Extended-Location-Policy-Rules Attributes MUST NOT be used for session identification.
属性、ダイナミックな承認クライアント（DAC）は、service-type属性なしでNASへのCoA-Requestを送信しますが、[RFC5176]あたりとしてNAS識別子とセッション識別子を含む、要求された-ロケーション情報、基本-、場所にすることができますポリシー・ルール、および拡張 - ロケーション-ポリシールールの属性。要求された-ロケーション情報、ベーシック・場所・ポリシー・ルール、および拡張 - ロケーション-ポリシールールの属性は、セッションの識別に使用してはいけません。
Figure 4 shows this approach graphically.
図4は、図式このアプローチを示しています。
+---------------+ +---------------+ +------+
| Dynamic | | Dynamic | |RADIUS|
| Authorization | | Authorization | |Server|
| Server/NAS | | Client | | |
+---------------+ +---------------+ +------+
| | |
| | |
| Access-Request | |
| + Location-Capable | |
|----------------------------------------------------------->|
| | |
| Access-Challenge | |
| + Basic-Location-Policy-Rules | |
| + Extended-Location-Policy-Rules | |
| + Requested-Location-Info | |
|<-----------------------------------------------------------|
| | |
| Access-Request | |
| + Location-Information | |
| + Location-Data | |
| + Basic-Location-Policy-Rules | |
| + Extended-Location-Policy-Rules | |
|----------------------------------------------------------->|
| | |
| | |
: | :
: Multiple Protocol Exchanges to perform :
: Authentication, Key Exchange, and Authorization :
: ...continued... | :
: | :
| | |
| | |
| Access-Accept | |
| + Requested-Location-Info | |
| + Basic-Location-Policy-Rules | |
| + Extended-Location-Policy-Rules | |
|<-----------------------------------------------------------|
| | |
: : :
: <<Some time later>> : :
: : :
| | |
| CoA | |
| + Requested-Location-Info | |
| + Basic-Location-Policy-Rules | |
| + Extended-Location-Policy-Rules | |
|<--------------------------------------------| |
| | |
| CoA ACK | |
|-------------------------------------------->| |
| | |
: : :
: <<Further exchanges later>> : :
: : :
Figure 4: Location Delivery Based on CoA
図4：場所の配達のCoAに基づいて、
Location information may also be reported in accounting messages. Accounting messages are generated when the session starts, when the session stops, and periodically during the lifetime of the session. Accounting messages may also be generated when the user roams during handoff.
位置情報は、アカウンティングメッセージで報告することができます。アカウンティングメッセージは、セッションが停止し、定期的にセッションの存続期間中にすると、セッションは、起動時に生成されます。ユーザーがハンドオフ中にローミングするときアカウンティングメッセージも生成することができます。
Accounting information may be needed by the billing system to calculate the user's bill. For example, there may be different tariffs or tax rates applied based on the location.
会計情報は、ユーザの法案を計算する課金システムによって必要とすることができます。例えば、位置に基づいて適用異なる料金又は税率があってもよいです。
If the RADIUS server needs to obtain location information in accounting messages, then it needs to include a Requested-Location-Info Attribute with the Access-Accept message. The Basic-Location-Policy-Rules and the Extended-Location-Policy-Rules Attributes are to be echoed in the Accounting-Request if indicated in the Access-Accept.
RADIUSサーバは、アカウンティングメッセージに位置情報を取得する必要がある場合、それは要求され、ロケーション情報は、Access-Acceptメッセージに属性含める必要があります。基本-ロケーションポリシールールと拡張 - ロケーション-ポリシールールの属性は、接続許可に示されている場合はアカウンティング要求にエコーされることになります。
Figure 5 shows the message exchange.
図5は、メッセージ交換を示しています。
+---------+ +---------+ +---------+
| | | Network | | RADIUS |
| User | | Access | | Server |
| | | Server | | |
+---------+ +---------+ +---------+
| | |
: : :
: Initial Protocol Interaction :
: (details omitted) :
: : :
| | |
| | Access-Accept |
| | + Requested-Location-Info |
| | + Basic-Location-Policy-Rules |
| | + Extended-Location-Policy-Rules|
| |<---------------------------------|
| Authentication | |
| Success | |
|<----------------------| |
| | |
| | Accounting-Request |
| | + Location-Information |
| | + Location-Data |
| | + Basic-Location-Policy-Rules |
| | + Extended-Location-Policy-Rules|
| |--------------------------------->|
| | |
| | Accounting-Response |
| |<---------------------------------|
| | |
Figure 5: Location Delivery in Accounting Messages
図5：アカウンティングメッセージ内の場所配信
It is important to note that the location-specific parts of the attributes defined below are not meant to be processed by the RADIUS server. Instead, a location-server-specific component used in combination with the RADIUS server is responsible for receiving, processing, and further distributing location information (in combination with proper access control and privacy protection). As such, from a RADIUS server point of view, location information is treated as opaque data.
なお、以下に定義された属性の位置特定の部分がRADIUSサーバによって処理されることを意味するものではないことに注意することが重要です。代わりに、RADIUSサーバと組み合わせて使用する場所サーバー固有のコンポーネントは、受信処理を担当し、さらに（適切なアクセス制御とプライバシー保護と組み合わせて）位置情報を配信します。このように、ビューのRADIUSサーバ点から、位置情報は、不透明なデータとして扱われます。
This attribute carries the operator namespace identifier and the operator name. The operator name is combined with the namespace identifier to uniquely identify the owner of an access network. The value of the Operator-Name is a non-NULL terminated text whose length MUST NOT exceed 253 bytes.
この属性は、オペレータの名前空間識別子と演算子名を運びます。オペレータ名は、一意のアクセスネットワークの所有者を識別するための名前空間識別子と組み合わされます。オペレータの名前の値が非NULLは、長さが253のバイトを超えてはならないテキストを終了します。
The Operator-Name Attribute SHOULD be sent in Access-Request and Accounting-Request messages where the Acc-Status-Type is set to Start, Interim, or Stop.
オペレータ-name属性は、アクセス要求およびアカウンティング要求ACC-ステータス-Typeが起動するように設定されたメッセージ、中間、または停止して送ってください。
A summary of the Operator-Name Attribute is shown below.
オペレータ-name属性の概要は以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Text (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
126 - Operator-Name
126 - オペレータ名
Length:
長さ：
>= 4
＞＝ ４
Text:
テキスト：
The format is shown below. The data type of this field is a text. All fields are transmitted from left to right:
書式は以下に示されています。このフィールドのデータ型がテキストです。すべてのフィールドは、左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace ID | Operator-Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operator-Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Namespace ID:
名前空間ID：
The value within this field contains the operator namespace identifier. The Namespace ID value is encoded in ASCII.
このフィールド内の値は、オペレータの名前空間識別子が含まれています。名前空間のID値はASCIIでエンコードされています。
Example: '1' (0x31) for REALM
例：レルムの '1'（0x31）
Operator-Name:
オペレータ名：
The text field of variable length contains an Access Network Operator Name. This field is a RADIUS-based data type of Text.
可変長のテキストフィールドには、アクセスネットワークオペレータの名前が含まれています。このフィールドは、テキストのRADIUSベースのデータ型です。
The Namespace ID field provides information about the operator namespace. This document defines four values for this attribute, which are listed below. Additional namespace identifiers must be registered with IANA (see Section 8.1) and must be associated with an organization responsible for managing the namespace.
名前空間のIDフィールドは、オペレータの名前空間に関する情報を提供します。この文書では、以下のとおり、この属性のための4つの値を、定義されています。追加の名前空間識別子は、IANAに登録する必要があります（8.1節を参照）、および名前空間の管理を担当する組織に関連付けられている必要があります。
TADIG ('0' (0x30)):
TADIG（ '0'（0x30から））：
This namespace can be used to indicate operator names based on Transferred Account Data Interchange Group (TADIG) codes, as defined in [GSM]. TADIG codes are assigned by the TADIG Working Group within the Global System for Mobile Communications (GSM) Association. The TADIG code consists of two fields, with a total length of five ASCII characters consisting of a three-character country code and a two-character alphanumeric operator (or company) ID.
この名前空間は、[GSM]で定義されるように、転写されたアカウントデータインターチェンジグループ（TADIG）コードに基づいてオペレータ名を示すために使用することができます。 TADIGコードは、モバイル通信用グローバルシステム（GSM）アソシエーション内TADIGワーキンググループによって割り当てられます。 TADIGコードは3文字の国コードと2文字の英数字のオペレータ（または会社）IDからなる5つのASCII文字の合計の長さで、2つのフィールドで構成されています。
REALM ('1' (0x31)):
REALM（ '1'（0x31））：
The REALM operator namespace can be used to indicate operator names based on any registered domain name. Such names are required to be unique, and the rights to use a given realm name are obtained coincident with acquiring the rights to use a particular Fully Qualified Domain Name (FQDN). Since this operator is limited to ASCII, any registered domain name that contains non-ASCII characters must be converted to ASCII. The Punycode encoding [RFC3492] is used for this purpose.
REALMのオペレータの名前空間は、登録ドメイン名に基づいてオペレータ名を示すために使用することができます。このような名前は一意であることが要求され、与えられたレルム名を使用する権利は、特定の完全修飾ドメイン名（FQDN）を使用する権利を取得して一致を得ています。この演算子は、ASCIIに限定されているので、非ASCII文字が含まれている任意の登録ドメイン名がASCIIに変換する必要があります。ピュニコードエンコーディング[RFC3492]は、この目的のために使用されます。
E212 ('2' (0x32)):
E212（ '2'（0x32の））：
The E212 namespace can be used to indicate operator names based on the Mobile Country Code (MCC) and Mobile Network Code (MNC) defined in [ITU212]. The MCC/MNC values are assigned by the Telecommunications Standardization Bureau (TSB) within the ITU-T and by designated administrators in different countries. The E212 value consists of three ASCII digits containing the MCC, followed by two or three ASCII digits containing the MNC.
E212の名前空間は[ITU212]で定義されたモバイル国コード（MCC）およびモバイルネットワークコード（MNC）に基づいて、オペレータ名を示すために使用することができます。 MCC / MNC値はITU-T内の電気通信標準化局（TSB）によって、異なる国にある指定された管理者によって割り当てられます。 E212値は、MNCを含有する二、三のASCII数字が続くMCCを含む3個のASCII数字から成ります。
ICC ('3' (0x33)):
ICC（ '3'（0x33の））：
The ICC namespace can be used to indicate operator names based on International Telecommunication Union (ITU) Carrier Codes (ICC) defined in [ITU1400]. ICC values are assigned by national regulatory authorities and are coordinated by the Telecommunication Standardization Bureau (TSB) within the ITU Telecommunication Standardization Sector (ITU-T). When using the ICC namespace, the attribute consists of three uppercase ASCII characters containing a three-letter alphabetic country code, as defined in [ISO], followed by one to six uppercase alphanumeric ASCII characters containing the ICC itself.
ICCの名前空間は、[ITU1400]で定義された国際電気通信連合（ITU）キャリアコード（ICC）に基づいた演算子名を示すために使用することができます。 ICCの値は、国の規制当局によって割り当てられ、ITU電気通信標準化部門（ITU-T）内電気通信標準化局（TSB）によって調整されています。 ICCの名前空間を使用する場合は、属性がICC自体を含む1〜6個の大文字の英数字のASCII文字に続いて、[ISO]で定義されているように、三文字のアルファベットの国コードを含む3つの大文字のASCII文字で構成されています。
The Location-Information Attribute MAY be sent in the Access-Request message, the Accounting-Request message, both of these messages, or no message. For the Accounting-Request message, the Acc-Status-Type may be set to Start, Interim, or Stop.
位置情報属性は、Access-Requestメッセージ、アカウンティング要求メッセージ、これらのメッセージの両方、またはメッセージなしで送信することができます。アカウンティング要求メッセージの場合は、ACC-ステータス-Typeは中間、または停止、起動するように設定することができます。
The Location-Information Attribute provides meta-data about the location information, such as sighting time, time-to-live, location-determination method, etc.
位置情報の属性等照準時間、存続時間、位置決意法として、位置情報に関するメタデータを提供します
The format is shown below.
書式は以下に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
127 - Location-Information
127 - 位置情報
Length:
長さ：
>= 23
＞＝ ２３
String:
文字列：
The format is shown below. The data type of this field is a string. All fields are transmitted from left to right:
書式は以下に示されています。このフィールドのデータ型は文字列です。すべてのフィールドは、左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | Code | Entity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sighting Time ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sighting Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Method ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Index (16 bits):
インデックス（16ビット）：
The 16-bit unsigned integer value allows this attribute to provide information relating to the information included in the Location-Data Attribute to which it refers (via the Index).
16ビット符号なし整数値は、この属性は、ロケーション・データに含まれる情報に関連する情報を提供することを可能にする（索引を介して）それが参照する属性。
Code (8 bits):
コード（8ビット）：
This field indicates the content of the location profile carried in the Location-Data Attribute. Two profiles are defined in this document -- namely, a civic location profile (see Section 4.3.1) that uses value (0) and a geospatial location profile (see Section 4.3.2) that uses the value (1).
このフィールドは、ロケーションデータ属性で運ばれたロケーションプロファイルの内容を示します。つまり、市民のロケーション・プロファイル値（0）を使用する（セクション4.3.1を参照）、値（1）を使用して地理空間ロケーション・プロファイル（4.3.2項参照） - 2つのプロファイルは、この文書で定義されています。
Entity (8 bits):
エンティティ（8ビット）：
This field encodes which location this attribute refers to as an unsigned 8-bit integer value. Location information can refer to different entities. This document registers two entity values, namely:
このフィールドは、この属性が符号なし8ビット整数値ともいう位置符号化します。位置情報が異なるエンティティを参照することができます。この文書では、すなわち、2つのエンティティの値を登録します。
Value (0) describes the location of the user's client device.
値は（0）ユーザーのクライアントデバイスの位置を説明しています。
Value (1) describes the location of the RADIUS client.
値は、（1）RADIUSクライアントの場所を説明します。
The registry used for these values is established by this document, see Section 8.4.
これらの値のために使用されるレジストリは、8.4項を参照してください、この文書によって確立されます。
Sighting Time (64 bits)
照準時間（64ビット）
This field indicates when the location information was accurate. The data type of this field is a string, and the content is expressed in the 64-bit Network Time Protocol (NTP) timestamp format [RFC1305].
位置情報が正確であった場合、このフィールドは示します。このフィールドのデータタイプは文字列であり、コンテンツは、64ビットのネットワークタイムプロトコル（NTP）タイムスタンプ形式[RFC1305]で表されます。
Time-to-Live (64 bits):
タイム・ツー・ライブ（64ビット）：
This field gives a hint regarding for how long location information should be considered current. The data type of this field is a string and the content is expressed in the 64-bit Network Time Protocol (NTP) timestamp format [RFC1305]. Note that the Time-to-Live field is different than the Retention Expires field used in the Basic-Location-Policy-Rules Attribute, see Section 4.4. The Retention Expires field indicates the time the recipient is no longer permitted to possess the location information.
このフィールドは、現在検討すべきであるどのくらいの位置についてはに関するヒントを提供します。このフィールドのデータタイプは文字列であり、内容は、64ビットのネットワークタイムプロトコル（NTP）タイムスタンプ形式[RFC1305]で表されます。タイム・ツー・ライブ・フィールドは保持が基本 - ロケーション-ポリシールールで使用されるフィールドは、属性有効期限とは異なることに注意してください、セクション4.4を参照してください。保持フィールドは、受信者がもはや位置情報を所有することを許可された時間を示す有効期限。
Method (variable):
メソッド（変数）：
Describes the way that the location information was determined. This field MUST contain the value of exactly one IANA-registered 'method' token [RFC4119].
位置情報が決定された方法を記載しています。このフィールドは、1つのIANA登録「メソッド」トークン[RFC4119]の値を含まなければなりません。
The length of the Location-Information Attribute MUST NOT exceed 253 octets.
位置情報属性の長さが253個のオクテットを超えてはなりません。
The Location-Data Attribute MAY be sent in Access-Request and Accounting-Request messages. For the Accounting-Request message, the Acc-Status-Type may be set to Start, Interim, or Stop.
ロケーションデータ属性は、アクセス要求およびアカウンティング要求メッセージで送信することができます。アカウンティング要求メッセージの場合は、ACC-ステータス-Typeは中間、または停止、起動するように設定することができます。
The format is shown below.
書式は以下に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
128 - Location-Data
128 - ロケーションデータ
Length:
長さ：
>= 5
＞＝ ５
String:
文字列：
The format is shown below. The data type of this field is a string. All fields are transmitted from left to right:
書式は以下に示されています。このフィールドのデータ型は文字列です。すべてのフィールドは、左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | Location ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Location ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Index (16 bits):
インデックス（16ビット）：
The 16-bit unsigned integer value allows this attribute to associate the Location-Data Attribute with the Location-Information Attributes.
16ビットの符号なし整数値は、この属性は、位置情報の属性と属性のロケーションデータを関連付けることができます。
Location (variable):
場所（変数）：
The format of the location data depends on the location profile. This document defines two location profiles. Details of the location profiles are described below.
位置データの形式は、ロケーション・プロファイルに依存します。この文書では、二つの場所のプロファイルを定義します。ロケーション・プロファイルの詳細については後述します。
Civic location is a popular way to describe the location of an entity. This section defines the civic location-information profile corresponding to the value (0) indicated in the Code field of the Location-Information Attribute. The location format is based on the encoding format defined in Section 3.1 of [RFC4776], whereby the first 3 octets are not put into the Location field of the above-described RADIUS Location-Data Attribute (i.e., the code for the DHCP option, the length of the DHCP option, and the 'what' element are not included).
シビック場所は、エンティティの位置を記述するための一般的な方法です。このセクションでは、（0）は、位置情報属性のコードフィールドに示される値に対応する都市ロケーション情報のプロファイルを定義します。位置フォーマットが最初の3つのオクテット（上記RADIUSロケーションデータ属性のロケーションフィールドに入れていないことにより、[RFC4776]のセクション3.1で定義された符号化形式に基づいており、すなわち、DHCPのオプションのためのコード、 DHCPオプションの長さ、そして「何の要素が含まれていません）。
This section defines the geospatial location-information profile corresponding to the value (1) indicated in the Code field of the Location-Information Attribute. Geospatial location information is encoded as an opaque object, and the format is based on the Location
このセクションでは、（1）位置情報属性のコードフィールドに示される値に対応する地理空間位置情報プロファイルを定義します。地理空間位置情報は、不透明なオブジェクトとして符号化され、フォーマットは、位置に基づきます
Configuration Information (LCI) format defined in Section 2 of [RFC3825] but starts with the third octet (i.e., the code for the DHCP option and the length field is not included).
コンフィギュレーション情報（LCI）フォーマットは、[RFC3825]のセクション2で定義されたが、第三のオクテット（すなわち、DHCPオプションと長さフィールドのコードが含まれていない）から始まります。
The Basic-Location-Policy-Rules Attribute MAY be sent in Access-Request, Access-Accept, Access-Challenge, Change-of-Authorization, and Accounting-Request messages.
基本-ロケーションポリシールール属性がアクセス要求、アクセス-受け入れ、アクセスチャレンジ、チェンジ・オブ・認可、およびアカウンティング要求メッセージで送信することができます。
Policy rules control the distribution of location information. In order to understand and process the Basic-Location-Policy-Rules Attribute, RADIUS clients are obligated to utilize a default value of Basic-Location-Policy-Rules, unless explicitly configured otherwise, and to echo the Basic-Location-Policy-Rules Attribute that they receive from a server. As a default, the Note Well field does not carry a pointer to human-readable privacy policies, the retransmission-allowed is set to zero (0), i.e., further distribution is not allowed, and the Retention Expires field is set to 24 hours.
ポリシールールは、位置情報の分布を制御します。基本-ロケーションポリシールールの属性を理解し、処理するために、RADIUSクライアントが明示的に設定されていない限り、基本-場所-ポリシールールのデフォルト値を利用して、基本的な-ロケーションポリシールールをエコーすることが義務付けされています彼らは、サーバーから受信したことを属性。デフォルトでは、ノートまあフィールドは再送信が許可され、ゼロに設定されているが（0）、すなわち、さらに分布が許可されていない人間が読めるプライバシーポリシーへのポインタを運ばない、と保持は24時間に設定されたフィールドを有効期限。
With regard to authorization policies, this document reuses work done in [RFC4119] and encodes those policies in a non-XML format. Two fields ('Sighting Time' and 'Time-to-Live') are additionally included in the Location-Information Attribute to conform to the GEOPRIV requirements [RFC3693], Section 2.7.
認可ポリシーに関しては、このドキュメントは[RFC4119]で行われた作業を再利用し、非XMLフォーマットでこれらのポリシーを符号化します。二つのフィールド（「照準時間」と「タイム・ツー・ライブ・」）はさらにGEOPRIV要件[RFC3693]、セクション2.7に準拠するように属性位置情報に含まれています。
The format of the Basic-Location-Policy-Rules Attribute is shown below.
基本-ロケーションポリシールール属性の書式は以下に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
129 - Basic-Location-Policy-Rules
129 - 基本 - ロケーション-ポリシールール
Length:
長さ：
>= 12
＞＝ １２
String:
文字列：
The format is shown below. The data type of this field is a string. All fields are transmitted from left to right:
書式は以下に示されています。このフィールドのデータ型は文字列です。すべてのフィールドは、左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Retention Expires ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retention Expires ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retention Expires | Note Well ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Note Well ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document reuses fields from the RFC 4119 [RFC4119] 'usage-rules' element. These fields have the following meaning:
この文書は、RFC 4119 [RFC4119]「利用ルール」要素からフィールドを再利用します。これらのフィールドは、以下の意味があります。
Flags (16 bits):
フラグ（16ビット）：
The Flags field is a bit mask. Only the first bit (R) is defined in this document, and it corresponds to the Retransmission Allowed field:
フラグフィールドは、ビットマスクです。最初のビット（R）は、この文書で定義され、それが再送可フィールドに対応しています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|o o o o o o o o o o o o o o o|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R = Retransmission Allowed o = reserved.
予約= Oで可R =再送。
All reserved bits MUST be zero. When the value of the Retransmission Allowed field is set to zero (0), then the recipient of this Location Object is not permitted to share the enclosed location information, or the object as a whole, with other parties. The value of '1' allows this attribute to share the location information with other parties by considering the extended policy rules.
すべての予約ビットはゼロでなければなりません。再送許可フィールドの値がゼロに設定されている場合（0）、このロケーション・オブジェクトの受信者は、他の当事者と囲まれた位置情報、又は全体としてオブジェクトを共有することを許可されていません。 「1」の値は、この属性が拡張されたポリシールールを考慮して、他の当事者と位置情報を共有することができます。
Retention Expires (64 bits):
保持は、（64ビット）の有効期限：
This field specifies an absolute date at which time the Recipient is no longer permitted to possess the location information. The data type of this field is a string and the format is a 64-bit NTP timestamp [RFC1305].
このフィールドは、受信者は、もはや位置情報を保有することを許可された時点で絶対的な日付を指定します。このフィールドのデータタイプは文字列で、フォーマットは、64ビットのNTPタイムスタンプ[RFC1305]です。
Note Well (variable):
まあ（変数）を注意してください：
This field contains a URI that points to human-readable privacy instructions. The data type of this field is a string. This field is useful when location information is distributed to third-party entities, which can include humans in a location-based service. RADIUS entities are not supposed to process this field.
このフィールドは、人間が読めるプライバシー命令を指すURIが含まれています。このフィールドのデータ型は文字列です。位置情報は、ロケーションベースのサービスでは、人間を含むことができ、サードパーティのエンティティに配信されている場合、このフィールドは便利です。 RADIUSエンティティは、このフィールドを処理することになっていません。
Whenever a Location Object leaves the RADIUS ecosystem, the URI in the Note Well Attribute MUST be expanded to the human-readable text. For example, when the Location Object is transferred to a SIP-based environment, then the human-readable text is placed into the 'note-well' element of the 'usage-rules' element contained in the PIDF-LO (Presence Information Data Format - Location Object) document (see [RFC4119]). The Note Well field may be empty.
Locationオブジェクトは、RADIUSの生態系を離れるたび、ノートまあ属性におけるURIは、人間が読めるテキストに展開されなければなりません。例えば、位置オブジェクトは、人間可読テキストをPIDF-LOに含まれる「利用ルール」要素（プレゼンス情報データの「ノートウェル」要素内に配置され、SIPベースの環境に移されたときフォーマット - 場所オブジェクト）ドキュメント（[RFC4119]を参照）。注まあフィールドが空になることがあります。
The Extended-Location-Policy-Rules Attribute MAY be sent in Access-Request, Access-Accept, Access-Challenge, Access-Reject, Change-of-Authorization, and Accounting-Request messages.
拡張 - ロケーション・ポリシー・ルール属性は、変更の承認、アクセス拒否、アクセスチャレンジ、アクセス-受け入れ、アクセス要求で送信され、アカウンティング要求メッセージかもしれません。
The Ruleset Reference field of this attribute is of variable length. It contains a URI that indicates where the richer ruleset can be found. This URI SHOULD use the HTTPS URI scheme. As a deviation from [RFC4119], this field only contains a reference and does not carry an attached, extended ruleset. This modification is motivated by the size limitations imposed by RADIUS.
この属性のルールセット・リファレンス・フィールドは可変長です。これは、より豊かなルールセットを見つけることができる場所を示すというURIが含まれています。このURIは、HTTPS URIスキームを使用すべきです。 [RFC4119]からの偏差として、このフィールドは、参照のみを含み、取り付け、拡張ルールセットを搬送しません。この変更は、RADIUSによって課されるサイズ制限によって動機付けられています。
In order to understand and process the Extended-Location-Policy-Rules Attribute, RADIUS clients are obligated to attach the URI to the Extended-Location-Policy-Rules Attribute when they are explicitly configured to do so, and to echo the Extended-Location-Policy-Rules Attribute that they receive from a server. There is no expectation that RADIUS clients will need to retrieve data at the URL specified in the attribute or to parse the XML policies.
理解と拡張 - ロケーション・ポリシー・ルールの属性を処理するために、RADIUSクライアントは、彼らが明示的にそうするように構成されている場合、属性、および拡張-場所をエコーする拡張 - ロケーション・ポリシー・ルールへのURIを添付することが義務付けされています-policy-ルールは、サーバーから受信したことを属性。 RADIUSクライアントは属性で指定されたURLでデータを取得する必要がありますまたはXMLポリシーを解析するために何の期待はありません。
The format of the Extended-Location-Policy-Rules Attribute is shown below.
拡張 - ロケーション・ポリシー・ルール属性の書式は以下に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
130 - Extended-Location-Policy-Rules
130 - 拡張 - ロケーション-ポリシールール
Length:
長さ：
>= 3
＞＝ ３
String:
文字列：
This field is at least two octets in length, and the format is shown below. The data type of this field is a string. The fields are transmitted from left to right:
このフィールドは、長さが少なくとも2つのオクテットであり、書式は以下に示されています。このフィールドのデータ型は文字列です。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ruleset Reference ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ruleset Reference:
ルールセット・リファレンス：
This field contains a URI that points to the policy rules.
このフィールドは、ポリシールールを指すURIが含まれています。
The Location-Capable Attribute allows an NAS (or client function of a proxy server) to indicate support for the functionality specified in this document. The Location-Capable Attribute with the value for 'Location Capable' MUST be sent with the Access-Request messages, if the NAS supports the functionality described in this document and is capable of sending location information. A RADIUS server MUST NOT challenge for location information unless the Location-Capable Attribute has been sent to it.
場所対応の属性は、NAS（プロキシサーバまたはクライアント機能）は、この文書で指定された機能のサポートを示すことができます。 NASは、このドキュメントで説明する機能をサポートして位置情報を送信することが可能である場合は、「できる場所」の値を持つ場所可能な属性は、アクセス要求メッセージを送らなければなりません。場所対応の属性がそれに送られていない限り、RADIUSサーバは、位置情報のために挑戦してはなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
131 - Location-Capable Attribute
131 - ロケーション対応の属性
Length:
長さ：
6
６
Integer:
整数：
The content of the Integer field encodes the requested capabilities. Each capability value represents a bit position.
整数フィールドの内容は、要求された機能をコードしています。各能力値は、ビット位置を表します。
This document specifies the following capabilities.
このドキュメントでは、次の機能を指定します。
Name:
名前：
CIVIC_LOCATION
CIVIC_LOCATION
Description:
説明：
The RADIUS client uses the CIVIC_LOCATION to indicate that it is able to return civic location based on the location profile defined in Section 4.3.1.
RADIUSクライアントは、4.3.1項で定義された場所のプロファイルに基づいて市民の場所を返すことができることを示すためにCIVIC_LOCATIONを使用しています。
Numerical Value:
数値：
A numerical value of this token is '1'.
このトークンの数値が「1」です。
Name:
名前：
GEO_LOCATION
GEO_LOCATION
Description:
説明：
The RADIUS client uses the GEO_LOCATION to indicate that it is able to return geodetic location based on the location profile defined in Section 4.3.2.
RADIUSクライアントは、4.3.2項で定義された場所のプロファイルに基づいて測地位置を返すことができることを示すためにGEO_LOCATIONを使用しています。
Numerical Value:
数値：
A numerical value of this token is '2'.
このトークンの数値は「2」です。
Name:
名前：
USERS_LOCATION
USERS_LOCATION
Description:
説明：
The numerical value representing USERS_LOCATION indicates that the RADIUS client is able to provide a Location-Information Attribute with the Entity Attribute expressing the value of zero (0), i.e., the RADIUS client is capable of returning the location information of the user's client device.
USERS_LOCATIONを表す数値は、RADIUSクライアントがゼロの値を表すエンティティ属性（0）、すなわちで項目位置情報を提供することができることを示す、RADIUSクライアントは、ユーザーのクライアントデバイスの位置情報を返すことが可能です。
Numerical Value:
数値：
A numerical value of this token is '4'.
このトークンの数値は「4」です。
Name:
名前：
NAS_LOCATION
NAS_LOCATION
Description:
説明：
The numerical value representing NAS_LOCATION indicates that the RADIUS client is able to provide a Location-Information Attribute that contains location information with the Entity Attribute expressing the value of one (1), i.e., the RADIUS client is capable of returning the location information of the NAS.
NAS_LOCATIONを表す数値は、RADIUSクライアントがエンティティ属性、すなわち、（1）1の値を発現する位置情報を含む位置情報の属性を提供することができることを示す、RADIUSクライアントは、位置情報を返すことが可能ですNAS。
Numerical Value:
数値：
A numerical value of this token is '8'.
このトークンの数値は「8」です。
The Requested-Location-Info Attribute allows the RADIUS server to indicate which location information about which entity it wants to receive. The latter aspect refers to the entities that are indicated in the Entity field of the Location-Information Attribute.
要求された-ロケーション情報の属性は、RADIUSサーバは、それが受信したいエンティティについてのどの位置情報を示すことができます。後者の態様は、位置情報属性のエンティティフィールドに示されているエンティティを指します。
The Requested-Location-Info Attribute MAY be sent in an Access-Accept, Access-Challenge, or Change-of-Authorization packet.
要求された-ロケーション情報の属性は、接続許可、アクセスチャレンジで送信された、または変更の承認パケットであってもよいです。
If the RADIUS server wants to dynamically decide on a per-request basis to ask for location information from the RADIUS client, then the following cases need to be differentiated. If the RADIUS client and the RADIUS server have agreed out-of-band to mandate the transfer of location information for every network-access authentication request, then the processing listed below is not applicable.
RADIUSサーバが動的にRADIUSクライアントからの位置情報を求めるためにリクエストごとに決定したい場合は、次の例では区別する必要があります。 RADIUSクライアントとRADIUSサーバは、すべてのネットワークアクセス認証要求のための位置情報の転送を強制するためにアウト・オブ・バンド合意した場合には、以下に示す処理が適用されません。
o If the RADIUS server requires location information for computing the authorization decision and the RADIUS client does not provide it with the Access-Request message, then the Requested-Location-Info Attribute is attached to the Access-Challenge with a hint about what is required.
O RADIUSサーバは、認可の決定を計算するための位置情報を必要とし、RADIUSクライアントがAccess-Requestメッセージでそれを提供しない場合、要求された-ロケーション情報の属性が必要とされるかについてのヒントを使用してアクセスチャレンジに接続されている場合。
o If the RADIUS server does not receive the requested information in response to the Access-Challenge (including the Requested-Location-Info Attribute), then the RADIUS server may respond with an Access-Reject message with an Error-Cause Attribute (including the "Location-Info-Required" value).
RADIUSサーバは、（要求 - ロケーション-info属性を含む）アクセスチャレンジに応答して、要求された情報を受信しない場合は、O、その後、RADIUSサーバは（を含むエラー-原因属性でのAccess-Rejectメッセージで応答することができます「ロケーションインフォ必要」値）。
o If the RADIUS server would like location information in the Accounting-Request message but does not require it for computing an authorization decision, then the Access-Accept message MUST include a Required-Info Attribute. This is typically the case when location information is used only for billing. The RADIUS client SHOULD attach location information, if available, to the Accounting-Request (unless authorization policies dictate something different).
RADIUSサーバは、アカウンティング要求メッセージ内の位置情報を好むだろうが、認可の決定を計算するためにそれを必要としない場合は、O、その後、Access-Acceptメッセージには、必要な-情報属性を含める必要があります。これは、典型的には、位置情報のみ課金するために使用される場合です。利用可能な場合、RADIUSクライアントは、アカウンティング要求（認可ポリシーは、別の何かを指示しない限り）に、位置情報を添付してください。
If the RADIUS server does not send a Requested-Location-Info Attribute, then the RADIUS client MUST NOT attach location information to messages towards the RADIUS server. The user's authorization policies, if available, MUST be consulted by the RADIUS server before requesting location information delivery from the RADIUS client.
RADIUSサーバは、要求・ロケーション情報の属性を送信しない場合は、RADIUSクライアントは、RADIUSサーバへのメッセージに位置情報を添付してはなりません。ユーザーの認可ポリシーは、利用可能な場合、RADIUSクライアントからの位置情報の配信を要求する前に、RADIUSサーバから相談されなければなりません。
Figure 6 shows a simple protocol exchange where the RADIUS server indicates the desire to obtain location information, namely civic location information of the user, to grant access. Since the Requested-Location-Info Attribute is attached to the Access-Challenge, the RADIUS server indicates that location information is required for computing an authorization decision.
図6は、RADIUSサーバがアクセスを許可する位置情報、ユーザのすなわち市民の位置情報を取得したい旨を示す単純なプロトコル交換を示します。要求 - ロケーション-info属性がアクセスチャレンジに取り付けられているので、RADIUSサーバは、位置情報が、許可の決定を計算するために必要であることを示しています。
+---------+ +---------+
| RADIUS | | RADIUS |
| Client | | Server |
+---------+ +---------+
| |
| |
| Access-Request |
| + Location-Capable |
| ('CIVIC_LOCATION', |
| 'GEO_LOCATION', |
| 'NAS_LOCATION', |
| 'USERS_LOCATION') |
|--------------------------------->|
| |
| Access-Challenge |
| + Requested-Location-Info |
| ('CIVIC_LOCATION', |
| 'USERS_LOCATION') |
| + Basic-Location-Policy-Rules |
| + Extended-Location-Policy-Rules |
|<---------------------------------|
| |
| Access-Request |
| + Location-Information |
| + Location-Data |
| + Basic-Location-Policy-Rules |
| + Extended-Location-Policy-Rules |
|--------------------------------->|
| |
| .... |
Figure 6: RADIUS Server Requesting Location Information
図6：RADIUSサーバが位置情報を要求
The Requested-Location-Info Attribute MUST be sent by the RADIUS server, in the absence of an out-of-band agreement, if it wants the RADIUS client to return location information and if authorization policies permit it. This Requested-Location-Info Attribute MAY appear in the Access-Accept or in the Access-Challenge message.
認可ポリシーがそれを許可した場合に要求さ-ロケーション情報の属性は、RADIUSクライアントが位置情報を返すしたい場合には、アウトオブバンドの合意がない場合には、RADIUSサーバによって送信されなければなりません。この要求-ロケーション情報の属性は、接続許可またはアクセスチャレンジメッセージ内に表示されることがあります。
A summary of the attribute is shown below.
属性の概要は以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Integer ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
132 - Requested-Location-Info Attribute
132 - 要求された-ロケーション情報の属性
Length:
長さ：
6
６
Integer:
整数：
The content of the Integer field encodes the requested information attributes. Each capability value represents a bit position.
整数フィールドの内容は、要求された情報の属性を符号化します。各能力値は、ビット位置を表します。
This document specifies the following capabilities:
このドキュメントでは、次の機能を指定します。
Name:
名前：
CIVIC_LOCATION
CIVIC_LOCATION
Description:
説明：
The RADIUS server uses the Requested-Location-Info Attribute with the value set to CIVIC_LOCATION to request specific location information from the RADIUS client. The numerical value representing CIVIC_LOCATION requires the RADIUS client to attach civic location attributes. CIVIC_LOCATION refers to the location profile defined in Section 4.3.1.
RADIUSサーバは、RADIUSクライアントから特定の位置情報を要求するためにCIVIC_LOCATIONに設定した値と属性要求-ロケーション情報を使用しています。 CIVIC_LOCATIONを表す数値は、市民の場所の属性を添付するRADIUSクライアントが必要です。 CIVIC_LOCATIONはセクション4.3.1で定義されたロケーション・プロファイルを指します。
Numerical Value:
数値：
A numerical value of this token is '1'.
このトークンの数値が「1」です。
Name:
名前：
GEO_LOCATION
GEO_LOCATION
Description:
説明：
The RADIUS server uses the Requested-Location-Info Attribute with the value set to GEO_LOCATION to request specific location information from the RADIUS client. The numerical value representing GEO_LOCATION requires the RADIUS client to attach geospatial location attributes. GEO_LOCATION refers to the location profile described in Section 4.3.2.
RADIUSサーバは、要求された-ロケーション情報は、RADIUSクライアントから特定の位置情報を要求するためにGEO_LOCATIONに設定した値と属性を使用します。 GEO_LOCATIONを表す数値は、地理空間位置の属性を添付するRADIUSクライアントが必要です。 GEO_LOCATIONは、セクション4.3.2に記載ロケーションプロファイルを指します。
Numerical Value:
数値：
A numerical value of this token is '2'.
このトークンの数値は「2」です。
Name:
名前：
USERS_LOCATION
USERS_LOCATION
Description:
説明：
The numerical value representing USERS_LOCATION indicates that the RADIUS client MUST send a Location-Information Attribute with the Entity Attribute expressing the value of zero (0). Hence, there is a one-to-one relationship between the USERS_LOCATION token and the value of zero (0) of the Entity Attribute inside the Location-Information Attribute. A value of zero indicates that the location information in the Location-Information Attribute refers to the user's client device.
USERS_LOCATIONを表す数値は、RADIUSクライアントは、ゼロ（0）の値を表すエンティティ属性と属性の位置情報を送信しなければならないことを示しています。したがって、位置情報属性内のエンティティ属性のUSERS_LOCATIONトークンゼロ（0）の値との間の1対1の関係が存在します。ゼロの値は、位置情報属性内の位置情報は、ユーザのクライアント・デバイスを指すことを示しています。
Numerical Value:
数値：
A numerical value of this token is '4'.
このトークンの数値は「4」です。
Name:
名前：
NAS_LOCATION
NAS_LOCATION
Description:
説明：
The numerical value representing NAS_LOCATION indicates that the RADIUS client MUST send a Location-Information Attribute that contains location information with the Entity Attribute expressing the value of one (1). Hence, there is a one-to-one relationship between the NAS_LOCATION token and the value of one (1) of the Entity Attribute inside the Location-Information Attribute. A value of one indicates that the location information in the Location-Information Attribute refers to the RADIUS client.
NAS_LOCATIONを表す数値は、RADIUSクライアントがオン（1）の値を表すエンティティ属性と位置情報を含む位置情報項目を送信する必要があることを示します。したがって、位置情報属性内のエンティティ属性のNAS_LOCATIONトークンと一つ（1）の値との間の1対1の関係が存在します。一方の値は、位置情報属性内の位置情報は、RADIUSクライアントを意味することを示しています。
Numerical Value:
数値：
A numerical value of this token is '8'.
このトークンの数値は「8」です。
Name:
名前：
FUTURE_REQUESTS
FUTURE_REQUESTS
Description:
説明：
The numerical value representing FUTURE_REQUESTS indicates that the RADIUS client MUST provide future Access-Requests for the same session with the same type of information as returned in the initial Access-Request message.
FUTURE_REQUESTSを表す数値は、RADIUSクライアントが初期アクセス要求メッセージで返される情報と同じタイプで同じセッションのための将来のアクセス・リクエストを提供しなければならないことを示しています。
Numerical Value:
数値：
A numerical value of this token is '16'.
このトークンの数値は「16」です。
Name:
名前：
NONE
無し
Description:
説明：
The RADIUS server uses this token to request that the RADIUS client stop sending location information.
RADIUSサーバは、RADIUSクライアントは、位置情報の送信を停止することを要求するために、このトークンを使用しています。
Numerical Value:
数値：
A numerical value of this token is '32'.
このトークンの数値は「32」です。
If neither the NAS_LOCATION nor the USERS_LOCATION bit is set, then per-default the location of the user's client device is returned (if authorization policies allow it). If both the NAS_LOCATION and the USERS_LOCATION bits are set, then the returned location information has to be put into separate attributes. If neither the CIVIC_LOCATION nor the GEO_LOCATION bit is set in the Requested-Location-Info Attribute, then no location information is returned. If both the CIVIC_LOCATION and the GEO_LOCATION bits are set, then the location information has to be put into separate attributes. The value of NAS_LOCATION and USERS_LOCATION refers to the location information requested via CIVIC_LOCATION and GEO_LOCATION.
NAS_LOCATIONもUSERS_LOCATIONビットどちらも設定されている場合は（認可ポリシーで許可されている場合）、ユーザーのクライアントデバイスのその後毎のデフォルトの場所が返されます。 NAS_LOCATIONとUSERS_LOCATIONビットの両方が設定されている場合、返される位置情報は、別個の属性に入れなければなりません。 CIVIC_LOCATIONもGEO_LOCATIONビットのいずれもが要求され、ロケーション情報の属性に設定されている場合は、何の位置情報が返されません。 CIVIC_LOCATIONとGEO_LOCATION両方のビットが設定されている場合、位置情報は、別個の属性に入れなければなりません。 NAS_LOCATIONとUSERS_LOCATIONの値がCIVIC_LOCATIONとGEO_LOCATIONを介して要求された位置情報を指します。
As an example, if the bits for NAS_LOCATION, USERS_LOCATION, and GEO_LOCATION are set, then the location information of the RADIUS client and the users' client device are returned in a geospatial-location format.
NAS_LOCATION、USERS_LOCATION、及びGEO_LOCATIONためのビットが設定されている場合、一例として、次に、RADIUSクライアントとユーザーのクライアントデバイスの位置情報は地理空間的位置の形式で返されます。
The following table provides a guide to which attributes may be found in which RADIUS messages, and in what quantity.
次の表は、属性RADIUSメッセージここで、どのような量で見出されてもよいためのガイドを提供します。
Request Accept Reject Challenge Accounting # Attribute Request 0-1 0-1 0 0 0+ 126 Operator-Name 0+ 0 0 0 0+ 127 Location-Information 0+ 0 0 0 0+ 128 Location-Data 0-1 0-1 0-1 0-1 0-1 129 Basic-Location-Policy-Rules 0-1 0-1 0-1 0-1 0-1 130 Extended-Location-Policy-Rules 0-1 0 0 0 0 131 Location-Capable 0 0-1 0 0-1 0 132 Requested-Location-Info 0 0 0-1 0 0 101 Error-Cause (*)
要求は、0-1 0-1 0 0 0 + 126オペレータ名0+ 0チャレンジ会計＃の属性要求を拒否0 0 0 + 127位置情報0+ 0 0 0 0 + 128場所-データ0-1 0-1を受け入れます0-1 0-1 0-1 129ベーシック・ロケーションポリシールール0-1 0-1 0-1 0-1 0-1 130拡張・ロケーションポリシールール0-1 0 0 0 0 131、場所に可能0 0-1 0 0-1 0 132要求-ロケーション情報0 0 0-1 0 0 101エラー - 原因（*）
(*) Note: The Error-Cause Attribute contains the value for the 'Location-Info-Required' error.
（*）注意：エラー原因の属性は、「ロケーション情報-必要」というエラーの値が含まれています。
Change-of-Authorization Messages
チェンジ・オブ・認証メッセージ
Request ACK NAK # Attribute 0-1 0 0 129 Basic-Location-Policy-Rules 0-1 0 0 130 Extended-Location-Policy-Rules 0-1 0 0 132 Requested-Location-Info
要求ACK NAKの＃0-1 0 0 130拡張 - ロケーション・ポリシー・ルール0-1 0 0 132要求-ロケーション情報0-1 0 0 129基本-場所-ポリシールール属性
Legend:
伝説：
0 This attribute MUST NOT be present. 0+ Zero or more instances of this attribute MAY be present. 0-1 Zero or one instance of this attribute MAY be present. 1 Exactly one instance of this attribute MUST be present. 1+ One or more of these attributes MUST be present.
0この属性は存在してはなりません。 0+この属性のゼロ以上のインスタンスが存在してもよいです。この属性の0-1ゼロまたは1つのインスタンスが存在してもよいです。この属性の1つのちょうど1つのインスタンスが存在しなければなりません。 1+これらの属性の1つ以上が存在しなければなりません。
Figure 7: Table of Attributes
図7：属性の表
The Error-Cause Attribute is defined in [RFC5176].
エラー原因の属性は、[RFC5176]で定義されています。
The Location-Information and the Location-Data Attribute MAY appear more than once. For example, if the server asks for civic and geospatial location information, two Location-Information Attributes need to be sent.
位置情報およびロケーションデータ属性が複数回表示されることがあります。サーバーは、市民や地理位置情報を要求した場合、2位置情報の属性を送信する必要があります。
The attributes defined in this document are not used in any messages other than the ones listed in Figure 7.
この文書で定義された属性は、図7に記載されているもの以外のメッセージで使用されていません。
IANA allocated a new value (509) from the Error-Cause registry with the semantics of 'Location-Info-Required'.
IANAは、「場所・インフォ必須」の意味でエラー-原因レジストリから新しい値（509）を割り当てました。
When used in Diameter, the attributes defined in this specification can be used as Diameter attribute-value pairs (AVPs) from the code space 1-255 (RADIUS attribute-compatibility space). No additional Diameter code values are therefore allocated. The data types and flag rules, as defined in [RFC3588], for the Diameter AVPs are as follows:
直径が使用される場合、本明細書で定義された属性は、コードスペース1-255（RADIUS属性互換空間）から直径属性値ペア（AVPの）として使用することができます。追加直径コード値は、したがって、割り当てられていません。次のように直径のAVPのために、[RFC3588]で定義されるデータ型とフラグ規則は、次のとおりです。
+---------------------+
| AVP Flag rules |
+----+-----+------+-----+----+
| | |SHOULD| MUST| |
Attribute Name Value Type |MUST| MAY | NOT | NOT|Encr|
+---------------------------------+----+-----+------+-----+----+
|Operator-Name OctetString| | P | | V,M | Y |
|Location-Information OctetString| | P | | V,M | Y |
|Location-Data OctetString| | P | | V,M | Y |
|Basic-Location- | | | | | |
| Policy-Rules OctetString| | P | | V,M | Y |
|Extended-Location- | | | | | |
| Policy-Rules OctetString| | P | | V,M | Y |
|Requested- | | | | | |
| Location-Info OctetString| | P | | V,M | Y |
|Location-Capable OctetString| | P | | V,M | Y |
+---------------------------------+----+-----+------+-----+----+
The RADIUS attributes in this specification have no special translation requirements for Diameter-to-RADIUS or RADIUS-to-Diameter gateways; they are copied as is, except for changes relating to headers, alignment, and padding. See also Section 4.1 of [RFC3588] and Section 9 of [RFC4005].
RADIUSは、この仕様書の直径ツーRADIUSまたはRADIUS対直径のゲートウェイのための特別な翻訳要件を持っていない属性。彼らは、ヘッダー、位置合わせ、及びパディングに関連する変更点を除いて、そのままコピーされます。また、[RFC4005]の[RFC3588]及び第9のセクション4.1を参照してください。
What this specification says about the applicability of the attributes for RADIUS Access-Request packets applies in Diameter to AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072]. What is said about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or Diameter-EAP-Answer [RFC4072] with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. What is said about Access-Accept applies in Diameter to AA-Answer or Diameter-EAP-Answer messages that indicate success. Similarly, what is said about RADIUS Access-Reject packets applies in Diameter to AA-Answer or Diameter-EAP-Answer messages that indicate failure.
何この仕様は、RADIUSアクセス要求パケットの属性の適用可能性について言うことはAA-リクエスト[RFC4005]または直径-EAP-要求[RFC4072]に直径が適用されます。どのようなアクセスチャレンジについて語っていることの結果、コードAVPがDIAMETER_MULTI_ROUND_AUTHに設定してAA-回答[RFC4005]または直径-EAP-回答[RFC4072]に直径が適用されます。言われて何成功を示すAA-回答または直径-EAP-回答メッセージに直径が適用されるアクセス - 受け入れます。失敗を示すAA-回答または直径-EAP-回答メッセージに直径が適用されるRADIUSパケットのアクセスが拒否について同様に、何を言われています。
What is said about CoA-Request applies in Diameter to Re-Auth-Request [RFC4005].
何のCoA-要求が再認証リクエスト[RFC4005]に直径が適用さについて語っています。
What is said about Accounting-Request applies in Diameter to Accounting-Request [RFC4005] as well.
何アカウンティング要求について言われていることだけでなくアカウンティング要求[RFC4005]に直径が適用されます。
Note that these AVPs may be used by Diameter applications other than RFC 4005 [RFC4005] and RFC 4072 [RFC4072]. The above-mentioned applications are, however, likely to be relevant in the context of this document.
これらのAVPは、RFC 4005 [RFC4005]及びRFC 4072 [RFC4072]以外のDiameterアプリケーションによって使用されてもよいことに留意されたいです。上記のアプリケーションは、しかし、この文書の文脈では、関連する可能性があります。
A number of security aspects are relevant for the distribution of location information via RADIUS. These aspects are discussed in separate subsections.
セキュリティ面の数は、RADIUSを介して位置情報の分布に関連します。これらの態様は、別のサブセクションで説明されています。
Requirements for the protection of a Location Object are defined in [RFC3693] -- namely, mutual end-point authentication, data object integrity, data object confidentiality, and replay protection.
すなわち、相互エンドポイント認証、データオブジェクトの完全性、データオブジェクトの機密性、及びリプレイ保護 - ロケーションオブジェクトの保護のための要件は[RFC3693]で定義されています。
If no authentication, integrity, and replay protection between the participating RADIUS entities is provided, then adversaries can spoof and modify transmitted attributes. Two security mechanisms are proposed for RADIUS:
参加RADIUSエンティティ間の認証、整合性、および再生保護が提供されない場合、その敵は偽装と送信属性を変更することができます。 2つのセキュリティメカニズムは、RADIUSのために提案されています。
o [RFC2865] proposes the usage of a static key that raised concerns regarding the lack of dynamic key management. At the time of writing, work is ongoing to address some shortcomings of the [RFC2865] attribute regarding security protection.
O [RFC2865]は、動的キー管理の欠如に関する懸念を提起した静的なキーの使用法を提案しています。執筆時点では、作業には、セキュリティ保護に関する[RFC2865]属性のいくつかの欠点に対処するために進行中です。
o RADIUS over IPsec [RFC3579] enables the use of standard key-management mechanisms, such as Kerberized Internet Negotiation of Keys (KINK), the Internet Key Exchange Protocol (IKE), and IKEv2 [RFC4306], to establish IPsec security associations. Confidentiality protection MUST be used to prevent an eavesdropper from gaining access to location information. Confidentiality protection is already present for other reasons in many environments, such as for the transport of keying material in the context of Extensible Authentication Protocol (EAP) authentication and authorization. Hence, this requirement is, in many environments, already fulfilled. Mutual authentication MUST be provided between neighboring RADIUS entities to prevent man-in-the-middle attacks. Since mutual authentication is already required for key transport within RADIUS messages, it does not represent a deployment obstacle. Since IPsec protection is already suggested as a mechanism to protect RADIUS, no additional considerations need to be addressed beyond those described in [RFC3579].
IPsecの[RFC3579]以上のOのRADIUSは、IPsecセキュリティアソシエーションを確立するために、キーのKerberos対応インターネット交渉（KINK）、インターネット鍵交換プロトコル（IKE）、およびIKEv2の[RFC4306]などの標準的な鍵管理メカニズムの使用を可能にします。機密性の保護は、位置情報へのアクセスを得ることから、盗聴者を防ぐために使用しなければなりません。機密保護は既にそのような拡張認証プロトコル（EAP）認証および許可の文脈において鍵材料を輸送するためのような多くの環境では他の理由のために存在します。したがって、この要件は、多くの環境では、すでに満たされています。相互認証は、man-in-the-middle攻撃を防ぐために、隣接RADIUSエンティティとの間に設けなければなりません。相互認証がすでにRADIUSメッセージ内の主要な輸送のために必要とされるので、展開の障害を示すものではありません。 IPsec保護は、すでにRADIUSを保護するためのメカニズムとして提案されているので、追加の考慮事項は、[RFC3579]に記載されているものを超えて対処する必要がありません。
In case IPsec protection is not available for some reason and RADIUS-specific security mechanisms have to be used, then the following considerations apply. The Access-Request message is not integrity protected. This would allow an adversary to change the contents of the Location Object or to insert, modify, and delete attributes or individual fields. To address these problems, the Message-Authenticator (80) can be used to integrity protect the entire Access-Request packet. The Message-Authenticator (80) is also required when EAP is used and, hence, is supported by many modern RADIUS servers.
場合にはIPsec保護が何らかの理由で利用できないとRADIUS固有のセキュリティ・メカニズムを使用する必要があり、その後、次の点に注意してください。 Access-Requestメッセージは、完全性が保護されていません。これは、敵がLocationオブジェクトの内容を変更したり、挿入するために、変更、および属性や個々のフィールドを削除できるようになります。これらの問題に対処するために、メッセージ・オーセンティケータ（80）は、全体のAccess-Requestパケットを保護する整合性に使用することができます。メッセージ認証（80）も、したがって、EAPを使用する場合に必要とされるが、多くの近代的なRADIUSサーバによってサポートされています。
Access-Request packets including location attribute(s) without a Message-Authenticator (80) Attribute SHOULD be silently discarded by the RADIUS server. A RADIUS server supporting location attributes MUST calculate the correct value of the Message-Authenticator (80) and MUST silently discard the packet if it does not match the value sent.
属性は、サイレントRADIUSサーバによって廃棄されるべきであるメッセージ認証なしの場所属性（複数可）を含むアクセス要求パケット（80）。位置属性をサポートするRADIUSサーバは、メッセージオーセンティケータ（80）の正しい値を計算しなければならないし、それが送信された値と一致しない場合静かにパケットを捨てなければなりません。
Access-Accept messages, including location attribute(s), without a Message-Authenticator (80) Attribute SHOULD be silently discarded by the NAS. An NAS supporting location attributes MUST calculate the correct value of a received Message-Authenticator (80) and MUST silently discard the packet if it does not match the value sent.
メッセージ認証なしで、場所属性（複数可）を含むメッセージを、アクセス・受け入れ（80）属性が黙っNASによって捨てられるべきです。 NAS支持位置は、受信したメッセージ認証（80）の正しい値を計算しなければならない属性と、それが送信された値と一致しない場合静かにパケットを捨てなければなりません。
RADIUS and Diameter make some assumptions about the trust between traversed RADIUS entities in the sense that object-level security is not provided by either RADIUS or Diameter. Hence, some trust has to be placed on the RADIUS entities to behave according to the defined rules. Furthermore, the RADIUS protocol does not involve the user in their protocol interaction except for tunneling authentication information (such as EAP messages) through their infrastructure. RADIUS and Diameter have even become a de facto protocol for key distribution for network-access authentication applications. Hence, in the past there were some concerns about the trust placed into the infrastructure -- particularly from the security area -- when it comes to keying. The EAP keying infrastructure is described in [RFC4282].
RADIUSおよび直径は、オブジェクトレベルのセキュリティがRADIUSまたは直径のどちらかによって提供されていないという意味で、横断RADIUSエンティティ間の信頼関係に関するいくつかの仮定を行います。したがって、いくつかの信頼は、定義されたルールに従って動作するようにRADIUSエンティティ上に配置されなければなりません。また、RADIUSプロトコルはインフラストラクチャを介してトンネル認証情報（例えば、EAPメッセージなど）を除いて、それらのプロトコル相互作用にユーザを必要としません。 RADIUSおよび直径はさえ、ネットワークアクセス認証アプリケーションのための鍵の配布のための事実上のプロトコルとなっています。したがって、過去にインフラに置い信頼に関するいくつかの懸念があった - 特にセキュリティエリアから - それはキーイングに来るとき。 EAPキーイング・インフラストラクチャは、[RFC4282]に記載されています。
This section discusses privacy implications for the distribution of location information within RADIUS. Note also that it is possible for the RADIUS server to obtain some amount of location information from the NAS identifier. This document, however, describes procedures to convey more accurate location information about the end host and/or the network. In a number of deployment environments, location information about the network also reveals the current location of the user with a certain degree of precision, depending on the location-determination mechanism used, the update frequency, the size of the network, and other factors, such as movement traces.
このセクションでは、RADIUS内の位置情報の配信のためのプライバシーへの影響について説明します。 RADIUSサーバがNAS識別子から位置情報のいくつかの量を入手することが可能であることにも留意されたいです。この文書では、しかし、エンドホストおよび/またはネットワークに関するより正確な位置情報を伝達するための手順を記載しています。デプロイメント環境の数は、ネットワークの位置情報を使用しても位置決意機構、更新頻度、ネットワークの大きさ、および他の要因に応じて、精度のある程度ユーザの現在位置を明らかにする、移動軌跡など。
Three types of use cases have to be differentiated:
ユースケースの3つのタイプが区別されなければなりません：
o The RADIUS server does not want to receive location information from the RADIUS client.
O RADIUSサーバは、RADIUSクライアントからの位置情報を受信したくはありません。
o In case there is an out-of-band agreement between the entity responsible for the NAS and the entity operating the RADIUS server, location information may be sent without an explicit request from the RADIUS server.
O NASとRADIUSサーバを動作させるエンティティを担当するエンティティとの間の帯域外合意がある場合に、位置情報は、RADIUSサーバからの明示的な要求なしに送信することができます。
o The RADIUS server dynamically requests location information from the NAS.
O RADIUSサーバを動的にNASからの位置情報を要求します。
The RADIUS client MUST behave according to the following guidelines:
RADIUSクライアントは、次のガイドラインに従って動作しなければなりません。
o If neither an out-of-band agreement exists nor location information is requested by the RADIUS server, then location information is not disclosed by the RADIUS client.
どちらもアウトオブバンドの合意が存在しないでも位置情報がRADIUSサーバによって要求された場合、O、その後、位置情報は、RADIUSクライアントによって開示されていません。
o The RADIUS client MUST pass location information to other entities (e.g., when information is written to a local database or to the log files) only together with the policy rules. The entity receiving the location information (together with the policies) MUST follow the guidance given with these rules.
O RADIUSクライアントと他のエンティティの位置情報を渡す必要があり（例えば、情報は、ローカルデータベースまたはログファイルに書き込まれている場合）、ポリシールールにのみ一緒。 （一緒にポリシーに）位置情報を受信エンティティは、これらの規則で指定された指針に従わなければなりません。
o A RADIUS client MUST include Basic-Location-Policy-Rules and Extended-Location-Policy-Rules Attributes that are configured within an Access-Request packet.
O RADIUSクライアントは、基本的な-場所-ポリシールールと拡張 - ロケーション-ポリシールールのAccess-Requestパケット内に構成されている属性を含める必要があります。
o NAS implementations supporting this specification, which are configured to provide location information, MUST echo Basic-Location-Policy-Rules and Extended-Location-Policy-Rules Attributes unmodified within a subsequent Access-Request packet. In addition, an Access-Request packet sent with a Service-Type value of "Authorize Only" MUST include the Basic-Location-Policy-Rules or Extended-Location-Policy-Rules Attributes that were received in a previous Access-Accept if the FUTURE_REQUESTS flag was set in the Requested-Location-Info Attribute.
O位置情報を提供するように構成されているこの仕様をサポートするNAS実装は、基本-ロケーションポリシールールをエコーしなければならないおよび拡張ロケーションポリシールールは、後続のアクセス要求パケット内に未修飾の属性。また、アクセス要求パケットは、ポリシールールが拡張 - ロケーション以前に受けたことの属性「だけが認可する」基本 - ロケーション・ポリシー・ルールまたはを含まなければならないのサービスタイプの値を使用して送信される場合、接続許可FUTURE_REQUESTSフラグが要求され、ロケーション情報の属性に設定されました。
The RADIUS server is a natural place for storing authorization policies since the user typically has some sort of trust relationship with the entity operating the RADIUS server. Once the infrastructure is deployed and location-aware applications are available, there might be a strong desire to use location information for other purposes as well.
RADIUSサーバは、ユーザが一般的にRADIUSサーバを操作するエンティティとの信頼関係のいくつかの並べ替えを持っているので、認可ポリシーを格納するための自然な場所です。インフラストラクチャを展開し、位置認識アプリケーションが利用可能であるならば、他の目的のために位置情報を使用する強い願望があるかもしれません。
The Common Policy framework [RFC4745] that was extended for geolocation privacy [GEO-POLICY] is tailored for this purpose. The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825] gives users the ability to change their privacy policies using a standardized protocol. These policies are an important tool for limiting further distribution of the user's location to other location-based services.
ジオロケーションプライバシーのために延長された共通のポリシーフレームワーク[RFC4745] [GEO-POLICY]は、この目的のために調整されています。拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）[RFC4825]は、ユーザーが標準化されたプロトコルを使用して、彼らのプライバシーポリシーを変更する機能を提供します。これらのポリシーは、他のロケーションベースのサービスへのユーザの位置の更なる配布を制限するための重要なツールです。
The RADIUS server MUST behave according to the following guidelines:
RADIUSサーバは、次のガイドラインに従って動作しなければなりません。
o The RADIUS server MUST attach available rules to the Access-Accept, Access-Reject, or Access-Challenge message when the RADIUS client is supposed to provide location information.
O RADIUSサーバが利用可能にルールを添付しなければならないのAccess-受け入れRADIUSクライアントが位置情報を提供することになっているとき、アクセスが拒否、またはアクセスチャレンジメッセージ。
o When location information is made available to other entities (e.g., writing to stable storage for later billing processing), then the RADIUS server MUST attach the privacy rules to location information.
位置情報は、他のエンティティに利用可能になる場合、O（例えば、後で課金処理のための安定したストレージに書き込む）、次いで、RADIUSサーバは、位置情報のプライバシールールを添付しなければなりません。
A RADIUS proxy, behaving as a combined RADIUS client and RADIUS server, MUST follow the rules described in Sections 7.2.1 and 7.2.2.
RADIUSプロキシは、合成RADIUSクライアントとRADIUSサーバーとして動作し、セクション7.2.1および7.2.2に記載の規則に従わなければなりません。
For the envisioned usage scenarios, the identity of the user and his device is tightly coupled to the transfer of location information. If the identity can be determined by the visited network or RADIUS brokers, then it is possible to correlate location information with a particular user. As such, it allows the visited network and brokers to learn the movement patterns of users.
想定される使用シナリオのために、ユーザのアイデンティティおよび彼のデバイスは、しっかり位置情報の転送に結合されています。同一性は、訪問先ネットワーク又はRADIUSブローカーによって決定することができる場合、特定のユーザに位置情報を相関させることが可能です。このように、それは、訪問先ネットワークとブローカーは、ユーザーの移動パターンを学習することができます。
The user's identity can be "leaked" to the visited network or RADIUS brokers in a number of ways:
ユーザのアイデンティティは、いくつかの方法で訪問先ネットワークまたはRADIUSブローカーに「リークした」ことができます。
o The user's device may employ a fixed Media Access Control (MAC) address or base its IP address on such an address. This enables the correlation of the particular device to its different locations. Techniques exist to avoid the use of an IP address that is based on a MAC address [RFC4941]. Some link layers make it possible to avoid MAC addresses or change them dynamically.
Oユーザーのデバイスは、固定されたメディアアクセス制御（MAC）アドレスを使用するか、そのようなアドレスをそのIPアドレスをベースできます。これは、別の場所に特定の装置の相関を可能にします。テクニックは、MACアドレス[RFC4941]に基づいてIPアドレスの使用を避けるために存在します。いくつかのリンク層は、それが可能なMACアドレスを回避または動的に変更するために作ります。
o Network-access authentication procedures, such as the PPP Challenge Handshake Authentication Protocol (CHAP) [RFC1994] or EAP [RFC4187], may reveal the user's identity as a part of the authentication procedure. Techniques exist to avoid this problem in EAP methods, for instance by employing private Network Access Identifiers (NAIs) [RFC4282] in the EAP Identity Response message and by method-specific private identity exchanges in the EAP method (e.g., [RFC4187], [RFC5281], [PEAP], and [RFC5106]). Support for identity privacy within CHAP is not available.
OこのようなPPPチャレンジハンドシェイク認証プロトコル（CHAP）[RFC1994]またはEAP [RFC4187]などのネットワークアクセス認証手順は、認証手順の一部として、ユーザの身元を明らかにすることができます。テクニックは、EAPアイデンティティ応答メッセージにし、EAP方式におけるメソッド固有のプライベートアイデンティティの交換（例えば、[RFC4187]、[によってプライベートネットワークアクセス識別子（のNAI）[RFC4282]を使用することによって、たとえば、EAP方法でこの問題を回避するために存在しますRFC5281]、[PEAP]、および[RFC5106]）。 CHAP内のアイデンティティプライバシーのサポートは利用できません。
o RADIUS may return information from the home network to the visited one in a manner that makes it possible to either identify the user or at least correlate his session with other sessions, such as the use of static data in a Class Attribute [RFC2865] or in some accounting attribute usage scenarios [RFC4372].
O RADIUSは、いずれかのユーザーを識別したり、少なくとも、そのようなクラス属性[RFC2865]または内の静的データの使用など他のセッション、と彼のセッションを相関させることを可能にする方法で訪問したものに、ホームネットワークからの情報を返すことがあります。いくつかの会計属性の使用シナリオでは、[RFC4372]。
o Mobility protocols may reveal some long-term identifier, such as a home address.
Oモビリティプロトコルは、このようなホームアドレスとして、いくつかの長期的な識別子を明らかにすることができます。
o Application-layer protocols may reveal other permanent identifiers.
Oアプリケーション層プロトコルは、他の永久的な識別子を公開してもよいです。
To prevent the correlation of identities with location information, it is necessary to prevent leakage of identity information from all sources, not just one.
位置情報とアイデンティティの相関を防止するためには、すべてのソースだけではなく、1から身元情報の漏洩を防止する必要があります。
Unfortunately, most users are not educated about the importance of identity confidentiality, and some protocols lack support for identity-privacy mechanisms. This problem is made worse by the fact that users may be unable to choose particular protocols, as the choice is often dictated by the type of network operator they use, the type of network they wish to access, the kind of equipment they have, or the type of authentication method they are using.
残念ながら、ほとんどのユーザーは、アイデンティティの機密性の重要性について教育されていない、といくつかのプロトコルは、アイデンティティ・プライバシーメカニズムをサポートしていません。この問題は、選択は、多くの場合、彼らが使用するネットワークオペレータの種類によって決定されるよう、ユーザーは、特定のプロトコルを選択することができない可能性があるという事実によって悪化している、ネットワークの種類は、彼らが持っている機器の種類、アクセスしたい、または認証方法の種類は、彼らが使用しています。
A scenario where the user is attached to the home network is, from a privacy point of view, simpler than a scenario where a user roams into a visited network, since the NAS and the home RADIUS server are in the same administrative domain. No direct relationship between the visited and the home network operator may be available, and some RADIUS brokers need to be consulted. With subscription-based network access as used today, the user has a contractual relationship with the home network provider that could (theoretically) allow higher privacy considerations to be applied (including policy rules stored at the home network itself, for the purpose of restricting further distribution).
ユーザーがホームネットワークに接続されているシナリオは、ビューのプライバシーの観点から、NASとホームRADIUSサーバが同じ管理ドメインにあるため、ユーザは、訪問先ネットワークにローミングシナリオよりも簡単です。訪問し、ホームネットワークオペレータが利用可能であってもよく、一部のRADIUSのブローカーが相談する必要があるとの間には直接的な関係はありません。今日使用されるようなサブスクリプションベースのネットワーク・アクセスでは、ユーザーは、（理論的に）高いプライバシーの配慮をさらに制限するために、ホームネットワーク自体に格納されたポリシールールを含む（適用される可能性があり、ホームネットワークプロバイダとの契約関係を持っています分布）。
In many cases it is necessary to secure the transport of location information along the RADIUS infrastructure. Mechanisms to achieve this functionality are discussed in Section 7.1.
多くの場合、RADIUSインフラストラクチャに沿って位置情報の輸送を確保する必要があります。この機能を実現するためのメカニズムは、7.1節で議論されています。
The Attribute Types and Attribute Values defined in this document have been registered by the Internet Assigned Numbers Authority (IANA) from the RADIUS namespaces as described in the "IANA Considerations" section of RFC 3575 [RFC3575], in accordance with BCP 26 [RFC5226]. Additionally, the Attribute Type has been registered in the Diameter namespace. For RADIUS attributes and registries created by this document, IANA placed them in the Radius Types registry.
この文書で定義された属性タイプと属性値は、BCP 26 [RFC5226]に従って、RFC 3575 [RFC3575]の「IANAの考慮事項」の項で説明したようにRADIUS名前空間からInternet Assigned Numbers Authority（IANA）によって登録されています。また、属性タイプは、Diameter名前空間に登録されています。 RADIUS属性と、この文書が作成したレジストリのために、IANAは、RADIUSタイプレジストリにそれらを置きました。
This document defines the following attributes:
このドキュメントでは、次の属性を定義します。
Operator-Name
Location-Information
Location-Data
Basic-Location-Policy-Rules
Extended-Location-Policy-Rules
Location-Capable
Requested-Location-Info
Please refer to Section 5 for the registered list of numbers.
番号の登録リストについては、第5章を参照してください。
IANA has also assigned a new value (509) for the Error-Cause Attribute [RFC5176] of "Location-Info-Required" according to this document.
IANAはまた、この文書によると、「場所・インフォ必要」のエラー原因の属性[RFC5176]の新しい値（509）が割り当てられています。
Additionally, IANA created the following new registries listed in the subsections below.
また、IANAは以下のサブセクションに記載されている次の新しいレジストリを作成しました。
This document also defines an Operator Namespace Identifier registry (used in the Namespace ID field of the Operator-Name Attribute). Note that this document requests IANA only to maintain a registry of existing namespaces for use in this identifier field, and not to establish any namespaces or place any values within namespaces.
この文書はまた、（オペレータname属性の名前空間IDフィールドに使用される）オペレータネームスペース識別子レジストリを定義します。このドキュメントはIANAがこれだけ識別子フィールドで使用するために既存の名前空間のレジストリを維持するために、および任意の名前空間を確立したり、名前空間内の任意の値を配置しないように要請することに注意してください。
IANA added the following values to the Operator Namespace Identifier registry using a numerical identifier (allocated in sequence), a token for the operator namespace, and a contact person for the registry.
IANAは、（順序で割り当てられた）数値識別子、オペレータの名前空間のためのトークン、およびレジストリの担当者を使用して、オペレータネームスペース識別子レジストリに以下の値を追加しました。
+----------+--------------------+------------------------------------+
|Identifier| Operator Namespace | Contact Person |
| | Token | |
+----------+--------------------+------------------------------------+
| 0x30 | TADIG | TD.13 Coordinator |
| | | (td13@gsm.org) |
| 0x31 | REALM | IETF O&M Area Directors |
| | | (ops-ads@ietf.org) |
| 0x32 | E212 | ITU Director |
| | | (tsbdir@itu.int) |
| 0x33 | ICC | ITU Director |
| | | (tsbdir@itu.int) |
+----------+--------------------+------------------------------------+
Note that the above identifier values represent the ASCII value '0' (decimal 48 or hex 0x30), '1' (decimal 49, or hex 0x31), '2' (decimal 50, or hex 0x32), and '3' (decimal 51, or hex 0x33). This encoding was chosen to simplify parsing.
上記識別子の値が '0'（十進48または六角0x30から）、 '1'（49進、または六角0x31）、 '2'（十進50、又は六角0x32の）ASCII値を表し、 '3' ことに注意してください（小数51、又は六角0x33の）。このエンコードは、解析を簡素化するために選ばれました。
Requests to IANA for a new value for a Namespace ID, i.e., values from 0x34 to 0xFE, will be approved by Expert Review. A designated expert will be appointed by the IESG.
名前空間IDの新しい値のためのIANAへの要求は、すなわち、0x34のから0xFEのに値が、専門家レビューによって承認されます。指定された専門家はIESGによって任命されます。
The Expert Reviewer should ensure that a new entry is indeed required or could fit within an existing database, e.g., whether there is a real requirement to provide a token for a Namespace ID because one is already up and running, or whether the REALM identifier plus the name should be recommended to the requester. In addition, the Expert Reviewer should ascertain to some reasonable degree of diligence that a new entry is a correct reference to an operator namespace whenever a new one is registered.
エキスパートレビュー、新たなエントリは、1つが稼働して既にあるので、名前空間IDのトークンを提供するために、実際の要件があるかどうかを、実際に必要とされるか、既存のデータベース内に収まることができ、例えばことを保証しなければならないかどうかREALM識別子をプラス名前は、要求者に推奨されるべきです。加えて、専門家レビューは、新しいエントリが新しいものが登録されるたびにオペレータネームスペースへの正しい参照である勤勉のいくつかの合理的な程度を確かめるべきです。
Section 4.2 defines the Location-Information Attribute and a Code field that contains an 8-bit integer value. Two values, zero and one, are defined in this document, namely:
セクション4.2は、位置情報項目と、8ビットの整数値を含むコード・フィールドを定義します。二つの値、0と1が、つまり、この文書で定義されています。
Value (0): Civic location profile described in Section 4.3.1
値（0）：セクション4.3.1に記載シビックロケーション・プロファイル
Value (1): Geospatial location profile described in Section 4.3.2
値（1）：4.3.2項で説明地理空間ロケーション・プロファイル
The remaining values are reserved for future use.
残りの値は、将来の使用のために予約されています。
Following the policies outlined in [RFC3575], the available bits with a description of their semantics will be assigned after the Expert Review process. Updates can be provided based on expert approval only. Based on expert approval, it is possible to mark entries as "deprecated". A designated expert will be appointed by the IESG.
[RFC3575]に概説された方針に続いて、その意味の説明と利用可能なビットは、専門家レビュー・プロセスの後に割り当てられます。アップデートは、専門家の承認に基づいて提供することができます。専門家の承認に基づいて、「非推奨」としてエントリをマークすることが可能です。指定された専門家はIESGによって任命されます。
Each registration must include the value and the corresponding semantics of the defined location profile.
各登録値と定義されたロケーションプロファイルの対応する意味を含まなければなりません。
Section 4.6 defines the Location-Capable Attribute that contains a bit map. 32 bits are available, from which 4 bits are defined by this document. This document creates a new IANA registry for the Location-Capable Attribute. IANA added the following values to this registry:
4.6節は、ビットマップが含まれている場所可能な属性を定義します。 32ビットは4ビットがこのドキュメントによって定義され、そこから、入手可能です。この文書では、場所対応の属性の新しいIANAレジストリを作成します。 IANAは、このレジストリに以下の値を追加しました：
+----------+----------------------+
| Value | Capability Token |
+----------+----------------------+
| 1 | CIVIC_LOCATION |
| 2 | GEO_LOCATION |
| 4 | USERS_LOCATION |
| 8 | NAS_LOCATION |
+----------+----------------------+
Following the policies outlined in [RFC3575], the available bits with a description of their semantics will be assigned after the Expert Review process. Updates can be provided based on expert approval only. Based on expert approval, it is possible to mark entries as "deprecated". A designated expert will be appointed by the IESG.
[RFC3575]に概説された方針に続いて、その意味の説明と利用可能なビットは、専門家レビュー・プロセスの後に割り当てられます。アップデートは、専門家の承認に基づいて提供することができます。専門家の承認に基づいて、「非推奨」としてエントリをマークすることが可能です。指定された専門家はIESGによって任命されます。
Each registration must include:
それぞれの登録が含まれている必要があります
Name:
名前：
Capability Token (i.e., an identifier of the capability)
能力トークン（即ち、能力の識別子）
Description:
説明：
Brief description indicating the meaning of the 'info' element.
「情報」要素の意味を示す簡単な説明。
Numerical Value:
数値：
A numerical value that is placed into the Capability Attribute representing a bit in the bit-string of the Requested-Location-Info Attribute.
リクエスト・ロケーション情報項目のビットストリング内のビットを表す能力属性に置かれる数値。
Section 4.2 defines the Location-Information Attribute that contains an 8-bit Entity field. Two values are registered by this document, namely:
4.2節は、8ビットのエンティティのフィールドが含まれている位置情報属性を定義します。 2つの値はすなわち、この文書によって登録されています。
Value (0) describes the location of the user's client device.
値は（0）ユーザーのクライアントデバイスの位置を説明しています。
Value (1) describes the location of the RADIUS client.
値は、（1）RADIUSクライアントの場所を説明します。
All other values are reserved for future use.
他のすべての値は、将来の使用のために予約されています。
Following the policies outlined in [RFC3575], the available bits with a description of their semantics will be assigned after the Expert Review process. Updates can be provided based on expert approval only. Based on expert approval, it is possible to mark entries as "deprecated". A designated expert will be appointed by the IESG.
[RFC3575]に概説された方針に続いて、その意味の説明と利用可能なビットは、専門家レビュー・プロセスの後に割り当てられます。アップデートは、専門家の承認に基づいて提供することができます。専門家の承認に基づいて、「非推奨」としてエントリをマークすることが可能です。指定された専門家はIESGによって任命されます。
Each registration must include the value and a corresponding description.
各登録値と対応する記述を含まなければなりません。
Section 4.4 defines the Basic-Location-Policy-Rules Attribute that contains flags indicating privacy settings. 16 bits are available, from which a single bit, bit (0), indicating 'retransmission allowed' is defined by this document. Bits 1-15 are reserved for future use.
4.4節は、プライバシー設定を示すフラグが含まれている基本的な-場所-ポリシールールの属性を定義します。 16ビットは単一ビットが、ビットは（0）を示す「許容再送」はこのドキュメントによって定義されているから、入手可能です。ビット1-15は、将来の使用のために予約されています。
Following the policies outline in [RFC3575], the available bits with a description of their semantics will be assigned after the Expert Review process. Updates can be provided based on expert approval only. Based on expert approval, it is possible to mark entries as "deprecated". A designated expert will be appointed by the IESG.
[RFC3575]でポリシーの概要に続いて、その意味の説明と利用可能なビットは、専門家レビュー・プロセスの後に割り当てられます。アップデートは、専門家の承認に基づいて提供することができます。専門家の承認に基づいて、「非推奨」としてエントリをマークすることが可能です。指定された専門家はIESGによって任命されます。
Each registration must include the bit position and the semantics of the bit.
各登録は、ビット位置とビットの意味を含んでいなければなりません。
Section 4.7 defines the Requested-Location-Info Attribute that contains a bit map. 32 bits are available, from which 6 bits are defined by this document. This document creates a new IANA registry for the Requested-Location-Info Attribute. IANA added the following values to this registry:
4.7節は、ビットマップが含まれている要求 - ロケーション情報の属性を定義します。 32ビットは、6ビットがこのドキュメントによって定義され、そこから、入手可能です。この文書では、要求 - ロケーション-info属性のための新しいIANAレジストリを作成します。 IANAは、このレジストリに以下の値を追加しました：
+----------+----------------------+
| Value | Capability Token |
+----------+----------------------+
| 1 | CIVIC_LOCATION |
| 2 | GEO_LOCATION |
| 4 | USERS_LOCATION |
| 8 | NAS_LOCATION |
| 16 | FUTURE_REQUESTS |
| 32 | NONE |
+----------+----------------------+
The semantics of these values are defined in Section 4.7.
これらの値の意味は、4.7節で定義されています。
Following the policies outlined in [RFC3575], new Capability Tokens, with a description of their semantics for usage with the Requested-Location-Info Attribute, will be assigned after the Expert Review process. Updates can be provided based on expert approval only. Based on expert approval, it is possible to mark entries as "deprecated". A designated expert will be appointed by the IESG.
要求された-ロケーション情報との使用のためにその意味の説明を[RFC3575]に概説された方針、新機能のトークンを、続いて、専門家レビュー・プロセスの後に割り当てられます属性。アップデートは、専門家の承認に基づいて提供することができます。専門家の承認に基づいて、「非推奨」としてエントリをマークすることが可能です。指定された専門家はIESGによって任命されます。
Each registration must include:
それぞれの登録が含まれている必要があります
Name:
名前：
Capability Token (i.e., an identifier of the capability)
能力トークン（即ち、能力の識別子）
Description:
説明：
Brief description indicating the meaning of the 'info' element.
「情報」要素の意味を示す簡単な説明。
Numerical Value:
数値：
A numerical value that is placed into the Capability Attribute representing a bit in the bit-string of the Requested-Location-Info Attribute.
リクエスト・ロケーション情報項目のビットストリング内のビットを表す能力属性に置かれる数値。
The authors would like to thank the following people for their help with an initial version of this document and for their input: Chuck Black, Paul Congdon, Jouni Korhonen, Sami Ala-luukko, Farooq Bari, Ed Van Horne, Mark Grayson, Jukka Tuomi, Jorge Cuellar, and Christian Guenther.
作者はこのドキュメントの初期のバージョンで彼らの助けのために、その入力のため、以下の人々に感謝したいと思います：チャック・ブラック、ポールコングドン、Jouni Korhonen、サミアラ - luukko、ファルークバーリ、エド・ヴァン・ホーン、マーク・グレイソン、ユッカTuomi 、ホルヘクエリャル、およびキリスト教のギュンター。
Henning Schulzrinne provided the civic location information content found in this document. The geospatial location-information format is based on work done by James Polk, John Schnizlein, and Marc Linsner. The authorization policy format is based on the work done by Jon Peterson.
ヘニングSchulzrinneとは、この文書で見つかった市民の位置情報コンテンツを提供します。地理空間位置情報のフォーマットは、ジェームズ・ポーク、ジョンSchnizlein、そしてマーク・Linsnerによって行われた作業に基づいています。認可ポリシー形式はジョン・ピーターソンが行った作業に基づいています。
The authors would like to thank Victor Lortz, Anthony Leibovitz, Jose Puthenkulam, Bernrad Aboba, Jari Arkko, Parviz Yegani, Serge Manning, Kuntal Chowdury, Pasi Eronen, Blair Bullock and Eugene Chang for their feedback to an initial version of this document. We would like to thank Jari Arkko for his textual contributions. Lionel Morand provided detailed feedback on numerous issues. His comments helped to improve the quality of this document. Jouni Korhonen, Victor Fajardo, Tolga Asveren, and John Loughney helped us with the Diameter RADIUS interoperability section. Andreas Pashalidis reviewed a later version document and provided a number of comments. Alan DeKok, Lionel Morand, Jouni Korhonen, David Nelson, and Emile van Bergen provided guidance on the Requested-Location-Info Attribute and participated in the capability-exchange discussions. Allison Mankin, Jouni Korhonen, and Pasi Eronen provided text for the Operator Namespace Identifier registry. Jouni Korhonen interacted with the GSMA to find a contact person for the TADIG operator namespace, and Scott Bradner consulted the ITU-T to find a contact person for the E212 and the ICC operator namespace.
作者はこのドキュメントの初期バージョンへのフィードバックのためにビクターLortz、アンソニー・リーボビッツ、ホセPuthenkulam、Bernrad Aboba、ヤリArkko、Parviz Yegani、セルジュ・マニング、Kuntal Chowdury、パシEronen、ブレアBullockのとユージン・チャンに感謝したいと思います。私たちは、彼のテキストの貢献のためのヤリArkkoに感謝したいと思います。ライオネル・モランは、多くの問題について詳細なフィードバックを提供します。彼のコメントは、このドキュメントの品質を向上させるために役立ちました。 Jouni Korhonen、ビクターファハルド、トルガAsveren、ジョンLoughneyは、Diameter RADIUSの相互運用性のセクションで私たちを助けました。アンドレアスPashalidisは、以降のバージョンのドキュメントをレビューやコメントの数を提供します。アランDeKok、ライオネル・モラン、Jouni Korhonen、デビッド・ネルソン、そしてエミール・バンベルゲンは、要求された-ロケーション情報の属性に関するガイダンスを提供し、機能交換の議論に参加しました。アリソンマンキン、Jouni Korhonen、およびパシEronenは、オペレータの名前空間識別子レジストリのためのテキストを提供しました。 Jouni KorhonenはTADIGオペレーターの名前空間のための連絡担当者を見つけるために、GSMAと相互作用し、そしてスコット・ブラッドナーはE212とICCのオペレータの名前空間のための連絡担当者を見つけるために、ITU-Tを相談しました。
This document is based on the discussions within the IETF GEOPRIV Working Group. Therefore, the authors thank Henning Schulzrinne, James Polk, John Morris, Allison Mankin, Randall Gellens, Andrew Newton, Ted Hardie, and Jon Peterson for their time discussing a number of issues with us. We thank Stephen Hayes for aligning this work with 3GPP activities.
このドキュメントはIETF GEOPRIVワーキンググループ内での議論に基づいています。そのため、著者は私たちに多くの問題を議論する彼らの時間のためのヘニングSchulzrinneと、ジェームズ・ポーク、ジョン・モリス、アリソンマンキン、ランドールGellens、アンドリュー・ニュートン、テッドハーディー、およびジョンピーターソンに感謝します。私たちは、3GPPの活動でこの仕事を整列させるためのスティーブン・ヘイズに感謝します。
We would like to thank members of the Wimax Forum Global Roaming Working Group (GRWG) for their feedback on the Operator-Name attribute. Ray Jong Kiem helped us with his detailed description to correct the document.
私たちは、オペレータ-Name属性に彼らのフィードバックのためにWiMAXフォーラム・グローバルローミングワーキンググループ（GRWG）のメンバーに感謝したいと思います。レイジョンキエムは、文書を修正するために彼の詳細な説明で私たちを助けました。
The RADEXT Working Group chairs, David Nelson and Bernard Aboba, provided several draft reviews and we would like to thank them for the help and their patience.
RADEXTワーキンググループチェア、デビッド・ネルソンとバーナードAbobaは、いくつかのドラフトレビューを提供し、我々は助けと忍耐に感謝したいと思います。
Finally, we would like to thank Dan Romascanu, Glen Zorn, Russ Housley, Jari Arkko, Ralph Droms, Adrial Farrel, Tim Polk, and Lars Eggert for the IETF Last Call comments; Derek Atkins for his security area directorate review; and Yoshiko Chong for spotting a bug in the IANA Considerations section.
最後に、我々は、IETFラストコール・コメントのダンRomascanu、グレン・ソーン、ラスHousley、ヤリArkko、ラルフDroms、Adrialファレル、ティムポーク、およびラースエッゲルトに感謝したいと思います。彼のセキュリティエリア総局の審査のためのデレク・アトキンス。そして佳子チョンIANAの考慮事項のセクションでバグをスポッティングため。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル" [RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、 "ピュニコード：アプリケーションにおける国際化ドメイン名のUnicodeのブートストリングのエンコード（IDNA）"、RFC 3492、2003年3月。
[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月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004.
[RFC3825]ポーク、J.、Schnizlein、J.、およびM. Linsner、 "座標ベースのロケーションの設定については、動的ホスト構成プロトコル・オプション"、RFC 3825、2004年7月。
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[RFC4776] Schulzrinneと、H.、RFC 4776、2006年11月 "シビック用動的ホスト構成プロトコル（DHCPv4とDHCPv6の）オプションは、構成情報をアドレス"。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
、RFC 5176、2008年1月[RFC5176]千葉、M.、Dommety、G.、エクランド、M.、ミトン、D.、およびB. Aboba、 "ユーザーサービス（RADIUS）でリモート認証ダイヤルへのダイナミックな承認拡張機能"。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[GEO-POLICY] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J. Polk, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", Work in Progress, February 2009.
[GEO-POLICY] Schulzrinneと、H.、Tschofenig、H.、モリス、J.、クエリャル、J.、およびJ.ポーク、 "ジオロケーション・ポリシー：位置情報のためのプライバシー設定を表現するためのドキュメントフォーマット"、作業進行中、 2009年2月。
[GMLv3] "Open Geography Markup Language (GML) Implementation Specification", OGC 02-023r4, January 2003, <http://www.opengis.org/techno/implementation.htm>.
[GMLv3] "オープン地理マークアップ言語（GML）実装仕様"、OGC 02-023r4、2003年1月、<http://www.opengis.org/techno/implementation.htm>。
[GSM] "TADIG Naming Conventions", Version 4.1, GSM Association Official Document TD.13, June 2006.
[GSM] "TADIG命名規則"、バージョン4.1、GSM協会の公式文書TD.13、2006年6月。
[ISO] "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes", ISO 3166-1, 1997.
[ISO]「の国とその下位区分の名前の表現のためのコード - 第1部：国コード」、ISO 3166-1、1997。
[ITU1400] "Designations for interconnections among operators' networks", ITU-T Recommendation M.1400, January 2004.
[ITU1400] "事業者のネットワーク間の相互接続のための呼称"、ITU-T勧告M.1400、2004年1月。
[ITU212] "The international identification plan for mobile terminals and mobile users", ITU-T Recommendation E.212, May 2004.
[ITU212]「の携帯端末やモバイルユーザーのための国際識別計画」、ITU-T勧告E.212、2004年5月。
[PEAP] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
[PEAP] Josefsson氏、S.、Palekar、A.、サイモン、D.、およびG.ツォルン、 "保護されたEAPプロトコル（PEAP）バージョン2"、進歩、2004年10月に作業。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装"、RFC 1305、1992年3月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]シンプソン、W.、 "PPPチャレンジハンドシェイク認証プロトコル（CHAP）"、RFC 1994、1996年8月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、 "RADIUSアカウンティング"、RFC 2866、2000年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.カルフーン、 "RADIUS（ユーザサービスにおけるリモート認証ダイヤル）拡張認証プロトコル（EAP）のサポート"、RFC 3579、2003年9月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.、およびJ.ポーク、 "Geopriv要件"、RFC 3693、2004年2月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005]カルフーン、P.、ツォルン、G.、スペンス、D.、およびD.ミトン、 "直径ネットワークアクセスサーバーアプリケーション"、RFC 4005、2005年8月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]スタンレー、D.、ウォーカー、J.、およびB. Aboba、 "無線LANのための拡張認証プロトコル（EAP）メソッド要件"、RFC 4017、2005年3月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.、ヒラー、T.、およびG.ゾルン、 "直径拡張認証プロトコル（EAP）アプリケーション"、RFC 4072、2005年8月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]ピーターソン、J.、 "プレゼンスベースGEOPRIVロケーション・オブジェクト・フォーマット"、RFC 4119、2005年12月。
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4187] Arkko、J.とH. Haverinen、 "第3世代認証及び鍵合意（EAP-AKA）のための拡張認証プロトコル方式"、RFC 4187、2006年1月。
[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月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006.
[RFC4372] Adrangi、F.、LIOR、A.、Korhonen、J.、およびJ. Loughney、 "有料ユーザーID"、RFC 4372、2006年1月。
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.
[RFC4745] Schulzrinneと、H.、Tschofenig、H.、モリス、J.、クエリャル、J.、ポーク、J.、およびJ.ローゼンバーグ、 "共通ポリシー：プライバシー設定を表現するためのドキュメントフォーマット"、RFC 4745、2月2007。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]ローゼンバーグ、J.、 "拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）"、RFC 4825、2007年5月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten氏、T.、Draves、R.、およびS.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 4941、2007年9月。
[RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", RFC 5106, February 2008.
[RFC5106] Tschofenig、H.、Kroeselberg、D.、Pashalidis、A.、オオバ、Y.、およびF. Bersani、 "拡張認証プロトコル、インターネット鍵交換プロトコルバージョン2（EAP-IKEv2の）方法"、RFC 5106 、2008年2月。
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[RFC5281]ファンク、P.とS.ブレーク - ウィルソン、 "拡張認証プロトコルトンネル型トランスポート層セキュリティ認証プロトコルバージョン0（EAP-TTLSv0）"、RFC 5281、2008年8月。
Appendix A. Matching with GEOPRIV Requirements
GEOPRIV要件と付録A.マッチング
This section compares the requirements for a GEOPRIV using protocol, described in [RFC3693], against the approach of distributing Location Objects with RADIUS.
このセクションでは、RADIUSとロケーションオブジェクトを配信する手法に対して、[RFC3693]に記載さGEOPRIV使用してプロトコルのための要件を比較します。
In Appendices A.1 and A.2, we discuss privacy implications when RADIUS entities make location information available to other parties. In Appendix A.3, the requirements are matched against these two scenarios.
RADIUSエンティティが他の当事者への位置情報を利用できるようにするとき付録A.1とA.2では、我々は、プライバシーへの影響を議論します。付録A.3では、要件は、これら2つのシナリオと照合されます。
A.1. Distribution of Location Information at the User's Home Network
A.1。ユーザーのホームネットワークでの位置情報の流通
When location information is conveyed from the RADIUS client to the RADIUS server, then it might subsequently be made available for different purposes. This section discusses the privacy implications for making location information available to other entities.
位置情報は、RADIUSクライアントからRADIUSサーバーに搬送されると、それは、その後、異なる目的のために利用可能となる可能性があります。このセクションでは、他のエンティティへの位置情報を利用可能にするため、プライバシーへの影響について説明します。
To use a more generic scenario, we assume that the visited RADIUS and the home RADIUS server belong to different administrative domains. The Location Recipient obtains location information about a particular Target via protocols specified outside the scope of this document (e.g., SIP, HTTP, or an API).
より一般的なシナリオを使用するために、我々は、訪問RADIUSとホームRADIUSサーバが異なる管理ドメインに属していることを前提としています。ロケーション受信者は、この文書（例えば、SIP、HTTP、またはAPI）の範囲外で指定されたプロトコルを介して、特定のターゲットについての位置情報を取得します。
The subsequent figure shows the interacting entities graphically.
後続の図は、グラフィカル相互作用エンティティを示します。
visited network | home network
|
| +----------+
| | Rule |
| | Holder |
| +----+-----+
| |
| rule|interface
+----------+ | V +----------+
|Location | | +----------+ notification |Location |
|Generator | | |Location |<------------->|Recipient |
+----------+ publication |Server | interface | |
|RADIUS |<------------->+----------+ +----------+
|Client | interface |RADIUS | E.g., SIP/HTTP
+----------+ | |Server |
| +----------+
E.g., NAS RADIUS
|
|
Figure 8: Location Server at the Home Network
図8：ホームネットワークでのロケーションサーバ
The term 'Rule Holder' in Figure 8 denotes the entity that creates the authorization ruleset.
図8における用語「ルールホルダーは、」承認ルールセットを作成し、実体を表します。
A.2. Distribution of Location Information at the Visited Network
A.2。訪問先ネットワークでの位置情報の流通
This section describes a scenario where location information is made available to Location Recipients by a Location Server in the visited network. Some identifier needs to be used as an index within the location database. One possible identifier is the Network Access Identifier. RFC 4282 [RFC4282] and RFC 4372 [RFC4372] provide background regarding whether entities in the visited network can obtain the user's NAI in cleartext.
このセクションでは、位置情報は、訪問先ネットワークにおけるロケーションサーバによって場所の受信者に利用可能にされたシナリオを説明しています。いくつかの識別子は、位置データベース内のインデックスとして使用する必要があります。一つの可能な識別子は、ネットワークアクセス識別子です。 RFC 4282 [RFC4282]およびRFC 4372 [RFC4372]は訪問先ネットワーク内のエンティティがクリアテキストでのユーザのNAIを得ることができるかどうかについての背景を提供しています。
The visited network provides location information to a Location Recipient (e.g., via SIP or HTTP). This document enables the NAS to obtain the user's privacy policy via the interaction with the RADIUS server. Otherwise, only default policies, which are very restrictive, are available. This allows the Location Server in the visited network to ensure they act according to the user's policies.
訪問先ネットワークは、位置受信者（例えば、SIPまたはHTTPを介して）に位置情報を提供します。このドキュメントでは、RADIUSサーバとの相互作用を介して、ユーザーのプライバシーポリシーを取得するためにNASを可能にします。それ以外の場合は、非常に制限されている唯一のデフォルトポリシーは、ご利用いただけます。これは、彼らが、ユーザのポリシーに従って行動することを確認するために訪問したネットワーク内のロケーションサーバを可能にします。
The subsequent figure shows the interacting entities graphically.
後続の図は、グラフィカル相互作用エンティティを示します。
visited network | home network
|
+----------+ |
|Location | |
|Recipient | |
| | |
+----------+ |
^ | +----------+
| | | Rule |
notification | | Holder |
interface | | |
| | +----+-----+
| | |
| | rule|interface
v | |
+----------+ | |
|Location | | v
|Server | | +----------+
+----------+ Rule Transport|RADIUS |
|RADIUS |<------------->|Server |
|Client | RADIUS +----------+
+----------+ |
|Location | |
|Generator |
+----------+
Figure 9: Location Server at the Visited Network
図9：訪問先ネットワークのロケーションサーバ
Location information always travels with privacy policies. This document enables the RADIUS client to obtain these policies. The Location Server can subsequently act according to these policies to provide access control using the Extended-Location-Policy-Rules and to adhere to the privacy statements in the Basic-Location-Policy-Rules.
位置情報は常にプライバシーポリシーに移動します。この文書では、これらのポリシーを取得するためにRADIUSクライアントを有効にします。ロケーションサーバは、その後の拡張 - ロケーション・ポリシー・ルールを使用してアクセス制御を提供し、基本的な - ロケーション・ポリシー・ルールにおけるプライバシーステートメントに準拠するには、これらの方針に従って行動することができます。
A.3. Requirements Matching
A.3。要件マッチング
Section 7.1 of [RFC3693] details the requirements of a "Location Object". We discuss these requirements in the subsequent list.
[RFC3693]のセクション7.1は、「Locationオブジェクト」の要件を詳しく説明しています。私たちは、その後のリストに、これらの要件を議論します。
Req. 1. (Location Object generalities):
必須。 1.（Locationオブジェクトの一般論）：
* Regarding requirement 1.1, the syntax and semantics of the Location Object are taken from [RFC3825] and [RFC4776]. It is furthermore possible to convert it to the format used in the Geography Markup Language (GMLv3) [GMLv3], as used with PIDF-LO [RFC4119].
*要件1.1に関しては、構文と場所オブジェクトのセマンティクスは、[RFC3825]と[RFC4776]から取得されます。 PIDF-LO [RFC4119]で使用されるように、地理マークアップ言語（GMLv3）GMLv3]で使用されるフォーマットに変換することも可能です。
* Regarding requirement 1.2, a number of fields in the civic location-information format are optional.
*要件1.2について、市民の位置情報フォーマットのフィールドの数は任意です。
* Regarding requirement 1.3, the inclusion of type of place item (CAtype 29) used in the DHCP civic format gives a further classification of the location. This attribute can be seen as an extension.
*要件1.3に関しては、DHCP市民の形式で使用される場所の項目（CAtype 29）のタイプを含めることは、位置のさらなる分類を与えます。この属性は、拡張機能として見ることができます。
* Regarding requirement 1.4, this document does not define the format of the location information.
*要件1.4に関して、この文書は、位置情報のフォーマットを定義していません。
* Regarding requirement 1.5, location information is only sent from the RADIUS client to the RADIUS server.
*要件1.5に関しては、位置情報のみをRADIUSサーバにRADIUSクライアントから送信されます。
* Regarding requirement 1.6, the Location Object contains both location information and privacy rules. Location information is described in Sections 4.2, 4.3.1, and 4.3.2. The corresponding privacy rules are detailed in Sections 4.4 and 4.5.
*要件1.6に関しては、Locationオブジェクトは、位置情報とプライバシー規則の両方が含まれています。位置情報は、セクション4.2、4.3.1および4.3.2に記載されています。対応するプライバシー規則は、セクション4.4と4.5で詳述されています。
* Regarding requirement 1.7, the Location Object is usable in a variety of protocols. The format of the object is reused from other documents, as detailed in Sections 4.2, 4.3.1, 4.3.2, 4.4, and 4.5.
*要件1.7に関しては、Locationオブジェクトは、さまざまなプロトコルで使用可能です。セクション4.2、4.3.1、4.3.2、4.4、および4.5で詳述したように、オブジェクトのフォーマットは、他の文書から再利用されます。
* Regarding requirement 1.8, the encoding of the Location Object has an emphasis on a lightweight encoding format to be used with RADIUS.
*要件1.8に関しては、Locationオブジェクトの符号化は、RADIUSで使用する軽量なエンコード形式に重点を有しています。
Req. 2. (Location Object fields):
必須。 2.（Locationオブジェクトフィールド）：
* Regarding requirement 2.1, the target identifier is carried within the network-access authentication protocol (e.g., within the EAP-Identity Response when EAP is used and/or within the EAP method itself). As described in Section 7.2 of this document, it has a number of advantages if this identifier is not carried in clear. This is possible with certain EAP methods whereby the identity in the EAP-Identity Response only contains information relevant for routing the response to the user's home network. The user identity is protected by the authentication and key exchange protocol.
（EAPおよび/またはEAPメソッド自体内で使用されるとき、EAPアイデンティティ応答内で、例えば）*要件2.1に関しては、ターゲット識別子は、ネットワークアクセス認証プロトコルの中で運ばれます。このドキュメントのセクション7.2で説明したように、この識別子は明らかで運ばれていない場合、それは多くの利点を有します。これは、EAP-アイデンティティ応答のIDが唯一のユーザのホームネットワークへの応答をルーティングするための関連情報が含まれていることにより、特定のEAP方式で可能です。ユーザー識別情報は、認証と鍵交換プロトコルにより保護されています。
* Regarding requirement 2.2, the Location Recipient is, in the main scenario, the home RADIUS server. For a scenario where the Location Recipient is obtaining location information from the Location Server via HTTP or SIP, the respective mechanisms defined in these protocols are used to identify the recipient. The Location Generator cannot, a priori, know the recipients if they are not defined in this protocol.
*要件2.2については、所在地の受信者は、メインシナリオ、ホームRADIUSサーバに、です。ロケーション受信者がHTTPまたはSIPを介してロケーションサーバから位置情報を取得されたシナリオでは、これらのプロトコルで定義された各機構は、受信者を識別するために使用されます。彼らはこのプロトコルで定義されていない場合は場所ジェネレーターは、先験的には、受信者を知ることができません。
* Regarding requirement 2.3, the credentials of the Location Recipient are known to the RADIUS entities based on the security mechanisms defined in the RADIUS protocol itself. Section 7 of this document describes these security mechanisms offered by the RADIUS protocol. The same is true for requirement 2.4.
*要件2.3については、所在地の受信者の資格情報は、RADIUSプロトコル自体に定義されたセキュリティ・メカニズムに基づいてRADIUSエンティティに知られています。このドキュメントのセクション7は、RADIUSプロトコルによって提供されるこれらのセキュリティメカニズムについて説明します。同じことは、要件2.4にも当てはまります。
* Regarding requirement 2.5, Sections 4.2, 4.3.1, and 4.3.2 describe the content of the Location fields. Since the location format itself is not defined in this document, motion and direction vectors as listed in requirement 2.6 are not defined.
*要件2.5、セクション4.2、4.3.1および4.3.2に関しては、ロケーションフィールドの内容を記述する。ロケーション・フォーマット自体は本文書で定義されていないので、要件2.6に記載されている動きと方向ベクトルが定義されていません。
* Regarding requirement 2.6, this document provides the capability for the RADIUS server to indicate what type of location information it would like to see from the RADIUS client.
*要件2.6に関しては、この文書では、それはRADIUSクライアントから見たい場所情報の種類を示すために、RADIUSサーバのための機能を提供します。
* Regarding requirement 2.7, timing information is provided with the 'Sighting Time' and 'Time-to-Live' fields defined in Section 4.2.
*要件2.7に関しては、タイミング情報をすることは「目撃時間」と「タイム・ツー・ライブ」のセクション4.2で定義されたフィールドを備えています。
* Regarding requirement 2.8, a reference to an external (more detailed ruleset) is provided with the Extended-Location-Policy-Rules Attribute in Section 4.5.
*要件2.8に関しては、外部（より詳細なルールセット）への参照は、4.5節に属性の拡張 - ロケーション-ポリシールールが設けられています。
* Regarding requirement 2.9, security headers and trailers are provided as part of the RADIUS protocol or even as part of IPsec.
*要件2.9に関しては、セキュリティヘッダとトレーラは、RADIUSプロトコルの一部として、またはさえのIPsecの一部として提供されます。
* Regarding requirement 2.10, a version number in RADIUS is provided with the IANA registration of the attributes. New attributes are assigned a new IANA number.
*要件2.10に関しては、RADIUSでのバージョン番号は属性のIANA登録が設けられています。新しい属性は、新しいIANA番号が割り当てられています。
Req. 3. (Location Data Types):
必須。 3.（所在地データ型）：
* Regarding requirement 3.1, this document reuses civic and geospatial location information as described in Sections 4.3.2 and 4.3.1.
セクション4.3.2および4.3.1に記載したよう*要件3.1に関して、この文書は、市民と地理空間位置情報を再使用します。
* With the support of civic and geospatial location information, support of requirement 3.2 is fulfilled.
*市民と地理位置情報のサポートにより、要件3.2のサポートが満たされています。
* Regarding requirement 3.3, the geospatial location information used by this document only refers to absolute coordinates. However, the granularity of the location information can be reduced with the help of the AltRes, LoRes, and LaRes fields described in [RFC3825].
*要件3.3に関して、本文書で使用される地理空間位置情報は、絶対座標を指します。しかし、位置情報の精度は、[RFC3825]に記載AltRes、LORES、及びラレスフィールドの助けを借りて低減することができます。
* Regarding requirement 3.4, further Location Data Types can be added via new coordinate reference systems (CRSs -- see the Datum field in [RFC3825]) and via extensions to [RFC3825] and [RFC4776].
*要件3.4について、さらにロケーションデータ型は、新しい座標参照系を介して添加することができる（のCRSは - [RFC3825]内のデータフィールドを参照）、[RFC3825]及び[RFC4776]の拡張機能を介し。
Section 7.2 of [RFC3693] details the requirements of a "using protocol". These requirements are listed below.
[RFC3693]のセクション7.2「使用プロトコル」の要件を詳述します。これらの要件は以下のとおりです。
Req. 4.: The using protocol has to obey the privacy and security instructions coded in the Location Object (LO) regarding the transmission and storage of the LO. This document requires that entities that aim to make location information available to third parties be required to obey the privacy instructions.
必須。 4：使用したプロトコルは、LOの伝送及び貯蔵に関する位置オブジェクト（LO）に符号化されたプライバシーおよびセキュリティの命令に従うことを有しています。このドキュメントは、第三者への位置情報を利用可能にすることを目指しエンティティは、プライバシーの指示に従うために必要されている必要があります。
Req. 5.: The using protocol will typically facilitate that the keys associated with the credentials are transported to the respective parties, that is, key establishment is the responsibility of the using protocol. Section 7 of this document specifies how security mechanisms are used in RADIUS and how they can be reused to provide security protection for the Location Object. Additionally, the privacy considerations (see Section 7.2) are also relevant for this requirement.
必須。 5：使用したプロトコルは、典型的には、資格情報に関連付けられたキーがそれぞれの当事者に輸送されることを容易にする、つまり、鍵確立は、使用プロトコルの責任です。このドキュメントのセクション7は、セキュリティ・メカニズムがRADIUSで使用され、それらがどのようにLocationオブジェクトのセキュリティ保護を提供するために再利用できる方法を指定します。また、プライバシーの考慮事項は（セクション7.2を参照）も、この要件に関連しています。
Req. 6. (Single Message Transfer): In particular, for tracking of small target devices, the design should allow a single message/ packet transmission of location as a complete transaction. The encoding of the Location Object is specifically tailored towards the inclusion into a single message that even respects the (Path) MTU size.
必須。 6.（単一のメッセージ転送）：具体的には、小さなターゲットデバイスの追跡のために、設計は、完全なトランザクションとしての位置の単一のメッセージ/パケットの送信を可能にすべきです。 Locationオブジェクトの符号化は、具体的にも（パス）MTUサイズを尊重単一のメッセージに含めるに向かって調整されます。
Section 7.3 of [RFC3693] details the requirements of a "Rule-based Location Data Transfer". These requirements are listed below.
[RFC3693]のセクション7.3には、「ルールベースの場所のデータ転送」の要件を詳しく説明しています。これらの要件は以下のとおりです。
Req. 7. (LS Rules): With the scenario shown in Figure 8, the decision of a Location Server to provide a Location Recipient access to location information is based on Rule Maker-defined privacy rules that are stored at the home network. With regard to the scenario shown in Figure 9, the Rule Maker-defined privacy rules are sent from the RADIUS server to the NAS (see Sections 4.4, 4.5, and 7.2 for more details).
必須。 7.（LSルール）：図8に示すシナリオでは、ロケーションサーバの決定は、ホームネットワークに保存されているルールメーカー定義のプライバシールールに基づいて位置情報を位置情報受信者のアクセスを提供します。図9に示されたシナリオに関して、ルールメーカー定義のプライバシールールは（セクション4.4、4.5を参照して、より詳しくは7.2）NASにRADIUSサーバから送信されます。
Req. 8. (LG Rules): For all usage scenarios, it is possible to consider the privacy rule before transmitting location information from the NAS to the RADIUS server or even to third parties. In the case of an out-of-band agreement between the owner of the NAS and the owner of the RADIUS server, privacy might be applied on a higher granularity. For the scenario shown in Figure 8, the visited network is already in possession of the user's location information prior to the authentication and authorization of the user. A correlation between the location and the user identity might, however, still not be possible for the visited network (as explained in Section 7.2). A Location Server in the visited network has to evaluate available rulesets.
必須。 8.（LGルール）：すべての使用シナリオでは、RADIUSサーバに、あるいは第三者にNASからの位置情報を送信する前に、プライバシールールを考慮することが可能です。 NASの所有者とRADIUSサーバの所有者間の帯域外契約の場合は、プライバシーが高い粒度で適用される可能性があります。図8に示すシナリオでは、訪問先ネットワークは、既にユーザの認証および認可の前に、ユーザの位置情報を保持しています。 （セクション7.2で説明したように）位置とユーザ識別との間の相関関係は、しかし、まだ訪問先ネットワークで可能ではないかもしれません。訪問先ネットワークにおけるロケーションサーバは、使用可能なルールセットを評価することがあります。
Req. 9. (Viewer Rules): The Rule Maker might define (via mechanisms outside the scope of this document) which policy rules are disclosed to other entities.
必須。 9.（ビューアルール）：ルールメーカーは、ポリシールールが他のエンティティに開示されている（このドキュメントの範囲外の機構を介して）定義できます。
Req. 10. (Full Rule language): GEOPRIV has defined a rule language capable of expressing a wide range of privacy rules that is applicable in the area of the distribution of Location Objects. A basic ruleset is provided with the Basic-Location-Policy-Rules Attribute (Section 4.4). A reference to the extended ruleset is carried in Section 4.5. The format of these rules is described in [RFC4745] and [GEO-POLICY].
必須。 10.（フルルール言語）：GEOPRIVロケーションオブジェクトの分布の領域にも適用可能であるプライバシー規則の広い範囲を発現することができるルール言語を定義しています。基本的なルールセットは、基本-場所-ポリシールールの属性（4.4節）が設けられています。拡張されたルールセットへの参照は、4.5節に運ばれます。これらのルールの形式は[RFC4745]と[GEO-POLICY]に記載されています。
Req. 11. (Limited Rule language): A limited (or basic) ruleset is provided by the Policy-Information Attribute in Section 4.4 (and as introduced with PIDF-LO [RFC4119]).
必須。 11.（限定ルール言語）：ポリシー情報によって提供される制限され（または塩基）のルールセットが4.4節内の属性（およびPIDF-LOで導入として[RFC4119]）。
Section 7.4 of [RFC3693] details the requirements of a "Location Object Privacy and Security". These requirements are listed below.
[RFC3693]のセクション7.4には、「場所のオブジェクトのプライバシーとセキュリティ」の要件を詳しく説明しています。これらの要件は以下のとおりです。
Req. 12 (Identity Protection): Support for unlinkable pseudonyms is provided by the usage of a corresponding authentication and key-exchange protocol. Such protocols are available, for example, with the support of EAP as network-access authentication methods. Some EAP methods support passive user-identity confidentiality, whereas others even support active user-identity confidentiality. This issue is further discussed in Section 7. The importance for user-identity confidentiality and identity protection has already been recognized as an important property (see, for example, a document on EAP method requirements for wireless LANs [RFC4017]).
必須。 12（識別情報保護）：アンリンカブル仮名のサポートが対応する認証及び鍵交換プロトコルの使用によって提供されます。そのようなプロトコルは、ネットワークアクセス認証方式としてEAPの支援を受けて、例えば、利用可能です。他の人にもアクティブなユーザー・アイデンティティの機密性をサポートするのに対し、いくつかのEAP方式は、パッシブ・ユーザ・アイデンティティの機密性をサポートしています。この問題は、さらに、ユーザのアイデンティティの機密性とアイデンティティ保護のための重要性はすでに重要な特性（例えば、無線LANのEAP方式要件に関する文書を参照してください[RFC4017]）として認識されているセクション7で説明されています。
Req. 13. (Credential Requirements): As described in Section 7 , RADIUS signaling messages can be protected with IPsec. This allows a number of authentication and key exchange protocols to be used as part of IKE, IKEv2, or KINK.
必須。 13（資格要件）：セクション7で説明したように、RADIUSシグナリングメッセージがIPSecで保護することができます。これは、認証・鍵交換プロトコルの数は、IKE、IKEv2の、又はKINKの一部として使用されることを可能にします。
Req. 14. (Security Features): GEOPRIV defines a few security requirements for the protection of Location Objects, such as mutual end-point authentication, data object integrity, data object confidentiality, and replay protection. As described in Section 7, these requirements are fulfilled with the usage of IPsec if mutual authentication refers to the RADIUS entities (acting as various GEOPRIV entities) that directly communicate with each other.
必須。 14.（セキュリティ機能）：GEOPRIVは、このような相互のエンドポイントの認証、データオブジェクトの整合性、データオブジェクトの機密性、および再生保護などの場所オブジェクトの保護のためのいくつかのセキュリティ要件を定義します。セクション7で説明したように、相互認証が直接互いに通信（各種GEOPRIVエンティティとして動作する）RADIUSエンティティを参照する場合、これらの要件は、IPSecの使用で満たされます。
Req. 15. (Minimal Crypto): A minimum of security mechanisms are mandated by the usage of RADIUS. Communication security for Location Objects between RADIUS infrastructure elements is provided by the RADIUS protocol (including IPsec and its dynamic key-management framework), rather than relying on object security via S/SIME (which is not available with RADIUS).
必須。 15.（最小クリプト）は：セキュリティメカニズムの最小値は、RADIUSの使用によって義務付けられています。 RADIUSインフラストラクチャ要素との間の位置オブジェクトの通信セキュリティは、（IPsecとそのダイナミックキー管理フレームワークを含む）、よりもむしろ（RADIUSで使用できません）S / SIMEを介してオブジェクトのセキュリティに依存RADIUSプロトコルによって提供されます。
Authors' Addresses
著者のアドレス
Hannes Tschofenig (editor) Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenig（編集）、ノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：Hannes.Tschofenig@gmx.net URI：http://www.tschofenig.priv.at
Farid Adrangi Intel Corporatation 2111 N.E. 25th Avenue Hillsboro OR USA
ファリドAdrangiインテルコーポレーション2111 N.E.第25回アベニューヒルズボロOR USA
EMail: farid.adrangi@intel.com
メールアドレス：farid.adrangi@intel.com
Mark Jones Bridgewater Systems Corporation 303 Terry Fox Drive Ottawa, Ontario K2K 3J1 CANADA
マーク・ジョーンズブリッジウォーターシステムズ社303テリー・フォックスドライブオタワ、オンタリオ州K2K 3J1 CANADA
EMail: mark.jones@bridgewatersystems.com
メールアドレス：mark.jones@bridgewatersystems.com
Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Ottawa, Ontario K2K 3J1 CANADA
アビLIORブリッジウォーターシステムズ社303テリー・フォックスドライブオタワ、オンタリオ州K2K 3J1 CANADA
EMail: avi@bridgewatersystems.com
メールアドレス：avi@bridgewatersystems.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052 USA
EMail: bernarda@microsoft.com
メールアドレス：bernarda@microsoft.com