rtcweb M. Thomson Internet-Draft Skype Intended status: Standards Track March 28, 2012 Expires: September 29, 2012 Using Datagram Transport Layer Security (DTLS) For Interactivity Connectivity Establishment (ICE) Connectivity Checking: ICE-DTLS draft-thomson-rtcweb-ice-dtls-00 Abstract 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. Status of this Memo 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 September 29, 2012. Copyright Notice 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. Thomson Expires September 29, 2012 [Page 1] Internet-Draft ICE-DTLS March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. ICE using DTLS . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Without Optimization . . . . . . . . . . . . . . . . . . . 4 3.2. With Optimization . . . . . . . . . . . . . . . . . . . . 5 3.3. Connectivity Check and Nomination . . . . . . . . . . . . 5 3.4. ICE Controller Selection . . . . . . . . . . . . . . . . . 5 3.5. DTLS Cookie Handling . . . . . . . . . . . . . . . . . . . 6 4. Indicating Continuing Consent to Receive . . . . . . . . . . . 7 5. Parallel STUN . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Signaling in SDP . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Thomson Expires September 29, 2012 [Page 2] Internet-Draft ICE-DTLS March 2012 1. Introduction 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. 2. Terminology 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 Thomson Expires September 29, 2012 [Page 3] Internet-Draft ICE-DTLS March 2012 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. 3. ICE using DTLS The DTLS ClientHello and ServerHello messages can be used as a replacement connectivity check request. 3.1. Without Optimization 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: 1. Caller gathers server reflexive and relay candidates. 2. Caller signals call creation. Callee signals response, callee sends first connectivity check - a Session Traversal Utilities for NAT (STUN) [RFC5389] Binding request. 3. Caller responds to connectivity check, creates own connectivity check. Callee responds to connectivity check. 4. Caller creates an ICE nomination (a STUN Binding request with USE-CANDIDATE set). Callee responds to nomination. Callee sends DTLS ClientHello. 5. Caller sends a DTLS HelloVerifyRequest with a cookie. Callee re- sends the ClientHello with the cookie. 6. Caller sends a DTLS ServerHello and associated messages. Callee sends a DTLS Finished and ChangeCipherSpec. 7. Caller validates the Finished message. Caller can begin media transmission. Caller sends a Finished message. Callee validates the Finished message. Callee can begin media transmission. 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. Thomson Expires September 29, 2012 [Page 4] Internet-Draft ICE-DTLS March 2012 3.2. With Optimization Using the DTLS handshake messages for connectivity checking takes far fewer round trips in the best case: 1. Caller gathers server reflexive and relay candidates. 2. Caller signals call creation, indicating support for ICE-DTLS. Callee signals response. Callee sends DTLS ClientHello including a specially formatted cookie. 3. Caller sends a DTLS ServerHello and associated messages. Callee sends a DTLS Finished and ChangeCipherSpec. 4. Caller validates the Finished message. Caller can begin media transmission. Caller sends a Finished message. Callee validates the Finished message. Callee can begin media transmission. 3.3. Connectivity Check and Nomination 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. 3.4. ICE Controller Selection 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 Thomson Expires September 29, 2012 [Page 5] Internet-Draft ICE-DTLS March 2012 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. 3.5. DTLS Cookie Handling 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: Thomson Expires September 29, 2012 [Page 6] Internet-Draft ICE-DTLS March 2012 ice_user = ice_ufrag_peer | ':' | ice_ufrag_local Cookie = HMAC[hash](ice_pwd_peer, Random | ice_user) | ice_user ... 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. 4. Indicating Continuing Consent to Receive 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. 5. Parallel STUN 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. 6. Signaling in SDP The Session Description Protocol (SDP) [RFC4566] can be used to signal support for this feature. Thomson Expires September 29, 2012 [Page 7] Internet-Draft ICE-DTLS March 2012 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. 7. Security Considerations 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]). 8. IANA Considerations [[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]. Contact Name: Martin Thomson, martin.thomson@gmail.com Attribute Name: ice-dtls Long Form: ice-dtls Type of Attribute: session- or media-level Charset Considerations: The attribute is not subject to the charset attribute. Purpose: This attribute indicates that DTLS is supported as an alternative mechanism for ICE connectivity checking and consent. The values of the attribute indicate the hash functions that can be used to calculate the value of the DTLS cookie. Thomson Expires September 29, 2012 [Page 8] Internet-Draft ICE-DTLS March 2012 Appropriate Values: A whitespace-separated list of values taken from the IANA registry of Hash Function Textual Names [IANAHashText]. 9. Acknowledgments Cullen Jennings provided the initial idea for this optimization. 10. References 10.1. Normative References [IANAHashText] Internet Asigned Numbers Authority, "IANA registry of Hash Function Textual Names". [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, February 2012. Thomson Expires September 29, 2012 [Page 9] Internet-Draft ICE-DTLS March 2012 10.2. Informative References [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. Author's Address Martin Thomson Skype 3210 Porter Drive Palo Alto, CA 94304 US Phone: +1 650-353-1925 Email: martin.thomson@gmail.com Thomson Expires September 29, 2012 [Page 10]