[要約] RFC 4484は、SIPにおけるトレイトベースの認可要件に関する規格です。このRFCの目的は、SIPセッションの認可プロセスを改善し、セキュリティとプライバシーを強化することです。
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)
セッション開始プロトコル（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).
Copyright（c）The Internet Society（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）のIDを確認するために直交する許可要件があるという認識に起因します。補足許可情報により、UASは、SIP要求を発信したプリンシパルのさらなる属性に依存する非同一性ベースのポリシーを実装できる場合があります。
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は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に関連付けられた属性の承認サービスによるアサーションが必要です。アサーションとは、これらの属性のセットで構成される一種のドキュメントで、アサーション（認証サービスのオペレーター）を生成する当事者が提供するデジタル署名に包まれています。これらの属性は、問題のアイデンティティの「特性」または「特性」、つまりそのアイデンティティに対応するプリンシパルに関する事実を説明しています。たとえば、特定の校長は大学の教員である可能性があります。その校長の身元の主張は、「教員」の「特性」があると述べ、大学によって主張が発行される（および署名）される可能性があります。UASがこの特性アサーションでリクエストを受け取った場合、署名大学を信頼している場合、UACの身元を見るのではなく、教員が問題の要求を行うことが許可されているかどうかに基づいて許可決定を下すことができますそして、彼らがいくつかの外部手段を通じて教員であるかどうかを識別しようとしています。したがって、これらのアサーションにより、UAS自体のIDに関連する属性を保存またはアクセスすることなく、UASが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.
実際、特性ベースの承認が使用される場合、UACのユーザーのIDの代わりにUASに属性の主張を提示できます。多くの場合、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の両方から信頼される承認サービスに依存します。そのため、このドキュメントに記載されている承認サービスは、単一のドメインまたは互いの承認サービスを信頼することに同意したフェデレーションドメインのいずれかでクライアントに最も適用されます。これは、学術環境、またはプリンシパルの属性を互いに共有したいビジネスパートナーシップで一般的になる可能性があります。複数のプロバイダーにシングルサインオンサービスを提供するために、いくつかの特性ベースの承認アーキテクチャが提案されています。
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.
このドキュメントでは、キーワードが「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうはならない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、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リクエストが認可サービスに提供され、アサーションの基礎を提供する場合があります。ユーザーエージェントは、招待状などの特定の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サーバーはほとんどのクエリに特性情報のみ（「教員」、「学生」、または「スタッフ」）を提供する場合がありますが、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.
2つのドメインのエンドポイントがリアルタイム通信サービスを共有する場合、ドメインが会計情報と解決情報をリアルタイムで交換する必要がある場合があります。呼び出されたドメインの貴重なリソース（たとえば、パブリックスイッチド電話ネットワーク（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ユーザーエージェントサーバーは、もちろん、PSTN発信者の身元を知ることに関心があります。これは、SIPメッセージ内で何らかの方法（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.
サービスプロバイダーがこの問題に対処しようとする方法はいくつかあります。1つの可能性は、ゲートウェイからすべての呼び出しを、認識可能な「エッジ」プロキシサーバー（「sip.example.com」など）を介してルーティングすることです。したがって、Edgeプロキシサーバーを介してリクエストを受け取ったSIPエンティティ（ホップバイホップの相互暗号認証の使用を想定）は、コールが発生したサービスプロバイダーを知るでしょう。ただし、宛先ユーザーエージェントサーバーに到達する前に、発信元サービスプロバイダーのエッジプロキシからのリクエストが再度プロキシになる可能性があります。したがって、多くの場合、元のサービスプロバイダーの身元は交換的にのみ知られている可能性があります。さらに、多くのアーキテクチャでは、PSTNゲートウェイから発生しなかったリクエストをEdge Proxyサーバーから送信できます。最後の分析では、リクエストの受信者は、リクエストがゲートウェイから来たことを知るよりも、リクエストがどのキャリアから来たのかを知ることにあまり興味がありません。
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'.
別の可能な解決策は、ゲートウェイのホスト名（ '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」で署名されます）。これらのアサーションは、発信元のサービスプロバイダーから宛先ユーザーエージェントサーバーにエンドツーエンドで移動するため、Cryptographic認証情報を破棄することなく、携帯電話を携帯することができる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.
インターネットテレフォニーコミュニティには、ユーザーの身元に基づいて特定のコールを割り当てることにかなりの関心があり、ネットワークリソースが不足している場合に優先順位付けされた呼び出しが優先的な扱いが付与されると推定されます。異なるドメインに優先度を割り当てるための基準が異なる場合があり、ドメインが互いの優先順位付けポリシーを尊重したい状況であっても、ドメインが非ローカルユーザーのアイデンティティを優先事項と相関させる可能性は低いです。
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.
暗号化の計算は高価であり、コンピューティング許可の決定は、意思決定とエンティティが認可決定を計算するエンティティとの間に多くの時間と複数のメッセージを必要とする場合があります。特にモバイル環境では、これらのエンティティは物理的に分離されています。したがって、「シングルサインオン」の概念は、認証アサーションと特性ベースの認証のもう1つの潜在的な適用です。ユーザーは、1つのプロトコルを通じて認証および承認され、他の潜在的な無関係なプロトコル交換における結果の認可アサーションを再利用できます。
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シグナリングの承認、および低レベルのネットワーク関数、たとえばSIPによって確立されたリアルタイムメディアセッションのパフォーマンスを改善するためのサービス品質（QOS）予約などの認可が含まれる場合があります。。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が必要な場合、endホストは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仲介者がアサーションが必要であることを認識し、承認サービス自体を転送するか、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]で説明されているようにコンテンツインディードを使用して）、承認サービスを要求するためにアサーションを追加することも可能かもしれません。
4. Authorization services MUST have a way to authenticate a SIP UAC.
4. 承認サービスには、SIP UACを認証する方法が必要です。
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.
5. 承認サービスによって生成されたアサーションは、プリンシパルが請求する権利がある特定の特性に一連の価値を提供できる必要があります。
6. The mechanism MUST provide a way for authorized SIP intermediaries (e.g., authorized proxy servers) to inspect assertions.
6. このメカニズムは、認定された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. メカニズムには、単一のベースラインに必須の承認承認アサーションスキームが必要です。メカニズムは、実装するためのオプションである他のアサーションスキームのサポートも許可する必要があります。アサーションスキームの1つの例は、セキュリティアサーションマークアップ言語（SAML）[6]であり、もう1つは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メッセージとメッセージの承認のアサーションとの関係を指します。たとえば、参照整合性チェックは、メッセージの送信者を比較します（たとえば、「From "Headerフィールド値）とアサーションによって提供されたIDでのメッセージの送信者が比較されます。さまざまな種類のリレーおよびなりすまし攻撃を防ぐために、参照の完全性が必要です。参照の整合性は、吸引ごと、トランザクションごと、またはダイアログごとに適用される場合があることに注意してください。
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リクエストを発信する元本のIDに関連する属性および/または特性をアサートできる必要があります。この仕様では、特定の特性または属性は必要ありません。
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. アサーションスキームは、問題のプリンシパルの特性および/または属性を選択的に共有する方法を提供する必要があります。言い換えれば、受信者の暗号化された保証されたアイデンティティに基づいて、特定のプリンシパルの属性の一部のみを特定の受信者に表示することが可能である必要があります。
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.
15. UASまたはプロキシサーバーが、現在および有効な承認主張がないリクエストを拒否し、リクエストを完了するためにそのようなアサーションを取得しなければならないことを送信UACに通知することが可能である必要があります。
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.
17. UASまたはプロキシサーバーが、受信者に知られている属性や特性を提供しない、または問題のリクエストに関連する属性または特性を提供しないリクエストを拒否することができなければなりません。
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.
18. UACが、複数の認証サービスが完了するためにアサーションを提供する必要がある場合に、1つのSIP要求に複数のアサーションを添付することが可能です。
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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION 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] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[3] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[4] Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[4] Burger、E.、ed。、「セッション開始プロトコル（SIP）メッセージにおけるコンテンツ間接のメカニズム」、RFC 4483、2006年5月。
[5] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[5] ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、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] Farrell、S。およびR. Housley、「認証のためのインターネット属性証明書プロファイル」、RFC 3281、2002年4月。
Authors' Addresses
著者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
Jon Peterson Neustar、Inc。1800 Sutter St Suite 570 Concord、CA 94520 US
Phone: +1 925/363-8720
EMail: 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リチャードソン、テキサス75802 US
EMail: jmpolk@cisco.com
Douglas C. Sicker University of Colorado at Boulder ECOT 531 Boulder, CO 80309 US
ダグラスC.コロラド州シッカー大学ボルダーエコット531ボルダー、コロラド州80309米国
EMail: douglas.sicker@colorado.edu
Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 Munich 81739 Germany
Hannes Tschofenig Siemens Ag Otto-Hahn-Ring 6 Munich 81739ドイツ
EMail: Hannes.Tschofenig@siemens.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。