> -----Original Message----- > From: Manger, James H [mailto:[email protected]] > Sent: Wednesday, February 03, 2010 10:19 PM > To: Eran Hammer-Lahav; OAuth WG ([email protected]) > Subject: RE: Comment on draft-hammer-http-token-auth-01 > > > 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.
What do you mean by 'binding secrets to hash algorithms in the protocol"? > > 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. This is a question for the group - is this a use case we want to support? Is it worth the complexity it adds? > > > Breaking the existing model of HTTP authentication (1 scheme per > > > mechanism) is the wrong approach. > > > > Not sure what you mean. > > 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. That's OAuth 1.0 today, just to be clear. > You have broken the model where the scheme means something about the > type of > 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
