RFC4189 日本語訳
4189 Requirements for End-to-Middle Security for the SessionInitiation Protocol (SIP). K. Ono, S. Tachimoto. October 2005. (Format: TXT=25842 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Ono
Request for Comments: 4189 S. Tachimoto
Category: Informational NTT Corporation
October 2005
コメントを求めるワーキンググループK.小野の要求をネットワークでつないでください: 4189秒間Tachimotoカテゴリ: 情報のNTT社の2005年10月
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).
Copyright(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.
Session Initiationプロトコル(SIP)ユーザエージェント(UA)は、要求経路のすべての仲介者がメッセージに含まれたメッセージ本体、そして/または、ヘッダーを点検するといつも信じるというわけではありません。 UAは仲介者からメッセージ本体、そして/または、ヘッダーを保護したがっているかもしれません、内容に基づくサービスを提供するものを除いて。 この状況は終わりから終わりへのセキュリティを妨げないUAと仲介者の間で通過された情報を保証するために「終わりから中央へのセキュリティ」と呼ばれるメカニズムを必要とします。 このドキュメントはメカニズムが終わりから中央へのセキュリティを実現するという1セットの要件を定義します。
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
1. 序論…2 1.1. このドキュメントで中古のコンベンション…2 2. ケースを使用してください…2 2.1. シナリオに関する例…2 2.2. 例を修理してください…4 3. 終わりから中央へのセキュリティの範囲…6 4. ソリューションのための要件…6 4.1. 一般要件…6 4.2. 終わりから中央への秘密性のための要件…7 4.3. 終わりから中央への保全のための要件…7 5. セキュリティ問題…8 6. 承認…9 7. 参照…9 7.1. 標準の参照…9 7.2. 有益な参照…9
Ono & Tachimoto Informational [Page 1] RFC 4189 End-to-Middle Security Requirements October 2005
[1ページ]RFC4189終わりから中央へのセキュリティ要件2005年10月の情報の小野とTachimoto
1. Introduction
1. 序論
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.
Session Initiationプロトコル(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とプロキシサーバの間のメッセージ本体、そして/または、ヘッダーを固定するためにそれを必要とするものに情報を開示している間、セキュリティー対策を必要とします。 私たちは、これを「終わりから中央へのセキュリティ」と呼びます。
1.1. Conventions Used in This Document
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 RFC-2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC-2119[1]で説明されるように本書では解釈されることであるべきですか?
2. Use Cases
2. ケースを使用してください。
2.1. Examples of Scenarios
2.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.
私たちはここで信じられて部分的に信じられたプロキシサーバがメッセージ経路にともに存在するシナリオに関する例について説明します。 これらの状況は終わりから中央へのセキュリティが必要である理由を示します。
Ono & Tachimoto Informational [Page 2] RFC 4189 End-to-Middle Security Requirements October 2005
[2ページ]RFC4189終わりから中央へのセキュリティ要件2005年10月の情報の小野とTachimoto
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.
以下の例では、User#1はProxyサーバ#1つ(プロキシ#1)提供された安全保障政策かサービスを知りません。 ユーザ#1は終わりから終わりへのセキュリティのためのMIME S/暗号化メッセージ内容を含むMESSAGE[5]要求を送ります、図1に示されるように、Proxy#1、は未知のデータの推進を禁止する厳しい安全保障政策に基づく要求を拒絶しますが。
Home network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+
User #1-----| | C |-----| [C] |-----| [C] |-----| C |-----User #2
| +-----+ +-----+ | +-----+ +-----+
| UA #1 Proxy #1 | Proxy #2 UA #2
+---------------------+
ホームネットワーク+---------------------+ | +-----+ +-----+ | +-----+ +-----+ ユーザ#1-----| | C|-----| [C]|-----| [C]|-----| C|-----ユーザ#2| +-----+ +-----+ | +-----+ +-----+ | UA#1プロキシ#1| プロキシ#2UA#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番目の例では、Proxyサーバ#1はUA#1を使用するUser#1のホームプロキシサーバです。 ユーザ#1は図2に示されるようにProxy#1とProxy#2を通してUser#2とコミュニケートします。 User#1は既に、Proxy#1安全保障政策(MESSAGE要求の内容の点検を必要とする)を知りますが、User#1は、Proxy#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要求メッセージが、Proxy#1がメッセージ本体を点検するのを認可しても、UA#1は、同じプロキシサーバがUA#2からのその後のMESSAGE要求でメッセージ本体を点検するのを認可できません。
Home network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+
User #1-----| | C |-----| C |-----| [C] |-----| C |----- User #2
| +-----+ +-----+ | +-----+ +-----+
| UA #1 Proxy #1 | Proxy #2 UA #2
+---------------------+
ホームネットワーク+---------------------+ | +-----+ +-----+ | +-----+ +-----+ ユーザ#1-----| | C|-----| C|-----| [C]|-----| C|----- ユーザ#2| +-----+ +-----+ | +-----+ +-----+ | UA#1プロキシ#1| プロキシ#2UA#2+---------------------+
C: Content that UA #1 needs to disclose [C]: Content that UA #1 needs to protect
C: UA#1が[C]を明らかにするために必要とする内容: UA#1、が保護する必要がある内容
Figure 2: Deployment example #2
図2: 展開例#2
Ono & Tachimoto Informational [Page 3] RFC 4189 End-to-Middle Security Requirements October 2005
[3ページ]RFC4189終わりから中央へのセキュリティ要件2005年10月の情報の小野とTachimoto
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番目の例では、User#1は例えば訪問された(潜在的に不安定な)ネットワークにおける1対UA#1プロキシサーバ、ホットスポットサービスまたはローミング・サービスを接続します。 あるホームネットワークサービスを利用するUser#1必需品以来、UA#1はホームプロキシサーバ、Proxy#1、に接続します。 しかしながら、UA#1は訪問されたネットワーク(プロキシA)のプロキシサーバでProxy#1に接続しなければなりません、User#1がそのネットワークの方針に従わなければならないので。 プロキシAは呼び出しの送付先アドレスに基づくアクセスコントロールを実行します。 ユーザ#1は要求が含むメッセージ本体を点検しないようにルート要求にProxy Aを任せるだけです、図3に示されるように。 ユーザ#1は、ともに要求を発送して、メッセージ本体を点検するためにProxy#1を信じます。
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
+---------------------+
訪問されたネットワーク+---------------------+ | +-----+ +-----+ | +-----+ +-----+ +-----+ ユーザ#1--| | C|-----| [C]|-----| C|-----| [C]|-----| C| | +-----+ +-----+ | +-----+ +-----+ +-----+ | UA#1プロキシA| プロキシ#1つのプロキシ#2UA#2+---------------------+
C: Content that UA #1 needs to disclose [C]: Content that UA #1 needs to protect
C: UA#1が[C]を明らかにするために必要とする内容: UA#1、が保護する必要がある内容
Figure 3: Deployment example #3
図3: 展開例#3
2.2. Service Examples
2.2. サービスの例
We describe here several services that require end-to-middle security.
私たちはここで終わりから中央へのセキュリティを必要とするいくつかのサービスについて説明します。
2.2.1. Logging Services for Instant Messages
2.2.1. インスタントメッセージのための伐採サービス
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.
伐採Servicesは格納機能で、それがUAsの間で交換されたメッセージ内容を登録するかどうかということです。(機能はプロキシサーバで位置しています)。 格納機能は創始者ネットワーク、そして/または、送信先ネットワークに位置するかもしれません。 インスタントメッセージの内容が個人情報を含んでいると、UACs(UA Clients)はUASes(UA Servers)のための内容を暗号化します。 格納機能は、双方向の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.
このサービスは財政的なネットワークで配布されるかもしれません、健康管理サービスプロバイダーのネットワーク、コミュニケーションを格納するのがそれらの安全保障政策によって必要とされる他のネットワークと同様に。
Ono & Tachimoto Informational [Page 4] RFC 4189 End-to-Middle Security Requirements October 2005
[4ページ]RFC4189終わりから中央へのセキュリティ要件2005年10月の情報の小野とTachimoto
2.2.2. Non-emergency Call Routing Based on the Location Object
2.2.2. 位置のオブジェクトに基づく非緊急通報ルート設定
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 Object[6]は人のプライバシー機密の地理的な位置情報を含んでいます。 いくつかのプロキシサーバには、地理的な位置情報に基づくルーティングを提供する能力があるでしょう。 UAsが非緊急事態で位置のベースのルーティングを使いたがっているとき、UAsは要求経路に沿った他のプロキシサーバからそのような能力でプロキシサーバに接続するのが必要であり、それを保護している間にINVITE要求のメッセージ本体に含まれた地理的な位置情報を明らかにします。 また、Location Objectは、位置のベースのルーティングが適用されている前にデータ保全のためにプロキシサーバによって確かめられる必要があります。 時々、UACsはLocation ObjectをUASesに送りたがっています。 これはUACsが同時にプロキシサーバと、そして、UASesに安全なデータを送る必要性を提示する別の好例です。
2.2.3. User Authentication
2.2.3. ユーザー認証
2.2.3.1. User Authentication Using the AIBs
2.2.3.1. AIBsを使用するユーザー認証
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.
Authenticated Identity Bodies(AIBs)[7]はユーザを特定するのに使用されるデジタルに署名しているデータです。 ユーザを認証するのが必要であり、署名について確かめるProxyサーバ。 創始者が匿名を必要とするとき、署名される前にAIBのユーザアイデンティティは暗号化されています。 ユーザを認証するProxyサーバは、AIBでユーザアイデンティティを見るためにボディーを解読する必要があります。 そのようなプロキシサーバの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を含むことができました。 プロキシサーバは、ユーザを認証するために要求メッセージでそれを見る必要があります。 別のプロキシサーバは、時々ユーザー認証のために応答メッセージでそれを見る必要があります。
2.2.3.2. User Authentication in HTTP Digest Authentication
2.2.3.2. HTTPダイジェスト認証におけるユーザー認証
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認証[8]のためのユーザー認証データは潜在的にユーザ名などの個人情報を含んでいます。 要求メッセージのSIPヘッダーだけにユーザー認証データを設定できます。 この情報は、しっかりと隣接して見つけられたユーザ、そして/または、非隣接をUAに認証するサーバに伝えられる必要があります。
2.2.4. Media-related Services
2.2.4. メディア関連のサービス
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,
ファイアウォール縦断はメッセージ本体でメディア情報に基づくサービスの例です、Session記述プロトコル(SDP)[9]などのように。 SIPプロトコルをサポートするファイアウォール実体、またはプロキシサーバで共同見つけられたmidcom[10]エージェント
Ono & Tachimoto Informational [Page 5] RFC 4189 End-to-Middle Security Requirements October 2005
[5ページ]RFC4189終わりから中央へのセキュリティ要件2005年10月の情報の小野とTachimoto
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のアドレスとポート情報は、しっかりとmidcomエージェントとして作動する受取人UAsとプロキシサーバに伝えられる必要があります。 したがって、プロキシサーバが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]のための主要なパラメタを含んでいると、主要なパラメタは、終わりから終わりへの秘密性のためだけに暗号化される必要があります。
3. Scope of End-to-Middle Security
3. 終わりから中央へのセキュリティの範囲
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 Digest認証、S/MIME Cryptographic Message Syntax(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.
このドキュメントは終わりから中央へのセキュリティのデータの機密性と保全のための要件について主に議論します。
4. Requirements for a Solution
4. ソリューションのための要件
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要求を送ります。
4.1. General Requirements
4.1. 一般要件
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は1に情報を得ます: ソリューションSHOULDはUAがMIMEでS/機密保護しているメッセージを扱う方法で少ししか影響を与えさせません。
Ono & Tachimoto Informational [Page 6] RFC 4189 End-to-Middle Security Requirements October 2005
[6ページ]RFC4189終わりから中央へのセキュリティ要件2005年10月の情報の小野とTachimoto
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は2に情報を得ます: それ、SHOULD NOTは取り扱いによるMIMEでS/機密保護しているボディーに基づいたサービスに既存のSIPヘッダーを提供しないプロキシサーバに影響を与えます。
REQ-GEN-3: It SHOULD NOT violate the standardized mechanism of proxy
servers in terms of handling message bodies.
REQは3に情報を得ます: それ、SHOULD NOTは取り扱いメッセージ本体に関してプロキシサーバの標準化されたメカニズムに違反します。
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は4に情報を得ます: それ、SHOULDはUAにプロキシサーバの安全保障政策を発見させます。 安全保障政策はメッセージで明らかにする、そして/または、確かめるべきデータが必要であることを含意します。
This requirement is necessary when the UA does not know
statically which proxy servers or domains need
disclosing data and/or verification.
UAが、どのプロキシサーバかドメインが、データ、そして/または、検証を明らかにする必要であるかを静的に知らないとき、この要件が必要です。
4.2. Requirements for End-to-Middle Confidentiality
4.2. 終わりから中央への秘密性のための要件
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: それ、SHOULDは特定のメッセージ本体を見るようプロキシサーバにUAを要求させます。 SHOULDが安全であるようそれ自体で要求してください。 すなわち、それ、UAのために認証されて、データ保全のために確かめられたSHOULD。
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が初めは情報を開示するプロキシサーバに情報を開示するよう要求できるかもしれません。 SHOULDが安全であるようそれ自体で要求してください。 すなわち、それ、UAのために認証されて、データ保全のために確かめられたSHOULD。
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に役立つプロバイダーに明らかにされるのを許容するとき、この要件が必要です。
4.3. Requirements for End-to-Middle Integrity
4.3. 終わりから中央への保全のための要件
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.
このセクションは終わりから中央への保全のための要件を列挙します。 データ保全を確かめるのは、データが認証されたユーザによって作成されて、悪意あるユーザーによって作り出されないのをチェックするのを必要とします。 したがって、データ保全の検証はユーザー認証を必要とします。
Ono & Tachimoto Informational [Page 7] RFC 4189 End-to-Middle Security Requirements October 2005
[7ページ]RFC4189終わりから中央へのセキュリティ要件2005年10月の情報の小野とTachimoto
REQ-INT-1: The solution SHOULD work even when the SIP end-to-end
authentication and integrity services are enabled.
REQ-INT-1: SIP終わりから終わりへの認証と保全サービスが可能にされるときさえ、ソリューションSHOULDは働いています。
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: それ、SHOULDは特定のメッセージ本体について確かめて、ユーザを認証するようプロキシサーバにUAを要求させます。 SHOULDが安全であるようそれ自体で要求してください。 すなわち、それ、UAのために認証されて、データ保全のために確かめられたSHOULD。
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: それ、SHOULDはUAがプロキシサーバへの. 要求SHOULD自身を提供している要求が安全であるという同じ情報に関する検証データを送るよう受取人UAにUAを要求させます。 すなわち、それ、UAのために認証されて、データ保全のために確かめられたSHOULD。
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に役立つプロバイダーに明らかにされるのを許容するとき、この要件が必要です。
5. Security Considerations
5. セキュリティ問題
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構造メッセージをプロキシサーバに送るところです、盗聴によって得られたユーザー認証データを含んでいて。 別の脅威モデルは悪意があるプロキシサーバが多くの複雑なMIME構造メッセージをプロキシサーバに送るところです、ソースIPアドレスと隣接しているプロキシサーバのViaヘッダーを含んでいて。これらの攻撃は目標プロキシサーバの総合的な性能を減速させるでしょう。
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.
これらの攻撃を防ぐのに、ユーザとサーバ証明メカニズムが、反射攻撃に対して保護される必要があるか、またはユーザとサーバ証明は、いつも同時にデータ保全の保護で実行される必要があります。 これらの攻撃を防ぐために、以下の必要条件は満たされるべきです。
Ono & Tachimoto Informational [Page 8] RFC 4189 End-to-Middle Security Requirements October 2005
[8ページ]RFC4189終わりから中央へのセキュリティ要件2005年10月の情報の小野とTachimoto
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 それ、SHOULDはユーザー認証のために反射攻撃に対する保護をサポートします。
o It SHOULD simultaneously support user authentication and data
integrity protection.
o それ、SHOULDは、同時に、ユーザー認証とデータ保全が保護であるとサポートします。
These last two requirements are met by HTTP Digest
authentication.
これらの最後の2つの必要条件がHTTP Digest認証で満たされます。
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 それ、SHOULDはサーバ証明のための反射攻撃に対する保護をサポートします。
o It SHOULD simultaneously support server authentication and data
integrity protection.
o それ、SHOULDは、同時に、サーバ証明とデータ保全が保護であるとサポートします。
These last three requirements are met by TLS.
これらの最後の3つの必要条件がTLSによって満たされます。
6. Acknowledgments
6. 承認
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マーイとCullenジョニングスと、そして、ジョン・ピーターソンと、ゴンサロ・キャマリロと、ショーン・オルソンと、マークBaugherと、メアリ・バーンズと、他のものに感謝したがっています。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
7.2. Informative References
7.2. 有益な参照
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[3] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
Ono & Tachimoto Informational [Page 9] RFC 4189 End-to-Middle Security Requirements October 2005
[9ページ]RFC4189終わりから中央へのセキュリティ要件2005年10月の情報の小野とTachimoto
[4] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
Ramsdell(B.)が「/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1証明書取り扱いであると機密保護する」[4]、RFC3850、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] キャンベル、B.、ローゼンバーグ、J.、Schulzrinne、H.、Huitema、C.、およびD.Gurle、「インスタントメッセージングのためのセッション開始プロトコル(一口)拡大」、RFC3428(2002年12月)。
[6] Peterson, J., "A Presence-based GEOPRIV Location Object Format",
RFC 4119, October 2005.
[6] ピーターソン、J.、「存在ベースのGEOPRIV位置のオブジェクト形式」、RFC4119、2005年10月。
[7] Peterson, J., "Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format", RFC 3893, September 2004.
[7] ピーターソン、J.、「セッション開始プロトコル(一口)はアイデンティティ本体(AIB)形式を認証した」RFC3893、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認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
[9] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[9] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、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と、「Middlebox通信アーキテクチャとフレームワーク」、RFC3303(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.
2004年の[11]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[12] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004.
[12]Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
Ono & Tachimoto Informational [Page 10] RFC 4189 End-to-Middle Security Requirements October 2005
[10ページ]RFC4189終わりから中央へのセキュリティ要件2005年10月の情報の小野とTachimoto
Authors' Addresses
作者のアドレス
Kumiko Ono Network Service Systems Laboratories NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan
研究所NTT社の9-11テロ、美土里町の3丁目の武蔵野市、久美子小野ネットワークサービス・システム日本東京180-8585
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
研究所NTT社の9-11テロ、美土里町の3丁目の武蔵野市、Shinya Tachimotoネットワークサービス・システム日本東京180-8585
EMail: tachimoto.shinya@lab.ntt.co.jp
メール: tachimoto.shinya@lab.ntt.co.jp
Ono & Tachimoto Informational [Page 11] RFC 4189 End-to-Middle Security Requirements October 2005
[11ページ]RFC4189終わりから中央へのセキュリティ要件2005年10月の情報の小野とTachimoto
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Ono & Tachimoto Informational [Page 12]
小野とTachimoto情報です。[12ページ]
一覧
スポンサーリンク
