Subject: [http-auth] Doing it the TLS mutual way...

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jun 2011 22:48:11 +0100

Ok, here's my idea to throw on the pile. I'm not making a claim
that it's perfect, or even better than whatever - the right
thing here will be what's technically a sufficient improvement
and that gets deployed - but nonetheless, I think this could
work if it got traction, though of course its really only a
strawman at this point.

As it says below, Russ pointed out that this is quite like
what the enroll WG tried to do a while back, so I'm clearly
not suggesting something novel here either.

Anyway if this isn't DoA, then I'd welcome someone else
with the time and interest helping to turn it into an I-D
with a bit more detail.

And of course, this is just done as an individual, (a
phrase I hate adding but seemingly necessary sometimes;-)

S.

A HTTP authentication scheme for public TLS mutual authentication
-----------------------------------------------------------------
2011-06-14a, [email-masked]

The Problem
-----------

- TLS mutual authentication is too hard to deploy on the public
Internet.

- Password based authentication schemes leave server side
databases vulnerable.

- EKE/PAKE schemes may help but may require the verifier to store
a database of values that are dictionary attackable and these
schemes do require a password to be sent to the server at least at
account creation and reset time.

The Approach
------------

Try to use as much as possible of what we have now (TLS mutual
authentication) and just make it more usable.

Define a new HTTP authentication scheme that means: I'm going to
ask you to do TLS mutual authentication in a moment. If you don't
have a key pair for this <<service>> already, then go <<here>> for
account creation during which you need to generate a key pair and
send me the self-signed cert (SSC) with <<service>> as the issuer
and subject name and containing your <<service>>-specific public
key.  Your <<account>> identifier needs to be in a subjecAltName
within that SSC.

That can all happen in a couple of roundtrips with no human
intervention or complex processing if all that's needed is to
ensure key continuity (e.g. setting up some don't care account
somewhere). Including key generation, that should be quicker and
easier than typing even a well-worn password.

If some higher level of assurance of the identifers used is
needed, then initial signup might need to be following by
validation of various identifiers, for example via a mail
round-trip to validate that the client does have access to a
particular email account. However, that is out of scope of this
scheme and if needed should be handled via some form of workflow
for account creation - this scheme is just one step in such a
workflow.

If you've signed up already then you should have a key pair for
this <<service>> so when the server does a STARTTLS equivalent
it'll ask for a client cert issued by <<service>> and you can use
the SSC you generated earlier.

If you want to access your account from another browser then you
must first access <<thisplace>> from the first browser. At that
point you will be shown a short-lived <<secret>> value. You must
then go through the signup process from the new browser as usual
but also including the <<secret>> value in order for us to
securely accept that the new SSC also binds to the same
<<account>>.

If you loose the private key or other state (e.g. SSC) from one
browser environment, then so long as you have some other working
browser you can re-associate your account with a new SSC from the
(probably re-installed) browser that lost state in the normal way
- this is just like adding a second browser.

If you loose all private keys then you will have to contact
support who will handle your account reset manually.

The Details
-----------

...are almost all TBD. But this should be doable. Some initial
notes below.

This probably has to be done after initial server-authenticated
TLS to preserve privacy of the account identifier. (With some more
signup-time complexity, the server could give the client a secret
to use to encrypt the account identifier. Not sure if that'd be
worth it.)

The server needs to add support for the new scheme and keep a
database of public keys (or hashes) and account identifiers, or
just SSCs.  Servers would need an application layer add-on for
account signup and for binding additional SSCs to accounts.

TLS is unmodified. Server-side TLS accelerators would need to be
modified slightly to play the protocol and pass on the account
information in some form usable by current applications.

There is no revocation. SSC "validity" should be long term and
ignored on the TLS server.

General HTTP proxies should not be affected.

Browsers would need most change to add the signup logic and the
new HTTP authentication scheme. There would need to be some chrome
as well.

The secret for binding a 2nd SSC to an account could be embedded
in a URI which may help usability in some cases.

Need to consider how to make sure this doesn't get in the way of
existing enterprise TLS mutual auth uses.

Need to consider a migration scheme for accounts with existing
passwords.

The service name could, but need not, be the service URL. Any
string chosen by the server deployer should work.

Need to check out what enroll did and why that didn't work.

Acks
----

Russ Housley pointed out the enroll similarity and the issue of
additional assurance of identifiers, e.g. via a mail round-trip.

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Jun 2011 14:53:24 -0500

> not suggesting something novel here either.

Something not too unlike this was presented at the W3C IDBROWSER
workshop, and several people have suggested something along these
lines at various times (including at that workshop, where even I
mentioned something of the sort as a possible alternative to my
proposal).

> The Problem

PKI doesn't gives us strong mutual authentication.  Or even strong
authentication at all in a PKI with too many root CAs and too many
principals to really validate them all.  Thus you're not actually
proposing a user cert PKI.

In other words, this doesn't get us mutual authentication because the
servers will continue to be authenticated as weakly as they are today.

This could be addressed by having services whose job is to whitelist
other services.  For example, suppose I'm shopping: I could use a user
cert from a shopping federation and my browser could be smart enough
to go ask that federation if any given server I'm visiting has the
right cert.  This would be more than a remote cert validation service.
 It's at least a remote server cert pinning service, but better than
