Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
RFC 4572

Document	Type	RFC - Proposed Standard (July 2006) Obsoleted by RFC 8122 Updates RFC 4145 Was draft-ietf-mmusic-comedia-tls (mmusic WG)
	Author	Jonathan Lennox
	Last updated	2018-12-20
	RFC stream	Internet Engineering Task Force (IETF)
	Formats	txt html pdf htmlized bibtex
	Additional resources	Mailing list discussion
IESG	Responsible AD	Allison J. Mankin
	Send notices to	(None)

Email authors Email WG IPR References Referenced by Search Lists

RFC 4572

Network Working Group J. Lennox
Request for Comments: 4572 Columbia U.
Updates: 4145 July 2006
Category: Standards Track

Connection-Oriented Media Transport over the Transport Layer Security
(TLS) Protocol in the Session Description Protocol (SDP)

Status of This Memo

This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.

Abstract

This document specifies how to establish secure connection-oriented
media transport sessions over the Transport Layer Security (TLS)
protocol using the Session Description Protocol (SDP). It defines a
new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax
and semantics for an SDP 'fingerprint' attribute that identifies the
certificate that will be presented for the TLS session. This
mechanism allows media transport over TLS connections to be
established securely, so long as the integrity of session
descriptions is assured.

This document extends and updates RFC 4145.

Lennox Standards Track [Page 1]
RFC 4572 Comedia over TLS in SDP July 2006

Table of Contents

1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................4
3.1. SDP Operational Modes ......................................4
3.2. Threat Model ...............................................5
3.3. The Need for Self-Signed Certificates ......................5
3.4. Example SDP Description for TLS Connection .................6
4. Protocol Identifiers ............................................6
5. Fingerprint Attribute ...........................................7
6. Endpoint Identification .........................................9
6.1. Certificate Choice .........................................9
6.2. Certificate Presentation ..................................10
7. Security Considerations ........................................10
8. IANA Considerations ............................................12
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15

Lennox Standards Track [Page 2]
RFC 4572 Comedia over TLS in SDP July 2006

1. Introduction

The Session Description Protocol (SDP) [1] provides a general-purpose
format for describing multimedia sessions in announcements or
invitations. For many applications, it is desirable to establish, as
part of a multimedia session, a media stream that uses a connection-
oriented transport. RFC 4145, Connection-Oriented Media Transport in
the Session Description Protocol (SDP) [2], specifies a general
mechanism for describing and establishing such connection-oriented
streams; however, the only transport protocol it directly supports is
TCP. In many cases, session participants wish to provide
confidentiality, data integrity, and authentication for their media
sessions. This document therefore extends the Connection-Oriented
Media specification to allow session descriptions to describe media
sessions that use the Transport Layer Security (TLS) protocol [3].

The TLS protocol allows applications to communicate over a channel
that provides confidentiality and data integrity. The TLS
specification, however, does not specify how specific protocols
establish and use this secure channel; particularly, TLS leaves the
question of how to interpret and validate authentication certificates
as an issue for the protocols that run over TLS. This document
specifies such usage for the case of connection-oriented media
transport.

Complicating this issue, endpoints exchanging media will often be
unable to obtain authentication certificates signed by a well-known
root certification authority (CA). Most certificate authorities
charge for signed certificates, particularly host-based certificates;
additionally, there is a substantial administrative overhead to
obtaining signed certificates, as certification authorities must be
able to confirm that they are issuing the signed certificates to the
correct party. Furthermore, in many cases endpoints' IP addresses
and host names are dynamic: they may be obtained from DHCP, for
example. It is impractical to obtain a CA-signed certificate valid
for the duration of a DHCP lease. For such hosts, self-signed
certificates are usually the only option. This specification defines
a mechanism that allows self-signed certificates can be used
securely, provided that the integrity of the SDP description is
assured. It provides for endpoints to include a secure hash of their
certificate, known as the "certificate fingerprint", within the
session description. Provided that the fingerprint of the offered
certificate matches the one in the session description, end hosts can
trust even self-signed certificates.

The rest of this document is laid out as follows. An overview of the
problem and threat model is given in Section 3. Section 4 gives the
basic mechanism for establishing TLS-based connected-oriented media

Lennox Standards Track [Page 3]
RFC 4572 Comedia over TLS in SDP July 2006

in SDP. Section 5 describes the SDP fingerprint attribute, which,
assuming that the integrity of SDP content is assured, allows the
secure use of self-signed certificates. Section 6 describes which
X.509 certificates are presented, and how they are used in TLS.
Section 7 discusses additional security considerations.

2. Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and
indicate requirement levels for compliant implementations.

3. Overview

This section discusses the threat model that motivates TLS transport
for connection-oriented media streams. It also discusses in more
detail the need for end systems to use self-signed certificates.

3.1. SDP Operational Modes

There are two principal operational modes for multimedia sessions:
advertised and offer-answer. Advertised sessions are the simpler
mode. In this mode, a server publishes, in some manner, an SDP
session description of a multimedia session it is making available.
The classic example of this mode of operation is the Session
Announcement Protocol (SAP) [15], in which SDP session descriptions
are periodically transmitted to a well-known multicast group.
Traditionally, these descriptions involve multicast conferences, but
unicast sessions are also possible. (Connection-oriented media,
obviously, cannot use multicast.) Recipients of a session
description connect to the addresses published in the session
description. These recipients may not previously have been known to
the advertiser of the session description.

Alternatively, SDP conferences can operate in offer-answer mode [5].
This mode allows two participants in a multimedia session to
negotiate the multimedia session between them. In this model, one
participant offers the other a description of the desired session
from its perspective, and the other participant answers with the
desired session from its own perspective. In this mode, each of the
participants in the session has knowledge of the other one. This is
the mode of operation used by the Session Initiation Protocol (SIP)
[16].

Lennox Standards Track [Page 4]
RFC 4572 Comedia over TLS in SDP July 2006

3.2. Threat Model

Participants in multimedia conferences often wish to guarantee
confidentiality, data integrity, and authentication for their media
sessions. This section describes various types of attackers and the
ways they attempt to violate these guarantees. It then describes how
the TLS protocol can be used to thwart the attackers.

The simplest type of attacker is one who listens passively to the
traffic associated with a multimedia session. This attacker might,
for example, be on the same local-area or wireless network as one of
the participants in a conference. This sort of attacker does not
threaten a connection's data integrity or authentication, and almost
any operational mode of TLS can provide media stream confidentiality.

More sophisticated is an attacker who can send his own data traffic
over the network, but who cannot modify or redirect valid traffic.
In SDP's 'advertised' operational mode, this can barely be considered
an attack; media sessions are expected to be initiated from anywhere
on the network. In SDP's offer-answer mode, however, this type of
attack is more serious. An attacker could initiate a connection to
one or both of the endpoints of a session, thus impersonating an
endpoint, or acting as a man in the middle to listen in on their
communications. To thwart these attacks, TLS uses endpoint
certificates. So long as the certificatesif all ports are allowed, this field MUST be zero. ICMP and
ICMPv6 Type and Code values, as well as Mobile IP version 6
(MIPv6) mobility header (MH) Type values, are represented in this
field as specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type
and Code values are treated as a single 16-bit integer port
number, with Type in the most significant eight bits and Code in
the least significant eight bits. MIPv6 MH Type values are
treated as a single 16-bit integer port number, with Type in the
most significant eight bits and the least significant eight bits
set to zero.

o End Port (2 octets, unsigned integer) - Value specifying the
largest port number allowed by this Traffic Selector. For
protocols for which port is undefined (including protocol 0), or
if all ports are allowed, this field MUST be 65535. ICMP and
ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are
represented in this field as specified in Section 4.4.1.1 of
[IPSECARCH]. ICMP Type and Code values are treated as a single
16-bit integer port number, with Type in the most significant
eight bits and Code in the least significant eight bits. MIPv6 MH
Type values are treated as a single 16-bit integer port number,
with Type in the most significant eight bits and the least
significant eight bits set to zero.

o Starting Address - The smallest address included in this Traffic
Selector (length determined by TS Type).

o Ending Address - The largest address included in this Traffic
Selector (length determined by TS Type).

