RFC 3893 - Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format 日本語訳

URL : https://tools.ietf.org/html/rfc3893
タイトル : RFC 3893 - セッション開始プロトコル（SIP）認証済みアイデンティティボディ（AIB）フォーマット
翻訳編集 : 自動生成

Network Working Group                                        J. Peterson
Request for Comments: 3893                                       NeuStar
Category: Standards Track                                 September 2004

                   Session Initiation Protocol (SIP)
                Authenticated Identity Body (AIB) Format

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）インターネット協会（2004）。

Abstract

抽象

RFC 3261 introduces the concept of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given.

RFC 3261は、ヘッダ上の参照整合性を提供するために、セッション開始プロトコル（SIP）要求または応答にS / MIMEボディを追加の概念を導入します。この文書では、「認証された識別体」、デジタル署名されたSIPメッセージ、またはメッセージフラグメントから完全性及び認証の特性を導出するためのより具体的なメカニズムを提供します。（認証されたアイデンティティ機関、又はAIBsとしても知られる）は、体のための標準的なフォーマットは、本文書に記載されています。こうした機関とのSIPメッセージの受信者によるAIBsの処理のためのいくつかの考察も与えられています。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Requirements Notation. . . . . . . . . . . . . . . . . .  3
   2.  AIB Format . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Example of a Request with AIB  . . . . . . . . . . . . . . . .  5
   4.  AIBs for Identifying Third-Parties . . . . . . . . . . . . . .  6
   5.  Identity in non-INVITE Requests  . . . . . . . . . . . . . . .  7
   6.  Identity in Responses  . . . . . . . . . . . . . . . . . . . .  7
   7.  Receiving an AIB . . . . . . . . . . . . . . . . . . . . . . .  7
   8.  Encryption of Identity . . . . . . . . . . . . . . . . . . . .  8
   9.  Example of Encryption  . . . . . . . . . . . . . . . . . . . .  8
   10. Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       12.1. Normative References . . . . . . . . . . . . . . . . . . 11
       12.2. Informative References . . . . . . . . . . . . . . . . . 11
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   14. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
   15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13

1. Introduction

1. はじめに

Section 23.4 of RFC 3261 [1] describes an integrity mechanism that relies on signing tunneled 'message/sip' MIME bodies within SIP requests. The purpose of this mechanism is to replicate the headers of a SIP request within a body carried in that request in order to provide a digital signature over these headers. The signature on this body also provides authentication.

RFC 3261のセクション23.4には、[1] SIPリクエスト内でトンネリング「というメッセージ/一口」MIMEボディを署名に依存している整合性のメカニズムを説明しています。この機構の目的は、これらのヘッダーを介してデジタル署名を提供するために、その要求内で運ば本体内のSIPリクエストのヘッダを複製することです。このボディの署名は、認証を提供します。

The core requirement that motivates the tunneled 'message/sip' mechanism is the problem of providing a cryptographically verifiable identity within a SIP request. The baseline SIP protocol allows a user agent to express the identity of its user in any of a number of headers. The primary place for identity information asserted by the sender of a request is the From header. The From header field contains a URI (like 'sip:alice@example.com') and an optional display-name (like "Alice") that identifies the originator of the request. A user may have many identities that are used in different contexts.

トンネリング「メッセージ/ SIP」機構を動機コア要件は、SIP要求内暗号検証可能な識別情報を提供する問題です。ベースラインSIPプロトコルは、ヘッダーの数のいずれかでそのユーザのアイデンティティを表現するユーザエージェントを可能にします。リクエストの送信者によって表明さ身元情報の主な場所は、Fromヘッダーです。要求の発信元を識別し、（「アリス」のような）任意の表示名：ヘッダフィールドから（「alice@example.com SIP」など）URIを含みます。ユーザーは、異なるコンテキストで使用されている多くのアイデンティティを有することができます。

Typically, this URI is an address-of-record that can be de-referenced in order to contact the originator of the request; specifically, it is usually the same address-of-record under which a user registers their devices in order to receive incoming requests. This address-of-record is assigned and maintained by the administrator of the SIP service in the domain identified by the host portion of the address-of-record. However, the From field of a request can usually be set arbitrarily by the user of a SIP user agent; the From header of a message provides no internal assurance that the originating user can legitimately claim the given identity. Nevertheless, many SIP user agents will obligingly display the contents of the From field as the identity of the originator of a received request (as a sort of caller identification function), much as email implementations display the From field as the sender's identity.

