RFC 4474 - Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) 日本語訳

URL : https://tools.ietf.org/html/rfc4474
タイトル : RFC 4474 - セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化
翻訳編集 : 自動生成

Network Working Group                                        J. Peterson
Request for Comments: 4474                                       NeuStar
Category: Standards Track                                    C. Jennings
                                                           Cisco Systems
                                                             August 2006

       Enhancements for Authenticated Identity Management in the
                   Session Initiation Protocol (SIP)

Status of This Memo

このメモのステータス

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2006）。

Abstract

抽象

The existing 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 messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer.

セッション開始プロトコル（SIP）における既存のセキュリティメカニズムは、暗号特にドメイン間コンテキストにおいて、SIPリクエストを発信エンドユーザの身元を保証するには不十分です。この文書では、確実にSIPメッセージの発信者を識別するためのメカニズムを定義します。これは、署名者の証明書への参照を搬送するため、アイデンティティを検証するために使用される署名、およびアイデンティティ情報を搬送するため、二つの新しいSIPヘッダフィールド、アイデンティティを定義することによってそうします。

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Background ......................................................3
   4. Overview of Operations ..........................................6
   5. Authentication Service Behavior .................................7
      5.1. Identity within a Dialog and Retargeting ..................10
   6. Verifier Behavior ..............................................11
   7. Considerations for User Agent ..................................12
   8. Considerations for Proxy Servers ...............................13
   9. Header Syntax ..................................................13
   10. Compliance Tests and Examples .................................16
      10.1. Identity-Info with a Singlepart MIME body ................17
      10.2. Identity for a Request with No MIME Body or Contact ......20
   11. Identity and the TEL URI Scheme ...............................22
   12. Privacy Considerations ........................................23
   13. Security Considerations .......................................24
      13.1. Handling of digest-string Elements .......................24
      13.2. Display-Names and Identity ...............................27
      13.3. Securing the Connection to the Authentication Service ....28
      13.4. Domain Names and Subordination ...........................29
      13.5. Authorization and Transitional Strategies ................30
   14. IANA Considerations ...........................................31
      14.1. Header Field Names .......................................31
      14.2. 428 'Use Identity Header' Response Code ..................32
      14.3. 436 'Bad Identity-Info' Response Code ....................32
      14.4. 437 'Unsupported Certificate' Response Code ..............32
      14.5. 438 'Invalid Identity Header' Response Code ..............33
      14.6. Identity-Info Parameters .................................33
      14.7. Identity-Info Algorithm Parameter Values .................33
   Appendix A. Acknowledgements ......................................34
   Appendix B. Bit-Exact Archive of Examples of Messages .............34
      B.1. Encoded Reference Files ...................................35
   Appendix C. Original Requirements .................................38
   References ........................................................39
      Normative References ...........................................39
      Informative References .........................................39

1. Introduction

1. はじめに

This document provides enhancements to the existing mechanisms for authenticated identity management in the Session Initiation Protocol (SIP, RFC 3261 [1]). An identity, for the purposes of this document, is defined as a SIP URI, commonly a canonical address-of-record (AoR) employed to reach a user (such as 'sip:alice@atlanta.example.com').

この文書は、認証されたアイデンティティのセッション開始プロトコルで管理するための既存のメカニズムへの拡張機能を提供（SIP、RFC 3261 [1]）。同一性は、本文書の目的のために、SIP URIとして定義され、一般に正規のアドレス・オブ・レコード（のAoR）が（例えば「：alice@atlanta.example.com SIP」として）ユーザに到達するために使用しました。

RFC 3261 stipulates several places within a SIP request where a user can express an identity for themselves, notably the user-populated From header field. However, the recipient of a SIP request has no way to verify that the From header field has been populated appropriately, in the absence of some sort of cryptographic authentication mechanism.

RFC 3261は、ユーザが自身のIDを表現することができるSIP要求、特にユーザ移入Fromヘッダフィールド内のいくつかの場所を定めています。しかしながら、SIPリクエストの受信者は、ヘッダフィールドから暗号化認証メカニズムのある種の非存在下で、適切に移入されていることを確認する方法がありません。

RFC 3261 specifies a number of security mechanisms that can be employed by SIP user agents (UAs), including Digest, Transport Layer Security (TLS), and S/MIME (implementations may support other security schemes as well). However, few SIP user agents today support the end-user certificates necessary to authenticate themselves (via S/MIME, for example), and furthermore Digest authentication is limited by the fact that the originator and destination must share a prearranged secret. It is desirable for SIP user agents to be able to send requests to destinations with which they have no previous association -- just as in the telephone network today, one can receive a call from someone with whom one has no previous association, and still have a reasonable assurance that the person's displayed Caller-ID is accurate. A cryptographic approach, like the one described in this document, can probably provide a much stronger and less-spoofable assurance of identity than the telephone network provides today.

RFC 3261は、ダイジェスト、トランスポート層セキュリティ（TLS）、およびS / MIME（実装は、他のセキュリティ方式をサポートすることができる）を含むSIPユーザエージェント（UAS）によって使用することができるセキュリティ機構の数を指定します。しかし、いくつかのSIPユーザエージェント今日は（例えば、S / MIMEを経由して）自分自身を認証するために必要なエンドユーザーの証明書をサポートし、さらにダイジェスト認証は、発信元と宛先が事前に決められた秘密を共有しなければならないという事実によって制限されています。 SIPユーザエージェントは、彼らが以前の関連性がないいるとの宛先にリクエストを送信できるようにすることが望ましい - ちょうど電話網のように、今日を、1は1つが以前の関連性を持っていない、誰と誰からの電話を受けて、まだ持っていることができます人の表示発信者IDが正確であることの合理的な保証。暗号化のアプローチは、この文書で説明したものと同様に、おそらく電話網が今日提供よりもはるかに強いとアイデンティティのあまり偽装可能な保証を提供することができます。

2. Terminology

2.用語

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.

この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、及び「OPTIONAL」は、RFC 2119 [2]に記載のコンプライアントSIP実装の要求レベルを示すものとして解釈されるべきです。

3. Background

3.背景

The usage of many SIP applications and services is governed by authorization policies. These policies may be automated, or they may be applied manually by humans. An example of the latter would be an Internet telephone application that displays the Caller-ID of a caller, which a human may review before answering a call. An example of the former would be a presence service that compares the identity of potential subscribers to a whitelist before determining whether it should accept or reject the subscription. In both of these cases, attackers might attempt to circumvent these authorization policies through impersonation. Since the primary identifier of the sender of a SIP request, the From header field, can be populated arbitrarily by the controller of a user agent, impersonation is very simple today. The mechanism described in this document aspires to provide a strong identity system for SIP in which authorization policies cannot be circumvented by impersonation.

多くのSIPアプリケーションおよびサービスの使用は認可ポリシーによって管理されます。これらのポリシーは、自動化され得る、またはそれらは、ヒトによって手動で適用することができます。後者の例は、ヒトが呼び出しに応答する前に検討することができる、発信者の発信者IDを表示するインターネット電話アプリケーションだろう。前者の例は、サブスクリプションを受け入れるか拒否するかどうかを決定する前に、ホワイトリストに潜在的な加入者の身元を比較プレゼンスサービスになります。いずれの場合も、攻撃者は偽装を介してこれらの認可ポリシーを回避しようとする場合があります。 SIP要求の送信元の一次識別子ので、ヘッダフィールドから、ユーザエージェントの制御により任意に移入することができ、偽装は、今日非常に簡単です。この文書で説明するメカニズムは、認可ポリシーは、偽装によって回避することができないSIPのための強力なアイデンティティシステムを提供することを目指しています。

All RFC 3261-compliant user agents support Digest authentication, which utilizes a shared secret, as a means for authenticating themselves to a SIP registrar. Registration allows a user agent to express that it is an appropriate entity to which requests should be sent for a particular SIP AoR URI (e.g., 'sip:alice@atlanta.example.com').

すべてのRFC 3261に準拠したユーザエージェントは、SIPレジストラに自分自身を認証するための手段として、共有秘密を利用してダイジェスト認証をサポートしています。登録は、ユーザエージェントは、（例えば、「：alice@atlanta.example.com SIP」）特定のSIP URIのAoRのために送信されるべき要求に適切なエンティティであることを表現することを可能にします。

By the definition of identity used in this document, registration is a proof of the identity of the user to a registrar. However, the credentials with which a user agent proves its identity to a registrar cannot be validated by just any user agent or proxy server -- these credentials are only shared between the user agent and their domain administrator. So this shared secret does not immediately help a user to authenticate to a wide range of recipients. Recipients require a means of determining whether or not the 'return address' identity of a non-REGISTER request (i.e., the From header field value) has legitimately been asserted.

このドキュメントで使用されているアイデンティティの定義では、登録は、レジストラへのユーザーの身元の証明です。しかし、ユーザーエージェントは、レジストラにその身元を証明していると資格証明書はただのユーザーエージェントまたはプロキシサーバーによって検証することができない - これらの資格は、唯一のユーザーエージェントとそのドメイン管理者の間で共有されています。だから、この共有秘密は、すぐにユーザーが受信者の広い範囲への認証には役立ちません。受信者は、非REGISTER要求（ヘッダフィールド値から、すなわち、）の「リターンアドレス」アイデンティティが合法的にアサートされたか否かを決定する手段を必要とします。

The AoR URI used for registration is also the URI with which a UA commonly populates the From header field of requests in order to provide a 'return address' identity to recipients. From an authorization perspective, if you can prove you are eligible to register in a domain under a particular AoR, you can prove you can legitimately receive requests for that AoR, and accordingly, when you place that AoR in the From header field of a SIP request other than a registration (like an INVITE), you are providing a 'return address' where you can legitimately be reached. In other words, if you are authorized to receive requests for that 'return address', logically, it follows that you are also authorized to assert that 'return address' in your From header field. This is of course only one manner in which a domain might determine how a particular user is authorized to populate the From header field; as an aside, for other sorts of URIs in the From (like anonymous URIs), other authorization policies would apply.

登録に使用のAoR URIはまた、UAは、一般的に受信者に「リターンアドレス」アイデンティティを提供するために、リクエストのFromヘッダーフィールドに移入されるURIです。承認の観点から、あなたは、特定のAoR下のドメインに登録する資格があることを証明できる場合は、SIPのFromヘッダーフィールドでのAoRことを置くとき、あなたは、それに応じてあなたが合法的にそののAoRのための要求を受信できることを証明し、することができます（INVITEのような）登録以外の要求は、あなたが合法的に到達することができる「戻りアドレス」を提供しています。あなたがその「戻りアドレス」の要求を受信することが許可されている場合は、他の言葉では、論理的に、また、あなたのFromヘッダーフィールドに「アドレスを返す」ことを主張することが許可されていることになります。もちろん、これは、ドメインは、特定のユーザがヘッダのフィールドをポピュレートすることを許可されている方法を決定する可能性のある唯一の方法です。余談として、（匿名のURIなど）からのURIの他の種類のために、他の認可ポリシーが適用されます。

Ideally, then, SIP user agents should have some way of proving to recipients of SIP requests that their local domain has authenticated them and authorized the population of the From header field. This document proposes a mediated authentication architecture for SIP in which requests are sent to a server in the user's local domain, which authenticates such requests (using the same practices by which the domain would authenticate REGISTER requests). Once a message has been authenticated, the local domain then needs some way to communicate to other SIP entities that the sending user has been authenticated and its use of the From header field has been authorized. This document addresses how that imprimatur of authentication can be shared.

理想的には、その後、SIPユーザエージェントは、SIPの受信者に証明するいくつかの方法を持っている必要があり、そのローカルドメインは、それらを認証されてから、ヘッダフィールドの人口を承認していることを要求します。この文書では、要求が（ドメインはREGISTER要求を認証することになることで、同じプラクティスを使用して）、そのような要求を認証し、ユーザーのローカルドメインにサーバーに送信されるSIPのための媒介認証アーキテクチャを提案しています。メッセージが認証された後、ローカルドメインは、次いで、送信ユーザが認証され、Fromヘッダフィールドの使用が認可された他のSIPエンティティに通信するための何らかの方法が必要です。この文書では、認証のimprimaturを共有することができますどのように対処しています。

RFC 3261 already describes an architecture very similar to this in Section 26.3.2.2, in which a user agent authenticates itself to a local proxy server, which in turn authenticates itself to a remote proxy server via mutual TLS, creating a two-link chain of transitive authentication between the originator and the remote domain. While this works well in some architectures, there are a few respects in which this is impractical. For one, transitive trust is inherently weaker than an assertion that can be validated end-to-end. It is possible for SIP requests to cross multiple intermediaries in separate administrative domains, in which case transitive trust becomes even less compelling.

RFC 3261は、既にの2リンクチェーンを作成し、ユーザエージェントが順番に相互TLSを介してリモートプロキシサーバに対して自身を認証するローカルプロキシサーバに対して自身を認証するセクション26.3.2.2でこれと非常によく似たアーキテクチャを説明します発信元とリモートドメイン間で推移認証。これは、いくつかのアーキテクチャではうまく動作しますが、これは非現実的であるいくつかの点があります。一つは、推移的な信頼は、エンドツーエンドを検証することができます主張よりも本質的に弱いです。 SIPリクエストは、ケースの推移的な信頼がさらに少なく魅力的になっている別の管理ドメイン内に複数の仲介を横断することが可能です。

One solution to this problem is to use 'trusted' SIP intermediaries that assert an identity for users in the form of a privileged SIP header. A mechanism for doing so (with the P-Asserted-Identity header) is given in [12]. However, this solution allows only hop-by-hop trust between intermediaries, not end-to-end cryptographic authentication, and it assumes a managed network of nodes with strict mutual trust relationships, an assumption that is incompatible with widespread Internet deployment.

この問題の解決策の1つは、特権SIPヘッダの形式でユーザーのためのアイデンティティを主張する「信頼」SIPの仲介を使用することです。（P-Asserted-Identityヘッダと）そうするための機構は、[12]に記載されています。しかし、この解決策は仲介の間の唯一のホップバイホップの信頼を可能にする、ない暗号認証にエンド - エンド、それは厳格な相互の信頼関係を持つノードの管理するネットワーク、広範なインターネットの展開と互換性のない仮定を前提としています。

Accordingly, this document specifies a means of sharing a cryptographic assurance of end-user SIP identity in an interdomain or intradomain context that is based on the concept of an 'authentication service' and a new SIP header, the Identity header. Note that the scope of this document is limited to providing this identity assurance for SIP requests; solving this problem for SIP responses is more complicated and is a subject for future work.

したがって、この文書は、「認証サービス」と新しいSIPヘッダ、Identityヘッダーの概念に基づいてドメイン間またはドメイン内のコンテキストでエンドユーザーのSIPアイデンティティの暗号保証を共有する手段を指定します。この文書の範囲は、SIPリクエストのために、このアイデンティティ保証を提供することに制限されていることに注意してください。 SIP応答のために、この問題を解決することは、より複雑であり、将来の仕事のための主題です。

This specification allows either a user agent or a proxy server to provide identity services and to verify identities. To maximize end-to-end security, it is obviously preferable for end-users to acquire their own certificates and corresponding private keys; if they do, they can act as an authentication service. However, end-user certificates may be neither practical nor affordable, given the difficulties of establishing a Public Key Infrastructure (PKI) that extends to end-users, and moreover, given the potentially large number of SIP user agents (phones, PCs, laptops, PDAs, gaming devices) that may be employed by a single user. In such environments, synchronizing keying material across multiple devices may be very complex and requires quite a good deal of additional endpoint behavior. Managing several certificates for the various devices is also quite problematic and unpopular with users. Accordingly, in the initial use of this mechanism, it is likely that intermediaries will instantiate the authentication service role.

この仕様は、ユーザーエージェントやアイデンティティサービスを提供し、身元を確認するために、プロキシサーバのいずれかを可能にします。エンドユーザーが独自の証明書と対応する秘密鍵を取得するためのエンドツーエンドのセキュリティを最大化するために、それは明らかに好適です。彼らがしなければ、彼らは認証サービスとして機能します。しかし、エンドユーザーの証明書は、エンドユーザーに拡張する公開鍵基盤（PKI）を確立することの難しさを考えると、実用的にも手頃な価格でもないとすることができ、しかも、潜在的に大規模なSIPユーザエージェントの数（携帯電話、PC、ラップトップ与えられました単一のユーザによって使用されてもよいやPDA、ゲーム機）。このような環境では、複数のデバイス間で鍵材料を同期することは非常に複雑で、追加のエンドポイントの振る舞いのかなり良い取引を必要とします。様々なデバイスのためのいくつかの証明書を管理することも非常に問題とユーザーと不評です。したがって、このメカニズムの初期の使用では、仲介者は、認証サービスの役割をインスタンス化する可能性があります。

4. Overview of Operations

事業の概要4。

This section provides an informative (non-normative) high-level overview of the mechanisms described in this document.

このセクションでは、本書で説明されたメカニズムの有益な（非規範的）高レベルの概要を提供します。

Imagine the case where Alice, who has the home proxy of example.com and the address-of-record sip:alice@example.com, wants to communicate with sip:bob@example.org.

alice@example.com、SIPと通信したい：bob@example.org example.comのホームプロキシとアドレスのレコード一口を持っているアリスは、ケースを想像してみてください。

Alice generates an INVITE and places her identity in the From header field of the request. She then sends an INVITE over TLS to an authentication service proxy for her domain.

アリスは、INVITEを生成し、リクエストのFromヘッダーフィールドに彼女のアイデンティティを置きます。彼女はその後、彼女のドメインの認証サービスプロキシにTLSの上にINVITEを送信します。

The authentication service authenticates Alice (possibly by sending a Digest authentication challenge) and validates that she is authorized to assert the identity that is populated in the From header field. This value may be Alice's AoR, or it may be some other value that the policy of the proxy server permits her to use. It then computes a hash over some particular headers, including the From header field and the bodies in the message. This hash is signed with the certificate for the domain (example.com, in Alice's case) and inserted in a new header field in the SIP message, the 'Identity' header.

認証サービスは、（おそらくダイジェスト認証チャレンジを送信することにより）アリスを認証し、彼女はFromヘッダーフィールドに移入されたアイデンティティを主張するために許可されていることを検証します。この値は、アリスののAoRであってもよいし、プロキシサーバーのポリシーは、彼女が使用することを許可するいくつかの他の値であってもよいです。次に、Fromヘッダフィールドと、メッセージ中の体を含め、いくつかの特定のヘッダ上のハッシュを計算します。このハッシュは、ドメインの証明書で署名（example.com、アリスの場合）と、SIPメッセージ、「アイデンティティ」ヘッダに新たなヘッダフィールドに挿入されます。

The proxy, as the holder of the private key of its domain, is asserting that the originator of this request has been authenticated and that she is authorized to claim the identity (the SIP address-of-record) that appears in the From header field. The proxy also inserts a companion header field, Identity-Info, that tells Bob how to acquire its certificate, if he doesn't already have it.

プロキシは、そのドメインの秘密鍵の所有者として、この要求の発信元が認証されていることを主張していると彼女はアイデンティティを主張するために許可されていること（SIPアドレスのレコード）Fromヘッダーフィールドに表示されます。プロキシはまた、彼はすでにそれを持っていない場合は、その証明書を取得する方法をボブに指示コンパニオンヘッダフィールド、アイデンティティ情報を、挿入されます。