Systems that are complying with [IPSECARCH] that wish to indicate
"ANY" ports MUST set the start port to 0 and the end port to 65535;
note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems
working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but
not "ANY" ports, MUST set the start port to 65535 and the end port to
0.

The Traffic Selector types 7 and 8 can also refer to ICMP or ICMPv6
type and code fields, as well as MH Type fields for the IPv6 mobility
header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets
have separate source and destination fields. The method for
specifying the Traffic Selectors for ICMP and MIPv6 is shown by
example in Section 4.4.1.3 of [IPSECARCH].

The following table lists values for the Traffic Selector Type field
and the corresponding Address Selector Data. The values in the
following table are only current as of the publication date of RFC
4306. Other values may have been added since then or will be added

Kaufman, et al. Expires May 17, 2014 [Page 107]
Internet-Draft IKEv2bis November 2013

after the publication of this document. Readers should refer to
[IKEV2IANA] for the latest values.

TS Type Value
-------------------------------------------------------------------
TS_IPV4_ADDR_RANGE 7

A range of IPv4 addresses, represented by two four-octet
values. The first value is the beginning IPv4 address
(inclusive) and the second value is the ending IPv4 address
(inclusive). All addresses falling between the two specified
addresses are considered to be within the list.

TS_IPV6_ADDR_RANGE 8

A range of IPv6 addresses, represented by two sixteen-octet
values. The first value is the beginning IPv6 address
(inclusive) and the second value is the ending IPv6 address
(inclusive). All addresses falling between the two specified
addresses are considered to be within the list.

3.14. Encrypted Payload

The Encrypted payload, denoted SK{...} in this document, contains
other payloads in encrypted form. The Encrypted payload, if present
in a message, MUST be the last payload in the message. Often, it is
the only payload in the message. This payload is also called the
"Encrypted and Authenticated" payload.

The algorithms for encryption and integrity protection are negotiated
during IKE SA setup, and the keys are computed as specified in
Sections 2.14 and 2.18.

This document specifies the cryptographic processing of Encrypted
payloads using a block cipher in CBC mode and an integrity check
algorithm that computes a fixed-length checksum over a variable size
message. The design is modeled after the ESP algorithms described in
RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document
completely specifies the cryptographic processing of IKE data, but
those documents should be consulted for design rationale. Future
documents may specify the processing of Encrypted payloads for other
types of transforms, such as counter mode encryption and
authenticated encryption algorithms. Peers MUST NOT negotiate
transforms for which no such specification exists.

When an authenticated encryption algorithm is used to protect the IKE
SA, the construction of the Encrypted payload is different than what
is described here. See [AEAD] for more information on authenticated

Kaufman, et al. Expires May 17, 2014 [Page 108]
Internet-Draft IKEv2bis November 2013

encryption algorithms and their use in ESP.

The payload type for an Encrypted payload is forty-six (46). The
Encrypted payload consists of the IKE generic payload header followed
by individual fields as follows:

1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| (length is block size for encryption algorithm) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encrypted IKE Payloads ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 21: Encrypted Payload Format

o Next Payload - The payload type of the first embedded payload.
Note that this is an exception in the standard header format,
since the Encrypted payload is the last payload in the message and
therefore the Next Payload field would normally be zero. But
because the content of this payload is embedded payloads and there
was no natural place to put the type of the first one, that type
is placed here.

o Payload Length - Includes the lengths of the header,
initialization vector (IV), Encrypted IKE payloads, Padding, Pad
Length, and Integrity Checksum Data.

o Initialization Vector - For CBC mode ciphers, the length of the
initialization vector (IV) is equal to the block length of the
underlying encryption algorithm. Senders MUST select a new
unpredictable IV for every message; recipients MUST accept any
value. The reader is encouraged to consult [MODES] for advice on
IV generation. In particular, using the final ciphertext block of
the previous message is not considered unpredictable. For modes
other than CBC, the IV format and processing is specified in the
document specifying the encryption algorithm and mode.

Kaufman, et al. Expires May 17, 2014 [Page 109]
Internet-Draft IKEv2bis November 2013

o IKE payloads are as specified earlier in this section. This field
is encrypted with the negotiated cipher.

o Padding MAY contain any value chosen by the sender, and MUST have
a length that makes the combination of the payloads, the Padding,
and the Pad Length to be a multiple of the encryption block size.
This field is encrypted with the negotiated cipher.

o Pad Length is the length of the Padding field. The sender SHOULD
set the Pad Length to the minimum value that makes the combination
of the payloads, the Padding, and the Pad Length a multiple of the
block size, but the recipient MUST accept any length that results
in proper alignment. This field is encrypted with the negotiated
cipher.

o Integrity Checksum Data is the cryptographic checksum of the
entire message starting with the Fixed IKE header through the Pad
Length. The checksum MUST be computed over the encrypted message.
Its length is determined by the integrity algorithm negotiated.

3.15. Configuration Payload

The Configuration payload, denoted CP in this document, is used to
exchange configuration information between IKE peers. The exchange
is for an IRAC to request an internal IP address from an IRAS and to
exchange other information of the sort that one would acquire with
Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly
connected to a LAN.

The Configuration payload is defined as follows:

1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CFG Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Configuration Attributes ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 22: Configuration Payload Format

The payload type for the Configuration payload is forty-seven (47).

Kaufman, et al. Expires May 17, 2014 [Page 110]
Internet-Draft IKEv2bis November 2013

o CFG Type (1 octet) - The type of exchange represented by the
Configuration Attributes. The values in the following table are
only current as of the publication date of RFC 4306. Other values
may have been added since then or will be added after the
publication of this document. Readers should refer to [IKEV2IANA]
for the latest values.

CFG Type Value
--------------------------
CFG_REQUEST 1
CFG_REPLY 2
CFG_SET 3
CFG_ACK 4

o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on
receipt.

o Configuration Attributes (variable length) - These are type length
value (TLV) structures specific to the Configuration payload and
are defined below. There may be zero or more Configuration
Attributes in this payload.

3.15.1. Configuration Attributes

1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 23: Configuration Attribute Format

o Reserved (1 bit) - This bit MUST be set to zero and MUST be
ignored on receipt.

o Attribute Type (15 bits) - A unique identifier for each of the
Configuration Attribute Types.

o Length (2 octets, unsigned integer) - Length in octets of value.

o Value (0 or more octets) - The variable-length value of this
Configuration Attribute. The following lists the attribute types.

The values in the following table are only current as of the

Kaufman, et al. Expires May 17, 2014 [Page 111]
Internet-Draft IKEv2bis November 2013

publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and
INTERNAL_IP6_NBNS which were removed by this document). Other values
may have been added since then or will be added after the publication
of this document. Readers should refer to [IKEV2IANA] for the latest
values.

Attribute Type Value Multi-Valued Length
------------------------------------------------------------
INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets
INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
INTERNAL_IP4_DNS 3 YES 0 or 4 octets
INTERNAL_IP4_NBNS 4 YES 0 or 4 octets
INTERNAL_IP4_DHCP 6 YES 0 or 4 octets
APPLICATION_VERSION 7 NO 0 or more
INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
INTERNAL_IP6_DNS 10 YES 0 or 16 octets
INTERNAL_IP6_DHCP 12 YES 0 or 16 octets
INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets
SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
INTERNAL_IP6_SUBNET 15 YES 17 octets

* These attributes may be multi-valued on return only if
multiple values were requested.

o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
internal network, sometimes called a red node address or private
address, and it MAY be a private address on the Internet. In a
request message, the address specified is a requested address (or
a zero-length address if no specific address is requested). If a
specific address is requested, it likely indicates that a previous
connection existed with this address and the requestor would like
to reuse that address. With IPv6, a requestor MAY supply the low-
order address octets it wants to use. Multiple internal addresses
MAY be requested by requesting multiple internal address
attributes. The responder MAY only send up to the number of
addresses requested. The INTERNAL_IP6_ADDRESS is made up of two
fields: the first is a 16-octet IPv6 address, and the second is a
one-octet prefix-length as defined in [ADDRIPV6]. The requested
address is valid as long as this IKE SA (or its rekeyed
successors) requesting the address is valid. This is described in
more detail in Section 3.15.3.