典型的には、このURIは、アドレス・オブ・レコード要求の発信者に連絡するために参照解除することが可能です。具体的には、ユーザーが着信要求を受信するために、自社のデバイスを登録するの下で、同じアドレス・オブ・レコードが通常です。このアドレス・オブ・レコードは、アドレス・オブ・レコードのホスト部分によって識別されたドメインでのSIPサービスの管理者によって割り当てられ、維持されています。しかし、要求のFromフィールド通常のSIPユーザエージェントのユーザによって任意に設定することができます。メッセージのヘッダから発信ユーザが合法的に与えられた識別情報を請求することができることは内部の保証を提供しません。それにもかかわらず、多くのSIPユーザエージェントは、親切に多くの電子メールの実装は、送信者のIDとしてフィールドから表示として、（発信者識別機能の一種として）受信した要求の発信元のIDとしてFromフィールドの内容を表示します。

In order to provide the recipient of a SIP message with greater assurance of the identity of the sender, a cryptographic signature can be provided over the headers of the SIP request, which allows the signer to assert a verifiable identity. Unfortunately, a signature over the From header alone is insufficient because it could be cut-and-pasted into a replay or forwarding attack, and more headers are therefore needed to correlate a signature with a request. RFC 3261 therefore recommends copying all of the headers from the request into a signed MIME body; however, SIP messages can be large, and many of the headers in a SIP message would not be relevant in determining the identity of the sender or assuring reference integrity with the request, and moreover some headers may change in transit for perfectly valid reasons. Thus, this large tunneled 'message/sip' body will almost necessarily be at variance with the headers in a request when it is received by the UAS, and the burden in on the UAS to determine which header changes were legitimate, and which were security violations. It is therefore desirable to find a happy medium - to provide a way of signing just enough headers that the identity of the sender can be ascertained and correlated with the request. 'message/sipfrag' [4] provides a way for a subset of SIP headers to be included in a MIME body; the Authenticated Identity Body (AIB) format described in Section 2 is based on 'message/sipfrag'.

送信者の身元の大きな保証を有するSIPメッセージの受信者を提供するために、暗号署名は、署名者は、検証可能なアイデンティティをアサートすることを可能にするSIPリクエストのヘッダーの上に設けることができます。それはカット・アンド・ペーストし、再生又は転送攻撃に、よりヘッダは従って要求に署名を相関させるために必要とされることができるので、残念ながら、単独で、Fromヘッダを超える署名が不十分です。 RFC 3261は、したがって、署名付きMIMEボディに要求からヘッダの全てのコピーをお勧めします。しかし、SIPメッセージを大きくすることができる、およびSIPメッセージのヘッダーの多くは、送信者の身元を決定するか、要求に参照整合性を保証するには適切ではない、しかも一部のヘッダが完全に正当な理由のために輸送中に変更されることがあります。したがって、この大トンネリング 'メッセージ/ SIPの体は、ほとんど必ず、それがUASによって受信されるリクエストのヘッダー、およびUASは、ヘッダの変更が正当であったかを決定する上で負担と分散であること、およびセキュリティあったであろう違反。送信者の身元を確認し、要求を相関させることができるだけで十分なのヘッダーに署名する方法を提供すること - 幸せなメディアを見つけることが望ましいです。「メッセージ/ sipfrag」[4] MIMEボディに含まれるSIPヘッダのサブセットのための方法を提供します。第2節で説明し認証されたアイデンティティボディ（AIB）フォーマットは「メッセージ/ sipfrag」に基づいています。

For reasons of end-to-end privacy, it may also be desirable to encrypt AIBs; procedures for this encryption are given in Section 8.

エンドツーエンド・プライバシーの理由のため、またAIBsを暗号化することが望ましい場合があります。この暗号化のための手順は、セクション8に記載されています。

This document proposes that the AIB format should be used instead of the existing tunneled 'message/sip' mechanism described in RFC 3261, section 23.4, in order to provide the identity of the caller; if integrity over other, unrelated headers is required, then the 'message/sip' mechanism should be used.

この文書では、AIBフォーマットが発呼者のアイデンティティを提供するために、代わりにRFC 3261に記載され、既存のトンネリング「メッセージ/ SIP」機構、セクション23.4を使用することを提案しています。他の、無関係のヘッダ上の整合性が必要な場合は、「メッセージ/ SIP」メカニズムが使用されるべきです。

1.1. Requirements Notation

1.1. 要件表記

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[2]。

2. AIB Format

2. AIBのフォーマット

