[要約] RFC 4372は、Chargeable User Identity（CUI）に関する要約と目的を提供します。CUIは、通信ネットワーク上での利用者の識別情報を料金計算に使用するための仕組みです。このRFCは、CUIの概念と実装に関するガイドラインを提供し、ネットワークプロバイダー間の相互運用性を向上させることを目的としています。
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
充電可能なユーザーID
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).
Copyright（c）The Internet Society（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サーバーからユーザーの真のアイデンティティを隠すことができます。これらの方法では、user-name（1）属性には、RADIUSパケットをホームネットワークにルーティングするのに十分な匿名ID（例： @example.com）が含まれていますが、それ以外の場合はユーザーを識別するには不十分です。このメカニズムは状況によっては良い実践ですが、ローカルおよび中間ネットワークが現在のセッションを結合するために代理IDが必要な場合に問題があります。
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.
これは、ホームネットワークによって提供されるユニークなIDは、認証パケットと会計パケットを相関させるために、ローミングトランザクションに関与するすべての関係者に伝えることができるべきであることを意味します。
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.
特定のビジネスニーズを満たすためには、仲介者に独自のアイデンティティ、課税可能なユーザーアイデンティティ（CUI）を提供する必要があります。これは、ユーザーの匿名性を損なうべきではありません。このドキュメントで提供されるメカニズムにより、住宅オペレーターは、ユーザーを表す一時的なIDを提供し、同時にユーザーの匿名性を保護することにより、これらのビジネス要件を満たすことができます。
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 Alliance、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属性は、ローミングソリューションに悪影響を及ぼした半径仕様の運用的な抜け穴を閉じることを目的としています。CUIの使用は、プライバシー（PEAPやEAP-TTLなど）をサポートする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属性の代わりに他のいくつかのメカニズムが提案されています。これらのメカニズムは不十分であるか、他の問題を引き起こします。標準の半径クラス（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-Acceptパケットでサーバーからクライアントに送信される可能性があり、会計がサポートされている場合は、会計レクエストパケットの一部としてクライアントが会計サーバーに送信する必要があります。クライアントは、属性をローカルに解釈してはなりません。」したがって、RADIUSクライアントまたは仲介業者は、CUIが含まれているかどうかを決定することを妨げるクラス（25）属性を解釈してはなりません。さらに、RADIUSパケットに複数のクラス属性がある可能性があり、クラス（25）属性の内容はクライアントによって解釈されるわけではないため、ホームネットワークの外側のエンティティがCUIを含むものを決定することが難しくなります。
- On the use of RADIUS User-Name(1) attribute:
- radius user-name（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.
Access-Requestパケットに含まれるユーザー（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.
一方、Access-Acceptパケット内で送信されたユーザー名（1）属性の書き換えは、ユーザーを解析せずにAccess-Acceptパケットをルーティングするためにプロキシステート（33）属性を使用できるため、よりまれに発生しません。名前（1）属性。その結果、RADIUSサーバーは、Access-Requestパケット内のユーザー名（1）属性からのプロキシストリッピングルーティング情報が、Access-Acceptパケットに含まれるユーザー名（1）属性にこの情報を追加すると想定できません。。その結果、User-Name（1）属性がAccess-Acceptパケットで送信されると、Access-Requestパケットと会計レクエストパケットが異なるパスに従う可能性があります。この結果が望ましくない場合、RADIUSクライアントは、アカウンティングパケットで元のユーザー名（1）を使用する必要があります。したがって、CUIを会計パケットに含めることができるように、Access-Acceptパケット内のCUIをRADIUSクライアントに伝えるためには、別のメカニズムが必要です。
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）属性の使用法を変更します。したがって、CUIは、プライバシーをサポートするEAPメソッドが使用される場合、請求および詐欺防止に対する標準的なアプローチを提供します。関連するすべての問題を解決するものではありませんが、請求と詐欺の予防を提供します。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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-第3世代パートナーシッププロジェクトAAA-認証、承認、および会計AKA-認証と主要な契約CUI-課金型ユーザーアイデンティティGSMA -GSM Association IRAP -International Roaming Access Protocols Program -Network Access Server PEAP-保護された拡張認証プロトコルSIM SIM SIM - サブスクライバーIDモジュールTTLS -Tunneled Transport Layer Security WISPR -WirelessISPローミングWPA -Wi -Fi Protected Access
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].
このドキュメントは、RADIUSプロトコルが[RFC2865]および[RFC2866]で指定されているように動作し、[RFC3576]で指定されている動的認証、および[RFC3588]で指定されている直径プロトコルが動作することを前提としています。
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属性のないAccess-AcceptパケットがCUI属性を要求したRADIUSクライアントによって受信された場合、アクセスacceptパケットはアクセスrejectとして扱われる場合があります。
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がAccess-Acceptパケットに含まれている場合、CUI属性をサポートするRADIUSクライアントは、CUI属性がRADIUS Accounting-Request（Start、Interim、およびStop）に表示されることを確認する必要があります。この要件は、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.
Access-AcceptパケットでCUI属性を要求するRADIUSクライアントには、Access-Requestパケット内にCUI属性を含める必要があります。初期認証の場合、CUI属性には単一のNUL文字（NUL CUIと呼ばれます）が含まれます。また、再認証中、CUI属性には、アクセス認定に以前に受信されたCUI値（非NUL 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.
Access-Requestで非NUN CUI値を受信すると、Home Radius Serverは、CUIの値が以前のAccess-Acceptから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サーバーが、CUI（NULまたはその他に設定）を含むアクセスレクエストパケットを受信する場合、Access-AcceptパケットにCUI属性を含める必要があります。それ以外の場合、Access-RequestパケットにCUIが含まれていない場合、Home Radius ServerにAccess-AcceptパケットにCUI属性を含めるべきではありません。Access-Requestは、初期認証または再認証中に送信される場合があります。
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.
Access-RequestにCUIを含めることにより再認可中にCUIを要求したNASは、アクセスacceptでCUIを受け取ります。NASは、すべての会計メッセージにそのCUIの価値を含める必要があります。
A summary of the RADIUS CUI attribute is given below.
半径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
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を識別します。この文字列値は、特定のユーザーへの参照です。文字列値の形式とコンテンツは、Home Radiusサーバーによって決定されます。ユーザーへの参照の拘束力のある寿命は、ビジネス契約に基づいて決定されます。たとえば、寿命は1つの請求期間に設定できます。Home Radius Server以外の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
リクエスト拒否チャレンジアカウンティング＃属性要求
Note: If the Access-Accept packet contains CUI, then the NAS MUST include the CUI in Accounting Requests (Start, Interim, and Stop) packets.
注：Access-Acceptパケットに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プロキシおよびクライアント）は、CUIを変更したり、Access-Acceptに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.
サービスの盗難を試みると、中間者は、アクセスacceptパケットと会計パケットにCUIを挿入、変更、または削除しようとする場合があります。ただし、RADIUS Access-AcceptおよびAccountingパケットはすでに整合性保護を提供しています。
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を含めている場合、中間者がそれを削除する場合があります。これにより、Access-AcceptパケットはCUI属性を含めません。これにより、NASがセッションを拒否する可能性があります。このようなサービス拒否（DOS）攻撃を防ぐには、NASには、CUI属性を含むアクセスリケストパケット内にメッセージ-Authenticator（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.
著者は、Jari Arkko、Bernard Aboba、David Nelson、Barney Wolff、Blair Bullock、Sami Ala-Luukko、Lothar Reith、David Mariblanca、Eugene Chang、Greg Weber、Mark Graysonにフィードバックと指導に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C。、「Radius Accounting」、RFC 2866、2000年6月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、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.
[RFC3576] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、およびB. Aboba、「リモート認証のダイヤルインユーザーサービス（RADIUS）への動的認証拡張」、RFC 3576、2003年7月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
Authors' Addresses
著者のアドレス
Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA
ファリッド・アドラギ・インテル・コーポレーション2111 N.E.25th Avenue Hillsboro、または97124 USA
Phone: +1 503-712-1791
EMail: farid.adrangi@intel.com
Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Ottawa, Ontario K2K 3J1 Canada
Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Ottawa、オンタリオK2K 3J1カナダ
Phone: +1 613-591-9104
EMail: avi@bridgewatersystems.com
Jouni Korhonen Teliasonera Corporation P.O.Box 970 FIN-00051, Sonera Finland
Jouni Korhonen Teliasonera Corporation P.O.Box 970 Fin-00051、Sonera Finland
Phone: +358405344455
EMail: jouni.korhonen@teliasonera.com
John Loughney Nokia Itamerenkatu 11-13 FIN-00180, Helsinki Finland
ジョン・ラフニー・ノキア・イタメレンカトゥ11-13フィン-00180、ヘルシンキフィンランド
Phone: +358504836342
EMail: john.loughney@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://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）によって提供されます。