Internet Engineering Task Force (IETF) J. Elwell
Request for Comments: 5876 Siemens Enterprise Communications
Updates: 3325 April 2010
Category: Informational
ISSN: 2070-1721
Updates to Asserted Identity in the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）にアイデンティティをアサートするアップデート
Abstract
抽象
The Session Initiation Protocol (SIP) has a mechanism for conveying the identity of the originator of a request by means of the P-Asserted-Identity and P-Preferred-Identity header fields. These header fields are specified for use in requests using a number of SIP methods, in particular the INVITE method. However, RFC 3325 does not specify the insertion of the P-Asserted-Identity header field by a trusted User Agent Client (UAC), does not specify the use of P-Asserted-Identity and P-Preferred-Identity header fields with certain SIP methods such as UPDATE, REGISTER, MESSAGE, and PUBLISH, and does not specify how to handle an unexpected number of URIs or unexpected URI schemes in these header fields. This document extends RFC 3325 to cover these situations.
セッション開始プロトコル（SIP）は、P-アサート・アイデンティティ及びP-Preferred-Identityヘッダフィールドを用いて要求の発信元のアイデンティティを搬送するための機構を有しています。これらのヘッダーフィールドは、特定の方法をINVITE、SIPメソッドの数を使用して要求に使用するために指定されています。しかし、RFC 3325は、信頼できるユーザエージェントクライアント（UAC）によってP-Asserted-Identityヘッダフィールドの挿入を指定していない、P-アサート - アイデンティティの使用を指定して、特定のSIPとP-Preferred-Identityヘッダフィールドありません例えばUPDATEなどの方法、REGISTERメッセージ、および公開、及びこれらのヘッダフィールド内のURIまたは予期しないURIスキームの予期しない数の処理方法を指定しません。この文書では、これらの状況をカバーするためにRFC 3325を拡張します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5876.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5876で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Discussion ......................................................4
3.1. Inclusion of P-Asserted-Identity by a UAC ..................4
3.2. Inclusion of P-Asserted-Identity in Any Request ............5
3.3. Dialog Implications ........................................6
4. Behaviour .......................................................6
4.1. UAC Behaviour ..............................................7
4.2. Proxy Behaviour ............................................7
4.3. Registrar Behaviour ........................................7
4.4. UAS Behaviour ..............................................8
4.5. General Handling ...........................................8
5. Security Considerations .........................................9
6. Acknowledgements ...............................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................11
The Session Initiation Protocol (SIP) is specified in RFC 3261 [RFC3261]. RFC 3325 [RFC3325] specifies a mechanism for conveying the asserted identity of the originator of a SIP request within a Trust Domain. This is achieved by means of the P-Asserted-Identity header field, which is specified for use in requests using a number of SIP methods, in particular the INVITE method. In addition, the P-Preferred-Identity header field can be used to indicate a preference for which identity should be asserted when there is a choice.
セッション開始プロトコル（SIP）は、RFC 3261 [RFC3261]で指定されています。 RFC 3325 [RFC3325]は信頼ドメイン内のSIPリクエストの発信元のアサートされたアイデンティティを搬送するための機構を指定します。これは、特定の方法をINVITE、SIPメソッドの数を使用して要求に使用するために指定されているP-Asserted-Identityヘッダフィールドの手段によって達成されます。また、P-Preferred-Identityヘッダフィールドは、選択が存在する場合にアイデンティティがアサートされるべき対象の優先度を示すために使用することができます。
RFC 3325 does not specify the insertion of the P-Asserted-Identity header field by a User Agent Client (UAC) in the same Trust Domain as the first proxy. Also, RFC 3325 does not specify the use of the P-Asserted-Identity and P-Preferred-Identity header fields with certain SIP methods such as UPDATE [RFC3311], REGISTER, MESSAGE [RFC3428], and PUBLISH [RFC3903]. This document extends RFC 3325 by allowing inclusion of the P-Asserted-Identity header field by a UAC in the same Trust Domain as the first proxy and allowing use of P-Asserted-Identity and P-Preferred-Identity header fields in any request except ACK and CANCEL. The reason for these two exceptions is that ACK and CANCEL requests cannot be challenged for digest authentication.
RFC 3325は、最初のプロキシと同じ信頼ドメイン内のユーザエージェントクライアント（UAC）によってP-Asserted-Identityヘッダフィールドの挿入を指定していません。また、RFC 3325は、UPDATE [RFC3311]、REGISTERメッセージ[RFC3428]などの特定のSIPメソッドとP-アサート・アイデンティティ及びP-Preferred-Identityヘッダフィールドの使用を指定し、[RFC3903]を公開していません。この文書では、最初のプロキシとして同じ信頼ドメインにUACによってP-Asserted-Identityヘッダフィールドを含めることを可能にし、以外の任意の要求にP-アサート・アイデンティティ及びP-Preferred-Identityヘッダフィールドの使用を可能にすることによって、RFC 3325を拡張しますACKとCANCEL。これらの2つの例外の理由は、ACKとCANCELリクエストは、ダイジェスト認証に挑戦することができないということです。
RFC 3325 allows the P-Asserted-Identity and P-Preferred-Identity header fields each to contain at most two URIs, where one is a SIP or SIPS URI [RFC3261] and the other is a TEL URI [RFC3966]. This may be unduly restrictive in the future, for example, if there is a need to allow other URI schemes, if there is a need to allow both a SIP and a SIPS URI, or if there is a need to allow more than one URI with the same scheme (e.g., a SIP URI based on a telephone number and a SIP URI that is not based on a telephone number). This document therefore provides forwards compatibility by mandating tolerance to the receipt of unexpected URIs.
RFC 3325は、1つのSIP URIであるか、または[RFC3261]をSIPおよび他のTEL URI [RFC3966]は、最大2つのURI、で含有するP-アサート・アイデンティティ及びP-Preferred-Identityヘッダフィールドそれぞれを可能にします。他のURIスキームを可能にする必要がある場合、SIPとSIPS URIの両方を可能にする必要がある場合、これは、例えば、将来的に過度に制限的であってもよく、または複数のURIを許可する必要がある場合同じスキーム（例えば、電話番号に基づいていない電話番号に基づいて、SIP URIとSIP URI）。この文書では、したがって、予期しないURIの領収書に対する耐性を義務付けることにより、前方互換性を提供します。
This document does not alter the fact that the asserted identity mechanism has limited applicability, i.e., within a Trust Domain. For general applicability, including operation outside a Trust Domain (e.g., over the public Internet) or between different Trust Domains, a different mechanism is needed. RFC 4474 [RFC4474] specifies the Identity header field, in conjunction with the From header field, to provide authenticated identity in such circumstances. RFC 4916 [RFC4916] specifies the use of RFC 4474 in mid-dialog requests, in particular, in requests in the reverse direction to the dialog-forming request as a means of providing authenticated connected identity.
この文書では、アサートされたアイデンティティメカニズムは、信頼ドメイン内、すなわち、適用可能性を制限しているという事実を変えるものではありません。 （公共のインターネット上で、例えば、）または異なる信頼ドメイン間の信頼ドメインの外部操作を含む一般的な適用については、別のメカニズムが必要です。 RFC 4474 [RFC4474]はこのような状況で認証IDを提供するために、ヘッダのフィールドに関連して、アイデンティティ・ヘッダ・フィールドを指定します。 RFC 4916 [RFC4916]は、認証接続IDを提供する手段としてダイアログ形成要求に逆方向の要求で、特に、中間ダイアログ要求にRFC 4474の使用を指定します。
RFC 3325 is unclear on the use of P-Asserted-Identity in responses. In contrast to requests, there is no means in SIP to challenge a User Agent Server (UAS) to provide SIP digest authentication in a response. As a result, there is currently no standardised mechanism whereby a proxy can authenticate a UAS. Since authenticating the source of a message is a prerequisite for asserting an identity, this document does not specify the use of the P-Asserted-Identity header field in responses. This may be the subject of a future update to RFC 3325. Also, this document does not specify the use of the P-Preferred-Identity header field in responses, as this would serve no purpose in the absence of the ability for a proxy to insert the P-Asserted-Identity header field.
RFC 3325は、応答のP-アサート・アイデンティティの使用については不明です。リクエストとは対照的に、応答でSIPダイジェスト認証を提供するために、ユーザエージェントサーバ（UAS）を挑戦するSIPには手段がありません。その結果、プロキシがUASを認証することができる標準化機構は現在存在しません。メッセージの送信元を認証するアイデンティティをアサートするための前提条件であるので、この文書は、応答におけるP-Asserted-Identityヘッダフィールドの使用を指定していません。これは、このに対してプロキシの能力の非存在下で何の目的を果たすないだろうとしても、この文書は、応答のP-Preferred-Identityヘッダフィールドの使用を指定していないRFC 3325.に将来のアップデートの対象とすることができますP-Asserted-Identityヘッダフィールドを挿入します。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document uses the concepts of Trust Domain and Spec(T), as specified in section 2.3 of RFC 3324 [RFC3324].
RFC 3324 [RFC3324]のセクション2.3で指定されるように、このドキュメントは、信頼ドメイン及び仕様（T）の概念を使用します。
RFC 3325 does not include procedures for a UAC to include the P-Asserted-Identity header field in a request. This can be meaningful if the UAC is in the same Trust Domain as the first downstream SIP entity. Examples of types of UACs that are often suitable for inclusion in a Trust Domain are:
RFC 3325は、要求にP-Asserted-Identityヘッダフィールドを含むようにUACの手順を含んでいません。 UACは、第一下流SIPエンティティと同じ信頼ドメイン内にある場合、これは有意義であることができます。しばしば信頼ドメインに含めるのに適している求めるUACのタイプの例は：
o Public Switched Telephone Network (PSTN) gateways;
O公衆交換電話網（PSTN）ゲートウェイを交換しました。
o media servers;
お めぢあ せｒゔぇｒｓ；
o application servers (or Back-to-Back User Agents (B2BUAs)) that act as URI list servers [RFC5363];
Oアプリケーションサーバ（またはバックツーバックユーザエージェント（型B2BUA））URIリストサーバ[RFC5363]として動作し、
o application servers (or B2BUAs) that perform third party call control.
サードパーティの呼制御を行うOアプリケーションサーバ（または型B2BUA）。
In the particular case of a PSTN gateway, the PSTN gateway might be able to assert an identity received from the PSTN, the proxy itself having no means to authenticate such an identity. Likewise, in the case of certain application server or B2BUA arrangements, the application server or B2BUA may be in a position to assert an identity of a user on the other side of that application server or B2BUA.
PSTNゲートウェイの特定の場合には、PSTNゲートウェイは、PSTNから受信した識別、そのようなアイデンティティを認証する手段を持たないプロキシ自体をアサートすることができるかもしれません。同様に、特定のアプリケーションサーバまたはB2BUA構成の場合には、アプリケーションサーバまたはB2BUAは、アプリケーションサーバーまたはB2BUAの他方の側のユーザのアイデンティティをアサートする位置にあってもよいです。
In accordance with RFC 3325, nodes within a Trust Domain must behave in accordance with a Spec(T), and this principle needs to be applied between a UAC and its proxy as part of the condition to consider the UAC to be within the same Trust Domain. The normal proxy procedures of RFC 3325 ensure that the header field is removed or replaced if the first proxy considers the UAC to be outside the Trust Domain.
RFC 3325によれば、信頼ドメイン内のノードは、仕様（T）に応じて動作する必要があり、この原理は同じトラスト内にあるようにUACを検討する条件の一部として、UACとプロキシとの間に印加される必要がありますドメイン。 RFC 3325の通常のプロキシ・プロシージャ第プロキシがUACは、信頼ドメイン外にあると考えるならば、ヘッダフィールドを削除または置換されていることを確認。
This update to RFC 3325 clarifies that a UAC may include a P-Asserted-Identity header field in a request in certain circumstances.
RFC 3325にこの更新は、UACは、特定の状況における要求にP-Asserted-Identityヘッダフィールドを含むことができることを明確にしています。
There are several use cases that would benefit from the use of the P-Asserted-Identity header field in an UPDATE request. These use cases apply within a Trust Domain where the use of asserted identity is appropriate (see RFC 3325).
UPDATE要求でP-Asserted-Identityヘッダフィールドの使用から利益を得るであろういくつかのユースケースがあります。これらのユースケースは、（RFC 3325を参照）がアサートアイデンティティの使用が適切である信頼ドメイン内適用されます。
In one example, an established call passes through a gateway to the PSTN. The gateway becomes aware that the remote party in the PSTN has changed, e.g., due to call transfer. By including the P-Asserted-Identity header field in an UPDATE request, the gateway can convey the identity of the new remote party to the peer SIP User Agent (UA).
一例では、確立された呼はPSTNへのゲートウェイを通過します。ゲートウェイは、PSTNにおける相手が転送を呼び出すことにより、例えば、変更されたことを知るようになります。更新要求にP-Asserted-Identityヘッダフィールドを含めることで、ゲートウェイは、ピアSIPユーザエージェント（UA）に新しい相手のIDを伝えることができます。
Note that the (re-)INVITE method could be used in this situation. However, this forces an offer-answer exchange, which typically is not required in this situation. Also, it involves three messages rather than two.
（再）INVITEメソッドは、このような状況で使用することができることに注意してください。しかし、これは一般的に、このような状況で必要とされていないオファーアンサー交換を、強制的に。また、3つのメッセージではなく、2を必要とします。
In another example, a B2BUA that provides third party call control (3PCC) [RFC3725] wishes to join two calls together, one of which is still waiting to be answered and potentially is forked to different UAs. At this point in time, it is not possible to trigger the normal offer-answer exchange between the two joined parties, because of the mismatch between a single dialog on the one side and potentially multiple early dialogs on the other side, so this action must wait until one of the called UAs answers. However, it would be useful to give an early indication to each user concerned of the identity of the user to which they will become connected when the call is answered. In other words, it would provide the new calling UA with the identity of the new called user and provide the new called UA(s) with the identity of the new calling user. This can be achieved by the B2BUA sending an UPDATE request with a P-Asserted-Identity header field on the dialogs concerned.
別の例では、第三者呼制御（3PCC）を提供B2BUA [RFC3725]は2つのコールに参加することを希望する、のいずれかは、まだ答えすると、潜在的に別のUAに二股される待機しています。この時点で、ために片側に単一のダイアログと反対側にある潜在的に複数の早期ダイアログの間のミスマッチのため、2つの参加当事者間の正常なオファーアンサー交換をトリガすることはできませんので、このアクションが必要呼ばれるのUAの答えの1まで待ちます。しかし、呼が応答されたとき、彼らが接続になりますするユーザーのIDを懸念し、各ユーザへの早期指示を与えるために有用であろう。言い換えれば、それは新しいと呼ばれるユーザーのIDと新しい呼び出しUAを提供するだろうし、新しいコール・ユーザーのIDと新しいと呼ばれるUA（複数可）を提供しています。これは、当該ダイアログ上でP-Asserted-Identityヘッダフィールドで更新要求を送信B2BUAによって達成することができます。
Within a Trust Domain, a P-Asserted-Identity header field could advantageously be used in a REGISTER request between an edge proxy that has authenticated the source of the request and the registrar.
信頼ドメイン内で、P-Asserted-Identityヘッダフィールドは、有利には、要求およびレジストラのソースを認証したエッジプロキシとの間のREGISTERリクエストで使用することができます。
Within a Trust Domain, a P-Asserted-Identity header field could advantageously be used in a MESSAGE request to assert the source of a page-mode instant message. This would complement its use in an INVITE request to assert the source of an instant-message session or any other form of session. Similarly, between a UAC and first proxy that are not within the same Trust Domain, a P-Preferred-Identity header field could be used in a MESSAGE request to express a preference when the user has several identities.
信頼ドメイン内で、P-Asserted-Identityヘッダフィールドは、有利にはページモードインスタントメッセージのソースをアサートするMESSAGE要求で使用することができます。これは、インスタント・メッセージ・セッションまたはセッションの任意の他の形態のソースをアサートするINVITE要求におけるその使用を補完することになります。同様に、同一の信頼ドメイン内にないUACと最初のプロキシとの間で、P-Preferred-Identityヘッダフィールドは、ユーザが複数のIDを有する場合に嗜好を表現するMESSAGE要求で使用することができます。
Within a Trust Domain, a P-Asserted-Identity header field could advantageously be used in a PUBLISH request to assert the source of published state information. This would complement its use in SUBSCRIBE and NOTIFY requests. Similarly, between a UAC and first proxy that are not within the same Trust Domain, a P-Preferred-Identity header field could be used in a PUBLISH request to express a preference when the user has several identities.
信頼ドメイン内で、P-Asserted-Identityヘッダフィールドは、有利に公開された状態情報のソースをアサートするPUBLISHリクエストで使用することができます。これは、SUBSCRIBEとNOTIFYリクエストでその使用を補完します。同様に、同一の信頼ドメイン内にないUACと最初のプロキシとの間で、P-Preferred-Identityヘッダフィールドは、ユーザが複数のIDを持つ嗜好を表現するPUBLISHリクエストで使用することができます。
Thus, there are several examples where P-Asserted-Identity could be used in requests with methods for which there is no provision in RFC 3325. This leaves a few methods for which use cases are less obvious, but the inclusion of P-Asserted-Identity would not cause any harm. In any requests, the header field would simply assert the source of that request, whether or not this is of any use to the UAS. Inclusion of P-Asserted-Identity in a request requires that the original asserter of an identity be able to authenticate the source of the request. This implies the ability to challenge a request for SIP digest authentication, which is not possible with ACK and CANCEL requests. Therefore, ACK and CANCEL requests need to be excluded.
したがって、P-アサート・アイデンティティは、RFC 3325.には規定これはケースがあまり明白である使用のためのいくつかの方法を残すが、P-Asserted-の包含がないいる方法と要求で使用することができるいくつかの例がありますアイデンティティは、任意の害を起こしません。すべての要求では、ヘッダフィールドは単にこのUASへの使用であるか否かを、その要求のソースを主張だろう。要求におけるP-アサート・アイデンティティを含めることは、同一の元のアサーションが要求元を認証することができることを必要とします。これは、ACKでは不可能であるSIPダイジェスト認証の要求を、挑戦し、要求をキャンセルする機能を意味します。そのため、ACKとCANCELリクエストを除外するする必要があります。
Similarly, there are examples where P-Preferred-Identity could be used in requests with methods for which there is no provision in RFC 3325 or any other RFC (with the exception of ACK and CANCEL).
同様に、P-好ましいアイデンティティは、RFC 3325または任意の他のRFC（ACKを除くとCANCEL）には規定がないいる方法と要求で使用することができる例があります。
This update to RFC 3325 allows a P-Asserted-Identity or P-Preferred-Identity header field to be included in any request except ACK and CANCEL.
RFC 3325にこの更新は、P-アサート・アイデンティティ又はP-Preferred-Identityヘッダフィールドは、ACK以外の任意の要求に含まれるキャンセルすることを可能にします。
A P-Asserted-Identity header field in a received request asserts the identity of the source of that request and says nothing about the source of subsequent received requests claiming to relate to the same dialog. The recipient can make its own deductions about the source of subsequent requests not containing a P-Asserted-Identity header field. This document does not change RFC 3325 in this respect.
受信した要求でP-Asserted-Identityヘッダフィールドは、その要求の送信元のアイデンティティを主張すると同じダイアログに関連すると主張し、後続の受信要求のソースについては何も言いません。受信者は、P-Asserted-Identityヘッダフィールドを含まない後続の要求のソースに関する独自の控除を行うことができます。この文書では、この点でRFC 3325を変更しません。
This document updates RFC 3325 by allowing a P-Asserted-Identity header field to be included by a UAC within the same Trust Domain and by allowing a P-Asserted-Identity or P-Preferred-Identity header field to appear in any request except ACK or CANCEL.
P-Asserted-Identityヘッダフィールドは、同じ信頼ドメイン内およびP-アサート・アイデンティティ又はP-Preferred-Identityヘッダフィールドは、ACK以外の任意の要求に表示させることにより、UACによって包含されることを可能にすることで、この文書の更新RFC 3325またはCANCEL。
A UAC MAY include a P-Asserted-Identity header field in any request except ACK and CANCEL to report the identity of the user on behalf of which the UAC is acting and whose identity the UAC is in a position to assert. A UAC SHOULD do so only in cases where it believes it is in the same Trust Domain as the SIP entity to which it sends the request and where it is connected to that SIP entity in accordance with the security requirements of RFC 3325. A UAC SHOULD NOT do so in other circumstances and might instead use the P-Preferred-Identity header field. A UAC MUST NOT include both header fields.
UACは、ACK以外の任意の要求にP-Asserted-Identityヘッダフィールドを含み、UACが作用すると、そのアイデンティティUACがアサートする位置にあるの代わりにユーザのアイデンティティを報告するためにキャンセルすることができます。 UACは、それがSIPエンティティは、要求を送信し、どこそれがSHOULD RFC 3325. A UACのセキュリティ要件に合わせてそのSIPエンティティに接続されていると、それは同じ信頼ドメインであると考えている場合には、そうすべきですその他の状況では、そう、代わりにP-Preferred-Identityヘッダフィールドを使用する場合がありますしません。 UACは、両方のヘッダフィールドを含んではいけません。
A UAC MAY include a P-Preferred-Identity header field in any request except ACK or CANCEL.
UACは、ACK以外の任意の要求にP-Preferred-Identityヘッダフィールドを含むか、取り消すことができます。
Inclusion of a P-Asserted-Identity or P-Preferred-Identity header field in a request is not limited to the methods allowed in RFC 3325.
要求におけるP-アサート・アイデンティティ又はP-Preferred-Identityヘッダフィールドを含めることは、RFC 3325で許可された方法に限定されるものではありません。
If a proxy receives a request containing a P-Asserted-Identity header field from a UAC within the Trust Domain, it MUST behave as it would for a request from any other node within the Trust Domain, in accordance with the rules of RFC 3325 for a proxy.
プロキシが信頼ドメイン内UACからP-Asserted-Identityヘッダフィールドを含むリクエストを受信した場合、それは信頼ドメイン内の他のノードからの要求と同じように、それはのためにRFC 3325の規則に従って、振る舞うしなければなりませんプロキシ。
Note that this implies that the proxy must have authenticated the sender of the request in accordance with the Spec(T) in force for the Trust Domain and determined that the sender is indeed part of the Trust Domain.
このプロキシは、信頼ドメインのための力の仕様（T）に応じて、リクエストの送信者を認証し、送信者が実際に信頼ドメインの一部であることを決定したなければならないことを意味することに留意されたいです。
If a proxy receives a request (other than ACK or CANCEL) containing a P-Asserted-Identity or P-Preferred-Identity header field, it MUST behave in accordance with the rules of RFC 3325 for a proxy, even if the method is not one for which RFC 3325 specifies use of that header field.
プロキシはP-アサート・アイデンティティ又はP-Preferred-Identityヘッダフィールドを含む（ACK以外またはCANCEL）要求を受信した場合、それは方法がない場合でも、プロキシのRFC 3325の規則に従って挙動しなければなりませんこれはRFC 3325のための1つは、そのヘッダフィールドの使用を指定します。
If a registrar receives a REGISTER request containing a P-Asserted-Identity header field, it MUST disregard the asserted identity unless it is received from a node within the Trust Domain. If the node is within the Trust Domain (the node having been authenticated by some means), the registrar MAY use this as evidence that the registering UA has been authenticated and is represented by the identity asserted in the header field.
レジストラは、P-Asserted-Identityヘッダフィールドを含む登録要求を受信した場合、それが信頼ドメイン内のノードから受信されない限り、それがアサートされたアイデンティティを無視しなければなりません。ノード（ノードは、何らかの手段によって認証された）信頼ドメイン内にある場合、レジストラは、登録UAが認証されたヘッダフィールドにアサートされたアイデンティティによって表されることを証拠としてこれを使用するかもしれ。
If a UAS receives any request (other than ACK or CANCEL) containing a P-Asserted-Identity header field, it MUST behave in accordance with the rules of RFC 3325 for a UAS, even if the method is not one for which RFC 3325 specifies use of that header field.
UASは、P-Asserted-Identityヘッダフィールドを含む（ACK以外またはCANCEL）任意の要求を受信した場合、この方法は、RFC 3325に指定するためのものでない場合であっても、UASのためのRFC 3325の規則に従って挙動しなければなりませんそのヘッダフィールドの使用。
An entity receiving a P-Asserted-Identity or P-Preferred-Identity header field can expect the number of URIs and the combination of URI schemes in the header field to be in accordance with RFC 3325, any updates to RFC 3325, or any Spec(T) that states otherwise. If an entity receives a request containing a P-Asserted-Identity or P-Preferred-Identity header field containing an unexpected number of URIs or unexpected URI schemes, it MUST act as follows:
P-アサート・アイデンティティ又はP-Preferred-Identityヘッダフィールドを受信エンティティURIの数とヘッダフィールド内のURIスキームの組み合わせは、RFC 3325に従うことを期待することができ、任意の更新RFC 3325、または任意の仕様にそうでない場合は状態（T）。エンティティは、P-アサート・アイデンティティ又はURIのまたは予期しないURIスキームの予想外の数を含むP-Preferred-Identityヘッダフィールドを含むリクエストを受信した場合、次のように行動しなければなりません。
o ignore any URI with an unexpected URI scheme;
O予期しないURIスキームで任意のURIを無視します。
o ignore any URI for which the expected maximum number of URIs with the same scheme occurred earlier in the header field; and
O同じスキームURIの予想される最大数は、以前のヘッダフィールドに発生した任意のURIを無視します。そして
o ignore any URI whose scheme is not expected to occur in combination with a scheme that occurred earlier in the header field.
Oそのスキーム以前ヘッダフィールドの発生方式との組み合わせで発生することが予想されていない任意のURIを無視します。
In the absence of a Spec(T) determining otherwise, this document does not change the RFC 3325 requirement that allows each of these header fields to contain at most two URIs, where one is a SIP or SIPS URI and the other is a TEL URI, but future updates to this document may relax that requirement. In the absence of such a relaxation or a Spec(T) determining otherwise, the RFC 3325 requirement means that an entity receiving a request containing a P-Asserted-Identity or P-Preferred-Identity header field must act as follows:
そうでなければ決定仕様（T）の非存在下で、この文書は、これらのヘッダフィールドのそれぞれ1つはSIPであるか、またはURIをSIPおよび他のTEL URIで最も2つのURI、で含有することができ、RFC 3325の要件を変更しませんしかし、このドキュメントの将来のアップデートは、その要件を緩和します。そうでなければ決定そのような緩和または仕様（T）の非存在下では、RFC 3325の要件は、企業が次のようにP-アサート・アイデンティティ又はP-Preferred-Identityヘッダフィールドが作用しなければならない含む要求を受信することを意味します。
o ignore any URI with a scheme other than SIP, SIPS, or TEL;
O SIP、SIPS、またはTEL以外の方式で任意のURIを無視します。
o ignore a second or subsequent SIP URI, a second or subsequent SIPS URI, or a second or subsequent TEL URI; and
O第二またはその後のSIP URI、第二またはその後のSIPS URI、又は第二又はその後のTEL URIを無視します。そして
o ignore a SIP URI if a SIPS URI occurred earlier in the header field and vice versa.
SIPS URIが以前のヘッダーフィールドとその逆で発生した場合、O SIP URIを無視します。
A proxy MUST NOT forward a URI when forwarding a request if that URI is to be ignored in accordance with the requirement above.
そのURIは、上記の要件に応じて、無視される場合、要求を転送するとき、プロキシは、URIを転送してはいけません。
When a UAC or a proxy sends a request containing a P-Asserted-Identity header field to another node in the Trust Domain, if that other node complies with RFC 3325 but not with this specification, and if the method is not one for which RFC 3325 specifies use of the P-Asserted-Identity header field, and if the request also contains a Privacy header field with value 'id', as specified in RFC 3325, the other node might not handle the Privacy header field correctly. To prevent incorrect handling of the Privacy header field with value 'id', the Spec(T) in force for the Trust Domain SHOULD require all nodes to comply with this specification. If this is not the case, a UAC or a proxy SHOULD NOT include a P-Asserted-Identity header field in a request if the method is not one for which RFC 3325 specifies use of the P-Asserted-Identity header field and if the request also contains a Privacy header field with value 'id'.
UACまたはプロキシは、信頼ドメイン内の別のノードへのP-Asserted-Identityヘッダフィールドを含むリクエストを送信すると、他のノードは、RFC 3325に準拠していなく、本明細書では、本方法はRFCのための1つでない場合場合3325は、P-Asserted-Identityヘッダフィールドの使用を指定し、要求も値とプライバシーヘッダフィールドが含まれている場合に「ID」は、RFC 3325で指定されるように、他のノードが正しくプライバシーヘッダフィールドを処理できない可能性があります。値「ID」とプライバシーヘッダフィールドの誤った取り扱いを防止するために、信頼ドメインのための力の仕様（T）は、この仕様に準拠するすべてのノードを要求すべきです。そうでない場合メソッドは場合RFC 3325はP-Asserted-Identityヘッダフィールドの使用を指定し、ためのものではない場合、UACまたはプロキシは、要求にP-Asserted-Identityヘッダフィールドを含むべきではありません要求は、値「ID」とプライバシーヘッダフィールドを含みます。
The use of asserted identity raises a number of security considerations, which are discussed fully in [RFC3325]. This document raises the following additional security considerations.
アサートされたアイデンティティの使用は[RFC3325]で完全に説明されているセキュリティ上の考慮事項の数を発生させます。このドキュメントでは、次の追加のセキュリティ上の考慮事項が発生します。
When adding a P-Asserted-Identity header field to a message, an entity must have authenticated the source of the message by some means. One means is to challenge the sender of a message to provide SIP digest authentication. Responses cannot be challenged, and also ACK and CANCEL requests cannot be challenged. Therefore, this document limits the use of P-Asserted-Identity to requests other than ACK and CANCEL.
メッセージにP-Asserted-Identityヘッダフィールドを追加する場合、エンティティは、いくつかの手段によってメッセージの送信元を認証している必要があります。 1つの手段は、SIPダイジェスト認証を提供するために、メッセージの送信者に挑戦することです。レスポンスは挑戦することができず、また、ACKとCANCEL要求が挑戦することができません。したがって、この文書は、ACK以外のキャンセル要求にP-アサート - アイデンティティの使用を制限します。
When sending a request containing the P-Asserted-Identity header field and also the Privacy header field with value 'id' to a node within the Trust Domain, special considerations apply if that node does not support this specification. Section 4.5 makes a special provision for this case.
P-Asserted-Identityヘッダフィールドとも信頼ドメイン内のノードに値「ID」とプライバシーヘッダフィールドを含むリクエストを送信する際に、そのノードがこの仕様をサポートしていない場合、特別な考慮事項が当てはまります。 4.5節は、この場合のための特別な準備を行います。
When receiving a request containing a P-Asserted-Identity header field, a proxy will trust the assertion only if the source is known to be within the Trust Domain and behaves in accordance with a Spec(T), which defines the security requirements. This applies regardless of the nature of the resource (UA or proxy). One example where a trusted source might be a UA is a PSTN gateway. In this case, the UA can assert an identity received from the PSTN, the proxy itself having no means to authenticate such an identity. A SIP entity must not trust an identity asserted by a source outside the Trust Domain. Typically, a UA under the control of an individual user (such as a desk phone or mobile phone) should not be considered part of a Trust Domain.
P-Asserted-Identityヘッダフィールドを含むリクエストを受信した場合、プロキシは、ソースが信頼ドメイン内にあることが知られており、セキュリティ要件を定義する仕様（T）に応じて動作しますされている場合にのみアサーションを信頼します。これは、リソース（UAまたはプロキシ）の性質に関係なく適用されます。信頼できるソースは、UAかもしれない一例は、PSTNゲートウェイです。この場合、UAは、プロキシ自体がそのようなアイデンティティを認証する手段を持たない、PSTNから受信したIDをアサートすることができます。 SIPエンティティは、信頼ドメイン外部ソースによってアサートアイデンティティを信頼してはいけません。典型的には、（例えば、固定電話や携帯電話など）は、個々のユーザの制御下UAは、信頼ドメインの一部とみなされるべきではありません。
When receiving a response from a node outside the Trust Domain, a proxy has no standardised SIP means to authenticate the source of the response. For this reason, this document does not specify the use of P-Asserted-Identity or P-Preferred-Identity in responses.
信頼ドメインの外部のノードから応答を受信した場合、プロキシは、標準化SIPレスポンスの送信元を認証することを意味していません。このため、このドキュメントは、応答のP-アサート・アイデンティティまたはP-優先アイデンティティの使用を指定しません。
Useful comments were received from Francois Audet, John-Luc Bakker, Jeroen van Bemmel, Hans Erik van Elburg, Vijay Gurbani, Cullen Jennings, Hadriel Kaplan, Paul Kyzivat, Jonathan Rosenberg, Thomas Stach, and Brett Tate during drafting and review.
有益なコメントを起草し、審査の際にフランソワAudet、ジョン・リュック・バッカー、イェルーンバンBemmel、ハンス・エリック・バンElburg、ビジェイGurbani、カレン・ジェニングス、Hadrielカプラン、ポールKyzivat、ジョナサン・ローゼンバーグ、トーマスStach、およびブレット・テイトから受け取りました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3261] 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.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[RFC3324]ワトソン、M.、2002年11月、RFC 3324、 "ネットワークのための短期要件は、アイデンティティをアサート"。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903]ニエミ、A.、 "イベント状態の出版のためのセッション開始プロトコル（SIP）の拡張"、RFC 3903、2004年10月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinneと、H.、 "電話番号については、TEL URI"、RFC 3966、2004年12月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロ、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916]エルウェル、J.、 "セッション開始プロトコル（SIP）に接続アイデンティティ"、RFC 4916、2007年6月。
[RFC5363] Camarillo, G. and A. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008.
[RFC5363]キャマリロ、G.、およびA.ローチ、RFC 5363、2008年10月 "セッション開始プロトコル（SIP）URIリストサービスのためのフレームワークとセキュリティの考慮事項"。
Author's Address
著者のアドレス
John Elwell Siemens Enterprise Communications
ジョンエルウェルシーメンスエンタープライズコミュニケーションズ
Phone: +44 115 943 4989 EMail: john.elwell@siemens-enterprise.com
電話：+44 115 943 4989 Eメール：john.elwell@siemens-enterprise.com