As a way of sharing authenticated identity among parties in the network, a special type of MIME body format, the Authenticated Identity Body (AIB) format, is defined in this section. AIBs allow a party in a SIP transaction to cryptographically sign the headers that assert the identity of the originator of a message, and provide some other headers necessary for reference integrity.

ネットワーク内の当事者間で認証されたアイデンティティを共有する方法として、MIMEボディフォーマットの特殊なタイプは、認証されたアイデンティティボディ（AIB）フォーマットは、このセクションで定義されています。 AIBsは、暗号メッセージの発信者の身元を主張し、ヘッダーに署名し、参照整合性のために必要ないくつかの他のヘッダを提供するために、SIPトランザクションでパーティーを許可します。

An AIB is a MIME body of type 'message/sipfrag' - for more information on constructing sipfrags, including examples, see [4]. This MIME body MUST have a Content-Disposition [3] disposition-type of 'aib', a new value defined in this document specifically for authenticated identity bodies. The Content-Disposition header SHOULD also contain a 'handling' parameter indicating that this MIME body is optional (i.e., if this mechanism is not supported by the user agent server, it can still attempt to process the request).

AIBは、タイプ「メッセージ/ sipfrag」のMIME本体である - 例を含む構築sipfrags、の詳細については、[4]を参照します。このMIMEボディは「AIB」、認証されたアイデンティティの体のために特別に、この文書で定義された新しい価値のコンテンツ処分[3]気質型を持たなければなりません。 Content-Dispositionヘッダーは、（このメカニズムはユーザエージェントサーバによってサポートされていない場合、すなわち、それはまだ要求を処理しようと試みることができる）このMIME本体がオプションであることを示す「処理」パラメータを含むべきです。

AIBs using the 'message/sipfrag' MIME type MUST contain the following headers when providing identity for an INVITE request: From, Date, Call-ID, and Contact; they SHOULD also contain the To and CSeq header. The security properties of these headers, and circumstances in which they should be used, are described in Section 10. AIBs MAY contain any other headers that help to uniquely identify the transaction or provide related reference integrity. An example of the AIB format for an INVITE is:

日付から、コールID、および連絡先を、;：INVITE要求のためのアイデンティティを提供する際に「メッセージ/ sipfrag」MIMEタイプを使用してAIBsは、以下のヘッダを含まなければなりません彼らはまた、へとのCSeqヘッダを含むべきです。セキュリティこれらのヘッダの性質、及びそれらが使用されるべき状況は、10 AIBs一意の取引を識別または関連する参照整合性を提供するのに役立つ任意の他のヘッダを含むかもしれ項に記載されています。 INVITEのためのAIBフォーマットの例を示します。

Content-Type: message/sipfrag Content-Disposition: aib; handling=optional

Content-Type：メッセージ/ sipfragのコンテンツディスポジション：AIB。取り扱い=オプション

From: Alice <sip:alice@example.com> To: Bob <sip:bob@example.net> Contact: <sip:alice@pc33.example.com> Date: Thu, 21 Feb 2002 13:02:03 GMT Call-ID: a84b4c76e66710 CSeq: 314159 INVITE

From：へ：<alice@example.com一口>：アリスボブ<一口：bob@example.net>連絡先：<SIP：alice@pc33.example.com>日付：木、2002年2月21日午前13時02分03秒GMTコールIDを：のCSeq a84b4c76e66710：314159は、INVITE

Unsigned AIBs MUST be treated by any recipients according to the rules set out in Section 7 for AIBs that do not validate. After the AIB has been signed, it SHOULD be added to existing MIME bodies in the request (such as SDP), if necessary by transitioning the outermost MIME body to a 'multipart/mixed' format.

符号なしAIBsは検証しませんAIBsについては、第7に定めるルールに従って任意の受信者によって処理されなければなりません。 AIBが署名された後、必要であれば、それは、混合/マルチパート」の形式に最も外側のMIME本体を移行することによって、要求（例えばSDPなど）に存在するMIME体に添加されるべきです。

3. Example of a Request with AIB

AIBとリクエストの3例

The following shows a full SIP INVITE request with an AIB:

以下は、完全なSIPは、AIBでINVITEリクエストを示しています。

INVITE sip:bob@example.net SIP/2.0 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 To: Bob <sip:bob@example.net> From: Alice <sip:alice@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.example.com> Content-Type: multipart/mixed; boundary=unique-boundary-1

