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

[Stephen Farrell <[e-mail]>]

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, [e-mail]

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.