Ncat HTTP Digest authentication; nonce strategy

[David Fifield <david () bamsoftware com>]

I've been working on integrating the research and coding that Venkat did
last summer on HTTP Digest authentication for Ncat in proxy mode.

http://seclists.org/nmap-dev/2009/q3/773

The way I've been using it is

cd ~/nmap/ncat
svn switch svn://svn.insecure.org/nmap-exp/david/ncat-digest

I'm writing this to explain some implementation decisions and see if
anyone has suggestions.

Digest authentication, from RFC 2617, is a bit more secure than Basic
authentication, already supported by Ncat, which sends the user name and
password as cleartext. Digest works by the server sending a nonce, and
then the client sending back (basically)

MD5(MD5(username:password):nonce:MD5(method:uri))

The server does the same computation using its knowledge of the
password, and allows access only if it matches the client's. The nonce
is supposed to be uniquely generated every time the server challenges
the client. The nonces I implemented for Ncat look like this:

1263929285.015273-a8e75fae174fc0e6a5df47bf9900beb6

The first part is the current time (from gettimeofday). The second part
is a hash of the time and a server secret. The secret is randomly
generated once when the server is started. So the structure of the nonce
is this:

timestamp-MD5(secret:timestamp)

This is the same nonce format recommended by RFC 2617, section 3.2.1,
except that it doesn't include an ETag because we don't have access to
those. This format allows us to check the age of a nonce when it comes
back from the client, and ensure that it was one we issued, without
having to keep a list of issued nonces in memory.

In at least one way, this code doesn't meet the full potential of Digest
authentication: it doesn't fully prevent replay attacks. An eavesdropper
can copy one of your requests to the proxy and cause the same request to
be sent again. (But not just any arbitrary request.) To mitigate this,
I've limited the lifetime of nonces to 10 seconds, which should be
enough time for a client to send its followup request after receiving
the nonce.

To fix this would require keeping a list of recent nonces (not all of
them that have been issued, but only those that have been used to
authenticate successfully, and only up until the nonce lifetime has
expired). This is difficult to do with Ncat's current architecture,
because client requests are processed after forking. At that point, it's
not easy to change global state in the parent listening process.

Ncat will offer both Basic and Digest authentication to clients. A
client is supposed to pick the best authentication scheme it supports.

Apart from the server doing Digest authentication of clients, Ncat will
also be able use Digest to authenticate itself to another proxy as a
client.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/