1. The Elbert HTTP Server HTTP Authentication, providing security in tough times By: Shawn M. Jones

2. Updated FSM

3. Authentication FSM

4. 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 #4 6.If they match, return 200 7.If not, return 401 with WWW-Authenticate header

5. Authentication:Digest 1.Parse the Authorization header into key-value pairs 2.Determine if the nonce is stale, or invalid; if invalid, return 401; if valid, go on 3.Use the username to find the MD5-hashed secret known by the server MD5(username:realm:password), store it as A1 4.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 client 7.If they match, return 200 8.If not, return 401 with WWW-Authenticate header

6. Is the given nonce stale? 1.Extract the nonce used the client from the headers 2.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 401 5.If the timestamp is not the current timestamp, the nonce is stale; send a 401 with stale=True 6.Otherwise, it is fresh; so continue to process

7. 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

8. 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

9. 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.

10. Work Remaining Authentication: Digest – WWW-Authenticate header stale – Authorization header nextnonce – qop type auth-int – algorithm type MD5Sess

11. 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)?