bob@example.net SIP / 2.0経由：SIP INVITE SIP / 2.0 / UDP pc33.example.comを、ブランチ= z9hG4bKnashds8へ：ボブ<SIP：bob@example.net>から：アリス<SIP：alice@example.com >; = 1928301774のCall-IDタグ：のCSeq a84b4c76e66710：314159は、マックス・フォワードをINVITE：70日：木、2002年2月21日午後1時02分03秒GMT連絡先：<SIP：alice@pc33.example.com>のContent-Type：マルチパートを/混合; =境界ユニークな境界-1

--unique-boundary-1

--unique境界-1

Content-Type: application/sdp Content-Length: 147

コンテンツタイプ：アプリケーション/ SDPコンテンツの長さ：147

v=0 o=UserA 2890844526 2890844526 IN IP4 example.com s=Session SDP c=IN IP4 pc33.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

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

   --unique-boundary-1
   Content-Type: multipart/signed;
     protocol="application/pkcs7-signature";
     micalg=sha1; boundary=boundary42
   Content-Length: 608

--boundary42 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional

--boundary42のContent-Type：メッセージ/ sipfragのContent-処分：AIB。取り扱い=オプション

From: Alice <sip:alice@example.com> To: Bob <sip:bob@example.net> Contact: <sip:alice@pc33.example.com> Date: Thu, 21 Feb 2002 13:02:03 GMT Call-ID: a84b4c76e66710 CSeq: 314159 INVITE

--boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64

--boundary42のContent-Type：アプリケーション/ PKCS7署名。名前= smime.p7sコンテンツ転送 - エンコード：BASE64

Content-Disposition: attachment; filename=smime.p7s; handling=required

コンテンツディスポジション：添付ファイル;ファイル名= smime.p7s。ハンドリング=必要

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756

--boundary42--

--unique-boundary-1--

--unique境界-1--

4. AIBs for Identifying Third-Parties

サードパーティを識別するための4 AIBs

There are special-case uses of the INVITE method in which some SIP messages are exchanged with a third party before an INVITE is sent, and in which the identity of the third party needs to be carried in the subsequent INVITE. The details of addressing identity in such contexts are outside the scope of this document. At a high level, it is possible that identity information for a third party might be carried in a supplemental AIB. The presence of a supplemental AIB within a message would not preclude the appearance of a 'regular' AIB as specified in this document.

特殊なケースが送信され、いくつかのSIPメッセージがINVITE前に、第三者との間で交換されるINVITEメソッドを使用し、ここで、第三者の身元が、その後は、INVITEで運ばれる必要があるがあります。そのような文脈でアイデンティティを扱うの詳細は、このドキュメントの範囲外です。ハイレベルでは、サードパーティのID情報を補足AIBで運ばれるかもしれないことは可能です。この文書で指定されたメッセージ内の補足AIBの存在は、「定期的な」AIBの外観を排除するものではありません。

Example cases in which supplemental AIBs might appear include:

補足AIBsが表示される可能性のある例の場合は、次のとおりです。

The use of the REFER [5] method, for example, has a requirement for the recipient of an INVITE to ascertain the identity of the referrer who caused the INVITE to be sent.

REFER [5]の方法の使用は、例えば、送信されるINVITE引き起こさリファラの身元を確認するために、INVITEの受信者のための要件を有しています。

Third-party call control (3PCC [6]) has an even more complicated identity problem. A central controller INVITEs one party, gathers identity information (and session context) from that party, and then uses this information to INVITE another party. Ideally, the controller would also have a way to share a cryptographic identity signature given by the first party INVITEd by the controller to the second party invited by the controller.

サードパーティの呼制御（3PCC [6]）、より複雑なアイデンティティの問題を抱えています。中央制御装置は、一方の当事者を招いている相手から識別情報（およびセッションコンテキスト）を収集し、その後、別の当事者を招待し、この情報を使用します。理想的には、コントローラは、コントローラによって招か第二者へのコントローラによって招か最初のパーティによって与えられた暗号アイデンティティ署名を共有する方法を持っているでしょう。

In both of these cases, the Call-ID and CSeq of the original request (3PCC INVITE or REFER) would not correspond with that of the request in by the subsequent INVITE, nor would the To or From. In both the REFER case and the 3PCC case, the Call-ID and CSeq cannot be used to guarantee reference integrity, and it is therefore much harder to correlate an AIB to a subsequent INVITE request.

これらの場合、コールIDと元の要求のCSeqの両方で（3PCC INVITEまたはREFER）INVITE後続によって、リクエストのものと一致しないであろう、また希望にまたはから。 REFERケースと3PCCの場合の両方において、コールIDとのCSeqは、参照整合性を保証するために使用することができず、後続のINVITE要求にAIBを相関することがはるかに困難です。

