Subject: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch)

From: Sean Turner <[email-masked]>
Date: Thu, 12 Apr 2018 09:45:18 -0400

The WGLC for this document has ended.  I think it was really good that @ IETF101 the IdP hackathon happened because it looked like they might have uncovered something to be changed in our document and possibly in the webrtc-pc draft; see the [0] thread.  As the Shepherd trying to drive this to closure, we need to we need to decide what changes might be made in draft-ietf-rtcweb-security-arch.  In that thread, I saw two things that we might change (both from mt):

0) More text to address a linkability concern:

  As a practical matter, if the browser were to use the same certificate
  for multiple origins, then it would create a massive privacy problem
  that enables linkability (aka user tracking).  I couldn't find that
  written down, but I thought it was.  If it isn't written down, then we
  should correct that.

I actually think this is basically covered here:
https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#section-4.4.1
But want to make sure others agree:

1) Tweak protocol to include an identifier to prevent reuse of assertion on every RTCPeerConnection:

  More complex sites frequently generate multiple RTCPeerConnection
  instances for their communications, especially for group
  conversations.  If the browser requests an assertion once and they use
  that value for every RTCPeerConnection, then that's OK.  From my
  perspective, I would be happy modifying the protocol to include an
  identifier and prevent that; for this the IdP can use caching or its
  local storage.

So, what would that look like?

Did I miss anything else that needs to be addressed?

spt

[0] https://mailarchive.ietf.org/arch/msg/rtcweb/2r2u20UQIKwNeY1PsYFrDw7jXEw

> On Mar 12, 2018, at 19:08, Sean Turner <[email-masked]> wrote:
> 
> All,
> 
> This is the WGLC for the “WebRTC Security Architecture” draft available @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/.  Please review the draft and send your comments to this list by 2359UTC on April 6th, 2018.
> 
> Note the gh repo is here:
> https://github.com/rtcweb-wg/security-arch
> 
> Thanks,
> C/T/S

---

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 12 Apr 2018 21:52:26 -0700

> On Apr 12, 2018, at 06:45, Sean Turner <[email-masked]> wrote:

Agreed.

> 1) Tweak protocol to include an identifier to prevent reuse of assertion on every RTCPeerConnection:

To be honest I’m actually confused by Martin’s statement.

>  that value for every RTCPeerConnection, then that's OK.

This sentence sounds to me like it would/should be okay for pages/service to re-use identity assertions.

>  From my

While this sounds to me like the opposite.

> So, what would that look like?

The tls-id from https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-32 <https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-32> could serve that purpose.

Best
  Nils Ohlmeier

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Apr 2018 18:10:35 -0700

On Thu, Apr 12, 2018 at 6:45 AM, Sean Turner <[email-masked]> wrote:

> The WGLC for this document has ended.  I think it was really good that @
> IETF101 the IdP hackathon happened because it looked like they might have
> uncovered something to be changed in our document and possibly in the
> webrtc-pc draft; see the [0] thread.  As the Shepherd trying to drive this
> to closure, we need to we need to decide what changes might be made in
> draft-ietf-rtcweb-security-arch.  In that thread, I saw two things that
> we might change (both from mt):
>

Isn't this the relevant text:
"

   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.)

"

> So, what would that look like?

Wouldn't it be sufficient to include the tls-id in the identity binding?

-Ekr

> > This is the WGLC for the “WebRTC Security Architecture” draft available
> @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/.  Please
> review the draft and send your comments to this list by 2359UTC on April
> 6th, 2018.
> >

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Apr 2018 08:47:12 +1000

tls-id is connection-based (i.e., it applies to a single bundle),
whereas identity is session-based.  That was my initial thought, but
then we have to deal with the 1:N problem there.  The simplest
approach might be to move a=identity to the bundle, but that leads to
some interesting downstream effects.  You probably want to avoid
having multiple identities in the same RTCPeerConnection, for
instance.

On Sat, Apr 21, 2018 at 11:10 AM, Eric Rescorla <[email-masked]> wrote:
>> draft-ietf-rtcweb-security-arch.  In that thread, I saw two things that we
>> might change (both from mt):
>>
>> [0]
>> https://mailarchive.ietf..org/arch/msg/rtcweb/2r2u20UQIKwNeY1PsYFrDw7jXEw
>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 Apr 2018 12:34:51 +0000

