RFC3325 日本語訳
3325 Private Extensions to the Session Initiation Protocol (SIP) forAsserted Identity within Trusted Networks. C. Jennings, J. Peterson,M. Watson. November 2002. (Format: TXT=36170 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Jennings Request for Comments: 3325 Cisco Systems Category: Informational J. Peterson NeuStar, Inc. M. Watson Nortel Networks November 2002
コメントを求めるワーキンググループC.ジョニングス要求をネットワークでつないでください: 3325年のシスコシステムズカテゴリ: M.ワトソンノーテルが2002年11月にネットワークでつなぐ情報のJ.ピーターソンNeuStar Inc.
Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
信じられたネットワークの中の断言されたアイデンティティのためのセッション開始プロトコル(一口)への個人的な拡大
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the identity of authenticated users, and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for use between different trust domains, or use in the Internet at large.
このドキュメントは信じられたSIPサーバのネットワークが認証されたユーザのアイデンティティ、および既存のプライバシーメカニズムの応用についてアイデンティティ問題に断言するのを可能にするSession Initiationプロトコル(SIP)に個人的な拡大について説明します。 そのような情報の世代、輸送、および用法だけに、これらの拡張子の使用は管理ドメインの中で以前に同意している方針で適切です。 このドキュメントは、異なった信用ドメインの間で使用に適した一般的なプライバシーかアイデンティティモデルを提供するか、または全体のインターネットで使用を提供しません。
Table of Contents
目次
1. Applicability Statement . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 6. Hints for Multiple Identities . . . . . . . . . . . . . . . 6 7. Requesting Privacy . . . . . . . . . . . . . . . . . . . . . 6 8. User Agent Server Behavior . . . . . . . . . . . . . . . . . 7 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 7 9.1 The P-Asserted-Identity Header . . . . . . . . . . . . 8 9.2 The P-Preferred-Identity Header . . . . . . . . . . . . 8 9.3 The "id" Privacy Type . . . . . . . . . . . . . . . . . 9
1. 適用性証明. . . . . . . . . . . . . . . . . . 2 2。 コンベンション. . . . . . . . . . . . . . . . . . . . . . . . 3 3。 序論. . . . . . . . . . . . . . . . . . . . . . . . 4 4。 概観. . . . . . . . . . . . . . . . . . . . . . . . . . 5 5。 プロキシの振舞い. . . . . . . . . . . . . . . . . . . . . . . 5 6。 複数のアイデンティティのために、.6 7に暗示します。 プライバシー. . . . . . . . . . . . . . . . . . . . . 6 8を要求します。 ユーザエージェントサーバの振舞い. . . . . . . . . . . . . . . . . 7 9。 正式な構文. . . . . . . . . . . . . . . . . . . . . . . 7 9.1アイデンティティであると断言されたP.89.2ヘッダーは「イド」プライバシーが.9にタイプするPがアイデンティティを好んでいる.89.3のヘッダーです。
Jennings, et. al. Informational [Page 1] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[1ページ]のRFC3325一口
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1 Network Asserted Identity passed to trusted gateway . . 9 10.2 Network Asserted Identity Withheld . . . . . . . . . . 11 11. Example of Spec(T) . . . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 13.1 Registration of new SIP header fields . . . . . . . . . 14 13.2 Registration of "id" privacy type for SIP Privacy header 15 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 Normative References . . . . . . . . . . . . . . . . . . . . 15 Informational References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
10. 例. . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1のNetwork Asserted Identityは信じられたゲートウェイ. . 9 10.2Network Asserted Identity Withheld. . . . . . . . . . 11 11に通りました。 仕様(T). . . . . . . . . . . . . . . . . . . . . 13 12に関する例。 セキュリティ問題. . . . . . . . . . . . . . . . . . 14 13。 新しいSIPヘッダーのIANA Considerations.14 13.1RegistrationはSIP Privacyヘッダー15 14のために「イド」プライバシータイプの.14 13.2Registrationをさばきます。 標準の参照. . . . . . . . . . . . . . . . . . . . 15の情報の参照. . . . . . . . . . . . . . . . . . 16作者のものが.17の完全な著作権宣言文. . . . . . . . . . . . . . . . . . 18を記述するという承認. . . . . . . . . . . . . . . . . . . . . . 15
1. Applicability Statement
1. 適用性証明
This document describes private extensions to SIP [1] that enable a network of trusted SIP servers to assert the identity of end users or end systems, and to convey indications of end-user requested privacy. The use of these extensions is only applicable inside a 'Trust Domain' as defined in Short term requirements for Network Asserted Identity [5]. Nodes in such a Trust Domain are explicitly trusted by its users and end-systems to publicly assert the identity of each party, and to be responsible for withholding that identity outside of the Trust Domain when privacy is requested. The means by which the network determines the identity to assert is outside the scope of this document (though it commonly entails some form of authentication).
このドキュメントは信じられたSIPサーバのネットワークがエンドユーザかエンドシステムのアイデンティティについて断言して、エンドユーザの要求されたプライバシーのしるしを運ぶのを可能にするSIP[1]に個人的な拡大について説明します。 これらの拡張子の使用はNetwork Asserted Identity[5]のためのShort用語要件で定義されるように単に'信用Domain'で適切です。 そのユーザとエンドシステムによって公的に各当事者のアイデンティティについて断言して、そのようなTrust Domainのノードはプライバシーが要求されているときTrust Domainの外でそのアイデンティティを差し控えるのに責任があると明らかに信じられます。 ネットワークがこのドキュメントの範囲の外に断言するアイデンティティがあることを(一般的に何らかの形式の認証を伴いますが)決定する手段。
A key requirement of [5] is that the behavior of all nodes within a given Trust Domain 'T' is known to comply to a certain set of specifications known as 'Spec(T)'. Spec(T) MUST specify behavior for the following:
[5]の主要な要件は与えられたTrust Domain'T'の中のすべてのノードの動きが'仕様(T)'として知られているある仕様に応じるのが知られているということです。 仕様(T)は以下のための振舞いを指定しなければなりません:
1. The manner in which users are authenticated
1. ユーザが認証される方法
2. The mechanisms used to secure the communication among nodes within the Trust Domain
2. メカニズムは以前はTrust Domainの中のノードの中でよくコミュニケーションを保証していました。
3. The mechanisms used to secure the communication between UAs and nodes within the Trust Domain
3. メカニズムは以前はTrust Domainの中でよくUAsとノードとのコミュニケーションを保証していました。
Jennings, et. al. Informational [Page 2] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[2ページ]のRFC3325一口
4. The manner used to determine which hosts are part of the Trust Domain
4. 方法は、以前はよくどのホストがTrust Domainの一部であるかを決定していました。
5. The default privacy handling when no Privacy header field is present
5. どんなPrivacyヘッダーフィールドも存在していないときのデフォルトプライバシー取り扱い
6. That nodes in the Trust Domain are compliant to SIP [1]
6. Trust DomainのノードはSIPに対応します。[1]
7. That nodes in the Trust Domain are compliant to this document
7. Trust Domainのノードはこのドキュメントに対応します。
8. Privacy handling for identity as described in Section 7.
8. セクション7で説明されるアイデンティティのためのプライバシー取り扱い。
An example of a suitable Spec(T) is shown in Section 11.
適当なSpec(T)に関する例はセクション11に示されます。
This document does NOT offer a general privacy or identity model suitable for inter-domain use or use in the Internet at large. Its assumptions about the trust relationship between the user and the network may not apply in many applications. For example, these extensions do not accommodate a model whereby end users can independently assert their identity by use of the extensions defined here. Furthermore, since the asserted identities are not cryptographically certified, they are subject to forgery, replay, and falsification in any architecture that does not meet the requirements of [5].
このドキュメントは全体のインターネットで相互ドメイン使用か使用に適した一般的なプライバシーかアイデンティティモデルを提供しません。 ユーザとネットワークとの信用関係に関する仮定は多くのアプリケーションで適用されないかもしれません。 例えば、これらの拡大はエンドユーザがここで定義された拡張子の使用で独自に彼らのアイデンティティについて断言できるモデルに対応しません。 その上、断言されたアイデンティティが暗号で公認されないので、それらは[5]に関する必要条件を満たさないどんな構造でも偽造、再生、および改竄を受けることがあります。
The asserted identities also lack an indication of who specifically is asserting the identity, and so it must be assumed that the Trust Domain is asserting the identity. Therefore, the information is only meaningful when securely received from a node known to be a member of the Trust Domain.
また、断言されたアイデンティティがだれが明確にアイデンティティについて断言するかしるしを欠いているので、Trust Domainがアイデンティティについて断言していると思わなければなりません。 したがって、Trust Domainのメンバーであることが知られているノードからしっかりと受け取ると、情報は重要であるだけです。
Despite these limitations, there are sufficiently useful specialized deployments that meet the assumptions described above, and can accept the limitations that result, to warrant informational publication of this mechanism. An example deployment would be a closed network which emulates a traditional circuit switched telephone network.
これらの制限にもかかわらず、このメカニズムの情報の公表を保証するために結果として生じる制限は、上で説明された仮定を満たす十分役に立つ専門化している展開であり、受け入れることができます。 例の展開は伝統的なサーキット切り換えられた電話網を見習う閉じているネットワークでしょう。
2. Conventions
2. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[3])で説明されるように本書では解釈されることであるべきです。
Throughout this document requirements for or references to proxy servers or proxy behavior apply similarly to other intermediaries within a Trust Domain (ex: B2BUAs).
このドキュメント中では、プロキシサーバかプロキシの振舞いの要件か参照が同様にTrust Domain(例えば、B2BUAs)の中の他の仲介者に適用されます。
Jennings, et. al. Informational [Page 3] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[3ページ]のRFC3325一口
The terms Identity, Network Asserted Identity and Trust Domain in this document have meanings as defined in [5].
用語のIdentity、Network Asserted Identity、およびTrust Domainには、意味が[5]で定義されるように本書ではあります。
3. Introduction
3. 序論
Various providers offering a telephony service over IP networks have selected SIP as a call establishment protocol. Their environments require a way for trusted network elements operated by the service providers (for example SIP proxy servers) to communicate the identity of the subscribers to such a service, yet also need to withhold this information from entities that are not trusted when necessary. Such networks typically assume some level of transitive trust amongst providers and the devices they operate.
呼び出し設立が議定書を作るとき、サービスオーバーIPネットワークを電話に提供する様々なプロバイダーがSIPを選択しました。 彼らの環境は、加入者のアイデンティティをそのようなサービスに伝えるためにサービスプロバイダー(例えば、SIPプロキシサーバ)によって運用された信じられたネットワーク要素のための方法を必要として、また、まだ必要であるときに信じられない実体からのこの情報を差し控える必要があります。 そのようなネットワークはそれらが操作するプロバイダーと装置の中で何らかのレベルの他動な信用を通常仮定します。
These networks need to support certain traditional telephony services and meet basic regulatory and public safety requirements. These include Calling Identity Delivery services, Calling Identity Delivery Blocking, and the ability to trace the originator of a call. While baseline SIP can support each of these services independently, certain combinations cannot be supported without the extensions described in this document. For example, a caller that wants to maintain privacy and consequently provides limited information in the SIP From header field will not be identifiable by recipients of the call unless they rely on some other means to discover the identity of the caller. Masking identity information at the originating user agent will prevent certain services, e.g., call trace, from working in the Public Switched Telephone Network (PSTN) or being performed at intermediaries not privy to the authenticated identity of the user.
これらのネットワークは、ある伝統的な電話サービスを支持して、基本の規定の、そして、公共の安全要求事項を満たす必要があります。 これらはCalling Identity Deliveryサービス、Calling Identity Delivery Blocking、および呼び出しの創始者をつける能力を含んでいます。 基線SIPが独自にそれぞれのこれらのサービスを支持できる間、本書では説明された拡大なしである組み合わせをサポートできません。 例えば、彼らが訪問者のアイデンティティを発見するある他の手段を当てにしないなら、呼び出しの受取人はプライバシーを維持したくて、その結果、SIP Fromヘッダーフィールドに限られた情報を前提とする訪問者が身元保証可能にならないでしょう。 由来しているユーザエージェントでアイデンティティ情報にマスクをかけると、あるサービスは防がれるでしょう、例えば、呼び出し跡、Public Switched Telephone Network(PSTN)で働いているか、またはユーザの認証されたアイデンティティに関与していない仲介者で実行されるのから。
This document attempts to provide a network asserted identity service using a very limited, simple mechanism, based on requirements in [5]. This work is derived from a previous attempt, [6], to solve several problems related to privacy and identity in Trust Domains. A more comprehensive mechanism, [7] which uses cryptography to address this problem is the subject of current study by the SIP working group.
このドキュメントは、アイデンティティサービスであると非常に制限されて、簡単なメカニズムを使用することで断言されたネットワークを提供するのを試みます、[5]の要件に基づいて。 Trust Domainsでプライバシーとアイデンティティに関連するいくつかの問題を解決するために前の試み、[6]からこの仕事を得ます。 より多くの包括的メカニズム、[7] どれがこのその問題を訴えるのに暗号を使用するかは、SIPワーキンググループによる現在の研究の対象です。
Providing privacy in a SIP network is more complicated than in the PSTN. In SIP networks, the participants in a session are typically able to exchange IP traffic directly without involving any SIP service provider. The IP addresses used for these sessions may themselves reveal private information. A general purpose mechanism for providing privacy in a SIP environment is discussed in [2]. This document applies that privacy mechanism to the problem of network asserted identity.
SIPネットワークにプライバシーを提供するのはPSTNより複雑です。 SIPネットワークでは、直接どんなSIPサービスプロバイダーにもかかわらないで、セッションの関係者はIP交通を通常交換できます。 セッションがそうするこれらに自分たちで使用されるIPアドレスは個人情報を明らかにします。 [2]でSIP環境にプライバシーを提供するための汎用のメカニズムについて議論します。 このドキュメントはアイデンティティであると断言されたネットワークの問題にそのプライバシーメカニズムを適用します。
Jennings, et. al. Informational [Page 4] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[4ページ]のRFC3325一口
4. Overview
4. 概観
The mechanism proposed in this document relies on a new header field called 'P-Asserted-Identity' that contains a URI (commonly a SIP URI) and an optional display-name, for example:
本書では提案されたメカニズムは例えばURI(一般的にSIP URI)と任意の表示名を含む'アイデンティティであると断言されたP'と呼ばれる新しいヘッダーフィールドを当てにします:
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
Pはアイデンティティについて断言しました: 「Cullenジョニングス」<一口: fluffy@cisco.com 、gt。
A proxy server which handles a message can, after authenticating the originating user in some way (for example: Digest authentication), insert such a P-Asserted-Identity header field into the message and forward it to other trusted proxies. A proxy that is about to forward a message to a proxy server or UA that it does not trust MUST remove all the P-Asserted-Identity header field values if the user requested that this information be kept private. Users can request this type of privacy as described in Section 7.
メッセージを扱うプロキシサーバは、何らかの方法(: 例えば、ダイジェスト認証)で由来しているユーザを認証した後に、そのようなアイデンティティであると断言されたPヘッダーフィールドをメッセージに挿入して、他の信じられたプロキシにそれを送ることができます。 ユーザが、この情報が個人的に保たれるよう要求したなら、メッセージをプロキシサーバに転送しようとしているプロキシかそれが信じないUAがすべてのアイデンティティであると断言されたPヘッダーフィールド値を取り除かなければなりません。 ユーザはセクション7で説明されるようにこのタイプのプライバシーを要求できます。
The formal syntax for the P-Asserted-Identity header is presented in Section 9.
アイデンティティであると断言されたPヘッダーに、正式な構文はセクション9に提示されます。
5. Proxy Behavior
5. プロキシの振舞い
A proxy in a Trust Domain can receive a message from a node that it trusts, or a node that it does not trust. When a proxy receives a message from a node it does not trust and it wishes to add a P- Asserted-Identity header field, the proxy MUST authenticate the originator of the message, and use the identity which results from this authentication to insert a P-Asserted-Identity header field into the message.
Trust Domainのプロキシはそれが信じるノード、またはそれが信じないノードからメッセージを受け取ることができます。 プロキシがそれが信じないノードからメッセージを受け取って、P断言されたアイデンティティヘッダーフィールドを加えたがっているとき、プロキシは、アイデンティティであると断言されたPヘッダーフィールドをメッセージに挿入するのにメッセージの創始者を認証して、この認証から生じるアイデンティティを使用しなければなりません。
If the proxy receives a message (request or response) from a node that it trusts, it can use the information in the P-Asserted-Identity header field, if any, as if it had authenticated the user itself.
プロキシがそれが信じるノードからメッセージ(要求か応答)を受け取るなら、アイデンティティであると断言されたPヘッダーフィールドに情報を使用できます、もしあれば、まるでユーザ自身を認証したかのように。
If there is no P-Asserted-Identity header field present, a proxy MAY add one containing at most one SIP or SIPS URI, and at most one tel URL. If the proxy received the message from an element that it does not trust and there is a P-Asserted-Identity header present which contains a SIP or SIPS URI, the proxy MUST replace that SIP or SIPS URI with a single SIP or SIPS URI or remove this header field. Similarly, if the proxy received the message from an element that it does not trust and there is a P-Asserted-Identity header present which contains a tel URI, the proxy MUST replace that tel URI with a single tel URI or remove the header field.
どんな存在しているアイデンティティであると断言されたPヘッダーフィールドもなければ、プロキシはほとんどの1SIPかSIPS URIと、高々あるtel URLでの、ある含有を加えるかもしれません。 どれがSIPを含んでいるか、そして、SIPS URI、プロキシがそれが信じない要素からメッセージを受け取って、出席しているアイデンティティであると断言されたPヘッダーがあれば、プロキシはそのSIPかSIPS URIを独身のSIPかSIPS URIに取り替えなければならないか、またはこのヘッダーフィールドを移さなければなりません。 同様に、プロキシが要素からのどんな信用もしないで、出席しているアイデンティティであると断言されたPヘッダーがあるというtel URIを含むメッセージを受け取ったなら、プロキシは、そのtel URIをただ一つのtel URIに取り替えなければならないか、またはヘッダーフィールドを移さなければなりません。
When a proxy forwards a message to another node, it must first determine if it trusts that node or not. If it trusts the node, the proxy does not remove any P-Asserted-Identity header fields that it
プロキシが別のノードにメッセージを転送するとき、それは、最初に、そのノードを信じるかどうか決定しなければなりません。 ノード、プロキシが取り外さないと信じるならどんなアイデンティティであると断言されたPヘッダーもそれをさばく、それ
Jennings, et. al. Informational [Page 5] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[5ページ]のRFC3325一口
generated itself, or that it received from a trusted source. If it does not trust the element, then the proxy MUST examine the Privacy header field (if present) to determine if the user requested that asserted identity information be kept private.
それ自体を発生させた、または、それは信頼できるソースから受信されました。 要素を信じないなら、プロキシは、ユーザが、断言されたアイデンティティ情報が個人的に保たれるよう要求したかどうか決定するために、Privacyヘッダーフィールド(存在しているなら)を調べなければなりません。
6. Hints for Multiple Identities
6. 複数のアイデンティティのためのヒント
If a P-Preferred-Identity header field is present in the message that a proxy receives from an entity that it does not trust, the proxy MAY use this information as a hint suggesting which of multiple valid identities for the authenticated user should be asserted. If such a hint does not correspond to any valid identity known to the proxy for that user, the proxy can add a P-Asserted-Identity header of its own construction, or it can reject the request (for example, with a 403 Forbidden). The proxy MUST remove the user-provided P-Preferred- Identity header from any message it forwards.
Pがアイデンティティを好んでいるヘッダーフィールドがプロキシがそれが信じない実体から受信するというメッセージに存在しているなら、プロキシは複数の認証されたユーザにとって、有効なアイデンティティのどれが断言されるべきであるかを示唆するヒントとしてこの情報を使用するかもしれません。 そのようなヒントがそのユーザでプロキシにおいて知られているどんな有効なアイデンティティとも食い違っているなら、プロキシがそれ自身の工事のアイデンティティであると断言されたPヘッダーを加えることができますか、またはそれは要求(例えば403Forbiddenと共に)を拒絶できます。 プロキシはそれが転送するどんなメッセージからもユーザによって提供されたPで都合のよいアイデンティティのヘッダーを取り除かなければなりません。
A user agent only sends a P-Preferred-Identity header field to proxy servers in a Trust Domain; user agents MUST NOT populate the P- Preferred-Identity header field in a message that is not sent directly to a proxy that is trusted by the user agent. Were a user agent to send a message containing a P-Preferred-Identity header field to a node outside a Trust Domain, then the hinted identity might not be managed appropriately by the network, which could have negative ramifications for privacy.
ユーザエージェントはPがアイデンティティを好んでいるヘッダーフィールドをTrust Domainのプロキシサーバに送るだけです。 ユーザエージェントは直接ユーザエージェントによって信じられるプロキシに送られないメッセージのP都合のよいアイデンティティヘッダーフィールドに居住してはいけません。 ユーザエージェントがTrust Domainの外にPがアイデンティティを好んでいるヘッダーフィールドをノードに含むメッセージを送るなら、暗示されたアイデンティティはネットワークによって適切に管理されないでしょうに。(それは、プライバシーのための否定的分岐を持つことができました)。
7. Requesting Privacy
7. プライバシーを要求します。
Parties who wish to request the removal of P-Asserted-Identity header fields before they are transmitted to an element that is not trusted may add the "id" privacy token defined in this document to the Privacy header field. The Privacy header field is defined in [6]. If this token is present, proxies MUST remove all the P-Asserted- Identity header fields before forwarding messages to elements that are not trusted. If the Privacy header field value is set to "none" then the proxy MUST NOT remove the P-Asserted-Identity header fields.
それらが信じられない要素に伝えられる前にアイデンティティであると断言されたPヘッダーフィールドの取り外しを要求したがっている党は本書ではPrivacyヘッダーフィールドと定義された「イド」プライバシー象徴を加えるかもしれません。 Privacyヘッダーフィールドは[6]で定義されます。 この象徴が存在しているなら、信じられない要素にメッセージを転送する前に、プロキシはすべてのPで断言されたアイデンティティのヘッダーフィールドを取り除かなければなりません。 Privacyヘッダーフィールド価値が「なにも」に設定されるなら、プロキシはアイデンティティであると断言されたPヘッダーフィールドを取り除いてはいけません。
When a proxy is forwarding the request to an element that is not trusted and there is no Privacy header field, the proxy MAY include the P-Asserted-Identity header field or it MAY remove it. This decision is a policy matter of the Trust Domain and MUST be specified in Spec(T). It is RECOMMENDED that the P-Asserted-Identity header fields SHOULD NOT be removed unless local privacy policies prevent it, because removal may cause services based on Asserted Identity to fail.
プロキシが信じられない要素に要求を転送していて、Privacyヘッダーフィールドが全くないとき、プロキシがアイデンティティであると断言されたPヘッダーフィールドを入れるかもしれませんか、またはそれはそれを取り除くかもしれません。 この決定をTrust Domainの方針問題であり、Spec(T)で指定しなければなりません。 地方のプライバシーに関する方針がそれを防がないならアイデンティティであると断言されたPヘッダーフィールドSHOULD NOTが取り外されるのは、RECOMMENDEDです、取り外しがAsserted Identityに基づくサービスに失敗されるかもしれないので。
Jennings, et. al. Informational [Page 6] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[6ページ]のRFC3325一口
However, it should be noted that unless all users of the Trust Domain have access to appropriate privacy services, forwarding of the P- Asserted-Identity may result in disclosure of information which the user has not requested and cannot prevent. It is therefore STRONGLY RECOMMENDED that all users have access to privacy services as described in this document.
しかしながら、Trust Domainのすべてのユーザが適切なプライバシーサービスに近づく手段を持っていないなら、P断言されたアイデンティティの推進がユーザが要求していなくて、防ぐことができない情報の公開をもたらすかもしれないことに注意されるべきです。 したがって、すべてのユーザが本書では説明されるようにプライバシーサービスに近づく手段を持っているのは、STRONGLY RECOMMENDEDです。
Formal specification of the "id" Privacy header priv-value is described in Section 9.3. Some general guidelines for when users require privacy are given in [2].
「イド」Privacyヘッダーpriv-価値に関する形式仕様はセクション9.3で説明されます。 [2]でユーザがプライバシーを必要とする時の間のいくつかの一般的ガイドラインを与えます。
If multiple P-Asserted-Identity header field values are present in a message, and privacy of the P-Asserted-Identity header field is requested, then all instances of the header field values MUST be removed before forwarding the request to an entity that is not trusted.
複数のアイデンティティであると断言されたPヘッダーフィールド値がメッセージに存在していて、アイデンティティであると断言されたPヘッダーフィールドのプライバシーを要求するなら、信じられない実体に要求を転送する前に、ヘッダーフィールド値のすべての例を取り除かなければなりません。
8. User Agent Server Behavior
8. ユーザエージェントサーバの振舞い
Typically, a user agent renders the value of a P-Asserted-Identity header field that it receives to its user. It may consider the identity provided by a Trust Domain to be privileged, or intrinsically more trustworthy than the From header field of a request. However, any specific behavior is specific to implementations or services. This document also does not mandate any user agent handling for multiple P-Asserted-Identity header field values that happen to appear in a message (such as a SIP URI alongside a tel URL).
通常、ユーザエージェントはそれがユーザに受けるアイデンティティであると断言されたPヘッダーフィールドの値をレンダリングします。 それは、Trust Domainによって提供されたアイデンティティが特権があるか、または要求のFromヘッダーフィールドより本質的に信頼できると考えるかもしれません。 しかしながら、どんな特異的行動も実現かサービスに特定です。 このドキュメントもメッセージ(tel URLと並んでSIP URIなどの)にたまたま現れる複数のアイデンティティであると断言されたPヘッダーフィールド値のための少しのユーザエージェント取り扱いも強制しません。
However, if a User Agent Server receives a message from a previous element that it does not trust, it MUST NOT use the P-Asserted- Identity header field in any way.
しかしながら、UserエージェントServerがそれが信じない前の要素からメッセージを受け取るなら、それは何らかの方法でPで断言されたアイデンティティのヘッダーフィールドを使用してはいけません。
If a UA is part of the Trust Domain from which it received a message containing a P-Asserted-Identity header field, then it can use the value freely but it MUST ensure that it does not forward the information to any element that is not part of the Trust Domain, if the user has requested that asserted identity information be kept private.
UAがそれがアイデンティティであると断言されたPヘッダーフィールドを含むメッセージを受け取ったTrust Domainの一部であるなら、自由に値を使用できますが、それは、ユーザが、断言されたアイデンティティ情報が個人的に保たれるよう要求して、Trust Domainが部分がないというどんな要素への情報も転送しないのを確実にしなければなりません。
If a UA is not part of the Trust Domain from which it received a message containing a P-Asserted-Identity header field, then it can assume this information does not need to be kept private.
UAがそれがアイデンティティであると断言されたPヘッダーフィールドを含むメッセージを受け取ったTrust Domainの一部でないなら、それは、この情報によって個人的に保たれる必要はないと仮定できます。
9. Formal Syntax
9. 正式な構文
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [4].
以下の構文仕様はRFC-2234[4]で説明されるように増大しているBN記法(BNF)を使用します。
Jennings, et. al. Informational [Page 7] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[7ページ]のRFC3325一口
9.1 The P-Asserted-Identity Header
9.1 アイデンティティであると断言されたPヘッダー
The P-Asserted-Identity header field is used among trusted SIP entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication.
アイデンティティであると断言されたPヘッダーフィールドは、それが認証で確かめられたときSIPメッセージを送るユーザのアイデンティティを運ぶのに信じられたSIP実体(通常仲介者)の中で使用されます。
PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value *(COMMA PAssertedID-value) PAssertedID-value = name-addr / addr-spec
PAssertedID=「アイデンティティであると断言されたP」HCOLON PAssertedID-値*(COMMA PAssertedID-値)PAssertedID-値は名前addr / addr仕様と等しいです。
A P-Asserted-Identity header field value MUST consist of exactly one name-addr or addr-spec. There may be one or two P-Asserted-Identity values. If there is one value, it MUST be a sip, sips, or tel URI. If there are two values, one value MUST be a sip or sips URI and the other MUST be a tel URI. It is worth noting that proxies can (and will) add and remove this header field.
アイデンティティであると断言されたPヘッダーフィールド価値はまさに1名前-addrかaddr-仕様から成らなければなりません。 1か2つのアイデンティティであると断言されたP値があるかもしれません。 1つの値があれば、それは、一口、一口、またはtel URIであるに違いありません。 2つの値があれば、1つの値が、一口でなければならないかURIをちびちび飲みます、そして、もう片方がtel URIであるに違いありません。 プロキシがそうすることができる価値が注意されて、(and will)がこのヘッダーフィールドを加えて、取り除くということです。
This document adds the following entry to Table 2 of [1]:
このドキュメントは[1]のTable2に以下のエントリーを加えます:
Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- P-Asserted-Identity adr - o - o o -
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG------------ ----- ----- --- --- --- --- --- --- アイデンティティであると断言されたP adr--o--o o、-
SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o - - -
潜水艦審判INF UPD PRAでない--- --- --- --- --- --- o o o - - -
9.2 The P-Preferred-Identity Header
9.2 Pがアイデンティティを好んでいるヘッダー
The P-Preferred-Identity header field is used from a user agent to a trusted proxy to carry the identity the user sending the SIP message wishes to be used for the P-Asserted-Header field value that the trusted element will insert.
Pがアイデンティティを好んでいるヘッダーフィールドはアイデンティティを運ぶのにユーザエージェントから信じられたプロキシまで使用されて、SIPメッセージを送るユーザを信じられた要素が挿入するヘッダーフィールドであると断言されたP値に使用されたいということです。
PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value *(COMMA PPreferredID-value) PPreferredID-value = name-addr / addr-spec
PPreferredID=「P都合のよいアイデンティティ」HCOLON PPreferredID-値*(COMMA PPreferredID-値)PPreferredID-値は名前addr / addr仕様と等しいです。
A P-Preferred-Identity header field value MUST consist of exactly one name-addr or addr-spec. There may be one or two P-Preferred-Identity values. If there is one value, it MUST be a sip, sips, or tel URI. If there are two values, one value MUST be a sip or sips URI and the other MUST be a tel URI. It is worth noting that proxies can (and will) remove this header field.
Pがアイデンティティを好んでいるヘッダーフィールド値はまさに1名前-addrかaddr-仕様から成らなければなりません。 1か2つのPがアイデンティティを好んでいる値があるかもしれません。 1つの値があれば、それは、一口、一口、またはtel URIであるに違いありません。 2つの値があれば、1つの値が、一口でなければならないかURIをちびちび飲みます、そして、もう片方がtel URIであるに違いありません。 プロキシがそうすることができる価値が注意されて、(and will)がこのヘッダーフィールドを取り除くということです。
Jennings, et. al. Informational [Page 8] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[8ページ]のRFC3325一口
This document adds the following entry to Table 2 of [1]:
このドキュメントは[1]のTable2に以下のエントリーを加えます:
Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- P-Preferred-Identity adr - o - o o -
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG------------ ----- ----- --- --- --- --- --- --- Pがアイデンティティを好んでいるadr--o--o o、-
SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o - - -
潜水艦審判INF UPD PRAでない--- --- --- --- --- --- o o o - - -
9.3 The "id" Privacy Type
9.3 「イド」プライバシータイプ
This specification adds a new privacy type ("priv-value") to the Privacy header, defined in [2]. The presence of this privacy type in a Privacy header field indicates that the user would like the Network Asserted Identity to be kept private with respect to SIP entities outside the Trust Domain with which the user authenticated. Note that a user requesting multiple types of privacy MUST include all of the requested privacy types in its Privacy header field value.
この仕様は新しいプライバシータイプ(「priv-値」)を[2]で定義されたPrivacyヘッダーに加えます。 Privacyヘッダーフィールドにおける、このプライバシータイプの存在は、Network Asserted IdentityをユーザによってTrust Domainの外でユーザが認証したものでSIP実体に関して個人的に保たれたがっているのを示します。 複数のタイプのプライバシーが要求されたプライバシーのすべてを含まなければならないよう要求するユーザがPrivacyヘッダーフィールド価値をタイプすることに注意してください。
priv-value = "id"
priv-値は「イド」と等しいです。
Example:
例:
Privacy: id
プライバシー: イド
10. Examples
10. 例
10.1 Network Asserted Identity passed to trusted gateway
10.1 信じられたゲートウェイに渡されたネットワークAsserted Identity
In this example, proxy.cisco.com creates a P-Asserted-Identity header field from an identity it discovered from SIP Digest authentication. It forwards this information to a trusted proxy which forwards it to a trusted gateway. Note that these examples consist of partial SIP messages that illustrate only those headers relevant to the authenticated identity problem.
この例では、proxy.cisco.comはそれがSIP Digest認証から発見したアイデンティティからアイデンティティであると断言されたPヘッダーフィールドを作成します。 それは信じられたプロキシへの信じられたゲートウェイにそれを送るこの情報を転送します。 これらの例が認証されたアイデンティティ問題に関連しているそれらのヘッダーだけを例証する部分的なSIPメッセージから成ることに注意してください。
* F1 useragent.cisco.com -> proxy.cisco.com
* F1useragent.cisco.com->proxy.cisco.com
INVITE sip:+14085551212@cisco.com SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123 To: <sip:+14085551212@cisco.com> From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 1 INVITE Max-Forwards: 70 Privacy: id
INVITE一口: + 14085551212@cisco.com SIP/2.0Via: 一口/2.0/TCP useragent.cisco.com; ブランチ=z9hG4bK-123To: <一口: + 14085551212@cisco.com 、gt;、From: 「匿名」の<一口: anonymous@anonymous.invalid 、gt;、; タグは9802748呼び出しIDと等しいです: 245780247857024504CSeq: 1 前方へマックスを招待してください: 70プライバシー: イド
Jennings, et. al. Informational [Page 9] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[9ページ]のRFC3325一口
* F2 proxy.cisco.com -> useragent.cisco.com
* F2 proxy.cisco.com->useragent.cisco.com
SIP/2.0 407 Proxy Authorization Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123 To: <sip:+14085551212@cisco.com>;tag=123456 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 1 INVITE Proxy-Authenticate: .... realm="sip.cisco.com"
以下を通って一口/2.0 407プロキシ認可 一口/2.0/TCP useragent.cisco.com; ブランチ=z9hG4bK-123To: <一口: + 14085551212@cisco.com 、gt;、;=123456From:にタグ付けをしてください 「匿名」の<一口: anonymous@anonymous.invalid 、gt;、; タグは9802748呼び出しIDと等しいです: 245780247857024504CSeq: 1 招待は以下をプロキシで認証します。 … . 分野="sip.cisco.com"
* F3 useragent.cisco.com -> proxy.cisco.com
* F3 useragent.cisco.com->proxy.cisco.com
INVITE sip:+14085551212@cisco.com SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124 To: <sip:+14085551212@cisco.com> From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 70 Privacy: id Proxy-Authorization: .... realm="sip.cisco.com" user="fluffy"
INVITE一口: + 14085551212@cisco.com SIP/2.0Via: 一口/2.0/TCP useragent.cisco.com; ブランチ=z9hG4bK-124To: <一口: + 14085551212@cisco.com 、gt;、From: 「匿名」の<一口: anonymous@anonymous.invalid 、gt;、; タグは9802748呼び出しIDと等しいです: 245780247857024504CSeq: 2 前方へマックスを招待してください: 70プライバシー: イドProxy-認可: … . 「綿毛分野="sip.cisco.com"ユーザ=」
* F4 proxy.cisco.com -> proxy.pstn.net (trusted)
* F4 proxy.cisco.com->proxy.pstn.net(信じられます)
INVITE sip:+14085551212@proxy.pstn.net SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc To: <sip:+14085551212@cisco.com> From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 69 P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com> P-Asserted-Identity: tel:+14085264000 Privacy: id
INVITE一口: + 14085551212@proxy.pstn.net SIP/2.0Via: 一口/2.0/TCP useragent.cisco.com; ブランチは以下を通ってz9hG4bK-124と等しいです。 一口/2.0/TCP proxy.cisco.com; ブランチ=z9hG4bK-abc To: <一口: + 14085551212@cisco.com 、gt;、From: 「匿名」の<一口: anonymous@anonymous.invalid 、gt;、; タグは9802748呼び出しIDと等しいです: 245780247857024504CSeq: 2 前方へマックスを招待してください: 69 Pはアイデンティティについて断言しました: 「Cullenジョニングス」<一口: fluffy@cisco.com 、gt;、Pはアイデンティティについて断言しました: tel: +14085264000 プライバシー: イド
Jennings, et. al. Informational [Page 10] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[10ページ]のRFC3325一口
* F5 proxy.pstn.net -> gw.pstn.net (trusted)
* F5 proxy.pstn.net->gw.pstn.net(信じられます)
INVITE sip:+14085551212@gw.pstn.net SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc Via: SIP/2.0/TCP proxy.pstn.net;branch=z9hG4bK-a1b2 To: <sip:+14085551212@cisco.com> From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 68 P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com> P-Asserted-Identity: tel:+14085264000 Privacy: id
INVITE一口: + 14085551212@gw.pstn.net SIP/2.0Via: 一口/2.0/TCP useragent.cisco.com; ブランチは以下を通ってz9hG4bK-124と等しいです。 一口/2.0/TCP proxy.cisco.com; ブランチは以下を通ってz9hG4bK-abcと等しいです。 一口/2.0/TCP proxy.pstn.net; ブランチ=z9hG4bK-a1b2To: <一口: + 14085551212@cisco.com 、gt;、From: 「匿名」の<一口: anonymous@anonymous.invalid 、gt;、; タグは9802748呼び出しIDと等しいです: 245780247857024504CSeq: 2 前方へマックスを招待してください: 68 Pはアイデンティティについて断言しました: 「Cullenジョニングス」<一口: fluffy@cisco.com 、gt;、Pはアイデンティティについて断言しました: tel: +14085264000 プライバシー: イド
10.2 Network Asserted Identity Withheld
10.2ネットワークは、アイデンティティが差し控えたと断言しました。
In this example, the User Agent sends an INVITE that indicates it would prefer the identity sip:fluffy@cisco.com to the first proxy, which authenticates this with SIP Digest. The first proxy creates a P-Asserted-Identity header field and forwards it to a trusted proxy (outbound.cisco.com). The next proxy removes the P-Asserted-Identity header field and the request for Privacy before forwarding this request onward to the biloxi.com proxy server which it does not trust.
この例では、Userエージェントはアイデンティティ一口を好むでしょう: 第1代SIP Digestと共にこれを認証するプロキシへの fluffy@cisco.com を示すINVITEを送ります。 第1代プロキシは、アイデンティティであると断言されたPヘッダーフィールドを作成して、信じられたプロキシ(outbound.cisco.com)にそれを送ります。 それが信じないbiloxi.comプロキシサーバにこの要求を前方へ転送する前に、次期プロキシはアイデンティティであると断言されたPヘッダーフィールドとPrivacyを求める要求を取り除きます。
* F1 useragent.cisco.com -> proxy.cisco.com
* F1useragent.cisco.com->proxy.cisco.com
INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111 To: <sip:bob@biloxi.com> From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 1 INVITE Max-Forwards: 70 Privacy: id P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
INVITE一口: bob@biloxi.com SIP/2.0Via: 一口/2.0/TCP useragent.cisco.com; ブランチ=z9hG4bK-a111To: <一口: bob@biloxi.com 、gt;、From: 「匿名」の<一口: anonymous@anonymous.invalid 、gt;、; タグは9802748呼び出しIDと等しいです: 245780247857024504CSeq: 1 前方へマックスを招待してください: 70プライバシー: イドのP都合のよいアイデンティティ: 「Cullenジョニングス」<一口: fluffy@cisco.com 、gt。
* F2 proxy.cisco.com -> useragent.cisco.com SIP/2.0 407 Proxy Authorization Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111 To: <sip:bob@biloxi.com>;tag=123456 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 1 INVITE Proxy-Authenticate: .... realm="cisco.com"
* F2 proxy.cisco.com->useragent.cisco.com SIP/2.0 407Proxy Authorization Via: 一口/2.0/TCP useragent.cisco.com; ブランチ=z9hG4bK-a111To: <一口: bob@biloxi.com 、gt;、;=123456From:にタグ付けをしてください 「匿名」の<一口: anonymous@anonymous.invalid 、gt;、; タグは9802748呼び出しIDと等しいです: 245780247857024504CSeq: 1 招待は以下をプロキシで認証します。 … . 分野="cisco.com"
Jennings, et. al. Informational [Page 11] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[11ページ]のRFC3325一口
* F3 useragent.cisco.com -> proxy.cisco.com
* F3 useragent.cisco.com->proxy.cisco.com
INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123 To: <sip:bob@biloxi.com> From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 70 Privacy: id P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@cisco.com> Proxy-Authorization: .... realm="cisco.com" user="fluffy"
INVITE一口: bob@biloxi.com SIP/2.0Via: 一口/2.0/TCP useragent.cisco.com; ブランチ=z9hG4bK-a123To: <一口: bob@biloxi.com 、gt;、From: 「匿名」の<一口: anonymous@anonymous.invalid 、gt;、; タグは9802748呼び出しIDと等しいです: 245780247857024504CSeq: 2 前方へマックスを招待してください: 70プライバシー: イドのP都合のよいアイデンティティ: 「Cullenジョニングス」<一口: fluffy@cisco.com 、gt;、プロキシ認可: … . 「綿毛分野="cisco.com"ユーザ=」
* F4 proxy.cisco.com -> outbound.cisco.com (trusted)
* F4 proxy.cisco.com->outbound.cisco.com(信じられます)
INVITE sip:bob@biloxi SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234 To: <sip:bob@biloxi.com> From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 69 P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@vovida.org> Privacy: id
INVITE一口: bob@biloxi SIP/2.0Via: 一口/2.0/TCP useragent.cisco.com; ブランチは以下を通ってz9hG4bK-a123と等しいです。 一口/2.0/TCP proxy.cisco.com; ブランチ=z9hG4bK-b234To: <一口: bob@biloxi.com 、gt;、From: 「匿名」の<一口: anonymous@anonymous.invalid 、gt;、; タグは9802748呼び出しIDと等しいです: 245780247857024504CSeq: 2 前方へマックスを招待してください: 69 Pはアイデンティティについて断言しました: 「Cullenジョニングス」<一口: fluffy@vovida.org 、gt;、プライバシー: イド
* F5 outbound.cisco.com -> proxy.biloxi.com (not trusted)
* F5 outbound.cisco.com->proxy.biloxi.com(信じられません)
INVITE sip:bob@biloxi SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234 Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345 To: <sip:bob@biloxi.com> From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 68 Privacy: id
INVITE一口: bob@biloxi SIP/2.0Via: 一口/2.0/TCP useragent.cisco.com; ブランチは以下を通ってz9hG4bK-a123と等しいです。 一口/2.0/TCP proxy.cisco.com; ブランチは以下を通ってz9hG4bK-b234と等しいです。 一口/2.0/TCP outbound.cisco.com; ブランチ=z9hG4bK-c345To: <一口: bob@biloxi.com 、gt;、From: 「匿名」の<一口: anonymous@anonymous.invalid 、gt;、; タグは9802748呼び出しIDと等しいです: 245780247857024504CSeq: 2 前方へマックスを招待してください: 68プライバシー: イド
Jennings, et. al. Informational [Page 12] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[12ページ]のRFC3325一口
* F6 proxy.biloxi.com -> bobster.biloxi.com
* F6 proxy.biloxi.com->bobster.biloxi.com
INVITE sip:bob@bobster.biloxi.com SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234 Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345 Via: SIP/2.0/TCP proxy.biloxi.com;branch=z9hG4bK-d456 To: <sip:bob@biloxi.com> From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Call-ID: 245780247857024504 CSeq: 2 INVITE Max-Forwards: 67 Privacy: id
INVITE一口: bob@bobster.biloxi.com SIP/2.0Via: 一口/2.0/TCP useragent.cisco.com; ブランチは以下を通ってz9hG4bK-a123と等しいです。 一口/2.0/TCP proxy.cisco.com; ブランチは以下を通ってz9hG4bK-b234と等しいです。 一口/2.0/TCP outbound.cisco.com; ブランチは以下を通ってz9hG4bK-c345と等しいです。 一口/2.0/TCP proxy.biloxi.com; ブランチ=z9hG4bK-d456To: <一口: bob@biloxi.com 、gt;、From: 「匿名」の<一口: anonymous@anonymous.invalid 、gt;、; タグは9802748呼び出しIDと等しいです: 245780247857024504CSeq: 2 前方へマックスを招待してください: 67プライバシー: イド
11. Example of Spec(T)
11. 仕様に関する例(T)
The integrity of the mechanism described in this document relies on one node knowing (through configuration) that all of the nodes in a Trust Domain will behave in a predetermined way. This requires the predetermined behavior to be clearly defined and for all nodes in the Trust Domain to be compliant. The specification set that all nodes in a Trust Domain T must comply with is termed 'Spec(T)'.
本書では説明されたメカニズムの保全はTrust Domainのノードのすべてが予定された方法で振る舞わせる1つのノードの知ること(構成を通した)を当てにします。 これは、明確に定義されて、Trust Domainのすべてのノードが対応であるために予定された振舞いを必要とします。 Trust Domain Tのすべてのノードが従わなければならない仕様セットは'仕様(T)'と呼ばれます。
The remainder of this section presents an example Spec(T), which is not normative in any way.
このセクションの残りは例のSpec(T)を寄贈します。(Spec(T)は何らかの方法で規範的ではありません)。
1. Protocol requirements
1. プロトコル要件
The following specifications MUST be supported:
以下の仕様を支持しなければなりません:
1. RFC 3261
1. RFC3261
2. RFC 3325
2. RFC3325
2. Authentication requirements
2. 認証要件
Users MUST be authenticated using SIP Digest Authentication.
SIP Digest Authenticationを使用して、ユーザを認証しなければなりません。
3. Security requirements
3. セキュリティ要件
Connections between nodes within the Trust Domain and between UAs and nodes in the Trust Domain MUST use TLS using a cipher suite of RSA_WITH_AES_128_CBC_SHA1. Mutual authentication between nodes in the trust domain MUST be performed and confidentiality MUST be negotiated.
RSA_WITH_AES_128_CBC_SHA1の暗号スイートを使用して、Trust DomainのTrust Domainの中のノードとUAsとノードの間のコネクションズはTLSを使用しなければなりません。 信用ドメインのノードの間の互いの認証を実行しなければなりません、そして、秘密性を交渉しなければなりません。
Jennings, et. al. Informational [Page 13] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[13ページ]のRFC3325一口
4. Scope of Trust Domain
4. 信用ドメインの範囲
The Trust Domain specified in this agreement consists of hosts which posses a valid certificate which is a) signed by examplerootca.org; b) whose subjectAltName ends with one of the following domain names: trusted.div1.carrier-a.net, trusted.div2.carrier-a.net, sip.carrier-b.com; and c) whose domain name corresponds to the hostname in the subjectAltName in the certificate.
この合意で指定されたTrust Domainはa)であるそれの武装隊a有効な証明書がexamplerootca.orgでサインしたホストから成ります。 b) だれのsubjectAltNameは以下のドメイン名の1つで以下を終わらせますか? trusted.div1.carrier-a.が網状になっていて、trusted.div2.carrier-a.が網状になっているsip.carrier-b.com。 そして、ドメイン名が証明書のsubjectAltNameのホスト名に対応するc)。
5. Implicit handling when no Privacy header is present
5. どんなPrivacyヘッダーも出席していないときの暗黙の取り扱い
The elements in the trust domain must support the 'id' privacy service therefore absence of a Privacy header can be assumed to indicate that the user is not requesting any privacy. If no Privacy header field is present in a request, elements in this Trust Domain MUST act as if no privacy is requested.
信用ドメインの要素は'イド'プライバシーサービスを支持しなければなりません、したがって、Privacyヘッダーの不在が、ユーザが少しのプライバシーも要求していないのを示すと思うことができます。 どんなPrivacyヘッダーフィールドも要求に存在していないなら、まるでプライバシーが全く要求されていないかのようにこのTrust Domainの要素は作用しなければなりません。
12. Security Considerations
12. セキュリティ問題
The mechanism provided in this document is a partial consideration of the problem of identity and privacy in SIP. For example, these mechanisms provide no means by which end users can securely share identity information end-to-end without a trusted service provider. Identity information that the user designates as 'private' can be inspected by any intermediaries participating in the Trust Domain. This information is secured by transitive trust, which is only as reliable as the weakest link in the chain of trust.
本書では提供されたメカニズムはSIPのアイデンティティとプライバシーの問題の部分対価です。 例えば、これらのメカニズムはエンドユーザが信じられたサービスプロバイダーなしでアイデンティティの情報の終わりから終わりをしっかりと共有できる手段を全く提供しません。 Trust Domainに参加するどんな仲介者もユーザが'個人的である'として指定するアイデンティティ情報を点検できます。 他動な信用でこの情報を保証します。(それは、信用のチェーンで最も弱いリンクだけと同じくらい信頼できます)。
When a trusted entity sends a message to any destination with that party's identity in a P-Asserted-Identity header field, the entity MUST take precautions to protect the identity information from eavesdropping and interception to protect the confidentiality and integrity of that identity information. The use of transport or network layer hop-by-hop security mechanisms, such as TLS or IPSec with appropriate cipher suites, can satisfy this requirement.
信じられた実体がアイデンティティであると断言されたPヘッダーフィールドにおけるそのパーティーのアイデンティティがあるどんな目的地にもメッセージを送るとき、そのアイデンティティ情報の秘密性と保全を保護するために雨垂れと妨害からアイデンティティ情報を保護するために実体の予防策を講されなければなりません。 輸送の使用かホップごとの適切な暗号スイートがあるTLSかIPSecなどのネットワーク層セキュリティー対策がこの要件を満たすことができます。
13. IANA Considerations
13. IANA問題
13.1 Registration of new SIP header fields
13.1 新しいSIPヘッダーフィールドの登録
This document defines two new private SIP header fields, "P- Asserted-Identity" and "P-Preferred-Identity". As recommended by the policy of the Transport Area, these headers have been registered by the IANA in the SIP header registry, using the RFC number of this document as its reference.
このドキュメントは2新しい個人的なSIPヘッダーフィールド、「P断言されたアイデンティティ」、および「P都合のよいアイデンティティ」を定義します。 Transport Areaの方針で推薦されるように、これらのヘッダーはSIPヘッダー登録のIANAによって登録されました、参照としてこのドキュメントのRFC番号を使用して。
Jennings, et. al. Informational [Page 14] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[14ページ]のRFC3325一口
Name of Header: P-Asserted-Identity
ヘッダーの名前: アイデンティティであると断言されたP
Short form: none
急に、形成してください: なし
Registrant: Cullen Jennings fluffy@cisco.com
記入者: カレンジョニングス fluffy@cisco.com
Normative description: Section 9.1 of this document
標準の記述: セクション9.1 このドキュメントについて
Name of Header: P-Preferred-Identity
ヘッダーの名前: Pはアイデンティティを好みました。
Short form: none
急に、形成してください: なし
Registrant: Cullen Jennings fluffy@cisco.com
記入者: カレンジョニングス fluffy@cisco.com
Normative description: Section 9.2 of this document
標準の記述: セクション9.2 このドキュメントについて
13.2 Registration of "id" privacy type for SIP Privacy header
13.2 SIP Privacyヘッダーのための「イド」プライバシータイプの登録
Name of privacy type: id
プライバシータイプの名前: イド
Short Description: Privacy requested for Third-Party Asserted Identity
短い記述: Third-パーティAsserted Identityのために要求されたプライバシー
Registrant: Cullen Jennings fluffy@cisco.com
記入者: カレンジョニングス fluffy@cisco.com
Normative description: Section 9.3 of this document
標準の記述: セクション9.3 このドキュメントについて
14. Acknowledgements
14. 承認
Thanks to Bill Marshall and Flemming Andreason [6], Mark Watson [5], and Jon Peterson [7] for authoring drafts which represent the bulk of the text making up this document. Thanks to many people for useful comments including Jonathan Rosenberg, Rohan Mahy and Paul Kyzivat.
このドキュメントを作るテキストの大半を表す書いている草稿をビル・マーシャル、フレミングAndreason[6]、マーク・ワトソン[5]、およびジョン・ピーターソン[7]をありがとうございます。 ジョナサン・ローゼンバーグ、Rohanマーイ、およびポールKyzivatを含む役に立つコメントを多くの人々をありがとうございます。
Normative References
引用規格
[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] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[2] ピーターソン、J.、「セッション開始プロトコル(一口)のためのプライバシーメカニズム」、RFC3323、2002年11月。
Jennings, et. al. Informational [Page 15] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[15ページ]のRFC3325一口
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[4] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
Informational References
情報の参照
[5] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[5] ワトソン、M.、「ネットワークの断言されたアイデンティティのための短期間要件」、RFC3324、2002年11月。
[6] Andreasen, F., "SIP Extensions for Network-Asserted Caller Identity and Privacy within Trusted Networks", Work in Progress.
[6] F.、「信じられたネットワークの中のネットワークによって断言された訪問者のアイデンティティとプライバシーのための一口拡大」というAndreasenは進行中で働いています。
[7] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress.
[7] ピーターソン、J.、「セッション開始プロトコル(一口)における認証されたアイデンティティ管理のための増進」が進行中で働いています。
Jennings, et. al. Informational [Page 16] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[16ページ]のRFC3325一口
Authors' Addresses
作者のアドレス
Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/3 San Jose, CA 95134 USA
カレンジョニングスシスコシステムズ170の西タスマンDrive MS: SJC-21/3カリフォルニア95134サンノゼ(米国)
Phone: +1 408 527-9132 EMail: fluffy@cisco.com
以下に電話をしてください。 +1 408 527-9132 メールしてください: fluffy@cisco.com
Jon Peterson NeuStar, Inc. 1800 Sutter Street, Suite 570 Concord, CA 94520 USA
ジョンピーターソンNeuStar, Inc.1800Sutter通り、スイート570一致、カリフォルニア94520米国
Phone: +1 925/363-8720 EMail: Jon.Peterson@NeuStar.biz
以下に電話をしてください。 +1 925/363-8720 メールしてください: Jon.Peterson@NeuStar.biz
Mark Watson Nortel Networks Maidenhead Office Park (Bray House) Westacott Way Maidenhead, Berkshire England
ワトソンノーテルネットワーク処女性オフィスパーク(ロバの鳴き声家)Westacott道が処女性、バークシャーイギリスであるとマークしてください。
Phone: +44 (0)1628-434456 EMail: mwatson@nortelnetworks.com
以下に電話をしてください。 +44 (0) 1628-434456 メールしてください: mwatson@nortelnetworks.com
Jennings, et. al. Informational [Page 17] RFC 3325 SIP Asserted Identity November 2002
etジョニングス、アル。 2002年11月にアイデンティティであると断言された情報[17ページ]のRFC3325一口
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Jennings, et. al. Informational [Page 18]
etジョニングス、アル。 情報[18ページ]
一覧
スポンサーリンク