Thus, in these cases some other headers might be used to provide reference integrity between the headers in a supplemental AIB with the headers of a 3PCC or REFER-generated INVITE, but this usage is outside of the scope of this document. In order for AIBs to be used in these third-party contexts, further specification work is required to determine which additional headers, if any, need to be included in an AIB in a specific third-party case, and how to differentiate the primary AIB in a message from a third-party AIB.

したがって、これらの場合にいくつかの他のヘッダは3PCCのヘッダを補足AIBのヘッダー間の参照整合性を提供したり、REFER-生成INVITEために使用されるかもしれないが、この使用は、この文書の範囲外です。 AIBsためにさらに指定作業は、追加ヘッダが、もしあれば、特定のサードパーティの場合にAIBに含まれる必要があるかを決定するために必要とされる、これらのサードパーティのコンテキストで使用されるように、どのようにプライマリAIBを区別しますサードパーティAIBからのメッセージインチ

5. Identity in non-INVITE Requests

非INVITE要求5.アイデンティティ

The requirements for populating an AIB in requests within a dialog generally parallel those of the INVITE: From, Call-ID, Date, and Contact header fields are REQUIRED.

ダイアログ内のリクエストにAIBを取り込むための要件は、一般的に、INVITEのものと平行：コールID、日付、およびContactヘッダーフィールドが要求され、より。

Some non-INVITE requests, however, may have different identity requirements. New SIP methods or extensions that leverage AIB security MUST identify any special identity requirements in the Security Considerations of their specification.

いくつかの非INVITEリクエストは、しかし、異なるIDの要件を有することができます。新しいSIPメソッドや拡張は、レバレッジAIBのセキュリティは、その仕様のセキュリティの考慮に特別アイデンティティの要件を識別しなければならないということ。

6. Identity in Responses

応答6.アイデンティティ

Many of the practices described in the preceding sections can be applied to responses as well as requests. Note that a new set of headers must be generated to populate the AIB in a response. The From header field of the AIB in the response to an INVITE MUST correspond to the address-of-record of the responder, NOT to the From header field received in the request. The To header field of the request MUST NOT be included. A new Date header field and Contact header field should be generated for the AIB in a response. The Call-ID and CSeq should, however, be copied from the request.

前のセクションで説明実践の多くは、応答、ならびに要求に適用することができます。ヘッダの新しいセットが応答でAIBを移入するために生成されなければならないことに注意してください。応答におけるAIBのヘッダフィールドからのINVITEしないFromヘッダフィールドは要求で受信し、レスポンダのアドレス・オブ・レコードに対応しなければなりません。リクエストのToヘッダーフィールドを含んではいけません。新しいDateヘッダフィールドとContactヘッダーフィールドは応答にAIBのために生成されなければなりません。コールIDとのCSeqは、しかし、要求からコピーする必要があります。

Generally, the To header field of the request will correspond to the address-of-record of the responder. In some architectures where re-targeting is used, however, this need not be the case. Some recipients of response AIBs may consider it a cause for security concern if the To header field of the request is not the same as the address-of-record in the From header field of the AIB in a response.

一般に、リクエストのヘッダにフィールドは、レスポンダのアドレス・オブ・レコードに対応することになります。再標的化が使用されるいくつかのアーキテクチャでは、しかし、そうである必要はありません。リクエストのToヘッダーフィールドは、アドレスのレコードAIBのFromヘッダーフィールドでの応答と同じではない場合、応答AIBsの一部の受信者は、セキュリティ上の懸念の原因検討することができます。

7. Receiving an AIB

AIBの受信7.

When a user agent receives a request containing an AIB, it MUST verify the signature, including validating the certificate of the signer, and compare the identity of the signer (the subjectAltName) with, in the INVITE case, the domain portion of the URI in the From header field of the request (for non-INVITE requests, other headers MAY be subject to this comparison). The two should correspond exactly; if they do not, the user agent MUST report this condition to its user before proceeding. User agents MAY distinguish between plausibly minor variations (the difference between 'example.com' and 'sip.example.com') and major variations ('example.com' vs.

ユーザエージェントは、AIBを含む要求を受信すると、署名者の証明書を検証するなど、署名を検証しなければならない、とで、INVITE場合には、URIのドメイン部分を有する署名者（のsubjectAltName）の同一性を比較しますリクエストのFromヘッダフィールド（要求非INVITEのために、他のヘッダがこの比較の対象とすることができます）。二人は正確に対応しなければなりません。そうでない場合、ユーザエージェントは、先に進む前に、そのユーザーにこの状況を報告しなければなりません。ユーザエージェントは、もっともらしく小さな変化（「example.com」と「sip.example.com」の違い）との主要なバリエーション（「example.com」対間を区別することができます

'example.org') when reporting these discrepancies in order to give the user some idea of how to handle this situation. Analysis and comparison of the Date, Call-ID, and Contact header fields as described in Section 10 MUST also be performed. Any discrepancies or violations MUST be reported to the user.

