[要約] 本RFCはRFC 4474を置き換え、SIPリクエストの発信者が主張するSIP URIまたは電話番号の識別情報を、署名付きPASSporTと資格情報で検証するSTIR仕様を定めます。発信側の認証サービスがIdentityヘッダーを追加し、受信側の検証サービスが署名と資格情報を検証します。検証結果に基づく通話の認可や遮断のポリシーは本RFCの範囲外です。
Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 8224 NeuStar
Obsoletes: 4474 C. Jennings
Category: Standards Track Cisco
ISSN: 2070-1721 E. Rescorla
RTFM, Inc.
C. Wendt
Comcast
February 2018
Authenticated Identity Management in the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）における認証済みアイデンティティ管理
Abstract
概要
The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.
Session Initiation Protocol（SIP）の既存のセキュリティ機構では、特にドメイン間の環境で、SIPリクエストを発信するエンドユーザーの識別情報を暗号学的に保証するには不十分です。本書では、SIPリクエストの発信者を安全に識別する仕組みを定義します。識別情報の検証に使う署名を伝えるSIPヘッダーフィールドと、署名者の資格情報を参照する情報を定義します。
This document obsoletes RFC 4474.
このドキュメントはRFC 4474を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書はInternet Engineering Task Force（IETF）の成果です。IETFコミュニティの合意を反映し、公開レビューを経てInternet Engineering Steering Group（IESG）により発行が承認されました。Internet Standardsの詳細については、RFC 7841のSection 2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8224.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8224で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文書に関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3 2. Terminology .....................................................4 3. Architectural Overview ..........................................5 4. Identity Header Field Syntax ....................................7 4.1. PASSporT Construction ......................................8 4.1.1. Example Full and Compact Forms of PASSporT in Identity ........................................10 5. Example of Operations ..........................................11 5.1. Example Identity Header Construction ......................13 6. Signature Generation and Validation ............................14 6.1. Authentication Service Behavior ...........................14 6.1.1. Handling Repairable Errors .........................16 6.2. Verifier Behavior .........................................17 6.2.1. Authorization of Requests ..........................19 6.2.2. Failure Response Codes Sent by a Verification Service ...............................19 6.2.3. Handling Retried Requests ..........................21 6.2.4. Handling the Full Form of PASSporT .................21 7. Credentials ....................................................22 7.1. Credential Use by the Authentication Service ..............22 7.2. Credential Use by the Verification Service ................23 7.3. "info" Parameter URIs .....................................24 7.4. Credential System Requirements ............................25 8. Identity Types .................................................26 8.1. Differentiating Telephone Numbers from URIs ...............26 8.2. Authority for Telephone Numbers ...........................27 8.3. Telephone Number Canonicalization Procedures ..............28 8.4. Authority for Domain Names ................................29 8.5. URI Normalization .........................................30 9. Extensibility ..................................................31 10. Backwards Compatibility with RFC 4474 .........................32
11. Privacy Considerations ........................................32 12. Security Considerations .......................................34 12.1. Protected Request Fields .................................34 12.1.1. Protection of the To Header and Retargeting .......36 12.2. Unprotected Request Fields ...............................37 12.3. Malicious Removal of Identity Headers ....................37 12.4. Securing the Connection to the Authentication Service ....38 12.5. Authorization and Transitional Strategies ................39 12.6. Display-Names and Identity ...............................40 13. IANA Considerations ...........................................40 13.1. SIP Header Fields ........................................40 13.2. SIP Response Codes .......................................41 13.3. Identity-Info Parameters .................................41 13.4. Identity-Info Algorithm Parameter Values .................41 14. Changes from RFC 4474 .........................................41 15. References ....................................................42 15.1. Normative References .....................................42 15.2. Informative References ...................................43 Acknowledgments ...................................................46 Authors' Addresses ................................................46
This document provides enhancements to the existing mechanisms for authenticated identity management in the Session Initiation Protocol (SIP) [RFC3261]. An identity, for the purposes of this document, is defined as either
本書は、Session Initiation Protocol（SIP）[RFC3261]における認証済み識別情報管理の既存機構を強化します。本書では、識別情報を次のいずれかとして定義します。
o a canonical address-of-record (AoR) SIP URI employed to reach a user (such as "sip:alice@atlanta.example.com") or
o ユーザーへの到達に使われる正規のAddress-of-Record（AoR）SIP URI（例: "sip:alice@atlanta.example.com"）、または
o a telephone number, which commonly appears either in a tel URI [RFC3966] or as the user portion of a SIP URI.
o 電話番号。通常はtel URI [RFC3966]内に現れるか、SIP URIのuser部分として現れます。
[RFC3261] specifies several places within a SIP request where users can express an identity for themselves, most prominently the user-populated From header field. However, in the absence of some sort of cryptographic authentication mechanism, the recipient of a SIP request has no way to verify that the From header field has been populated appropriately. This leaves SIP vulnerable to a category of abuses such as impersonation attacks that facilitate or enable robocalling, voicemail hacking, swatting, and related problems as described in [RFC7340]. Ideally, a cryptographic approach to identity can provide a much stronger assurance of identity than the Caller ID services that the telephone network provides today, and one less vulnerable to spoofing.
[RFC3261] encourages user agents (UAs) to implement a number of potential authentication mechanisms, including Digest authentication, Transport Layer Security (TLS), and S/MIME (implementations may support other security schemes as well). However, few SIP UAs today support the end-user certificates necessary to authenticate themselves (via S/MIME, for example), and for its part Digest authentication is limited by the fact that the originator and destination must share a prearranged secret. Practically speaking, originating UAs need to be able to securely communicate their users' identities to destinations with which they have no previous association.
[RFC3261]は、Digest認証、Transport Layer Security（TLS）、S/MIMEなど、複数の認証機構を実装するようユーザーエージェント（UA）に推奨しています（実装は他のセキュリティ方式もサポートできます）。しかし現在、SIP UAのうち、たとえばS/MIMEで自らを認証するために必要なエンドユーザー証明書をサポートするものはごくわずかです。またDigest認証では、発信側と宛先側が事前に共有した秘密を持つ必要があります。実際には、発信側UAは、これまで関係のなかった宛先にもユーザーの識別情報を安全に伝えられる必要があります。
As an initial attempt to address this gap, [RFC4474] specified a means of signing portions of SIP requests in order to provide an identity assurance. However, [RFC4474] was in several ways misaligned with deployment realities (see [SIP-RFC4474-CONCERNS]). Most significantly, [RFC4474] did not deal well with telephone numbers as identifiers, despite their enduring use in SIP deployments. [RFC4474] also provided a signature over material that intermediaries in existing deployments commonly altered. This specification therefore deprecates the syntax and behavior specified by [RFC4474], reconsidering the problem space in light of the threat model in [RFC7375] and aligning the signature format with PASSporT (Personal Assertion Token) [RFC8225]. Backwards-compatibility considerations are given in Section 10.
この隔たりに対処する最初の試みとして、[RFC4474]は識別情報を保証するためにSIPリクエストの一部に署名する方法を規定しました。しかし、[RFC4474]はいくつかの点で実際の導入状況に適合していませんでした（[SIP-RFC4474-CONCERNS]を参照）。特に、SIPで電話番号が長く使われているにもかかわらず、識別子としての電話番号を適切に扱えませんでした。また、既存の導入環境で仲介者が一般に変更する情報にも署名していました。そのため本仕様は、[RFC4474]が規定した構文と動作を非推奨とし、[RFC7375]の脅威モデルを踏まえて問題領域を見直すとともに、署名形式をPASSporT（Personal Assertion Token）[RFC8225]に合わせます。後方互換性についてはSection 10で説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、BCP 14 [RFC2119] で説明されているように解釈されるものとします。
In addition, this document uses three terms specific to the mechanism:
さらに、このドキュメントでは、メカニズムに固有の3つの用語を使用しています。
o Identity: An identifier for the user of a communications service; for the purposes of SIP, either a SIP URI or a telephone number. Identities are derived from an "identity field" in a SIP request such as the From header field.
o Identity（識別情報）: 通信サービスのユーザーを識別する情報です。SIPではSIP URIまたは電話番号を指します。識別情報は、Fromヘッダーフィールドなど、SIPリクエスト内の"identity field"から導出されます。
o Authentication Service: A logical role played by a SIP entity that adds Identity headers to SIP requests.
o Authentication Service: SIPリクエストにIdentityヘッダーを追加するSIPエンティティが担う論理的な役割です。
o Verification Service (or "Verifier"): A logical role played by a SIP entity that validates Identity headers in a SIP request.
o Verification Service（Verifier）: SIPリクエスト内のIdentityヘッダーを検証するSIPエンティティが担う論理的な役割です。
The identity architecture for SIP defined in this specification depends on a logical "authentication service" that validates outgoing requests. An authentication service may be implemented either as part of a UA or as a proxy server; typically, it is a component of a network intermediary like a proxy to which originating UAs send unsigned requests. Once the originator of the message has been authenticated, through prearranged means with the authentication service, the authentication service then creates and adds an Identity header field to the request. This requires computing cryptographic information -- including a digital signature over some components of messages -- that lets other SIP entities verify that the sending user has been authenticated and its claim of a particular identity has been authorized. These "verification services" validate the signature and enable policy decisions to be made based on the results of the validation.
本仕様が定義するSIPの識別情報アーキテクチャーは、発信リクエストを検証する論理的な"authentication service"に依存します。認証サービスはUAの一部としても、プロキシサーバーとしても実装できます。通常は、発信側UAから署名のないリクエストを受け取るプロキシなど、ネットワーク仲介者の構成要素です。発信者が認証サービスとの事前の取り決めに基づいて認証されると、認証サービスはIdentityヘッダーフィールドを作成してリクエストに追加します。そのために、メッセージの一部に対するデジタル署名などの暗号学的情報を計算します。これにより、他のSIPエンティティは、発信ユーザーが認証済みであり、そのユーザーが特定の識別情報を主張する権限を与えられていることを検証できます。"verification service"は署名を検証し、その結果に基づくポリシー判断を可能にします。
Policy decisions made after validation depend heavily on the verification service's trust for the credentials that the authentication service uses to sign requests. As robocalling, voicemail hacking, and swatting usually involve impersonation of telephone numbers, credentials that will be trusted by relying parties to sign for telephone numbers are a key component of the architecture. Authority over telephone numbers is, however, not as easy to establish on the Internet as authority over traditional domain names. This document assumes the existence of credentials for establishing authority over telephone numbers for cases where the telephone number is the identity of the user, but does not mandate or specify a credential system; [RFC8226] describes a credential system compatible with this architecture.
検証後のポリシー判断は、認証サービスがリクエストの署名に使う資格情報を検証サービスがどれだけ信頼するかに大きく依存します。ロボコール、ボイスメールへの不正アクセス、スワッティングでは電話番号のなりすましが多いため、電話番号に対する署名を依拠当事者が信頼できる資格情報は、このアーキテクチャーの重要な要素です。ただし、インターネット上で電話番号の権限を確立するのは、従来のドメイン名の場合ほど容易ではありません。本書は、ユーザーの識別情報が電話番号である場合に、その番号の権限を確立する資格情報が存在すると仮定しますが、資格情報システムを義務付けたり規定したりはしません。[RFC8226]は、このアーキテクチャーと互換性のある資格情報システムを説明しています。
Although addressing the vulnerabilities in the Secure Telephone Identity Revisited (STIR) problem statement [RFC7340] and threat model mostly requires dealing with telephone number as identities, SIP must also handle signing for SIP URIs as identities. This is typically easier to deal with, as these identities are issued by organizations that have authority over Internet domains. When a new user becomes associated with example.com, for example, the administrator of the SIP service for that domain can issue them an identity in that namespace, such as sip:alice@example.com. Alice may then send REGISTER requests to example.com that make her UAs eligible to receive requests for sip:alice@example.com. In other cases, Alice may herself be the owner of her own domain and may issue herself identities as she chooses. But ultimately, it is the controller of the SIP service at example.com that must be responsible for authorizing the use of names in the example.com domain. Therefore, for the purposes of SIP as defined in [RFC3261], the necessary credentials needed to prove that a user is authorized to use a particular From header field must ultimately derive from the domain owner: either (1) a UA gives requests to the domain name owner in order for them to be signed by the domain owner's credentials or (2) the UA must possess credentials that prove that the domain owner has given the UA the right to a name.
Secure Telephone Identity Revisited（STIR）の問題提起[RFC7340]と脅威モデルが扱う脆弱性への対処では、主に電話番号を識別情報として扱いますが、SIPではSIP URIを識別情報として署名する必要もあります。SIP URIはインターネットドメインの権限を持つ組織が発行するため、通常はこちらの方が扱いやすいものです。たとえば、新しいユーザーがexample.comに所属すると、そのドメインのSIPサービス管理者はsip:alice@example.comのような名前空間内の識別情報を発行できます。その後Aliceはexample.comにREGISTERリクエストを送り、自分のUAがsip:alice@example.com宛てのリクエストを受信できるようにします。Alice自身がドメインを所有し、自分で識別情報を発行する場合もあります。しかし最終的には、example.comドメイン内の名前の使用を許可する責任は、example.comのSIPサービスを管理する主体にあります。[RFC3261]が定義するSIPでは、特定のFromヘッダーフィールドをユーザーが使う権限を証明する資格情報は、最終的にドメイン所有者に由来する必要があります。つまり、(1) UAがリクエストをドメイン所有者に渡し、所有者の資格情報で署名してもらうか、(2) ドメイン所有者がUAにその名前の使用権を与えたことを証明する資格情報をUAが持つ必要があります。
In order to share a cryptographic assurance of end-user SIP identity in an interdomain or intradomain context, an authentication service constructs tokens based on the PASSporT format [RFC8225], which is special encoding of a JSON [RFC8259] object comprising values derived from certain header field values in the SIP request. The authentication service computes a signature over those JSON elements as PASSporT specifies. An encoding of the resulting PASSporT is then placed in the SIP Identity header field. In order to assist in the validation of the Identity header field, this specification also describes a parameter of the Identity header field that can be used by the recipient of a request to recover the credentials of the signer.
ドメイン間またはドメイン内でエンドユーザーのSIP識別情報を暗号学的に保証するため、認証サービスはPASSporT形式[RFC8225]に基づくトークンを作成します。PASSporTは、SIPリクエスト内の特定のヘッダーフィールド値から導出した値を含むJSON [RFC8259]オブジェクトを特殊な形式で符号化したものです。認証サービスはPASSporTの規定に従ってJSON要素に署名し、その結果のPASSporTを符号化してSIP Identityヘッダーフィールドに格納します。Identityヘッダーフィールドの検証を支援するため、本仕様は、受信側が署名者の資格情報を取得するために使えるパラメーターも規定します。
Note that the scope of this document is limited to providing an identity assurance for SIP requests; solving this problem for SIP responses is outside the scope of this work (see [RFC4916]). Future work might specify ways that a SIP implementation could gateway PASSporTs to other protocols.
このドキュメントの範囲は、SIPリクエストのID保証の提供に限定されていることに注意してください。 SIP応答に関するこの問題の解決は、この作業の範囲外です（[RFC4916]を参照）。今後の作業では、SIP実装がPASSporTを他のプロトコルにゲートウェイする方法を指定する可能性があります。
The Identity and Identity-Info header fields that were previously defined in [RFC4474] are deprecated by this document. This revised specification collapses the grammar of Identity-Info into the Identity header field via the "info" parameter. Note that unlike the prior specification in [RFC4474], the Identity header field is now allowed to appear more than one time in a SIP request. The revised grammar for the Identity header field builds on the ABNF [RFC5234] in [RFC3261], Section 25. It is as follows:
Identity = "Identity" HCOLON signed-identity-digest SEMI
ident-info *( SEMI ident-info-params )
signed-identity-digest = 1*(base64-char / ".")
ident-info = "info" EQUAL ident-info-uri
ident-info-uri = LAQUOT absoluteURI RAQUOT
ident-info-params = ident-info-alg / ident-type /
ident-info-extension
ident-info-alg = "alg" EQUAL token
ident-type = "ppt" EQUAL token
ident-info-extension = generic-param
base64-char = ALPHA / DIGIT / "/" / "+"
In addition to the "info" parameter, and the "alg" parameter previously defined in [RFC4474], this specification defines the optional "ppt" parameter (PASSporT Type). The "absoluteURI" portion of ident-info-uri MUST contain a URI; see Section 7.3 for more on choosing how to advertise credentials through this parameter.
「info」パラメータと以前に[RFC4474]で定義された「alg」パラメータに加えて、この仕様はオプションの「ppt」パラメータ（PASSporTタイプ）を定義します。 ident-info-uriの「absoluteURI」部分にはURIが含まれていなければなりません (MUST)。このパラメーターを使用して資格情報を通知する方法の選択の詳細については、7.3項を参照してください。
The signed-identity-digest contains a base64 encoding of a PASSporT [RFC8225], which secures the request with a signature that PASSporT generates over the JSON header and payload objects; some of those header and claim element values will mirror values of the SIP request.
signed-identity-digestには、PASSporT [RFC8225]のbase64エンコードが含まれています。これにより、PASSporTがJSONヘッダーおよびペイロードオブジェクトを介して生成する署名でリクエストが保護されます。これらのヘッダーとクレーム要素の値の一部は、SIPリクエストの値を反映しています。
For SIP implementations to populate the PASSporT header JSON object with fields from a SIP request, the following elements MUST be placed as the values corresponding to the designated JSON keys:
SIP実装がPASSporTヘッダーのJSONオブジェクトにSIPリクエストのフィールドを設定するには、次の要素を、指定されたJSONキーに対応する値として配置しなければなりません (MUST)。
o First, per the baseline PASSporT specification [RFC8225], the JSON "typ" key MUST have the value "passport".
o 2番目に、ベースラインPASSporT仕様[RFC8225]に従い、JSONキー "typ" の値を "passport" にしなければなりません (MUST)。
o Second, the JSON key "alg" MUST mirror the value of the optional "alg" parameter in the SIP Identity header field. Note that if the "alg" parameter is absent from the Identity header, the default value is "ES256".
o 次に、JSONキー「alg」は、SIP Identityヘッダーフィールドのオプションの「alg」パラメーターの値をミラーリングしなければなりません (MUST)。 Identityヘッダーに「alg」パラメーターがない場合、デフォルト値は「ES256」であることに注意してください。
o Third, the JSON key "x5u" MUST have a value equivalent to the quoted URI in the "info" parameter, per the simple string comparison rules of [RFC3986], Section 6.2.1.
o 3番目に、[RFC3986]のセクション6.2.1の単純な文字列比較ルールに従って、JSONキー「x5u」の「info」パラメータに引用符で囲まれたURIと同等の値が含まれていなければなりません (MUST)。
o Fourth, if a PASSporT extension is in use, then the optional JSON key "ppt" MUST be present and have a value equivalent to the quoted value of the "ppt" parameter of the Identity header field.
o 4番目に、PASSporT拡張が使用されている場合、オプションのJSONキー「ppt」が存在し、Identityヘッダーフィールドの「ppt」パラメーターの引用符で囲まれた値と同等の値を持っていなければなりません (MUST)。
An example of the PASSporT header JSON object without any extension is:
拡張子のないPASSporTヘッダーJSONオブジェクトの例は次のとおりです。
{ "typ":"passport",
"alg":"ES256",
"x5u":"https://www.example.com/cert.cer" }
To populate the PASSporT payload JSON object from a SIP request, the following elements MUST be placed as values corresponding to the designated JSON keys:
SIPリクエストからPASSporTペイロードJSONオブジェクトを生成するには、次の要素を、指定されたJSONキーに対応する値として配置しなければなりません (MUST)。
o First, the JSON "orig" object MUST be populated. If the originating identity is a telephone number, then the array MUST be populated with a JSON object containing a "tn" element with a value set to the value of the quoted originating identity, a canonicalized telephone number (see Section 8.3). Otherwise, the object MUST be populated with a JSON object containing a "uri" element, set to the value of the AoR of the UA sending the message as taken from the addr-spec of the From header field, per the procedures in Section 8.5.
o まず、JSONの "orig" オブジェクトを設定しなければなりません (MUST)。発信元の識別情報が電話番号の場合、正規化した発信元番号（Section 8.3を参照）を値とする "tn" 要素を含むJSONオブジェクトを配列に設定しなければなりません (MUST)。それ以外の場合は、メッセージを送信するUAのAoRを値とする "uri" 要素を含むJSONオブジェクトを設定しなければなりません (MUST)。このAoRは、Section 8.5の手順に従い、Fromヘッダーフィールドのaddr-specから取得します。
o Second, the JSON "dest" array MUST be populated. If the destination identity is a telephone number, then the array MUST be populated with a JSON object containing a "tn" element with a value set to the value of the quoted destination identity, a canonicalized telephone number (see Section 8.3). Otherwise, the array MUST be populated with a JSON object containing a "uri" element, set to the value of the addr-spec component of the To header field, which is the AoR to which the request is being sent, per the procedures in Section 8.5. Multiple JSON objects are permitted in "dest" for future compatibility reasons.
o 次に、JSONの "dest" 配列を設定しなければなりません (MUST)。宛先の識別情報が電話番号の場合は、正規化した宛先番号（Section 8.3を参照）を値とする "tn" 要素を含むJSONオブジェクトを配列に設定しなければなりません (MUST)。それ以外の場合は、Toヘッダーフィールドのaddr-spec値（リクエストの送信先となるAoR）を値とする "uri" 要素を含むJSONオブジェクトを、Section 8.5の手順に従って配列に設定しなければなりません (MUST)。将来の互換性のため、"dest" には複数のJSONオブジェクトを含めてもかまいません。
o Third, the JSON key "iat" MUST appear. The authentication service SHOULD set the value of "iat" to an encoding of the value of the SIP Date header field as a JSON NumericDate (as UNIX time, per [RFC7519], Section 2), though an authentication service MAY set the value of "iat" to its own current clock time. If the authentication service uses its own clock time, then the use of the full form of PASSporT is REQUIRED. In either case, the authentication service MUST NOT generate a PASSporT for a SIP request if the Date header is outside of its local policy for freshness (sixty seconds is RECOMMENDED).
o 3番目に、JSONキー "iat" が存在しなければなりません (MUST)。認証サービスは、"iat" の値として、SIPのDateヘッダーフィールドの値をJSON NumericDate（UNIX時刻。[RFC7519] Section 2）に符号化した値を設定すべきです (SHOULD)。ただし、認証サービスは独自の現在時刻を "iat" の値に設定してもよいです (MAY)。独自の時刻を使う場合は、PASSporTの完全形式を使わなければなりません (MUST)。いずれの場合も、Dateヘッダーの値が鮮度に関するローカルポリシーの範囲外なら、認証サービスはSIPリクエストのPASSporTを生成してはなりません (MUST NOT)（60秒以内の差が推奨されます (SHOULD)）。
o Fourth, if the request contains a Session Description Protocol (SDP) message body and if that SDP contains one or more "a=fingerprint" attributes, then the JSON key "mky" MUST appear with the algorithm(s) and value(s) of the fingerprint attributes (if they differ), following the format given in [RFC8225], Section 5.2.2.
o 4番目に、リクエストにSession Description Protocol（SDP）メッセージ本文が含まれ、そのSDPに1つ以上の "a=fingerprint" 属性が含まれる場合、JSONキー "mky" を含め、その値を指紋属性のアルゴリズムと値（複数ある場合はそれぞれ）にしなければなりません (MUST)。形式は[RFC8225] Section 5.2.2に従います。
For example:
例えば：
{ "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551213"]},
"iat":1443208345 }
For information on the security properties of these SIP message elements and why their inclusion mitigates replay attacks, see Section 12. Note that future extensions to PASSporT could introduce new claims and that further SIP procedures could be required to extract information from the SIP request to populate the values of those claims; see Section 9 of this document.
これらのSIPメッセージ要素が持つセキュリティ特性と、これらを含めることでリプレイ攻撃を軽減できる理由についてはSection 12を参照してください。将来のPASSporT拡張で新たなクレームが導入され、それらの値を設定するためにSIPリクエストから情報を抽出する追加手順が必要になる可能性もあります。本書のSection 9を参照してください。
The "orig" and "dest" arrays may contain identifiers of heterogeneous type; for example, the "orig" array might contain a "tn" claim, while the "dest" contains a "uri" claim. Also note that in some cases, the "dest" array may be populated with more than one value. This could, for example, occur when multiple "dest" identities are specified in a meshed conference. Defining how a SIP implementation would align multiple destination identities in PASSporT with such systems is left as a subject for future specifications.
"orig" 配列と "dest" 配列には、異なる種類の識別子を含められます。たとえば、"orig" 配列には "tn" クレームを、"dest" 配列には "uri" クレームを含めることができます。また、"dest" 配列に複数の値を設定する場合もあります。たとえば、メッシュ型会議で複数の "dest" 識別情報を指定する場合です。SIP実装がPASSporT内の複数の宛先識別情報をそのようなシステムに対応付ける方法は、今後の仕様で定める課題です。
After these two JSON objects, the header and the payload, have been constructed and base64-encoded, they must each be hashed and signed per [RFC8225], Section 6. The header, payload, and signature components comprise a full PASSporT object. The resulting PASSporT may be carried in SIP in either (1) a full form, which includes the header and payload as well as the signature or (2) a compact form, which only carries the signature per [RFC8225], Section 7. The hashing and signing algorithm is specified by the "alg" parameter of the Identity header field and the mirrored "alg" parameter of PASSporT. All implementations of this specification MUST support the required signing algorithms of PASSporT. At present, there is one mandatory-to-support value for the "alg" parameter: "ES256", as defined in [RFC7519], which connotes an Elliptic Curve Digital Signature Algorithm (ECDSA) P-256 digital signature.
ヘッダーとペイロードという2つのJSONオブジェクトを構築してbase64符号化した後、それぞれを[RFC8225] Section 6に従ってハッシュ化し、署名します。ヘッダー、ペイロード、署名の各要素で完全なPASSporTオブジェクトを構成します。生成したPASSporTは、(1) ヘッダー、ペイロード、署名を含む完全形式、または (2) [RFC8225] Section 7に従い署名だけを含むコンパクト形式のいずれかでSIPに載せられます。ハッシュ化と署名に使うアルゴリズムは、Identityヘッダーフィールドの "alg" パラメーターと、PASSporT内の対応する "alg" パラメーターで指定します。本仕様のすべての実装は、PASSporTで必須とされる署名アルゴリズムをサポートしなければなりません (MUST)。現在、"alg" パラメーターでサポートが必須の値は[RFC7519]が定義する "ES256" の1つです。これは楕円曲線デジタル署名アルゴリズム（ECDSA）P-256によるデジタル署名を表します。
As Appendix F of the JSON Web Signature (JWS) specification [RFC7515] notes, there are cases where "it is useful to integrity-protect content that is not itself contained in a JWS." Since the fields that make up the majority of the PASSporT header and payload have values replicated in the SIP request, the SIP usage of PASSporT may exclude the base64-encoded version of the header and payload JSON objects from the Identity header field and instead present a detached signature: what PASSporT calls its compact form; see [RFC8225], Section 7.
When an authentication service constructs an Identity header, the contents of the signed-identity-digest field MUST contain either a full or compact PASSporT. Use of the compact form is RECOMMENDED in order to reduce message size, but note that extensions often require the full form (see Section 9).
認証サービスがIdentityヘッダーを構築する場合、signed-identity-digestフィールドには完全形式またはコンパクト形式のPASSporTを含めなければなりません (MUST)。メッセージサイズを小さくするため、コンパクト形式を使うことが推奨されます (SHOULD)。ただし、拡張機能では完全形式が必要になることがよくあります（Section 9を参照）。
For example, a full form of PASSporT in an Identity header might look as follows (backslashes shown for line folding only):
たとえば、Identityヘッダーの完全な形式のPASSporTは次のようになります（バックスラッシュは行の折りたたみのみに表示されます）。
Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \ joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ \ kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \ I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \ q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ ojNCpTzO3QfPOlckGaS6hEck7w;info=<https://biloxi.example.org \ /biloxi.cert>
The compact form of the same PASSporT object would appear in the Identity header as:
同じPASSporTオブジェクトのコンパクト形式は、Identityヘッダーフィールドに次のように現れます。
Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qj \
pjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
info=<https://biloxi.example.org/biloxi.cert>
This section provides an informative (non-normative) high-level example of the operation of the mechanisms described in this document.
このセクションでは、このドキュメントで説明されているメカニズムの操作に関する有益な（非規範的な）高レベルの例を示します。
Imagine a case where Bob, who has the home proxy of example.com and the AoR sip:12155551212@example.com;user=phone, wants to communicate with Alice at sip:alice@example.com. They have no prior relationship, and Alice implements best practices to prevent impersonation attacks.
example.comのホームプロキシとAoR sip:12155551212@example.com;user=phoneを持つBobが、sip:alice@example.comのAliceと通信しようとしているとします。2人の間には事前の関係がなく、Aliceはなりすまし攻撃を防ぐためのベストプラクティスを実装しています。
Bob's UA generates an INVITE and places his AoR in the From header field of the request. He then sends an INVITE to an authentication service proxy for his domain.
ボブのUAはINVITEを生成し、彼のAoRをリクエストのFromヘッダーフィールドに配置します。次に、自分のドメインの認証サービスプロキシにINVITEを送信します。
............................ ..............................
. . . .
. +-------+ . . +-------+ .
. Signs for | | . Signed . | | .
. 12125551xxx| Auth |------------> | Verif | .
. | Svc | . INVITE . | Svc | .
. | Proxy | . . | Proxy | .
. > +-------+ . . +-------+ \ .
. / | . -> \ .
. / | . --. \ .
. / | . -- . \ .
. / | . -- . \ .
. / +-------+. -- . \ .
. / | |.<- . \ .
. / | Cert |. . > .
. +-------+ | Store |. . +-------+ .
. | | | |. . | | .
. | Bob | +-------+. . | Alice | .
. | UA | . . | UA | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................
The proxy authenticates Bob and validates that he is authorized to assert the identity that he populated in the From header field. The proxy authentication service then constructs a PASSporT that contains a JSON representation of values that mirror certain parts of the SIP request, including the identity in the From header field value. As a part of generating the PASSporT, the authentication service signs a hash of that JSON header and payload with the private key associated with the appropriate credential for the identity (in this example, a certificate with authority to sign for numbers in a range from 12155551000 to 12155551999), and the signature is inserted by the proxy server into the Identity header field value of the request as a compact form of PASSporT. Alternatively, the JSON header and payload themselves might also have been included in the object when using the full form of PASSporT.
プロキシはBobを認証し、Fromヘッダーフィールドに設定された識別情報をBobが主張する権限を持つことを確認します。次にプロキシ上の認証サービスは、Fromヘッダーフィールド値の識別情報など、SIPリクエストの一部を反映する値をJSONで表したPASSporTを作成します。認証サービスはPASSporTの生成時に、適切な資格情報に対応する秘密鍵でJSONヘッダーとペイロードのハッシュに署名します。この例では、その資格情報は12155551000から12155551999までの番号に署名する権限を持つ証明書です。プロキシサーバーは署名をコンパクト形式のPASSporTとしてリクエストのIdentityヘッダーフィールド値に挿入します。完全形式を使う場合は、JSONヘッダーとペイロードもオブジェクトに含められます。
The proxy authentication service, as the holder of a private key with authority over Bob's telephone number, is asserting that the originator of this request has been authenticated and that he is authorized to claim the identity that appears in the From header field. The proxy inserts an "info" parameter into the Identity header field that tells Alice how to acquire keying material necessary to validate its credentials (a public key), in case she doesn't already have it.
プロキシ上の認証サービスは、Bobの電話番号に対する権限を持つ秘密鍵の保有者として、このリクエストの発信者が認証済みであり、Fromヘッダーフィールドに示された識別情報を主張する権限を持つことを表明します。プロキシはIdentityヘッダーフィールドに "info" パラメーターを挿入し、Aliceがまだ持っていない場合に、資格情報（公開鍵）を検証するための鍵素材を取得できる場所を示します。
When Alice's domain receives the request, a proxy verification service validates the signature provided in the Identity header field and then determines that the authentication service credentials demonstrate authority over the identity in the From header field. This same validation operation might be performed by a verification service in Alice's UA server (UAS). Ultimately, this valid request is rendered to Alice. If the validation were unsuccessful, some other treatment could be applied by the receiving domain or Alice's UA.
Aliceのドメインがリクエストを受信すると、プロキシ上の検証サービスはIdentityヘッダーフィールドの署名を検証し、認証サービスの資格情報がFromヘッダーフィールド内の識別情報に対する権限を示していることを確認します。AliceのUAサーバー（UAS）上の検証サービスが同じ検証を行う場合もあります。最終的に、この有効なリクエストはAliceに提示されます。検証に失敗した場合、受信ドメインまたはAliceのUAは別の処理を適用できます。
For the following SIP request:
次のSIPリクエストの場合：
INVITE sip:alice@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Alice <sip:alice@example.com>
From: Bob <sip:12155551212@example.com;user=phone>;tag=1928301774>
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Fri, 25 Sep 2015 19:12:25 GMT
Contact: <sip:12155551212@gateway.example.com>
Content-Type: application/sdp
Content-Length: ...
v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP
c=IN IP4 pc33.atlanta.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
An authentication service will create a corresponding PASSporT object. The properly serialized PASSporT header and payload JSON objects would look as follows. For the header, the values chosen by the authentication service at "example.com" might read:
認証サービスは、対応するPASSporTオブジェクトを作成します。適切にシリアル化されたPASSporTヘッダーとペイロードJSONオブジェクトは次のようになります。ヘッダーの場合、「example.com」の認証サービスによって選択された値は次のようになります。
{"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/
passport.cer"}
The serialized payload will derive values from the SIP request (the From, To, and Date header field values) as follows:
シリアル化されたペイロードは、次のようにSIP要求から値（From、To、およびDateヘッダーフィールド値）を取得します。
{"dest":{"uri":["sip:alice@example.com"]},"iat":1443208345,
"orig":{"tn":"12155551212"}}
The authentication service would then generate the signature over the object, following the procedures in [RFC8225], Section 6. That signature would look as follows:
[RFC8225]、セクション6の手順に従って、認証サービスはオブジェクトに対して署名を生成します。その署名は次のようになります。
rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ ojNCpTzO3QfPOlckGaS6hEck7w
rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ ojNCpTzO3QfPOlckGaS6hEck7w
An authentication service signing this request and using the compact form of PASSporT would thus generate and add to the request an Identity header field of the following form:
したがって、このリクエストに署名し、PASSporTのコンパクト形式を使用する認証サービスは、次の形式のIdentityヘッダーフィールドを生成してリクエストに追加します。
Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \
lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
info=<https://cert.example.org/passport.cer>
SIP entities that instantiate the authentication service and verification service roles will, respectively, generate and validate the Identity header and the signature it contains.
認証サービスと検証サービスの役割をインスタンス化するSIPエンティティは、それぞれ、Identityヘッダーとそれに含まれる署名を生成および検証します。
Any entity that instantiates the authentication service role MUST possess the private key of one or more credentials that can be used to sign for a domain or a telephone number (see Section 7.1). The authentication service role can be instantiated, for example, by an intermediary such as a proxy server or by a UA. Intermediaries that instantiate this role MUST be capable of authenticating one or more SIP users who can register for that identity. Commonly, this role will be instantiated by a proxy server, since proxy servers are more likely to have a static hostname, hold corresponding credentials, and have access to SIP registrar capabilities that allow them to authenticate users. It is also possible that the authentication service role might be instantiated by an entity that acts as a redirect server, but that is left as a topic for future work.
認証サービスの役割を担うエンティティは、ドメインまたは電話番号に署名するために使える1つ以上の資格情報の秘密鍵を保有しなければなりません (MUST)（Section 7.1を参照）。この役割は、プロキシサーバーなどの仲介者やUAが担えます。この役割を担う仲介者は、その識別情報に登録できる1人以上のSIPユーザーを認証できなければなりません (MUST)。通常はプロキシサーバーがこの役割を担います。プロキシサーバーは静的なホスト名を持ち、対応する資格情報を保持し、ユーザー認証を可能にするSIPレジストラー機能にアクセスできる可能性が高いためです。リダイレクトサーバーとして動作するエンティティが認証サービスの役割を担うことも考えられますが、これは今後の課題です。
An authentication service adds the Identity header field to SIP requests. The procedures below define the steps that must be taken when each Identity header field is added. More than one Identity header field may appear in a single request, and an authentication service may add an Identity header field to a request that already contains one or more Identity header fields.
認証サービスはSIPリクエストにIdentityヘッダーフィールドを追加します。以下の手順では、Identityヘッダーフィールドを追加するたびに必要となる処理を定めます。1つのリクエストに複数のIdentityヘッダーフィールドが含まれる場合があり、認証サービスは、すでに1つ以上のIdentityヘッダーフィールドを含むリクエストにも別のフィールドを追加できます。
Entities instantiating the authentication service role perform the following steps, in order, to generate an Identity header field for a SIP request:
認証サービスの役割を担うエンティティは、SIPリクエストのIdentityヘッダーフィールドを生成するため、次の手順を順番に実行します。
Step 1: Check Authority for the Identity
ステップ1：IDの権限を確認する
First, the authentication service must determine whether it is authoritative for the identity of the originator of the request. The authentication service extracts the identity from the URI value from the "identity field"; in ordinary operations, that is the addr-spec component of the From header field. In order to determine whether the signature for the identity field should be over the entire identity field URI or just a telephone number, the authentication service MUST follow the process described in Section 8.1. The information in that section will lead to either the telephone number canonicalization procedures in Section 8.3 for telephone numbers or the URI normalization procedures described in Section 8.5 for domain names. Whichever the result, if the authentication service is not authoritative for the identity in question, it SHOULD process and forward the request normally unless the local policy is to block such requests. The authentication service MUST NOT add an Identity header field if the authentication service does not have the authority to make the claim it asserts.
まず、認証サービスは、要求の発信者の識別情報について自らが権限を持つかどうかを判断する必要があります。認証サービスは "identity field" のURI値から識別情報を取り出します。通常の運用では、これはFromヘッダーフィールドのaddr-spec要素です。署名対象をidentity fieldのURI全体にするか電話番号だけにするかを判断するため、認証サービスはSection 8.1の手順に従わなければなりません (MUST)。同節の手順により、電話番号の場合はSection 8.3の電話番号正規化手順へ、ドメイン名の場合はSection 8.5のURI正規化手順へ進みます。認証サービスがその識別情報に対する権限を持たない場合は、ローカルポリシーでブロックすることになっていない限り、通常どおりリクエストを処理して転送すべきです (SHOULD)。認証サービスは、自らが主張する内容を主張する権限を持たない場合、Identityヘッダーフィールドを追加してはなりません (MUST NOT)。
Step 2: Authenticate the Originator
ステップ2：発信者を認証する
The authentication service MUST then determine whether or not the originator of the request is authorized to claim the identity given in the identity field. In order to do so, the authentication service MUST authenticate the originator of the message. Some possible ways in which this authentication might be performed include the following:
認証サービスは次に、要求の発信者がidentity fieldに示された識別情報を主張する権限を持つかどうかを判断しなければなりません (MUST)。そのために、認証サービスはメッセージの発信者を認証しなければなりません (MUST)。この認証には、たとえば次の方法があります。
o If the authentication service is instantiated by a SIP intermediary (proxy server), it may authenticate the request with the authentication scheme used for registration in its domain (e.g., Digest authentication).
o 認証サービスがSIP仲介（プロキシサーバー）によってインスタンス化される場合、そのドメインへの登録に使用される認証スキーム（ダイジェスト認証など）を使用して要求を認証できます。
o If the authentication service is instantiated by a SIP UA, a UA may authenticate its own user through any system-specific means, perhaps simply by virtue of having physical access to the UA.
o 認証サービスがSIP UAによってインスタンス化される場合、UAは、おそらくUAへの物理的なアクセスを利用することにより、システム固有の手段を介して自身のユーザーを認証できます。
Authorization of the use of a particular username or telephone number in the user part of the From header field is a matter of local policy for the authentication service; see Section 7.1 for more information.
Fromヘッダーフィールドのユーザー部分での特定のユーザー名または電話番号の使用の承認は、認証サービスのローカルポリシーの問題です。詳細については、セクション7.1を参照してください。
Note that this check is performed only on the addr-spec in the identity field (e.g., the URI of the originator, like "sip:alice@atlanta.example.com"); it does not cover the display-name portion of the From header field (e.g., "Alice Atlanta"). For more information, see Section 12.6.
この確認の対象はidentity fieldのaddr-spec（発信者のURIである "sip:alice@atlanta.example.com" など）だけです。Fromヘッダーフィールドのdisplay-name部分（"Alice Atlanta" など）は対象外です。詳細についてはSection 12.6を参照してください。
Step 3: Verify Date is Present and Valid
ステップ3：日付が存在し、有効であることを確認する
An authentication service MUST add a Date header field to SIP requests that do not have one. The authentication service MUST ensure that any preexisting Date header field in the request is accurate. Local policy can dictate precisely how accurate the Date must be; a RECOMMENDED maximum discrepancy of sixty seconds will ensure that the request is unlikely to upset any verifiers. If the Date header field value contains a time different by more than one minute from the current time noted by the authentication service, the authentication service SHOULD reject the request. Finally, the authentication service MUST verify that both the Date header field and the current time fall within the validity period of its credential.
認証サービスは、DateヘッダーフィールドのないSIPリクエストにDateヘッダーフィールドを追加しなければなりません (MUST)。また、リクエストにすでにあるDateヘッダーフィールドが正確であることを確認しなければなりません (MUST)。Dateの許容精度はローカルポリシーで厳密に定められます。最大60秒の差が推奨されます (SHOULD)。この範囲なら、検証者がリクエストを拒否する可能性は低くなります。Dateヘッダーフィールドの時刻が認証サービスの把握する現在時刻から1分を超えてずれている場合、認証サービスはリクエストを拒否すべきです (SHOULD)。最後に、Dateヘッダーフィールドの時刻と現在時刻の両方が資格情報の有効期間内にあることを検証しなければなりません (MUST)。
See Section 12.1 for information on how the Date header field assists verifiers.
Dateヘッダーフィールドがベリファイアを支援する方法については、セクション12.1を参照してください。
Step 4: Populate and Add the Identity Header
ステップ4：IDヘッダーに入力して追加する
Subsequently, the authentication service MUST form a PASSporT object and add a corresponding Identity header field to the request containing either the full or compact form of PASSporT. For the baseline PASSporT header (headers containing no "ppt" parameter), this follows the procedures in Section 4; if the authentication service is using an alternative "ppt" format, it MUST add an appropriate "ppt" parameter and follow the procedures associated with that extension (see Section 9). After the Identity header field has been added to the request, the authentication service MUST also add an "info" parameter to the Identity header field. The "info" parameter contains a URI from which the authentication service's credential can be acquired; see Section 7.3 for more on credential acquisition.
続いて、認証サービスはPASSporTオブジェクトを形成し、対応するIdentityヘッダーフィールドを、PASSporTの完全な形式またはコンパクトな形式のいずれかを含む要求に追加しなければなりません (MUST)。ベースラインPASSporTヘッダー（「ppt」パラメーターを含まないヘッダー）の場合、これはセクション4の手順に従います。認証サービスが代替の「ppt」フォーマットを使用している場合、適切な「ppt」パラメーターを追加し、その拡張に関連する手順に従わなければなりません (MUST)（セクション9を参照）。 Identityヘッダーフィールドがリクエストに追加された後、認証サービスは「info」パラメーターをIdentityヘッダーフィールドに追加しなければなりません (MUST)。 「info」パラメーターには、認証サービスの資格情報を取得できるURIが含まれています。資格取得の詳細については、セクション7.3を参照してください。
An authentication service MAY use the full form of the PASSporT in the Identity header field. The presence of the full form is OPTIONAL because the information carried in the baseline PASSporT headers and claims is usually redundant with information already carried elsewhere in the SIP request. Using the compact form can significantly reduce SIP message size, especially when the PASSporT payload contains media keys. The syntax of the compact form is given in [RFC8225], Section 7; essentially, it contains only the signature component of the PASSporT.
認証サービスは、IdentityヘッダーフィールドでPASSporTの完全形式を使ってもよいです (MAY)。ベースラインPASSporTのヘッダーとクレームに含まれる情報は、通常SIPリクエストの別の箇所にもあり重複するため、完全形式の使用は任意です (MAY)。コンパクト形式を使うと、特にPASSporTペイロードにメディア鍵が含まれる場合、SIPメッセージのサイズを大幅に削減できます。コンパクト形式の構文は[RFC8225] Section 7で規定されています。基本的にはPASSporTの署名要素だけを含みます。
Note that per the behavior specified in [RFC8225], use of the full form is mandatory when optional extensions are included. See Section 9.
[RFC8225]が規定する動作では、任意の拡張機能を含める場合、完全形式を使う必要があります。Section 9を参照してください。
Also, in some cases, a request signed by an authentication service will be rejected by the verification service on the receiving side, and the authentication service will receive a SIP 4xx status code in the backwards direction, such as a 438 ("Invalid Identity Header") response indicating a verification failure. If the authentication service did not originally send the full form of the PASSporT object in the Identity header field, it SHOULD retry the request with the full form after receiving a 438 response; however, implementations SHOULD NOT retry the request more than once. Authentication services implemented at proxy servers would retry such a request as a sequential fork, by reprocessing the destination as a new target and handling it serially as described in Section 16.6 of [RFC3261].
場合によっては、認証サービスが署名したリクエストを受信側の検証サービスが拒否し、検証失敗を示す438（"Invalid Identity Header"）などのSIP 4xxステータスコードが認証サービスに逆方向から返されます。認証サービスがIdentityヘッダーフィールドにPASSporTの完全形式を付けずに送信していた場合、438応答を受信した後、完全形式を付けてリクエストを再試行すべきです (SHOULD)。ただし、実装はリクエストを2回以上再試行すべきではありません (SHOULD NOT)。プロキシサーバー上の認証サービスは、宛先を新しいターゲットとして再処理し、[RFC3261] Section 16.6の説明どおり順次処理することで、逐次フォークとして再試行します。
The information in the full form is useful on the verification side for debugging errors, and there are some known causes of verification failures (such as the Date header field value changing in transit; see Section 12.1 for more information) that can be resolved by the inclusion of the full form of PASSporT.
完全形式の情報は、検証側でエラーをデバッグする際に役立ちます。また、転送中にDateヘッダーフィールドの値が変わる場合など、検証失敗の既知の原因の一部は（詳細はSection 12.1を参照）、PASSporTの完全形式を含めることで解消できます。
Finally, the authentication service forwards the message normally.
最後に、認証サービスはメッセージを通常どおり転送します。
This document specifies a logical role for SIP entities; this role is called a verification service, or verifier. When a verifier receives a SIP message containing one or more Identity header fields, it inspects the signature(s) to verify the identity of the originator of the message. The results of a verification are provided as input to an authorization process that is outside the scope of this document.
本書は、SIPエンティティが担う論理的な役割として、verification service（Verifier）を規定します。Verifierは1つ以上のIdentityヘッダーフィールドを含むSIPメッセージを受信すると、署名を調べて発信者の識別情報を検証します。検証結果は、本書の範囲外である認可処理への入力として使われます。
A SIP request may contain zero, one, or more Identity header fields. A verification service performs the steps below on each Identity header field that appears in a request. If a verification service cannot use any Identity header in a request, due to the absence of Identity headers or unsupported "ppt" parameters, and the presence of an Identity header field is required by local policy (for example, based on a per-sending-domain policy or a per-sending-user policy), then a 428 "Use Identity Header" response MUST be sent in the backwards direction. For more on this and other verifier responses, see Section 6.2.2.
SIPリクエストにはIdentityヘッダーフィールドが0個、1個、または複数個含まれる場合があります。検証サービスは、リクエストに含まれる各Identityヘッダーフィールドについて以下の手順を実行します。Identityヘッダーがない場合、または未対応の "ppt" パラメーターがあるため検証サービスがどのIdentityヘッダーも利用できず、ローカルポリシー（送信ドメイン別または送信ユーザー別のポリシーなど）がIdentityヘッダーフィールドを要求する場合、428 "Use Identity Header" 応答を逆方向に送信しなければなりません (MUST)。この応答や他の検証サービスの応答についてはSection 6.2.2を参照してください。
In order to verify an Identity header field in a message, an entity acting as a verifier MUST perform the following steps, in the order specified below. Note that when an Identity header field contains a full-form PASSporT object, the verifier MUST follow the additional procedures in Section 6.2.4.
メッセージ内のIdentityヘッダーフィールドを検証するため、Verifierとして動作するエンティティは、以下の手順を指定順に実行しなければなりません (MUST)。IdentityヘッダーフィールドにPASSporTの完全形式が含まれる場合、VerifierはSection 6.2.4の追加手順にも従わなければなりません (MUST)。
Step 1: Check for an Unsupported "ppt"
手順1：サポートされていない「ppt」を確認する
The verifier MUST inspect any optional "ppt" parameter appearing in the Identity header. If no "ppt" parameter is present, then the verifier proceeds normally with Steps 2 through 5. If a "ppt" parameter value is present and the verifier does not support it, it MUST ignore the Identity header field. If a supported "ppt" parameter value is present, the verifier proceeds with Step 2 and will ultimately follow the "ppt" variations described in Step 5.
Verifierは、Identityヘッダーにある任意の "ppt" パラメーターを調べなければなりません (MUST)。"ppt" パラメーターがなければ、Verifierは通常どおりStep 2からStep 5に進みます。"ppt" パラメーター値があり、Verifierがそれに対応していない場合、Identityヘッダーフィールドを無視しなければなりません (MUST)。対応する値がある場合、VerifierはStep 2に進み、最終的にStep 5で説明する "ppt" 固有の手順に従います。
Step 2: Determine the Originator's Identity
ステップ2：発信者のIDを決定する
In order to determine whether the signature for the identity field should be over the entire identity field URI or just a telephone number, the verification service MUST follow the process described in Section 8.1. The information in that section will lead to either the telephone number canonicalization procedures in Section 8.3 for telephone numbers or the URI normalization procedures described in Section 8.5 for domain names.
署名対象をidentity fieldのURI全体にするか電話番号だけにするかを判断するため、検証サービスはSection 8.1の手順に従わなければなりません (MUST)。同節の手順により、電話番号の場合はSection 8.3の電話番号正規化手順へ、ドメイン名の場合はSection 8.5のURI正規化手順へ進みます。
Step 3: Identify Credential for Validation
ステップ3：検証のための資格情報を特定する
The verifier must ensure that it has access to the proper keying material to validate the signature in the Identity header field; this usually involves dereferencing a URI in the "info" parameter of the Identity header field. See Section 7.2 for more information on these procedures. If the verifier does not support the credential described in the "info" parameter, then it treats the credential for this header field as unsupported.
Verifierは、Identityヘッダーフィールドの署名を検証するために必要な鍵素材を取得できることを確認します。通常はIdentityヘッダーフィールドの "info" パラメーターにあるURIを逆参照します。この手順の詳細はSection 7.2を参照してください。"info" パラメーターが示す資格情報に対応していない場合、Verifierはそのヘッダーフィールドの資格情報を未対応として扱います。
Step 4: Check the Freshness of Date
ステップ4：日付の鮮度を確認する
The verifier furthermore ensures that the value of the Date header field of the request meets local policy for freshness (sixty seconds is RECOMMENDED) and that it falls within the validity period of the credential used to sign the Identity header field. For more on the attacks this prevents, see Section 12.1. If the full form of the PASSporT is present, the verifier SHOULD compare the "iat" value in the PASSporT to the Date header field value in the request. If the two are different, and the "iat" value differs from the Date header field value but remains within verification service policy for freshness, the verification service SHOULD perform the computation required by Step 5, using the "iat" value instead of the Date header field value.
Verifierはさらに、リクエストのDateヘッダーフィールド値が鮮度に関するローカルポリシーを満たし（60秒以内の差が推奨されます (SHOULD)）、Identityヘッダーフィールドの署名に使われた資格情報の有効期間内にあることを確認します。これによって防止できる攻撃についてはSection 12.1を参照してください。PASSporTの完全形式がある場合、VerifierはPASSporT内の "iat" 値をリクエストのDateヘッダーフィールド値と比較すべきです (SHOULD)。両者が異なり、"iat" 値がDateヘッダーフィールド値とは異なるものの検証サービスの鮮度ポリシーの範囲内にある場合、検証サービスはDateヘッダーフィールド値の代わりに "iat" 値を使ってStep 5で必要となる計算を行うべきです (SHOULD)。
Step 5: Validate the Signature
ステップ5：署名を検証する
The verifier MUST validate the signature in the Identity header field over the PASSporT object. For baseline PASSporT objects (with no Identity header field "ppt" parameter), the verifier MUST follow the procedures for generating the signature over a PASSporT object as described in Section 4. If a "ppt" parameter is present (and, per Step 1, is supported), the verifier follows the procedures for that "ppt" (see Section 9). If a verifier determines that the signature in the Identity header field does not correspond to the reconstructed signed-identity-digest, then the Identity header field should be considered invalid.
Verifierは、Identityヘッダーフィールド内の署名をPASSporTオブジェクトに対して検証しなければなりません (MUST)。ベースラインPASSporTオブジェクト（Identityヘッダーフィールドに "ppt" パラメーターがないもの）では、VerifierはSection 4で説明するPASSporTオブジェクトへの署名手順に従わなければなりません (MUST)。"ppt" パラメーターがあり、Step 1で対応済みと確認された場合、Verifierはその "ppt" の手順に従います（Section 9を参照）。Identityヘッダーフィールドの署名が再構成したsigned-identity-digestと一致しない場合、そのIdentityヘッダーフィールドは無効と見なすべきです。
The verification of an Identity header field does not entail any particular treatment of the request. The handling of the message after the verification process depends on how the verification service is implemented and on local policy. This specification does not propose any authorization policy for UAs or proxy servers to follow based on the presence of a valid Identity header field, the presence of an invalid Identity header field, the absence of an Identity header field, or the presence of a stale Date header field value. However, it is anticipated that local policies could involve making different forwarding decisions in intermediary implementations, or changing how the user is alerted or how identity is rendered in UA implementations.
Identityヘッダーフィールドを検証しても、リクエストに対する具体的な処理方法は決まりません。検証後のメッセージ処理は、検証サービスの実装とローカルポリシーによって異なります。本仕様は、有効または無効なIdentityヘッダーフィールドの有無、Identityヘッダーフィールドの欠如、あるいは古いDateヘッダーフィールド値に基づいてUAやプロキシサーバーが従う認可ポリシーを提案しません。ただし、ローカルポリシーにより、仲介者の転送判断を変えたり、UAでユーザーへの通知方法や識別情報の表示方法を変えたりすることは想定されます。
The presence of multiple Identity header fields within a message raises the prospect that a verification service could receive a message containing both valid and invalid Identity header fields. As a guideline, this specification recommends that only if a verifier determines that all Identity header fields within a message are invalid should the request be considered to have an invalid identity. If at least one Identity header field value is valid and from a trusted source, then relying parties can use that header for authorization decisions regardless of whether other untrusted or invalid Identity headers appear in a request.
メッセージに複数のIdentityヘッダーフィールドがあると、検証サービスが有効なものと無効なものの両方を受信する可能性があります。指針として、本仕様は、メッセージ内のすべてのIdentityヘッダーフィールドが無効だとVerifierが判断した場合に限り、リクエストの識別情報を無効と見なすことを推奨します。少なくとも1つのIdentityヘッダーフィールド値が有効で信頼できる送信元のものであれば、依拠当事者は、他の信頼できない、または無効なIdentityヘッダーがリクエストに含まれていても、そのフィールドを認可判断に使えます。
[RFC4474] originally defined four response codes for failure conditions specific to the Identity header field and its original mechanism. These status codes are retained in this specification, with some slight modifications. Also, this specification details responding with a 403 "Forbidden" response when a stale Date header field value is received; see below.
[RFC4474]は、当初、Identityヘッダーフィールドとその元のメカニズムに固有の障害条件に対して4つの応答コードを定義しました。これらのステータスコードは、若干の変更を加えて、この仕様で保持されています。また、この仕様では、古いDateヘッダーフィールド値が受信されたときに403 "Forbidden"応答で応答することを詳しく説明しています。下記参照。
A 428 response will be sent (per Section 6.2) when an Identity header field is required but no Identity header field without a "ppt" parameter or with a supported "ppt" value has been received. In the case where one or more Identity header fields with unsupported "ppt" values have been received, then a verification service may send a 428 with a human-readable reason phrase like "Use Supported PASSporT Format". Note, however, that this specification gives no guidance on how a verification service might decide to require an Identity header field for a particular SIP request. Such authorization policies are outside the scope of this specification.
Identityヘッダーフィールドが必要であるにもかかわらず、"ppt" パラメーターのないIdentityヘッダーフィールドも、対応する "ppt" 値を持つIdentityヘッダーフィールドも受信していない場合、Section 6.2に従って428応答を送信します。未対応の "ppt" 値を持つIdentityヘッダーフィールドだけを受信した場合、検証サービスは "Use Supported PASSporT Format" のような人が読める理由句を付けて428応答を送信できます。ただし、特定のSIPリクエストでIdentityヘッダーフィールドを必須とするかを検証サービスがどう判断するか、本仕様は指針を示しません。このような認可ポリシーは本仕様の範囲外です。
The 436 "Bad Identity Info" response code indicates an inability to acquire the credentials needed by the verification service for validating the signature in an Identity header field. Again, given the potential presence of multiple Identity header fields, this response code should only be sent when the verification service is unable to dereference the URIs and/or acquire the credentials associated with all Identity header fields in the request. This failure code could be repairable if the authentication service resends the request with an "info" parameter pointing to a credential that the verification service can access.
436 "Bad Identity Info" 応答コードは、Identityヘッダーフィールドの署名検証に必要な資格情報を検証サービスが取得できないことを示します。リクエストに複数のIdentityヘッダーフィールドがある場合、この応答コードを送信するのは、検証サービスがすべてのURIを逆参照できない、またはリクエスト内のすべてのIdentityヘッダーフィールドに対応する資格情報を取得できない場合に限るべきです。この失敗は、認証サービスが検証サービスからアクセスできる資格情報を指す "info" パラメーターを付けてリクエストを再送すれば、解消できる場合があります。
The 437 "Unsupported Credential" response (previously "Unsupported Certificate"; see Section 13.2) is sent when a verification service can acquire, or already holds, the credential represented by the "info" parameter of at least one Identity header field in the request but does not support said credential(s), for reasons such as failing to trust the issuing certification authority (CA) or failing to support the algorithm with which the credential was signed.
リクエスト内の少なくとも1つのIdentityヘッダーフィールドについて、検証サービスが "info" パラメーターの示す資格情報を取得できる、またはすでに保持しているものの、その資格情報に対応していない場合、437 "Unsupported Credential" 応答（以前の名称は "Unsupported Certificate"。Section 13.2を参照）を送信します。対応できない理由には、発行元の認証局（CA）を信頼していないことや、資格情報への署名に使われたアルゴリズムをサポートしていないことなどがあります。
The 438 "Invalid Identity Header" response indicates that of the set of Identity header fields in a request, no header field with a valid and supported PASSporT object has been received. Like the 428 response, this is sent by a verification service when its local policy dictates that a broken signature in an Identity header field is grounds for rejecting a request. Note that in some cases, an Identity header field may be broken for other reasons than that an originator is attempting to spoof an identity: for example, when a transit network alters the Date header field of the request. Sending a full-form PASSporT can repair some of these conditions (see Section 6.2.4), so the recommended way to attempt to repair this failure is to retry the request with the full form of PASSporT if it had originally been sent with the compact form. The alternative reason phrase "Invalid PASSporT" can be used when an extended full-form PASSporT lacks required headers or claims, or when an extended full-form PASSporT signaled with the "ppt" parameter lacks required claims for that extension. Sending a string along these lines will help humans debugging the sending system.
438 "Invalid Identity Header" 応答は、リクエスト内のIdentityヘッダーフィールドに、有効で対応可能なPASSporTオブジェクトが1つもないことを示します。428応答と同様、ローカルポリシーが署名の破損をリクエスト拒否の理由とする場合に、検証サービスが送信します。発信者が識別情報を偽装しようとした場合以外にも、Identityヘッダーフィールドが無効になることがあります。たとえば、転送ネットワークがリクエストのDateヘッダーフィールドを変更した場合です。PASSporTの完全形式を送信すれば、このような状態の一部を解消できます（Section 6.2.4を参照）。そのため、コンパクト形式で送信していた場合に完全形式で再試行することが、修復を試みる推奨方法です。拡張された完全形式のPASSporTに必要なヘッダーまたはクレームがない場合や、"ppt" パラメーターで示された拡張の完全形式にその拡張で必要なクレームがない場合は、代替の理由句 "Invalid PASSporT" を使えます。このような理由句は、送信側システムのデバッグに役立ちます。
Finally, a 403 response may be sent when the verification service receives a request with a Date header field value that is older than the local policy for freshness permits. The same response may be used when the "iat" in the full form of a PASSporT has a value older than the local policy for freshness permits. The reason phrase "Stale Date" can be sent to help humans debug the failure.
検証サービスが、鮮度に関するローカルポリシーで許容される範囲より古いDateヘッダーフィールド値を持つリクエストを受信した場合、403応答を送信できます。PASSporTの完全形式に含まれる "iat" 値が同じ許容範囲より古い場合にも、同じ応答を使えます。デバッグに役立てるため、理由句 "Stale Date" を送信できます。
Future specifications may explore ways, including Reason codes or Warning headers, to communicate further information that could be used to disambiguate the source of errors in cases with multiple Identity headers in a single request or to provide similar detailed feedback for debugging purposes.
今後の仕様では、ReasonコードやWarningヘッダーなどを使って追加情報を伝え、1つのリクエストにIdentityヘッダーが複数ある場合にエラーの発生元を判別したり、デバッグ用の詳細情報を提供したりする方法を検討する可能性があります。
If a verification service sends a failure response in the backwards direction, the authentication service may retry the request as described in Section 6.1.1. If the authentication service is instantiated at a proxy server, then it will retry the request as a sequential fork. Verification services implemented at a proxy server will recognize this request as a spiral rather than a loop due to the proxy behavior fix documented in [RFC5393], Section 4.2. However, if the verification service is implemented in an endpoint, the endpoint will need to override the default UAS behavior (in particular, the SHOULD in [RFC3261], Section 8.2.2.2) to accept this request as a spiral rather than a loop.
検証サービスが逆方向に失敗応答を送信した場合、認証サービスはSection 6.1.1で説明するようにリクエストを再試行することがあります。認証サービスがプロキシサーバー上にある場合は、逐次フォークとして再試行します。[RFC5393] Section 4.2に記載されたプロキシ動作の修正により、プロキシ上の検証サービスはこのリクエストをループではなくスパイラルとして認識します。一方、エンドポイント上の検証サービスでは、リクエストをスパイラルとして受け入れるために、既定のUAS動作を上書きする必要があります。特に、[RFC3261] Section 8.2.2.2のSHOULDに従う動作を上書きします。
If the full form of PASSporT is present in an Identity header, this permits the use of optional extensions as described in [RFC8225], Section 8.3. Furthermore, the verification service can extract from the "orig" and "dest" elements of the PASSporT full form the canonical telephone numbers created by the authentication service, as well as an "iat" claim corresponding to the Date header field that the authentication service used. These values may be used to debug canonicalization problems or to avoid unnecessary signature breakage caused by intermediaries that alter certain SIP header field values in transit.
PASSporTの完全形式がIdentityヘッダーに含まれる場合、[RFC8225] Section 8.3で説明する任意の拡張機能を使えます。検証サービスはさらに、完全形式のPASSporTにある "orig" と "dest" から、認証サービスが生成した正規化済み電話番号を取り出せます。また、認証サービスが使ったDateヘッダーフィールドに対応する "iat" クレームも取り出せます。これらの値は、正規化の問題のデバッグや、転送中にSIPヘッダーフィールド値を変更する仲介者による不要な署名不一致の回避に役立ちます。
However, the verification service MUST NOT treat the value in the "orig" of a full-form PASSporT as the originating identity of the call: the originating identity of the call is always derived from the SIP signaling, and it is that value, per the procedures above in Section 6.2 Step 2, that is used to recompute the signature at the verification service. That value, rather than the value inside the PASSporT object, is rendered to an end user in ordinary SIP operations, and if a verification service were to simply trust that the value in the "orig" corresponded to the call that it received without comparing it to the call signaling, this would enable various cut-and-paste attacks. As an optimization, when the full form is present, the verification service MAY delay performing that cryptographic operation and first compute its own canonicalization of an originating telephone number to compare it to the values in the "orig" element of PASSporT. This would allow the verification service to ascertain whether or not the two ends agree on the canonical number form; if they do not, then surely the signature validation would fail.
ただし検証サービスは、PASSporT完全形式の "orig" の値を通話の発信元識別情報として扱ってはなりません (MUST NOT)。通話の発信元識別情報は常にSIPシグナリングから導出します。Section 6.2のStep 2に従って検証サービスが署名を再計算する際に使うのも、その値です。通常のSIP運用でエンドユーザーに表示するのはPASSporT内の値ではなく、シグナリングから得た値です。検証サービスがSIPシグナリングと照合せずに "orig" の値を受信した通話のものだと信頼すれば、さまざまな切り貼り攻撃が可能になります。最適化として、PASSporTの完全形式がある場合、検証サービスは暗号処理を後回しにし、まず発信元電話番号を独自に正規化して "orig" の値と比較してもよいです (MAY)。これにより、両端で正規化後の番号形式が一致するか確認できます。一致しなければ、署名検証は必ず失敗します。
This section gives general guidance on the use of credential systems by authentication and verification services, as well as requirements that must be met by credential systems that conform with this architecture. It does not mandate any specific credential system.
このセクションでは、認証および検証サービスによる資格情報システムの使用に関する一般的なガイダンスと、このアーキテクチャーに準拠する資格情報システムが満たす必要のある要件について説明します。特定の資格情報システムを義務付けるものではありません。
Furthermore, this specification allows either a UA or a proxy server to provide the authentication service function and/or the verification service function. For the purposes of end-to-end security, it is obviously preferable for end systems to acquire their own credentials; in this case, UAs can act as authentication services. However, for some deployments, end-user credentials may be neither practical nor affordable, given the potentially large number of SIP UAs (phones, PCs, laptops, PDAs, gaming devices) that may be employed by a single user. Synchronizing keying material across multiple devices may be prohibitively complex and require quite a good deal of additional endpoint behavior. Managing several credentials for the various devices could also be burdensome. Thus, for reasons of credential management alone, implementing the authentication service at an intermediary may be more practical. This trade-off needs to be understood by implementers of this specification.
さらに本仕様では、UAまたはプロキシサーバーのいずれも、認証サービス機能や検証サービス機能を提供できます。エンドツーエンドセキュリティのためには、エンドシステムが自ら資格情報を取得する方法が望ましく、その場合UAが認証サービスとして動作できます。しかし、1人のユーザーが多数のSIP UA（電話、PC、ラップトップ、PDA、ゲーム機など）を使う環境では、エンドユーザーごとの資格情報が現実的でない、または費用面で難しい場合があります。複数デバイス間で鍵素材を同期するのは非常に複雑で、エンドポイントに多くの追加動作が必要になる場合があります。各デバイスの資格情報を管理する負担もあります。そのため、資格情報の管理だけを考えれば、仲介者に認証サービスを実装する方が現実的な場合があります。実装者はこのトレードオフを理解する必要があります。
In order to act as an authentication service, a SIP entity must possess the private keying material of one or more credentials that cover domain names or telephone numbers. These credentials may represent authority over one domain (such as example.com) or a set of domains enumerated by the credential. Similarly, a credential may represent authority over a single telephone number or a range of telephone numbers. The way that the scope of a credential's authority is expressed is specific to the credential mechanism.
認証サービスとして動作するには、SIPエンティティはドメイン名または電話番号を対象とする1つ以上の資格情報の秘密鍵素材を保有する必要があります。資格情報は、example.comのような単一ドメイン、または資格情報に列挙された複数のドメインに対する権限を表す場合があります。同様に、単一の電話番号または電話番号範囲に対する権限を表す場合もあります。資格情報の権限範囲をどのように表すかは、資格情報機構によって異なります。
Authorization of the use of a particular username or telephone number in the From header field value is a matter of local policy for the authentication service, one that depends greatly on the manner in which authentication is performed. For non-telephone number user parts, one policy might be as follows: the username given in the "username" parameter of the Proxy-Authorization header field must correspond exactly to the username in the From header field of the SIP message. However, there are many cases in which this is too limiting or inappropriate; a realm might use "username" parameters in the Proxy-Authorization header field that do not correspond to the user portion of From header fields, or a user might manage multiple accounts in the same administrative domain. In this latter case, a domain might maintain a mapping between the values in the "username" parameter of the Proxy-Authorization header field and a set of one or more SIP URIs that might legitimately be asserted for that "username". For example, the username can correspond to the "private identity" as defined by the Third Generation Partnership Project (3GPP) [TS-3GPP.23.228], in which case the From header field can contain any one of the public identities associated with this private identity. In this instance, another policy might be as follows: the URI in the From header field must correspond exactly to one of the mapped URIs associated with the "username" given in the Proxy-Authorization header field. This is a suitable approach for telephone numbers in particular.
Fromヘッダーフィールド値で特定のユーザー名または電話番号を使うことを許可するかは、認証の方式に大きく依存する認証サービスのローカルポリシーです。電話番号ではないuser部分について、たとえば次のポリシーが考えられます。Proxy-Authorizationヘッダーフィールドの "username" パラメーターのユーザー名は、SIPメッセージのFromヘッダーフィールド内のユーザー名と完全に一致する必要があります。しかし、この条件が厳しすぎる、または不適切な場合もあります。たとえば、レルムがFromヘッダーフィールドのuser部分とは異なる "username" をProxy-Authorizationヘッダーフィールドで使う場合や、ユーザーが同じ管理ドメイン内で複数のアカウントを管理する場合です。後者の場合、ドメインはProxy-Authorizationヘッダーフィールドの "username" 値と、そのユーザー名で正当に主張できる1つ以上のSIP URIとの対応表を保持できます。たとえば、ユーザー名がThird Generation Partnership Project（3GPP）[TS-3GPP.23.228]の定義する "private identity" に対応する場合、Fromヘッダーフィールドにはそのprivate identityに関連付けられた公開識別情報のいずれかを含められます。この場合の別のポリシーとして、FromヘッダーフィールドのURIは、Proxy-Authorizationヘッダーフィールドの "username" に対応付けられたURIのいずれかと完全に一致する必要があります。この方法は特に電話番号に適しています。
This specification could also be used with credentials that cover a single name or URI, such as alice@example.com or sip:alice@example.com. This would require a modification to authentication service behavior to operate on a whole URI rather than a domain name. Because this is not believed to be a pressing use case, this is deferred to future work, but implementers should note this as a possible future direction.
この仕様は、alice@example.comやsip:alice@example.comのような単一の名前またはURIを対象とする資格情報にも利用できます。その場合、認証サービスの動作を変更し、ドメイン名ではなくURI全体を扱う必要があります。差し迫った用途ではないと考えられるため、今後の課題とします。実装者は、将来この方向に拡張される可能性に留意してください。
Exceptions to such authentication service policies arise for cases like anonymity; if the AoR asserted in the From header field uses a form like "sip:anonymous@example.com" (see [RFC3323]), then the "example.com" proxy might authenticate only that the user is a valid user in the domain and insert the signature over the From header field as usual.
匿名性などの場合は、このような認証サービスのポリシーに例外が生じます。Fromヘッダーフィールドで主張するAoRが "sip:anonymous@example.com" のような形式を使う場合（[RFC3323]を参照）、"example.com" のプロキシはユーザーがそのドメインの正規ユーザーであることだけを認証し、通常どおりFromヘッダーフィールドに署名できます。
In order to act as a verification service, a SIP entity must have a way to acquire credentials for authorities over particular domain names, telephone numbers, and/or number ranges. Dereferencing the URI found in the "info" parameter of the Identity header field (as described in Section 7.3) MUST be supported by all verification service implementations to create a baseline means of credential acquisition. Provided that the credential used to sign a message is not previously known to the verifier, SIP entities SHOULD discover this credential by dereferencing the "info" parameter, unless they have some implementation-specific way of acquiring the needed keying material, such as an offline store of periodically updated credentials. The 436 "Bad Identity Info" response exists for cases where the verification service cannot dereference the URI in the "info" parameter.
検証サービスとして動作するSIPエンティティは、特定のドメイン名、電話番号、または番号範囲に対する権限を示す資格情報を取得する手段を持つ必要があります。資格情報を取得する基本手段として、Identityヘッダーフィールドの "info" パラメーターにあるURIを逆参照する機能を、すべての検証サービス実装がサポートしなければなりません (MUST)（Section 7.3を参照）。署名に使われた資格情報をVerifierがまだ知らない場合、定期更新される資格情報のオフライン保管など、必要な鍵素材を取得する実装固有の手段がない限り、SIPエンティティは "info" パラメーターを逆参照して資格情報を取得すべきです (SHOULD)。検証サービスが "info" パラメーターのURIを逆参照できない場合に備え、436 "Bad Identity Info" 応答があります。
This specification does not propose any particular policy for a verification service to determine whether or not the holder of a credential is the appropriate party to sign for a given SIP identity. Guidance on this is deferred to credential mechanism specifications.
この仕様は、資格情報の所有者が特定のSIP IDに署名するための適切な当事者であるかどうかを決定する検証サービスの特定のポリシーを提案していません。これに関するガイダンスは、資格メカニズムの仕様に委ねられています。
Verification service implementations supporting this specification may wish to have some means of retaining credentials (in accordance with normal practices for credential lifetimes and revocation) in order to prevent themselves from needlessly downloading the same credential every time a request from the same identity is received. Credentials cached in this manner may be indexed in accordance with local policy: for example, by their scope of authority or by the URI given in the "info" parameter value. Further consideration of how to cache credentials is deferred to the credential mechanism specifications.
本仕様に対応する検証サービス実装は、同じ識別情報からリクエストを受信するたびに同じ資格情報を不要にダウンロードしないよう、資格情報の有効期間や失効に関する通常の慣行に従って資格情報を保持する手段を備えたいと考える場合があります。この方法でキャッシュした資格情報は、ローカルポリシーに従って索引付けできます。たとえば、権限範囲や "info" パラメーター値のURIを索引に使えます。資格情報のキャッシュ方法については、資格情報機構の仕様でさらに検討します。
An "info" parameter MUST contain a URI that dereferences to a resource that contains the public key components of the credential used by the authentication service to sign a request. It is essential that a URI in the "info" parameter be dereferencable by any entity that could plausibly receive the request. For common cases, this means that the URI SHOULD be dereferencable by any entity on the public Internet. In constrained deployment environments, a service private to the environment MAY be used instead.
"info" パラメーターには、リクエストの署名に認証サービスが使った資格情報の公開鍵要素を含むリソースを取得できるURIを含めなければなりません (MUST)。"info" パラメーターのURIは、そのリクエストを受信し得るすべてのエンティティが取得できる必要があります。一般的な環境では、パブリックインターネット上の任意のエンティティがそのURIを取得できるべきです (SHOULD)。制約のある導入環境では、代わりにその環境内のプライベートサービスを使ってもよいです (MAY)。
Beyond providing a means of accessing credentials for an identity, the "info" parameter further serves as a means of differentiating which particular credential was used to sign a request, when there are potentially multiple authorities eligible to sign. For example, imagine a case where a domain implements the authentication service role for a range of telephone numbers and a UA belonging to Alice has acquired a credential for a single telephone number within that range. Either would be eligible to sign a SIP request for the number in question. Verification services, however, need a means to differentiate which one performed the signature. The "info" parameter performs that function.
"info" パラメーターは、識別情報の資格情報を取得する手段であるだけでなく、署名できる権限主体が複数ある場合に、どの資格情報でリクエストに署名したかを区別する役割も持ちます。たとえば、ドメインが電話番号範囲に対する認証サービスを運用し、その範囲内の単一番号の資格情報をAliceのUAが取得したとします。ドメインの認証サービスもAliceのUAも、その番号に関するSIPリクエストに署名できます。しかし検証サービスは、どちらが署名したかを区別する必要があります。その役割を "info" パラメーターが担います。
This document makes no recommendation for the use of any specific credential system. Today, there are two primary credential systems in place for proving ownership of domain names: certificates (e.g., X.509 v3; see [RFC5280]) and the domain name system itself (e.g., DNS-Based Authentication of Named Entities (DANE); see [RFC6698]). It is envisioned that either could be used in the SIP identity context: an "info" parameter could, for example, give an HTTP URL of the Content-Type "application/pkix-cert" pointing to a certificate (following the conventions of [RFC2585]). The "info" parameter might use the DNS URL scheme (see [RFC4501]) to designate keys in the DNS.
本書は特定の資格情報システムを推奨しません。現在、ドメイン名の所有権を証明する主な資格情報システムは、証明書（X.509 v3など。[RFC5280]を参照）とDomain Name System自体（DNS-Based Authentication of Named Entities（DANE）など。[RFC6698]を参照）の2つです。どちらもSIPの識別情報に利用できます。たとえば、"info" パラメーターには、証明書を指すContent-Type "application/pkix-cert" のHTTP URLを指定できます（[RFC2585]の方式に従います）。また、"info" パラメーターでDNS URL schemeを使い、DNS内の鍵を指定することもできます（[RFC4501]を参照）。
While no comparable public credentials exist for telephone numbers, either approach could be applied to telephone numbers. A credential system based on certificates is given in [RFC8226], but this specification can work with other credential systems; for example, using the DNS was proposed in [CIDER].
電話番号に対応する公開資格情報はありませんが、どちらのアプローチも電話番号に適用できます。証明書に基づく資格情報システムは[RFC8226]で提供されていますが、この仕様は他の資格情報システムでも機能します。たとえば、DNSの使用は[CIDER]で提案されました。
In order for a credential system to work with this mechanism, its specification must detail:
資格情報システムがこのメカニズムで機能するためには、その仕様で詳細を指定する必要があります。
o which URI schemes the credential will use in the "info" parameter, and any special procedures required to dereference the URIs,
o 資格情報が「info」パラメーターで使用するURIスキーム、およびURIを逆参照するために必要な特別な手順
o how the verifier can learn the scope of the credential,
o 検証者が資格の範囲をどのように学習できるか、
o any special procedures required to extract keying material from the resources designated by the URI,
o URIで指定されたリソースからキー情報を抽出するために必要な特別な手順、
o any algorithms required to validate the credentials (e.g., for certificates, any algorithms used by certificate authorities to sign certificates themselves), and
o 資格情報を検証するために必要なアルゴリズム（証明書の場合、認証局が証明書自体に署名するために使用するアルゴリズムなど）、および
o how the associated credentials will support the mandatory signing algorithm(s) required by PASSporT [RFC8225].
o 関連する資格情報が、PASSporT [RFC8225]で必要とされる必須の署名アルゴリズムをどのようにサポートするか。
SIP entities cannot reliably predict where SIP requests will terminate. When choosing a credential scheme for deployments of this specification, it is therefore essential that the trust anchor(s) for credentials be widely trusted or that deployments restrict the use of this mechanism to environments where the reliance on particular trust anchors is assured by business arrangements or similar constraints.
SIPエンティティは、SIPリクエストが最終的にどこへ届くかを確実には予測できません。そのため、本仕様を導入する際に資格情報方式を選ぶときは、資格情報のtrust anchorが広く信頼されていること、または特定のtrust anchorへの依存が取引上の取り決めなどで保証された環境に導入を限定することが不可欠です。
Note that credential systems must address key lifecycle management concerns: were a domain to change the credential available at the Identity header field "info" parameter URI before a verifier evaluates a request signed by an authentication service, this would cause obvious verifier failures. When a rollover occurs, authentication services SHOULD thus provide new "info" URIs for each new credential and SHOULD continue to make older key acquisition URIs available for a duration longer than the plausible lifetime of a SIP transaction (a minute would most likely suffice).
資格情報システムは鍵のライフサイクル管理にも対処する必要があります。検証者が認証サービスによる署名済みリクエストを評価する前に、ドメインがIdentityヘッダーフィールドの "info" パラメーターURIで提供する資格情報を変更すると、検証に失敗することは明らかです。そのため鍵を更新する際、認証サービスは新しい資格情報ごとに新しい "info" URIを提供すべきです (SHOULD)。また、SIPトランザクションの妥当な存続期間（おそらく1分あれば十分です）より長い期間、古い鍵を取得するURIも引き続き利用可能にすべきです (SHOULD)。
The STIR problem statement [RFC7340] focuses primarily on cases where the called and calling parties identified in the To and From header field values use telephone numbers, as this remains the dominant use case in the deployment of SIP. However, the Identity header mechanism also works with SIP URIs without telephone numbers (of the form "sip:user@host") and, potentially, other identifiers when SIP interworks with other protocols.
STIRの問題提起[RFC7340]は主に、ToおよびFromヘッダーフィールド値で識別される着信側と発信側が電話番号を使う場合に焦点を当てています。SIPの導入では、これが依然として中心的な用途です。ただし、Identityヘッダー機構は、電話番号を含まないSIP URI（"sip:user@host" の形式）や、SIPが他のプロトコルと相互接続する場合の別の識別子にも利用できます。
Authentication services confirm the identity of the originator of a call, which is typically found in the From header field value. The guidance in this specification also applies to extracting the URI containing the originator's identity from the P-Asserted-Identity header field value instead of the From header field value. In some trusted environments, the P-Asserted-Identity header field is used in lieu of the From header field to convey the AoR or telephone number of the originator of a request; where it does, local policy might therefore dictate that the canonical identity derives from the P-Asserted-Identity header field rather than the From header field.
認証サービスは、通常Fromヘッダーフィールド値にある通話発信者の識別情報を確認します。本仕様の指針は、Fromヘッダーフィールド値の代わりにP-Asserted-Identityヘッダーフィールド値から発信者の識別情報を含むURIを取り出す場合にも適用されます。信頼された環境の一部では、要求発信者のAoRまたは電話番号を伝えるために、Fromヘッダーフィールドの代わりにP-Asserted-Identityヘッダーフィールドを使います。その場合、ローカルポリシーにより、正規化する識別情報の取得元をFromヘッダーフィールドではなくP-Asserted-Identityヘッダーフィールドとすることがあります。
Ultimately, in any case where local policy canonicalizes the identity into a form different from how it appears in the From header field, the use of the full form of PASSporT by authentication services is RECOMMENDED, but because the "orig" claim of PASSporT itself could then divulge information about users or networks, implementers should be mindful of the guidelines in Section 11.
ローカルポリシーによって識別情報をFromヘッダーフィールドとは異なる形式に正規化する場合、認証サービスはPASSporTの完全形式を使うことが推奨されます (SHOULD)。ただし、その場合PASSporTの "orig" クレームがユーザーやネットワークの情報を明らかにする可能性があるため、実装者はSection 11の指針に留意してください。
In order to determine whether or not the user portion of a SIP URI is a telephone number, authentication services and verification services MUST perform the following procedure on any SIP URI they inspect that contains a numeric user part. Note that the same procedures are followed for creating the canonical form of a URI found in the From header field as the procedures used for a URI found in the To header field or the P-Asserted-Identity header field.
SIP URIのuser部分が電話番号かどうかを判断するため、認証サービスと検証サービスは、数値を含むuser部分を持つSIP URIを調べる際に次の手順を実行しなければなりません (MUST)。Fromヘッダーフィールド内のURIを正規形にする場合も、ToまたはP-Asserted-Identityヘッダーフィールド内のURIに使う手順と同じ手順に従います。
First, implementations will ascertain if the user portion of the URI constitutes a telephone number. Telephone numbers most commonly appear in SIP header field values in the username portion of a SIP URI (e.g., "sip:+17005551008@chicago.example.com;user=phone"). The user part of SIP URIs with the "user=phone" parameter conforms to the syntax of the tel URI scheme [RFC3966]. It is also possible for a tel URI to appear in SIP header fields outside the context of a SIP or Session Initiation Protocol Secure (SIPS) URI (e.g., "tel:+17005551008"). Thus, in standards-compliant environments, numbers will be explicitly labeled by the use of tel URIs or the "user=phone" parameter.
まず実装は、URIのuser部分が電話番号かどうかを判定します。電話番号は通常、SIP URIのusername部分としてSIPヘッダーフィールド値に現れます（例: "sip:+17005551008@chicago.example.com;user=phone"）。"user=phone" パラメーターを持つSIP URIのuser部分は、tel URI scheme [RFC3966]の構文に従います。また、SIP URIまたはSession Initiation Protocol Secure（SIPS）URIの外で、tel URIがSIPヘッダーフィールドに現れる場合もあります（例: "tel:+17005551008"）。したがって標準に準拠する環境では、tel URIまたは "user=phone" パラメーターを使って電話番号を明示します。
Alternatively, implementations in environments that do not conform to those standards MAY follow local policies for identifying telephone numbers. For example, implementations could infer that the user part is a telephone number due to the presence of the "+" indicator at the start of the user portion. Absent even that indication, if there are numbers present in the user portion, implementations might conceivably also detect that the user portion of the URI contains a telephone number by determining whether or not those numbers would be dialable or routable in the local environment -- bearing in mind that the telephone number may be a valid E.164 number [E.164], a nationally specific number, or even a private branch exchange number. Implementations could also rely on external hints: for example, a verification service implementation could infer from the type of credential that signed a request that the signature must be over a telephone number.
これらの標準に準拠しない環境では、実装はローカルポリシーに従って電話番号を識別してもよいです (MAY)。たとえばuser部分の先頭に "+" があることから、電話番号だと推定できます。その手掛かりもなくuser部分に数字が含まれる場合は、その数字がローカル環境で発信またはルーティング可能かを調べて、URIのuser部分が電話番号を含むと判定することも考えられます。電話番号は有効なE.164番号[E.164]、国内固有の番号、または構内交換機の内線番号である可能性があることに留意してください。外部の手掛かりを使うこともできます。たとえば検証サービス実装は、リクエストに署名した資格情報の種類から、署名対象が電話番号であると推定できます。
Regardless of how the implementation detects telephone numbers, once a telephone number has been detected, implementations SHOULD follow the procedures in Section 8.3. If the URI field does not contain a telephone number or if the result of the canonicalization of the From header field value does not form a valid E.164 telephone number, the authentication service and/or verification service SHOULD treat the entire URI as a SIP URI and apply the procedures in Section 8.5. These URI normalization procedures are invoked to canonicalize the URI before it is included in a PASSporT object in, for example, a "uri" claim. See Section 8.5 for that behavior.
実装が電話番号を検出した方法にかかわらず、電話番号を検出した後はSection 8.3の手順に従うべきです (SHOULD)。URIフィールドに電話番号が含まれない場合、またはFromヘッダーフィールド値を正規化しても有効なE.164電話番号にならない場合、認証サービスや検証サービスはURI全体をSIP URIとして扱い、Section 8.5の手順を適用すべきです (SHOULD)。これらのURI正規化手順は、URIを "uri" クレームなどのPASSporTオブジェクトに含める前に正規化するために使います。詳細はSection 8.5を参照してください。
In order for telephone numbers to be used with the mechanism described in this document, authentication services must receive credentials from an authority for telephone numbers or telephone number ranges, and verification services must trust the authority employed by the authentication service that signs a request. Per Section 7.4, enrollment procedures and credential management are outside the scope of this document; approaches to credential management for telephone numbers are discussed in [RFC8226].
本書の機構で電話番号を使うには、認証サービスが電話番号または番号範囲の権限主体から資格情報を受け取り、検証サービスがリクエストに署名した認証サービスの権限主体を信頼する必要があります。Section 7.4にあるとおり、登録手順と資格情報管理は本書の範囲外です。電話番号の資格情報管理方式については[RFC8226]が説明しています。
Once an implementation has identified a telephone number, it must construct a number string. That requires performing the following steps:
実装が電話番号を識別したら、番号文字列を作成する必要があります。そのためには、次の手順を実行する必要があります。
o Implementations MUST drop any "+"s, internal dashes, parentheses, or other non-numeric characters, except for the "#" or "*" keys used in some special service numbers (typically, these will appear only in the To header field value). This MUST result in an ASCII string limited to "#", "*", and digits without whitespace or visual separators.
o 一部の特殊サービス番号で使う "#" または "*" を除き、"+"、番号内部のハイフン、括弧、その他の数字以外の文字を削除しなければなりません (MUST)（通常、これらの文字はToヘッダーフィールド値にだけ現れます）。その結果は、空白や視覚的な区切り文字を含まず、ASCIIの "#"、"*"、数字だけから成る文字列でなければなりません (MUST)。
o Next, an implementation must assess if the number string is a valid, globally routable number with a leading country code.
o 次に、実装は、数値文字列が有効なグローバルにルーティング可能な番号であり、先頭の国コードがあるかどうかを評価する必要があります。
If not, implementations SHOULD convert the number into E.164 format, adding a country code if necessary; this may involve transforming the number from a dial string (see [RFC3966]), removing any national or international dialing prefixes or performing similar procedures. It is only in the case that an implementation cannot determine how to convert the number to a globally routable format that this step may be skipped. This will be the case, for example, for nationally specific service numbers (e.g., 911, 112); however, calls to those numbers are routed in a very strict fashion, which ordinarily prevents them from reaching entities that don't understand the numbers.
該当しない場合、実装は必要に応じて国コードを追加し、番号をE.164形式に変換すべきです (SHOULD)。この変換には、ダイヤル文字列からの変換（[RFC3966]を参照）、国内または国際発信プレフィックスの削除、その他同様の処理が含まれることがあります。この手順を省略できるのは、実装が番号をグローバルにルーティング可能な形式へ変換する方法を判断できない場合に限ります。たとえば911や112など国内固有の緊急サービス番号が該当します。ただし、これらの番号への通話は非常に厳密にルーティングされるため、通常は番号を理解しないエンティティには届きません。
o Some domains may need to take unique steps to convert their numbers into a global format, and such transformations during canonicalization can also be made in accordance with specific policies used within a local domain. For example, one domain may only use local number formatting and need to convert all To/From header field user portions to E.164 by prepending country-code and region-code digits; another domain might have prefixed usernames with trunk-routing codes, in which case the canonicalization will need to remove the prefix. This specification cannot anticipate all of the potential transformations that might be useful.
o 一部のドメインでは、番号をグローバル形式に変換するために固有の処理が必要です。正規化時の変換は、そのローカルドメインで採用しているポリシーに従って行うこともできます。たとえば、市内番号だけを使うドメインでは、国コードと地域コードを先頭に付け、すべてのTo/Fromヘッダーフィールドのuser部分をE.164形式にする必要がある場合があります。別のドメインでは、usernameの前に中継ルーティングコードを付けていることがあり、その場合は正規化時にその接頭辞を取り除く必要があります。本仕様ですべての有用な変換を想定することはできません。
o The resulting canonical number string will be used as input to the hash calculation during signing and verifying processes.
o 結果として得られる正規の数値文字列は、署名および検証プロセス中にハッシュ計算への入力として使用されます。
The ABNF of this number string is:
この数値文字列のABNFは次のとおりです。
tn-spec = 1*tn-char
tn-char = "#" / "*" / DIGIT
The resulting number string is used in the construction of the telephone number field(s) in a PASSporT object.
結果の数値文字列は、PASSporTオブジェクトの電話番号フィールドの構築に使用されます。
To use a SIP URI as an identity in this mechanism requires authentication and verification systems to support standard mechanisms for proving authority over a domain name: that is, the domain name in the host portion of the SIP URI.
このメカニズムでSIP URIをIDとして使用するには、ドメイン名、つまりSIP URIのホスト部分のドメイン名に対する権限を証明するための標準メカニズムをサポートする認証および検証システムが必要です。
A verifier MUST evaluate the correspondence between the user's identity and the signing credential by following the procedures defined in [RFC5922], Section 7.2. While [RFC5922] deals with the use of TLS and is specific to certificates, the procedures described are applicable to verifying identity if one substitutes the "hostname of the server" for the domain portion of the user's identity in the From header field of a SIP request with an Identity header field.
This process is complicated by two deployment realities. In the first place, credentials have varying ways of describing their subjects and may indeed have multiple subjects, especially in "virtual hosting" cases where multiple domains are managed by a single application (see [RFC5922], Section 7.8). Secondly, some SIP services may delegate SIP functions to a subordinate domain and utilize the procedures in [RFC3263] that allow requests for, say, "example.com" to be routed to "sip.example.com". As a result, a user with the AoR "sip:alice@example.com" may process requests through a host like "sip.example.com", and it may be that latter host that acts as an authentication service.
この処理は、実際の導入環境にある2つの事情によって複雑になります。第一に、資格情報によってsubjectの記述方法が異なり、複数のsubjectを含むこともあります。単一のアプリケーションで複数のドメインを管理する "virtual hosting" の場合は特にそうです（[RFC5922] Section 7.8を参照）。第二に、一部のSIPサービスはSIP機能を下位ドメインに委任し、[RFC3263]の手順で "example.com" 宛てのリクエストを "sip.example.com" にルーティングします。その結果、AoRが "sip:alice@example.com" のユーザーのリクエストを "sip.example.com" のようなホストが処理し、そのホストが認証サービスとして動作する場合があります。
To address the second of these problems, a domain that deploys an authentication service on a subordinate host might supply that host with the private keying material associated with a credential whose subject is a domain name that corresponds to the domain portion of the AoRs that the domain distributes to users. Note that this corresponds to the comparable case of routing inbound SIP requests to a domain. When the NAPTR and SRV procedures of [RFC3263] are used to direct requests to a domain name other than the domain in the original Request-URI (e.g., for "sip:alice@example.com", the corresponding SRV records point to the service "sip1.example.org"), the client expects that the certificate passed back in any TLS exchange with that host will correspond exactly with the domain of the original Request-URI, not the domain name of the host.
2つ目の問題に対処するため、下位ホストに認証サービスを導入するドメインは、そのホストに秘密鍵素材を提供することがあります。その鍵素材は、ユーザーに配布するAoRのドメイン部分に対応するドメイン名をsubjectとする資格情報に関連付けられています。これは、着信SIPリクエストをドメインへルーティングする場合と同様です。[RFC3263]のNAPTRおよびSRV手順で、元のRequest-URIのドメインとは異なるドメイン名にリクエストを送る場合（例: "sip:alice@example.com" に対応するSRVレコードがサービス "sip1.example.org" を指す場合）、クライアントは、そのホストとのTLS交換で返される証明書がホスト自身のドメイン名ではなく、元のRequest-URIのドメインと正確に一致することを期待します。
Consequently, in order to make inbound routing to such SIP services work, a domain administrator must similarly be willing to share the domain's private key with the service. This design decision was made to compensate for the insecurity of the DNS, and it makes certain potential approaches to DNS-based "virtual hosting" unsecurable for SIP in environments where domain administrators are unwilling to share keys with hosting services.
したがって、このようなSIPサービスへの着信ルーティングを機能させるには、ドメイン管理者はドメインの秘密鍵をそのサービスと共有する必要があります。この設計はDNSのセキュリティ上の弱点を補うために採用されました。その結果、ドメイン管理者がホスティングサービスとの鍵共有を望まない環境では、DNSベースの "virtual hosting" をSIPで安全に実現できない方式があります。
Just as telephone numbers may undergo a number of syntactic transformations during transit, the same can happen to SIP and SIPS URIs without telephone numbers as they traverse certain intermediaries. Therefore, when generating a PASSporT object based on a SIP request, any SIP and SIPS URIs must be transformed into a canonical form that captures the AoR represented by the URI before they are provisioned in PASSporT claims such as "uri". The URI normalization procedures required are as follows.
電話番号が転送中に構文上の変換を受けるのと同様に、電話番号を含まないSIP URIやSIPS URIも、特定の仲介者を通過する間に変換されることがあります。そのため、SIPリクエストに基づいてPASSporTオブジェクトを生成する際は、"uri" クレームなどにURIを格納する前に、URIが表すAoRを保持する正規形へすべてのSIP URIとSIPS URIを変換する必要があります。必要なURI正規化手順は次のとおりです。
Following the ABNF of [RFC3261], the SIP or SIPS URI in question MUST discard all elements after the "hostport" of the URI, including all uri-parameters and escaped headers, from its syntax. Of the userinfo component of the SIP URI, only the user element will be retained: any password (and any leading ":" before the password) MUST be removed, and since this userinfo necessarily does not contain a telephone-subscriber component, no further parameters can appear in the user portion.
[RFC3261]のABNFに従い、対象のSIP URIまたはSIPS URIでは、URI構文から "hostport" より後ろの要素をすべて取り除かなければなりません (MUST)。これにはすべてのURIパラメーターとエスケープされたヘッダーが含まれます。SIP URIのuserinfo要素ではuserだけを残します。passwordと、その直前のコロン (":") を取り除かなければなりません (MUST)。このuserinfoにはtelephone-subscriber要素が含まれないため、user部分にそれ以外のパラメーターは現れません。
The hostport portion of the SIP or SIPS URI MUST similarly be stripped of any trailing port along with the ":" that proceeds the port, leaving only the host.
SIP URIまたはSIPS URIのhostport部分も同様に、ホストだけを残し、末尾のポート番号とその直前の ":" のコロンを取り除かなければなりません (MUST)。
The ABNF of this canonical URI form (following the syntax defined in [RFC3261]) is:
この正規URIフォームのABNF（[RFC3261]で定義された構文に従う）は次のとおりです。
canon-uri = ( "sip" / "sips" ) ":" user "@" host
Finally, the URI will be subject to the syntax-based URI normalization procedures of [RFC3986], Section 6.2.2. Implementations MUST perform case normalization (rendering the scheme, user, and host all lowercase) and percent-encoding normalization (decoding any percent-encoded octet that corresponds to an unreserved character, per [RFC3986], Section 2.3). However, note that normalization procedures face known challenges in some internationalized environments (see [IRI-COMPARISON]) and that perfect normalization of URIs may not be possible in those environments.
For future PASSporT applications, it may be desirable to provide an identifier without an attached protocol scheme. Future specifications that define PASSporT claims for SIP as a using protocol could use these basic procedures but could eliminate the scheme component. A more exact definition is left to future specifications.
将来のPASSporTアプリケーションでは、プロトコルスキームを付加せずに識別子を提供することが望ましい場合があります。 SIPのPASSporTクレームを使用プロトコルとして定義する将来の仕様では、これらの基本的な手順を使用できますが、スキームコンポーネントを削除できます。より正確な定義は将来の仕様に任されています。
As future requirements may warrant increasing the scope of the Identity mechanism, this specification specifies an optional "ppt" parameter of the Identity header field, which mirrors the "ppt" header in PASSporT. The "ppt" parameter value MUST consist of a token containing an extension specification, which denotes an extended set of one or more signed claims per the type extensibility mechanism specified in [RFC8225], Section 8. Note that per the guidance in that section, "ppt" is used only to enforce a mandatory extension: optional claims may be added to any PASSporT object without requiring the use of "ppt", but the compact form of PASSporT MUST NOT be used when optional claims are present in the PASSporT payload.
将来の要件によりIdentity機構の対象範囲を広げる必要が生じる可能性があるため、本仕様はIdentityヘッダーフィールドに任意の "ppt" パラメーターを定めています。このパラメーターはPASSporTの "ppt" ヘッダーに対応します。"ppt" パラメーター値は、拡張仕様を示すtokenでなければなりません (MUST)。この拡張仕様は、[RFC8225] Section 8で定義される型拡張機構に従い、署名対象のクレームを1つ以上拡張します。なお同節の指針に従い、"ppt" は必須の拡張を適用する場合に限って使います。任意のクレームは "ppt" なしでPASSporTオブジェクトに追加できますが、PASSporTペイロードに任意のクレームがある場合、コンパクト形式を使ってはなりません (MUST NOT)。
The potential for extensions is one of the primary motivations for allowing the presence of multiple Identity header fields in the same SIP request. It is envisioned that future extensions might allow for alternate information to be signed or explicitly allow different parties to provide the signatures than the authorities envisioned by baseline STIR. A request might, for example, have one Identity added by an authentication service at the originating administrative domain and then another Identity header field added by some further intermediary using a PASSporT extension. While this specification does not define any such specific purpose for multiple Identity header fields, implementations MUST support receiving multiple header fields for reasons of future compatibility.
拡張できることは、同じSIPリクエストに複数のIdentityヘッダーフィールドを許す主な理由の1つです。将来の拡張では、別の情報への署名や、ベースラインSTIRが想定する権限主体とは異なる主体による署名が可能になるかもしれません。たとえば、発信元の管理ドメインにある認証サービスがIdentityヘッダーフィールドを1つ追加し、さらに別の仲介者がPASSporT拡張を使ってもう1つ追加する場合があります。本仕様は複数のIdentityヘッダーフィールドを使う具体的な目的を定めませんが、将来の互換性のため、実装は複数のヘッダーフィールドを受信できなければなりません (MUST)。
An authentication service cannot assume that verifiers will understand any given extension. Verifiers that do support an extension may then trigger appropriate application-level behavior in the presence of an extension; authors of extensions should provide appropriate extension-specific guidance to application developers on this point.
認証サービスは、検証者が特定の拡張子を理解できるとは想定できません。拡張機能をサポートするベリファイアは、拡張機能が存在する場合に適切なアプリケーションレベルの動作をトリガーします。拡張機能の作成者は、この点に関してアプリケーション開発者に適切な拡張機能固有のガイダンスを提供する必要があります。
This specification introduces several significant changes from the version of the Identity header field defined by [RFC4474]. However, due to the problems enumerated in [SIP-RFC4474-CONCERNS], it is not believed that the original Identity header field has seen any deployment, or even implementation in deployed products.
本仕様は[RFC4474]が定義したIdentityヘッダーフィールドから大幅に変更しています。しかし、[SIP-RFC4474-CONCERNS]に挙げられた問題を踏まえると、旧仕様のIdentityヘッダーフィールドは実運用に導入されておらず、導入済み製品にも実装されていないと考えられます。
As such, this mechanism contains no provisions for signatures generated with this specification to work with implementations compliant with [RFC4474], nor does it contain any related backwards-compatibility provisions. Hypothetically, were an implementation compliant with [RFC4474] to receive messages containing this revised version of the Identity header field, it would likely fail the request with a 436 response code due to the absence of an Identity-Info header field (Section 4). Implementations of this specification, for debugging purposes, might interpret a 436 with a reason phrase of "Bad Identity Info" (previously "Bad Identity-Info"; see Section 13.2) as an indication that the request has failed because it reached a (hypothetical) verification service that is compliant with [RFC4474].
そのため、本機構には、本仕様で生成した署名を[RFC4474]準拠の実装で使うための規定も、その他の後方互換性の規定もありません。仮に[RFC4474]準拠の実装が改訂版Identityヘッダーフィールドを含むメッセージを受信すると、Identity-Infoヘッダーフィールドがないため（Section 4を参照）、436応答コードでリクエストを拒否する可能性が高いです。デバッグのため、本仕様の実装は、理由句が "Bad Identity Info"（旧称 "Bad Identity-Info"。Section 13.2を参照）の436応答を受け取った場合、（仮想的な）[RFC4474]準拠検証サービスに到達したためリクエストが失敗したと解釈できます。
The purpose of this mechanism is to provide a reliable identification of the originator of a SIP request, specifically a cryptographic assurance that an authority asserts the originator can claim the URI the identity stipulated in the request. This URI may contain or imply a variety of personally identifying information, including the name of a human being, their place of work or service provider, and, possibly, further details. The intrinsic privacy risks associated with that URI are, however, no different from those of baseline SIP. Per the guidance in [RFC6973], implementers should make users aware of the privacy trade-off of providing secure identity.
本機構の目的は、SIPリクエストの発信者を確実に識別すること、特に、発信者がリクエスト内で主張するURIを使う権限を持つと権限主体が表明したことを暗号学的に保証することです。このURIには、人名、勤務先やサービス提供者など、さまざまな個人識別情報が含まれたり示唆されたりする可能性があります。しかし、そのURIに伴う本質的なプライバシーリスクは、従来のSIPの場合と変わりません。[RFC6973]の指針に従い、実装者は安全な識別情報を提供する際のプライバシー上のトレードオフをユーザーに知らせるべきです。
The identity mechanism presented in this document is compatible with the standard SIP practices for privacy described in [RFC3323]. A SIP proxy server can act as both a privacy service as described in [RFC3323] and an authentication service. Since a UA can provide any From header field value that the authentication service is willing to authorize, there is no reason why private SIP URIs that contain legitimate domains (e.g., sip:anonymous@example.com) cannot be signed by an authentication service. The construction of the Identity header field is the same for private URIs as it is for any other sort of URIs. Similar practices could be used to support opportunistic signing of SIP requests for UA-integrated authentication services with self-signed certificates, though that is outside the scope of this specification and is left as a matter for future investigation.
本書の識別情報機構は、[RFC3323]が説明する標準的なSIPプライバシー慣行と両立します。SIPプロキシサーバーは、[RFC3323]のプライバシーサービスと認証サービスの両方として動作できます。UAは認証サービスが許可するFromヘッダーフィールド値を指定できるため、sip:anonymous@example.comのように正当なドメインを含むプライベートSIP URIにも認証サービスが署名できます。プライベートURIでも、Identityヘッダーフィールドの構築方法は他のURIと同じです。自己署名証明書を使うUA統合型認証サービスでSIPリクエストに機会的に署名する場合にも同様の方法を使える可能性がありますが、これは本仕様の範囲外であり、今後の検討課題です。
Note, however, that even when using anonymous SIP URIs, an authentication service must possess a certificate corresponding to the host portion of the addr-spec of the From header field value of the request; accordingly, using domains like "anonymous.invalid" will not be usable by privacy services that simultaneously act as authentication services. The assurance offered by the usage of anonymous URIs with a valid domain portion is "this is a known user in my domain that I have authenticated, but I am keeping its identity private."
ただし、匿名のSIP URIを使用する場合でも、認証サービスは、要求のFromヘッダーフィールド値のaddr-specのホスト部分に対応する証明書を所有している必要があります。したがって、「anonymous.invalid」のようなドメインを使用しても、認証サービスとして同時に機能するプライバシーサービスでは使用できません。有効なドメイン部分を持つ匿名URIの使用によって提供される保証は、「これは認証済みのドメイン内の既知のユーザーですが、そのIDは非公開にしています」です。
It is worth noting two features of this more anonymous form of identity. One can eliminate any identifying information in a domain through the use of the domain "anonymous.invalid", but we must then acknowledge that it is difficult for a domain to be both anonymous and authenticated. The use of the domain "anonymous.invalid" entails that no corresponding authority for the domain can exist, and as a consequence, authentication service functions for that domain are meaningless. The second feature is more germane to the threats this document mitigates [RFC7375]. None of the relevant attacks, all of which rely on the attacker taking on the identity of a victim or hiding their identity using someone else's identity, are enabled by an anonymous identity. As such, the inability to assert an authority over an anonymous domain is irrelevant to our threat model.
この匿名性の高い識別情報には2つの特徴があります。ドメイン "anonymous.invalid" を使えば、ドメインから識別情報をなくせますが、その場合、ドメインを匿名かつ認証済みにすることは難しいと認める必要があります。"anonymous.invalid" を使うと、そのドメインに対応する権限主体は存在できず、そのドメインに対する認証サービスの機能は意味を失います。2つ目の特徴は、本書が軽減する脅威[RFC7375]により関係します。ここで問題となる攻撃はいずれも、攻撃者が被害者になりすますか、他者の識別情報を使って自分の身元を隠すことに依存します。匿名の識別情報では、こうした攻撃は可能になりません。したがって、匿名ドメインに対する権限を主張できないことは、本書の脅威モデルには関係しません。
[RFC3325] defines the "id" priv-value token, which is specific to the P-Asserted-Identity header field. The sort of assertion provided by the P-Asserted-Identity header field is very different from the Identity header field presented in this document. It contains additional information about the originator of a message that may go beyond what appears in the From header field; P-Asserted-Identity holds a definitive identity for the originator that is somehow known to a closed network of intermediaries. Presumably, that network will use this identity for billing or security purposes. The danger of this network-specific information leaking outside of the closed network motivated the "id" priv-value token. The "id" priv-value token has no implications for the Identity header field, and privacy services MUST NOT remove the Identity header field when a priv-value of "id" appears in a Privacy header field.
[RFC3325]は、P-Asserted-Identityヘッダーフィールドに固有の "id" priv-value tokenを定義します。P-Asserted-Identityヘッダーフィールドが示す主張は、本書のIdentityヘッダーフィールドとは大きく異なります。P-Asserted-Identityには、Fromヘッダーフィールドに現れる情報を超える発信者情報が含まれる場合があります。このフィールドは、仲介者から成る閉じたネットワークが何らかの方法で把握している発信者の確定的な識別情報を保持します。そのネットワークは、この識別情報を課金またはセキュリティに使うと考えられます。ネットワーク固有の情報が外部に漏れる危険が、"id" priv-value tokenを設けた理由です。"id" priv-value tokenはIdentityヘッダーフィールドには影響しません。Privacyヘッダーフィールドにpriv-value "id" がある場合、プライバシーサービスはIdentityヘッダーフィールドを削除してはなりません (MUST NOT)。
The full form of the PASSporT object provides the complete JSON objects used to generate the signed-identity-digest of the Identity header field value, including the canonicalized form of the telephone number of the originator of a call if the signature is over a telephone number. In some contexts, local policy may require a canonicalization that differs substantially from the original From header field. Depending on those policies, potentially the full form of PASSporT might divulge information about the originating network or user that might not appear elsewhere in the SIP request. Were it to be used to reflect the contents of the P-Asserted-Identity header field, for example, then the object would need to be converted to the compact form when the P-Asserted-Identity header is removed to avoid any such leakage outside of a trust domain. Since, in those contexts, the canonical form of the originator's identity could not be reassembled by a verifier and thus the Identity signature validation process would fail, using P-Asserted-Identity with the full form of PASSporT in this fashion is NOT RECOMMENDED outside of environments where SIP requests will never leave the trust domain. As a side note, history shows that closed networks never stay closed and one should design their implementation assuming connectivity to the broader Internet.
PASSporTオブジェクトの完全形式には、Identityヘッダーフィールド値のsigned-identity-digestを生成するために使ったJSONオブジェクト全体が含まれます。署名対象が電話番号の場合は、発信者の電話番号を正規化した形式も含まれます。ローカルポリシーによっては、元のFromヘッダーフィールドとは大きく異なる正規化が必要です。そのようなポリシーでは、PASSporTの完全形式によって、SIPリクエストの他の箇所にはない発信元ネットワークやユーザーの情報が明らかになる可能性があります。たとえば、P-Asserted-Identityヘッダーフィールドの内容を反映する場合、信頼ドメインの外への情報漏えいを防ぐため、P-Asserted-Identityヘッダーを削除するときにPASSporTをコンパクト形式に変換する必要があります。このような環境では、検証者が発信者識別情報の正規形を再構成できず、Identity署名の検証に失敗します。そのため、SIPリクエストが信頼ドメインの外に出ない環境を除き、この方法でPASSporTの完全形式とP-Asserted-Identityを併用することは推奨されません (SHOULD NOT)。なお、閉じたネットワークも閉じたままとは限らないことを踏まえ、より広いインターネットとの接続を想定して実装を設計すべきです。
Finally, note that unlike [RFC3325], the mechanism described in this specification adds no information to SIP requests that has privacy implications -- apart from disclosing that an authentication service is willing to sign for an originator.
最後に、[RFC3325]とは異なり、この仕様で説明されているメカニズムは、プライバシーに影響を与えるSIPリクエストに情報を追加しないことに注意してください。
This document describes a mechanism that provides a signature over the Date header field of SIP requests, parts of the To and From header fields, and (when present) any media keying material in the message body. In general, the considerations related to the security of these header fields are the same as those given in [RFC3261] for including header fields in tunneled "message/sip" MIME bodies (see Section 23 of [RFC3261] in particular). This section details the individual security properties obtained by including each of these header fields within the signature; collectively, this set of header fields provides the necessary properties to prevent impersonation. It addresses the solution-specific attacks against in-band solutions enumerated in [RFC7375], Section 4.1.
このドキュメントでは、SIPリクエストのDateヘッダーフィールド、ToおよびFromヘッダーフィールドの一部、および（存在する場合は）メッセージ本文のメディアキー情報に署名を提供するメカニズムについて説明します。一般に、これらのヘッダーフィールドのセキュリティに関連する考慮事項は、トンネル化された「message/sip」MIME本文にヘッダーフィールドを含めることについて[RFC3261]で提供されたものと同じです（特に[RFC3261]のセクション23を参照）。このセクションでは、これらの各ヘッダーフィールドを署名に含めることによって取得される個々のセキュリティプロパティについて詳しく説明します。まとめると、この一連のヘッダーフィールドは、なりすましを防ぐために必要なプロパティを提供します。 [RFC7375]のセクション4.1に列挙されているインバンドソリューションに対するソリューション固有の攻撃に対処します。
The From header field value (in ordinary operations) indicates the identity of the originator of the message; for the purposes of this document, either the SIP AoR URI or an embedded telephone number provides the identity of a SIP user. Note that in some deployments the identity of the originator may reside in P-Asserted-Identity instead. The originator's identity is the key piece of information that this mechanism secures; the remainder of the signed parts of a SIP request are present to provide reference integrity and to prevent certain types of cut-and-paste attacks.
Fromヘッダーフィールドの値（通常の操作）は、メッセージの発信者のIDを示します。このドキュメントでは、SIP AoR URIまたは埋め込まれた電話番号のいずれかがSIPユーザーのIDを提供します。一部の展開では、発信者のIDが代わりにP-Asserted-Identityに存在する場合があることに注意してください。発信者のIDは、このメカニズムが保護する重要な情報です。 SIPリクエストの署名された残りの部分は、参照の整合性を提供し、特定のタイプのカットアンドペースト攻撃を防ぐために存在します。
The Date header field value protects against cut-and-paste attacks, as described in [RFC3261], Section 23.4.2. That specification recommends that implementations notify the user of a potential security issue if the signed Date header field value is stale by an hour or more. To prevent cut-and-paste of recently observed messages, this specification instead RECOMMENDS a shorter interval of sixty seconds. Implementations of this specification MUST NOT deem valid a request with an outdated Date header field. Note that per the behavior described in [RFC3893], Section 10, servers can keep state of recently received requests, and thus if an Identity header field is replayed by an attacker within the Date interval, verifiers can detect that it is spoofed because a message with an identical Date from the same source had recently been received.
[RFC3261] Section 23.4.2が説明するように、Dateヘッダーフィールド値は切り貼り攻撃を防ぎます。同仕様は、署名されたDateヘッダーフィールド値が1時間以上古い場合、潜在的なセキュリティ問題をユーザーに通知するよう実装に推奨しています。最近観測されたメッセージの切り貼りを防ぐため、本仕様では代わりに60秒という短い間隔を推奨します。本仕様の実装は、古いDateヘッダーフィールドを持つリクエストを有効と見なしてはなりません (MUST NOT)。[RFC3893] Section 10の動作に従い、サーバーは最近受信したリクエストの状態を保持できます。そのため、攻撃者がDateの有効期間内にIdentityヘッダーフィールドを再送しても、同じ送信元から同一のDateを持つメッセージを最近受信していれば、Verifierは偽造を検出できます。
It has been observed in the wild that some networks change the Date header field value of SIP requests in transit; to accommodate that type of scenario, alternative behavior might be necessary. Verification services that observe a signature validation failure MAY therefore reconstruct the Date header field component of the signature from the "iat" carried in the full form of PASSporT: provided that time recorded by "iat" falls within the local policy for freshness that would ordinarily apply to the Date header, the verification service MAY treat the signature as valid, provided it keeps adequate state to detect recent replays. Note that this will require the inclusion of the full form of the PASSporT object by authentication services in networks where such failures are observed.
実環境では、一部のネットワークが転送中にSIPリクエストのDateヘッダーフィールド値を変更することが確認されています。この状況に対応するには別の動作が必要になる場合があります。そのため、署名検証に失敗した検証サービスは、PASSporT完全形式の "iat" から署名対象のDateヘッダーフィールド要素を再構成してもよいです (MAY)。"iat" の時刻が、通常Dateヘッダーに適用する鮮度ポリシーの範囲内であり、最近のリプレイを検出するための十分な状態を保持していることを条件として、検証サービスは署名を有効として扱ってもよいです (MAY)。このような失敗が観測されるネットワークでは、認証サービスがPASSporTの完全形式を含める必要があります。
The To header field value provides the identity of the SIP user that this request originally targeted. Covering the identity in the To header field with the Identity signature serves two purposes. First, it prevents cut-and-paste attacks in which an Identity header field from a legitimate request for one user is cut-and-pasted into a request for a different user. Second, it preserves the starting URI scheme of the request; this helps prevent downgrade attacks against the use of SIPS. The To identity offers additional protection against cut-and-paste attacks beyond the Date header field. For example, without a signature over the To identity, an attacker who receives a call from a target could immediately cut-and-paste the Identity and From header field value from that INVITE into a new request to the target's voicemail service within the Date interval, and the voicemail service would have no way of knowing that the Identity header field it received had been originally signed for a call intended for a different number. However, note the caveats below in Section 12.1.1.
Toヘッダーフィールド値は、このリクエストが当初宛てていたSIPユーザーの識別情報を示します。Toヘッダーフィールド内の識別情報もIdentity署名の対象にすると、2つの攻撃を防げます。第一に、あるユーザー宛ての正当なリクエストのIdentityヘッダーフィールドを別のユーザー宛てのリクエストに貼り付ける攻撃を防ぎます。第二に、リクエスト開始時のURI schemeを保持し、SIPSの使用に対するダウングレード攻撃を防ぎます。Toの識別情報への署名は、Dateヘッダーフィールドだけの場合より強い切り貼り対策になります。たとえばToの識別情報に署名がなければ、着信を受けた攻撃者は、そのINVITEのIdentityヘッダーフィールドとFromヘッダーフィールド値を、有効期間内に標的のボイスメールサービス宛ての新しいリクエストへ貼り付けられます。ボイスメールサービスは、受信したIdentityヘッダーフィールドが別の番号宛ての通話に署名されたものだと判別できません。ただしSection 12.1.1の注意点も参照してください。
When signing a request that contains a fingerprint of keying material in SDP for DTLS-SRTP [RFC5763], this mechanism always provides a signature over that fingerprint. This signature prevents certain classes of impersonation attacks in which an attacker forwards or cut-and-pastes a legitimate request. Although the target of the attack may accept the request, the attacker will be unable to exchange media with the target, as they will not possess a key corresponding to the fingerprint. For example, there are some baiting attacks, launched with the REFER method or through social engineering, where the attacker receives a request from the target and reoriginates it to a third party. These might not be prevented by only a signature over the From, To, and Date, but they could be prevented by securing a fingerprint for DTLS-SRTP. While this is a different form of impersonation than is commonly used for robocalling, ultimately there is little purpose in establishing the identity of the user that originated a SIP request if this assurance is not coupled with a comparable assurance over the contents of the subsequent media communication. This signature also reduces the potential for active eavesdropping attacks against the SIP media. In environments where DTLS-SRTP is unsupported, however, no field is signed and no protections are provided.
DTLS-SRTP [RFC5763]用の鍵素材のfingerprintをSDPに含むリクエストに署名する場合、本機構は常にそのfingerprintにも署名します。この署名により、攻撃者が正当なリクエストを転送または貼り付けるタイプのなりすまし攻撃を防げます。攻撃対象がリクエストを受け入れても、攻撃者はfingerprintに対応する鍵を持たないため、対象とメディアを交換できません。たとえば、REFER methodやソーシャルエンジニアリングを使うおびき寄せ攻撃では、攻撃者が対象から受け取ったリクエストを第三者宛てに再発信します。From、To、Dateへの署名だけではこの攻撃を防げない場合がありますが、DTLS-SRTPのfingerprintを保護すれば防げる可能性があります。これはロボコールで一般的なものとは異なるなりすましですが、SIPリクエストの発信ユーザーの識別情報を保証しても、その後のメディア通信の内容に同等の保証がなければ、得られるものは限られます。この署名はSIPメディアに対する能動的な盗聴攻撃の可能性も低減します。ただし、DTLS-SRTPに対応しない環境では何にも署名されず、保護も提供されません。
Armed with the original value of the To header field, the recipient of a request may be tempted to compare it to their own identity in order to determine whether or not the identity information in this call might have been replayed. However, any request may be legitimately retargeted as well, and as a result legitimate requests may reach a SIP endpoint whose user is not identified by the URI designated in the To header field value. It is therefore difficult for any verifier to decide whether or not some prior retargeting was "legitimate". Retargeting can also cause confusion when identity information is provided for requests sent in the backwards direction in a dialog, as the dialog identifiers may not match credentials held by the ultimate target of the dialog. For further information on the problems of response identity, see [SIP-RETARGET].
リクエストの受信者は、元のToヘッダーフィールド値を使い、それを自分の識別情報と比較して、この通話の識別情報が再送されたものか判断したくなるかもしれません。しかし、リクエストは正当に別の宛先へ変更されることもあります。その結果、Toヘッダーフィールド値が示すURIでは識別されないユーザーを持つSIPエンドポイントに、正当なリクエストが届く場合があります。そのためVerifierが、以前の宛先変更が正当だったかを判断するのは困難です。ダイアログの逆方向に送るリクエストに識別情報を付ける場合も、宛先変更によって混乱が起こることがあります。ダイアログ識別子が、最終的な宛先が持つ資格情報と一致しない可能性があるためです。応答の識別情報に関する問題は[SIP-RETARGET]を参照してください。
Any means for authentication services or verifiers to anticipate retargeting is outside the scope of this document and is likely to have the same applicability to response identity as it does to requests in the backwards direction within a dialog. Consequently, no special guidance is given for implementers here regarding the "connected party" problem (see [RFC4916]); authentication service behavior is unchanged if retargeting has occurred for a dialog-forming request. Ultimately, the authentication service provides an Identity header field for requests in the dialog only when the user is authorized to assert the identity given in the From header field, and if they are not, an Identity header field is not provided. And per the threat model of [RFC7375], resolving problems with "connected" identity has little bearing on detecting robocalling or related impersonation attacks.
認証サービスやVerifierが宛先変更を予測する方法は本書の範囲外です。また、その方法は、ダイアログ内で逆方向に送るリクエストと同様に、応答の識別情報にも適用されると考えられます。そのため、"connected party" 問題（[RFC4916]を参照）について実装者への特別な指針は示しません。ダイアログを確立するリクエストの宛先が変更されても、認証サービスの動作は変わりません。認証サービスは、ユーザーがFromヘッダーフィールドに示された識別情報を主張する権限を持つ場合に限り、ダイアログ内のリクエストにIdentityヘッダーフィールドを付けます。権限がなければ付けません。[RFC7375]の脅威モデルに照らすと、"connected" 識別情報の問題を解決しても、ロボコールや関連するなりすまし攻撃の検出にはほとんど影響しません。
[RFC4474] originally provided protections for Contact, Call-ID, and CSeq. This document removes protection for these fields. The absence of these header field values creates some opportunities for determined attackers to impersonate based on cut-and-paste attacks; however, the absence of these header field values does not seem impactful to the primary focus of this document, which is the prevention of the simple unauthorized claiming of an identity for the purposes of robocalling, voicemail hacking, or swatting.
[RFC4474]は当初、Contact、Call-ID、CSeqを保護していました。本書ではこれらのフィールドを保護対象から外します。これらのヘッダーフィールド値がないと、攻撃者が切り貼り攻撃でなりすます余地が生じます。しかし、ロボコール、ボイスメールへの不正アクセス、スワッティングを目的とした単純な不正識別情報の主張を防ぐという本書の主な目的には、これらの値がなくても大きな影響はないと考えられます。
It might seem attractive to provide a signature over some of the information present in the Via header field value(s). For example, without a signature over the sent-by field of the topmost Via header field, an attacker could remove that Via header field and insert its own in a cut-and-paste attack, which would cause all responses to the request to be routed to a host of the attacker's choosing. However, a signature over the topmost Via header field does not prevent attacks of this nature, since the attacker could leave the topmost Via intact and merely insert a new Via header field directly after it, which would cause responses to be routed to the attacker's host "on their way" to the valid host; the end result would be exactly the same. Although it is possible that an intermediary-based authentication service could guarantee that no Via hops are inserted between the sending UA and the authentication service, it could not prevent an attacker from adding a Via hop after the authentication service and thereby preempting responses. It is necessary for the proper operation of SIP for subsequent intermediaries to be capable of inserting such Via header fields, and thus it cannot be prevented. As such, though it is desirable, securing Via is not possible through the sort of identity mechanism described in this document; the best known practice for securing Via is the use of SIPS.
Viaヘッダーフィールド値の一部にも署名したくなるかもしれません。たとえば、最上位Viaヘッダーフィールドのsent-byに署名がなければ、攻撃者はそのViaヘッダーフィールドを削除し、自分の値に置き換える切り貼り攻撃を行えます。そうすると、すべての応答が攻撃者の選んだホストへルーティングされます。しかし最上位Viaヘッダーフィールドに署名しても、この攻撃は防げません。攻撃者はそのViaを残したまま直後に新しいViaヘッダーフィールドを挿入でき、応答を正規のホストへ向かう途中で攻撃者のホストにもルーティングできるためです。最終的な結果は同じです。仲介者型認証サービスは、送信UAと認証サービスの間にVia hopが挿入されないことを保証できるかもしれませんが、認証サービスの後に攻撃者がVia hopを加えて応答を横取りすることは防げません。SIPを正しく動作させるには後続の仲介者がViaヘッダーフィールドを挿入できる必要があるため、これを防止できません。したがって望ましい対策ではありますが、本書の識別情報機構でViaを保護することはできません。Viaを保護する既知の最善策はSIPSを使うことです。
In the end analysis, the Identity header field cannot protect itself. Any attacker could remove the header field from a SIP request and modify the request arbitrarily afterwards. However, this mechanism is not intended to protect requests from men-in-the-middle who interfere with SIP messages; it is intended only to provide a way that the originators of SIP requests can prove that they are who they claim to be. At best, by stripping identity information from a request, a man-in-the-middle could make it impossible to distinguish any illegitimate messages he would like to send from those messages sent by an authorized user. However, it requires a considerably greater amount of energy to mount such an attack than it does to mount trivial impersonations by just copying someone else's From header field. This mechanism provides a way that an authorized user can provide a definitive assurance of his identity that an unauthorized user, an impersonator, cannot.
結局のところ、Identityヘッダーフィールド自体を保護することはできません。攻撃者はSIPリクエストからこのヘッダーフィールドを削除し、その後リクエストを自由に変更できます。ただし本機構は、SIPメッセージに介入する中間者からリクエストを守るものではありません。目的は、SIPリクエストの発信者が自分の主張する本人であることを証明する方法を提供することです。中間者は、リクエストから識別情報を取り除くことで、正規ユーザーが送ったメッセージと自分が送ろうとする不正なメッセージを区別できなくすることはできます。しかし、その攻撃には他人のFromヘッダーフィールドをコピーするだけの単純ななりすましより大きな労力が必要です。本機構により、正規ユーザーは自らの識別情報を確実に証明できますが、不正ユーザーはそれができません。
In the absence of UA-based authentication services, the assurance provided by this mechanism is strongest when a UA forms a direct connection, preferably one secured by TLS, to an intermediary-based authentication service. The reasons for this are twofold:
UAベースの認証サービスがない場合、UAが中間ベースの認証サービスへの直接接続（できればTLSで保護された接続）を形成するときに、このメカニズムによって提供される保証が最も強くなります。これには2つの理由があります。
o If a user does not receive a certificate from the authentication service over the TLS connection that corresponds to the expected domain (especially when the user receives a challenge via a mechanism such as Digest), then it is possible that a rogue server is attempting to pose as an authentication service for a domain that it does not control, possibly in an attempt to collect shared secrets for that domain. A similar practice could be used for telephone numbers, though the application of certificates for telephone numbers to TLS is left as a matter for future study.
o UAがTLS接続を通じて認証サービスから受け取る証明書が想定したドメインに対応していない場合（特にDigestなどでユーザーに認証要求が届いた場合）、不正なサーバーが、自ら管理していないドメインの認証サービスになりすましている可能性があります。その目的は、そのドメインの共有シークレットを収集することかもしれません。電話番号にも同様の方法を適用できますが、電話番号用証明書をTLSに適用する方法は今後の検討課題です。
o Without TLS, the various header field values and the body of the request will not have integrity protection when the request arrives at an authentication service. Accordingly, a prior legitimate or illegitimate intermediary could modify the message arbitrarily.
o TLSがなければ、リクエストが認証サービスに届いた時点で、各ヘッダーフィールド値と本文の完全性は保護されません。そのため、途中にいた正規または不正な仲介者がメッセージを自由に変更できてしまいます。
Of these two concerns, the first is most material to the intended scope of this mechanism. This mechanism is intended to prevent impersonation attacks, not man-in-the-middle attacks; integrity over parts of the header and body is provided by this mechanism only to prevent replay attacks. However, it is possible that applications relying on the presence of the Identity header field could leverage this integrity protection for services other than replay protection.
これら2つの懸念のうち、最初の懸念は、このメカニズムの意図された範囲にとって最も重要です。このメカニズムは、中間者攻撃ではなく、なりすまし攻撃を防ぐことを目的としています。ヘッダーとボディの一部の整合性は、リプレイ攻撃を防ぐためにのみこのメカニズムによって提供されます。ただし、Identityヘッダーフィールドの存在に依存するアプリケーションが、リプレイ保護以外のサービスでこの整合性保護を利用できる可能性があります。
Accordingly, direct TLS connections SHOULD be used between the UA client (UAC) and the authentication service whenever possible. The opportunistic nature of this mechanism, however, makes it very difficult to constrain UAC behavior, and moreover there will be some deployment architectures where a direct connection is simply infeasible and the UAC cannot act as an authentication service itself. Accordingly, when a direct connection and TLS are not possible, a UAC should use the SIPS mechanism, Digest "auth-int" for body integrity, or both when it can. The ultimate decision to add an Identity header field to a request lies with the authentication service, of course; domain policy must identify those cases where the UAC's security association with the authentication service is too weak.
したがって、可能な限り、UAクライアント（UAC）と認証サービスの間で直接TLS接続を使用すべきです (SHOULD)。ただし、このメカニズムには日和見的な性質があるため、UACの動作を制限することは非常に難しく、さらに、直接接続が単に実行不可能であり、UAC自体が認証サービスとして機能できない展開アーキテクチャもあります。したがって、直接接続とTLSが不可能な場合、UACはSIPSメカニズム、ダイジェスト「auth-int」、またはその両方を使用できる必要があります。もちろん、Identityヘッダーフィールドをリクエストに追加する最終的な決定は、認証サービスにあります。ドメインポリシーは、認証サービスとのUACのセキュリティアソシエーションが弱すぎるケースを特定する必要があります。
Ultimately, the worth of an assurance provided by an Identity header field is limited by the security practices of the authentication service that issues the assurance. Relying on an Identity header field generated by a remote administrative domain assumes that the issuing domain uses recommended administrative practices to authenticate its users. However, it is possible that some authentication services will implement policies that effectively make users unaccountable (e.g., ones that accept unauthenticated registrations from arbitrary users). The value of an Identity header field from such authentication services is questionable. While there is no magic way for a verifier to distinguish "good" from "bad" signers by inspecting a SIP request, it is expected that further work in authorization practices could be built on top of this identity solution; without such an identity solution, many promising approaches to authorization policy are impossible. That much said, it is RECOMMENDED that authentication services based on proxy servers employ strong authentication practices.
最終的に、Identityヘッダーフィールドが提供する保証の価値は、その保証を発行する認証サービスのセキュリティ慣行によって決まります。リモート管理ドメインが生成したIdentityヘッダーフィールドを信頼することは、そのドメインが推奨される管理慣行に従ってユーザーを認証していると仮定することです。しかし、ユーザーを追跡できない状態にするポリシー（任意のユーザーからの未認証登録を受け入れるなど）を実装する認証サービスもあり得ます。そのようなサービスのIdentityヘッダーフィールドを信頼できるかは疑問です。SIPリクエストを調べるだけでVerifierが署名者の善し悪しを判別する方法はありませんが、この識別情報機構を土台に認可慣行をさらに整備できます。この機構がなければ、有望な認可ポリシーの多くは実現できません。以上を踏まえ、プロキシサーバー上の認証サービスには強固な認証慣行を採用することが推奨されます (SHOULD)。
One cannot expect the Identity header field to be supported by every SIP entity overnight. This leaves the verifier in a difficult position; when it receives a request from a given SIP user, how can it know whether or not the originator's domain supports Identity? In the absence of ubiquitous support for Identity, some transitional strategies are necessary.
Identityヘッダーフィールドが、すべてのSIPエンティティですぐにサポートされるとは期待できません。そのためVerifierは難しい立場になります。あるSIPユーザーからリクエストを受けたとき、発信元ドメインがIdentityに対応しているかどうかをどう判断できるでしょうか。Identityが広くサポートされるまでは、移行戦略が必要です。
o A verifier could remember when it receives a request from a domain or telephone number that uses Identity and, in the future, view messages received from that source without an Identity header field with skepticism.
o Verifierは、Identityを使うドメインまたは電話番号からリクエストを受信したことを記録し、将来その送信元からIdentityヘッダーフィールドのないメッセージを受信した場合には、慎重に扱うことができます。
o A verifier could consult some sort of directory that indicates whether a given caller should have a signed identity. There are a number of potential ways in which this could be implemented. This is left as a subject for future work.
o Verifierは、特定の発信者が署名付き識別情報を持つはずかどうかを示すディレクトリを参照できます。その実装方法はいくつか考えられます。詳細は今後の課題です。
In the long term, some sort of identity mechanism, either the one documented in this specification or a successor, must become mandatory-to-use for SIP; that is the only way to guarantee that this protection can always be expected by verifiers.
長期的には、本仕様で説明するものかその後継のいずれかの識別情報機構を、SIPで必須にする必要があります。これが、Verifierが常にこの保護を期待できるようにする唯一の方法です。
Finally, it is worth noting that the presence or absence of the Identity header fields cannot be the sole factor in making an authorization decision. Permissions might be granted to a message on the basis of the specific verified Identity or really on any other aspect of a SIP request. Authorization policies are outside the scope of this specification, but this specification advises any future authorization work not to assume that messages with valid Identity header fields are always good.
最後に、Identityヘッダーフィールドの有無が、承認を決定する唯一の要因にはなり得ないことに注意してください。特定の検証済みIDに基づいて、または実際にはSIP要求の他の側面に基づいて、メッセージにアクセス許可が付与される場合があります。承認ポリシーはこの仕様の範囲外ですが、この仕様では、将来の承認作業では、有効なIdentityヘッダーフィールドを持つメッセージが常に適切であるとは想定しないようにアドバイスしています。
As a matter of interface design, SIP UAs might render the display-name portion of the From header field of a caller as the identity of the caller; there is a significant precedent in email user interfaces for this practice. Securing the display-name component of the From header field value is outside the scope of this document but may be the subject of future work, such as through the "ppt" name mechanism.
インターフェイス設計によっては、SIP UAは発信者のFromヘッダーフィールドのdisplay-name部分を発信者の識別情報として表示することがあります。電子メールのユーザーインターフェイスにも同様の慣行があります。Fromヘッダーフィールド値のdisplay-name要素を保護することは本書の範囲外ですが、"ppt" name機構などを使う将来の課題になる可能性があります。
In the absence of signing the display-name, authentication services might check and validate it, and compare it to a list of acceptable display-names that may be used by the originator; if the display-name does not meet policy constraints, the authentication service could return a 403 response code. In this case, the reason phrase should indicate the nature of the problem: for example, "Inappropriate Display Name". However, the display-name is not always present, and in many environments the requisite operational procedures for display-name validation may not exist, so no normative guidance is given here.
display-nameに署名しない場合、認証サービスはその値を検査・検証し、発信者が使える表示名の一覧と比較することがあります。display-nameがポリシー上の制約を満たさなければ、認証サービスは403応答コードを返すことがあります。その場合、理由句には問題の内容（例: "Inappropriate Display Name"）を示すべきです。ただしdisplay-nameが常に存在するとは限らず、多くの環境には検証に必要な運用手順もないため、本書では規範的な指針を示しません。
IANA has completed a number of actions described in this document. Primarily, the previous references to [RFC4474] in the "Session Initiation Protocol (SIP) Parameters" registry have been updated to point to this document, unless specified otherwise below.
IANAは、このドキュメントで説明されているいくつかのアクションを完了しました。主に、 "Session Initiation Protocol（SIP）Parameters"レジストリの[RFC4474]への以前の参照は、以下で特に指定されていない限り、このドキュメントを指すように更新されています。
The Identity-Info header in the SIP "Header Fields" registry has been marked as deprecated by this document.
SIP "Header Fields"レジストリのIdentity-Infoヘッダーは、このドキュメントで非推奨としてマークされています。
Also, the Identity-Info header reserved the compact form "n" at its time of registration. That compact form has been removed from the registry. The Identity header, however, retains the compact form "y" reserved by [RFC4474].
また、Identity-Infoヘッダーは、登録時にコンパクトフォーム "n"を予約していました。そのコンパクトなフォームはレジストリから削除されました。ただし、Identityヘッダーは、[RFC4474]によって予約されているコンパクトな形式「y」を保持します。
The 436 "Bad Identity-Info" default reason phrase has been changed to "Bad Identity Info" in the SIP "Response Codes" registry.
SIPの「応答コード」レジストリで、436「Bad Identity-Info」のデフォルトの理由フレーズが「Bad Identity Info」に変更されました。
The 437 "Unsupported Certificate" default reason phrase has been changed to "Unsupported Credential".
437「サポートされていない証明書」のデフォルトの理由フレーズが「サポートされていない資格情報」に変更されました。
IANA manages a registry for Identity-Info parameters. Per this specification, IANA has changed the name of this registry to "Identity Parameters".
IANAはIdentity-Infoパラメーターのレジストリを管理しています。本仕様に従い、IANAはこのレジストリ名を "Identity Parameters" に変更しました。
This specification defines one new value for the registry: "info" as defined in Section 7.3.
この仕様では、7.3で定義されているように、レジストリに「info」という1つの新しい値を定義しています。
IANA managed an "Identity-Info Algorithm Parameter Values" registry; per this specification, IANA has deprecated and closed this registry. Since the algorithms for signing PASSporTs are defined in [RFC8225] rather than in this specification, there is no longer a need for an algorithm parameter registry for the Identity header field.
IANAは "Identity-Info Algorithm Parameter Values" レジストリを管理していました。本仕様に従って、このレジストリは廃止され、閉鎖されました。PASSporTの署名アルゴリズムは本仕様ではなく[RFC8225]で定義されるため、Identityヘッダーフィールド用のアルゴリズムパラメーターレジストリは不要になりました。
The following are salient changes from the original RFC 4474:
以下は、元のRFC 4474からの重要な変更です。
o The credential mechanism has been generalized; credential enrollment, acquisition, and trust are now outside the scope of this document.
o 資格メカニズムが一般化されました。資格情報の登録、取得、および信頼は、このドキュメントの範囲外です。
o This document reduces the scope of the Identity signature to remove CSeq, Call-ID, Contact, and the message body; signing of key fingerprints in SDP is now included.
o 本書ではIdentity署名の対象を縮小し、CSeq、Call-ID、Contact、メッセージ本文を除外しました。一方、SDP内の鍵fingerprintへの署名を追加しました。
o The Identity-Info header field has been deprecated, and its components have been relocated into parameters of the Identity header field (which obsoletes the previous version of the header field).
o Identity-Infoヘッダーフィールドを非推奨とし、その構成要素をIdentityヘッダーフィールドのパラメーターに移しました（これにより旧版のヘッダーフィールドは置き換えられます）。
o The Identity header field can now appear multiple times in one request.
o Identityヘッダーフィールドは、1回のリクエストで複数回出現できるようになりました。
o The previous signed-identity-digest format has been replaced with PASSporT (signing algorithms are now defined in a separate specification).
o 以前の署名付きIDダイジェスト形式はPASSporTに置き換えられました（署名アルゴリズムは別の仕様で定義されています）。
o Status code descriptions have been revised.
o ステータスコードの説明が改訂されました。
[E.164] International Telecommunication Union, "The international public telecommunication numbering plan", ITU-T Recommendation E.164, November 2010, <https://www.itu.int/rec/T-REC-E.164/en>.
[E.164] International Telecommunication Union, "The international public telecommunication numbering plan", ITU-T Recommendation E.164, November 2010, <https://www.itu.int/rec/T-REC-E.164/en>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, DOI 10.17487/RFC3263, June 2002, <https://www.rfc-editor.org/info/rfc3263>.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, DOI 10.17487/RFC3263, June 2002, <https://www.rfc-editor.org/info/rfc3263>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <https://www.rfc-editor.org/info/rfc3966>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <https://www.rfc-editor.org/info/rfc3966>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, DOI 10.17487/RFC5922, June 2010, <https://www.rfc-editor.org/info/rfc5922>.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, DOI 10.17487/RFC5922, June 2010, <https://www.rfc-editor.org/info/rfc5922>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, <https://www.rfc-editor.org/info/rfc8225>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, <https://www.rfc-editor.org/info/rfc8225>.
[CIDER] Kaplan, H., "A proposal for Caller Identity in a DNS-based Entrusted Registry (CIDER)", Work in Progress, draft-kaplan-stir-cider-00, July 2013.
[CIDER] Kaplan, H., "A proposal for Caller Identity in a DNS-based Entrusted Registry (CIDER)", Work in Progress, draft-kaplan-stir-cider-00, July 2013.
[IRI-COMPARISON] Masinter, L. and M. Duerst, "Comparison, Equivalence and Canonicalization of Internationalized Resource Identifiers", Work in Progress, draft-ietf-iri-comparison-02, October 2012.
[IRI-COMPARISON] Masinter, L. and M. Duerst, "Comparison, Equivalence and Canonicalization of Internationalized Resource Identifiers", Work in Progress, draft-ietf-iri-comparison-02, October 2012.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999, <https://www.rfc-editor.org/info/rfc2585>.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999, <https://www.rfc-editor.org/info/rfc2585>.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <https://www.rfc-editor.org/info/rfc3323>.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <https://www.rfc-editor.org/info/rfc3323>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <https://www.rfc-editor.org/info/rfc3325>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <https://www.rfc-editor.org/info/rfc3325>.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, DOI 10.17487/RFC3893, September 2004, <https://www.rfc-editor.org/info/rfc3893>.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, DOI 10.17487/RFC3893, September 2004, <https://www.rfc-editor.org/info/rfc3893>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, <https://www.rfc-editor.org/info/rfc4474>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, <https://www.rfc-editor.org/info/rfc4474>.
[RFC4501] Josefsson, S., "Domain Name System Uniform Resource Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006, <https://www.rfc-editor.org/info/rfc4501>.
[RFC4501] Josefsson, S., "Domain Name System Uniform Resource Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006, <https://www.rfc-editor.org/info/rfc4501>.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 2007, <https://www.rfc-editor.org/info/rfc4916>.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 2007, <https://www.rfc-editor.org/info/rfc4916>.
[RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B. Campen, "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", RFC 5393, DOI 10.17487/RFC5393, December 2008, <https://www.rfc-editor.org/info/rfc5393>.
[RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B. Campen, "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", RFC 5393, DOI 10.17487/RFC5393, December 2008, <https://www.rfc-editor.org/info/rfc5393>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, <https://www.rfc-editor.org/info/rfc7340>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, <https://www.rfc-editor.org/info/rfc7340>.
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", RFC 7375, DOI 10.17487/RFC7375, October 2014, <https://www.rfc-editor.org/info/rfc7375>.
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", RFC 7375, DOI 10.17487/RFC7375, October 2014, <https://www.rfc-editor.org/info/rfc7375>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, <https://www.rfc-editor.org/info/rfc8226>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, <https://www.rfc-editor.org/info/rfc8226>.
[SIP-RETARGET] Peterson, J., "Retargeting and Security in SIP: A Framework and Requirements", Work in Progress, draft-peterson-sipping-retarget-00, February 2005.
[SIP-RETARGET] Peterson, J., "Retargeting and Security in SIP: A Framework and Requirements", Work in Progress, draft-peterson-sipping-retarget-00, February 2005.
[SIP-RFC4474-CONCERNS] Rosenberg, J., "Concerns around the Applicability of RFC 4474", Work in Progress, draft-rosenberg-sip-rfc4474- concerns-00, February 2008.
[SIP-RFC4474-CONCERNS] Rosenberg, J., "Concerns around the Applicability of RFC 4474", Work in Progress, draft-rosenberg-sip-rfc4474- concerns-00, February 2008.
[TS-3GPP.23.228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 7.7.0, March 2007, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
[TS-3GPP.23.228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 7.7.0, March 2007, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
The authors would like to thank Adam Roach, Jim Schaad, Ning Zhang, Syed Ali, Olle Jacobson, Dave Frankel, Robert Sparks, Dave Crocker, Stephen Kent, Brian Rosen, Alex Bobotek, Paul Kyzivat, Jonathan Lennox, Richard Shockey, Martin Dolly, Andrew Allen, Hadriel Kaplan, Sanjay Mishra, Anton Baskov, Pierce Gorman, David Schwartz, Eric Burger, Alan Ford, Christer Holmberg, Philippe Fouquart, Michael Hamer, Henning Schulzrinne, and Richard Barnes for their comments.
著者は、コメントを寄せたAdam Roach、Jim Schaad、Ning Zhang、Syed Ali、Olle Jacobson、Dave Frankel、Robert Sparks、Dave Crocker、Stephen Kent、Brian Rosen、Alex Bobotek、Paul Kyzivat、Jonathan Lennox、Richard Shockey、Martin Dolly、Andrew Allen、Hadriel Kaplan、Sanjay Mishra、Anton Baskov、Pierce Gorman、David Schwartz、Eric Burger、Alan Ford、Christer Holmberg、Philippe Fouquart、Michael Hamer、Henning Schulzrinne、Richard Barnesに感謝します。
Jon Peterson Neustar, Inc. 1800 Sutter St. Suite 570 Concord, CA 94520 United States of America
Jon Peterson Neustar, Inc. 1800 Sutter St. Suite 570 Concord, CA 94520 United States of America
Email: jon.peterson@neustar.biz
Cullen Jennings Cisco 400 3rd Avenue SW, Suite 350 Calgary, AB T2P 4H2 Canada
Cullen Jennings Cisco 400 3rd Avenue SW, Suite 350 Calgary, AB T2P 4H2 Canada
Email: fluffy@cisco.com
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 United States of America
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 United States of America
Email: ekr@rtfm.com
Chris Wendt Comcast One Comcast Center Philadelphia, PA 19103 United States of America
Chris Wendt Comcast One Comcast Center Philadelphia, PA 19103 United States of America
Email: chris-ietf@chriswendt.net