Network Working Group C. Jennings
Request for Comments: 3325 Cisco Systems
Category: Informational J. Peterson
NeuStar, Inc.
M. Watson
Nortel Networks
November 2002
Private Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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サーバのネットワークを有効にするセッション開始プロトコル（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
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
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).
この文書では、[1]、エンドユーザまたはエンド・システムのアイデンティティを主張するために、エンドユーザの指示を伝えるために、信頼できるSIPサーバのネットワークを可能にする、プライバシーを要求したSIPにプライベート拡張機能について説明します。これらの拡張機能を使用するには、Identity [5]をアサートネットワークのための短期要件で定義された「信頼ドメイン」の内側にのみ適用されます。こうした信頼ドメイン内のノードは、明示的に公に各当事者の身元を主張するために、プライバシーが要求されたときに信頼ドメインの外のアイデンティティを保留に関与するとそのユーザーおよびエンドシステムから信頼されています。 （それは一般的に、認証のいくつかのフォームを伴うが）ネットワークをアサートするアイデンティティを決定する手段は、この文書の範囲外です。
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]の重要な要件は、与えられた信頼ドメイン「T」内のすべてのノードの挙動は「仕様（T）」として知られている仕様の特定のセットに準拠することが知られていることです。スペック（T）は、次の動作を指定する必要があります。
2. The mechanisms used to secure the communication among nodes within the Trust Domain
2.信頼ドメイン内のノード間の通信を保護するために使用されるメカニズム
3. The mechanisms used to secure the communication between UAs and nodes within the Trust Domain
3.信頼ドメイン内のUAとノード間の通信を保護するために使用されるメカニズム
4. The manner used to determine which hosts are part of the Trust Domain
4.信頼ドメインの一部であるホストを決定するために使用される方法
5. The default privacy handling when no Privacy header field is present
5.何のプライバシーヘッダフィールドが存在しない場合、デフォルトのプライバシーの取り扱い
An example of a suitable Spec(T) is shown in Section 11.
適切な仕様（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.
アサートアイデンティティはまた、具体的アイデンティティを主張している、そして信頼ドメインは、アイデンティティを主張していることを前提としなければならない人の表示を欠いています。安全信頼ドメインのメンバーであることが知られているノードから受信したときしたがって、情報は意味があります。
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.
これらの制限にもかかわらず、上記の仮定を満たしており、このメカニズムの情報掲載を保証するために、結果としての限界を受け入れることができ便利な専門的な展開は十分にあります。例の展開は、従来の回線交換電話網エミュレート閉じたネットワークになります。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[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).
このドキュメントのための要件または参照を通じてプロキシサーバまたはプロキシ行動に信頼ドメイン（例：型B2BUA）内の他の仲介業者と同様に適用されます。
The terms Identity, Network Asserted Identity and Trust Domain in this document have meanings as defined in [5].
アイデンティティ、ネットワークは、この文書でIDと信頼ドメインをアサート用語は、[5]で定義されるような意味を持ちます。
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.
これらのネットワークは、特定の従来の電話サービスをサポートし、基本的な規制や公共の安全要件を満たす必要があります。これらは、アイデンティティの配達サービスを呼び出すアイデンティティ配信ブロッキングを呼び出し、通話の発信元を追跡する機能が含まれています。ベースラインSIPは、独立して、これらのサービスの各々を支援することができるが、特定の組み合わせは、この文書で説明する拡張なしにサポートすることはできません。彼らは、発信者の身元を発見するために、いくつかの他の手段に頼らない限り、例えば、プライバシーを維持したいと考え、その結果、FromヘッダーフィールドSIPでの限られた情報を提供し、発信者は、コールの受信者に識別されません。発信ユーザエージェントでアイデンティティ情報をマスキングすることは公共での作業から、例えば、トレースを呼び出し、特定のサービスを防ぐことができます交換電話網（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.
このドキュメントは、ネットワークがで要件に基づいて、非常に限られた、シンプルなメカニズムを使用してIDサービスをアサート提供しようとする[5]。この作品は、前回の試行から派生し、[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アドレスは、自身が個人情報を公開してもよいです。 SIP環境でプライバシーを提供するための汎用機構は[2]に記載されています。この文書では、ネットワークの問題にプライバシーメカニズムは、アイデンティティを主張していることに適用されます。
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-アサート-アイデンティティ： "カレン・ジェニングス" <一口：fluffy@cisco.com>
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-Asserted-Identityヘッダフィールドを挿入し、他の信頼できるプロキシに転送します。利用者がこの情報を非公開にすることを要求した場合、それは信頼していないことをプロキシサーバーまたはUAにメッセージを転送しようとしているプロキシは、すべてのP-Asserted-Identityヘッダフィールド値を削除する必要があります。第7節で説明したように、ユーザーは、プライバシーのこのタイプを要求することができます。
The formal syntax for the P-Asserted-Identity header is presented in Section 9.
P-Asserted-Identityヘッダのための正式な構文は、セクション9に示されています。
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.
信頼ドメイン内のプロキシは、それが信頼するノード、またはそれは信頼していないノードからメッセージを受け取ることができます。プロキシは、それが信頼していないノードからメッセージを受信し、P-Asserted-Identityヘッダフィールドを追加したい場合、プロキシは、メッセージの発信者を認証し、Pを挿入するには、この認証に起因するアイデンティティを使用しなければなりませんメッセージに-Asserted-Identityヘッダフィールド。
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-Asserted-Identityヘッダフィールド内の情報を使用することができます。
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-Asserted-Identityヘッダフィールドが存在した場合、プロキシは、多くても1つのSIPを含むものを追加したり、URIをSIPS、および最大で1つのTEL URL MAY。プロキシは、それが信頼していないとSIPが含まれているか、URIをSIPS本P-Asserted-Identityヘッダがあること要素からメッセージを受信した場合、プロキシは、SIPを交換するか、SIPS URIを単一のSIPまたはURIをSIPSしなければならない、またはこのヘッダフィールドを削除します。プロキシは、それが信頼しないこと要素からメッセージを受信し、TEL URIを含むP-Asserted-Identityヘッダが存在した場合に同様に、プロキシは単一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 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.
プロキシが別のノードにメッセージを転送するとき、それは最初に、そのノードを信頼するかどうかを決定しなければなりません。それはノードを信頼している場合、プロキシはそれ自体を生成し、またはそれが信頼できるソースから受信した任意のP-Asserted-Identityヘッダフィールドを削除しません。それは要素を信頼していない場合、プロキシは、ID情報をアサート要求したユーザを非公開にするかどうかを判断するために（存在する場合）プライバシーヘッダフィールドを調べる必要があります。
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-Preferred-Identityヘッダフィールドは、プロキシは、それが信頼しないエンティティから受信したメッセージに存在する場合、プロキシは、アサートされるべきで認証されたユーザのための複数の有効なアイデンティティのどの示唆するヒントとしてこの情報を使用することができます。このようなヒントは、そのユーザのプロキシに知られている任意の有効なIDに対応しない場合、プロキシは、それ自身の構造のP-Asserted-Identityヘッダを追加することができ、またはそれは（禁止403と、など）の要求を拒否することができます。プロキシは、任意のメッセージを転送し、そこからユーザ提供P-Preferred-Identityヘッダを削除する必要があります。
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-Preferred-Identityヘッダフィールドを送ります。ユーザエージェントは、ユーザエージェントによって信頼されているプロキシに直接送信されていないメッセージにP-Preferred-Identityヘッダフィールドを移入してはいけません。信頼ドメインの外部のノードにP-Preferred-Identityヘッダフィールドを含むメッセージを送信するユーザエージェントし、次いで示唆アイデンティティ、プライバシーのために負の波及効果を有する可能性があり、ネットワークによって適切に管理されない場合があります。
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-Asserted-Identityヘッダフィールドの削除を要求することを望む締約国は、プライバシーヘッダフィールドには、この文書で定義された「ID」のプライバシートークンを追加することができます。プライバシーヘッダフィールドは、[6]で定義されています。このトークンがある場合は、プロキシは信頼されていない要素にメッセージを転送する前に、すべてのP-Asserted-Identityヘッダフィールドを削除する必要があります。プライバシーヘッダフィールドの値が「なし」に設定されている場合、プロキシはP-Asserted-Identityヘッダフィールドを削除してはなりません。
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.
プロキシが信頼されていない要素に要求を転送されないプライバシーヘッダフィールドが存在しない場合、プロキシは、P-Asserted-Identityヘッダフィールドを含むか、またはそれを除去することができます。この決定は、信頼ドメインのポリシーの問題であり、仕様（T）で指定する必要があります。ローカルのプライバシーポリシーはそれを防ぐない限り、除去がアサート・アイデンティティに基づいてサービスが失敗する可能性がありますので、P-Asserted-Identityヘッダフィールドは、削除されないことをお勧めします。
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.
しかし、信頼ドメインのすべてのユーザーが適切なプライバシーサービスへのアクセスを持っていない限り、P-アサート - アイデンティティの転送は、ユーザーが要求していないと防ぐことができない情報の開示をもたらすことができることに留意すべきです。この文書で説明したように、すべてのユーザーがプライバシーサービスへのアクセス権を持っていることが強く推奨します。
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].
「ID」プライバシーヘッダ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-Asserted-Identityヘッダフィールド値はメッセージ中に存在し、プライバシーのP-Asserted-Identityヘッダフィールドが要求され、その後、ヘッダフィールド値のすべてのインスタンスがあるエンティティに要求を転送する前に除去しなければならない場合信頼されていません。
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-Asserted-Identityヘッダフィールドの値をレンダリングします。これは、信頼ドメインが提供するアイデンティティが特権、またはリクエストの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.
ユーザエージェントサーバはそれが信頼していないことを前の要素からメッセージを受信した場合しかし、それはどのような方法でP-Asserted-Identityヘッダフィールドを使用してはなりません。
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-Asserted-Identityヘッダフィールドを含むメッセージを受信し、そこから信頼ドメインの一部である場合、それは自由に値を使用することができるが、それは一部ではない任意の要素に情報を転送しないことを保証しなければなりません信頼ドメインの、利用者がID情報を非公開にすることアサートその要求した場合。
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-Asserted-Identityヘッダフィールドを含むメッセージを受信し、そこから信頼ドメインの一部ではない場合、それは、この情報は非公開にする必要がないと仮定することができます。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [4].
以下の構文仕様は、RFC-2234に記載されているように拡張バッカスナウア記法（BNF）を使用する[4]。
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-Asserted-Identityヘッダフィールドは、それが認証によって確認されたように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-Asserted-Identityヘッダフィールドの値は、厳密に1つの名前-ADDRまたはADDR仕様で構成されなければなりません。 1または2 P-アサート・アイデンティティ値があるかもしれません。一つの値が存在する場合、それは一口、一口、またはTEL URIでなければなりません。二つの値がある場合、一つの値は、SIPであるか、またはURIをSIPおよび他のTEL URIでなければなりませんしなければなりません。これは、プロキシが（および意志）を追加し、このヘッダフィールドを削除することができますことは注目に値します。
This document adds the following entry to Table 2 of [1]:
この文書では、[1]の表2に次のエントリを追加します。
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-Asserted-Identity adr - o - o o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o - - -
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-Preferred-Identityヘッダフィールドは、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-Preferred-Identityヘッダフィールドの値は、厳密に1つの名前-ADDRまたはADDR仕様で構成されなければなりません。 1または2つのP-プリファード・アイデンティティ値があるかもしれません。一つの値が存在する場合、それは一口、一口、またはTEL URIでなければなりません。二つの値がある場合、一つの値は、SIPであるか、またはURIをSIPおよび他のTEL URIでなければなりませんしなければなりません。これは、プロキシが（とします）、このヘッダフィールドを削除することができますことは注目に値します。
This document adds the following entry to Table 2 of [1]:
この文書では、[1]の表2に次のエントリを追加します。
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-Preferred-Identity adr - o - o o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o - - -
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.
この仕様は、[2]で定義されたプライバシー・ヘッダに新しいプライバシータイプ（「PRIV-値」）を追加します。プライバシーヘッダフィールドに、このプライバシータイプの存在は、ユーザーのネットワークをしたいと思いますが、ユーザーが認証されて信頼ドメイン外のSIPエンティティに対する非公開にすることがアイデンティティをアサートすることを示しています。プライバシーの複数の種類を要求しているユーザは、そのプライバシーヘッダフィールド値に要求されたプライバシーのタイプのすべてを含まなければならないことに注意してください。
priv-value = "id"
PRIV-値= "ID"
Example:
例：
Privacy: id
プライバシー：ID
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ダイジェスト認証から発見アイデンティティからP-Asserted-Identityヘッダフィールドを生成します。それは、信頼できるゲートウェイに転送し、信頼できるプロキシにこの情報を転送します。これらの実施例は認証されたアイデンティティの問題に関連しただけのヘッダーを示す部分的なSIPメッセージからなることに留意されたいです。
* F1 useragent.cisco.com -> proxy.cisco.com
* F1 useragent.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
SIP / 2.0 / TCP useragent.cisco.com;ブランチ= z9hG4bK-123：+14085551212@cisco.com SIP / 2.0経由：SIPのINVITE <一口：+14085551212@cisco.com>から： "匿名" <一口： anonymous@anonymous.invalid>;タグは= 9802748のCall-ID：245780247857024504のCSeq：1最大前方にINVITE：70プライバシー：ID
* 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"
SIP / 2.0 407プロキシ認証経由：SIP / 2.0 / TCP useragent.cisco.com;ブランチ= z9hG4bK-123：<SIP：+14085551212@cisco.com>;タグ= 123456から： "匿名" <一口：匿名@ anonymous.invalid>;タグは= 9802748のCall-ID：245780247857024504のCSeq：1プロキシ認証をINVITE：....レルム= "sip.cisco.com"
* F3 useragent.cisco.com -> proxy.cisco.com
*効果的なOsrzinh.sescu.kom - > Broxa.sescu.kom
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"
SIP / 2.0 / TCP useragent.cisco.com;ブランチ= z9hG4bK-124：+14085551212@cisco.com SIP / 2.0経由：SIPのINVITE <一口：+14085551212@cisco.com>から： "匿名" <一口： anonymous@anonymous.invalid>;タグ= 9802748のCall-ID：245780247857024504のCSeq：2 INVITE最大フォワード：70プライバシー：IDプロキシ許可：....レルム= "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 SIP：+14085551212@proxy.pstn.net SIP / 2.0経由：SIP / 2.0 / TCP useragent.cisco.com;分岐= z9hG4bK-124を介し：SIP / 2.0 / TCP proxy.cisco.com;分岐= z9hG4bK-ABC <一口：+14085551212@cisco.com>から： "匿名" <一口：anonymous@anonymous.invalid>へ;タグは= 9802748コールID：245780247857024504のCSeq：2マックス-前方にINVITE：69 P-アサート - アイデンティティ： "カレンジェニングス" <一口：fluffy@cisco.com> P-アサート - アイデンティティ：TEL：+14085264000プライバシー：ID
* 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 SIP：+14085551212@gw.pstn.net SIP / 2.0経由：SIP / 2.0 / TCP useragent.cisco.com;分岐= z9hG4bK-124を介し：SIP / 2.0 / TCP proxy.cisco.com;分岐= z9hG4bK-ABCビア：SIP / 2.0 / TCPのproxy.pstn.net;ブランチ= z9hG4bK-A1B2へ：<SIP：+14085551212@cisco.com>から： "匿名" <一口：anonymous@anonymous.invalid>;タグ= 9802748 Call- ID：245780247857024504のCSeq：2 INVITE最大フォワード：68 P-アサート・アイデンティティ： "カレンジェニングス" <SIP：fluffy@cisco.com> P-アサート・アイデンティティ：TEL：14085264000プライバシー：ID
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.
SIPダイジェストでこれを認証する最初のプロキシにfluffy@cisco.com：この例では、ユーザエージェントは、それはそれはアイデンティティの一口を好む示しINVITEを送信します。最初のプロキシは、P-Asserted-Identityヘッダフィールドを作成し、信頼できるプロキシ（outbound.cisco.com）に転送します。次のプロキシは、P-Asserted-Identityヘッダフィールドと、それは信頼していないbiloxi.comのプロキシサーバーへの以降、この要求を転送する前に、プライバシーの要求を削除します。
* F1 useragent.cisco.com -> proxy.cisco.com
* F1 useragent.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>
SIP INVITE：bob@biloxi.comをSIP / 2.0経由：SIP / 2.0 / TCP useragent.cisco.com;ブランチ= z9hG4bK-A111へ：<SIP：bob@biloxi.com>から： "匿名" <一口：匿名@ anonymous.invalid>;タグは= 9802748のCall-ID：245780247857024504のCSeq：最大前方にINVITE 1：70プライバシー：IDのP-好ましいアイデンティティ： "カレンジェニングス" <SIP：fluffy@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-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 407プロキシ認証経由：SIP / 2.0 / TCP useragent.cisco.com;ブランチ= z9hG4bK-A111へ：<SIP：bob@biloxi.com>。タグ= 123456から： "匿名" <SIP：anonymous@anonymous.invalid>;タグ= 9802748のCall-ID：プロキシ認証をINVITE 1：245780247857024504のCSeq ....レルム= "cisco.com"
* F3 useragent.cisco.com -> proxy.cisco.com
*効果的なOsrzinh.sescu.kom - > Broxa.sescu.kom
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"
SIP INVITE：bob@biloxi.comをSIP / 2.0経由：SIP / 2.0 / TCP useragent.cisco.com;ブランチ= z9hG4bK-A123へ：<SIP：bob@biloxi.com>から： "匿名" <一口：匿名@ anonymous.invalid>;タグ= 9802748のCall-ID：マックス-前方にINVITE：2：245780247857024504のCSeq 70プライバシー：ID P-プリファード・アイデンティティ： "カレン・ジェニングス" <一口：fluffy@cisco.com>プロキシ認証.. ..分野= "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
SIPのINVITE：ビロクシーSIP / 2.0 @ボブ経由：SIP / 2.0 / TCP useragent.cisco.com;ブランチ= z9hG4bK-A123経由：SIP / 2.0 / TCP proxy.cisco.com;ブランチ= z9hG4bK-B234へ：<SIP： bob@biloxi.com>から： "匿名" <一口：anonymous@anonymous.invalid>;タグ= 9802748のCall-ID：245780247857024504のCSeq：マックス-前方にINVITE 2：69 P-アサート - アイデンティティ： "カレン・ジェニングス" <一口：fluffy@vovida.org>プライバシー：ID
* 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
SIPのINVITE：ビロクシーSIP / 2.0 @ボブ経由：SIP / 2.0 / TCP useragent.cisco.com;ブランチ= z9hG4bK-A123経由：SIP / 2.0 / TCP proxy.cisco.com;枝は= z9hG4bK-B234経由：SIP / 2.0 / TCP outbound.cisco.com;ブランチ= z9hG4bK-c345へ：<SIP：bob@biloxi.com>から： "匿名" <一口：anonymous@anonymous.invalid>;タグ= 9802748のCall-ID：245780247857024504のCSeq：2マックス・前方にINVITE：68プライバシー：ID
* 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
SIPのINVITE：bob@bobster.biloxi.com SIP / 2.0経由：SIP / 2.0 / TCP useragent.cisco.com;ブランチ= z9hG4bK-A123経由：SIP / 2.0 / TCP proxy.cisco.com;ブランチ= z9hG4bK-B234経由：<bob@biloxi.com SIP：>：「匿名：SIP / 2.0 / TCP outbound.cisco.com;：;枝は= z9hG4bK-c345経由ブランチ= z9hG4bK-d456にSIP / 2.0 / TCP proxy.biloxi.com 「<一口：anonymous@anonymous.invalid>;タグは= 9802748コールID：245780247857024504のCSeq：2マックス-前方にINVITE：67プライバシー：ID
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)'.
本書で説明されたメカニズムの完全性は、信頼ドメイン内のすべてのノードが所定の方法で動作します（コンフィギュレーションを介して）知る一つのノードに依存しています。これは、明確に定義される所定の動作を必要とし、信頼ドメイン内のすべてのノードのために準拠します。信頼ドメインT内のすべてのノードが順守しなければならないように設定仕様が「仕様（T）」と呼ばれます。
The remainder of this section presents an example Spec(T), which is not normative in any way.
このセクションの残りの部分は、どのような方法で規範的でない例仕様（T）を、提示します。
The following specifications MUST be supported:
以下の仕様をサポートしなければなりません。
Users MUST be authenticated using SIP Digest Authentication.
ユーザーは、SIPダイジェスト認証を使用して認証されなければなりません。
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.
信頼ドメイン内および信頼ドメイン内のUAとノード間のノード間の接続は、RSA_WITH_AES_128_CBC_SHA1の暗号スイートを使用してTLSを使用しなければなりません。信頼ドメイン内のノード間の相互認証を実行しなければなりませんし、機密性が交渉しなければなりません。
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.
この契約で指定された信頼ドメインA）examplerootca.orgによって署名された有効な証明書を保有宿主から成ります。 B）その次のsubjectAltNameドメイン名のいずれかで終了：trusted.div1.carrier-a.net、trusted.div2.carrier-a.net、sip.carrier-b.com。およびc）そのドメイン名は、証明書内のsubjectAltName内のホスト名に対応しています。
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.
信頼ドメイン内の要素は、従って、プライバシーヘッダが存在しない場合は、ユーザが任意のプライバシーを要求していないことを示すと仮定することができる「ID」プライバシーサービスをサポートしなければなりません。何のプライバシーヘッダフィールドがリクエストに存在しない場合は、この信頼ドメイン内の要素には、プライバシーが要求されていないかのように行動しなければなりません。
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におけるアイデンティティとプライバシーの問題の部分的な考慮事項です。例えば、これらのメカニズムは、エンドユーザーが確実エンドツーエンド信頼できるサービスプロバイダことなく識別情報を共有することが可能ないかなる手段を提供しません。ユーザーが「プライベート」として指定アイデンティティ情報が信頼ドメインに参加する任意の仲介によって検査することができます。この情報は信頼の連鎖で最も弱いリンクと同じくらい信頼性がある推移的な信頼によって確保されています。
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-Asserted-Identityヘッダフィールドにその当事者の同一性を有する任意の宛先にメッセージを送信すると、エンティティは、そのID情報の機密性と完全性を保護するための盗聴や傍受から身元情報を保護するための予防措置を講じなければなりません。適切な暗号スイートを有するこのようなTLSまたはIPSecなどのトランスポートまたはネットワーク層ホップバイホップセキュリティメカニズムの使用は、この要件を満たすことができます。
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-プリファード・アイデンティティ」。交通エリアのポリシーによって推奨されるように、これらのヘッダは参照としてこの文書のRFC番号を使用して、SIPヘッダレジストリにIANAによって登録されています。
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
Name of privacy type: id
プライバシータイプの名称：ID
Short Description: Privacy requested for Third-Party Asserted Identity
短い説明：サードパーティのために要求された個人情報は、アイデンティティをアサート
Registrant: Cullen Jennings fluffy@cisco.com
登録者：カレン・ジェニングスfluffy@cisco.com
Normative description: Section 9.3 of this document
規範的な説明：このドキュメントのセクション9.3
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]のおかげ。ジョナサン・ローゼンバーグ、ローハンマーイとポール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.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[2]ピーターソン、J.、RFC 3323 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"、2002年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[4]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
Informational References
情報の参照
[5] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[5]ワトソン、M.は、2002年11月、RFC 3324、 "ネットワークのための短期要件は、アイデンティティをアサート"。
[6] Andreasen, F., "SIP Extensions for Network-Asserted Caller Identity and Privacy within Trusted Networks", Work in Progress.
[6]アンドレア、F.、「信頼できるネットワーク内のSIPネットワーク-アサート発信者アイデンティティのための拡張機能とプライバシー」、進行中の作業。
[7] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress.
[7]ピーターソン、J.、 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理の強化"、ProgressのWork。
Authors' Addresses
著者のアドレス
Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/3 San Jose, CA 95134 USA
カレンジェニングスシスコシステムズ170西タスマンドライブMS：SJC-3分の21サンノゼ、CA 95134 USA
Phone: +1 408 527-9132 EMail: fluffy@cisco.com
電話：+1 408 527-9132 Eメール：fluffy@cisco.com
Jon Peterson NeuStar, Inc. 1800 Sutter Street, Suite 570 Concord, CA 94520 USA
ジョンピーターソンNeuStar、Inc.の1800サターストリート、スイート570コンコード、CA 94520 USA
Phone: +1 925/363-8720 EMail: Jon.Peterson@NeuStar.biz
電話：+1 925/363から8720 Eメール：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 Eメール：mwatson@nortelnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。