1 / 12

Web Server Design Week 11

Web Server Design Week 11. Old Dominion University Department of Computer Science CS 495/595 Spring 2010 Martin Klein <mklein@cs.odu.edu> 3/24/10. Digest Authentication. Still based on the challenge / response mechanisms first employed in “Basic” authentication Same: status code 401

sarah
Download Presentation

Web Server Design Week 11

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Server DesignWeek 11 Old Dominion University Department of Computer Science CS 495/595 Spring 2010 Martin Klein <mklein@cs.odu.edu> 3/24/10

  2. Digest Authentication • Still based on the challenge / response mechanisms first employed in “Basic” authentication • Same: • status code 401 • WWW-Authenticate response header • Authorization request header • New: • Authentication-Info response header • We will ignore the sections that deal with backward compatibility with RFC 2069

  3. Response WWW-Authenticate: Digest (1) realm=”mklein@www.cs.odu.edu", (2) domain=“http://www.cs.odu.edu/~mklein/teaching/cs595-s10”, (3) qop="auth,auth-int", (4) nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", (5) algorithm=“MD5”, (6) stale=“false”, (7) opaque="5ccc069c403ebaf9f0171e9517f40e41" similar to Basic’s notion of realm list of URIs for which this challenge applies (all URIs at the server if not listed) quality of protection: authentication, authentication with integrity opaque data stream issued by the server per 401 challenge (not per access!) the algorithm used to encode the secrets if “true”, then password is good, but previous nonce is old (retry w/ new nonce, don’t prompt user) opaque data stream issued by the server for a particular domain

  4. Request Authorization: Digest username=“mklein”, (1) realm=”mklein@www.cs.odu.edu", (2) uri=“http://www.cs.odu.edu/~mklein/teaching/cs595-s10/ a4-test/limited2/foo/”, (3) qop=auth, (4) nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", (5) nc=00000001, (6) opaque=”8ab38009c403ebaf9f0171e9517f40e41b”, (7) cnonce=“dcd98b7102dd2f0e8b11d0f600bfb0c093”, (8) response=“6629fae49393a05397450978507c4ef1” specifies the realm specifies the URI in a particular domain quality of protection: authentication, authentication with integrity the nonce provided by the server in the 401 response (hex value) nonce count -- how many times this nonce has been used opaque data stream issued by the server for a particular domain client-generated nonce the request digest

  5. Constructing the Request Digest request digest = md5(md5(A1):nonce:ncount:cnonce:qop:md5(A2)) • if algorithm == MD5, • A1 = username:realm:password • elsif algorithm == MD5-sess • A1 = md5(username:realm:password):nonce:cnonce • if qop == auth • A2 = method:URI • elsif qop == auth-int • A2 = method:URI:md5(entity-body) sections 3.2.2.1 - 3.2.2.3 in RFC 2617

  6. Generating Nonce / Opaque Values “nonce” suggestion from 3.2.1: base64(time-stamp md5(time-stamp:ETag:private-key)) note whitespace! “opaque” discussed in 3.3, but no suggestions are given. this field can be used to encode server state information; esp. useful if after authentication, a 301/302 is generated. We’ll use: md5(URI:private-key)

  7. Authentication-Info Response Header Authentication-Info: (1) nextnonce=“1a28b7102dd2f0e8b11d0f600bfbdd441” (2) qop=auth, (3) rspauth="d3b07384d113edec49eaa6238ad5ff00", (4) nc=00000001, (5) cnonce=“dcd98b7102dd2f0e8b11d0f600bfb0c093” optional, allows 1 time nonce values (at expense of efficiency; consider nonce count instead) quality of protection: authentication, authentication with integrity optional, supports mutual authentication (server knows client’s password) nonce count -- how many times this nonce has been used client-generated nonce

  8. Constructing the Response Authorization same as constructing the request digest that goes into the “Authorization” request header, except: • if qop == auth • A2 = :URI • elsif qop == auth-int • A2 = :URI:md5(entity-body) (same as before, but the method is not applicable. note leading colon!) section 3.2.3 in RFC 2617

  9. Request for A Digest Protected URI GET http://www.cs.odu.edu:80/~mklein/teaching/cs595-s10/a4-test/limited2/foo/bar.txt HTTP/1.1 Host: www.cs.odu.edu Connection: close ---- HTTP/1.1 401 Authorization Required Date: Wed, 24 Mar 2010 15:22:23 GMT Server: Apache/2.2.14 (Unix) DAV/2 PHP/5.2.11 WWW-Authenticate: Digest realm="Go Monarchs!”, nonce="AASCjX87Cgc=9e3f538c2bd88f60535ebf7d72f9270a7f39e599”, algorithm=MD5, qop="auth" Content-Length: 496 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>401 Authorization Required</title> </head><body> <h1>Authorization Required</h1> <p>This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.</p> <hr> <address>Apache/2.2.14 (Unix) DAV/2 PHP/5.2.11 Server at www.cs.odu.edu Port 80</address> </body></html>

  10. Re-Request With Authorization Header GET http://www.cs.odu.edu:80/~mklein/teaching/cs595-s10/a4-test/limited2/foo/bar.txt HTTP/1.1 Authorization: Digest username="mklein", realm="Go Monarchs!”, uri=http://www.cs.odu.edu:80/~mklein/teaching/cs595-s10/a4-test/limited2/foo/bar.txt, qop=auth, nonce="AASCjX87Cgc=9e3f538c2bd88f60535ebf7d72f9270a7f39e599”, nc=00000001, cnonce="00a3722f4d2ba9bf069fb7831ed17f10”, response="383dba13ad3b180ab0e9eaec9b3f2993" Host: www.cs.odu.edu Connection: close ---- HTTP/1.1 200 OK Date: Wed, 24 Mar 2010 15:22:23 GMT Server: Apache/2.2.14 (Unix) DAV/2 PHP/5.2.11 Authentication-Info: rspauth="b88e779d36f52bbf20546893d2cd8178”, cnonce="00a3722f4d2ba9bf069fb7831ed17f10", nc=00000001, qop=auth Last-Modified: Sun, 07 Jan 2007 23:04:10 GMT ETag: "6a17a9-12-4267b54a86e80" Accept-Ranges: bytes Content-Length: 18 Connection: close Content-Type: text/plain Can you see this?

  11. Client-Side Code Snippets # parse nonce and opaque (if it exists) values from the server response … $cnonce = md5_hex(”Blue wins the CAA"); $ncount = "00000002"; $a1 = md5_hex("mklein:Go Monarchs!:mypwd"); $a2 = md5_hex("GET:$baseURL" . "limited2/foo/bar.txt"); $response = md5_hex("$a1:$nonce:$ncount:$cnonce:auth:$a2"); … # GET 200 $test[7]="\ GET $baseURL" . "limited2/foo/bar.txt HTTP/1.1 Authorization: Digest username=\"mklein\", realm=\”Go Monarchs!\", uri=\"$baseURL"."limited2/foo/bar.txt\", qop=auth, nonce=\"$nonce\", nc=$ncount, cnonce=\"$cnonce\", response=\"$response\" Host: $host Connection: close "; note that values for nc & qop are not quoted

  12. How… > pwd /home/mklein/public_html/teaching/cs595-s10/a4-test/limited2 > more .htaccess AuthType Digest AuthName "Go Monarchs!" AuthDigestProvider file AuthUserFile /home/mklein/cs595passwd-digest Require valid-user > more /home/mklein/cs595passwd-digest mklein:Go Monarchs!:135580cdbef2cbec785601f177446ba7 Apache % more ~/public_html/teaching/cs595-s10/a4-test/limited2/WeMustProtectThisHouse\! # # A4 password file # authorization-type=Digest # realm="Colonial Place" # mklein:Go Monarchs!:135580cdbef2cbec785601f177446ba7 Our Server

More Related