WebRTC Security Architecture
draft-ietf-rtcweb-security-arch-20
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-01-14
|
20 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-06-29
|
20 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-03-16
|
20 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2019-10-30
|
20 | (System) | RFC Editor state changed to REF from EDIT |
2019-08-16
|
20 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-08-15
|
20 | (System) | RFC Editor state changed to MISSREF from EDIT |
2019-08-15
|
20 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-08-07
|
20 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-08-06
|
20 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2019-08-01
|
20 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Taylor Yu was marked no-response |
2019-07-25
|
20 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-07-25
|
20 | (System) | IANA Action state changed to In Progress from On Hold |
2019-07-24
|
20 | (System) | IANA Action state changed to On Hold from In Progress |
2019-07-22
|
20 | (System) | RFC Editor state changed to MISSREF |
2019-07-22
|
20 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-07-22
|
20 | (System) | Announcement was received by RFC Editor |
2019-07-22
|
20 | (System) | IANA Action state changed to In Progress |
2019-07-22
|
20 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-20.txt |
2019-07-22
|
20 | (System) | New version approved |
2019-07-22
|
19 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-07-22
|
19 | Cindy Morgan | IESG has approved the document |
2019-07-22
|
19 | Cindy Morgan | Closed "Approve" ballot |
2019-07-22
|
20 | (System) | Request for posting confirmation emailed to previous authors: Eric Rescorla |
2019-07-22
|
20 | Eric Rescorla | Uploaded new revision |
2019-07-22
|
19 | Cindy Morgan | Ballot approval text was generated |
2019-07-22
|
19 | Adam Roach | IESG state changed to Approved-announcement to be sent from IESG Evaluation::External Party |
2019-07-22
|
19 | Adam Roach | RFC Editor Note was changed |
2019-07-22
|
19 | Adam Roach | RFC Editor Note for ballot was generated |
2019-07-22
|
19 | Adam Roach | RFC Editor Note for ballot was generated |
2019-07-22
|
19 | Adam Roach | Last call announcement was generated |
2019-07-12
|
19 | Benjamin Kaduk | [Ballot comment] Thanks for addressing my Discuss points! I'll leave the original Comment section below, as I note that at least one issue remains (I … [Ballot comment] Thanks for addressing my Discuss points! I'll leave the original Comment section below, as I note that at least one issue remains (I spot-checked the SDP Offer/Answer reference, that still points to RFC 6454, which is "the Web Origin Concept". I didn't make any attempt to trim points that did get addressed. Section 3 (My comment about TCB and the other browser from the companion document is probably relevant here, too.) Section 4.1 This message is sent to the signaling server, e.g., by XMLHttpRequest [XmlHttpRequest] or by WebSockets [RFC6455], preferably over TLS [RFC5246]. The signaling server processes the message from Alice's This is the optimistic "best security" case, and we already say we're talking to the signaling server over HTTPS, so it should be safe to just say "over TLS" and drop the "preferably". (Also, s/5246/8446.) 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. [...] I think I'm confused. We're displaying trusted browser chrome based on an assertion from some IdP that we have no relationship with and no reason to trust? Section 4.3 Once the ICE checks have completed [more specifically, once some ICE checks have completed], [...] nit: that's not really more specific. Maybe "Once the requisite ICE checks have completed"? Section 5 I see that the 4566 includes the pad characters, though sometimes we will mention explicitly whether they are or are not included. Note that long lines in the example are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line and the carriage return that follows shall be ignored. leading whitespace, too, right? Section 5.1 This section defines the SDP Offer/Answer [RFC6454] considerations for the SDP 'identity' attribute. 6454 is "the Web Origin Concept"; presumably this is supposed to be 4566 (or 3264?). Section 5.1.3 I feel like we need some text here about the (non?)trustworthiness of the IdP. Section 5.1.4 I'm a bit confused at what's going on here. Is "MAY send the same" supposed to prevent changing it? If I don't send it, does that identity continue to apply to the existing DTLS connections but not any new ones generated by the session modification? Am I allowed to send a different one? 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. nit: is this "each media section"/"every media section" redundant? Section 6.1 Also note that the security architecture depends on the keying material not being available to move between origins. But, it is assumed that the identity assertion can be passed to anyone that the page cares to. There may be some (weak) privacy considerations if this is literally anyone, since it would allow some observers (with weird abilities/restrictions) to associate "real" identities with keys in a way that they couldn't otherwise do. Section 6.2 Because HTTP origins cannot be securely established against network attackers, implementations MUST NOT allow the setting of permanent access permissions for HTTP origins. Implementations MUST refuse all permissions grants for HTTP origins. Just to check: this last sentence applies for one-time requets, too? The semantics of this request are that the media stream from the camera and microphone will only be routed through a connection which has been cryptographically verified (through the IdP mechanism or an X.509 certificate in the DTLS-SRTP handshake) as being associated with the stated identity. [...] Does this need to be an exhaustive list or can we leave it open-ended? Also, it may be appropriate to mention some concept of "IdP trusted to authenticate the stated identity". API Requirement: The API MUST provide a mechanism for the requesting JS to relinquish the ability to see or modify the media (e.g., via MediaStream.record()). [...] Do we need to say anything about that state transition being visible to the peer, here? UI Requirement: If the UI indication of camera/microphone use are [...] camera and microphone input when the indication is hidden. [Note: this may not be necessary in systems that are non-windows-based but that have good notifications support, such as phones.] nit: s/windows/window/? Clients MAY permit the formation of data channels without any direct user approval. Because sites can always tunnel data through the server, further restrictions on the data channel do not provide any additional security. (though see Section 6.3 for a related issue). Is there anything to say about why clients might not opt to do so (and what such approval might look like)? (My comments about "verified user" including the IdP in some way will apply here as well.) Section 6.3 While continuing consent is required, the ICE [RFC8445]; Section 10 keepalives use STUN Binding Indications which are one-way and therefore not sufficient. The current WG consensus is to use ICE Is the "the current WG consensus" language going to age well? Binding Requests for continuing consent freshness. ICE already requires that implementations respond to such requests, so this approach is maximally compatible. A separate document will profile the ICE timers to be used; see [RFC7675]. Is there a WIP draft for this separate document? Section 6.4 API Requirement: The API MUST provide a mechanism to allow the JS to suppress ICE negotiation (though perhaps to allow candidate gathering) until the user has decided to answer the call [note: determining when the call has been answered is a question for the JS.] This enables a user to prevent a peer from learning their IP address if they elect not to answer a call and also from learning whether the user is online. nit: maybe make it more clear that this only applies for incoming calls? Section 6.5 Media traffic MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is, implementations MUST NOT negotiate cipher suites with NULL encryption modes. [...] It's not clear to me that the "that is" reflects a strict equivalence; would "in particular" be more appropriate? (Also, "cipher suite" is a DTLS term, but do we want to disambiguate explicitly?) [obligatory "Perfect Forward Secrecy" vs. "Forward Secrecy" note] Implementations MUST NOT implement DTLS renegotiation and MUST reject it with a "no_renegotiation" alert if offered. "MUST NOT implement" isn't really something that 2119 language can enforce; "MUST NOT use" is the best we can get. Endpoints MUST NOT implement TLS False Start [RFC7918]. (7918 doesn't claim to be applicable to DTLS anyway) API Requirement: Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin. (This avoids creating a super-cookie.) nit: might be appropriate to note why we care about a super-cookie (and what it is) * 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. I'm not sure I see anywhere that we allow the usage of null ciphers. Section 7 Recently, a number of Web-based identity technologies (OAuth, Facebook Connect etc.) have been developed. While the details vary, what these technologies share is that they have a Web-based (i.e., HTTP/HTTPS) identity provider which attests to your identity. For instance, if I have an account at example.org, I could use the example.org identity provider to prove to others that I was alice@example.org. [...] I agree with Alissa that the first person is not needed here. Section 7.1 Third-Party: IdPs which don't have control of their section of the [...] identity space. Probably the best-known example of a third-party identity provider is SSL/TLS certificates, where there are a large number of CAs all of whom can attest to any domain name. This probably needs some qualifier, given recent developments with CAA and similar mechanisms. 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 The RP still needs to establish somehow that the IdP in use is in fact an authoritative IdP, though! Section 7.2 In order to provide security without trusting the calling site, the PeerConnection component of the browser must interact directly with the IdP. The details of the mechanism are described in the W3C API specification, but the general idea is that the PeerConnection A reference to that W3C API spec might be handy. Section 7.3 There are two parts to this work: o The precise information from the signaling message that must be cryptographically bound to the user's identity and a mechanism for carrying assertions in JSEP messages. This is specified in Section 7.4. nit: the grammar is a bit weird here, as the "information from the signaling message" isn't really a part of this work, but rather the specification for what information that is. Section 7.4 The indentation of the line with "}, {" is a bit confusing. This object is encoded in a JSON [RFC8259] string for passing to the IdP. The identity assertion returned by the IdP, which is encoded in I'm a little confused what this "encoded in a JSON string" is supposed to mean. 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. The IdP probably wants to know enough about its structure to not turn into a signing oracle for other protocols, though. Section 7.4.1 (RFC 8259 JSON inherently is UTF-8, so maybe we don't need to mention that.) It's a little surprising to see sha-1 fingerprint in use (since "examples are recommendations"), though I didn't find anything that would actually formally deprecate such usage yet. Note that long lines in the example are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line and the carriage return that follows shall be ignored. leading whitespace, too, right? Section 7.5.2 (Still need to say how it's know than authoritative assertions are in fact authoritative for what they claim.) Section 7.6 The input to identity assertion is the JSON-encoded object described in Section 7.4 that contains the set of certificate fingerprints the browser intends to use. This string is treated as opaque from the perspective of the IdP. (IdP still doesn't want to become a signing oracle.) For use in signaling, the assertion is serialized into JSON, Base64-encoded [RFC4648], and used as the value of the "identity" attribute. nit: it's unclear that "serialized into JSON" adds any value, since the thing is defined to be a JSON object. Section 7.7 I think that the framing of HTTP Basic (7617) here is not great. RFC 7235 might be a better link for HTTP Authentication in general, and of course there are mechanisms that don't include sending the password in plaintext, like SCRAM (RFC7804). Section 8 The IdP proxy verifies the assertion. Depending on the identity protocol, the proxy might contact the IdP server or other servers. For instance, an OAuth-based protocol will likely require using the IdP as an oracle, whereas with a signature-based scheme might be able to verify the assertion without contacting the IdP, provided that it has cached the relevant public key. IMPORTANT: Do we need a freshness property for the assertion? Some of these schemes do not provide freshness. Figure 6 shows an example response formatted as JSON for illustrative purposes. (Doesn't the W3C API spec need to say how the response is formatted? Is the JSON formatting actually "illustrative" then, or is this just an example output?) Section 8.1 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: Reading closely, I think this is supposed to be "unless either", but it's easy to assume it should be read as "unless both", so I think clarification is in order. Any "@" or "%" characters in the "user" portion of the identity MUST be escaped according to the "Percent-Encoding" rules defined in We just said in the first paragraph that "user" has "any character except '@'", so this is a bit redundant. Section 9.1 Users who wish to assure themselves of security against a 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. I suppose an "untrustworthy" IdP is basically a malicious one, though there are perhaps some subtleties that could be distinguished here. 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 Diffie-Hellman (DH) key controlled by the content JS, thus violating the security guarantees otherwise provided by the IdP mechanism. I don't think I fully understand the scenario described in this last sentence. Is "compute digital signatures" supposed to be with some specific secret key, and/or is "a browser's generated key" one that is covered under the fingerprint in the IdP assertion? Section 9.2 Otherwise, the other side will learn linkable information. nit: "linkable information that would allow them to correlate the browser across multiple calls". Section 9.3 Consider the case of a call center which accepts calls via WebRTC. An attacker proxies the call center's front-end and arranges for multiple clients to initiate calls to the call center. Note that this requires user consent in many cases but because the data channel does not need consent, he can use that directly. I think I'm missing a step here. How is the attacker using the data channel directly when the point is to get the multiple browsers to send the data on the data channel? Muxing multiple media flows over a single transport makes it harder to individually suppress a single flow by denying ICE keepalives. Either media-level (RTCP) mechanisms must be used or the implementation must deny responses entirely, thus terminating the call. nit: "must be used to suppress the misbehaving flow", I think. Section 9.4.3 The "origin" field of the signature request can be used to check that the user has agreed to disclose their identity to the calling site; because it is supplied by the PeerConnection it can be trusted to be correct. I don't see an "origin" field in the signature request; is this supposed to be the "domain"? Section 9.4.5.1 nit: it might be friendlier to the reader to prefix this with "When popup blocking is in use, ". Section 13.2 It's perhaps debatable that JSEP is only an informative reference. |
2019-07-12
|
19 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-07-12
|
19 | Adam Roach | IESG state changed to IESG Evaluation::External Party from IESG Evaluation::AD Followup |
2019-07-12
|
19 | Adam Roach | Waiting until July 22 to put in RFC Editor Queue, per https://mailarchive.ietf.org/arch/msg/rtcweb/n-WNLc5_9qAITUECgxJpe6C__hY |
2019-07-12
|
19 | Alexey Melnikov | [Ballot comment] Thank you for addressing my DISCUSS. |
2019-07-12
|
19 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
2019-07-07
|
19 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-07-07
|
19 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-07-07
|
19 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-19.txt |
2019-07-07
|
19 | (System) | New version approved |
2019-07-07
|
19 | (System) | Request for posting confirmation emailed to previous authors: Eric Rescorla |
2019-07-07
|
19 | Eric Rescorla | Uploaded new revision |
2019-03-10
|
18 | Tim Chown | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Tim Chown. Sent review to list. |
2019-03-07
|
18 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-03-07
|
18 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-03-06
|
18 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2019-03-06
|
18 | Benjamin Kaduk | [Ballot discuss] The question of when an IdP is trustworthy, whether at all (even for "authoritative" IdPs) or for a specific user, is a pretty … [Ballot discuss] The question of when an IdP is trustworthy, whether at all (even for "authoritative" IdPs) or for a specific user, is a pretty core topic for the identity assertion scheme presented here. These topics do get explained in localized sections of the document, but there seem to be other portions of the text that do not really acknowledge the risks. I've tried to note these in the COMMENT section (though having finished reading the document, perhaps I am overzealous about determination that an authoritative IdP is indeed authoritative). I also think that we need to be more careful about having the IdP know the semantics of what it's signing (or otherwise attesting to), so that it does not turn into a signing oracle, etc.. The "Modifying the Session" treatment for the SDP "identity" attribute seems incompletely specified. I'm a bit unclear about how the port in the IdP URI's Authority (Section 7.5) would get discovered. If it can be remotely supplied, there may be risks in just trusting blindly whatever value is received. It seems like there are some unstated privacy considerations in allowing the IdP proxy to automatically generate an assertion (that reveals the user's identity) at the request of javascript from the calling application, as described in Section 7.7. Section 9.4 talks about how the IdP is attesting to the binding of the user identified in the assertion with the key fingerprints, but in Sections 7.4 and 7.6 we claim that this assertion is "opaque to the IdP"; these statements appear to be in conflict with each other. |
2019-03-06
|
18 | Benjamin Kaduk | [Ballot comment] Section 3 (My comment about TCB and the other browser from the companion document is probably relevant here, too.) Section 4.1 This … [Ballot comment] Section 3 (My comment about TCB and the other browser from the companion document is probably relevant here, too.) Section 4.1 This message is sent to the signaling server, e.g., by XMLHttpRequest [XmlHttpRequest] or by WebSockets [RFC6455], preferably over TLS [RFC5246]. The signaling server processes the message from Alice's This is the optimistic "best security" case, and we already say we're talking to the signaling server over HTTPS, so it should be safe to just say "over TLS" and drop the "preferably". (Also, s/5246/8446.) 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. [...] I think I'm confused. We're displaying trusted browser chrome based on an assertion from some IdP that we have no relationship with and no reason to trust? Section 4.3 Once the ICE checks have completed [more specifically, once some ICE checks have completed], [...] nit: that's not really more specific. Maybe "Once the requisite ICE checks have completed"? Section 5 I see that the 4566 includes the pad characters, though sometimes we will mention explicitly whether they are or are not included. Note that long lines in the example are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line and the carriage return that follows shall be ignored. leading whitespace, too, right? Section 5.1 This section defines the SDP Offer/Answer [RFC6454] considerations for the SDP 'identity' attribute. 6454 is "the Web Origin Concept"; presumably this is supposed to be 4566 (or 3264?). Section 5.1.3 I feel like we need some text here about the (non?)trustworthiness of the IdP. Section 5.1.4 I'm a bit confused at what's going on here. Is "MAY send the same" supposed to prevent changing it? If I don't send it, does that identity continue to apply to the existing DTLS connections but not any new ones generated by the session modification? Am I allowed to send a different one? 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. nit: is this "each media section"/"every media section" redundant? Section 6.1 Also note that the security architecture depends on the keying material not being available to move between origins. But, it is assumed that the identity assertion can be passed to anyone that the page cares to. There may be some (weak) privacy considerations if this is literally anyone, since it would allow some observers (with weird abilities/restrictions) to associate "real" identities with keys in a way that they couldn't otherwise do. Section 6.2 Because HTTP origins cannot be securely established against network attackers, implementations MUST NOT allow the setting of permanent access permissions for HTTP origins. Implementations MUST refuse all permissions grants for HTTP origins. Just to check: this last sentence applies for one-time requets, too? The semantics of this request are that the media stream from the camera and microphone will only be routed through a connection which has been cryptographically verified (through the IdP mechanism or an X.509 certificate in the DTLS-SRTP handshake) as being associated with the stated identity. [...] Does this need to be an exhaustive list or can we leave it open-ended? Also, it may be appropriate to mention some concept of "IdP trusted to authenticate the stated identity". API Requirement: The API MUST provide a mechanism for the requesting JS to relinquish the ability to see or modify the media (e.g., via MediaStream.record()). [...] Do we need to say anything about that state transition being visible to the peer, here? UI Requirement: If the UI indication of camera/microphone use are [...] camera and microphone input when the indication is hidden. [Note: this may not be necessary in systems that are non-windows-based but that have good notifications support, such as phones.] nit: s/windows/window/? Clients MAY permit the formation of data channels without any direct user approval. Because sites can always tunnel data through the server, further restrictions on the data channel do not provide any additional security. (though see Section 6.3 for a related issue). Is there anything to say about why clients might not opt to do so (and what such approval might look like)? (My comments about "verified user" including the IdP in some way will apply here as well.) Section 6.3 While continuing consent is required, the ICE [RFC8445]; Section 10 keepalives use STUN Binding Indications which are one-way and therefore not sufficient. The current WG consensus is to use ICE Is the "the current WG consensus" language going to age well? Binding Requests for continuing consent freshness. ICE already requires that implementations respond to such requests, so this approach is maximally compatible. A separate document will profile the ICE timers to be used; see [RFC7675]. Is there a WIP draft for this separate document? Section 6.4 API Requirement: The API MUST provide a mechanism to allow the JS to suppress ICE negotiation (though perhaps to allow candidate gathering) until the user has decided to answer the call [note: determining when the call has been answered is a question for the JS.] This enables a user to prevent a peer from learning their IP address if they elect not to answer a call and also from learning whether the user is online. nit: maybe make it more clear that this only applies for incoming calls? Section 6.5 Media traffic MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is, implementations MUST NOT negotiate cipher suites with NULL encryption modes. [...] It's not clear to me that the "that is" reflects a strict equivalence; would "in particular" be more appropriate? (Also, "cipher suite" is a DTLS term, but do we want to disambiguate explicitly?) [obligatory "Perfect Forward Secrecy" vs. "Forward Secrecy" note] Implementations MUST NOT implement DTLS renegotiation and MUST reject it with a "no_renegotiation" alert if offered. "MUST NOT implement" isn't really something that 2119 language can enforce; "MUST NOT use" is the best we can get. Endpoints MUST NOT implement TLS False Start [RFC7918]. (7918 doesn't claim to be applicable to DTLS anyway) API Requirement: Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin. (This avoids creating a super-cookie.) nit: might be appropriate to note why we care about a super-cookie (and what it is) * 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. I'm not sure I see anywhere that we allow the usage of null ciphers. Section 7 Recently, a number of Web-based identity technologies (OAuth, Facebook Connect etc.) have been developed. While the details vary, what these technologies share is that they have a Web-based (i.e., HTTP/HTTPS) identity provider which attests to your identity. For instance, if I have an account at example.org, I could use the example.org identity provider to prove to others that I was alice@example.org. [...] I agree with Alissa that the first person is not needed here. Section 7.1 Third-Party: IdPs which don't have control of their section of the [...] identity space. Probably the best-known example of a third-party identity provider is SSL/TLS certificates, where there are a large number of CAs all of whom can attest to any domain name. This probably needs some qualifier, given recent developments with CAA and similar mechanisms. 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 The RP still needs to establish somehow that the IdP in use is in fact an authoritative IdP, though! Section 7.2 In order to provide security without trusting the calling site, the PeerConnection component of the browser must interact directly with the IdP. The details of the mechanism are described in the W3C API specification, but the general idea is that the PeerConnection A reference to that W3C API spec might be handy. Section 7.3 There are two parts to this work: o The precise information from the signaling message that must be cryptographically bound to the user's identity and a mechanism for carrying assertions in JSEP messages. This is specified in Section 7.4. nit: the grammar is a bit weird here, as the "information from the signaling message" isn't really a part of this work, but rather the specification for what information that is. Section 7.4 The indentation of the line with "}, {" is a bit confusing. This object is encoded in a JSON [RFC8259] string for passing to the IdP. The identity assertion returned by the IdP, which is encoded in I'm a little confused what this "encoded in a JSON string" is supposed to mean. 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. The IdP probably wants to know enough about its structure to not turn into a signing oracle for other protocols, though. Section 7.4.1 (RFC 8259 JSON inherently is UTF-8, so maybe we don't need to mention that.) It's a little surprising to see sha-1 fingerprint in use (since "examples are recommendations"), though I didn't find anything that would actually formally deprecate such usage yet. Note that long lines in the example are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line and the carriage return that follows shall be ignored. leading whitespace, too, right? Section 7.5.2 (Still need to say how it's know than authoritative assertions are in fact authoritative for what they claim.) Section 7.6 The input to identity assertion is the JSON-encoded object described in Section 7.4 that contains the set of certificate fingerprints the browser intends to use. This string is treated as opaque from the perspective of the IdP. (IdP still doesn't want to become a signing oracle.) For use in signaling, the assertion is serialized into JSON, Base64-encoded [RFC4648], and used as the value of the "identity" attribute. nit: it's unclear that "serialized into JSON" adds any value, since the thing is defined to be a JSON object. Section 7.7 I think that the framing of HTTP Basic (7617) here is not great. RFC 7235 might be a better link for HTTP Authentication in general, and of course there are mechanisms that don't include sending the password in plaintext, like SCRAM (RFC7804). Section 8 The IdP proxy verifies the assertion. Depending on the identity protocol, the proxy might contact the IdP server or other servers. For instance, an OAuth-based protocol will likely require using the IdP as an oracle, whereas with a signature-based scheme might be able to verify the assertion without contacting the IdP, provided that it has cached the relevant public key. IMPORTANT: Do we need a freshness property for the assertion? Some of these schemes do not provide freshness. Figure 6 shows an example response formatted as JSON for illustrative purposes. (Doesn't the W3C API spec need to say how the response is formatted? Is the JSON formatting actually "illustrative" then, or is this just an example output?) Section 8.1 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: Reading closely, I think this is supposed to be "unless either", but it's easy to assume it should be read as "unless both", so I think clarification is in order. Any "@" or "%" characters in the "user" portion of the identity MUST be escaped according to the "Percent-Encoding" rules defined in We just said in the first paragraph that "user" has "any character except '@'", so this is a bit redundant. Section 9.1 Users who wish to assure themselves of security against a 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. I suppose an "untrustworthy" IdP is basically a malicious one, though there are perhaps some subtleties that could be distinguished here. 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 Diffie-Hellman (DH) key controlled by the content JS, thus violating the security guarantees otherwise provided by the IdP mechanism. I don't think I fully understand the scenario described in this last sentence. Is "compute digital signatures" supposed to be with some specific secret key, and/or is "a browser's generated key" one that is covered under the fingerprint in the IdP assertion? Section 9.2 Otherwise, the other side will learn linkable information. nit: "linkable information that would allow them to correlate the browser across multiple calls". Section 9.3 Consider the case of a call center which accepts calls via WebRTC. An attacker proxies the call center's front-end and arranges for multiple clients to initiate calls to the call center. Note that this requires user consent in many cases but because the data channel does not need consent, he can use that directly. I think I'm missing a step here. How is the attacker using the data channel directly when the point is to get the multiple browsers to send the data on the data channel? Muxing multiple media flows over a single transport makes it harder to individually suppress a single flow by denying ICE keepalives. Either media-level (RTCP) mechanisms must be used or the implementation must deny responses entirely, thus terminating the call. nit: "must be used to suppress the misbehaving flow", I think. Section 9.4.3 The "origin" field of the signature request can be used to check that the user has agreed to disclose their identity to the calling site; because it is supplied by the PeerConnection it can be trusted to be correct. I don't see an "origin" field in the signature request; is this supposed to be the "domain"? Section 9.4.5.1 nit: it might be friendlier to the reader to prefix this with "When popup blocking is in use, ". Section 13.2 It's perhaps debatable that JSEP is only an informative reference. |
2019-03-06
|
18 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-03-06
|
18 | Alissa Cooper | [Ballot comment] In Section 7 I would suggest using Alice and Bob (or some other name) rather than "I" and "you/your." alice@example.org is used there … [Ballot comment] In Section 7 I would suggest using Alice and Bob (or some other name) rather than "I" and "you/your." alice@example.org is used there so the pronouns are mixed. Same comment for 9.1 -- I would suggest replacing "your" with "the user's." |
2019-03-06
|
18 | Alissa Cooper | Ballot comment text updated for Alissa Cooper |
2019-03-06
|
18 | Eric Rescorla | [Ballot comment] I am an author |
2019-03-06
|
18 | Eric Rescorla | [Ballot Position Update] New position, Recuse, has been recorded for Eric Rescorla |
2019-03-06
|
18 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-03-05
|
18 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2019-03-05
|
18 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-03-05
|
18 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-03-05
|
18 | Alissa Cooper | [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper |
2019-03-05
|
18 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-03-05
|
18 | Alexey Melnikov | [Ballot discuss] Thank you for a well written document! My apologies for filing a procedural DISCUSS on this, but I am looking at: 7.5. Determining … [Ballot discuss] Thank you for a well written document! My apologies for filing a procedural DISCUSS on this, but I am looking at: 7.5. Determining the IdP URI 3. The path, starting with "/.well-known/idp-proxy/" and appended with the IdP protocol. Note that the separator characters '/' (%2F) and '\' (%5C) MUST NOT be permitted in the protocol field, lest an attacker be able to direct requests outside of the controlled "/.well-known/" prefix. Query and fragment values MAY be used by including '?' or '#' characters. "idp-proxy" is not registered in the IANA's registry and this document doesn't register it either. If I missed where this is registered, please point me to the right document. If I haven't, please register it in this document. |
2019-03-05
|
18 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov |
2019-03-04
|
18 | Ben Campbell | [Ballot comment] Update to the Update: As Adam mentioned in email; while t= vs c=0 ordering is correct in 7.4.1, t= vs a= is not. … [Ballot comment] Update to the Update: As Adam mentioned in email; while t= vs c=0 ordering is correct in 7.4.1, t= vs a= is not. (Capturing it here for the ballot record.) Update: Ignore my comment about t= vs c=0. I had my order crossed; it is correct in the example. I'm balloting "yes", but have a few minor comments and editorial comments: §1: - (nit) The first sentence will not age well; I gather RTCWEB will close before long. (also The WG acronym is RTCWEB, not WebRTC. Or are you talking about the W3C?) - (nit) Figure 2: It seems a bit weird to have XMPP here, but never mentioned in the text. At least, please expand the abbreviation somwhere. (It also shows up in figure 4.) (nit) §3.1, first bullet: While I don't normally object (beyond nose holding, anyway) to the use of first person in RFCs, it seems an odd choice for this sentence. I assume "we" in this sentence does not refer to the the author or the WG. §4.1: (nit) - '... button next to Bob’s name which says "Call".': s/which/that - "The calling site will also provide some user interface element (e.g., a button) to allow Bob to answer the call, though this is most likely not part of the trusted UI." This is the first mention of "trusted UI". It would be helpful to elaborate on that prior to this mention. §5.1.4: - "In this case, the established identity SHOULD be applied to existing DTLS connections as well as new connections established using one of those fingerprints." Applied by the recipient? (consider active voice). Also, why not MUST? Don't unexpected things happen if the recipient doesn't do this? §6.2: - "Because HTTP origins cannot be securely established against network attackers, implementations MUST NOT allow the setting of permanent access permissions for HTTP origins. Implementations MUST refuse all permissions grants for HTTP origins." (nit-ish) - The MUST NOT seems non-constraining considering the last sentence. Or am I reading that sentence wrong? (nit) - .E.g., "Call customerservice@ford.com"' : sentence fragment. (nit) - ".. unlikely that browsers would have an X.509 certificate..." : Plural disagreement (assuming the browsers do not share 1 cert). (maybe nit) - "Clients MAY permit the formation of data channels without any direct user approval." Is the switch from talking about "the browser" to "Clients" intentional? §6.4: (nit) - "Note that these requirements are NOT intended..." "NOT" in all caps is likely to be confused with 2119/8174 language. §6.5: (nit) - "Implementations MUST implement SRTP [RFC3711]. Implementations MUST implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP keying. Implementations MUST implement [RFC8261]." Thank you for using the citation style that doesn't assume everyone has memorized the RFC numbers. But why not do the same for 8261? §7.2: (nit) - First paragraph: Can there be a citation for the W3C API spec? (My bad, the draft is correct. Comment removed.) §7.1.4, SDP example: (nit) §11: The first sentence is a fragment. §13.1 (normative references) (nit) - There's a reference to RFC 5234, but it is not cited in the text. - Is there a reason to reference 5246 rather than 8446, which obsoleted it? §13.2: - seems like the jsep reference should be normative. |
2019-03-04
|
18 | Ben Campbell | Ballot comment text updated for Ben Campbell |
2019-03-04
|
18 | Ben Campbell | [Ballot comment] Update: Ignore my comment about t= vs c=0. I had my order crossed; it is correct in the example. I'm balloting "yes", but … [Ballot comment] Update: Ignore my comment about t= vs c=0. I had my order crossed; it is correct in the example. I'm balloting "yes", but have a few minor comments and editorial comments: §1: - (nit) The first sentence will not age well; I gather RTCWEB will close before long. (also The WG acronym is RTCWEB, not WebRTC. Or are you talking about the W3C?) - (nit) Figure 2: It seems a bit weird to have XMPP here, but never mentioned in the text. At least, please expand the abbreviation somwhere. (It also shows up in figure 4.) (nit) §3.1, first bullet: While I don't normally object (beyond nose holding, anyway) to the use of first person in RFCs, it seems an odd choice for this sentence. I assume "we" in this sentence does not refer to the the author or the WG. §4.1: (nit) - '... button next to Bob’s name which says "Call".': s/which/that - "The calling site will also provide some user interface element (e.g., a button) to allow Bob to answer the call, though this is most likely not part of the trusted UI." This is the first mention of "trusted UI". It would be helpful to elaborate on that prior to this mention. §5.1.4: - "In this case, the established identity SHOULD be applied to existing DTLS connections as well as new connections established using one of those fingerprints." Applied by the recipient? (consider active voice). Also, why not MUST? Don't unexpected things happen if the recipient doesn't do this? §6.2: - "Because HTTP origins cannot be securely established against network attackers, implementations MUST NOT allow the setting of permanent access permissions for HTTP origins. Implementations MUST refuse all permissions grants for HTTP origins." (nit-ish) - The MUST NOT seems non-constraining considering the last sentence. Or am I reading that sentence wrong? (nit) - .E.g., "Call customerservice@ford.com"' : sentence fragment. (nit) - ".. unlikely that browsers would have an X.509 certificate..." : Plural disagreement (assuming the browsers do not share 1 cert). (maybe nit) - "Clients MAY permit the formation of data channels without any direct user approval." Is the switch from talking about "the browser" to "Clients" intentional? §6.4: (nit) - "Note that these requirements are NOT intended..." "NOT" in all caps is likely to be confused with 2119/8174 language. §6.5: (nit) - "Implementations MUST implement SRTP [RFC3711]. Implementations MUST implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP keying. Implementations MUST implement [RFC8261]." Thank you for using the citation style that doesn't assume everyone has memorized the RFC numbers. But why not do the same for 8261? §7.2: (nit) - First paragraph: Can there be a citation for the W3C API spec? (My bad, the draft is correct. Comment removed.) §7.1.4, SDP example: (nit) §11: The first sentence is a fragment. §13.1 (normative references) (nit) - There's a reference to RFC 5234, but it is not cited in the text. - Is there a reason to reference 5246 rather than 8446, which obsoleted it? §13.2: - seems like the jsep reference should be normative. |
2019-03-04
|
18 | Ben Campbell | Ballot comment text updated for Ben Campbell |
2019-03-04
|
18 | Ben Campbell | [Ballot comment] I'm balloting "yes", but have a few minor comments and editorial comments: §1: - (nit) The first sentence will not age well; I … [Ballot comment] I'm balloting "yes", but have a few minor comments and editorial comments: §1: - (nit) The first sentence will not age well; I gather RTCWEB will close before long. (also The WG acronym is RTCWEB, not WebRTC. Or are you talking about the W3C?) - (nit) Figure 2: It seems a bit weird to have XMPP here, but never mentioned in the text. At least, please expand the abbreviation somwhere. (It also shows up in figure 4.) (nit) §3.1, first bullet: While I don't normally object (beyond nose holding, anyway) to the use of first person in RFCs, it seems an odd choice for this sentence. I assume "we" in this sentence does not refer to the the author or the WG. §4.1: (nit) - '... button next to Bob’s name which says "Call".': s/which/that - "The calling site will also provide some user interface element (e.g., a button) to allow Bob to answer the call, though this is most likely not part of the trusted UI." This is the first mention of "trusted UI". It would be helpful to elaborate on that prior to this mention. §5.1.4: - "In this case, the established identity SHOULD be applied to existing DTLS connections as well as new connections established using one of those fingerprints." Applied by the recipient? (consider active voice). Also, why not MUST? Don't unexpected things happen if the recipient doesn't do this? §6.2: - "Because HTTP origins cannot be securely established against network attackers, implementations MUST NOT allow the setting of permanent access permissions for HTTP origins. Implementations MUST refuse all permissions grants for HTTP origins." (nit-ish) - The MUST NOT seems non-constraining considering the last sentence. Or am I reading that sentence wrong? (nit) - .E.g., "Call customerservice@ford.com"' : sentence fragment. (nit) - ".. unlikely that browsers would have an X.509 certificate..." : Plural disagreement (assuming the browsers do not share 1 cert). (maybe nit) - "Clients MAY permit the formation of data channels without any direct user approval." Is the switch from talking about "the browser" to "Clients" intentional? §6.4: (nit) - "Note that these requirements are NOT intended..." "NOT" in all caps is likely to be confused with 2119/8174 language. §6.5: (nit) - "Implementations MUST implement SRTP [RFC3711]. Implementations MUST implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP keying. Implementations MUST implement [RFC8261]." Thank you for using the citation style that doesn't assume everyone has memorized the RFC numbers. But why not do the same for 8261? §7.2: (nit) - First paragraph: Can there be a citation for the W3C API spec? §7.1.4, SDP example: We just had a report against draft-ietf-mmusic-sdp-simulcast claiming that putting "t=" after "c=" is not legal. 4566 and 4566bis seem to support that. (I realize that, if that's in fact an error, we've got it all over the place.) (nit) §11: The first sentence is a fragment. §13.1 (normative references) (nit) - There's a reference to RFC 5234, but it is not cited in the text. - Is there a reason to reference 5246 rather than 8446, which obsoleted it? §13.2: - seems like the jsep reference should be normative. |
2019-03-04
|
18 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2019-02-28
|
18 | Mirja Kühlewind | [Ballot comment] 1) This is related to my discuss on draft-ietf-rtcweb-security. I think I don't fully understand the split between those two documents, as section … [Ballot comment] 1) This is related to my discuss on draft-ietf-rtcweb-security. I think I don't fully understand the split between those two documents, as section 4.2 seems to introduce a normative reference to draft-ietf-rtcweb-security: "As described in ([I-D.ietf-rtcweb-security]; Section 4.2) media consent verification is provided via ICE. " However, given that section 6.3 actually normatively (re-)states the ICE requirements as well, I would maybe recommend to instead say: "As described in ([I-D.ietf-rtcweb-security]; Section 4.2) and stated in section 6.3 media consent verification is provided via ICE. " and then move the reference to draft-ietf-rtcweb-security to informative. 2) I would have also expected some discussion in the security considerations sections about the risks to the user if the browser gets corrupted, as indicated by the trust model presented in sec 3. 3) In Sec 9.2: "Combined WebRTC/Tor implementations SHOULD arrange to route the media as well as the signaling through Tor. Currently this will produce very suboptimal performance." Maybe make these sentences a bit more general, e.g. "Combined WebRTC/anonymity service implementations SHOULD arrange to route the media as well as the signaling through the anonymity network. Currently with e.g. Tor this will produce very suboptimal performance. |
2019-02-28
|
18 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-02-21
|
18 | Cindy Morgan | Placed on agenda for telechat - 2019-03-07 |
2019-02-21
|
18 | Adam Roach | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-02-21
|
18 | Adam Roach | Ballot has been issued |
2019-02-21
|
18 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2019-02-21
|
18 | Adam Roach | Created "Approve" ballot |
2019-02-21
|
18 | Adam Roach | Ballot writeup was changed |
2019-02-15
|
18 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-02-14
|
18 | Sabrina Tanamal | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-02-14
|
18 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Not OK |
2019-02-14
|
18 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-rtcweb-security-arch-18. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-rtcweb-security-arch-18. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the att-field (session level) registry on the Session Description Protocol (SDP) Parameters registry page located at: https://www.iana.org/assignments/sdp-parameters/ a single, new registration is to be made as follows: Type: identity SDP Name: identity Mux Category: NORMAL Reference: [ RFC-to-be; Section 5 ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-02-14
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Taylor Yu |
2019-02-14
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Taylor Yu |
2019-02-14
|
18 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Withdrawn' |
2019-02-14
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tobias Gondrom |
2019-02-14
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tobias Gondrom |
2019-02-10
|
18 | Tobias Gondrom | Assignment of request for Last Call review by SECDIR to Tobias Gondrom was rejected |
2019-02-09
|
18 | Russ Housley | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Russ Housley. Sent review to list. |
2019-02-07
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2019-02-07
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2019-02-07
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tobias Gondrom |
2019-02-07
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tobias Gondrom |
2019-02-05
|
18 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2019-02-05
|
18 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2019-02-01
|
18 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-02-01
|
18 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-02-15): From: The IESG To: IETF-Announce CC: adam@nostrum.com, rtcweb-chairs@ietf.org, Sean Turner , rtcweb@ietf.org, … The following Last Call announcement was sent out (ends 2019-02-15): From: The IESG To: IETF-Announce CC: adam@nostrum.com, rtcweb-chairs@ietf.org, Sean Turner , rtcweb@ietf.org, draft-ietf-rtcweb-security-arch@ietf.org, sean@sn3rd.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (WebRTC Security Architecture) to Proposed Standard The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC Security Architecture' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-02-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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". The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7918: Transport Layer Security (TLS) False Start (Informational - IETF stream) |
2019-02-01
|
18 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-02-01
|
18 | Adam Roach | Last call was requested |
2019-02-01
|
18 | Adam Roach | Last call announcement was generated |
2019-02-01
|
18 | Adam Roach | Ballot approval text was generated |
2019-02-01
|
18 | Adam Roach | Ballot writeup was generated |
2019-02-01
|
18 | Adam Roach | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-02-01
|
18 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-02-01
|
18 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-18.txt |
2019-02-01
|
18 | (System) | New version approved |
2019-02-01
|
18 | (System) | Request for posting confirmation emailed to previous authors: Eric Rescorla |
2019-02-01
|
18 | Eric Rescorla | Uploaded new revision |
2018-11-27
|
17 | Adam Roach | Waiting for new version to resolve https://github.com/rtcweb-wg/security-arch/issues/82 |
2018-11-27
|
17 | Adam Roach | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2018-11-17
|
17 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-11-17
|
17 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-17.txt |
2018-11-17
|
17 | (System) | New version approved |
2018-11-17
|
17 | (System) | Request for posting confirmation emailed to previous authors: Eric Rescorla |
2018-11-17
|
17 | Eric Rescorla | Uploaded new revision |
2018-10-30
|
16 | Adam Roach | See AD review at https://mailarchive.ietf.org/arch/msg/rtcweb/ieVu9QV3cIazGjZQaBPBJtrefwU |
2018-10-30
|
16 | Adam Roach | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-10-30
|
16 | Adam Roach | IESG state changed to AD Evaluation from Publication Requested |
2018-10-22
|
16 | Sean Turner | 1. Summary This document defines the security architecture for WebRTC. This draft is bound standards track because it includes protocol for web-based peer authentication. Sean … 1. Summary This document defines the security architecture for WebRTC. This draft is bound standards track because it includes protocol for web-based peer authentication. Sean Turner is the document shepherd and Adam Roach is our Über Area Director! 2. Review and Consensus This draft has been discussed on the mailing list and at numerous RTCweb f2f meetings. It’s been amended numerous times based on WG feedback and it reflects the WG consensus. 3. Intellectual Property The shepherd has confirmed the author's direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points DOWNREFs: There is one DOWNREF to RFC 2818, but it's been in the DOWNRE registry forever. It should be called out during the IETF LC, but it's really just a formality. IANA Considerations: There is one SDP attribute registration and it follows the procedures specified in s8.2.4 of RFC 4566. |
2018-10-22
|
16 | Sean Turner | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2018-10-22
|
16 | Sean Turner | IESG state changed to Publication Requested from AD is watching |
2018-10-22
|
16 | Sean Turner | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2018-10-22
|
16 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-16.txt |
2018-10-22
|
16 | (System) | New version approved |
2018-10-22
|
16 | (System) | Request for posting confirmation emailed to previous authors: Eric Rescorla |
2018-10-22
|
16 | Eric Rescorla | Uploaded new revision |
2018-09-10
|
15 | Adam Roach | Waiting on merge of https://github.com/rtcweb-wg/security-arch/pull/77 |
2018-07-17
|
15 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-15.txt |
2018-07-17
|
15 | (System) | New version approved |
2018-07-17
|
15 | (System) | Request for posting confirmation emailed to previous authors: Eric Rescorla |
2018-07-17
|
15 | Eric Rescorla | Uploaded new revision |
2018-04-12
|
14 | Sean Turner | Tag Revised I-D Needed - Issue raised by WGLC set. |
2018-04-12
|
14 | Sean Turner | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2018-03-12
|
14 | Sean Turner | Tags Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway cleared. |
2018-03-12
|
14 | Sean Turner | IETF WG state changed to In WG Last Call from Waiting for WG Chair Go-Ahead |
2018-03-12
|
14 | Cindy Morgan | New version available: draft-ietf-rtcweb-security-arch-14.txt |
2018-03-12
|
14 | (System) | Secretariat manually posting. Approvals already received |
2018-03-12
|
14 | Cindy Morgan | Uploaded new revision |
2018-03-10
|
13 | Sean Turner | 1. Summary This document defines the security architecture for WebRTC. This draft is bound standards track because it includes protocol for web-based peer authentication. Sean … 1. Summary This document defines the security architecture for WebRTC. This draft is bound standards track because it includes protocol for web-based peer authentication. Sean Turner is the document shepherd and Adam Roach is our Über Area Director! 2. Review and Consensus This draft has been discussed on the mailing list and at numerous RTCweb f2f meetings. It’s been amended numerous times based on WG feedback and it reflects the WG consensus. 3. Intellectual Property The shepherd has confirmed the author's direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points DOWNREFs: There is one DOWNREF to RFC 2818, but it's been in the DOWNRE registry forever. It should be called out during the IETF LC, but it's really just a formality. IANA Considerations: There is one SDP attribute registration and it follows the procedures specified in s8.2.4 of RFC 4566. |
2018-03-10
|
13 | Sean Turner | Changed consensus to Yes from Unknown |
2018-02-27
|
13 | Sean Turner | 1. Summary This document defines the security architecture for WebRTC. This draft is bound standards track because it includes protocol for web-based peer authentication. Sean … 1. Summary This document defines the security architecture for WebRTC. This draft is bound standards track because it includes protocol for web-based peer authentication. Sean Turner is the document shepherd and Adam Roach is our Über Area Director! 2. Review and Consensus This draft has been discussed on the mailing list and at numerous RTCweb f2f meetings. It’s been amended numerous times based on WG feedback and it reflects the WG consensus. 3. Intellectual Property The shepherd has confirmed the author's direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points DOWNREFs: There are a lot of references to IDs but they’re all bound for standards track. IANA Considerations: There is one SDP attribute registration and it follows the procedures specified in RFC 4566. |
2018-01-22
|
13 | Adam Roach | Shepherding AD changed to Adam Roach |
2017-11-21
|
13 | Sean Turner | Notification list changed to Sean Turner <sean@sn3rd.com> |
2017-11-21
|
13 | Sean Turner | Document shepherd changed to Sean Turner |
2017-11-12
|
13 | Adam Roach | IESG state changed to AD is watching from Dead |
2017-10-30
|
13 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-13.txt |
2017-10-30
|
13 | (System) | New version approved |
2017-10-30
|
13 | (System) | Request for posting confirmation emailed to previous authors: Eric Rescorla |
2017-10-30
|
13 | Eric Rescorla | Uploaded new revision |
2016-12-10
|
12 | (System) | Document has expired |
2016-06-08
|
12 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-12.txt |
2016-04-08
|
11 | (System) | Document has expired |
2016-04-08
|
11 | (System) | IESG state changed to Dead from AD is watching::External Party |
2016-04-07
|
11 | Alissa Cooper | IESG state changed to AD is watching::External Party from Publication Requested |
2015-10-14
|
11 | (System) | Notify list changed from rtcweb-chairs@ietf.org, draft-ietf-rtcweb-security-arch@ietf.org, draft-ietf-rtcweb-security-arch.ad@ietf.org, turners@ieca.com, draft-ietf-rtcweb-security-arch.shepherd@ietf.org to (None) |
2015-10-08
|
11 | Tero Kivinen | Request for Early review by SECDIR Completed: Has Issues. Reviewer: Tobias Gondrom. |
2015-07-02
|
11 | Tero Kivinen | Request for Early review by SECDIR is assigned to Tobias Gondrom |
2015-07-02
|
11 | Tero Kivinen | Request for Early review by SECDIR is assigned to Tobias Gondrom |
2015-04-02
|
11 | Sean Turner | Tag Revised I-D Needed - Issue raised by WGLC set. |
2015-04-02
|
11 | Sean Turner | IETF WG state changed to Waiting for WG Chair Go-Ahead from Submitted to IESG for Publication |
2015-03-25
|
11 | Cindy Morgan | Shepherding AD changed to Alissa Cooper |
2015-03-19
|
11 | Sean Turner | How’s this for the proto write-up? I tend to either go for funny or very short - this one is short ;) 1. Summary This … How’s this for the proto write-up? I tend to either go for funny or very short - this one is short ;) 1. Summary This document defines the security architecture for WebRTC. This draft is bound standards track because it includes protocol for web-based peer authentication. Sean Turner is the document shepherd and Alissa Cooper is going to be our über Area Director! 2. Review and Consensus This draft has been discussed on the mailing list and at numerous RTCweb f2f meetings. It’s been amended numerous times based on WG feedback and it reflects the WG consensus. 3. Intellectual Property The shepherd has confirmed the author's direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points DOWNREFs: There are a lot of references to IDs but they’re all bound for standards track. IANA Considerations: There’s one SDP attribute registration and it follows the procedures specified in RFC 4566. |
2015-03-19
|
11 | Sean Turner | State Change Notice email list changed to rtcweb-chairs@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-security-arch@ietf.org, draft-ietf-rtcweb-security-arch.ad@ietf.org, turners@ieca.com, draft-ietf-rtcweb-security-arch.shepherd@ietf.org |
2015-03-19
|
11 | Sean Turner | Responsible AD changed to Richard Barnes |
2015-03-19
|
11 | Sean Turner | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2015-03-19
|
11 | Sean Turner | IESG state changed to Publication Requested |
2015-03-19
|
11 | Sean Turner | IESG process started in state Publication Requested |
2015-03-19
|
11 | Sean Turner | Intended Status changed to Proposed Standard from None |
2015-03-19
|
11 | Sean Turner | Changed document writeup |
2015-03-07
|
11 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-11.txt |
2014-08-14
|
10 | Sean Turner | Tag Doc Shepherd Follow-up Underway set. |
2014-08-14
|
10 | Sean Turner | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2014-07-10
|
10 | Sean Turner | IETF WG state changed to In WG Last Call from WG Document |
2014-07-04
|
10 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-10.txt |
2014-07-02
|
09 | Sean Turner | Document shepherd changed to Sean Turner |
2014-02-14
|
09 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-09.txt |
2014-01-23
|
08 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-08.txt |
2014-01-10
|
07 | Magnus Westerlund | Document shepherd changed to Ted Hardie |
2013-07-15
|
07 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-07.txt |
2013-01-22
|
06 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-06.txt |
2012-10-22
|
05 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-05.txt |
2012-10-22
|
04 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-04.txt |
2012-07-16
|
03 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-03.txt |
2012-06-05
|
02 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-02.txt |
2012-03-12
|
01 | Eric Rescorla | New version available: draft-ietf-rtcweb-security-arch-01.txt |
2012-01-23
|
00 | (System) | New version available: draft-ietf-rtcweb-security-arch-00.txt |