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

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Apr 2013 11:58:05 +0100

Hi Manu,

Just on the HOBA bit...

On 04/18/2013 10:27 PM, Manu Sporny 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:-)

The HTTP scheme in HOBA is an HTTP authentication scheme so I
don't know what you mean when you say putting the signatures
in the URLs, since we don't do that. I think its that part
(section 4 of the HOBA draft) where there's most in common
between these, but also section 6.

The non-normative JS stuff does say to put the signature in
the URL though yes, but is quite a work-in-progress. That
section is really there to demonstrate that a site could do
the moral equivalent of HOBA without waiting for all UAs
to implement the spec. so e.g., if forms made for a better
example that'd be ok too I think (not sure if my co-authors
agree though). But your points about message size and logs
are reasonable.

HOBA is just about public key methods, not HMAC which is
a real difference.

All in all your stuff and this looks quite similar to me, so
I'd say we should talk all right.

Cheers,
S.

---

From: Manu Sporny <[email-masked]>
Date: Thu, 18 Apr 2013 17:27:11 -0400

My name is Manu Sporny. I'm the current Chair of the W3C RDFa WG, JSON
for Linking Data (JSON-LD) CG, and Web Payments CG. I am also an editor
of various W3C specs and member of the HTML WG and RDF WG.

There is a relatively new spec at W3C called Web Keys[1] that now
supports HTTP Signatures[2]. It is being worked on as a part of the Web
Payments[3] work. Specifically, the PaySwarm[4] specifications use Web
Keys and HTTP request signatures.

We'd like to coordinate with the IETF on this work to make sure we have
all parties interested in solving this problem involved in the work. We
would also like more eyes doing security audits[5] on the protocol.

For a high-level introduction to Web Keys, see the Mozilla Hacks article:

https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-identity-part-1-of-3/

For a high-level introduction to the Web Payments work, look here:

http://blog.meritora.com/launch/

One of the first questions that came up in the IETF HTTP WG thread[5] on
the matter is why none of the other HTTP authentication schemes were
acceptable to the Web Payments group at W3C. Here is a quick run-down of
the reasoning:

HTTP Mutual Authentication
http://tools.ietf.org/html/draft-oiwa-http-mutualauth-12

Overkill for our purposes and requires multiple bounces back and forth
between the client and the server. Key exchange isn't required since
that's taken care of by the Web Keys PKI framework. We don't intend the
Web Keys HTTP signature protocol to be session-based, as a session-based
value can be built on top of HTTP signatures pretty easily.

HTTP Multilegged Auth
http://tools.ietf.org/id/draft-montenegro-httpbis-multilegged-auth-01.txt

Seems like overkill for our needs and is fairly specific to HTTP 2.0. We
wanted something that could work for HTTP 1.0. Multi-legged
authentication is something that we're not interested in solving using
HTTP Signatures. Putting state into the protocol is something we'd like
to avoid if possible.

HTTP Salted Challenge Response
http://tools.ietf.org/html/draft-melnikov-httpbis-scram-auth-00

Uses HMACs, doesn't use public key crypto, which is a requirement for
Web Keys and the Web Payments work.

HTTP REST Auth
http://tools.ietf.org/id/draft-williams-http-rest-auth-03.txt

This was the solution that seemed to be most interesting to the Web Keys
and Web Payments work. However, it requires quite a bit of state to be
remembered by the server (the Session URIs). Keeping the state of a
"session" around isn't desirable. We didn't want there to be a concept
of logging in and logging out of a website w/ the HTTP Signature stuff.
We'd rather that sessions are built on top of HTTP Signatures via a HTTP
header or cookie. Again, if we had to pick a back-up solution, HTTP REST
Auth seems like it might work for us, but we'd rather not use if we
don't have to.

I'll stop here and wait for feedback from the groups that are involved.
I am in contact with Stephen Farrell and a few other folks at IETF about
where best to coordinate the work.

-- manu

[1] https://payswarm.com/specs/source/web-keys/
[2]
https://github.com/joyent/node-http-signature/blob/master/http_signing.md
[3] http://www.w3.org/community/webpayments/
[4] https://payswarm.com/
[5] http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0145.html

-- 
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/

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 19 Apr 2013 11:33:48 -0400

Hi Manu,

> https://github.com/joyent/node-http-signature/blob/master/http_signing.md

