Re: [OAUTH-WG] TAuth

[Justin Richer <[e-mail]>]

Responses inline.

> On Nov 22, 2016, at 2:14 PM, Stevie Graham <[e-mail]> wrote:
> 
> Hi,
> 
> Coming across this thread late. I’m the Author of the TAuth post.
> 
> > What I don't understand is that he's saying people disable TLS checks so he's going to solve it with mutual TLS? 
> 
> It’s simple. Mutual TLS enables service providers to assert the peers are properly authenticated and enforce this as a policy. This won’t stop an incompetent developer disabling peer verification but it will stop that developer using the service if they do.

What I’m saying is that it’s a matter of complexity. The argument in the article I read was that deployment of TLS with server verification was difficult for developers. Mutual TLS is several order of magnitude more difficult. Does it give you reasonably strong client authentication? Of course, but when usability and security fight, usability wins. I never argued that it’s less secure, just less usable. The two arguments being made in the TAuth essay are mutually exclusive: “we can’t use this because it’s too hard / we must use this because it’s more secure”. You can’t say something is too difficult to use and then replace it with something even more difficult. 

> 
> > The reason an OAuth 2.0 server does not authenticate _public_ clients is because, by definition, a public client cannot keep its client secret confidential and so client authentication is almost meaningless. <snip> but they don't recognize that their insistence relies on the assumption that a secret key embedded in a client application can be kept confidential.
> 
> This is incorrect. Modern mobile clients are capable of keeping a secret confidential, e.g. the Secure Enclave Processor on modern iOS devices and the Android analogues. The SEP can generate key material and use it to encrypt and sign arbitrary data. Key material is generated within the SEP and cannot be exfiltrated. To me this is the definition of being able to protect its own secrets. The TAuth bearer token analogue is not sensitive at all and cannot be used without the corresponding key material.

You’re conflating configuration time secrets (the lack of which defines public clients) and runtime secrets. The ability for mobile applications to keep per-instance runtime secrets is exactly why we have both Dynamic Registration and PKCE in OAuth. What you’re describing in TAuth is largely analogous to the PoP token efforts here in OAuth.

> 
> > Does adding TOKBIND resolve the issues?
> 
> Feel free to correct me here. I wasn’t that familiar with token binding but after reading the draft IMO it’s inferior to TAuth because it binds tokens to the connection. This necessitates refresh tokens, which I find an impediment to developer experience. TAuth binds tokens to the identity (the cert and pkey) thus can be reused again and again across TLS sessions. Token binding also provides no cryptographic guarantees that the peers are verified and that the connection is private.

Token binding folks, correct me if I’m wrong, but this is my understanding: You don’t require refresh tokens with token binding, as the token can be used across multiple TLS connections to the same resource server. Refresh tokens help with cases where the resource owner isn’t present anymore and the access token is no longer valid. 

There are still a lot of other issues with the premise of TAuth and its marketing. It’s not the technology of binding an access token to a certificate identity — that’s not even that new: I proposed and built that years ago in an OAuth system in the healthcare space. In our case it ended up not working very well because of the complexities of managing mutual TLS and client certificates at the resource servers. We’re moving away from single-API systems and on to complex micro-service architectures with distributed resource servers all protected by a common AS. Keeping client credentials sync’d to such resource servers is difficult, and you’ll need a way to do that. It’s doable, just difficult to deploy.

But the thing is: you can do everything that TAuth can do — and then some — by augmenting OAuth with a few simple things. First, we’ve got a way to bind a certificate to a client, which is being discussed in a current draft here in the WG. The next step would be to tie that keying information to the token itself at issuance, which is covered in PoP architecture. The last step, and only missing step, is a presentation mechanism that binds the access token to the client’s certificate over mutual TLS. If you’re OK with the pain of mutual TLS (which is a huge if), then that part’s not difficult at all and could be written up in a short spec.

Instead, what really bothers me is the misinformation of what makes OAuth insecure and how TAuth fixes those things. The reality is that most of the problems cited for OAuth are deployment decisions (which do have very valid but not universal applicability), and TAuth is really just leaving different doors open for problems. For example, the essay I read states that “OAuth tokens can’t be revoked quickly but TAuth tokens can”. This is just patently false, given that you can deploy OAuth with a shared data store or token introspection and get the same immediate revocation capabilities. It also states that OAuth tokens have to expire but TAuth tokens can live forever — again, this is patently false. OAuth tokens don’t have to expire, but it’s considered good practice for them to do so in order to limit the attack surface. Do you really want a powerful credential sitting around forever? That’s caused many problems in OAuth 1 systems, which is why we built in the assumption of expiration possibilities in OAuth 2 and the refresh token mechanism (which is not a bearer token, mind you, and has a completely different attack surface). And if you’re going after developers who can’t get server-side TLS right (as per the introduction of the article), those same developers have exactly zero chance of getting mutual TLS right. 

In the end, I welcome you to contribute TAuth to the working group here and hopefully have it adopted into the OAuth ecosystem. 

 — Justin