OAuth-J Announces OAuth Optical Transport Profile for Network Resilience, Applying Cryptocurrency Technology

【AF Wire, Tokyo】The OAuth Foundation Japan (OAuth-J) announced on April 1, 2018 that it would begin developing the OAuth Optical Transport Profile (OAuth OTP), a new OAuth profile designed to work even with Internet-isolated networks.

OAuth [RFC6749] is an API protection technology widely used not only by GAFAM (Google, Apple, Facebook, Amazon, and Microsoft), but also by mobile carriers, banks, airlines, media companies, government agencies, and others, and is a core technology of the API economy. However, because it relies on HTTPS as its communication protocol (transport), it has had the drawback that processing cannot be performed when servers are distributed across multiple disconnected networks due to the recent trend toward network resilience—for example, in an Internet-isolated environment where the client is on the internal network and the authorization server is on the Internet side¹. Consequently, strengthening network resilience carried the risk of being left behind by the API economy.

To solve this problem, OAuth OTP introduces optical transport for use between internal and external networks in place of HTTPS. Specifically, it uses the two-dimensional code technology found in paper wallets, which are often used to improve the security of cryptocurrency transactions employing blockchains: authorization requests and responses are printed on paper and then processed by scanning them with an optical reader connected to the network on the other side. When converting a request into a two-dimensional code, a unique 4-digit ID called a nonce is generated separately and included in it², and the same ID is included in the response³. This also protects against code injection attacks⁴. In addition, because paper is scanned with an optical reader, unlike methods that use USB flash drives, it also protects against supply-chain contamination⁵ and related BadUSB⁶ attacks.

This draft specification had been scheduled for submission to the IETF as an I-D during fiscal year 2017, before this announcement. However, according to editor Nat Sakimura, “Even on April Fools’ Day, it is unacceptable to tell the malicious lie that fiscal year 2017 has ended.” Accordingly, it has still not been submitted as of today.

Nov Matake, Executive Director of OAuth-J, expressed his expectations as follows:

“This draft specification is the decisive solution that will save many Japanese organizations from falling out of the API economy, and its benefits will spread not only across Japan but also to many organizations in Asia and elsewhere that follow Japan’s example. OAuth-J therefore hopes to submit the draft to the Universe Standardization Organization as well and obtain a USO number. We would prefer a number in the 800 range, but given the recent state of number allocation, it is too early to say whether that wish will be granted.”

Update on April 2

Apparently it is customary to reveal the joke on 4/2, so here goes: I think this would actually work. Whether there is any use for it needs further consideration, though. Incidentally, the QR codes in the diagram really do contain an OAuth request and response. They use the code flow, however. In an actual isolated network, the code flow would require another 1 round trip, so it is not practical. The implicit flow would be preferable.

In that case, the access token would be printed in plain text in the QR code. Surveillance cameras would naturally be installed in a place where this kind of work is performed, creating a risk that the access token could leak from those images and then be used. The access token therefore needs to be encrypted or sender-constrained. The former would no longer be covered by RFC 6749 and would also have implications if the token leaked through other means, so the latter would be preferable. In that case, one possible approach would be for the client to register its public key with the AS in advance, include the keyhash in the AT, and use it in combination with MTLS. If the resource is on the internal network, this would eliminate the need to connect to the external network. If the resource is on the external network, it would be practical to retrieve the data on the external network and then bring the data into the internal network before working with it.

Also, when printing a QR code, I think its expiration date should be printed in a human-readable form. Once it has expired, it should be discarded or archived.

1. When the resources being handled are personally identifiable information[JIS X 9250], individuals are generally on the Internet side, so the authorization server needs to be on the Internet side.
2. Because the state variable is used, it is compatible with existing OAuth.
3. This is automatically satisfied by RFC 6749.
4. An attack that exploits weak binding between the authorization request and response to replace an authorization code with one obtained separately. Also known as a cut-and-paste attack.
5. An attack carried out within the supply chain between a product leaving the factory and reaching its user, such as replacing the product, implanting software, or degrading its performance limits under adverse conditions. Warehouses, truck beds, and similar locations are particularly vulnerable. There have been cases in which cryptocurrency hardware wallets purchased through Amazon were subjected to this attack and all the cryptocurrency was stolen. This is an especially serious issue for military supplies; under the National Defense Authorization Act, the U.S. Department of Defense requires risks to be reduced by purchasing directly from producers without using distribution channels.
6. An attack presented at Black Hat USA 2014. It uses USB firmware to deceive a connected device, enabling various actions such as data theft.