that, it can be a remote whitelist.  This would allow us to get strong
mutual authentication from TLS.

(Yes, the TLS server cert PKI sticks in my craw.)

> - Password based authentication schemes leave server side

But they could be pass-through schemes such that the RP doesn't have
to have access to it, thus you minimize the attack surface.  This is
the sort of thing that ABFAB WG is working on.  (I'm assuming you
meant things like DIGEST-MD5 here.)

> account creation and reset time.

The above comment applies to this as well.

> The Approach

Options for getting the user certs issued/enrolled would include:

 - a certification protocol for enrollment and/or remote access to
user certs (basically issue a new, short-lived cert when the user
authenticates to the "IdP");
 - a cert registration protocol for registering self-signed certs as
RP-only user certs.

SACRED could be another option for remote access to credentials.

And yet I don't like this approach, nor any of the possible variants.

I much prefer doing authentication at a higher layer, with channel
binding to TLS -- this would require zero changes to TLS (particularly
when using tls-server-end-point as the channel binding type) and HTTP
(at most one might need a new HTTP error code).  Application-layer
authentication could even be implemented, on the server-side, as CGI
programs to get massive adoption to be trivial (no need to upgrade
existing code, just install new code).  Whereas schemes based on TLS
user certs seem to require at least somewhat invasive changes to TLS
and HTTP.

Still, I'd live with this approach IF we also did something to improve
authentication of the service to the user.  So far no one who proposes
TLS user cert approaches proposes any way to strengthen server
authentication, and that has me quite concerned: this may be the only
chance we get for many years to improve authentication of the servers
to the users -- let's not blow it!

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Jun 2011 00:01:16 +0100

Hi Nico.

Skipping over stuff where I'd agree or maybe quibble a bit to
the meaty part:

> user certs seem to require at least somewhat invasive changes to TLS

I don't think a TLS change is needed for this approach, other than
maybe in terms of the interface between a server's TLS accelerator
and the backend, however, there is a fair point that higher layer
authentication is different and can be as good. I suspect that
the TLS mutual approach might be easier to do, but that's just
me arm-waving at this point really.

I think that's ok though - I reckon we're at the point of trying
to identify options that can meet our security requirements.
After that we'll have to see which, if any, of those might get
real deployment and then figure out the relevant details. At
least that where I think we're at.

(And before anyone says it: I do not think we should go off and
write up those requirements in an RFC. This is not our first
attempt at this and the minutiae of the requirements matter
far less than adoption of something that's really better than
current password schemes.)

> to the users -- let's not blow it!

Better server auth is also a fair point - however that might be
somewhat less pressing were client credentials not immediately
stealable from backend databases. Could be that DANE might
provide an approach to help in that respect were we to take
this TLS mutual approach.

I totally agree that *if* this activity results in something new
actually being deployed then we better do a good job because we
won't get another chance if we do a bad job.

However, I also think that we had better not scare off the
punters by demanding more security perfection than is possible.
Put another way - actual deployment here trumps most things
so long as whatever gets deployed is a real improvement.

S.

---

From: Nico Williams <[email-masked]>
Date: Fri, 17 Jun 2011 12:18:44 -0500

On Wed, Jun 15, 2011 at 6:01 PM, Stephen Farrell
<[email-masked]> wrote:
>> [...]

I'm guessing concentrators already provide this.  But yeah.

Also, I suspect that there are subtle changes that are required in
order to get credential selection right on the client side with one's
chosen TLS implementation, and possibly on the server side to deal
with arbitrary credential validation methods (there was a bit of
discussion of this latter at the W3C workshop during Q&A for the WebID
presentation, brought on by questions/comments by Brad Hill, but Henry
Story wasn't present, so there were no detailed answers).

> me arm-waving at this point really.

Perhaps we can ask the WebID folks about their experience here, since
they've gone further down this road than anyone else, near as I can
tell.

> current password schemes.)

I don't think we need to publish a requirements RFC before we do
anything else, or even at all.  But we need to have some clue as to
what the requirements are :)

> this TLS mutual approach.

A lot of authentication methods can and do protect client credentials
from theft.  ZKPPs are all the rage right now, and for good reason.
And no, the fact that the server's verifiers can be stolen doesn't
bother me if people minimize that infrastructure and protect it.  This
isn't like credit card information (where there's no need to structure
the data, thus it ends up all over the place), nor as sensitive as
Kerberos KDBs, say.  Plus between KDFs like scruypt and decent
password quality we can do a very good job of slowing the offline
dictionary attacks enough that theft of asymmetric password verifiers
is not that big a deal.

There's also ABFAB WG's mechanism.  There's OAuth (which, I hear, is
getting mutual auth soon too).  There's Kerberos (always in demand in
the enterprise).  Etcetera.

> won't get another chance if we do a bad job.

I suspect that the TLS user cert approach could get traction very
quickly if it's true that no changes are needed to TLS stacks.  I'll
hope, in that case, that we still get to deploy app-layer
authentication in some use cases, because if you don't care for user
certs (because that's not the authentication infrastructure that you
have), there's really no better choice.

Nico
--