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

Eric Rescorla <> Fri, 11 November 2011 16:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34A7221F88AB for <>; Fri, 11 Nov 2011 08:45:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.943
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pHtjisNgXS0m for <>; Fri, 11 Nov 2011 08:45:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9B1E321F87FA for <>; Fri, 11 Nov 2011 08:45:14 -0800 (PST)
Received: by vcbfk1 with SMTP id fk1so4152066vcb.31 for <>; Fri, 11 Nov 2011 08:45:14 -0800 (PST)
Received: by with SMTP id cw8mr1483287vcb.266.1321029914084; Fri, 11 Nov 2011 08:45:14 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 11 Nov 2011 08:44:32 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Fri, 11 Nov 2011 08:44:32 -0800
Message-ID: <>
To: Oscar Ohlsson <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [rtcweb] Regarding the assertion mechanism in the new security draft
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Nov 2011 16:45:15 -0000

On Fri, Nov 11, 2011 at 7:42 AM, Oscar Ohlsson
<> 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.


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