Hi,

A couple of questions on the SDP identity attribute.

Q1:
---

The draft lacks the offer/answer procedure sections (generate offer,
generate answer, modify session etc) for the attribute, which I think
should be added. My question is regarding the following statement, which
seems to indicate that the attribute is only used in offers:

  "Implementations SHOULD only include a single identity attribute in an
offer² (there is no text about including the attribute in an answer)

However, in draft-ietf-rtcweb-sdp it is included in both the offer and
answer.

Q2:
---

Also, the mux category is missing (draft-ietf-mmusic-sdp-mux-attributes
also covers session-level attributes). I assume it is ³NORMAL².

Regards,

Christer

On 23/04/18 01:47, "rtcweb on behalf of Martin Thomson"
<[email-masked] on behalf of [email-masked]> wrote:

>>> 1) Tweak protocol to include an identifier to prevent reuse of
>>>assertion
>>> on every RTCPeerConnection:
>>>
>>> > This is the WGLC for the ³WebRTC Security Architecture² draft
>>>available

---

From: Sean Turner <[email-masked]>
Date: Thu, 26 Apr 2018 20:26:38 -0400

> On Apr 23, 2018, at 08:34, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

This is about what to do if you include a=identity not about whether to include it.

> However, in draft-ietf-rtcweb-sdp it is included in both the offer and

I think that draft-ietf-rtcweb-sdp includes them in both the offer and the answer because the examples are using the WEBRTC Identity mechanism.  I think this is consistent with what is in both draft-ietf-rtcweb-sdp and draft-ietf-rtcweb-jsep:

   If WebRTC identity is being used, an "a=identity" line as
   described in [I-D.ietf-rtcweb-security-arch], Section 5.

> also covers session-level attributes). I assume it is ³NORMAL².

I think this mans adding:

  Mux Category: NORMAL

to the IANA registration?

spt

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 26 Apr 2018 19:02:43 -0600

> On Apr 12, 2018, at 7:45 AM, Sean Turner <[email-masked]> wrote:
> 

It’s not clear to me what the problem we are solving here is. Who are we trying to stop from reusing an assertion and why. The assertion is already bound to the specific private key and specific web origin. The IdP can bind it to a narrow time range if the IdP wants ( most do). I’m not seeing the big difference from reusing an assertion vs. asking the for a bunch of them. The protocol that users the assertion may end up forking the same assertion to many places regardless of what the browser does. 

Changing this so that the IdP see how many PeerConnections are formed seems like it just reveal more usage information to the IdP and does not help security.

Assuming I am just not getting the problem and we do want to solve this … I is not clear to me how to make this all work with tls-id due to all the bundle issues. Another approach would the browser greater a GUID for the PeerConnection and that is passed in the IdP proxy code and the IdP can bind it into the assertion or not but if it does bind into the assertion, then the browser will only validate the assertion on the PeerConnection with matching GUID. This is probably wrong and half baked as I don’t really get the problem.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Apr 2018 06:10:37 +0000

Hi,

>This is about what to do if you include a=identity not about whether to

When new SDP attributes are defined, there needs to be offer/answer
procedures. Because, I assume the attribute can be used on the wire, in
SDP offers and answers?

Also, if the attribute is scoped to WebRTC, or to some specific security
solutions, I think that also needs to be covered.

>I think that draft-ietf-rtcweb-sdp includes them in both the offer and
>the answer because the examples are using the WEBRTC Identity mechanism.
>I think this is consistent with what is in both draft-ietf-rtcweb-sdp and
>draft-ietf-rtcweb-jsep:
>

That sentence is only for the initial offer. Unless I’ve missed it, there
is no text about a=identity regarding answers.

>to the IANA registration?

Correct. But, NORMAL is just my assumption -  I want people to confirm
whether that is correct :)

Regards,

Christer

>>>>> The WGLC for this document has ended.  I think it was really good
>>>>>that
>>>>> @
>>>>>https://mailarchive.ietf..org/arch/msg/rtcweb/2r2u20UQIKwNeY1PsYFrDw7j
>>>>>XE
>>>>> w
>>>>>