When Bob's domain receives the request, it verifies the signature provided in the Identity header, and thus can validate that the domain indicated by the host portion of the AoR in the From header field authenticated the user, and permitted the user to assert that From header field value. This same validation operation may be performed by Bob's user agent server (UAS).

ボブのドメインが要求を受信すると、それは、Identityヘッダに設けられた署名を検証し、従ってヘッダフィールドからのAoRのホスト部分で示す領域は、ユーザを認証し、ヘッダからそれを主張することをユーザに許可することを検証することができフィールドの値。この同じ検証動作は、ボブのユーザエージェントサーバ（UAS）により行うことができます。

5. Authentication Service Behavior

5.認証サービスの動作

This document defines a new role for SIP entities called an authentication service. The authentication service role can be instantiated by a proxy server or a user agent. Any entity that instantiates the authentication service role MUST possess the private key of a domain certificate. Intermediaries that instantiate this role MUST be capable of authenticating one or more SIP users that can register in that domain. Commonly, this role will be instantiated by a proxy server, since these entities are more likely to have a static hostname, hold a corresponding certificate, and have access to SIP registrar capabilities that allow them to authenticate users in their domain. 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.

この文書では、認証サービスと呼ばれるSIPエンティティのための新しい役割を定義します。認証サービスの役割は、プロキシサーバまたはユーザエージェントによってインスタンス化することができます。認証サービスの役割をインスタンス化する任意のエンティティは、ドメイン証明書の秘密鍵を持っていなければなりません。この役割をインスタンス化仲介は、そのドメインに登録することができる1人のまたは複数のSIPユーザーを認証することができなければなりません。これらのエンティティは、静的なホスト名を持って対応する証明書を保持し、彼らのドメインでユーザーを認証できるようにするSIPレジストラ機能へのアクセス権を持っている可能性がありますので、一般的に、この役割は、プロキシサーバによってインスタンス化されます。認証サービスの役割がリダイレクトサーバとして動作するエンティティによってインスタンス化されるかもしれないが、それは今後の作業のためのトピックとして残されていることも可能です。

SIP entities that act as an authentication service MUST add a Date header field to SIP requests if one is not already present (see Section 9 for information on how the Date header field assists verifiers). Similarly, authentication services MUST add a Content-Length header field to SIP requests if one is not already present; this can help verifiers to double-check that they are hashing exactly as many bytes of message-body as the authentication service when they verify the message.

1が存在しない場合、認証サービスとして動作するSIPエンティティは、要求をSIPにDateヘッダーフィールドを追加する必要があります（Dateヘッダフィールドは検証を支援する方法については、セクション9を参照してください）。同様に、認証サービスは1つが既に存在しない場合、要求をSIPにContent-Lengthヘッダフィールドを追加しなければなりません。これは、検証は、彼らがメッセージを確認する認証サービスとして正確にメッセージボディの多くのバイトをハッシュ化していることをダブルチェックすることができます。

Entities instantiating the authentication service role perform the following steps, in order, to generate an Identity header for a SIP request:

認証サービスの役割をインスタンス化するエンティティは、SIPリクエストのIdentityヘッダを生成するために、順番に、次の手順を実行します。

Step 1:

ステップ1：

The authentication service MUST extract the identity of the sender from the request. The authentication service takes this value from the From header field; this AoR will be referred to here as the 'identity field'. If the identity field contains a SIP or SIP Secure (SIPS) URI, the authentication service MUST extract the hostname portion of the identity field and compare it to the domain(s) for which it is responsible (following the procedures in RFC 3261, Section 16.4, used by a proxy server to determine the domain(s) for which it is responsible). If the identity field uses the TEL URI scheme, the policy of the authentication service determines whether or not it is responsible for this identity; see Section 11 for more information. If the authentication service is not responsible for the identity in question, it SHOULD process and forward the request normally, but it MUST NOT add an Identity header; see below for more information on authentication service handling of an existing Identity header.

認証サービスは要求から送信者の身元を抽出する必要があります。認証サービスは、Fromヘッダフィールドからこの値をとります。これのAoRは「アイデンティティーフィールド」としてここで参照されます。アイデンティティフィールドはSIPまたはSIPセキュア（SIPS）URIが含まれている場合は、認証サービスは、IDフィールドのホスト名部分を抽出し、（RFC 3261、セクションでの手順に従って、それが担当するドメイン（複数可）に、それを比較する必要がありますそれが担当するドメイン（単数または複数）を決定するためにプロキシ・サーバによって使用される16.4）。アイデンティティフィールドはTEL URIスキームを使用している場合は、認証サービスのポリシーは、それが、このアイデンティティの責任であるか否かを判断します。詳細については、セクション11を参照してください。認証サービスが問題のアイデンティティを担当していない場合は、それが処理し、正常に要求を転送しますが、Identityヘッダーを追加してはならないべきです。既存のIdentityヘッダの認証サービスの取り扱いの詳細については、下記を参照してください。

Step 2:

ステップ2：

The authentication service MUST determine whether or not the sender 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 sender of the message. Some possible ways in which this authentication might be performed include:

認証サービスは、リクエストの送信者が身元フィールドで与えられたアイデンティティを主張することが許可されているかどうかを決定しなければなりません。そうするためには、認証サービスは、メッセージの送信者を認証しなければなりません。この認証が行われるかもしれないいくつかの可能な方法は次のとおりです。

         If the authentication service is instantiated by a SIP
         intermediary (proxy server), it may challenge the request with
         a 407 response code using the Digest authentication scheme (or
         viewing a Proxy-Authentication header sent in the request,
         which was sent in anticipation of a challenge using cached
         credentials, as described in RFC 3261, Section 22.3).  Note
         that if that proxy server is maintaining a TLS connection with
         the client over which the client had previously authenticated
         itself using Digest authentication, the identity value obtained
         from that previous authentication step can be reused without an
         additional Digest challenge.

If the authentication service is instantiated by a SIP user agent, a user agent can be said to authenticate its user on the grounds that the user can provision the user agent with the private key of the domain, or preferably by providing a password that unlocks said private key.

認証サービスは、SIPユーザエージェントによってインスタンス化されている場合は、ユーザエージェントが理由でそのユーザを認証すると言うことができ、ユーザ缶の提供、そのドメインの秘密鍵を持つユーザエージェント、または好ましくは、前記ロックを解除するパスワードを提供することにより、秘密鍵。

Authorization of the use of a particular username in the From header field is a matter of local policy for the authentication service, one that depends greatly on the manner in which authentication is performed. For example, one policy might be as follows: the username given in the 'username' parameter of the Proxy-Authorization header 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 Proxy-Authorization that do not correspond to the user-portion of SIP From headers, 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 Proxy-Authorization 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 in Third Generation Partnership Project (3GPP), 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. Various exceptions to such policies might arise for cases like anonymity; if the AoR asserted in the From header field uses a form like 'sip:anonymous@example.com', then the 'example.com' proxy should authenticate that the user is a valid user in the domain and insert the signature over the From header field as usual.

Fromヘッダフィールドに特定のユーザ名を使用することの許可は、認証サービスは、認証が行われる方法に大きく依存するいずれかのローカルポリシーの問題です。プロキシ認証ヘッダの「ユーザ名」パラメータで指定されたユーザー名は、SIPメッセージのヘッダからフィールドにユーザ名に正確に対応しなければならない：例えば以下のように、あるポリシーがあるかもしれません。しかし、これはあまりにも制限または不適切されている場合が多いです。レルムは、FromヘッダーSIPのユーザー部分に対応していないプロキシ認証の「ユーザー名」パラメータを使用するかもしれない、またはユーザーが同じ管理ドメインで複数のアカウントを管理することがあります。この後者の場合では、ドメインは、プロキシ認証の「ユーザー名」パラメータの値と合法その「ユーザ名」アサートされるかもしれない一つまたは複数のSIP URIの組との間のマッピングを維持するかもしれません。ヘッダフィールドからこのプライベートアイデンティティに関連付けられた公開アイデンティティのいずれかを含むことができ、その場合、第三世代パートナーシッププロジェクト（3GPP）で定義されるように、例えば、ユーザ名が「プライベートアイデンティティ」に対応することができます。次のようにこの例では、別のポリシーがあるかもしれない：Fromヘッダフィールド内のURIは、Proxy-Authorizationヘッダで与えられる「ユーザ名」に関連付けられたマッピングされたURIの一つに正確に対応しなければなりません。そのような政策への様々な例外は匿名性のような場合のために発生する可能性があります。 AoRは、Fromヘッダーフィールドにアサート場合は、「一口：anonymous@example.com」のようなフォームを使用し、その後、「example.com」プロキシは、ユーザーがドメイン内の有効なユーザーであることを認証してから、上で署名を挿入する必要がありますいつものようにヘッダーフィールド。

Note that this check is performed on the addr-spec in the From header field (e.g., the URI of the sender, like 'sip:alice@atlanta.example.com'); it does not convert the display-name portion of the From header field (e.g., 'Alice Atlanta'). Authentication services MAY check and validate the display-name as well, and compare it to a list of acceptable display-names that may be used by the sender; if the display-name does not meet policy constraints, the authentication service MUST return a 403 response code. 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. For more information, see Section 13.2.

このチェックは、FromヘッダフィールドにADDR仕様上で実行されることに留意されたい（例えば、「SIP：alice@atlanta.example.com」のような送信者のURI）。それはFromヘッダフィールド（例えば、「アリスアトランタ」）の表示名の部分を変換しません。チェックと同様の表示名を確認し、送信者が使用することができる許容されるディスプレイ名のリストにそれを比較することができる認証サービス。表示名は、ポリシー制約を満たしていない場合、認証サービスは、403応答コードを返さなければなりません。理由句は、問題の性質を示すべきです。例えば、「不適切な表示名」。ただし、表示名は常に存在していない、と多くの環境で表示名を検証するために必要な操作手順が存在しない場合があります。詳細については、13.2節を参照してください。

Step 3:

ステップ3：

The authentication service SHOULD ensure that any preexisting Date header in the request is accurate. Local policy can dictate precisely how accurate the Date must be; a RECOMMENDED maximum discrepancy of ten minutes will ensure that the request is unlikely to upset any verifiers. If the Date header contains a time different by more than ten minutes from the current time noted by the authentication service, the authentication service SHOULD reject the request. This behavior is not mandatory because a user agent client (UAC) could only exploit the Date header in order to cause a request to fail verification; the Identity header is not intended to provide a source of non-repudiation or a perfect record of when messages are processed. Finally, the authentication service MUST verify that the Date header falls within the validity period of its certificate. For more information on the security properties associated with the Date header field value, see Section 9.

認証サービスは、要求内の任意の既存のDateヘッダが正確であることを確認する必要があります。ローカルポリシーは、日付でなければなりませんどのように正確に正確に指示することができます。 10分の推奨最大不一致は、要求が任意の検証を混乱しそうであることを確認します。 Dateヘッダは、認証サービスによって指摘、現在の時刻から10分以上により、異なる時間が含まれている場合は、認証サービスは要求を拒否すべきです。ユーザエージェントクライアント（UAC）が唯一の検証に失敗する要求を起こすために、Dateヘッダを悪用する可能性がありますので、この動作は必須ではありません。 Identityヘッダは、否認防止のソースまたはメッセージが処理されるときの完璧な記録を提供するものではありません。最後に、認証サービスは、Dateヘッダは、その証明書の有効期間内にあることを確かめなければなりません。日付ヘッダフィールド値に関連付けられたセキュリティプロパティの詳細については、セクション9を参照してください。

Step 4:

ステップ4：

The authentication service MUST form the identity signature and add an Identity header to the request containing this signature. After the Identity header has been added to the request, the authentication service MUST also add an Identity-Info header. The Identity-Info header contains a URI from which its certificate can be acquired. Details on the generation of both of these headers are provided in Section 9.

認証サービスは、同一のシグネチャを形成し、この署名を含む要求にIdentityヘッダを追加しなければなりません。 Identityヘッダーが要求に追加された後、認証サービスは、アイデンティティ-Infoヘッダーを追加しなければなりません。アイデンティティ-Infoヘッダーは、その証明書を取得することができ、そこからURIが含まれています。これらのヘッダの両方の生成の詳細については、セクション9に設けられています。

Finally, the authentication service MUST forward the message normally.

最後に、認証サービスは、通常、メッセージを転送しなければなりません。

5.1. Identity within a Dialog and Retargeting

5.1. ダイアログとリターゲット内のアイデンティティ

Retargeting is broadly defined as the alteration of the Request-URI by intermediaries. More specifically, retargeting supplants the original target URI with one that corresponds to a different user, a user that is not authorized to register under the original target URI. By this definition, retargeting does not include translation of the Request-URI to a contact address of an endpoint that has registered under the original target URI, for example.

リターゲッティングは、広義仲介によるリクエストURIの変更として定義されます。より具体的には、リターゲットは、異なるユーザに対応するもの、元のターゲットURIの下に登録することを許可されていないユーザに元のターゲットURIに取って代わります。この定義によると、再標的は例えば、元のターゲットURIの下に登録されたエンドポイントの連絡先へのRequest-URIの翻訳が含まれていません。

When a dialog-forming request is retargeted, this can cause a few wrinkles for the Identity mechanism when it is applied to requests sent in the backwards direction within a dialog. This section provides some non-normative considerations related to this case.

ダイアログ形成要求がリターゲットされている場合、これは、それがダイアログ内後方方向に送信されたリクエストに適用されたアイデンティティメカニズムのためのいくつかのしわを引き起こす可能性があります。このセクションでは、このケースに関連するいくつかの非規範的配慮を提供します。

When a request is retargeted, it may reach a SIP endpoint whose user is not identified by the URI designated in the To header field value. The value in the To header field of a dialog-forming request is used as the From header field of requests sent in the backwards direction during the dialog, and is accordingly the header that would be signed by an authentication service for requests sent in the backwards direction. In retargeting cases, if the URI in the From header does not identify the sender of the request in the backwards direction, then clearly it would be inappropriate to provide an Identity signature over that From header. As specified above, if the authentication service is not responsible for the domain in the From header field of the request, it MUST NOT add an Identity header to the request, and it should process/forward the request normally.

要求が再標的化されるとき、それは、そのユーザフィールド値をヘッダに指定されたURIによって識別されていないSIPエンドポイントに到達することができます。ダイアログ形成要求のToヘッダーフィールドの値は、ダイアログ中に後方方向に送信されたリクエストのFromヘッダフィールドとして使用され、それに応じて逆方向に送信される要求の認証サービスによって署名されるヘッダであります方向。リターゲットの場合において、もしURIに後方方向にリクエストの送信者を識別しないヘッダから、その後はっきりそれはヘッダからその上にアイデンティティ・シグネチャを提供するためには不適切であろう。認証サービスは、リクエストのFromヘッダーフィールドにドメインの責任でない場合は、上記のとおり、それはリクエストにIdentityヘッダーを追加してはならない、それは/処理する通常の要求を転送する必要があります。

Any means of anticipating retargeting, and so on, is outside the scope of this document, and likely to have equal 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; authentication service behavior is unchanged if retargeting has occurred for a dialog-forming request. Ultimately, the authentication service provides an Identity header for requests in the backwards dialog when the user is authorized to assert the identity given in the From header field, and if they are not, an Identity header is not provided.

ようにリターゲットを予測し、任意の手段は、この文書の範囲外である、そしてそれは、ダイアログ内の後方方向での要求に同じように応答アイデンティティに等しく適用可能性を持っている可能性が。その結果、特別な指導は、「接続先か」の問題についてここでは、実装のために与えられていません。リターゲッティングは、ダイアログ形成要求のために発生した場合、認証サービスの動作は変更されません。最終的にユーザーがFromヘッダーフィールドで与えられたアイデンティティを主張することが許可されている場合、認証サービスは後方ダイアログのリクエストのためにIdentityヘッダを提供し、そうでない場合は、Identityヘッダが提供されていません。

For further information on the problems of response identity and the potential solution spaces, see [15].

応答IDおよび電位溶液空間の問題の詳細については、[15]参照。

6. Verifier Behavior

6.検証の動作

This document introduces a new logical role for SIP entities called a server. When a verifier receives a SIP message containing an Identity header, it may inspect the signature to verify the identity of the sender of the message. Typically, the results of a verification are provided as input to an authorization process that is outside the scope of this document. If an Identity header is not present in a request, and one 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.

この文書では、サーバーと呼ばれるSIPエンティティのための新しい論理的な役割を紹介します。検証者は、Identityヘッダを含むSIPメッセージを受信すると、メッセージの送信者の身元を確認するために署名を検査することができます。典型的には、検証の結果は、この文書の範囲外である認証プロセスへの入力として提供されます。 Identityヘッダは、要求に存在しない、1は、（例えば、毎送信ドメインポリシー、またはごとの送信ユーザポリシーに基づいて）、次いで、428 'を使用するアイデンティティ・ヘッダのローカルポリシーによって必要とされる場合応答が送らなければなりません。

In order to verify the identity of the sender of a message, an entity acting as a verifier MUST perform the following steps, in the order here specified.

メッセージの送信者の身元を確認するために、検証として動作するエンティティは、ここで指定された順序で、次の手順を実行しなければなりません。

Step 1:

ステップ1：

The verifier MUST acquire the certificate for the signing domain. Implementations supporting this specification SHOULD have some means of retaining domain certificates (in accordance with normal practices for certificate lifetimes and revocation) in order to prevent themselves from needlessly downloading the same certificate every time a request from the same domain is received. Certificates cached in this manner should be indexed by the URI given in the Identity-Info header field value.

検証は、署名ドメインの証明書を取得する必要があります。この仕様をサポートする実装は不同じ証明書を同じドメインからの要求が受信されるたびにダウンロードするから身を防ぐために（証明書の有効期限と失効のための通常の慣行に従って）ドメイン証明書を保持するいくつかの手段を持っているべきです。このようにして、キャッシュされた証明書は、Identity-Infoヘッダフィールド値に指定されたURIによって索引付けされるべきです。

Provided that the domain certificate used to sign this message is not previously known to the verifier, SIP entities SHOULD discover this certificate by dereferencing the Identity-Info header, unless they have some more efficient implementation-specific way of acquiring certificates for that domain. If the URI scheme in the Identity-Info header cannot be dereferenced, then a 436 'Bad Identity-Info' response MUST be returned. The verifier processes this certificate in the usual ways, including checking that it has not expired, that the chain is valid back to a trusted certification authority (CA), and that it does not appear on revocation lists. Once the certificate is acquired, it MUST be validated following the procedures in RFC 3280 [9]. If the certificate cannot be validated (it is self-signed and untrusted, or signed by an untrusted or unknown certificate authority, expired, or revoked), the verifier MUST send a 437 'Unsupported Certificate' response.

