This article builds on some of the ideas presented in the article, Using Ethereum and Metamask for Website Authentication. You might want to read that before this…

RADIUS 802.1x — Background

Most corporate/enterprise environments use some sort of Radius authentication to secure access to their network. The Radius authentication protocol, RFC 2865, is really just a framework for authentication. It defines

the different endpoint roles and message types that make up an authentication procedure. For example, the RADIUS specification specifies that a User (called a Supplicant) sends an Access Request message to a Network Access Server (NAS), which in turn sends a RADIUS Access Request packet to a RADIUS Server. The protocol specifies that the RADIUS Server can respond to the NAS with a RADIUS Access-Challenge Packet, etc.



While the RADIUS protocol specifies over a dozen message types, it is agnostic regarding the actual contents of those messages. This is accomplished by using Attribute-Value pairs (AVP’s) within the messages. Each AVP specifies an attribute type, length, and value. So to really get to the nuts and bolts of the industry-standard RADIUS authentication protocol we need to dig a little deeper into the specific authentication types. These are almost always part of the Extensible Authentication Protocol , or EAP suite of Authentication protocols.

EAP

EAP or Extensible Authentication Prootcol (RFC 3748) is also really just a framework for authentication. That is, EAP is not a specific authentication mechanism; instead it specifies common functions and the negotiation of authentication methods called EAP methods. There are currently about 40 different methods defined in the EAP protocol, with sub-protocols defining the actual authentication mechanisms.



Before we go into one of the specific EAP methods, let’s be clear. EAP messages are generally sent from a user to a Network Access Server (NAS), which re-packages the EAP messages into RADIUS Access-Request packets (as EAP AVP’s). The NAS then sends the RADIUS Access-Request packets to the RADIUS Server. The RADIUS Server optionally responds to the NAS with RADIUS Access-Challenge messages, (which also contain EAP AVP’s). The NAS may then communicate with the Supplicant to get the required information to answer Access-Challenge messages, via another RADIUS Access-Request message. Finally the RADIUS Server responds to the NAS with a RADIUS Access-Granted message. And subsequently the NAS communicates with the Supplicant, granting access to the requested network resources.

Simplified view of an authentication using an EAP variant with a challenge/response protocol

EAP-CHAP

There are over 50 EAP authentication methods (sub-protocols). But for

the purpose of this article I will focus on the EAP authentication method called EAP-CHAP (RFC 1994). In EAP-CHAP an Authenticator sends a “challenge” message to the user (Peer). In response the Peer computes a hash based on the challenge and a shared secret. The Authenticator checks the response against its own calculation of the expected hash value. If the values match, then the Authenticator acknowledges the authentication; otherwise access is denied.



EAP-CHAP is supported by almost all RADIUS Servers. It is considered

somewhat secure because the secret is never transmitted in any message. Nevertheless, in practice EAP-CHAP suffers from security considerations relating to the initial communication of the shared secret between the Peer and the Authenticator.

MetaMask Authentication

We are proposing an authentication mechanism that is conceptually similar to EAP-CHAP: Similar to EAP-CHAP, an Authenticator sends a “challenge” message to the user, and without revealing any private information the user generates a response which the Authenticator can check, by performing it’s own own calculation. However to use MetaMask for authentication the generated response is actually a Keccak signature (ECDSA signature of Keccak hash) of the challenge message; and the Authenticator uses the ECRecover function to derive the Ethereum account address from the signature, and then to check that against the account address on file.

Although the CHAP specification does not directly specify all the possible hashing functions that could be used (RFC 1700), it does mandate the that the MD5 hash must be supported — and in practice that is the de facto hash that is used. In addition, even though the mechanics of our proposed authentication mechanism would be very similar to EAP-CHAP, the specification makes it clear that the Authenticator executes a hash function on the challenge and shared secret in order to validate the Peer’s response. For these and other reasons we are proposing an entirely new EAP protocol.

EAP-Keccak

In our proposed EAP-Keccak authentication protocol, the shared secret

is replaced with a shared account-address. The challenge is specified as an ASCII message, including a URI (identifying the Authenticator), and a “block-height”. While the protocol will not mandate that the block-height correspond to the height of the Ethereum blockchain, it will mandate that the block-height change with each authentication (and in that way it serves the function of salt in the challenge). In EAP-Keccak the Authenticator would execute the EC-Recover computation on the Challenge response in order to validate the Peer’s shared account-address. The protocol would otherwise be analogous to EAP-CHAP.



We anticipate that the EAP-Keccak proposal will encounter relatively little opposition, as it is mechanically very similar to EAP-CHAP, and EC-Recover is generally acknowledged to be more secure than MD5. Moreover, use of this authentication technique in a RADIUS setting is vastly more secure than EAP-CHAP, because it obviates the need to communicate a shared secret between the Peer and the Authenticator. In practice people will use MetaMask, or a similar tool to sign the Challenge message. In this way a user only needs to remember a single strong password (to unlock MetaMask), and never needs to communicate that password to anyone. Think of that:

Just one password to remember; What a relief!

Ethereum Wildfire Project

The Ethereum Wildfire Project is gearing up to submit an Internet Draft to the IETF, in order formalize the EAP-Keccak protocol. At the same time we plan to submit a module supporting EAP-Keccak to the FreeRadius project (which supplies a very popular, free, open-source RADIUS server). We believe that the most effective way to popularize the Ethereum-based login technique is via enterprise adoption; that is, workplaces that adopt this protocol will require their employees to use it. Check out the Token-Sale section of our website to see how you can contribute to help us evangelize this technique.

Yaniv Shapiro & Radhika Anand

for the Ethereum Wildfire Project