Subject: [OAUTH-WG] Comment on draft-hammer-http-token-auth-01

From: "Manger, James H" <[email-masked]>
Date: Thu, 4 Feb 2010 11:02:47 +1000

Comments on draft-hammer-http-token-auth-01 (3 Feb 2010) after a quick read.

[http://tools.ietf.org/html/draft-hammer-http-token-auth-01]

The simple bearer token mode is still buried as an exception to the request signing rules. This just isn’t necessary, it’s awful.

Choosing a hash algorithm is assumed to be done when a credential is issued. It is nice crypto-hygiene to only use a given secret with a single algorithm, but it is not always sensible. One app may only support SHA-1, while another only supports SHA-256. Standard APIs may only accept an id and secret, and assume that acceptable hash algorithms are configured elsewhere in the software. Having to reissue all credentials to stop supporting an old hash algorithm will not always be practical, and looks like a substantial barrier to removing support for algorithms that get broken.

I would prefer to stick with more common practise: explicitly list the MAC algorithm in a signed request; and support some algorithm negotiation when accessing a protected resource (eg by the server listing supported algorithms in a WWW-Authenticate header). This doesn’t stop a credential-issuer stating that only a specific hash alg can be used with a specific secret, it just doesn’t force this mode.

There is only a spot for a single id in the protocol, not spots for separate authentication and authorization ids. The absence of both in existing authentication mechanisms is the only reason there is any concern about using those mechanisms with credentials from delegation.

The example use a poor choice of realm: realm=”http://example.com/”. Realms are only meaningful in the scope of the current server. The example suggests any-old-site.com can return realm=”http://yahoo.com/” and the client will retry the request a set of token credentials issued for Yahoo services. Yikes!

The 1st paragraph of the introduction confuses the “client” terminology. “Client” is used to means an OAuth “resource owner” and OAuth “client”.

Breaking the existing model of HTTP authentication (1 scheme per mechanism) is the wrong approach.

--

James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Feb 2010 21:39:17 -0700

Thanks James.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Manger, James H
> Sent: Wednesday, February 03, 2010 5:03 PM
> To: OAuth WG ([email-masked])
> Subject: [OAUTH-WG] Comment on draft-hammer-http-token-auth-01
> 
> The simple bearer token mode is still buried as an exception to the request
> signing rules.

This draft was just to remove the confusing bits. I am still working on it to make the plain method easier to notice.

> This just isn’t necessary, it’s awful.

Constructive criticism is always helpful. :-)

> Choosing a hash algorithm is assumed to be done when a credential is issued.
> It is nice crypto-hygiene to only use a given secret with a single algorithm, but
> it is not always sensible. One app may only support SHA-1, while another only
> supports SHA-256. Standard APIs may only accept an id and secret, and
> assume that acceptable hash algorithms are configured elsewhere in the
> software. Having to reissue all credentials to stop supporting an old hash
> algorithm will not always be practical, and looks like a substantial barrier to
> removing support for algorithms that get broken.

I disagree. Voiding a token to stop supporting an algorithm is perfectly reasonable and might not even require user involvement if the refresh mechanism is (adopted and) used. And if the reason for this is a broken algorithm, well, I would hope the tokens are voided, not just used with the same secret and new algorithm.

I am not sure what you mean by "one app may only support SHA-1, while another only supports SHA-256". Are you suggesting something like a company with centralized token service but where each service using a different set of algorithm, but still sharing the same token across services? Sounds like a company in need of new management.

> I would prefer to stick with more common practise: explicitly list the MAC
> algorithm in a signed request; and support some algorithm negotiation when
> accessing a protected resource (eg by the server listing supported algorithms
> in a WWW-Authenticate header). This doesn’t stop a credential-issuer stating
> that only a specific hash alg can be used with a specific secret, it just doesn’t
> force this mode.

This change was based directly on WG feedback. I asked two questions:

1. What should be included in the challenge?
2. Should one token be allowed to support multiple algorithms?

It seems to me that were was no interest in negotiating algorithms or tokens with multiple methods. But I am happy to ask these questions again and see if people have different answers now that there is a new draft to poke at.

> There is only a spot for a single id in the protocol, not spots for separate
> authentication and authorization ids. The absence of both in existing
> authentication mechanisms is the only reason there is any concern about
> using those mechanisms with credentials from delegation.

