From stpeter@stpeter.im Mon Aug 22 11:02:29 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBF021F8B64 for ; Mon, 22 Aug 2011 11:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, 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 1idVRbU+TudN for ; Mon, 22 Aug 2011 11:02:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E76F921F8B10 for ; Mon, 22 Aug 2011 11:02:25 -0700 (PDT) Received: from dhcp-64-101-72-239.cisco.com (unknown [64.101.72.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 177F8415A0 for ; Mon, 22 Aug 2011 12:05:44 -0600 (MDT) Message-ID: <4E5299F2.9050208@stpeter.im> Date: Mon, 22 Aug 2011 12:03:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "http-auth@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.3 OpenPGP: url=https://stpeter.im/stpeter.asc X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------080204090103020003000304" Subject: [http-auth] Fwd: [TLS] TLS-OBC proposal X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 18:02:30 -0000 This is a multi-part message in MIME format. --------------080204090103020003000304 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Of interest. -------- Original Message -------- Subject: [TLS] TLS-OBC proposal Date: Mon, 22 Aug 2011 10:53:05 -0700 From: Dirk Balfanz To: tls@ietf.org Dear TLS-WG, I few weeks ago I presented a proposal for an "origin-bound certificates" TLS extension at IETF 81. It's much easier to understand what this extension is trying to accomplish when presented in a broader context of web authentication (which I tried to give in Quebec), so I put together a little web site that is supposed to do just that for those who couldn't be at the IETF meeting: http://browserauth.net (This took me a little while, hence the delay in sending out the I-D). Anyway, here is the I-D: http://tools.ietf.org/html/draft-balfanz-tls-obc, which I submit for your comments/feedback. (Again, remember to read http://browserauth.net for some context.) All feedback is welcome, of course, but if you can't think of anything to comment on, I have a couple particular questions: - in Section 2.1.1 we currently stipulate that the client include the origin of the origin-bound cert as part of the OBC X.509 extension. When we implemented this, we didn't really know what to do with that data on the server side. If the client also uses TLS-SNI, then we could imagine comparing the SNI and OBC origins in some manner on the server side, but there isn't really a vehicle to signal an error back to the client saying "your SNI and OBC origins don't match". Similarly, we could perhaps at some higher layer compare the HTTP "Host" header with the OBC origin, but then again - what do you do when they don't match? Respond with a 400 at the HTTP layer? An alternative to the current language in the I-D would be to simply mark the cert as origin-bound, but without putting the origin itself into the cert. Any thoughts? - What do you think of the privacy-enhancing power of using per-origin certs? The idea there is that different domains see different "identities" (public keys) for the same client. Of course, if two domains choose to collaborate, they can probably find a way to correlate the two identities they see for the same client. This is similar to cookies, where normally "identities" (cookies) for one domain are not revealed to another domain unless, of course, they choose to collaborate. How much privacy would we really lose if we just used one certificate for all origins? It would certainly make the design and implementation simpler. (I tend to favor per-origin certs, but I'm curious as to what other people think.) Thanks for your consideration! Dirk. --------------080204090103020003000304 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1h aWxpbmcgbGlzdApUTFNAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90bHMKCg== --------------080204090103020003000304-- From stephen.farrell@cs.tcd.ie Tue Aug 23 03:43:38 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E9621F8A91 for ; Tue, 23 Aug 2011 03:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 aRyjr5h883EJ for ; Tue, 23 Aug 2011 03:43:25 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7E921F8A55 for ; Tue, 23 Aug 2011 03:43:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id BDCC7171C5F; Tue, 23 Aug 2011 11:44:09 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1314096247; bh=2sbY3fcQ3pPFTO IDkqCuwN3RmJ84PBG+Hi6mKHjtvXY=; b=CXHQqRpNF4ZZFBZAJNv+K79lxvNOy0 EXEpFvY2rwh4tcnWU2Fj93rQWgfyMc+bjoK2mMB02Ja7slnmQDlk1J4mLVFAQXUE jcXD+3A4D2PImOF3olliD9ng3VhrNshXogZMiC4Ivc2ipEKGe59qqDLI5Rkooi0n 0n7RtVuAzUaCMw7EUs6m58ibPQ0siwKajTpCVxK4nCeiiFJLpxtXCjmeUkDXTfM7 A1Ns2H4nodqfRgJnoRspXoTnHYmwTNi2CnNc8iAFHHdF+ZvWKtpmXrL/lG/mhcLm tx1Mov7iDQak/CO7R7OTJ8QgI05ryUGSFmZRa0sjkoh1Pn3yf9rDEI+g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id OzzEO2OP56Oh; Tue, 23 Aug 2011 11:44:07 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 50B3B171C1A; Tue, 23 Aug 2011 11:44:04 +0100 (IST) Message-ID: <4E538469.8020506@cs.tcd.ie> Date: Tue, 23 Aug 2011 11:43:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E5299F2.9050208@stpeter.im> In-Reply-To: <4E5299F2.9050208@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-balfanz-tls-obc@tools.ietf.org, "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: [TLS] TLS-OBC proposal X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 10:43:38 -0000 On 08/22/2011 07:03 PM, Peter Saint-Andre wrote: > Of interest. Indeed. This is quite like the idea I was trying to propose on this list before quebec, but does the negotiation inside TLS rather than as a HTTP authentication scheme. I *think* I'd still prefer the latter, but am wondering if the authors thought about that? One of the reasons it might be better to do this outside TLS is that I think then it'd be easier for a site to allow a user to bind >1 of these cert to the same account (you could provide the URL that allows that as a parameter maybe). Again though, maybe the authors thought that through, which I didn't;-) S. PS: Since the question relates to http auth, I've not cc'd the tls list. > > -------- Original Message -------- > Subject: [TLS] TLS-OBC proposal > Date: Mon, 22 Aug 2011 10:53:05 -0700 > From: Dirk Balfanz > To: tls@ietf.org > > > > Dear TLS-WG, > > I few weeks ago I presented a proposal for an "origin-bound > certificates" TLS extension at IETF 81. It's much easier to understand > what this extension is trying to accomplish when presented in a broader > context of web authentication (which I tried to give in Quebec), so I > put together a little web site that is supposed to do just that for > those who couldn't be at the IETF meeting: http://browserauth.net (This > took me a little while, hence the delay in sending out the I-D). > > Anyway, here is the > I-D: http://tools.ietf.org/html/draft-balfanz-tls-obc, which I submit > for your comments/feedback. (Again, remember to read > http://browserauth.net for some context.) > > All feedback is welcome, of course, but if you can't think of anything > to comment on, I have a couple particular questions: > > - in Section 2.1.1 we currently stipulate that the client include the > origin of the origin-bound cert as part of the OBC X.509 extension. When > we implemented this, we didn't really know what to do with that data on > the server side. If the client also uses TLS-SNI, then we could imagine > comparing the SNI and OBC origins in some manner on the server side, but > there isn't really a vehicle to signal an error back to the client > saying "your SNI and OBC origins don't match". Similarly, we could > perhaps at some higher layer compare the HTTP "Host" header with the OBC > origin, but then again - what do you do when they don't match? Respond > with a 400 at the HTTP layer? An alternative to the current language in > the I-D would be to simply mark the cert as origin-bound, but without > putting the origin itself into the cert. Any thoughts? > > - What do you think of the privacy-enhancing power of using per-origin > certs? The idea there is that different domains see different > "identities" (public keys) for the same client. Of course, if two > domains choose to collaborate, they can probably find a way to correlate > the two identities they see for the same client. This is similar to > cookies, where normally "identities" (cookies) for one domain are not > revealed to another domain unless, of course, they choose to > collaborate. How much privacy would we really lose if we just used one > certificate for all origins? It would certainly make the design and > implementation simpler. (I tend to favor per-origin certs, but I'm > curious as to what other people think.) > > Thanks for your consideration! > > Dirk. > > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From balfanz@google.com Wed Aug 24 23:06:59 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B781F21F8AC3 for ; Wed, 24 Aug 2011 23:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.143 X-Spam-Level: X-Spam-Status: No, score=-105.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, 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 BIoZviM4TFky for ; Wed, 24 Aug 2011 23:06:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0BF21F855B for ; Wed, 24 Aug 2011 23:06:56 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p7P687Kb007805 for ; Wed, 24 Aug 2011 23:08:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314252489; bh=qWSR6FZLvyhqKGgBbJhD0uxAzho=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=QeilqjXJ89/BrN6SW52hqxyOep6HXPySr6H4xbZWdv/E6q32RVjRJ0jMSATg8XIBz tNeztn3g9dk6ZMkeNQ6BQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=mDopSUDmNuSXaGmHtX/OjppzEeBXgYgIDNBeSRbnz1AyJAyq+Rv+CnRDpKWTbH4de LRu9U9GiIiHWFgnsuHxyw== Received: from gyf3 (gyf3.prod.google.com [10.243.50.67]) by hpaq3.eem.corp.google.com with ESMTP id p7P684ZX012377 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 24 Aug 2011 23:08:05 -0700 Received: by gyf3 with SMTP id 3so2017957gyf.17 for ; Wed, 24 Aug 2011 23:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vRoW18YZDmitXJcH68A8Z7/A1f/5Q0mhbnxYx2KU25E=; b=tjvvoQtXBNCcCwxDZirJ09klcEF42x8m0W/I6bx9mSqlIQcmGkvl9Kzh6CnuObTOd3 nP4wgQrX/0hIXWMGZVIw== Received: by 10.91.47.27 with SMTP id z27mr1577755agj.98.1314252484423; Wed, 24 Aug 2011 23:08:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.47.27 with SMTP id z27mr1577745agj.98.1314252484008; Wed, 24 Aug 2011 23:08:04 -0700 (PDT) Received: by 10.90.56.4 with HTTP; Wed, 24 Aug 2011 23:08:03 -0700 (PDT) In-Reply-To: <4E538469.8020506@cs.tcd.ie> References: <4E5299F2.9050208@stpeter.im> <4E538469.8020506@cs.tcd.ie> Date: Wed, 24 Aug 2011 23:08:03 -0700 Message-ID: From: Dirk Balfanz To: Stephen Farrell Content-Type: multipart/alternative; boundary=001485f91e0e745d7604ab4e4035 X-System-Of-Record: true Cc: draft-balfanz-tls-obc@tools.ietf.org, "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: [TLS] TLS-OBC proposal X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 06:06:59 -0000 --001485f91e0e745d7604ab4e4035 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 23, 2011 at 3:43 AM, Stephen Farrell wrote: > > > On 08/22/2011 07:03 PM, Peter Saint-Andre wrote: > >> Of interest. >> > > Indeed. This is quite like the idea I was trying > to propose on this list before quebec, but does > the negotiation inside TLS rather than as a HTTP > authentication scheme. > > I *think* I'd still prefer the latter, but am > wondering if the authors thought about that? > > I'll copy-and-paste a response I gave to a similar question on the TLS list below:: I made a few attempts at doing this on HTTP layer - they didn't really work out. One problem is security: if we look at integrity, for example, TLS gives us that for free. To recreate that, say, at the HTTP layer, we'd have to invent some form of signature on the HTTP request. So immediately the question is: how much of the request do you sign? Do you sign the all headers? The POST body? If you sign the whole POST body, then you can't generate the signature until you've seen the whole POST body. What if the POST body is a multi-gigabyte video? And if the signature goes into the HTTP headers, which must come _before_ the POST body, this means you have read the whole POST body for signing it, and then read it again to pump it out to the network (assuming it's so big that it doesn't fit into whatever buffer you have). Another problem was performance: Signing every single HTTP request with an asymmetric key seems like overkill. So somehow, the server and client would have to negotiate an HMAC key that would be used to sign HTTP requests. That HMAC key would probably be visible to the attacker (which we assume sits in the browser). To decrease the benefit that the attacker has from seeing the HMAC key, we would re-negotiate a new HMAC key every so often, with the client having to re-prove that it is in possession of its private key (we assume that the attacker can't get to the private key, since that can sit in a TPM). It's hard to imagine how to do that on the HTTP or application layer without introducing a roundtrip between client and server that establishes that new HMAC key. While that roundtrip is happening, you can't make other calls to the server (well, you can make 3 others or so depending on how many simultaneous HTTP connections your browser allows with a server, but the point is that you're using one of your limited number of TCP channels for this key renegotiation). In TLS, we have a similar problem - the session master secret might be known to the attacker, so every now and then we'd like to reset it by renegotiating the TLS session. In TLS, however, we can interleave data and handshake messages, so renegotiating the session secret doesn't mean that we're holding up a whole TCP connection. These (and a couple of other) nice features that TLS gives us for free we would end up "reinventing" on the HTTP layer, up to the point where we would have reinvented almost all of TLS. > One of the reasons it might be better to do this > outside TLS is that I think then it'd be easier > for a site to allow a user to bind >1 of these > cert to the same account (you could provide the > URL that allows that as a parameter maybe). > Again though, maybe the authors thought that > through, which I didn't;-) > Just like today you can have multiple cookies "bound" to the same account (e.g., one for the browser session you have open on your desktop, and one for the browser session on your laptop), you can do the same thing with TLS-OBC: you simply bind the cookie that you set on the desktop browser to the desktop browser's cert, and the cookie that you set on the laptop browser to the laptop browser's cert. Does this make sense? Dirk. > > S. > > PS: Since the question relates to http auth, I've > not cc'd the tls list. > > > >> -------- Original Message -------- >> Subject: [TLS] TLS-OBC proposal >> Date: Mon, 22 Aug 2011 10:53:05 -0700 >> From: Dirk Balfanz >> To: tls@ietf.org >> >> >> >> Dear TLS-WG, >> >> I few weeks ago I presented a proposal for an "origin-bound >> certificates" TLS extension at IETF 81. It's much easier to understand >> what this extension is trying to accomplish when presented in a broader >> context of web authentication (which I tried to give in Quebec), so I >> put together a little web site that is supposed to do just that for >> those who couldn't be at the IETF meeting: http://browserauth.net (This >> took me a little while, hence the delay in sending out the I-D). >> >> Anyway, here is the >> I-D: http://tools.ietf.org/html/**draft-balfanz-tls-obc, >> which I submit >> for your comments/feedback. (Again, remember to read >> http://browserauth.net for some context.) >> >> All feedback is welcome, of course, but if you can't think of anything >> to comment on, I have a couple particular questions: >> >> - in Section 2.1.1 we currently stipulate that the client include the >> origin of the origin-bound cert as part of the OBC X.509 extension. When >> we implemented this, we didn't really know what to do with that data on >> the server side. If the client also uses TLS-SNI, then we could imagine >> comparing the SNI and OBC origins in some manner on the server side, but >> there isn't really a vehicle to signal an error back to the client >> saying "your SNI and OBC origins don't match". Similarly, we could >> perhaps at some higher layer compare the HTTP "Host" header with the OBC >> origin, but then again - what do you do when they don't match? Respond >> with a 400 at the HTTP layer? An alternative to the current language in >> the I-D would be to simply mark the cert as origin-bound, but without >> putting the origin itself into the cert. Any thoughts? >> >> - What do you think of the privacy-enhancing power of using per-origin >> certs? The idea there is that different domains see different >> "identities" (public keys) for the same client. Of course, if two >> domains choose to collaborate, they can probably find a way to correlate >> the two identities they see for the same client. This is similar to >> cookies, where normally "identities" (cookies) for one domain are not >> revealed to another domain unless, of course, they choose to >> collaborate. How much privacy would we really lose if we just used one >> certificate for all origins? It would certainly make the design and >> implementation simpler. (I tend to favor per-origin certs, but I'm >> curious as to what other people think.) >> >> Thanks for your consideration! >> >> Dirk. >> >> >> >> >> ______________________________**_________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/**listinfo/http-auth >> > --001485f91e0e745d7604ab4e4035 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 23, 2011 at 3:43 AM, Stephen= Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 08/22/2011 07:03 PM, Peter Saint-Andre wrote:
Of interest.

Indeed. This is quite like the idea I was trying
to propose on this list before quebec, but does
the negotiation inside TLS rather than as a HTTP
authentication scheme.

I *think* I'd still prefer the latter, but am
wondering if the authors thought about that?


I'll copy-and-paste a response I g= ave to a similar question on the TLS list below::

I mad= e a few attempts at doing this on HTTP layer - they didn't really work = out. One problem is security: if we look at integrity, for example, TLS giv= es us that for free. To recreate that, say, at the HTTP layer, we'd hav= e to invent some form of signature on the HTTP request. So immediately the = question is: how much of the request do you sign? Do you sign the all heade= rs? The POST body? If you sign the whole POST body, then you can't gene= rate the signature until you've seen the whole POST body. What if the P= OST body is a multi-gigabyte video? And if the signature goes into the HTTP= headers, which must come _before_ the POST body, this means you have read = the whole POST body for signing it, and then read it again to pump it out t= o the network (assuming it's so big that it doesn't fit into whatev= er buffer you have).=A0

Another problem was performance: Signi= ng every single HTTP request with an asymmetric key seems like overkill. So= somehow, the server and client would have to negotiate an HMAC key that wo= uld be used to sign HTTP requests. That HMAC key would probably be visible = to the attacker (which we assume sits in the browser). To decrease the bene= fit that the attacker has from seeing the HMAC key, we would re-negotiate a= new HMAC key every so often, with the client having to re-prove that it is= in possession of its private key (we assume that the attacker can't ge= t to the private key, since that can sit in a TPM). It's hard to imagin= e how to do that on the HTTP or application layer without introducing a rou= ndtrip between client and server that establishes that new HMAC key. While = that roundtrip is happening, you can't make other calls to the server (= well, you can make 3 others or so depending on how many simultaneous HTTP c= onnections your browser allows with a server, but the point is that you'= ;re using one of your limited number of TCP channels for this key renegotia= tion). In TLS, we have a similar problem - the session master secret might = be known to the attacker, so every now and then we'd like to reset it b= y renegotiating the TLS session. In TLS, however, we can interleave data an= d handshake messages, so renegotiating the session secret doesn't mean = that we're holding up a whole TCP connection.=A0

These (and a couple of other) nice fea= tures that TLS gives us for free we would end up "reinventing" on= the HTTP layer, up to the point where we would have reinvented almost all = of TLS.
=A0
One of the reasons it might be better to do this
outside TLS is that I think then it'd be easier
for a site to allow a user to bind >1 of these
cert to the same account (you could provide the
URL that allows that as a parameter maybe).
Again though, maybe the authors thought that
through, which I didn't;-)

Just lik= e today you can have multiple cookies "bound" to the same account= (e.g., one for the browser session you have open on your desktop, and one = for the browser session on your laptop), you can do the same thing with TLS= -OBC: you simply bind the cookie that you set on the desktop browser to the= desktop browser's cert, and the cookie that you set on the laptop brow= ser to the laptop browser's cert.=A0

Does this make sense?

Dirk.

=A0

S.

PS: Since the question relates to http auth, I've
not cc'd the tls list.



-------- Original Message --------
Subject: =A0 =A0 =A0 =A0[TLS] TLS-OBC proposal
Date: =A0 Mon, 22 Aug 2011 10:53:05 -0700
From: =A0 Dirk Balfanz<balfanz@google.com>
To: =A0 =A0 tls@ietf.org<= /a>



Dear TLS-WG,

I few weeks ago I presented a proposal for an "origin-bound
certificates" TLS extension at IETF 81. It's much easier to unders= tand
what this extension is trying to accomplish when presented in a broader
context of web authentication (which I tried to give in Quebec), so I
put together a little web site that is supposed to do just that for
those who couldn't be at the IETF meeting: http://browserauth.net (This
took me a little while, hence the delay in sending out the I-D).

Anyway, here is the
I-D: http://tools.ietf.org/html/draft-balfanz-tls-obc, which= I submit
for your comments/feedback. (Again, remember to read
http://browserauth.net= for some context.)

All feedback is welcome, of course, but if you can't think of anything<= br> to comment on, I have a couple particular questions:

- in Section 2.1.1 we currently stipulate that the client include the
origin of the origin-bound cert as part of the OBC X.509 extension. When we implemented this, we didn't really know what to do with that data on=
the server side. If the client also uses TLS-SNI, then we could imagine
comparing the SNI and OBC origins in some manner on the server side, but there isn't really a vehicle to signal an error back to the client
saying "your SNI and OBC origins don't match". Similarly, we = could
perhaps at some higher layer compare the HTTP "Host" header with = the OBC
origin, but then again - what do you do when they don't match? Respond<= br> with a 400 at the HTTP layer? An alternative to the current language in
the I-D would be to simply mark the cert as origin-bound, but without
putting the origin itself into the cert. Any thoughts?

- What do you think of the privacy-enhancing power of using per-origin
certs? The idea there is that different domains see different
"identities" (public keys) for the same client. Of course, if two=
domains choose to collaborate, they can probably find a way to correlate the two identities they see for the same client. This is similar to
cookies, where normally "identities" (cookies) for one domain are= not
revealed to another domain unless, of course, they choose to
collaborate. How much privacy would we really lose if we just used one
certificate for all origins? It would certainly make the design and
implementation simpler. (I tend to favor per-origin certs, but I'm
curious as to what other people think.)

Thanks for your consideration!

Dirk.




_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth

--001485f91e0e745d7604ab4e4035-- From yutaka-oiwa-aist-temp@g.oiwa.jp Wed Aug 24 23:51:42 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4154821F8AF6 for ; Wed, 24 Aug 2011 23:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.144 X-Spam-Level: X-Spam-Status: No, score=-4.144 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 T5O5HJpG7oJ3 for ; Wed, 24 Aug 2011 23:51:41 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 12B3321F8AF4 for ; Wed, 24 Aug 2011 23:51:40 -0700 (PDT) Received: by ywe9 with SMTP id 9so1754526ywe.31 for ; Wed, 24 Aug 2011 23:52:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.13.21 with SMTP id 21mr474751ybm.125.1314255172429; Wed, 24 Aug 2011 23:52:52 -0700 (PDT) Sender: yutaka@g.oiwa.jp X-Google-Sender-Delegation: yutaka@g.oiwa.jp Received: by 10.150.189.6 with HTTP; Wed, 24 Aug 2011 23:52:52 -0700 (PDT) In-Reply-To: References: <4E5299F2.9050208@stpeter.im> <4E538469.8020506@cs.tcd.ie> Date: Thu, 25 Aug 2011 15:52:52 +0900 X-Google-Sender-Auth: tnCYzsyp9IxuU3iSlYcikdNEI6E Message-ID: From: Yutaka OIWA To: Dirk Balfanz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-balfanz-tls-obc@tools.ietf.org, "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: [TLS] TLS-OBC proposal X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 06:51:42 -0000 Hi Dirk, This does support for use of TLS, but does not support for doing authentication and authorization in TLS. Your point mentioned seems to be solved by the major solution which has already been widely deployed: using TLS for encryption and basic server authentication, and performing authentication in the application layer. What we need here more are strong authentication and channel binding (which I am proposing one of them). Doing authentication in the lower layer like TLS brings too much complexity and inconvenience to both applications and users. Apart from TLS-OBC for a while, for example, TLS-SRP will work on Web only for very simple web application, but it cannot support any good user experiences for conventional large websites which usually need much control of how and when the users will be authenticated and authorized. TLS-OBC seems to be a bit different in this situation, but can you give me some more hint on the sales point of TLS-OBS, compared to using the combination of conventional TLS, some secure session management (e.g. secure cookie), HTTP or application-la= yer authentication (which the TLS-OBS is already relying on), and channel binding among those? And one another word, you've mentioned about use of TLS renegotiation for resetting the key, but please never rely on TLS renegotiation for any means other than re-establishing the session key independently with the upper-lay= er's requirements (e.g. solely controlled by the number of bits sent or the time since key generation). Controlling TLS's behavior from the application layer seems never be realistic to be implemented and deployed, especially on the Web server side. This requirement is very stro= ng especially on the Web system than others, because Web server (which has TLS capability) and Web applications are separate entities with loose coupling interfaces. This is not the case for other services like SMTP or IMAP: each mail server itself handles both TLS and the application logic in a single application, so they can e.g. kick in TLS-SRP using TLS renegotiation if desired. 2011/8/25 Dirk Balfanz : > > > On Tue, Aug 23, 2011 at 3:43 AM, Stephen Farrell > wrote: >> >> >> On 08/22/2011 07:03 PM, Peter Saint-Andre wrote: >>> >>> Of interest. >> >> Indeed. This is quite like the idea I was trying >> to propose on this list before quebec, but does >> the negotiation inside TLS rather than as a HTTP >> authentication scheme. >> >> I *think* I'd still prefer the latter, but am >> wondering if the authors thought about that? >> > > I'll copy-and-paste a response I gave to a similar question on the TLS li= st > below:: > I made a few attempts at doing this on HTTP layer - they didn't really wo= rk > out. One problem is security: if we look at integrity, for example, TLS > gives us that for free. To recreate that, say, at the HTTP layer, we'd ha= ve > to invent some form of signature on the HTTP request. So immediately the > question is: how much of the request do you sign? Do you sign the all > headers? The POST body? If you sign the whole POST body, then you can't > generate the signature until you've seen the whole POST body. What if the > POST body is a multi-gigabyte video? And if the signature goes into the H= TTP > headers, which must come _before_ the POST body, this means you have read > the whole POST body for signing it, and then read it again to pump it out= to > the network (assuming it's so big that it doesn't fit into whatever buffe= r > you have). > > Another problem was performance: Signing every single HTTP request with a= n > asymmetric key seems like overkill. So somehow, the server and client wou= ld > have to negotiate an HMAC key that would be used to sign HTTP requests. T= hat > HMAC key would probably be visible to the attacker (which we assume sits = in > the browser). To decrease the benefit that the attacker has from seeing t= he > HMAC key, we would re-negotiate a new HMAC key every so often, with the > client having to re-prove that it is in possession of its private key (we > assume that the attacker can't get to the private key, since that can sit= in > a TPM). It's hard to imagine how to do that on the HTTP or application la= yer > without introducing a roundtrip between client and server that establishe= s > that new HMAC key. While that roundtrip is happening, you can't make othe= r > calls to the server (well, you can make 3 others or so depending on how m= any > simultaneous HTTP connections your browser allows with a server, but the > point is that you're using one of your limited number of TCP channels for > this key renegotiation). In TLS, we have a similar problem - the session > master secret might be known to the attacker, so every now and then we'd > like to reset it by renegotiating the TLS session. In TLS, however, we ca= n > interleave data and handshake messages, so renegotiating the session secr= et > doesn't mean that we're holding up a whole TCP connection. > > These (and a couple of other) nice features that TLS gives us for free we > would end up "reinventing" on the HTTP layer, up to the point where we wo= uld > have reinvented almost all of TLS. > >> >> One of the reasons it might be better to do this >> outside TLS is that I think then it'd be easier >> for a site to allow a user to bind >1 of these >> cert to the same account (you could provide the >> URL that allows that as a parameter maybe). >> Again though, maybe the authors thought that >> through, which I didn't;-) > > Just like today you can have multiple cookies "bound" to the same account > (e.g., one for the browser session you have open on your desktop, and one > for the browser session on your laptop), you can do the same thing with > TLS-OBC: you simply bind the cookie that you set on the desktop browser t= o > the desktop browser's cert, and the cookie that you set on the laptop > browser to the laptop browser's cert. > Does this make sense? > Dirk. > >> >> S. >> >> PS: Since the question relates to http auth, I've >> not cc'd the tls list. >> >> >>> >>> -------- Original Message -------- >>> Subject: =A0 =A0 =A0 =A0[TLS] TLS-OBC proposal >>> Date: =A0 Mon, 22 Aug 2011 10:53:05 -0700 >>> From: =A0 Dirk Balfanz >>> To: =A0 =A0 tls@ietf.org >>> >>> >>> >>> Dear TLS-WG, >>> >>> I few weeks ago I presented a proposal for an "origin-bound >>> certificates" TLS extension at IETF 81. It's much easier to understand >>> what this extension is trying to accomplish when presented in a broader >>> context of web authentication (which I tried to give in Quebec), so I >>> put together a little web site that is supposed to do just that for >>> those who couldn't be at the IETF meeting: http://browserauth.net (This >>> took me a little while, hence the delay in sending out the I-D). >>> >>> Anyway, here is the >>> I-D: http://tools.ietf.org/html/draft-balfanz-tls-obc, which I submit >>> for your comments/feedback. (Again, remember to read >>> http://browserauth.net for some context.) >>> >>> All feedback is welcome, of course, but if you can't think of anything >>> to comment on, I have a couple particular questions: >>> >>> - in Section 2.1.1 we currently stipulate that the client include the >>> origin of the origin-bound cert as part of the OBC X.509 extension. Whe= n >>> we implemented this, we didn't really know what to do with that data on >>> the server side. If the client also uses TLS-SNI, then we could imagine >>> comparing the SNI and OBC origins in some manner on the server side, bu= t >>> there isn't really a vehicle to signal an error back to the client >>> saying "your SNI and OBC origins don't match". Similarly, we could >>> perhaps at some higher layer compare the HTTP "Host" header with the OB= C >>> origin, but then again - what do you do when they don't match? Respond >>> with a 400 at the HTTP layer? An alternative to the current language in >>> the I-D would be to simply mark the cert as origin-bound, but without >>> putting the origin itself into the cert. Any thoughts? >>> >>> - What do you think of the privacy-enhancing power of using per-origin >>> certs? The idea there is that different domains see different >>> "identities" (public keys) for the same client. Of course, if two >>> domains choose to collaborate, they can probably find a way to correlat= e >>> the two identities they see for the same client. This is similar to >>> cookies, where normally "identities" (cookies) for one domain are not >>> revealed to another domain unless, of course, they choose to >>> collaborate. How much privacy would we really lose if we just used one >>> certificate for all origins? It would certainly make the design and >>> implementation simpler. (I tend to favor per-origin certs, but I'm >>> curious as to what other people think.) >>> >>> Thanks for your consideration! >>> >>> Dirk. >>> >>> >>> >>> >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From stephen.farrell@cs.tcd.ie Thu Aug 25 01:49:49 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B0821F8AF2 for ; Thu, 25 Aug 2011 01:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 V1dqDeO9h-rP for ; Thu, 25 Aug 2011 01:49:49 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id CC55C21F8AF0 for ; Thu, 25 Aug 2011 01:49:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6B6EA153576; Thu, 25 Aug 2011 09:50:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1314262236; bh=Bkk5SF3ZnxMG7p /wsaPz/d17n7asNve2esrnrw94KyM=; b=l0unzGrptklRPi+B9tuaDasLLje1vo 2OkWieZzeqwPMleboGZjGbT6Ca9XighuWppJzIlEOygGRjRNoCdnuQETHV/3+z5a 23Tfi7weQQx1e/Bc09w3cWr6owA+vtM6ZaIeLjWKa1nD5ppHzzNLvGjR+PzADlzf APedG9VJL+sLYGQQvBo2qsJa0MJASXYCU8uEsuBBFKrsVvp+PJ/HLdkSVAazvvw6 Ef517cEqS0wS46TxeWFzRMydiqkV1zdPa4Mrmrf8Xbm3VemfGpReF3N/k4zbdVx9 mBnlYrL79K70Q5qyZ+lehCjS9x9p0zLrIkweSso2hNwKHqzbyo1JEHfQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id dz4f+VkhUBy3; Thu, 25 Aug 2011 09:50:36 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B280215356C; Thu, 25 Aug 2011 09:50:31 +0100 (IST) Message-ID: <4E560CD6.9070100@cs.tcd.ie> Date: Thu, 25 Aug 2011 09:50:30 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Dirk Balfanz References: <4E5299F2.9050208@stpeter.im> <4E538469.8020506@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-balfanz-tls-obc@tools.ietf.org, "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: [TLS] TLS-OBC proposal X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 08:49:50 -0000 On 08/25/2011 07:08 AM, Dirk Balfanz wrote: > On Tue, Aug 23, 2011 at 3:43 AM, Stephen Farrell > wrote: > >> >> >> On 08/22/2011 07:03 PM, Peter Saint-Andre wrote: >> >>> Of interest. >>> >> >> Indeed. This is quite like the idea I was trying >> to propose on this list before quebec, but does >> the negotiation inside TLS rather than as a HTTP >> authentication scheme. >> >> I *think* I'd still prefer the latter, but am >> wondering if the authors thought about that? >> >> > I'll copy-and-paste a response I gave to a similar question on the TLS list > below:: Yep, saw that there, but its the answer to a different question:-) What I was thinking about was having a HTTP authentication scheme that flagged that the server supported OBC (or equivalent) and then having the client (re)negotiate TLS with a new or existing OBC cert. So basically using TLS as-is in protocol terms, but flagging the OBC stuff in HTTP. > >> One of the reasons it might be better to do this >> outside TLS is that I think then it'd be easier >> for a site to allow a user to bind>1 of these >> cert to the same account (you could provide the >> URL that allows that as a parameter maybe). >> Again though, maybe the authors thought that >> through, which I didn't;-) >> > > Just like today you can have multiple cookies "bound" to the same account > (e.g., one for the browser session you have open on your desktop, and one > for the browser session on your laptop), you can do the same thing with > TLS-OBC: you simply bind the cookie that you set on the desktop browser to > the desktop browser's cert, and the cookie that you set on the laptop > browser to the laptop browser's cert. > > Does this make sense? Again I think you're answering a different question. The issue with any TLS-mutual auth scheme is that the user with >1 device needs a way to bind those TLS client certs to one account. I think for any TLS mutual auth scheme to work we need a way to do that, including OBC or equivalent. I was asking if there's a way to do that with your scheme, and suggesting that maybe it'd be easier to do if the negotiation of OBC happened at the HTTP layer. S. > > Dirk. > > > >> >> S. >> >> PS: Since the question relates to http auth, I've >> not cc'd the tls list. >> >> >> >>> -------- Original Message -------- >>> Subject: [TLS] TLS-OBC proposal >>> Date: Mon, 22 Aug 2011 10:53:05 -0700 >>> From: Dirk Balfanz >>> To: tls@ietf.org >>> >>> >>> >>> Dear TLS-WG, >>> >>> I few weeks ago I presented a proposal for an "origin-bound >>> certificates" TLS extension at IETF 81. It's much easier to understand >>> what this extension is trying to accomplish when presented in a broader >>> context of web authentication (which I tried to give in Quebec), so I >>> put together a little web site that is supposed to do just that for >>> those who couldn't be at the IETF meeting: http://browserauth.net (This >>> took me a little while, hence the delay in sending out the I-D). >>> >>> Anyway, here is the >>> I-D: http://tools.ietf.org/html/**draft-balfanz-tls-obc, >>> which I submit >>> for your comments/feedback. (Again, remember to read >>> http://browserauth.net for some context.) >>> >>> All feedback is welcome, of course, but if you can't think of anything >>> to comment on, I have a couple particular questions: >>> >>> - in Section 2.1.1 we currently stipulate that the client include the >>> origin of the origin-bound cert as part of the OBC X.509 extension. When >>> we implemented this, we didn't really know what to do with that data on >>> the server side. If the client also uses TLS-SNI, then we could imagine >>> comparing the SNI and OBC origins in some manner on the server side, but >>> there isn't really a vehicle to signal an error back to the client >>> saying "your SNI and OBC origins don't match". Similarly, we could >>> perhaps at some higher layer compare the HTTP "Host" header with the OBC >>> origin, but then again - what do you do when they don't match? Respond >>> with a 400 at the HTTP layer? An alternative to the current language in >>> the I-D would be to simply mark the cert as origin-bound, but without >>> putting the origin itself into the cert. Any thoughts? >>> >>> - What do you think of the privacy-enhancing power of using per-origin >>> certs? The idea there is that different domains see different >>> "identities" (public keys) for the same client. Of course, if two >>> domains choose to collaborate, they can probably find a way to correlate >>> the two identities they see for the same client. This is similar to >>> cookies, where normally "identities" (cookies) for one domain are not >>> revealed to another domain unless, of course, they choose to >>> collaborate. How much privacy would we really lose if we just used one >>> certificate for all origins? It would certainly make the design and >>> implementation simpler. (I tend to favor per-origin certs, but I'm >>> curious as to what other people think.) >>> >>> Thanks for your consideration! >>> >>> Dirk. >>> >>> >>> >>> >>> ______________________________**_________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/**listinfo/http-auth >>> >> >