Subject: [rtcweb] Regarding the assertion mechanism in the new security draft

From: Oscar Ohlsson <[email-masked]>
Date: Fri, 11 Nov 2011 16:42:28 +0100

Eric,

I read through your latest security draft and I found the the assertion mechanism described in the Appendix very interesting. One thing I didn't quite understand though is why the ROAP session ID needs to be included in the assertion. As far as I can tell you only need to assert the fingerprint. I would appreciate if you could explain your reasoning here.

Regards,

Oscar Ohlsson

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Nov 2011 08:44:32 -0800

> I read through your latest security draft and I found the the assertion mechanism described in the Appendix very interesting. One thing I didn't quite understand though is why the ROAP session ID n…

Thanks!

I should probably admit at this point that I haven't done a complete
security analysis
of the assertion-based system, so exactly what fields need to be
signed is, I think
a bit of an open question. I tried to make the level of maturity clear
in my draft,
but I'm not certain I did.

With that said, my theory there was that it would be a good idea to
cryptographically
bind the assertion to this specific session rather than just to the
identity in general.
This prevents replay style attacks. However, as you suggest, it's not entirely
clear how one would go about mounting such an attack without simultaneously
controlling enough keying material so you could do anything. Do you
see a downside
to signing this data?

Best,
-Ekr

---

From: Oscar Ohlsson <[email-masked]>
Date: Mon, 14 Nov 2011 09:36:13 +0100

I had a slightly different scenario in mind when I was posing the question. Say that I have several client certificates (issued by some CA) installed in my browser and I want to use one of them to authenticate myself in WebRTC. Would I then also need to sign the ROAP session ID using this certificate? If not, what is the difference between a CA issued certifcate and self-signed certificate whose fingerprint is asserted through BrowserID?

Regards,

Oscar Ohlsson 

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: den 11 november 2011 17:45
> To: Oscar Ohlsson
> Cc: [email-masked]
> Subject: Re: Regarding the assertion mechanism in the new 
> security draft
> 
> > I read through your latest security draft and I found the 
> the assertion mechanism described in the Appendix very 
> interesting. One thing I didn't quite understand though is 
> why the ROAP session ID needs to be included in the 
> assertion. As far as I can tell you only need to assert the 
> fingerprint. I would appreciate if you could explain your 
> reasoning here.
> 
> Thanks!
> 
> I should probably admit at this point that I haven't done a 
> complete security analysis of the assertion-based system, so 
> exactly what fields need to be signed is, I think a bit of an 
> open question. I tried to make the level of maturity clear in 
> my draft, but I'm not certain I did.
> 
> With that said, my theory there was that it would be a good 
> idea to cryptographically bind the assertion to this specific 
> session rather than just to the identity in general.
> This prevents replay style attacks. However, as you suggest, 
> it's not entirely clear how one would go about mounting such 
> an attack without simultaneously controlling enough keying 
> material so you could do anything. Do you see a downside to 
> signing this data?
> 
> Best,
> -Ekr
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Nov 2011 00:41:26 -0800

> I had a slightly different scenario in mind when I was posing the question. Say that I have several client certificates (issued by some CA) installed in my browser and I want to use one of them to…

I would assume that whatever mechanism you had for generating
assertions would have them cover the same data values. I.e.,
I'm not yet ready to commit on whether we need the session ID,
but presumably it should always be covered or not.

-Ekr