Re: [OAUTH-WG] TAuth
Dick Hardt <dick.hardt@gmail.com> Wed, 11 May 2016 00:23 UTC
Return-Path: <dick.hardt@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62D612B02B for <oauth@ietfa.amsl.com>; Tue, 10 May 2016 17:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UReaGuptr4P for <oauth@ietfa.amsl.com>; Tue, 10 May 2016 17:22:57 -0700 (PDT)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6FBA12B02A for <OAuth@ietf.org>; Tue, 10 May 2016 17:22:57 -0700 (PDT)
Received: by mail-ig0-x22f.google.com with SMTP id bi2so145736014igb.0 for <OAuth@ietf.org>; Tue, 10 May 2016 17:22:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uCxSB9l5+3UYgSyvwT1BenzOyjO1WWHguEkr3BSqSlc=; b=m2JEnbDNrxkG3s0hIpk3mBE/p3TRk+uSqibVHGAIeX46lqSYJ6sbbxQ+4kycFmy9BL 0gTxGO84BCyD0vLT+CLbyax2xBgZ2Rv6xHvLpJkGkHF8wHZ4W7RA0c9SrQa50l9Heoku WkEJ8i7QysMQ6xLy2CJ0HI0mLi8SpwNs+tQVEC272X6LQsE8BizDA26mNEwI0MPdYNwc ewpI1AyXJpW8FOgHBtOkCu84dXugjJXeJE3dQlkr2DTgzPFLk8B44k43+BvBgX43AKb0 gwsiyqfBnSuLx+FJ6FzTqMjUiiv0SDR+vfpB/GY8IuofUE0Zrq4fM+jpndQ59jlf18RJ FLUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uCxSB9l5+3UYgSyvwT1BenzOyjO1WWHguEkr3BSqSlc=; b=gIHxVsGMzZys8LBDFjk7hrbRo7A17ndxN9OH67TWQuh6Rf3WLMtRFkduurOzDXRzH3 sIx8KD9jQg5w/WZUf4SlPktCIqc2mESfpDZ8V15KGkyU2jXjU0F9fikkuUznJqQcUmO+ q0PmWzvZICaegVd26qmhzgKiNBeBFDhKwvV/k04yfPvcpyCnJtwuIHBU6LAKNHsOg5KS KlSXPahwpaCQwX1/YTsW0Lz2/cKUJ1t9Oq356AtfB2lrP60CnwP8dAid5uzdC40DcBa6 y0ymujs0ZpddO2EbfsRbiJNlbPetK/hNf8x4XVhZJLpdmdOIO5fqCpO9w5f7jkbSp28y tZAw==
X-Gm-Message-State: AOPr4FUsTa43H2StSooeG9Qf3LXv9+vom5TXnHkMTxWUtKlQVpTCUQKEtHl8YzZHBwlsRvT67vFiVtiKHQ0PCw==
X-Received: by 10.50.70.197 with SMTP id o5mr822069igu.70.1462926175558; Tue, 10 May 2016 17:22:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.111.20 with HTTP; Tue, 10 May 2016 17:22:36 -0700 (PDT)
In-Reply-To: <pjn8ovq6db4enh1fmikoyi2p.1462925137123@email.android.com>
References: <pjn8ovq6db4enh1fmikoyi2p.1462925137123@email.android.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 10 May 2016 17:22:36 -0700
Message-ID: <CAD9ie-vhmEpsLRU-263rpkJy9vBc+rs0=vHiyJ484zACSAQtZA@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="bcaec505533906e9590532860b43"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/hSj6byc-CDR1BPW--EWa8fVB8rY>
Cc: Oauth Wrap Wg <OAuth@ietf.org>
Subject: Re: [OAUTH-WG] TAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 May 2016 00:23:02 -0000
Let us know what you learn Justin! On Tue, May 10, 2016 at 5:05 PM, Justin Richer <jricher@mit.edu> wrote: > I posted about this the other day. What I don't understand is that he's > saying people disable TLS checks so he's going to solve it with mutual TLS? > > I need to email this guy and learn more about what he's doing. > > --Justin > > *Sent from my phone* > > -------- Original message -------- > From: Brock Allen <brockallen@gmail.com> > Date: 5/10/16 6:44 PM (GMT-06:00) > To: Dick Hardt <dick.hardt@gmail.com>, Oauth Wrap Wg <OAuth@ietf.org> > Subject: Re: [OAUTH-WG] TAuth > > Doesn’t the recent PoP work address many of these concerns? > > Also, as for developers disabling SSL — does anyone still do this and > think it’s safe? Or are people just being lazy? Or are there certain > contexts that I’m unaware of where this is valid? > > -Brock > > > From: OAuth <oauth-bounces@ietf.org> on behalf of Dick Hardt < > dick.hardt@gmail.com> > Date: Tuesday, May 10, 2016 at 7:24 PM > To: Oauth Wrap Wg <OAuth@ietf.org> > Subject: [OAUTH-WG] TAuth > > Does anyone think there are useful lessons here? > > Does adding TOKBIND resolve the issues? > > https://blog.teller.io/2016/04/26/tauth.html > > *Teller* <https://blog.teller.io/> > > Join waiting list <http://teller.io/#waitlist> > > Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're > fixing it > > This week we released our authorisation flow making it possible for you to > go from building apps that talk to your bank account, to building apps that > can talk to any bank account. This is huge. Check out this SMS bot (how on > trend) I hacked up yesterday morning. (and don't forget to join the beta > wait list <https://teller.io/>). > > > Getting to this point took longer than we expected. This is because there > wasn't a good story for delegating authorisation for sensitive APIs. The > most popular choice, OAuth 2.0 <http://oauth.net/2> - which has been > chosen by the Open Banking Working Group > <http://theodi.org/open-banking-standard>, BBVA > <https://www.bbvaapimarket.com/web/api_market/bbva/bbva-connect/documentation#3-legged-flow>, > RBS <https://bluebank.portal.azure-api.net/getting-started>, and Mondo > <https://getmondo.co.uk/docs/#authentication> - is also amongst the worst > from a security perspective. > > Teller provides an API for your bank account. The EU is forcing all > European banks to expose account APIs with PSD II > <http://ec.europa.eu/finance/payments/framework/index_en.htm> by end of > 2017. These banks are disconcertingly converging around OAuth 2.0* without > fully considering the impact on their customers, and something needs to be > done before it's too late. > > * One notable exception is the Open Bank Project > <http://www.openbankproject.com/>. It is sticking with OAuth 1.0a > <http://oauth.net/core/1.0a/> precisely because OAuth 1.0a doesn't share > the same security issues as OAuth 2.0. > > Man-in-the-middle > > One of the biggest problems with OAuth 2.0 is that it delegates all > security concerns to TLS but only the client authenticates the server (via > it's SSL certificate), the server does not authenticate the client. This > means the server has no way of knowing who is actually sending the request. > Is it a bona fide user, or is an attacker tampering with the request? When > an attacker is able to insinuate themselves between a legitimate user and > the server, it's called a man-in-the-middle (MITM) attack. It looks like > this: > > - client attempts to connect to service > - attacker successfully reroutes traffic to a host it controls > - malicious host accepts connection from client > - malicious host connects to service > - service accepts connection from malicious host > - client communicates with service proxied through malicious host, > which can see and tamper with any data sent or received > > You're probably thinking "hang on, isn't this the point of SSL?" Yes it > is, but there are a number of ways to present a bogus certificate and a > client accept it. The most realistic threat is the client developer not > properly verifying the server certificate, i.e. was it ultimately signed by > a trusted certificate authority? > > *Follow* <https://twitter.com/tpope> > > <https://twitter.com/tpope> > > *Tim Pope* @tpope <https://twitter.com/tpope> > > Pull requests to disable SSL certificate verification: more common than > you would think. > > 2:24 PM - 11 Feb 2013 > <https://twitter.com/tpope/status/301094352434892800> > > - 5 5 Retweets > <https://twitter.com/intent/retweet?tweet_id=301094352434892800>5 5 > likes <https://twitter.com/intent/like?tweet_id=301094352434892800> > > Unfortunately a large <http://stackoverflow.com/a/7332983/223213> number > <http://stackoverflow.com/a/16298999/223213> of developers > <http://stackoverflow.com/a/36154521/223213> think that disabling SSL > peer verification is the correct fix to a SSL path validation error. There > are many more that will offer the same advice with the caveat that it > introduces a security issue <http://stackoverflow.com/a/12293898/223213> > that < 100% of readers will consider. As an API provider with a duty of > care to our users we can't simply hope developers on our platform don't do > this. > > Bearer tokens > > Once a user authorises a client application to access its account, the > application obtains a bearer token from the authorisation server. As the > name suggests if you have possession of the bearer token then you are > essentially the user. There is no cryptographic proof that the requesting > client is the intended developer and not an attacker. If an attacker is > able to successfully MITM a client it could have catastrophic implications > for the user, e.g. an empty bank account, loans opened in their name, etc. > OAuth 2.0 is simply a security car crash from a bank's perspective. They > have no way to prove that an API transaction is bona fide, exposing them to > unlimited liability. > > For more information on OAuth 2.0 shortcomings see OAuth Bearer Tokens > are a Terrible Idea > <https://hueniverse.com/2010/09/29/oauth-bearer-tokens-are-a-terrible-idea/> > and OAuth 2.0 and the Road to Hell > <https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/> by Eran > Hammer <https://twitter.com/eranhammer> the original primary author of > OAuth 2.0 who formally removed his name from the standard, calling it "the > biggest professional disappointment of [his] career." > > Finding something better > > Sitting down to design the solution to this problem I had two high-level > goals: > > - be the most secure solution for the user > - not unnecessarily impede developer experience. Developers are users > too and their needs deserve equal consideration. > > From a security perspective I wanted: > > - cryptographic proof of client identity > - to stop MITM attacks > - to unimpeachably attribute a request to a given developer. In > cryptography this is known as non-repudiation > <https://en.wikipedia.org/wiki/Non-repudiation>. > > (N.B. Non-repudiation is a de facto requirement of PSD II. If a bank can't > prove an account owner authorised a transaction, they're liable for any > losses incurred by the user.) > > There are solutions to the bearer token problem like JWT tokens (RFC7523 > <https://tools.ietf.org/html/rfc7523>) but in most cases these rely on a > shared secret which is used to computed a HMAC-based signature. Shared > secrets mean no non-repudiation. Public key cryptography can be used with > JWT tokens but they don't solve the problem of how the client will generate > key pairs, demonstrate proof of possession of the private key, and enrol > the public key with the API. Most importantly using JWT tokens make it > basically impossible for you to experiment with an API using cURL. A major > impediment to developer experience. > > In an ideal world we'd have cryptographic proof of the client's identity > without it having to leak through the application level (and stop us > cURLing the API!). As I thought about it it became the clear the answer was > hiding in plain sight: *SSL client certificates.* > > Client SSL Authentication > > A SSL handshake involving client certificates contains an extra message at > the end of the handshake, the *CertificateVerify* > <https://www.ietf.org/rfc/rfc2246.txt> message. > > Client Server > > > ClientHello --------> > > ServerHello > > Certificate* > > ServerKeyExchange* > > CertificateRequest* > > <-------- ServerHelloDone > > Certificate* > > ClientKeyExchange > > CertificateVerify* > > [ChangeCipherSpec] > > Finished --------> > > [ChangeCipherSpec] > > <-------- Finished > > Application Data <-------> Application Data > > > Fig. 1 - Message flow for a full handshake > > The client collects all the handshake messages and signs them with it's > private key and sends the result to the server. The server then verifies > the signature using the public key of the client certificate. If the > signature can be verified with the public key, the server knows the client > is in possession of the private key, and is therefore a bona fide user. > > Let's look at this in the context of our original attack: > > - client attempts to connect to service > - attacker successfully reroutes traffic to a host it controls > - malicious host accepts connection from client accepting the client's > certificate > - malicious host connects to service > - the malicious host will fail to SSL handshake because the host > doesn’t have the private key for the client’s certificate. The attacker > therefore cannot compute the correct *CertificateVerify* handshake > message. The *CertificateVerify* message from the first handshake > cannot be used because the handshake sequences diverge (different server > certificates presented by the host). > > Introducing TAuth > > TAuth is Client SSL Authentication + User Tokens + Great Tooling. > > Client SSL authentication is often overlooked because of the poor UX of > using client certificates in the browser and that generating certificates > is a painful multistep process involving arcane OpenSSL CLI incantations. > However as we're talking about API clients the browser UX point is > irrelevant. As far as certificate generation goes, we can write better > tools. These days it's possible to generate a key pair, a PKCS#10 > certificate request, and sign it all in the browser. Thanks to WebCrypto > <http://www.w3.org/TR/WebCryptoAPI/> the whole process is reduced to one > click. > > This is how Teller does it: > > A private key and a SSL certificate signed by Teller generated in one > click. > > And this is what a request looks like with client certificates: > > Let's recap what we've achieved here: > > - Cryptographic proof of the client identity > - The cURLability of the API is preserved > - The client developer has generated a private key known only to them > and no one else, meaning the bank can actually say "you did that > transaction" (non-repudiation) > > Token security > > Notice in the above example. The Teller API accepts connections from > clients without a client certificate. We do this because we provide > developers with read-only personal access tokens for their own accounts if > they want to quickly hack something up and not bother with provisioning > certs. Now notice how the API does not accept the token presented, but > accepts it when used with the client SSL certificate. TAuth bearer tokens > are bound on the server side to a private key through an application. This > means they are useless without the private key (which only the developer > ever has) and therefore not sensitive. As matter of fact, here is one for > my bank account: > > > You'll need the private key it's bound to for it to be of any use, and > that has never left my laptop. > > TAuth tokens do not expire (but can be revoked). OAuth 2.0 introduced the > concept of time-limited tokens. Large internet companies found it useful > for scaling purposes to issue self-encoded, encrypted tokens. The drawbacks > are developers have to pay the complexity cost of refreshing tokens and > most importantly tokens cannot be revoked, they're good until they expire. > For bank account APIs this is an undesirable property, a token should be > void as soon as the account owner wishes. TAuth checks the token revocation > status at each request. > > Given that we have no need for self-encoded tokens and that tokens are > useless to anyone without the private key, we can consider them public and > directly return them in the callback further simplifying things for the > developer compared to OAuth without compromising the user's security. > > Bonus: DDOS mitigation > > TAuth can help mitigate layer 7 based DDOS attacks > <https://en.wikipedia.org/wiki/Application_layer_DDoS_attack> too. If the > client does not present a valid client certificate the server can just > choose to bounce the connection. > > Conclusion > > OAuth 2.0 is simply not fit for use with sensitive APIs and all the pieces > needed to build something that is exist today. Aside from unbound bearer > tokens, OAuth is too open-ended and complicated to get right for most > developers. It's so bad it even has it's own threat model as a separate > RFC <https://tools.ietf.org/html/rfc6819> to offer mitigations for the > endless problems that can happen. > > *TAuth stands for Trusted Authentication*, and it provides the best > security for users while maintaining the highest possible quality developer > experience. Less can go wrong when everything is simpler. *If your bank > has OAuth 2.0 in production you must ask yourself, do they really know what > they're doing?* > > TAuth is available in production today for our existing beta users and > we've already begun the work to make it an open standard we hope the > industry adopts. If you're at a bank and want to offer your customers the > security they deserve email me - *sg at teller.io <http://teller.io>* > > Sign up for the beta waiting list at Teller.io <http://teller.io/>. > _______________________________________________ OAuth mailing list > OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth > -- Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!
- [OAUTH-WG] TAuth Dick Hardt
- Re: [OAUTH-WG] TAuth Brock Allen
- Re: [OAUTH-WG] TAuth Justin Richer
- Re: [OAUTH-WG] TAuth Dick Hardt
- Re: [OAUTH-WG] TAuth Takahiko Kawasaki
- Re: [OAUTH-WG] TAuth Stevie Graham
- Re: [OAUTH-WG] TAuth Justin Richer