「example.org」）ユーザーにこのような状況を処理する方法のいくつかのアイデアを与えるために、これらの矛盾を報告します。項10に記載のように分析し、日付の比較、コールID、およびContactヘッダフィールドも実行しなければなりません。任意の不一致や違反は、ユーザーに報告しなければなりません。

When the originating user agent of a request receives a response containing an AIB, it SHOULD compare the identity in the From header field of the AIB of the response with the original value of the To header field in the request. If these represent different identities, the user agent SHOULD render the identity in the AIB of the response to its user. Note that a discrepancy in these identity fields is not necessarily an indication of a security breach; normal re-targeting may simply have directed the request to a different final destination. Implementors therefore may consider it unnecessary to alert the user of a security violation in this case.

要求の発信ユーザエージェントがAIBを含む応答を受信すると、要求のフィールドをヘッダーの元の値を持つレスポンスのAIBのヘッダフィールドから識別情報を比較する必要があります。これらは異なるアイデンティティを表現する場合、ユーザーエージェントは、そのユーザへの応答のAIBでのアイデンティティを表現すべきです。これらのアイデンティティの分野での不一致は必ずしもセキュリティ侵害の兆候ではないことに注意してください。通常の再標的化は、単に異なる最終的な宛先に要求を指向していることができます。実装者は、したがって、それが不要なこの場合はセキュリティ違反のユーザーに警告するために検討することができます。

8. Encryption of Identity

アイデンティティの8.暗号化

Many SIP entities that support the use of S/MIME for signatures also support S/MIME encryption, as described in RFC 3261, Section 23.4.3.

RFC 3261、セクション23.4.3で説明したように、署名のためのS / MIMEの使用をサポートする多くのSIPエンティティはまた、S / MIME暗号化をサポートしています。

While encryption of AIBs entails that only the holder of a specific key can decrypt the body, that single key could be distributed throughout a network of hosts that exist under common policies. The security of the AIB is therefore predicated on the secure distribution of the key. However, for some networks (in which there are federations of trusted hosts under a common policy), the widespread distribution of a decryption key could be appropriate. Some telephone networks, for example, might require this model.

AIBsの暗号化は、特定のキーの唯一の所有者が単一のキーが共通の方針の下に存在するホストのネットワーク全体に分散することができることを、身体を復号化できることを伴いますが。 AIBのセキュリティは、そのための鍵の安全な配布を前提としています。ただし、一部のネットワーク（ここで共通のポリシーの下で信頼されたホストの連盟がある）ため、復号鍵の広範な分布が適切であろう。いくつかの電話網は、例えば、このモデルが必要になることがあります。

When an AIB is encrypted, the AIB SHOULD be encrypted before it is signed. Implementations MUST still accept AIBs that have been signed and then encrypted.

AIBが暗号化されている場合は、それが署名される前に、AIBは暗号化されるべきです。実装はまだ署名して、暗号化されているAIBsを受け入れなければなりません。

9. Example of Encryption

暗号化の9例

The following is an example of an encrypted and signed AIB (without any of the preceding SIP headers). In a rendition of this body sent over the wire, the text wrapped in asterisks would be in ciphertext.

以下は、暗号化の一例であり、（前のSIPヘッダの任意なし）AIBに署名しました。ワイヤ上で送信され、このボディの演出では、アスタリスクに包まれたテキストは、暗号文になります。

   Content-Type: multipart/signed;
     protocol="application/pkcs7-signature";
     micalg=sha1; boundary=boundary42
   Content-Length: 568
   Content-Disposition: aib; handling=optional

--boundary42

Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m handling=required Content-Length: 231

コンテンツタイプ：アプリケーション/ PKCS7-MIME; SMIME型=エンベロープデータ。名前= smime.p7mというコンテンツ転送 - エンコード：base64でコンテンツディスポジション：添付ファイル;ファイル名= smime.p7mという扱い=必要なContent-Length：231

