Network Working Group K. Ono
Request for Comments: 4189 S. Tachimoto
Category: Informational NTT Corporation
October 2005
Requirements for End-to-Middle Security for
the Session Initiation Protocol (SIP)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security.
セッション開始プロトコル（SIP）ユーザエージェント（UA）は、常にそのメッセージ本体および/またはそのメッセージに含まれるヘッダを検査するために、その要求のパス内のすべての仲介を信頼していません。 UAは、その内容に基づいてサービスを提供するものを除き、仲介者からのメッセージ本文および/またはヘッダを保護することをお勧めします。この状況は、エンドツーエンドのセキュリティを妨げないUAと仲介者の間で渡される情報を、確保するために、「エンド・ツー・ミドルセキュリティ」と呼ばれる仕組みが必要です。この文書では、エンド・ツー・ミドルセキュリティを達成するためのメカニズムのための要件のセットを定義します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Use Cases .......................................................2
2.1. Examples of Scenarios ......................................2
2.2. Service Examples ...........................................4
3. Scope of End-to-Middle Security .................................6
4. Requirements for a Solution .....................................6
4.1. General Requirements .......................................6
4.2. Requirements for End-to-Middle Confidentiality .............7
4.3. Requirements for End-to-Middle Integrity ...................7
5. Security Considerations .........................................8
6. Acknowledgments .................................................9
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
The Session Initiation Protocol (SIP) [2] supports hop-by-hop security using Transport Layer Security (TLS) [3] and end-to-end security using Secure MIME (S/MIME) [4]. Use of TLS assumes that a SIP UA trusts all proxy servers along its request path to inspect the message bodies contained in the message, and use of S/MIME assumes that a SIP UA does not trust any proxy servers to do so.
[3]、エンドツーエンドのセキュリティセキュアMIME（S / MIME）を使用して、セッション開始プロトコル（SIP）[2]トランスポート層セキュリティ（TLS）を使用して、ホップバイホップセキュリティをサポートしている[4]。 TLSを使用すると、その要求のパスに沿ったすべてのプロキシサーバがメッセージに含まれるメッセージ本文を検査するSIP UA信託と仮定して、S / MIMEを使用すると、SIP UAがそうするために、任意のプロキシサーバーを信頼していないことを前提としています。
However, there is a model in which trusted and partially-trusted proxy servers are mixed along a message path. The partially-trusted proxy servers are only trusted to provide SIP routing, but these proxy servers are not trusted by users to inspect its data, except the routing headers. A hop-by-hop confidentiality service using TLS is not suitable for this model. An end-to-end confidentiality service using S/MIME is also not suitable when the intermediaries provide services based on reading the message bodies and/or headers. This problem is described in Section 23 of [2].
しかし、信頼できると部分的に信頼されたプロキシサーバがメッセージの経路に沿って混合されたモデルがあります。部分的に信頼されたプロキシサーバーのみSIPルーティングを提供するために信頼されているが、これらのプロキシサーバーは、ルーティングヘッダを除いて、そのデータを検査するために、ユーザーから信頼されていません。 TLSを使用したホップバイホップ機密性サービスは、このモデルには適していません。仲介は、メッセージ本文および/またはヘッダを読みに基づいてサービスを提供する際にS / MIMEを使用して、エンドツーエンドの機密性サービスも適していません。この問題は、[2]のセクション23に記載されています。
In some cases, a UA might want to protect its message bodies and/or headers from proxy servers along its request path, except from those that provide services based on reading its message bodies and/or headers. Conversely, a proxy server might want to view the message bodies and/or headers to sufficiently provide these services. Such proxy servers are not always the first hop from the UA. This situation requires a security mechanism to secure message bodies and/or headers between the UA and the proxy servers, while disclosing information to those that need it. We call this "end-to-middle security".
いくつかのケースでは、UAは、そのメッセージ本文および/またはヘッダを読みに基づいてサービスを提供するものから除き、その要求パスに沿ってプロキシサーバからそのメッセージの本文および/またはヘッダを保護することをお勧めします。逆に、プロキシサーバは十分にこれらのサービスを提供するために、メッセージ本文および/またはヘッダーを表示したい場合があります。このようなプロキシサーバは常にUAからの最初のホップではありません。それを必要とするものに情報を開示しながら、このような状況は、UAとプロキシサーバーの間でメッセージの本文および/またはヘッダを確保するためのセキュリティ・メカニズムが必要です。私たちは、この「エンド・ツー・ミドルセキュリティ」と呼びます。
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 RFC-2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC-2119に記載されるように解釈される[1]。
We describe here examples of scenarios in which trusted and partially-trusted proxy servers both exist in a message path. These situations demonstrate the reasons why end-to-middle security is required.
ここでは、信頼できると部分的に信頼されたプロキシサーバーの両方がメッセージパスに存在するシナリオの例を記載しています。これらの状況は、エンド・ツー・ミドルセキュリティが必要とされる理由を示しています。
In the following example, User #1 does not know the security policies or services provided by Proxy server #1 (Proxy#1). User #1 sends a MESSAGE [5] request including S/MIME-encrypted message content for end-to-end security, as shown in Figure 1, while Proxy #1 rejects the request based on its strict security policy that prohibits the forwarding of unknown data.
次の例では、ユーザ＃1は、プロキシサーバ＃1（プロキシ＃1）によって提供されるセキュリティポリシーやサービスを知っていません。プロキシ＃1の転送を禁止し、その厳密なセキュリティポリシーに基づいて、要求を拒否しながら、図1に示すように、ユーザ＃1は、エンドツーエンドのセキュリティのためのS / MIME暗号化メッセージの内容を含むメッセージ[5]要求を送信します未知のデータ。
Home network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+
User #1-----| | C |-----| [C] |-----| [C] |-----| C |-----User #2
| +-----+ +-----+ | +-----+ +-----+
| UA #1 Proxy #1 | Proxy #2 UA #2
+---------------------+
C: Content that UA #1 allows the entity to inspect [C]: Content that UA #1 prevents the entity from inspecting
C：UA＃1はエンティティが検査することを可能にするコンテンツ[C]：UA＃1は検査からエンティティを防止するコンテンツ
Figure 1: Deployment example #1
図1：展開例＃1
In the second example, Proxy server #1 is the home proxy server of User #1 using UA #1. User #1 communicates with User #2 through Proxy #1 and Proxy #2, as shown in Figure 2. Although User #1 already knows Proxy #1's security policy, which requires the inspection of the content of the MESSAGE request, User #1 does not know whether Proxy #2 is trustworthy, and thus wants to protect the message bodies in the request. To accomplish this, UA #1 will need to be able to grant a trusted intermediary (Proxy #1) to inspect message bodies, while preserving their confidentiality from other intermediaries (Proxy #2).
2番目の例では、プロキシサーバ＃1は、UA＃1を使用してユーザ＃1のホームプロキシサーバーです。ユーザ＃1が既にMESSAGE要求の内容の検査を必要とするプロキシ＃1のセキュリティポリシー、ユーザ＃1を知っているが、図2に示すように、ユーザ＃1は、プロキシ＃1とプロキシ＃2を介してユーザ＃2と通信しますプロキシ＃2が信頼できるので、リクエストにメッセージ本体を保護するために望んでいるかどうか分かりません。これを実現するために、UA＃1は、（プロキシ＃2）他の仲介から自分の機密性を維持しながら、（プロキシ＃1）、メッセージ本文を検査する信頼できる仲介を付与することができるようにする必要があります。
Even if UA #1's request message authorizes Proxy #1 to inspect the message bodies, UA #1 is unable to authorize the same proxy server to inspect the message bodies in subsequent MESSAGE requests from UA #2.
UA＃1の要求メッセージは、メッセージ本文を検査するプロキシ＃1を承認した場合でも、UA＃1はUA＃2からの後続MESSAGEリクエストでメッセージ本文を検査するために同じプロキシサーバーを承認することができません。
Home network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+
User #1-----| | C |-----| C |-----| [C] |-----| C |----- User #2
| +-----+ +-----+ | +-----+ +-----+
| UA #1 Proxy #1 | Proxy #2 UA #2
+---------------------+
C: Content that UA #1 needs to disclose [C]: Content that UA #1 needs to protect
C：[C]を開示するUA＃1ニーズ内容：UA＃1ニーズを保護するために、コンテンツ
Figure 2: Deployment example #2
図2：展開の例＃2
In the third example, User #1 connects UA #1 to a proxy server in a visited (potentially insecure) network, e.g., a hotspot service or a roaming service. Since User #1 wants to utilize certain home network services, UA #1 connects to a home proxy server, Proxy #1. However, UA #1 must connect to Proxy #1 via the proxy server of the visited network (Proxy A), because User #1 must follow the policy of that network. Proxy A performs access control based on the destination addresses of calls. User #1 only trusts Proxy A to route requests, not to inspect the message bodies the requests contain, as shown in Figure 3. User #1 trusts Proxy #1 both to route the requests and to inspect the message bodies.
第3の例では、ユーザ＃1は、訪問先（潜在的に安全でない）ネットワーク、例えば、ホットスポットサービスまたはローミングサービスのプロキシサーバへUA＃1とを接続します。ユーザ＃1は、特定のホームネットワークサービスを利用したいので、UA＃1は、ホームプロキシサーバー、プロキシ＃1に接続します。ユーザ＃1は、そのネットワークの方針に従わなければならないためしかし、UA＃1は、訪問先ネットワーク（プロキシA）のプロキシサーバを経由してプロキシ＃1に接続する必要があります。プロキシAは、コールの宛先アドレスに基づいてアクセス制御を行います。ユーザ＃1は、要求はプロキシ＃1は、要求の両方の経路に図3ユーザ＃1信託に示すように、含み、メッセージボディを検査するためにメッセージ本文を検査するのではなく、ルート要求にプロキシAを信頼します。
The same problems as in the second example also exist here.
第二の例の場合と同様の問題がここにも存在します。
Visited network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+ +-----+
User #1 -- | | C |-----| [C] |-----| C |-----| [C] |-----| C |
| +-----+ +-----+ | +-----+ +-----+ +-----+
| UA #1 Proxy A | Proxy #1 Proxy #2 UA #2
+---------------------+
C: Content that UA #1 needs to disclose [C]: Content that UA #1 needs to protect
C：[C]を開示するUA＃1ニーズ内容：UA＃1ニーズを保護するために、コンテンツ
Figure 3: Deployment example #3
図3：展開例＃3
We describe here several services that require end-to-middle security.
ここでは、エンド・ツー・ミドルセキュリティを必要とするいくつかのサービスについて説明します。
Logging Services are provided by the archiving function, which is located in the proxy server, that logs the message content exchanged between UAs. The archiving function could be located at the originator network and/or the destination network. When the content of an instant message contains private information, UACs (UA Clients) encrypt the content for the UASes (UA Servers). The archiving function needs to log the content in a message body in bidirectional MESSAGE requests in such a way that the data is decipherable. The archiving function also needs a way to verify the data integrity of the content before logging.
ロギングサービスは、ユーザーエージェントの間で交換メッセージの内容をログに記録し、プロキシサーバに位置するアーカイブ機能によって提供されます。アーカイブ機能は、発信ネットワーク及び/又は宛先ネットワークに配置することができます。インスタントメッセージの内容は、個人情報が含まれている場合、求めるUAC（UAクライアント）がUASes（UAサーバー）のコンテンツを暗号化します。アーカイブ機能は、データが解読されるように双方向MESSAGE要求でメッセージ本文の内容をログに記録する必要があります。アーカイブ機能もログインする前に、コンテンツのデータの整合性を検証する方法が必要です。
This service might be deployed in financial networks, health care service provider's networks, as well as other networks in which archiving communication is required by their security policies.
このサービス金融ネットワークで展開されるかもしれない、ヘルスケアサービスプロバイダのネットワークだけでなく、アーカイブ通信は、セキュリティポリシーによって必要とされる他のネットワーク。
The Location Object [6] includes a person's geographical location information that is privacy-sensitive. Some proxy servers will have the ability to provide routing based on the geographical location information. When UAs want to employ location-based routing in non-emergency situations, the UAs need to connect to the proxy servers with such a capability and disclose the geographical location information contained in the message body of the INVITE request, while protecting it from other proxy servers along the request path. The Location Object also needs to be verified for data integrity by the proxy servers before location-based routing is applied. Sometimes the UACs want to send the Location Object to the UASes. This is another good example that presents the need for UACs to simultaneously send secure data to a proxy server and to the UASes.
Locationオブジェクトは、[6]プライバシーに敏感な人の地理的位置情報を含んでいます。プロキシサーバーは、地理的位置情報に基づいてルーティングを提供する能力を持つことになります。 UAが非緊急事態におけるロケーションベースのルーティングを採用したい場合は、他のプロキシからそれを保護しながら、UAは、このような機能をプロキシサーバに接続し、INVITE要求のメッセージボディに含まれている地理的位置情報を開示する必要があります要求パスに沿っサーバ。 Locationオブジェクトは、ロケーションベースのルーティングが適用される前に、プロキシサーバによるデータの整合性を検証する必要があります。時には求めるUACはUASesにLocationオブジェクトを送りたいです。これが求めるUACが同時にプロキシサーバへとUASesへの安全なデータを送信するための必要性を提示し、別の良い例です。
The Authenticated Identity Bodies (AIBs) [7] is a digitally-signed data that is used for identifying users. Proxy servers that need to authenticate a user, verify the signature. When the originator needs anonymity, the user identity in the AIB is encrypted before being signed. Proxy servers that authenticate the user need to decrypt the body in order to view the user identity in the AIB. Such proxy servers can be located adjacently and/or non-adjacently to the UA.
認証されたアイデンティティボディ（AIBs）[7]ユーザーを識別するために使用されるデジタル署名データです。ユーザーを認証する必要があるプロキシサーバは、署名を検証します。発信者が匿名性を必要とする場合、AIBでのユーザーIDは、署名される前に暗号化されます。ユーザーを認証プロキシサーバーは、AIBでのユーザーIDを表示するために身体を解読する必要があります。このようなプロキシサーバはUAに隣接および/または非隣接配置することができます。
The AIB could be included in all request/response messages. The proxy server needs to view it in request messages in order to authenticate users. Another proxy server sometimes needs to view it in response messages for user authentication.
AIBは、すべての要求/応答メッセージに含めることができます。プロキシサーバーは、ユーザーを認証するために要求メッセージで表示する必要があります。別のプロキシサーバは、時々、ユーザ認証用の応答メッセージで表示する必要があります。
User authentication data for HTTP Digest authentication [8] includes potentially private information, such as a user name. The user authentication data can be set only in a SIP header of request messages. This information needs to be transmitted securely to servers that authenticate users, located either adjacently and/or non-adjacently to the UA.
HTTPダイジェスト認証のためのユーザ認証データ[8]ユーザ名などの潜在的に個人情報を含んでいます。ユーザ認証データは、要求メッセージのSIPヘッダに設定することができます。この情報は、UAのいずれかに隣接して、および/または非隣接位置するユーザを認証サーバに安全に送信する必要があります。
Firewall traversal is an example of services based on media information in a message body, such as the Session Description Protocol (SDP) [9]. A firewall entity that supports the SIP protocol, or a midcom [10] agent co-located with a proxy server,
ファイヤウォールトラバーサルは、セッション記述プロトコル（SDP）などのメッセージ本体内のメディア情報に基づいて、サービスの例である[9]。 SIPプロトコル、またはMIDCOMをサポートするファイアウォールエンティティ[10]エージェント、プロキシサーバと同じ場所に配置
controls a firewall based on the address and port information of media streams in the SDP offer/answer. The address and port information in the SDP needs to be transmitted securely to recipient UAs and the proxy server operating as a midcom agent. Therefore, there is a need for a proxy server to be able to decrypt the SDP, as well as to verify the integrity of the SDP.
SDPオファー/アンサー内のメディア・ストリームのアドレスとポート情報に基づいてファイアウォールを制御します。 SDP内のアドレスとポート情報は、受信者UAとMIDCOMエージェントとして動作するプロキシサーバに安全に送信される必要があります。そのため、プロキシサーバは、SDPを復号化するだけでなく、SDPの整合性を検証することができるようにするための必要性があります。
When the SDP includes key parameters for Secure RTP (SRTP) [11], the key parameters need to be encrypted only for end-to-end confidentiality.
SDPは、セキュアRTP（SRTP）[11]のための重要なパラメータが含まれている場合、重要なパラメータは、エンドツーエンドの機密性のために暗号化される必要があります。
End-to-middle security consists of user authentication, data integrity, and data confidentiality. Providing data integrity requires authenticating peer who creates the data. However, this document only describes requirements for data confidentiality and data integrity, since end-to-middle authentication is covered by existing mechanisms such as HTTP Digest authentication, S/MIME Cryptographic Message Syntax (CMS) SignedData body [12], or an AIB.
エンド・ツー・ミドルセキュリティは、ユーザー認証、データの整合性、およびデータの機密性から構成されています。データの整合性を提供することで、データを作成し、ピアの認証が必要です。エンド・ツー・ミドル認証は、このようなHTTPダイジェスト認証、S / MIME暗号メッセージ構文（CMS）のSignedData体[12]、またはAIBなどの既存のメカニズムによって覆われているので、この文書のみ、データの機密性とデータ整合性のための要件を記述する。
As for data integrity, the CMS SignedData body can be used for verification of the data integrity and authentication of the signer by any entities. The CMS SignedData body can be used for end-to-middle security and end-to-end security simultaneously. However, a proxy server generally does not verify the data integrity using the CMS SignedData body, and there is no way for a UA to request the proxy server to verify the message. Therefore, some new mechanisms are needed to achieve data integrity for end-to-middle security.
データの整合性については、CMSのSignedDataボディは、任意のエンティティによって署名者のデータ整合性と認証の検証のために使用することができます。 CMSのSignedData体は同時に、エンド・ツー・ミドルセキュリティとエンドツーエンドのセキュリティのために使用することができます。しかし、プロキシサーバは、一般的にCMSのSignedDataボディを使用して、データの整合性を検証しないと、UAがメッセージを確認するためにプロキシサーバーを要求するための方法はありません。そのため、いくつかの新しいメカニズムは、エンド・ツー・ミドルセキュリティのためのデータの整合性を達成するために必要とされています。
This document mainly discusses requirements for data confidentiality and the integrity of end-to-middle security.
このドキュメントでは、主にデータの機密性とエンド・ツー・ミドルセキュリティの整合性のための要件について説明します。
We describe here requirements for a solution. The requirements are mainly applied during the phase of a dialog creation or sending a MESSAGE request.
ここでは解決のための要件について説明します。要件は、主に、ダイアログ作成またはMESSAGEリクエストを送信する段階中に適用されます。
The following are general requirements for end-to-middle confidentiality and integrity.
以下のエンド・ツー・ミドル機密性と完全性についての一般的な要件です。
REQ-GEN-1: The solution SHOULD have little impact on the way a UA handles S/MIME-secured messages.
REQ-GEN-1：ソリューションは、UAは、S / MIMEで保護されたメッセージを処理する方法にはほとんど影響を持っているべきです。
REQ-GEN-2: It SHOULD NOT have an impact on proxy servers that do not provide services based on S/MIME-secured bodies in terms of handling the existing SIP headers.
REQ-GEN-2：これは、既存のSIPヘッダを処理するという点でS / MIMEで保護されたボディに基づいてサービスを提供していないプロキシサーバに影響を持つべきではありません。
REQ-GEN-3: It SHOULD NOT violate the standardized mechanism of proxy servers in terms of handling message bodies.
REQ-GEN-3：これは、メッセージ本文を扱うという点で、プロキシサーバの標準化されたメカニズムに違反すべきではありません。
REQ-GEN-4: It SHOULD allow a UA to discover security policies of proxy servers. Security policies imply what data is needed to disclose and/or verify in a message.
REQ-GEN-4：それはUAがプロキシサーバのセキュリティポリシーを発見できるようにする必要があります。セキュリティポリシーは、データの開示および/またはメッセージに検証するために必要なものを暗示します。
This requirement is necessary when the UA does not know
statically which proxy servers or domains need
disclosing data and/or verification.
REQ-CONF-1: The solution MUST allow encrypted data to be shared with the recipient UA and a proxy server, when a UA wants.
REQ-CONF-1：ソリューションは、UAが望む時に暗号化されたデータは、受信者UAとプロキシサーバと共有することを許可する必要があります。
REQ-CONF-2: It MUST NOT violate end-to-end encryption when the encrypted data does not need to be shared with any proxy servers.
REQ-CONF-2：暗号化されたデータは、任意のプロキシサーバと共有する必要がない場合それは、エンドツーエンドの暗号化に違反してはなりません。
REQ-CONF-3: It SHOULD allow a UA to request a proxy server to view specific message bodies. The request itself SHOULD be secure; namely it SHOULD be authenticated for the UA and verified for the data integrity.
REQ-CONF-3：それはUAが特定のメッセージ本文を表示するために、プロキシサーバーを要求できるようにする必要があります。要求自体が安全でなければなりません。つまりそれは、UAのために、認証とデータの整合性のために確認する必要があります。
REQ-CONF-4: It MAY allow a UA to request that the recipient UA disclose information to the proxy server to which the requesting UA is initially disclosing information. The request itself SHOULD be secure; namely it SHOULD be authenticated for the UA and verified for the data integrity.
REQ-CONF-4：それはUAが受信者UAが要求するUAは、最初に情報を開示されているプロキシサーバに情報を開示することを要求することを可能にします。要求自体が安全でなければなりません。つまりそれは、UAのために、認証とデータの整合性のために確認する必要があります。
This requirement is necessary when a provider
operating the proxy server allows its security
policies to be revealed to the provider serving the
recipient UA.
This section enumerates the requirements for the end-to-middle integrity. Verifying the data integrity requires checking that the data is created by the authenticated user and not forged by a malicious user. Therefore, verification of the data integrity requires the user authentication.
このセクションでは、エンド・ツー・ミドル整合性の要件を列挙します。データの整合性を検証することは、データが認証されたユーザによって作成され、悪意あるユーザによって偽造されていないことを確認する必要があり。そのため、データの整合性の検証は、ユーザー認証が必要です。
REQ-INT-1: The solution SHOULD work even when the SIP end-to-end authentication and integrity services are enabled.
REQ-INT-1：ソリューションは、SIPエンドツーエンドの認証と完全性サービスが有効になっている場合でも動作するはずです。
REQ-INT-2: It SHOULD allow a UA to request a proxy server to verify specific message bodies and authenticate the user. The request itself SHOULD be secure; namely it SHOULD be authenticated for the UA and verified for the data integrity.
REQ-INT-2：それはUAが特定のメッセージ本文を検証し、ユーザーを認証するために、プロキシサーバーを要求できるようにする必要があります。要求自体が安全でなければなりません。つまりそれは、UAのために、認証とデータの整合性のために確認する必要があります。
REQ-INT-3: It SHOULD allow a UA to request the recipient UA to send the verification data of the same information that the requesting UA is providing to the proxy server. The request itself SHOULD be secure; namely it SHOULD be authenticated for the UA and verified for the data integrity.
REQ-INT-3：それはUAが要求するUAがプロキシサーバーに提供されているのと同じ情報の検証データを送信するために、受信者UAを要求できるようにする必要があります。要求自体が安全でなければなりません。つまりそれは、UAのために、認証とデータの整合性のために確認する必要があります。
This requirement is necessary when a provider operating
the proxy server allows its security policies to be
revealed to the provider serving the recipient UA.
This document describes the requirements for confidentiality and integrity between a UA and a proxy server. Although this document does not cover any requirements for authentication, verifying the data integrity requires peer authentication. Also, peer authentication is important in order to prevent attacks from malicious users and servers.
この文書では、UAとプロキシサーバー間の機密性と完全性の要件について説明します。このドキュメントは、認証のための任意の要件をカバーしていませんが、データの整合性を検証することは、ピア認証が必要です。また、ピア認証は、悪意のあるユーザーやサーバーからの攻撃を防ぐために重要です。
The end-to-middle security requires additional processing on message bodies, such as unpacking MIME structure, data decryption, and/or signature verification to proxy servers. Therefore, the proxy servers that enable end-to-middle security are vulnerable to a Denial-of-Services attack. A threat model is where a malicious user sends many complicated-MIME-structure messages to a proxy server, containing user authentication data obtained by eavesdropping. Another threat model is where a malicious proxy server sends many complicated-MIME-structure messages to a proxy server, containing the source IP address and the Via header of an adjacent proxy server. These attacks will slow down the overall performance of target proxy servers.
エンド・ツー・ミドルセキュリティは、プロキシサーバへアンパックMIME構造、データの復号化、及び/又は署名検証としてメッセージ本文、上で追加の処理を必要とします。そのため、エンド・ツー・ミドルセキュリティを有効にプロキシサーバは、拒否のサービス攻撃に対して脆弱です。悪意のあるユーザーが盗聴によって得られたユーザ認証データを含む、プロキシサーバに多くの複雑な-MIME-構造メッセージを送信場所脅威モデルです。悪意のあるプロキシサーバが送信元IPアドレスと、隣接するプロキシサーバのViaヘッダを含む、プロキシサーバに多くの複雑な-MIME-構造メッセージを送信ところ、別の脅威モデルです。これらの攻撃は、ターゲットプロキシサーバーの全体的なパフォーマンスが低下します。
To prevent these attacks, user and server authentication mechanisms need to be protected against replay attacks, or the user and server authentication always need to be executed simultaneously with protection of data integrity. In order to prevent these attacks, the following requirements should be met.
これらの攻撃を防ぐために、ユーザーとサーバーの認証メカニズムは、リプレイ攻撃から保護する必要がある、またはユーザーとサーバーの認証は、常にデータの整合性を保護すると同時に実行する必要があります。これらの攻撃を防ぐために、次の要件を満たす必要があります。
o The solution MUST support mutual authentication, data confidentiality, and data integrity protection between a UA and a proxy server.
Oソリューションは、UAとプロキシサーバ間の相互認証、データの機密性、およびデータ整合性の保護をサポートしなければなりません。
o It SHOULD support protection against a replay attack for user authentication.
Oこれは、ユーザー認証のためのリプレイ攻撃に対する保護をサポートする必要があります。
o It SHOULD simultaneously support user authentication and data integrity protection.
Oそれは同時に、ユーザー認証とデータ整合性保護をサポートする必要があります。
These last two requirements are met by HTTP Digest
authentication.
o It MUST support mutual authentication, data confidentiality, and data integrity protection between proxy servers.
Oそれは、相互認証、データの機密性、およびプロキシサーバ間でデータの整合性保護をサポートしなければなりません。
o It SHOULD support protection against a replay attack for server authentication.
Oこれは、サーバー認証のリプレイ攻撃に対する保護をサポートする必要があります。
o It SHOULD simultaneously support server authentication and data integrity protection.
Oそれは同時に、サーバ認証とデータ整合性保護をサポートする必要があります。
These last three requirements are met by TLS.
これらの最後の3つの要件は、TLSによって満たされます。
The authors would like to thank to Rohan Mahy and Cullen Jennings for their initial support of this concept, and to Jon Peterson, Gonzalo Camarillo, Sean Olson, Mark Baugher, Mary Barnes, and others for their reviews and constructive comments.
著者は、この概念の彼らの初期のサポートのため、およびジョンピーターソン、ゴンサロ・カマリロ、ショーン・オルソン、マーク・Baugher、メアリー・バーンズ、そして彼らのレビューと建設的なコメントのために他の人にロハンマーイとカレン・ジェニングスに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] 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.
[2]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[4] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[4] Ramsdell、B.は、RFC 3850、2004年7月 "/多目的インターネットメール拡張（S / MIME）バージョン3.1証明書の処理を固定します"。
[5] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[5]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[6] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, October 2005.
[6]ピーターソン、J.、 "プレゼンスベースGEOPRIVロケーション・オブジェクト・フォーマット"、RFC 4119、2005年10月。
[7] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[7]ピーターソン、J.、 "セッション開始プロトコル（SIP）認証済みアイデンティティボディ（AIB）フォーマット"、RFC 3893、2004年9月。
[8] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[8]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[9] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[9]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[10] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[10] Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリター、A.、およびA. Rayhan、 "ミドル通信アーキテクチャおよびフレームワーク"、RFC 3303、2002年8月。
[11] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[11] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[12] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[12] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
Authors' Addresses
著者のアドレス
Kumiko Ono Network Service Systems Laboratories NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan
くみこ おの ねとぉｒｋ せｒゔぃせ Ｓｙｓてｍｓ ぁぼらとりえｓ んっｔ こｒぽらちおん ９ー１１、 みどりーちょ ３ーちょめ むさしのーし、 ときょ １８０ー８５８５ じゃぱん
EMail: ono.kumiko@lab.ntt.co.jp, kumiko@cs.columbia.edu
電子メール：ono.kumiko@lab.ntt.co.jp、kumiko@cs.columbia.edu
Shinya Tachimoto Network Service Systems Laboratories NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan
しにゃ たちもと ねとぉｒｋ せｒゔぃせ Ｓｙｓてｍｓ ぁぼらとりえｓ んっｔ こｒぽらちおん ９ー１１、 みどりーちょ ３ーちょめ むさしのーし、 ときょ １８０ー８５８５ じゃぱん
EMail: tachimoto.shinya@lab.ntt.co.jp
メールアドレス：tachimoto.shinya@lab.ntt.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。