Re: [TLS] TLS-OBC proposal
Nikos Mavrogiannopoulos <nmav@gnutls.org> Sun, 04 September 2011 12:41 UTC
Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1663621F8581 for <tls@ietfa.amsl.com>; Sun, 4 Sep 2011 05:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.566
X-Spam-Level:
X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, 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 vrW7iFUWLO8S for <tls@ietfa.amsl.com>; Sun, 4 Sep 2011 05:41:31 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC0E021F8538 for <tls@ietf.org>; Sun, 4 Sep 2011 05:41:30 -0700 (PDT)
Received: by wwf5 with SMTP id 5so2805148wwf.13 for <tls@ietf.org>; Sun, 04 Sep 2011 05:43:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8o4P5CMfPrjO5qx3ff7vsc+7OQYlay7JSik3j9ieSTM=; b=aOQrBXJxVYJAapZ7jvrYrpEnA+ttcY0xPCAN3UtsWPKRbx6izxk3tbAzXVwU6FyOgl 5IbmdM8JvQFql7tmmZ58qOlm3QPJmKpyHqv9KUDdQSGRX+cvcmVW36zWX75LrBdapkyx S85Hjlftm2rf4k5o1j8e2GlL+aI8l/2N5mHR8=
Received: by 10.227.10.67 with SMTP id o3mr2856692wbo.26.1315140191401; Sun, 04 Sep 2011 05:43:11 -0700 (PDT)
Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id fo14sm4784567wbb.19.2011.09.04.05.43.09 (version=SSLv3 cipher=OTHER); Sun, 04 Sep 2011 05:43:10 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4E637262.3040007@gnutls.org>
Date: Sun, 04 Sep 2011 14:43:14 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110820 Icedove/3.1.12
MIME-Version: 1.0
To: Dirk Balfanz <balfanz@google.com>
References: <CADHfa2AMOeShxH_k5ZEB3DUVJAnOqvZmLMg5Yz8smtBDGkQsNg@mail.gmail.com> <4E5F71AC.5090900@gnutls.org> <CADHfa2Ad2dU5FkaDjZA6Hn+gnp_crf6Phw9eJMqfg8gd9Kdeyw@mail.gmail.com>
In-Reply-To: <CADHfa2Ad2dU5FkaDjZA6Hn+gnp_crf6Phw9eJMqfg8gd9Kdeyw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] TLS-OBC proposal
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Sep 2011 12:41:32 -0000
On 09/02/2011 07:21 PM, Dirk Balfanz wrote: >> * In http://www.browserauth.net/**tls-client-authentication<http://www.browserauth.net/tls-client-authentication>you mention the inability to log-out as one reason that TLS client >> authentication fails. However this is not addressed by OBC if I understand >> correctly. (to be honest I think that the inability to log-out is just a UI >> problem. TLS authentication does not need to imply log-in. You might have >> buttons login and logout that will log the user in and out even if TLS with >> authentication was used) > The site where I wrote the documentation - browserauth.net - is an example > for this. There is a sign-in link at the bottom of each page. Are you saying > that with TLS Client Auth, the server would require a certificate from the > client, and the user would have to decide upfront whether or not to supply a > certificate. Then, when the user gives no certificate or a "wrong" > certificate, there would be no sign-in link on the site (but it would still > render), but when the "right" certificate is given by the user, then the > server would give the user a sign-in link on the page? At that point, the > sign-in link isn't really about signing in. It's more a "you already know > who I am, please give me some edit controls on this page"-link. Also, note > that the user had to decide whether or not to provide a certificate before > they saw the page. > With TLS-OBC, you have the normal cookie model. The first time you go to the > site, you have no cookies. It's up to the server to decide whether or not it > can give you a meaningful UI in that case (browserauth.net decides that it > can). Then, when it's time to reveal to the server who you are, you click on > the sign-in link, and eventually end up with a cookie that you send to the > server, which will allow it to identify you, and draw a "logged-in" state > UI. > I totally agree that this a UI issue - a pretty subtle one. But I think that > TLS Client Auth will dictate a different UI from what we're used to today, > whereas TLS-OBC with cookies will allow us to stick to the same UIs we have > today. Indeed, but you still use client certificate authentication. The difference is that there is no trusted party certifying the client's name and the 1-1 mapping to certificates with sites. > The critical extension is there so that these certificates can't be used out > of context. For example, we require the server to check that the extension > is there, or else reject the certificate. [...] > A separate question is whether that string (the origin) should be in the > cert to begin with. I take it that your inclination would be to not include > it, which is what I'm also considering now. I find your point above quite interesting (preventing (re)use in different contexts). It might be worth keeping it. regards, Nikos
- [TLS] TLS-OBC proposal Dirk Balfanz
- Re: [TLS] TLS-OBC proposal Anders Rundgren
- Re: [TLS] TLS-OBC proposal Chris Richardson
- Re: [TLS] TLS-OBC proposal Wan-Teh Chang
- Re: [TLS] TLS-OBC proposal Chris Newman
- Re: [TLS] TLS-OBC proposal Dirk Balfanz
- Re: [TLS] TLS-OBC proposal Dirk Balfanz
- Re: [TLS] TLS-OBC proposal Dirk Balfanz
- Re: [TLS] TLS-OBC proposal Nikos Mavrogiannopoulos
- Re: [TLS] TLS-OBC proposal Dirk Balfanz
- Re: [TLS] TLS-OBC proposal Nikos Mavrogiannopoulos
- Re: [TLS] TLS-OBC proposal Anders Rundgren
- Re: [TLS] TLS-OBC proposal Nikos Mavrogiannopoulos
- Re: [TLS] TLS-OBC proposal Anders Rundgren
- Re: [TLS] TLS-OBC proposal Martin Rex
- Re: [TLS] TLS-OBC proposal Nico Williams
- Re: [TLS] TLS-OBC proposal Nico Williams
- Re: [TLS] TLS-OBC proposal Nico Williams