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

Homeoffice_work_business
Banking – made in Swiss Homeoffices

Wandelt sich das Homeoffice nun auch für die Schweizer Bankenwelt zur Normalität? Zumindest ist sicher, dass die Covid-Krise langfristige Auswirkungen auf die Bankenkultur haben wird. Anhand von vier Hypothesen zeigen wir mögliche Veränderungen auf.

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
Security 750x410
Warum Security ohne Usability zu Fehlern führt!

Neue regulatorische Anforderungen wie PSD2 und GDPR, sowie die ansteigende Bedrohung durch Cybercrime haben das Thema Security ganz oben auf die Agenda gesetzt. Kritisch ist aber, wie diese erhöhten Security-Anforderungen umgesetzt werden. Ungenügende Security macht angreifbar, andererseits kann schlecht umgesetzte Sicherheit zum Business-Killer werden.

Mehr erfahren
cloud_man_mountain
Von der Hybrid Cloud zur Multi-Cloud – Neue Möglichkeiten für Ihren Erfolg

So. Da haben wir jetzt Private Cloud, Public Cloud und Hybrid Cloud. Und jetzt kommt dann noch eine Multi-Cloud. Wozu? Was ist da überhaupt der Unterschied?

Mehr erfahren
murer_lead
Eine Einführung in Open Banking

Open Banking // Schweizer Banken müssen sich zwar nicht mit Open Banking auseinandersetzen, sollten es aber auf jeden Fall tun. Wenn Open Banking richtig umgesetzt und implementiert ist, dann sind Banken besser für die Zukunft gerüstet. Dabei gibt es auch kulturelle Fragen zu bedenken.

Mehr erfahren