*********************************************************** * Content-Type: message/sipfrag * * Content-Disposition: aib; handling=optional * * * * From: sip:alice@example.com * * Call-ID: a84b4c76e66710 * * Contact: sip:alice@device21.example.com * * Date: Thu, 21 Feb 2002 13:02:03 GMT * ***********************************************************

************************************************** ********* *のContent-Type：メッセージ/ sipfrag * *コンテンツディスポジション：AIB。取り扱い=オプション* * * *から：SIP：alice@example.com * *コールIDを：a84b4c76e66710 * *お問い合わせ：SIP：alice@device21.example.com * *日付：木、2002年2月21日午後1時02分03秒GMT * ************************************************ ***********

--boundary42

Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required

コンテンツタイプ：アプリケーション/ PKCS7署名。名前= smime.p7sコンテンツ転送 - エンコード：base64でコンテンツディスポジション：添付ファイル;ファイル名= smime.p7s。ハンドリング=必要

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756

--boundary42--

10. Security Considerations

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

The purpose of an AIB is to provide an identity for the sender of a SIP message. This identity is held in the From header field of an AIB. While other headers are also included, they are provided solely to assist in detection of replays and cut-and-paste attacks leveraged to impersonate the caller. The contents of the From header field of a valid AIB are suitable for display as a "Caller ID" for the sender of the SIP message.

AIBの目的は、SIPメッセージの送信者の身元を提供することです。このIDは、AIBのFromヘッダフィールドに保持されます。他のヘッダも含まれるが、それらは単にリプレイの検出と、呼び出し元を偽装するために活用カットアンドペースト攻撃を助けるために提供されます。有効AIBのFromヘッダフィールドの内容は、SIPメッセージの送信者の「発信者ID」として表示するのに適しています。

This document mandates the inclusion of the Contact, Date, Call-ID, and From header fields within an AIB, and recommends the inclusion of CSeq and To header fields, when 'message/sipfrag' is used to represent the identity of a request's sender. If these headers are omitted, some important security properties of AIB are lost. In general, the considerations related to the inclusion of various headers in an AIB are the same as those given in RFC 3261 for

この文書では、コールID、およびAIB内のヘッダフィールドから連絡先、日付を含めることを義務付け、とのCSeqを含めることをお勧めしますと「メッセージ/ sipfragは、」リクエストの送信者の身元を表すために使用されている場合、フィールドのToヘッダー。これらのヘッダが省略されている場合は、AIBのいくつかの重要なセキュリティのプロパティが失われます。一般的には、AIBで各種ヘッダを含めることに関連する考慮事項は、は、RFC 3261に指定されたものと同じです

including headers in tunneled 'message/sip' MIME bodies (see Section 23 in particular).

トンネリング「メッセージ/ SIP」MIMEボディ（特に、セクション23を参照）ヘッダを含みます。

