Network Working Group J. Peterson
Request for Comments: 4484 NeuStar
Category: Informational J. Polk
Cisco
D. Sicker
CU Boulder
H. Tschofenig
Siemens
August 2006
Trait-Based Authorization Requirements
for the Session Initiation Protocol (SIP)
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP). While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system.
この文書では、セッション開始プロトコル（SIP）のために、形質ベースの認証に関連する要件のセットをレイアウトします。いくつかの認証メカニズムは、基本SIP仕様に記載されているが、特性ベースの認証は、セッション内の参加者の属性に基づいて政策決定を行うために使用される情報を提供します。このアプローチは、認可のための豊かなフレームワークを提供し、だけでなく、アイデンティティシステムのユーザーのために大きいプライバシーを可能にします。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Trait-Based Authorization Framework .............................4
4. Example Use Cases ...............................................7
4.1. Settlement for Services ....................................7
4.2. Associating Gateways with Providers ........................7
4.3. Permissions on Constrained Resources .......................8
4.4. Managing Priority and Precedence ...........................9
4.5. Linking Different Protocols ...............................10
5. Trait-Based Authorization Requirements .........................11
6. Security Considerations ........................................13
7. Acknowledgements ...............................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................13
This document explores requirements of the Session Initiation Protocol (SIP) [1] for enabling trait-based authorization. This effort stems from the recognition that when SIP requests are received by a User Agent Server (UAS), there are authorization requirements that are orthogonal to ascertaining of the identity of the User Agent Client (UAC). Supplemental authorization information might allow the UAS to implement non-identity-based policies that depend on further attributes of the principal that originated a SIP request.
この文書では、形質ベースの認証を有効にするためのセッション開始プロトコル（SIP）[1]の要件を探ります。この取り組みは、SIPリクエストはユーザエージェントサーバ（UAS）によって受信されたとき、ユーザエージェントクライアント（UAC）の身元の把握に直交する許可要件があるという認識から生じます。補足許可情報がUASは、SIP要求を発信元本のさらなる属性に依存非IDベースのポリシーを実装することが可能かもしれません。
For example, in traditional SIP authorization architectures, the mere fact that a UAC has been authenticated by a UAS doesn't mean that the UAS will grant the UAC full access to its services or capabilities -- in most instances, a UAS will compare the authenticated identity of the UAC to some set of users that are permitted to make particular requests (as a way of making an authorization decision). However, in large communities of users with few preexisting relationships (such as federations of discrete service providers), it is unlikely that the authenticated identity of a UAC alone will give a UAS sufficient information to decide how to handle a given request.
例えば、従来のSIP認証アーキテクチャで、UACがUASによって認証されたという単なる事実は、UASはそのサービスや機能へのUACのフルアクセス権を付与することを意味するものではありません - ほとんどの場合、UASは比較します（認可判断を作る方法など）特定の要求を行うことが許可されているユーザーのいくつかのセットにUACのアイデンティティを認証し。しかし、（そのような個別のサービスプロバイダの連合など）いくつかの既存の関係を持つユーザーの大規模なコミュニティでは、UACの認証された識別情報だけではUASに与えられたリクエストの処理方法を決定するのに十分な情報を与えることはほとんどありません。
Trait-based authorization entails an assertion by an authorization service of attributes associated with an identity. An assertion is a sort of document consisting of a set of these attributes that are wrapped within a digital signature provided by the party that generates the assertion (the operator of the authorization service). These attributes describe the 'trait' or 'traits' of the identity in question -- facts about the principal corresponding to that identity. For example, a given principal might be a faculty member at a university. An assertion for that principal's identity might state that they have the 'trait' of 'is a faculty member', and the assertion would be issued (and signed) by a university. When a UAS receives a request with this trait assertion, if it trusts the signing university, it can make an authorization decision based on whether or not faculty members are permitted to make the request in question, rather than just looking at the identity of the UAC and trying to discern whether or not they are a faculty member through some external means. Thus, these assertions allow a UAS to authorize a SIP request without having to store or access attributes associated with the identity of the UAC itself. Even complex authorization decisions based the presence of multiple disjointed attributes are feasible; for example, a 'faculty' member could be part of the 'chemistry' department, and both of these traits could be used to make authorization decisions in a given federation.
形質ベースの認証は、IDに関連付けられた属性の認可サービスでアサーションを伴います。アサーションは、アサーションを生成するパーティ（認可サービスの事業者）によって提供されたデジタル署名の中にラップされ、これらの属性の組からなる文書の一種です。そのIDに対応する主要についての事実 - これらの属性は、「特性」または問題のアイデンティティの「特徴」を説明します。例えば、与えられた校長は、大学の教員であるかもしれません。そのプリンシパルのアイデンティティのためのアサーションは、彼らが「教員である」の特性」を持っていると述べているかもしれない、と主張は、大学によって発行された（と署名）されるだろう。 UASは、この特性アサーションとの要求を受け取ると、それは署名大学を信頼している場合、それは教員が問題の要求を行うことが許可されているかどうかに基づいて承認決定を行うだけではなく、UACのアイデンティティを見てすることができますそして、彼らはいくつかの外部手段を通じて教員あるかどうかを識別しようとしています。したがって、これらの主張は、UASは、UAC自体のアイデンティティに関連付けられた属性を格納またはアクセスしなくても、SIP要求を認証することを可能にします。複数のバラバラの属性の存在をベースとしても、複雑な承認決定が可能です。例えば、「教員」メンバは、「化学」部門の一部とすることができる、およびこれらの形質の両方が与えられたフェデレーションでの認可決定を行うために使用することができます。
It is easy to see how traits can be used in a single administrative domain, for example, a single university, where all users are managed under the same administration. In order for traits to have a broader usage for services like SIP, which commonly are not bounded by administrative domains, domains that participate in a common authorization scheme must federate with one another. The concept of federation is integral to any trait-based authorization scheme. Domains that federate with one another agree on the syntax and semantics of traits -- without this consensus, trait-based authorization schemes would only be useful in an intradomain context. A federation is defined as a set of administrative domains that implement common policies regarding the use and applicability of traits for authorization decisions. Federation necessarily implies a trust relationship, and usual implies some sort of pre-shared keys or other means of cryptographic assurance that a particular assertion was generated by an authorization service that participates in the federation.
それは、特性は、例えば、単一の管理ドメインで使用することができる方法を確認することは容易である、すべてのユーザーが同じ管理の下で管理されている単一の大学、。形質は、一般的に管理ドメインで囲まれていないSIPのようなサービスのためのより広範な使用を持っているようにするためには、共通の認証スキームに参加ドメインが相互に連携しなければなりません。フェデレーションの概念は、任意の特性に基づく認可スキームに不可欠です。互いに連携ドメインは、形質の構文とセマンティクスに合意 - この合意なしに、特性ベースの認証スキームはドメイン内のコンテキストで有用であろう。フェデレーションは、認可の決定のための形質の使用および適用に関する一般的なポリシーを実装管理ドメインの集合として定義されます。フェデレーションは、必ずしも信頼関係を意味し、通常は、事前共有キーまたは特定のアサーションがフェデレーションに参加する許可サービスによって生成された暗号保証する他の手段のいくつかの並べ替えを意味しています。
In fact, when trait-based authorization is used, an assertion of attributes can be presented to a UAS instead of the identity of user of the UAC. In many cases, a UAS has no need to know who, exactly, has made a request -- knowing the identity is only a means to the end of matching that identity to policies that actually depend on traits independent of identity. This fact allows trait-based authorization to offer a very compelling privacy and anonymity solution. Identity becomes one more attribute of an assertion that may or may not be disclosed to various destinations.
実際には、特性ベースの認証を使用する場合、属性の主張は、UASの代わりに、UACのユーザーのIDに提示することができます。身元を知って、実際にアイデンティティの独立した特性に依存ポリシーにそのIDを照合の最後に唯一の手段である - 多くの場合、UASは、正確に、要求がなされたかを知るする必要がありません。この事実は、非常に説得力のプライバシーと匿名性ソリューションを提供するために、形質ベースの認証を可能にします。アイデンティティは、または様々な目的地に開示されていてもいなくてもよいアサーションの1つの以上の属性になります。
Trait-based authorization for SIP depends on authorization services that are trusted by both the UAC and the UAS that wish to share a session. For that reason, the authorization services described in this document are most applicable to clients either in a single domain or in federated domains that have agreed to trust one another's authorization services. This could be common in academic environments, or business partnerships that wish to share attributes of principals with one another. Some trait-based authorization architectures have been proposed to provide single sign-on services across multiple providers.
SIPのための形質ベースの認証は、UACとセッションを共有したいUASの両方によって信頼されている認証サービスに依存します。そのため、このドキュメントで説明する認証サービスは、単一のドメインまたは1に別の認証サービスを信頼することに合意したフェデレーションドメインのいずれかでクライアントに最も適しています。これは学術的環境、または互いにプリンシパルの属性を共有したいビジネスパートナーシップに共通である可能性があります。いくつかの特性ベースの認証アーキテクチャには、複数のプロバイダ間でシングルサインオンサービスを提供するために提案されてきました。
Although trait-based identity offers an alternative to traditional identity architectures, this effort should be considered complementary to the end-to-end cryptographic SIP identity effort [3]. An authentication service might also act as an authorization service, generating some sort of trait assertion token instead of an authenticated identity body.
トレイトベースのアイデンティティは、伝統的なアイデンティティ・アーキテクチャに代わるものを提供していますが、この努力は、エンドツーエンドの暗号化SIPアイデンティティの努力と相補的な考慮すべきである[3]。認証サービスは、形質の主張のいくつかの並べ替えのトークンの代わりに、認証されたアイデンティティの体を生成する、認証サービスとして動作するかもしれません。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、及び「OPTIONAL」は、RFC 2119 [2]に記載のコンプライアントSIP実装の要求レベルを示すものとして解釈されるべきです。
A trait-based authorization architecture entails the existence of an authorization service. Devices must send requests to an authorization service in order to receive an assertion that can be used in the context of a given network request. Different network request types will often necessitate different or additional attributes in assertions from the authorization service.
トレイトベースの認証アーキテクチャは、認可サービスの存在を伴います。デバイスは、与えられたネットワーク要求のコンテキストで使用可能なアサーションを受信するために認可サービスに要求を送信する必要があります。異なるネットワーク要求の種類は、多くの場合、認証サービスからのアサーションに異なるまたは追加の属性を必要とします。
For the purposes of SIP, SIP requests might be supplied to an authorization service to provide the basis for an assertion. It could be the case that a user agent will take a particular SIP request, such as an INVITE, for which it wishes to acquire an assertion and forward this to the authorization service (in a manner similar to the way that an authenticated identity body is requested in [3]). User agents might also use a separate protocol to request an assertion. In either case, the client will need to authenticate itself to an authorization service before it receives an assertion. This authentication could use any of the standard mechanisms described in RFC 3261 [1], or use some other means of authentication.
SIPの目的のために、SIPリクエストは、アサーションのための基礎を提供するために、許可サービスに供給される可能性があります。これは、ユーザエージェントは、それがアサーションを取得し、認証された識別体があることを方法と同様にして（許可サービスにこれを転送することを望むため、このようなINVITEように、特定のSIP要求を取る場合であってもよいです[3]）に要請しました。ユーザエージェントはまた、アサーションを要求するために別のプロトコルを使用する場合があります。いずれの場合も、クライアントは、それがアサーションを受信する前に、認証サービスに自分自身を認証する必要があります。この認証は、RFC 3261に記載されている標準的な機構のいずれかを使用することができる[1]、または認証の他の手段を使用します。
Once a SIP UA has an assertion, it will need some way to carry an assertion within in a SIP request. It's possible that this assertion could be provided by reference or by value. For example, a SIP UA could include a MIME body within a SIP request that contains the assertion; this would be inclusion by value. Alternatively, content indirection [4], or some new header, could be used to provide a URI (perhaps an HTTP URL) where interested parties could acquire the assertion; this is inclusion by reference.
SIP UAはアサーションを持っていると、それは、SIPリクエストで内アサーションを運ぶためにいくつかの方法が必要になります。これは、この主張は、参照することによってまたは値によって提供されている可能性があります。例えば、SIP UAは、アサーションが含まれているSIP要求内のMIME本体を含むことができます。これは値によって含めることになります。あるいは、コンテンツ間接[4]、またはいくつかの新しいヘッダ、利害関係者は、アサーションを取得できたURI（おそらく、HTTPのURL）を提供するために使用することができます。これは、参照によって包含されます。
The basic model is as follows:
次のように基本的なモデルは次のようになります。
+----------------+ | |
| +------------+ | Request | +------------+ |
| | Entity | |------------------------>| | Assertion | |
| | requesting | | | | Granting | |
| | authz | |<------------------------| | Entity | |
| | assertions | | Assertion | +------------+ |
| +------------+ | | ^ |
| | | | . Trust |
| | | | . Rel. |
| | | | v |
| | | | +------------+ |
| Transfer | | | Assertion | |
| | | | | Verifying | |
| | | | | Entity | |
| | | | +------------+ |
| | | | |
| v | +----------------+
| +------------+ | Service Request + ^ |
| | Entity | | Assertion | |
| | using authz| | -----------------------------+ |
| | assertion | | |
| +------------+ | <-------------------------------+
+----------------+ Response/Error
The entity requesting authorization assertions (or the entity that gets some assertions granted) and the entity using these authorization assertions might be co-located in the same host or domain, or they might be entities in different domains that share a federate with one another. The same is true for the entity that grants these assertions to a particular entity and the entity that verifies these assertions.
エンティティは、認証アサーション（または許可されたいくつかのアサーションを取得するエンティティ）を要求し、これらの認可アサーションを使用してエンティティは、同じホストまたはドメイン内に一緒に配置される可能性があります、または彼らはお互いにフェデレートを共有し、異なるドメイン内のエンティティであるかもしれません。同じことは、特定のエンティティとこれらの主張を検証エンティティにこれらのアサーションを付与するエンティティのために真です。
From a protocol point of view, it is worth noting that the process of obtaining some assertions might happen some time before the usage of these assertions. Furthermore, different protocols might be used and the assertions may have a lifetime that might allow that these assertions are presented to the verifying entity multiple times (during the lifetime of the assertion).
ビューのプロトコルの観点から、それはいくつかのアサーションを取得するプロセスは、これらのアサーションの使用前にいくつかの時間を起こるかもしれないことは注目に値します。さらに、異なるプロトコルが使用されるかもしれないと主張は、これらのアサーションは（アサーションの存続期間中に）検証エンティティに複数回提示されることを可能にするかもしれない寿命を有していてもよいです。
Some important design decisions are associated with carrying assertions in a SIP request. If an assertion is carried by value, or uses a MIME-based content indirection system, then proxy servers will be unable to inspect the assertion themselves. If the assertion were referenced in a header, however, it might be possible for the proxy to acquire and inspect the assertion itself. There are certainly architectures in which it would be meaningful for proxy servers to apply admissions controls based on assertions.
いくつかの重要な設計上の決定は、SIPリクエストにアサーションを運ぶと関連しています。アサーションが値によって運ばれる、またはMIMEベースのコンテンツ間接システムを使用している場合、プロキシサーバは、アサーション自体を検査することができません。アサーションは、ヘッダ内で参照された場合、プロキシは、取得と主張自体を検査するために、しかし、それは可能かもしれません。プロキシサーバがアサーションに基づいて入学制御を適用することは意味があると思われる中でのアーキテクチャは確かにあります。
It is also the case that carrying assertions by reference allows versatile access controls to be applied to the assertion itself. For instance, an HTTP URL where an assertion could be acquired could indicate a web server that challenged requests, and only allowed certain authorized sources to inspect the assertion, or that provided different versions of the assertion depending on who is asking. When a SIP UA initiates a request with privacy controls [5], a web server might provide only trait information ('faculty', 'student', or 'staff') to most queries, but provide more detailed information, including the identity of the originator of the SIP request, to certain privileged askers. The end-users that make requests should have some way to inform authorization services of the attributes that should be shared with particular destinations.
それはまた、参照によりアサーションを搬送する汎用性の高いアクセス制御を主張自体に適用されることを可能にする場合です。例えば、アサーションを取得することができHTTPのURLは、リクエストに挑戦し、Webサーバを示している可能性があり、かつ唯一の特定の権限の源はアサーションを検査することができ、またはそれを求めている人に応じて、アサーションの異なるバージョンを提供します。 SIP UAは、プライバシー制御で要求を開始すると、[5]、Webサーバは、ほとんどのクエリにのみ特性情報（「教員」、「学生」、または「スタッフ」）提供しますが、より詳細な情報を提供する、のアイデンティティを含むかもしれません特定の特権askersへのSIP要求の発信元、。要求を行うエンドユーザーは、特定の送信先と共有しなければならない属性の認証サービスを通知するためにいくつかの方法を持っている必要があります。
Assertions themselves might be scoped to a particular SIP transaction or SIP dialog, or they might have a longer lifetime. The recipient of an assertion associated with a SIP request needs to have some way to verify that the authorization service intended that this assertion could be used for the request in question. However, the format of assertions is not specified by these requirements.
アサーション自体は、特定のSIPトランザクションまたはSIPダイアログにスコープされる可能性があります、または彼らは長い寿命を持っているかもしれません。 SIPリクエストに関連したアサーションの受信者は、認可サービスは、この主張が問題の要求のために使用することができることを意図していることを確認するためにいくつかの方法を持っている必要があります。しかし、アサーションの形式は、これらの要件によって指定されていません。
Trait assertions for responses to SIP requests are outside the scope of these requirements; it is not clear if there is any need for the recipient of a request to provide authorization data to the requestor.
SIP要求への応答のための形質アサーションは、これらの要件の範囲外です。要求者に認証データを提供するための要求の受信者の必要があるかどうかは明らかではありません。
Trait-based authorization has significant applicability to SIP. There are numerous instances in which it is valuable to assert particular facts about a principal other than the principal's identity to aid the recipient of a request in making an authorization policy decision. For example, a telephony service provider might assert that a particular user is a 'customer' as a trait. An emergency services network might indicate that a particular user has a privileged status as a caller.
形質ベースの認証は、SIPへの重要な適用性を有します。承認ポリシーの意思決定における要求の受信者を支援するために、プリンシパルのアイデンティティ以外の元本について特定の事実を主張する貴重である多数のインスタンスがあります。例えば、テレフォニーサービスプロバイダーは、特定のユーザが形質として「顧客」であることを主張するかもしれません。緊急サービスネットワークは、特定のユーザが呼び出し元と特権的地位を持っていることを示している可能性があります。
The following use cases are by no means exhaustive, but provide a few high-level examples of the sorts of services that trait-based authorization might provide. All of the cases below consider interdomain usage of authorization assertions.
次の使用例は、徹底的決してですが、特性ベースの認証を提供するかもしれないサービスの種類のいくつかの高レベルの例を示します。以下の例はすべて、認証アサーションのドメイン間の使用を検討してください。
When endpoints in two domains share real-time communications services, sometimes there is a need for the domains to exchange accounting and settlement information in real-time. The operators of valuable resources (for example, Public Switched Telephone Network (PSTN) trunking, conference bridges, or the like) in the called domain may wish to settle with the calling domain (either with the operators of the domain or a particular user), and some accounting operations might need to complete before a call is terminated. For example, a caller in one domain might want to access a conference bridge in another domain, and the called domain might wish to settle for the usage of the bridge with the calling domain. Or in a wireless context, a roaming user might want to use services in a visited network, and the visited network might need to understand how to settle with the user's home network for these services.
二つのドメイン内のエンドポイントは、リアルタイム通信サービスを共有する場合、時々ドメインはリアルタイムで会計および決済情報を交換するための必要性があります。貴重な資源のオペレータは、（いずれかのドメインまたは特定のユーザーの事業者との）呼び出し元のドメインと和解することを望むかもしれないというドメインで（例えば、公衆交換電話網（PSTN）トランキング、会議ブリッジ、などを交換しました） 、およびいくつかの経理業務は、コールが終了する前に完了する必要がある場合があります。例えば、1つのドメイン内の発信者は、別のドメイン内の会議ブリッジにアクセスする場合があります、と呼ばれるドメインが、呼び出し元のドメインとブリッジの使用のために解決したいかもしれません。または無線文脈で、ローミングユーザーは、訪問先ネットワークのサービスを使用する場合がありますし、訪問先ネットワークは、これらのサービスのためのユーザのホームネットワークで解決する方法を理解する必要がある場合があります。
Assuming that the calling domain constitutes some sort of commercial service capable of exchanging accounting information, the called domain may want to verify that the remote user has a billable account in good standing before allowing a remote user access to valuable resources. Moreover, the called domain may need to discover the network address of an accounting server and some basic information about how to settle with it.
呼び出し元のドメインは、会計情報を交換できる商用サービスのいくつかの並べ替えを構成していると仮定すると、呼び出されたドメインは、貴重なリソースへのリモートユーザーアクセスを許可する前に、リモートユーザーが良好な状態で請求可能なアカウントを持っていることを確認することをお勧めします。また、呼び出されたドメインは、アカウンティングサーバとそれに落ち着くする方法についていくつかの基本的な情報のネットワークアドレスを発見する必要があるかもしれません。
An authorization assertion created by the calling domain could provide the called domain with an assurance that a user's account can settle for a particular service. In some cases, no further information may be required to process a transaction, but if more specific accounting data is needed, traits could also communicate the network address of an accounting server, the settlement protocol that should be used, and so on.
呼び出し元のドメインで作成された認証アサーションは、ユーザーのアカウントが特定のサービスのために解決できることを保証して呼び出されたドメインを提供することができます。いくつかのケースでは、それ以上の情報は、トランザクションを処理するのに必要ないかもしれないが、より具体的な会計データが必要な場合、特性はまた、アカウンティングサーバのネットワークアドレス、ように使用すべきであり、決済プロトコルを通信することができます。
Imagine a case where a particular telephone service provider has deployed numerous PSTN-SIP gateways. When calls come in from the PSTN, they are eventually proxied to various SIP user agents. Each SIP user agent server is interested to know the identity of the PSTN caller, of course, which could be given within SIP messages in any number of ways (in SIP headers, bodies, or what have you). However, in order for the recipient to be able to trust the identity (in this instance, the calling party's telephone number) stated in the call, they must first trust that the call originated from the gateway and that the gateway is operated by a known (and trusted) provider.
特定の電話サービスプロバイダは、多数のPSTN-SIPゲートウェイを展開した場合を想像します。呼び出しはPSTNから来るとき、彼らは最終的に、様々なSIPユーザエージェントにプロキシされています。各SIPユーザエージェントサーバは、いくつかの方法でSIPメッセージの中に与えられることができ、もちろんのPSTN発信者の身元、知って興味を持っている（SIPヘッダ、ボディ内に、または何を持っています）。ただし、受信者が身元を信頼することができるようにするために（この例では、発呼者の電話番号が）呼び出しで述べたように、彼らは最初のコールがゲートウェイから発信することを信頼しなければならないとゲートウェイは、既知によって運営されていることプロバイダを（信頼できます）。
There are a number of ways that a service provider might try to address this problem. One possibility would be routing all calls from gateways through a recognizable 'edge' proxy server (say, 'sip.example.com'). Accordingly, any SIP entity that received a request via the edge proxy server (assuming the use of hop-by-hop mutual cryptographic authentication) would know the service provider from whom the call originated. However, it is possible that requests from the originating service provider's edge proxy might be proxied again before reaching the destination user agent server, and thus in many cases the originating service provider's identity would be known only transitively. Moreover, in many architectures requests that did not originate from PSTN gateways could be sent through the edge proxy server. In the end analysis, the recipient of the request is less interested in knowing which carrier the request came from than in knowing that the request came from a gateway.
サービスプロバイダは、この問題に対処しようとするかもしれないいくつかの方法があります。一つの可能性は、認識可能な「エッジ」プロキシ・サーバ（例えば、「sip.example.com」）を介してゲートウェイからのすべてのコールをルーティングすることになります。したがって、エッジプロキシサーバを介して要求を受信したSIPエンティティは、コールが発信者からサービスプロバイダを知っているであろう（ホップバイホップ相互暗号認証の使用を想定します）。しかし、元のサービスプロバイダのエッジプロキシからのリクエストが送信先ユーザエージェントサーバに到達する前に、再びプロキシされる場合がありますので、多くの場合、元のサービス・プロバイダのアイデンティティが唯一の推移知られているであろうことは可能です。また、多くのアーキテクチャでPSTNゲートウェイから発信されなかった要求は、エッジプロキシサーバを経由して送信することができます。端分析において、リクエストの受信者は、要求が、要求がゲートウェイから来たことを知ることでよりから来たキャリアを知ることにはあまり興味があります。
Another possible solution is to issue certificates to every gateway corresponding to the hostname of the gateway ('gateway1.example.com'). Gateways could therefore sign SIP requests directly, and this property could be preserved end-to-end. But depending on the public key infrastructure, this could, however, become costly for large numbers of gateways, and moreover a user agent server that receives the request has no direct assurance from a typical certificate that the host is in fact a gateway just because it happens to be named 'gateway1'.
もう1つの可能な解決策は、ゲートウェイ（「gateway1.example.com」）のホスト名に対応するすべてのゲートウェイに証明書を発行することです。ゲートウェイは、したがって、直接SIPリクエストに署名することができ、そしてこのプロパティは、エンドツーエンドを保存することができます。しかし、公開鍵インフラストラクチャによっては、これは、しかし、ゲートウェイの多数のために高価なになる可能性があり、しかも要求を受信したユーザエージェントサーバは、ホストはそれので、実際にはゲートウェイであることを、一般的な証明書からの直接の保証がありません「gateway1」という名前のことが起こります。
Trait-based authorization would enable the trait 'is a gateway' to be associated with an assertion that is generated by the service provider (i.e., signed by 'example.com'). Since these assertions would travel end-to-end from the originating service provider to the destination user agent server, SIP requests that carry them can pass through any number of intermediaries without discarding cryptographic authentication information. This mechanism also does not rely on hostname conventions to identify what constitutes a gateway and what does not -- it relies on an explicit and unambiguous attribute in an assertion.
形質ベースの認証は、形質を可能にする（すなわち、「example.com」によって署名された）サービス・プロバイダによって生成されたアサーションに関連付けられる「ゲートウェイです」。これらのアサーションは、エンドツーエンドの先のユーザエージェントサーバへの発信サービスプロバイダからの旅行をするだろうので、それらを運ぶSIPリクエストは、暗号化、認証情報を破棄することなく仲介の任意の数を通過することができます。それは、アサーションで明示的かつ明確な属性に依存している - このメカニズムはまた、ゲートウェイと何しませんを構成するものを識別するために、ホスト名の規則に依存しません。
Consider a scenario wherein two universities are making use of a videoconferencing service over a constrained-bandwidth resource. Both universities would like to enforce policies that determine how this constrained bandwidth will be allocated to members of their respective communities. For example, faculty members might have privileges to establish videoconferences during the day, while students might not. Faculty might also be able to add students to a particular videoconference dynamically, or otherwise moderate the content or attendance of the conference, whereas students might participate only more passively.
2つの大学が制約帯域幅リソースを介してテレビ会議サービスを利用して、請求のシナリオを検討してください。両大学は、この制約の帯域幅は、それぞれのコミュニティのメンバーに割り当てられます方法を決定するポリシーを適用したいと思います。例えば、教員が学生ではないかもしれないが、日中のテレビ会議を確立する権限を持っているかもしれません。教員も学生が唯一のより受動的に関与している可能性があるのに対し、動的に特定のビデオ会議に学生を追加、あるいは会議の内容や出席を緩和することができるかもしれません。
Trait-based authorization is ideal for managing authorization decisions that are predicated on membership in a group. Rather than basing access on individual users, levels (or roles) could be assigned that would be honored by both universities, since they both participate in the same federation.
形質ベースの認証は、グループのメンバーシップを前提している認可決定を管理するための理想的です。両者が同じ連合に参加して以来、むしろ個々のユーザーにアクセスを基づかより、レベル（またはロール）は、両大学で名誉を与えられるという割り当てることができます。
If the federation honored the traits "faculty", "staff", and "student", they could be leveraged to ensure appropriate use of the network resource between universities participating in the federation. An assertion would then be attached to every request to establish a session that indicated the role of the requestor. Only if the requestor has the appropriate trait would the session request be granted. Ideally, these policies would be enforced by intermediaries (SIP proxy servers) that are capable of inspecting and verifying the assertions.
フェデレーションは、形質「学部」、「スタッフ」、および「学生」を受賞した場合、それらがフェデレーションに参加大学間のネットワーク資源の適切な使用を確保するために活用することができます。アサーションは、要求者の役割を示したセッションを確立するためにあらゆる要求に添付されるだろう。要求者が適切な形質を持っている場合にのみ、セッション要求が許可されるだろう。理想的には、これらのポリシーはアサーションを検査し、検証することが可能な仲介（SIPプロキシサーバ）によって強制されるだろう。
There is a significant amount of interest in the Internet telephony community in assigning certain calls a 'priority' based on the identity of the user, with the presumption that prioritized calls will be granted preferential treatment when network resources are scarce. Different domains might have different criteria for assigning priority, and it is unlikely that a domain would correlate the identity of a non-local user with the need for priority, even in situations where domains would like to respect one another's prioritization policies.
インターネット電話のコミュニティの関心にかなりの量は、ネットワークリソースが不足しているとき、呼び出しが優遇を付与されます優先順位前提で、ユーザーのIDに基づいて「優先順位」を、特定の呼び出しを割り当てることです。異なるドメインは、優先順位を割り当てるための異なる基準を持っているかもしれませんが、ドメインでもドメインが互いの優先順位付けポリシーを尊重したい状況では、優先順位の必要性と非ローカルユーザーのIDを相関するであろうことはほとんどありません。
Existing proposals have focused largely on adding a new header field to SIP that might carry a priority indicator. This use case does not challenge this strategy, but merely shows by way of example how this requirement might be met with a trait-based authorization system. As such, the limitations of the header field approach will not be contrasted here with a hypothetical trait-based system.
既存の提案は、主に優先度インジケータを運ぶ可能性があるSIPに新しいヘッダフィールドを追加することに焦点を当てています。このユースケースは、この戦略に挑戦、単にこの要件は、形質ベースの認証システムと会ったことがありますどのように一例として示していません。このように、ヘッダフィールドアプローチの限界は、仮定形質ベースのシステムで、ここで対比されません。
An assertion created by a domain for a particular request might have an associated 'priority' attribute. Recipients of the request could inspect and verify the signature associated with the assertion to determine which domain had authenticated the user and made the priority assessment. If the assertion's creator is trusted by the evaluator, the given priority could be factored into any relevant request processing.
特定の要求のためのドメインで作成されたアサーションは、関連する「優先順位」属性を持っているかもしれません。リクエストの受信者は検査し、ユーザを認証し、優先度評価をしていたどのドメインを決定するためにアサーションに関連付けられた署名を確認できました。アサーションの作成者は、評価者によって信頼されている場合、与えられた優先順位は、関連するすべての要求処理に分解することができます。
Cryptographic computations are expensive and computing authorization decisions might require a lot of time and multiple messages between the entity enforcing the decisions and the entity computing the authorization decision. Particularly in a mobile environment these entities are physically separated -- or not even in the same administrative domain. Accordingly, the notion of "single sign-on" is another potential application of authorization assertions and trait-based authorization -- a user is authenticated and authorized through one protocol, and can reuse the resulting authorization assertion in other, potential unrelated protocol exchanges.
暗号計算は高価であり、コンピューティングの許可決定は、時間と意思決定と承認の決定を計算するエンティティを施行するエンティティ間の複数のメッセージの多くを必要とするかもしれません。でも、同じ管理ドメイン内またはない - 特にモバイル環境でこれらのエンティティを物理的に分離されています。したがって、「シングルサインオン」の概念は、認証アサーション及び形質ベースの許可の別の潜在的なアプリケーションは、 - ユーザが認証され、プロトコルを介して認可、および他の潜在的な無関係なプロトコル交換で得られた認可アサーションを再利用することができています。
For example, in some environments it is useful to make the authorization decision for a "high-level" service (such as a voice call). The authorization for the "voice call" itself might include authorization for SIP signaling and also for lower-level network functions, for example, a quality-of-service (QoS) reservation to improve the performance of real-time media sessions established by SIP. Since the SIP signaling protocol and the QoS reservation protocol are totally separate, it is necessary to link the authorization decisions of the two protocols. The authorization decision might be valid for a number of different protocol exchanges, for different protocols and for a certain duration or some other attributes.
例えば、一部の環境では、（音声通話など）、「高レベル」のサービスの認可決定を行うために有用です。 「音声通話」の認可自体が低レベルのネットワーク機能のためにも、SIPシグナリングの認証とを含むかもしれない、例えば、サービス品質（QoS）の予約がSIPによって確立されたリアルタイムのメディアセッションのパフォーマンスを向上させます。 SIPシグナリングプロトコルとQoS予約プロトコルが完全に分離されているので、2つのプロトコルの許可決定をリンクする必要があります。認可判断は、異なるプロトコル交換の数について、異なるプロトコルのために、一定期間またはいくつかの他の属性に有効かもしれません。
To enable this mechanism as part of the initial authorization step, an authorization assertion is returned to the end host of the SIP UAC (cryptographically protected). If QoS is necessary, the end host might reuse the returned assertion in the QoS signaling protocol. Any domains in the federation that would honor the assertion generated to authorize the SIP signaling would similarly honor the use of the assertion in the context of QoS. Upon the initial generation of the assertion by an authorization server, traits could be added that specify the desired level of quality that should be granted to the media associated with a SIP session.
初期認証ステップの一部として、このメカニズムを有効にするために、許可アサーションは、SIP UACのエンドホストに返される（暗号で保護されました）。 QoSが必要な場合は、エンドホストは、QoSシグナリングプロトコルで返されたアサーションを再利用する場合があります。 SIPシグナリングを承認するために生成されたアサーションを尊重することになるフェデレーション内のすべてのドメインは、同様のQoSの文脈におけるアサーションの使用を尊重であろう。認可サーバによってアサーションの初期発生時に、特性はそれがSIPのセッションに関連付けられたメディアに付与されるべき品質の所望のレベルを指定して追加することができます。
The following are the constraints and requirements for trait-based authorization in SIP:
SIPにおける特性ベースの認証のための制約と要件を以下に示します。
1. The mechanism MUST support a way for SIP user agents to embed an authorization assertion in SIP requests. Assertions can be carried either by reference or by value.
1.メカニズムは、SIPリクエストで認証アサーションを埋め込むためにSIPユーザエージェントへの道をサポートしなければなりません。アサーションは、参照することにより、または値のいずれかによって実施することができます。
2. The mechanism MUST allow SIP UACs to deliver to an authorization service those SIP requests that need to carry an assertion. The mechanism SHOULD also provide a way for SIP intermediaries to recognize that an assertion will be needed, and either forward requests to an authorization service themselves or notify the UAC of the need to do so.
2.メカニズムは、SIP求めるUACが認可サービスへのアサーションを実行する必要があり、それらのSIPリクエストを提供できるようにしなければなりません。メカニズムは、SIPの仲介はアサーションが必要とされるであろうことを認識し、認証サービスに転送要求のいずれかに自分自身をまたはそうする必要性のUACを通知するための方法を提供する必要があります。
3. Authorization services MUST be capable of delivering an assertion to a SIP UAC, either by reference or by value. It MAY also be possible for an authorization service to add assertions to requests itself, if the user profile permits this (for example, through the use of content-indirection as described in [4]).
3.認可サービスは、参照することにより、または値のいずれかによって、SIP UACにアサーションを供給できなければなりません。ユーザープロファイルを許可この（例えば、[4]に記載されているように、コンテンツ・インダイレクションの使用を介して）場合、許可サービスは、要求自体にアサーションを追加することも可能です。
5. The assertions generated by authorization services MUST be capable of providing a set of values for a particular trait that a principal is entitled to claim.
前記許可サービスによって生成されたアサーションは、主体が主張する権利があり、特定の形質の値のセットを提供することができなければなりません。
6. The mechanism MUST provide a way for authorized SIP intermediaries (e.g., authorized proxy servers) to inspect assertions.
前記機構は、アサーションを検査する（例えば、許可されたプロキシサーバ）認可SIP仲介するための方法を提供しなければなりません。
7. The mechanism MUST have a single baseline mandatory-to-implement authorization assertion scheme. The mechanism MUST also allow support of other assertion schemes, which would be optional to implement. One example of an assertion scheme is Security Assertion Markup Language (SAML) [6] and another is RFC 3281 X.509 Attribute Certificates [7].
7.メカニズムは、単一のベースラインの実装に必須の認証アサーションスキームを持たなければなりません。メカニズムは、実装するために、オプションとなり、他のアサーションスキームのサポートを許容しなければなりません。アサーション・スキームの一例は、セキュリティアサーションマークアップ言語（SAML）[6]と他のRFC 3281 X.509属性証明書である[7]。
8. The mechanism MUST ensure reference integrity between a SIP request and assertion. Reference integrity refers to the relationship between a SIP message and the assertion authorizing the message. For example, a reference integrity check would compare the sender of the message (as expressed in the SIP request, for example, in the "From" header field value) with the identity provided by the assertion. Reference integrity is necessary to prevent various sorts of relay and impersonation attacks. Note that reference integrity MAY apply on a per-message, per-transaction, or per-dialog basis.
8.メカニズムは、SIPリクエストとアサーションとの間の参照整合性を確保しなければなりません。参照整合性は、SIPメッセージとメッセージを認証アサーションとの間の関係を指します。たとえば、参照整合性チェックはアサーションによって提供される同一性（ヘッダフィールド値「から」は、例えば、SIPリクエストで表現されるように）、メッセージの送信者を比較することになります。参照整合性は、リレーやなりすまし攻撃の様々な種類を防止する必要があります。メッセージごとの、あたりのトランザクション、またはごとのダイアログベースで適用される場合があることに参照整合性に注意してください。
9. Assertion schemes used for this mechanism MUST be capable of asserting attributes and/or traits associated with the identity of the principal originating a SIP request. No specific traits or attributes are required by this specification.
この機構に使用される9アサーションスキームは、SIP要求元プリンシパルのアイデンティティに関連する属性および/または特性をアサートすることができなければなりません。いかなる特定の特徴または属性は、この仕様で必要とされていません。
10. The mechanism MUST support a means for end-users to specify policies to an authorization service for the distribution of their traits and/or attributes to various destinations.
10.メカニズムは、エンドユーザーが様々な目的地への特性および/または属性の配布のための認可サービスにポリシーを指定するための手段をサポートしなければなりません。
11. The mechanism MUST provide a way of preventing unauthorized parties (either intermediaries or endpoints) from viewing the contents of assertions.
11.機構は、アサーションの内容を表示するから、権限のない者（仲介者またはエンドポイントのいずれか）を予防する方法を提供しなければなりません。
12. Assertion schemes MUST provide a way of selectively sharing the traits and/or attributes of the principal in question. In other words, it must be possible to show only some of the attributes of a given principal to particular recipients, based on the cryptographically- assured identity of the recipient.
12.アサーション方式は、選択的特性および/または問題のプリンシパルの属性を共有する方法を提供しなければなりません。換言すれば、受信者のcryptographically-確実なアイデンティティに基づいて、特定の受信者に与えられた元本の属性の一部だけを表示することが可能でなければなりません。
13. It MUST be possible to provide an assertion that contains no identity -- that is, to present only attributes or traits of the principal making a request, rather than the identity of the principal.
13.何のアイデンティティを含まないアサーションを提供することが可能でなければなりません - つまり、むしろプリンシパルのアイデンティティより要求を行う主体の属性のみまたは特徴を提示します。
14. The manner in which an assertion is distributed MUST permit cryptographic authentication and integrity properties to be applied to the assertion by the authorization service.
14アサーションが分散される方法は、認可サービスによってアサーションに適用される暗号化認証及び整合性特性を可能にしなければなりません。
15. It MUST be possible for a UAS or proxy server to reject a request that lacks a present and valid authorization assertion, and to inform the sending UAC that it must acquire such an assertion in order to complete the request.
UASまたはプロキシサーバが存在し、有効な認証アサーションを欠い要求を拒否し、それが要求を完了するために、このような主張を獲得しなければならないことを送信元UACを通知する15.ことが可能でなければなりません。
16. The recipient of a request containing an assertion MUST be able to ascertain which authorization service generated the assertion.
16.アサーションを含むリクエストの受信者は、アサーションを生成した許可サービス確かめることができなければなりません。
17. It MUST be possible for a UAS or proxy server to reject a request containing an assertion that does not provide any attributes or traits that are known to the recipient or that are relevant to the request in question.
UASまたはプロキシサーバーが受信者に知られているか、または当該の要求に関連していることの任意の属性や特性を提供していないアサーションを含む要求を拒否する17.ことが可能でなければなりません。
18. It SHOULD be possible for a UAC to attach multiple assertions to a single SIP request, in cases where multiple authorization services must provide assertions in order for a request to complete.
UACは、複数の認証サービスを完了するための要求ためにアサーションを提供しなければならない場合には、単一のSIPリクエストに複数のアサーションを接続するために18それは可能なはずです。
The subject of this document is an authorization system for SIP that is not predicated on the distribution of end-users' identities, but rather shares traits of the users. As such, the bulk of this document discusses security.
本書の主題は、エンドユーザーのアイデンティティの分布を前提とされていないSIPのための認証システムではなく、むしろユーザーの特徴を共有しています。そのため、この文書の大部分は、セキュリティについて説明します。
The distribution of authorization assertions requires numerous security properties. An authorization service must be able to sign assertions, or provide some similar cryptographic assurance that can provide non-repudiation for assertions. These requirements are further detailed in Section 3.
認証アサーションの分布は、多数のセキュリティ・プロパティが必要です。認可サービスは、アサーションに署名、または表明のための否認防止を提供することができ、いくつかの類似した暗号保証を与えることができなければなりません。これらの要件は、第3節で、さらに詳細に記載されています。
The authors thank Christopher Eagan and Mary Barnes for their valuable input.
著者は、彼らの貴重な入力のためのクリストファー・イーガンとメアリー・バーンズに感謝します。
[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.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[3]ピーターソン、J.とC.ジェニングスを、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[4] Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[4]バーガー、E.、エド。、 "セッション開始プロトコル（SIP）におけるコンテンツの間接化の仕組みメッセージ"、RFC 4483、2006年5月を。
[5] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[5]ピーターソン、J.、RFC 3323 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"、2002年11月。
[6] Organization for the Advancement of Structured Industry Standards, "Security Assertion Markup Language v1.0", November 2002, <http://www.oasis-open.org>.
[6]構造化業界標準の推進、「セキュリティアサーションマークアップ言語v1.0の」のための組織、2002年11月、<http://www.oasis-open.org>。
[7] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[7]ファレル、S.とR. Housley氏、 "認可のためのインターネット属性証明書プロフィール"、RFC 3281、2002年4月。
Authors' Addresses
著者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
ジョンピーターソンNeuStar、Inc.の1800サッターセントスイート570コンコード、CA 94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
電話：+1 925/363から8720 Eメール：jon.peterson@neustar.biz URI：http://www.neustar.biz/
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Suite 570 Richardson, TX 75802 US
ジェームズ・M.ポークシスコシステムズ2200東ジョージ・ブッシュ大統領のターンパイクスイート570リチャードソン、TX 75802米国
EMail: jmpolk@cisco.com
メールアドレス：jmpolk@cisco.com
Douglas C. Sicker University of Colorado at Boulder ECOT 531 Boulder, CO 80309 US
ボルダーECOT 531ボルダー、CO 80309米国コロラド州のダグラス・C.病状大学
EMail: douglas.sicker@colorado.edu
メールアドレス：douglas.sicker@colorado.edu
Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 Munich 81739 Germany
ハンネスTschofenigシーメンスAGオットー・ハーンリング6ミュンヘン81739ドイツ
EMail: Hannes.Tschofenig@siemens.com
メールアドレス：Hannes.Tschofenig@siemens.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。