彼らは、そのドメインの証明書を取得するいくつかのより効率的な実装固有の方法を持っていない限り、このメッセージの署名に使用されるドメイン証明書が以前に検証者に知られていないと仮定すると、SIPエンティティは、アイデンティティ-Infoヘッダーを逆参照することで、この証明書を発見すべきです。アイデンティティ-Infoヘッダー内のURIスキームは逆参照することができない場合は、436「悪いアイデンティティ情報の応答が返されなければなりません。検証プロセス、それはチェーンが戻って、信頼できる認証局（CA）に有効であること、そしてそれが失効リストに表示されないことを、期限が切れていないことを確認するなど、通常の方法で、この証明書。証明書が取得されると、[9] RFC 3280における手順に従って検証されなければなりません。証明書は、（それが自己署名と信頼されていない、または信頼されていないか、不明な証明機関によって署名、期限切れ、または無効化）検証できない場合は、ベリファイアは437「サポートされていない証明書の応答を送らなければなりません。

Step 2:

ステップ2：

The verifier MUST follow the process described in Section 13.4 to determine if the signer is authoritative for the URI in the From header field.

検証者は、署名者からヘッダフィールド内のURIのための権限があるかどうかを決定するために、セクション13.4に記載された方法に従わなければなりません。

Step 3:

ステップ3：

The verifier MUST verify the signature in the Identity header field, following the procedures for generating the hashed digest-string described in Section 9. If a verifier determines that the signature on the message does not correspond to the reconstructed digest-string, then a 438 'Invalid Identity Header' response MUST be returned.

検証者は438次に、検証者がメッセージに署名が再構成されたダイジェスト文字列に対応していないと判断した場合項9に記載のハッシュダイジェスト文字列を生成するための手順に従って、Identityヘッダフィールドに署名を検証しなければなりません「無効なアイデンティティヘッダー」応答が返されなければなりません。

Step 4:

ステップ4：

The verifier MUST validate the Date, Contact, and Call-ID headers in the manner described in Section 13.1; recipients that wish to verify Identity signatures MUST support all of the operations described there. It must furthermore ensure that the value of the Date header falls within the validity period of the certificate whose corresponding private key was used to sign the Identity header.

検証は、日付、連絡先を検証、およびCall-IDヘッダを13.1に記載したようにしなければなりません。アイデンティティの署名を検証したい受信者が説明した操作のすべてをサポートしなければなりません。それはさらに、Dateヘッダーの値は、対応する秘密鍵Identityヘッダーの署名に使用された証明書の有効期間内にあることを確認する必要があります。

7. Considerations for User Agent

ユーザーエージェントのための7の考慮事項

This mechanism can be applied opportunistically to existing SIP deployments; accordingly, it requires no change to SIP user agent behavior in order for it to be effective. However, because this mechanism does not provide integrity protection between the UAC and the authentication service, a UAC SHOULD implement some means of providing this integrity. TLS would be one such mechanism, which is attractive because it MUST be supported by SIP proxy servers, but is potentially problematic because it is a hop-by-hop mechanism. See Section 13.3 for more information about securing the channel between the UAC and the authentication service.

このメカニズムは、既存のSIP展開に日和見適用することができます。したがって、それが効果的であるためにはSIPユーザエージェントの行動への変更を必要としません。このメカニズムは、UACと認証サービスとの間の整合性の保護を提供していないためしかし、UACは、この整合性を提供するいくつかの手段を実装する必要があります。 TLSは、SIPプロキシサーバによってサポートされなければならないので魅力的であるが、それはホップバイホップ機構であるため、潜在的に問題があるような一の機構であろう。 UACと認証サービスとの間のチャネルをセキュリティ保護の詳細については、13.3節を参照してください。

When a UAC sends a request, it MUST accurately populate the From header field with a value corresponding to an identity that it believes it is authorized to claim. In a request, it MUST set the URI portion of its From header to match a SIP, SIPS, or TEL URI AoR that it is authorized to use in the domain (including anonymous URIs, as described in RFC 3323 [3]). In general, UACs SHOULD NOT use the TEL URI form in the From header field (see Section 11).

UACが要求を送るとき、それは正確に主張することを許可されていると考えているアイデンティティに対応する値を有するヘッダフィールドから移入する必要があります。要求に、（RFC 3323に記載されているように[3]、匿名のURIを含む）ドメインで使用することが許可されているSIP、SIPS、またはTEL URIのAoRと一致するヘッダからののURI部分を設定しなければなりません。一般的に、求めるUACは、ヘッダフィールドから（セクション11を参照）TEL URIの形式を使用しないでください。

Note that this document defines a number of new 4xx response codes. If user agents support these response codes, they will be able to respond intelligently to Identity-based error conditions.

このドキュメントは新しいの4xx応答コードの数を定義することに注意してください。ユーザエージェントは、これらの応答コードをサポートする場合は、IDベースのエラー条件にインテリジェントに対応することができるようになります。

The UAC MUST also be capable of sending requests, including mid-call requests, through an 'outbound' proxy (the authentication service). The best way to accomplish this is using pre-loaded Route headers and loose routing. For a given domain, if an entity that can instantiate the authentication service role is not in the path of dialog-forming requests, identity for mid-dialog requests in the backwards direction cannot be provided.

UACはまた、「アウトバウンド」のプロキシ（認証サービス）を介して、ミッドコール要求を含むリクエストを送信することができなければなりません。これを実現する最良の方法は、プリロードされたRouteヘッダとゆるいルーティングを使用しています。認証サービスの役割をインスタンス化することができますエンティティが後方方向に、ダイアログ中のリクエストのためのダイアログ形成要求、アイデンティティのパスにない場合は指定されたドメインでは、提供することはできません。

As a recipient of a request, a user agent that can verify signed identities should also support an appropriate user interface to render the validity of identity to a user. User agent implementations SHOULD differentiate signed From header field values from unsigned From header field values when rendering to an end-user the identity of the sender of a request.

リクエストの受信者として、署名身元を確認することができ、ユーザーエージェントは、ユーザーに身元の妥当性をレンダリングするために適切なユーザインタフェースをサポートする必要があります。エンドユーザに要求の送信者の身元をレンダリングするときにユーザエージェントの実装は、符号なしのヘッダフィールド値からヘッダフィールド値から符号付き区別すべきです。

8. Considerations for Proxy Servers

プロキシサーバのための8の注意事項

Domain policy may require proxy servers to inspect and verify the identity provided in SIP requests. A proxy server may wish to ascertain the identity of the sender of the message to provide spam prevention or call control services. Even if a proxy server does not act as an authentication service, it MAY validate the Identity header before it makes a forwarding decision for a request. Proxy servers MUST NOT remove or modify an existing Identity or Identity-Info header in a request.

ドメインポリシーは、SIPリクエストで提供アイデンティティを検査し、確認するためにプロキシサーバが必要な場合があります。プロキシサーバは、スパム対策を提供したり、制御サービスを呼び出すためのメッセージの送信者の身元を確認することもできます。プロキシサーバが認証サービスとして機能していない場合であっても、それは、要求の転送決定を行う前に、それがIdentityヘッダーを検証することができます。プロキシサーバーは、要求に既存のIDまたはID-Infoヘッダーを削除または変更してはいけません。

9. Header Syntax

9.ヘッダーの構文

This document specifies two new SIP headers: Identity and Identity-Info. Each of these headers can appear only once in a SIP message. The grammar for these two headers is (following the ABNF [6] in RFC 3261 [1]):

アイデンティティとアイデンティティ情報：この文書では、2つの新しいSIPヘッダを指定します。これらのヘッダのそれぞれは、SIPメッセージに一度だけ表示されます。これら2つのヘッダのための文法である（以下のABNF [6] RFCで3261 [1]）。

Identity = "Identity" HCOLON signed-identity-digest signed-identity-digest = LDQUOT 32LHEX RDQUOT

アイデンティティ=「アイデンティティ」HCOLON署名アイデンティティダイジェスト署名アイデンティティダイジェスト= LDQUOT 32LHEX RDQUOT

Identity-Info = "Identity-Info" HCOLON ident-info *( SEMI ident-info-params ) ident-info = LAQUOT absoluteURI RAQUOT ident-info-params = ident-info-alg / ident-info-extension ident-info-alg = "alg" EQUAL token ident-info-extension = generic-param

アイデンティティ情報= "アイデンティティ・インフォ" HCOLONのident-情報*（SEMIのident-情報-のparams）IDENT-情報= LAQUOT absoluteURIでRAQUOTのident-INFO-のparams = IDENT-情報-ALG / IDENT-INFO-延長identを-info- ALG = "ALG" EQUALトークンのident-INFO-延長=ジェネリック-PARAM

The signed-identity-digest is a signed hash of a canonical string generated from certain components of a SIP request. To create the contents of the signed-identity-digest, the following elements of a SIP message MUST be placed in a bit-exact string in the order specified here, separated by a vertical line, "|" or %x7C, character:

署名されたアイデンティティ・ダイジェストは、SIP要求の特定の成分から生成された標準的な文字列の署名されたハッシュです。「|」符号付きアイデンティティダイジェストのコンテンツを作成するために、SIPメッセージの次の要素は、縦線で区切られた、ここで指定された順序でビットの正確な列に配置する必要がありますまたは％x7C、文字：

o The AoR of the UA sending the message, or addr-spec of the From header field (referred to occasionally here as the 'identity field').

UAののAoRがメッセージ、またはヘッダフィールドからのADDRスペックを送信O（へ時にはここで「識別フィールド」という）。

o The addr-spec component of the To header field, which is the AoR to which the request is being sent. o The callid from Call-Id header field. o The digit (1*DIGIT) and method (method) portions from CSeq header field, separated by a single space (ABNF SP, or %x20). Note that the CSeq header field allows linear whitespace (LWS) rather than SP to separate the digit and method portions, and thus the CSeq header field may need to be transformed in order to be canonicalized. The authentication service MUST strip leading zeros from the 'digit' portion of the Cseq before generating the digest-string. o The Date header field, with exactly one space each for each SP and the weekday and month items case set as shown in BNF in RFC 3261. RFC 3261 specifies that the BNF for weekday and month is a choice amongst a set of tokens. The RFC 2234 rules for the BNF specify that tokens are case sensitive. However, when used to construct the canonical string defined here, the first letter of each week and month MUST be capitalized, and the remaining two letters must be lowercase. This matches the capitalization provided in the definition of each token. All requests that use the Identity mechanism MUST contain a Date header. o The addr-spec component of the Contact header field value. If the request does not contain a Contact header, this field MUST be empty (i.e., there will be no whitespace between the fourth and fifth "|" characters in the canonical string). o The body content of the message with the bits exactly as they are in the Message (in the ABNF for SIP, the message-body). This includes all components of multipart message bodies. Note that the message-body does NOT include the CRLF separating the SIP headers from the message-body, but does include everything that follows that CRLF. If the message has no body, then message-body will be empty, and the final "|" will not be followed by any additional characters.

リクエストが送信されたのAoRのフィールドヘッダのADDRスペック成分、O。 Call-IDヘッダーフィールドからcallid O。 O桁（1 * DIGIT）及び方法（メソッド）部分単一空間（ABNF SP、または％X20）によって分離されたCSeqヘッダーフィールドから。 CSeqヘッダーフィールドは、数字及び方法の部分を分離するために、及び従ってCSeqヘッダーフィールドを正規化するために変換する必要があるかもしれなくSPより線形空白（LWS）を可能にすることに留意されたいです。認証サービスは、ダイジェスト文字列を生成する前にCSEQの「数字」部分から先行ゼロを除去しなければなりません。 O正確に一つの各SPの空間それぞれRFC 3261、RFC 3261にBNFのように設定曜日、月アイテムの場合と日付ヘッダーフィールドは、曜日と月のBNFは、トークンのセットの間で選択であることを指定します。 BNFのためのRFC 2234個のルールは、トークンが大文字と小文字が区別されることを指定します。ここで定義された標準的な文字列を構築するために使用する場合ただし、毎週、月の最初の文字を大文字にしなければならない、そして残りの2つの文字は小文字にする必要があります。これは、各トークンの定義で提供さ総額と一致しました。アイデンティティ・メカニズムを使用するすべての要求はDateヘッダを含まなければなりません。 Contactヘッダーフィールド値のADDRスペック成分O。（|標準的な文字列内の文字「」すなわち、第四及び第五の間に空白が生じない）要求がContactヘッダが含まれていない場合、このフィールドは空である必要があります。（SIPのためのABNF、メッセージボディ内の）それらがメッセージにあるとおりにビットを、メッセージの本文の内容O。これは、マルチパートメッセージ本体のすべてのコンポーネントが含まれています。メッセージボディがメッセージ本文からのSIPヘッダを分離するCRLFが含まれていませんが、CRLFということになるすべてのものが含まれないことに注意してください。メッセージに本体がない場合は、メッセージボディは空になり、そして最終的に「|」任意の追加の文字が続くことはありません。

For more information on the security properties of these headers, and why their inclusion mitigates replay attacks, see Section 13 and [5]. The precise formulation of this digest-string is, therefore (following the ABNF [6] in RFC 3261 [1]):

よりこれらのヘッダのセキュリティ特性に関する情報、そしてなぜ彼らのインクルージョンは、リプレイ攻撃を軽減するために、第13条及び[5]を参照してください。このダイジェスト文字列の正確な製剤は、従って、（ABNF以下の[6] RFC 3261 [1]）、です。

Note again that the first addr-spec MUST be taken from the From header field value, the second addr-spec MUST be taken from the To header field value, and the third addr-spec MUST be taken from the Contact header field value, provided the Contact header is present in the request.

最初のaddr-specはヘッダーフィールド値から、第二のaddr-specはフィールド値をヘッダから取らなければならない、そして第三のADDR-specはContactヘッダーフィールド値から取らなければならない、提供から取らなければならないことに再度注意してくださいContactヘッダは、要求に存在しています。

After the digest-string is formed, it MUST be hashed and signed with the certificate for the domain. The hashing and signing algorithm is specified by the 'alg' parameter of the Identity-Info header (see below for more information on Identity-Info header parameters). This document defines only one value for the 'alg' parameter: 'rsa-sha1'; further values MUST be defined in a Standards Track RFC, see Section 14.7 for more information. All implementations of this specification MUST support 'rsa-sha1'. When the 'rsa-sha1' algorithm is specified in the 'alg' parameter of Identity-Info, the hash and signature MUST be generated as follows: compute the results of signing this string with sha1WithRSAEncryption as described in RFC 3370 [7] and base64 encode the results as specified in RFC 3548 [8]. A 1024-bit or longer RSA key MUST be used. The result is placed in the Identity header field. For detailed examples of the usage of this algorithm, see Section 10.

ダイジェストストリングを形成した後、それはハッシュされ、ドメインの証明書で署名されなければなりません。ハッシュおよび署名アルゴリズムは、Identity-INFOヘッダの「ALG」パラメータ（アイデンティティ-Infoヘッダーパラメータの詳細については以下を参照）で指定されています。この文書では、「ALG」パラメータのための一つの値だけを定義しています。「RSA-SHA1を」;さらに値が標準化過程RFCで定義する必要があり、詳細については、セクション14.7を参照してください。この仕様のすべての実装は、「RSA-SHA1」をサポートしなければなりません。「RSA-SHA1」アルゴリズムはアイデンティティ情報の「ALG」パラメータで指定された場合、以下のように、ハッシュおよび署名が生成されなければならない：RFC 3370に記載されているように[7]とBASE64 sha1WithRSAEncryptionでこの文字列に署名した結果を計算します[8] RFC 3548で指定された結果を符号化します。 1024ビット以上のRSAキーを使用しなければなりません。結果は、Identityヘッダフィールドに置かれます。このアルゴリズムの使用方法の詳細な例については、セクション10を参照してください。

The 'absoluteURI' portion of the Identity-Info header MUST contain a URI which dereferences to a resource containing the certificate of the authentication service. All implementations of this specification MUST support the use of HTTP and HTTPS URIs in the Identity-Info header. Such HTTP and HTTPS URIs MUST follow the conventions of RFC 2585 [10], and for those URIs the indicated resource MUST be of the form 'application/pkix-cert' described in that specification. Note that this introduces key lifecycle management concerns; were a domain to change the key available at the Identity-Info 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 Identity-Info URIs for each new certificate, and SHOULD continue to make older key acquisition URIs available for a duration longer than the plausible lifetime of a SIP message (an hour would most likely suffice).

アイデンティティ-Infoヘッダーの「absoluteURIで」部分は、認証サービスの証明書を含むリソースへの間接参照URIを含まなければなりません。この仕様のすべての実装は、Identity-InfoヘッダーでHTTPとHTTPSのURIの使用をサポートしなければなりません。 HTTPやHTTPS URIは、RFC 2585 [10]の規則に従う必要があり、それらのURIの指定されたリソースは、その明細書に記載のフォーム「アプリケーション/ PKIX-CERT」でなければなりません。これは、鍵のライフサイクル管理の懸念を導入していることに注意してください。検証は、認証サービスによって署名された要求を評価する前に、アイデンティティ情報URIで入手可能なキーを変更するには、ドメインた、これは明白な検証の失敗の原因となります。ロールオーバーが発生した場合、認証サービスは、このようにそれぞれの新しい証明書のための新しいアイデンティティ情報のURIを提供すべきであり、SIPメッセージのもっともらしい寿命よりも長い期間のために、古い鍵取得URIが利用できるようにし続けるべきである（時間だろう最も可能性が高いで十分）。

The Identity-Info header field MUST contain an 'alg' parameter. No other parameters are defined for the Identity-Info header in this document. Future Standards Track RFCs may define additional Identity-Info header parameters.

アイデンティティ-Infoヘッダーフィールドは、「ALG」パラメータを含まなければなりません。他のパラメータは、この文書のアイデンティティ-Infoヘッダーのために定義されていません。今後の標準化過程のRFCが追加のアイデンティティ-Infoヘッダーのパラメータを定義することができます。

This document adds the following entries to Table 2 of RFC 3261 [1]:

この文書では、[1] RFC 3261の表2に次のエントリを追加します。

      Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
      ------------         -----   -----   ---  ---  ---  ---  ---  ---
      Identity               R       a      o    o    -    o    o    o

                                           SUB  NOT  REF  INF  UPD  PRA
                                           ---  ---  ---  ---  ---  ---
                                            o    o    o    o    o    o

      Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
      ------------         -----   -----   ---  ---  ---  ---  ---  ---
      Identity-Info          R       a      o    o    -    o    o    o

                                           SUB  NOT  REF  INF  UPD  PRA
                                           ---  ---  ---  ---  ---  ---
                                            o    o    o    o    o    o

Note, in the table above, that this mechanism does not protect the CANCEL method. The CANCEL method cannot be challenged, because it is hop-by-hop, and accordingly authentication service behavior for CANCEL would be significantly limited. Note as well that the REGISTER method uses Contact header fields in very unusual ways that complicate its applicability to this mechanism, and the use of Identity with REGISTER is consequently a subject for future study, although it is left as optional here for forward-compatibility reasons. The Identity and Identity-Info header MUST NOT appear in CANCEL.

このメカニズムはCANCELメソッドを保護しないことを、上記の表では、注意してください。 CANCELメソッドは、ホップバイホップであるので、挑戦し、そして大幅に制限されることでしょうCANCELのためにそれに応じてサービスの動作を認証することはできません。 REGISTERメソッドは、このメカニズムへの適用を複雑に非常に珍しい方法でContactヘッダーフィールドを使用し、それは将来の互換性の理由のために、ここで、オプションとして残されているものの、REGISTERとアイデンティティの使用は、結果として、今後の検討課題であることにも注意してください。アイデンティティとアイデンティティ情報ヘッダは、CANCELにも現れてはなりません。

