[要約] RFC 3329は、SIPセッションのセキュリティメカニズムの合意に関する規格です。その目的は、SIPセッションのセキュリティを確保し、通信の機密性と完全性を保護することです。
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)
セッション開始プロトコル（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.
Copyright（c）The Internet Society（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は特定の攻撃に対して脆弱です。複数の代替方法とアルゴリズムを使用した認証と整合性の保護は、中間（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 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. セキュリティメカニズム自体の選択は安全である必要があります。従来、すべてのセキュリティプロトコルは安全な形式の交渉を使用していました。たとえば、Diffie-Hellmanを通じて相互鍵を確立した後、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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
1. クライアント---------クライアントリスト---------->サーバー2.クライアント<--------サーバーリスト----------サーバー3.クライアント------（セキュリティをオンにする）-------サーバー4.クライアント---------サーバーリスト---------->サーバー5。クライアント<-------- OKまたはエラー---------サーバー
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ヘッダーフィールド、すなわち、セキュリティクライアント、セキュリティサーバー、セキュリティVerifyを定義します。このセクションの構文要素の拡張された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)
Security-Client = "Security-Client" Hcolon Sec-Mechanism *（Comma Sec-Mechanism）Security-Server = "Security-Server" Hcolon Sec-Mechanism *（Comma Sec-Mechanism）Security-Verify = "Security-Verify" hcolonSECメカニズム *（コンマセクションメカニズム）
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:
メカニズム名前このトークンは、セキュリティクライアントヘッダーフィールドに表示されるときに、クライアントがサポートするセキュリティメカニズムを識別します。または、サーバーによって、セキュリティサーバーまたはセキュリティ検証ヘッダーフィールドに表示される場合。メカニズム名のトークンはIANAに登録されています。この仕様は4つの値を定義します。
* "tls" for TLS [3].
* TLSの「TLS」[3]。
* "digest" for HTTP Digest [4].
* httpダイジェストの「ダイジェスト」[4]。
* "ipsec-ike" for IPsec with IKE [2].
* IKE [2]を使用したIPSECの「Ipsec-yik」。
* "ipsec-man" for manually keyed IPsec without IKE.
* IKEなしで手動でキー化されたIPSECの「IPSEC-MAN」。
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.
DIGEST-ALGORITHMこのオプションパラメーターは、HTTP Digestアルゴリズムパラメーターの入札ダウン攻撃を防ぐために、HTTP Digest [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.
DIGEST-QOPこのオプションパラメーターは、HTTP Digest QOPパラメーターの入札ダウン攻撃を防ぐために、HTTP Digest [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:
Digest-Verifyこのオプションパラメーターは、SIPセキュリティメカニズム契約（このドキュメント）の入札ダウン攻撃を防ぐために、HTTP Digest [4]のみでのみ定義されます。フィールドのコンテンツは、[4]の「リクエストダイジェスト」とまったく同じ方法でカウントされます。「QOP」指令の値が「認証」であるか、不特定の場合、A2は次のとおりです。
A2 = Method ":" digest-uri-value ":" security-server
If the "qop" value is "auth-int", then A2 is:
「QOP」値が「auth-int」である場合、A2は次のとおりです。
A2 = Method ":" digest-uri-value ":" H(entity-body) ":"
security-server
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].
Digest-Verifyパラメーターを計算または解釈する前に、セキュリティサーバーヘッダーフィールドのすべての線形白スペースを単一のSPに置き換える必要があります。メソッド、ダイジェスト尿価値、エンティティボディ、およびその他の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.
この仕様では、HTTPダイジェストに拡張または変更が導入されていないことに注意してください[4]。この仕様は、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.
クライアントが[5]で指定されたルールに従っているために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.
この仕様のセキュリティ契約を使用したいクライアントは、ファーストホッププロキシに宛てられたリクエストにセキュリティクライアントヘッダーフィールドを追加する必要があります（つまり、リクエストの宛先は最初のホッププロキシです）。このヘッダーフィールドには、クライアントがサポートするすべてのセキュリティメカニズムのリストが含まれています。クライアントは、このリストに優先パラメーターを追加しないでください。クライアントは、要求に「秒」の値を備えた要件とプロキシレクイアヘッダーフィールドの両方を追加する必要があります。
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.
値「sec-agree」を備えた要求またはプロキシレクイアヘッダーフィールドを含む保護されていないリクエストを受信するサーバーは、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リクエストは、前のステップで開始されたセキュリティメカニズムを利用する必要があります。これらのリクエストには、以前に受信したサーバーのリストをセキュリティサーバーヘッダーフィールドに反映するセキュリティ検証ヘッダーフィールドを含める必要があります。これらの要求には、値「sec-agree」を持つ要求ヘッダーフィールドとプロキシレクイアヘッダーフィールドの両方が必要です。
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.
[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（セキュリティ契約が必要）応答でクライアントに応答する必要があります。この応答には、サポートされているセキュリティメカニズムのサーバーの未修正リストを含める必要があります。リストが変更されておらず、サーバーがプロキシである場合、要求ヘッダーフィールドとプロキシレクイアヘッダーフィールドの両方から「秒」値を削除し、値が残っていない場合はヘッダーフィールドを削除する必要があります。
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.
サーバーは、ローカルポリシーに基づいてこのドキュメントに記載されているセキュリティ契約を使用することを決定します。このメカニズムを使用するように構成されているネットワークインターフェイスからサーバーがリクエストを受信した場合、リクエストがエントリ経由で1つしかないことを確認する必要があります。いくつかのエントリがある場合、サーバーは最初のホップ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（拡張要求）応答を返す必要があります。リクエストにサポートされているヘッダーフィールドにSEC-Agreeオプションタグがある場合、494（セキュリティ契約が必要）応答を返す必要があります。どちらの状況でも、サーバーは応答に、その機能をリストするセキュリティサーバーヘッダーフィールドを含め、オプションタグ「sec-agree」を備えたヘッダーフィールドを必要とする必要があります。また、サーバーは、クライアントが優先セキュリティメカニズムを開始できるように、必要な情報を追加する必要があります（たとえば、HTTPダイジェストのプロキシ - 認識ヘッダーフィールド）。
Clients that support the extension defined in this document SHOULD add a Supported header field with a value of "sec-agree".
このドキュメントで定義されている拡張機能をサポートするクライアントは、「sec-agree」の値でサポートされているヘッダーフィールドを追加する必要があります。
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」が選択された場合、クライアントは[1]のセクション8.1.2の手順を使用して、[5]のDNS手順への入力として使用されるURIを決定します。ただし、URIがSIP URIの場合、SIPではなくSIPであるかのようにスキームを扱う必要があります。URIスキームがSIPでない場合、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ダイジェスト認証チャレンジが含まれます。クライアントは、セキュリティサーバーヘッダーフィールドのアルゴリズムとQOPパラメーターを使用して、HTTPダイジェストチャレンジで同じパラメーターを置き換える必要があります。また、クライアントは、2.2で指定されたセキュリティサーバーヘッダーフィールドを保護するために、Security-VerifyヘッダーフィールドのDigest-Verifyパラメーターを使用する必要があります。
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-yik」を使用するために、クライアントは、サーバーへの最初のリクエストで、リクエスト-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].
「IPSec-Man」は、通信SIPエンティティが使用するキーやその他のパラメーターを知っている場合にのみ機能することに注意してください。この仕様の範囲外で、この情報をピアにどのように知らせることができるかを説明します。必須の実装アルゴリズムなどの最小実装に関するすべてのルールは、[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は、セキュリティ協会の期間を交渉します。Digestを使用してクライアントが提供する資格情報が有効になっていない場合、サーバーはクライアントを再チャレンジします。Ipsec-Manを使用すると、キーの配布に使用される同じ帯域外のメカニズムが、セキュリティ協会の持続時間を定義するために使用されると想定されています。
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、プロキシ、レジストラなどの他の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:
「Where」列は、ヘッダーフィールドを使用できるリクエストと応答の種類を説明しています。ヘッダーは、他のタイプの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は、プロキシがどのメカニズムをサポートするかを事前に知らずに、アウトバウンドプロキシで使用するセキュリティメカニズムを交渉します。ここでは、オプション方法を使用して、プロキシのセキュリティ機能を要求できます。このようにして、最初の招待がプロキシを介して送信される前であっても、セキュリティを開始できます。
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）。
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接続を介して招待リクエストを送信します（3）。この招待状には、サーバーのセキュリティリストが含まれています。サーバーはそれを検証し、静的リストと一致するため、招待を処理して次のホップに転送します。
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は他のセキュリティがどのようなセキュリティをサポートしているかを知らず、エラーが発生しやすい試行を余儀なくされます。
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-agree proxy-require：sec-agree
(2) SIP/2.0 494 Security Agreement Required
Security-Server: ipsec-ike;q=0.1
Security-Server: 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
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).
招待とACK（7）の200 OK応答（6）もTLS接続を介して送信されます。ACKには、Invite（3）と同じセキュリティVerifyヘッダーフィールドが含まれます。
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のこの例では、クライアントはアウトバウンドプロキシを使用してCalleeに招待状を送信します。この招待には、必要なヘッダーフィールドは含まれていません。
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.
プロキシは、そのローカルポリシーに従って、招待を受け入れません。IPSec-yikおよびTLSをリストするセキュリティサーバーヘッダーフィールドを備えた421（拡張機能が必要）を返します。UACはIPSEC-akeをサポートしているため、キーエクスチェンジを実行し、プロキシとセキュリティ関連を確立します。
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.
2番目の招待状（4）とACK（8）には、421で受け取ったセキュリティサーバーヘッダーフィールドを反映するセキュリティヴェイバイヘッダーフィールドが含まれています。確立されたセキュリティ協会を使用して送信されます。
(1) INVITE sip:uas.example.com SIP/2.0
(1) sipを招待する：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
(4) INVITE sip:uas.example.com SIP/2.0
Security-Verify: ipsec-ike;q=0.1
Security-Verify: tls;q=0.2
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 Digestを使用して現在のネットワークを使用して、たとえば、すべての機器の同時変更を必要とせずに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.
* 変更がサーバーの選択に影響を与えた場合、サーバーとクライアントは、図1のステップ3または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の実装は、NonCeパラメーターへのタイムスタンプを含めるなど、既存の返信保護オプションを慎重に利用する必要があります[4]。
All clients that implement this specification MUST select HTTP Digest, TLS, IPsec, or any stronger method for the protection of the second request.
この仕様を実装するすべてのクライアントは、2番目の要求を保護するためのHTTPダイジェスト、TLS、IPSEC、またはより強力な方法を選択する必要があります。
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の新しいメカニズム名の名前空間を定義します。セクション2.2では、中央調整本体が必要です。この調整の原因は、インターネットに割り当てられた数字当局（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-YIK」、および「IPSEC-MAN」を定義します。これらのメカニズム名に加えて、「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登録には、表2に示す情報が含まれます。IANAが維持する情報の種類も示します。
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
宛先：ietf-sip-sec-agree-mechanism-name@iana.org件名：新しいSIPセキュリティ契約の登録メカニズム
Mechanism Name:
メカニズム名：
(Token value conforming to the syntax described in Section 2.2.)
（セクション2.2で説明した構文に準拠したトークン値。）
Published Specification(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)
ヘッダー名：Security-Verifyコンパクトフォーム：（なし）
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.
この仕様は、新しいオプションタグ、つまりSEC-Agreeを定義します。オプションタグは、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.
名前：SEC-Agree説明：このオプションタグは、セキュリティ契約メカニズムのサポートを示しています。要求またはプロキシリクイアヘッダーで使用する場合、セキュリティ契約メカニズムを使用するためにプロキシサーバーが必要であることを示します。サポートされているヘッダーで使用すると、ユーザーエージェントクライアントがセキュリティ契約メカニズムをサポートしていることを示します。494（セキュリティ契約が必要）または421（拡張要求）応答の要求ヘッダーで使用される場合、ユーザーエージェントクライアントがセキュリティ契約メカニズムを使用する必要があることを示します。
Sanjoy Sen and Lee Valerius from Nortel Networks have contributed to the document.
Nortel NetworksのSanjoy SenとLee Valeriusがこの文書に貢献しています。
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.
貢献者に加えて、著者は、アリソン・マンキン、ロルフ・ブロム、ジェームズ・アンダーリー、ジョナサン・ローゼンバーグ、ヒュー・シー、ガンサー・ホーン、クリスター・ボーマン、デビッド・カステラノス・ザモラ、ミゲル・ガルシア、ヴァルテリ・ニエミ、マーティン・エウチュナー、エリック・レスパルラ、メンバーに感謝したいと考えています。この問題分野での興味深い議論のための3GPPSA3グループの。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[2] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[3] Dierks, T. and C. Allen, P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3] Dierks、T。and C. Allen、P。Kocher、「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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。and L. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）：SIPサーバーの位置」、RFC 3263、2002年6月。
[6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[6] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[7] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[8] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[11] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)", Work in Progress.
[11] Garcia-Martin、M。、「セッション開始プロトコル（SIP）の第3世代パートナーシッププロジェクト（3GPP）リリース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ベースのサービスのアクセスセキュリティ、リリース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] マドソン、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。and R. Glenn、「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] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、1998年11月。
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
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 [14]の「HMAC-SHA-1-96」の値がある場合があります。アルゴリズムパラメーターは必須です。
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プロトコルを定義します。AH [6]の場合は「AH」、またはESP [7]の「ESP」の値がある場合があります。プロトコルパラメーターが存在しない場合、プロトコルはデフォルトで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プロトコルが使用されるモードを定義します。輸送モードの「トランス」の値、またはトンネリングモードの「トン」の値がある場合があります。モードパラメーターが存在しない場合、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」、または暗号化なしの「null」の値がある場合があります。暗号化 - アルゴリズムパラメーターが存在しない場合、暗号化は使用されません。
Spi Defines the SPI number used for inbound messages.
SPIは、インバウンドメッセージに使用されるSPI番号を定義します。
Port1 Defines the destination port number for inbound messages that are protected.
PORT1は、保護されているインバウンドメッセージの宛先ポート番号を定義します。
Port2 Defines the source port number for outbound messages that are protected. Port 2 is optional.
PORT2は、保護されているアウトバウンドメッセージのソースポート番号を定義します。ポート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
Jari Arkko Ericsson Jorvas、フィン02420フィンランド
Phone: +358 40 507 9256
EMail: jari.arkko@ericsson.com
Vesa Torvinen Ericsson Joukahaisenkatu 1 Turku, FIN 20520 Finland
Vesa Torvinen Ericsson Joukahaisenkatu 1 Turku、Fin 20520 Finland
Phone: +358 40 723 0822
EMail: vesa.torvinen@ericsson.fi
Gonzalo Camarillo Advanced Signalling Research Lab. Ericsson FIN-02420 Jorvas Finland
Gonzalo Camarillo Advanced Signaling Research Lab。エリクソンフィン-02420ジョルバスフィンランド
Phone: +358 40 702 3535
EMail: Gonzalo.Camarillo@ericsson.com
Aki Niemi NOKIA Corporation P.O.Box 321, FIN 00380 Finland
Aki niemi Nokia Corporation P.O.Box 321、Fin 00380フィンランド
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Tao Haukka Nokia Corporation P.O. Box 50 FIN - 90570 Oulu Finland
タオ・ハウカ・ノキア・コーポレーションP.O.ボックス50フィン-90570オウルフィンランド
Phone: +358 40 517 0079
EMail: tao.haukka@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。