--- 1/draft-ietf-rtcweb-security-arch-16.txt 2018-11-17 15:13:10.425593318 -0800 +++ 2/draft-ietf-rtcweb-security-arch-17.txt 2018-11-17 15:13:10.513595436 -0800 @@ -1,18 +1,18 @@ RTCWEB E. Rescorla Internet-Draft RTFM, Inc. -Intended status: Standards Track October 22, 2018 -Expires: April 25, 2019 +Intended status: Standards Track November 17, 2018 +Expires: May 21, 2019 WebRTC Security Architecture - draft-ietf-rtcweb-security-arch-16 + draft-ietf-rtcweb-security-arch-17 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 https://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 April 25, 2019. + This Internet-Draft will expire on May 21, 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -65,24 +65,23 @@ 3.1. Authenticated Entities . . . . . . . . . . . . . . . . . 5 3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . 6 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 8 4.2. Media Consent Verification . . . . . . . . . . . . . . . 10 4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . 11 4.4. Communications and Consent Freshness . . . . . . . . . . 11 5. SDP Identity Attribute . . . . . . . . . . . . . . . . . . . 12 5.1. Offer/Answer Considerations . . . . . . . . . . . . . . . 13 5.1.1. Generating the Initial SDP Offer . . . . . . . . . . 13 - 5.1.2. Answerer Processing of SDP Offer . . . . . . . . . . 14 - 5.1.3. Generating of SDP Answer . . . . . . . . . . . . . . 14 - 5.1.4. Offerer Processing of SDP Answer . . . . . . . . . . 14 - 5.1.5. Modifying the Session . . . . . . . . . . . . . . . . 14 + 5.1.2. Generating of SDP Answer . . . . . . . . . . . . . . 14 + 5.1.3. Processing an SDP Offer or Answer . . . . . . . . . . 14 + 5.1.4. Modifying the Session . . . . . . . . . . . . . . . . 14 6. Detailed Technical Description . . . . . . . . . . . . . . . 14 6.1. Origin and Web Security Issues . . . . . . . . . . . . . 14 6.2. Device Permissions Model . . . . . . . . . . . . . . . . 15 6.3. Communications Consent . . . . . . . . . . . . . . . . . 17 6.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 17 6.5. Communications Security . . . . . . . . . . . . . . . . . 18 7. Web-Based Peer Authentication . . . . . . . . . . . . . . . . 20 7.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . . . 21 7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 22 7.3. Items for Standardization . . . . . . . . . . . . . . . . 24 @@ -87,47 +86,48 @@ 7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 22 7.3. Items for Standardization . . . . . . . . . . . . . . . . 24 7.4. Binding Identity Assertions to JSEP Offer/Answer Transactions . . . . . . . . . . . . . . . . . . . . . . 24 7.4.1. Carrying Identity Assertions . . . . . . . . . . . . 25 7.5. Determining the IdP URI . . . . . . . . . . . . . . . . . 26 7.5.1. Authenticating Party . . . . . . . . . . . . . . . . 27 7.5.2. Relying Party . . . . . . . . . . . . . . . . . . . . 27 7.6. Requesting Assertions . . . . . . . . . . . . . . . . . . 27 7.7. Managing User Login . . . . . . . . . . . . . . . . . . . 28 + 8. Verifying Assertions . . . . . . . . . . . . . . . . . . . . 29 8.1. Identity Formats . . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 - 9.1. Communications Security . . . . . . . . . . . . . . . . . 30 + 9.1. Communications Security . . . . . . . . . . . . . . . . . 31 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 32 9.4. IdP Authentication Mechanism . . . . . . . . . . . . . . 33 9.4.1. PeerConnection Origin Check . . . . . . . . . . . . . 33 9.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . . 34 9.4.3. Privacy of IdP-generated identities and the hosting site . . . . . . . . . . . . . . . . . . . . . . . . 34 9.4.4. Security of Third-Party IdPs . . . . . . . . . . . . 34 - 9.4.4.1. Confusable Characters . . . . . . . . . . . . . . 34 + 9.4.4.1. Confusable Characters . . . . . . . . . . . . . . 35 9.4.5. Web Security Feature Interactions . . . . . . . . . . 35 9.4.5.1. Popup Blocking . . . . . . . . . . . . . . . . . 35 9.4.5.2. Third Party Cookies . . . . . . . . . . . . . . . 35 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 12.1. Changes since -15 . . . . . . . . . . . . . . . . . . . 36 12.2. Changes since -11 . . . . . . . . . . . . . . . . . . . 36 - 12.3. Changes since -10 . . . . . . . . . . . . . . . . . . . 36 + 12.3. Changes since -10 . . . . . . . . . . . . . . . . . . . 37 12.4. Changes since -06 . . . . . . . . . . . . . . . . . . . 37 12.5. Changes since -05 . . . . . . . . . . . . . . . . . . . 37 12.6. Changes since -03 . . . . . . . . . . . . . . . . . . . 37 - 12.7. Changes since -03 . . . . . . . . . . . . . . . . . . . 37 - 12.8. Changes since -02 . . . . . . . . . . . . . . . . . . . 37 + 12.7. Changes since -03 . . . . . . . . . . . . . . . . . . . 38 + 12.8. Changes since -02 . . . . . . . . . . . . . . . . . . . 38 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 13.1. Normative References . . . . . . . . . . . . . . . . . . 38 13.2. Informative References . . . . . . . . . . . . . . . . . 41 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42 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 @@ -593,40 +593,36 @@ SDP session that contains an SDP "identity" attribute. 5.1.1. Generating the Initial SDP Offer When an offerer sends an offer, in order to provide its identity assertion to the peer, it includes an 'identity' attribute in the offer. In addition, the offerer includes one or more SDP 'fingerprint' attributes. The 'identity' attribute MUST be bound to all the 'fingerprint' attributes in the session description. -5.1.2. Answerer Processing of SDP Offer - - When an answerer receives an offer that contains an 'identity' - attribute, the answerer can use the the attribute information to - contact the IdP, and verify the identity of the peer. If the - identity verification fails, the answerer MUST reject the offer. - -5.1.3. Generating of SDP Answer +5.1.2. Generating of SDP Answer If the answerer elects to include an 'identity' attribute, it follows the same steps as those in Section 5.1.1. The answerer can choose to include or omit an 'identity' attribute independently, regardless of whether the offerer did so. -5.1.4. Offerer Processing of SDP Answer +5.1.3. Processing an SDP Offer or Answer - Offer processing of an 'identity' attribute is the same as that - described in Section 5.1.2. + When an endpoint receives an offer or answer that contains an + 'identity' attribute, the answerer can use the the attribute + information to contact the IdP, and verify the identity of the peer. + If the identity verification fails, the answerer MUST discard the + offer or answer as malformed. -5.1.5. Modifying the Session +5.1.4. Modifying the Session When modifying a session, if the set of fingerprints is unchanged, then the sender MAY send the same 'identity' attribute. In this case, the established identity SHOULD be applied to existing DTLS connections as well as new connections established using one of those fingerprints. Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1 requires that each media section use the same set of fingerprints for every media section. If the set of fingerprints changes, then the sender MUST either send @@ -832,26 +829,28 @@ All media channels MUST be secured via SRTP and SRTCP. Media traffic MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is, implementations MUST NOT negotiate cipher suites with NULL encryption modes. DTLS-SRTP MUST be offered for every media channel. WebRTC implementations MUST NOT offer SDP Security Descriptions [RFC4568] or 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 + All Implementations MUST implement DTLS 1.2 with the + TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 + curve [FIPS186]. Earlier drafts of this specification required DTLS + 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and + at the time of this writing some implementations do not support DTLS + 1.2; endpoints which support only DTLS 1.2 might encounter + interoperability issues. 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 (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. @@ -1344,46 +1343,54 @@ "contents": "{\"fingerprint\":[ ... ]}" } Figure 6: Example verification result 8.1. Identity Formats The identity provided from the IdP to the RP browser MUST consist of a string representing the user's identity. This string is in the form "@", where "user" consists of any character except - '@', and domain is an internationalized domain name [RFC5890]. + '@', and domain is an internationalized domain name [RFC5890] encoded + as a sequence of U-labels. The PeerConnection API MUST check this string as follows: 1. If the domain portion of the string is equal to the domain name of the IdP proxy, then the assertion is valid, as the IdP is authoritative for this domain. Comparison of domain names is done using the label equivalence rule defined in Section 2.3.2.4 of [RFC5890]. 2. If the domain portion of the string is not equal to the domain name of the IdP proxy, then the PeerConnection object MUST reject the assertion unless: 1. the IdP domain is trusted as an acceptable third-party IdP; and 2. local policy is configured to trust this IdP domain for the domain portion of the identity string. - Sites that have identities that do not fit into the RFC822 style (for - instance, identifiers that are simple numeric values, or values that - contain '@' characters) SHOULD convert them to this form by escaping - illegal characters and appending their IdP domain (e.g., - user%40133@identity.example.com), thus ensuring that they are - authoritative for the identity. + Any "@" or "%" characters in the "user" portion of the identity MUST + be escaped according to the "Percent-Encoding" rules defined in + Section 2.1 of [RFC3986]. Characters other than "@" and "%" MUST NOT + be percent-encoded. For example, with a user of "user@133" and a + domain of "identity.example.com", the resulting string will be + encoded as "user%40133@identity.example.com". + + Implementations are cautioned to take care when displaying user + identities containing escaped "@" characters. If such characters are + unescaped prior to display, implementations MUST distinguish between + the domain of the IdP proxy and any domain that might be implied by + the portion of the portion that appears after the escaped "@" + sign. 9. Security Considerations Much of the security analysis of this problem is contained in [I-D.ietf-rtcweb-security] or in the discussion of the particular issues above. In order to avoid repetition, this section focuses on (a) residual threats that are not addressed by this document and (b) threats produced by failure/misbehavior of one of the components in the system. @@ -1881,22 +1887,22 @@ Bergkvist, Burnett, Jennings, Narayanan, "WebRTC 1.0: Real-time Communication Between Browsers", October 2011. Available at http://dev.w3.org/2011/webrtc/editor/ webrtc.html 13.2. Informative References [I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C., and E. Rescorla, "JavaScript - Session Establishment Protocol", draft-ietf-rtcweb-jsep-24 - (work in progress), October 2017. + Session Establishment Protocol", draft-ietf-rtcweb-jsep-25 + (work in progress), October 2018. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, .