IETF Logo Mail Archive

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

Oscar Ohlsson <oscar.ohlsson@ericsson.com> Mon, 14 November 2011 08:36 UTC

Return-Path: <oscar.ohlsson@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CDE21F8DB7 for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 00:36:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UFFhNuYTYjZ for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 00:36:17 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 28ADD21F8DB6 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 00:36:16 -0800 (PST)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-a5-4ec0d2ff0ba8
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EE.2E.13753.FF2D0CE4; Mon, 14 Nov 2011 09:36:15 +0100 (CET)
Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.198]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 14 Nov 2011 09:36:15 +0100
From: Oscar Ohlsson <oscar.ohlsson@ericsson.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 14 Nov 2011 09:36:13 +0100
Thread-Topic: Regarding the assertion mechanism in the new security draft
Thread-Index: AcygkUmAUf6KuCOmRvqUz79XUI8r/ACFxEQw
Message-ID: <A1B638D2082DEA4092A268AA8BEF294D180B8F3616@ESESSCMS0360.eemea.ericsson.se>
References: <A1B638D2082DEA4092A268AA8BEF294D180B8F333B@ESESSCMS0360.eemea.ericsson.se> <CABcZeBM8uhr5fxkcFy7Vob6zmF5Q9QzVAnHBR74w8o+LazysAA@mail.gmail.com>
In-Reply-To: <CABcZeBM8uhr5fxkcFy7Vob6zmF5Q9QzVAnHBR74w8o+LazysAA@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: sv-SE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Regarding the assertion mechanism in the new security draft
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Nov 2011 08:36:18 -0000

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:ekr@rtfm.com] 
> Sent: den 11 november 2011 17:45
> To: Oscar Ohlsson
> Cc: rtcweb@ietf.org
> Subject: Re: Regarding the assertion mechanism in the new 
> security draft
> 
> On Fri, Nov 11, 2011 at 7:42 AM, Oscar Ohlsson 
> <oscar.ohlsson@ericsson.com> wrote:
> > 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.
> 
> 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
>

v2.23.0 | Report a Bug | By Email