RFC3702 日本語訳
3702 Authentication, Authorization, and Accounting Requirements forthe Session Initiation Protocol (SIP). J. Loughney, G. Camarillo. February 2004. (Format: TXT=31243 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Loughney
Request for Comments: 3702 Nokia
Category: Informational G. Camarillo
Ericsson
February 2004
Loughneyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3702年のノキアカテゴリ: 情報のG.キャマリロエリクソン2004年2月
Authentication, Authorization, and Accounting
Requirements for the Session Initiation Protocol (SIP)
セッション開始プロトコルのための認証、承認、および会計要件(一口)
Status of this Memo
この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.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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.
Session Initiationプロトコル(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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 半径. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 用語と頭文字語. . . . . . . . . . . . . . . . 4 1.3。 要件言語。 . . . . . . . . . . . . . . . . . 4 2. 要件. . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1。 一般的な要件。 . . . . . . . . . . . . . . . . . . 5 2.1.1. 同じドメイン. . . . . . 5 2.1.2の中のコミュニケーション。 異なったドメインのコミュニケーション。 . . . . 5 2.1.3. 発見。 . . . . . . . . . . . . . . . . . . . 5 2.1.4. 異なったネットワーク、サービス、およびユーザ. . . . . . . . . . . . . . . 5 2.1.5を統合する能力。 一口サーバエントリーをアップデートします。 . . . . . . . . . . 5 2.1.6. セッション変化をちびちび飲んでください。 . . . . . . . . . . . . . . 5 2.1.7. プロトコルメッセージ. . . . . 5 2.1.8の信頼できる転送。 回. . . . . . . . . . . . . . . . 6 2.1の.9にセットアップに電話をしてください。 セキュリティ. . . . . . . . . . . . . . . . . . . . 6 2.2。 認証要件。 . . . . . . . . . . . . . . 6 2.2.1. 認証は要求. . . . . . 6 2.2.2を一口に基礎づけました。 一口要求のフレキシブルな認証。 . . . . 6
Loughney & Camarillo Informational [Page 1] RFC 3702 AAA Requirements for SIP February 2004
一口2004年2月のためのLoughneyとキャマリロの情報[1ページ]のRFC3702AAA要件
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
2.3. 承認要件. . . . . . . . . . . . . . . 6 2.3.1。 一口要求を認可する能力。 . . . . . . . 7 2.3.2. 情報転送. . . . . . . . . . . . . . 7 2.3.3。 ユーザ反-承認。 . . . . . . . . . . . . . 7 2.3.4. ユーザ再承認。 . . . . . . . . . . . . . 7 2.3.5. クレジットには、コントロール. . . . . . . . . . . 7 2.4をサポートしてください。 要件を説明します。 . . . . . . . . . . . . . . . . 8 2.4.1. 課金情報. . . . . . 8 2.4.2の分離。 課金情報はセッション進行に関連しました。 . . . . . . . . . . . . . . . . . . 8 2.4.3. 課金情報はセッション進行に関連しませんでした。 . . . . . . . . . . . . . . . . . . 9 2.4.4. 1回の、そして、セッションベースの会計で、記録. . . . . . . . . . . . . . . 9 2.4が.5であるとサポートしてください。 会計で、異なったメディアでコンポーネント. . . . . . . . . . . . . . . . . . . 9 2.4が.6であるとサポートしてください。 会計世代パラメタの構成。 . . . . . . . . . . . . . . . . . . 9 2.4.7. 任意の相関関係. . . . . . . 9 3のために、サポートします。 シナリオ。 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. 第三者サービスプロバイダー. . . . 11 3.2を使用することで移動するWLAN。 条件付きの承認。 . . . . . . . . . . . . . . . 12 4. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 12 5. 承認. . . . . . . . . . . . . . . . . . . . . . . 12 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1。 引用規格. . . . . . . . . . . . . . . . . . 13 6.2。 有益な参照. . . . . . . . . . . . . . . . . 13 7。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 14 8。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 15
1. Introduction
1. 序論
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ワーキンググループはAAAベースのソリューションの適用性を多くのプロトコルに指定しました。(例えば、モバイルIP[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)の必要性があります。
Loughney & Camarillo Informational [Page 2] RFC 3702 AAA Requirements for SIP February 2004
一口2004年2月のためのLoughneyとキャマリロの情報[2ページ]のRFC3702AAA要件
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とコミュニケートする切れるということです。 SIP実体は、AAAサーバにアクセスするのにSIP-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アプリケーションを作成するだろうことです。 要件がこのドキュメントで概説したどんなプロトコルミーティングも使用できました。 可能な候補は、特にDiameter[3]とウェブサービスモデルに従うXMLベースのプロトコルです。
1.1. RADIUS
1.1. 半径
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:
このドキュメントの主な目的は新しいプロトコルを使用することでAAAアプリケーションに取り組んでいるデザイナーに入力を提供することです、DiameterやXMLベースのプロトコルのように。 それにもかかわらず、いくつかの限られた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クライアントは、Dynamic Authorizationが[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などのように議定書を作ります。
Loughney & Camarillo Informational [Page 3] RFC 3702 AAA Requirements for SIP February 2004
一口2004年2月のためのLoughneyとキャマリロの情報[3ページ]のRFC3702AAA要件
4. Section 2.3.3: RADIUS clients would need to support Dynamic
Authorization [7].
4. セクション2.3.3: RADIUSクライアントは、Dynamic Authorizationが[7]であるとサポートする必要があるでしょう。
5. Section 2.3.4: RADIUS clients would need to support Dynamic
Authorization [7].
5. セクション2.3.4: RADIUSクライアントは、Dynamic Authorizationが[7]であるとサポートする必要があるでしょう。
1.2. Terminology and Acronyms
1.2. 用語と頭文字語
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 proxies: SIP proxies are nodes which forward SIP requests and
responses, as well as make policy decisions.
SIPプロキシ: SIPプロキシはSIP要求と応答を転送して、政策決定をするノードです。
UAC: User Agent Client
UAC: ユーザエージェントのクライアント
UAS: User Agent Server
UAS: ユーザエージェントサーバ
1.3. Requirements Language
1.3. 要件言語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように解釈されることであるべきです。
2. Requirements
2. 要件
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.
このセクションで、私たちは要件をリストアップします。 プロトコルソリューションは、それらがサポートしないサービスのための要件を満たすのに必要ではありません。 例えば、会計サービスではなく、認証サービスを提供するソリューションは会計要件を実現させる必要はありません。 ソリューションがそれらが提供している特定のサービスのために一般的な要件、および要件を実現させると予想されます。
Loughney & Camarillo Informational [Page 4] RFC 3702 AAA Requirements for SIP February 2004
一口2004年2月のためのLoughneyとキャマリロの情報[4ページ]のRFC3702AAA要件
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は会計に関連する要件をリストアップします。
2.1. Common Requirements
2.1. 一般的な要件
This section outlines general requirements on the SIP-AAA interface.
このセクションはSIP-AAAインタフェースに関する一般的な要件について概説します。
2.1.1. Communication within the Same Domain
2.1.1. 同じドメインの中のコミュニケーション
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サーバとのコミュニケーションをサポートしなければなりません。
2.1.2. Communication between Different Domains
2.1.2. 異なったドメインのコミュニケーション
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サーバとのコミュニケーションをサポートしなければなりません。 これは両方の実体の間のプロキシか再直接のサーバー・アーキテクチャにかかわるかもしれません。
2.1.3. Discovery
2.1.3. 発見
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インタフェースSHOULDに含まれた情報で、質問されなければならない特定のAAAサーバは推論できてください。
2.1.4. Ability to Integrate Different Networks, Services and Users
2.1.4. 異なったネットワーク、サービス、およびユーザを統合する能力
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アーキテクチャはアクセス独立者であるに違いありません。 サービスプロバイダーはアクセス法か技術の如何にかかわらずAAAサービスをSIPに供給できなければなりません。
2.1.5. Updating SIP Server Entries
2.1.5. 一口サーバエントリーをアップデートします。
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インタフェースで、AAAサーバはSIP実体がユーザに関して持っている情報をアップデートできなければなりません。
2.1.6. SIP Session Changes
2.1.6. 一口セッション変化
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サーバを知らせることができなければなりません。
2.1.7. Reliable Transfer of Protocol Messages
2.1.7. プロトコルメッセージの信頼できる転送
The SIP-AAA interface SHOULD provide a reliable transfer of AAA protocol messages between the SIP entity and the AAA server.
SIP-AAAインタフェースSHOULDはAAAプロトコルメッセージの信頼できる転送をSIP実体とAAAサーバの間に供給します。
Loughney & Camarillo Informational [Page 5] RFC 3702 AAA Requirements for SIP February 2004
一口2004年2月のためのLoughneyとキャマリロの情報[5ページ]のRFC3702AAA要件
2.1.8. Call Setup Times
2.1.8. 回にセットアップに電話をしてください。
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は適切であるところで呼び出しセットアップ回数を過度に負います。 登録の間、何らかの遅れをサポートするのが妥当であるかもしれませんが、継続しているセッション(特にリアルタイムの)の間の遅れは問題が多いです。
2.1.9. Security
2.1.9. セキュリティ
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インタフェースは秘密性、データ発生源認証、保全、および反復操作による保護をサポートしなければなりません。 また、これに加えて、SIP実体とAAAサーバの間の双方向の認証をサポートしなければなりません。
2.2. Authentication Requirements
2.2. 認証要件
This section outlines requirements on the SIP-AAA interface related to authentication.
このセクションは認証に関連するSIP-AAAインタフェースに関する要件について概説します。
2.2.1. Authentication Based on SIP Requests
2.2.1. 一口要求に基づく認証
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.
ホームAAAサーバはどんなSIP要求にも基づくユーザを認証できなければなりません、非2xxの最終的な応答のためのCANCELsとACKsを除いて。
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の最終的な応答のためのCANCELsとACKsはホップごとのユーザの資格証明書を持っていないプロキシが生成することができる要求です。
2.2.2. Flexible Authentication of SIP Requests
2.2.2. 一口要求のフレキシブルな認証
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認証)で強制されたすべての認証機構に対応できなければなりません。
2.3. Authorization Requirements
2.3. 承認要件
This section outlines requirements on the SIP-AAA interface related to authorization.
このセクションは承認に関連するSIP-AAAインタフェースに関する要件について概説します。
Loughney & Camarillo Informational [Page 6] RFC 3702 AAA Requirements for SIP February 2004
一口2004年2月のためのLoughneyとキャマリロの情報[6ページ]のRFC3702AAA要件
2.3.1. Ability to Authorize SIP Requests
2.3.1. 一口要求を認可する能力
The SIP-AAA interface MUST allow AAA servers to authorize any SIP request, except CANCELs and ACKs for non-2xx final responses.
SIP-AAAインタフェースで、AAAサーバは非2xxの最終的な応答のためにCANCELsとACKs以外のどんなSIP要求も認可できなければなりません。
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の最終的な応答のためのCANCELsとACKsはホップごとのプロキシが生成することができる要求です。 非2xxの最終的な応答のためにキャンセルかACKを受けるSIPサーバがそれらに挑戦しません、終わりから終わりへの要求を処理するだろうというとき。 代わりに、彼らは、輸送かネットワーク層でキャンセルかACKを送る実体が取り消されるか、またはackedされる要求を生成したものと同じであることをチェックします。
2.3.2. Information Transfer
2.3.2. 情報転送
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インタフェースで、承認決定をするのに使用されるために広範囲か1セットの情報を移さなければなりません。 特に、SIP-AAAインタフェースはSIP実体にユーザ・プロファイルを提供するという承認決定をしているAAAサーバを許容しなければなりません。 そのようなユーザ・プロファイルは承認決定に関する詳細を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.に宛てられたユーザAからINVITEを受け取ります。SIPプロキシは、AAAサーバについて質問して、以下の答えを得ます: ユーザAが、ユーザBに電話をするのに権限を与えられます、要求が特定のSIPプロキシサーバC.In本件で発送される限り、プロキシがINVITEを進めるのにSIPのゆるいルーティングのテクニックを使用する必要があるSIPによって、ユーザBに届くC前に、それはSIPプロキシを横断します。
2.3.3. User De-authorization
2.3.3. ユーザ反-承認
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.
AAAサーバは、SIP-AAAインタフェースでいつもう特定のユーザが特定のタスクを実行するのに権限を与えられないかをSIP実体に知らせることができなければなりません、それが進行中のタスクであっても。
2.3.4. User Re-authorization
2.3.4. ユーザ再承認
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実体に知らせることができなければなりません。
2.3.5. Support for Credit Control
2.3.5. 金融調整のサポート
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インタフェースは、クレジットがコントロールであるとサポートしなければなりません。 そのサービスイベントの実行を認可する前に、すなわち、AAAサーバは要求されたサービスイベント充電のために適用範囲がないかどうかエンドユーザのアカウントをチェックできなければなりません。 この要件がまた、会計に関連することに注意してください。
Loughney & Camarillo Informational [Page 7] RFC 3702 AAA Requirements for SIP February 2004
一口2004年2月のためのLoughneyとキャマリロの情報[7ページ]のRFC3702AAA要件
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.
金融調整は、そのアカウントのクレジットが消耗しているか、または吐き出されるとき、特定のアカウントに関連するすべての請求できるイベントがエンドユーザから差し控えられるところで前払いのサービスを実装するために役に立ちます。
2.4. Accounting Requirements
2.4. 会計要件
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ノードを分析するかが、必要な話が記録であると生成することができるのは、重要です。
2.4.1. Separation of Accounting Information
2.4.1. 課金情報の分離
AAA accounting messages MUST be able to provide granular information based on different parameters.
AAA会計メッセージは異なったパラメタに基づく粒状の情報を提供できなければなりません。
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ウェイの呼ぶ)で生成された他の情報と「セッション持続時間」情報を切り離すのは可能であるべきです。 課金情報を切り離すのに、セッションの異なった局面に基づく異なったパーティーに課金情報を提供するのは可能になります。
2.4.2. Accounting Information Related to Session Progression
2.4.2. セッション進行に関連する課金情報
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インタフェースにあるに違いありません。
Loughney & Camarillo Informational [Page 8] RFC 3702 AAA Requirements for SIP February 2004
一口2004年2月のためのLoughneyとキャマリロの情報[8ページ]のRFC3702AAA要件
2.4.3. Accounting Information Not Related to Session Progression
2.4.3. セッション進行に関連しない課金情報
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).
サポートが転送を説明するための会計データに含まれた情報がセッション(例えばどんなセッションのときにも関連しない即時のMESSAGE)の設立、進行、および終了に直接の関係を持っていないSIP-AAAインタフェースにあるに違いありません。
2.4.4. Support for One-Time and Session-based Accounting Records
2.4.4. 1回の、そして、セッションベースの会計帳簿のサポート
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サーバに提供できなければなりません。 1回のイベント会計帳簿とセッションの両方が会計をサポートしなければならない(START、INTERIM、STOP記録)を基礎づけました。
2.4.5. Support for Accounting on Different Media Components
2.4.5. 異なったメディアコンポーネントにおける会計のサポート
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インタフェースはメディアコンポーネント(例えば、声とビデオ)あたりの会計をサポートしなければなりません。 すなわち、SIP-AAAインタフェースは与えられたセッションのメディアストリームのタイプ(例えば、声とビデオ)をAAAサーバに提供できなければなりません。
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インタフェースは、異なったパーティーがメディアコンポーネント単位で請求されるのを可能にしなければなりません。
2.4.6. Configuration of Accounting Generation Parameters
2.4.6. 会計世代パラメタの構成
The SIP-AAA interface MUST allow AAA servers to communicate parameters for accounting generation.
SIP-AAAインタフェースで、AAAサーバは会計世代パラメタを伝えることができなければなりません。
2.4.7. Support for Arbitrary Correlations
2.4.7. 任意の相関関係のサポート
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サーバはSIPメッセージのどんな局面との特定のAAAセッションも関連させることができなければなりません。 例えば、SIP対話に関する課金情報を受け取るAAAサーバはSIP対話についてCall-IDを知りたがっているかもしれません。
Loughney & Camarillo Informational [Page 9] RFC 3702 AAA Requirements for SIP February 2004
一口2004年2月のためのLoughneyとキャマリロの情報[9ページ]のRFC3702AAA要件
3. Scenarios
3. シナリオ
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
一口一口AAA UAC Proxyサーバ
| | |
|---METHOD---->| |
| |--Is it OK?-->|
| | |
| |<-----OK------|
| | |
| | |
| | | |---メソッド---->|、|、| |--それは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プロキシはある資格証明書で要求を受け取ります。 407(プロキシAuthentication Required)応答を使用することでプロキシによって挑戦された後に、要求を生成したSIP UACは資格証明書を含んだかもしれません。 この要求のための特定のサービスを提供するのがOKであるなら、SIPプロキシはAAAサーバの尋ねるのに要求を送ります。 サービスは、単に要求を前方に発送しているか、または、より複雑なサービスから成るかもしれません。 AAAサーバは、資格証明書が正しいのを(認証)チェックして、ユーザ・プロファイルをチェックします。 ユーザ・プロファイルは、サービスを提供するのがOKであることを示して、SIPプロキシにこたえます。 SIPプロキシはSIP UACによって要求されたサービスを提供します。
Loughney & Camarillo Informational [Page 10] RFC 3702 AAA Requirements for SIP February 2004
一口2004年2月のためのLoughneyとキャマリロの情報[10ページ]のRFC3702AAA要件
3.1. WLAN Roaming Using Third Party Service Providers
3.1. 第三者サービスプロバイダーを使用することで移動するWLAN
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はUser Aが、SIPに、SIPプロキシCを通して発送されると合図して欲しいユーザB.と共にインターネットの上の声のセッションを確立したがっています、通話記録サービスを提供するので(すべての呼び出しの持続時間が月の間、作られている状態で、すなわち、SIPプロキシCは1カ月に一度ユーザAにメールを送ります)。
SIP AAA
User A Proxy C Server User B
AAAのユーザのためにプロキシCサーバーのユーザBをちびちび飲んでください。
| | | |
|----INVITE----->| | |
| | | |
|<-----407-------| | |
| | | |
|------ACK------>| | |
| | | |
|----INVITE----->| | |
| |---Is this OK?-->| |
| | | |
| |<------OK--------| |
| | | |
| |---------INVITE------------------>|
| | | |
| |-Accounting msg->| |
| | | |
| | | | |----招待----->|、|、|、|、|、|、| | <、-、-、-、--407-------| | | | | | | |------ACK------>|、|、|、|、|、|、| |----招待----->|、|、|、| |---このOKですか?-->|、|、|、|、|、|、| | <、-、-、-、-、--OK--------| | | | | | | |---------招待------------------>|、|、|、|、|、| |-会計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.
彼のホームドメインの外でWLANアクセスを使用することでユーザAはインターネットにアクセスします。 ユーザAのユーザA、ユーザB、SIPプロキシC、およびホーム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プロキシCは407(プロキシAuthentication Required)応答でユーザAから初期のINVITEに挑戦します、そして、ユーザAは彼の資格証明書を含むINVITEを再発行します。 SIPプロキシCはユーザAのホームAAAサーバに相談します。(それは、SIPプロキシCがその呼び出しに資格証明書がユーザAのものであり、前に進んで、サービスを提供できると確認します)。 SIPプロキシCは、SIPプロキシCによって提供されたサービスのためにユーザAを請求するためにユーザBに向かってINVITEフォワードを発送して、会計メッセージをAAAサーバに送ります。(それは、後で使用されるでしょう)。
Loughney & Camarillo Informational [Page 11] RFC 3702 AAA Requirements for SIP February 2004
一口2004年2月のためのLoughneyとキャマリロの情報[11ページ]のRFC3702AAA要件
3.2. Conditional Authorization
3.2. 条件付きの承認
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(ユーザAの家のドメインにあります)を使用しています。 SIPプロキシCが家のAAAサーバに相談して、どれが、ユーザAからの要求がSIPプロキシD. SIPプロキシCを通して発送されなければならないのを示すかがSIPのゆるいルーティングを使用するので、INVITEは目的地に到着する前に、Dを横断します。 SIPプロキシDは通話記録サービスをユーザAに提供するでしょう。
SIP AAA SIP
User A Proxy C Server Proxy D
AAAの一口ユーザのためにプロキシCサーバプロキシDをちびちび飲んでください。
| | | |
|----INVITE----->| | |
| | | |
|<-----407-------| | |
| | | |
|------ACK------>| | |
| | | |
|----INVITE----->| | |
| |------Is this OK?---->| |
| | | |
| |<-OK if routed thru D-| |
| | | |
| |---------INVITE------------------>|
| | | |
| | | | |----招待----->|、|、|、|、|、|、| | <、-、-、-、--407-------| | | | | | | |------ACK------>|、|、|、|、|、|、| |----招待----->|、|、|、| |------これはOKですか?---->|、|、|、|、|、|、| | <、-OK Dを通して発送されるなら| | | | | | | |---------招待------------------>|、|、|、|、|
Figure 3: Conditional Authorization
図3: 条件付きの認可
4. Security Considerations
4. セキュリティ問題
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 Interfaceの重大な要件です。 セクション2.1 .9 脅威とセキュリティ要件について説明します。 セクション2.2と2.3は認証と認可要件について詳しく説明します。
5. Acknowledgements
5. 承認
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.
作者は彼らのコメントについてSIPの当座のミーティング、2002年5月の関係者に感謝したがっています。 また、作者は彼らのコメントについてハリーHakala、メアリBarns、ピートマッキャン、ヤリArkko、アキNiemi、ユハHeinanen、ヘンリーSinnreich、アリソン・マンキン、およびバーナードAbobaに感謝するでしょう。
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要件」ドキュメントの作者に感謝したがっています、本書では含まれた情報のいくつかの基礎を提供したので。
Loughney & Camarillo Informational [Page 12] RFC 3702 AAA Requirements for SIP February 2004
一口2004年2月のためのLoughneyとキャマリロの情報[12ページ]のRFC3702AAA要件
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「使用のためのRequirement Levelsを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
6.2. Informative References
6.2. 有益な参照
[3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[3] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルンとG.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
[4] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP
Authentication, Authorization, and Accounting Requirements", RFC
2977, October 2000.
[4] S.、ヒラー、T.、ジェイコブズ、S.、C.パーキンス、および「モバイルIP認証、認可、および会計要件」とガラスで覆ってください、RFC2977、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.とウィレンスとS.とルーベン、A.とW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2865(2000年6月)。
[6] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[6]Aboba、B.、J.Vollbrecht、および「ローミングにおけるプロキシ推論と政策の実施」、RFC2607、6月1999日
[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] 千葉、M.、Dommety、G.、エクルンド、M.、ミットン、D.、およびB.Aboba、「リモート認証へのダイナミックな認可拡大はユーザでサービス(半径)にダイヤルします」、RFC3576、2003年7月。
[8] Aboba, B., Arkko, J. and D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000.
[8]AbobaとB.とArkkoとJ.とD.ハリントン、「会計管理への紹介」、RFC2975、2000年10月。
Loughney & Camarillo Informational [Page 13] RFC 3702 AAA Requirements for SIP February 2004
一口2004年2月のためのLoughneyとキャマリロの情報[13ページ]のRFC3702AAA要件
7. Authors' Addresses
7. 作者のアドレス
John Loughney Nokia Itamerenkatu 11-13 00180 Helsinki Finland
ジョンLoughneyノキアItamerenkatu11-13 00180ヘルシンキフィンランド
EMail: John.Loughney@nokia.com
メール: John.Loughney@nokia.com
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
ゴンサロキャマリロエリクソンは合図研究研究室を進めました。 フィン-02420Jorvasフィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Loughney & Camarillo Informational [Page 14] RFC 3702 AAA Requirements for SIP February 2004
一口2004年2月のためのLoughneyとキャマリロの情報[14ページ]のRFC3702AAA要件
8. Full Copyright Statement
8. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Loughney & Camarillo Informational [Page 15]
Loughneyとキャマリロ情報です。[15ページ]
一覧
スポンサーリンク
