Re: [http-auth] Web Keys and HTTP Signatures

On 04/19/2013 06:58 AM, Stephen Farrell wrote:
>> HTTP Origin-Bound Authentication (HOBA) 
>> http://tools.ietf.org/id/draft-farrell-httpbis-hoba-02.txt
>> 
>> We had considered signatures in the URL in the second approach to
>> the problem in the Web Keys spec. We eventually rejected the
>> solution because of limitations in the URL length in some browsers
>> and because we wanted the semantics of the HTTP headers to be able
>> to be a part of the digital signature. We also didn't want large
>> signed messages being dumped to the webserver logs (the request
>> line is typically included). So, while HOBA does solve the problem,
>> it doesn't solve it in a way that is acceptable to us.
> 
> I think you're misreading the spec a little, or we've written it
> badly:-)

I did misread the spec a bit, confusing some of the features in other
HTTP Auth specs with some of the HOBA features. So, I took tonight to do
a thorough review of the spec and outline the issues that we have with
the current HOBA spec located at:

http://tools.ietf.org/html/draft-farrell-httpbis-hoba-02

I do agree that we should chat a bit more deeply about HOBA, Web Keys,
Persona, and HTTP Signatures. So, please take this not as negative
feedback, but constructive criticism and the first exchange toward
attempting to map out a way forward for these specs.

Here's the HOBA spec review from a Web Keys / Web Payments perspective:

1.  Introduction
----------------

> HOBA also defines some services that are required for modern HTTP 
> authentication:
> 
> o  Servers can bind a CPK with an identifier, such as an account 
> name.  HOBA allows servers to define their own policies for binding
> CPKs with accounts during account registration.

While a bit vague, we want to ensure that there is a well-defined way to
do this. We're currently in the process of discussing how this should
happen with the Mozilla Persona team. Ideally, the CPKs are setup or
transmitted to the server when a Persona-like login exchange happens.
We'd like to provide CPKs via some sort of identity expressed as Linked
Data, like the sort that's defined in the Web Keys spec:

curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu

> o  Users are likely to use more than one device or user agent (UA) 
> for the same HTTP based service, so HOBA gives a way to associate 
> more than one CPK to the same account, but without having to register
> for each separately.

+1, the approach above is how we accomplish this for Web Keys.

> o  Users are also likely to lose a private key, or the client's 
> memory of which key pair is associated with which origin.  For 
> example if a user loses the computer or mobile device in which state
> is stored.  HOBA allows for clients to tell servers to delete the
> association between a CPK and an account.

We took this approach 3+ years ago and quickly found that it would be a
nightmare to have to contact every server that you've performed a login
on to delete the association. Even worse, if you don't do this and the
key is compromised, you enable the attacker to gain access to the server
without your knowledge.

Instead, the server should track an "identity" and that identity will
have keys that are currently valid, or that have been revoked (like the
following):

curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3

The server MUST check the validity of a key before allowing login. There
could be cache values / E-Tags associated with keys to make sure that
they're being properly cached via HTTP proxies.

> o  Logout features can be useful for user agents, so HOBA defines a 
> way to close a current HTTP "session", and also a way to close all 
> current sessions, even if more than one session is currently active
> from different user agents for the same account.

Session management absolutely should not be a part of the base
specification on HTTP Signatures. It should be layered on top of HTTP
signatures. I realize that HOBA might be doing this to "solve" the
session login problem on the Web via HTTP Auth once and for all, but
this is at the wrong level of abstraction. You can implement sessions on
top of HTTP Signatures any way that you would like (session cookies,
HTTP headers carrying session information, URL query parameters with
session information, etc.).

There should be a separation between HTTP Signatures and HTTP session
management.

1.2.  Terminology
-----------------

> also optionally include an HTTP "realm" as defined in the HTTP 
> authentication specification.

We don't use realm as most Access Control List (ACL) systems require far
more complicated forms of specifying what the client can and cannot do
with a particular CPK.

For example, look at the way OAuth is used in Twitter. When you provide
a website with a particular OAuth token, you can grant them a number of
privileges wrt. your account: let them see my e-mail address, let them
tweet on my behalf, let them see my followers, let them see my profile
information, etc. These sorts of access grants rarely fit nicely into a
"realm" field. We think ACL should be a completely separate spec that is
layered on top of HTTP Signatures or HOBA. We don't think it is a good
idea to solve the problem at this level.

2.  HOBA for Both HTTP Authentication and JavaScript
----------------------------------------------------

> On receipt of a challenge from a server, the client marshals a
> to-be- signed blob that includes the web-origin name, the realm, and
> the challenge string; and signs that hashed blob using the hash
> algorithm identified with the challenge and the private key
> corresponding to the CPK for that web-origin.

Yikes, this stomps all over the work that Mozilla is doing on Persona
(and not in a good way). They seem to have a good solution for this, we
should build off of that. The Javascript implementation of HOBA is also
a hack in that it shoves authentication parameters into the URL and we
/definitely/ don't want a Web where that becomes the norm. If this stuff
is going to be integrated into the browser, we should not create a
solution that makes it difficult for that to happen.

The solution shouldn't have a JavaScript-version and an HTTP-version. It
should all run over HTTP, especially since the very large majority of
JavaScript environments are capable of accessing and writing HTTP headers.

3.  HOBA HTTP Authentication Mechanism
--------------------------------------

> On receipt of a challenge from a server, the client marshals a
> to-be- signed blob that includes the web-origin name, the realm, and
> the challenge string; and signs that hashed blob using the hash
> algorithm identified with the challenge and the private key
> corresponding to the CPK for that web-origin.