10. Compliance Tests and Examples

10.コンプライアンス試験および実施例

The examples in this section illustrate the use of the Identity header in the context of a SIP transaction. Implementers are advised to verify their compliance with the specification against the following criteria:

このセクションの例は、SIPトランザクションのコンテキストでIdentityヘッダの使用を示します。実装者は、次の基準に照らし仕様への準拠を検証することをお勧めします。

o Implementations of the authentication service role MUST generate identical base64 identity strings to the ones shown in the Identity headers in these examples when presented with the source message and utilizing the appropriate supplied private key for the domain in question. o Implementations of the verifier role MUST correctly validate the given messages containing the Identity header when utilizing the supplied certificates (with the caveat about self-signed certificates below).

ソースメッセージを提示し、問題のドメインのための適切な提供された秘密鍵を利用する場合、O認証サービスの役割の実装は、これらの例におけるアイデンティティヘッダに示されたものと同一のbase64でアイデンティティの文字列を生成しなければなりません。 O検証者の役割の実装は正しく（以下、自己署名証明書に関する警告で）供給された証明書を利用する場合Identityヘッダを含む所定のメッセージを検証しなければなりません。

Note that the following examples use self-signed certificates, rather than certificates issued by a recognized certificate authority. The use of self-signed certificates for this mechanism is NOT RECOMMENDED, and it appears here only for illustrative purposes. Therefore, in compliance testing, implementations of verifiers SHOULD generate appropriate warnings about the use of self-signed certificates. Also, the example certificates in this section have placed their domain name subject in the subjectAltName field; in practice, certificate authorities may place domain names in other locations in the certificate (see Section 13.4 for more information).

次の例では、自己署名証明書ではなく、認識された証明機関によって発行された証明書を使用することに注意してください。このメカニズムのための自己署名証明書の使用は推奨されません、それは例示の目的のみのためにここに表示されます。したがって、コンプライアンス・テストにおいて、検証の実装は、自己署名証明書の使用に関する適切な警告を生成する必要があります。また、このセクションの例で証明書がのsubjectAltNameフィールドに自分のドメイン名の対象を配置しています。実際には、認証局は、証明書の他の場所（詳細については、セクション13.4を参照）でのドメイン名を入れることができます。

Note that all examples in this section use the 'rsa-sha1' algorithm.

このセクションのすべての例は、「RSA-SHA1」アルゴリズムを使用することに注意してください。

Bit-exact reference files for these messages and their various transformations are supplied in Appendix B.

これらのメッセージとその様々な変換のビットの正確な参照ファイルは、付録Bに供給され、

10.1. Identity-Info with a Singlepart MIME body

10.1. シングルパートMIMEボディを持つアイデンティティ情報

Consider the following private key and certificate pair assigned to 'atlanta.example.com' (rendered in OpenSSL format).

「atlanta.example.com」（OpenSSLの形式でレンダリング）に割り当てられ、次の秘密鍵と証明書のペアを考えてみましょう。

   MQ0wCwYDVQQKDARJRVRGMRwwGgYDVQQDDBNhdGxhbnRhLmV4YW1wbGUuY29tggEA
   MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEADdQYtswBDmTSTq0mt211
   7alm/XGFrb2zdbU0vorxRdOZ04qMyrIpXG1LEmnEOgcocyrXRBvq5p6WbZAcEQk0
   DsE3Ve0Nc8x9nmvljW7GsMGFCnCuo4ODTf/1lGdVr9DeCzcj10YUQ3MRemDMXhY2
   CtDisLWl7SXOORcZAi1oU9w=
   -----END CERTIFICATE-----

A user of atlanta.example.com, Alice, wants to send an INVITE to bob@biloxi.example.org. She therefore creates the following INVITE request, which she forwards to the atlanta.example.org proxy server that instantiates the authentication service role:

atlanta.example.comの利用者は、アリスは、bob@biloxi.example.orgするINVITEを送信したいです。彼女は、したがって、以下は彼女が認証サービスの役割をインスタンス化atlanta.example.orgプロキシサーバに転送要求を、INVITE作成します。

         INVITE sip:bob@biloxi.example.org SIP/2.0
         Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
         To: Bob <sip:bob@biloxi.example.org>
         From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
         Call-ID: a84b4c76e66710
         CSeq: 314159 INVITE
         Max-Forwards: 70
         Date: Thu, 21 Feb 2002 13:02:03 GMT
         Contact: <sip:alice@pc33.atlanta.example.com>
         Content-Type: application/sdp
         Content-Length: 147

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

V = 0 0 =ユーザーA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com S =セッションのSDP C = IN IP4 pc33.atlanta.example.com T = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000

When the authentication service receives the INVITE, it authenticates Alice by sending a 407 response. As a result, Alice adds an Authorization header to her request, and resends to the atlanta.example.com authentication service. Now that the service is sure of Alice's identity, it calculates an Identity header for the request. The canonical string over which the identity signature will be generated is the following (note that the first line wraps because of RFC editorial conventions):

認証サービスは、INVITEを受信すると、それは407応答を送信することにより、アリスを認証します。結果として、アリスは彼女の要求にAuthorizationヘッダを付加し、そしてatlanta.example.com認証サービスに再送します。今、サービスはアリスの身元の確認であること、それはリクエストのIdentityヘッダを計算します。アイデンティティの署名が生成される上で標準的な文字列は、（最初の行が原因RFCの編集規則のラップことに注意）以下のとおりであります：

sip:alice@atlanta.example.com|sip:bob@biloxi.example.org| a84b4c76e66710|314159 INVITE|Thu, 21 Feb 2002 13:02:03 GMT| sip:alice@pc33.atlanta.example.com|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

SIP：alice@atlanta.example.com | SIP：bob@biloxi.example.org | a84b4c76e66710 | 314159 INVITE |木、21を2002年2月午後1時02分03秒GMT | SIP：alice@pc33.atlanta.example.com | V = 0 0 =ユーザーA 2890844526 2890844526、IN IP4 pc33.atlanta.example.com S =セッションSDPのC IN = IP4 pc33.atlanta.example.comトン= 0 0メートル=オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000

The resulting signature (sha1WithRsaEncryption) using the private RSA key given above, with base64 encoding, is the following:

base64エンコーディングと、上記のRSA秘密鍵を使用して得られた署名（sha1WithRsaEncryption）は、以下の通りです。

ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=

ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn FVcnyaZ ++ yRlBYYQTLqWzJ + KVhPKbfU / pryhVn9Yc6U =

Accordingly, the atlanta.example.com authentication service will create an Identity header containing that base64 signature string (175 bytes). It will also add an HTTPS URL where its certificate is made available. With those two headers added, the message looks like the following:

したがって、atlanta.example.com認証サービスは、BASE64署名文字列（175バイト）を含むIdentityヘッダを作成します。また、その証明書が使用可能になるHTTPSのURLを追加します。これら2つのヘッダを追加すると、メッセージは次のようになります。

INVITE sip:bob@biloxi.example.org SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 To: Bob <sip:bob@biloxi.example.org> From: Alice <sip:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:alice@pc33.atlanta.example.com> Identity: "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=" Identity-Info: <https://atlanta.example.com/atlanta.cer>;alg=rsa-sha1 Content-Type: application/sdp Content-Length: 147

ボブ<SIP：bob@biloxi.example.org>から：アリス<一口;：bob@biloxi.example.org SIP / 2.0経由：ブランチ= z9hG4bKnashds8にSIP / 2.0 / TLS pc33.atlanta.example.com SIPのINVITE ：alice@atlanta.example.com>; = 1928301774のCall-IDタグ：a84b4c76e66710のCSeq：314159は、マックス・フォワードをINVITE：70日：木、2002年2月21日13時02分03秒GMT連絡先：<SIP：alice@pc33.atlanta .example.comと>アイデンティティ： "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn FVcnyaZ ++ yRlBYYQTLqWzJ + KVhPKbfU / pryhVn9Yc6U =" アイデンティティ情報：<https://atlanta.example.com/atlanta.cer>; ALG = RSA-SHA1のContent-Type：アプリケーション/ SDPのContent-Length：147

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

atlanta.example.com then forwards the request normally. When Bob receives the request, if he does not already know the certificate of atlanta.example.com, he dereferences the URL in the Identity-Info header to acquire the certificate. Bob then generates the same canonical string given above, from the same headers of the SIP request. Using this canonical string, the signed digest in the Identity header, and the certificate discovered by dereferencing the

atlanta.example.comは、通常、要求を転送します。ボブは、要求を受け取ると、彼はすでにatlanta.example.comの証明書を認識していない場合、彼は証明書を取得するには、Identity-InfoヘッダーにURLを参照解除します。ボブは、その後のSIPリクエストの同じヘッダから、上記と同じ標準的な文字列を生成します。この標準的な文字列を使用して、アイデンティティ・ヘッダに署名されたダイジェスト、および証明書は、間接参照によって発見します

Identity-Info header, Bob can verify that the given set of headers and the message body have not been modified.

アイデンティティ-Infoヘッダー、ボブは、ヘッダの所定のセットとメッセージ本体が変更されていないことを確認することができます。

10.2. Identity for a Request with No MIME Body or Contact

10.2. ノーMIMEボディや連絡先とのリクエストのためのアイデンティティ

Consider the following private key and certificate pair assigned to "biloxi.example.org".

「biloxi.example.org」に割り当てられ、次の秘密鍵と証明書のペアを考えてみましょう。

Bob (bob@biloxi.example.org) now wants to send a BYE request to Alice at the end of the dialog initiated in the previous example. He therefore creates the following BYE request, which he forwards to the 'biloxi.example.org' proxy server that instantiates the authentication service role:

ボブ（bob@biloxi.example.org）は今、前の例では開始され、ダイアログの最後にアリスにBYE要求を送信したいです。したがって、彼は彼が認証サービスの役割をインスタンス化する「biloxi.example.org」プロキシサーバに転送し、以下のBYEリクエストを作成します：

BYEをSIP：alice@pc33.atlanta.example.com SIP / 2.0経由：SIP / 2.0 / TLSの192.0.2.4;分岐= z9hG4bKnashds10最大フォワード：5,441：ボブ<SIP：bob@biloxi.example.org>;タグ= a6c85cfへ：アリス<SIP：alice@atlanta.example.com>;タグ= 1928301774のCall-ID：a84b4c76e66710のCSeq：231 BYEのコンテンツの長さ：0

When the authentication service receives the BYE, it authenticates Bob by sending a 407 response. As a result, Bob adds an Authorization header to his request, and resends to the biloxi.example.org authentication service. Now that the service is sure of Bob's identity, it prepares to calculate an Identity header for the request. Note that this request does not have a Date header field. Accordingly, the biloxi.example.org will add a Date header to the request before calculating the identity signature. If the Content-Length header were not present, the authentication service would add it as well. The baseline message is thus:

認証サービスは、BYEを受信すると、それは407応答を送信することで、ボブを認証します。その結果、ボブは、彼の要求にAuthorizationヘッダを付加し、そしてbiloxi.example.org認証サービスに再送します。今、サービスがボブの身元の確認であること、それはリクエストのIdentityヘッダを計算するための準備します。この要求は、Dateヘッダーフィールドを持っていないことに注意してください。従って、biloxi.example.orgは、ID署名を計算する前に要求に日付ヘッダを追加します。 Content-Lengthヘッダが存在しない場合は、認証サービスは、同様にそれを追加します。ベースラインメッセージは、このようにあります。

BYEをSIP：alice@pc33.atlanta.example.com SIP / 2.0経由：SIP / 2.0 / TLSの192.0.2.4;分岐= z9hG4bKnashds10最大フォワード：5,441：ボブ<SIP：bob@biloxi.example.org>;タグ=へa6c85cf：アリス<SIP：alice@atlanta.example.com>;タグ= 1928301774日：木、2002年2月21日午前14時19分51秒GMTコール-ID：a84b4c76e66710のCSeq：231 BYEのコンテンツの長さ：0

Also note that this request contains no Contact header field. Accordingly, biloxi.example.org will place no value in the canonical string for the addr-spec of the Contact address. Also note that there is no message body, and accordingly, the signature string will terminate, in this case, with two vertical bars. The canonical string over which the identity signature will be generated is the following (note that the first line wraps because of RFC editorial conventions):

また、この要求は何のContactヘッダーフィールドが含まれていないことに注意してください。したがって、biloxi.example.orgは連絡先アドレスのaddrのスペックのための標準的な文字列には値を置かないだろう。また、メッセージ・ボディが存在しないことに注意し、それに応じて、署名列は、二つの垂直バーと、この場合には、終了します。アイデンティティの署名が生成される上で標準的な文字列は、（最初の行が原因RFCの編集規則のラップことに注意）以下のとおりであります：

sip:bob@biloxi.example.org|sip:alice@atlanta.example.com| a84b4c76e66710|231 BYE|Thu, 21 Feb 2002 14:19:51 GMT||

SIP：bob@biloxi.example.org | SIP：alice@atlanta.example.com | a84b4c76e66710 | 231 BYE |木、2002年2月21日午後2時19分51秒GMT ||

The resulting signature (sha1WithRsaEncryption) using the private RSA key given above for biloxi.example.org, with base64 encoding, is the following: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=

base64エンコーディングとbiloxi.example.orgための上記のRSA秘密鍵を使用して得られた署名（sha1WithRsaEncryption）は、以下の通りである：sv5CTo05KqpSmtHt3dcEiO / 1CWTSZtnG3iV + 1nmurLXV / HmtyNS7Ltrg9dlxkWzo eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER / Ovgtw0Lu5csIp pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs =

Accordingly, the biloxi.example.org authentication service will create an Identity header containing that base64 signature string. It will also add an HTTPS URL where its certificate is made available. With those two headers added, the message looks like the following:

従って、biloxi.example.org認証サービスは、BASE64署名文字列を含むIdentityヘッダを作成します。また、その証明書が使用可能になるHTTPSのURLを追加します。これら2つのヘッダを追加すると、メッセージは次のようになります。

BYE sip:alice@pc33.atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob <sip:bob@biloxi.example.org>;tag=a6c85cf To: Alice <sip:alice@atlanta.example.com>;tag=1928301774 Date: Thu, 21 Feb 2002 14:19:51 GMT Call-ID: a84b4c76e66710 CSeq: 231 BYE Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=" Identity-Info: <https://biloxi.example.org/biloxi.cer>;alg=rsa-sha1 Content-Length: 0

BYEをSIP：alice@pc33.atlanta.example.com SIP / 2.0経由：SIP / 2.0 / TLSの192.0.2.4;分岐= z9hG4bKnashds10最大フォワード：5,441：ボブ<SIP：bob@biloxi.example.org>;タグアリス<SIP：alice@atlanta.example.com>へ= a6c85cf; = 1928301774日タグ：木、2002年2月21日午前14時19分51秒GMTコール-ID：a84b4c76e66710のCSeq：231 BYEアイデンティティ：「sv5CTo05KqpSmtHt3dcEiO / 1CWTSZtnG3iV + 1nmurLXV / HmtyNS7Ltrg9dlxkWzo eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER / Ovgtw0Lu5csIp pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs =」アイデンティティ情報：<https://biloxi.example.org/biloxi.cer>; ALG = RSA-SHA1のContent-Length：0

biloxi.example.org then forwards the request normally.

biloxi.example.orgは、通常、要求を転送します。

11. Identity and the TEL URI Scheme

11.アイデンティティとTEL URIスキーム

Since many SIP applications provide a Voice over IP (VoIP) service, telephone numbers are commonly used as identities in SIP deployments. In the majority of cases, this is not problematic for the identity mechanism described in this document. Telephone numbers commonly appear in the username portion of a SIP URI (e.g., 'sip:+17005551008@chicago.example.com;user=phone'). That username conforms to the syntax of the TEL URI scheme (RFC 3966 [13]). For this sort of SIP address-of-record, chicago.example.com is the appropriate signatory.

多くのSIPアプリケーションは、ボイスオーバーIP（VoIP）のサービスを提供しているため、電話番号は、一般的にSIP展開でのIDとして使用されています。ほとんどの場合、これは本書では説明識別メカニズムの問題はありません。電話番号は、一般的にSIP URIのユーザー名部分に表示される（例えば、「SIP：+17005551008@chicago.example.com;ユーザー=電話」）。そのユーザー名は、TEL URIスキームの構文に準拠（RFC 3966 [13]）。 SIPアドレス・オブ・レコードのこの種のために、chicago.example.comは適切で署名しています。

It is also possible for a TEL URI to appear in the SIP To or From header field outside the context of a SIP or SIPS URI (e.g., 'tel:+17005551008'). In this case, it is much less clear which signatory is appropriate for the identity. Fortunately for the identity mechanism, this form of the TEL URI is more common for the To header field and Request-URI in SIP than in the From header field, since the UAC has no option but to provide a TEL URI alone when the remote domain to which a request is sent is unknown. The local domain, however, is usually known by the UAC, and accordingly it can form a proper From header field containing a SIP URI with a username in TEL URI form. Implementations that intend to send their requests through an authentication service SHOULD put telephone numbers in the From header field into SIP or SIPS URIs whenever possible.

TEL URIは、SIPのコンテキストの外部ヘッダ・フィールドにまたはからSIPに表示されるか、URI（例えば、「：17005551008 TEL」）をSIPSすることも可能です。この場合、アイデンティティのために適切である締約それほど明確です。 UACは時にリモートドメインのみTEL URIを提供するしかありませんでしたので、幸いアイデンティティメカニズムのために、TEL URIのこの形式は、FromヘッダーフィールドよりもSIPのフィールドとRequest-URIヘッダするためには、より一般的ですこれに送られるリクエストは不明です。ローカルドメインが、しかし、通常UACによって知られており、従ってそれはTEL URIの形式でユーザー名とSIP URIを含むヘッダフィールドから適切に形成することができます。認証サービスを通じて要求を送信しようとする実装は、SIPまたはSIPS URIを可能な限りにFromヘッダーフィールドに電話番号を置くべきです。

If the local domain is unknown to a UAC formulating a request, it most likely will not be able to locate an authentication service for its request, and therefore the question of providing identity in these cases is somewhat moot. However, an authentication service MAY sign a request containing a TEL URI in the From header field. This is permitted in this specification strictly for forward compatibility purposes. In the longer-term, it is possible that ENUM [14] may provide a way to determine which administrative domain is responsible for a telephone number, and this may aid in the signing and verification of SIP identities that contain telephone numbers. This is a subject for future work.

ローカルドメインが要求を策定UACに知られていない場合は、最も可能性が高いその要求に対する認証サービスを見つけることができませんので、これらの場合にアイデンティティを提供するという問題が多少議論の余地があります。しかし、認証サービスからヘッダフィールドにTEL URIを含む要求に署名することができます。これは、前方互換性の目的のために厳密にこの仕様で許可されています。長期では、ENUM [14]管理ドメインは、電話番号を担当し、そしてこれは、電話番号が含まれているSIPのアイデンティティの署名と検証を助けることができるかを決定する方法を提供する可能性があります。これは、将来の仕事のための主題です。

12. Privacy Considerations

12.プライバシーに関する注意事項

