The purpose of the scheme described here — MUMBLE — is to authenticate 9p connections between Erlang on Xen nodes running 9P2000.e protocol. MUMBLE is inspired by a MUNGE authentication scheme [1].
All nodes of the Erlang on Xen cluster share a secret key. The secret key is passed on from parent to child nodes.
When a node establishes a 9p connection to another node, it issues a Tauth message and then writes a single MUMBLE message to the afid. The MUMBLE message contains the node and group ids of the originating node authenicated by MAC based on the secret key. A correct MAC confirms that the message was encoded by the node belonging to the same Erlang on Xen cluster. The recieving node then decides whether to grant access based on the provided credentials.
The MUMBLE message also carries a session key that may be used for recovering 9p connections when a transport connection is reestablished. Additional information may be encoded in the Extra field.
A MUMBLE message can be represented in binary or textual format. The binary encoding of a MUMBLE message is given below. The number encoding is little-endian (LSB).
Size | Description | Notes |
---|---|---|
2 | Version number | 0x0100 |
20 | MAC | HMAC-SHA1 of the entire message |
8 | Session key | |
4 | Time encoded | time_t |
4 | Time to live | in seconds |
2 | L1 | |
L1 | Node id | e.g. “550e8400-e29b-41d4-a716-446655440000” |
2 | L2 | |
L2 | Group id | e.g. “swarm1” |
4 | L3 | |
L3 | Extra |
The textual representation of the MUMBLE message can be obtained by base64-encoding of the binary format, prepending a string “MUMBLE:” to the beginning of the string and “:” to its end.
MUMBLE messages are not encrypted. It is assumed that the cluster uses a secure private network most of the time. For inter-datacenter communications, 9p connections should use an encrypted tunnel, protecting MUMBLE messages along the way.
MUNGE project (link).