[要約] RFC 5876は、SIPでの主張された身元情報の更新に関するアップデートを提供しています。その目的は、SIPセッション中のユーザーの身元情報を正確かつ効果的に更新することです。
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）でアサートされたIDの更新
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 asserted-Identityおよびp-preferred-Identityヘッダーフィールドを使用して、要求の発信者のアイデンティティを伝えるメカニズムがあります。これらのヘッダーフィールドは、多くのSIPメソッド、特にInviteメソッドを使用して、リクエストで使用するために指定されています。ただし、RFC 3325は、信頼できるユーザーエージェントクライアント（UAC）によるPアサート付きアイデンティティヘッダーフィールドの挿入を指定していないため、特定のSIPでPアサート付きアイデンティティとP-Preferred-Identityヘッダーフィールドの使用を指定しません。更新、登録、メッセージ、公開などの方法は、これらのヘッダーフィールドで予期しない数の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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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要求のオリジネーターの主張されたアイデンティティを伝えるためのメカニズムを指定します。これは、多くのSIPメソッド、特に招待方法を使用したリクエストで使用するために指定されているP asserted-Identityヘッダーフィールドによって達成されます。さらに、PREFERED-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は、更新[RFC3311]、レジスタ、メッセージ[RFC3428]、および公開[RFC3903]などの特定のSIPメソッドを使用して、P asserted-IdentityおよびP-referred-Identityヘッダーフィールドの使用を指定しません。このドキュメントは、最初のプロキシと同じ信頼ドメインのUACによるp asserted-Identityヘッダーフィールドを含めることを許可し、リクエストを除き、P-asserted-IdentityヘッダーフィールドをP-asserted-Identityヘッダーフィールドの使用を許可することにより、RFC 3325を拡張します。ACKとキャンセル。これら2つの例外の理由は、ACKとキャンセルの要求にダイジェスト認証に挑戦できないためです。
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を使用すると、それぞれP-Asserted-IdentityおよびP-Referred-Identityヘッダーフィールドが最大2つのURIを含むことができます。1つはSIPまたはSIP URI [RFC3261]、もう1つはTel URI [RFC3966]です。これは、他の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]は、Headerフィールドと併せてIDヘッダーフィールドを指定し、そのような状況で認証されたアイデンティティを提供します。RFC 4916 [RFC4916]は、認証された接続されたアイデンティティを提供する手段として、ダイアログ形成リクエストの逆方向のリクエストで、Mid-Dialog要求で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 asserted-Identityの使用が不明です。リクエストとは対照的に、SIPでは、ユーザーエージェントサーバー（UAS）に挑戦して、応答でSIPダイジェスト認証を提供する手段はありません。その結果、プロキシがUASを認証できる標準化されたメカニズムは現在ありません。メッセージのソースを認証することは、IDを主張するための前提条件であるため、このドキュメントでは、応答でP-Asserted-Identityヘッダーフィールドの使用を指定しません。これは、RFC 3325の将来の更新の主題である可能性があります。また、このドキュメントでは、プロキシの能力がない場合に目的を果たさないため、このドキュメントは応答におけるP-Preferred-Identityヘッダーフィールドの使用を指定していません。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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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には、UACがP-Asserted-Identityヘッダーフィールドをリクエストに含める手順は含まれていません。これは、UACが最初のダウンストリームSIPエンティティと同じ信頼ドメインにある場合、意味があります。信頼ドメインに含めるのにしばしば適したUACのタイプの例は次のとおりです。
o Public Switched Telephone Network (PSTN) gateways;
o パブリックスイッチ付き電話ネットワーク（PSTN）ゲートウェイ。
o media servers;
o メディアサーバー。
o application servers (or Back-to-Back User Agents (B2BUAs)) that act as URI list servers [RFC5363];
o URIリストサーバー[RFC5363]として機能するアプリケーションサーバー（またはバックツーバックユーザーエージェント（B2BUAS））;
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の反対側にユーザーのIDを主張する立場にある場合があります。
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とそのプロキシの間に条件の一部として適用する必要があります。ドメイン。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).
更新リクエストで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ヘッダーフィールドを更新リクエストに含めることにより、Gatewayは新しいリモートパーティーの身元をPeer SIPユーザーエージェント（UA）に伝えることができます。
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.
この状況では、（再）招待方法を使用できることに注意してください。ただし、これにより、オファーアンスワーの交換が強制されます。これは通常、この状況では必要ありません。また、2つではなく3つのメッセージが含まれます。
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）[RFC3725]を提供するB2BUAは、2つのコールを一緒に参加したいと考えています。この時点で、片側の単一のダイアログともう一方の側の複数の初期ダイアログ間の不一致のために、2つの参加者間の通常のオファー回答をトリガーすることはできません。呼び出されたUASの1つが回答するまで待ちます。ただし、ユーザーの身元について、各ユーザーにコールが応答されたときに接続されるようになることを早期に示すことは有用です。言い換えれば、新しい呼び出しのUAに新しい呼び出されたユーザーのIDを提供し、新しい呼び出されたUAに新しい呼び出しユーザーのIDを提供します。これは、B2BUAが関係するダイアログにP-Asserted-Identityヘッダーフィールドを使用して更新リクエストを送信することで実現できます。
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ヘッダーフィールドは、リクエストのソースとレジストラを認証したEdgeプロキシ間のレジスタリクエストで有利に使用できます。
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ヘッダーフィールドをメッセージリクエストで有利に使用して、ページモードインスタントメッセージのソースをアサートできます。これにより、インスタントメサージセッションまたはその他の形式のセッションのソースを主張するための招待リクエストでの使用が補完されます。同様に、同じ信頼ドメイン内にないUACと最初のプロキシの間で、ユーザーがいくつかのアイデンティティを持っている場合、PREFERED-IDENTITYヘッダーフィールドをメッセージ要求で使用できます。
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ヘッダーフィールドを公開リクエストで有利に使用して、公開された州情報のソースを主張することができます。これにより、サブスクライブおよび通知リクエストでの使用が補完されます。同様に、同じ信頼ドメイン内にないUACと最初のプロキシの間で、ユーザーがいくつかのアイデンティティを持っている場合、PREFERED-IDENTITYヘッダーフィールドを公開要求で使用できます。
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.
したがって、RFC 3325に規定がない方法を使用したリクエストでp asserted-Identityを使用できるいくつかの例があります。アイデンティティは害を引き起こしません。どのリクエストでも、ヘッダーフィールドは、これがUASに役立つかどうかにかかわらず、その要求のソースを単純に主張するだけです。リクエストにP asserted-Identityを含めるには、アイデンティティの元のアッセルターがリクエストのソースを認証できることが必要です。これは、ACKおよびキャンセルリクエストでは不可能なSIPダイジェスト認証のリクエストに挑戦する機能を意味します。したがって、ACKおよびキャンセルリクエストを除外する必要があります。
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).
同様に、RFC 3325または他のRFCに規定がない方法を備えたリクエストでp-referred-Identityを使用できる例があります（ACKおよびキャンセルを除く）。
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-Asserted-IdentityまたはP-Referred-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ヘッダーフィールドを同じ信頼ドメイン内のUACに含めることを許可し、P-Asserted-IdentityまたはP-aserred-IdentityヘッダーフィールドをACKを除く任意のリクエストに表示できるようにすることにより、RFC 3325を更新します。またはキャンセル。
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が主張する立場にあるユーザーのIDを報告します。UACは、リクエストを送信するSIPエンティティと同じ信頼ドメインにあると信じている場合にのみ、RFC 3325のセキュリティ要件に従ってそのSIPエンティティに接続されている場合にのみ行う必要があります。他の状況ではそうではなく、代わりにp-referred-Identityヘッダーフィールドを使用する場合があります。UACには両方のヘッダーフィールドを含めてはなりません。
A UAC MAY include a P-Preferred-Identity header field in any request except ACK or CANCEL.
UACには、ACKまたはキャンセルを除く任意のリクエストに、p-referred-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 asserted-Identityまたはp-referred-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-asserted-Identityまたはp-referred-Identityヘッダーフィールドを含むリクエスト（ACKまたはキャンセル以外）を受信した場合、メソッドがプロキシのRFC 3325のルールに従って動作する必要があります。RFC 3325がそのヘッダーフィールドの使用を指定するもの。
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ヘッダーフィールドを含むレジスタリクエストを受信した場合、Trustドメイン内のノードから受信されない限り、主張されたIDを無視する必要があります。ノードが信頼ドメイン内にある場合（ノードは何らかの手段で認証されています）、レジストラはこれを登録UAが認証され、ヘッダーフィールドで主張されたIDによって表されているという証拠として使用できます。
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.
P-Asserted-Identityヘッダーフィールドを含むUASが（ACK以外のACKまたはキャンセル）を受信した場合、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 asserted-Identityまたはp-referred-Identityヘッダーフィールドを受け取るエンティティは、URIの数とヘッダーフィールドのURIスキームの組み合わせがRFC 3325、RFC 3325の更新、または仕様に従ってあることを期待できます。（t）そうでないと述べています。エンティティが、予期しない数のURIまたは予期しないURIスキームを含むP asserted-Identityまたはp-referred-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）がない場合、このドキュメントは、これらのヘッダーフィールドのそれぞれが最大2つのURIを封じ込めることを可能にするRFC 3325要件を変更しません。、しかし、このドキュメントの将来の更新は、その要件を緩和するかもしれません。そのようなリラクゼーションまたは仕様（t）がない場合、RFC 3325要件は、P asserted-Identityまたはp-referred-Identityヘッダーフィールドを含むリクエストを受信するエンティティが次のように機能する必要があることを意味します。
o ignore any URI with a scheme other than SIP, SIPS, or TEL;
o SIP、SIP、または電話以外のスキームでURIを無視します。
o ignore a second or subsequent SIP URI, a second or subsequent SIPS URI, or a second or subsequent TEL URI; and
o 2番目またはその後のSIP URI、2番目またはその後のSIPS URI、または2番目またはその後のTel URIを無視します。と
o ignore a SIP URI if a SIPS URI occurred earlier in the header field and vice versa.
o SIPS URIがヘッダーフィールドの早い段階で発生した場合、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のものではない場合3325 P-Asserted-Identityヘッダーフィールドの使用を指定し、RFC 3325で指定されているように、リクエストに値「ID」を持つプライバシーヘッダーフィールドも含まれている場合、他のノードはプライバシーヘッダーフィールドを正しく処理できない場合があります。値「ID」でプライバシーヘッダーフィールドの誤った処理を防ぐために、信頼ドメインの仕様（T）は、この仕様に準拠するためにすべてのノードを必要とする必要があります。これがそうでない場合、UACまたはプロキシは、RFC 3325がP-Asserted-Identityヘッダーフィールドの使用を指定している方法ではない場合、およびメソッドがリクエストに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およびキャンセルリクエストも挑戦することはできません。したがって、このドキュメントは、ACK以外の要求とキャンセル以外のリクエストにP asserted-Identityの使用を制限します。
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である可能性のある1つの例は、PSTNゲートウェイです。この場合、UAはPSTNから受け取ったアイデンティティを主張することができます。これは、そのようなアイデンティティを認証する手段を持たないプロキシ自体です。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 asserted-Identityまたはp-preferred-Identityの使用を指定していません。
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.
Francois Audet、John-Luc Bakker、Jeroen Van Bemmel、Hans Erik van Elburg、Vijay Gurbani、Cullen Jennings、Hadriel Kaplan、Paul Kyzivat、Jonathan Rosenberg、Thomas Stach、Brett Tateからの有用なコメントが受け取られました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年10月。
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[RFC3324]ワトソン、M。、「ネットワーク主張されたアイデンティティの短期要件」、RFC 3324、2002年11月。
[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] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内での主張されたアイデンティティのセッション開始プロトコル（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] Campbell、B.、Rosenberg、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] Niemi、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] Rosenberg、J.、Peterson、J.、Schulzrinne、H.、およびG. Camarillo、「セッション開始プロトコル（SIP）のサードパーティコールコントロール（3PCC）の最良の現在のプラクティス」、BCP 85、RFC 3725、2004年4月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916] Elwell、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] Camarillo、G。およびA. Roach、「セッション開始プロトコル（SIP）URI-Listサービスのフレームワークとセキュリティ上の考慮事項」、RFC 5363、2008年10月。
Author's Address
著者の連絡先
John Elwell Siemens Enterprise Communications
John Elwell Siemens Enterprise Communications
Phone: +44 115 943 4989
EMail: john.elwell@siemens-enterprise.com