That draft is very similar to the approach we have used in iSchedule 
(<https://datatracker.ietf.org/doc/draft-desruisseaux-ischedule/>) - which 
is an HTTP-based calendar and scheduling messaging protocol.

We choose to re-use existing email signing technology - DKIM 
(<http://tools.ietf.org/html/rfc6376>) - primarily because the security 
model and key management were a good fit for our application. There is also 
the benefit of code re-use, and working with a protocol that is already 
deployed and used heavily in the email environment. Also, DKIM was designed 
with the prospect of being applicable to protocols beyond email technology 
- and I think with iSchedule we have proven it can work with HTTP.

I would definitely urge you to take a serious look at DKIM. There are a 
number of interesting features there that don't seem to have been addressed 
in the draft you cited. In particular dealing with both header and body 
canonicalization (headers are particular problem in HTTP due to 
intermediaries, caches etc).

-- 
Cyrus Daboo

---

From: Manu Sporny <[email-masked]>
Date: Sat, 20 Apr 2013 23:19:46 -0400

On 04/19/2013 06:58 AM, Stephen Farrell wrote:
>> 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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 21 Apr 2013 19:13:37 +0100

HI Manu,

Thanks for the thorough review. Some good points and
defo a bunch of things to check out... but not today:-)

I'll take a better look at this Monday,
Cheers,
S.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 21 Apr 2013 14:39:51 -0700

Manu Sporny wrote:
> Yes, it seems like a very applicable technology for your use case. The
> one thing I missed is whether or not DKIM allows multiple identities per
> user in a domain? Does it let users create as many sub-accounts as they
> want and associate keys with them? Anything is possible, what I'm asking
> is if this is something that is standardized. Access to DNS places a
> pretty high bar and we were hoping to lower that by a significant amount
> with Web Keys.
> 
>>From my understanding, DKIM defines a domain-level digital signature
> authentication framework. WebKeys defines a identity-level digital
> signature authentication framework.

You can have any number of selectors per domain. Selectors can be delegated
as needed (or not). Whether it's a good idea to have zillions of records served
by given zone is another matter. I assume that an untrusted client has a selector.
That is another thing that's worth considering because the use case it's been
deployed with is mainly ~trustable entities. I don't see why that would be problem
off the top of my head, but it's worth thinking about.

> Where DKIM uses the DNS system to discover key information for a domain.
> Web Keys uses the Web and Linked Data formats to discover key
> information for a particular identity.

DKIM uses DNS to store raw public keys. No more, no less. It is linked to
a domain insofar as the domain's owners/managers determines what is populated
in its zone files. The bigger issue in my mind is whether you need DNSSEC.
For mail signing, it was an acceptable risk to not have the keys themselves
be signed. If you require that level of protection, then it implies DNSSEC
and all of the machinery behind it. Which isn't to say it's not possible,
just TANSTAAFL.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 21 Apr 2013 15:27:50 -0700

Manu Sporny wrote:

> The Javascript implementation of HOBA is also

Um, HOBA-js is just client server protocol. It is completely normal and expected
for a web site to define the url parameters coming from the client. There's nothing
magical about signature parameters. The one thing that would need to be mentioned is
that there is no significance to the parameter names -- there would be no iana
registry or anything like that. The client and server would just need to agree
to their names and functionality which is nothing different than any other parameter.

> the profile and check the validity of the signature.

I don't know whether this is relevant, but HOBA doesn't require third parties.
It's just a get-rid-of-passwords-as-currently-deployed scheme. As such, it
doesn't require 3rd party trust, somebody else's business model, etc. Just drop
hoba in and deprecate passwords being stored on servers. I for one would be happy to
see a spec that limits itself to just the client server problem so that web
sites can get their heads around even that smaller problem without them exploding
when you drag 3rd party complexity in.

> 4.3.  Authentication Phase

I think you might be taking this draft way too literally. At least from my
vantage point, the idea in HOBA for the here and now is to sketch out how
this kind of idea could work, and the discussions about session, etc, is
to illustrate how it might work with real world sites today with real world
session management, etc. That is, you shouldn't read too much normative into
this draft.

> 5.  Using HOBA-js

The current draft is an amalgamation of two ideas that are generally similar.
I had independently come up with HOBA-js and then noticed Paul and Stephen
working on something similar. My idea was to use javascript+crypto libraries
and do this entirely at the application layer. Obviously webcrypto would be
a huge help, and get rid of dodgy js crypto libraries but it isn't available
yet.

This blog post documents what I did.

http://rip-van-webble.blogspot.com/2012/06/using-asymmetric-keys-for-web-joinlogin.html

I actually have a live implementation that does this. FWIW, it uses time stamps instead
of nonces for replay protection.

> wrong level of abstraction and unnecessary.

It shows that this can be done today, and that it doesn't even require standardization.
The reason I put it out there is because crypto is hard to get right, and even if it
doesn't _require_ standardization, standardization is a good way of getting clueful
eyeballs on would-be crypto deployments.

Mike

---

From: Manu Sporny <[email-masked]>
Date: Sun, 21 Apr 2013 17:18:06 -0400

On 04/19/2013 11:33 AM, Cyrus Daboo wrote:
>  (<https://datatracker.ietf.org/doc/draft-desruisseaux-ischedule/>) -
>  which is an HTTP-based calendar and scheduling messaging protocol.

Thanks for the pointer to the draft. I skimmed it and I agree that there
are a number of very interesting similarities.

> (<http://tools.ietf.org/html/rfc6376>) - primarily because the 
> security model and key management were a good fit for our 
> application. There is also the benefit of code re-use, and working 
> with a protocol that is already deployed and used heavily in the 
> email environment. Also, DKIM was designed with the prospect of
> being applicable to protocols beyond email technology - and I think
> with iSchedule we have proven it can work with HTTP.

> I would definitely urge you to take a serious look at DKIM. There
> are a number of interesting features there that don't seem to have
> been addressed in the draft you cited. In particular dealing with
> both header and body canonicalization (headers are particular problem
> in HTTP due to intermediaries, caches etc).

Yes, Proxy header modification is a problem for Web Keys and HTTP
Signatures now. We think we have some working solutions, but won't know
for sure until we get some deployment experience with the protocol (or
someone that has already been through that pain point can let us know
what we're doing wrong).

I agree with you. We need to take a serious look at DKIM and your spec
and figure out if we missed something obvious with Web Keys and HTTP
Signatures. Glancing through your spec sparked a few ideas, so I'm
looking forward to a thorough read and review of it wrt. Web Keys and
HTTP Signatures.

-- manu