Ilari & Rene,
Certificate-based smart cards are widely used within the US Government. The Department of Defense has millions of it's so-called CACs (Common Access Cards) in use, and they are used by most DoD employees on a daily basis to access information systems (logical access). Other federal agencies have been less successful, but still somewhat successful, with the deployment of the PIV (Personal Identity Verification) cards for logical access. It is very common for federal agencies to purchase laptops that have slots for smart cards. The primary advantage of the CAC and PIV cards is that they provide both physical access and logical access. For physical access, the cards have embedded proximity chips. For logical access, the advantage is that they free relying parties from both identity and password management. If a card is lost, the employee can get a new card without having to change a single password. They also significantly ease the usability burden, as the employee need only remember a 6 digit PIN. I have an article coming out in a few weeks that looks in depth at the CAC and PIV deployment. When it is published, I will post a link here. Ilari is correct in stating that the use of smartcards requires the deployment of a card-reading infrastructure. The growing use of smartcards for credit cards might result in the deployment of some credit card readers in the home, which could also be used for certificate-containing smartcards. Another promising form factor are USB tokens that combine a smartcard chip and a smartcard reader. I believe that one way to move forward in providing strong logical authentication is systems that allow people to use the chips in their credit cards as an identity root. Another way to move forward is for universities and businesses to adopt multi-mode cards for their identification cards. With the cost of smart card readers plummeting (they cost less than $15 now retail, and the actual parts cost is substantially less), the fact that smartcards provide both high levels of usability and security should be attractive to many organizations. Simson Garfinkel ________________________________ From: dane <dane-boun...@ietf.org> on behalf of Ilari Liusvaara <ilariliusva...@welho.com> Sent: Saturday, September 17, 2016 12:13 PM To: Rene 'Renne' Bartsch, B.Sc. Informatics Cc: IETF DANE Mailinglist Subject: Re: [dane] draft-ietf-dane-smime-12: TLS client-authentication On Sat, Sep 17, 2016 at 05:37:12PM +0200, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > Hi, > > > everyone knows the problem: > > We have dozens or hundreds of services to login and every service wants > a user-name and a password. Most users reuse their passwords and a lot > of services do not protect the passwords securely (no hashing, salting, > etc.). If a service is hacked or malicious, the perpetrator can be quite > sure to be able to reuse the credentials at other services. Not to > mention passwords like 12345. > > In TLS operation, a user can be authenticated with a client-certificate. > The password is neither transmitted over the wire nor to the > service-provider. There is only one single password for the > client-certificate instead of multiple passwords for multiple services. > So I suggest to add this case to the application description in section > 6 of draft-ietf-dane-smime-12 or a successor/errata. (Sorry, I lost > track of the current state of SMIMEA). Unfortunately, client certificates tend to be UX disaster. Things only get worse if one needs to consider multiple services, as using one key for multiple services tends to have bad security consequences. These tend to be the reasons browser vendors are phasing out <keygen> and client certificate installation, pretty much meaning one has to have physical smartcard for TLS client certificate authentication. And such smartcards with the necressary equipment are pretty rare (I happen to have one) and tend to be built around real-world identity, which is great for some services, but not-so-great for most. I have once experimented on what it would take to implement client certificate authentication in a site, and pretty quickly gave up, given the horrible UX it had (not to mention technical problems, even with all the PKI baggage I could short-circuited). -Ilari _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane dane Info Page - Internet Engineering Task Force<https://www.ietf.org/mailman/listinfo/dane> www.ietf.org Your email address: Your name (optional): You may enter a privacy password below. This provides only mild security, but should prevent others from messing with ...
_______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane
