[要約] RFC 3702は、SIP (Session Initiation Protocol) において、ユーザー認証、サービス認可、および利用実績の記録（AAA）を一貫して行うための技術要件を定義しています。メッセージの完全性保護、リプレイ攻撃の防止、および課金管理に必要な詳細なセッション情報の伝達に関する必要条件を整理しています。IP電話（VoIP）やマルチメディアサービスにおいて、キャリアグレードのセキュリティと信頼性の高いユーザー管理を実現するためのプロトコル設計指針を提供することを目的としています。
Network Working Group J. Loughney
Request for Comments: 3702 Nokia
Category: Informational G. Camarillo
Ericsson
February 2004
Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP)
Session Initiation Protocol (SIP) における認証・認可・アカウンティング (AAA) 要件
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
As Session Initiation Protocol (SIP) services are deployed on the Internet, there is a need for authentication, authorization, and accounting of SIP sessions. This document sets out the basic requirements for this work.
セッション開始プロトコル（SIP）サービスがインターネット上に展開されるため、SIPセッションの認証、承認、および会計が必要です。このドキュメントは、この作業の基本的な要件を定めています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 4 1.3. Requirements Language. . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Common Requirements. . . . . . . . . . . . . . . . . . . 5 2.1.1. Communication within the Same Domain . . . . . . 5 2.1.2. Communication between Different Domains. . . . . 5 2.1.3. Discovery. . . . . . . . . . . . . . . . . . . . 5 2.1.4. Ability to Integrate Different Networks, Services and Users . . . . . . . . . . . . . . . 5 2.1.5. Updating SIP Server Entries. . . . . . . . . . . 5 2.1.6. SIP Session Changes. . . . . . . . . . . . . . . 5 2.1.7. Reliable Transfer of Protocol Messages . . . . . 5 2.1.8. Call Setup Times . . . . . . . . . . . . . . . . 6 2.1.9. Security . . . . . . . . . . . . . . . . . . . . 6 2.2. Authentication Requirements. . . . . . . . . . . . . . . 6 2.2.1. Authentication Based on SIP Requests . . . . . . 6 2.2.2. Flexible Authentication of SIP Requests. . . . . 6
2.3. Authorization Requirements . . . . . . . . . . . . . . . 6
2.3.1. Ability to Authorize SIP Requests. . . . . . . . 7
2.3.2. Information Transfer . . . . . . . . . . . . . . 7
2.3.3. User De-authorization. . . . . . . . . . . . . . 7
2.3.4. User Re-authorization. . . . . . . . . . . . . . 7
2.3.5. Support for Credit Control . . . . . . . . . . . 7
2.4. Accounting Requirements. . . . . . . . . . . . . . . . . 8
2.4.1. Separation of Accounting Information . . . . . . 8
2.4.2. Accounting Information Related to Session
Progression. . . . . . . . . . . . . . . . . . . 8
2.4.3. Accounting Information Not Related to Session
Progression. . . . . . . . . . . . . . . . . . . 9
2.4.4. Support for One-Time and Session-based
Accounting Records . . . . . . . . . . . . . . . 9
2.4.5. Support for Accounting on Different Media
Components . . . . . . . . . . . . . . . . . . . 9
2.4.6. Configuration of Accounting Generation
Parameters. . . . . . . . . . . . . . . . . . . 9
2.4.7. Support for Arbitrary Correlations . . . . . . . 9
3. Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. WLAN Roaming Using Third Party Service Providers . . . . 11
3.2. Conditional Authorization. . . . . . . . . . . . . . . . 12
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 13
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
The AAA working group is chartered to work on authentication, authorization, and accounting solutions for the Internet. This work consists of a base protocol, applications, end-to-end security application, and a general architecture for providing these services [3]. The AAA working group has specified applicability of AAA-based solutions for a number of protocols (e.g., AAA requirements for Mobile IP [4]).
AAAワーキンググループは、インターネットの認証、承認、および会計ソリューションに取り組むためにチャーターされています。この作業は、ベースプロトコル、アプリケーション、エンドツーエンドのセキュリティアプリケーション、およびこれらのサービスを提供するための一般的なアーキテクチャで構成されています[3]。AAAワーキンググループは、多くのプロトコル（モバイルIPのAAA要件[4]）に対するAAAベースのソリューションの適用性を指定しています。
SIP is a signalling protocol for creating, modifying, and terminating different types of sessions, such as Internet phone calls, multimedia distribution, and multimedia conferences [1]. SIP sessions have needs for session authentication, authorization, and accounting (AAA).
SIPは、インターネット電話、マルチメディア配信、マルチメディア会議など、さまざまな種類のセッションを作成、変更、および終了するためのシグナリングプロトコルです[1]。SIPセッションには、セッション認証、承認、会計（AAA）のニーズがあります。
In order to authenticate and authorize users, it is typically more convenient for SIP entities to communicate with an AAA sever than to attempt to store user credentials and profiles locally. SIP entities use the SIP-AAA interface to access the AAA server.
ユーザーを認証および承認するためには、通常、SIPエンティティがユーザーの資格情報とプロファイルをローカルに保存しようとするよりも、AAA Severと通信する方が便利です。SIPエンティティは、SIP-AAAインターフェイスを使用してAAAサーバーにアクセスします。
This document provides requirements for the interface between SIP entities and AAA servers. While accounting requirements are discussed, this document does not cover SIP charging or billing mechanisms.
このドキュメントは、SIPエンティティとAAAサーバー間のインターフェイスの要件を提供します。会計要件については説明しますが、このドキュメントでは、SIP課金または請求メカニズムをカバーしていません。
One possible use of this document would be to create an AAA application for SIP. Any protocol meeting the requirements outlined by this document could be used. Possible candidates, among others, are Diameter [3] and XML-based protocols following the web-services model.
このドキュメントの使用可能な1つは、SIP用のAAAアプリケーションを作成することです。このドキュメントで概説されている要件を満たすプロトコルを使用することができます。可能な候補者は、とりわけ、Webサービスモデルに続くDiameter[3]およびXMLベースのプロトコルです。
The main purpose of this document is to provide input to designers working on AAA applications using new protocols, such as Diameter and XML-based protocols. Nevertheless, a few limited RADIUS [5] extensions may meet some of the requirements in this document (for instance, some of the authentication requirements). We expect that while RADIUS with these limited extensions will meet particular functional requirements, it will not meet other important requirements. The following are some requirements that are not expected to be met by RADIUS:
このドキュメントの主な目的は、DiameterやXMLベースのプロトコルなどの新しいプロトコルを使用してAAAアプリケーションで作業するデザイナーに入力を提供することです。それにもかかわらず、いくつかの限られたRADIUS[5]拡張は、このドキュメントの要件の一部を満たす可能性があります（たとえば、認証要件の一部）。これらの限られた拡張機能を備えたRADIUSは特定の機能要件を満たしているが、他の重要な要件を満たすことはないと予想しています。以下は、RADIUSで満たされるとは期待されていない要件です。
1. Section 2.1.3: RADIUS does not support a discovery feature.
1. セクション2.1.3：RADIUSは発見機能をサポートしていません。
2. Section 2.1.7: RADIUS does not support reliable message delivery.
2. セクション2.1.7：RADIUSは信頼できるメッセージ配信をサポートしていません。
The following list contains the requirements that can be met by RADIUS or RADIUS extensions.
次のリストには、RADIUSまたはRADIUSの拡張機能で満たすことができる要件が含まれています。
1. Section 2.1.2: Communication between domains does not scale well in RADIUS. As a result, inter-domain communications are typically handled using a proxy architecture [6].
1. セクション2.1.2：ドメイン間の通信は、RADIUSで十分に拡張しません。その結果、ドメイン間通信は通常、プロキシアーキテクチャを使用して処理されます[6]。
2. Section 2.1.5: RADIUS clients would need to support Dynamic Authorization [7].
2. セクション2.1.5：RADIUSクライアントは、動的な承認をサポートする必要があります[7]。
3. Section 2.1.9: RADIUS clients would need to rely on a lower-layer security protocol, such as IPSec, to perform mutual authentication.
3. セクション2.1.9：RADIUSクライアントは、相互認証を実行するために、IPSECなどの低層セキュリティプロトコルに依存する必要があります。
4. Section 2.3.3: RADIUS clients would need to support Dynamic Authorization [7].
4. セクション2.3.3：RADIUSクライアントは、動的な承認をサポートする必要があります[7]。
5. Section 2.3.4: RADIUS clients would need to support Dynamic Authorization [7].
5. セクション2.3.4：RADIUSクライアントは、動的な承認をサポートする必要があります[7]。
AAA: Authentication, Authorization, and Accounting
AAA：認証、承認、および会計
Accounting: The collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. Accounting management requires that resource consumption be measured, rated, assigned, and communicated between appropriate parties [8].
会計：容量と傾向分析、コストの割り当て、監査、請求の目的のためのリソース消費データの収集。会計管理では、リソースの消費を測定、評価、割り当て、および適切な当事者間で伝達する必要があります[8]。
Accounting with credit control: The application checks the end user's account for coverage for the requested service event charge prior to execution of that service event.
クレジットコントロールを備えた会計：アプリケーションは、そのサービスイベントを実行する前に、要求されたサービスイベント料金の補償をエンドユーザーのアカウントにチェックします。
Home AAA Server: Server where user with which the user maintains an account relationship.
ホームAAAサーバー：ユーザーがアカウント関係を維持するユーザーがいるサーバー。
SIP: Session Initiation Protocol
SIP：セッション開始プロトコル
SIP proxies: SIP proxies are nodes which forward SIP requests and responses, as well as make policy decisions.
SIPプロキシ：SIPプロキシは、リクエストと応答を転送し、ポリシーの決定を下すノードです。
UAC: User Agent Client
UAC：ユーザーエージェントクライアント
UAS: User Agent Server
UAS：ユーザーエージェントサーバー
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、BCP 14 で説明されているように解釈されるものとします。
In this section, we list the requirements. Protocol solutions are not required to satisfy requirements for services that they do not support. For example, a solution that provides authentication services but not accounting services does not need to fulfill the accounting requirements. It is expected that solutions will fulfill the general requirements, plus the requirements for the specific services they are providing.
このセクションでは、要件をリストします。プロトコルソリューションは、サポートしていないサービスの要件を満たすために必要ではありません。たとえば、認証サービスを提供するが会計サービスを提供するソリューションでは、会計要件を満たす必要はありません。ソリューションは、一般的な要件に加えて、提供している特定のサービスの要件を満たすことが期待されています。
Section 2.1 lists general requirements, Section 2.2 lists requirements related to authentication, Section 2.3 lists requirements related to authorization, and Section 2.4 lists requirements related to accounting.
セクション2.1には、一般的な要件、セクション2.2には、認証に関連する要件をリストし、セクション2.3に認証に関連する要件をリストし、セクション2.4には会計に関連する要件がリストされています。
This section outlines general requirements on the SIP-AAA interface.
このセクションでは、SIP-AAAインターフェイスに関する一般的な要件の概要を説明します。
The SIP-AAA interface MUST support communications between a SIP entity and an AAA server that belong to the same domain.
SIP-AAAインターフェイスは、SIPエンティティと同じドメインに属するAAAサーバーとの間の通信をサポートしなければなりません (MUST)。
The SIP-AAA interface MUST support communications between a SIP entity in one domain and an AAA server in another domain. This MAY involve a proxy or a redirect server architecture between both entities.
SIP-AAAインターフェイスは、1つのドメイン内のSIPエンティティと別のドメインのAAAサーバー間の通信をサポートしなければなりません (MUST)。これには、両方のエンティティ間でプロキシまたはリダイレクトサーバーアーキテクチャが含まれる場合があります (MAY)。
With the information contained in the SIP messages, the SIP-AAA interface SHOULD be able to deduce the particular AAA server that has to be queried.
SIPメッセージに含まれる情報によって、SIP-AAAインターフェイスは、問い合わせる必要がある特定のAAAサーバーを推定できるべきです (SHOULD)。
The basic AAA architecture MUST be access independent. Service providers have to be able to provide AAA services for SIP, irrespective of access method or technology.
基本的なAAAアーキテクチャは、独立したアクセスでなければなりません (MUST)。サービスプロバイダーは、アクセス方法やテクノロジーに関係なく、SIPにAAAサービスを提供できる必要があります。
When required, the SIP-AAA interface MUST allow the AAA server to update the information that a SIP entity has about a user.
必要な場合、SIP-AAAインターフェイスは、SIPエンティティがユーザーについて持っている情報をAAAサーバーが更新できるようにしなければなりません (MUST)。
The SIP-AAA interface MUST allow a SIP entity to inform the AAA server about changes in the SIP session that may affect the authorization, authentication, or accounting for that SIP session.
SIP-AAAインターフェイスは、SIPエンティティが、そのSIPセッションの認可、認証、アカウンティングに影響しうるSIPセッションの変更についてAAAサーバーに通知できるようにしなければなりません (MUST)。
The SIP-AAA interface SHOULD provide a reliable transfer of AAA protocol messages between the SIP entity and the AAA server.
SIP-AAAインターフェイスは、SIPエンティティとAAAサーバー間のAAAプロトコルメッセージの信頼できる転送を提供すべきです (SHOULD)。
AAA SHOULD NOT unduly burden call setup times where appropriate. It may be reasonable to support some delay during registration, but delay during on-going sessions (especially real-time) is problematic.
AAAは、必要に応じてセットアップ時間のセットアップ時間を過度に負担するべきではありません (SHOULD NOT)。登録中のある程度の遅延をサポートすることは合理的かもしれませんが、進行中のセッション（特にリアルタイム）中の遅延に問題があります。
The SIP-AAA interface is a potential target of an attack. An eavesdropper may attempt to obtain confidential data by sniffing messages. Additionally, an active attacker may attempt to modify, insert, or replay messages between the SIP entity and the AAA server. Attackers may also attempt to impersonate legitimate SIP entities or AAA servers.
SIP-AAAインターフェイスは、攻撃の潜在的なターゲットです。盗聴者は、メッセージをスニッフィングすることにより、機密データを取得しようとする場合があります。さらに、アクティブな攻撃者は、SIPエンティティとAAAサーバー間のメッセージの変更、挿入、またはリプレイを試みる場合があります。攻撃者は、合法的なSIPエンティティまたはAAAサーバーになりすまそうとする場合もあります。
To address these threats, the SIP-AAA interface MUST support confidentiality, data origin authentication, integrity, and replay protection. In addition to this, bi-directional authentication between the SIP entity and the AAA server MUST be supported as well.
これらの脅威に対処するために、SIP-AAAインターフェイスは、機密性、データの起源認証、整合性、およびリプレイ保護をサポートしなければなりません (MUST)。これに加えて、SIPエンティティとAAAサーバーの間の双方向認証もサポートしなければなりません (MUST)。
This section outlines requirements on the SIP-AAA interface related to authentication.
このセクションでは、認証に関連するSIP-AAAインターフェイスに関する要件の概要を説明します。
The home AAA server MUST be able to authenticate a user based on any SIP request, except CANCELs and ACKs for non-2xx final responses.
Home AAAサーバーは、SIPリクエストに基づいてユーザーを認証できなければなりません (MUST)。
CANCELs and ACKs for non-2xx final responses are hop-by-hop requests that can be generated by proxies that do not have the user's credentials.
非2XX最終応答のキャンセルとACKは、ユーザーの資格情報を持たないプロキシによって生成できるホップバイホップリクエストです。
The SIP-AAA interface MUST be flexible enough to accommodate a variety of authentication mechanisms used to authenticate SIP requests. In particular, the SIP-AAA interface MUST be able to accommodate all the authentication mechanisms mandated by the SIP specifications (e.g., Digest authentication).
SIP-AAAインターフェイスは、SIPリクエストの認証に使用されるさまざまな認証メカニズムに対応するのに十分な柔軟性が必要です。特に、SIP-AAAインターフェイスは、SIP仕様（例：Digest認証）によって義務付けられているすべての認証メカニズムに対応できる必要があります。
This section outlines requirements on the SIP-AAA interface related to authorization.
このセクションでは、承認に関連するSIP-AAAインターフェイスに関する要件の概要を説明します。
The SIP-AAA interface MUST allow AAA servers to authorize any SIP request, except CANCELs and ACKs for non-2xx final responses.
SIP-AAAインターフェイスは、非2XX最終応答のキャンセルとACKを除き、AAAサーバーがSIPリクエストを承認することを許可しなければなりません (MUST)。
CANCELs and ACKs for non-2xx final responses are hop-by-hop requests that can be generated by proxies. SIP servers receiving a CANCEL or a ACK for a non-2xx final response do not challenge them, as they would do with an end-to-end request. Instead, they check at the transport or network layer that the entity sending the CANCEL or the ACK is the same as the one that generated the request being canceled or acked.
非2XX最終応答のキャンセルとACKは、プロキシによって生成できるホップバイホップリクエストです。CANCELまたはACKを受信するSIPサーバーは、2XX以外の最終応答のために、エンドツーエンドのリクエストを使用するように、それらに挑戦しません。代わりに、彼らはトランスポートまたはネットワーク層で、キャンセルまたはACKを送信するエンティティがキャンセルまたはACKのリクエストを生成したものと同じであることを確認します。
The SIP-AAA interface MUST allow transferring a wide range or set of information to be used to make an authorization decision. In particular, the SIP-AAA interface MUST allow an AAA server that is making an authorization decision to deliver the user profile to the SIP entity. Such a user profile may provide further information about the authorization decision to the SIP entity.
SIP-AAAインターフェイスは、承認決定を下すために、広範囲または情報のセットを使用することを許可しなければなりません (MUST)。特に、SIP-AAAインターフェイスは、ユーザープロファイルをSIPエンティティに配信するための許可決定を下しているAAAサーバーを許可しなければなりません (MUST)。このようなユーザープロファイルは、SIPエンティティへの承認決定に関するさらなる情報を提供する場合があります。
For instance, a SIP proxy receives an INVITE from user A addressed to user B. The SIP proxy queries an AAA server and gets the following answer: user A is authorized to call user B, as long as the requests are routed through a particular SIP proxy server C. In this case, the SIP proxy needs to use SIP loose routing techniques to forward the INVITE so that it traverses SIP proxy C before reaching user B.
たとえば、SIPプロキシは、ユーザーBにアドレス指定されたユーザーからINVITE状を受信します。SIPプロキシはAAAサーバーをクエリし、次の回答を取得します。プロキシサーバーC.この場合、SIPプロキシは、SIPルーズルーティングテクニックを使用してINVITE状を転送して、ユーザーBに到達する前にSIPプロキシCを横断するようにする必要があります。
The SIP-AAA interface MUST allow the AAA server to inform a SIP entity when a particular user is no longer authorized to perform a particular task, even if it is an ongoing task.
SIP-AAAインターフェイスは、特定のユーザーが継続的なタスクであっても、特定のタスクを実行することを許可されなくなった場合、AAAサーバーにSIPエンティティに通知できるようにしなければなりません (MUST)。
The SIP-AAA interface MUST allow the AAA server to inform a SIP entity that a particular authorization has been refreshed, and therefore, the user is still authorized to perform a particular task.
SIP-AAAインターフェイスは、AAAサーバーがSIPエンティティに特定の承認が更新されていることを通知できるようにしなければなりません (MUST)。したがって、ユーザーは特定のタスクを実行することを許可されています。
The SIP-AAA interface MUST support credit control. That is, the AAA server has to be able to check the end user's account for coverage for the requested service event charge before authorizing execution of that service event. Note that this requirement is related to accounting as well.
SIP-AAAインターフェイスは、クレジットコントロールをサポートしなければなりません (MUST)。つまり、AAAサーバーは、そのサービスイベントの実行を許可する前に、要求されたサービスイベント料金のカバレッジについてエンドユーザーのアカウントを確認できる必要があります。この要件は会計にも関連していることに注意してください。
Credit control is useful to implement prepaid services where all chargeable events related to a specific account are withheld from the end user when the credit of that account is exhausted or expired.
クレジット管理は、特定のアカウントに関連するすべての充電可能なイベントが、そのアカウントのクレジットが使い果たされたり期限切れになったときにエンドユーザーから差し控えられているプリペイドサービスを実装するのに役立ちます。
This section outlines requirements on the SIP-AAA interface related to accounting. Accounting is more than simple charging. Accounting may be a simple list of services accessed, servers accessed, duration of session, etc. Charging for SIP sessions can be extremely complex and requires some additional study. It is not the intent of this section to focus on charging.
このセクションでは、会計に関連するSIP-AAAインターフェイスに関する要件の概要を説明します。会計は単純な課金以上のものです。会計は、アクセスされたサービスの簡単なリスト、アクセスされたサーバー、セッションの期間などです。SIPセッションの課金は非常に複雑であり、追加の調査が必要です。このセクションの課金に焦点を合わせることは意図ではありません。
The information available to be accounted is different at SIP proxies and at SIP UAs. When end-to-end encryption is used, proxies do not have access to some parts of the SIP messages, while UAs have access to the whole messages. In addition to this, UAs typically have information about the session itself (e.g., number of audio packets exchanged during an audio session). Therefore, even if the SIP-AAA interface provides a means to transfer a wide range of data, some SIP nodes may not have access to it. In order to design a network, it is important to analyze which SIP nodes will be able to generate the desired account records.
考慮される情報は、SIPプロキシおよびSIP UASで異なります。エンドツーエンドの暗号化を使用する場合、プロキシはSIPメッセージの一部の部分にアクセスできず、UASはメッセージ全体にアクセスできます。これに加えて、UASには通常、セッション自体に関する情報があります（たとえば、オーディオセッション中に交換されるオーディオパケットの数）。したがって、SIP-AAAインターフェイスが幅広いデータを転送する手段を提供したとしても、一部のSIPノードはそれにアクセスできない場合があります。ネットワークを設計するには、どのSIPノードが目的のアカウントレコードを生成できるかを分析することが重要です。
AAA accounting messages MUST be able to provide granular information based on different parameters.
AAAアカウンティングメッセージは、さまざまなパラメーターに基づいて詳細な情報を提供できなければなりません (MUST)。
For example, it should be possible to separate "session duration" information from other information generated via additional services (e.g., 3-way calling). Separating accounting information makes it possible to provide accounting information to different parties based upon different aspects of the session.
たとえば、「セッション期間」情報を追加のサービス（3ウェイコールなど）を介して生成された他の情報から分離することができるはずです。会計情報を分離することで、セッションのさまざまな側面に基づいて、さまざまな関係者に会計情報を提供することができます。
There MUST be support in the SIP-AAA interface for accounting transfers where the information contained in the accounting data has a direct bearing on the establishment, progression, and termination of a session (e.g., reception of a BYE request).
会計データに含まれる情報が、セッションの確立、進行、および終了（たとえば、Byeリクエストの受信）に直接関係している場合、会計転送のためのSIP-AAAインターフェイスにサポートが必要です。
There MUST be support in the SIP-AAA interface for accounting transfers where the information contained in the accounting data does NOT have a direct bearing on the establishment, progression, and termination of a session (e.g., an instant MESSAGE that is not related to any session).
会計データに含まれる情報がセッションの確立、進行、終了に直接関係していない場合、会計転送のためのSIP-AAAインターフェイスにサポートが必要です（例えば、どのような関係にないインスタントメッセージがあります。セッション）。
The SIP-AAA interface MUST allow SIP servers to provide relevant accounting information for billing and inter-network settlement purposes to the AAA servers. Both one-time event accounting records and session based (START, INTERIM, STOP records) accounting MUST be supported.
SIP-AAAインターフェイスでは、SIPサーバーがAAAサーバーに請求およびネットワーク間の和解目的に関連する会計情報を提供できるようにしなければなりません (MUST)。1回限りのイベント会計レコードとセッションベース（開始、暫定、停止記録）の会計は両方ともサポートしなければなりません (MUST)。
The SIP-AAA interface MUST support accounting per media component (e.g., voice and video). That is, the SIP-AAA interface MUST be able to provide the AAA server with the types (e.g., voice and video) of the media streams of a given session.
SIP-AAAインターフェイスは、メディアコンポーネントごとの会計（音声やビデオなど）をサポートしなければなりません (MUST)。つまり、SIP-AAAインターフェイスは、特定のセッションのメディアストリームのタイプ（音声やビデオなど）をAAAサーバーに提供できなければなりません (MUST)。
Note, however, that some SIP entities do not have access to this information, which is typically carried in session descriptions. An example of a SIP entity with access to this information is a SIP UA (e.g., a gateway towards the PSTN).
ただし、一部のSIPエンティティはこの情報にアクセスできないことに注意してください。この情報は通常、セッションの説明に掲載されています。この情報にアクセスできるSIPエンティティの例は、SIP UA（たとえば、PSTNへのゲートウェイ）です。
The SIP-AAA interface MUST enable different parties to be charged per media component.
SIP-AAAインターフェイスは、メディアコンポーネントごとにさまざまな関係者を請求できるようにしなければなりません (MUST)。
The SIP-AAA interface MUST allow AAA servers to communicate parameters for accounting generation.
SIP-AAAインターフェイスは、AAAサーバーが会計生成のパラメーターを通信できるようにしなければなりません (MUST)。
Some networks need to be able to relate accounting information to some aspect of the SIP messages involved. So, the SIP-AAA interface MUST allow the AAA server to correlate a particular AAA session with any aspect of the SIP messages. For example, an AAA server that receives accounting information about a SIP dialog may be interested in knowing the Call-ID of the SIP dialog.
一部のネットワークでは、会計情報を関連するSIPメッセージの一部の側面に関連付ける必要があります。したがって、SIP-AAAインターフェイスは、AAAサーバーが特定のAAAセッションをSIPメッセージのあらゆる側面と関連付けられるようにしなければなりません (MUST)。たとえば、SIPダイアログに関する会計情報を受信するAAAサーバーは、SIPダイアログのコールIDを知ることに関心がある場合があります。
This section outlines some possible scenarios for SIP and AAA interaction. These are purely illustrative examples and do not impose any requirements.
このセクションでは、SIPおよびAAAインタラクションのいくつかの可能なシナリオの概要を説明します。これらは純粋に説明的な例であり、要件を課しません。
Figure 1 shows the typical call flow between a SIP proxy that communicates to an AAA server that performs authentication and authorization. All the examples are based on this flow.
図1は、認証と承認を実行するAAAサーバーに通信するSIPプロキシ間の典型的なコールフローを示しています。すべての例は、このフローに基づいています。
SIP SIP AAA
UAC Proxy Server
| | |
|---METHOD---->| |
| |--Is it OK?-->|
| | |
| |<-----OK------|
| | |
| | |
Figure 1: Call flow over the SIP-AAA interface
図1：SIP-AAAインターフェイス上のフローを呼び出します
The SIP proxy receives a request with certain credentials. The SIP UAC that generated the request may have included the credentials after having been challenged by the proxy using a 407 (Proxy Authentication Required) response. The SIP proxy sends a request to the AAA server asking if it is OK to provide a particular service for this request. The service may be simply routing forward the request or may consist of a more complex service. The AAA server checks that the credentials are correct (authentication), and checks the user profile. The user profile indicates that it is OK to provide the service, and responds to the SIP proxy. The SIP proxy provides the service requested by the SIP UAC.
SIPプロキシは、特定の資格情報を含むリクエストを受信します。リクエストを生成したSIP UACには、407（プロキシ認証が必要）応答を使用してプロキシによって挑戦された後、資格情報が含まれている可能性があります。SIPプロキシは、このリクエストに対して特定のサービスを提供することが問題であるかどうかを尋ねるAAAサーバーにリクエストを送信します。このサービスは、単にリクエストを転送するか、より複雑なサービスで構成されている場合があります。AAAサーバーは、資格情報が正しいことを確認し（認証）、ユーザープロファイルをチェックします。ユーザープロファイルは、サービスを提供することが問題であることを示し、SIPプロキシに応答します。SIPプロキシは、SIP UACから要求されたサービスを提供します。
User A wants to establish a voice session over the Internet with user B. User A wants its SIP signalling to be routed through SIP proxy C, because it provides a call log service (i.e., SIP proxy C sends an email to user A once a month with the duration of all the calls made during the month).
ユーザーAは、ユーザーBを使用してインターネット上で音声セッションを確立したいと考えています。ユーザーAは、SIPプロキシCを介してSIPシグナリングをルーティングしたいと考えています。月中に行われたすべての呼び出しの期間がある月）。
SIP AAA
User A Proxy C Server User B
| | | |
|----INVITE----->| | |
| | | |
|<-----407-------| | |
| | | |
|------ACK------>| | |
| | | |
|----INVITE----->| | |
| |---Is this OK?-->| |
| | | |
| |<------OK--------| |
| | | |
| |---------INVITE------------------>|
| | | |
| |-Accounting msg->| |
| | | |
Figure 2: WLAN roaming user
図2：WLANローミングユーザー
User A accesses the Internet using a WLAN access outside his home domain. User A, user B, SIP proxy C, and the home AAA server of user A are all in different domains.
ユーザーAは、ホームドメインの外側のWLANアクセスを使用してインターネットにアクセスします。ユーザーA、ユーザーB、SIPプロキシC、およびユーザーAのホームAAAサーバーはすべて異なるドメインにあります。
SIP proxy C challenges the initial INVITE from user A with a 407 (Proxy Authentication Required) response, and user A reissues the INVITE including his credentials. SIP proxy C consults user A's home AAA server, which confirms that the credentials belong to user A and that SIP proxy C can go ahead and provide its service for that call. SIP proxy C routes the INVITE forward towards user B and sends an accounting message to the AAA server, which will be used later to charge user A for the service provided by SIP proxy C.
SIP Proxy Cは、407（プロキシ認証が必要）応答を使用して、ユーザーAからの最初のINVITEに挑戦し、ユーザーは資格情報を含むINVITEを再発行します。SIP Proxy Cは、ユーザーAのホームAAAサーバーに相談します。これは、資格情報がユーザーAに属し、SIPプロキシCが先に進み、その呼び出しにサービスを提供できることを確認します。SIPプロキシCは、INVITE状をユーザーBに向かって前方にルーティングし、AAAサーバーに会計メッセージを送信します。AAAサーバーは、SIP Proxy Cが提供するサービスに対してユーザーAを請求するために後で使用されます。
User A is not in his home domain, but he still uses SIP proxy C (which is in user's A home domain) as the outbound proxy for an INVITE. SIP proxy C consults the home AAA server, which indicates that requests from user A have to be routed through SIP proxy D. SIP proxy C uses SIP loose routing so that the INVITE traverses D before reaching its destination. SIP proxy D will provide a call log service for user A.
ユーザーAは彼のホームドメインにはありませんが、彼はまだINVITEのアウトバウンドプロキシとしてSIPプロキシC（ユーザーのホームドメイン）を使用しています。SIPプロキシCは、Home AAA Serverに相談します。これは、ユーザーAからのリクエストをSIPプロキシDを介してルーティングする必要があることを示しています。SIPプロキシCは、SIPルーズルーティングを使用して、INVITE状が宛先に到達する前にDを通過するようにします。SIPプロキシDは、ユーザーAにコールログサービスを提供します。
SIP AAA SIP
User A Proxy C Server Proxy D
| | | |
|----INVITE----->| | |
| | | |
|<-----407-------| | |
| | | |
|------ACK------>| | |
| | | |
|----INVITE----->| | |
| |------Is this OK?---->| |
| | | |
| |<-OK if routed thru D-| |
| | | |
| |---------INVITE------------------>|
| | | |
Figure 3: Conditional Authorization
図3：条件付き承認
Security is a critical requirement of the SIP-AAA Interface. Section 2.1.9 describes the threats and security requirements. Sections 2.2 and 2.3 elaborate on the authentication and authorization requirements.
セキュリティは、SIP-AAAインターフェイスの重要な要件です。セクション2.1.9では、脅威とセキュリティ要件について説明します。セクション2.2および2.3は、認証と承認の要件について詳しく説明します。
The authors would like to thank the participants of the SIP interim meeting, May 2002 for their comments. The authors would also thank Harri Hakala, Mary Barns, Pete McCann, Jari Arkko, Aki Niemi, Juha Heinanen, Henry Sinnreich, Allison Mankin, and Bernard Aboba for their comments.
著者は、2002年5月のSIP暫定会議の参加者にコメントについて感謝したいと思います。著者はまた、ハリ・ハカラ、メアリー・バーンズ、ピート・マッキャン、ジャリ・アークコ、アキ・ニーミ、ジュハ・ヘイナネン、ヘンリー・シン・マライヒ、アリソン・マンキン、バーナード・アボバにコメントに感謝します。
The authors would like to thank the authors of the "AAA Requirements for IP Telephony/Multimedia" document, as it provided a basis for some of the information contained in this document.
著者は、このドキュメントに含まれる情報の一部の基礎を提供したため、「IPテレフォニー/マルチメディアのAAA要件」ドキュメントの著者に感謝します。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner, S.、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko、「Diameterベースプロトコル」、RFC 3588、2003年9月。
[4] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
[4] Glass, S., Hiller, T., Jacobs, S. and C. Perkins、「モバイルIP認証、承認、および会計要件」、RFC 2977、2000年10月。
[5] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial in User Service (RADIUS)", RFC 2865, June 2000.
[5] Rigney, C., Willens, S., Rubens, A. and W. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[6] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[6] Aboba, B. and J. Vollbrecht、「ローミングにおけるプロキシチェーンと政策実装」、RFC 2607、1999年6月。
[7] 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.
[7] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba、「Dynamic Authorization Extensions to Remote Authentication Dial in User Service（RADIUS）」、RFC 3576、2003年7月。
[8] Aboba, B., Arkko, J. and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
[8] Aboba, B., Arkko, J. and D. Harrington、「会計管理の紹介」、RFC 2975、2000年10月。
John Loughney Nokia Itamerenkatu 11-13 00180 Helsinki Finland
ジョン・ラフニー・ノキア・イタメレンカトゥ11-13 00180ヘルシンキフィンランド
EMail: John.Loughney@nokia.com
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson Advanced Signaling Research Lab。Fin-02420 Jorvas Finland
EMail: Gonzalo.Camarillo@ericsson.com
Copyright (C) The Internet Society (2004). 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.
著作権（c）The Internet Society（2004）。この文書は、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 currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。