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