Re: [rtcweb] Regarding the assertion mechanism in the new security draft
Eric Rescorla <ekr@rtfm.com> Fri, 11 November 2011 16:45 UTC
Return-Path: <ekr@rtfm.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 34A7221F88AB for <rtcweb@ietfa.amsl.com>; Fri, 11 Nov 2011 08:45:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.943
X-Spam-Level:
X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 pHtjisNgXS0m for <rtcweb@ietfa.amsl.com>; Fri, 11 Nov 2011 08:45:14 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1E321F87FA for <rtcweb@ietf.org>; Fri, 11 Nov 2011 08:45:14 -0800 (PST)
Received: by vcbfk1 with SMTP id fk1so4152066vcb.31 for <rtcweb@ietf.org>; Fri, 11 Nov 2011 08:45:14 -0800 (PST)
Received: by 10.220.187.136 with SMTP id cw8mr1483287vcb.266.1321029914084; Fri, 11 Nov 2011 08:45:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.118.132 with HTTP; Fri, 11 Nov 2011 08:44:32 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <A1B638D2082DEA4092A268AA8BEF294D180B8F333B@ESESSCMS0360.eemea.ericsson.se>
References: <A1B638D2082DEA4092A268AA8BEF294D180B8F333B@ESESSCMS0360.eemea.ericsson.se>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 11 Nov 2011 08:44:32 -0800
Message-ID: <CABcZeBM8uhr5fxkcFy7Vob6zmF5Q9QzVAnHBR74w8o+LazysAA@mail.gmail.com>
To: Oscar Ohlsson <oscar.ohlsson@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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: Fri, 11 Nov 2011 16:45:15 -0000
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
- [rtcweb] Regarding the assertion mechanism in the… Oscar Ohlsson
- Re: [rtcweb] Regarding the assertion mechanism in… Eric Rescorla
- Re: [rtcweb] Regarding the assertion mechanism in… Eric Rescorla
- Re: [rtcweb] Regarding the assertion mechanism in… Oscar Ohlsson