That's another area where I feel there is no interest. The existing schemes come with too much existing deployment and expectations - that's why we are not reusing them. The token scheme is designed to always work with a server issuing tokens, even if there is no end-user. The idea of using it as a replacement for Basic auth is pretty much dead considering that requiring servers to keep plain text copies of passwords is a deal breaker.

Did you reach a different conclusion from these discussions?

> The example use a poor choice of realm: realm=”http://example.com/”.
> Realms are only meaningful in the scope of the current server. The example
> suggests any-old-site.com can return realm=”http://yahoo.com/” and the
> client will retry the request a set of token credentials issued for Yahoo
> services.

Yeah. I had "Example Resources" before but changed it. The realm parameter needs a lot of work.

> Yikes!

Sorry. Didn't mean to scare you.

> The 1st paragraph of the introduction confuses the “client” terminology.
> “Client” is used to means an OAuth “resource owner” and OAuth “client”.

Fixed.

> mechanism) is the wrong approach.

Not sure what you mean.

EHL

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 4 Feb 2010 17:19:12 +1100

> I disagree. Voiding a token to stop supporting an algorithm is
> perfectly reasonable and might not even require user involvement if the
> refresh mechanism is (adopted and) used. And if the reason for this is
> a broken algorithm, well, I would hope the tokens are voided, not just
> used with the same secret and new algorithm.

Migrating to new algorithms is a very slow and tortuous process -- partly 
because an algorithm is rarely completely broken in a single instant. Even MD5 
is still safe for some purposes. Binding secrets to hash algorithms in the 
protocol (not just as a choice by one server) will make migrations that much 
harder.

> I am not sure what you mean by "one app may only support SHA-1, while
> another only supports SHA-256". Are you suggesting something like a
> company with centralized token service but where each service using a
> different set of algorithm, but still sharing the same token across
> services? Sounds like a company in need of new management.

That is exactly what I am suggesting. Old apps, new apps, outsourced apps, 
legacy apps, white-label apps rebadged, app in this language, app in that 
language, apps in the cloud, apps from a merger...
There is no way I expect perfect consistency in supported algorithms, but I do 
want to try to have SSO across these apps and a central token service for 
accessing their APIs.

I don't want to have to upgrade every single app (even the niche near 
end-of-life ones) to support a new algorithm before I can start using it 
anywhere. If a credential bound to a new algorithm is issued to a client, that 
client can no longer access apps that have not been upgraded -- or, worst 
still, the client is expected to manage multiple app-specific credentials 
where previously they used one.

> > mechanism) is the wrong approach.

In most HTTP authentication mechanisms, knowing the scheme is sufficient to 
know the sort of credential required, the security properties, and if you have 
the code to support it. With Token, the credentials might be just a token, a 
token and shared secret, or a token and asymmetric key. With Token, you may or 
may not be safe from passive attacks, or active attacks; may or may not 
require lower-layer security; might have to do computationally-intensive 
public-key crypto or might only require trivial copy 'n paste.

You have broken the model where the scheme means something about the type of 
credential and the security.

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Feb 2010 23:44:04 -0700

> From: Manger, James H [mailto:[email-masked]]
> Sent: Wednesday, February 03, 2010 10:19 PM
> To: Eran Hammer-Lahav; OAuth WG ([email-masked])
> Subject: RE: Comment on draft-hammer-http-token-auth-01
> 

What do you mean by 'binding secrets to hash algorithms in the protocol"?
 
> where previously they used one.

This is a question for the group - is this a use case we want to support? Is it worth the complexity it adds?
 
> public-key crypto or might only require trivial copy 'n paste.

That's OAuth 1.0 today, just to be clear.

> credential and the security.

Not in practice. The server knows exactly what kind of credentials it is issuing and the client knows exactly what kind of credentials it is using. To suggest that just because the scheme does not include some label makes it broken is going too far. All I did was remove the ability to negotiate the authentication method, not make it completely arbitrary.

According to your analysis, adding the ability to negotiate the type of credentials or algorithm has the exact same problem because you can't tell what the client will choose. In my draft, the client is limited to what the server issued in the first place and what it is willing to accept.

If this is a real issue, it can only be solved be creating a scheme per credential type and potentially algorithm.

EHL