[KI-LC] PKI vs Non-PKI based trust models

Bob Pinheiro kantara at bobpinheiro.com
Fri Mar 18 11:13:02 EDT 2011


For the consumer market, I agree that an obvious strong authentication 
device would be a mobile phone.  If the phone is a smartphone, then it's 
also a smartcard because it incorporates a chip for processing, just 
like a plastic smartcard.  If such a smartphone is going to be used to 
access online apps requiring strong authentication, then the chip could 
incorporate a certificate for that purpose.    But if the consumer is 
going to access these apps on a different computer, then using the 
mobile phone as an authentication device isn't going to work if 
authentication is based on the certificate.  So an alternative is to 
incorporate a one-time password generator, or even to use the phone to 
receive a one-time authorization code via SMS.  But that's cumbersome 
IMO.  If I'm going to do online banking from my laptop computer, I don't 
want to have to get out my cell phone and generate a OTP, then type it 
into the computer.  Or depend on being able to receive a SMS message and 
then type that into the computer.

So while a mobile phone may work in some situations, for others (IMO) it 
would be too cumbersome.  For those apps, a USB device housing a 
certificate seems like the most secure and convenient choice.  Just 
stick the device into the computer's USB port, enter a password, and 
you're good to go.  For strong online authentication purposes, a USB 
device incorporating smartcard technology makes more sense to me than a 
plastic smartcard, which would require a card reader that most consumers 
don't have, and that would still have to be available at each computer 
the consumer uses.  A single USB smartcard device could not only house 
multiple certificates for a variety of relying parties, or maybe just a 
single certificate trusted by multiple relying parties. It could also 
house an active client / claims agent to make portable a collection of 
long-lived U-Prove tokens.  [Long-lived U-Prove tokens could transmit 
claims to relying parties without needing an identity provider to be 
available when the claims are required.  This seems to be an important 
consideration, given that the providers of high value services may not 
want to shut out their customers if an identity provider is offline.]

You may object and say that people don't want to carry around another 
device.  But consider this: people already carry around a lot of keys 
for different things.  You need a key to get into your house.  Different 
keys for different doors, even.  You need another key to start your 
car.  You may need another key to get into your office, or to unlock 
your desk drawer.  Carrying around a bunch of keys is something that 
people are used to doing.  So what's the big deal about carrying around 
a small USB thingy to unlock all your important online stuff?

That's not necessarily the argument I would use to sell the idea of USB 
devices as authentication devices.  And a USB smartcard is probably too 
expensive for the mass consumer market at this time.  For instance, an 
IronKey costs about $80 US.  Maybe there are less expensive 
alternatives, but still, the only way this scenario would probably work 
is if consumers are simply given these USB smartcard devices and 
instructed to insert them into the computer's USB port when doing online 
banking, etc.  But who would provide these devices to consumers, and 
educate them as to their use?

This gets back to the biggest problem that I think is impeding the 
deployment of strong authN and high assurance claims for 
consumers.....at least in the US.  There needs to be relying parties 
such as banks, healthcare providers, social networking sites (???) and 
others that want to reduce identity-related fraud through the use of 
high assurance claims and strong authentication, and are willing to help 
bankroll the deployment of strong authN to the masses.  Given the right 
incentives, maybe different consortia would arise within different trust 
communities such as banking, healthcare, etc., that might distribute USB 
smartcards (provided the economics can be made to work).  But once a 
consumer possesses one, he/she ought to be able to install certificates 
or U-Prove tokens into the device for all the different high assurance 
applications across these trust communities.

Obviously there are going to be big issues to tackle to make such a 
scheme work, and not everyone may agree with my viewpoint.  In Europe 
they seem to like plastic smartcards that require a card reader.  But 
isn't this sort of what's being proposed by the National Strategy for 
Trusted Identities in Cyberspace?  Even though it is voluntary, 
obviously the goal is to have high adoption levels.  So something like 
what I'm proposing seems necessary.  Use a smartphone as an 
authentication device for smartphone apps requiring strong authN, and a 
USB smartcard for everything else.  Provision certificates or U-Prove 
tokens into these devices for authentication or transmittal of claims to 
various relying parties.  Allow the exportation of these certificates 
and/or U-Prove tokens to personal computers that are frequently used for 
these applications, perhaps conditioned on the need for a Trusted 
Platform Module on the computer to house these things.

