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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Shape meter 形状メーター

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る