o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one
netmask is allowed in the request and response messages (e.g.,
255.255.255.0), and it MUST be used only with an
INTERNAL_IP4_ADDRESS attribute. INTERNAL_IP4_NETMASK in a
CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET
containing the same information ("send traffic to these addresses

Kaufman, et al. Expires May 17, 2014 [Page 112]
Internet-Draft IKEv2bis November 2013

through me"), but also implies a link boundary. For instance, the
client could use its own address and the netmask to calculate the
broadcast address of the link. An empty INTERNAL_IP4_NETMASK
attribute can be included in a CFG_REQUEST to request this
information (although the gateway can send the information even
when not requested). Non-empty values for this attribute in a
CFG_REQUEST do not make sense and thus MUST NOT be included.

o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS
server within the network. Multiple DNS servers MAY be requested.
The responder MAY respond with zero or more DNS server attributes.

o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server
(WINS) within the network. Multiple NBNS servers MAY be
requested. The responder MAY respond with zero or more NBNS
server attributes.

o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send
any internal DHCP requests to the address contained within the
attribute. Multiple DHCP servers MAY be requested. The responder
MAY respond with zero or more DHCP server attributes.

o APPLICATION_VERSION - The version or application information of
the IPsec host. This is a string of printable ASCII characters
that is NOT null terminated.

o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge-
device protects. This attribute is made up of two fields: the
first being an IP address and the second being a netmask.
Multiple sub-networks MAY be requested. The responder MAY respond
with zero or more sub-network attributes. This is discussed in
more detail in Section 3.15.2.

o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute
MUST be zero-length and specifies a query to the responder to
reply back with all of the attributes that it supports. The
response contains an attribute that contains a set of attribute
identifiers each in 2 octets. The length divided by 2 (octets)
would state the number of supported attributes contained in the
response.

o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge-
device protects. This attribute is made up of two fields: the
first is a 16-octet IPv6 address, and the second is a one-octet
prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY
be requested. The responder MAY respond with zero or more sub-
network attributes. This is discussed in more detail in
Section 3.15.2.

Kaufman, et al. Expires May 17, 2014 [Page 113]
Internet-Draft IKEv2bis November 2013

Note that no recommendations are made in this document as to how an
implementation actually figures out what information to send in a
response. That is, we do not recommend any specific method of an
IRAS determining which DNS server should be returned to a requesting
IRAC.

The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request
information from its peer. If an attribute in the CFG_REQUEST
Configuration payload is not zero-length, it is taken as a suggestion
for that attribute. The CFG_REPLY Configuration payload MAY return
that value, or a new one. It MAY also add new attributes and not
include some requested ones. Unrecognized or unsupported attributes
MUST be ignored in both requests and responses.

The CFG_SET and CFG_ACK pair allows an IKE endpoint to push
configuration data to its peer. In this case, the CFG_SET
Configuration payload contains attributes the initiator wants its
peer to alter. The responder MUST return a Configuration payload if
it accepted any of the configuration data and it MUST contain the
attributes that the responder accepted with zero-length data. Those
attributes that it did not accept MUST NOT be in the CFG_ACK
Configuration payload. If no attributes were accepted, the responder
MUST return either an empty CFG_ACK payload or a response message
without a CFG_ACK payload. There are currently no defined uses for
the CFG_SET/CFG_ACK exchange, though they may be used in connection
with extensions based on Vendor IDs. An implementation of this
specification MAY ignore CFG_SET payloads.

3.15.2. Meaning of INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET

INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets,
ones that need one or more separate SAs, that can be reached through
the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET
attributes may also express the gateway's policy about what traffic
should be sent through the gateway; the client can choose whether
other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is
sent through the gateway or directly to the destination. Thus,
traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET
attributes should be sent through the gateway that announces the
attributes. If there are no existing Child SAs whose Traffic
Selectors cover the address in question, new SAs need to be created.

For instance, if there are two subnets, 198.51.100.0/26 and
192.0.2.0/24, and the client's request contains the following:

CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)

Kaufman, et al. Expires May 17, 2014 [Page 114]
Internet-Draft IKEv2bis November 2013' private keys have not
been compromised, the endpoints have an external trusted mechanism
(most commonly, a mutually-trusted certification authority) to
validate certificates, and the endpoints know what certificate
identity to expect, endpoints can be certain that such an attack has
not taken place.

Finally, the most serious type of attacker is one who can modify or
redirect session descriptions: for example, a compromised or
malicious SIP proxy server. Neither TLS itself nor any mechanisms
that use it can protect an SDP session against such an attacker.
Instead, the SDP description itself must be secured through some
mechanism; SIP, for example, defines how S/MIME [17] can be used to
secure session descriptions.

3.3. The Need for Self-Signed Certificates

SDP session descriptions are created by any endpoint that needs to
participate in a multimedia session. In many cases, such as SIP
phones, such endpoints have dynamically-configured IP addresses and
host names and must be deployed with nearly zero configuration. For
such an endpoint, it is for practical purposes impossible to obtain a
certificate signed by a well-known certification authority.

Lennox Standards Track [Page 5]
RFC 4572 Comedia over TLS in SDP July 2006

If two endpoints have no prior relationship, self-signed certificates
cannot generally be trusted, as there is no guarantee that an
attacker is not launching a man-in-the-middle attack. Fortunately,
however, if the integrity of SDP session descriptions can be assured,
it is possible to consider those SDP descriptions themselves as a
prior relationship: certificates can be securely described in the
session description itself. This is done by providing a secure hash
of a certificate, or "certificate fingerprint", as an SDP attribute;
this mechanism is described in Section 5.

3.4. Example SDP Description for TLS Connection

Figure 1 illustrates an SDP offer that signals the availability of a
T.38 fax session over TLS. For the purpose of brevity, the main
portion of the session description is omitted in the example, showing
only the 'm' line and its attributes. (This example is the same as
the first one in RFC 4145 [2], except for the proto parameter and the
fingerprint attribute.) See the subsequent sections for explanations
of the example's TLS-specific attributes.

(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.)

m=image 54111 TCP/TLS t38
c=IN IP4 192.0.2.2
a=setup:passive
a=connection:new
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

Figure 1: Example SDP Description Offering a TLS Media Stream

4. Protocol Identifiers

The 'm' line in SDP specifies, among other items, the transport
protocol to be used for the media in the session. See the "Media
Descriptions" section of SDP [1] for a discussion on transport
protocol identifiers.

This specification defines a new protocol identifier, 'TCP/TLS',
which indicates that the media described will use the Transport Layer
Security protocol [3] over TCP. (Using TLS over other transport
protocols is not discussed in this document.) The 'TCP/TLS' protocol
identifier describes only the transport protocol, not the upper-layer
protocol. An 'm' line that specifies 'TCP/TLS' MUST further qualify

Lennox Standards Track [Page 6]
RFC 4572 Comedia over TLS in SDP July 2006

the protocol using a fmt identifier to indicate the application being
run over TLS.

Media sessions described with this identifier follow the procedures
defined in RFC 4145 [2]. They also use the SDP attributes defined in
that specification, 'setup' and 'connection'.

5. Fingerprint Attribute

Parties to a TLS session indicate their identities by presenting
authentication certificates as part of the TLS handshake procedure.
Authentication certificates are X.509 [6] certificates, as profiled
by RFC 3279 [7], RFC 3280 [8], and RFC 4055 [9].

In order to associate media streams with connections and to prevent
unauthorized barge-in attacks on the media streams, endpoints MUST
provide a certificate fingerprint. If the X.509 certificate
presented for the TLS connection matches the fingerprint presented in
the SDP, the endpoint can be confident that the author of the SDP is
indeed the initiator of the connection.

A certificate fingerprint is a secure one-way hash of the DER
(distinguished encoding rules) form of the certificate. (Certificate
fingerprints are widely supported by tools that manipulate X.509
certificates; for instance, the command "openssl x509 -fingerprint"
causes the command-line tool of the openssl package to print a
certificate fingerprint, and the certificate managers for Mozilla and
Internet Explorer display them when viewing the details of a
certificate.)

