Network Working Group J. Arkko
Request for Comments: 3329 V. Torvinen
Category: Standards Track G. Camarillo
Ericsson
A. Niemi
T. Haukka
Nokia
January 2003
Security Mechanism Agreement for the
Session Initiation Protocol (SIP)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
この文書では、セッション開始プロトコル（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
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
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.
本明細書の目的は、セッション開始プロトコル（SIP）のためのネゴシエーション機能を定義することである[1]。この交渉は、唯一のUAとその最初のホップSIPエンティティ間で動作するように意図されます。
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は、特定の攻撃に対して脆弱です。複数の代替方法及びアルゴリズムを使用して認証と完全性保護（例えば、[4]参照）MITM（中間者）攻撃に対して脆弱です。
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 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. 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.保障協定プロセスが関与するエンティティによって維持されるように任意の追加の状態を導入してはなりません。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[9]。
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
Figure 1: Security agreement message flow.
図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：この仕様を使用したいクライアントは、サーバーへの最初の要求に沿って、そのサポートされるセキュリティメカニズムのリストを送信することができます。
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.
必要に応じてステップ1と2の間に、サーバーは、非自己記述型のセキュリティ機構を設定してもよいです。セキュリティメカニズムのこのタイプで、サーバが必ずしもステートフルであることに注意してください。クライアントは、ステップ2と4の間に非自己記述のセキュリティメカニズムを設定します。
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ヘッダフィールド、すなわちセキュリティ・クライアント、セキュリティ・サーバと定義するセキュリティを、確認してください。このセクションのシンタックス要素のための増大している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秒機構）セキュリティサーバ= "セキュリティサーバ" HCOLON秒-機構*（COMMA秒機構）セキュリティ検証= "セキュリティを確認します" HCOLON SEC-機構*（COMMA SEC-機構）
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-メカニズム=機構名*（SEMIメカパラメータ）機構名=（ "ダイジェスト" / "TLS" / "IPSecでIKE" / "IPSecの人" /トークン）メカパラメータ=（優先/ digest-アルゴリズム/ダイジェストQOP /消化ベリファイ/拡張）優先= "Q" EQUALのqvalueのqvalue =（ "0" [ "" 0 * 3DIGIT]）/（ "1" [ "" * 3 0（ "0" ）]）= "D-ALG" アルゴリズムダイジェストEQUALトークンダイジェストQOP = "D-QOPは" EQUALトークン= "D-VER" EQUAL LDQUOT 32LHEX RDQUOT拡張= 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:
メカニズム名は、このトークンは、セキュリティクライアントのヘッダフィールドに表示されたときに、クライアントがサポートするセキュリティ・メカニズムを識別します。またはサーバーによって、それはセキュリティ・サーバまたはセキュリティを確認したヘッダフィールドに表示されたとき。メカニズム名トークンはIANAに登録されています。この仕様は四つの値を定義します。
* "tls" for TLS [3].
* TLSのための "TLS" [3]。
* "digest" for HTTP Digest [4].
* HTTPダイジェストのための "ダイジェスト" [4]。
* "ipsec-ike" for IPsec with IKE [2].
* "のIPSec-IKE" IKEとIPsecの[2]。
* "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.
ダイジェストアルゴリズムは、このオプションのパラメータは、HTTPダイジェストアルゴリズムパラメータの入札ダウン攻撃を防ぐためにのみHTTPダイジェスト[4]のためにここで定義されています。フィールドの内容は、「アルゴリズム」フィールドの[4]で定義されるように同じ値を有していてもよいです。
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.
ダイジェストQOPは、このオプションのパラメータは、HTTPダイジェストQOPパラメータの入札ダウン攻撃を防ぐためにのみHTTPダイジェスト[4]のためにここで定義されています。フィールドの内容は、「QOP」フィールドの[4]で定義されるように同じ値を有していてもよいです。
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:
このオプションパラメータは、SIPのセキュリティメカニズム協定（本書）の入札ダウン攻撃を防ぐためにのみHTTPダイジェスト[4]のためにここで定義されたダイジェストは、確認してください。フィールドの内容は、セキュリティサーバヘッダフィールドはA2パラメータに含まれていることを除いて、[4]に「要求ダイジェスト」とまったく同じようにカウントされます。 「QOP」ディレクティブの値が「認証」であるか、指定されていない場合は、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].
セキュリティ・サーバのヘッダフィールドのすべての線形空白はダイジェスト・検証パラメータを計算するか、解釈する前に、単一のSPに置き換える必要があります。この方法は、ダイジェスト-URI値、エンティティボディ、および任意の他のHTTPダイジェストパラメータ[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.
[4]本明細書は、HTTPダイジェストへの拡張または変更を導入しないことに留意されたいです。この仕様は唯一のSIPエンティティ間のセキュリティメカニズムのネゴシエーションを保護するために、既存のHTTPダイジェストメカニズムを再使用しています。
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エンティティは、最初のホッププロキシまたはアウトバウンドプロキシと呼ばれています。しかし、読者はユーザエージェントサーバはまた、ユーザエージェントクライアントのためのネクストホップすることができることを心に留めなければなりません。
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 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.
それはで指定されたルールに従っているため、クライアントがサーバーに連絡するTLSを使用して終わる場合は、[5]、クライアントはこの仕様の保障協定の手順を使用してはなりません。クライアントは、[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.
本明細書のセキュリティ契約を使用することを望むクライアントは、要求にセキュリティクライアントヘッダフィールドを追加しなければならない（即ち、要求の宛先が最初のホッププロキシである）、その最初のホッププロキシ宛て。このヘッダーフィールドは、クライアントがサポートしているすべてのセキュリティ・メカニズムのリストが含まれています。クライアントは、このリストに優先パラメータを追加しないでください。クライアントが追加しなければならない、両方の値を持つヘッダフィールドを必要とし、プロキシ要求その要求に「秒-同意します」。
The contents of the Security-Client header field may be used by the server to include any necessary information in its response.
セキュリティ・クライアントヘッダフィールドの内容は、その応答に必要な情報を含めるためにサーバによって使用されてもよいです。
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ヘッダーフィールドが含まれている保護されていない要求を受信したサーバは、494（保障協定必須）応答でクライアントに応答しなければならない「秒-同意します」。サーバは、サーバがサポートするセキュリティ・メカニズムをリストこの応答には、セキュリティ・サーバヘッダーフィールドを追加しなければなりません。サーバーはクライアントの、サーバのリストには、共通のセキュリティメカニズムが存在しない場合でも、応答にそのリストを追加しなければなりません。サーバーのリストには、クライアントのリストの内容に依存してはなりません。
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).
サーバは、セキュリティ・サーバヘッダフィールドに送信するリストでセキュリティクライアントのヘッダフィールドに受信したリストを比較しなければなりません。クライアントがこのレスポンスを受信すると、それは最高の「Q」の値と共通のセキュリティメカニズムを選択します。クライアントがそのメカニズムを開始できるように、したがって、サーバは、必要な情報を追加する必要があり（例えば、HTTPダイジェストのためのプロキシ認証ヘッダフィールド）。
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).
クライアントは、セキュリティ・サーバヘッダフィールドを持つレスポンスを受信すると、クライアントに知られているすべてのメカニズムの中で最も高い「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 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.
攻撃者は、要求のセキュリティクライアントヘッダーフィールドを変更した場合、サーバは、その応答において最高優先値と共通のセキュリティメカニズムを確立するために必要な情報を含まなくてもよい（例えば、プロキシ認証ヘッダフィールドがありません）。応じて、情報の不足などを検出し、クライアントが現在のセキュリティ契約プロセスが中止考慮しなければならない、と前述のように、セキュリティ・クライアントヘッダフィールドを使用して、新しい要求を送信することによって、再び、それを起動しようとするかもしれません。
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".
そのサーバーにクライアントから送信された後続のすべてのSIP要求は、前のステップで開始されたセキュリティメカニズムの使用をしなければなりません。これらの要求は、セキュリティ・サーバのヘッダフィールドに、以前に受信したサーバのリストを反映セキュリティを確認ヘッダフィールドを含まなければなりません。これらの要求にも価値を持つ必要とプロキシが-Requireヘッダーフィールド「SEC-同意」の両方を持たなければなりません。
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.
サーバは、着信要求のセキュリティ確認ヘッダフィールドに記載されているセキュリティメカニズムがサポートされるセキュリティメカニズムのその静的リストに対応することを確認しなければなりません。
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.
で定義された標準のSIPヘッダーフィールドの比較ルール以下の[1]、両方のリストが等価であるとみなされるべき同じ順序で、同じセキュリティ・メカニズムを含有しなければならない、ということに注意してください。また、それぞれの特定のセキュリティ・メカニズムのために、両方のリストでそのパラメータが同じ値を持っている必要があります。
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（保障協定必須）応答でクライアントに反応しなければなりません。この応答は、サポートされているセキュリティ・メカニズムのサーバの未修正のリストを含まなければなりません。リストが変更され、サーバがプロキシでなかった場合、それは「SEC-同意」の両方の要求とプロキシ要求ヘッダーフィールドの値、およびNOの値が残っていないならば、ヘッダフィールドを削除する削除する必要があります。
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).
セキュリティは、2つのSIPエンティティ間で交渉されていたら、別の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のユーザーは、セキュリティ・メカニズムの合意の結果を知らされるべきです。ユーザは、特定のセキュリティ機構を受け入れるように拒否し、ピアとさらにSIP通信を中止することができます。
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 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エントリを持っていることを確認する必要があります。いくつかの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.
本契約のメカニズムを使用することを決定したサーバーに関係なく存在または着信要求のいずれかの要求、プロキシ要求またはサポートされているヘッダフィールドの不在のエントリを介して保護されていないとの要求に挑戦しなければなりません。
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).
ポリシーによって、この仕様を使用する必要があり、必要、プロキシ要求またはサポートされているヘッダフィールドに秒-同意オプションタグを持っていない要求を受信したサーバは421（拡張必須）応答を返さなければなりません。要求がサポートされているヘッダフィールドに秒-同意オプションタグを持っていた場合、それは494（保障協定必須）応答を返さなければなりません。両方の状況では、サーバは、応答して、その中にオプションタグ「SEC-同意」とその能力とRequireヘッダーフィールドをリストセキュリティ・サーバのヘッダフィールドを含まなければなりません。クライアントは、好ましいセキュリティメカニズムを開始できるように、サーバは、必要な情報を追加する必要があり（例えば、HTTPダイジェストのためのプロキシ認証ヘッダフィールド）。
Clients that support the extension defined in this document SHOULD add a Supported header field with a value of "sec-agree".
この文書で定義された拡張をサポートするクライアントは、「SEC-同意」の値がサポートされているヘッダフィールドを追加する必要があります。
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.
クライアントがサーバからセキュリティサーバのヘッダフィールドに受信したリストからセキュリティ・メカニズムを選択したら、それはそのメカニズムを開始します。異なるメカニズムは異なる開始手続きが必要です。
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」を選択した場合、クライアントは、セクション8.1.2の手順を使用して[1]〜[5]のDNS手順への入力として使用されるべきURIを決定します。 URIは、SIP URIであるならば、それは一口であるかのようにしかし、それは、SIPではない、スキームを扱わなければなりません。 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（保障協定必須）応答は、HTTPダイジェスト認証チャレンジが含まれています。クライアントは、HTTPダイジェスト挑戦で同じパラメータを置き換えるために、セキュリティ・サーバのヘッダフィールドにアルゴリズムとQOPパラメータを使用しなければなりません。また、クライアントは2.2で指定されたセキュリティ・サーバのヘッダフィールドを保護するためのセキュリティを確認しヘッダフィールドにダイジェスト検証パラメータを使用する必要があります。
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.
「IPSecの池」を使用するには、クライアントがサーバーへの最初の要求でのRequest-URIのホスト部分へのIKE接続を確立しようとします。 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の資格情報やマニュアルSAが入力されていると同時に設定される方法を説明するために、この仕様の範囲外です。
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の人が使用される場合、キーを配布するために使用される同一のアウトオブバンドメカニズムは、セキュリティアソシエーションの継続時間を定義するために使用されているものとします。
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.
この文書で定義されたヘッダフィールドは、UACとUAS、プロキシ、およびレジストラを含む他のSIPエンティティ間のセキュリティメカニズムを交渉するために使用することができます。 SIPメソッドとプロキシ処理に関連するヘッダの使用に関する情報は、表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
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
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：ヘッダーフィールドはオプションです。
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とサーバーの実装は、この拡張子の有無にかかわらず動作するように構成可能でなければなりません。
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.
このメカニズムを使用するように構成されているサーバは、また、[5]で定義されたルールに基づいてTLSを使用するクライアントからの要求を受け付けてもよいです。この拡張機能をサポートしていない、とTLSをサポートしないクライアントからの要求は、お受けできません。これは明らかに、いくつかのSIPクライアントとの相互運用性を破ります。したがって、この拡張は、何らかの形で、すべてのクライアントは、この拡張機能を実装したりTLSを使用することが可能であることを保証されている環境で使用する必要があります。この拡張機能は、また、通信できないというオプションも受け入れられた場合、安全でない通信が許容できない環境で使用されてもよいです。
The following examples illustrate the use of the mechanism defined above.
以下の実施例は、上記で定義された機構の使用を示します。
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----->|
| | |
| | |
| | |
| | |
Figure 2: Negotiation Initiated by the Client.
図2：クライアントによって開始交渉。
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は、セキュリティメカニズムを交渉することが可能であり、それはTLSとHTTPダイジェスト（1）をサポートしていると同時に示し、そのアウトバウンドプロキシにOPTIONS要求を送信します。
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.
IPsecとTLS（2） - アウトバウンドプロキシは、セキュリティ・メカニズムの独自のリストをUACに応答します。唯一の共通のセキュリティメカニズムは、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.
この例では、ステップ2でセキュリティサーバのヘッダなしで実行された場合、UACは、他の1がサポートするセキュリティの種類を知っているだろう、とエラーが発生しやすいために臨床試験を余儀なくされるだろう。
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.
ステップ3で省略されたセキュリティを確認した場合より真剣に、全体のプロセスはのMITM攻撃の発生しやすいだろう。攻撃者は、試験の「ICMPポート到達不能」メッセージを偽造、又はステップ1のヘッダから強力なセキュリティオプションを削除、従って実質的にセキュリティを低下させる可能性があります。
(1) OPTIONS sip:proxy.example.com SIP/2.0 Security-Client: tls Security-Client: digest Require: sec-agree Proxy-Require: sec-agree
（1）オプションのSIP：proxy.example.com SIP / 2.0セキュリティクライアント：TLSセキュリティクライアント：消化が必要：プロキシは、要求秒、同意：SEC-同意
(2) SIP/2.0 494 Security Agreement Required Security-Server: ipsec-ike;q=0.1 Security-Server: tls;q=0.2
（2）SIP / 2.0 494セキュリティ契約に必要なセキュリティ・サーバ：IPSecでIKE; Q = 0.1セキュリティサーバ：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）SIP INVITE：proxy.example.comをSIP / 2.0セキュリティベリファイ：IPSecでIKE; Q = 0.1セキュリティ確認：TLS; Q = 0.2経路：SIP：callee@domain.com要求：SEC-同意Proxy-を必要：SEC-同意
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).
200 OK応答は、（6）INVITEおよびACK（7）は、TLS接続を介して送信されます。 ACKは、INVITE（3）と同様のセキュリティを確認ヘッダフィールドを含むであろう。
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を送信します。これは、任意のRequireヘッダーフィールドが含まれていませんINVITE。
UAC Proxy UAS
| | |
|-----(1) INVITE---->| |
| | |
|<-----(2) 421-------| |
| | |
|------(3) ACK------>| |
| | |
|<=======IKE========>| |
| | |
|-----(4) INVITE---->| |
| |----(5) INVITE--->|
| | |
| |<---(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を一覧表示し、セキュリティ・サーバのヘッダフィールドと421（拡張必須）を返します。 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）を含んでセキュリティ確認421で受信したセキュリティサーバヘッダーフィールドを反映ヘッダフィールドをINVITE（4）、200 OK（7）とACK（8）確立されたセキュリティアソシエーションを使用して送信されます。
(1) INVITE sip:uas.example.com SIP/2.0
uas.example.com SIP / 2.0：（1）SIPのINVITE
(2) SIP/2.0 421 Extension Required Security-Server: ipsec-ike;q=0.1 Security-Server: tls;q=0.2
（2）SIP / 2.0 421拡張に必要なセキュリティ・サーバ：IPSecでIKE; Q = 0.1セキュリティサーバ：TLS; Q = 0.2
(4) INVITE sip:uas.example.com SIP/2.0 Security-Verify: ipsec-ike;q=0.1 Security-Verify: tls;q=0.2
Q = 0.1セキュリティを確認し、IPSecでIKE：TLS; Q = 0.2 uas.example.com SIP / 2.0セキュリティベリファイ：（4）SIPのINVITE
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セキュリティメカニズム間で選択することが可能となる程度です。特に、本明細書に提示される方法は、HTTPダイジェスト、例えば、使用して、現在のネットワークが確実にすべての機器に同時変更を必要とせずにIPsec、例えば、にアップグレードすることを可能にします。この仕様書で提示する方法は、最も弱い提案されたメカニズムは、セキュリティを確認ヘッダフィールドのための少なくとも整合性とリプレイ保護を提供する場合にのみ安全です。
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.
結論として、セキュリティの違いは、アルゴリズムを破るために、攻撃者を求めて対可能些細な攻撃をしています。ネットワークは最初に（例えば、HTTPダイジェスト[4]のような）完全性保護で展開され、そしてその後、新しいデバイスが追加された場合、これは深刻な結果を有する場合の例であることもサポート暗号化（TLSなど[3]）。このような状況では、安全でないネゴシエーション手順は、攻撃者が自明のみ完全性保護を使用するためにも、新しいデバイスを強制することができます。
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.
変更は、サーバーの選択に影響を与えた場合は、サーバとクライアントは、彼らがお互いに通信することができないので、ステップ3または図1の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ダイジェスト実装は慎重に使用する必要があり、このようなナンスパラメータにタイムスタンプを含む、およびノンスカウンタを使用するなど、既存の返信保護オプション[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ダイジェスト、TLS、IPsecの、または2番目の要求の保護のための任意の強力な方法を選択する必要があります。
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節に新しい機構名の名前空間を定義します。この調整を担当するボディは、Internet Assigned Numbers 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の池」、および「IPSecの人」を定義します。これらのメカニズムの名前に加えて、「IPSecの-3GPP」メカニズム名も登録されている（付録Aを参照してください）。 [10]に概説された方針以下、さらにメカニズム名前はIETFコンセンサスに基づいて割り当てられます。
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に登録は、登録されているトークン機構名、および対応するセキュリティ機構の詳細を説明公開RFCへのポインタを含まなければなりません。
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登録はまた、IANAによって維持される情報の種類を示している。表2に示す情報が含まれています。
Mechanism Name Reference
-------------- ---------
digest [RFC3329]
tls [RFC3329]
ipsec-ike [RFC3329]
ipsec-man [RFC3329]
ipsec-3gpp [RFC3329]
Table 2: Initial IANA registration.
表2：初期IANA登録。
To: ietf-sip-sec-agree-mechanism-name@iana.org
Subject: Registration of a new SIP Security Agreement mechanism
Mechanism Name:
機構名：
(Token value conforming to the syntax described in Section 2.2.)
（トークン値は、2.2節で説明した構文に準拠します）。
Published Specification(s):
公開明細書（S）：
(Descriptions of new SIP Security Agreement mechanisms require a published RFC.)
（新しいSIP保障協定のメカニズムの説明が公開RFCが必要です。）
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つの新しいヘッダフィールド、すなわちセキュリティ・クライアント、セキュリティ・サーバを登録し、セキュリティを確認します。これらのヘッダは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)
ヘッダー名：セキュリティを確認しコンパクトなフォーム：（なし）
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（保障協定必須）登録します。応答コードはhttp://www.iana.org/assignments/sip-parameters下SIPメソッド及びレスポンスコードのサブレジストリに含まれていた次の情報によって定義されます。
Response Code Number: 494 Default Reason Phrase: Security Agreement Required
応答コード番号：494デフォルトの理由フレーズ：保障協定必須
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でオプションタグのサブレジストリに含まれている以下の情報によって定義されます。
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.
名前：秒-同意説明：このオプションタグが保障協定メカニズムのサポートを示します。要求、またはプロキシ要求ヘッダーで使用する場合は、プロキシサーバを保障協定のメカニズムを使用する必要があることを示しています。サポートされているヘッダーで使用する場合は、ユーザエージェントクライアントが保障協定のメカニズムをサポートしていることを示しています。 494（保障協定必須）または421（拡張必須）応答にRequireヘッダーで使用した場合、それはユーザエージェントクライアントが保障協定メカニズムを使用しなければならないことを示しています。
Sanjoy Sen and Lee Valerius from Nortel Networks have contributed to the document.
ノーテルネットワークスからサンジョイ・センとリーヴァレリウスは、文書に貢献してきました。
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.
貢献者に加えて、著者はアリソンマンキン、ロルフブロム、ジェームズUndery、ジョナサン・ローゼンバーグ、ヒューShieh、ギュンター・ホーン、クリスターBoman、デビッドCastellanosの-サモラ、ミゲル・ガルシア、Valtteriニエミ、マーティンEUCHNER、エリックレスコラとメンバーに感謝したいですこの問題空間で興味深い議論の3GPP SA3グループの。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[2] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[2]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[3] Dierks, T. and C. Allen, P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3]ダークス、T.とC.アレン、P.コッヘル、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[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認証：基本とダイジェストアクセス認証"、 RFC 2617、1999年6月。
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[6]ケント、S.とR.アトキンソン、 "IP認証ヘッダ"、RFC 2402、1998年11月。
[7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[7]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[8]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
、BCP 26、RFC 2434、1998年10月[10] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[11] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)", Work in Progress.
[11]ガルシア・マーチン、M.、進行中で働いて、「第3世代パートナーシッププロジェクト（3GPP）は、セッション開始プロトコル（SIP）の5つの要件をリリース」。
[12] 3rd Generation Partnership Project, "Access security for IP-based services, Release 5", TS 33.203 v5.3.0, September 2002.
[12]第3世代パートナーシッププロジェクト、 "IPベースのサービスのためのAccessのセキュリティ、リリース5"、TS 33.203 V5.3.0、2002年9月。
[13] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[13] Madson、C.とR.グレン、 "ESPおよびAH内のHMAC-MD5-96の使用"、RFC 2403、1998年11月。
[14] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[14] Madson、C.とR.グレン、 "ESPおよびAH内のHMAC-SHA-1-96の使用"、RFC 2404、1998年11月。
[15] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[15]ペレイラ、R.とR.アダムス、 "ESP CBCモード暗号アルゴリズム"、RFC 2451、1998年11月。
Appendix A. Syntax of ipsec-3gpp
ipsec-3GPPの付録A.構文
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マルチメディアサブシステム[12]に使用されています。増大している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
機構名=（ "IPSecで3GPP"）メカパラメータ=（アルゴリズム/プロトコル/モード/暗号化アルゴリズム/ SPI / PORT1 / PORT2）アルゴリズム= "ALG" EQUAL（ "HMAC-MD5-96" /「HMAC- SHA-1-96" ）プロトコル= "PROT" EQUAL（ "ああ" / "ESP"）モード= "MOD" EQUAL（ "トランス" / "TUN"）を暗号化アルゴリズム= "ealg" EQUAL（「DES-EDE3 -cbc」/ "NULL"）SPIは= "SPI" EQUAL spivalue spivalue = 10DIGIT。 = 1 * DIGIT 0ポート1〜4294967295 = "ポート1" EQUALポートPORT2 = "ポート2" EQUALポートポート
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.
このアルゴリズムは、このパラメータは、使用する認証アルゴリズムを定義します。これは、HMAC-MD5-96 [13]のための "HMAC-MD5-96"、または "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.
プロトコルこのパラメータは、IPsecプロトコルを定義します。これは、ESPのためのAH [6]、または "ESP" の "ああ" の値を有することができる[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.
モードこのパラメータは、IPsecプロトコルが使用されるモードを定義します。これは、トランスポートモード、またはトンネリングモードのための「TUN」の値の「トランス」の値を有することができます。何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.
暗号化アルゴリズムは、このパラメータは、使用される暗号化アルゴリズムを定義します。これはない暗号化のための3DES [15]は、「DES-EDE3-CBC」の値、または「ヌル」を有していてもよいです。何の暗号化アルゴリズムのパラメータが存在しない場合、暗号化は使用されません。
Spi Defines the SPI number used for inbound messages.
SPIは、インバウンドメッセージに使用SPI番号を定義します。
Port1 Defines the destination port number for inbound messages that are protected.
ポート1は保護されて受信メッセージの宛先ポート番号を定義します。
Port2 Defines the source port number for outbound messages that are protected. Port 2 is optional.
ポート2は、保護されて送信メッセージの送信元ポート番号を定義します。ポート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で保護することを可能にするセレクタをサポートしていることを想定しています。セキュリティアソシエーションの継続時間は、結合、対応する登録の有効期間と同じです。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson Jorvas, FIN 02420 Finland
ヤリArkkoエリクソンJorvas、FIN 02420フィンランド
Phone: +358 40 507 9256 EMail: jari.arkko@ericsson.com
電話番号：+358 40 507 9256 Eメール：jari.arkko@ericsson.com
Vesa Torvinen Ericsson Joukahaisenkatu 1 Turku, FIN 20520 Finland
VESA TorvinenエリクソンJoukahaisenkatu 1トゥルク、FIN 20520フィンランド
Phone: +358 40 723 0822 EMail: vesa.torvinen@ericsson.fi
電話番号：+358 40 723 0822 Eメール：vesa.torvinen@ericsson.fi
Gonzalo Camarillo Advanced Signalling Research Lab. Ericsson FIN-02420 Jorvas Finland
ゴンサロ・カマリロ高度なシグナリング研究所。エリクソンFIN-02420 Jorvasフィンランド
Phone: +358 40 702 3535 EMail: Gonzalo.Camarillo@ericsson.com
電話番号：+358 40 702 3535 Eメール：Gonzalo.Camarillo@ericsson.com
Aki Niemi NOKIA Corporation P.O.Box 321, FIN 00380 Finland
安芸ニエミNOKIA社P.O.Box 321、FIN 00380フィンランド
Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com
電話番号：+358 50 389 1644 Eメール：aki.niemi@nokia.com
Tao Haukka Nokia Corporation P.O. Box 50 FIN - 90570 Oulu Finland
タオファルコンノキア・コーポレーションの私書箱ボックス50 FIN - 90570オウルフィンランド
Phone: +358 40 517 0079 EMail: tao.haukka@nokia.com
電話番号：+358 40 517 0079 Eメール：tao.haukka@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。