RFC 6193
Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP)
Abstract ✨
okay so this doc is all about setting up a media session that acts like a virtual private network (VPN) 🔒. It's for on-demand media and app sharing between peers, and the whole thing runs over the Session Initiation Protocol. 💖 It extends the protocol identifier in the Session Description Protocol (SDP) so it can negotiate the Internet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. 🎀 It also covers how to boot up IKE and generate IPsec security associations using a self-signed certificate. ✨ Iconic. 💅
Status of This Memo ✨
The vibe check first: this doc is not an Internet Standards Track spec. 🌸 It's published for informational purposes only. 🧚
It's an independent contribution to the RFC Series, separate from any other RFC stream. 🦋 The RFC Editor picked to publish it at their discretion and makes no statement about its value for implementation or deployment. 💀 Documents the RFC Editor approves for publication are not a candidate for any level of Internet Standard. Go check Section 2 of RFC 5741 if you want the receipts. 📚
Want the current status, any errata, or to give feedback? Hit up 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. 🌈
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. 🎀 Read those carefully, bestie, because they spell out your rights and restrictions for this doc. 👑
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 ...................................211. Applicability Statement ✨
okay bestie, this one is important 🚨. The doc gives info about a deployed use of the Session Initiation Protocol (SIP) [RFC3261] for the Internet community. 💖 It is not currently an IETF standards track proposal. 🌸
Here's the tea: SIP is used as a name resolution and authentication mechanism to kick off an Internet Key Exchange Protocol (IKE) [RFC5996] session. ✨ The goal is an on-demand virtual private network (VPN) to a home router that doesn't have a fixed IP address, using self-signed certificates. 🏠🔐 It's only applicable when the integrity of the Session Description Protocol (SDP) [RFC4566] is assured. 🎀 How you ensure that integrity is outside this doc's scope, so don't look for it here. 🙈
This doc walks through how a pair of SIP user agents resolve each other's names, securely swap fingerprints of their self-signed certificates, and agree to set up an IPsec-based VPN [RFC4301]. 🦋 It does not change the IPsec or IKE specs at all. 👑 The limits are real, but there are still plenty of use cases where this is super helpful, like:
- Sharing media over a VPN between two user devices, using a framework from the Digital Living Network Alliance (DLNA) or similar protocols. 📺
- Accessing remote desktop apps over a VPN started by a SIP call. 💻 Like, a customer service agent can access a customer's PC remotely to troubleshoot while they're chatting on the phone. 📞 Click-to-call, but make it cute. 💅
- Accessing and controlling medical equipment (medical robotics) remotely to monitor elderly folks in rural areas, aka remote care services. 🩺🌾
- Playing a LAN-based game that's peer-to-peer instead of going through a gaming server. 🎮🌈
2. Introduction ✨
This section is the setup: it describes the problem with getting into home networks and gives a quick overview of the proposed fix. 🧚
2.1. Problem Statement 🌸
Home servers and network-capable consumer electronics are everywhere now. 📱 People love sharing content and apps with each other, so they're always looking for ways to set up multiple communication channels. 💜 But remote home access comes with some real obstacles, lowkey annoying ones. 😭
Okay so, a device outside the home network often can't connect to a device inside it. 🚫 That's because the home device sits behind a network address translation (NAT) or firewall that lets outgoing connections through but blocks incoming ones. 🧱 One solid fix is VPN remote access to the NAT device, which is usually the home router. 🏡 Once the outside device joins the home network securely, connecting to everything inside becomes easy, since popular LAN-based methods like DLNA work transparently. 🫶
It gets harder when the home router is itself behind a NAT. 😵💫 In that case, you also need NAT traversal for remote access to the home router. 🦋 Plus, the home router's global IP address isn't always fixed, so you need a good name resolution mechanism too. 🔍
Then there's authentication. 🔐 A remote client and a home router have to authenticate each other over IKE to set up IPsec for remote access, and they can't always securely swap a pre-shared key ahead of time. 🙃 Admin costs can make it impractical to hand out certificates signed by a well-known root certification authority (CA) to every device. 💸 And publishing a temporary certificate for a device with no fixed IP address or hostname is inefficient. 🤦♀️ To solve these auth issues, this doc proposes a mechanism where the devices authenticate each other using self-signed certificates. 🎀✨
2.2. Approach to Solution
okay so this doc is proposing SIP as the name resolution and authentication mechanism, and it's giving three main reasons 💅✨
- Delegation of Authentication to Third Party: devices don't have to babysit their own signed certificates and whitelists 🫶 they can lean on the authentication and authorization stuff SIP already supports 🎀
- UDP Hole Punching for IKE/IPsec: SIP has a cross-NAT rendezvous mechanism, and Interactive Connectivity Establishment (ICE) [RFC5245] can open ports through the NAT 🦋 put those together and you get something that works for general apps AND real-time media. Setting up a session between devices behind different types of NAT without SIP is really hard, ngl 😭
- Reuse of Existing SIP Infrastructure: SIP servers are already widely deployed as a scalable infrastructure, so reusing them without any modifications is super practical 🌸
Today SIP isn't just for Voice over IP (VoIP) anymore. It's used for all kinds of apps and is recognized as a general protocol for session initiation, so it can also be used to kick off IKE/IPsec sessions. Literally main character energy 👑
BUT, there's already a spec 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] (called comedia-tls from here on) describes how to swap the fingerprint of a self-signed certificate so a Transport Layer Security (TLS) [RFC5246] connection can be set up. This spec says self-signed certificates can be used securely, as long as the integrity of the SDP description is assured 🔥 And since a certificate is used for authentication in IKE too, not only TLS, this mechanism gets applied to setting up an IPsec security association (SA) by extending the SDP protocol identifier so it can specify IKE 🧚
One easy way to protect the integrity of the SDP description (which is the whole premise here 🙈) is the SIP identity [RFC4474] mechanism. [RFC5763] also refers to this approach. SIP identity can protect the integrity of a body part and the value of the From header in a SIP request using a valid Identity header. So the receiver can set up secure IPsec connections with the sender by checking that the hash value of the certificate sent during IKE negotiation matches the fingerprint in the SDP. SIP identity doesn't protect the identity of the receiver of the SIP request, but SIP-connected identity [RFC4916] does 💜 Also, the possible deficiencies discussed in [RFC4474-Concerns] could affect this spec if SIP identity is used for the security mechanism. Noted, bestie ⚠️
Okay so with all that in mind, this document defines the new media formats "ike-esp" and "ike-esp-udpencap". They can be used when the protocol identifier is "udp", and they enable negotiating IKE for media sessions over an SDP exchange, on the condition that the integrity of the SDP description is assured 🎀 It also specifies how 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] plus the points implementations should take care of. Because devices might be behind NAT, this doc also covers how to combine IKE/IPsec NAT-Traversal [RFC3947][RFC3948] with ICE 🦋 And it defines the attribute "ike-setup" for IKE media sessions, similar to the "setup" attribute for TCP-based media transport in RFC 4145 [RFC4145]. This attribute negotiates the role of each endpoint in the IKE session 💖
2.3. Alternative Solution under Prior Relationship between Two Nodes
Under pretty limited conditions, certificates signed by trusted third parties or pre-shared keys between endpoints could be used for authentication in IKE. SIP servers would only handle name resolution and authorization of session initiation in that case. Those limited cases are covered in Section 8 🌈
2.4. Authorization Model
In this doc, SIP servers are used to authorize each SIP call. The actual IPsec/IKE media sessions aren't authorized by SIP servers, though. They're authorized by the remote client and the home router, based on the info in SIP/SDP ✨ For example, the home router recognizes the remote client by its SIP-URI and its 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 IKE negotiation, the certificate fingerprint in the SDP gets 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
Okay, 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] 🤓📚
3. Protocol Overview
Figure 1 shows a VPN remote access case: a device outside the home connects to a home router whose IP address isn't fixed 🏠 The external device, the remote client, knows the Address of Record of the home router but has no info about its contact address or certificate. Generally, setting up an IPsec SA dynamically and securely in this situation is hard 😭 BUT, as comedia-tls [RFC4572] specifies, if the integrity of SDP session descriptions is assured, the home router and the remote client can have a prior relationship by exchanging certificate fingerprints. Those are 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 set up 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 💅
(4) Remote Client joins the Home Network 🏡🎉
By this method, the self-signed certificates of both parties are used for authentication in IKE. SDP itself isn't concerned with all the negotiations related to key exchange, like encryption and authentication algorithms. Those negotiations are up to IKE 🧚 In many cases where IPsec is used for remote access, a remote client needs to dynamically get a private address inside the home network while it's initiating the remote access. So the IPsec security policy also needs to be set dynamically at the same time. BUT, managing the security policy is the responsibility of the high-level application, not SDP 🙈 SDP's roles here are to determine the IP addresses of both parties used for the IKE connection with the 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 "ike-esp" format means the media described is IKE for establishing an IPsec security association, as described in IPsec Encapsulating Security Payload (ESP) [RFC4303]. "ike-esp-udpencap" means the media described is IKE that's capable of NAT traversal, for establishing 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 setting up a normal IPsec tunnel when there's no need for 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 💜
This doc also defines a new attribute, "ike-setup" 🌸 It can be used when the protocol identifier is "udp" and the "fmt" field is "ike-esp" or "ike-esp-udpencap", to describe how endpoints should do the IKE session setup procedure. The "ike-setup" attribute says which endpoint should start setting up an IKE session. It's charset-independent, and it can be a session-level or media-level attribute. Here's the ABNF for it, bestie 📜
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 defined for the "setup" attribute 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 / passiveThe semantics for the "ike-setup" attribute values "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]. The one difference is 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 ✨
okay so this section is where the actual rules live 📜 It describes a way to negotiate IKE for media sessions using the SDP offer/answer model. bestie, let's get into it 🫶
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 🎀.
ngl, NAT is the chaotic part. If either of the endpoints that negotiate IKE is behind the NAT, both endpoints need to send IKE and IPsec packets through it 😭. That's handled in [RFC3947] and [RFC3948]: both endpoints wrap IPsec-ESP packets in a UDP header and multiplex them into the UDP path that IKE generates 🦋.
To indicate this kind of IKE session, the offerer uses ike-esp-udpencap media lines 🌸. In this case, the offerer MAY decide its transport addresses (the combo of IP address and port) before starting IKE, using the ICE framework 💅. Because UDP-encapsulated ESP packets and IKE packets go through the same UDP hole in a NAT, IPsec NAT-Traversal works as long as ICE reserves just one UDP path through the NAT ✨. However, those UDP packets have 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, an audio stream can be included in the same SDP so there's a voice session while the VPN is being set up. This may be useful to verify that the connected device is actually operated by somebody who is authorized to access it, as described in Section 9 🔥. If that happens, the negotiation described in this specification only happens for the ike-esp or ike-esp-udpencap media lines, and the other media lines are negotiated and set up normally 🧚.
If the answerer decides it will refuse the IKE session without starting 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 it SHOULD process the other media lines normally (only if it is still reasonable to establish that media without a VPN) 🙅♀️.
If the offerer and the answerer agree to start an IKE session through 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.
Also, the offerer can end up as the IKE responder and the answerer as the IKE initiator, which is a plot twist 😭. For example, when a Remote Access Server (RAS) sends an INVITE to a 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. So 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 has been terminated, it MAY terminate the media associated with the VPN or the entire SIP session.
Session timers in SIP [RFC4028] MAY be used for session maintenance of the SIP call, but this does not necessarily ensure that the VPN session is still alive 🥺. If the VPN session needs session maintenance such as keep-alive and rekeying, it MUST be done using its own maintenance mechanisms. A SIP re-INVITE MUST NOT be used for this purpose 💀. Also, 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 an IPsec-aware NAT may multiplex IKE sessions using port 500 without changing the port number 🙃. If ICE is used for IPsec NAT-Traversal, this port transition of IKE means ICE has to generate an additional UDP path for port 4500, which 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 ✨. So the endpoints SHOULD use their local UDP port 4500 for an IKE session from the start, and ICE will only need to generate a UDP path for port 4500 🦋.
When using ICE, the port an initiator observes for a responder's IKE 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 starts an IKE session on the port number decided by an SDP offer/answer or ICE 💅.
5.5. Multiplexing UDP Messages When Using ICE 🧩
Following ICE, an offerer and an answerer start a STUN connectivity check after the SDP exchange. Then the offerer initiates the IKE session using the UDP path generated by STUN packets. On top of that, UDP-encapsulated ESP packets are multiplexed into the same UDP path as IKE. So it's 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.
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's also necessary to tell STUN apart from ESP, so the bits 32-63 from the beginning of the UDP payload MUST be checked. If those bits do not match the STUN magic cookie 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 needed to determine whether the packet is STUN or ESP. The magic cookie field of STUN overlaps the sequence number field of ESP, so there's still a possibility that the ESP sequence number 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 }
}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 the SDP exchange are below.
(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
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 💫.
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 ✨
okay so once both parties have securely shared their fingerprints over the SDP exchange, the IKE initiator MAY start the IKE session with the other party 💌 to follow this spec, a digital signature MUST be chosen as the authentication method in IKE phase 1 🔐. the certificate used has to have a hash value that matches the fingerprint you swapped over SDP, so it MUST be used 🫶 and if the certificate in IKE doesn't match the original fingerprint, the endpoint MUST terminate the IKE session by detecting an authentication failure 💀 no notes, that's the vibe.
and also, each party MUST present a certificate and be authenticated by each other 🎀 mutual auth or nothing, bestie.
the example in Section 3 is for tunnel mode IPsec used for remote access, but the negotiated IPsec mode 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 the SDP offer/answer model is responsible for is exchanging the fingerprints of the certificates used for IKE 🌸 so the SDP offer/answer is not responsible for setting the security policy. it just isn't its job, periodt 💅
8. Specifications Assuming Prior Relationship between Two Nodes 👑
this section covers the specification for the limited cases where certificates signed by trusted third parties or pre-shared keys between endpoints can be used for authentication in IKE 🧸 since the endpoints already have a prior relationship here, they use SIP servers for only name resolution and authorization ✨ however, even in this case, the integrity of the SDP description MUST be assured 🔒 no skipping that, ever.
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 handle 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 makes sure the certificate offered in IKE is the same one owned by the peer that was authorized at the SIP/SDP layer 🫶 so authorization in SIP and authentication in IKE become consistent with each other. consistency is the whole mood ✨
8.2. Configured Pre-Shared Key 🔑
if a pre-shared key for IKE authentication is installed in both endpoints in advance, they don't need to exchange the fingerprints of their certificates 🌸 however, they may still need to say which pre-shared key they'll use in the following IKE authentication in SDP, because they may have several pre-shared keys 🙈 so a new attribute, psk-fingerprint, is defined to exchange the fingerprint of a pre-shared key over SDP 💖 this attribute also makes authorization in SIP consistent with authentication in IKE. psk-fingerprint is applied to pre-shared keys the same way the "fingerprint" from [RFC4572] is applied to certificates 🎀 here's the ABNF for the psk-fingerprint attribute. using psk-fingerprint is OPTIONAL 🌈
attribute =/ psk-fingerprint-attribute
psk-fingerprint-attribute = "psk-fingerprint" ":" hash-func SP
psk-fingerprint
hash-func = "sha-1" / "sha-224" / "sha-256" /
"sha-384" / "sha-512" / token
; Additional hash functions can only come
; from updates to RFC 3279
psk-fingerprint = 2UHEX *(":" 2UHEX)
; Each byte in upper-case hex, separated
; by colons.
UHEX = DIGIT / %x41-46 ; A-F uppercasehere's an example of SDP negotiation for IKE with pre-shared key authentication, without IPsec NAT-Traversal 🧚
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 💀
okay, this entire document is about security 😭 the security considerations that apply to SDP in general are described in the SDP specification [RFC4566]. the security issues you should think about when using comedia-tls are described in Section 7 of its specification [RFC4572]. this section mainly covers the security considerations specific to negotiating 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 make sure the chosen IPsec security associations (including encryption and authentication algorithms) meet the security requirements of the higher-level application 🛡️ once IKE has finished negotiating, the decision to conclude IKE and establish an IPsec security association with the remote peer is entirely up to each endpoint 👑 this is pretty similar to how VPNs are usually set up when there's no SIP involved 🦋
in the general authentication process in IKE, the subject DN or subjectAltName is recognized as the identity of the remote party 🫣 but by using the SIP identity and SIP-connected identity mechanisms in this spec, certificates are only used as carriers for the peers' public keys 💖 so there's no need for info about who signed the certificate or who is named in the 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 can't provide end-to-end security inside the VPN as long as the VPN uses tunnel mode IPsec 😬 so other security methods, like the Secure Real-time Transport Protocol (SRTP) [RFC3711], must be used to secure the packets 🔐
when you use the specification in this document, you need to keep in mind that security based on SIP authentication provided by a SIP proxy may be breached under the following circumstances 🚨
- if a legitimate user's terminal is used by another person, that person may be able to establish a VPN with the legitimate identity information. this issue also applies to general VPN cases based on a shared secret key. furthermore, SIP has a similar problem when file transfer, IM, or comedia-tls is used for non-voice/video communication 🙈
- if a malicious user hijacks the proxy, they can use whatever credential is on the Access Control List (ACL) to gain access to the home network 😈
to counter 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 the VPN would be another method 📞
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.jp11. Acknowledgments 🫶
huge thank-you to Remi Denis-Courmont, Dale Worley, Richard Barnes, David Hancock, Stuart Hoggan, Jean-Francois Mule, Gonzalo Camarillo, and Robert Sparks for giving comments and suggestions that helped make this document 💜 Eric Rescorla especially gave insightful comments from a security point of view 🔐 and Shintaro Mizuno and Shida Schubert put a ton of effort into improving this document too 🌟 you all are literal legends 👑
12. References 📚
the reference list picks up in the next part 🦋
12.1. Normative References
okay bestie, these are the docs the spec leans on the hardest, so you really want these in your back pocket 📚✨ Here's the full list, no cap:
[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.
[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
these ones are the extra reading 🦋 handy for context, but the spec doesn't need you to have them memorized:
[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.
Authors' Addresses 💖
the people who wrote this, and where to find them 🌸
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📦 where this page comes from
- ietf: rfc6193 2011-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms