[要約] RFC 6193は、IKEプロトコルをSDPで記述するためのメディア記述に関する仕様です。このRFCの目的は、IKEセッションのセットアップと管理をSDPで行うための標準化を提供することです。
Independent Submission M. Saito
Request for Comments: 6193 NTT Communications
Category: Informational D. Wing
ISSN: 2070-1721 Cisco Systems
M. Toyama
NTT Corporation
April 2011
Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP)
セッション説明プロトコル（SDP）のインターネットキーエクスチェンジプロトコル（IKE）のメディア説明
Abstract
概要
This document specifies how to establish a media session that represents a virtual private network using the Session Initiation Protocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of the Session Description Protocol (SDP) so that it can negotiate use of the Internet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. It also specifies a method to boot up IKE and generate IPsec security associations using a self-signed certificate.
このドキュメントは、ピア間のオンデマンドメディア/アプリケーション共有を目的として、セッション開始プロトコルを使用して仮想プライベートネットワークを表すメディアセッションを確立する方法を指定します。セッション説明プロトコル（SDP）のプロトコル識別子を拡張して、SDPオファー/回答モデルでのメディアセッションにインターネットキーエクスチェンジプロトコル（IKE）の使用を交渉できるようにします。また、自己署名証明書を使用してIKEを起動してIPSECセキュリティ協会を生成する方法を指定します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6193.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6193で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Applicability Statement .........................................3
2. Introduction ....................................................3
2.1. Problem Statement ..........................................4
2.2. Approach to Solution .......................................4
2.3. Alternative Solution under Prior Relationship
between Two Nodes ..........................................6
2.4. Authorization Model ........................................6
2.5. Conventions Used in This Document ..........................6
3. Protocol Overview ...............................................7
4. Protocol Identifiers ............................................8
5. Normative Behavior ..............................................9
5.1. SDP Offer and Answer Exchange ..............................9
5.2. Maintenance and Termination of VPN Session ................10
5.3. Forking ...................................................11
5.4. Port Usage ................................................11
5.5. Multiplexing UDP Messages When Using ICE ..................11
6. Examples .......................................................13
6.1. Example of SDP Offer and Answer Exchange without
IPsec NAT-Traversal .......................................13
6.2. Example of SDP Offer and Answer Exchange with
IPsec NAT-Traversal .......................................14
7. Application to IKE .............................................15
8. Specifications Assuming Prior Relationship between Two Nodes ...16
8.1. Certificates Signed by Trusted Third Party ................16
8.2. Configured Pre-Shared Key .................................16
9. Security Considerations ........................................17
10. IANA Considerations ...........................................19
11. Acknowledgments ...............................................20
12. References ....................................................20
12.1. Normative References .....................................20
12.2. Informative References ...................................21
This document provides information about a deployed use of the Session Initiation Protocol (SIP) [RFC3261] for the Internet community. It is not currently an IETF standards track proposal. The mechanisms in this document use SIP as a name resolution and authentication mechanism to initiate an Internet Key Exchange Protocol (IKE) [RFC5996] session. The purpose of this document is to establish an on-demand virtual private network (VPN) to a home router that does not have a fixed IP address using self-signed certificates. It is only applicable under the condition that the integrity of the Session Description Protocol (SDP) [RFC4566] is assured. The method to ensure this integrity of SDP is outside the scope of this document. This document specifies the process in which a pair of SIP user agents resolve each other's names, exchange the fingerprints of their self-signed certificates securely, and agree to establish an IPsec-based VPN [RFC4301]. However, this document does not make any modifications to the specifications of IPsec/IKE. Despite the limitations of the conditions under which this document can be applied, there are sufficient use cases in which this specification is helpful, such as the following:
このドキュメントは、インターネットコミュニティ向けのセッション開始プロトコル（SIP）[RFC3261]の展開された使用に関する情報を提供します。現在、IETF標準の追跡提案ではありません。このドキュメントのメカニズムは、SIPを名前の解像度と認証メカニズムとして使用して、インターネットキー交換プロトコル（IKE）[RFC5996]セッションを開始します。このドキュメントの目的は、自己署名証明書を使用して固定IPアドレスを持たないホームルーターにオンデマンド仮想プライベートネットワーク（VPN）を確立することです。セッション説明プロトコル（SDP）[RFC4566]の整合性が保証されているという条件の下でのみ適用できます。このSDPの整合性を確保する方法は、このドキュメントの範囲外です。このドキュメントは、一対のSIPユーザーエージェントが互いの名前を解決し、自己署名証明書の指紋を安全に交換し、IPSECベースのVPN [RFC4301]を確立することに同意するプロセスを指定します。ただし、このドキュメントでは、IPSEC/IKEの仕様を変更しません。このドキュメントを適用できる条件の制限にもかかわらず、次のように、この仕様が役立つ十分なユースケースがあります。
o Sharing media using a framework developed by Digital Living Network Alliance (DLNA) or similar protocols over VPN between two user devices.
o 2つのユーザーデバイス間のVPNを介したDigital Living Network Alliance（DLNA）または同様のプロトコルによって開発されたフレームワークを使用してメディアを共有します。
o Accessing remote desktop applications over VPN initiated by SIP call. As an additional function of click-to-call, a customer service agent can access a customer's PC remotely to troubleshoot the problem while talking with the customer over the phone.
o SIPコールによって開始されたVPNを介したリモートデスクトップアプリケーションへのアクセス。Click-to-Callの追加機能として、カスタマーサービスエージェントは、顧客のPCにリモートでアクセスして、電話で顧客と話をしながら問題をトラブルシューティングすることができます。
o Accessing and controlling medical equipment (medical robotics) remotely to monitor the elderly in a rural area (remote care services).
o 農村部（リモートケアサービス）の高齢者を監視するために、医療機器（医療用ロボット工学）へのアクセスと制御。
o Using a LAN-based gaming protocol based on peer-to-peer rather than via a gaming server.
o ゲーミングサーバーを介してではなく、ピアツーピアに基づいたLANベースのゲームプロトコルを使用します。
This section describes the problem in accessing home networks and provides an overview of the proposed solution.
このセクションでは、ホームネットワークへのアクセスに関する問題について説明し、提案されたソリューションの概要を説明します。
Home servers and network-capable consumer electronic devices have been widely deployed. People using such devices are willing to share content and applications and are therefore seeking ways to establish multiple communication channels with each other. However, there are several obstacles to be overcome in the case of remote home access.
ホームサーバーとネットワーク利用可能な消費者電子デバイスは広く展開されています。そのようなデバイスを使用する人々は、コンテンツとアプリケーションを共有する意思があるため、複数の通信チャネルを互いに確立する方法を模索しています。ただし、リモートホームアクセスの場合、克服すべきいくつかの障害があります。
It is often not possible for a device outside the home network to connect to another device inside the home network because the home device is behind a network address translation (NAT) or firewall that allows outgoing connections but blocks incoming connections. One effective solution for this problem is VPN remote access to the NAT device, which is usually a home router. With this approach, once the external device joins the home network securely, establishing connections with all the devices inside the home will become easy because popular LAN-based communication methods such as DLNA can be used transparently. However, there are more difficult cases in which a home router itself is located behind the NAT. In such cases, it is also necessary to consider NAT traversal of the remote access to the home router. In many cases, because the global IP address of the home router is not always fixed, it is necessary to make use of an effective name resolution mechanism.
ホームデバイスはネットワークアドレス変換（NAT）またはファイアウォールの背後にあるため、ホームネットワークの外側のデバイスがホームネットワーク内の別のデバイスに接続することはできないことがよくあります。この問題の効果的なソリューションの1つは、通常、ホームルーターであるNATデバイスへのVPNリモートアクセスです。このアプローチを使用すると、外部デバイスがホームネットワークに安全に結合すると、DLNAなどの人気のあるLANベースの通信方法を透過的に使用できるため、ホーム内のすべてのデバイスとの接続を確立することが簡単になります。ただし、ホームルーター自体がNATの後ろにあるより難しいケースがあります。そのような場合、ホームルーターへのリモートアクセスのNATトラバーサルを考慮する必要もあります。多くの場合、ホームルーターのグローバルIPアドレスは常に固定されているとは限らないため、効果的な名前解像度メカニズムを使用する必要があります。
In addition, there is the problem of how a remote client and a home router authenticate each other over IKE to establish IPsec for remote access. It is not always possible for the two devices to securely exchange a pre-shared key in advance. Administrative costs can make it impractical to distribute authentication certificates signed by a well-known root certification authority (CA) to all the devices. In addition, it is inefficient to publish a temporary certificate to a device that does not have a fixed IP address or hostname. To resolve these authentication issues, this document proposes a mechanism that enables the devices to authenticate each other using self-signed certificates.
さらに、リモートクライアントとホームルーターがIKEを介して互いに認証してリモートアクセスのためにIPSECを確立する方法という問題があります。2つのデバイスが事前に事前に共有キーを安全に交換できるとは限りません。管理コストにより、有名なルート認証局（CA）がすべてのデバイスに署名した認証証明書を配布することは非現実的になります。さらに、固定IPアドレスまたはホスト名を持たないデバイスに一時的な証明書を公開することは非効率的です。これらの認証の問題を解決するために、このドキュメントは、デバイスが自己署名証明書を使用して互いに認証できるようにするメカニズムを提案します。
This document proposes the use of SIP as a name resolution and authentication mechanism because of three main advantages:
このドキュメントでは、3つの主な利点のために、名前の解決と認証メカニズムとしてのSIPの使用を提案しています。
o Delegation of Authentication to Third Party
o サードパーティへの認証の委任
Devices can be free from managing their signed certificates and whitelists by taking advantage of authentication and authorization mechanisms supported by SIP.
SIPがサポートする認証と認証メカニズムを活用することにより、デバイスは署名された証明書とホワイトリストを管理することができません。
o UDP Hole Punching for IKE/IPsec
o IKE/IPSECのUDPホールパンチ
SIP has a cross-NAT rendezvous mechanism, and Interactive Connectivity Establishment (ICE) [RFC5245] has a function to open ports through the NAT. The combination of these effective functions can be used for general applications as well as real-time media. It is difficult to set up a session between devices without SIP if the devices are behind various types of NAT.
SIPにはクロスナットのランデブーメカニズムがあり、インタラクティブな接続性確立（ICE）[RFC5245]には、NATを介してポートを開く機能があります。これらの効果的な機能の組み合わせは、一般的なアプリケーションとリアルタイムメディアに使用できます。デバイスがさまざまなタイプのNATの背後にある場合、SIPなしでデバイス間でセッションを設定することは困難です。
o Reuse of Existing SIP Infrastructure
o 既存のSIPインフラストラクチャの再利用
SIP servers are widely distributed as a scalable infrastructure, and it is quite practical to reuse them without any modifications.
SIPサーバーは、スケーラブルなインフラストラクチャとして広く分散されており、変更なしでそれらを再利用することは非常に実用的です。
Today, SIP is applied to not only Voice over IP (VoIP) but also various applications and is recognized as a general protocol for session initiation. Therefore, it can also be used to initiate IKE/IPsec sessions.
今日、SIPはVoice over IP（VoIP）だけでなく、さまざまなアプリケーションにも適用され、セッション開始の一般的なプロトコルとして認識されています。したがって、IKE/IPSECセッションの開始にも使用できます。
However, there is also a specification that uses a self-signed certificate for authentication in the SIP/SDP framework. "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)" [RFC4572] (hereafter referred to as comedia-tls) specifies a method to exchange the fingerprint of a self-signed certificate to establish a Transport Layer Security (TLS) [RFC5246] connection. This specification defines a mechanism by which self-signed certificates can be used securely, provided that the integrity of the SDP description is assured. Because a certificate itself is used for authentication not only in TLS but also in IKE, this mechanism will be applied to the establishment of an IPsec security association (SA) by extending the protocol identifier of SDP so that it can specify IKE.
ただし、SIP/SDPフレームワークで認証に自己署名証明書を使用する仕様もあります。「セッション説明プロトコル（SDP）のトランスポートレイヤーセキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート」[RFC4572]（以下、Comedia-TLSと呼ばれる）は、自己署名証明書の指紋を交換する方法を指定します。輸送層セキュリティ（TLS）[RFC5246]接続を確立します。この仕様は、SDP説明の整合性が保証されていれば、自己署名証明書を安全に使用できるメカニズムを定義します。証明書自体はTLSだけでなくIKEでも認証に使用されるため、このメカニズムは、IKEを指定できるようにSDPのプロトコル識別子を拡張することにより、IPSECセキュリティ協会（SA）の確立に適用されます。
One easy method to protect the integrity of the SDP description, which is the premise of this specification, is to use the SIP identity [RFC4474] mechanism. This approach is also referred to in [RFC5763]. Because the SIP identity mechanism can protect the integrity of a body part as well as the value of the From header in a SIP request by using a valid Identity header, the receiver of the request can establish secure IPsec connections with the sender by confirming that the hash value of the certificate sent during IKE negotiation matches the fingerprint in the SDP. Although SIP identity does not protect the identity of the receiver of the SIP request, SIP-connected identity [RFC4916] does. Note that the possible deficiencies discussed in [RFC4474-Concerns] could affect this specification if SIP identity is used for the security mechanism.
この仕様の前提であるSDP説明の整合性を保護する簡単な方法の1つは、SIP ID [RFC4474]メカニズムを使用することです。このアプローチは[RFC5763]でも参照されます。SIPアイデンティティメカニズムは、有効なIDヘッダーを使用して、SIPリクエストのHeaderの整合性とHeaderの値を保護できるため、リクエストの受信者は、送信者との安全なIPSEC接続を確立することができます。IKE交渉中に送信された証明書のハッシュ値は、SDPの指紋と一致します。SIPアイデンティティは、SIP要求の受信者のIDを保護しませんが、SIP接続ID [RFC4916]は行います。[RFC4474対立]で議論されている可能性のある欠陥は、SIP IDがセキュリティメカニズムに使用される場合、この仕様に影響を与える可能性があることに注意してください。
Considering the above background, this document defines new media formats "ike-esp" and "ike-esp-udpencap", which can be used when the protocol identifier is "udp", to enable the negotiation of using IKE for media sessions over SDP exchange on the condition that the integrity of the SDP description is assured. It also specifies the method to set up an IPsec SA by exchanging fingerprints of self-signed certificates based on comedia-tls, and it notes the example of SDP offer/answer [RFC3264] and the points that should be taken care of by implementation. Because there is a chance that devices are behind NAT, this document also covers the method to combine IKE/IPsec NAT-Traversal [RFC3947][RFC3948] with ICE. In addition, it defines the attribute "ike-setup" for IKE media sessions, similar to the "setup" attribute for TCP-based media transport defined in RFC 4145 [RFC4145]. This attribute is used to negotiate the role of each endpoint in the IKE session.
上記の背景を考慮すると、このドキュメントは、プロトコル識別子が「UDP」であるときに使用できる新しいメディア形式「IKE-ESP」と「IKE-ESP-UDPENCAP」を定義し、SDPを介したメディアセッションにIKEを使用する交渉を可能にしますSDP説明の整合性が保証されているという条件で交換してください。また、Comedia-TLSに基づいて自己署名証明書の指紋を交換してIPSEC SAを設定する方法を指定し、SDPオファー/回答[RFC3264]の例と実装によって世話されるべきポイントに注目しています。デバイスがNATの背後にある可能性があるため、このドキュメントでは、IKE/IPSEC NATトラバーサル[RFC3947] [RFC3948]を氷と組み合わせる方法もカバーしています。さらに、RFC 4145 [RFC4145]で定義されているTCPベースのメディアトランスポートの「セットアップ」属性と同様に、IKEメディアセッションの属性「IKE-Setup」を定義します。この属性は、IKEセッションの各エンドポイントの役割を交渉するために使用されます。
Under quite limited conditions, certificates signed by trusted third parties or pre-shared keys between endpoints could be used for authentication in IKE, using SIP servers only for name resolution and authorization of session initiation. Such limited cases are addressed in Section 8.
非常に限られた条件下では、SIPサーバーを使用して、SIPサーバーを使用して、セッション開始の承認のために、SIPサーバーを使用して、IKEでの認証に使用できます。このような限られたケースは、セクション8で説明されています。
In this document, SIP servers are used for authorization of each SIP call. The actual media sessions of IPsec/IKE are not authorized by SIP servers but by the remote client and the home router based on the information in SIP/SDP. For example, the home router recognizes the remote client with its SIP-URI and IP address in the SDP. If it decides to accept the remote client as a peer of a VPN session, it will accept the following IKE session. Then, during the IKE negotiation, the certificate fingerprint in the SDP is compared with the certificate exchanged in the IKE session. If they match, IKE negotiation continues. Only a successful IKE negotiation establishes an IPsec session with the remote peer.
このドキュメントでは、SIPサーバーが各SIPコールの許可に使用されます。IPSEC/IKEの実際のメディアセッションは、SIPサーバーではなく、SIP/SDPの情報に基づいたリモートクライアントとホームルーターによって承認されています。たとえば、ホームルーターは、SDPにSIP-URIおよびIPアドレスを持つリモートクライアントを認識します。リモートクライアントをVPNセッションのピアとして受け入れることを決定した場合、次のIKEセッションを受け入れます。次に、IKEの交渉中に、SDPの証明書指紋をIKEセッションで交換した証明書と比較されます。彼らが一致する場合、Ike交渉は続きます。IKEの交渉が成功しただけで、リモートピアとのIPSECセッションが確立されます。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Figure 1 shows a case of VPN remote access from a device outside the home to a home router whose IP address is not fixed. In this case, the external device, a remote client, recognizes the Address of Record of the home router but does not have any information about its contact address and certificate. Generally, establishing an IPsec SA dynamically and securely in this situation is difficult. However, as specified in comedia-tls [RFC4572], if the integrity of SDP session descriptions is assured, it is possible for the home router and the remote client to have a prior relationship with each other by exchanging certificate fingerprints, i.e., secure one-way hashes of the distinguished encoding rules (DER) form of the certificates.
図1は、家の外のデバイスからIPアドレスが固定されていないホームルーターへのVPNリモートアクセスのケースを示しています。この場合、外部デバイスであるリモートクライアントは、ホームルーターの記録のアドレスを認識しますが、連絡先の住所と証明書に関する情報はありません。一般に、この状況で動的かつ安全にIPSECを確立することは困難です。ただし、Comedia-TLS [RFC4572]で指定されているように、SDPセッションの説明の整合性が保証されている場合、ホームルーターとリモートクライアントは、証明書指紋を交換することで互いに事前に関係を持つことができます。 - 証明書の著名なエンコードルール（der）形式の方法。
REGISTRATION REGISTRATION
(1) +----------+ (1)
+------------->| |<---------+
| INVITE(2) | | |
| +----------->| SIP |--------+ |
| | 200 OK(2) | Proxy | | |
| | +----------| |<-----+ | |
| | | | | | | | _________
| | V +----------+ | V | / \
+----------+ IKE (Media Session) +---------+ \
| Remote |<---------(3)------->| Home | Home \
| Client | | Router | Network |
| ============(4)==================== |
|(SIP UAC) | VPN (IPsec SA) |(SIP UAS)| /
+----------+ +---------+ /
\_________/
Figure 1: Remote Access to Home Network
図1：ホームネットワークへのリモートアクセス
(1) Both Remote Client and Home Router generate secure signaling channels. They may REGISTER to SIP Proxy using TLS.
(1) リモートクライアントとホームルーターの両方が、安全なシグナリングチャネルを生成します。TLSを使用してSIPプロキシに登録する場合があります。
(2) Remote Client sends an offer SDP with an INVITE request to Home Router, and Home Router returns an answer SDP with a reliable response (e.g., 200 OK). Both exchange the fingerprints of their self-signed certificates in SDP during this transaction. Remote Client does not accept an answer SDP with an unreliable response as the final response.
(2) リモートクライアントは、ホームルーターへの招待状リクエストでオファーSDPを送信し、ホームルーターは信頼できる応答（たとえば200 OK）で回答SDPを返します。どちらも、このトランザクション中にSDPで自己署名証明書の指紋を交換します。リモートクライアントは、最終的な応答として信頼できない応答を持つ回答SDPを受け入れません。
(3) After the SDP exchange, Remote Client, which has the active role, initiates IKE with Home Router, which has the passive role, to establish an IPsec SA. Both validate that the certificate presented in the IKE exchange has a fingerprint that matches the fingerprint from SDP. If they match, IKE negotiation proceeds as normal.
(3) SDP Exchangeの後、アクティブな役割を持つリモートクライアントは、IPSEC SAを確立するために、受動的な役割を持つホームルーターでIKEを開始します。どちらも、IKE Exchangeで提示された証明書がSDPの指紋に一致する指紋を持っていることを検証します。それらが一致する場合、Ike交渉は通常どおりに進行します。
(4) Remote Client joins the Home Network.
(4) リモートクライアントはホームネットワークに参加します。
By this method, the self-signed certificates of both parties are used for authentication in IKE, but SDP itself is not concerned with all the negotiations related to key-exchange, such as those of encryption and authentication algorithms. These negotiations are up to IKE. In many cases where IPsec is used for remote access, a remote client needs to dynamically obtain a private address inside the home network while initiating the remote access. Therefore, the IPsec security policy also needs to be set dynamically at the same time. However, such a management function of the security policy is the responsibility of the high-level application. SDP is not concerned with it. The roles of SDP here are to determine the IP addresses of both parties used for IKE connection with c-line in SDP and to exchange the fingerprints of the certificates used for authentication in IKE with the fingerprint attribute in SDP.
この方法では、両当事者の自己署名証明書はIKEの認証に使用されますが、SDP自体は、暗号化や認証アルゴリズムなどのキー交換に関連するすべての交渉に関係していません。これらの交渉はIKEに至ります。IPSECがリモートアクセスに使用される多くの場合、リモートクライアントは、リモートアクセスを開始しながらホームネットワーク内のプライベートアドレスを動的に取得する必要があります。したがって、IPSECセキュリティポリシーも同時に動的に設定する必要があります。ただし、セキュリティポリシーのこのような管理機能は、高レベルのアプリケーションの責任です。SDPはそれに関心がありません。ここでのSDPの役割は、SDPのC-LineとのIKE接続に使用される両当事者のIPアドレスを決定し、SDPの指紋属性とともにIKEの認証に使用される証明書の指紋を交換することです。
This document defines two SDP media formats for the "udp" protocol under the "application" media type: "ike-esp" and "ike-esp-udpencap". The format "ike-esp" indicates that the media described is IKE for the establishment of an IPsec security association as described in IPsec Encapsulating Security Payload (ESP) [RFC4303]. In contrast, "ike-esp-udpencap" indicates that the media described is IKE, which is capable of NAT traversal for the establishment of UDP encapsulation of IPsec packets through NAT boxes as specified in [RFC3947] and [RFC3948]. Even if the offerer and answerer exchange "ike-esp-udpencap", IKE conforming to [RFC3947] and [RFC3948] can end up establishing a normal IPsec tunnel when there is no need to use UDP encapsulation of IPsec. Both the offerer and answerer can negotiate IKE by specifying "udp" in the "proto" field and "ike-esp" or "ike-esp-udpencap" in the "fmt" field in SDP.
このドキュメントでは、「アプリケーション」メディアタイプの「IKE-ESP」および「IKE-ESP-UDPENCAP」の下にある「UDP」プロトコルの2つのSDPメディア形式を定義しています。「IKE-ESP」という形式は、記載されているメディアがIPSECセキュリティ協会の確立のためのIKEであることを示しています。対照的に、「Ike-esp-udpencap」は、説明されているメディアがIKEであることを示しています。これは、[RFC3947]および[RFC3948]で指定されているように、NATボックスを介したIPSECパケットのUDPカプセル化を確立するためにNATトラバーサルが可能であることを示しています。提供者と応答者が「Ike-esp-udpencap」を交換したとしても、IKEは[RFC3947]および[RFC3948]に準拠することで、IPSECのUDPカプセル化を使用する必要がない場合に通常のIPSECトンネルを確立することになります。オファーと応答者の両方は、「プロト」フィールドで「UDP」と「IKE-ESP」または「IKE-ESP-UDPENCAP」をSDPの「Ike-esp」または「Ike-esp-udpencap」を指定することにより、IKEをネゴシエートできます。
In addition, this document defines a new attribute "ike-setup", which can be used when the protocol identifier is "udp" and the "fmt" field is "ike-esp" or "ike-esp-udpencap", in order to describe how endpoints should perform the IKE session setup procedure. The "ike-setup" attribute indicates which of the end points should initiate the establishment of an IKE session. The "ike-setup" attribute is charset-independent and can be a session- or media-level attribute. The following is the ABNF of the "ike-setup" attribute.
さらに、このドキュメントは、プロトコル識別子が「UDP」であり、「FMT」フィールドが「IKE-ESP」または「IKE-ESP-UDPENCAP」である場合に使用できる新しい属性「IKE-Setup」を定義します。エンドポイントがIKEセッションのセットアップ手順をどのように実行するかを説明するため。「IKESetup」属性は、どのエンドポイントがIKEセッションの確立を開始するかを示します。「ike-setup」属性はcharsetに依存しており、セッションまたはメディアレベルの属性になる可能性があります。以下は、「ike-setup」属性のABNFです。
ike-setup-attr = "a=ike-setup:" role
role = "active" / "passive" / "actpass"
'active': The endpoint will initiate an outgoing session. 'passive': The endpoint will accept an incoming session. 'actpass': The endpoint is willing to accept an incoming session or to initiate an outgoing session.
「アクティブ」：エンドポイントは発信セッションを開始します。「パッシブ」：エンドポイントは着信セッションを受け入れます。「ActPass」：エンドポイントは、着信セッションを受け入れるか、発信セッションを開始することをいとわない。
Both endpoints use the SDP offer/answer model to negotiate the value of "ike-setup", following the procedures determined for the "setup" attribute defined in Section 4.1 of [RFC4145]. However, "holdconn", as defined in [RFC4145], is not defined for the "ike-setup" attribute.
両方のエンドポイントは、[RFC4145]のセクション4.1で定義されている「セットアップ」属性で決定された手順に従って、SDPオファー/回答モデルを使用して「IKE-Setup」の値を交渉します。ただし、[RFC4145]で定義されている「HoldConn」は、「IKESetup」属性に対して定義されていません。
Offer Answer
----------------------------
active passive
passive active
actpass active / passive
The semantics for the "ike-setup" attribute values of "active", "passive", and "actpass" in the offer/answer exchange are the same as those described for the "setup" attribute in Section 4.1 of [RFC4145], except that "ike-setup" applies to an IKE session instead of a TCP connection. The default value of the "ike-setup" attribute is "active" in the offer and "passive" in the answer.
オファー/回答交換の「アクティブ」、「パッシブ」、および「ActPass」の「IKEセットアップ」属性値のセマンティクスは、[RFC4145]のセクション4.1の「セットアップ」属性について説明したものと同じです。「Ike-Setup」は、TCP接続の代わりにIKEセッションに適用されることを除きます。「ike-setup」属性のデフォルト値は、オファーで「アクティブ」であり、回答の「パッシブ」です。
In this section, a method to negotiate the use of IKE for media sessions in the SDP offer/answer model is described.
このセクションでは、SDPオファー/回答モデルでのメディアセッションへのIKEの使用を交渉する方法について説明します。
An offerer and an answerer negotiate the use of IKE following the usage of the protocol identifiers defined in Section 4. If IPsec NAT-Traversal is not necessary, the offerer MAY use the media format "ike-esp" to indicate an IKE session.
オファーと応答者は、セクション4で定義されたプロトコル識別子の使用に続いてIKEの使用を交渉します。IPSECAT-Traversalが必要ない場合、オファーはIKEセッションを示すためにメディア形式「IKE-ESP」を使用できます。
If either of the endpoints that negotiate IKE is behind the NAT, the endpoints need to transmit both IKE and IPsec packets over the NAT. That mechanism is specified in [RFC3947] and [RFC3948]: both endpoints encapsulate IPsec-ESP packets with a UDP header and multiplex them into the UDP path that IKE generates.
IKEを交渉するエンドポイントのいずれかがNATの背後にある場合、エンドポイントはIKEとIPSECパケットの両方をNAT上に送信する必要があります。このメカニズムは[RFC3947]および[RFC3948]で指定されています。両方のエンドポイントは、UDPヘッダーを使用してIPSEC-ESPパケットをカプセル化し、IKEが生成するUDPパスに多重化します。
To indicate this type of IKE session, the offerer uses "ike-esp-udpencap" media lines. In this case, the offerer MAY decide their transport addresses (combination of IP address and port) before starting IKE, making use of the ICE framework. Because UDP-encapsulated ESP packets and IKE packets go through the same UDP hole of a NAT, IPsec NAT-Traversal works if ICE reserves simply one UDP path through the NAT. However, those UDP packets need to be multiplexed with Session Traversal Utilities for NAT (STUN) [RFC5389] packets if ICE is required to use STUN. A method to coordinate IPsec NAT-Traversal and ICE is described in Sections 5.4 and 5.5.
このタイプのIKEセッションを示すために、Offererは「Ike-esp-udpencap」メディアラインを使用します。この場合、オファーは、IKEを開始する前に、ICEフレームワークを使用する前に、輸送アドレス（IPアドレスとポートの組み合わせ）を決定することができます。UDPがカプセル化されたESPパケットとIKEパケットは、NATの同じUDPホールを通過するため、ICEをNATを通るUDPパスを1つだけ留める場合、IPSEC NATトラバーサルは機能します。ただし、これらのUDPパケットは、STUNを使用するためにICEが必要な場合は、NAT（STUN）[RFC5389]パケットのセッショントラバーサルユーティリティで多重化する必要があります。IPSEC NATトラバーサルとICEを調整する方法は、セクション5.4および5.5で説明されています。
The offer MAY contain media lines for media other than "ike-esp" or "ike-esp-udpencap". For example, audio stream may be included in the same SDP to have a voice session when establishing the VPN. This may be useful to verify that the connected device is indeed operated by somebody who is authorized to access it, as described in Section 9. If that occurs, the negotiation described in this specification occurs only for the "ike-esp" or "ike-esp-udpencap" media lines; other media lines are negotiated and set up normally. If the answerer determines it will refuse the IKE session without beginning the IKE negotiation (e.g., the From address is not on the permitted list), it SHOULD reject the "ike-esp" or "ike-esp-udpencap" media line in the normal manner by setting the port number in the SDP answer to 0 and SHOULD process the other media lines normally (only if it is still reasonable to establish that media without VPN).
このオファーには、「IKE-ESP」または「IKE-ESP-UDPENCAP」以外のメディアのメディアラインが含まれる場合があります。たとえば、VPNを確立する際に音声セッションを行うために、同じSDPにオーディオストリームを含めることができます。これは、セクション9で説明されているように、接続されたデバイスが実際にアクセスすることを許可されている人によって実際に操作されていることを確認するのに役立つ場合があります。それが発生した場合、この仕様で説明されている交渉は「IKE-ESP」または「IKE」でのみ発生します。-esp-udpencap "メディアライン。他のメディアラインはネゴシエートされ、正常に設定されます。回答者がIKEの交渉を開始せずにIKEセッションを拒否すると判断した場合（たとえば、アドレスが許可されているリストにはありません）、「IKE-ESP」または「IKE-ESP-UDPENCAP」メディアラインを拒否する必要があります。SDPの回答でポート番号を0に設定することにより、通常の方法で通常の方法で、他のメディアラインを通常処理する必要があります（VPNなしでそのメディアを確立することがまだ合理的である場合のみ）。
If the offerer and the answerer agree to start an IKE session by the offer/answer exchange, they will start the IKE setup. Following the comedia-tls specification [RFC4572], the fingerprint attribute, which may be either a session- or a media-level SDP attribute, is used to exchange fingerprints of self-signed certificates. If the fingerprint attribute is a session-level attribute, it applies to all IKE sessions and TLS sessions for which no media-level fingerprint attribute is defined.
オファーと応答者がオファー/回答の交換によりIKEセッションを開始することに同意した場合、IKEセットアップを開始します。Comedia-TLS仕様[RFC4572]に従って、セッションレベルまたはメディアレベルのSDP属性のいずれかである指紋属性は、自己署名証明書の指紋を交換するために使用されます。指紋属性がセッションレベルの属性である場合、メディアレベルの指紋属性が定義されていないすべてのIKEセッションとTLSセッションに適用されます。
Note that it is possible for an offerer to become the IKE responder and an answerer to become the IKE initiator. For example, when a Remote Access Server (RAS) sends an INVITE to an RAS client, the server may expect the client to become an IKE initiator. In this case, the server sends an offer SDP with ike-setup:passive and the client returns an answer SDP with ike-setup:active.
提供者がIKEレスポンダーになり、回答者がIKEイニシエーターになることが可能であることに注意してください。たとえば、リモートアクセスサーバー（RAS）がRASクライアントに招待を送信すると、サーバーはクライアントがIKEイニシエーターになることを期待する場合があります。この場合、サーバーはIKESetup：Passiveを使用してオファーSDPを送信し、クライアントはIKESetup：ActiveでSDPを返します。
If the high-level application recognizes a VPN session as the media session, it MAY discard the IPsec SA and terminate IKE when that media session is terminated by a BYE request. Therefore, the application aware of the VPN session MUST NOT send a BYE request as long as it needs the IPsec SA. On the other hand, if the high-level application detects that a VPN session is terminated, it MAY terminate the media associated with the VPN or the entire SIP session. Session timers in SIP [RFC4028] MAY be used for the session maintenance of the SIP call, but this does not necessarily ensure that the VPN session is alive. If the VPN session needs session maintenance such as keep-alive and rekeying, it MUST be done utilizing its own maintenance mechanisms. SIP re-INVITE MUST NOT be used for this purpose. Note that each party can cache the certificate of the other party as described in the Security Considerations section of comedia-tls [RFC4572].
高レベルのアプリケーションがVPNセッションをメディアセッションとして認識している場合、IPSEC SAを破棄し、そのメディアセッションがBYEリクエストによって終了するとIKEを終了する可能性があります。したがって、VPNセッションを認識しているアプリケーションは、IPSEC SAが必要な限り、さようならリクエストを送信してはなりません。一方、高レベルのアプリケーションがVPNセッションが終了したことを検出した場合、VPNまたはSIPセッション全体に関連するメディアを終了する場合があります。SIP [RFC4028]のセッションタイマーは、SIPコールのセッションメンテナンスに使用できますが、これは必ずしもVPNセッションが生きていることを保証するものではありません。VPNセッションでは、維持や再キーイングなどのセッションメンテナンスが必要な場合は、独自のメンテナンスメカニズムを利用して行う必要があります。SIP Re-Inviteは、この目的に使用してはなりません。各当事者は、Comedia-TLS [RFC4572]のセキュリティに関する考慮事項セクションに記載されているように、相手の証明書をキャッシュできることに注意してください。
Forking to multiple registered instances is outside the scope of this document. At least, it is assumed that a User Agent Client (UAC) establishes a session with only one User Agent Server (UAS). Encountering forked answers should be treated as an illegal process, and the UAC should cancel the session.
複数の登録インスタンスへの分岐は、このドキュメントの範囲外です。少なくとも、ユーザーエージェントクライアント（UAC）が1つのユーザーエージェントサーバー（UAS）のみでセッションを確立すると想定されています。フォークの回答に遭遇することは違法なプロセスとして扱われるべきであり、UACはセッションをキャンセルする必要があります。
IKE generally uses local UDP port 500, but the IPsec NAT-Traversal specification requires a port transition to local UDP port 4500 during IKE negotiation because IPsec-aware NAT may multiplex IKE sessions using port 500 without changing the port number. If using ICE for IPsec Nat-Traversal, this port transition of IKE means ICE has to generate an additional UDP path for port 4500, and this would be unnecessary overhead. However, IPsec NAT-Traversal allows an IKE session to use local UDP port 4500 from the beginning without using port 500. Therefore, the endpoints SHOULD use their local UDP port 4500 for an IKE session from the beginning, and ICE will only need to generate a UDP path of port 4500.
IKEは通常、ローカルUDPポート500を使用しますが、IPSEC NAT-Traversal仕様では、IKEの交渉中にローカルUDPポート4500へのポート遷移が必要です。IPSECAWARENATは、ポート番号を変更せずにポート500を使用してマルチプレックスIKEセッションを使用する可能性があるためです。IPSEC NAT-TraversalにICEを使用する場合、IKEのこのポート遷移により、ICEはポート4500に追加のUDPパスを生成する必要があり、これは不必要なオーバーヘッドになります。ただし、IPSEC NAT-Traversalにより、IKEセッションはポート500を使用せずにIKEセッションで最初からローカルUDPポート4500を使用できます。したがって、エンドポイントは、最初からIKEセッションにローカルUDPポート4500を使用する必要があります。ポート4500のUDPパス。
When using ICE, a responder's IKE port observed by an initiator is not necessarily 500 or 4500. Therefore, an IKE initiator MUST allow any destination ports in addition to 500 and 4500 for the IKE packets that it sends. An IKE initiator just initiates an IKE session to the port number decided by an SDP offer/answer or ICE.
ICEを使用する場合、イニシエーターによって観察されるレスポンダーのIKEポートは必ずしも500または4500ではありません。したがって、IKEイニシエーターは、送信するIKEパケットの500および4500に加えて宛先ポートを許可する必要があります。IKEイニシエーターは、SDPオファー/回答またはICEによって決定されたポート番号のIKEセッションを開始します。
Conforming to ICE, an offerer and an answerer start a STUN connectivity check after SDP exchange. Then the offerer initiates the IKE session making use of the UDP path generated by STUN packets. In addition, UDP-encapsulated ESP packets are multiplexed into the same UDP path as IKE. Thus, it is necessary to multiplex the three different packets, STUN, IKE, and UDP-encapsulated ESP, into the same UDP path. This section describes how to demultiplex these three packets.
SDP交換後、氷、オファー、および応答者がスタン接続チェックを開始します。次に、STUNパケットによって生成されたUDPパスを使用して、オファーがIKEセッションを開始します。さらに、UDPにカプセル化されたESPパケットは、IKEと同じUDPパスに多重化されます。したがって、3つの異なるパケット、Stun、IKE、およびUDPにカプセル化されたESPを同じUDPパスにマルチプレックスする必要があります。このセクションでは、これらの3つのパケットを反映する方法について説明します。
At the first step, the endpoint that received a UDP packet at the multiplexed port MUST check the first 32 bits (bits 0-31) of the UDP payload. If they are all 0, which is defined as a non-ESP marker, that packet MUST be treated as an IKE packet.
最初のステップでは、多重化されたポートでUDPパケットを受信したエンドポイントは、UDPペイロードの最初の32ビット（ビット0-31）をチェックする必要があります。それらがすべて0である場合、これは非ESPマーカーとして定義されている場合、そのパケットはIKEパケットとして扱う必要があります。
Otherwise, it is judged as an ESP packet in the IPsec NAT-Traversal specification. It is furthermore necessary to distinguish STUN from ESP. Therefore, the bits 32-63 from the beginning of the UDP payload MUST be checked. If the bits do not match the magic cookie of STUN 0x2112A442 (most packets do not match), the packet is treated as an ESP packet because it is no longer a STUN packet.
それ以外の場合、IPSEC NATトラバーサル仕様のESPパケットとして判断されます。さらに、StunをESPと区別する必要があります。したがって、UDPペイロードの先頭からのビット32-63をチェックする必要があります。BITがStun 0x2112A442のマジッククッキーと一致しない場合（ほとんどのパケットは一致しません）、パケットはスタンパケットではなくなったため、ESPパケットとして扱われます。
However, if the bits do match the magic cookie, an additional test is necessary to determine if the packet is STUN or ESP. The magic cookie field of STUN overlaps the sequence number field of ESP, so a possibility still remains that the sequence number of ESP coincides with 0x2112A442. In this additional test, the validity of the fingerprint attribute of the STUN message MUST be checked. If there is a valid fingerprint in the message, it is judged as a STUN packet; otherwise, it is an ESP packet.
ただし、ビットがマジッククッキーと一致する場合、パケットがスタンするのか、それともESPであるかを判断するには、追加のテストが必要です。スタンのマジッククッキーフィールドは、ESPのシーケンス番号フィールドと重複するため、ESPのシーケンス数が0x2112A442と一致する可能性はまだ残っています。この追加テストでは、スタンメッセージの指紋属性の有効性をチェックする必要があります。メッセージに有効な指紋がある場合、スタンパケットとして判断されます。それ以外の場合、それはESPパケットです。
The above logic is expressed as follows.
上記のロジックは次のように表されます。
if SPI-field-is-all-zeros
{ packet is IKE }
else
{
if bits-32-through-63 == stun-magic-cookie-value and
bits-0-through-1 == 0 and
bits-2-through-15 == a STUN message type and
bits-16-through-31 == length of this UDP packet
{
fingerprint_found == parse_for_stun_fingerprint();
if fingerprint_found == 1
{ packet is STUN }
else
{ packet is ESP }
}
else
{ packet is ESP }
}
If IPsec NAT-Traversal is not necessary, SDP negotiation to set up IKE is quite simple. Examples of SDP exchange are as follows.
IPSEC NAT-Traversalが必要ない場合、IKEを設定するためのSDP交渉は非常に簡単です。SDP交換の例は次のとおりです。
(Note: Due to RFC formatting conventions, this document splits SDP across lines whose content would exceed 72 characters. A backslash character marks where this line folding has taken place. This backslash and its trailing CRLF and whitespace would not appear in actual SDP content.)
（注：RFCのフォーマットコンベンションにより、このドキュメントは、コンテンツが72文字を超えるラインにSDPを分割します。このライン折りたたみが行われたバックスラッシュ文字マーク。））
offer SDP
...
m=application 500 udp ike-esp
c=IN IP4 192.0.2.10
a=ike-setup:active
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
...
answer SDP
...
m=application 500 udp ike-esp
c=IN IP4 192.0.2.20
a=ike-setup:passive
a=fingerprint:SHA-1 \
D2:9F:6F:1E:CD:D3:09:E8:70:65:1A:51:7C:9D:30:4F:21:E4:4A:8E
...
Figure 2: SDP Example When Offerer Is an IKE Initiator
図2：SDPの例募集者がIKEイニシエーターである場合
offer SDP
...
m=application 500 udp ike-esp
c=IN IP4 192.0.2.10
a=ike-setup:passive
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
...
answer SDP
...
m=application 500 udp ike-esp
c=IN IP4 192.0.2.20
a=ike-setup:active
a=fingerprint:SHA-1 \
D2:9F:6F:1E:CD:D3:09:E8:70:65:1A:51:7C:9D:30:4F:21:E4:4A:8E
...
Figure 3: SDP Example When Offerer Is an IKE Responder
図3：SDPの例募集者がIKEレスポンダーである場合
We consider the following scenario here.
ここでは、次のシナリオを検討します。
+---------------------+
| |
| Internet |
| |
+---------------------+
| |
| |(192.0.2.20:45664)
| +---------+
| | NAT |
| +---------+
| |
(192.0.2.10:4500)| |(192.0.2.100:4500)
+---------+ +----------+
| offerer | | answerer |
+---------+ +----------+
Figure 4: NAT-Traversal Scenario
図4：NATトラバーサルシナリオ
As shown above, an offerer is on the Internet, but an answerer is behind the NAT. The offerer cannot initiate an IKE session unless the answerer prepares a global routable transport address that accepts IKE packets. In this case, the following offer/answer exchange will take place.
上記のように、オファーはインターネット上にありますが、回答者はNATの背後にあります。応募者は、IKEパケットを受け入れるグローバルなルーティング可能な輸送アドレスを準備しない限り、IKEセッションを開始できません。この場合、次のオファー/回答交換が行われます。
offer SDP
...
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
m=application 4500 udp ike-esp-udpencap
c=IN IP4 192.0.2.10
a=ike-setup:active
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=candidate:1 1 udp 2130706431 192.0.2.10 4500 typ host
...
answer SDP
...
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=application 45664 udp ike-esp-udpencap
c=IN IP4 192.0.2.20
a=ike-setup:passive
a=fingerprint:SHA-1 \
D2:9F:6F:1E:CD:D3:09:E8:70:65:1A:51:7C:9D:30:4F:21:E4:4A:8E
a=candidate:1 1 udp 2130706431 192.0.2.100 4500 typ host
a=candidate:2 1 udp 1694498815 192.0.2.20 45664 typ srflx \
raddr 192.0.2.100 rport 4500
...
Figure 5: SDP Example with IPsec NAT-Traversal
図5：IPSEC Nat-Traversalを使用したSDPの例
After the fingerprints of both parties are securely shared over the SDP exchange, the IKE initiator MAY start the IKE session with the other party. To follow this specification, a digital signature MUST be chosen as an authentication method in IKE phase 1. In this process, a certificate whose hash value matches the fingerprint exchanged over SDP MUST be used. If the certificate used in IKE does not match the original fingerprint, the endpoint MUST terminate the IKE session by detecting an authentication failure.
両当事者の指紋がSDP交換を介して安全に共有された後、IKEイニシエーターは他の当事者とのIKEセッションを開始できます。この仕様に従うには、IKEフェーズ1の認証方法としてデジタル署名を選択する必要があります。このプロセスでは、HASH値がSDPを介して交換された指紋と一致する証明書を使用する必要があります。IKEで使用されている証明書が元の指紋と一致しない場合、エンドポイントは認証障害を検出してIKEセッションを終了する必要があります。
In addition, each party MUST present a certificate and be authenticated by each other.
さらに、各当事者は証明書を提示し、互いに認証される必要があります。
The example described in Section 3 is for tunnel mode IPsec used for remote access, but the mode of negotiated IPsec is not limited to tunnel mode. For example, IKE can negotiate transport mode IPsec to encrypt multiple media sessions between two parties with only a pair of IPsec security associations. The only thing for which the SDP offer/answer model is responsible is to exchange the fingerprints of certificates used for IKE; therefore, the SDP offer/answer is not responsible for setting the security policy.
セクション3で説明した例は、リモートアクセスに使用されるトンネルモードIPSEC用ですが、ネゴシエートされたIPSECのモードはトンネルモードに限定されません。たとえば、IKEはTransport Mode IPSECと交渉して、IPSECセキュリティ協会のペアのみで2つの関係者間で複数のメディアセッションを暗号化できます。SDPの提供/回答モデルが責任を負う唯一のことは、IKEに使用される証明書の指紋を交換することです。したがって、SDPの申し出/回答は、セキュリティポリシーの設定について責任を負いません。
This section describes the specification for the limited cases in which certificates signed by trusted third parties or pre-shared keys between endpoints can be used for authentication in IKE. Because the endpoints already have a prior relationship in this case, they use SIP servers for only name resolution and authorization. However, even in this case, the integrity of the SDP description MUST be assured.
このセクションでは、IKEの認証には、信頼できる第三者またはエンドポイント間の事前共有キーによって署名された証明書が署名された限られたケースの仕様について説明します。この場合、エンドポイントはすでに以前の関係を持っているため、名前の解決と承認のみにSIPサーバーを使用しています。ただし、この場合でも、SDP説明の完全性を保証する必要があります。
The protocol overview in this case is the same as in Section 3. The SDP offer/answer procedure is also the same as in Sections 5 and 6. Both endpoints have a prior relationship through the trusted third parties, and SIP servers are used for name resolution and authorization of session initiation. Even so, they MAY exchange fingerprints in the SDP because one device can have several certificates and it would be necessary to specify in advance which certificate will be used for the following IKE authentication. This process also ensures that the certificate offered in the IKE process is the same as that owned by the peer that has been authorized at the SIP/SDP layer. By this process, authorization in SIP and authentication in IKE become consistent with each other.
この場合のプロトコルの概要は、セクション3と同じです。SDPオファー/回答手順はセクション5および6と同じです。両方のエンドポイントは、信頼できるサードパーティを通じて以前の関係を持ち、SIPサーバーは名前に使用されます。セッション開始の解決と承認。それでも、1つのデバイスに複数の証明書を作成できるため、SDPで指紋を交換する場合があり、次のIKE認証に使用される証明書を事前に指定する必要があります。また、このプロセスにより、IKEプロセスで提供される証明書が、SIP/SDPレイヤーで承認されたピアが所有する証明書と同じであることが保証されます。このプロセスにより、SIPの許可とIKEの認証は互いに一致します。
If a pre-shared key for IKE authentication is installed in both endpoints in advance, they need not exchange the fingerprints of their certificates. However, they may still need to specify which pre-shared key they will use in the following IKE authentication in SDP because they may have several pre-shared keys. Therefore, a new attribute, "psk-fingerprint", is defined to exchange the fingerprint of a pre-shared key over SDP. This attribute also has the role of making authorization in SIP consistent with authentication in IKE. Attribute "psk-fingerprint" is applied to pre-shared keys as the "fingerprint" defined in [RFC4572] is applied to certificates. The following is the ABNF of the "psk-fingerprint" attribute. The use of "psk-fingerprint" is OPTIONAL.
IKE認証の事前共有キーが両方のエンドポイントに事前にインストールされている場合、証明書の指紋を交換する必要はありません。ただし、いくつかの事前共有キーがある可能性があるため、SDPで次のIKE認証で使用する事前株式キーを指定する必要がある場合があります。したがって、新しい属性「PSK-fingerprint」は、SDPを介して事前に共有キーの指紋を交換するために定義されます。この属性には、IKEの認証と一致するSIPで認可を作成する役割もあります。[RFC4572]で定義されている「指紋」が証明書に適用されるため、属性「PSK-FingerPrint」は事前に共有キーに適用されます。以下は、「PSK-FingerPrint」属性のABNFです。「psk-fingerprint」の使用はオプションです。
attribute =/ psk-fingerprint-attribute
属性=/ psk-fingerprint-aTtribute
psk-fingerprint-attribute = "psk-fingerprint" ":" hash-func SP psk-fingerprint
psk-fingerprint-attribute = "psk-fingerprint" "：" hash-func sp psk-fingerprint
hash-func = "sha-1" / "sha-224" / "sha-256" /
"sha-384" / "sha-512" / token
; Additional hash functions can only come
; from updates to RFC 3279
psk-fingerprint = 2UHEX *(":" 2UHEX)
; Each byte in upper-case hex, separated
; by colons.
UHEX = DIGIT / %x41-46 ; A-F uppercase
An example of SDP negotiation for IKE with pre-shared key authentication without IPsec NAT-Traversal is as follows.
IPSEC Nat-Traversalなしの事前共有キー認証を備えたIKEのSDP交渉の例は次のとおりです。
offer SDP
...
m=application 500 udp ike-esp
c=IN IP4 192.0.2.10
a=ike-setup:active
a=psk-fingerprint:SHA-1 \
12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02
...
answer SDP
...
m=application 500 udp ike-esp
c=IN IP4 192.0.2.20
a=ike-setup:passive
a=psk-fingerprint:SHA-1 \
12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02
...
Figure 6: SDP Example of IKE with Pre-Shared Key Authentication
図6：事前共有キー認証を備えたIKEのSDP例
This entire document concerns security, but the security considerations applicable to SDP in general are described in the SDP specification [RFC4566]. The security issues that should be considered in using comedia-tls are described in Section 7 in its specification [RFC4572]. This section mainly describes the security considerations specific to the negotiation of IKE using comedia-tls.
このドキュメント全体はセキュリティに関するものですが、一般的にSDPに適用されるセキュリティ上の考慮事項は、SDP仕様[RFC4566]で説明されています。Comedia-TLSの使用で考慮すべきセキュリティの問題は、その仕様[RFC4572]のセクション7で説明されています。このセクションでは、主に、Comedia-TLSを使用したIKEの交渉に固有のセキュリティ上の考慮事項について説明します。
Offering IKE in SDP (or agreeing to one in the SDP offer/answer model) does not create an obligation for an endpoint to accept any IKE session with the given fingerprint. However, the endpoint must engage in the standard IKE negotiation procedure to ensure that the chosen IPsec security associations (including encryption and authentication algorithms) meet the security requirements of the higher-level application. When IKE has finished negotiating, the decision to conclude IKE and establish an IPsec security association with the remote peer is entirely the decision of each endpoint. This procedure is similar to how VPNs are typically established in the absence of SIP.
SDPでIKEを提供する（またはSDPオファー/回答モデルの1つに同意する）ことは、指定された指紋を使用したIKEセッションを受け入れるエンドポイントの義務を作成しません。ただし、エンドポイントは、選択されたIPSECセキュリティ協会（暗号化と認証アルゴリズムを含む）が高レベルのアプリケーションのセキュリティ要件を満たすことを保証するために、標準のIKE交渉手順に従事する必要があります。IKEが交渉を終えたとき、IKEを締めくくり、リモートピアとのIPSECセキュリティ関連を確立する決定は、各エンドポイントの決定です。この手順は、SIPがない場合にVPNが通常どのように確立されるかに似ています。
In the general authentication process in IKE, subject DN or subjectAltName is recognized as the identity of the remote party. However, by using SIP identity and SIP-connected identity mechanisms in this spec, certificates are used simply as carriers for the public keys of the peers and there is no need for the information about who is the signer of the certificate and who is indicated by subject DN.
IKEの一般的な認証プロセスでは、サブジェクトDNまたはSubjectAltNameがリモートパーティのIDとして認識されています。ただし、この仕様でSIP IDとSIP接続のアイデンティティメカニズムを使用することにより、証明書は単にピアの公開鍵のキャリアとして使用され、証明書の署名者と誰が示されているかについての情報は必要ありません。主題DN。
In this document, the purpose of using IKE is to launch the IPsec SA; it is not for the security mechanism of RTP and RTCP [RFC3550] packets. In fact, this mechanism cannot provide end-to-end security inside the VPN as long as the VPN uses tunnel mode IPsec. Therefore, other security methods such as the Secure Real-time Transport Protocol (SRTP) [RFC3711] must be used to secure the packets.
このドキュメントでは、IKEを使用する目的は、IPSEC SAを起動することです。RTPおよびRTCP [RFC3550]パケットのセキュリティメカニズムのためではありません。実際、このメカニズムは、VPNがトンネルモードIPSECを使用する限り、VPN内でエンドツーエンドのセキュリティを提供することはできません。したがって、安全なリアルタイム輸送プロトコル（SRTP）[RFC3711]などの他のセキュリティ方法を使用して、パケットを保護する必要があります。
When using the specification defined in this document, it needs to be considered that under the following circumstances, security based on SIP authentication provided by SIP proxy may be breached.
このドキュメントで定義されている仕様を使用する場合、次の状況では、SIPプロキシによって提供されるSIP認証に基づくセキュリティが違反される可能性があることを考慮する必要があります。
o If a legitimate user's terminal is used by another person, it may be able to establish a VPN with the legitimate identity information. This issue also applies to the general VPN cases based on the shared secret key. Furthermore, in SIP we have a similar problem when file transfer, IM, or comedia-tls where non-voice/video is used as a means of communication.
o 合法的なユーザーの端末が他の人によって使用されている場合、正当なID情報を含むVPNを確立できる可能性があります。この問題は、共有されたシークレットキーに基づいた一般的なVPNケースにも適用されます。さらに、SIPでは、コミュニケーションの手段として非声/ビデオが使用されるファイル転送、IM、またはComedia-TLSの場合、同様の問題があります。
o If a malicious user hijacks the proxy, he or she can use whatever credential is on the Access Control List (ACL) to gain access to the home network.
o 悪意のあるユーザーがプロキシをハイジャックした場合、アクセス制御リスト（ACL）にある資格情報を使用してホームネットワークへのアクセスを得ることができます。
For countermeasures to these issues, it is recommended to use unique information such as a password that only a legitimate user knows for VPN establishment. Validating the originating user by voice or video before establishing VPN would be another method.
これらの問題への対策については、正当なユーザーのみがVPN確立で知っているパスワードなどの一意の情報を使用することをお勧めします。VPNを確立する前に、音声またはビデオごとに発信ユーザーを検証することは、別の方法です。
IANA has registered the following new SDP attributes and media formats.
IANAは、次の新しいSDP属性とメディア形式を登録しています。
Attribute name: ike-setup Long form name: IKE setup extensions Type of attribute: Session-level and media-level Subject to charset: No Purpose: Attribute to indicate initiator and responder of IKE-based media session Appropriate values: See Section 4 of RFC 6193 Contact name: Makoto Saito, ma.saito@nttv6.jp
属性名：ike-setup long form名：ikeセットアップ拡張機能タイプの属性：セッションレベルとメディアレベルのcharsetの対象：目的なし：IKEベースのメディアセッションのイニシエーターとレスポンダーを示す属性適切な値：セクション4を参照RFC 6193連絡先名：Makoto Saito、MA.Saito@nttv6.jp
Media format name: ike-esp Long form name: IKE followed by IPsec ESP Associated media: application Associated proto: udp Subject to charset: No Purpose: Media format that indicates IKE and IPsec ESP as a VPN session Reference to the spec: See Section 5 of RFC 6193 Contact name: Makoto Saito, ma.saito@nttv6.jp
メディア形式名：IKE-ESP Long Form名：IKEの後にIPSEC ESP関連メディア：アプリケーション関連のプロト：charsetの対象：目的なし：IKEおよびIPSEC ESPを示すメディア形式は、SPECへのVPNセッションを参照してください：セクションを参照してくださいRFC 6193の5つの連絡先名：Makoto Saito、MA.Saito@nttv6.jp
Media format name: ike-esp-udpencap Long form name: IKE followed by IPsec ESP or UDP encapsulated IPsec ESP Associated media: application Associated proto: udp Subject to charset: No Purpose: Media format that indicates IKE that supports NAT-Traversal and IPsec ESP or UDP encapsulation of IPsec ESP packets as a VPN session Reference to the spec: See Section 5 of RFC 6193 Contact name: Makoto Saito, ma.saito@nttv6.jp
メディア形式名：IKE-esp-udpencap long form name name：ike xlod ipsec espまたはudp capsec esp esp esp esp：アプリケーションに関連するproto：udp charset：no tulting：no noter：media format not-traversalおよびipsecececececececececececececececeESPまたはUDP IPSEC ESPパケットのVPNセッションとしてのカプセル化スペックへの参照：RFC 6193のセクション5を参照してください。
Attribute name: psk-fingerprint Long form name: Fingerprint of pre-shared key extensions Type of attribute: Session-level and media-level Subject to charset: No Purpose: Attribute to indicate a pre-shared key that will be used in the following media session Appropriate values: See Section 8.2. of RFC 6193 Contact name: Makoto Saito, ma.saito@nttv6.jp
属性名：psk-fingerprint long form name name：shared extensions前の指紋属性のタイプ：セッションレベルとメディアレベルのcharsetの対象：目的なし：属性以下で使用される事前共有キーを示す属性メディアセッション適切な値：セクション8.2を参照してください。of RFC 6193連絡先名：マッコト賞saito、マサチューセッツ州saito@nttv6.jp
We would like to thank Remi Denis-Courmont, Dale Worley, Richard Barnes, David Hancock, Stuart Hoggan, Jean-Francois Mule, Gonzalo Camarillo, and Robert Sparks for providing comments and suggestions contributing to this document. Eric Rescorla especially gave insightful comments from a security point of view. Shintaro Mizuno and Shida Schubert also contributed a lot of effort to improving this document.
レミ・デニス・コールモント、デール・ウォーリー、リチャード・バーンズ、デビッド・ハンコック、スチュアート・ホーガン、ジャン・フランソワ・ラバ、ゴンザロ・カマリロ、ロバート・スパークスに、この文書に貢献するコメントや提案を提供してくれたことに感謝します。エリック・レスコルラは、特にセキュリティの観点から洞察に富んだコメントをしました。和江とshidaシューベルトは、この文書を改善するために多くの努力を貢献しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] 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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A。、およびV. Volpe、「IKEにおけるNat-Traversalの交渉」、RFC 3947、2005年1月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、Volpe、V.、Diburro、L。、およびM. Stenberg、「IPSEC ESPパケットのUDPカプセル化」、RFC 3948、2005年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572] Lennox、J。、「セッション説明プロトコル（SDP）の輸送層セキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート」、RFC 4572、2006年7月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：オファー/回答プロトコルのネットワークアドレス翻訳者（NAT）トラバーサルのプロトコル」、RFC 5245、2010年4月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NATのセッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン2（IKEV2）」、RFC 5996、2010年9月。
[RFC4474-Concerns] Rosenberg, J., "Concerns around the Applicability of RFC 4474", Work in Progress, February 2008.
[RFC4474-Concerns] Rosenberg、J。、「RFC 4474の適用性に関する懸念」、2008年2月、進行中の作業。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[RFC4028] Donovan、S。およびJ. Rosenberg、「セッション開始プロトコル（SIP）のセッションタイマー」、RFC 4028、2005年4月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145] Yon、D。およびG. Camarillo、「セッション説明プロトコル（SDP）のTCPベースのメディアトランスポート」、RFC 4145、2005年9月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916] Elwell、J。、「セッション開始プロトコル（SIP）の接続アイデンティティ」、RFC 4916、2007年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, May 2010.
[RFC5763] Fischl、J.、Tschofenig、H.、およびE. Rescorla、「データグラム輸送層セキュリティ（DTLS）を使用した安全なリアルタイムトランスポートプロトコル（SRTP）セキュリティコンテキストを確立するためのフレームワーク」、RFC 5763、2010年5月。
Authors' Addresses
著者のアドレス
Makoto Saito NTT Communications 1-1-6 Uchisaiwai-Cho, Chiyoda-ku Tokyo 100-8019 Japan
Makoto Saito NTT Communications 1-1-6 Uchisaiwai-Cho、Chiyoda-Ku Tokyo 100-8019 Japan
EMail: ma.saito@nttv6.jp
Dan Wing Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States
ダンウィングシスコシステム170ウェストタスマンドライブサンノゼ、カリフォルニア95134アメリカ合衆国
EMail: dwing@cisco.com
Masashi Toyama NTT Corporation 9-11 Midori-Cho 3-Chome, Musashino-Shi Tokyo 180-8585 Japan
田山田Ntt Corporation 9-11 Midori-Cho 3-Chome、Musashino-Shi Tokyo 180-8585 Japan
EMail: toyama.masashi@lab.ntt.co.jp