The identity mechanism presented in this document is compatible with the standard SIP practices for privacy described in RFC 3323 [3]. A SIP proxy server can act both as a privacy service and as an authentication service. Since a user agent 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 is the same for private URIs as it is for any other sort of URIs.

この文書の識別機構は、RFC 3323に記載のプライバシーのための標準的なSIP慣行に対応している[3]。 SIPプロキシサーバは、プライバシーサービスとして、認証サービスの両方として機能することができます。認証サービスによって署名することができないユーザエージェントは、認証サービスを許可する意思があることヘッダーフィールド値から任意のものを提供することができるので、正当なドメイン（anonymous@example.com例えば、SIP）を含む民間のSIP URIがない理由は存在しません。それはURIの他のソートにあるようIdentityヘッダの建設は、民間のURIでも同じです。

Note, however, that an authentication service must possess a certificate corresponding to the host portion of the addr-spec of the From header field of any request that it signs; accordingly, using domains like 'anonymous.invalid' will not be possible for privacy services that also 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". The use of the domain 'anonymous.invalid' entails that no corresponding authority for the domain can exist, and as a consequence, authentication service functions are meaningless.

認証サービスは、それが署名の要求のFromヘッダフィールドのADDR仕様のホスト部分に対応する証明書を有していなければならないことは、注意してください。したがって、「anonymous.invalid」のようなドメインを使用した場合も、認証サービスとして機能し、プライバシーサービスのために行うことはできません。有効なドメイン部分と、匿名のURIの使用によって提供される保証は、「これは私が認証されている自分のドメイン内の既知のユーザーですが、私はそのアイデンティティがプライベート保管しております」です。ドメイン「anonymous.invalid」の使用は、ドメインには、対応する権限が存在しないことができ、結果として、認証サービス機能が無意味であることを必要とします。

The "header" level of privacy described in RFC 3323 requests that a privacy service alter the Contact header field value of a SIP message. Since the Contact header field is protected by the signature in an Identity header, privacy services cannot be applied after authentication services without a resulting integrity violation.

プライバシーサービスは、SIPメッセージのContactヘッダーフィールド値を変更RFC 3323回の要求に記載プライバシーの「ヘッダ」レベル。 Contactヘッダーフィールドは、Identityヘッダー内の署名により保護されているので、プライバシーサービスは、結果の整合性違反せずに認証サービスの後に適用することはできません。

RFC 3325 [12] defines the "id" priv-value token, which is specific to the P-Asserted-Identity header. The sort of assertion provided by the P-Asserted-Identity header is very different from the Identity header presented in this document. It contains additional information about the sender of a message that may go beyond what appears in the From header field; P-Asserted-Identity holds a definitive identity for the sender that is somehow known to a closed network of intermediaries that presumably the 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, and privacy services MUST NOT remove the Identity header when a priv-value of "id" appears in a Privacy header.

RFC 3325 [12] P-Asserted-Identityヘッダに固有の "ID" PRIV-値のトークンを定義します。 P-Asserted-Identityヘッダによって提供されるアサーションの種類は、この文書のIdentityヘッダとは非常に異なっています。これは、Fromヘッダーフィールドに表示される内容を超えて、メッセージの送信者に関する追加情報が含まれています。 P-アサート-アイデンティティは何とかおそらくネットワークは、課金やセキュリティの目的のために、このIDを使用します仲介の閉じたネットワークに知られている送信者のための決定的なアイデンティティを保持しています。「ID」PRIV-値トークンを動機閉じたネットワークの外部に漏れるこのネットワーク固有の情報の危険性。「ID」PRIV-値トークンはIdentityヘッダには意味がありませんし、「ID」のPRIV-値はプライバシーヘッダーに表示されたときに、プライバシーサービスは、Identityヘッダーを削除してはなりません。

Finally, note that unlike RFC 3325, the mechanism described in this specification adds no information to SIP requests that has privacy implications.

最後に、RFC 3325とは異なり、本明細書に記載されたメカニズムは、プライバシーの意味を持つSIPリクエストに何も情報が追加されていないことに注意してください。

13. Security Considerations

13.セキュリティの考慮事項

13.1. Handling of digest-string Elements

13.1. ダイジェスト文字列要素の取扱い

This document describes a mechanism that provides a signature over the Contact, Date, Call-ID, CSeq, To, and From header fields of SIP requests. While a signature over the From header field would be sufficient to secure a URI alone, the additional headers provide replay protection and reference integrity necessary to make sure that the Identity header will not be used in cut-and-paste attacks. In general, the considerations related to the security of these headers are the same as those given in RFC 3261 for including headers in tunneled 'message/sip' MIME bodies (see Section 23 in particular). The following 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.

この文書は、連絡先、日付の上に署名を提供するメカニズムを説明コールID、のCSeq、し、SIPリクエストのヘッダフィールドから。 Fromヘッダフィールドを超える署名が一人でURIを確保するのに十分であろうが、追加のヘッダは、Identityヘッダーをカットアンドペースト攻撃に使用されないことを確認するために必要な再生保護と参照整合性を提供します。一般に、これらのヘッダのセキュリティに関する考慮事項は、トンネル「メッセージ/ SIP」MIMEボディ（特に、セクション23を参照）にヘッダを含めるため、RFC 3261に指定されたものと同じです。次のセクションでは、署名内のこれらのヘッダフィールドのそれぞれを含むことによって得られた個々のセキュリティプロパティを詳細。集合的に、ヘッダーフィールドのこのセットは、なりすましを防ぐために必要な特性を提供します。

The From header field indicates the identity of the sender of the message, and the SIP address-of-record URI in the From header field is the identity of a SIP user, for the purposes of this document. The To header field provides the identity of the SIP user that this request targets. Providing the To header field in the Identity signature serves two purposes: first, it prevents cut-and-paste attacks in which an Identity header from 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, which helps prevent downgrade attacks against the use of SIPS.

ヘッダフィールドからのメッセージの送信者のアイデンティティを示し、SIPアドレス・オブ・レコードURIヘッダフィールドから、この文書の目的のために、SIPユーザのアイデンティティです。 Toヘッダフィールドは、SIPユーザこの要求対象の識別を提供します。アイデンティティの署名フィールドをヘッダーには提供することは2つの目的を果たす：まず、それは一人のユーザのための正当な要求からIdentityヘッダをカットアンドペーストし、異なるユーザの要求にしたカットアンドペースト攻撃を防止します。第二に、SIPSの使用に対するダウングレード攻撃を防ぐことができます要求の開始URIスキームを保持します。

The Date and Contact headers provide reference integrity and replay protection, as described in RFC 3261, Section 23.4.2. Implementations of this specification MUST NOT deem valid a request with an outdated Date header field (the RECOMMENDED interval is that the Date header must indicate a time within 3600 seconds of the receipt of a message). Implementations MUST also record Call-IDs received in valid requests containing an Identity header, and MUST remember those Call-IDs for at least the duration of a single Date interval (i.e., commonly 3600 seconds). Because a SIP-compliant UA never generates the same Call-ID twice, verifiers can use the Call-ID to recognize cut-and-paste attacks; the Call-ID serves as a nonce. The result of this is that if an Identity header is replayed within the Date interval, verifiers will recognize that it is invalid because of a Call-ID duplication; if an Identity header is replayed after the Date interval, verifiers will recognize that it is invalid because the Date is stale. The CSeq header field contains a numbered identifier for the transaction, and the name of the method of the request; without this information, an INVITE request could be cut-and-pasted by an attacker and transformed into a BYE request without changing any fields covered by the Identity header, and moreover requests within a certain transaction could be replayed in potentially confusing or malicious ways.

RFC 3261、セクション23.4.2で説明したように日付と連絡先のヘッダーには、参照整合性およびリプレイ保護を提供します。この仕様の実装が古い日付ヘッダフィールドで有効な要求を考えるてはならない（推奨される間隔は、Dateヘッダは、メッセージの受信の3600秒以内の時間を示さなければならないということです）。また、実装はコールIDがIdentityヘッダを含む有効な要求で受信し記録しなければならない、と単一日付間隔（すなわち、一般的に3600秒）の少なくとも期間中にこれらのCall-IDを覚えておく必要があります。 SIP準拠のUAが二度同じCall-IDを生成することはありませんので、検証者は、カットアンドペースト攻撃を認識するためのCall-IDを使用することができます。コールIDは、ナンスとして機能します。この結果は、Identityヘッダが日付間隔内で再生した場合、検証は、それが理由のCall-IDの重複で無効であることを認識するだろうということです。 Identityヘッダは、日付間隔の後に再生される場合、検証者は、日付が古いので、それが無効であることを認識するだろう。 CSeqヘッダーフィールドは、トランザクションの番号識別子、および要求のメソッドの名前を含みます。この情報なしに、INVITE要求をカットアンドペーストし、攻撃者によって、およびBYE要求に変換Identityヘッダで覆われて、任意のフィールドを変更せずに、あるトランザクション内また要求は、潜在的に混乱または悪質な方法で再生することができることができます。

The Contact header field is included to tie the Identity header to a particular user agent instance that generated the request. Were an active attacker to intercept a request containing an Identity header, and cut-and-paste the Identity header field into its own request (reusing the From, To, Contact, Date, and Call-ID fields that appear in the original message), the attacker would not be eligible to receive SIP requests from the called user agent, since those requests are routed to the URI identified in the Contact header field. However, the Contact header is only included in dialog-forming requests, so it does not provide this protection in all cases.

Contactヘッダーフィールドは、要求を生成し、特定のユーザエージェントインスタンスにIdentityヘッダを結合するために含まれています。独自の要求（から、に、連絡先、日付を再利用し、元のメッセージに表示されるコールIDをフィールド）内のIdentityヘッダフィールドをIdentityヘッダを含むリクエストをインターセプトし、カットアンドペーストする活発な攻撃者でしたこれらの要求は、Contactヘッダーフィールドで識別URIにルーティングされるため、攻撃者は、と呼ばれるユーザエージェントからのSIPリクエストを受けることではないでしょう。しかし、Contactヘッダは、ダイアログ形成要求に含まれているので、すべての場合には、この保護機能を提供していません。

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, an attacker could remove that Via header 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 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, which has exactly the same end result. Although it is possible that an intermediary-based authentication service could guarantee that no Via hops are inserted between the sending user agent 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ヘッダー一番上のフィールドに、攻撃者はViaヘッダーことを削除する可能性があり、にルーティングする要求にすべての応答を引き起こすことになる、カットアンドペースト攻撃に独自の挿入します攻撃者が選択したホスト。攻撃者はそのまま経由最上位のままにして、単に攻撃者のホスト」にルーティングされるように応答を引き起こすことになる、それの直後に新しいViaヘッダーフィールドを挿入する可能性があるのでしかし、Viaヘッダー最上位超える署名は、この種の攻撃を防ぐことはできません。まったく同じ最終結果を持っている有効なホストは、「自分の道に。それは仲介ベースの認証サービスは一切経由ホップは、送信ユーザエージェントと認証サービスの間に挿入されていないことを保証できることが可能ですが、それは経由で認証サービスの後にホップ追加し、それによって反応を先取りから攻撃を防ぐことができませんでした。これは、後続の媒体がヘッダフィールドを介してそのような挿入を可能にするためのSIPの適切な動作のために必要であり、従って、それを防止することができません。それは望ましいもののような、ビアを確保することは、この文書に記載されアイデンティティ機構の並べ替えを介しては不可能です。経由を確保するための最もよく知られている練習はSIPSの使用です。

This mechanism also provides a signature over the bodies of SIP requests. The most important reason for doing so is to protect Session Description Protocol (SDP) bodies carried in SIP requests. 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 media descriptors. Note, however, that this is not perfect end-to-end security. The authentication service itself, when instantiated at a intermediary, could conceivably change the SDP (and SIP headers, for that matter) before providing a signature. Thus, while this mechanism reduces the chance that a replayer or man-in-the-middle will modify SDP, it does not eliminate it entirely. Since it is a foundational assumption of this mechanism that the users trust their local domain to vouch for their security, they must also trust the service not to violate the integrity of their message without good reason. Note that RFC 3261, Section 16.6, states that SIP proxy servers "MUST NOT add to, modify, or remove the message body."

このメカニズムは、SIPリクエストのボディ上の署名を提供します。そうするための最も重要な理由は、セッション記述プロトコル（SDP）SIPリクエストで運ば体を保護することです。この保証は、メディア記述上で同等の保証と結合されていない場合、SIPリクエストを発信したユーザのアイデンティティを確立する上で少し目的があります。これは完璧なエンドツーエンドのセキュリティではないこと、しかし、注意してください。認証サービス自体中間にインスタンス化するとき、考えられる署名を提供する前に（そのことについて、及びSIPヘッダ）SDPを変えることができます。このメカニズムがreplayerかのman-in-the-middleはSDPを変更する可能性を低減しつつ、それはそれを完全に排除するものではありません。それは、ユーザーが自分のセキュリティを保証するために、地元のドメインを信頼して、このメカニズムの基礎的前提であるので、彼らはまた、正当な理由なしにそのメッセージの整合性に違反していないサービスを信頼する必要があります。そのRFC 3261、セクション16.6に注意し、SIPプロキシサーバ「は、に追加、変更、またはメッセージ本文を削除してはなりません。」と述べています

In the end analysis, the Identity and Identity-Info headers cannot protect themselves. Any attacker could remove these headers 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 SIP users can prove definitively 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.

最後の分析では、アイデンティティとアイデンティティ情報のヘッダには、自分自身を保護することはできません。任意の攻撃者は、SIPリクエストからこれらのヘッダを削除し、任意にその後の要求を変更することができます。しかし、このメカニズムは、男性・イン・ザ・ミドルSIPメッセージに干渉するからの要求を保護するものではありません。唯一のSIPユーザーが決定的に彼らがあると主張する者であることを証明することができる方法を提供することを意図しています。せいぜい、リクエストから身元情報をストリッピングすることにより、のman-in-the-middleは不可能彼が正規のユーザによって送信されたそれらのメッセージから送信したい任意の違法なメッセージを区別するために作ることができます。しかし、それはそれだけで他の誰かがFromヘッダーフィールドですコピーすることで、些細な偽装をマウントするよりも、このような攻撃を仕掛けるためにエネルギーのかなり大きい量を必要とします。このメカニズムは、許可されたユーザが不正なユーザ、偽装者は、できないことを彼のアイデンティティの決定的な保証を提供できるような方法を提供します。

One additional respect in which the Identity-Info header cannot protect itself is the 'alg' parameter. The 'alg' parameter is not included in the digest-string, and accordingly, a man-in-the-middle might attempt to modify the 'alg' parameter. However, it is important to note that preventing men-in-the-middle is not the primary impetus for this mechanism. Moreover, changing the 'alg' would at worst result in some sort of bid-down attack, and at best cause a failure in the verifier. Note that only one valid 'alg' parameter is defined in this document and that thus there is currently no weaker algorithm to which the mechanism can be bid down. 'alg' has been incorporated into this mechanism for forward-compatibility reasons in case the current algorithm exhibits weaknesses, and requires swift replacement, in the future.

アイデンティティ-Infoヘッダーが自分自身を守ることができない一つの追加については、「ALG」パラメータです。 'ALG' パラメータは、ダイジェスト文字列に含まれていない、それに応じて、のman-in-the-middleは、 'ALG' パラメータを変更しようとするかもしれません。しかし、男性・イン・ザ・ミドルを防止することは、このメカニズムのための主要な原動力ではないことに注意することが重要です。また、入札ダウン攻撃のいくつかの並べ替え、および検証で最高の原因で故障で最悪の結果で「ALG」を考え変えます。唯一の有効な「ALG」パラメータは、この文書では、したがって、メカニズムがダウンして入札することが可能にする全く弱いアルゴリズムが現在存在しないことが規定されていることに注意してください。「ALG」が現在のアルゴリズムは、将来的に、弱点を示し、迅速な交換を必要とする場合には前方互換性の理由のために、この機構に組み込まれています。

13.2. Display-Names and Identity

13.2. 表示名とアイデンティティ

As a matter of interface design, SIP user agents 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. As such, it might seem that the lack of a signature over the display-name is a significant omission.

インタフェース設計の問題として、SIPユーザエージェントは、発呼者のアイデンティティなどの発信者のFromヘッダフィールドの表示名の部分をレンダリングする可能性があります。この練習のための電子メールのユーザーインターフェイスが大幅に先例があります。このように、表示名を超える署名がないことが重要漏れであるように見えるかもしれません。

However, there are several important senses in which a signature over the display-name does not prevent impersonation. In the first place, a particular display-name, like "Jon Peterson", is not unique in the world; many users in different administrative domains might legitimately claim that name. Furthermore, enrollment practices for SIP-based services might have a difficult time discerning the legitimate display-name for a user; it is safe to assume that impersonators will be capable of creating SIP accounts with arbitrary display-names. The same situation prevails in email today. Note that an impersonator who attempted to replay a message with an Identity header, changing only the display-name in the From header field, would be detected by the other replay protection mechanisms described in Section 13.1.

ただし、表示名を超える署名がなりすましを防ぐことはできませんここでいくつかの重要な感覚があります。まず第一に、特定の表示名は、「ジョン・ピーターソン」のように、世界でもユニークではありません。異なる管理ドメイン内の多くのユーザーは、合法的にその名を主張するかもしれません。さらに、SIPベースのサービスの登録プラクティスは、ユーザのための正当な表示名を目の肥え困難な時期を持っているかもしれません。なりすましが任意の表示、名前のSIPアカウントを作成することができるであろうと仮定しても安全です。同じような状況は、今日メールに優先されます。 Fromヘッダフィールドにのみ表示名を変更する、アイデンティティ・ヘッダとメッセージを再生しようと偽装は、セクション13.1に記載されている他のリプレイ保護メカニズムによって検出されることに留意されたいです。

Of course, an authentication service can enforce policies about the display-name even if the display-name is not signed. The exact mechanics for creating and operationalizing such policies is outside the scope of this document. The effect of this policy would not be to prevent impersonation of a particular unique identifier like a SIP URI (since display-names are not unique identifiers), but to allow a domain to manage the claims made by its users. If such policies are enforced, users would not be free to claim any display-name of their choosing. In the absence of a signature, man-in-the-middle attackers could conceivably alter the display-names in a request with impunity. Note that the scope of this specification is impersonation attacks, however, and that a man-in-the-middle might also strip the Identity and Identity-Info headers from a message.

もちろん、認証サービスは、表示名が署名されていない場合でも、表示名についてのポリシーを適用することができます。そのようなポリシーを作成し、運用開始の正確な機構は、この文書の範囲外です。このポリシーの効果は、（表示名は一意の識別子でないため）SIP URIのような特定の一意の識別子のなりすましを防止することができないだろうが、ドメインがそのユーザーによって行われた特許請求の範囲を管理することを可能にします。そのような政策が施行されている場合、ユーザーは自分が選択した任意の表示名を主張する自由ではないでしょう。署名がない場合には、のman-in-the-middle攻撃が考えられる大手を振って要求して表示名を変更することができます。この仕様の範囲は、しかし、なりすまし攻撃である、とのman-in-the-middleもメッセージからアイデンティティとアイデンティティ情報のヘッダを取り除くかもしれないことに注意してください。