A fingerprint is represented in SDP as an attribute (an 'a' line).
It consists of the name of the hash function used, followed by the
hash value itself. The hash value is represented as a sequence of
uppercase hexadecimal bytes, separated by colons. The number of
bytes is defined by the hash function. (This is the syntax used by
openssl and by the browsers' certificate managers. It is different
from the syntax used to represent hash values in, e.g., HTTP digest
authentication [18], which uses unseparated lowercase hexadecimal
bytes. It was felt that consistency with other applications of
fingerprints was more important.)

The formal syntax of the fingerprint attribute is given in Augmented
Backus-Naur Form [10] in Figure 2. This syntax extends the BNF
syntax of SDP [1].

Lennox Standards Track [Page 7]
RFC 4572 Comedia over TLS in SDP July 2006

attribute =/ fingerprint-attribute

fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint

hash-func = "sha-1" / "sha-224" / "sha-256" /
"sha-384" / "sha-512" /
"md5" / "md2" / token
; Additional hash functions can only come
; from updates to RFC 3279

fingerprint = 2UHEX *(":" 2UHEX)
; Each byte in upper-case hex, separated
; by colons.

UHEX = DIGIT / %x41-46 ; A-F uppercase

Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute

A certificate fingerprint MUST be computed using the same one-way
hash function as is used in the certificate's signature algorithm.
(This ensures that the security properties required for the
certificate also apply for the fingerprint. It also guarantees that
the fingerprint will be usable by the other endpoint, so long as the
certificate itself is.) Following RFC 3279 [7] as updated by RFC
4055 [9], therefore, the defined hash functions are 'SHA-1' [11]
[19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11],
'MD5' [12], and 'MD2' [13], with 'SHA-1' preferred. A new IANA
registry of Hash Function Textual Names, specified in Section 8,
allows for addition of future tokens, but they may only be added if
they are included in RFCs that update or obsolete RFC 3279 [7].
Self-signed certificates (for which legacy certificates are not a
consideration) MUST use one of the FIPS 180 algorithms (SHA-1,
SHA-224, SHA-256, SHA-384, or SHA-512) as their signature algorithm,
and thus also MUST use it to calculate certificate fingerprints.

The fingerprint attribute may be either a session-level or a media-
level SDP attribute. If it is a session-level attribute, it applies
to all TLS sessions for which no media-level fingerprint attribute is
defined.

Lennox Standards Track [Page 8]
RFC 4572 Comedia over TLS in SDP July 2006

6. Endpoint Identification

6.1. Certificate Choice

An X.509 certificate binds an identity and a public key. If SDP
describing a TLS session is transmitted over a mechanism that
provides integrity protection, a certificate asserting any
syntactically valid identity MAY be used. For example, an SDP
description sent over HTTP/TLS [20] or secured by S/MIME [17] MAY
assert any identity in the certificate securing the media connection.

Security protocols that provide only hop-by-hop integrity protection
(e.g., the sips protocol [16], SIP over TLS) are considered
sufficiently secure to allow the mode in which any valid identity is
accepted. However, see Section 7 for a discussion of some security
implications of this fact.

In situations where the SDP is not integrity-protected, however, the
certificate provided for a TLS connection MUST certify an appropriate
identity for the connection. In these scenarios, the certificate
presented by an endpoint MUST certify either the SDP connection
address, or the identity of the creator of the SDP message, as
follows:

o If the connection address for the media description is specified
as an IP address, the endpoint MAY use a certificate with an
iPAddress subjectAltName that exactly matches the IP in the
connection-address in the session description's 'c' line.
Similarly, if the connection address for the media description is
specified as a fully-qualified domain name, the endpoint MAY use a
certificate with a dNSName subjectAltName matching the specified
'c' line connection-address exactly. (Wildcard patterns MUST NOT
be used.)

o Alternately, if the SDP session description of the session was
transmitted over a protocol (such as SIP [16]) for which the
identities of session participants are defined by uniform resource
identifiers (URIs), the endpoint MAY use a certificate with a
uniformResourceIdentifier subjectAltName corresponding to the
identity of the endpoint that generated the SDP. The details of
what URIs are valid are dependent on the transmitting protocol.
(For more details on the validity of URIs, see Section 7.)

Identity matching is performed using the matching rules specified by
RFC 3280 [8]. If more than one identity of a given type is present
in the certificate (e.g., more than one dNSName name), a match in any
one of the set is considered acceptable. To support the use of
certificate caches, as described in Section 7, endpoints SHOULD

Lennox Standards Track [Page 9]
RFC 4572 Comedia over TLS in SDP July 2006

consistently provide the same certificate for each identity they
support.

6.2. Certificate Presentation

In all cases, an endpoint acting as the TLS server (i.e., one taking
the 'setup:passive' role, in the terminology of connection-oriented
media) MUST present a certificate during TLS initiation, following
the rules presented in Section 6.1. If the certificate does not
match the original fingerprint, the client endpoint MUST terminate
the media connection with a bad_certificate error.

If the SDP offer/answer model [5] is being used, the client (the
endpoint with the 'setup:active&

TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

then a valid response could be the following (in which TSr and
INTERNAL_IP4_SUBNET contain the same information):

CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63),
(0, 0-65535, 192.0.2.0-192.0.2.255))

In these cases, the INTERNAL_IP4_SUBNET does not really carry any
useful information.

A different possible response would have been this:

That response would mean that the client can send all its traffic
through the gateway, but the gateway does not mind if the client
sends traffic not included by INTERNAL_IP4_SUBNET directly to the
destination (without going through the gateway).

A different situation arises if the gateway has a policy that
requires the traffic for the two subnets to be carried in separate
SAs. Then a response like this would indicate to the client that if
it wants access to the second subnet, it needs to create a separate
SA:

INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
only part of the address space. For instance, if the client requests
the following:

Kaufman, et al. Expires May 17, 2014 [Page 115]
Internet-Draft IKEv2bis November 2013

CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

then the gateway's response might be:

Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET in
CFG_REQUESTs is unclear, they cannot be used reliably in
CFG_REQUESTs.

3.15.3. Configuration Payloads for IPv6

The Configuration payloads for IPv6 are based on the corresponding
IPv4 payloads, and do not fully follow the "normal IPv6 way of doing
things". In particular, IPv6 stateless autoconfiguration or router
advertisement messages are not used, neither is neighbor discovery.
Note that there is an additional document that discusses IPv6
configuration in IKEv2, [IPV6CONFIG]. At the present time, it is an
experimental document, but there is a hope that with more
implementation experience, it will gain the same standards treatment
as this document.

A client can be assigned an IPv6 address using the
INTERNAL_IP6_ADDRESS Configuration payload. A minimal exchange might
look like this:

CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the
CFG_REQUEST to request a specific address or interface identifier.

Kaufman, et al. Expires May 17, 2014 [Page 116]
Internet-Draft IKEv2bis November 2013

The gateway first checks if the specified address is acceptable, and
if it is, returns that one. If the address was not acceptable, the
gateway attempts to use the interface identifier with some other
prefix; if even that fails, the gateway selects another interface
identifier.

The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
field. When used in a CFG_REPLY, this corresponds to the
INTERNAL_IP4_NETMASK attribute in the IPv4 case.

Although this approach to configuring IPv6 addresses is reasonably
simple, it has some limitations. IPsec tunnels configured using
IKEv2 are not fully featured "interfaces" in the IPv6 addressing
architecture sense [ADDRIPV6]. In particular, they do not
necessarily have link-local addresses, and this may complicate the
use of protocols that assume them, such as [MLDV2].

3.15.4. Address Assignment Failures

If the responder encounters an error while attempting to assign an IP
address to the initiator during the processing of a Configuration
payload, it responds with an INTERNAL_ADDRESS_FAILURE notification.
The IKE SA is still created even if the initial Child SA cannot be
created because of this failure. If this error is generated within
an IKE_AUTH exchange, no Child SA will be created. However, there
are some more complex error cases.

If the responder does not support Configuration payloads at all, it
can simply ignore all Configuration payloads. This type of
implementation never sends INTERNAL_ADDRESS_FAILURE notifications.
If the initiator requires the assignment of an IP address, it will
treat a response without CFG_REPLY as an error.

