From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6193.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc6193.txt (limited to 'doc/rfc/rfc6193.txt') diff --git a/doc/rfc/rfc6193.txt b/doc/rfc/rfc6193.txt new file mode 100644 index 0000000..31f9240 --- /dev/null +++ b/doc/rfc/rfc6193.txt @@ -0,0 +1,1235 @@ + + + + + + +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. + +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. + + 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. + + + + + + + + + + + + + +Saito, et al. Informational [Page 1] + +RFC 6193 Media Description for IKE in SDP April 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + +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 + + + + + + +Saito, et al. Informational [Page 2] + +RFC 6193 Media Description for IKE in SDP April 2011 + + +1. Applicability Statement + + 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: + + o Sharing media using a framework developed by Digital Living + Network Alliance (DLNA) or similar protocols over VPN between two + user devices. + + 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 Accessing and controlling medical equipment (medical robotics) + remotely to monitor the elderly in a rural area (remote care + services). + + o Using a LAN-based gaming protocol based on peer-to-peer rather + than via a gaming server. + +2. Introduction + + This section describes the problem in accessing home networks and + provides an overview of the proposed solution. + + + + + + + + + +Saito, et al. Informational [Page 3] + +RFC 6193 Media Description for IKE in SDP April 2011 + + +2.1. Problem Statement + + 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. + + 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. + +2.2. Approach to Solution + + This document proposes the use of SIP as a name resolution and + authentication mechanism because of three main advantages: + + o Delegation of Authentication to Third Party + + Devices can be free from managing their signed certificates and + whitelists by taking advantage of authentication and authorization + mechanisms supported by SIP. + + + + + +Saito, et al. Informational [Page 4] + +RFC 6193 Media Description for IKE in SDP April 2011 + + + o UDP Hole Punching for IKE/IPsec + + 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. + + o Reuse of Existing SIP Infrastructure + + SIP servers are widely distributed as a scalable infrastructure, + and it is quite practical to reuse them without any modifications. + + 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. + + 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. + + 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. + + + +Saito, et al. Informational [Page 5] + +RFC 6193 Media Description for IKE in SDP April 2011 + + + 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. + +2.3. Alternative Solution under Prior Relationship between Two Nodes + + 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. + +2.4. Authorization Model + + 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. + +2.5. Conventions Used in This Document + + 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]. + + + + + + + + +Saito, et al. Informational [Page 6] + +RFC 6193 Media Description for IKE in SDP April 2011 + + +3. Protocol Overview + + 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. + + 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) Both Remote Client and Home Router generate secure signaling + channels. They may REGISTER to SIP Proxy using TLS. + + (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. + + (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 + + + + +Saito, et al. Informational [Page 7] + +RFC 6193 Media Description for IKE in SDP April 2011 + + + matches the fingerprint from SDP. If they match, IKE + negotiation proceeds as normal. + + (4) Remote Client joins the Home Network. + + 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. + +4. Protocol Identifiers + + 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. + + 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. + + + + + + +Saito, et al. Informational [Page 8] + +RFC 6193 Media Description for IKE in SDP April 2011 + + + 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. + + 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. + + 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. + +5. Normative Behavior + + In this section, a method to negotiate the use of IKE for media + sessions in the SDP offer/answer model is described. + +5.1. SDP Offer and Answer Exchange + + 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. + + 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. + + 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 + + + +Saito, et al. Informational [Page 9] + +RFC 6193 Media Description for IKE in SDP April 2011 + + + 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. + + 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). + + 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. + + 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. + +5.2. Maintenance and Termination of VPN Session + + 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 + + + +Saito, et al. Informational [Page 10] + +RFC 6193 Media Description for IKE in SDP April 2011 + + + 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]. + +5.3. Forking + + 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. + +5.4. Port Usage + + 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. + + 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. + +5.5. Multiplexing UDP Messages When Using ICE + + 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. + + + + +Saito, et al. Informational [Page 11] + +RFC 6193 Media Description for IKE in SDP April 2011 + + + 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. + + 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. + + 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. + + 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 } + } + + + + + + + + + + +Saito, et al. Informational [Page 12] + +RFC 6193 Media Description for IKE in SDP April 2011 + + +6. Examples + +6.1. Example of SDP Offer and Answer Exchange without IPsec NAT- + Traversal + + If IPsec NAT-Traversal is not necessary, SDP negotiation to set up + IKE is quite simple. Examples of SDP exchange are as follows. + + (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.) + + 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 + + + + + + + + + + + + + + + + + + +Saito, et al. Informational [Page 13] + +RFC 6193 Media Description for IKE in SDP April 2011 + + + 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 + +6.2. Example of SDP Offer and Answer Exchange with IPsec NAT-Traversal + + 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 + + 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. + + + + +Saito, et al. Informational [Page 14] + +RFC 6193 Media Description for IKE in SDP April 2011 + + + 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 + +7. Application to IKE + + 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. + + 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 + + + +Saito, et al. Informational [Page 15] + +RFC 6193 Media Description for IKE in SDP April 2011 + + + certificates used for IKE; therefore, the SDP offer/answer is not + responsible for setting the security policy. + +8. Specifications Assuming Prior Relationship between Two Nodes + + 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. + +8.1. Certificates Signed by Trusted Third Party + + 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. + +8.2. Configured Pre-Shared Key + + 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. + + attribute =/ psk-fingerprint-attribute + + psk-fingerprint-attribute = "psk-fingerprint" ":" hash-func SP + psk-fingerprint + + + + +Saito, et al. Informational [Page 16] + +RFC 6193 Media Description for IKE in SDP April 2011 + + + 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. + + 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 + +9. Security Considerations + + 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. + + 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 + + + +Saito, et al. Informational [Page 17] + +RFC 6193 Media Description for IKE in SDP April 2011 + + + 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. + + 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. + + 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. + + 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. + + 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 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. + + 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. + + + + + + + + + + + +Saito, et al. Informational [Page 18] + +RFC 6193 Media Description for IKE in SDP April 2011 + + +10. IANA Considerations + + IANA has registered the following new SDP attributes and media + formats. + + 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 + + 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 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 + + + 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 + + + + +Saito, et al. Informational [Page 19] + +RFC 6193 Media Description for IKE in SDP April 2011 + + +11. Acknowledgments + + 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. + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [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. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, June + 2002. + + [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, + "Negotiation of NAT-Traversal in the IKE", RFC 3947, + January 2005. + + [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. + Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC + 3948, January 2005. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC + 4303, December 2005. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the + Transport Layer Security (TLS) Protocol in the Session + Description Protocol (SDP)", RFC 4572, July 2006. + + + + + +Saito, et al. Informational [Page 20] + +RFC 6193 Media Description for IKE in SDP April 2011 + + + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", RFC 5245, April + 2010. + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + October 2008. + + [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, + "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC + 5996, September 2010. + +12.2. Informative References + + [RFC4474-Concerns] + Rosenberg, J., "Concerns around the Applicability of RFC + 4474", Work in Progress, February 2008. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, March 2004. + + [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the + Session Initiation Protocol (SIP)", RFC 4028, April 2005. + + [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in + the Session Description Protocol (SDP)", RFC 4145, + September 2005. + + [RFC4474] Peterson, J. and C. Jennings, "Enhancements for + Authenticated Identity Management in the Session + Initiation Protocol (SIP)", RFC 4474, August 2006. + + [RFC4916] Elwell, J., "Connected Identity in the Session Initiation + Protocol (SIP)", RFC 4916, June 2007. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [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. + + + +Saito, et al. Informational [Page 21] + +RFC 6193 Media Description for IKE in SDP April 2011 + + +Authors' Addresses + + 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 + + EMail: 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 + + + + + + + + + + + + + + + + + + + + + + + + +Saito, et al. Informational [Page 22] + -- cgit v1.2.3