05. Dezember 2016

MAC Token Profile: the Never-Ending Battle over Signatures

MAC Token Profile: the Never-Ending Battle over Signatures<br/>

Whilst comparing different authentication schemes such as HTTP Basic Authentication vs. HTTP Digest Access Authentication, one-way SSL vs. two-way SSL, SAML vs. WSS or OAuth 1.0 vs. OAuth 2.0  one notices that they all address similar problems when it comes to apply signatures in order to achieve the known AAA principles. However, the way and where digital signatures are applied, especially to new authentication protocols such as OAuth, can open new and interesting scenarios to secure API.

The numerous feedback received from the “Authentication vs. Authorization with OAuth” blog (Knupfer Rainer, Bricalli Cristina. 2016) shows that we have maybe indeed put too many irons in the fire. We introduced different OAuth specification versions, we mentioned Bearer Tokens and signatures, briefly evaluated the pro and cons of PKI vs. shared key and designed an overall architecture of a self-registering portal. That’s a lot! It was to our great satisfaction that the requirement of strong authentication for confidential exposed information has been understood. However, we feel the need to go one step further to clarify different aspects regarding signatures and token type in the context of OAuth that often lead to confusion.

Technical architects and software engineers often need to deal with many details, different types of architectures, technical specifications and buzzwords and so it may happen that “subtle” differences such as signing the request and tokens do not emerge straight away. While the first secures the communication between two parties, the signed tokens are used to protect token integrity and are necessary to establish a trusted relationship between the authorization server and protected resource.

(Source: Understanding Trust-Direction. 2016)

Referring to the previously written blog post, the OAuth 1.0a 2-legged usage falls in the category of protecting the request. As a “collateral” effect, we achieved strong authentication. However, apart from the fact that OAuth specification was originally developed to protect insecure communication, the stated objective was to create an authorization delegation protocol (hueniverse. 2016). In this delegation process, the acquired token for accessing the protected resource plays the most important aspect.

In the token context used with the OAuth2.0 specification, we encounter the Bearer Token Profile (RFC 6750, 2016) and the Message Authentication Code (MAC) Token Profile (OAuth 2.0 Message Authentication Code (MAC) Tokens. 2016). Comparing Bearer Tokens and MAC Tokens is like comparing cash with credit cards. While the former can be used by anyone without legitimation, the MAC Tokens must be first signed in order to be used and validated thereafter. In fact, the MAC Tokens specification defines how clients must sign the OAuth 2.0 request required by the service provider. As a matter of fact, the Bearer Token must be used in a trusted environment with secure HTTPS communication channel. In contrast, MAC Tokens can be used in different scenarios such as: Integrity protection over insecure channels, Point-to-Point Encryption (P2PE) or End-to-End Encryption (E2EE) over multiple hops. Similar to the signed request, a signed token has the benefit of offering an authentication and non-repudiation mechanism.

The idea behind a MAC is to produce a message that is impossible to create without the secret key. The HMAC integrates a hashed message and the key using the HMAC-SHA1 or HMAC-SHA256 algorithm (Krawczyk et.Al., 1997) so that the receiver can check the integrity and authenticity.

Message authentication code (Source: Wikipedia. 2016)

The good thing about this method is that it’s not necessary to have a complex PKI infrastructure in place or deal with various aspects of the X509 certificates such as the certificate authority and chain of trust. As with any symmetric key encryption solution, the parties need to deal with key distribution and protection of secret keys. OAuth 2.0 is mainly a 3-legged protocol that accesses the protected resource with the previously exchanged Authorization Grant for an Access Token and so the token is used to calculate the MAC.

In order to validate the request, the OAuth 2.0 MAC Token Profile defines the mac_key, a session key used as the key to sign and the encrypted shared key embedded in the access_token. Of course, this profile uses nonce and timestamp in order to detect and mitigate replay attacks but this is the approximate way this profile exchanges the secret over the wire.

A bit confused after reading both blog posts? Is it not controversial to advocate the OAuth 1.0a 2-legged schema with PKI infrastructure in one discussion and then go on to “promote” the OAuth 2.0 3-legged schema with symmetric encryption? A consultant would answer, yes but … it depends. Indeed, securing API is not a trivial matter that can be solved without raising doubts. The best approach would be to technically compare the two specifications and find the right usages, but this is not up for discussion here. For the sake of simplicity, we can assert that OAuth 1.0a is definitively a secure and tested signature-based protocol successfully used in enterprise environments. Even if OAuth 2.0 seems to be an evolution, in reality it is a different approach security wise. At present, enterprise environments with security gateways in place still tend to adopt OAuth 1.0a while OAuth 2.0 is mainly used in social networks where more moderate security is required. The MAC Token profile is more sophisticated to implement for the client and the resource server. Furthermore, the proposal has not yet been finalized and verisimilar it is not widely adopted by the IT-industry.