There are many environments in which policies regarding the display-name aren't feasible. Distributing bit-exact and internationalizable display-names to end-users as part of the enrollment or registration process would require mechanisms that are not explored in this document. In the absence of policy enforcement regarding domain names, there are conceivably attacks that an adversary could mount against SIP systems that rely too heavily on the display-name in their user interface, but this argues for intelligent interface design, not changes to the mechanisms. Relying on a non-unique identifier for identity would ultimately result in a weak mechanism.

表示名に関する方針が不可能である、多くの環境があります。登録または登録プロセスの一環として、エンドユーザに、ビット正確かつ国際化表示名を配布することは、この文書で検討されていないメカニズムを必要とします。メカニズムへの変更はなく、ドメイン名に関するポリシーの適用がない場合には、攻撃は敵が自分のユーザーインターフェースで表示名に過度に依存しているSIPシステムに対してマウントすることができると考えられるがありますが、これは、インテリジェントなインターフェイスデザインのために主張しています。アイデンティティのための非一意の識別子に依存することは、最終的に弱いメカニズムにつながります。

13.3. Securing the Connection to the Authentication Service

13.3. 認証サービスへの接続の保護

The assurance provided by this mechanism is strongest when a user agent forms a direct connection, preferably one secured by TLS, to an intermediary-based authentication service. The reasons for this are twofold:

ユーザエージェントは、直接接続、中間ベースの認証サービスに、TLSによって固定好ましいものを形成する場合、このメカニズムによって提供される保証は最強です。その理由は2つあります：

If a user does not receive a certificate from the authentication service over this 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.

ユーザは、（ユーザーがそのようなダイジェストなどの機構を介しての挑戦を受けた場合は特に）、予想されるドメインに対応し、このTLS接続経由で認証サービスから証明書を受信しない場合、不正なサーバが提起しようとしている可能性がありそれはおそらく、そのドメインの共有秘密を収集するための試みで、コントロールしていないドメインの認証サービスなど。

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.

要求が認証サービスに到着したときに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 the header and bodies is provided by this mechanism only to prevent replay attacks. However, it is possible that applications relying on the presence of the Identity header could leverage this integrity protection, especially body integrity, for services other than replay protection.

これら二つの問題のうち、最初は、このメカニズムの意図した範囲に最も材料です。このメカニズムはないman-in-the-middle攻撃、なりすまし攻撃を防ぐためのものです。ヘッダとボディの上に整合性が唯一のリプレイ攻撃を防ぐために、このメカニズムによって提供されます。しかし、Identityヘッダーの存在に依存するアプリケーションは再生保護以外のサービスのために、特に身体の完全性、この完全性保護を活用する可能性があります。

Accordingly, direct TLS connections SHOULD be used between the 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 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.

したがって、直接TLS接続は、UACと認証サービス可能な限りの間で使用されるべきです。このメカニズムの日和見的性質は、しかし、それは非常に困難UACの行動を制約することができ、しかも直接接続が簡単に実現不可能であるとUACは、認証サービス自体として機能することはできませんいくつかの展開アーキテクチャが存在します。直接接続およびTLSが不可能なときときそれができるしたがって、UACはSIPSメカニズム、身体の整合性のためのダイジェスト "のauth-int型、またはその両方を使用する必要があります。リクエストにIdentityヘッダーを追加するための最終決定は当然の認証サービス、とあります。ドメインポリシーは、認証サービスとUACのセキュリティアソシエーションが弱すぎるような場合を識別する必要があります。

13.4. Domain Names and Subordination

13.4. ドメイン名および劣後

When a verifier processes a request containing an Identity-Info header, it must compare the domain portion of the URI in the From header field of the request with the domain name that is the subject of the certificate acquired from the Identity-Info header. While it might seem that this should be a straightforward process, it is complicated by two deployment realities. In the first place, certificates 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. Secondly, some SIP services may delegate SIP functions to a subordinate domain and utilize the procedures in RFC 3263 [4] that allow requests for, say, 'example.com' to be routed to 'sip.example.com'. As a result, a user with the AoR 'sip:jon@example.com' may process its requests through a host like 'sip.example.com', and it may be that latter host that acts as an authentication service.

検証者は、Identity-Infoヘッダを含むリクエストを処理するとき、それは、Identity-Infoヘッダーから取得した証明書の対象であるドメイン名を持つリクエストのFromヘッダフィールド内のURIのドメイン部分を比較しなければなりません。それは、これは簡単なプロセスでなければならないことに思えるかもしれないが、それは2つの展開現実によって複雑になります。最初の場所では、証明書は、特に複数のドメインは、単一のアプリケーションで管理されている「仮想ホスティング」の場合には、それぞれの科目を記述する方法を変えてきたし、実際に複数の被写体を有することができます。第二に、いくつかのSIPサービスは、[4]と言う、「example.com」「sip.example.com」にルーティングする、要求を許可し、その下位のドメインへのSIP機能を委譲し、RFC 3263に記載されている手順を利用することができます。結果としてのAoR「SIP：jon@example.com」を持つユーザは、「sip.example.com」のようなホストを介してその要求を処理することができ、それは認証サービスとして作用する後者のホストであってもよいです。

To meet the second of these problems, a domain that deploys an authentication service on a subordinate host MUST be willing to supply that host with the private keying material associated with a certificate 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 RFC 3263 are used to direct requests to a domain name other than the domain in the original Request-URI (e.g., for 'sip:jon@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. 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.

これらの問題の第二を満たすために、下位のホスト上の認証サービスを展開ドメインは、その被写体のAORのドメイン部分に対応するドメイン名された証明書に関連付けられた秘密鍵材料とそのホストを提供する意思がなければなりませんドメインは、ユーザーに配布すること。このドメインへの着信SIP要求をルーティングする匹敵場合に相当します。 RFC 3263のNAPTRとSRV手順は、元のRequest-URI（例えば、ドメイン以外のドメイン名への直接要求に使用される場合は、「SIP：jon@example.com」のため、対応するSRVレコードは、サービスを指します「sip1.example.org」）、クライアント証明書がそのホストにすべてのTLS交換に戻って渡されたが、元のRequest-URIのドメインではなく、ホストのドメイン名と正確に対応することを期待しています。したがって、このようなSIPサービスの仕事へのインバウンドルーティングを行うために、ドメイン管理者は、同様のサービスで、ドメインの秘密鍵を共有して喜んでなければなりません。この設計上の決定は、DNSの不安を補うためになされたもので、ドメイン管理者は、ホスティングサービスでキーを共有することを望まない環境でのSIPのためのunsecurable DNSベースの「仮想ホスティング」にある電位のアプローチを行いました。

A verifier MUST evaluate the correspondence between the user's identity and the signing certificate by following the procedures defined in RFC 2818 [11], Section 3.1. While RFC 2818 deals with the use of HTTP in TLS, the procedures described are applicable to verifying identity if one substitutes the "hostname of the server" in HTTP for the domain portion of the user's identity in the From header field of a SIP request with an Identity header.

検証者は、RFC 2818 [11]、セクション3.1で定義された手順に従って、ユーザーのIDと署名証明書との対応を評価しなければなりません。 RFC TLSにおけるHTTPを使用した2818取引しながら、説明する手順は、1つのSIPリクエストのFromヘッダーフィールドにおけるユーザのアイデンティティのドメイン部分を持つためにHTTPで、「サーバーのホスト名を」代入した場合に身元を確認するに適用されますIdentityヘッダ。

Because the domain certificates that can be used by authentication services need to assert only the hostname of the authentication service, existing certificate authorities can provide adequate certificates for this mechanism. However, not all proxy servers and user agents will be able to support the root certificates of all certificate authorities, and moreover there are some significant differences in the policies by which certificate authorities issue their certificates. This document makes no recommendations for the usage of particular certificate authorities, nor does it describe any particular policies that certificate authorities should follow, but it is anticipated that operational experience will create de facto standards for authentication services. Some federations of service providers, for example, might only trust certificates that have been provided by a certificate authority operated by the federation. It is strongly RECOMMENDED that self-signed domain certificates should not be trusted by verifiers, unless some previous key exchange has justified such trust.

認証サービスで使用できるドメイン証明書は、認証サービスのホスト名だけを主張する必要があるため、既存の認証局は、このメカニズムのための適切な証明書を提供することができます。ただし、すべてのプロキシサーバとユーザエージェントは、すべての認証局のルート証明書をサポートすることができます、また認証局が証明書を発行したことにより、政策のいくつかの重要な違いがあります。この文書は、特定の証明機関の利用のための提言を行うものではありません、またそれは、証明機関が従うべき特定のポリシーを記述しないが、運用経験が認証サービスのためのデファクトスタンダードを作成することが予想されます。サービスプロバイダのいくつかの連合は、例えば、唯一の連盟が運営する認証局によって提供されている証明書を信頼することがあります。強く、いくつかの以前の鍵交換は、このような信頼関係を正当化していない限り、自己署名ドメイン証明書は、検証者が信頼されるべきではないことを推奨します。

For further information on certificate security and practices, see RFC 3280 [9]. The Security Considerations of RFC 3280 are applicable to this document.

証明書のセキュリティと実践の詳細については、RFC 3280 [9]を参照してください。 RFC 3280のセキュリティの考慮事項は、この文書に適用されます。

13.5. Authorization and Transitional Strategies

13.5. 認可および移行戦略

Ultimately, the worth of an assurance provided by an Identity header is limited by the security practices of the domain that issues the assurance. Relying on an Identity header generated by a remote administrative domain assumes that the issuing domain used its administrative practices to authenticate its users. However, it is possible that some domains will implement policies that effectively make users unaccountable (e.g., ones that accept unauthenticated registrations from arbitrary users). The value of an Identity header from such domains is questionable. While there is no magic way for a verifier to distinguish "good" from "bad" domains 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 such as token-based identifiers.

最終的には、Identityヘッダーによって提供される保証の価値は、保証を発行したドメインのセキュリティ対策によって制限されています。遠隔管理ドメインによって生成されたIdentityヘッダに依存することは発行ドメインは、そのユーザーを認証するために、その管理慣行を使用していることを前提としています。しかし、それはいくつかのドメインが効果的にユーザーが不可解にする政策を実施することが可能である（例えば、任意のユーザーからの未認証登録を受け入れるもの）。そのようなドメインからIdentityヘッダの値は疑問です。検証は、SIPリクエストを調べて「悪い」ドメインから「良い」と区別するための魔法の方法はありませんが、承認慣行の更なる作業が、このアイデンティティ・ソリューションの上に構築することができることを期待されています。そのようなアイデンティティソリューションせずに、認可ポリシーに多くの有望なアプローチは不可能です。それくらい言った、プロキシサーバに基づく認証サービスは、トークンベースの識別子として強力な認証プラクティスを採用することが推奨されます。

One cannot expect the Identity and Identity-Info headers to be supported by every SIP entity overnight. This leaves the verifier in a compromising position; when it receives a request from a given SIP user, how can it know whether or not the sender's domain supports Identity? In the absence of ubiquitous support for identity, some transitional strategies are necessary.

一つは、アイデンティティとアイデンティティ情報のヘッダは、一晩すべてのSIPエンティティによってサポートされることを期待することはできません。これは、妥協の位置に検証を残し;それは与えられたSIPユーザからの要求を受信したとき、どのようにそれは、送信者のドメインがアイデンティティをサポートしているか否かを知ることができますか？アイデンティティのためのユビキタス支援がない場合には、いくつかの移行戦略が必要です。

A verifier could remember when it receives a request from a domain that uses Identity, and in the future, view messages received from that domain without Identity headers with skepticism.

それはアイデンティティを使用するドメインからの要求を受信し、将来的には、ビューのメッセージは懐疑を持つIdentityヘッダなしでそのドメインから受信したときに検証を覚えることができます。

A verifier could query the domain through some sort of callback system to determine whether or not it is running an authentication service. There are a number of potential ways in which this could be implemented; use of the SIP OPTIONS method is one possibility. This is left as a subject for future work.

検証は、認証サービスを実行しているかどうかを判断するために、コールバックシステムのいくつかの並べ替えてドメインを問い合わせることができます。これを実装することができている可能性はいくつかの方法があります。 SIP OPTIONSメソッドを使用することは、1つの可能性です。これは、将来の仕事のための課題として残されています。

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 the SIP protocol; that is the only way to guarantee that this protection can always be expected by verifiers.

長期的に、同一の機構のいくつかの並べ替え、本明細書に記載のいずれか一つまたは後継者は、SIPプロトコルのために必須に使用にならなければなりません。それは、この保護は常に検証が期待できることを保証する唯一の方法です。

Finally, it is worth noting that the presence or absence of the Identity headers 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 headers are always good.

最後に、それは、Identityヘッダの有無は、認可決定を行うで唯一の要因であることができないことは注目に値します。アクセス権は、SIPリクエストの他の側面上の特定の検証アイデンティティや実際に基づいてメッセージに付与される可能性があります。認可ポリシーは、この仕様の範囲外であるが、この仕様は、有効なIdentityヘッダーを含むメッセージは常に良好であることを前提としていない将来の承認作業をアドバイスします。

14. IANA Considerations

14. IANAの考慮事項

This document requests changes to the header and response-code sub-registries of the SIP parameters IANA registry, and requests the creation of two new registries for parameters for the Identity-Info header.

このドキュメントは、IANAレジストリパラメータSIPのヘッダとレスポンスコードのサブレジストリへの変更を要求し、アイデンティティ-Infoヘッダーのパラメータのための2つの新しいレジストリの作成を依頼します。

14.1. Header Field Names

14.1. ヘッダーフィールド名

This document specifies two new SIP headers: Identity and Identity-Info. Their syntax is given in Section 9. These headers are defined by the following information, which has been added to the header sub-registry under http://www.iana.org/assignments/sip-parameters.

アイデンティティとアイデンティティ情報：この文書では、2つの新しいSIPヘッダを指定します。その構文は、これらのヘッダはhttp://www.iana.org/assignments/sip-parameters下ヘッダーサブレジストリに追加された次の情報によって定義されたセクション9に記載されています。

         Header Name: Identity
         Compact Form: y
         Header Name: Identity-Info
         Compact Form: n

14.2. 428 'Use Identity Header' Response Code

14.2. 428「を使用するアイデンティティヘッダーの」レスポンスコード

This document registers a new SIP response code, which is described in Section 6. It is sent when a verifier receives a SIP request that lacks an Identity header in order to indicate that the request should be re-sent with an Identity header. This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters.

この文書は、検証要求がIdentityヘッダで再送信されるべきであることを示すためにIdentityヘッダを欠いているSIP要求を受信したときにそれが送信され、セクション6に記載されている新たなSIP応答コードを登録します。この応答コードはhttp://www.iana.org/assignments/sip-parameters下方法と応答コードのサブレジストリに追加された次の情報によって定義されます。

         Response Code Number: 428
         Default Reason Phrase: Use Identity Header

14.3. 436 'Bad Identity-Info' Response Code

14.3. 436「悪いアイデンティティ情報」応答コード

This document registers a new SIP response code, which is described in Section 6. It is used when the Identity-Info header contains a URI that cannot be dereferenced by the verifier (either the URI scheme is unsupported by the verifier, or the resource designated by the URI is otherwise unavailable). This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters.

アイデンティティ-Infoヘッダーは（URIスキームのいずれかが検証者によってサポートされていない、またはリソースが指定検証者によって間接参照することができないURIが含まれている場合、この文書は、それが使用されている第6章に記載されている新たなSIP応答コードを登録しますURIにより）それ以外の場合は使用できません。この応答コードはhttp://www.iana.org/assignments/sip-parameters下方法と応答コードのサブレジストリに追加された次の情報によって定義されます。

         Response Code Number: 436
         Default Reason Phrase: Bad Identity-Info

14.4. 437 'Unsupported Certificate' Response Code

14.4. 437「サポートされていない証明書」レスポンスコード

This document registers a new SIP response code, which is described in Section 6. It is used when the verifier cannot validate the certificate referenced by the URI of the Identity-Info header, because, for example, the certificate is self-signed, or signed by a root certificate authority for whom the verifier does not possess a root certificate. This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters.

この文書は、それが検証者は、Identity-InfoヘッダのURIにより参照証明書を検証できない場合、例えば、証明書は自己署名されている、ので、使用されるか、または、セクション6に記載されている新たなSIP応答コードを登録します検証は、ルート証明書を持たない人のために、ルート認証局が署名しました。この応答コードはhttp://www.iana.org/assignments/sip-parameters下方法と応答コードのサブレジストリに追加された次の情報によって定義されます。

         Response Code Number: 437
         Default Reason Phrase: Unsupported Certificate

14.5. 438 'Invalid Identity Header' Response Code

14.5. 438「無効なアイデンティティヘッダー」応答コード

This document registers a new SIP response code, which is described in Section 6. It is used when the verifier receives a message with an Identity signature that does not correspond to the digest-string calculated by the verifier. This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters.

この文書は、検証者が検証者によって算出ダイジェスト文字列に対応しないアイデンティティ署名付きメッセージを受信したときにそれが使用されている第6章に記載されている新たなSIP応答コードを登録します。この応答コードはhttp://www.iana.org/assignments/sip-parameters下方法と応答コードのサブレジストリに追加された次の情報によって定義されます。

         Response Code Number: 438
         Default Reason Phrase: Invalid Identity Header

14.6. Identity-Info Parameters

14.6. アイデンティティ情報のパラメータ

The IANA has created a new registry for Identity-Info headers. This registry is to be prepopulated with a single entry for a parameter called 'alg', which describes the algorithm used to create the signature that appears in the Identity header. Registry entries must contain the name of the parameter and the specification in which the parameter is defined. New parameters for the Identity-Info header may be defined only in Standards Track RFCs.

IANAは、Identity-情報ヘッダーの新しいレジストリを作成しました。このレジストリは、Identityヘッダに表示された署名を作成するために使用されるアルゴリズムを記述する「ALG」と呼ばれるパラメータのための単一のエントリで事前入力されます。レジストリエントリは、パラメータの名前とパラメータが定義されている仕様が含まれている必要があります。アイデンティティ-Infoヘッダーのための新しいパラメータは、唯一の標準化過程のRFCで定義されてもよいです。

14.7. Identity-Info Algorithm Parameter Values

14.7. アイデンティティ・インフォアルゴリズムのパラメータ値

The IANA has created a new registry for Identity-Info 'alg' parameter values. This registry is to be prepopulated with a single entry for a value called 'rsa-sha1', which describes the algorithm used to create the signature that appears in the Identity header. Registry entries must contain the name of the 'alg' parameter value and the specification in which the value is described. New values for the 'alg' parameter may be defined only in Standards Track RFCs.

IANAは、Identity-情報「ALG」パラメータ値のための新しいレジストリを作成しました。このレジストリは、Identityヘッダに表示された署名を作成するために使用されるアルゴリズムを記述する「RSA-SHA1」と呼ばれる値のための単一のエントリで事前入力されます。レジストリエントリは、「ALG」パラメータ値の名前と値が記述されている仕様が含まれている必要があります。「ALG」パラメータの新しい値は標準化過程のRFCで定義されてもよいです。

Appendix A. Acknowledgements

付録A.謝辞

The authors would like to thank Eric Rescorla, Rohan Mahy, Robert Sparks, Jonathan Rosenberg, Mark Watson, Henry Sinnreich, Alan Johnston, Patrik Faltstrom, Paul Kyzviat, Adam Roach, John Elwell, Aki Niemi, and Jim Schaad for their comments. Jonathan Rosenberg provided detailed fixes to innumerable sections of the document. The bit-archive presented in Appendix B follows the pioneering example of RFC 4475 [16]. Thanks to Hans Persson and Tao Wan for thorough nit reviews.

作者は彼らのコメントのためにエリックレスコラ、ロハンマーイ、ロバート・スパークス、ジョナサン・ローゼンバーグ、マーク・ワトソン、ヘンリーSinnreich、アラン・ジョンストン、パトリックFaltstrom、ポールKyzviat、アダムローチ、ジョンエルウェル、アキニエミ、およびジムSchaadに感謝したいと思います。ジョナサン・ローゼンバーグは、文書の無数のセクションに詳細な修正を提供します。付録Bに示されたビット・アーカイブは、RFC 4475 [16]の先駆的な例を以下。徹底したNITレビューのためのハンス・パーションとタオワンに感謝します。

Appendix B. Bit-Exact Archive of Examples of Messages

メッセージの例を付録B.ビット正確なアーカイブ

The following text block is an encoded, gzip-compressed TAR archive of files that represent the transformations performed on the examples of messages discussed in Section 10. It includes for each example:

次のテキストブロックは、各例えば含むセクション10で説明したメッセージの例に対して行わ変換を表すファイルの符号化され、gzipで圧縮されたtarアーカイブです。

o (foo).message: the original message o (foo).canonical: the canonical string constructed from that message o (foo).sha1: the SHA1 hash of the canonical string (hexadecimal) o (foo).signed: the RSA-signed SHA1 hash of the canonical string (binary) o (foo).signed.enc: the base64 encoding of the RSA-signed SHA1 hash of the canonical string as it would appear in the request o (foo).identity: the original message with the Identity and Identity-Info headers added

O（FOO）.message：元のメッセージO（FOO）.canonical：そのメッセージO（FOO）.sha1から構築標準的な文字列：.signed標準的な文字列（16進数）O（FOO）のSHA1ハッシュ：RSAそれは、要求O（FOO）.identityに現れるように標準的な文字列のRSA署名SHA1ハッシュのbase64エンコーディング：元の標準的な文字列（バイナリ）O（FOO）.signed.encのSHA1ハッシュを-signed追加のアイデンティティとアイデンティティ情報ヘッダを持つメッセージ

Also included in the archive are two public key/certificate pairs, for atlanta.example.com and biloxi.example.org, respectively, including:

：また、アーカイブに含めて、それぞれ、atlanta.example.comとbiloxi.example.orgのために、2公開鍵/証明書のペアも含ま

o (foo).cer: the certificate of the domain o (foo).privkey: the private key of the domain o (foo).pubkey: the public key of the domain, extracted from the cert file for convenience

O（FOO）.CER：ドメイン0（FOO）.privkeyの証明書：ドメイン0（FOO）.pubkeyの秘密鍵：ドメインの公開鍵、便宜上証明書ファイルから抽出されました

To recover the compressed archive file intact, the text of this document may be passed as input to the following Perl script (the output should be redirected to a file or piped to "tar -xzvf -").

そのまま圧縮されたアーカイブファイルを復元するには、この文書のテキストは（出力をファイルにリダイレクトするかを「タール-xzvf - 」パイプする必要があります）次のPerlスクリプトへの入力として渡すことができます。

   #!/usr/bin/perl
   use strict;
   my $bdata = "";
   use MIME::Base64;
   while(<>) {
    if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) {
        if ( m/^\s*[^\s]+\s*$/) {
            $bdata = $bdata . $_;
        }
     }
   }
   print decode_base64($bdata);

