Subject: [dane] draft-ietf-dane-smime-12: TLS client-authentication

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Sat, 17 Sep 2016 17:37:12 +0200

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.
But if every service issues a certificate for a user the user
application will be bloated with client-certificates. Not to mention the
work-load for the user to create backups and to renew the
client-certificates. A single client-certificate can be issued by a
Certificate Authorities which is usually complicated, expensive and CAs
have been proven to be unreliable.

DANE-SMIMEA allows to validate an email-address/SMIME-certificate tupel
via DNSSEC. That way a service-provider can validate a user is matching
the email-address, be it a CA-issued or self-signed S/MIME-certificate.

This establishes the opportunity to use DANE-SMIMEA as a global
authentication system. The user creates a self-signed S/MIME-certificate
and publishes it via DANE-SMIMEA. At a service he selects
DANE-SMIMEA-Authentication and in his application (e.g. browser) the
user selects the S/MIME-certificate to be used. The service provider
(e.g. a mod_auth_smimea-module in Apache) validates the
email-address/Common Name against the DNSSEC-protected public key in the
SMIMEA-RR and can be sure to be connected with the user having that
exact email-address.

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).

Regards,

Renne

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 17 Sep 2016 19:13:28 +0300

> 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

---

From: "Garfinkel, Simson L. (Fed)" <[email-masked]>
Date: Sun, 18 Sep 2016 15:41:43 +0000

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 <[email-masked]> on behalf of Ilari Liusvaara <[email-masked]>
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

-Ilari

_______________________________________________
dane mailing list
[email-masked]
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 ...

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 18 Sep 2016 19:59:57 +0300

On Sun, Sep 18, 2016 at 03:41:43PM +0000, Garfinkel, Simson L. (Fed) wrote:
> 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.

Yes, if you have widely distributed smartcards, the reader
infrastructure and sites tied to real-world identity, then things
should work just great.

Let's just say that out of the main methods used around the part of
the world I live in, using official ID card, which also is a smartcard
is the least BS way (if you happen to have a smartcard reader set up).

Unfortunately, none of those three assumptions above is true in the
wider web environment. There you don't want things like linkability
to real-world identity or even linkability between origins. Nor can
one assume presence of extra hardware.

Also, there is currently no feasible way to go "all in" with any
form of "what you have" authentication (except for some select sites
with larger budgets for security). And if you don't go "all in",
then you probably do cause problems for those using tokens of some
kind via still having legacy baggage from passwords.

-Ilari