---

From: Tim Hollebeek <[email-masked]>
Date: Sat, 28 Apr 2018 00:13:06 +0000

I’m going from my memory from the IETF 101 hackathon here, so someone feel free to correct me if I’m remembering the details wrong (I probably am for at least some of it), but as I recall it, the issue was essentially that when one requests an identity assertion, if one presents it to someone, the security properties are Awesome [TM] because only authorized persons can get an identity assertion from the IDP.

However, after one has presented an identity assertion to a potentially untrusted party, presentation of that assertion to additional parties is Slightly Less Than Awesome [TM], because the additional parties cannot distinguish between the person who legitimately obtained the identity assertion, and the party to which the identity assertion was previously presented.

Various arguments were made that this is not a problem because the lifetime of identity assertions is short, with lifetimes on the order of days to hours.  There was also some discussion (before the issue was found) about if expiration of the relevant temporary certificates needed to be checked at all.  Call me crazy, but only having a few hours to carry out my attack doesn’t hinder me much as an attacker!

One solution that was discussed, which may or may not work for all use cases and this certainly should be explored, was that identity assertions are cheap and therefore supporting the complexity of identity assertion re-use might not make sense.  We discussed simply adding a nonce to the creation of identity assertions, so IDPs could enforce that they are validated only once, essentially turning them into bearer tokens.  If the process fails (network hiccup, etc) it is possible to transparently regenerate a new assertion and retry.  IIRC certain non-attack failure scenarios needed this retry logic anyway.

If needed, I can go back and re-read the messages from that weekend to help refresh my memory, but that’s what I remember.

-Tim

From: rtcweb [mailto:[email-masked]] On Behalf Of Cullen Jennings
Sent: Thursday, April 26, 2018 9:03 PM
To: Sean Turner <[email-masked]>
Cc: RTCWeb IETF <[email-masked]>
Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch)

On Apr 12, 2018, at 7:45 AM, Sean Turner <[email-masked] <mailto:[email-masked]> > wrote:

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 28 Apr 2018 10:01:17 -0600

Tim - that sounds about right but this is the part I don’t get…. 

All the identity assertion does is bind the public key from the TLS connection to the a name/identity. Think of it like a certificate that binds my private key to name. Anyone can get my cert and pass it around however they want. That is fine. Similarly the assertion can be passed around handed to bad people etc. But anyone using it need to match it with a TLS connection that does proof of possession of the private key that matches the public key. That private key is going to be very narrowly scoped on what has access to it. People that want to rely on this identity assertion have to be sure that they require proof of possession of private key.

So I do not see the issue at all that the identity assertion, just like a normal X508 certificate, can be passed around. I’m not getting whey this is Slightly Less than Awesome :-) 

I’m not arguing there is no problem, but I am not getting what the problem is. 

Cullen 

> On Apr 27, 2018, at 6:13 PM, Tim Hollebeek <[email-masked]> wrote:
> 
> On Apr 12, 2018, at 7:45 AM, Sean Turner <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Apr 2018 14:29:42 +1000

I agree with Cullen.

I would also point out that with an intended recipient, the IdP can
limit the information that can be obtained from an assertion.  If the
assertion were provided to other than the intended recipient, the IdP
could refuse to provide an identity.  That requires authenticating the
recipient as well, which isn't something we naturally assume, but the
mechanisms for enabling that are all in place.

FWIW, I think that an abundance of caution suggests that limiting the
assertion to a particular session is sensible.  The problem there is
that we would need a session identifier in order to do that.  Until we
discovered that RTCCertificate was portable, that was considered
sufficient, I would prefer to remove that portability.  Maybe we
should consider adding an origin to RTCCertificate that would allow it
to be moved to other origins, but not be used by them.