The initiator may request a particular type of address (IPv4 or IPv6)
that the responder does not support, even though the responder
supports Configuration payloads. In this case, the responder simply
ignores the type of address it does not support and processes the
rest of the request as usual.

If the initiator requests multiple addresses of a type that the
responder supports, and some (but not all) of the requests fail, the
responder replies with the successful addresses only. The responder
sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.

If the initiator does not receive the IP address(es) required by its
policy, it MAY keep the IKE SA up and retry the Configuration payload
as separate INFORMATIONAL exchange after suitable timeout, or it MAY
tear down the IKE SA by sending a Delete payload inside a separate

Kaufman, et al. Expires May 17, 2014 [Page 117]
Internet-Draft IKEv2bis November 2013

INFORMATIONAL exchange and later retry IKE SA from the beginning
after some timeout. Such a timeout should not be too short
(especially if the IKE SA is started from the beginning) because
these error situations may not be able to be fixed quickly; the
timeout should likely be several minutes. For example, an address
shortage problem on the responder will probably only be fixed when
more entries are returned to the address pool when other clients
disconnect or when responder is reconfigured with larger address
pool.

3.16. Extensible Authentication Protocol (EAP) Payload

The Extensible Authentication Protocol payload, denoted EAP in this
document, allows IKE SAs to be authenticated using the protocol
defined in RFC 3748 [EAP] and subsequent extensions to that protocol.
When using EAP, an appropriate EAP method needs to be selected. Many
of these methods have been defined, specifying the protocol's use
with various authentication mechanisms. EAP method types are listed
in [EAP-IANA]. A short summary of the EAP format is included here
for clarity.

Figure 24: EAP Payload Format

The payload type for an EAP payload is forty-eight (48).

Figure 25: EAP Message Format

o Code (1 octet) indicates whether this message is a Request (1),
Response (2), Success (3), or Failure (4).

Kaufman, et al. Expires May 17, 2014 [Page 118]
Internet-Draft IKEv2bis November 2013

o Identifier (1 octet) is used in PPP to distinguish replayed
messages from repeated ones. Since in IKE, EAP runs over a
reliable protocol, it serves no function here. In a response
message, this octet MUST be set to match the identifier in the
corresponding request.

o Length (2 octets, unsigned integer) is the length of the EAP
message and MUST be four less than the Payload Length of the
encapsulating payload.

o Type (1 octet) is present only if the Code field is Request (1) or
Response (2). For other codes, the EAP message length MUST be
four octets and the Type and Type_Data fields MUST NOT be present.
In a Request (1) message, Type indicates the data being requested.
In a Response (2) message, Type MUST either be Nak or match the
type of the data requested. Note that since IKE passes an
indication of initiator identity in the first message in the
IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity
requests (type 1). The initiator MAY, however, respond to such
requests if it receives them.

o Type_Data (Variable Length) varies with the Type of Request and
the associated Response. For the documentation of the EAP
methods, see [EAP].

Note that since IKE passes an indication of initiator identity in the
first message in the IKE_AUTH exchange, the responder should not send
EAP Identity requests. The initiator may, however, respond to such
requests if it receives them.

4. Conformance Requirements

In order to assure that all implementations of IKEv2 can
interoperate, there are "MUST support" requirements in addition to
those listed elsewhere. Of course, IKEv2 is a security protocol, and
one of its major functions is to allow only authorized parties to
successfully complete establishment of SAs. So a particular
implementation may be configured with any of a number of restrictions
concerning algorithms and trusted authorities that will prevent
universal interoperability.

IKEv2 is designed to permit minimal implementations that can
interoperate with all compliant implementations. The following are
features that can be omitted in a minimal implementation:

o Ability to negotiate SAs through a NAT and tunnel the resulting
ESP SA over UDP.

Kaufman, et al. Expires May 17, 2014 [Page 119]
Internet-Draft IKEv2bis November 2013

#x27; role) MUST also present a
certificate following the rules of Section 6.1. The server MUST
request a certificate, and if the client does not provide one, or if
the certificate does not match the provided fingerprint, the server
endpoint MUST terminate the media connection with a bad_certificate
error.

Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.

If offer/answer is not being used (e.g., if the SDP was sent over the
Session Announcement Protocol [15]), there is no secure channel
available for clients to communicate certificate fingerprints to
servers. In this case, servers MAY request client certificates,
which SHOULD be signed by a well-known certification authority, or
MAY allow clients to connect without a certificate.

7. Security Considerations

This entire document concerns itself with security. The problem to
be solved is addressed in Section 1, and a high-level overview is
presented in Section 3. See the SDP specification [1] for security
considerations applicable to SDP in general.

Offering a TCP/TLS connection in SDP (or agreeing to one in SDP
offer/answer mode) does not create an obligation for an endpoint to
accept any TLS connection with the given fingerprint. Instead, the

Lennox Standards Track [Page 10]
RFC 4572 Comedia over TLS in SDP July 2006

endpoint must engage in the standard TLS negotiation procedure to
ensure that the TLS stream cipher and MAC algorithm chosen meet the
security needs of the higher-level application. (For example, an
offered stream cipher of TLS_NULL_WITH_NULL_NULL SHOULD be rejected
in almost every application scenario.)

Like all SDP messages, SDP messages describing TLS streams are
conveyed in an encapsulating application protocol (e.g., SIP, Media
Gateway Control Protocol (MGCP), etc.). It is the responsibility of
the encapsulating protocol to ensure the integrity of the SDP
security descriptions. Therefore, the application protocol SHOULD
either invoke its own security mechanisms (e.g., secure multiparts)
or, alternatively, utilize a lower-layer security service (e.g., TLS
or IPsec). This security service SHOULD provide strong message
authentication as well as effective replay protection.

However, such integrity protection is not always possible. For these
cases, end systems SHOULD maintain a cache of certificates that other
parties have previously presented using this mechanism. If possible,
users SHOULD be notified when an unsecured certificate associated
with a previously unknown end system is presented and SHOULD be
strongly warned if a different unsecured certificate is presented by
a party with which they have communicated in the past. In this way,
even in the absence of integrity protection for SDP, the security of
this document's mechanism is equivalent to that of the Secure Shell
(ssh) protocol [21], which is vulnerable to man-in-the-middle attacks
when two parties first communicate, but can detect ones that occur
subsequently. (Note that a precise definition of the "other party"
depends on the application protocol carrying the SDP message.) Users
SHOULD NOT, however, in any circumstances be notified about
certificates described in SDP descriptions sent over an integrity-
protected channel.

To aid interoperability and deployment, security protocols that
provide only hop-by-hop integrity protection (e.g., the sips protocol
[16], SIP over TLS) are considered sufficiently secure to allow the
mode in which any syntactically valid identity is accepted in a
certificate. This decision was made because sips is currently the
integrity mechanism most likely to be used in deployed networks in
the short to medium term. However, in this mode, SDP integrity is
vulnerable to attacks by compromised or malicious middleboxes, e.g.,
SIP proxy servers. End systems MAY warn users about SDP sessions
that are secured in only a hop-by-hop manner, and definitions of
media formats running over TCP/TLS MAY specify that only end-to-end
integrity mechanisms be used.

Lennox Standards Track [Page 11]
RFC 4572 Comedia over TLS in SDP July 2006

Depending on how SDP messages are transmitted, it is not always
possible to determine whether or not a subjectAltName presented in a
remote certificate is expected for the remote party. In particular,
given call forwarding, third-party call control, or session
descriptions generated by endpoints controlled by the Gateway Control
Protocol [22], it is not always possible in SIP to determine what
entity ought to have generated a remote SDP response. In general,
when not using authenticity and integrity protection of SDP
descriptions, a certificate transmitted over SIP SHOULD assert the
endpoint's SIP Address of Record as a uniformResourceIndicator
subjectAltName. When an endpoint receives a certificate over SIP
asserting an identity (including an iPAddress or dNSName identity)
other than the one to which it placed or received the call, it SHOULD
alert the user and ask for confirmation. This applies whether
certificates are self-signed, or signed by certification authorities;
a certificate for sip:bob@example.com may be legitimately signed by a
certification authority, but may still not be acceptable for a call
to sip:alice@example.com. (This issue is not one specific to this
specification; the same consideration applies for S/MIME-signed SDP
carried over SIP.)

