Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement RPC Authentication #20
Currently the RPC server is completely unauthenticated, responding to any and all requests sent to the server. Such behavior is fine for the current pre-alpha state the daemon is in, however future release should introduce a mechanism for authenticating privileged peers to the RPC server.
Two possible paths forward are first a simple password-based authentication mechanism, and a more advanced finer grained auth system which uses macaroons. The first path leads to ACL based security policies, while the second path leads to security policies implemented via bearer credentials.
In either case, gRPC's credentials package will need to be consulted in order to discern exactly how we'd like to integrate a proposed authentication mechanism into the daemon.
A tutorial for adding authentication into gRPC can be found here, and may prove useful in fixing this issue.
The password based mechanism is likely the simplest option to start out with initially. Fields within the configuration would be added for one, or many
The second proposed option is more involved, but is much more advanced and provides a very high degree of flexibility. Macaroons are decentralized bearer credentials with support for delegation, attenuation, and several other useful features. In this model, the per-RPC auth method would be used, and created macaroons can have fine-grained access policies. For example, a macaroon could be created that only allows sending 50,000
Background on Macaroons
Macaroons are described by the paper Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud. In essence, they are bearer tokens issued by a target service (in our case,
How Macaroons Work
Macaroons start as a nonce value, unique per macaroon, and an HMAC signature with a key known only to the target service. When a caveat is added, the original HMAC signature is removed but used as the key to sign the new caveat, and the new HMAC signature is appended. In this way, the recipient of the macaroon has no way of dropping previous caveats before attaching new ones, and only the target service can issue new macaroons.
First vs. Third Party Caveats
A caveat can be anything (some examples are defined by the Go Macaroon Bakery) that restricts actions a user may request a target service to take. For example, a caveat may require that the action requested is a read-only action (thus prohibiting write). This is a first-party caveat because the target service can directly verify the condition specified by the macaroon.
A caveat may also require a signature from a known key, attesting to the target service that the owner of the key approves the request based on its own criteria (with optional additional caveats). This is a third-party caveat because it requires the target service to trust the third party which owns the key. There are no use cases described below for third-party caveats, though some may exist. This could be an area with a lot of possibilities but would also require careful security analysis.
Potential Uses of Macaroons in