Joyent unveils HTTP Signature auth scheme for REST APIs(joyeur.com)
joyeur.com
Joyent unveils HTTP Signature auth scheme for REST APIs
http://joyeur.com/2012/01/03/a-bit-more-about-the-new-joyent-cloud-api/
5 comments
We didn't want token-based auth (i.e, Oauth2 or openstack), nor did we want shared-secret based auth (i.e., hmac). We specifically wanted to offer authentication with public-key crypto, and as the blog post points out, the usability of client-auth SSL sucks.
So when you say it's not solving a problem that hasn't already been solved, if you're talking about "the ability to sign a request" in the most generic sense, sure, it's already been solved N times.
Generally speaking though, in most of those schemes key management is an afterthought, and we didn't want it to be an afterthought. It's been solved by SSH, and that's what we wanted to leverage.; the point was not to reinvent the wheel, the point was to leverage an existing security mechanism.
So when you say it's not solving a problem that hasn't already been solved, if you're talking about "the ability to sign a request" in the most generic sense, sure, it's already been solved N times.
Generally speaking though, in most of those schemes key management is an afterthought, and we didn't want it to be an afterthought. It's been solved by SSH, and that's what we wanted to leverage.; the point was not to reinvent the wheel, the point was to leverage an existing security mechanism.
How do your alternative examples solve the problem of using a single key (ssh key) to authenticate both using an ssh client and http(s)?
A better write-up can be found on GitHub: https://github.com/joyent/node-http-signature/blob/master/ht...
Frankly, the blog post leaves a lot of questions and is short on links to answers. It would be easy to walk away from the post thinking Joyent's HTTP Signatures to be incompetently designed. It was almost enough to have me quip, "More like HTTPS Signatures," because the design in the blog post is only sensible over TLS. However, having found the above link, I see that it is the defaults that assume TLS, but that you can specify the signature contain all headers and the request line. This makes it possible to sign requests over HTTP.
I'd rather the defaults be reasonable for insecure transports (i.e., all headers + 'request-line'), since the TLS case is easily handled with just 'headers="date"'. If that's not to happen, I'd hope that implementations actively prevent the use of the defaults over insecure transports. Unfortunately, Joyent's reference implementation doesn't seem to do this.
Frankly, the blog post leaves a lot of questions and is short on links to answers. It would be easy to walk away from the post thinking Joyent's HTTP Signatures to be incompetently designed. It was almost enough to have me quip, "More like HTTPS Signatures," because the design in the blog post is only sensible over TLS. However, having found the above link, I see that it is the defaults that assume TLS, but that you can specify the signature contain all headers and the request line. This makes it possible to sign requests over HTTP.
I'd rather the defaults be reasonable for insecure transports (i.e., all headers + 'request-line'), since the TLS case is easily handled with just 'headers="date"'. If that's not to happen, I'd hope that implementations actively prevent the use of the defaults over insecure transports. Unfortunately, Joyent's reference implementation doesn't seem to do this.
They're not unveiling anything. They're just describing how their API works, and they've reinvented a wheel.
What other authentication scheme combines HTTP(S) and SSH keys in a similar way?
I really like the idea of using SSH keys: one less password to manage, and it avoids sharing a secret with your provider.
With hash-based signature schemes, you know that your secret has to be stored in cleartext, which is why you can't choose your own signing token on any clouds.
As a solution for technical users, SSH-keys seem like a great idea: they're battle-tested, avoid a shared secret, are no less convenient than using long system-generated tokens, and have a much richer ecosystem (e.g. ssh-agent, password protection, the possibility to store it on hardware devices etc)
With hash-based signature schemes, you know that your secret has to be stored in cleartext, which is why you can't choose your own signing token on any clouds.
As a solution for technical users, SSH-keys seem like a great idea: they're battle-tested, avoid a shared secret, are no less convenient than using long system-generated tokens, and have a much richer ecosystem (e.g. ssh-agent, password protection, the possibility to store it on hardware devices etc)
As far as I can tell the signature applies only to the date header. Which means that if an attacker can intercept a signed request they can swap in any request of their own without having to change the signature at all. And the server will interpret it as a legitimate signed request.
They are using TLS to assume that the client authenticates the server is who it says it is -- if you can man in the middle TLS, there are lots of other possible exploits besides this signature one.
Thanks. It's not clear to me from the post that it's using TLS but that would make sense. Though if requiring TLS I wonder why not just use basic auth since it's simpler and since TLS would protect the password.
One of the things that's neat about, say, OAuth's MAC authentication, is that it works over plain old HTTP without TLS. Likewise for the AWS API's signature-based security scheme. Sounds like I erroneously assumed that this was aiming to do similarly.
One of the things that's neat about, say, OAuth's MAC authentication, is that it works over plain old HTTP without TLS. Likewise for the AWS API's signature-based security scheme. Sounds like I erroneously assumed that this was aiming to do similarly.
It's too bad this couldn't model the Keystone token authentication API that OpenStack is doing:
http://keystone.openstack.org/
Or say, heck, don't like OpenStack, even just using OAuth2 would be fine:
http://datatracker.ietf.org/wg/oauth/charter/
It sounds cool, using SSH keys as your API signature, but really it isn't solving a problem that hasn't already been solved.