On Sun, Apr 29, 2018 at 2:01 AM, Cullen Jennings <[email-masked]> wrote:
> All the identity assertion does is bind the public key from the TLS
> connection to the a name/identity. Think of it like a certificate that binds
> my private key to name. Anyone can get my cert and pass it around however
> they want. That is fine. Similarly the assertion can be passed around handed
> to bad people etc. But anyone using it need to match it with a TLS
> connection that does proof of possession of the private key that matches the
> public key. That private key is going to be very narrowly scoped on what has
> access to it. People that want to rely on this identity assertion have to be
> sure that they require proof of possession of private key.
>
> So I do not see the issue at all that the identity assertion, just like a
> normal X508 certificate, can be passed around. I’m not getting whey this is
> Slightly Less than Awesome :-)
>
> I’m going from my memory from the IETF 101 hackathon here, so someone feel
> free to correct me if I’m remembering the details wrong (I probably am for
> at least some of it), but as I recall it, the issue was essentially that
> when one requests an identity assertion, if one presents it to someone, the
> security properties are Awesome [TM] because only authorized persons can get
> an identity assertion from the IDP.
>
> However, after one has presented an identity assertion to a potentially
> untrusted party, presentation of that assertion to additional parties is
> Slightly Less Than Awesome [TM], because the additional parties cannot
> distinguish between the person who legitimately obtained the identity
> assertion, and the party to which the identity assertion was previously
> presented.
>
> Various arguments were made that this is not a problem because the lifetime
> of identity assertions is short, with lifetimes on the order of days to
> hours.  There was also some discussion (before the issue was found) about if
> expiration of the relevant temporary certificates needed to be checked at
> all.  Call me crazy, but only having a few hours to carry out my attack
> doesn’t hinder me much as an attacker!
>
> One solution that was discussed, which may or may not work for all use cases
> and this certainly should be explored, was that identity assertions are
> cheap and therefore supporting the complexity of identity assertion re-use
> might not make sense.  We discussed simply adding a nonce to the creation of
> identity assertions, so IDPs could enforce that they are validated only
> once, essentially turning them into bearer tokens.  If the process fails
> (network hiccup, etc) it is possible to transparently regenerate a new
> assertion and retry.  IIRC certain non-attack failure scenarios needed this
> retry logic anyway.
>
> If needed, I can go back and re-read the messages from that weekend to help
> refresh my memory, but that’s what I remember.
>
> -Tim
>
> Subject: Re: [rtcweb] Addressing WGLC comments for
> draft-ietf-rtcweb-security-arch? (was Re: WGLC for
> draft-ietf-rtcweb-security-arch)
>
>
>
>
> It’s not clear to me what the problem we are solving here is. Who are we
> trying to stop from reusing an assertion and why. The assertion is already
> bound to the specific private key and specific web origin. The IdP can bind
> it to a narrow time range if the IdP wants ( most do). I’m not seeing the
> big difference from reusing an assertion vs. asking the for a bunch of them.
> The protocol that users the assertion may end up forking the same assertion
> to many places regardless of what the browser does.
>
> Changing this so that the IdP see how many PeerConnections are formed seems
> like it just reveal more usage information to the IdP and does not help
> security.
>
> Assuming I am just not getting the problem and we do want to solve this … I
> is not clear to me how to make this all work with tls-id due to all the
> bundle issues. Another approach would the browser greater a GUID for the
> PeerConnection and that is passed in the IdP proxy code and the IdP can bind
> it into the assertion or not but if it does bind into the assertion, then
> the browser will only validate the assertion on the PeerConnection with
> matching GUID. This is probably wrong and half baked as I don’t really get
> the problem.
>
>
>

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 30 Apr 2018 15:20:32 +0000

It's entirely possible that there isn't actually a problem if you do all the right things.
But it's important that all those right things are actually required, and the rationale
is clearly explained in the security considerations.  For example, doing certificate 
expiration checks, so that there isn't crypto data lying around that can be used in 
"interesting" ways in the future when the standard may have evolved into something 
else, seems like a good idea to me.

I also think the musings in Martin's last paragraph make sense and are headed in the 
right direction.  There's no harm in making protocols robust against attack scenarios
we haven't thought of yet.

