Network Working Group F. Adrangi
Request for Comments: 4372 Intel
Category: Standards Track A. Lior
Bridgewater Systems
J. Korhonen
Teliasonera
J. Loughney
Nokia
January 2006
Chargeable User Identity
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) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document describes a new Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identity. This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network.
この文書は、新しいリモート認証ダイヤルインユーザーサービス（RADIUS）属性、有料-ユーザ識別を記述する。この属性は、ホームネットワークの外部で発生するトランザクションをローミングの目的のために、ユーザを識別するために、ホームネットワークで使用することができます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Motivation .................................................3
1.2. Terminology ................................................4
2. Operation .......................................................5
2.1. Chargeable-User-Identity (CUI) Attribute ...................5
2.2. CUI Attribute ..............................................6
3. Attribute Table .................................................7
4. Diameter Consideration ..........................................7
5. IANA Considerations .............................................7
6. Security Considerations .........................................7
7. Acknowledgements ................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
Some authentication methods, including EAP-PEAP, EAP-TTLS, EAP-SIM and EAP-AKA, can hide the true identity of the user from RADIUS servers outside of the user's home network. In these methods, the User-Name(1) attribute contains an anonymous identity (e.g., @example.com) sufficient to route the RADIUS packets to the home network but otherwise insufficient to identify the user. While this mechanism is good practice in some circumstances, there are problems if local and intermediate networks require a surrogate identity to bind the current session.
EAP-PEAP、EAP-TTLS、EAP-SIMおよびEAP-AKAを含むいくつかの認証方法は、ユーザのホームネットワークの外にRADIUSサーバから利用者の本当の身元を隠すことができます。これらの方法では、ユーザー名（1）属性は、ホームネットワークにRADIUSパケットの経路に十分であるが、ユーザを識別するためにそれ以外の場合は不十分な匿名のアイデンティティを（例えば、@ example.com）が含まれています。このメカニズムは、いくつかの状況では良い習慣ですが、ローカルおよび中間ネットワークは、現在のセッションをバインドする代理アイデンティティが必要な場合は、問題があります。
This document introduces an attribute that serves as an alias or handle (hereafter, it is called Chargeable-User-Identity) to the real user's identity. Chargeable-User-Identity can be used outside the home network in scenarios that traditionally relied on User-Name(1) to correlate a session to a user.
この文書では、実際のユーザーのIDに（以後、それは有料-ユーザアイデンティティと呼ばれる）の別名として機能またはハンドル属性を紹介します。有料-ユーザ識別は、伝統的に、ユーザへのセッションを相関させるためにユーザー名（1）に頼っていたシナリオで、ホームネットワーク外で使用することができます。
For example, local or intermediate networks may limit the number of simultaneous sessions for specific users; they may require a Chargeable-User-Identity in order to demonstrate willingness to pay or otherwise limit the potential for fraud.
例えば、ローカルまたは中間ネットワークは、特定のユーザーのための同時セッションの数を制限することができます。彼らは支払うか、そうでない場合は詐欺の可能性を制限する意欲を実証するために、請求可能 - ユーザ識別が必要な場合があります。
This implies that a unique identity provided by the home network should be able to be conveyed to all parties involved in the roaming transaction for correlating the authentication and accounting packets.
これは、ホームネットワークが提供するユニークなアイデンティティが認証およびアカウンティングパケットを相関させるためのローミング取引に関わるすべての関係者に伝達することができなければならないことを意味しています。
Providing a unique identity, Chargeable-User-Identity (CUI), to intermediaries, is necessary to fulfill certain business needs. This should not undermine the anonymity of the user. The mechanism provided by this document allows the home operator to meet these business requirements by providing a temporary identity representing the user and at the same time protecting the anonymity of the user.
一意のID、有償・ユーザー・アイデンティティ（CUI）を提供、仲介に、特定のビジネスニーズを満たすことが必要です。これは、ユーザーの匿名性を損なうべきではありません。この文書で提供メカニズムは、ホームオペレータは、ユーザーを表す一時的なアイデンティティを提供することにより、利用者の匿名性を保護すると同時に、これらのビジネス要件を満たすことができます。
When the home network assigns a value to the CUI, it asserts that this value represents a user in the home network. The assertion should be temporary -- long enough to be useful for the external applications and not too long such that it can be used to identify the user.
ホームネットワークは、CUIに値を代入するときは、この値は、ホームネットワーク内のユーザを表していることを主張します。アサーションは一時的なものでなければならない - 十分な長さ、利用者を識別するために使用することができるような長すぎる外部アプリケーションのために有用ではないと。
Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance, and IRAP, have been studying mechanisms to provide roaming services, using RADIUS. Missing elements include mechanisms for billing and fraud prevention.
WISPrの、GSMA、3GPP、のWi-Fiアライアンス、およびIRAPを含むいくつかの組織は、RADIUSを使用して、ローミングサービスを提供するためのメカニズムを研究してきました。不足している要素は、課金、不正防止のための機構を含みます。
The CUI attribute is intended to close operational loopholes in RADIUS specifications that have impacted roaming solutions negatively. Use of the CUI is geared toward EAP methods supporting privacy (such as PEAP and EAP-TTLS), which are, for the most part, recent deployments. A chargeable identity reflecting the user profile by the home network is needed in such roaming scenarios.
CUI属性は負ローミングソリューションに影響を与えてきたRADIUS仕様で運用抜け穴を閉鎖することを意図しています。 CUIの使用は、大部分がある（例えばPEAPおよびEAP-TTLSなど）のプライバシーをサポートするEAP方式、最近の展開に向けています。ホームネットワークでユーザープロファイルを反映した充電アイデンティティは、そのようなローミングのシナリオで必要とされます。
Some other mechanisms have been proposed in place of the CUI attribute. These mechanisms are insufficient or cause other problems. It has been suggested that standard RADIUS Class(25) or User-Name(1) attributes could be used to indicate the CUI. However, in a complex global roaming environment where there could be one or more intermediaries between the NAS [RFC4282] and the home RADIUS server, the use of aforementioned attributes could lead to problems as described below.
いくつかの他のメカニズムは、CUI属性の代わりに提案されています。これらのメカニズムは不十分であるか、他の問題を引き起こします。標準のRADIUSクラス（25）またはユーザー名は、（1）CUIを示すために使用できる属性が示唆されています。後述のようにしかし、NAS [RFC4282]とホームRADIUSサーバとの間に1つのまたは複数の仲介があるかもしれない複雑なグローバルローミング環境では、前述の属性を使用することは問題につながる可能性があります。
- On the use of RADIUS Class(25) attribute:
- RADIUSクラス（25）属性の使用に関する：
[RFC2865] states: "This Attribute is available to be sent by the server to the client in an Access-Accept packet and SHOULD be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported. The client MUST NOT interpret the attribute locally." So RADIUS clients or intermediaries MUST NOT interpret the Class(25) attribute, which precludes determining whether it contains a CUI. Additionally, there could be multiple class attributes in a RADIUS packet, and since the contents of Class(25) attribute is not to be interpreted by clients, this makes it hard for the entities outside the home network to determine which one contains the CUI.
[RFC2865]は述べて：「この属性は、Access-受け入れパケットでクライアントにサーバによって送信することが可能ですし、会計がサポートされている場合アカウンティング要求パケットの一部としてアカウンティングサーバにクライアントでそのまま送ってください。クライアントは、ローカルに属性を解釈してはなりません。」だから、RADIUSクライアントまたは仲介は、CUIが含まれているかどうかを決定排除クラス（25）属性を、解釈してはなりません。また、複数のクラスがRADIUSパケットであっ属性をすることができ、クラスの内容以来（25）属性は、クライアントによって解釈されていない、これは難しいホームネットワーク外のエンティティはCUIが含まれているかを判断できるようになります。
- On the use of RADIUS User-Name(1) attribute:
- RADIUSユーザ名（1）属性の使用に関する：
The User-Name(1) attribute included in the Access-Request packet may be used for the purpose of routing the Access-Request packet, and in the process may be rewritten by intermediaries. As a result, a RADIUS server receiving an Access-Request packet relayed by a proxy cannot assume that the User-Name(1) attribute remained unmodified.
（1）属性は、アクセス要求パケットに含まれるユーザ名は、アクセス要求パケットをルーティングするために使用することができ、その過程で仲介することにより書き換えることができます。その結果、プロキシによって中継されたアクセス要求パケットを受信したRADIUSサーバは、ユーザ名は、（1）属性が修飾されていないままであることを前提とすることができません。
On the other hand, rewriting of a User-Name(1) attribute sent within an Access-Accept packet occurs more rarely, since a Proxy-State(33) attribute can be used to route the Access-Accept packet without parsing the User-Name(1) attribute. As a result, a RADIUS server cannot assume that a proxy stripping routing information from a User-Name(1) attribute within an Access-Request packet will add this information to a User-Name(1) attribute included within an Access-Accept packet. The result is that when a User-Name(1) attribute is sent in an Access-Accept packet, it is possible that the Access-Request packet and Accounting-Request packets will follow different paths. Where this outcome is undesirable, the RADIUS client should use the original User-Name(1) in accounting packets. Therefore, another mechanism is required to convey a CUI within an Access-Accept packet to the RADIUS client, so that the CUI can be included in the accounting packets.
一方、ユーザ名の書き換え（1）属性内で送信プロキシステート（33）属性がUSER-を解析せずにルーティングする接続許可パケットを使用することができるので、パケットは、よりめったに発生しないアクセス - 受け入れ名（1）属性。その結果、RADIUSサーバは、プロキシがユーザー名からルーティング情報を除去することを前提とすることはできません（1）のAccess-Requestパケット内の属性は、属性がアクセス-受け入れパケット内に含まれる（1）ユーザー名にこの情報を追加します。その結果は、ユーザ名（1）属性は、アクセス受諾パケットで送信される場合、アクセス要求パケットおよびアカウンティング要求パケットは異なる経路をたどることが可能であるということです。この結果は望ましくない場合は、RADIUSクライアントは、アカウンティングパケットに（1）オリジナルのユーザー名を使用する必要があります。したがって、別のメカニズムは、CUIはアカウンティングパケットに含めることができるように、RADIUSクライアントへのアクセスは、受け入れパケット内のCUIを伝えるために必要とされます。
The CUI attribute provides a solution to the above problems and avoids overloading RADIUS User-Name(1) attribute or changing the usage of existing RADIUS Class(25) attribute. The CUI therefore provides a standard approach to billing and fraud prevention when EAP methods supporting privacy are used. It does not solve all related problems, but does provide for billing and fraud prevention.
CUI属性は、上記の問題に対する解決策を提供し、RADIUSユーザ名（1）属性をオーバーロードしたり、既存のRADIUSクラス（25）属性の使用法を変更することが回避されます。プライバシーをサポートするEAPメソッドが使用される場合CUIは、従って、課金および不正防止の標準的なアプローチを提供します。これは、すべての関連の問題を解決していませんが、課金および詐欺防止のために提供しません。
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]に記載されているように解釈されます。
The following acronyms are used:
以下の頭字語が使用されます。
3GPP - Third Generation Partnership Project AAA - Authentication, Authorization, and Accounting AKA - Authentication and Key Agreement CUI - Chargeable-User-Identity GSMA - GSM Association IRAP - International Roaming Access Protocols Program NAS - Network Access Server PEAP - Protected Extensible Authentication Protocol SIM - Subscriber Identity Modules TTLS - Tunneled Transport Layer Security WISPr - Wireless ISP Roaming WPA - Wi-Fi Protected Access
3GPP - 第三世代パートナーシッププロジェクトAAA - 認証、認可、アカウンティングAKA - 認証と鍵共有CUI - 有料 - ユーザ識別GSMA - GSM協会IRAP - 国際ローミングアクセスプロトコルプログラムNAS - ネットワークアクセスサーバPEAP - 保護された拡張認証プロトコルSIM - 加入者識別モジュールTTLS - トンネル化トランスポート層セキュリティWISPrの - ワイヤレスISPローミングWPA - のWi-Fi保護アクセス
This document assumes that the RADIUS protocol operates as specified in [RFC2865] and [RFC2866], dynamic authorization as specified in [RFC3576], and the Diameter protocol as specified in [RFC3588].
このドキュメントは[RFC3588]で指定されるように[RFC2865]及び[RFC2866]、[RFC3576]で指定されるように動的認可、Diameterプロトコルで指定されたRADIUSプロトコルが動作することを前提としています。
The CUI attribute serves as an alias to the user's real identity, representing a chargeable identity as defined and provided by the home network as a supplemental or alternative information to User-Name(1). Typically, the CUI represents the identity of the actual user, but it may also indicate other chargeable identities such as a group of users. RADIUS clients (proxy or NAS) outside the home network MUST NOT modify the CUI attribute.
CUI属性が定義され、ユーザ名（1）の補足または代替情報として、ホームネットワークによって提供される帯電アイデンティティを表す、ユーザの本当の身元のエイリアスとして機能します。典型的には、CUIは、実際のユーザーのIDを表し、それはまた、そのようなユーザのグループなど、他の帯電アイデンティティを示すことができます。ホームネットワークの外部RADIUSクライアント（プロキシまたはNAS）は、CUIの属性を変更してはいけません。
The RADIUS server (a RADIUS proxy, home RADIUS server) may include the CUI attribute in the Access-Accept packet destined to a roaming partner. The CUI support by RADIUS infrastructure is driven by the business requirements between roaming entities. Therefore, a RADIUS server supporting this specification may choose not to send the CUI in response to an Access-Request packet from a given NAS, even if the NAS has indicated that it supports CUI.
RADIUSサーバ（RADIUSプロキシ、ホームRADIUSサーバ）は、ローミングパートナーに宛てアクセス - 受け入れパケット内のCUI属性を含むことができます。 RADIUSインフラストラクチャにより、CUIのサポートは、ローミングエンティティ間のビジネス要件によって駆動されます。したがって、この仕様をサポートするRADIUSサーバは、NASは、それがCUIをサポートしていることを示していたとしても、与えられたNASからのアクセス要求パケットに応答してCUIを送信しないことを選択することができます。
If an Access-Accept packet without the CUI attribute was received by a RADIUS client that requested the CUI attribute, then the Access-Accept packet MAY be treated as an Access-Reject.
CUI属性のないアクセス - 受け入れパケットはCUIの属性を要求したRADIUSクライアントによって受信された場合は、[アクセス-受け入れパケットは拒否のアクセスとして処理することができます。
If the CUI was included in an Access-Accept packet, RADIUS clients supporting the CUI attribute MUST ensure that the CUI attribute appears in the RADIUS Accounting-Request (Start, Interim, and Stop). This requirement applies regardless of whether the RADIUS client requested the CUI attribute.
CUIは、接続許可パケットに含まれている場合は、CUIの属性をサポートするRADIUSクライアントは、CUIの属性は、RADIUSアカウンティング - 要求（スタート、中間、および停止）に表示されていることを保証しなければなりません。この要件は関係なく、RADIUSクライアントは、CUIの属性を要求したかどうかに適用されます。
RFC 2865 includes the following statements about behaviors of RADIUS client and server with respect to unsupported attributes:
RFC 2865は、サポートされていない属性について、RADIUSクライアントとサーバの行動に関する次のステートメントが含まれています。
- "A RADIUS client MAY ignore Attributes with an unknown Type." - "A RADIUS server MAY ignore Attributes with an unknown Type."
- 「RADIUSクライアントは、未知のタイプと属性を無視するかもしれません。」 - 「RADIUSサーバは、未知のタイプと属性を無視するかもしれません。」
Therefore, RADIUS clients or servers that do not support the CUI may ignore the attribute.
そのため、CUIをサポートしていないRADIUSクライアントまたはサーバは、属性を無視することができます。
A RADIUS client requesting the CUI attribute in an Access-Accept packet MUST include within the Access-Request packet a CUI attribute. For the initial authentication, the CUI attribute will include a single NUL character (referred to as a nul CUI). And, during re-authentication, the CUI attribute will include a previously received CUI value (referred to as a non-nul CUI value) in the Access-Accept.
アクセス - 受け入れパケット内のCUI属性を要求するRADIUSクライアントがアクセス要求パケット内CUI属性を含まなければなりません。初期認証のために、CUI属性は（NULのCUIとも呼ばれる）単一NUL文字が含まれます。そして、再認証時に、CUIの属性は、アクセス受け入れに（非NUL CUI値と呼ぶ）以前に受信CUI値を含むであろう。
Upon receiving a non-nul CUI value in an Access-Request, the home RADIUS server MAY verify that the value of CUI matches the CUI from the previous Access-Accept. If the verification fails, then the RADIUS server SHOULD respond with an Access-Reject message.
アクセス要求における非NUL CUI値を受信すると、ホームRADIUSサーバは、CUIの値が前-受け入れAccessからCUIと一致していることを確認することができます。検証が失敗した場合、RADIUSサーバは、アクセス拒否メッセージで応答する必要があります。
If a home RADIUS server that supports the CUI attribute receives an Access-Request packet containing a CUI (set to nul or otherwise), it MUST include the CUI attribute in the Access-Accept packet. Otherwise, if the Access-Request packet does not contain a CUI, the home RADIUS server SHOULD NOT include the CUI attribute in the Access-Accept packet. The Access-Request may be sent either in the initial authentication or during re-authentication.
CUI属性をサポートしているホームRADIUSサーバが（NULに設定されているか、そうでなければ）CUIを含むアクセス要求パケットを受信した場合、それはアクセス-受け入れパケットにCUI属性を含まなければなりません。アクセス要求パケットはCUIが含まれていない場合はそれ以外の場合は、ホームRADIUSサーバは、接続許可パケット内のCUI属性を含めるべきではありません。アクセス要求は、初期認証または再認証時にどちらか送信されることがあります。
A NAS that requested the CUI during re-authentication by including the CUI in the Access-Request will receive the CUI in the Access-Accept. The NAS MUST include the value of that CUI in all Accounting Messages.
アクセス要求でCUIを含むことによって、再認証時にCUIを要求されたNASは、アクセス・受け入れでCUIを受け取ることになります。 NASは、すべてのアカウンティングメッセージにそのCUIの値を含まなければなりません。
A summary of the RADIUS CUI attribute is given below.
RADIUSのCUI属性の概要は以下のとおりです。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 89 for Chargeable-User-Identity.
タイプ：有料-ユーザ識別のための89。
Length: >= 3
長さ：> = 3
String:
文字列：
The string identifies the CUI of the end-user. This string value is a reference to a particular user. The format and content of the string value are determined by the Home RADIUS server. The binding lifetime of the reference to the user is determined based on business agreements. For example, the lifetime can be set to one billing period. RADIUS entities other than the Home RADIUS server MUST treat the CUI content as an opaque token, and SHOULD NOT perform operations on its content other than a binary equality comparison test, between two instances of CUI. In cases where the attribute is used to indicate the NAS support for the CUI, the string value contains a nul character.
文字列は、エンドユーザーのCUIを識別します。この文字列値は、特定のユーザへの参照です。文字列値の形式と内容は、ホームRADIUSサーバによって決定されます。ユーザーへの参照の結合寿命は、業務契約に基づいて決定されます。例えば、寿命は1つの請求期間に設定することができます。ホームRADIUSサーバ以外のRADIUSエンティティは不透明トークンとしてCUIコンテンツを扱わなければならない、とCUIの2つのインスタンス間で、バイナリ等価比較テスト以外のコンテンツに対する操作を実行しないでください。属性はCUIのためのNASのサポートを示すために使用される場合には、文字列値は、NUL文字が含まれています。
The following table provides a guide to which attribute(s) may be found in which kinds of packets, and in what quantity.
以下の表は、属性（複数可）は、パケットの種類のもので、どのような量で発見することができるためのガイドを提供します。
Request Accept Reject Challenge Accounting # Attribute Request 0-1 0-1 0 0 0-1 89 Chargeable-User-Identity
チャレンジ会計＃の属性要求0-1 0-1 0 0 0-1 89有償-ユーザ識別を拒否要求受け入れ
Note: If the Access-Accept packet contains CUI, then the NAS MUST include the CUI in Accounting Requests (Start, Interim, and Stop) packets.
注：アクセス-受け入れパケットはCUIが含まれている場合、NASは、アカウンティング要求（スタート、中間、および停止）パケットでCUIを含まなければなりません。
Diameter needs to define an identical attribute with the same Type value. The CUI should be available as part of the NASREQ application [RFC4005].
直径が同じ種類の値と同じ属性を定義する必要があります。 CUIはNASREQアプリケーション[RFC4005]の一部として利用可能であるべきです。
This document uses the RADIUS [RFC2865] namespace; see http://www.iana.org/assignments/radius-types. The IANA has assigned a new RADIUS attribute number for the CUI attribute.
この文書では、RADIUS [RFC2865]の名前空間を使用しています。 http://www.iana.org/assignments/radius-typesを参照してください。 IANAは、CUIの属性の新しいRADIUS属性番号を割り当てています。
CUI 89
CUI 89
It is strongly recommended that the CUI format used is such that the real user identity is not revealed. Furthermore, where a reference is used to a real user identity, it is recommended that the binding lifetime of that reference to the real user be kept as short as possible.
強く使用CUI形式は実ユーザIDが明らかにされていないようなものであることをお勧めします。参照が実際のユーザIDに使用される場合また、実際のユーザへの参照の結合ライフタイムができるだけ短くすることが推奨されます。
The RADIUS entities (RADIUS proxies and clients) outside the home network MUST NOT modify the CUI or insert a CUI in an Access-Accept. However, there is no way to detect or prevent this.
ホームネットワーク外のRADIUSエンティティ（RADIUSプロキシとクライアント）CUIを変更したり、受け入れAccessでCUIを挿入してはなりません。しかし、これを検出または防止するための方法はありません。
Attempting theft of service, a man-in-the-middle may try to insert, modify, or remove the CUI in the Access-Accept packets and Accounting packets. However, RADIUS Access-Accept and Accounting packets already provide integrity protection.
サービスの盗難をしようとすると、のman-in-the-middleは、挿入しようとする変更、またはアクセス・受け入れパケットおよびアカウンティングパケットにCUIを削除することができます。しかし、RADIUSアクセス - 受け入れ、会計パケットがすでに整合性の保護を提供します。
If the NAS includes CUI in an Access-Request packet, a man-in-the-middle may remove it. This will cause the Access-Accept packet to not include a CUI attribute, which may cause the NAS to reject the session. To prevent such a denial of service (DoS) attack, the NAS SHOULD include a Message-Authenticator(80) attribute within Access-Request packets containing a CUI attribute.
NASは、アクセス要求パケットでCUIが含まれている場合、のman-in-the-middleは、それを削除することがあります。これは、Access-受け入れパケットはNASがセッションを拒否することがありCUI属性を含めないようになります。サービス拒否（DoS）攻撃のような拒否を防ぐために、NASは、CUIの属性を含むアクセス要求パケット内のメッセージオーセンティケータ（80）属性を含むべきです。
The authors would like to thank Jari Arkko, Bernard Aboba, David Nelson, Barney Wolff, Blair Bullock, Sami Ala-Luukko, Lothar Reith, David Mariblanca, Eugene Chang, Greg Weber, and Mark Grayson for their feedback and guidance.
著者は、彼らのフィードバックとご指導をヤリArkko、バーナードAboba、デビッド・ネルソン、バーニー・ウルフ、ブレアBullockの、サミアラ - Luukko、ローターReithの、デビッドMariblanca、ユージン・チャン、グレッグ・ウェーバー、そしてマーク・グレイソンに感謝したいと思います。
[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.シンプソン、。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、 "RADIUSアカウンティング"、RFC 2866、2000年6月。
[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月。
[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月。
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
、RFC 3576、2003年7月[RFC3576]千葉、M.、Dommety、G.、エクランド、M.、ミトン、D.、およびB. Aboba、 "ユーザーサービス（RADIUS）でリモート認証ダイヤルへのダイナミックな承認拡張機能"。
[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月。
Authors' Addresses
著者のアドレス
Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA
ファリドAdrangiインテルコーポレーション2111 N.E.第25回アベニューヒルズボロ、OR 97124 USA
Phone: +1 503-712-1791 EMail: farid.adrangi@intel.com
電話：503-712-1791 Eメール+1：farid.adrangi@intel.com
Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Ottawa, Ontario K2K 3J1 Canada
アビLIORブリッジウォーターシステムズ社303テリー・フォックスドライブオタワ、オンタリオ州K2K 3J1カナダ
Phone: +1 613-591-9104 EMail: avi@bridgewatersystems.com
電話：+1 613-591-9104電子メール：avi@bridgewatersystems.com
Jouni Korhonen Teliasonera Corporation P.O.Box 970 FIN-00051, Sonera Finland
Jouni Korhonenテリアソネラ社P.O.Box 970 FIN-00051、フィンランドテリアソネラフィンランド
Phone: +358405344455 EMail: jouni.korhonen@teliasonera.com
電話：+358405344455 Eメール：jouni.korhonen@teliasonera.com
John Loughney Nokia Itamerenkatu 11-13 FIN-00180, Helsinki Finland
じょｈん ぉうｇｈねｙ のきあ いためれんかつ １１ー１３ ふぃんー００１８０、 へｌしんき ふぃんぁんｄ
Phone: +358504836342 EMail: john.loughney@nokia.com
電話：+358504836342 Eメール：john.loughney@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。