RFC3329 日本語訳
3329 Security Mechanism Agreement for the Session Initiation Protocol(SIP). J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, T. Haukka. January 2003. (Format: TXT=51503 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Arkko
Request for Comments: 3329 V. Torvinen
Category: Standards Track G. Camarillo
Ericsson
A. Niemi
T. Haukka
Nokia
January 2003
Arkkoがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3329年のV.Torvinenカテゴリ: 標準化過程G.キャマリロエリクソンA.Niemi T.Haukkaノキア2003年1月
Security Mechanism Agreement for the
Session Initiation Protocol (SIP)
セッション開始プロトコルのためのセキュリティー対策協定(一口)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document defines new functionality for negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity. This new functionality supplements the existing methods of choosing security mechanisms between SIP entities.
このドキュメントはSession Initiationプロトコル(SIP)ユーザエージェントとその次のホップSIP実体の間で使用されるセキュリティー対策を交渉するための新しい機能性を定義します。 この新しい機能性はSIP実体の間のセキュリティー対策を選ぶ既存の方法を補います。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Motivations . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Design Goals . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Conventions . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Overview of Operation . . . . . . . . . . . . . . . . . 3
2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Protocol Operation . . . . . . . . . . . . . . . . . . . 6
2.3.1 Client Initiated . . . . . . . . . . . . . . . . . . 6
2.3.2 Server Initiated . . . . . . . . . . . . . . . . . . 8
2.4 Security Mechanism Initiation. . . . . . . . . . . . . . 9
2.5 Duration of Security Associations. . . . . . . . . . . .10
2.6 Summary of Header Field Use. . . . . . . . . . . . . . .10
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 1.1動機. . . . . . . . . . . . . . . . . . . . . . 2 1.2デザイン目標. . . . . . . . . . . . . . . . . . . . . . 3 1.3コンベンション. . . . . . . . . . . . . . . . . . . . . . 3 2。 操作. . . . . . . . . . . . . . . . . 3 2.2構文. . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3プロトコル操作. . . . . . . . . . . . . . . . . . . 6 2.3.1クライアントの.32.1概要は.2サーバが.82.4に開始した.62.3を開始しました。ソリューション、セキュリティー対策開始。 . . . . . . . . . . . . . 9 2.5 セキュリティ協会の持続時間。 . . . . . . . . . . .10 ヘッダーフィールド使用の2.6概要。 . . . . . . . . . . . . . .10
Arkko, et. al. Standards Track [Page 1] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[1ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
3. Backwards Compatibility . . . . . . . . . . . . . . . . . .11
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . .12
4.1 Client Initiated . . . . . . . . . . . . . . . . . . . .12
4.2 Server Initiated . . . . . . . . . . . . . . . . . . . .14
5. Security Considerations . . . . . . . . . . . . . . . . . .15
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .17
6.1 Registration Information . . . . . . . . . . . . . . . .17
6.2 Registration Template. . . . . . . . . . . . . . . . . .18
6.3 Header Field Names . . . . . . . . . . . . . . . . . . .18
6.4 Response Codes . . . . . . . . . . . . . . . . . . . . .18
6.5 Option Tags. . . . . . . . . . . . . . . . . . . . . . .19
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . .19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .19
9. Normative References . . . . . . . . . . . . . . . . . . . .19
10. Informative References . . . . . . . . . . . . . . . . . . 20
A. Syntax of ipsec-3gpp . . . . . . . . . . . . . . . . . . . .21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .23
Full Copyright Statement . . . . . . . . . . . . . . . . . . . .24
3. 遅れている互換性. . . . . . . . . . . . . . . . . .11 4。 例. . . . . . . . . . . . . . . . . . . . . . . . . .12 4.1のクライアントの開始している.4.2サーバは.5を開始しました。 セキュリティ問題. . . . . . . . . . . . . . . . . .15 6。 IANA問題。 . . . . . . . . . . . . . . . . . . . .17 6.1 レジスト情報. . . . . . . . . . . . . . . .17 6.2登録テンプレート。 . . . . . . . . . . . . . . . . .18 6.3 ヘッダーフィールド名. . . . . . . . . . . . . . . . . . .18 6.4応答は.186.5個のオプションタグをコード化します。 . . . . . . . . . . . . . . . . . . . . . .19 7. 貢献者. . . . . . . . . . . . . . . . . . . . . . . .19 8。 承認. . . . . . . . . . . . . . . . . . . . . .19 9。 引用規格. . . . . . . . . . . . . . . . . . . .19 10。 ipsec-3gppの有益なReferences. . . . . . . . . . . . . . . . . . 20A.Syntax… .21人の作者のAddresses………………… . .23の完全なCopyright Statement……………… . .24
1. Introduction
1. 序論
Traditionally, security protocols have included facilities to agree on the used mechanisms, algorithms, and other security parameters. This is to add flexibility, since different mechanisms are usually suitable to different scenarios. Also, the evolution of security mechanisms often introduces new algorithms, or uncovers problems in existing ones, making negotiation of mechanisms a necessity.
伝統的に、セキュリティプロトコルは、中古のメカニズム、アルゴリズム、および他のセキュリティパラメタに同意するために施設を含んでいました。 これは、異なったメカニズムが通常異なったシナリオに適しているので柔軟性を加えるためのものです。 また、セキュリティー対策の発展は、しばしば新しいアルゴリズムを導入するか、または既存のものにおける問題を発見します、メカニズムの交渉を必要性にして。
The purpose of this specification is to define negotiation functionality for the Session Initiation Protocol (SIP) [1]. This negotiation is intended to work only between a UA and its first-hop SIP entity.
この仕様の目的はSession Initiationプロトコル(SIP)[1]のための交渉の機能性を定義することです。 この交渉がUAとその最初に、ホップSIP実体だけの間で働くことを意図します。
1.1 Motivations
1.1 動機
Without a secured method to choose between security mechanisms and/or their parameters, SIP is vulnerable to certain attacks. Authentication and integrity protection using multiple alternative methods and algorithms is vulnerable to Man-in-the-Middle (MitM) attacks (e.g., see [4]).
セキュリティー対策、そして/または、それらのパラメタを選ぶ機密保護しているメソッドがなければ、SIPはある攻撃に被害を受け易いです。 複数の別法とアルゴリズムを使用する認証と保全保護は中央のMan(MitM)攻撃に被害を受け易いです。(例えば、[4])を見てください。
It is also hard or sometimes even impossible to know whether a specific security mechanism is truly unavailable to a SIP peer entity, or if in fact a MitM attack is in action.
本当に、特定のセキュリティー対策がSIP同輩実体を入手できないかどうか、または事実上、MitM攻撃が動作中であるかどうかを知るのは、また、困難であるか、または時々不可能でさえあります。
In certain small networks these issues are not very relevant, as the administrators of such networks can deploy appropriate software versions and set up policies for using exactly the right type of
ある小さいネットワークでは、これらの問題はそれほど関連していません、ネットワークが適切なソフトウェアバージョンを配布することができるそのようなものとセットのまさに権利を使用するための方針への管理者がタイプするように
Arkko, et. al. Standards Track [Page 2] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[2ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
security. However, SIP is also expected to be deployed to hundreds of millions of small devices with little or no possibilities for coordinated security policies, let alone software upgrades, which necessitates the need for the negotiation functionality to be available from the very beginning of deployment (e.g., see [11]).
セキュリティ。 しかしながら、また、連携安全保障政策、まして、ソフトウェアの更新のために可能性でSIPによってまず何億台もの小さいデバイスに配布されないと予想されます、交渉の機能性がそもそも最初から展開で利用可能になる必要性を必要とするもの。(例えば、[11])を見てください。
1.2 Design Goals
1.2 デザイン目標
1. The entities involved in the security agreement process need to
find out exactly which security mechanisms to apply, preferably
without excessive additional roundtrips.
1. 担保契約プロセスにかかわる実体は、まさにどのセキュリティー対策を適用したらよいかを見つける必要があります、望ましくは、過度の追加往復旅行なしで。
2. The selection of security mechanisms itself needs to be secure.
Traditionally, all security protocols use a secure form of
negotiation. For instance, after establishing mutual keys through
Diffie-Hellman, IKE sends hashes of the previously sent data
including the offered crypto mechanisms [8]. This allows the
peers to detect if the initial, unprotected offers were tampered
with.
2. セキュリティー対策の品揃え自体は、安全である必要があります。 伝統的に、すべてのセキュリティプロトコルが安全な形式の交渉を使用します。 例えば、ディフィー-ヘルマンを通して互いのキーを設立した後に、IKEは提供された暗号メカニズム[8]を含む以前に送られたデータのハッシュを送ります。 これで、同輩は、初期の、そして、保護のない申し出がいじられたかどうか検出できます。
3. The entities involved in the security agreement process need to be
able to indicate success or failure of the security agreement
process.
3. 担保契約プロセスにかかわる実体は、担保契約プロセスの成否を示すことができる必要があります。
4. The security agreement process should not introduce any additional
state to be maintained by the involved entities.
4. 担保契約プロセスはかかわった実体によって維持される少しの追加状態も導入するはずがありません。
1.3 Conventions
1.3 コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [9].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[9])で説明されるように本書では解釈されることであるべきです。
2. Solution
2. ソリューション
2.1 Overview of Operation
2.1 操作の概要
The message flow below illustrates how the mechanism defined in this document works:
以下でのメッセージ流動は本書では定義されたメカニズムがどう動作するかを例証します:
1. Client ----------client list---------> Server
2. Client <---------server list---------- Server
3. Client ------(turn on security)------- Server
4. Client ----------server list---------> Server
5. Client <---------ok or error---------- Server
1. クライアント----------顧客リスト--------->サーバ2。 クライアント<。---------サーバリスト---------- サーバ3。 クライアント------(セキュリティにおける回転)------- サーバ4。 クライアント----------サーバリスト--------->サーバ5。 クライアント<。---------OKか誤り---------- サーバ
Figure 1: Security agreement message flow.
図1: 担保契約メッセージ流動。
Arkko, et. al. Standards Track [Page 3] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[3ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
Step 1: Clients wishing to use this specification can send a list of
their supported security mechanisms along the first request to the
server.
ステップ1: この仕様を使用したがっているクライアントは1番目に沿ったメカニズムがサーバに要求する彼らのサポートしているセキュリティのリストを送ることができます。
Step 2: Servers wishing to use this specification can challenge the
client to perform the security agreement procedure. The security
mechanisms and parameters supported by the server are sent along
in this challenge.
ステップ2: この仕様を使用したがっているサーバは、担保契約手順を実行するようにクライアントに挑むことができます。 この挑戦でサーバによってサポートされたセキュリティー対策とパラメタを送ります。
Step 3: The client then proceeds to select the highest-preference
security mechanism they have in common and to turn on the selected
security.
ステップ3: クライアントは、それらが共通である最も高い好みのセキュリティー対策を選択して、そして、選択されたセキュリティをつけかけます。
Step 4: The client contacts the server again, now using the selected
security mechanism. The server's list of supported security
mechanisms is returned as a response to the challenge.
ステップ4: 現在選択されたセキュリティー対策を使用して、クライアントは再びサーバに連絡します。 挑戦への応答としてサーバのサポートしているセキュリティー対策のリストを返します。
Step 5: The server verifies its own list of security mechanisms in
order to ensure that the original list had not been modified.
ステップ5: サーバは、オリジナルのリストが変更されていなかったのを確実にするためにそれ自身のセキュリティー対策のリストについて確かめます。
This procedure is stateless for servers (unless the used security mechanisms require the server to keep some state).
サーバに、この手順は状態がないです(中古のセキュリティー対策が何らかの状態を維持するためにサーバを必要としないなら)。
The client and the server lists are both static (i.e., they do not and cannot change based on the input from the other side). Nodes may, however, maintain several static lists, one for each interface, for example.
クライアントとサーバリストはともに静的です(そうしません、そして、他の側からの入力に基づいて変化できません)。 しかしながら、ノードはいくつかの静的なリスト、例えば、各インタフェースあたり1つを維持するかもしれません。
Between Steps 1 and 2, the server may set up a non-self-describing security mechanism if necessary. Note that with this type of security mechanisms, the server is necessarily stateful. The client would set up the non-self-describing security mechanism between Steps 2 and 4.
必要なら、Steps1と2の間では、サーバは自己について説明しないセキュリティー対策をセットアップするかもしれません。 このタイプのセキュリティー対策で、サーバが必ずstatefulであることに注意してください。 クライアントはSteps2と4の間の自己について説明しないセキュリティー対策をセットアップするでしょう。
2.2 Syntax
2.2構文
We define three new SIP header fields, namely Security-Client, Security-Server and Security-Verify. The notation used in the Augmented BNF definitions for the syntax elements in this section is as used in SIP [1], and any elements not defined in this section are as defined in SIP and the documents to which it refers:
そして、私たちが3つの新しいSIPヘッダーフィールド、Security-クライアント、すなわち、Security-サーバを定義する、Security確かめます。 このセクションの構文要素にAugmented BNF定義に使用される記法はSIP[1]で使用されています、そして、このセクションで定義されなかったどんな要素もそれが参照されるSIPとドキュメントで定義されるようにあります:
security-client = "Security-Client" HCOLON
sec-mechanism *(COMMA sec-mechanism)
security-server = "Security-Server" HCOLON
sec-mechanism *(COMMA sec-mechanism)
security-verify = "Security-Verify" HCOLON
sec-mechanism *(COMMA sec-mechanism)
セキュリティクライアント=「セキュリティクライアント」HCOLON秒メカニズム*(COMMA秒メカニズム)セキュリティサーバ=「セキュリティサーバ」*(COMMA秒メカニズム)が安全に確かめるHCOLON秒メカニズム=はHCOLON秒メカニズム*について「安全に確かめます」。(COMMA秒メカニズム)
Arkko, et. al. Standards Track [Page 4] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[4ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
sec-mechanism = mechanism-name *(SEMI mech-parameters)
mechanism-name = ( "digest" / "tls" / "ipsec-ike" /
"ipsec-man" / token )
mech-parameters = ( preference / digest-algorithm /
digest-qop / digest-verify / extension )
preference = "q" EQUAL qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
digest-algorithm = "d-alg" EQUAL token
digest-qop = "d-qop" EQUAL token
digest-verify = "d-ver" EQUAL LDQUOT 32LHEX RDQUOT
extension = generic-param
sec-mechanism = mechanism-name *(SEMI mech-parameters) mechanism-name = ( "digest" / "tls" / "ipsec-ike" / "ipsec-man" / token ) mech-parameters = ( preference / digest-algorithm / digest-qop / digest-verify / extension ) preference = "q" EQUAL qvalue qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) digest-algorithm = "d-alg" EQUAL token digest-qop = "d-qop" EQUAL token digest-verify = "d-ver" EQUAL LDQUOT 32LHEX RDQUOT extension = generic-param
Note that qvalue is already defined in the SIP BNF [1]. We have copied its definitions here for completeness.
qvalueがSIP BNF[1]で既に定義されることに注意してください。 私たちは完全性のためにここに定義をコピーしました。
The parameters described by the BNF above have the following semantics:
上のBNFによって説明されたパラメタは以下の意味論を持っています:
Mechanism-name
This token identifies the security mechanism supported by the
client, when it appears in a Security-Client header field; or
by the server, when it appears in a Security-Server or in a
Security-Verify header field. The mechanism-name tokens are
registered with the IANA. This specification defines four
values:
メカニズム名のThisトークンはSecurity-クライアントヘッダーフィールドに現れるとクライアントによってサポートされたセキュリティー対策を特定します。 Security-サーバか中に現れるとき、または、サーバで、aはヘッダーフィールドについてSecurity確かめます。 メカニズム名のトークンはIANAに登録されます。 この仕様は4つの値を定義します:
* "tls" for TLS [3].
* TLS[3]のための"tls"。
* "digest" for HTTP Digest [4].
* HTTPダイジェスト[4]のための「読みこなしてください。」
* "ipsec-ike" for IPsec with IKE [2].
* IKE[2]とIPsecのための"ipsec-ike"。
* "ipsec-man" for manually keyed IPsec without IKE.
* IKEのない手動で合わせられたIPsecのための「ipsec-男性。」
Preference
The "q" value indicates a relative preference for the
particular mechanism. The higher the value the more preferred
the mechanism is. All the security mechanisms MUST have
different "q" values. It is an error to provide two mechanisms
with the same "q" value.
「q」が評価する好みは特定のメカニズムのための相対的選好を示します。 高い..値..以上..都合のよい..メカニズム すべてのセキュリティー対策には、異なった「q」値がなければなりません。 それは同じ「q」値を2つのメカニズムに提供する誤りです。
Digest-algorithm
This optional parameter is defined here only for HTTP Digest
[4] in order to prevent the bidding-down attack for the HTTP
Digest algorithm parameter. The content of the field may have
same values as defined in [4] for the "algorithm" field.
[4] HTTP Digestアルゴリズムパラメタのための下に入札攻撃を防いで、ダイジェストアルゴリズムのThisの任意のパラメタはHTTP Digestのためだけにここで定義されます。 分野の内容は「アルゴリズム」分野への[4]の同じ値を定義されるようにするかもしれません。
Arkko, et. al. Standards Track [Page 5] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[5ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
Digest-qop
This optional parameter is defined here only for HTTP Digest
[4] in order to prevent the bidding-down attack for the HTTP
Digest qop parameter. The content of the field may have same
values as defined in [4] for the "qop" field.
[4] HTTP Digest qopパラメタのための下に入札攻撃を防いで、ダイジェスト-qop Thisの任意のパラメタはHTTP Digestのためだけにここで定義されます。 分野の内容は[4]の同じ値を"qop"分野に定義されるようにするかもしれません。
Digest-verify
This optional parameter is defined here only for HTTP Digest
[4] in order to prevent the bidding-down attack for the SIP
security mechanism agreement (this document). The content of
the field is counted exactly the same way as "request-digest"
in [4] except that the Security-Server header field is included
in the A2 parameter. If the "qop" directive's value is "auth"
or is unspecified, then A2 is:
This任意のパラメタについてダイジェストで確かめてください。ここで、HTTP Digestのためだけに、[4] SIPセキュリティー対策協定(このドキュメント)のための下に入札攻撃を防いで、定義されます。 Security-サーバヘッダーフィールドがA2パラメタに含まれているのを除いて、分野の内容は[4]でまさに同じように「要求ダイジェスト」にみなされます。 "qop"指示の値が"auth"であるか不特定であるなら、A2は以下の通りです。
A2 = Method ":" digest-uri-value ":" security-server
「A2はメソッドと等しい」:、」 「ダイジェストuri価値」:、」 セキュリティサーバ
If the "qop" value is "auth-int", then A2 is:
"qop"値が"auth-int"であるなら、A2は以下の通りです。
A2 = Method ":" digest-uri-value ":" H(entity-body) ":"
security-server
「A2はメソッドと等しい」:、」 「ダイジェストuri価値」:、」 「H(実体本体)」:、」 セキュリティサーバ
All linear white spaces in the Security-Server header field
MUST be replaced by a single SP before calculating or
interpreting the digest-verify parameter. Method, digest-uri-
value, entity-body, and any other HTTP Digest parameter are as
specified in [4].
計算するか、または解釈する前にSecurity-サーバヘッダーフィールドにおけるすべての直線的な余白を独身のSPに取り替えなければならない、パラメタについてダイジェストで確かめてください。 メソッド、ダイジェスト-uri値、実体本体、およびいかなる他のHTTP Digestパラメタも[4]で指定されるようにあります。
Note that this specification does not introduce any extension or change to HTTP Digest [4]. This specification only re-uses the existing HTTP Digest mechanisms to protect the negotiation of security mechanisms between SIP entities.
この仕様がHTTP Digest[4]に少しの拡大や変化も紹介しないことに注意してください。 この仕様は、SIP実体の間のセキュリティー対策の交渉を保護するのに既存のHTTP Digestメカニズムを再使用するだけです。
2.3 Protocol Operation
2.3 プロトコル操作
This section deals with the protocol details involved in the negotiation between a SIP UA and its next-hop SIP entity. Throughout the text the next-hop SIP entity is referred to as the first-hop proxy or outbound proxy. However, the reader should bear in mind that a user agent server can also be the next-hop for a user agent client.
このセクションはSIP UAとその次のホップSIP実体との交渉にかかわるプロトコルの詳細に対処します。 テキスト中では、次のホップSIP実体は最初に、ホッププロキシか外国行きのプロキシと呼ばれます。 しかしながら、読者は、また、ユーザエージェントサーバがユーザエージェントのクライアントのための次のホップであるかもしれないことを覚えておくべきです。
2.3.1 Client Initiated
2.3.1 開始されたクライアント
If a client ends up using TLS to contact the server because it has followed the rules specified in [5], the client MUST NOT use the security agreement procedure of this specification. If a client ends
クライアントが結局規則が[5]で指定したということになったのでサーバに連絡するのにTLSを使用するなら、クライアントはこの仕様の担保契約手順を用いてはいけません。 クライアントが終わるなら
Arkko, et. al. Standards Track [Page 6] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[6ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
up using non-TLS connections because of the rules in [5], the client MAY use the security agreement of this specification to detect DNS spoofing, or to negotiate some other security than TLS.
規則のために[5]で非TLS接続を使用するのに、クライアントは、DNSがだますのを検出するか、またはTLSよりある他のセキュリティを交渉するのにこの仕様の担保契約を使用するかもしれません。
A client wishing to use the security agreement of this specification MUST add a Security-Client header field to a request addressed to its first-hop proxy (i.e., the destination of the request is the first- hop proxy). This header field contains a list of all the security mechanisms that the client supports. The client SHOULD NOT add preference parameters to this list. The client MUST add both a Require and Proxy-Require header field with the value "sec-agree" to its request.
この仕様の担保契約を使用したがっているクライアントは最初に、ホッププロキシに扱われた要求にSecurity-クライアントヘッダーフィールドを追加しなければなりません(すなわち、要求の目的地は第1代ホッププロキシです)。 このヘッダーフィールドはクライアントがサポートするすべてのセキュリティー対策のリストを含んでいます。 クライアントSHOULD NOTは好みのパラメタをこのリストに追加します。 そして、クライアントが両方を加えなければならない、Require、要求が「秒同意している」値があるヘッダーフィールドをProxy必要としてください。
The contents of the Security-Client header field may be used by the server to include any necessary information in its response.
Security-クライアントヘッダーフィールドのコンテンツはサーバによって使用されて、応答にどんな必要事項も含むかもしれません。
A server receiving an unprotected request that contains a Require or Proxy-Require header field with the value "sec-agree" MUST respond to the client with a 494 (Security Agreement Required) response. The server MUST add a Security-Server header field to this response listing the security mechanisms that the server supports. The server MUST add its list to the response even if there are no common security mechanisms in the client's and server's lists. The server's list MUST NOT depend on the contents of the client's list.
値が「秒同意していた」状態でRequireを含んでいるか、またはヘッダーフィールドをProxy必要とする保護のない要求を受け取るサーバは494(セキュリティAgreement Required)応答でクライアントに反応しなければなりません。 サーバはサーバがサポートするセキュリティー対策を記載するこの応答にSecurity-サーバヘッダーフィールドを加えなければなりません。 クライアントとサーバのリストに共通の安全保障メカニズムが全くなくても、サーバは応答にリストを加えなければなりません。 サーバのリストはクライアントのリストのコンテンツによってはいけません。
The server MUST compare the list received in the Security-Client header field with the list to be sent in the Security-Server header field. When the client receives this response, it will choose the common security mechanism with the highest "q" value. Therefore, the server MUST add the necessary information so that the client can initiate that mechanism (e.g., a Proxy-Authenticate header field for HTTP Digest).
サーバはSecurity-クライアントヘッダーフィールドで受け取られたリストをSecurity-サーバヘッダーフィールドで送られるリストにたとえなければなりません。 クライアントがこの応答を受けるとき、それは最も高い「q」値がある共通の安全保障メカニズムを選ぶでしょう。 したがって、サーバは、クライアントがそのメカニズムを開始できる(例えば、aはHTTP DigestのためのヘッダーフィールドをProxy認証する)ように、必要事項を加えなければなりません。
When the client receives a response with a Security-Server header field, it MUST choose the security mechanism in the server's list with the highest "q" value among all the mechanisms that are known to the client. Then, it MUST initiate that particular security mechanism as described in Section 3.5. This initiation may be carried out without involving any SIP message exchange (e.g., establishing a TLS connection).
クライアントがSecurity-サーバヘッダーフィールドで応答を受けるとき、クライアントにとって知られているすべてのメカニズムの中に最も高い「q」値がある状態で、それはサーバのリストでセキュリティー対策を選ばなければなりません。 そして、それはセクション3.5で説明されるようにその特定のセキュリティー対策を開始しなければなりません。 どんなSIP交換処理(例えば、TLS接続を確立する)にもかかわらないで、この開始は運び出されるかもしれません。
If an attacker modified the Security-Client header field in the request, the server may not include in its response the information needed to establish the common security mechanism with the highest preference value (e.g., the Proxy-Authenticate header field is missing). A client detecting such a lack of information in the
攻撃者が要求におけるSecurity-クライアントヘッダーフィールドを変更したなら、サーバが応答に最も高い好みの値で共通の安全保障メカニズムを確立するのに必要である情報を含まないかもしれない、(例えば、分野がいなくて寂しいヘッダーをProxy認証してください、) 中にそのような資料不足を検出するクライアント
Arkko, et. al. Standards Track [Page 7] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[7ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
response MUST consider the current security agreement process aborted, and MAY try to start it again by sending a new request with a Security-Client header field as described above.
応答は、現在の担保契約プロセスが中止になったと考えなければならなくて、再び上で説明されるようにSecurity-クライアントヘッダーフィールドから新しい要求を送ることによって、それを出発させようとするかもしれません。
All the subsequent SIP requests sent by the client to that server SHOULD make use of the security mechanism initiated in the previous step. These requests MUST contain a Security-Verify header field that mirrors the server's list received previously in the Security- Server header field. These requests MUST also have both a Require and Proxy-Require header fields with the value "sec-agree".
クライアントによってそのサーバSHOULDに送られたすべてのその後のSIP要求が前のステップで開始されたセキュリティー対策を利用します。 これらの要求は含まなければなりません。aは以前にSecurityサーバヘッダーフィールドで受け取られたサーバのリストを反映するヘッダーフィールドについてSecurity確かめます。 そして、また、これらの要求には両方がなければならない、Require、値がある分野が「秒同意する」ヘッダーをProxy必要としてください。
The server MUST check that the security mechanisms listed in the Security-Verify header field of incoming requests correspond to its static list of supported security mechanisms.
サーバが、セキュリティー対策が中に記載したのをチェックしなければならない、セキュリティー対策であるとサポートされて、要求が静的なリストに対応する入来のヘッダーフィールドについてSecurity確かめてください。
Note that, following the standard SIP header field comparison
rules defined in [1], both lists have to contain the same security
mechanisms in the same order to be considered equivalent. In
addition, for each particular security mechanism, its parameters
in both lists need to have the same values.
[1]で定義された標準のSIPヘッダーフィールド比較規則に従って、両方のリストが同じ同等であると考えられるべき命令に同じセキュリティー対策を入れてあなければならないことに注意してください。 さらに、それぞれの特定のセキュリティー対策のために、両方のリストのパラメタは同じ値を必要とします。
The server can proceed processing a particular request if, and only if, the list was not modified. If modification of the list is detected, the server MUST respond to the client with a 494 (Security Agreement Required) response. This response MUST include the server's unmodified list of supported security mechanisms. If the list was not modified, and the server is a proxy, it MUST remove the "sec-agree" value from both the Require and Proxy-Require header fields, and then remove the header fields if no values remain.
サーバが特定の要求を処理しながら続くことができる、唯一、リストは変更されませんでした。 リストの変更が検出されるなら、サーバは494(セキュリティAgreement Required)応答でクライアントに反応しなければなりません。 この応答はサーバのサポートしているセキュリティー対策の変更されていないリストを含まなければなりません。リストが変更されないで、サーバがプロキシであり、値が全く残っていないなら、それは、両方のRequireから「秒同意している」値を取り除いて、ヘッダーフィールドをProxy必要として、次に、ヘッダーフィールドを取り除かなければなりません。
Once the security has been negotiated between two SIP entities, the same SIP entities MAY use the same security when communicating with each other in different SIP roles. For example, if a UAC and its outbound proxy negotiate some security, they may try to use the same security for incoming requests (i.e., the UA will be acting as a UAS).
異なったSIPの役割で互いにコミュニケートするとき、セキュリティが2つのSIP実体の間でいったん交渉されると、同じSIP実体は同じセキュリティを使用するかもしれません。 例えば、UACとその外国行きのプロキシが何らかのセキュリティを交渉するなら、彼らは入って来る要求に同じセキュリティを使用しようとするかもしれません(すなわち、UAはUASとして機能するでしょう)。
The user of a UA SHOULD be informed about the results of the security mechanism agreement. The user MAY decline to accept a particular security mechanism, and abort further SIP communications with the peer.
ユーザ、UA SHOULDでは、セキュリティー対策協定の結果に関して知識があってください。 ユーザは、特定のセキュリティー対策を受け入れて、同輩とのさらなるSIPコミュニケーションを中止するのを断るかもしれません。
2.3.2 Server Initiated
2.3.2 開始されたサーバ
A server decides to use the security agreement described in this document based on local policy. If a server receives a request from the network interface that is configured to use this mechanism, it must check that the request has only one Via entry. If there are
サーバは、本書ではローカルの方針に基づいて説明された担保契約を使用すると決めます。 サーバがこのメカニズムを使用するために構成されるネットワーク・インターフェースから要求を受け取るなら、要求には1つのViaエントリーしかないのはチェックしなければなりません。 あれば
Arkko, et. al. Standards Track [Page 8] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[8ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
several Via entries, the server is not the first-hop SIP entity, and it MUST NOT use this mechanism. For such a request, the server must return a 502 (Bad Gateway) response.
いくつかのViaエントリーであり、サーバは最初に、ホップSIP実体ではありません、そして、それはこのメカニズムを使用してはいけません。 そのような要求のために、サーバは502(悪いゲートウェイ)応答を返さなければなりません。
A server that decides to use this agreement mechanism MUST challenge unprotected requests with one Via entry regardless of the presence or the absence of any Require, Proxy-Require or Supported header fields in incoming requests.
この協定メカニズムを使用すると決めるサーバがどんなRequireの存在か不在にかかわらず1つのViaエントリーで保護のない要求に挑戦しなければならない、Proxy必要である、または、入って来る要求におけるSupportedヘッダーフィールド。
A server that by policy requires the use of this specification and receives a request that does not have the sec-agree option tag in a Require, Proxy-Require or Supported header field MUST return a 421 (Extension Required) response. If the request had the sec-agree option tag in a Supported header field, it MUST return a 494 (Security Agreement Required) response. In both situation the server MUST also include in the response a Security-Server header field listing its capabilities and a Require header field with an option- tag "sec-agree" in it. The server MUST also add necessary information so that the client can initiate the preferred security mechanism (e.g., a Proxy-Authenticate header field for HTTP Digest).
方針でこの仕様の使用を必要として、Requireに秒同意しているオプションタグを持っていない要求を受け取るサーバ、Proxy必要である、または、ヘッダーフィールドが421(拡大Required)応答を返さなければならないSupported。 要求がSupportedヘッダーフィールドで秒同意しているオプションタグを持っていたなら、それは494(セキュリティAgreement Required)応答を返さなければなりません。 またサーバが能力を記載するSecurity-サーバヘッダーがさばく応答に含まなければならない状況とオプションがあるRequireヘッダーフィールドの両方では、それで「秒同意してください」にタグ付けをしてください。 また、サーバは、クライアントが都合のよいセキュリティー対策を開始できる(例えば、aはHTTP DigestのためのヘッダーフィールドをProxy認証する)ように、必要事項を加えなければなりません。
Clients that support the extension defined in this document SHOULD add a Supported header field with a value of "sec-agree".
このドキュメントSHOULDで定義された拡大をサポートするクライアントが「秒同意してください」の値でSupportedヘッダーフィールドを加えます。
2.4 Security Mechanism Initiation
2.4 セキュリティー対策開始
Once the client chooses a security mechanism from the list received in the Security-Server header field from the server, it initiates that mechanism. Different mechanisms require different initiation procedures.
クライアントがSecurity-サーバヘッダーフィールドで受け取られたリストからサーバからセキュリティー対策をいったん選ぶと、それはそのメカニズムを開始します。 異なったメカニズムは異なった開始手順を必要とします。
If "tls" is chosen, the client uses the procedures of Section 8.1.2 of [1] to determine the URI to be used as an input to the DNS procedures of [5]. However, if the URI is a SIP URI, it MUST treat the scheme as if it were sips, not sip. If the URI scheme is not sip, the request MUST be sent using TLS.
"tls"が選ばれているなら、クライアントは、URIが入力として[5]のDNS手順に使用されることを決定するのに[1]についてセクション8.1.2の手順を用います。 しかしながら、URIがSIP URIであるなら、それは一口ではなく、一口であるかのように体系を扱わなければなりません。 URI体系が一口でないなら、要求にTLSを使用させなければなりません。
If "digest" is chosen, the 494 (Security Agreement Required) response will contain an HTTP Digest authentication challenge. The client MUST use the algorithm and qop parameters in the Security-Server header field to replace the same parameters in the HTTP Digest challenge. The client MUST also use the digest-verify parameter in the Security-Verify header field to protect the Security-Server header field as specified in 2.2.
「ダイジェスト」が選ばれていると、494(セキュリティAgreement Required)応答はHTTP Digest認証挑戦を含むでしょう。 クライアントは、HTTP Digest挑戦における同じパラメタを置き換えるのにSecurity-サーバヘッダーフィールドにアルゴリズムとqopパラメタを使用しなければなりません。 中、また、クライアントが使用しなければならない、パラメタについてダイジェストで確かめてください、2.2における指定されるとしてのSecurity-サーバヘッダーフィールドを保護するヘッダーフィールドについてSecurity確かめてください。
Arkko, et. al. Standards Track [Page 9] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[9ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
To use "ipsec-ike", the client attempts to establish an IKE connection to the host part of the Request-URI in the first request to the server. If the IKE connection attempt fails, the agreement procedure MUST be considered to have failed, and MUST be terminated.
IKE接続試みが失敗するなら、"ipsec-ike"(サーバへの最初の要求でRequest-URIのホスト部分にIKE接続を確立するクライアント試み)を使用するために、協定手順を失敗したと考えなければならなくて、終えなければなりません。
Note that "ipsec-man" will only work if the communicating SIP entities know which keys and other parameters to use. It is outside the scope of this specification to describe how this information can be made known to the peers. All rules for minimum implementations, such as mandatory-to-implement algorithms, apply as defined in [2], [6], and [7].
交信しているSIP実体が、どのキーと他のパラメタを使用したらよいかを知っている場合にだけ「ipsec-男性」が働くことに注意してください。 どうこの情報を明らかにされることができるかを同輩に説明するために、この仕様の範囲の外にそれはあります。 実装するために義務的なアルゴリズムなどの最小の実装のためのすべての規則が[2]、[6]、および[7]で定義されるように適用されます。
In both IPsec-based mechanisms, it is expected that appropriate policy entries for protecting SIP have been configured or will be created before attempting to use the security agreement procedure, and that SIP communications use port numbers and addresses according to these policy entries. It is outside the scope of this specification to describe how this information can be made known to the peers, but it would typically be configured at the same time as the IKE credentials or manual SAs have been entered.
両方のIPsecベースのメカニズムでは、SIPを保護するためのエントリーが持っている適切な方針が構成されるか、または担保契約手順を用いるのを試みる前に、作成されて、これらの方針エントリーに従ってSIPコミュニケーションがポートナンバーとアドレスを使用すると予想されます。 同輩にこの情報を明らかにされることができますが、IKE資格証明書かマニュアルと同時にSAsが入られたのが通常どう構成されるだろうかを説明するために、この仕様の範囲の外にそれはあります。
2.5 Duration of Security Associations
2.5 セキュリティ協会の持続時間
Once a security mechanism has been negotiated, both the server and the client need to know until when it can be used. All the mechanisms described in this document have a different way of signaling the end of a security association. When TLS is used, the termination of the connection indicates that a new negotiation is needed. IKE negotiates the duration of a security association. If the credentials provided by a client using digest are no longer valid, the server will re-challenge the client. It is assumed that when IPsec-man is used, the same out-of-band mechanism used to distribute keys is used to define the duration of the security association.
セキュリティー対策がいったん交渉されると、サーバとクライアントの両方が、いつまでそれを使用できるかを知る必要があります。 本書では説明されたすべてのメカニズムがセキュリティ協会の終わりに合図する異なった方法を持っています。 TLSが使用されているとき、接続の終了は、新しい交渉が必要であることを示します。 IKEはセキュリティ協会の持続時間を交渉します。 ダイジェストを使用することでクライアントによって提供された資格証明書がもう有効でないなら、サーバはクライアントに再挑戦するでしょう。 IPsec-男性がバンドの外で同じように使用されるとき、キーを分配するのに使用されるメカニズムがセキュリティ協会の持続時間を定義するのに使用されると思われます。
2.6 Summary of Header Field Use
2.6 ヘッダーフィールド使用の概要
The header fields defined in this document may be used to negotiate the security mechanisms between a UAC and other SIP entities including UAS, proxy, and registrar. Information about the use of headers in relation to SIP methods and proxy processing is summarized in Table 1.
本書では定義されたヘッダーフィールドは、UAS、プロキシ、および記録係を含んでいて、UACと他のSIP実体の間でセキュリティー対策を交渉するのに使用されるかもしれません。 SIPメソッドとプロキシ処理と関連したヘッダーの使用に関する情報はTable1にまとめられます。
Arkko, et. al. Standards Track [Page 10] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[10ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
Header field where proxy ACK BYE CAN INV OPT REG _________________________________________________________________ Security-Client R ard - o - o o o Security-Server 421,494 - o - o o o Security-Verify R ard - o - o o o
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG_________________________________________________________________ セキュリティクライアントR急性呼吸器病--o--○ ○ ○ Security-サーバ42万1494--o--○ ○ ○ R急性呼吸器病--o--o o oについてSecurity確かめてください。
Header field where proxy SUB NOT PRK IFO UPD MSG _________________________________________________________________ Security-Client R ard o o - o o o Security-Server 421,494 o o - o o o Security-Verify R ard o o - o o o
ヘッダーフィールドどこプロキシSUB NOT PRK IFO UPD MSG_________________________________________________________________ セキュリティクライアントR急性呼吸器病o o--o o o Security-サーバ42万1494○o--○ ○ ○ R急性呼吸器病o o--o o oについてSecurity確かめてください。
Table 1: Summary of Header Usage.
テーブル1: ヘッダー用法の概要。
The "where" column describes the request and response types in which the header field may be used. The header may not appear in other types of SIP messages. Values in the where column are:
「どこ」コラムはヘッダーフィールドが使用されるかもしれない要求と応答タイプについて説明するか。 ヘッダーは他のタイプに関するSIPメッセージに現れないかもしれません。 中の値、コラムは以下の通りです。
* R: Header field may appear in requests.
* R: ヘッダーフィールドは要求に現れるかもしれません。
* 421, 494: A numerical value indicates response codes with which
the header field can be used.
* 421, 494: 数値はヘッダーフィールドを使用できる応答コードを示します。
The "proxy" column describes the operations a proxy may perform on a header field:
「プロキシ」コラムはプロキシがヘッダーフィールドに実行するかもしれない操作について説明します:
* a: A proxy can add or concatenate the header field if not present.
* a: プロキシは、ヘッダーフィールドかプレゼントを加えるか、または連結できます。
* r: A proxy must be able to read the header field, and thus this
header field cannot be encrypted.
* r: プロキシはヘッダーフィールドを読むことができなければなりません、そして、その結果、このヘッダーフィールドは暗号化できません。
* d: A proxy can delete a header field value.
* d: プロキシはヘッダーフィールド値を削除できます。
The next six columns relate to the presence of a header field in a method:
次の6つのコラムがメソッドによるヘッダーフィールドの存在に関連します:
* o: The header field is optional.
* o: ヘッダーフィールドは任意です。
3. Backwards Compatibility
3. 遅れている互換性
The use of this extension in a network interface is a matter of local policy. Different network interfaces may follow different policies, and consequently the use of this extension may be situational by nature. UA and server implementations MUST be configurable to operate with or without this extension.
ネットワーク・インターフェースでのこの拡張子の使用はローカルの方針の問題です。 異なったネットワーク・インターフェースは異なった方針に従うかもしれません、そして、その結果、生来、この拡張子の使用は状況により異なるかもしれません。 UAとサーバ実装はこの拡大のあるなしにかかわらず作動するのにおいて構成可能であるに違いありません。
Arkko, et. al. Standards Track [Page 11] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[11ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
A server that is configured to use this mechanism, may also accept requests from clients that use TLS based on the rules defined in [5]. Requests from clients that do not support this extension, and do not support TLS, can not be accepted. This obviously breaks interoperability with some SIP clients. Therefore, this extension should be used in environments where it is somehow ensured that every client implements this extension or is able to use TLS. This extension may also be used in environments where insecure communication is not acceptable if the option of not being able to communicate is also accepted.
このメカニズムを使用するために構成されて、また受け入れるかもしれないサーバはクライアントから規則に基づいたTLSが[5]で定義したその使用を要求します。 この拡大をサポートしないで、またTLSをサポートしないクライアントからの要求を受け入れることができません。 これは何人かのSIPクライアントと共に相互運用性を明らかに壊します。 したがって、この拡張子はすべてのクライアントがこの拡大を実装するか、またはTLSを使用できるのがどうにか確実にされる環境で使用されるべきです。 また、この拡張子はまた、交信できないオプションを受け入れるなら不安定なコミュニケーションが許容できない環境で使用されるかもしれません。
4. Examples
4. 例
The following examples illustrate the use of the mechanism defined above.
以下の例は上で定義されたメカニズムの使用を例証します。
4.1 Client Initiated
4.1 開始されたクライアント
A UA negotiates the security mechanism to be used with its outbound proxy without knowing beforehand which mechanisms the proxy supports. The OPTIONS method can be used here to request the security capabilities of the proxy. In this way, the security can be initiated even before the first INVITE is sent via the proxy.
UAは、あらかじめプロキシがどのメカニズムをサポートするかを知らない外国行きのプロキシと共に使用されるためにセキュリティー対策を交渉します。 プロキシのセキュリティ能力を要求するのにここでOPTIONSメソッドを使用できます。 このように、プロキシを通して最初のINVITEを送る前にさえセキュリティを開始できます。
UAC Proxy UAS
| | |
|----(1) OPTIONS---->| |
| | |
|<-----(2) 494-------| |
| | |
|<=======TLS========>| |
| | |
|----(3) INVITE----->| |
| |----(4) INVITE--->|
| | |
| |<---(5) 200 OK----|
|<---(6) 200 OK------| |
| | |
|------(7) ACK------>| |
| |-----(8) ACK----->|
| | |
| | |
| | |
| | |
UACプロキシUAS| | | |----(1) オプション---->|、|、|、|、| | <、-、-、-、--(2) 494-------| | | | | |<====TLS========>|、|、|、|、| |----(3) 招待----->|、|、| |----(4) 招待--->|、|、|、|、| | <、-、--(5) 200 OK----| | <、-、--(6) 200 OK------| | | | | |------(7) ACK------>|、|、| |-----(8) ACK----->|、|、|、|、|、|、|、|、|、|、|、|、|
Figure 2: Negotiation Initiated by the Client.
図2: クライアントによって開始された交渉。
Arkko, et. al. Standards Track [Page 12] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[12ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
The UAC sends an OPTIONS request to its outbound proxy, indicating at the same time that it is able to negotiate security mechanisms and that it supports TLS and HTTP Digest (1).
UACはOPTIONS要求を外国行きのプロキシに送ります、同時にTLSとHTTP Digestが(1)であるとセキュリティー対策を交渉できて、サポートするのを示して。
The outbound proxy responds to the UAC with its own list of security mechanisms - IPsec and TLS (2). The only common security mechanism is TLS, so they establish a TLS connection between them. When the connection is successfully established, the UAC sends an INVITE request over the TLS connection just established (3). This INVITE contains the server's security list. The server verifies it, and since it matches its static list, it processes the INVITE and forwards it to the next hop.
外国行きのプロキシはそれ自身のセキュリティー対策のリストでUACに応じます--IPsecとTLS(2)。 唯一の共通の安全保障メカニズムがTLSであるので、彼らは彼らの間のTLS接続を確立します。 接続が首尾よく確立されるとき、UACはTLS接続の上のINVITE要求にちょうど確立した(3)を送ります。 このINVITEはサーバの軍事機密事項を含んでいます。 サーバがそれについて確かめて、静的なリストを合わせるので、それは、INVITEを処理して、次のホップにそれを送ります。
If this example was run without Security-Server header in Step 2, the UAC would not know what kind of security the other one supports, and would be forced to error-prone trials.
この例がStep2でSecurity-サーバヘッダーなしで実行されるなら、UACはもう片方がどういうセキュリティをサポートするかを知らないで、誤り傾向があるトライアルに強制されるでしょうに。
More seriously, if the Security-Verify was omitted in Step 3, the whole process would be prone for MitM attacks. An attacker could spoof "ICMP Port Unreachable" message on the trials, or remove the stronger security option from the header in Step 1, therefore substantially reducing the security.
省略されたコネはStep3、全体のプロセスでした。より真剣である、Security検証、MitM攻撃において、傾向があるでしょう。 攻撃者は、トライアルのときに「ICMPポート手の届かない」メッセージを偽造するか、またはStep1でヘッダーから、より強いセキュリティオプションを取り除くことができました、したがって、かなり、セキュリティを下げます。
(1) OPTIONS sip:proxy.example.com SIP/2.0
Security-Client: tls
Security-Client: digest
Require: sec-agree
Proxy-Require: sec-agree
(1)OPTIONS一口: proxy.example.com SIP/2.0Security-クライアント: tls Security-クライアント: Requireを読みこなしてください: 以下をProxy必要とするように秒同意してください。 秒同意してください。
(2) SIP/2.0 494 Security Agreement Required
Security-Server: ipsec-ike;q=0.1
Security-Server: tls;q=0.2
(2) 一口/2.0 494担保契約はセキュリティサーバを必要としました: ipsec-ike;、q=0.1 Security-サーバ: tls; q=0.2
(3) INVITE sip:proxy.example.com SIP/2.0
Security-Verify: ipsec-ike;q=0.1
Security-Verify: tls;q=0.2
Route: sip:callee@domain.com
Require: sec-agree
Proxy-Require: sec-agree
(3)INVITE一口: proxy.example.com SIP/2.0は以下についてSecurity確かめます。 ipsec-ike; 以下についてq=0.1 Security確かめてください。 tls;、q=0.2 Route: 一口: callee@domain.com Require: 以下をProxy必要とするように秒同意してください。 秒同意してください。
The 200 OK response (6) for the INVITE and the ACK (7) are also sent over the TLS connection. The ACK will contain the same Security- Verify header field as the INVITE (3).
また、INVITEとACK(7)のための200OK応答(6)をTLS接続の上に送ります。 ACKは含むでしょう。同じSecurityは、INVITE(3)をヘッダーフィールドについて確かめます。
Arkko, et. al. Standards Track [Page 13] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[13ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
4.2 Server Initiated
4.2 開始されたサーバ
In this example of Figure 3 the client sends an INVITE towards the callee using an outbound proxy. This INVITE does not contain any Require header field.
図3に関するこの例では、クライアントは、外国行きのプロキシを使用することで訪問される人に向かってINVITEを送ります。 このINVITEは少しのRequireヘッダーフィールドも含んでいません。
UAC Proxy UAS
| | |
|-----(1) INVITE---->| |
| | |
|<-----(2) 421-------| |
| | |
|------(3) ACK------>| |
| | |
|<=======IKE========>| |
| | |
|-----(4) INVITE---->| |
| |----(5) INVITE--->|
| | |
| |<---(6) 200 OK----|
|<----(7) 200 OK-----| |
| | |
|------(8) ACK------>| |
| |-----(9) ACK----->|
| | |
| | |
UACプロキシUAS| | | |-----(1) 招待---->|、|、|、|、| | <、-、-、-、--(2) 421-------| | | | | |------(3) ACK------>|、|、|、|、| |<====イケ========>|、|、|、|、| |-----(4) 招待---->|、|、| |----(5) 招待--->|、|、|、|、| | <、-、--(6) 200 OK----| | <、-、-、--(7) 200 OK-----| | | | | |------(8) ACK------>|、|、| |-----(9) ACK----->|、|、|、|、|、|、|
Figure 3: Server Initiated Security Negotiation.
図3: サーバはセキュリティ交渉を開始しました。
The proxy, following its local policy, does not accept the INVITE. It returns a 421 (Extension Required) with a Security-Server header field that lists IPsec-IKE and TLS. Since the UAC supports IPsec-IKE it performs the key exchange and establishes a security association with the proxy.
ローカルの方針に従って、プロキシはINVITEを受け入れません。 それはIPsec-IKEとTLSを記載するSecurity-サーバヘッダーフィールドがある421(拡大Required)を返します。 UACがIPsec-IKEをサポートするので、それは、主要な交換を実行して、プロキシとのセキュリティ仲間を設立します。
The second INVITE (4) and the ACK (8) contain a Security-Verify header field that mirrors the Security-Server header field received in the 421. The INVITE (4), the 200 OK (7) and the ACK (8) are sent using the security association that has been established.
INVITE(4)とACK(8)がaを含む秒に、421で受け取られたSecurity-サーバヘッダーフィールドを反映するヘッダーフィールドについてSecurity確かめてください。 INVITE(4)、200OK(7)、およびACK(8)に設立されたセキュリティ協会を使用させます。
(1) INVITE sip:uas.example.com SIP/2.0
(1)INVITE一口: uas.example.com SIP/2.0
(2) SIP/2.0 421 Extension Required
Security-Server: ipsec-ike;q=0.1
Security-Server: tls;q=0.2
(2) 一口/2.0 421拡張子はセキュリティサーバを必要としました: ipsec-ike;、q=0.1 Security-サーバ: tls; q=0.2
Arkko, et. al. Standards Track [Page 14] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[14ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
(4) INVITE sip:uas.example.com SIP/2.0
Security-Verify: ipsec-ike;q=0.1
Security-Verify: tls;q=0.2
(4)INVITE一口: uas.example.com SIP/2.0は以下についてSecurity確かめます。 ipsec-ike; 以下についてq=0.1 Security確かめてください。 tls; q=0.2
5. Security Considerations
5. セキュリティ問題
This specification is about making it possible to select between various SIP security mechanisms in a secure manner. In particular, the method presented herein allow current networks using, for instance, HTTP Digest, to be securely upgraded to, for instance, IPsec without requiring a simultaneous modification in all equipment. The method presented in this specification is secure only if the weakest proposed mechanism offers at least integrity and replay protection for the Security-Verify header field.
この仕様はそれを様々なSIPセキュリティー対策の間で安全な方法で選択するのにおいて可能にすることに関するものです。 特に、ここに提示されたメソッドは、しっかりとすべての設備における同時の変更を必要としないで例えば、IPsecにアップグレードするのに例えばHTTP Digestを使用することで現在のネットワークを許容します。 最も弱い場合にだけなる提案されたメカニズムが少なくとも保全と反復操作による保護を提供するこの仕様に提示されたメソッドが安全である、ヘッダーフィールドについてSecurity確かめてください。
The security implications of this are subtle, but do have a fundamental importance in building large networks that change over time. Given that the hashes are produced also using algorithms agreed in the first unprotected messages, one could ask what the difference in security really is. Assuming integrity protection is mandatory and only secure algorithms are used, we still need to prevent MitM attackers from modifying other parameters, such as whether encryption is provided or not. Let us first assume two peers capable of using both strong and weak security. If the initial offers are not protected in any way, any attacker can easily "downgrade" the offers by removing the strong options. This would force the two peers to use weak security between them. But if the offers are protected in some way -- such as by hashing, or repeating them later when the selected security is really on -- the situation is different. It would not be sufficient for the attacker to modify a single message. Instead, the attacker would have to modify both the offer message, as well as the message that contains the hash/ repetition. More importantly, the attacker would have to forge the weak security that is present in the second message, and would have to do so in real time between the sent offers and the later messages. Otherwise, the peers would notice that the hash is incorrect. If the attacker is able to break the weak security, the security method and/or the algorithm should not be used.
このセキュリティ含意は微妙ですが、時間がたつにつれて、大きいネットワークにそれを建てることにおける基本的な重要性を変えさせてください。 ハッシュがまた、最初の保護のないメッセージで同意されるアルゴリズムを使用することで生産されるなら、人は、セキュリティの違いが本当に何であるかを尋ねるかもしれません。 保全保護が義務的であり、安全なアルゴリズムだけが使用されていると仮定して、私たちは、まだMitM攻撃者が他のパラメタを変更するのを防ぐ必要があります、暗号化を提供するのなどように。 最初に、2人の同輩が強いものと同様に弱いセキュリティを使用できると仮定しましょう。 初期の申し出が何らかの方法で保護されないなら、どんな攻撃者も、強いオプションを取り除くことによって、容易に申し出を「格下げできます」。 これによって、2人の同輩がやむを得ず彼らの間の弱いセキュリティを使用するでしょう。 --選択されたセキュリティが本当にオンであるときに、申し出が後でそれらを論じ尽くすか、または繰り返すことなどの何らかの方法で保護されるならしかし、状況は異なっています。 攻撃者がただ一つのメッセージを変更するのは、十分でないでしょう。 代わりに、攻撃者は申し出メッセージとハッシュ/反復を含むメッセージの両方を変更しなければならないでしょう。 より重要に、攻撃者は、2番目のメッセージで存在している弱いセキュリティを鍛造しなければならなくて、リアルタイムで、送られた申し出と、より遅いメッセージの間でそうしなければならないでしょう。 さもなければ、同輩は、ハッシュが不正確であるのに気付くでしょう。 攻撃者が弱いセキュリティを壊すことができるなら、セキュリティメソッド、そして/または、アルゴリズムを使用するべきではありません。
In conclusion, the security difference is making a trivial attack possible versus demanding the attacker to break algorithms. An example of where this has a serious consequence is when a network is first deployed with integrity protection (such as HTTP Digest [4]), and then later new devices are added that support also encryption (such as TLS [3]). In this situation, an insecure negotiation procedure allows attackers to trivially force even new devices to use only integrity protection.
これが深刻な結果を持っているところに関する例がネットワークが最初に保全保護で配布される時である、((TLS[3])などのように。結論として、セキュリティ差で、些細な攻撃はアルゴリズムを破るために攻撃者を要求することに対して可能になっています。また、暗号化をサポートするHTTP Digest[4])としてそのようで、次に、後の新しいデバイスが加えられます。 この状況で、不安定な交渉手順で、攻撃者は新しいデバイスにさえ強制的に保全保護しか些細なことに使用させることができません。
Arkko, et. al. Standards Track [Page 15] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[15ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
Possible attacks against the security agreement include:
担保契約に対する可能な攻撃は:
1. Attackers could try to modify the server's list of security
mechanisms in the first response. This would be revealed to the
server when the client returns the received list using the
security.
1. 攻撃者は最初の応答でサーバのセキュリティー対策のリストを変更しようとすることができました。 クライアントがセキュリティを使用することで受信されたリストを返すとき、これはサーバに明らかにされるでしょう。
2. Attackers could also try to modify the repeated list in the second
request from the client. However, if the selected security
mechanism uses encryption this may not be possible, and if it uses
integrity protection any modifications will be detected by the
server.
2. また、攻撃者はクライアントからの2番目の要求における繰り返されたリストを変更しようとすることができました。 しかしながら、選択されたセキュリティー対策が暗号化を使用するなら、これは可能でないかもしれません、そして、それが保全保護を使用すると、どんな変更もサーバによって検出されるでしょう。
3. Attackers could try to modify the client's list of security
mechanisms in the first message. The client selects the security
mechanism based on its own knowledge of its own capabilities and
the server's list, hence the client's choice would be unaffected
by any such modification. However, the server's choice could
still be affected as described below:
3. 攻撃者は最初のメッセージでクライアントのセキュリティー対策のリストを変更しようとすることができました。 クライアントはそれ自身の能力とサーバのリストに関するそれ自身の知識に基づくセキュリティー対策を選択します、したがって、クライアントの選択はどんなそのような変更でも影響を受けないでしょう。 しかしながら、サーバの選択は以下で説明されるようにまだ影響を受けることができました:
* If the modification affected the server's choice, the server
and client would end up choosing different security mechanisms
in Step 3 or 4 of Figure 1. Since they would be unable to
communicate to each other, this would be detected as a
potential attack. The client would either retry or give up in
this situation.
* 変更がサーバの選択に影響するなら、サーバとクライアントは結局、図1のStep3か4の異なったセキュリティー対策を選ぶでしょうに。 彼らは互いに交信できないでしょう、したがって、これが起こり得るかもしれない攻撃として検出されるでしょう。 クライアントは、この状況で再試行するか、またはあきらめるでしょう。
* If the modification did not affect the server's choice, there's
no effect.
* 変更がサーバの選択に影響しなかったなら、効果が全くありません。
4. Finally, attackers may also try to reply old security agreement
messages. Each security mechanism must provide replay protection.
In particular, HTTP Digest implementations should carefully
utilize existing reply protection options such as including a
time-stamp to the nonce parameter, and using nonce counters [4].
4. また、最終的に、攻撃者は古い担保契約メッセージを回答に試みるかもしれません。 各セキュリティー対策は反復操作による保護を提供しなければなりません。 特に、HTTP Digest実装は一回だけのパラメタにタイムスタンプを含めて、一回だけのカウンタ[4]を使用するのなどように慎重に既存の回答保護オプションを利用するべきです。
All clients that implement this specification MUST select HTTP Digest, TLS, IPsec, or any stronger method for the protection of the second request.
この仕様を履行するすべてのクライアントがHTTP Digest、TLS、IPsec、または2番目の要求の保護のためのどんなより強いメソッドも選択しなければなりません。
Arkko, et. al. Standards Track [Page 16] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[16ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
6. IANA Considerations
6. IANA問題
This specification defines a new mechanism-name namespace in Section 2.2 which requires a central coordinating body. The body responsible for this coordination is the Internet Assigned Numbers Authority (IANA).
この仕様は中央の調整ボディーを必要とするセクション2.2で新しいメカニズム名の名前空間を定義します。 このコーディネートに原因となるボディーはインターネットAssigned民数記Authority(IANA)です。
This document defines four mechanism-names to be initially registered, namely "digest", "tls", "ipsec-ike", and "ipsec-man". In addition to these mechanism-names, "ipsec-3gpp" mechanism-name is also registered (see Appendix A). Following the policies outlined in [10], further mechanism-names are allocated based on IETF Consensus.
このドキュメントは初めは、登録されて、すなわち「読みこなす」4つのメカニズム名、"tls"、"ipsec-ike"、および「ipsec-男性」を定義します。 また、これらのメカニズム名に加えて、"ipsec-3gpp"メカニズム名は登録されます(Appendix Aを見てください)。 [10]に概説された方針に従って、IETF Consensusに基づいてさらなるメカニズム名を割り当てます。
Registrations with the IANA MUST include the mechanism-name token being registered, and a pointer to a published RFC describing the details of the corresponding security mechanism.
IANA MUSTとの登録証明書は対応するセキュリティー対策の細部について説明する発行されたRFCに登録されるメカニズム名のトークン、および指針を含んでいます。
6.1 Registration Information
6.1 レジスト情報
IANA registers new mechanism-names at http://www.iana.org/assignments/sip-parameters under "Security Mechanism Names". As this document specifies five mechanism-names, the initial IANA registration for mechanism-names will contain the information shown in Table 2. It also demonstrates the type of information maintained by the IANA.
IANAは http://www.iana.org/assignments/sip-parameters に「セキュリティー対策名」の下で新しいメカニズム名を登録します。 このドキュメントが5つのメカニズム名を指定するとき、メカニズム名のための初期のIANA登録はTable2に示された情報を含むでしょう。 また、それはIANAによって維持された情報の種類のデモをします。
Mechanism Name Reference
-------------- ---------
digest [RFC3329]
tls [RFC3329]
ipsec-ike [RFC3329]
ipsec-man [RFC3329]
ipsec-3gpp [RFC3329]
メカニズム名前参照-------------- --------- ダイジェスト[RFC3329]tls[RFC3329]ipsec-ike[RFC3329]ipsec-男性[RFC3329]ipsec-3gpp[RFC3329]
Table 2: Initial IANA registration.
テーブル2: IANA登録に頭文字をつけてください。
6.2 Registration Template
6.2 登録テンプレート
To: ietf-sip-sec-agree-mechanism-name@iana.org
Subject: Registration of a new SIP Security Agreement mechanism
To: ietf-sip-sec-agree-mechanism-name@iana.org Subject: 新しいSIP Security Agreementメカニズムの登録
Mechanism Name:
メカニズム名:
(Token value conforming to the syntax described in
Section 2.2.)
(セクション2.2で説明された構文に従うトークン値。)
Arkko, et. al. Standards Track [Page 17] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[17ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
Published Specification(s):
広められた仕様:
(Descriptions of new SIP Security Agreement mechanisms
require a published RFC.)
(新しいSIP Security Agreementメカニズムの記述は発行されたRFCを必要とします。)
6.3 Header Field Names
6.3 ヘッダーフィールド名
This specification registers three new header fields, namely Security-Client, Security-Server and Security-Verify. These headers are defined by the following information, which has been included in the sub-registry for SIP headers under http://www.iana.org/assignments/sip-parameters.
そして、この仕様が3つの新しいヘッダーフィールド、Security-クライアント、すなわち、Security-サーバを登録する、Security確かめます。 これらのヘッダーは以下の情報によって定義されます。(それは、 http://www.iana.org/assignments/sip-parameters の下のSIPヘッダーのためのサブ登録に含まれています)。
Header Name: Security-Client
Compact Form: (none)
ヘッダー名: セキュリティクライアントコンパクト形: (なにも)
Header Name: Security-Server
Compact Form: (none)
ヘッダー名: セキュリティサーバコンパクト形: (なにも)
Header Name: Security-Verify
Compact Form: (none)
ヘッダー名: コンパクト形について安全に確かめてください: (なにも)
6.4 Response Codes
6.4 応答コード
This specification registers a new response code, namely 494 (Security Agreement Required). The response code is defined by the following information, which has been included to the sub-registry for SIP methods and response-codes under http://www.iana.org/assignments/sip-parameters.
この仕様は新しい応答コード、すなわち、494(セキュリティAgreement Required)を登録します。 応答コードは以下の情報によって定義されます。(それは、 http://www.iana.org/assignments/sip-parameters の下にSIPメソッドと応答コードのためのサブ登録に含まれています)。
Response Code Number: 494
Default Reason Phrase: Security Agreement Required
応答コード番号: 494デフォルト理由句: 担保契約が必要です。
6.5 Option Tags
6.5 オプションタグ
This specification defines a new option tag, namely sec-agree. The option tag is defined by the following information, which has been included in the sub-registry for option tags under http://www.iana.org/assignments/sip-parameters.
この仕様はタグで、すなわち、秒同意していた状態で新しいオプションを定義します。 オプションタグは以下の情報によって定義されます。(それは、 http://www.iana.org/assignments/sip-parameters の下のオプションタグのためのサブ登録に含まれています)。
Arkko, et. al. Standards Track [Page 18] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[18ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
Name: sec-agree
Description: This option tag indicates support for the Security
Agreement mechanism. When used in the Require, or
Proxy-Require headers, it indicates that proxy servers
are required to use the Security Agreement mechanism.
When used in the Supported header, it indicates that
the User Agent Client supports the Security Agreement
mechanism. When used in the Require header in the 494
(Security Agreement Required) or 421 (Extension
Required) responses, it indicates that the User Agent
Client must use the Security Agreement Mechanism.
以下を命名してください。 記述に秒同意してください: このオプションタグはSecurity Agreementメカニズムのサポートを示します。 いつが、ヘッダーをRequireで使用するか、またはProxy必要とするか、そして、それは、プロキシサーバがSecurity Agreementメカニズムを使用するのに必要であることを示します。 Supportedヘッダーで使用されると、それは、UserエージェントClientがSecurity Agreementメカニズムをサポートするのを示します。 Requireヘッダーで494(セキュリティAgreement Required)か421(拡大Required)の応答に使用されると、それは、UserエージェントClientがSecurity Agreement Mechanismを使用しなければならないのを示します。
7. Contributors
7. 貢献者
Sanjoy Sen and Lee Valerius from Nortel Networks have contributed to the document.
ノーテルNetworksからのSanjoy SenとリーValeriusはドキュメントに貢献しました。
8. Acknowledgements
8. 承認
In addition to the contributors, the authors wish to thank Allison Mankin, Rolf Blom, James Undery, Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister Boman, David Castellanos-Zamora, Miguel Garcia, Valtteri Niemi, Martin Euchner, Eric Rescorla and members of the 3GPP SA3 group for interesting discussions in this problem space.
貢献者に加えて、作者はこの問題スペースでの興味深い議論について3GPP SA3グループのアリソン・マンキン、ロルフ・ブロム、ジェームスUndery、ジョナサン・ローゼンバーグ、ヒューShieh、ガンサーHorn、Krister Boman、デヴィッド・カステラノス-サモラ、ミゲル・ガルシア、Valtteri Niemi、マーチンEuchner、エリック・レスコラ、およびメンバーに感謝したがっています。
9. Normative References
9. 引用規格
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[2] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[3] Dierks, T. and C. Allen, P. Kocher, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[3] DierksとT.とC.アレン、P.コッハー、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[4] 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.
[4] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] ローゼンバーグ、J.、およびH.Schulzrinne、「セッション開始は(一口)について議定書の中で述べます」。 「一口サーバの場所を見つけます」、RFC3263、2002年6月。
[6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[6] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
Arkko, et. al. Standards Track [Page 19] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[19ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
[7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[7] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[8] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[10]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
10. Informative References
10. 有益な参照
[11] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP)
Release 5 requirements on the Session Initiation Protocol
(SIP)", Work in Progress.
[11] ガルシア-マーチン、M.、「第3世代Partnership Project(3GPP)はSession Initiationプロトコル(SIP)で5つの要件をリリースする」ProgressのWork。
[12] 3rd Generation Partnership Project, "Access security for IP-
based services, Release 5", TS 33.203 v5.3.0, September 2002.
[12] 第3世代Partnership Project、「IPのためのアクセス保護がサービス、Releaseを何5インチも基礎づけて、TS33.203がv5.3.0であり、9月は2002です」。
[13] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and
AH", RFC 2403, November 1998.
そして、[13] マドソン、C.、およびR.グレン、「超能力の中のHMAC-MD5-96の使用、ああ、」、RFC2403、11月1998日
[14] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
and AH", RFC 2404, November 1998.
そして、[14] マドソン、C.、およびR.グレン、「超能力の中のHMAC-SHA-1-96の使用、ああ、」、RFC2404、11月1998日
[15] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms",
RFC 2451, November 1998.
[15] ペレイラとR.とR.アダムス、「超能力CBC-モード暗号アルゴリズム」、RFC2451、1998年11月。
Arkko, et. al. Standards Track [Page 20] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[20ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
Appendix A. Syntax of ipsec-3gpp
ipsec-3gppの付録A.Syntax
This appendix extends the security agreement framework described in this document with a new security mechanism: "ipsec-3gpp". This security mechanism and its associated parameters are used in the 3GPP IP Multimedia Subsystem [12]. The Augmented BNF definitions below follow the syntax of SIP [1].
この付録は本書では新しいセキュリティー対策で説明された担保契約フレームワークを広げています: "ipsec-3gpp"。 このセキュリティー対策とその関連パラメタは3GPP IP Multimedia Subsystem[12]で使用されます。 以下でのAugmented BNF定義はSIP[1]の構文に従います。
mechanism-name = ( "ipsec-3gpp" )
mech-parameters = ( algorithm / protocol /mode /
encrypt-algorithm / spi /
port1 / port2 )
algorithm = "alg" EQUAL ( "hmac-md5-96" /
"hmac-sha-1-96" )
protocol = "prot" EQUAL ( "ah" / "esp" )
mode = "mod" EQUAL ( "trans" / "tun" )
encrypt-algorithm = "ealg" EQUAL ( "des-ede3-cbc" / "null" )
spi = "spi" EQUAL spivalue
spivalue = 10DIGIT; 0 to 4294967295
port1 = "port1" EQUAL port
port2 = "port2" EQUAL port
port = 1*DIGIT
プロトコル="prot"EQUAL(「ああ」/"esp")モードは「モッズ」EQUALと等しいです。メカニズム名の=("ipsec-3gpp")mech-パラメタがアルゴリズム="alg"EQUALと等しい、(アルゴリズム/プロトコル/mode / encrypt-アルゴリズム/spi/port1/port2)(「hmac-md5-96インチ/、「hmac-sha1、96インチ、)、(「移-」 /「大酒樽」) アルゴリズムを暗号化している="ealg"EQUAL("des-ede3-cbc"/「ヌル」)spi="spi"EQUAL spivalue spivalueは10DIGITと等しいです」。 0〜4294967295port1が等しい、「port1" EQUALポートport2は「port2" EQUALポートポートは1*DIGITと等しいこと」と等しいです。
The parameters described by the BNF above have the following semantics:
上のBNFによって説明されたパラメタは以下の意味論を持っています:
Algorithm
This parameter defines the used authentication algorithm. It
may have a value of "hmac-md5-96" for HMAC-MD5-96 [13], or
"hmac-sha-1-96" for HMAC-SHA-1-96 [14]. The algorithm
parameter is mandatory.
アルゴリズムThisパラメタは中古の認証アルゴリズムを定義します。 または、それには値があるかもしれない、「hmac-md5-96インチ、HMAC-MD5-96[13]、「hmac-sha、1、96インチ、HMAC-SHA-1-96[14]、」 アルゴリズムパラメタは義務的です。
Protocol
This parameter defines the IPsec protocol. It may have a value
of "ah" for AH [6], or "esp" for ESP [7]. If no Protocol
parameter is present, the protocol will be ESP by default.
プロトコルThisパラメタはIPsecプロトコルを定義します。 それには、AHのための「ああ」、[6]、または超能力[7]のための"esp"の値があるかもしれません。 どんなプロトコルパラメタも存在していないと、プロトコルはデフォルトで超能力になるでしょう。
Mode
This parameter defines the mode in which the IPsec protocol is
used. It may have a value of "trans" for transport mode, or a
value of "tun" for tunneling mode. If no Mode parameter is
present the IPsec protocol is used in transport mode.
モードThisパラメタはIPsecプロトコルが使用されているモードを定義します。 それには値があるかもしれない、「移-、」 交通機関、またはトンネリングモードのための「大酒樽」の値のために。 どんなModeパラメタも存在していないなら、IPsecプロトコルは交通機関で使用されます。
Encrypt-algorithm
This parameter defines the used encryption algorithm. It may
have a value of "des-ede3-cbc" for 3DES [15], or "null" for no
encryption. If no Encrypt-algorithm parameter is present,
encryption is not used.
アルゴリズムを暗号化しているThisパラメタは中古の暗号化アルゴリズムを定義します。 それには、3DES[15]のための"des-ede3-cbc"、または暗号化でない「ヌル」の値があるかもしれません。 どんなEncrypt-アルゴリズムパラメタも存在していないなら、暗号化は使用されていません。
Arkko, et. al. Standards Track [Page 21] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[21ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
Spi
Defines the SPI number used for inbound messages.
SPI番号が本国行きのメッセージに使用したSpi Defines。
Port1
Defines the destination port number for inbound messages that
are protected.
仕向港が保護される本国行きのメッセージのために付番するPort1 Defines。
Port2
Defines the source port number for outbound messages that are
protected. Port 2 is optional.
ソースポートが保護される外国行きのメッセージのために付番するPort2 Defines。 ポート2は任意です。
The communicating SIP entities need to know beforehand which keys to use. It is also assumed that the underlying IPsec implementation supports selectors that allow all transport protocols supported by SIP to be protected with a single SA. The duration of security association is the same as in the expiration interval of the corresponding registration binding.
交信しているSIP実体は、あらかじめどのキーを使用したらよいかを知る必要があります。 また、基本的なIPsec実装がSIPによってサポートされたすべてのトランスポート・プロトコルが独身のSAと共に保護されるのを許容するセレクタを支えると思われます。 セキュリティ協会の持続時間は対応する登録結合の満了間隔と同じです。
Arkko, et. al. Standards Track [Page 22] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[22ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
Authors' Addresses
作者のアドレス
Jari Arkko Ericsson Jorvas, FIN 02420 Finland
ヤリArkkoエリクソンJorvas、FIN02420フィンランド
Phone: +358 40 507 9256 EMail: jari.arkko@ericsson.com
以下に電話をしてください。 +358 40 507 9256はメールされます: jari.arkko@ericsson.com
Vesa Torvinen Ericsson Joukahaisenkatu 1 Turku, FIN 20520 Finland
Vesa TorvinenエリクソンJoukahaisenkatu1FIN20520トゥルク(フィンランド)
Phone: +358 40 723 0822 EMail: vesa.torvinen@ericsson.fi
以下に電話をしてください。 +358 40 723 0822はメールされます: vesa.torvinen@ericsson.fi
Gonzalo Camarillo Advanced Signalling Research Lab. Ericsson FIN-02420 Jorvas Finland
ゴンサロ・キャマリロは合図研究研究室を進めました。 エリクソンフィン-02420Jorvasフィンランド
Phone: +358 40 702 3535 EMail: Gonzalo.Camarillo@ericsson.com
以下に電話をしてください。 +358 40 702 3535はメールされます: Gonzalo.Camarillo@ericsson.com
Aki Niemi NOKIA Corporation P.O.Box 321, FIN 00380 Finland
アキNiemiノキア社の私書箱321、FIN00380フィンランド
Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com
以下に電話をしてください。 +358 50 389 1644はメールされます: aki.niemi@nokia.com
Tao Haukka Nokia Corporation P.O. Box 50 FIN - 90570 Oulu Finland
タオHaukkaノキア社の私書箱50フィン--90570オウルフィンランド
Phone: +358 40 517 0079 EMail: tao.haukka@nokia.com
以下に電話をしてください。 +358 40 517 0079はメールされます: tao.haukka@nokia.com
Arkko, et. al. Standards Track [Page 23] RFC 3329 SIP Security Agreement January 2003
et Arkko、アル。 標準化過程[23ページ]RFC3329は担保契約2003年1月にちびちび飲みます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Arkko, et. al. Standards Track [Page 24]
et Arkko、アル。 標準化過程[24ページ]
一覧
スポンサーリンク