-Tim

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: Monday, April 30, 2018 12:30 AM
> To: Cullen Jennings <[email-masked]>
> Cc: Tim Hollebeek <[email-masked]>; RTCWeb IETF
> <[email-masked]>
> Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-
> security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch)
> 
> I agree with Cullen.
> 
> I would also point out that with an intended recipient, the IdP can limit the
> information that can be obtained from an assertion.  If the assertion were
> provided to other than the intended recipient, the IdP could refuse to provide
> an identity.  That requires authenticating the recipient as well, which isn't
> something we naturally assume, but the mechanisms for enabling that are all in
> place.
> 
> FWIW, I think that an abundance of caution suggests that limiting the assertion
> to a particular session is sensible.  The problem there is that we would need a
> session identifier in order to do that.  Until we discovered that RTCCertificate
> was portable, that was considered sufficient, I would prefer to remove that
> portability.  Maybe we should consider adding an origin to RTCCertificate that
> would allow it to be moved to other origins, but not be used by them.
> 
> > connection to the a name/identity. Think of it like a certificate that
> > binds my private key to name. Anyone can get my cert and pass it
> > around however they want. That is fine. Similarly the assertion can be
> > passed around handed to bad people etc. But anyone using it need to
> > match it with a TLS connection that does proof of possession of the
> > private key that matches the public key. That private key is going to
> > be very narrowly scoped on what has access to it. People that want to
> > rely on this identity assertion have to be sure that they require proof of
> possession of private key.
> >
> > So I do not see the issue at all that the identity assertion, just
> > like a normal X508 certificate, can be passed around. I’m not getting
> > whey this is Slightly Less than Awesome :-)
> >
> > On Apr 27, 2018, at 6:13 PM, Tim Hollebeek
> > <[email-masked]>
> > wrote:
> >
> > I’m going from my memory from the IETF 101 hackathon here, so someone
> > feel free to correct me if I’m remembering the details wrong (I
> > probably am for at least some of it), but as I recall it, the issue
> > was essentially that when one requests an identity assertion, if one
> > presents it to someone, the security properties are Awesome [TM]
> > because only authorized persons can get an identity assertion from the IDP.
> >
> > However, after one has presented an identity assertion to a
> > potentially untrusted party, presentation of that assertion to
> > additional parties is Slightly Less Than Awesome [TM], because the
> > additional parties cannot distinguish between the person who
> > legitimately obtained the identity assertion, and the party to which
> > the identity assertion was previously presented.
> >
> > Various arguments were made that this is not a problem because the
> > lifetime of identity assertions is short, with lifetimes on the order
> > of days to hours.  There was also some discussion (before the issue
> > was found) about if expiration of the relevant temporary certificates
> > needed to be checked at all.  Call me crazy, but only having a few
> > hours to carry out my attack doesn’t hinder me much as an attacker!
> >
> > One solution that was discussed, which may or may not work for all use
> > cases and this certainly should be explored, was that identity
> > assertions are cheap and therefore supporting the complexity of
> > identity assertion re-use might not make sense.  We discussed simply
> > adding a nonce to the creation of identity assertions, so IDPs could
> > enforce that they are validated only once, essentially turning them
> > into bearer tokens.  If the process fails (network hiccup, etc) it is
> > possible to transparently regenerate a new assertion and retry.  IIRC
> > certain non-attack failure scenarios needed this retry logic anyway.
> >
> > If needed, I can go back and re-read the messages from that weekend to
> > help refresh my memory, but that’s what I remember.
> >
> > -Tim
> >
> > assertion on every RTCPeerConnection:
> >
> > It’s not clear to me what the problem we are solving here is. Who are
> > we trying to stop from reusing an assertion and why. The assertion is
> > already bound to the specific private key and specific web origin. The
> > IdP can bind it to a narrow time range if the IdP wants ( most do).
> > I’m not seeing the big difference from reusing an assertion vs. asking the for a
> bunch of them.
> > The protocol that users the assertion may end up forking the same
> > assertion to many places regardless of what the browser does.
> >
> > Changing this so that the IdP see how many PeerConnections are formed
> > seems like it just reveal more usage information to the IdP and does
> > not help security.
> >
> > Assuming I am just not getting the problem and we do want to solve
> > this … I is not clear to me how to make this all work with tls-id due
> > to all the bundle issues. Another approach would the browser greater a
> > GUID for the PeerConnection and that is passed in the IdP proxy code
> > and the IdP can bind it into the assertion or not but if it does bind
> > into the assertion, then the browser will only validate the assertion
> > on the PeerConnection with matching GUID. This is probably wrong and
> > half baked as I don’t really get the problem.
> >
> >
> >