Alternatively, the base-64 encoded block can be edited by hand to remove document structure lines and fed as input to any base-64 decoding utility.

あるいは、ベース64符号化されたブロックは、文書構造線を除去するために手動で編集し、任意のベース64復号ユーティリティへの入力として供給することができます。

B.1. Encoded Reference Files

B.1。エンコードされた参照ファイル

-- BEGIN MESSAGE ARCHIVE -- H4sICFfaz0QCA25ld2lkZW50LnRhcgDsW0us5NhZ7gUSwqiF2CAhFikiIQhFt992 +U46it+u8qPK5Uc9WPlVfj/KdpXtomEDCxaAhFggISE2WSHCIoIFioQQC8gqAhRA QQTY8JJAbMgGIYTv7b7T09PT0xNl+mqS3F8qVd3jY/uc85//+87/nXOLoIv9oGjB B2/PIAiDSBwfv1GERInxG8EwAh6/37UHMIQRKIljCI4+gGCUGKtP8Ad3YKemderJ 5EFSBW1QN2Xxmnp5GtblqXqUPfIffBdZcet/p82conUee0H9sfsfhiACw17nfwQa y+Dra+MkQGFkrI+TOPJgAt37/63bo2tjeHGuTVh+bc6FOUub/E0poM7nLGqyLJ06 Id3NGTocPxytMWF6jNJYpDqIoXVLoDlmr+pNx+o7ztZ1ke8WtnXhFUClU5GGLZ6l O3YN8T3P0Usm1GyG9lQGEiBXFE6+yPecSSvPykuV4TPB5ne9xNEO8KxQVXnk3cqn /TaK3C3T7A08cRGokyJPUzmrV7k5pHK7i5bQyOambNcDLxUmH9zMD2sl8FGa+WGt BG6bGe5nHafvFnK5n0dnT6N1nmF0mgt3EK3OxQVdiuMzZrNOhPxNOF37W7w4LmsL OA0Mpeqt7RTKTrDX1CztZgezbM7rLlvQeBnhWzWOV5qDZEdMahLZTo8Wq0oZOL4X FgkgMhY4pNBdU53sHVvlaIX5TjqH0+JkYXAXmmzgSI7H9N3RvHingrIOAUIzCph4 GhsdHGDwET+WCO5SuDtwxXKNvneGYrWiQ5WhaTEJXb0LXb6Trgd2DS0ZZscLWm6B au3aO48HZK4GEWgzN2oRTuBaG/vLXA+aZKh8kDBYyJj7bHWREXgjMWxIgFQrxPyx b3eUc3EEH6iEptuYL1zFRCpr22rPXujFs9EPx0s+o67pbhzRa/eOjvEZX+wjt1hH gKpDHdvdXJA5er1Y22tRXXed+KwyxzFadFtZyW1st4E7V7ROO4Rqw5Cnx6ncXb/Z 5ztdUOmx34dX3Ck8cydPc76+a5uO4XLTMI9Q3iIwDJBOloNbUahd5OK7FnQu637t L/cQdlSHel5tRVjh84Jfhl7pDfV2zZyPeEVs3D3t8XoKAVzDo3YAad6sp4r8nCUb UmxUUWAL9lRiS848gHAm+nZNcQF78RIY2lk6qq6DnFO30Q4B2JaLG2WTkcZ2uVx7 ezqGS4vqngA30c5r3KsI8ODevsvtFf6v6vicBsMd8j+ME+Qt/0PjAnCsT5AQes// d8z/a4OerNZze4z+iczvXqwBtvrI+7TMhDq3WqlMK9nlKt3a0z2RHGGlCQ8jMtub akAY2zocFupKgghFgbyFoS8BZx7Yl3mZXDZt5ZwYcj5kezmjEwY/YCO4rk+lFQc+ 26mK7GYb+rhviUDaVKy2X5DZUvOAOd8VeYQUtOfJ6QxVKtCW0DakDRBDOb3cIk3h F7toGs5wBFldupDkxU1TXS7dnKN1mgFumFWGNmhb8AJH0omt08VC23Jtj1O0A9sn ZMFvA6KMp8s6FYZmkbj7RdcoudzWYdsCq+3SmrVIvq9iqJOxaIu1+6ho406UU2vF ohHFJNVUDOr4sEIxeK0O6nJKHFZhclxeLK4DpvUqSdSqG1+eerx35ELXrPfF5gzq BWs4joD2qSUehFTp8aXsremUp0mrLxp+tnVMFALaFWhZHg6HWorIohz2um5KZcV4 QUcNh4BdC9HZV8ikckSn5WM83neiONKavbQlS4MlANoplaQn67JbMLQ2XSPumQa1

- メッセージアーカイブをBEGIN - H4sICFfaz0QCA25ld2lkZW50LnRhcgDsW0us5NhZ7gUSwqiF2CAhFikiIQhFt992 + U46it + u8qPK5Uc9WPlVfj / KdpXtomEDCxaAhFggISE2WSHCIoIFioQQC8gqAhRA QQTY8JJAbMgGIYTv7b7T09PT0xNl + mqS3F8qVd3jY / uc85 // + 87 / nXOLoIv9oGjB B2 / PIAiDSBwfv1GERInxG8EwAh6 / 37UHMIQRKIljCI4 + gGCUGKtP8Ad3YKemderJ 5EFSBW1QN2Xxmnp5GtblqXqUPfIffBdZcet / p82conUee0H9sfsfhiACw17nfwQa Y + DRA + MkQGFkrI + TOPJgAt37 / 63bo2tjeHGuTVh + bc6FOUub / E0poM7nLGqyLJ06 Id3NGTocPxytMWF6jNJYpDqIoXVLoDlmr + PNX + o7ztZ1ke8WtnXhFUClU5GGLZ6l O3YN8T3P0Usm1GyG9lQGEiBXFE6 + yPecSSvPykuV4TPB5ne9xNEO8KxQVXnk3cqn / TaK3C3T7A08cRGokyJPUzmrV7k5pHK7i5bQyOambNcDLxUmH9zMD2sl8FGa + WGT BG6bGe5nHafvFnK5n0dnT6N1nmF0mgt3EK3OxQVdiuMzZrNOhPxNOF37W7w4LmsL OA0Mpeqt7RTKTrDX1CztZgezbM7rLlvQeBnhWzWOV5qDZEdMahLZTo8Wq0oZOL4X FgkgMhY4pNBdU53sHVvlaIX5TjqH0 + JkYXAXmmzgSI7H9N3RvHingrIOAUIzCph4 GhsdHGDwET + WCO5SuDtwxXKNvneGYrWiQ5WhaTEJXb0LXb6Trgd2DS0ZZscLWm6B au3aO48HZK4GEWgzN2oRTuBaG / vLXA + aZKh8kDBYyJj7bHWREXgjMWxIgFQrxPyx b3eUc3EEH6iEptuYL1zFRCpr22rPXujFs9EPx0s + o67pbhzRa / eOjvEZX + wjt1 HH gKpDHdvdXJA5er1Y22tRXXed + KwyxzFadFtZyW1st4E7V7ROO4Rqw5Cnx6ncXb / Z 5ztdUOmx34dX3Ck8cydPc76 + a5uO4XLTMI9Q3iIwDJBOloNbUahd5OK7FnQu637t L / cQdlSHel5tRVjh84Jfhl7pDfV2zZyPeEVs3D3t8XoKAVzDo3YAad6sp4r8nCUb UmxUUWAL9lRiS848gHAm + nZNcQF78RIY2lk6qq6DnFO30Q4B2JaLG2WTkcZ2uVx7 ezqGS4vqngA30c5r3KsI8ODevsvtFf6v6vicBsMd8j + ME + QT / 0PjAnCsT5AQes // d8z / a4OerNZze4z + iczvXqwBtvrI + 7TMhDq3WqlMK9nlKt3a0z2RHGGlCQ8jMtub akAY2zocFupKgghFgbyFoS8BZx7Yl3mZXDZt5ZwYcj5kezmjEwY / YCO4rk + lFQc + 26mK7GYb + rhviUDaVKy2X5DZUvOAOd8VeYQUtOfJ6QxVKtCW0DakDRBDOb3cIk3h F7toGs5wBFldupDkxU1TXS7dnKN1mgFumFWGNmhb8AJH0omt08VC23Jtj1O0A9sn ZMFvA6KMp8s6FYZmkbj7RdcoudzWYdsCq + 3SmrVIvq9iqJOxaIu1 + 6ho406UU2vF ohHFJNVUDOr4sEIxeK0O6nJKHFZhclxeLK4DpvUqSdSqG1 + eerx35ELXrPfF5gzq BWs4joD2qSUehFTp8aXsremUp0mrLxp + tnVMFALaFWhZHg6HWorIohz2um5KZcV4 QUcNh4BdC9HZV8ikckSn5WM83neiONKavbQlS4MlANoplaQn67JbMLQ2XSPumQa1

OD9iBLYPiyDjudXR4en9xuHQdHmIDGp6VsjyyBvTE85DwIJMty65T2PDtkJqa4Gz Va/KPcjRF8i38qUytVhdmrEUb1rqHDnx7lFyGd+2RC1FCYwFOMErfKO3oymKyceF n8Q7oyfs1eqMEFsqJw1oOfhmaoQNCmJluerLmeSox20+g1idmdZA7zKolVXLMvKY TpCp3KwzlSHYhjpmBCGHXZEp1CnlI0nalZdxHPxtUDLsEFlNGfqGBRCgY9CCd97w YpuQ4HlY8Kyus6wBZ3LIb0tNXx2XmpOdd9EwqPv1VlB8Dgvdbr2S4dNWBnZVirLp Qbgsh0MSKJ646reXI3K8nKSLaHL9nlrRQdVtsbWRviDVDwyrTzD+n9yPGf7fhP8j 5kO3+I/AN/k/gZHYPf7fMf6vLEaZs++FfvGg0pDIGkfRmLsj2PLX6R5NY6JGcywT 6x9OCcDrOOGjUgLwOk74qJQAvJYT3o3O93f6e3b958ZZ2cdvQ/55s/6DvEf/QbBr /YeAifv4/yToP3DCsnQyfZP+s32j/mOO6Tp3ub75uf6TLipXpDDH5DWVbp7VCzve sGxrnfDuWEEErgvprjN2eda4aFS9PzVXGWzLmTSsmvSgcTQyfgYtK6/LkOsy4D2F nX15k4AAm6p+k9Y/FxD2LOBs+nMgph+o/YgXev+u9pM/746BZ4EotJ7YZ0qunQHX ZJni8v5B4wWaXjKJTnfhLmWvRYMzIXYbFjI5jFzInZwlZZR0gmoAGoi39e6ENYEk HsO0UyJ7umXRkl/i+LGOLxE6zD3bkFOqoJYZrS3Mo5bYjjSc16cLjwvABjZ3Tbgw EIHu51MYjruBLihkPUwjBwTDKJjJ0MqZLpQpjMVG40i2HhaHDtNTcH08ZDpASGdm Vh2T7DzUC/SINbE6epSnaWfJNGP36oT2b+QcHeOFULeg/XStYOQGpFdc6+EMcDBK fXviBR7sukN3IxIljBR2fkm/UvlF3SHaEOu9Kng98MJNO5PObPM9s20E9IU2zrbV NVXduLbrRP35fLmVfYCXdZ9mrHGr+yzi5y5+n7CIsCNRdBx901oTYGirG/vMgJcP mP/XeqHOxIMszduZuT2I2qEqFtsYT9j4suzz3WwHhFkxa4eV4ATDkcJN0Tub7Obi l4xiVww3PVTrTb0F53O84Qlbcl16TBnsXHb33UWn26oCVojgnBJk1lLYPuAkDTkf L8mhkBJ2iWCpiC5OB8ScQXFWUTvJ47o+sYS6nRFWkbHTIfaBwTGDU7PBxRN5hsMn 97rPvb3K/29B/nmz/kOit/wPI+NaYFz/49j9/s8nR/8Jb/UfFixdZqes1VXSpDV9 3CxjcUVb/RwFc6SNybjHPOfImvRJ2OKeEoQ6QBb58aQspcM86u350UQOEGHRULYs Ec0uDzIlkqqZ2q6txQOdKTuL4xNyu1G4OXtA95ICEEINTlmB7GqdqrH0TG7jhdyX vs2yPshFrEmJ1dTmymAmDflxuQHlpgjqeJi/pP8syEMjzOWtnCabMJmljbhsIwM1 CpjqVwY78D7TH/gcWSUkqF0uQRaDK2/pxB6UAouR+r3iqCEHiQ/mogxSvcX05ukQ 6jt7cTwPEr9uiHq7BWMT2xU51cIUhPOxTu0rqannADguEKwdDeu1GNJz6bxXbOVy nFKywvH7qaS7J1ZZbIUp4WYQ7+LMtf5DoESp0loF6Q4K5LsNryOnNhebXZ9ujcPA uPDMZJcd2w5Q4TNrBLsMy4WAaO7eoGbKZSo6CB4d5mIHLiQZKDjKXfKzmXWj/zBr o/IxNzemOTZbgzDarnmDbqXj4GtxsYVSA1xHnVSTeSqZFpqCKiD0etuj2BwV5Yuz 79UCoglCNqgzaEh+IUyD1Y2YIgak3kTDfnaKW2XV7jkvYzcRL0vAkdal3OL3Z0tA bEmp3VOqKMtQsmpJcxDMmytnzEcHh7WtoB1yzTsNZhfJCYJ1Ap3SS+ACJj3MV5mG Rp0y1Zos25ebOT47nU8kSB8RD/UuR8cWGddFYbKR2F0op5BLi2jaLdE8BigUVLYb E/b8eGdXOeNJ3M1I51WYCsm035/wcEMbO/yUnKcCq66gTedIeGQW29O0lQNgtUB9 ZL7Yy71YZETcymuNFIN1RK0MGUr3Y5osBHZ9bhaYVlYvEewnVwN6Bf8/fvnnW9N/ yBv9B8Wge/z/jtB/Xk8JwOs44aNSAvA6TviolAC8lhPu9Z9X4n8IHntOURax52R3 G//jAvD5+S8MxbGb9R8K38f/nVgTV1du6X7+OfwHvZNXWfC4rMOn15ecLPaCz9/u Ddxe9cr8qTPDXMwjiYAgRtx+iqDwhNnxT83o9DMTBJ4IgTtBRkdPYOwKpq5weCKq 5tOn9wnXJzn+b37F7cdM/2/M/2AUe3H+E7vZ/0eg+/2fO7ExZicvAr3yUPTxB0T7 xJivQOQx9BCwY+fq9i/QVIwJTI2/HiOPsXfc2im86MmFikTMlQunifwGHm9Rnf6R UNadU/vN1YQcS4S6zK8mTOlOPvt6/PncO60TPnEIb4Z7h4eAWV5N6OtGPrvntcD0 7LaxVTMUgkkSewhwThtcTT4UmB4CrJNlj+bc1eRlXBsvGMHxavIc3h4C8+chcjX5 dHPGWbOEcPlYGXkrtajv8fEShNmNaezbQkRjewoX+alWtjYo5e2gGaTS1iHlZ326 uZQPgckLCyzSJ5f2TOoC0+RK10bj1szDVccKicPn6sDPUZ80Bg2BB40rEX4NLs9h 20HKCfeaefXSw6rVcRnCp23hXyRXJPM1sc4oprAi6XSw126Fw2qBdlB4sJonn37R p0fz4jCO8mejtq2aKxB81Sfv2SX63DtOFj6pG+dREznwOE5l0Y6PeaQERdhGV5Nx 6O7R9TsM//OgaZwwuOP9Pwh7cf57hH7i5vw3gd/j/z3+fyz4/1Gh/XsSwV6K/2sk fwvveFP8QyRxm/9hY43r+Efg+/Ofd2KGRMM/9VLu/5knkwM5IyjUP6A4jPuI5wfU GEw4jsEocX2ghnQdGMbgA3bP8N9l8R+HReDfefwj7/7/H0ZCOPHs/A95H/93YV/6

