From flud

[edit] Authentication for flud Operations

Authentication is done via standard http authentication, with special semantics for username and password which allows the server to issue a cryptographic challenge to the client. This challenge can only be answered by the owner of the private key that corresponds to the node's identity, so this provides a strong self-certifying identity-check mechanism, ensuring that nodes cannot masquerade as others. The password field also requests a challenge for group identity. Details are explained below

[edit] Authentication Details

Each client request is responded to with a 401 response in the header, with a challenge in the header message and repeated in the body. The client reissues the response, filling the user 'username' field with the challenge-response and the 'password' field with groupIDu. The client must compute the response to the challenge each time by examining this value. The groupIDu never changes, so the client can simply send this value back with the response. This implies some server-side state; since the server responds with a 401 and expects the client to send a new request with an Authorization header that contains the challenge response, the server has to keep some state for each client. This state expires after a short time, and implies that client must make requests to individual servers serially.

A node's groupIDu is the same globally for each peer, so exposing it to one adversarial node means exposing it to all. At first glance, this seems bad, but groupIDu is useless by itself -- in order to use it, a node must also be able to answer challenges based on Kr. In other words, the security of groupIDu in this setting depends on Kr, and exposure of one node's groupIDu does not compromise the groupIDu for other nodes of the same group.