The Elbert HTTP Server

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 • Split the Authorization header, extracting the base64-encoded secret • Decode the base64-encoded secret, extract the username and password • Use MD5 to generate a one-way hash of the password supplied by the client • Use the username to find the hashed password known by the server • Compare the hashed value from #3 to #4 • If they match, return 200 • If not, return 401 with WWW-Authenticate header

5. Authentication:Digest • Parse the Authorization header into key-value pairs • Determine if the nonce is stale, or invalid; if invalid, return 401; if valid, go on • Use the username to find the MD5-hashed secret known by the server MD5(username:realm:password), store it as A1 • Calculate A2 based on the value of qop • If qop == “auth” then A2 = “:URI” • elsifqop == “auth-int” then A2 = “:URI:MD5(entity-body)” • 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)) • Compare #5 with the “response” value provided by the client • If they match, return 200 • If not, return 401 with WWW-Authenticate header

6. Is the given nonce stale? • Extract the nonce used the client from the headers • base-64 decode it and split on whitespace to get the timestamp and the md5-hashed value of (timestamp:ETag:private-key) • use the given timestamp along with the ETag and private-key to generate an MD5-hashed value • If it is valid, continue; otherwise send a 401 • If the timestamp is not the current timestamp, the nonce is stale; send a 401 with stale=True • 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 • 401trumps 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)?