References

hueniverse. 2016. Beginner’s Guide to OAuth – Part III : Security Architecture | hueniverse. [ONLINE] Available at: https://hueniverse.com/2008/10/03/beginners-guide-to-oauth-part-iii-security-architecture/. [Accessed 13 September 2016].

RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage. 2016. RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage. [ONLINE] Available at: https://tools.ietf.org/html/rfc6750. [Accessed 13 September 2016].

draft-ietf-oauth-v2-http-mac-05 - OAuth 2.0 Message Authentication Code (MAC) Tokens. 2016. draft-ietf-oauth-v2-http-mac-05 - OAuth 2.0 Message Authentication Code (MAC) Tokens. [ONLINE] Available at: https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05. [Accessed 13 September 2016].

Krawczyk, Bellare, Canetti. 1997. HMAC: Keyed-Hashing for Message Authentication. [ONLINE] Available at: https://www.ietf.org/rfc/rfc2104.txt. [Accessed 14 September 2016].

Knupfer Rainer, Bricalli Cristina. 2016.  Authentication vs. Authorization with OAuth, Does It Really Matter?, Available here (Accessed: 16th September 2016).

Understanding Trust Direction. 2016. Understanding Trust Direction. [ONLINE] Available at: https://technet.microsoft.com/en-us/library/cc731404(v=ws.11).aspx. [Accessed 27 September 2016].

Wikipedia. 2016. Message authentication code - Wikipedia, the free encyclopedia. [ONLINE] Available at: https://en.wikipedia.org/wiki/Message_authentication_code. [Accessed 27 September 2016].


Rainer Knupfer
Rainer Knupfer

Rainer Knupfer is a Lead Engineer at ti&m, graduated in Computer Science and IT-Information Security and has accumulated the right mix between education, consulting experiences and hands-on jobs. He's particularly interested in different aspects of technical security applied to software integration and development in different domains such as digital payment, security authentication design, regulatory compliance and omni-channel applications.

Ähnliche Artikel

emily-morter-188019-unsplash
Cloud Computing – Macht NoOps den IT-Betrieb bald überflüssig?

Während viele Unternehmen noch damit beschäftigt sind, im Rahmen ihrer agilen Transformation eine DevOps-Kultur einzuführen, entwickelt sich im Tooling-Bereich schon der Begriff NoOps, um weitere Schritte auf dem Weg zur vollständigen Automatisierung im Software-Betrieb zu beschreiben. Braucht es in Zukunft überhaupt noch ein Operations-Team?

Mehr erfahren
Analytics 750x410
Big Data - Many Talk About It, We Do It!

We’ve been working on big data topics in our labs and with our clients for quite a while now. Over time, we built a framework of technologies and utilities we can build data driven projects on. We call it ti&m analytics.

Mehr erfahren
I do not love you
I do not love you

For most readers, the title above probably has a strong negative connotation. What if instead of "you", the name of a company was used? The statement still has the same negative connotation, but an opinion of a customer regarding a company might be even more sensitive – at least from a sales point of view. Such public reviews constitute important sources of information for both prospective clients and companies alike. How can one identify, ideally in an automated way, such polarised opinions in the vastness of today’s cyberspace?

Mehr erfahren
aikido 750x410
Digitales Aikido in der Finanzindustrie

Technologische Fortschritte wie Automatisierung und künstliche Intelligenz gehen auch am Private Banking nicht vorbei. Matthias Plattner plädiert für eine Verbindung alter Werte und neuer Technologien und zieht eine Analogie zur Kampfsportart Aikido.

Mehr erfahren
2017_07_HCE-payment
How Does HCE Address the EMV Goals?

Not a day goes by without new mobile payment apps popping up or the Original Equipment Manufacturers, also called OEMs, launching their own mobile wallets (Apple Pay, Samsung Pay, Android Pay) in additional countries. Especially Switzerland plays an interesting role by focusing on the payment solution TWINT to solve the local mobile payment needs. However, regardless of the payment app and underlying technology, all solutions need to balance usability and security in order to justify a valid business case.

Mehr erfahren