RFC4484 日本語訳
4484 Trait-Based Authorization Requirements for the Session InitiationProtocol (SIP). J. Peterson, J. Polk, D. Sicker, H. Tschofenig. August 2006. (Format: TXT=37169 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Peterson
Request for Comments: 4484 NeuStar
Category: Informational J. Polk
Cisco
D. Sicker
CU Boulder
H. Tschofenig
Siemens
August 2006
コメントを求めるワーキンググループJ.ピーターソン要求をネットワークでつないでください: 4484年のNeuStarカテゴリ: CuボウルダーH.Tschofenigジーメンス2006年8月により病気の情報のJ.ポークシスコD.
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).
Copyright(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.
このドキュメントはSession Initiationプロトコル(SIP)のために特色ベースの承認に関連する1セットの要件を広げます。 いくつかの認証機構がベースSIP仕様で説明されている間、特色ベースの承認はセッションにおける、関係者の属性に基づいて政策決定をするのに使用される情報を提供します。 このアプローチは、より豊かなフレームワークを承認に提供して、アイデンティティシステムのユーザのために、よりすばらしいプライバシーを許容します。
Peterson, et al. Informational [Page 1] RFC 4484 SIPPING TBA August 2006
ピーターソン、他 TBA2006年8月にちびちび飲む情報[1ページ]のRFC4484
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
1. 序論…2 2. 用語…4 3. 特色ベースの承認フレームワーク…4 4. 例はケースを使用します…7 4.1. サービスのための解決…7 4.2. ゲートウェイをプロバイダーに関連づけます…7 4.3. 制約つきリソースにおける許容…8 4.4. 優先権と先行を管理します…9 4.5. 異なったプロトコルをリンクします…10 5. 特色ベースの承認要件…11 6. セキュリティ問題…13 7. 承認…13 8. 参照…13 8.1. 標準の参照…13 8.2. 有益な参照…13
1. Introduction
1. 序論
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.
このドキュメントは、特色ベースの承認を可能にするためにSession Initiationプロトコル(SIP)[1]の要件について調査します。 この取り組みはSIP要求がUserエージェントServer(UAS)によって受け取られるとき、UserエージェントClient(UAC)のアイデンティティの確かめと直交した承認要件があるという認識によります。 補足の承認情報で、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は特定の要求(承認決定をする方法としての)をすることが許可されている何らかのセットのユーザと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
特色ベースの承認はアイデンティティに関連している属性の承認サービスで主張を伴います。 主張は主張(承認サービスのオペレータ)を生成するパーティーによって提供されたデジタル署名の中で包装されるこれらの属性の1セットから成る一種のドキュメントです。 これらの属性は問題のアイデンティティの'特色'か'特色'について説明します--そのアイデンティティに対応する主体に関する事実。 例えば、当然のことの元本はaの教員であるかもしれません。
Peterson, et al. Informational [Page 2] RFC 4484 SIPPING TBA August 2006
ピーターソン、他 TBA2006年8月にちびちび飲む情報[2ページ]のRFC4484
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.
大学。 その主体のアイデンティティのための主張は、彼らには'教授陣はメンバーです'の'特色'があると述べるかもしれません、そして、主張は大学によって発行されるでしょう(そして、署名されます)。 署名大学を信じるならUASがこの特色主張で要求を受け取るとき、それは教員がただUACのアイデンティティを見て、いくつかの外部の手段で彼らが教員であるかどうか明察しようとするよりむしろ要求を問題にすることが許可されているかどうか基づく承認決定をすることができます。 したがって、これらの主張で、UAC自身のアイデンティティに関連している属性に保存するか、またはアクセスする必要はなくて、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のようなサービスのための、より広い用法を持つ特色に関する命令では、一般的な承認体系に参加するドメインはお互いと共に連邦化されなければなりません。 連邦の概念はどんな特色ベースの承認体系にも不可欠です。 お互いと共に連邦化されるドメインは特色の構文と意味論に同意します--このコンセンサスがなければ、特色ベースの承認体系は単にintradomain文脈で役に立つでしょう。 連邦は承認決定のために特色の使用と適用性に関する共通政策を実装する1セットの管理ドメインと定義されます。 連邦が必ず信頼関係を含意する、普通である、ある種のあらかじめ共有されたキーか特定の主張が連邦に参加する承認サービスで生成されたという暗号の保証の他の手段を含意します。
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のユーザのアイデンティティの代わりにUASに属性の主張を提示できます。 多くの場合、UASには、だれがアイデンティティが手段にすぎないことを知っていて、まさに要求をしたかを知る必要が全くアイデンティティの如何にかかわらず実際に特色に依存する方針へのそのアイデンティティを合わせる終わりまでありません。 この事実で、特色ベースの承認は非常に無視できないプライバシーと匿名対策を提供できます。 アイデンティティは様々な目的地に明らかにされるかもしれない主張のもうひとつの属性になります。
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
SIPのための特色ベースの承認はUACとセッションを共有したがっているUASの両方によって信じられる承認サービスによります。 その理由で、本書では説明される中で承認サービスはどちらかシングルでクライアントに最も適用されます。
Peterson, et al. Informational [Page 3] RFC 4484 SIPPING TBA August 2006
ピーターソン、他 TBA2006年8月にちびちび飲む情報[3ページ]のRFC4484
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.
ドメインか同意した連邦化されたドメインでは、お互いの承認サービスを信じてください。 これは主体の属性をお互いと共有したがっているアカデミックな環境、または事業提携で一般的であるかもしれません。 いくつかの特色ベースの承認アーキテクチャが、複数のプロバイダーの向こう側にシングルサインオンサービスを提供するために提案されました。
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]を補足していると考えられるべきです。 また、認証サービスは承認サービスとして機能するかもしれません、認証されたアイデンティティ本体の代わりにある種の特色主張トークンを生成して。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[2]について説明して、対応する一口実装のために要件レベルを示すとき解釈されることであるべきですか?
3. Trait-Based Authorization Framework
3. 特色ベースの承認フレームワーク
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要求で取るのは、事実であるかもしれません、INVITEのように。(認証されたアイデンティティ本体が[3])で要求されている方法と同様の方法で。(それは、INVITEを主張を取得して、承認サービスにこれを送りたがっています)。 また、ユーザエージェントは、主張を要求するのに別々のプロトコルを使用するかもしれません。 どちらの場合ではも、クライアントは、主張を受ける前に承認サービスにそれ自体を認証する必要があるでしょう。 この認証は、RFC3261[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
SIP UAに主張がいったんあると、それはSIP要求で主張を運ぶ何らかの道を必要とするでしょう。 参照か値でこの主張を提供できたのは可能です。 例えば、SIP UAは主張を含むSIP要求の中にMIME本体を含むことができました。 これは値で包含でしょう。 あるいはまた、内容
Peterson, et al. Informational [Page 4] RFC 4484 SIPPING TBA August 2006
ピーターソン、他 TBA2006年8月にちびちび飲む情報[4ページ]のRFC4484
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.
URI(恐らくHTTP URL)を利害関係者が主張を取得できたところに提供するのに間接指定[4]、または新しいヘッダーを使用できました。 参照でこれは包含です。
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
+----------------+ | | | +------------+ | 要求| +------------+ | | | 実体| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 主張| | | | 要求| | | | 与えること| | | | authz| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 実体| | | | 主張| | 主張| +------------+ | | +------------+ | | ^ | | | | | . 信頼| | | | | . Rel。 | | | | | v| | | | | +------------+ | | 転送| | | 主張| | | | | | | 検証| | | | | | | 実体| | | | | | +------------+ | | | | | | | v| +----------------+ | +------------+ | Service Request + ^ | | | 実体| | 主張| | | | authzを使用します。| | -----------------------------+ | | | 主張| | | | +------------+ | <-------------------------------+ +----------------+ 応答/誤り
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.
これらの承認主張を使用することで承認主張(または、いくつかの主張を承諾する実体)と実体を要求する実体は同じホストかドメインに共同位置するかもしれませんか、それらがお互いと共に連邦化しているaを共有する異なったドメインの実体であるかもしれません。 これらの主張を特定の実体に承諾する実体とこれらの主張について確かめる実体に、同じくらいは本当です。
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
いくつかの重要なデザイン決定がSIPでの主張が要求する携帯に関連しています。 主張が値によって運ばれるか、またはMIMEベースの満足している間接指定システムを使用すると、プロキシサーバはそうするでしょう。
Peterson, et al. Informational [Page 5] RFC 4484 SIPPING TBA August 2006
ピーターソン、他 TBA2006年8月にちびちび飲む情報[5ページ]のRFC4484
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.
自分たちで主張を点検できないでください。 しかしながら、主張がヘッダーで参照をつけられるなら、プロキシが主張自体を取得して、点検するのは、可能でしょうに。 確かにプロキシサーバが主張に基づく入場コントロールを当てはまるのが、重要であるアーキテクチャがあります。
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は要求に挑戦して、確信している認可されたソースが主張を点検するのを許容しただけであるか、または主張がだれが尋ねているかによる異なった見解を前提としたウェブサーバーを示すかもしれません。 SIP UAがプライバシーコントロール[5]で要求を開始するとき、ウェブサーバーは特色情報('教授陣'、'学生'、または'スタッフ')だけをほとんどの質問に提供するかもしれませんが、より詳細な情報を提供してください、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に持っています。 承認政策決定をする際に要求の受取人を支援するために主体のアイデンティティ以外の元本に関する特定の事実について断言するのが貴重である多数のインスタンスがあります。 例えば、電話サービスプロバイダーは、特定のユーザが特色として'顧客'であると断言するかもしれません。 緊急サービスネットワークは、特定のユーザには訪問者として特権がある状態がいるのを示すかもしれません。
Peterson, et al. Informational [Page 6] RFC 4484 SIPPING TBA August 2006
ピーターソン、他 TBA2006年8月にちびちび飲む情報[6ページ]のRFC4484
4. Example Use Cases
4. 例はケースを使用します。
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.
使用がケースに入れる以下は決して徹底的ではありませんが、特色ベースの承認が提供するかもしれないサービスの種類のいくつかのハイレベルの例を提供してください。 以下のケースのすべてが、interdomainが承認主張の用法であると考えます。
4.1. Settlement for Services
4.1. サービスのための解決
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つのドメインの終点が瞬時通信サービスを共有するとき、リアルタイムででドメインが会計と解決情報を交換する必要が時々あります。 呼ばれたドメインの貴重なリソース(例えば、Public Switched Telephone Network(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.
呼ぶドメインによって作成された承認主張はユーザのアカウントが特定のサービスを受け入れることができるという保証を呼ばれたドメインに提供するかもしれません。 いくつかの場合、詳細は全くトランザクションを処理するのに必要でないかもしれませんが、より特定の会計データが必要であるなら、また、特色は会計サーバ、使用されるべきである解決プロトコルのネットワーク・アドレスなどを伝えるかもしれません。
4.2. Associating Gateways with Providers
4.2. ゲートウェイをプロバイダーに関連づけます。
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,
特定の電話サービスプロバイダーが多数のPSTN-SIPゲートウェイを配布したケースを想像してください。 呼び出しが結局PSTNから入るとき、それらは様々なSIPユーザエージェントにproxiedされます。 SIPメッセージの中でいろいろな方法(SIPヘッダー、ボディーまたはなどにおける)で与えることができたそれぞれのSIPユーザエージェントサーバはもちろんPSTN訪問者のアイデンティティを知りたがっています。 しかしながら
Peterson, et al. Informational [Page 7] RFC 4484 SIPPING TBA August 2006
ピーターソン、他 TBA2006年8月にちびちび飲む情報[7ページ]のRFC4484
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.
受取人が呼び出しで述べられたアイデンティティ(このインスタンスにおける起呼側の電話番号)を信じることができるように、彼らは、最初に、呼び出しがゲートウェイから発して、ゲートウェイが知られている(そして、信じられる)プロバイダーによって操作されると信じなければなりません。
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'と言ってください)。 それに従って、縁のプロキシサーバ(ホップごとの互いの暗号の認証の使用を仮定する)で要求を受け取ったどんなSIP実体も呼び出しが発したサービスプロバイダーを知っているでしょう。 しかしながら、目的地ユーザエージェントサーバに達する前に、起因するサービスプロバイダーの縁のプロキシからの要求が再びproxiedされるかもしれなくて、その結果、多くの場合、起因するサービスプロバイダーのアイデンティティが移行的だけに知られているのは、可能です。 そのうえ、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'.
別の可能なソリューションはゲートウェイ('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要求がいろいろな仲介者を通り抜けることができます。 このメカニズムも何がゲートウェイを設立するか、そして、何が設立しないかを特定するためにホスト名コンベンションを当てにしません--それは主張における明白で明白な属性を当てにします。
4.3. Permissions on Constrained Resources
4.3. 制約つきリソースにおける許容
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
2つの大学がテレビ会議サービスオーバーの使用を強制的な帯域幅リソースにしているシナリオを考えてください。 両方の大学がこの強制的な帯域幅がどのようにメンバーに割り当てられるかを決定する方針を実施したがっている、彼ら
Peterson, et al. Informational [Page 8] RFC 4484 SIPPING TBA August 2006
ピーターソン、他 TBA2006年8月にちびちび飲む情報[8ページ]のRFC4484
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.
それぞれの共同体。 例えば、教員には、1日の間にビデオ会議を設立する特権があるかもしれませんが、学生はそうしないかもしれません。 教授陣は、ダイナミックに特定のビデオ会議に学生を加えるか、またはまた、そうでなければ、会議の内容か出席を加減できるかもしれませんが、学生は、より受け身だけに参加するかもしれません。
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プロキシサーバ)によって励行されるでしょう。
4.4. Managing Priority and Precedence
4.4. 優先権と先行を管理します。
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
特定の要求のためにドメインによって作成された主張は関連'優先権'属性を持っているかもしれません。 要求の受取人は、どのドメインがユーザを認証したかを決定するために主張に関連づけられて、された署名について、点検して、確かめることができました。
Peterson, et al. Informational [Page 9] RFC 4484 SIPPING TBA August 2006
ピーターソン、他 TBA2006年8月にちびちび飲む情報[9ページ]のRFC4484
priority assessment. If the assertion's creator is trusted by the evaluator, the given priority could be factored into any relevant request processing.
優先権査定。 主張のクリエイターが評価者によって信じられるなら、どんな関連要求処理も与えられた優先権の要因として考慮されるかもしれません。
4.5. Linking Different Protocols
4.5. 異なったプロトコルをリンクします。
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つのプロトコルを通して認証されて、認可されて、他の、そして、潜在的の関係ないプロトコル交換で結果として起こる認可主張を再利用できます。
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が必要であるなら、終わりのホストはQoSシグナリングプロトコルにおける返された主張を再利用するかもしれません。 SIPシグナリングを認可するために発生する主張を光栄に思う連邦におけるどんなドメインも同様にQoSの文脈における主張の使用を光栄に思うでしょう。 認可サーバによる主張の初期の世代のときに、SIPセッションに関連しているメディアに与えられるべきである必要なレベルの品質を指定する特色は加えられるかもしれません。
Peterson, et al. Informational [Page 10] RFC 4484 SIPPING TBA August 2006
ピーターソン、他 TBA2006年8月にちびちび飲む情報[10ページ]のRFC4484
5. Trait-Based Authorization Requirements
5. 特色ベースの認可要件
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 UACsは主張を運ぶ必要があるそれらのSIP要求を認可サービスに提供できなければなりません。 メカニズムSHOULDはまた、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. 認可サービスで発生する主張は元本が要求する権利を与えられる特定の特色に1セットの値を提供できなければなりません。
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つの例がSecurity Assertion Markup Language(SAML)[6]です、そして、別のものはRFC3281X.509 Attribute Certificates[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
8. メカニズムはSIP要求と主張の間の参照保全を確実にしなければなりません。 参照保全はSIPメッセージとメッセージを認可する主張との関係について言及します。 例えば、参照保全チェックは主張で提供するアイデンティティとメッセージ送信者を比較するでしょう(例えば、SIP要求で“From"ヘッダーフィールド価値で言い表されるように)。 参照保全が、様々な種類のリレーとものまねを防ぐのに必要です。
Peterson, et al. Informational [Page 11] RFC 4484 SIPPING TBA August 2006
ピーターソン、他 TBA2006年8月にちびちび飲む情報[11ページ]のRFC4484
attacks. Note that reference integrity MAY apply on a per-
message, per-transaction, or per-dialog basis.
攻撃。 参照保全がaで適用されるかもしれないことに注意してください、-、メッセージ、取引、または1対話あたりの基礎。
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. 主張計画は選択的に問題の校長の特色、そして/または、属性を共有する方法を提供しなければなりません。 言い換えれば、与えられた元本の属性のいくつかだけを特定の受取人に示しているのは可能であるに違いありません、ベースである、暗号で、アイデンティティに受取人を保証しました。
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. それ、SHOULD、UACがただ一つのSIP要求に複数の主張を付けるのにおいて可能であってください、複数の認可サービスが終了する要求において、整然としている主張を提供しなければならない場合で。
Peterson, et al. Informational [Page 12] RFC 4484 SIPPING TBA August 2006
ピーターソン、他 TBA2006年8月にちびちび飲む情報[12ページ]のRFC4484
6. Security Considerations
6. セキュリティ問題
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でさらに詳細です。
7. Acknowledgements
7. 承認
The authors thank Christopher Eagan and Mary Barnes for their valuable input.
作者は彼らの貴重な入力についてクリストファー・イーガンとメアリ・バーンズに感謝します。
8. References
8. 参照
8.1. Normative References
8.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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
8.2. Informative References
8.2. 有益な参照
[3] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[3] ピーターソン、J.、およびC.ジョニングス、「セッション開始における認証されたアイデンティティ管理のための増進は(一口)について議定書の中で述べます」、RFC4474、2006年8月。
[4] Burger, E., Ed., "A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[4] バーガー、E.、エド、「セッション開始プロトコル(一口)メッセージでの満足している間接指定のためのメカニズム」、RFC4483、5月2006日
[5] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[5] ピーターソン、J.、「セッション開始プロトコル(一口)のためのプライバシーメカニズム」、RFC3323、2002年11月。
[6] Organization for the Advancement of Structured Industry
Standards, "Security Assertion Markup Language v1.0", November
2002, <http://www.oasis-open.org>.
Structured Industry StandardsのAdvancementのための[6]組織、「セキュリティAssertion Markup Language 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、「認可のためのインターネット属性証明書プロフィール」、RFC3281、2002年4月。
Peterson, et al. Informational [Page 13] RFC 4484 SIPPING TBA August 2006
ピーターソン、他 TBA2006年8月にちびちび飲む情報[13ページ]のRFC4484
Authors' Addresses
作者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
ジョンピーターソンNeuStar Inc.1800サター通りスイート570一致、カリフォルニア94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
以下に電話をしてください。 +1 925/363-8720 メールしてください: jon.peterson@neustar.biz ユリ: http://www.neustar.biz/
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Suite 570 Richardson, TX 75802 US
ジェームスM.ポークシスコシステムズ2200の東ジョージ・ブッシュ大統領の高速道路Suite570テキサス75802リチャードソン(米国)
EMail: jmpolk@cisco.com
メール: jmpolk@cisco.com
Douglas C. Sicker University of Colorado at Boulder ECOT 531 Boulder, CO 80309 US
ダグラス・C.の、より病気のコロラド大学ボルダー校ECOT531ボウルダー、CO80309米国
EMail: douglas.sicker@colorado.edu
メール: douglas.sicker@colorado.edu
Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 Munich 81739 Germany
ハンネスTschofenigジーメンス株式会社オットーハーン一味6ミュンヘン81739ドイツ
EMail: Hannes.Tschofenig@siemens.com
メール: Hannes.Tschofenig@siemens.com
Peterson, et al. Informational [Page 14] RFC 4484 SIPPING TBA August 2006
ピーターソン、他 TBA2006年8月にちびちび飲む情報[14ページ]のRFC4484
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントは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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Peterson, et al. Informational [Page 15]
ピーターソン、他 情報[15ページ]
一覧
スポンサーリンク
