--- 1/draft-ietf-rtcweb-security-arch-14.txt 2018-07-17 13:13:49.717828311 -0700 +++ 2/draft-ietf-rtcweb-security-arch-15.txt 2018-07-17 13:13:49.801830355 -0700 @@ -1,18 +1,18 @@ RTCWEB E. Rescorla Internet-Draft RTFM, Inc. -Intended status: Standards Track March 10, 2018 -Expires: September 11, 2018 +Intended status: Standards Track July 17, 2018 +Expires: January 18, 2019 WebRTC Security Architecture - draft-ietf-rtcweb-security-arch-14 + draft-ietf-rtcweb-security-arch-15 Abstract This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -21,21 +21,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 11, 2018. + This Internet-Draft will expire on January 18, 2019. Copyright Notice Copyright (c) 2018 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 @@ -76,21 +76,21 @@ 5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 14 5.5. Communications Security . . . . . . . . . . . . . . . . . 15 5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 17 5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 18 5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 20 5.6.3. Items for Standardization . . . . . . . . . . . . . . 21 5.6.4. Binding Identity Assertions to JSEP Offer/Answer Transactions . . . . . . . . . . . . . . . . . . . . 21 5.6.4.1. Carrying Identity Assertions . . . . . . . . . . 22 5.6.4.2. a=identity Attribute . . . . . . . . . . . . . . 23 - 5.6.5. Determining the IdP URI . . . . . . . . . . . . . . . 23 + 5.6.5. Determining the IdP URI . . . . . . . . . . . . . . . 24 5.6.5.1. Authenticating Party . . . . . . . . . . . . . . 25 5.6.5.2. Relying Party . . . . . . . . . . . . . . . . . . 25 5.6.6. Requesting Assertions . . . . . . . . . . . . . . . . 25 5.6.7. Managing User Login . . . . . . . . . . . . . . . . . 26 5.7. Verifying Assertions . . . . . . . . . . . . . . . . . . 27 5.7.1. Identity Formats . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6.1. Communications Security . . . . . . . . . . . . . . . . . 28 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 30 @@ -98,32 +98,32 @@ 6.4.1. PeerConnection Origin Check . . . . . . . . . . . . . 31 6.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . . 31 6.4.3. Privacy of IdP-generated identities and the hosting site . . . . . . . . . . . . . . . . . . . . . . . . 32 6.4.4. Security of Third-Party IdPs . . . . . . . . . . . . 32 6.4.4.1. Confusable Characters . . . . . . . . . . . . . . 32 6.4.5. Web Security Feature Interactions . . . . . . . . . . 32 6.4.5.1. Popup Blocking . . . . . . . . . . . . . . . . . 33 6.4.5.2. Third Party Cookies . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.1. Changes since -11 . . . . . . . . . . . . . . . . . . . . 34 9.2. Changes since -10 . . . . . . . . . . . . . . . . . . . . 34 9.3. Changes since -06 . . . . . . . . . . . . . . . . . . . . 34 - 9.4. Changes since -05 . . . . . . . . . . . . . . . . . . . . 34 + 9.4. Changes since -05 . . . . . . . . . . . . . . . . . . . . 35 9.5. Changes since -03 . . . . . . . . . . . . . . . . . . . . 35 9.6. Changes since -03 . . . . . . . . . . . . . . . . . . . . 35 9.7. Changes since -02 . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 - 10.2. Informative References . . . . . . . . . . . . . . . . . 38 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 36 + 10.2. Informative References . . . . . . . . . . . . . . . . . 39 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction The Real-Time Communications on the Web (WebRTC) working group is tasked with standardizing protocols for real-time communications between Web browsers. The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems, (e.g., SIP- based[RFC3261] soft phones) WebRTC communications are directly @@ -177,28 +177,28 @@ This system presents a number of new security challenges, which are analyzed in [I-D.ietf-rtcweb-security]. This document describes a security architecture for WebRTC which addresses the threats and requirements described in that document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP - 14 [RFC2119]. [RFC8174] when, and only when, they appear in all + 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Trust Model The basic assumption of this architecture is that network resources exist in a hierarchy of trust, rooted in the browser, which serves as - the user's TRUSTED COMPUTING BASE (TCB). Any security property which + the user's Trusted Computing Base (TCB). Any security property which the user wishes to have enforced must be ultimately guaranteed by the browser (or transitively by some property the browser verifies). Conversely, if the browser is compromised, then no security guarantees are possible. Note that there are cases (e.g., Internet kiosks) where the user can't really trust the browser that much. In these cases, the level of security provided is limited by how much they trust the browser. Optimally, we would not rely on trust in any entities other than the browser. However, this is unfortunately not possible if we wish to @@ -266,21 +266,21 @@ parties. For instance, Alice might have an account with a social network which she can then use to authenticate to other web sites without explicitly having an account with those sites; this is a fairly conventional pattern on the Web. Section 5.6.1 provides an overview of Identity Providers and the relevant terminology. Alice and Bob might have relationships with different IdPs as well. This separation of identity provision and signaling isn't particularly important in "closed world" cases where Alice and Bob are users on the same social network and have identities based on - that domain (Figure 3) However, there are important settings where + that domain (Figure 3). However, there are important settings where that is not the case, such as federation (calls from one domain to another; Figure 4) and calling on untrusted sites, such as where two users who have a relationship via a given social network want to call each other on another, untrusted, site, such as a poker site. Note that the servers themselves are also authenticated by an external identity service, the SSL/TLS certificate infrastructure (not shown). As is conventional in the Web, all identities are ultimately rooted in that system. For instance, when an IdP makes an identity assertion, the Relying Party consuming that assertion is @@ -399,21 +399,21 @@ Prior to sending out the signaling message, the PeerConnection code contacts the identity service and obtains an assertion binding Alice's identity to her fingerprint. The exact details depend on the identity service (though as discussed in Section 5.6 PeerConnection can be agnostic to them), but for now it's easiest to think of as an OAuth token. The assertion may bind other information to the identity besides the fingerprint, but at minimum it needs to bind the fingerprint. This message is sent to the signaling server, e.g., by XMLHttpRequest - [XmlHttpRequest] or by WebSockets [RFC6455]. preferably over TLS + [XmlHttpRequest] or by WebSockets [RFC6455], preferably over TLS [RFC5246]. The signaling server processes the message from Alice's browser, determines that this is a call to Bob and sends a signaling message to Bob's browser (again, the format is currently undefined). The JS on Bob's browser processes it, and alerts Bob to the incoming call and to Alice's identity. In this case, Alice has provided an identity assertion and so Bob's browser contacts Alice's identity provider (again, this is done in a generic way so the browser has no specific knowledge of the IdP) to verify the assertion. This allows the browser to display a trusted element in the browser chrome indicating that a call is coming in from Alice. If Alice is in Bob's @@ -438,21 +438,21 @@ that message received securely from the signaling server. Because the far end sent an identity assertion along with their message, they know that this is verifiable from the IdP as well. Note that if the call is federated, as shown in Figure 4 then Alice is able to verify Bob's identity in a way that is not mediated by either her signaling server or Bob's. Rather, she verifies it directly with Bob's IdP. Of course, the call works perfectly well if either Alice or Bob doesn't have a relationship with an IdP; they just get a lower level of assurance. I.e., they simply have whatever information their - calling site claims about the caller/calllee's identity. Moreover, + calling site claims about the caller/callee's identity. Moreover, Alice might wish to make an anonymous call through an anonymous calling site, in which case she would of course just not provide any identity assertion and the calling site would mask her identity from Bob. 4.2. Media Consent Verification As described in ([I-D.ietf-rtcweb-security]; Section 4.2) media consent verification is provided via ICE. Thus, Alice and Bob perform ICE checks with each other. At the completion of these @@ -714,22 +714,23 @@ select it if offered. A SRTP MKI MUST NOT be used. All data channels MUST be secured via DTLS. All implementations MUST implement DTLS 1.0, with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve [FIPS186]. The DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. Implementations SHOULD implement DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. - Implementations MUST favor cipher suites which support PFS over non- - PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites. + Implementations MUST favor cipher suites which support (Perfect + Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD + over non-AEAD cipher suites. Implementations MUST NOT implement DTLS renegotiation and MUST reject it with a "no_renegotiation" alert if offered. API Requirement: The API MUST generate a new authentication key pair for every new call by default. This is intended to allow for unlinkability. API Requirement: The API MUST provide a means to reuse a key pair for calls. This can be used to enable key continuity-based @@ -772,21 +773,21 @@ * The "security characteristics" MUST indicate the cryptographic algorithms in use (For example: "AES-CBC".) However, if Null ciphers are used, that MUST be presented to the user at the top-level UI. * The "security characteristics" MUST indicate whether PFS is provided. * The "security characteristics" MUST include some mechanism to allow an out-of-band verification of the peer, such as a - certificate fingerprint or an SAS. + certificate fingerprint or a Short Authentication String (SAS). 5.6. Web-Based Peer Authentication In a number of cases, it is desirable for the endpoint (i.e., the browser) to be able to directly identify the endpoint on the other side without trusting the signaling service to which they are connected. For instance, users may be making a call via a federated system where they wish to get direct authentication of the other side. Alternately, they may be making a call on a site which they minimally trust (such as a poker site) but to someone who has an @@ -857,21 +858,21 @@ (Facebook identities only make sense within the context of the Facebook system). Third-Party: IdPs which don't have control of their section of the identity space but instead verify user's identities via some unspecified mechanism and then attest to it. Because the IdP doesn't actually control the namespace, RPs need to trust that the IdP is correctly verifying AP identities, and there can potentially be multiple IdPs attesting to the same section of the identity space. Probably the best-known example of a third-party - identity provider is SSL certificates, where there are a large + identity provider is SSL/TLS certificates, where there are a large number of CAs all of whom can attest to any domain name. If an AP is authenticating via an authoritative IdP, then the RP does not need to explicitly configure trust in the IdP at all. The identity mechanism can directly verify that the IdP indeed made the relevant identity assertion (a function provided by the mechanisms in this document), and any assertion it makes about an identity for which it is authoritative is directly verifiable. Note that this does not mean that the IdP might not lie, but that is a trustworthiness judgement that the user can make at the time he looks @@ -967,25 +968,25 @@ WebRTC API specification [webrtc-api]. The WebRTC API specification also defines JavaScript interfaces that the calling application can use to specify which IdP to use. That API also provides access to the assertion-generation capability and the status of the validation process. 5.6.4. Binding Identity Assertions to JSEP Offer/Answer Transactions An identity assertion binds the user's identity (as asserted by the - IdP) to the SDP offer/exchange transaction and specifically to the - media. In order to achieve this, the PeerConnection must provide the - DTLS-SRTP fingerprint to be bound to the identity. This is provided - as a JavaScript object (also known as a dictionary or hash) with a - single "fingerprint" key, as shown below: + IdP) to the SDP offer/answer exchange and specifically to the media. + In order to achieve this, the PeerConnection must provide the DTLS- + SRTP fingerprint to be bound to the identity. This is provided as a + JavaScript object (also known as a dictionary or hash) with a single + "fingerprint" key, as shown below: { "fingerprint": [ { "algorithm": "sha-256", "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" }, { "algorithm": "sha-1", "digest": "74:E9:76:C8:19:...:F4:45:6B" } ] } @@ -999,23 +1000,23 @@ 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 treats it as an opaque value to be attested to. Thus, new parameters can be added to the assertion without modifying the IdP. 5.6.4.1. Carrying Identity Assertions Once an IdP has generated an assertion, it is attached to the SDP - message. This is done by adding a new identity attribute to the SDP. - The sole contents of this value are a base-64 encoded [RFC4648] - identity assertion. For example: + offer/answer message. This is done by adding a new identity + attribute to the SDP. The sole contents of this value are a + Base64-encoded [RFC4648] identity assertion. For example: v=0 o=- 1181923068 1181923196 IN IP4 ua1.example.com s=example1 c=IN IP4 ua1.example.com a=fingerprint:sha-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=identity:\ eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\ In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\ @@ -1025,30 +1026,32 @@ t=0 0 m=audio 6056 RTP/SAVP 0 a=sendrecv ... The identity attribute attests to all "a=fingerprint" attributes in the session description. It is therefore a session-level attribute. Multiple "a=fingerprint" values can be used to offer alternative certificates for a peer. The "a=identity" attribute MUST include all - fingerprint values that are included in "a=fingerprint" lines. + fingerprint values that are included in "a=fingerprint" lines of the + session description. The RP browser MUST verify that the in-use certificate for a DTLS connection is in the set of fingerprints returned from the IdP when verifying an assertion. 5.6.4.2. a=identity Attribute - The identity attribute is session level only. It contains an - identity assertion, encoded as a base-64 string [RFC4648]. + The identity attribute is a session-level attribute only. It + contains an identity assertion, encoded as a Base-64 string + [RFC4648]. The syntax of this SDP attribute is defined using Augmented BNF [RFC5234]: identity-attribute = "identity:" identity-assertion [ SP identity-extension *(";" [ SP ] identity-extension) ] identity-assertion = base64 base64 = 1*(ALPHA / DIGIT / "+" / "/" / "=" ) identity-extension = extension-att-name [ "=" extension-att-value ] @@ -1057,20 +1060,25 @@ ; byte-string from [RFC4566] omitting ";" No extensions are defined for this attribute. The identity assertion is a JSON [RFC8259] encoded dictionary that contains two values. The "assertion" attribute contains an opaque string that is consumed by the IdP. The "idp" attribute is a dictionary with one or two further values that identify the IdP, as described in Section 5.6.5. + An identity assertion as defined in this document relies on the value + of "a=fingerprint" attributes, but this does not preclude the + definition of alternative means of binding an assertion to the + identity of a peer. + The semantics of multiple identity attributes are undefined. Implementations SHOULD only include a single identity attribute in an offer and relying parties MAY elect to ignore all but the first identity attribute. 5.6.5. Determining the IdP URI In order to ensure that the IdP is under control of the domain owner rather than someone who merely has an account on the domain owner's server (e.g., in shared hosting scenarios), the IdP JavaScript is @@ -1183,21 +1191,21 @@ "protocol": "bogus" }, "assertion": "{\"identity\":\"bob@example.org\", \"contents\":\"abcdefghijklmnopqrstuvwyz\", \"signature\":\"010203040506\"}" } Figure 5: Example assertion For use in signaling, the assertion is serialized into JSON, - base64-encoded [RFC4648], and used as the value of the "a=identity" + Base64-encoded [RFC4648], and used as the value of the "a=identity" attribute. 5.6.7. Managing User Login In order to generate an identity assertion, the IdP needs proof of the user's identity. It is common practice to authenticate users (using passwords or multi-factor authentication), then use Cookies [RFC6265] or HTTP authentication [RFC7617] for subsequent exchanges. The IdP proxy is able to access cookies, HTTP authentication or other @@ -1311,26 +1319,26 @@ malicious identity provider can only do so by verifying peer credentials directly, e.g., by checking the peer's fingerprint against a value delivered out of band. In order to protect against malicious content JavaScript, that JavaScript MUST NOT be allowed to have direct access to---or perform computations with---DTLS keys. For instance, if content JS were able to compute digital signatures, then it would be possible for content JS to get an identity assertion for a browser's generated key and then use that assertion plus a signature by the key to authenticate a - call protected under an ephemeral DH key controlled by the content - JS, thus violating the security guarantees otherwise provided by the - IdP mechanism. Note that it is not sufficient merely to deny the - content JS direct access to the keys, as some have suggested doing - with the WebCrypto API. [webcrypto]. The JS must also not be - allowed to perform operations that would be valid for a DTLS + call protected under an ephemeral Diffie-Hellman (DH) key controlled + by the content JS, thus violating the security guarantees otherwise + provided by the IdP mechanism. Note that it is not sufficient merely + to deny the content JS direct access to the keys, as some have + suggested doing with the WebCrypto API [webcrypto]. The JS must also + not be allowed to perform operations that would be valid for a DTLS endpoint. By far the safest approach is simply to deny the ability to perform any operations that depend on secret information associated with the key. Operations that depend on public information, such as exporting the public key are of course safe. 6.2. Privacy The requirements in this document are intended to allow: o Users to participate in calls without revealing their location. @@ -1535,31 +1543,35 @@ Type of Attribute: session-level Charset Considerations: This attribute is not subject to the charset attribute. Purpose: This attribute carries an identity assertion, binding an identity to the transport-level security session. Appropriate Values: See Section 5.6.4.2 of RFCXXXX [[Editor Note: - This document. + This document.]] + + Mux Category: NORMAL. 8. Acknowledgements Bernard Aboba, Harald Alvestrand, Richard Barnes, Dan Druta, Cullen Jennings, Hadriel Kaplan, Matthew Kaufman, Jim McEachern, Martin Thomson, Magnus Westerland. Matthew Kaufman provided the UI material in Section 5.5. 9. Changes + [RFC Editor: Please remove this section prior to publication.] + 9.1. Changes since -11 Update discussion of IdP security model Replace "domain name" with RFC 3986 Authority Clean up discussion of how to generate IdP URI. Remove obsolete text about null cipher suites.