One document matched: draft-ietf-rtcweb-stun-consent-freshness-16.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes'?>
<?rfc tocdepth="3"?>
<?rfc compact="yes"?>
<?rfc tocdepth="yes"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline ="yes"?>
<?rfc subcompact="no"?>
<?rfc tocompact="yes"?>
<?rfc colonspace="yes"?>
<rfc category="std" docName="draft-ietf-rtcweb-stun-consent-freshness-16"
ipr="trust200902">
<front>
<title abbrev="STUN Usage for Consent Freshness">STUN Usage for Consent
Freshness</title>
<author fullname="Muthu Arul Mozhi Perumal" initials="M."
surname="Perumal">
<organization>Ericsson</organization>
<address>
<postal>
<street>Ferns Icon</street>
<street>Doddanekundi, Mahadevapura</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560037</code>
<country>India</country>
</postal>
<email>muthu.arul@gmail.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D" surname="Wing">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>821 Alder Drive</street>
<city>Milpitas</city>
<region>California</region>
<code>95035</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Ram Mohan Ravindranath" initials="R"
surname="Ravindranath">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Cessna Business Park</street>
<street>Sarjapur-Marathahalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>rmohanr@cisco.com</email>
</address>
</author>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<author fullname="Martin Thomson" initials="M." surname="Thomson">
<organization>Mozilla</organization>
<address>
<postal>
<street>Suite 300</street>
<street>650 Castro Street</street>
<city>Mountain View</city>
<region>California</region>
<code>94041</code>
<country>US</country>
</postal>
<email>martin.thomson@gmail.com</email>
</address>
</author>
<date />
<area>RAI</area>
<workgroup>RTCWEB</workgroup>
<abstract>
<t>To prevent WebRTC applications, such as browsers, from launching
attacks by sending traffic to unwilling victims, periodic consent to send
needs to be obtained from remote endpoints.</t>
<t>This document describes a consent mechanism using a new Session
Traversal Utilities for NAT (STUN) usage.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>To prevent attacks on peers, endpoints have to ensure the remote peer
is willing to receive traffic. Verification of peer consent before sending
traffic is necessary in deployments like WebRTC to ensure that a
malicious JavaScript cannot use the browser as a platform for launching
attacks. This is performed both when the session
is first established to the remote peer using <xref
target="RFC5245">Interactive Connectivity Establishment ICE</xref>
connectivity checks, and periodically for the duration of the session
using the procedures defined in this document.</t>
<t>When a session is first established, ICE implementations obtain an
initial consent to send by performing STUN connectivity checks. This
document describes a new STUN usage with exchange of request and
response messages that verifies the remote peer's ongoing consent to
receive traffic. This consent expires after a period of time and needs
to be continually renewed, which ensures that consent can be
terminated.</t>
<t>This document defines what it takes to obtain, maintain, and lose
consent to send. Consent to send applies to a single 5-tuple. How
applications react to changes in consent is not described in this
document. The consent mechanism does not update the ICE procedures
defined in <xref target="RFC5245"></xref>.</t>
<t>Consent is obtained only by full ICE implementations. An ICE-lite
agent (as defined in Section 2.7 of <xref target="RFC5245"></xref>) does
not generate connectivity checks or run the ICE state machine. Hence, an
ICE-lite agent does not generate consent checks and will only respond to
any checks that it receives. No changes are required to ICE-lite
implementations in order to respond to consent checks, as they are
processed as normal ICE connectivity checks.</t>
</section>
<section anchor="sec-applic" title="Applicability">
<t>This document defines what it takes to obtain, maintain, and lose
consent to send using ICE. Section 4.4 and Section 5.3 of <xref
target="I-D.ietf-rtcweb-security-arch"></xref> further explains the
value of obtaining and maintaining consent.</t>
<t>Other Applications that have similar security requirements to verify
peer consent before sending non-ICE packets can use the consent
mechanism described in this document. The mechanism of how applications
are made aware of consent expiration is outside the scope of the
document.</t>
</section>
<section anchor="sec-term" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
<t><list style="hanging">
<t hangText="Consent:">The mechanism of obtaining permission from
the remote endpoint to send non-ICE traffic to a remote transport
address. Consent is obtained using ICE. Note that this is an
application-level consent; no human intervention is involved.</t>
<t hangText="Consent Freshness:">Maintaining and renewing consent
over time.</t>
<t hangText="Transport Address:">The remote peer's IP address and
UDP or TCP port number.</t>
</list></t>
</section>
<section title="Design Considerations">
<t>Although ICE requires periodic keepalive traffic to keep NAT bindings
alive (Section 10 of <xref target="RFC5245"></xref>, <xref
target="RFC6263"></xref>), those keepalives are sent as STUN Indications
which are send-and-forget, and do not evoke a response. A response is
necessary for consent to continue sending traffic. Thus, we need a
request/response mechanism for consent freshness. ICE can be used for
that mechanism because ICE implementations are already required to
continue listening for ICE messages, as described in Section 10 of <xref
target="RFC5245"></xref>. STUN binding requests sent for consent
freshness also serve the keepalive purpose (i.e to keep NAT bindings
alive). Because of that, dedicated keepalives (e.g. STUN Binding
Indications) are not sent on candidate pairs where consent requests are
sent, in accordance with Section 20.2.3 of <xref
target="RFC5245"></xref>.</t>
<t>When Secure Real-time Transport Protocol (SRTP) is used, the
following considerations are applicable. 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 other's keys, any of those parties could
have sent (or spoofed) the packet. Such shared key distributions are
possible with some <xref target="RFC3830">MIKEY</xref> modes, <xref
target="RFC4568">Security Descriptions</xref>, and <xref
target="I-D.ietf-avtcore-srtp-ekt">EKT</xref>. Thus, in such shared
keying distributions, receipt of an authenticated SRTP packet is not
sufficient to verify consent.</t>
<t>The mechanism proposed in the document is an optional extension to
the ICE protocol, it can be deployed at one end of the two-party
communication session without impact on the other party.</t>
</section>
<section title="Solution">
<t>Initial consent to send traffic is obtained using <xref
target="RFC5245">ICE</xref>. An endpoint gains consent to send on a
candidate pair when the pair enters the Succeeded ICE state. This
document establishes a 30 second expiry time on consent. 30 seconds was
chosen to balance the need to minimize the time taken to respond to a
loss of consent with the desire to reduce the occurrence of spurious
failures.</t>
<t>ICE does not identify when consent to send traffic ends. This
document describes two ways in which consent to send ends: expiration of
consent and immediate revocation of consent, which are discussed in the
following sections.</t>
<section title="Expiration of Consent">
<t>A full ICE implementation obtains consent to send using ICE. After
ICE concludes on a particular candidate pair and whenever the endpoint
sends application data on that pair consent is maintained
following the procedure described in this document.</t>
<t>An endpoint MUST NOT send data other than the messages used to
establish consent unless the receiving endpoint has consented to
receive data. Connectivity checks that are paced as described in
Section 16 of <xref target="RFC5245"></xref> and responses to
connectivity checks are permitted. That is, no application data (e.g.,
RTP or Datagram Transport Layer Security (DTLS)) can be sent until
consent is obtained.</t>
<t>Explicit consent to send is obtained and maintained by sending a
STUN binding request to the remote peer's transport address and
receiving a matching, authenticated, non-error STUN binding response
from the remote peer's transport address. These STUN binding requests
and responses are authenticated using the same short-term credentials
as the initial ICE exchange. <list style="hanging">
<t hangText="Note:">Although TCP has its own consent mechanism
(TCP acknowledgements), consent is necessary over a TCP connection
because it could be translated to a UDP connection (e.g., <xref
target="RFC6062"></xref>).</t>
</list></t>
<t>Consent expires after 30 seconds. That is, if a valid STUN binding
response has not been received from the remote peer's transport
address in 30 seconds, the endpoint MUST cease transmission on that
5-tuple. STUN consent responses received after consent expiry do not
re-establish consent, and may be discarded or cause an ICMP error.</t>
<t>To prevent expiry of consent, a STUN binding request can be sent
periodically. To prevent synchronization of consent checks, each
interval MUST be randomized from between 0.8 and 1.2 times the basic
period. Implementations SHOULD set a default interval of 5 seconds,
resulting in a period between checks of 4 to 6 seconds.
Implementations MUST NOT set the period between checks to less than 4
seconds. This timer is independent of the consent expiry timeout.</t>
<t>Each STUN binding request for consent MUST use a new STUN
transaction identifier, as described
in Section 6 of <xref target="RFC5389"></xref>. Each STUN binding
request for consent is transmitted once only. A sender therefore
cannot assume that it will receive a response for every consent
request, and a response might be for a previous request (rather than
for the most recently sent request).</t>
<t>An endpoint SHOULD await a binding response for each request it
sends for a time based on the estimated round-trip time (RTT) (see
Section 7.2.1 of <xref target="RFC5389"></xref>) with an allowance for
variation in network delay. The RTT value can be updated as described
in <xref target="RFC5389"></xref>. All outstanding STUN consent
transactions for a candidate pair MUST be discarded when consent
expires.</t>
<t>To meet the security needs of consent, an untrusted application
(e.g., JavaScript or signaling servers) MUST NOT be able to obtain or
control the STUN transaction identifier, because that enables spoofing
of STUN responses, falsifying consent.</t>
<t>To prevent attacks on the peer during ICE restart, an endpoint that
continues to send traffic on the previously validated candidate pair
during ICE restart MUST continue to perform consent freshness on that
candidate pair as described earlier.</t>
<t>While TCP affords some protection from off-path attackers (<xref
target="RFC5961"></xref>, <xref target="RFC4953"></xref>), there is
still a risk an attacker could cause a TCP sender to send forever by
spoofing ACKs. To prevent such an attack, consent checks MUST be
performed over all transport connections, including TCP. In this way,
an off-path attacker spoofing TCP segments cannot cause a TCP sender
to send once the consent timer expires (30 seconds).</t>
<t>An endpoint does not need to maintain consent if it does not send
application data. However, an endpoint MUST regain consent before it
resumes sending application data. In the absence of any packets, any
bindings in middleboxes for the flow might expire. Furthermore, having
one peer unable to send is detrimental to many protocols. Absent
better information about the network, if an endpoint needs to ensure
its NAT or firewall mappings do not expire, it can be done using
keepalive or other techniques (see Section 10 of <xref
target="RFC5245"></xref> and see <xref target="RFC6263"></xref>).</t>
<t>After consent is lost, the same ICE credentials MUST NOT be used on
the affected 5-tuple again. That means that a new session, or an ICE
restart, is needed to obtain consent to send on the affected candidate
pair.</t>
</section>
<section title="Immediate Revocation of Consent">
<t>In some cases it is useful to signal that consent is terminated
rather than relying on a timeout.</t>
<t>Consent for sending application data is immediately revoked by
receipt of an authenticated message that closes the connection (e.g.,
a TLS fatal alert) or receipt of a valid and authenticated STUN
response with error code Forbidden (403). Note however that consent
revocation messages can be lost on the network, so an endpoint could
resend these messages, or wait for consent to expire.</t>
<t>Receipt of an unauthenticated message that closes a connection
(e.g., TCP FIN) does not indicate revocation 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.</t>
<t>Note that an authenticated SRTCP BYE does not terminate consent; it
only indicates the associated SRTP source has quit.</t>
</section>
</section>
<section anchor="DSCP-consent" title="DiffServ Treatment for Consent">
<t>It is RECOMMENDED that STUN consent checks use the same Diffserv
Codepoint markings as the ICE connectivity checks described in Section
7.1.2.4 of <xref target="RFC5245"></xref> for a given 5-tuple. <list
style="hanging">
<t hangText="Note:">It is possible that different Diffserv
Codepoints are used by different media over the same transport
address <xref target="I-D.ietf-tsvwg-rtcweb-qos"></xref>. Such a
case is outside the scope of this document.</t>
</list></t>
</section>
<section title="DTLS applicability">
<t>The DTLS applicability is identical to what is described in Section
4.2 of <xref target="RFC7350"></xref>.</t>
</section>
<section title="Security Considerations">
<t>This document describes a security mechanism, details of which are
mentioned in Section 4.1 and Section 4.2. Consent requires 96 bits
transaction ID defined in section 6 of <xref target="RFC5389"/> to be
uniformly and randomly chosen from the interval 0
.. 2**96-1, and be cryptographically strong. This is good enough
security against an off-path attacker replaying old STUN consent
responses. Consent Verification to avoid attacks using a browser as an
attack platform against machines is discussed in Sections 3.3 and 4.2 of
<xref target="I-D.ietf-rtcweb-security"></xref>.</t>
<t>The security considerations discussed in <xref
target="RFC5245"></xref> should also be taken into account.</t>
</section>
<section anchor="sec.iana-considerations" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section title="Acknowledgement">
<t>Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus
Westerlund, Cullen Jennings, Christer Holmberg, Simon Perreault, Paul
Kyzivat, Emil Ivov, Jonathan Lennox, Inaki Baz Castillo, Rajmohan
Banavi, Christian Groves, Meral Shirazipour, David Black, Barry Leiba, Ben Campbell
and Stephen Farrell for their valuable inputs and comments. Thanks to Christer
Holmberg for doing a thorough review.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.5389"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3830"?>
<?rfc include="reference.RFC.4568"?>
<?rfc include="reference.RFC.6062"?>
<?rfc include="reference.I-D.ietf-tsvwg-rtcweb-qos"?>
<?rfc include="reference.I-D.ietf-avtcore-srtp-ekt"?>
<?rfc include="reference.I-D.ietf-rtcweb-security-arch"?>
<?rfc include="reference.RFC.6263"?>
<?rfc include="reference.I-D.ietf-rtcweb-security"?>
<?rfc include="reference.RFC.5961"?>
<?rfc include="reference.RFC.4953"?>
<?rfc include="reference.RFC.7350"?>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 20:44:34 |