This document does not define any mechanism for securely transporting
RTP and RTP Control Protocol (RTCP) packets over a
connection-oriented channel. There was no consensus in the working
group as to whether it would be better to send Secure RTP packets
[23] over a connection-oriented transport [24], or whether it would
be better to send standard unsecured RTP packets over TLS using the
mechanisms described in this document. The group consensus was to
wait until a use-case requiring secure connection-oriented RTP was
presented.

TLS is not always the most appropriate choice for secure connection-
oriented media; in some cases, a higher- or lower-level security
protocol may be appropriate.

8. IANA Considerations

This document defines an SDP proto value: 'TCP/TLS'. Its format is
defined in Section 4. This proto value has been registered by IANA
under "Session Description Protocol (SDP) Parameters" under "proto".

This document defines an SDP session and media-level attribute:
'fingerprint'. Its format is defined in Section 5. This attribute
has been registered by IANA under "Session Description Protocol (SDP)
Parameters" under "att-field (both session and media level)".

The SDP specification [1] states that specifications defining new
proto values, like the 'TCP/TLS' proto value defined in this one,

Lennox Standards Track [Page 12]
RFC 4572 Comedia over TLS in SDP July 2006

must define the rules by which their media format (fmt) namespace is
managed. For the TCP/TLS protocol, new formats SHOULD have an
associated MIME registration. Use of an existing MIME subtype for
the format is encouraged. If no MIME subtype exists, it is
RECOMMENDED that a suitable one be registered through the IETF
process [14] by production of, or reference to, a standards-track RFC
that defines the transport protocol for the format.

This specification creates a new IANA registry named "Hash Function
Textual Names". It will not be part of the SDP Parameters.

The names of hash functions used for certificate fingerprints are
registered by the IANA. Hash functions MUST be defined by standards-
track RFCs that update or obsolete RFC 3279 [7].

When registering a new hash function textual name, the following
information MUST be provided:

o The textual name of the hash function.

o The Object Identifier (OID) of the hash function as used in X.509
certificates.

o A reference to the standards-track RFC, updating or obsoleting RFC
3279 [7], defining the use of the hash function in X.509
certificates.

Figure 3 contains the initial values of this registry.

Hash Function Name OID Reference
------------------ --- ---------
"md2" 1.2.840.113549.2.2 RFC 3279
"md5" 1.2.840.113549.2.5 RFC 3279
"sha-1" 1.3.14.3.2.26 RFC 3279
"sha-224" 2.16.840.1.101.3.4.2.4 RFC 4055
"sha-256" 2.16.840.1.101.3.4.2.1 RFC 4055
"sha-384" 2.16.840.1.101.3.4.2.2 RFC 4055
"sha-512" 2.16.840.1.101.3.4.2.3 RFC 4055

Figure 3: IANA Hash Function Textual Name Registry

Lennox Standards Track [Page 13]
RFC 4572 Comedia over TLS in SDP July 2006

9. References

9.1. Normative References