So it seems I have strayed off into trying to propose a strategy for 
mass deployment of high assurance identity credentials for consumers 
under the NSTIC banner.  Maybe that's a bit premature, since the final 
NSTIC documents haven't been released yet.  But I do think that Kantara 
needs to consider at some point what role(s), if any, it wants to take 
in helping to make an Internet identity infrastructure widely adopted 
and usable by the masses.

Bob P.

---------------------------
Bob Pinheiro
Chair, Consumer Identity WG
908-654-1939
kantara at bobpinheiro.com
www.bobpinheiro.com



On 3/16/2011 5:42 PM, Colin Wallis wrote:
>
> Yep, fair point Rainer, regards the how SmartCards can come into play 
> and 'connecting islands'..
>
> It's not that we are totally averse to any PKI. We are looking at 
> PKI-ish solution as one of a number of options for federating 
> government agencies. But this is not customer/end user facing.
>
> Cheers
>
> Colin
>
> *From:*Rainer Hörbe [mailto:rainer at hoerbe.at]
> *Sent:* Wednesday, 16 March 2011 8:37 p.m.
> *To:* Bob Pinheiro
> *Cc:* Colin Wallis; dg-bctf at kantarainitiative.org; FI WG; Kantara 
> Leadership Council Kantara
> *Subject:* Re: [KI-LC] PKI vs Non-PKI based trust models
>
> Bob,
>
> SmartCards can be positioned in vertical markets, where there is a 
> fine tuned value proposition and quality level for users and service 
> providers, usually bundled with some "physical" benefit of the card 
> like a customer loyalty program or physical access control. My view is 
> that the way to better market penetration is to build these islands 
> and then connect them using both pki and non-pki federations. I would 
> not expect any breakthrough soon.
>
> - Rainer
>
> Am 16.03.2011 um 00:55 schrieb Colin Wallis:
>
>
>
> Bob
>
> Some interesting thoughts ..(moreso if one had decided to use 
> smartcard technology).
>
> FWIW, the emerging view from our program down in this little country 
> is that end user/citizen folks want to carry another card around like 
> a hole in the head.  It would be different if we already had a sizable 
> penetration of smartcards but we don't.   However, we see many more 
> possibilities with the ubiquitous mobile device. Those possibilities 
> are dashed right now because the things that make identity work are 
> hardwired into the OS with really, let's face it, no security.  And, a 
> bit like the browser vendors, I guess there is no incentive/pressure 
> on them to change, and understandably the unit price would go up.
>
> But wouldn't it be great to have a *separated* secure standardised TPM 
> for things that customers carry round with them whatever they were... 
> Bill, our lead architect uses an example of a phone, with all its 
> usual stuff on one side and the TPM module on the back.  We heard that 
> Iron Key are going the TPM-type way, so that seems to line up with 
> Bob's reference below. And this is getting close to our notion.  But 
> still, you want the USB to also do its usual storage functions and 
> more too, right?
>
> Cheers
>
> Colin
>
> *From:*Bob Pinheiro [mailto:kantara at bobpinheiro.com]
> *Sent:*Tuesday, 15 March 2011 5:43 p.m.
> *To:*John Bradley
> *Cc:*Colin Wallis;dg-bctf at kantarainitiative.org 
> <mailto:dg-bctf at kantarainitiative.org>; FI WG; Curry Patrick; Kantara 
> Leadership Council Kantara
> *Subject:*Re: [KI-LC] PKI vs Non-PKI based trust models
>
> OK, but it's still possible to use certificates for strong 
> authentication of consumers if the certificate is contained on a USB 
> smartcard token.  Of course, relying parties must accept certificates 
> for consumer authentication.   Maybe there is a chicken-and-egg 
> problem here: RPs may have little interest until someone shows them a 
> strong authentication solution using certificates and smartcards that 
> is economically viable for adoption and use by consumers.  But will 
> smartcard vendors devote resources to this until they see a consumer 
> market?
>
> TheSmart Card Alliance <http://www.smartcardalliance.org/>is a member 
> of Kantara, and is also interested in getting smartcard technology 
> into the hands of consumers.  The Smart Card Alliance is represented 
> on the Consumer Identity WG because they were hoping to get some 
> insight into consumer interest in, and adoption of, smartcards.  
> Unfortunately, that kind of insight doesn't exist within the Kantara 
> community.  At least not within CIWG.  Yet the Smart Card Alliance has 
> anIdentity Council 
> <http://www.smartcardalliance.org/pages/activities-councils-identity>, 
> so there ought to be some opportunities for collaboration between 
> Kantara and Smart Card Alliance.  There are at least two areas where 
> our interests probably overlap: use of smartcards for access to 
> patient health records, and smartcards as form factors for identity 
> credentials usable within the "ecosystem" enabled by the National 
> Strategy for Trusted Identities in Cyberspace.
>
> Another Kantara member is Fraunhofer FOKUS, which is the host of the 
> next Kantara meeting, and is also a provider (?) of German eID cards.  
> And although there seems to be no formal working relationships between 
> Kantara and Microsoft, smartcards were used to provide secure U-Prove 
> tokens for an RSA demo by splitting the token's private key between 
> the user's computing device and the smartcard.
>
> So there seems to be a number of areas of where certificates and 
> smartcards can be used for strong authentication and/or high assurance 
> claims.  If these topics are of sufficient interest within Kantara, 
> and resources can be found, perhaps there are opportunities for 
> collaboration with Smart Card Alliance and others.
>
> Bob P.
>
>
> On 3/14/2011 6:25 PM, John Bradley wrote:
>
> Colin,
>
> I spent many years with the PKI Forum and other places pushing the 
> better browser support rock up the hill to no great success.
>
> There has been no detectable improvement in mutual TLS support.  On 
> the other hand EV certs got in because there was a clear revenue model 
> to the PKI Forum participants.
>
> Some of the problem relates to TLS itself and the rest with the 
> browser venders.
>
> If I had to get one thing from them it would be a way to do ephemeral 
> keys for HoK as STORK and others have been asking for, also to no 
> great success.
>
> If someone wants to put together a gang to take on the browser venders 
> I am in, but I am realistic about any real progress after 10 years or 
> so of trying.
>
> John B.
>
> On 2011-03-14, at 5:56 PM, Colin Wallis wrote:
>
>
>
>
> So the problem with client side Certs is the way they are 
> implemented..with security in mind only, not privacy.  'Promiscuous' 
> is the label given to them down here..
>
> That's why the NZ Government does not use them in its consumer online 
> service strategy...
>
> And I might point out that it's too much of a generalisation for my 
> comfort to say to that 'eGov prefers PKI' (Rainer's 5th bullet)
>
> The lines between law enforcement/security (with no privacy) and 
> consumer service/security (with privacy) seem to be getting blurred in 
> some folks' minds (certainly not Bob's, nor John's..)
>
> <<BP:For example, could Kantara have a role to play in making it 
> practical to provision client-side certificates to consumers, so that 
> websites can enable the use of two-way SSL for consumers who have 
> client-side certificates>>
>
> Maybe, but I think it won't be listened to.  The change has got to 
> take place at the doors (hearts and minds) of the browser vendors, and 
> the logical co-ordination point for that is the CA Browser forum.  I'm 
> trying to think of the directional pressure that might persuade them 
> to tackle this problem - the Data Protection & Privacy Commissioners 
> group? Maybe. Kantara? Nope. At least not unless KI is pushing at an 
> open door..
>
> Cheers
>
> Colin
>
> *From:*lc-bounces at kantarainitiative.org 
> <mailto:lc-bounces at kantarainitiative.org>[mailto:lc-bounces at kantarainitiative.org]*On 
> Behalf Of*Bob Pinheiro
> *Sent:*Tuesday, 15 March 2011 6:16 a.m.
> *To:*John Bradley
> *Cc:*dg-bctf at kantarainitiative.org 
> <mailto:dg-bctf at kantarainitiative.org>; FI WG; Curry Patrick; Kantara 
> Leadership Council Kantara
> *Subject:*Re: [KI-LC] PKI vs Non-PKI based trust models
>
> Regarding U-Prove and failed efforts at consumer PKI:
>
> For high assurance consumer applications that (should) require strong 
> authentication, such as online banking, payments, access to patient 
> health records and other sensitive personal information, what are the 
> possibilities for doing strong authentication?
>
> Since PKI doesn't seem to be a realistic possibility at the consumer 
> level (at least not now), it seems that the current choice is limited 
> to one-time passwords, at least for consistency with IAF and NIST 
> 800-63 v1.0.2.
>
> U-Prove tokens are a potentially viable method for transmitting high 
> assurance claims to a RP for these consumer apps.  But even so, the 
> consumer will still need to strongly authenticate to either an 
> identity provider (who issues the tokens), or to a cloud-based active 
> client / token agent  / claims agent.  Or both (??).  With the demise 
> of Cardspace, the use of a self-issued infocard for performing this 
> authentication seems to be out.
>
> Joni has asked for volunteers for a strategy subcommittee to help 
> Kantara become more effective, attract more members, etc.  I'm 
> wondering whether one possible strategic goal for Kantara could be to 
> help transform PKI into something that is practical for use by consumers.
>
> For example, could Kantara have a role to play in making it practical 
> to provision client-side certificates to consumers, so that websites 
> can enable the use of two-way SSL for consumers who have client-side 
> certificates?
>
> A second possible strategic direction is to help in getting U-Prove to 
> be implemented in a way that is usable by consumers.  There is a 
> related effort in the form of a claims agent working group in Identity 
> Commons, but that is not specific to U-Prove.
>
> Maybe these thoughts are best discussed in the strategy subcommittee 
> instead, but I just wanted to put this out there and get some sense as 
> to whether anyone thinks these might be reasonable goals to pursue.  
> Or not?  Would such goals stray too far from Kantara's mission?
>
> Thanks
>
> Bob P.
>
>
> On 3/14/2011 10:50 AM, John Bradley wrote:
>
> I helped start Xcert software (now RSA KeyOn) 12 years ago to work on 
> federated identity issues using PKI client Auth.  Why PKI failed in 
> the consumer/internet space is a big topic.
>
>     I should also mention that u-prove (zero knowledge prrof)
>     cryptography contains elements of both certificates and
>     assertions.   I have limited expectations for any short term
>     traction on that however.
>
>     On 2011-03-14, at 8:08 AM, Rainer Hörbe wrote:
>
>
>
>
>
>     John, Patrick and I had a discussion about the pros and cons of
>     federation models based on credentials versus assertions. The
>     attached document is a preliminary result with conclusions like
>
>         * PKI and non-PKI federation models need to be combined in
>           most cases at higher LoA
>         * To implement a federation an RFC 3647-style policy is
>           insufficient; A more complete Trust Framework is needed
>         * Whereas the Higher Education sector favors brokered trust,
>           e-Government and Industry prefer the PKI approach. But it is
>           not a question of one way or the other.
>
>     Request for feedback:
>
>     I wonder where this discussion should be homed. FIWG, BCTF and
>     TFMM are related, and it is also an extrakantarian issue. Any
>     interest to take over this discussion?
>
>     - Rainer
>
>     <pki vs non-pki.pdf>
>
>    
>
> ====
> CAUTION:  This email message and any attachments contain information 
> that may be confidential and may be LEGALLY PRIVILEGED. If you are not 
> the intended recipient, any use, disclosure or copying of this message 
> or attachments is strictly prohibited. If you have received this email 
> message in error please notify us immediately and erase all copies of 
> the message and attachments. Thank you.
> ====
>
>
> ====
> CAUTION:  This email message and any attachments contain information 
> that may be confidential and may be LEGALLY PRIVILEGED. If you are not 
> the intended recipient, any use, disclosure or copying of this message 
> or attachments is strictly prohibited. If you have received this email 
> message in error please notify us immediately and erase all copies of 
> the message and attachments. Thank you.
> ====_______________________________________________
> LC mailing list
> LC at kantarainitiative.org <mailto:LC at kantarainitiative.org>
> http://kantarainitiative.org/mailman/listinfo/lc
>
> ====
> CAUTION:  This email message and any attachments contain information 
> that may be confidential and may be LEGALLY PRIVILEGED. If you are not 
> the intended recipient, any use, disclosure or copying of this message 
> or attachments is strictly prohibited. If you have received this email 
> message in error please notify us immediately and erase all copies of 
> the message and attachments. Thank you.
> ==== 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/lc/attachments/20110318/691ed0c2/attachment-0001.html 


More information about the LC mailing list