Internet DRAFT - draft-thomson-rtcweb-consent
draft-thomson-rtcweb-consent
RTCWEB M. Thomson
Internet-Draft Mozilla
Intended status: Standards Track D. Wing
Expires: May 24, 2014 C. Jennings
Cisco
November 20, 2013
Gaining and Maintaining Consent for Real-Time Applications
draft-thomson-rtcweb-consent-00
Abstract
This document describes how DTLS provides a WebRTC application a
clear indication that a receiver is willing to receive packets.
Mechanisms are described for maintaining that consent are described.
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 May 24, 2014.
Copyright Notice
Copyright (c) 2013 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, et al. Expires May 24, 2014 [Page 1]
Internet-Draft Receive Consent November 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2
2. Obtaining and Maintaining Receive Consent . . . . . . . . . . 2
2.1. Consent in WebRTC . . . . . . . . . . . . . . . . . . . . 3
2.2. The Role of ICE . . . . . . . . . . . . . . . . . . . . . 3
2.3. Relationship with Connection Liveness . . . . . . . . . . 4
3. Application Layer Protocol Identifiers . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
In addition to establishing connectivity, Interactive Connectivity
Establishment (ICE) [RFC5245] has been used in real-time applications
to establish that a peer is willing to receive packets.
This document describes how Datagram Transport Layer Security (DTLS)
[RFC6347] is sufficient for establishing consent to receive packets,
plus how this consent can be continuously refreshed.
This also uses Application-Layer Protocol Negotiation (ALPN)
[I-D.ietf-tls-applayerprotoneg] to restrict that consent to specific
uses. Application protocol tokens are defined for the Real-Time
Protocol (RTP) [RFC3550] over DTLS-SRTP [RFC5764], WebRTC data
channels [I-D.ietf-rtcweb-data-channel] and a multiplexed combination
of these two protocols.
1.1. Conventions and Terminology
At times, this document falls back on shorthands for establishing
interoperability requirements on implementations: the capitalized
words "MUST", "SHOULD" and "MAY". These terms are defined in
[RFC2119].
2. Obtaining and Maintaining Receive Consent
An endpoint MUST NOT send application data (in WebRTC, RTP or SCTP
data) on a DTLS connection unless the receiving endpoint consents to
receive the data.
Thomson, et al. Expires May 24, 2014 [Page 2]
Internet-Draft Receive Consent November 2013
An endpoint that initiates or responds to a DTLS handshake that
negotiates a specific application layer protocol (see Section 3)
explicitly consents to receive packets containing the described
protocol.
Consent expires after a fixed amount of time. Explicit consent to
receive is indicated by the receiving endpoint sending authenticated
packets from the inverted 5-tuple. An endpoint uses the receipt of
packets as an indication that the remote endpoint still consents to
receive data.
Any packet received from the inverted 5-tuple refreshes consent if
the packet is successfully validated by the protocol's authentication
check (for instance, a MAC). Any DTLS message is sufficient to
refresh consent, since these contain a MAC. For DTLS-SRTP [RFC5764],
receipt of an authenticated SRTP packet is sufficient.
Consent is ended immediately by receipt of a an authenticated message
that closes the connection (for instance, a TLS fatal alert).
Receipt of an unauthenticated end-of-session message (e.g., TCP FIN)
does not indicate loss of consent. Thus, an endpoint receiving an
unauthenticated end-of-session message SHOULD continue sending media
(over connectionless transport) or attempt to re-establish the
connection (over connection-oriented transport) until consent expires
or it receives an authenticated message revoking consent.
2.1. Consent in WebRTC
WebRTC applications MUST cease transmission on a connection if they
have not received any valid, authenticated packets for 30 seconds.
WebRTC applications that intend to maintain consent MUST send an
authenticated packet at least every 10 seconds. If there is no
application data to send, the DTLS heartbeat extension [RFC6520] MUST
be sent to maintain consent. This reduces the probability that
transient network failures cause consent expiration.
2.2. The Role of ICE
Given that DTLS is used to establish and maintain consent, ICE is
only used to test and nominate candidate pairs. This allows for the
use of DTLS without ICE, though this is unlikely to work for
endpoints with poor connectivity.
If ICE is not employed, a DTLS server SHOULD use the denial of
service countermeasures described in Section 4.2.1 of [RFC6347];
specifically the "HelloVerifyRequest" and the cookie that it carries.
Thomson, et al. Expires May 24, 2014 [Page 3]
Internet-Draft Receive Consent November 2013
2.3. Relationship with Connection Liveness
A connection is considered "live" if packets are received from a
remote endpoint within an application-dependent period.
A WebRTC application can request a notification when there are no
packets received for a certain period. Similarly, an application can
request that heartbeats are sent after an interval shorter than 10
seconds. These two time intervals might be controlled by the same
configuration item.
Sending heartbeats at a high rate could allow a malicious application
to generate congestion. A WebRTC application MUST NOT be able to
send heartbeats at a rate higher than 1 per second.
3. Application Layer Protocol Identifiers
The following ALPN identifiers are defined:
RTP (0x52 0x54 0x50): This token indicates that DTLS-SRTP [RFC5764]
is acceptable or selected.
SCTP (0x53 0x43 0x54 0x50): This token indicates that WebRTC Data
Channels [I-D.ietf-rtcweb-data-channel] is acceptable or accepted.
The DTLS record-layer carries encapsulated Stream Control
Transmission Protocol (SCTP) [RFC4960] packets as described in
[I-D.ietf-tsvwg-sctp-dtls-encaps].
RTP+SCTP (0x52 0x54 0x50 0x2b 0x53 0x43 0x54 0x50): This token
indicates that both DTLS-SRTP [RFC5764] and WebRTC Data Channels
[I-D.ietf-rtcweb-data-channel] are acceptable or selected. The
DTLS record-layer carries encapsulated SCTP packets as described
in [I-D.ietf-tsvwg-sctp-dtls-encaps]; this is multiplexed with
SRTP [RFC3711] packets as described in [RFC5764].
An application that can use a multiplexed combination of SRTP and
SCTP MUST select "RTP+SCTP" if it is available, even if it is not
using both protocols initially. This avoids any need to renegotiate
application layer protocols as usage needs change.
4. Security Considerations
This document defines a security mechanism.
Consent does not establish any bounds on the volume of packets that a
receiver is willing to accept. A receiver that receives packets at a
rate in excess of what it is willing to tolerate can close the
connection. If the close message is lost, this can result in
Thomson, et al. Expires May 24, 2014 [Page 4]
Internet-Draft Receive Consent November 2013
unwanted data being received until consent expires (i.e., 30
seconds).
SRTP is encrypted and authenticated with symmetric keys; that is,
both sender and receiver know the keys. With two party sessions,
receipt of an authenticated packet from the single remote party is a
strong assurance the packet came from that party. However, when a
session involves more than two parties, all of whom know each others
keys, any of those parties could have sent (or spoofed) the packet.
Such shared key distributions are possible with some MIKEY [RFC3830]
modes, Security Descriptions [RFC4568], and EKT
[I-D.ietf-avtcore-srtp-ekt].
5. IANA Considerations
This document registers three identifiers in the "Application Layer
Protocol Negotiation (ALPN) Protocol IDs" established by
[I-D.ietf-tls-applayerprotoneg].
Protocol: RTP over DTLS-SRTP
Identification Sequence: 0x52 0x54 0x50 ("RTP")
Specification: This document.
Protocol: WebRTC Data Channels
Identification Sequence: 0x53 0x43 0x54 0x50 ("SCTP")
Specification: This document.
Protocol: RTP over DTLS-SRTP multiplexed with WebRTC Data Channels
Identification Sequence: 0x52 0x54 0x50 0x2b 0x53 0x43 0x54 0x50
("RTP+SCTP")
Specification: This document.
6. Acknowledgements
Muthu Arul Mozhi Perumal, Ram Mohan Ravindranath, Tirumaleswar Reddy,
and Dan Wing are the authors of the original draft that dealt with
managing consent.
7. References
7.1. Normative References
Thomson, et al. Expires May 24, 2014 [Page 5]
Internet-Draft Receive Consent November 2013
[I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data
Channels", draft-ietf-rtcweb-data-channel-06 (work in
progress), October 2013.
[I-D.ietf-tls-applayerprotoneg]
Friedl, S., Popov, A., Langley, A., and S. Emile,
"Transport Layer Security (TLS) Application Layer Protocol
Negotiation Extension", draft-ietf-tls-applayerprotoneg-03
(work in progress), October 2013.
[I-D.ietf-tsvwg-sctp-dtls-encaps]
Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
dtls-encaps-02 (work in progress), October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[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.
7.2. Informative References
[I-D.ietf-avtcore-srtp-ekt]
McGrew, D. and D. Wing, "Encrypted Key Transport for
Secure RTP", draft-ietf-avtcore-srtp-ekt-01 (work in
progress), October 2013.
Thomson, et al. Expires May 24, 2014 [Page 6]
Internet-Draft Receive Consent November 2013
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007.
Authors' Addresses
Martin Thomson
Mozilla
Suite 300
650 Castro Street
Mountain View, CA 94041
US
Email: martin.thomson@gmail.com
Dan Wing
Cisco Systems, Inc.
510 McCarthy Blvd.
Milpitas, CA 95035
US
Phone: (408) 853 4197
Email: dwing@cisco.com
Cullen Jennings
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 408 421-9990
Email: fluffy@cisco.com
Thomson, et al. Expires May 24, 2014 [Page 7]