The From header field indicates the identity of the sender of the message; were this header to be excluded, the creator of the AIB essentially would not be asserting an identity at all. 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 follow the rules for acceptance of the Date header field in tunneled 'message/sip' requests described in RFC 3261, Section 23.4.2; this ensures that outdated AIBs will not be replayed (the suggested 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 AIBs, and MUST remember those Call-IDs for at least the duration of a single Date interval (i.e., 3600 seconds). Accordingly, if an AIB is replayed within the Date interval, receivers will recognize that it is invalid because of a Call-ID duplication; if an AIB is replayed after the Date interval, receivers will recognize that it is invalid because the Date is stale. The Contact header field is included to tie the AIB to a particular device instance that generated the request. Were an active attacker to intercept a request containing an AIB, and cut-and-paste the AIB into their own request (reusing the From, Contact, Date, and Call-ID fields that appear in the AIB), they 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.

ヘッダフィールドからのメッセージの送信者の身元を示します。このヘッダは除外された、本質的AIBの作成者は、すべてのアイデンティティを主張することはないだろう。 RFC 3261、セクション23.4.2で説明したように日付と連絡先のヘッダーには、参照整合性およびリプレイ保護を提供します。この仕様の実装は、RFC 3261で説明トンネリングされた」というメッセージ/一口の要求で日付ヘッダフィールドの受け入れ、セクション23.4.2の規則に従わなければなりません。これは時代遅れAIBsが再生されないことを確実にする（推奨間隔が日付ヘッダがメッセージの受信の3600秒以内の時間を示さなければならないということです）。また、実装はIDがコールAIBsで受信し記録しなければならない、と単一日付間隔（すなわち、3600秒）の少なくとも期間中にこれらのCall-IDを覚えておく必要があります。 AIBは、日付間隔内に再生される場合したがって、受信機は、それが理由のCall-IDの重複で無効であることを認識するであろう。 AIBは、日付のインターバルの後に再生される場合、受信機は、日付が古いので、それが無効であることを認識するだろう。 Contactヘッダーフィールドは、要求を生成した特定のデバイスインスタンスにAIBを結ぶために含まれます。 AIBを含む要求をインターセプトし、自分の要求にAIBをカット＆ペースト（から、連絡先、日付を再利用、およびCall-IDのAIBに表示されるフィールドを）するためにアクティブ攻撃だった、彼らは適格ではありませんこれらの要求は、Contactヘッダーフィールドで識別URIにルーティングされているので、と呼ばれるユーザエージェントからのSIPリクエストを受信します。

The To and CSeq header fields provide properties that are generally useful, but not for all possible applications of AIBs. If a new AIB is issued each time a new SIP transaction is initiated in a dialog, the CSeq header field provides a valuable property (replay protection for this particular transaction). If, however, one AIB is used for an entire dialog, subsequent transactions in the dialog would use the same AIB that appeared in the INVITE transaction. Using a single AIB for an entire dialog reduces the load on the generator of the AIB. The To header field usually designates the original URI that the caller intended to reach, and therefore it may vary from the Request-URI if re-targeting occurs at some point in the network. Accordingly, including the To header field in the AIB helps to identify cut-and-paste attacks in which an AIB sent to a particular destination is re-used to impersonate the sender to a different destination. However, the inclusion of the To header field probably would not make sense for many third-party AIB cases (as described in Section 4), nor is its inclusion necessary for responses.

およびのCSeqヘッダフィールドはなくAIBsのすべての可能な用途のために、一般的に有用な特性を提供します。新AIBが新しいSIPトランザクションはダイアログで開始されるたびに発行された場合、CSeqヘッダーフィールドは貴重な財産（この特定の取引のためのリプレイ保護）を提供します。しかし、1 AIBはダイアログ全体のために使用されている場合は、ダイアログ内の後続のトランザクションは、INVITEトランザクションに登場同じAIBを使用します。ダイアログ全体のための単一AIBを使用すると、AIBの発電機の負荷を軽減します。 Toヘッダフィールドは、通常、発信者が到達することを意図し、再ターゲティングは、ネットワーク内のある時点で発生した場合、したがって、それはリクエストURIから変化し得ることが、元のURIを指定します。従って、AIBでToヘッダーフィールドを含むことAIBは、特定の宛先に送信されたカットアンドペースト攻撃を識別するのに役立つ、異なる宛先に送信者を偽装するために再使用されます。しかし、Toヘッダフィールドを含めることは、おそらく（セクション4に記載されているように）多くのサードパーティAIBケースに意味をなす、また応答のために必要なその包含されないであろう。

11. IANA Considerations

11. IANAの考慮事項

This document defines a new MIME Content-Disposition disposition-type value of 'aib'. This value is reserved for MIME bodies that contain an authenticated identity, as described in section Section 2.

この文書では、「AIB」の新しいMIMEのContent-処分処分型の値を定義します。この値は、セクション、セクション2で説明したように、認証されたアイデンティティを含むMIMEボディのために予約されています。

12. References

12.参考文献

12.1. Normative References

12.1. 引用規格

[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]  Troost, R., Dorner, S., and K. Moore, "Communicating
        Presentation Information in Internet Messages: The Content-
        Disposition Header Field", RFC 2183, August 1997.

[4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.

[4]、R.、 "インターネットメディアタイプのメッセージ/ sipfrag"、RFC 3420、2002年11月スパークス。

12.2. Informative References

12.2. 参考文献

[5] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.

[5]、R.、 "セッション開始プロトコル（SIP）と呼ば-メカニズム"、RFC 3892、2004年9月スパークス。

[6] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.

[6]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロを、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）で第三者呼制御（3PCC）のベストプラクティス現在" 、2004年4月。

13. Acknowledgements

13.謝辞

The author would like to thank Robert Sparks, Jonathan Rosenberg, Mary Watson, and Eric Rescorla for their comments. Rohan Mahy also provided some valuable guidance.

作者は彼らのコメントのためにロバート・スパークス、ジョナサン・ローゼンバーグ、メアリー・ワトソン、そしてエリックレスコラに感謝したいと思います。ロハンマーイはまた、いくつかの貴重なガイダンスを提供します。

14. Author's Address

14.著者のアドレス

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/

15. Full Copyright Statement

15.完全な著作権声明

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

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/S HE 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.

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

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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

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

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。