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/ |