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)
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オファー/アンサーモデルにメディアセッションのインターネット鍵交換プロトコル（IKE）の使用を交渉できるように、セッション記述プロトコル（SDP）のプロトコル識別子を拡張します。また、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 Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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の標準トラックの提案ではありません。この文書に記載されているメカニズムは、インターネット鍵交換プロトコル（IKE）[RFC5996]セッションを開始するために、名前解決と認証メカニズムとしてSIPを使用します。このドキュメントの目的は、自己署名証明書を使用して、固定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デジタルリビングネットワークアライアンス（DLNA）、または2つのユーザデバイス間のVPNを超える同様のプロトコルが開発したフレームワークを使用してメディアを共有します。
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.
SIPコールによって開始されたVPNを介してリモートデスクトップアプリケーションへのアクセス、O。クリックツーコールの追加機能として、顧客サービス・エージェントは、電話で顧客と話している間に問題をトラブルシューティングするためにリモートで顧客の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.
ピア・ツー・ピアではなく、ゲームサーバを介してベースLANベースのゲームのプロトコルを使用し、O。
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.
また、リモートクライアントとホームルータは、リモートアクセスのためにIPsecを確立するために、IKEを介して相互に認証する方法の問題があります。 2つのデバイスがしっかりと事前に事前共有鍵を交換することは常に可能ではありません。行政コストは、すべてのデバイスによく知られたルート証明機関（CA）によって署名された認証証明書を配布することは非現実的にすることができます。また、固定のIPアドレスまたはホスト名を持っていないデバイスに一時証明書を発行することは非効率的です。これらの認証の問題を解決するには、この文書では、デバイスが自己署名証明書を使用して互いを認証することができる仕組みを提案しています。
This document proposes the use of SIP as a name resolution and authentication mechanism because of three main advantages:
この文書では、名前解決と認証機構ための三つの主要な利点として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
IKE / IPsecのUDPホールパンチングO
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は、クロスNATランデブー機構を有する、インタラクティブ接続確立（ICE）[RFC5245]はNATを介してポートを開く機能を有しています。これらの効果的な機能の組み合わせは、一般的なアプリケーションだけでなく、リアルタイムメディアのために使用することができます。デバイスがNATの様々なタイプの背後にある場合は、SIPなしでデバイス間のセッションを設定することは困難です。
o Reuse of Existing SIP Infrastructure
既存のSIPインフラストラクチャの再利用O
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は、ボイスオーバー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）でTransport Layer Security（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記述の完全性を保護するための一つの簡単な方法は、SIPアイデンティティ[RFC4474]メカニズムを使用することです。このアプローチは、[RFC5763]で言及されています。 SIPアイデンティティメカニズムが有効なIdentityヘッダーを使用することにより、本体部分の整合性だけでなく、SIPリクエストのヘッダーからの値を保護することができますので、リクエストの受信機があることを確認することで、送信者との安全なIPsec接続を確立することができますIKEネゴシエーション中に送信された証明書のハッシュ値は、SDP内の指紋と一致しました。 SIPアイデンティティは、SIPリクエストの受信機のアイデンティティを保護していないが、SIP接続アイデンティティ[RFC4916]ありません。 SIPのアイデンティティは、セキュリティ・メカニズムのために使用されている場合は、[RFC4474-懸念]で論じ可能不備がこの仕様に影響を与える可能性があることに注意してください。
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.
上記の背景を考慮すると、この文書は、「IKE-ESP」新しいメディア形式を定義し、プロトコル識別子は、「UDP」である場合、SDP上のメディアセッションのためのIKEを使用しての交渉を可能にするために、使用することができる「IKE-ESP-udpencap」、 SDP記述の整合性が確保されていることを条件に交流。また、COMEDIA-TLSに基づいて自己署名証明書のフィンガープリントを交換することにより、IPsecのSAを設定する方法を指定し、それはSDPオファー/アンサー[RFC3264]と実装によっての世話をしなければならないポイントの例を指摘しています。デバイスがNATの背後にある可能性があるため、この文書はまた、ICEとのIKE / IPsecのNATトラバーサル[RFC3947] [RFC3948]を結合する方法をカバーしています。また、RFC 4145 [RFC4145]で定義されたTCPベースのメディア転送のために、「セットアップ」属性と同様IKEメディアセッションの属性「IKE-セットアップ」を定義します。この属性は、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サーバを使用して、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セッションに交換して次に、IKEネゴシエーション中に、SDPでの証明書のフィンガープリントが比較されます。それらが一致する場合は、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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 SAを確立することが困難です。しかし、COMEDIA-TLS [RFC4572]で指定されたSDPセッション記述の整合性が保証されている場合、家庭用ルータとリモートクライアントは、証明書のフィンガープリントを交換することによって、互いの前に関係を持っているため、それが可能である、すなわち、安全な1証明書の識別符号化規則（DER）形式の-wayハッシュ。
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）リモートクライアントは、ホームルータへINVITEリクエストをオファー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交換、積極的な役割を持っている受動的な役割を持ってホームルータ、とIKEを開始し、リモートクライアント、後のIPsec SAを確立します。双方は、IKE交換中に提示された証明書は、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の役割は、ここではC線SDP内およびSDPで指紋属性でIKEでの認証に使用する証明書のフィンガープリントを交換するとのIKE接続に使用される、両当事者のIPアドレスを決定することです。
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カプセル化セキュリティペイロード（ESP）[RFC4303]に記載されているように記述されるメディアは、IPsecセキュリティアソシエーションの確立のためにIKEであることを示しています。対照的に、「IKE-ESP-udpencap」が記述されるメディアは、[RFC3947]及び[RFC3948]で指定されるようにNATボックスを介してIPsecパケットのUDPカプセル化の確立のためのNATトラバーサルが可能であるIKE、であることを示しています。オファーとアンサー交換「IKE-ESP-udpencap」は、IKEは、IPsecのUDPカプセル化を使用する必要がない場合、通常のIPsecトンネルを確立するに終わることができる[RFC3947]及び[RFC3948]に準拠していても。申出と回答の両方は、SDPの「FMT」の欄に「プロト」の欄に「UDP」を指定し、「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」フィールドは、「ESP-IKE」または「IKE-ESP-udpencap」である場合に使用することができる新しい属性「IKE-セットアップ」、定義しますエンドポイントがIKEセッションのセットアップ手順を実行する方法を説明します。 「池セットアップ」属性は、IKEセッションの確立を開始すべきであるエンドポイントのかを示します。 「IKE-セットアップ」属性は、文字セットに依存せず、セッション - またはメディアレベル属性にすることができます。以下は、「IKE-設定」属性のABNFです。
ike-setup-attr = "a=ike-setup:" role role = "active" / "passive" / "actpass"
IKE-セットアップのattr = "A = IKE-セットアップ：" 役割の役割= "アクティブ" / "受動的" / "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で定義された「セットアップ」属性の決定手順を以下、「IKE-設定」の値を交渉するSDPオファー/アンサーモデルを使用します。しかし、「holdconn」、[RFC4145]で定義されるように、「IKE-セットアップ」属性に定義されていません。
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-セットアップ」以外IKEセッションの代わりのTCP接続に適用されます。 「IKE-設定」属性のデフォルト値は、答えで提供中の「アクティブ」と「パッシブ」です。
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.
オファー側とアンサーは、IPsec NATトラバーサルの必要がない場合は、セクション4で定義されたプロトコル識別子の使用以下のIKEの使用を交渉、オファー側は、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の背後にある場合、エンドポイントはNATを介してIKEとIPsecの両方のパケットを送信する必要があります。両方のエンドポイントがUDPヘッダとのIPsec-ESPパケットをカプセル化し、IKEが生成するUDPパスにそれらを多重化：そのメカニズムは[RFC3947]と[RFC3948]で指定されています。
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セッションのこのタイプを示すには、オファー側は、「IKE-ESP-udpencap」メディア・ラインを使用しています。この場合、オファー側は、ICEフレームワークを利用して、IKEを開始する前に、それらの輸送アドレス（IPアドレスとポートの組み合わせ）を決めることができます。 UDPカプセル化ESPパケットとIKEパケットがNATの同じUDP穴を通過するので、IPsecのNATトラバーサルは、NAT経由単に1つのUDPパスICE埋蔵あれば動作します。しかし、これらのUDPパケットは、NAT（STUN）[RFC5389]パケットICEは、STUNを使用する必要がある場合のために、セッショントラバーサルユーティリティと多重化する必要があります。 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セッションを拒否します（例えば、Fromアドレスを許可リストに含まれていない）、それはに「IKE-ESP」または「IKE-ESP-udpencap」メディアラインを拒否すべきです（まだVPNなく、そのメディアを確立するのが妥当である場合のみ）を0にSDPアンサー内のポート番号を設定し、通常は他のメディア行を処理することにより、通常の方法。
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クライアントにINVITEを送信すると、サーバーは、クライアントがIKEイニシエータになることを期待することがあります。この場合、サーバは、IKE-セットアップでオファーSDP送信：パッシブは、クライアントがIKE-セットアップと回答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を必要とするようBYE要求を送ってはいけません。ハイレベルのアプリケーションは、VPNセッションが終了したことを検出する一方、それは、VPN全体のSIPセッションに関連付けられたメディアを終了することができます。 SIP [RFC4028]でのセッションタイマーは、SIPコールのセッション維持のために使用することができるが、これは必ずしもVPNセッションが生きていることを保証しません。 VPNセッションは、キープアライブおよび再入力などのセッション維持を必要とする場合、それは自身のメンテナンスのメカニズムを利用して行われなければなりません。 SIPの再INVITE、この目的のために使用してはいけません。 COMEDIA-TLS [RFC4572]のSecurity Considerations部で説明したように、各当事者が他の当事者の証明書をキャッシュできることに注意してください。
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）が唯一のユーザエージェントサーバ（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は、ポート番号を変更せずにポート500を使用してIKEセッションを多重化することができるので、IPsecのNATトラバーサルの仕様では、IKEネゴシエーション中にローカルUDPポート4500へのポートの移行が必要です。 IPsecのNAT-トラバーサルのためのICEを使用する場合は、IKEのこのポート遷移はICEは、ポート4500のための追加のUDPパスを生成するために有することを意味し、これは、不必要なオーバーヘッドであろう。しかし、IPsecのNATトラバーサルは、IKEセッションは、エンドポイントは、最初からIKEセッションのために彼らのローカルUDPポート4500を使用すべきであるため、ポート500を使用せずに最初からローカルUDPポート4500を使用すると、ICEのみを生成する必要がありますことができますポート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ポートは、IKEイニシエータは、それが送信IKEパケット500及び4500に加えて、任意の宛先ポートを許可する必要があり、したがって、必ずしも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.
ICEに準拠し、オファー側とアンサーは、SDP交換後のSTUNの接続性チェックを開始します。その後、オファー側は、STUNパケットによって生成されたUDPパスのIKEセッションを作るの使用を開始します。また、UDPカプセル化ESPパケットは、IKEと同じUDPパスに多重化されます。したがって、同じUDP路に、三つの異なるパケット、STUN、IKE、およびUDPカプセル化ESPを多重化する必要があります。このセクションでは、これら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）を確認しなければなりません。彼らは非ESPマーカーとして定義されている全て0、であれば、そのパケットは、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パケットと判断されます。 ESPからSTUNを区別することがさらに必要です。したがって、UDPペイロードの先頭からのビット32-63をチェックしなければなりません。ビットは（ほとんどのパケットが一致しない）STUN 0x2112A442のマジッククッキーと一致しない場合、それはもはやSTUNパケットであるため、パケットは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.
ビットはマジッククッキーと一致して行う場合は、追加のテストは、パケットがSTUNまたはESPであるかどうかを判断する必要があります。可能性はまだESPのシーケンス番号が0x2112A442と一致することに変わりはないので、STUNのマジッククッキーフィールドは、ESPのシーケンス番号フィールドと重なります。この追加のテストでは、STUNメッセージの指紋属性の妥当性をチェックしなければなりません。メッセージに有効な指紋があれば、それはSTUNのパケットであると判定されました。それ以外の場合は、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 } }
SPIフィールドは-すべてゼロである場合にそう{場合はビット-32スルー63 ==スタン・マジック・クッキー値とビット0スルー1 == 0とビット-2- {パケットがIKEです}スルー15 == STUNメッセージタイプと、このUDPパケットのビット-16スルー31 ==長{fingerprint_found == parse_for_stun_fingerprint（）。 {パケットがESP}}である他fingerprint_found == 1 {パケットがSTUNである} {パケットをESPである}}そうなら
6.1. Example of SDP Offer and Answer Exchange without IPsec NAT-Traversal
6.1. SDPオファーの例とは、IPsec NATトラバーサルなし交流回答します
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トラバーサルが必要でない場合は、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を分割し、この行の折りたたみが行われたバックスラッシュ文字マークをこのバックスラッシュとその末尾のCRLFと空白文字は、実際の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 ...
SDPを提供しています... M =アプリケーション500 UDP IKE-ESP IP4 192.0.2.10 = IKE-セットアップIN = C：\ 4A SHA-1：アクティブA =指紋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 ...
SDP ... M =アプリケーション500 UDP IKE-ESP C = IP4 192.0.2.20 IN = IKE-セットアップ応答：受動A =指紋：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：申出人は、IKEイニシエータであるSDP例
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 ...
SDPを提供しています... M =アプリケーション500 UDP IKE-ESP IP4 192.0.2.10 = IKE-セットアップIN = C：\ 4A SHA-1：受動A =指紋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 ...
SDPに答える... M =アプリケーション500 UDP IKE-ESP IP4 192.0.2.20 = IKE-セットアップIN = C：アクティブA =指紋：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：申出人は、IKEレスポンダですSDP例
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 ...
YH75Fviy6338Vbrhrlp8Yh A =氷ufrag：IP4 192.0.2.10 = IKE-セットアップIN 9uB6 M =アプリケーション4500 UDP IKE-ESP-udpencap C =アクティブA =指紋：SHA-1 SDP ... =氷PWDを提供\ 4A：AD：B9：B1：3F：82：18：3B：54：02：12：DF：3E：5D：49：6B：19：E5：7C：ABのA =候補：1つのUDP 2130706431 192.0。 2.10 4500標準のホスト...
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 ...
パッシブA =指紋：SHA-1 IP4 192.0.2.20 = IKE-Setupで= 8hhYメートル=アプリケーション45664 UDP IKE-ESP-udpencapのC：asd88fgpdd777uzjYhagZg A =アイスufrag：SDP ... =氷-PWDに答えます\ D2：9F：6F：1E：CD：D3：09：E8：70：65：1A：51：7C：9D：30：4F：21：E4：4A：8EのA =候補：1つのUDP 2130706431 192.0。 2.100 4500標準のホストA =候補：2 1 UDP標準srflx \ RADDR 192.0.2.100 RPORT 4500 1694498815 192.0.2.20 45664 ...
Figure 5: SDP Example with IPsec NAT-Traversal
図5：IPsecのNATトラバーサルと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セッションを開始することができます。この仕様に従うように、デジタル署名は、このプロセス、そのハッシュ値指紋と一致交換SDPにわたって使用されなければならない証明書でIKEフェーズ1における認証方法として選択されなければなりません。 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は、IPsecセキュリティアソシエーションのペアのみを持つ2つの当事者間の複数のメディアセッションを暗号化するために、トランスポートモードIPsecを交渉することができます。 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.
この場合のプロトコルの概要SDPオファー/アンサー手続きもセクション5および6の両方のエンドポイント信頼できるサードパーティを介して前関係を有する場合と同様であるセクション3と同様であるため、SIPサーバは、名前のために使用されますセッション開始の解像度と承認。そうであっても、1つのデバイスが複数の証明書を持つことができるので、彼らは、SDPに指紋を交換してもよいし、証明書には、次のIKE認証に使用される事前に指定することが必要であろう。このプロセスはまた、IKEプロセスで提供される証明書は、SIP / SDP層で承認されたピアが所有しているものと同じであることを保証します。この処理により、IKEにおけるSIPでの許可および認証は、互いに矛盾になります。
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-指紋」、SDPオーバー事前共有鍵のフィンガープリントを交換するように定義されています。この属性は、また、IKEにおける認証と一致SIPに承認を行う役割を有しています。 [RFC4572]で定義された「指紋」が証明書に適用される属性「PSK-指紋を」事前共有キーに適用されます。以下は、「PSK-指紋」属性のABNFです。 「PSK-指紋」の使用はオプションです。
attribute =/ psk-fingerprint-attribute
属性= / PSK-指紋属性
psk-fingerprint-attribute = "psk-fingerprint" ":" hash-func SP psk-fingerprint
PSK-指紋属性= "PSK-指紋" "：" ハッシュFUNCのSPのPSK-指紋
hash-func = "sha-1" / "sha-224" / "sha-256" / "sha-384" / "sha-512" / token ; Additional hash functions can only come ; from updates to RFC 3279
ハッシュFUNC = "SHA-1" / "SHA-224" / "SHA-256" / "SHA-384" / "SHA-512" /トークン。追加のハッシュ関数は来ることができます。 RFC 3279への更新から
psk-fingerprint = 2UHEX *(":" 2UHEX) ; Each byte in upper-case hex, separated ; by colons.
PSK-指紋= 2UHEX *（ "：" 2UHEX）。分離された大文字ヘクス、各バイト。コロンによります。
UHEX = DIGIT / %x41-46 ; A-F uppercase
UHEX = DIGIT /％x41-46。 -Fの大文字
An example of SDP negotiation for IKE with pre-shared key authentication without IPsec NAT-Traversal is as follows.
以下のようにIPsec NATトラバーサルのない事前共有キー認証と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 ...
SDPを提供しています... M =アプリケーション500 UDP IKE-ESP IP4 192.0.2.10 = IKE-セットアップIN = C：アクティブA = PSK-指紋：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 ...
SDP ... M =アプリケーション500 UDP IKE-ESP C = IP4 192.0.2.20 IN = IKE-セットアップ応答：受動A = PSK-指紋：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オファー/アンサーモデルのいずれかに同意する）を提供することは与えられた指紋を持つ任意のIKEセッションを受け入れるためのエンドポイントの義務を作成しません。しかし、エンドポイントは、（暗号化および認証アルゴリズムを含む）選択したのIPsecセキュリティアソシエーションは、より高いレベルのアプリケーションのセキュリティ要件を満たすことを確実にするために、標準のIKEネゴシエーションの手順に従事しなければなりません。 IKEは交渉を終えたときに、IKEを締結し、リモートピアとのIPsecセキュリティアソシエーションを確立するという決定は完全に各エンドポイントの決定です。この手順は、VPNのは、一般的にSIPの不存在下で確立されている方法に似ています。
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アイデンティティと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、正当な識別情報で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-セットアップロングフォーム名：属性のIKE設定の拡張機能タイプ：セッションレベルとメディアレベルのcharsetに件名：いいえ目的：属性IKEベースのメディアセッション適切な値のイニシエータとレスポンダを示すために：4節を参照してください。属性名RFC 6193担当者名：誠斉藤、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
Media形式名：IKE-ESPロングフォーム名：IKEはIPsecのESP関連するメディアが続く：アプリケーション関連プロト：文字セットにUDP件名：いいえ目的：仕様へのVPNセッションリファレンスとしてIKEおよびIPsec ESPを示しメディア形式：節参照RFC 6193連絡先名の5：誠斉藤、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
Media形式名：IKE-ESP-udpencapロングフォーム名：IKEはIPsecのESPまたはUDP続いIPsecのESP関連メディアをカプセル化：アプリケーション関連プロト：文字セットにUDP件名：いいえ目的：NATトラバーサルおよびIPsecをサポートしてIKEを示しメディアフォーマットESPや仕様へのVPNセッションの参考としてIPsecのESPパケットのUDPカプセル化：誠斉藤、ma.saito@nttv6.jp：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-指紋ロングフォーム名：文字セットに従うことを条件として、セッションレベルとメディアレベル：いいえ目的：属性の事前共有鍵拡張タイプの指紋属性は以下で使用される事前共有キーを示すために、属性名メディアセッション適切な値：8.2節を参照してください。誠斉藤、ma.saito@nttv6.jp：RFC 6193連絡先名の
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.
私たちは、この文書に貢献するコメントや提案を提供するためのレミデニス・Courmont、デイル・ウォーリー、リチャード・バーンズ、デヴィッド・ハンコック、スチュアートHoggan、ジャン=フランソワラバ、ゴンサロ・カマリロ、およびロバート・スパークスに感謝したいと思います。エリックレスコラは特に、セキュリティの観点から洞察に満ちたコメントを与えました。慎太郎水野と志田シューベルトも、この文書を改善するために多くの努力を貢献しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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.ボルペ、 "IKEにおけるNATトラバーサルのネゴシエーション"、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.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "IPsecのESPパケットのUDPカプセル化"、RFC 3948、2005年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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]レノックス、J.、 "接続指向のセッション記述プロトコル（SDP）でTransport Layer Security（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]ローゼンバーグ、J.、 "インタラクティブ接続確立（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]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "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]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2（IKEv2の）"、RFC 5996、2010年9月。
[RFC4474-Concerns] Rosenberg, J., "Concerns around the Applicability of RFC 4474", Work in Progress, February 2008.
[RFC4474-懸念]ローゼンバーグ、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.、フレデリック、R.、およびV.ヤコブソン、 "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.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[RFC4028]、RFC 4028 "セッション開始プロトコル（SIP）におけるセッションタイマー" ドノヴァン、S.およびJ.ローゼンバーグ、2005年4月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]ヨン、D.とG.カマリロ、 "TCPベースのセッション記述プロトコル（SDP）にメディアトランスポート"、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]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916]エルウェル、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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.レスコラ、RFC 5763、2010年5月 "セキュアリアルタイム転送プロトコル（SRTP）データグラムトランスポート層セキュリティ（DTLS）を使用して、セキュリティコンテキストを確立するためのフレームワーク"。
Authors' Addresses
著者のアドレス
Makoto Saito NTT Communications 1-1-6 Uchisaiwai-Cho, Chiyoda-ku Tokyo 100-8019 Japan
まこと さいと んっｔ こっむにかちおんｓ １ー１ー６ うちさいわいーちょ、 ちよだーく ときょ １００ー８０１９ じゃぱん
EMail: ma.saito@nttv6.jp
メールアドレス：ma.saito@nttv6.jp
Dan Wing Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States
ダン・ウイングシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134米国
EMail: dwing@cisco.com
メールアドレス：dwing@cisco.com
Masashi Toyama NTT Corporation 9-11 Midori-Cho 3-Chome, Musashino-Shi Tokyo 180-8585 Japan
まさし とやま んっｔ こｒぽらちおん ９ー１１ みどりーちょ ３ーちょめ、 むさしのーし ときょ １８０ー８５８５ じゃぱん
EMail: toyama.masashi@lab.ntt.co.jp
メールアドレス：toyama.masashi@lab.ntt.co.jp