The Elbert HTTP Server

HTTP Authentication, providing security in tough times

By: Shawn M. Jones

Updated FSM

Authentication FSM

Authentication: Basic

1. Split the Authorization header, extracting the base64-encoded secret

2. Decode the base64-encoded secret, extract the username and password

3. Use MD5 to generate a one-way hash of the password supplied by the client

4. Use the username to find the hashed password known by the server

5. Compare the hashed value from #3 to #46. If they match, return 2007. If not, return 401 with WWW-Authenticate header

Authentication:Digest1. Parse the Authorization header into key-value pairs2. Determine if the nonce is stale, or invalid; if invalid, return 401;

if valid, go on3. Use the username to find the MD5-hashed secret known by the server

MD5(username:realm:password), store it as A14. Calculate A2 based on the value of qop

1. If qop == “auth” then A2 = “:URI”2. elsif qop == “auth-int” then A2 = “:URI:MD5(entity-body)”

5. Create a digest using the data provided by the client, mixed with the A1 calculated form the server, of the form MD5(A1:nonce:ncount:cnonce:qop:MD5(A2))

6. Compare #5 with the “response” value provided by the client7. If they match, return 2008. If not, return 401 with WWW-Authenticate header

Is the given nonce stale?

1. Extract the nonce used the client from the headers2. base-64 decode it and split on whitespace to get the

timestamp and the md5-hashed value of (timestamp:ETag:private-key)

3. use the given timestamp along with the ETag and private-key to generate an MD5-hashed value

4. If it is valid, continue; otherwise send a 4015. If the timestamp is not the current timestamp, the

nonce is stale; send a 401 with stale=True6. Otherwise, it is fresh; so continue to process

Completed Work

• Status 416 for bad ranges• Authentication: Basic– Parse the WeMustProtectThisHouse! File– logging the username in Common Log Format– WWW-Authenticate Header with Basic and realm– Authorization header with Basic and realm– Comparison of secret supplied by client with one known by

server– 200 OK if they match– 401 if they don’t, or if no challenge was made to begin with

Completed Work

• Authentication: Digest– Parse the WeMustProtectThisHouse! File– logging the username in Common Log Format– Can Parse Authorization Request Header with Digest

• username• realm• uri• qop• nonce• nc• opaque• cnonce• response

Completed Work• Authentication: Digest

– WWW-Authenticate Response header (401)• realm• domain• qop• nonce• algorithm• opaque

– Authentication-Info Response header (200)• qop• rspauth• nc• cnonce

• 401 trumps 404• 404 in cases where Authentication is successful, but the URI has no representation• GET/HEAD with Range header works with Authentication• 400 for malformed directives, a URI in the request line that doesn’t match the uri

directive, etc.

Work Remaining

• Authentication: Digest– WWW-Authenticate header• stale

– Authorization header• nextnonce

– qop type auth-int– algorithm type MD5Sess

Questions for Dr. Nelson

• The client doesn’t request MD5-sess, so when does the server use it (PUT and POST?)

• When does the client request auth-int, with PUT and POST?

• For the domain part of WWW-Authenticate, do we just list files or are directories considered valid resources too?

• For slow clients (or connections with high latency or low bandwidth), wouldn’t the nonce always be stale?

• What do we do with the cnonce?• What do we do for content negotiation, 300, 301, 302 (i.e.

items that have no effective ETag for use in a nonce)?