[1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.

[2] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the
Session Description Protocol (SDP)", RFC 4145, September 2005.

[3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.

[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.

[6] International Telecommunications Union, "Information technology
- Open Systems Interconnection - The Directory: Public-key and
attribute certificate frameworks", ITU-T Recommendation X.509,
ISO Standard 9594-8, March 2000.

[7] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile",
RFC 3279, April 2002.

[8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.

[9] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
and Identifiers for RSA Cryptography for use in the Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 4055, June 2005.

[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.

[11] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-2, August 2002, <http://csrc.nist.gov/
publications/fips/fips180-2/fips180-2.pdf>.

[12] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.

Lennox Standards Track [Page 14]
RFC 4572 Comedia over TLS in SDP July 2006

[13] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
April 1992.

[14] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.

9.2. Informative References

[15] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.

[16] 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.

[17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.

[18] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.

[19] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001.

[20] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[21] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol
Architecture", RFC 4251, January 2006.

[22] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
Control Protocol Version 1", RFC 3525, June 2003.

[23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.

[24] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and
RTP Control Protocol (RTCP) Packets over Connection-Oriented
Transport", RFC 4571, July 2006.

Lennox Standards Track [Page 15]
RFC 4572 Comedia over TLS in SDP July 2006

Author's Address

Jonathan Lennox
Columbia University Department of Computer Science
450 Computer Science
1214 Amsterdam Ave., M.C. 0401
New York, NY 10027
US

EMail: lennox@cs.columbia.edu

Lennox Standards Track [Page 16]
RFC 4572 Comedia over TLS in SDP July 2006

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

o Ability to request (and respond to a request for) a temporary IP
address on the remote end of a tunnel.

o Ability to support EAP-based authentication.

o Ability to support window sizes greater than one.

o Ability to establish multiple ESP or AH SAs within a single IKE
SA.

o Ability to rekey SAs.

To assure interoperability, all implementations MUST be capable of
parsing all payload types (if only to skip over them) and to ignore
payload types that it does not support unless the critical bit is set
in the payload header. If the critical bit is set in an unsupported
payload header, all implementations MUST reject the messages
containing those payloads.

Every implementation MUST be capable of doing four-message
IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE,
one for ESP or AH). Implementations MAY be initiate-only or respond-
only if appropriate for their platform. Every implementation MUST be
capable of responding to an INFORMATIONAL exchange, but a minimal
implementation MAY respond to any request in the INFORMATIONAL
exchange with an empty response (note that within the context of an
IKE SA, an "empty" message consists of an IKE header followed by an
Encrypted payload with no payloads contained in it). A minimal
implementation MAY support the CREATE_CHILD_SA exchange only in so
far as to recognize requests and reject them with a Notify payload of
type NO_ADDITIONAL_SAS. A minimal implementation need not be able to
initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA
expires (based on locally configured values of either lifetime or
octets passed), and implementation MAY either try to renew it with a
CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
create a new one. If the responder rejects the CREATE_CHILD_SA
request with a NO_ADDITIONAL_SAS notification, the implementation
MUST be capable of instead deleting the old SA and creating a new
one.

Implementations are not required to support requesting temporary IP
addresses or responding to such requests. If an implementation does
support issuing such requests and its policy requires using temporary
IP addresses, it MUST include a CP payload in the first message in
the IKE_AUTH exchange containing at least a field of type
INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All other fields are
optional. If an implementation supports responding to such requests,
it MUST parse the CP payload of type CFG_REQUEST in the first message

Kaufman, et al. Expires May 17, 2014 [Page 120]
Internet-Draft IKEv2bis November 2013

in the IKE_AUTH exchange and recognize a field of type
INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing
an address of the appropriate type, it MUST return a CP payload of
type CFG_REPLY containing an address of the requested type. The
responder may include any other related attributes.

For an implementation to be called conforming to this specification,
it MUST be possible to configure it to accept the following:

o Public Key Infrastructure using X.509 (PKIX) Certificates
containing and signed by RSA keys of size 1024 or 2048 bits, where
the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or
ID_DER_ASN1_DN.

o Shared key authentication where the ID passed is any of ID_KEY_ID,
ID_FQDN, or ID_RFC822_ADDR.

o Authentication where the responder is authenticated using PKIX
Certificates and the initiator is authenticated using shared key
authentication.

5. Security Considerations

While this protocol is designed to minimize disclosure of
configuration information to unauthenticated peers, some such
disclosure is unavoidable. One peer or the other must identify
itself first and prove its identity first. To avoid probing, the
initiator of an exchange is required to identify itself first, and
usually is required to authenticate itself first. The initiator can,
however, learn that the responder supports IKE and what cryptographic
protocols it supports. The responder (or someone impersonating the
responder) can probe the initiator not only for its identity, but
using CERTREQ payloads may be able to determine what certificates the
initiator is willing to use.

Use of EAP authentication changes the probing possibilities somewhat.
When EAP authentication is used, the responder proves its identity
before the initiator does, so an initiator that knew the name of a
valid initiator could probe the responder for both its name and
certificates.

Repeated rekeying using CREATE_CHILD_SA without additional Diffie-
Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a
single key. Implementers should take note of this fact and set a
limit on CREATE_CHILD_SA exchanges between exponentiations. This
document does not prescribe such a limit.

The strength of a key derived from a Diffie-Hellman exchange using

Kaufman, et al. Expires May 17, 2014 [Page 121]
Internet-Draft IKEv2bis November 2013

any of the groups defined here depends on the inherent strength of
the group, the size of the exponent used, and the entropy provided by
the random number generator used. Due to these inputs, it is
difficult to determine the strength of a key for any of the defined
groups. Diffie-Hellman group number two, when used with a strong
random number generator and an exponent no less than 200 bits, is
common for use with 3DES. Group five provides greater security than
group two. Group one is for historic purposes only and does not
provide sufficient strength except for use with DES, which is also
for historic use only. Implementations should make note of these
estimates when establishing policy and negotiating security
parameters.

Note that these limitations are on the Diffie-Hellman groups
themselves. There is nothing in IKE that prohibits using stronger
groups nor is there anything that will dilute the strength obtained
from stronger groups (limited by the strength of the other algorithms
negotiated including the PRF). In fact, the extensible framework of
IKE encourages the definition of more groups; use of elliptic curve
groups may greatly increase strength using much smaller numbers.

It is assumed that all Diffie-Hellman exponents are erased from
memory after use.

The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator
has been authenticated. As a result, an implementation of this
protocol needs to be completely robust when deployed on any insecure
network. Implementation vulnerabilities, particularly DoS attacks,
can be exploited by unauthenticated peers. This issue is
particularly worrisome because of the unlimited number of messages in
EAP-based authentication.

The strength of all keys is limited by the size of the output of the
negotiated PRF. For this reason, a PRF whose output is less than 128
bits (e.g., 3DES-CBC) MUST NOT be used with this protocol.

The security of this protocol is critically dependent on the
randomness of the randomly chosen parameters. These should be
generated by a strong random or properly seeded pseudorandom source
(see [RANDOMNESS]). Implementers should take care to ensure that use
of random numbers for both keys and nonces is engineered in a fashion
that does not undermine the security of the keys.

For information on the rationale of many of the cryptographic design
choices in this protocol, see [SIGMA] and [SKEME]. Though the
security of negotiated Child SAs does not depend on the strength of
the encryption and integrity protection negotiated in the IKE SA,
implementations MUST NOT negotiate NONE as the IKE integrity

Kaufman, et al. Expires May 17, 2014 [Page 122]
Internet-Draft IKEv2bis November 2013

protection algorithm or ENCR_NULL as the IKE encryption algorithm.

When using pre-shared keys, a critical consideration is how to assure
the randomness of these secrets. The strongest practice is to ensure
that any pre-shared key contain as much randomness as the strongest
key being negotiated. Deriving a shared secret from a password,
name, or other low-entropy source is not secure. These sources are
subject to dictionary and social-engineering attacks, among others.

The NAT_DETECTION_*_IP notifications contain a hash of the addresses
and ports in an attempt to hide internal IP addresses behind a NAT.
Since the IPv4 address space is only 32 bits, and it is usually very
sparse, it would be possible for an attacker to find out the internal
address used behind the NAT box by trying all possible IP addresses
and trying to find the matching hash. The port numbers are normally
fixed to 500, and the SPIs can be extracted from the packet. This
reduces the number of hash calculations to 2^32. With an educated
guess of the use of private address space, the number of hash
calculations is much smaller. Designers should therefore not assume
that use of IKE will not leak internal address information.

When using an EAP authentication method that does not generate a
shared key for protecting a subsequent AUTH payload, certain man-in-
the-middle and server-impersonation attacks are possible [EAPMITM].
These vulnerabilities occur when EAP is also used in protocols that
are not protected with a secure tunnel. Since EAP is a general-
purpose authentication protocol, which is often used to provide
single-signon facilities, a deployed IPsec solution that relies on an
EAP authentication method that does not generate a shared key (also
known as a non-key-generating EAP method) can become compromised due
to the deployment of an entirely unrelated application that also
happens to use the same non-key-generating EAP method, but in an
unprotected fashion. Note that this vulnerability is not limited to
just EAP, but can occur in other scenarios where an authentication
infrastructure is reused. For example, if the EAP mechanism used by
IKEv2 utilizes a token authenticator, a man-in-the-middle attacker
could impersonate the web server, intercept the token authentication
exchange, and use it to initiate an IKEv2 connection. For this
reason, use of non-key-generating EAP methods SHOULD be avoided where
possible. Where they are used, it is extremely important that all
usages of these EAP methods SHOULD utilize a protected tunnel, where
the initiator validates the responder's certificate before initiating
the EAP authentication. Implementers should describe the
vulnerabilities of using non-key-generating EAP methods in the
documentation of their implementations so that the administrators
deploying IPsec solutions are aware of these dangers.

An implementation using EAP MUST also use a public-key-based

Kaufman, et al. Expires May 17, 2014 [Page 123]
Internet-Draft IKEv2bis November 2013

authentication of the server to the client before the EAP
authentication begins, even if the EAP method offers mutual
authentication. This avoids having additional IKEv2 protocol
variations and protects the EAP data from active attackers.

If the messages of IKEv2 are long enough that IP-level fragmentation
is necessary, it is possible that attackers could prevent the
exchange from completing by exhausting the reassembly buffers. The
chances of this can be minimized by using the Hash and URL encodings
instead of sending certificates (see Section 3.6). Additional
mitigations are discussed in [DOSUDPPROT].

Admission control is critical to the security of the protocol. For
example, trust anchors used for identifying IKE peers should probably
be different than those used for other forms of trust, such as those
used to identify public web servers. Moreover, although IKE provides
a great deal of leeway in defining the security policy for a trusted
peer's identity, credentials, and the correlation between them,
having such security policy defined explicitly is essential to a
secure implementation.

5.1. Traffic Selector Authorization

IKEv2 relies on information in the Peer Authorization Database (PAD)
when determining what kind of Child SAs a peer is allowed to create.
This process is described in Section 4.4.3 of [IPSECARCH]. When a
peer requests the creation of an Child SA with some Traffic
Selectors, the PAD must contain "Child SA Authorization Data" linking
the identity authenticated by IKEv2 and the addresses permitted for
Traffic Selectors.

For example, the PAD might be configured so that authenticated
identity "sgw23.example.com" is allowed to create Child SAs for
192.0.2.0/24, meaning this security gateway is a valid
"representative" for these addresses. Host-to-host IPsec requires
similar entries, linking, for example, "fooserver4.example.com" with
198.51.100.66/32, meaning this identity is a valid "owner" or
"representative" of the address in question.

As noted in [IPSECARCH], "It is necessary to impose these constraints
on creation of child SAs to prevent an authenticated peer from
spoofing IDs associated with other, legitimate peers". In the
example given above, a correct configuration of the PAD prevents
sgw23 from creating Child SAs with address 198.51.100.66, and
prevents fooserver4 from creating Child SAs with addresses from
192.0.2.0/24.

It is important to note that simply sending IKEv2 packets using some

Kaufman, et al. Expires May 17, 2014 [Page 124]
Internet-Draft IKEv2bis November 2013

particular address does not imply a permission to create Child SAs
with that address in the Traffic Selectors. For example, even if
sgw23 would be able to spoof its IP address as 198.51.100.66, it
could not create Child SAs matching fooserver4's traffic.

The IKEv2 specification does not specify how exactly IP address
assignment using Configuration payloads interacts with the PAD. Our
interpretation is that when a security gateway assigns an address
using Configuration payloads, it also creates a temporary PAD entry
linking the authenticated peer identity and the newly allocated inner
address.

It has been recognized that configuring the PAD correctly may be
difficult in some environments. For instance, if IPsec is used
between a pair of hosts whose addresses are allocated dynamically
using DHCP, it is extremely difficult to ensure that the PAD
specifies the correct "owner" for each IP address. This would
require a mechanism to securely convey address assignments from the
DHCP server, and link them to identities authenticated using IKEv2.

Due to this limitation, some vendors have been known to configure
their PADs to allow an authenticated peer to create Child SAs with
Traffic Selectors containing the same address that was used for the
IKEv2 packets. In environments where IP spoofing is possible (i.e.,
almost everywhere) this essentially allows any peer to create Child
SAs with any Traffic Selectors. This is not an appropriate or secure
configuration in most circumstances. See [H2HIPSEC] for an extensive
discussion about this issue, and the limitations of host-to-host
IPsec in general.

6. IANA Considerations

[IKEV2] defined many field types and values. IANA has already
registered those types and values in [IKEV2IANA], so they are not
listed here again.

One item has been removed from the IKEv2 Certificate Encodings table:
"Raw RSA Key".

IANA has updated all references to RFC 5996 to point to this
document.

7. Acknowledgements

Many individuals in the IPsecME Working Group were very helpful in
contributing ideas and text for this document, as well as in
reviewing the clarifications suggested by others.

Kaufman, et al. Expires May 17, 2014 [Page 125]
Internet-Draft IKEv2bis November 2013

The acknowledgements from the IKEv2 document were:

This document is a collaborative effort of the entire IPsec WG. If
there were no limit to the number of authors that could appear on an
RFC, the following, in alphabetical order, would have been listed:
Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt
Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John
Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero
Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer
Reingold, and Michael Richardson. Many other people contributed to
the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI,
each of which has its own list of authors. Hugh Daniel suggested the
feature of having the initiator, in message 3, specify a name for the
responder, and gave the feature the cute name "You Tarzan, Me Jane".
David Faucher and Valery Smyslov helped refine the design of the
Traffic Selector negotiation.

Kaufman, et al. Expires May 17, 2014 [Page 126]
Internet-Draft IKEv2bis November 2013

8. References

8.1. Normative References

[ADDGROUP]
Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.

[ADDRIPV6]
Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.

[AEAD] Black, D. and D. McGrew, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282,
August 2008.

[AESCMACPRF128]
Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
Advanced Encryption Standard-Cipher-based Message
Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
PRF-128) Algorithm for the Internet Key Exchange Protocol
(IKE)", RFC 4615, August 2006.

[AESXCBCPRF128]
Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 4434,
February 2006.

[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.

[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.

[ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.

[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[IKEV2IANA]
"Internet Key Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org>.

Kaufman, et al. Expires May 17, 2014 [Page 127]
Internet-Draft IKEv2bis November 2013

[IPSECARCH]
Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.

[MUSTSHOULD]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.

[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.

[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.

[UDPENCAPS]
Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.

[URLS] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.

8.2. Informative References

[AH] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.

[ARCHGUIDEPHIL]
Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, December 2002.

[ARCHPRINC]
Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.

[Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.

[DES] American National Standards Institute, "American National
Standard for Information Systems-Data Link Encryption",

Kaufman, et al. Expires May 17, 2014 [Page 128]
Internet-Draft IKEv2bis November 2013

ANSI X3.106, 1983.

[DH] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory,
V.IT-22 n. 6, June 1977.

[DIFFSERVARCH]
Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.

[DIFFSERVFIELD]
Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.

[DIFFTUNNEL]
Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.

[DOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.

[DOSUDPPROT]
C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection
for UDP-based protocols", ACM Conference on Computer and
Communications Security, October 2003.

[DSS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard",
Draft FIPS 186-3, June 2008.

[EAI] Abel, Y., "Internationalized Email Headers", RFC 5335,
September 2008.

[EAP-IANA]
"Extensible Authentication Protocol (EAP) Registry: Method
Types", <http://www.iana.org>.

[EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in
Tunneled Authentication Protocols", November 2002,
<http://eprint.iacr.org/2002/163>.

[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.

[EXCHANGEANALYSIS]

Kaufman, et al. Expires May 17, 2014 [Page 129]
Internet-Draft IKEv2bis November 2013

R. Perlman and C. Kaufman, "Analysis of the IPsec key
exchange Standard", WET-ICE Security Conference, MIT,
2001,
<http://sec.femto.org/wetice-2001/papers/radia-paper.pdf>.

[H2HIPSEC]
Aura, T., Roe, M., and A. Mohammed, "Experiences with
Host-to-Host IPsec", 13th International Workshop on
Security Protocols, Cambridge, UK, April 2005.

[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.

[IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH
Series in Information Processing, v. 1, Konstanz: Hartung-
Gorre Verlag, 1992.

[IDNA] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.

[IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.

[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.

[IP] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.

[IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173,
September 2001.

[IPSECARCH-OLD]
Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.

[IPV6CONFIG]
Eronen, P., Laganier, J., and C. Madson, "IPv6
Configuration in Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 5739, February 2010.

[ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.

Kaufman, et al. Expires May 17, 2014 [Page 130]
Internet-Draft IKEv2bis November 2013

[MAILFORMAT]
Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.

[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.

[MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.

[MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

[MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.

[MODES] National Institute of Standards and Technology, U.S.
Department of Commerce, "Recommendation for Block Cipher
Modes of Operation", SP 800-38A, 2001.

[NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.

[NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004.

[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.

[PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998.

[PHOTURIS]
Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.

[RANDOMNESS]
Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.

[REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol", RFC 4478, April 2006.

[REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In
Diffie-Hellman Key Agreement Protocols", December 2008, <
http://www.cacr.math.uwaterloo.ca/techreports/2008/
cacr2008-24.pdf>.

Kaufman, et al. Expires May 17, 2014 [Page 131]
Internet-Draft IKEv2bis November 2013

[RFC4945] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.

[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.

[RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman
Tests for the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 6989, July 2013.

[ROHCV2] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C.
Bormann, "IKEv2 Extensions to Support Robust Header
Compression over IPsec", RFC 5857, May 2010.

[RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems", February 1978.

[SHA] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard",
FIPS 180-3, October 2008.

[SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and its Use in the IKE
Protocols", Advances in Cryptography - CRYPTO 2003
Proceedings LNCS 2729, 2003, <http://
www.informatik.uni-trier.de/~ley/db/conf/crypto/
crypto2003.html>.

[SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", IEEE Proceedings of the 1996
Symposium on Network and Distributed Systems Security ,
1996.

[TRANSPARENCY]
Carpenter, B., "Internet Transparency", RFC 2775,
February 2000.

Appendix A. Summary of Changes from IKEv1

The goals of this revision to IKE are:

1. To define the entire IKE protocol in a single document,
replacing RFCs 2407, 2408, and 2409 and incorporating subsequent
changes to support NAT Traversal, Extensible Authentication, and
Remote Address acquisition;

Kaufman, et al. Expires May 17, 2014 [Page 132]
Internet-Draft IKEv2bis November 2013

2. To simplify IKE by replacing the eight different initial
exchanges with a single four-message exchange (with changes in
authentication mechanisms affecting only a single AUTH payload
rather than restructuring the entire exchange) see
[EXCHANGEANALYSIS];

3. To remove the Domain of Interpretation (DOI), Situation (SIT),
and Labeled Domain Identifier fields, and the Commit and
Authentication only bits;

4. To decrease IKE's latency in the common case by making the
initial exchange be 2 round trips (4 messages), and allowing the
ability to piggyback setup of a Child SA on that exchange;

5. To replace the cryptographic syntax for protecting the IKE
messages themselves with one based closely on ESP to simplify
implementation and security analysis;

6. To reduce the number of possible error states by making the
protocol reliable (all messages are acknowledged) and sequenced.
This allows shortening CREATE_CHILD_SA exchanges from 3 messages
to 2;

7. To increase robustness by allowing the responder to not do
significant processing until it receives a message proving that
the initiator can receive messages at its claimed IP address;

8. To fix cryptographic weaknesses such as the problem with
symmetries in hashes used for authentication (documented by Tero
Kivinen);

9. To specify Traffic Selectors in their own payloads type rather
than overloading ID payloads, and making more flexible the
Traffic Selectors that may be specified;

10. To specify required behavior under certain error conditions or
when data that is not understood is received in order to make it
easier to make future revisions in a way that does not break
backward compatibility;

11. To simplify and clarify how shared state is maintained in the
presence of network failures and DoS attacks; and

12. To maintain existing syntax and magic numbers to the extent
possible to make it likely that implementations of IKEv1 can be
enhanced to support IKEv2 with minimum effort.

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

Lennox Standards Track [Page 17]

Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) RFC 4572

Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
RFC 4572