Internet DRAFT - draft-thomson-rtcweb-ice-dtls

draft-thomson-rtcweb-ice-dtls






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]