OD9iBLYPiyDjudXR4en9xuHQdHmIDGp6VsjyyBvTE85DwIJMty65T2PDtkJqa4Gzバージニア州/ KPcjRF8i38qUytVhdmrEUb1rqHDnx7lFyGd + 2RC1FCYwFOMErfKO3oymKyceF n8Q7oyfs1eqMEFsqJw1oOfhmaoQNCmJluerLmeSox20 + g1idmdZA7zKolVXLMvKY TpCp3KwzlSHYhjpmBCGHXZEp1CnlI0nalZdxHPxtUDLsEFlNGfqGBRCgY9CCd97w YpuQ4HlY8Kyus6wBZ3LIb0tNXx2XmpOdd9EwqPv1VlB8Dgvdbr2S4dNWBnZVirLp Qbgsh0MSKJ646reXI3K8nKSLaHL9nlrRQdVtsbWRviDVDwyrTzD + n9yPGf7fhP8j 5kO3 + I / AN / K / gZHYPf7fMf6vLEaZs ++ FfvGg0pDIGkfRmLsj2PLX6R5NY6JGcywT 6x9OCcDrOOGjUgLwOk74qJQAvJYT3o3O93f6e3b958ZZ2cdvQ / 55S / 6DvEf / QbBr / YeAifv4 / yToP3DCsnQyfZP + s32j / mOO6Tp3ub75uf6TLipXpDDH5DWVbp7VCzve sGxrnfDuWEEErgvprjN2eda4aFS9PzVXGWzLmTSsmvSgcTQyfgYtK6 / LkOsy4D2F nX15k4AAm6p + k9Y / FxD2LOBs + nMgph + O / YgXev + u9pM / 746BZ4EotJ7YZ0qunQHX ZJni8v5B4wWaXjKJTnfhLmWvRYMzIXYbFjI5jFzInZwlZZR0gmoAGoi39e6ENYEk HsO0UyJ7umXRkl / I + LGOLxE6zD3bkFOqoJYZrS3Mo5bYjjSc16cLjwvABjZ3Tbgw EIHu51MYjruBLihkPUwjBwTDKJjJ0MqZLpQpjMVG40i2HhaHDtNTcH08ZDpASGdm Vh2T7DzUC / SINbE6epSnaWfJNGP36oT2b + QcHeOFULeg / XStYOQGpFdc6 + EMcDBK fXviBR7sukN3IxIljBR2fkm / U vlF3SHaEOu9Kng98MJNO5PObPM9s20E9IU2zrbV NVXduLbrRP35fLmVfYCXdZ9mrHGr + yzi5y5 + n7CIsCNRdBx901oTYGirG / vMgJcP MP / XeqHOxIMszduZuT2I2qEqFtsYT9j4suzz3WwHhFkxa4eV4ATDkcJN0Tub7Obi l4xiVww3PVTrTb0F53O84Qlbcl16TBnsXHb33UWn26oCVojgnBJk1lLYPuAkDTkf L8mhkBJ2iWCpiC5OB8ScQXFWUTvJ47o + sYS6nRFWkbHTIfaBwTGDU7PBxRN5hsMn 97rPvb3K / 29B / NMZ / kOit / WPI + NaYFz / 49j9 / s8nR / 8Jb / UfFixdZqes1VXSpDV9 3CxjcUVb / RwFc6SNybjHPOfImvRJ2OKeEoQ6QBb58aQspcM86u350UQOEGHRULYs Ec0uDzIlkqqZ2q6txQOdKTuL4xNyu1G4OXtA95ICEEINTlmB7GqdqrH0TG7jhdyX vs2yPshFrEmJ1dTmymAmDflxuQHlpgjqeJi / pP8syEMjzOWtnCabMJmljbhsIwM1 CpjqVwY78D7TH / gcWSUkqF0uQRaDK2 / pxB6UAouR + r3iqCEHiQ / mogxSvcX05ukQ 6jt7cTwPEr9uiHq7BWMT2xU51cIUhPOxTu0rqannADguEKwdDeu1GNJz6bxXbOVy nFKywvH7qaS7J1ZZbIUp4WYQ7 + LMtf5DoESp0loF6Q4K5LsNryOnNhebXZ9ujcPA uPDMZJcd2w5Q4TNrBLsMy4WAaO7eoGbKZSo6CB4d5mIHLiQZKDjKXfKzmXWj / ZBR O / IxNzemOTZbgzDarnmDbqXj4GtxsYVSA1xHnVSTeSqZFpqCKiD0etuj2BwV5Yuz 79UCoglCNqgzaEh + IUyD1Y2YIgak3kTDfnaKW2XV7jkvYzcRL0vAkdal3OL3Z0tA bEmp3VOqKMtQsmpJcxDMmytnzEcHh7WtoB1yzTsNZhfJCYJ1Ap 3SS + ACJj3MV5mG Rp0y1Zos25ebOT47nU8kSB8RD / UuR8cWGddFYbKR2F0op5BLi2jaLdE8BigUVLYb E / b8eGdXOeNJ3M1I51WYCsm035 / wcEMbO / yUnKcCq66gTedIeGQW29O0lQNgtUB9 ZL7Yy71YZETcymuNFIN1RK0MGUr3Y5osBHZ9bhaYVlYvEewnVwN6Bf8 / fvnnW9N / yBv9B8Wge / Z / JTB / Xk8JwOs44aNSAvA6TviolAC8lhPu9Z9X4n8IHntOURax52R3 G // jAvD5 + S8MxbGb9R8K38f / nVgTV1du6X7 + OfwHvZNXWfC4rMOn15ecLPaCz9 / U Ddxe9cr8qTPDXMwjiYAgRtx + iqDwhNnxT83o9DMTBJ4IgTtBRkdPYOwKpq5weCKq 5tOn9wnXJzn + b37F7cdM / 2 / M / 2AUe3H + E7vZ / 0eg + / 2fO7ExZicvAr3yUPTxB0T7 xJivQOQx9BCwY + fq9i / QVIwJTI2 / HiOPsXfc2im86MmFikTMlQunifwGHm9Rnf6R UNadU / vN1YQcS4S6zK8mTOlOPvt6 / PncO60TPnEIb4Z7h4eAWV5N6OtGPrvntcD0 7LaxVTMUgkkSewhwThtcTT4UmB4CrJNlj + bc1eRlXBsvGMHxavIc3h4C8 + chcjX5 dHPGWbOEcPlYGXkrtajv8fEShNmNaezbQkRjewoX + alWtjYo5e2gGaTS1iHlZ326 uZQPgckLCyzSJ5f2TOoC0 + RK10bj1szDVccKicPn6sDPUZ80Bg2BB40rEX4NLs9h 20HKCfeaefXSw6rVcRnCp23hXyRXJPM1sc4oprAi6XSw126Fw2qBdlB4sJonn37R p0fz4jCO8mejtq2aKxB81Sfv2SX63DtOFj6pG + dREznwOE5l0Y6PeaQERdhGV5Nx 6O7R9TsM // OgaZwwuOP9Pwh7cf57hH7i5vw3gd / J / Z3 + fyz4 / 1GH / XsSwV6K / 2SK fwvveFP8Qy RXM / 9hY43r + EFG + / Ofd2KGRMM / 9VLu / 5knkwM5IyjUP6A4jPuI5wfU GEw4jsEocX2ghnQdGMbgA3bP8N9l8R + HReDfefwj7 / 7 / H0ZCOPHs / A95H / 93YV / 6

P0b7Veqnf3f9W3/5n9/42+/75f/65g/4f3X4+p/9w0/8wt8Mv/97f/jX/zt88Stf +/Ljv/unb379+OvZvw3aN/7jn59+6vt/Q7n6sU3/RS36oT/5cS+a/8pXGLL7gy+R eY1dET/8qa/+8Q9Wf/HlP6r/9DNf+J9f+8Wf/c3f/vs/z4p/Eb8Q/PePfu2Xfu53 rB/59381fvIfH05+Xr6PwE9c/D8OCu9u4/+F/nt9BOBG/yXuz//djf77bYoYwLcr XADfilhxv+B4a/EfF+e4fTtbQG+Kfxy6Pv+D4SiMosTN+V9yzAnu4/9O4v9DN3k+ ZHfoffs/6JgQ4NRkrtlz84N2gdArCLmC0JtdoDfrDU/PT8bsu3xiNUFN/3875/Pa NBiH8Yt6CBS0Q2SDYcYEkSl9k75Nmkmn7ebWde2WLm3646Jp2q7FtU2btq496EGc KMgu4sH5a4dN8NccCMLYP6AMwcv+Bg/e1NMuZimTdlvXyWxx4/s5pQ0N5SXPk/d9 nrclaSuHrBhbaKb6cHiUHOYxWe8SBkK1CTFVTWbSpDDAGwjZ1vATeRvaWPWnbFIh msyQmKNYmhz38Sa7yG+ckGy5vJKSlF5E8v0ev8mq3bwHPCTYqv9mVEAN9//p+Z+m f9qCMMvqv/+k4fnfEiqCJbcJfVPnuyR/9XS0YxBorSR4jTK/zWywKUlfjUftlEvW a4qqzKsSE0pyvrf629Ubir6awigcGnVEnP0IiZ5wjr4ezjNiqr/IZ9IBl2eo6PU5 BrITiUwg5p5yxcsOWqKUKXvOLE7kHEhQBbtU0/Ek4+p4NDnGZ7zh0FiJvpETJxKF hKx6Is6AXxicGmYUJmvxjXmDTk+qzBSuZMxq0aUKTszlE6WhdM3FBkU5XZLCPT2l 8UlHKOT1ubOBsqtnREzwI5G436TkSgkxzYVkxr9bYbTDCFT/r0y9yshXUrRhlxRF G0sprxm2SY0q2/NYCrMGwkDAo6GZ/t+MCqhh/4/MVf2Pvv7DDMz/wP8Pg/+DyQEH yP+bUQE23P+JqD/zfxpZ9P5fewv8vwXo/d/W7OecjaRZhGWaZq04LtGUjCPIwkUQ krUXmI1xEstIUQmbOVD/IdN/EyrAPfZ/Ff2z+v5P7RD03wpit+2TyoevQvtisv3j fJz48e1pxN3xs+1I74vpO89MxqurnY/XnlxeLFx702lcIjvurZ8ods/MHQtevPD+ bbBr+dR5amnN25XtflV+/fCLPbs62/fO+OD7yqzx9EzqbtfLk4GznxZurp+JHZ0+ 7l5+tPr8vtj2OfXr0sLKnHgrqM6DAv9H/f/bCnCP/Z+ufzOm9PyfhfVfS9hvJkXs N4ci/iZ7gtkGAAAAAAAAAAAAAAAAAAAAAAAAAABAPX4DY+BfEQB4AAA= -- END MESSAGE ARCHIVE --

P0b7Veqnf3f9W3 / 5n9 / 42 + / 75F / 65グラム/ 4f3X4 + P / 9w0 / 8wt8Mv /ラ97f / jXの/ zt88Stf + / Ljv / unb379 + OvZvw3aN / 7jn59 + 6vt / Q7n6sU3 / RS36oT / 5CS + A / 8pXGLL7gy + R eY1dET / 8qa / + 8Q9Wf / HlP6r / 9DNf + J9f + 8Wf / C3F / VS / z4p / Eb8Q / PePfu2Xfu53をrB / 59381fvIfH05 + Xr6PwE9c / D8OCu9u4 / + F / nt9BOBG / yXuz // djf77bYoYwLcr XADfilhxv + B4A / EFF + e4fTtbQG + Kfxy6Pv + D4SiMosTN + V9yzAnu4 / 9O4v9DN3k + ZHfoffs / 6JgQ4NRkrtlz84N2gdArCLmC0JtdoDfrDU / PT8bsu3xiNUFN / 3875 / PA NBiH8Yt6CBS0Q2SDYcYEkSl9k75Nmkmn7ebWde2WLm3646Jp2q7FtU2btq496EGc KMgu4sH5a4dN8NccCMLYP6AMwcv + Bgを/ e1NMuZimTdlvXyWxx4 / s5pQ0N5SXPk / D9 nrclaSuHrBhbaKb6cHiUHOYxWe8SBkK1CTFVTWbSpDDAGwjZ1vATeRvaWPWnbFIh msyQmKNYmhz38Sa7yG + ckGy5vJKSlF5E8v0ev8mq3bwHPCTYqv9mVEAN9 // P + Z + M f9qCMMvqv / + k4fnfEiqCJbcJfVPnuyR / 9XS0YxBorSR4jTK / zWywKUlfjUftlEvW a4qqzKsSE0pyvrf629Ubir6awigcGnVEnP0IiZ5wjr4ezjNiqr / IZ9IBl2eo6PU5 BrITiUwg5p5yxcsOWqKUKXvOLE7kHEhQBbtU0 / EK4 + p4NDnGZ7zh0FiJvpETJxKF hKx6Is6AXxicGmYUJmvxjXmDTk + qzBSuZMxq0aUKTszlE6WhdM3FBkU5XZLCPT2l 8UlHKOT1ubOBsqtnREzwI5G436TkSgkxzYVkxr9bYbTDCFT / r0y9yshXUrRhlxRF G0sprxm2SY0q2 / NYCrMGwkDAo 6GZ / T + MCqhh / 4 / MVf2Pvv7DDMz / wP8Pg / + DyQEH y・Pと+ bUQE23P + JQD / zfxpZ9P5fewv8vwXo / D / W7OecjaRZhGWaZq04LtGUjCPIwkUQ krUXmI1xEstIUQmbOVD / IDN / EyrAPfZ / Ff2z + v5P7RD03wpit + 2TyoevQvtisv3j fJz48e1pxN3xs + 1I74vpO89MxqurnY / XnlxeLFx702lcIjvurZ8ods / MHQtevPD + bbBr + dR5amnN25XtflV + / fCLPbs62 / FO + OD7yqzx9EzqbtfLk4GznxZurp + JHZ0 + 7l5 + tPr8vtj2OfXr0sLKnHgrqM6DAv9H / F / bCnCP / Z + ufzOm9PyfhfVfS9hvJkXs N4ci / iZ7gtkGAAAAAAAAAAAAAAAAAAAAAAAAAABAPX4DY + BfEQB4AAA = - ENDメッセージアーカイブ -

Appendix C. Original Requirements

付録C.オリジナルの要件

The following requirements were crafted throughout the development of the mechanism described in this document. They are preserved here for historical reasons.

以下の要件は、この文書で説明するメカニズムの開発を通じて作られました。彼らは歴史的な理由のためにここに保存されています。

o The mechanism must allow a UAC or a proxy server to provide a strong cryptographic identity assurance in a request that can be verified by a proxy server or UAS. o User agents that receive identity assurances must be able to validate these assurances without performing any network lookup. o User agents that hold certificates on behalf of their user must be capable of adding this identity assurance to requests. o Proxy servers that hold certificates on behalf of their domain must be capable of adding this identity assurance to requests; a UAC is not required to support this mechanism in order for an identity assurance to be added to a request in this fashion. o The mechanism must prevent replay of the identity assurance by an attacker. o In order to provide full replay protection, the mechanism must be capable of protecting the integrity of SIP message bodies (to ensure that media offers and answers are linked to the signaling identity). o It must be possible for a user to have multiple AoRs (i.e., accounts or aliases) that it is authorized to use within a domain, and for the UAC to assert one identity while authenticating itself as another, related, identity, as permitted by the local policy of the domain.

Oメカニズムは、UACまたはプロキシサーバがプロキシサーバまたはUASによって検証することができ、要求に強力な暗号化身元保証を提供できるようにする必要があります。 O身元保証を受けるユーザエージェントは、任意のネットワーク・ルックアップを実行することなく、これらの保証を検証できるようにする必要があり。 Oそのユーザーに代わって証明書を保持するユーザエージェントは、要求に、このアイデンティティ保証を追加することが可能でなければなりません。 O自分のドメインに代わって証明書を保持するプロキシサーバーは、要求に、このアイデンティティ保証を追加することが可能でなければなりません。 UACは、身元保証は、このやり方では、要求に追加するために、このメカニズムをサポートする必要はありません。 Oメカニズムは、攻撃者が身元保証のリプレイを防ぐ必要があります。 Oフル再生保護を提供するために、メカニズムは、SIPメッセージボディの完全性を保護することが可能でなければならない（そのメディアの提供を確保するとの回答は、シグナリング・アイデンティティにリンクされています）。ユーザが複数のAORを有することが可能でなければならないO（すなわち、アカウントやエイリアス）は、それがドメイン内で使用することが許可されていること、及び、関連する、別のようにアイデンティティを自分自身を認証しながらによって許可されるようUACのために、1人のアイデンティティをアサートしますドメインのローカルポリシー。

References

リファレンス

Normative References

引用規格

[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[3] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.

[3]ピーターソン、J.、RFC 3323 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"、2002年11月。

[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.

[4]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。

[5] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.

[5]ピーターソン、J.、 "セッション開始プロトコル（SIP）認証済みアイデンティティボディ（AIB）フォーマット"、RFC 3893、2004年9月。

[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.

[6]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。

[7] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.

[7] Housley氏、R.、 "暗号メッセージ構文（CMS）アルゴリズム"、RFC 3370、2002年8月。

[8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.

[8] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 3548、2003年7月。

[9] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.

[9] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。

[10] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.

[10] Housley氏、R.とP.ホフマン、 "インターネットX.509公開鍵基盤運用プロトコル：FTPやHTTP"、RFC 2585、1999年5月。

[11] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[11]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。

Informative References

参考文献

[12] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.

[12]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。

[13] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.

[13] Schulzrinneと、H.、 "電話番号については、TEL URI"、RFC 3966、2004年12月。

[14] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.

[14] Faltstrom、P.とM. Mealling、RFC 3761、2004年4月 "統一資源識別子（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）へのE.164"。

[15] Peterson, J., "Retargeting and Security in SIP: A Framework and Requirements", Work in Progress, February 2005.

[15]ピーターソン、J.、「SIPでのリターゲットとセキュリティ：フレームワークと要件」、進歩、2005年2月に作業。

[16] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages, RFC 4475, May 2006.

[16]スパークス、R.、編、Hawrylyshen、A.、ジョンストン、A.、ローゼンバーグ、J.、およびH. Schulzrinneと、「セッション開始プロトコル（SIP）調教テストメッセージ、RFC 4475、2006年5月。

Authors' Addresses

著者のアドレス

Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US

ジョンピーターソンNeuStar、Inc.の1800サッターセントスイート570コンコード、CA 94520米国

Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/

電話：+1 925/363から8720 Eメール：jon.peterson@neustar.biz URI：http://www.neustar.biz/

Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 USA

カレンジェニングスシスコシステムズ170西タスマンドライブMS：SJC-2分の21サンノゼ、CA 95134 USA

Phone: +1 408 902-3341 EMail: fluffy@cisco.com

電話：+1 408 902-3341 Eメール：fluffy@cisco.com

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2006）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。