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

[Tim Hollebeek <[e-mail]>]

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:[e-mail]]
> Sent: Monday, April 30, 2018 12:30 AM
> To: Cullen Jennings <[e-mail]>
> Cc: Tim Hollebeek <[e-mail]>; RTCWeb IETF
> <[e-mail]>
> 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.
> 
> On Sun, Apr 29, 2018 at 2:01 AM, Cullen Jennings <[e-mail]> wrote:
> >
> > 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
> > <[e-mail]>
> > 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
> >
> > From: rtcweb [mailto:[e-mail]] On Behalf Of Cullen
> > Jennings
> > Sent: Thursday, April 26, 2018 9:03 PM
> > To: Sean Turner <[e-mail]>
> > Cc: RTCWeb IETF <[e-mail]>
> > 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 <[e-mail]> wrote:
> >
> > 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?
> >
> >
> > 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.
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >