Re: [TLS] HTTPS client-certificate-authentication in browsers

Henry Story <henry.story@bblfish.net> Thu, 28 July 2011 11:12 UTC

Return-Path: <henry.story@bblfish.net>
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 4C93221F8AD8 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 04:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.083
X-Spam-Level:
X-Spam-Status: No, score=-1.083 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, FB_MAKE_MONEY=1.555, J_CHICKENPOX_43=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvNzXey5RTpt for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 04:12:19 -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 EC3AD21F8AFA for <tls@ietf.org>; Thu, 28 Jul 2011 04:12:18 -0700 (PDT)
Received: by wwe5 with SMTP id 5so1557445wwe.13 for <tls@ietf.org>; Thu, 28 Jul 2011 04:12:16 -0700 (PDT)
Received: by 10.227.178.203 with SMTP id bn11mr7484817wbb.51.1311851536667; Thu, 28 Jul 2011 04:12:16 -0700 (PDT)
Received: from bblfish.home (AAubervilliers-651-1-161-132.w81-249.abo.wanadoo.fr [81.249.172.132]) by mx.google.com with ESMTPS id s12sm595585wec.32.2011.07.28.04.12.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 04:12:15 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset="iso-8859-1"
From: Henry Story <henry.story@bblfish.net>
In-Reply-To: <4E313B9C.3040104@telia.com>
Date: Thu, 28 Jul 2011 13:12:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A31F868F-0D95-4A31-A86A-57BE8BECB7AE@bblfish.net>
References: <mailman.1209.1311842548.23921.tls@ietf.org> <4E31299F.6060400@restena.lu> <4E3131AA.5010703@telia.com> <54838E8A-26D3-4B8E-9F0E-F03C3CF3AA86@bblfish.net> <4E313B9C.3040104@telia.com>
To: Anders Rundgren <anders.rundgren@telia.com>
X-Mailer: Apple Mail (2.1244.3)
Cc: Stefan Winter <stefan.winter@restena.lu>, tls@ietf.org
Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers
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: Thu, 28 Jul 2011 11:12:20 -0000

On 28 Jul 2011, at 12:36, Anders Rundgren wrote:

> Henry,
> You're missing the point.
> 
> These two guys says that having a key in the PC is braindead,
> particularly if you use it from a browser.

> Based on 15 years of experience of s.c. "security experts" we
> can safely drop this thread; it won't go anywhere.
> 
> This attitude was OK before we entered the "Google- and Apple-age".
> It's an entirely different ball-game now!

I hear different voices in this conversation. But the best thing
will be to build examples that can show how this technology can be
used in new ways. All good technology is like that: it escapes the
initial ideas of its creators.


> 
> Anders
> 
> On 2011-07-28 12:08, Henry Story wrote:
>> 
>> On 28 Jul 2011, at 11:53, Anders Rundgren wrote:
>> 
>>> http://www.hbci-kernel.de/fints.htm
>>> 
>>> I'm happy that none the banks I have talked have any interests
>>> in such crap.
>>> 
>>> The usage level of the German eID is hardly measurable either.
>>> 
>>> /A
>>> 
>>> On 2011-07-28 11:19, Stefan Winter wrote:
>>>> Hi,
>>>> 
>>>>>>> Lots of banks wants to use CCA for their users.
>>>>>>> 
>>>>>>> That is a non sequitur.
>>>>>>> 
>>>>>>> Banks (here in Germany) have abandoned tradtional TANs based on
>>>>>>> the unconditional presumption that client PCs are infested with
>>>>>>> malware, and most banks in Germany are currently replacing indexed TANs (iTAN)
>>>>>>> presumably based on the perception that malware on clients (trojans/phishing)
>>>>>>> has caught up with iTAN procedure complexity.
>>>>>>> 
>>>>>>> At this point, with the presumption that all client PCs are
>>>>>>> thoroughly infested with malware, going for a Single Sign-On
>>>>>>> mechanism would be completely braindead and irresponsible.
>>>>> So using client certificates for authentication is such a bad idea that
>>>>> there is no point in looking into issues on how to make it better?
>>>>> 
>>>>> How is the German e-card supposed work then?
>>>> 
>>>> Just trolling around on this list every now and then, but can't resist
>>>> to comment because I got my new eID card and also HBCI access recently.
>>>> 
>>>> eID: The electronic identity card contains lots of personal details
>>>> about you in some credential storage. It must be put into a whitelisted,
>>>> EAL-whatever certified hardware device, connected via USB. There is one
>>>> well-defined application on your computer which can ask the reader to
>>>> retrieve a *subset* of the personal information stored. Other
>>>> applications on the computer talk to this one application via an API.
>>>> Your card reader will present the name of the application which wants
>>>> the data, the pieces of data it wants to have from your card, and will
>>>> ask for your authorisation to reveal that personal data. That is done
>>>> via display+PIN directly on the card reader; no secret information ever
>>>> leaks the card reader unless authorized directly on the device by the
>>>> user. [1]
>>>> 
>>>> This exhibits a property of the system which plain presentation of a
>>>> X.509 certs won't allow: send only a subset of the stored information.
>> 
>> Here I disagree. A system build with WebID enabled X509 certificates should be able to release subsets of information too. But instead of having the information come from your device, or be locked in the certificate, the information can come from RESTful access to your profile, or to related resources.
>> 
>> Here is one way to do this:
>> 
>> http://blogs.oracle.com/bblfish/entry/sketch_of_a_restful_photo
>> 
>> This is just a generalisation of what your devices do. Think of adding a web server to the device in question. Then give profiles a URL, and then only show parts of the information to the authentified service requesting them. Now there is no reason to put a web server on that device, you might as well have it wherever you think is best. If you do that, you are starting to see how http://webid.info can work.
>> 
>> Henry
>> 
>> 
>>>> 
>>>> It was refreshing to see this in action when I got my reader last week:
>>>> my car insurance website signalled they need my real name, birthdate and
>>>> birthplace to log me in to manage my insurance contract - not the rest
>>>> of "me" that the card stores as well. Did that, logged into their
>>>> website, no need to even create a username/password combo.
>>>> 
>>>> Note that I didn't use the term "client certificate" at all - the system
>>>> does involve PKI, but it's invisible to the user; all he has is a
>>>> hardware token and a PIN.
>>>> 
>>>> Sure: you need the card reader. Joe Sixpack can manage to go to a shop
>>>> and put money on the shelf to get it, I assume - he does that same thing
>>>> when buying a TV. Joe doesn't even have to know or care about how to get
>>>> a "certificate" - he just gets all the stuff piggybacked on his usual
>>>> plastic ID card.
>>>> 
>>>> Banking: These days, TAN lists are going away. Alternatively, several
>>>> approaches come into use:
>>>> 
>>>> a) cell phone transaction numbers: enter transaction details on website,
>>>> website generates a TAN for this very transaction, sends it along with
>>>> the input it received from you to your (pre-registered) cell phone, you
>>>> enter the number from the cell phone into the website. - A second,
>>>> independent channel makes sure that even if the PC's comms channel is
>>>> compromised, harm is prevented.
>>>> 
>>>> b) offline generated transaction numbers. You get a hardware device,
>>>> branded to your bank account (provisioned secrets). Its only interface
>>>> to the outside world is a black&white camera to read a bar code; and a
>>>> display to show a resulting TAN. Workflow is: you enter your transaction
>>>> details on the web site, they generate $SOMEDATA from it (which includes
>>>> the transaction details). $SOMEDATA is signalled to the hardware device
>>>> via barcode scan, which uses it to generate a TAN based on the
>>>> pre-provisioned secrets and $SOMEDATA. Bank does the same computation,
>>>> TANs must match. Again, a second channel comes to the rescue even if the
>>>> PC is compromised.
>>>> 
>>>> c) HBCI - Home Banking Computer Interface. There is no browser at
>>>> all(!). An application uses the HBCI API to talk to bank servers. Client
>>>> authenticates with a smart card to be put into a card reader. All crypto
>>>> again happens on the card reader. Joe sixpack gets the smart card+PIN by
>>>> checking a box on his bank acocunt application and doesn't need to know
>>>> anything more.
>>>> 
>>>> None of these use Client Certificates in a browser. All of them survive
>>>> if the PC is malware-infested. But yes, there are still attacks on these
>>>> - they are not the cure-all.
>>>> 
>>>> Greetings,
>>>> 
>>>> Stefan Winter
>>>> 
>>>> [1] There are also readers without a keyboard. If you use these, too bad
>>>> for you, because then your infested PC will log your PIN and so on.
>>>> Because of that, the system got quite some beating when introduced.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>>> 
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 
> 

Social Web Architect
http://bblfish.net/