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