This challenge-response-session approach is a tried and true design, but
one that's fairly inefficient in that it requires multiple round-trips
in the common case between server and client to perform a single
authenticated operation.

The Web Keys specification takes a different approach in that the server
does not need to provide a challenge because the client includes a
client-specific time-boxed nonce. The nonce is guaranteed to increment
so replay attacks are prevented as long as the server tracks the nonces
correctly, which is the same requirement that TLS has. Only the latest
nonce per client needs to be tracked for a certain period of time, e.g.
5 minutes, which greatly reduces memory overhead on the server.

The downside is that both client and server must have their clocks
fairly closely aligned, which is not necessarily a terrible requirement
given the state of modern timekeeping technology on the Internet. In the
very worst case, the protocol could be expanded such that the server
provides a clock timestamp that the client can use to calculate it's own
clock skew based on the server's current clock.

Using a Linked Data-based identity coupled with an HTTP Signature and a
time-boxed nonce allows a client to make a direct signed request to a
server in 1 HTTP exchange instead of 2.

This is a fairly sharp deviation between the Web Keys + HTTP Signatures
spec and the HOBA spec.

4.  Using HOBA-http
-------------------

> 4.1.  CPK Preparation Phase
> 
> In the CPK preparation phase, the client determines if it already
> has a CPK for the web-origin it is going to.  If the has a CPK, the 
> client will use it; if the client does not have a CPK, it generates 
> one in anticipation of the server asking for one.

With Web Keys, the client does not create a new CPK for every
web-origin. It creates a single CPK for each identity associated with
the client.

With HOBA, providing a new key for every website that the client visits
is overkill and would result in a key management nightmare for the
person using a browser. Dialogs would include dozens of keys in the
average case, which would be a bit of a usability nightmare.

The Web Keys approach is to provide every identity on each device a key.
So, if you visit google.com and you have one personal identity and one
professional identity, and you use both on your home computer, then your
home computer would have two keys regardless of the number of websites
that you visit. Those keys would be tied to each public Linked Data
identity.

> 4.2.  Signing Phase
> 
> The user agent tries to access a protected resource on the server. 
> The server sends the HOBA WWW-Authenticate challenge.  The user
> agent receives the challenge and signs the challenge using the CPK
> it either already had or just generated.  The server validates the 
> signature.  If validation fails, the server aborts the transaction.

As explained above, the Web Keys + HTTP Signature approach is to not
utilize a challenge-response approach, but rather a Linked Data identity
coupled with a client-specific time-boxed nonce to achieve the same
level of protection.

There /could/ be a Web Keys WWW-Authenticate message, but all that would
do would be to notify the client that a Web Keys-based authentication
should be performed when communicating with the server.

> 4.3.  Authentication Phase
> 
> In the authentication phase, the server extracts the CPK from the 
> signing phase and decides if it recognizes the CPK.  If the server 
> recognizes the CPK, the server may finish the client authentication 
> process.

Since the Web Keys specification uses a URL to express the key used for
the digital signature, a server can discover the identity associated
with the key pretty easily. For example, if this key was specified in
the HTTP Signature: https://dev.payswarm.com/i/manu/keys/3

The server would get the key:

curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3

look for the owner of the key in the data, which would be:

https://dev.payswarm.com/i/manu

fetch that profile:

curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu

and then see if it has that identity on record as having an account on
the server. If it does, then it would verify that the key is owned by
the profile and check the validity of the signature.

4.3.  Authentication Phase
--------------------------

The last part of the first paragraph and the last 3 paragraphs should
just say that each topic covered is out of scope. The vast majority of
this section deals with things that are out of scope for HOBA (and most
HTTP Auth schemes).

4.4.  Logging in on a New User Agent
------------------------------------

The vast majority of this section is out of scope for this spec as well.

5.  Using HOBA-js
-----------------

I don't understand why HOBA-http cannot be accomplished via JavaScript
and XHR? Why do you need an entirely different way of encoding the HOBA
protocol using only URL-based parameters?

Unless I'm missing something, the entirety of this section is at the
wrong level of abstraction and unnecessary.

6.1.  Registration
------------------

This section is interesting because we've been struggling to figure out
a way to have UAs automatically (or semi-automatically) create accounts
on new web-origins. That said, Mozilla Persona is far ahead of us here,
so we should probably just fall in line w/ what they're doing.

6.2.  Associating Additional Keys to an Exiting Account
-------------------------------------------------------

As explained above, this is unnecessary if you use a Linked Data
identity like Web Keys does. You never have to add additional keys to an
existing account because the person accessing the site has already
paired their device with a key using their Identity Provider. When they
hit a web-origin, that association is already complete, therefore there
is nothing for the web-origin to do except lookup the key and the
identity. In effect, that key is automatically picked up by every
website that accesses the Linked Data identity.

6.3.  Logging Out
-----------------

Again, this is at the wrong level of abstraction, at least as far as Web
Keys and HTTP Signatures are concerned. If HOBA is to become a standard
way of doing HTTP session management, then this would be fine. That
said, I think you'll be competing with Mozilla Persona at that point.

-----------------------------------------------------------------------

Hopefully this is helpful to the HOBA editors. I'm having a chat with
one of the editors next week and I wanted to make sure to get this out
there so he has time to review the comments before our chat.

Again, this was just a friendly review of the spec before we try to
figure out how we can coordinate this activity between W3C and IETF.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Sunday, 21 April 2013 03:20:25 UTC