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

[Cullen Jennings <[e-mail]>]

> On Apr 30, 2018, at 9:20 AM, Tim Hollebeek <[e-mail]> wrote:
> 
> 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 certainly think it would be worth advising the IdP protocols designers that they they probably want to consider making the tokens only valid for a short time such as 30 seconds and they are welcome to have a way to invalidate and check validity of tokens if they want to do that. 

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

For sure - but we don’t want to do is make it so hard to use that no one uses. Something the IETF excels at :-) But as long as we can improve the robustness of the security without huge complication to use, I’m for that. 

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