[要約] RFC 4189は、セッション開始プロトコル（SIP）のエンドツーミドルセキュリティの要件を定義しています。このRFCの目的は、SIPセッションのセキュリティを確保するためのガイドラインを提供することです。
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)
セッション開始プロトコル（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).
Copyright（c）The Internet Society（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.
セッション開始プロトコル（SIP）[2]は、Transport Layer Security（TLS）[3]を使用したホップバイホップセキュリティと、Secure MIME（S/MIME）[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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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に示すように、エンドツーエンドのセキュリティ用の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
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は、図2に示すように、プロキシ＃1およびプロキシ＃2を介してユーザー＃2と通信します。ユーザー＃1は、メッセージ要求のコンテンツの検査を必要とするプロキシ＃1のセキュリティポリシーを既に知っていますが、ユーザー＃1プロキシ＃2が信頼できるかどうかはわかりません。したがって、リクエストでメッセージ本文を保護したいと考えています。これを達成するために、UA＃1は、他の仲介者からの機密性を維持しながら、メッセージ本文を検査するために信頼できる仲介者（プロキシ＃1）を付与できる必要があります（プロキシ＃2）。
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からの後続のメッセージリクエストでメッセージボディを検査するために同じプロキシサーバーを承認することができません。
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
Figure 2: Deployment example #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.
図2：展開の例＃2 3番目の例では、ユーザー＃1は、訪問された（潜在的に不安定な）ネットワーク、たとえばホットスポットサービスやローミングサービスのプロキシサーバーにUA＃1を接続します。ユーザー＃1は特定のホームネットワークサービスを利用したいため、UA＃1はホームプロキシサーバー、プロキシ＃1に接続します。ただし、UA＃1は、ユーザー＃1がそのネットワークのポリシーに従う必要があるため、訪問ネットワークのプロキシサーバー（プロキシA）を介してプロキシ＃1に接続する必要があります。プロキシAは、通話の宛先アドレスに基づいてアクセス制御を実行します。ユーザー＃1は、図3に示すように、リクエストに含まれるメッセージ本文を検査するのではなく、プロキシAをルーティングするためにプロキシAのみを信頼します。
The same problems as in the second example also exist here.
2番目の例と同じ問題もここに存在します。
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
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.
ロギングサービスは、UAS間で交換されるメッセージコンテンツをログに記録するプロキシサーバーにあるアーカイブ機能によって提供されます。アーカイブ機能は、オリジネーターネットワークおよび/または宛先ネットワークに配置できます。インスタントメッセージのコンテンツに個人情報が含まれている場合、UACS（UAクライアント）はUASE（UAサーバー）のコンテンツを暗号化します。アーカイブ関数は、データが解読可能であるように、双方向のメッセージ要求でメッセージ本文にコンテンツをログに記録する必要があります。アーカイブ機能には、ロギング前にコンテンツのデータ整合性を検証する方法も必要です。
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.
ロケーションオブジェクト[6]には、プライバシーに敏感な人の地理的位置情報が含まれています。一部のプロキシサーバーは、地理的位置情報に基づいてルーティングを提供する機能を備えています。UASが非緊急状況でロケーションベースのルーティングを採用したい場合、UASはそのような機能を使用してプロキシサーバーに接続し、招待要求のメッセージ本文に含まれる地理的位置情報を開示する必要があります。要求パスに沿ったサーバー。また、ロケーションベースのルーティングが適用される前に、プロキシサーバーによるデータの整合性のために位置オブジェクトを検証する必要があります。時々、UACSはロケーションオブジェクトをUASESに送信したい場合があります。これは、UACがプロキシサーバーとUASEに同時にセキュアデータを送信する必要性を提示するもう1つの良い例です。
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 Digest Authentication [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, 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）[9]など、メッセージ本文のメディア情報に基づいたサービスの例です。SIPプロトコルをサポートするファイアウォールエンティティ、またはプロキシサーバーと共同で共同主催されるMidcom [10]エージェントは、SDPオファー/回答のメディアストリームのアドレスとポート情報に基づいてファイアウォールを制御します。SDPのアドレスとポート情報は、受信者UASおよび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にSecure 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 Body、または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.
ここでは、ソリューションの要件について説明します。要件は、主にダイアログ作成のフェーズまたはメッセージリクエストの送信中に適用されます。
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.
この要件は、UAがどのプロキシサーバーまたはドメインがデータや検証の開示を必要とするかを静的に知らない場合に必要です。
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：Requirement 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.
この要件は、プロキシサーバーを操作するプロバイダーが、受信者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に、Requireming 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.
この要件は、プロキシサーバーを操作するプロバイダーが、受信者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アドレスと隣接するプロキシサーバーのヘッダーを含む多くの複雑な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.
これらの最後の2つの要件は、HTTPダイジェスト認証によって満たされます。
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.
著者は、このコンセプトの最初のサポートについて、Rohan MahyとCullen Jenningsに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3] Dierks、T。およびC. Allen、「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。、「セキュア/多目的インターネットメール拡張機能（S/MIME）バージョン3.1証明書処理」、RFC 3850、2004年7月。
[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] Campbell、B.、Rosenberg、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] Peterson、J。、「セッション開始プロトコル（SIP）認証IDボディ（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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本およびダイジェストアクセス認証」、RFC 2617、1999年6月。
[9] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[9] Handley、M。and 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.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「Middlebox Communication Architecture and Framework」、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.、McGrew、D.、Naslund、M.、Carrara、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
小野小野ネットワークサービスシステム研究所NTT Corporation 9-11、Midori-Cho 3-Chome Musashino-Shi、東京180-8585日本
EMail: 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
Tachimoto Network Service Systems Laboratories NTT Corporations 9-11、Midori-Cho 3-Chome Musashino-Shi、東京180-8585 Japan
EMail: tachimoto.shinya@lab.ntt.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。