< draft-ietf-rtcweb-security-arch-17.txt   draft-ietf-rtcweb-security-arch-18.txt >
RTCWEB E. Rescorla RTCWEB E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Intended status: Standards Track November 17, 2018 Intended status: Standards Track February 1, 2019
Expires: May 21, 2019 Expires: August 5, 2019
WebRTC Security Architecture WebRTC Security Architecture
draft-ietf-rtcweb-security-arch-17 draft-ietf-rtcweb-security-arch-18
Abstract Abstract
This document defines the security architecture for WebRTC, a This document defines the security architecture for WebRTC, a
protocol suite intended for use with real-time applications that can protocol suite intended for use with real-time applications that can
be deployed in browsers - "real time communication on the Web". be deployed in browsers - "real time communication on the Web".
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 21, 2019. This Internet-Draft will expire on August 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 43 skipping to change at page 2, line 43
5.1.3. Processing an SDP Offer or Answer . . . . . . . . . . 14 5.1.3. Processing an SDP Offer or Answer . . . . . . . . . . 14
5.1.4. Modifying the Session . . . . . . . . . . . . . . . . 14 5.1.4. Modifying the Session . . . . . . . . . . . . . . . . 14
6. Detailed Technical Description . . . . . . . . . . . . . . . 14 6. Detailed Technical Description . . . . . . . . . . . . . . . 14
6.1. Origin and Web Security Issues . . . . . . . . . . . . . 14 6.1. Origin and Web Security Issues . . . . . . . . . . . . . 14
6.2. Device Permissions Model . . . . . . . . . . . . . . . . 15 6.2. Device Permissions Model . . . . . . . . . . . . . . . . 15
6.3. Communications Consent . . . . . . . . . . . . . . . . . 17 6.3. Communications Consent . . . . . . . . . . . . . . . . . 17
6.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 17 6.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 17
6.5. Communications Security . . . . . . . . . . . . . . . . . 18 6.5. Communications Security . . . . . . . . . . . . . . . . . 18
7. Web-Based Peer Authentication . . . . . . . . . . . . . . . . 20 7. Web-Based Peer Authentication . . . . . . . . . . . . . . . . 20
7.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . . . 21 7.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . . . 21
7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 22 7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 23
7.3. Items for Standardization . . . . . . . . . . . . . . . . 24 7.3. Items for Standardization . . . . . . . . . . . . . . . . 24
7.4. Binding Identity Assertions to JSEP Offer/Answer 7.4. Binding Identity Assertions to JSEP Offer/Answer
Transactions . . . . . . . . . . . . . . . . . . . . . . 24 Transactions . . . . . . . . . . . . . . . . . . . . . . 24
7.4.1. Carrying Identity Assertions . . . . . . . . . . . . 25 7.4.1. Carrying Identity Assertions . . . . . . . . . . . . 25
7.5. Determining the IdP URI . . . . . . . . . . . . . . . . . 26 7.5. Determining the IdP URI . . . . . . . . . . . . . . . . . 26
7.5.1. Authenticating Party . . . . . . . . . . . . . . . . 27 7.5.1. Authenticating Party . . . . . . . . . . . . . . . . 27
7.5.2. Relying Party . . . . . . . . . . . . . . . . . . . . 27 7.5.2. Relying Party . . . . . . . . . . . . . . . . . . . . 28
7.6. Requesting Assertions . . . . . . . . . . . . . . . . . . 27 7.6. Requesting Assertions . . . . . . . . . . . . . . . . . . 28
7.7. Managing User Login . . . . . . . . . . . . . . . . . . . 28 7.7. Managing User Login . . . . . . . . . . . . . . . . . . . 29
8. Verifying Assertions . . . . . . . . . . . . . . . . . . . . 29 8. Verifying Assertions . . . . . . . . . . . . . . . . . . . . 29
8.1. Identity Formats . . . . . . . . . . . . . . . . . . . . 29 8.1. Identity Formats . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9.1. Communications Security . . . . . . . . . . . . . . . . . 31 9.1. Communications Security . . . . . . . . . . . . . . . . . 31
9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 32 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 33
9.4. IdP Authentication Mechanism . . . . . . . . . . . . . . 33 9.4. IdP Authentication Mechanism . . . . . . . . . . . . . . 34
9.4.1. PeerConnection Origin Check . . . . . . . . . . . . . 33 9.4.1. PeerConnection Origin Check . . . . . . . . . . . . . 34
9.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . . 34 9.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . . 34
9.4.3. Privacy of IdP-generated identities and the hosting 9.4.3. Privacy of IdP-generated identities and the hosting
site . . . . . . . . . . . . . . . . . . . . . . . . 34 site . . . . . . . . . . . . . . . . . . . . . . . . 35
9.4.4. Security of Third-Party IdPs . . . . . . . . . . . . 34 9.4.4. Security of Third-Party IdPs . . . . . . . . . . . . 35
9.4.4.1. Confusable Characters . . . . . . . . . . . . . . 35 9.4.4.1. Confusable Characters . . . . . . . . . . . . . . 35
9.4.5. Web Security Feature Interactions . . . . . . . . . . 35 9.4.5. Web Security Feature Interactions . . . . . . . . . . 35
9.4.5.1. Popup Blocking . . . . . . . . . . . . . . . . . 35 9.4.5.1. Popup Blocking . . . . . . . . . . . . . . . . . 36
9.4.5.2. Third Party Cookies . . . . . . . . . . . . . . . 35 9.4.5.2. Third Party Cookies . . . . . . . . . . . . . . . 36
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
12.1. Changes since -15 . . . . . . . . . . . . . . . . . . . 36 12.1. Changes since -15 . . . . . . . . . . . . . . . . . . . 37
12.2. Changes since -11 . . . . . . . . . . . . . . . . . . . 36 12.2. Changes since -11 . . . . . . . . . . . . . . . . . . . 37
12.3. Changes since -10 . . . . . . . . . . . . . . . . . . . 37 12.3. Changes since -10 . . . . . . . . . . . . . . . . . . . 37
12.4. Changes since -06 . . . . . . . . . . . . . . . . . . . 37 12.4. Changes since -06 . . . . . . . . . . . . . . . . . . . 37
12.5. Changes since -05 . . . . . . . . . . . . . . . . . . . 37 12.5. Changes since -05 . . . . . . . . . . . . . . . . . . . 38
12.6. Changes since -03 . . . . . . . . . . . . . . . . . . . 37 12.6. Changes since -03 . . . . . . . . . . . . . . . . . . . 38
12.7. Changes since -03 . . . . . . . . . . . . . . . . . . . 38 12.7. Changes since -03 . . . . . . . . . . . . . . . . . . . 38
12.8. Changes since -02 . . . . . . . . . . . . . . . . . . . 38 12.8. Changes since -02 . . . . . . . . . . . . . . . . . . . 38
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
13.1. Normative References . . . . . . . . . . . . . . . . . . 38 13.1. Normative References . . . . . . . . . . . . . . . . . . 39
13.2. Informative References . . . . . . . . . . . . . . . . . 41 13.2. Informative References . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
The Real-Time Communications on the Web (WebRTC) working group is The Real-Time Communications on the Web (WebRTC) working group is
tasked with standardizing protocols for real-time communications tasked with standardizing protocols for real-time communications
between Web browsers. The major use cases for WebRTC technology are between Web browsers. The major use cases for WebRTC technology are
real-time audio and/or video calls, Web conferencing, and direct data real-time audio and/or video calls, Web conferencing, and direct data
transfer. Unlike most conventional real-time systems, (e.g., SIP- transfer. Unlike most conventional real-time systems, (e.g., SIP-
based [RFC3261] soft phones) WebRTC communications are directly based [RFC3261] soft phones) WebRTC communications are directly
skipping to change at page 9, line 23 skipping to change at page 9, line 23
security check is required: untrusted origins are not allowed to security check is required: untrusted origins are not allowed to
access the camera and microphone, so the browser prompts Alice for access the camera and microphone, so the browser prompts Alice for
permission. permission.
In the current W3C API, once some streams have been added, Alice's In the current W3C API, once some streams have been added, Alice's
browser + JS generates a signaling message [I-D.ietf-rtcweb-jsep] browser + JS generates a signaling message [I-D.ietf-rtcweb-jsep]
containing: containing:
o Media channel information o Media channel information
o Interactive Connectivity Establishment (ICE) [RFC5245] candidates o Interactive Connectivity Establishment (ICE) [RFC8445] candidates
o A fingerprint attribute binding the communication to a key pair o A fingerprint attribute binding the communication to a key pair
[RFC5763]. Note that this key may simply be ephemerally generated [RFC5763]. Note that this key may simply be ephemerally generated
for this call or specific to this domain, and Alice may have a for this call or specific to this domain, and Alice may have a
large number of such keys. large number of such keys.
Prior to sending out the signaling message, the PeerConnection code Prior to sending out the signaling message, the PeerConnection code
contacts the identity service and obtains an assertion binding contacts the identity service and obtains an assertion binding
Alice's identity to her fingerprint. The exact details depend on the Alice's identity to her fingerprint. The exact details depend on the
identity service (though as discussed in Section 7 PeerConnection can identity service (though as discussed in Section 7 PeerConnection can
skipping to change at page 17, line 19 skipping to change at page 17, line 19
course). course).
Implementations SHOULD also provide a different user interface Implementations SHOULD also provide a different user interface
indication when calls are in progress to users whose identities are indication when calls are in progress to users whose identities are
directly verifiable. Section 6.5 provides more on this. directly verifiable. Section 6.5 provides more on this.
6.3. Communications Consent 6.3. Communications Consent
Browser client implementations of WebRTC MUST implement ICE. Server Browser client implementations of WebRTC MUST implement ICE. Server
gateway implementations which operate only at public IP addresses gateway implementations which operate only at public IP addresses
MUST implement either full ICE or ICE-Lite [RFC5245]. MUST implement either full ICE or ICE-Lite [RFC8445].
Browser implementations MUST verify reachability via ICE prior to Browser implementations MUST verify reachability via ICE prior to
sending any non-ICE packets to a given destination. Implementations sending any non-ICE packets to a given destination. Implementations
MUST NOT provide the ICE transaction ID to JavaScript during the MUST NOT provide the ICE transaction ID to JavaScript during the
lifetime of the transaction (i.e., during the period when the ICE lifetime of the transaction (i.e., during the period when the ICE
stack would accept a new response for that transaction). The JS MUST stack would accept a new response for that transaction). The JS MUST
NOT be permitted to control the local ufrag and password, though it NOT be permitted to control the local ufrag and password, though it
of course knows it. of course knows it.
While continuing consent is required, the ICE [RFC5245]; Section 10 While continuing consent is required, the ICE [RFC8445]; Section 10
keepalives use STUN Binding Indications which are one-way and keepalives use STUN Binding Indications which are one-way and
therefore not sufficient. The current WG consensus is to use ICE therefore not sufficient. The current WG consensus is to use ICE
Binding Requests for continuing consent freshness. ICE already Binding Requests for continuing consent freshness. ICE already
requires that implementations respond to such requests, so this requires that implementations respond to such requests, so this
approach is maximally compatible. A separate document will profile approach is maximally compatible. A separate document will profile
the ICE timers to be used; see [RFC7675]. the ICE timers to be used; see [RFC7675].
6.4. IP Location Privacy 6.4. IP Location Privacy
A side effect of the default ICE behavior is that the peer learns A side effect of the default ICE behavior is that the peer learns
skipping to change at page 19, line 20 skipping to change at page 19, line 20
1.2; endpoints which support only DTLS 1.2 might encounter 1.2; endpoints which support only DTLS 1.2 might encounter
interoperability issues. The DTLS-SRTP protection profile interoperability issues. The DTLS-SRTP protection profile
SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.
Implementations MUST favor cipher suites which support (Perfect Implementations MUST favor cipher suites which support (Perfect
Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD
over non-AEAD cipher suites. over non-AEAD cipher suites.
Implementations MUST NOT implement DTLS renegotiation and MUST reject Implementations MUST NOT implement DTLS renegotiation and MUST reject
it with a "no_renegotiation" alert if offered. it with a "no_renegotiation" alert if offered.
Endpoints MUST NOT implement TLS False Start [RFC7918].
API Requirement: The API MUST generate a new authentication key pair API Requirement: The API MUST generate a new authentication key pair
for every new call by default. This is intended to allow for for every new call by default. This is intended to allow for
unlinkability. unlinkability.
API Requirement: The API MUST provide a means to reuse a key pair API Requirement: The API MUST provide a means to reuse a key pair
for calls. This can be used to enable key continuity-based for calls. This can be used to enable key continuity-based
authentication, and could be used to amortize key generation authentication, and could be used to amortize key generation
costs. costs.
API Requirement: Unless the user specifically configures an external API Requirement: Unless the user specifically configures an external
skipping to change at page 25, line 11 skipping to change at page 25, line 21
"digest": "74:E9:76:C8:19:...:F4:45:6B" "digest": "74:E9:76:C8:19:...:F4:45:6B"
} ] } ]
} }
The "fingerprint" value is an array of objects. Each object in the The "fingerprint" value is an array of objects. Each object in the
array contains "algorithm" and "digest" values, which correspond array contains "algorithm" and "digest" values, which correspond
directly to the algorithm and digest values in the "fingerprint" directly to the algorithm and digest values in the "fingerprint"
attribute of the SDP [RFC8122]. attribute of the SDP [RFC8122].
This object is encoded in a JSON [RFC8259] string for passing to the This object is encoded in a JSON [RFC8259] string for passing to the
IdP. IdP. The identity assertion returned by the IdP, which is encoded in
the "identity" attribute, is a JSON object that is encoded as
described in Section 7.4.1.
This structure does not need to be interpreted by the IdP or the IdP This structure does not need to be interpreted by the IdP or the IdP
proxy. It is consumed solely by the RP's browser. The IdP merely proxy. It is consumed solely by the RP's browser. The IdP merely
treats it as an opaque value to be attested to. Thus, new parameters treats it as an opaque value to be attested to. Thus, new parameters
can be added to the assertion without modifying the IdP. can be added to the assertion without modifying the IdP.
7.4.1. Carrying Identity Assertions 7.4.1. Carrying Identity Assertions
Once an IdP has generated an assertion, it is attached to the SDP Once an IdP has generated an assertion (see Section 7.6), it is
offer/answer message. This is done by adding a new 'identity' attached to the SDP offer/answer message. This is done by adding a
attribute to the SDP. The sole contents of this value are a new 'identity' attribute to the SDP. The sole contents of this value
Base64-encoded [RFC4648] identity assertion. For example: is the identity assertion. The identity assertion produced by the
IdP is encoded into a UTF-8 JSON text, then Base64-encoded [RFC4648]
to produce this string. For example:
v=0 v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=example1 s=example1
c=IN IP4 ua1.example.com c=IN IP4 ua1.example.com
a=fingerprint:sha-1 \ a=fingerprint:sha-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=identity:\ a=identity:\
eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\ eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\
In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\ In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\
skipping to change at page 27, line 30 skipping to change at page 28, line 9
o Provided by the user directly. o Provided by the user directly.
o Selected from some set of IdPs known to the calling site. E.g., a o Selected from some set of IdPs known to the calling site. E.g., a
button that shows "Authenticate via Facebook Connect" button that shows "Authenticate via Facebook Connect"
7.5.2. Relying Party 7.5.2. Relying Party
Unlike the AP, the RP need not have any particular relationship with Unlike the AP, the RP need not have any particular relationship with
the IdP. Rather, it needs to be able to process whatever assertion the IdP. Rather, it needs to be able to process whatever assertion
is provided by the AP. As the assertion contains the IdP's identity, is provided by the AP. As the assertion contains the IdP's identity
the URI can be constructed directly from the assertion, and thus the in the "idp" field of the JSON-encoded object (see Section 7.6), the
RP can directly verify the technical validity of the assertion with URI can be constructed directly from the assertion, and thus the RP
no user interaction. Authoritative assertions need only be can directly verify the technical validity of the assertion with no
verifiable. Third-party assertions also MUST be verified against user interaction. Authoritative assertions need only be verifiable.
local policy, as described in Section 8.1. Third-party assertions also MUST be verified against local policy, as
described in Section 8.1.
7.6. Requesting Assertions 7.6. Requesting Assertions
The input to identity assertion is the JSON-encoded object described The input to identity assertion is the JSON-encoded object described
in Section 7.4 that contains the set of certificate fingerprints the in Section 7.4 that contains the set of certificate fingerprints the
browser intends to use. This string is treated as opaque from the browser intends to use. This string is treated as opaque from the
perspective of the IdP. perspective of the IdP.
The browser also identifies the origin that the PeerConnection is run The browser also identifies the origin that the PeerConnection is run
in, which allows the IdP to make decisions based on who is requesting in, which allows the IdP to make decisions based on who is requesting
skipping to change at page 38, line 34 skipping to change at page 39, line 15
13. References 13. References
13.1. Normative References 13.1. Normative References
[FIPS186] National Institute of Standards and Technology (NIST), [FIPS186] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", NIST PUB 186-4 , July "Digital Signature Standard (DSS)", NIST PUB 186-4 , July
2013. 2013.
[I-D.ietf-mmusic-sdp-uks] [I-D.ietf-mmusic-sdp-uks]
Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on
uses of Transport Layer Security with the Session uses of TLS with the Session Description Protocol (SDP)",
Description Protocol (SDP)", draft-ietf-mmusic-sdp-uks-02 draft-ietf-mmusic-sdp-uks-03 (work in progress), January
(work in progress), August 2018. 2019.
[I-D.ietf-rtcweb-rtp-usage] [I-D.ietf-rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
Communication (WebRTC): Media Transport and Use of RTP", Communication (WebRTC): Media Transport and Use of RTP",
draft-ietf-rtcweb-rtp-usage-26 (work in progress), March draft-ietf-rtcweb-rtp-usage-26 (work in progress), March
2016. 2016.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-10 (work in progress), January 2018. ietf-rtcweb-security-10 (work in progress), January 2018.
skipping to change at page 39, line 37 skipping to change at page 40, line 19
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<https://www.rfc-editor.org/info/rfc5245>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <https://www.rfc-editor.org/info/rfc5763>. 2010, <https://www.rfc-editor.org/info/rfc5763>.
skipping to change at page 40, line 39 skipping to change at page 41, line 15
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <https://www.rfc-editor.org/info/rfc7022>. September 2013, <https://www.rfc-editor.org/info/rfc7022>.
[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M.
Thomson, "Session Traversal Utilities for NAT (STUN) Usage Thomson, "Session Traversal Utilities for NAT (STUN) Usage
for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675,
October 2015, <https://www.rfc-editor.org/info/rfc7675>. October 2015, <https://www.rfc-editor.org/info/rfc7675>.
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", RFC 7918,
DOI 10.17487/RFC7918, August 2016,
<https://www.rfc-editor.org/info/rfc7918>.
[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media
Transport over the Transport Layer Security (TLS) Protocol Transport over the Transport Layer Security (TLS) Protocol
in the Session Description Protocol (SDP)", RFC 8122, in the Session Description Protocol (SDP)", RFC 8122,
DOI 10.17487/RFC8122, March 2017, DOI 10.17487/RFC8122, March 2017,
<https://www.rfc-editor.org/info/rfc8122>. <https://www.rfc-editor.org/info/rfc8122>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
"Datagram Transport Layer Security (DTLS) Encapsulation of "Datagram Transport Layer Security (DTLS) Encapsulation of
SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
2017, <https://www.rfc-editor.org/info/rfc8261>. 2017, <https://www.rfc-editor.org/info/rfc8261>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
[webcrypto] [webcrypto]
Dahl, Sleevi, "Web Cryptography API", June 2013. Dahl, Sleevi, "Web Cryptography API", June 2013.
Available at http://www.w3.org/TR/WebCryptoAPI/ Available at http://www.w3.org/TR/WebCryptoAPI/
[webrtc-api] [webrtc-api]
Bergkvist, Burnett, Jennings, Narayanan, "WebRTC 1.0: Bergkvist, Burnett, Jennings, Narayanan, "WebRTC 1.0:
Real-time Communication Between Browsers", October 2011. Real-time Communication Between Browsers", October 2011.
Available at http://dev.w3.org/2011/webrtc/editor/ Available at http://dev.w3.org/2011/webrtc/editor/
 End of changes. 23 change blocks. 
52 lines changed or deleted 64 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/