| rtcweb | M. Thomson |
| Internet-Draft | Skype |
| Intended status: Standards Track | March 2012 |
| Expires: August 31, 2012 |
Using Datagram Transport Layer Security (DTLS) For Interactivity Connectivity Establishment (ICE) Connectivity Checking: ICE-DTLS
Interactivity Connectivity Establishment (ICE) connectivity checking using the Datagram Transport Layer Security (DTLS) handshake is described. The DTLS handshake provides sufficient information to identify valid candidates and establish consent.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 31, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
User experience with real time applications depends greatly on low latency. At session setup time, optimizing the total number of network round trips between a user action and the receipt of media is key to improving user experience.
Interactivity Connectivity Establishment (ICE) [RFC5245] performs a crucial function in establishing a functional transport flow between peers in the presence of network address translation (NAT) middleboxes. Performing the complete ICE procedure can add significant additional latency to session setup.
A complete ICE connectivity check and candidate nomination requires - at best - one additional round trip. This assumes aggressive nomination and all the associated drawbacks. Without aggressive nomination, two round trips are added.
A transport session that is secured with Datagram Transport Layer Security (DTLS) [RFC6347] requires at least two additional round trips to establish once ICE negotiation completes.
A method is described that removes the need for blocking ICE connectivity checks and nominations with only minimal additional state overhead at each peer. This allows a secured session setup without additional latency. In addition, the negative consequences of aggressive nomination are avoided.
Peers identify candidates using information encoded in the DTLS cookie. This avoids the need for a DTLS HelloVerifyRequest and corresponding round trip.
Continuing consent to receive media in the session is verified using the DTLS heartbeat extension [RFC6520].
An extension to the Session Description Protocol (SDP) [RFC4566] identifies candidates that support this method.
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
The term server and client are used in this document to refer to the peers that act in the DTLS server and client roles. This is distinct from the caller and callee who are participants in the media session.
The DTLS ClientHello and ServerHello messages can be used as a replacement connectivity check request.
A complete session setup using ICE and DTLS optimistically requires between 5 and 7 round trips to complete. From the instant that the caller initiates a call:
This sequence assumes that no packets are lost or blocked during setup. It also assumes that the callee creates the DTLS ClientHello in order to save half a round trip, which probably doesn't correspond with established practice.
The delay imposed by acquiring consent for the call from the callee potentially dwarfs any delays from session setup. Low latency setup is most applicable to pre-authorized sessions and situations where an automated system is able to rapidly accept calls.
Using the DTLS handshake messages for connectivity checking takes far fewer round trips in the best case:
Validating the DTLS handshake requires that peers retain copies of the handshake messages. A (DTLS) client that sends multiple ClientHello messages in place of connectivity checks MUST retain the contents of each of those messages in order to later successfully complete the DTLS handshake.
This requires additional state retention - especially at the (DTLS) server - when multiple connectivity checks are sent and received. This information does not add significantly to the state burden imposed by ICE. Assuming that the client does not alter the configuration for each session, the Random and Cookie fields will vary in every ClientHello.
Continuing the handshake past the *Hello messages indicates that the candidate pair in use has been nominated. Once a Finished message has been received for any session, any state retained for other candidates within the same ICE negotiation MAY be discarded and any sessions abandoned.
This process implies that the peer in the DTLS client role is acting as the ICE controller. Since both peers need to send packets in order to create the session, a mechanism for determining which of the two clients is the controller is necessary.
A DTLS peer that receives a ClientHello when it has one of its own ClientHello messages outstanding continues to send. A peer that receives a message is more likely to be able to respond to those messages on the same transport flow than it is to successfully send its own messages. Based on the receipt of a message alone, there is no way to tell if the other peer has successfully received any other packets. Therefore, the peer creates the ServerHello and associated messages in response.
A peer that receives a ServerHello when its own ServerHello is outstanding must choose whether to end the handshake, or whether it is the controller. Only the ICE controller is able to continue the handshake.
Unless the ICE controller is selected by other means, the ICE controller is the peer that has the largest numeric public key value, taken from the DTLS Certificate message.
The HelloVerifyRequest message in DTLS is used to determine that a client is genuine and is able to receive packets. This allows a server to avoid allocating state for a client based on the receipt of an arbitrary packet.
Where a signaling relationship already exists between client and server, the cookie exchange provides less utility. However, the cookie still provides protection against receipt of spoofed ClientHello packets.
Populating the DTLS cookie with information from the signaling allows a server to determine that a packet is genuine without requiring a round trip for confirmation. Using the ICE username fragment and password ensures that no additional state is required to use this method.
The DTLS cookie includes information from the signaling, chosen by the DTLS server, plus a HMAC [RFC2104]. The HMAC that ensures that access to packets does not enable the sending of spoofed ClientHello messages.
The value of the Cookie is formed using a method similar to the ICE short term credential mechanism. The ICE user is formed by concatenating the username fragment from the peer, a colon (':') and the local username fragment. The HMAC is calculated using the ICE password as the key, with the text being a concatenation of the Random value from the DTLS ClientHello and the ICE user. No other information from the ClientHello is authenticated.
The Cookie is calculated as follows:
... where '|' implies concatenation. This method is roughly equivalent to the one used by ICE when forming STUN packets.
Hash agility is achieved by signaling the hash to use. Implementations MUST support SHA-1 [RFC3174]. See Section 6 for an example.
Multiple hash algorithms MAY be signaled to indicate that multiple different cookies are accepted.
In order to support ICE usernames longer than 12 octets or hash algorithms other than SHA-1, DTLS 1.2 [RFC6347] MUST be supported. DTLS 1.2 expands the size of the cookie field to 255 octets.
An important security concern for the web context is that a media sender has a means of checking that a media receiver consents to receive that media. Since consent can be revoked, a regular check is necessary to ensure that media is not unwanted.
The DTLS heartbeat extension [RFC6520] provides a means of signaling liveness of a DTLS session. A successful response also indicates that the receiver consents to the continuing receipt of data.
In order to support this feature, peers MUST use the heartbeat extension and MUST NOT send peer_not_allowed_to_send in the handshake.
The main drawback of this optimization is that it is not possible to gather peer reflexive addresses using the connectivity check. Performing a STUN Binding request in parallel to the DTLS handshake allows a client to gather a peer reflexive address without additional latency.
The Session Description Protocol (SDP) [RFC4566] can be used to signal support for this feature.
The ice-dtls attribute is set to the textual name of the hash function used in the HMAC. Valid values are taken from the IANA registry of Hash Function Textual Names [IANAHashText], with multiple values separated by spaces.
The Random field in the DTLS handshake provides more entropy than the corresponding field in STUN (224 bits vs. 96 bits). Both use an equivalent HMAC method. This makes guessing the correct ClientHello considerably harder than guessing the correct STUN Binding request.
The state maintained by peers using the DTLS handshake is increased marginally over what is required to perform ICE. Each peer is required to retain all the messages in the DTLS handshake in order to correctly form the Finished message. Since each peer also authenticates every ClientHello, only hosts with access to signaling are able to create state in this fashion.
State accumulation can be limited using the same methods recommended for the STUN Amplification Attack (Section 18.5.2 in [RFC5245]).
[[Note to IANA/RFC Editor: Please replace instance of RFCXXXX with the number of the published RFC and remove this note.]]
This specification defines a new SDP 'ice-dtls' attribute following the procedures of Section 8.2.4 of [RFC4566].
Cullen Jennings provided the initial idea for this optimization.
| [RFC5389] | Rosenberg, J., Mahy, R., Matthews, P. and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. |