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

Karin_Mathys_lead
Die digitale Transformation verändert Verhalten und Erwartungen der Kunden

Nach und nach verlagern sich Teile der Customer Journey in den digitalen Kanal. Trotzdem bleibt die persönliche Beratung für den Kunden wichtig. Um die konkreten Erwartungen zu erfüllen, müssen Unternehmen bei der Gestaltung ihres Angebots die Kunden und ihre Bedürfnisse ins Zentrum stellen.

Mehr erfahren
Trust 750x410
Authentication Is Good, Trust Is Better. What About Trusting Delegated Identity?

Trust in a relationship is a must and this is not only holds true for private lives but also in the virtual life. While trustworthiness for established authentication protocols is mainly based on agreement between entities, certificates and keys, trust in the identity delegation context is ambiguous because the owner might not be the consumer of the API. This post addresses some trust concerns when introducing protocols based on identity delegation that de-facto lead to an identity paradigm shift.

Mehr erfahren
Why Large Companies Need Small Garages
Why Large Companies Need Small Garages for Their Digitization Initiatives

Many established companies face the challenge of digitization and possible disruption by innovative startups or new market entrants.

Mehr erfahren
2017_04_artificial-intelligence
Artificial Intelligence: Taking a Closer Look

Rapid advancements in and around our current state as a species have always challenged us to innovate new technologies: from farming to transportation, building to space exploration. Right now, Artificial Intelligence is experiencing a revolution. But how do you build such an advanced intelligence? Let’s take a closer look at history and some basics.

Mehr erfahren
Welcome_Lead
Google Anthos – Die Cloud Plattform der Zukunft

Niemand Geringeres als Urs Hölzle hat das Anthos-Projekt von Google in Zürich vorgestellt. Anthos soll nichts weniger als zum Linux für die Cloud werden. Unser Senior Software-Ingenieur Fabian Camenzind war dabei und gibt einen Einblick in die wesentlichen Features sowie die Vor- und Nachteile von Anthos.

Mehr erfahren