Note that the basic authentication protocol does not make use of the Authentication(cid:173)
`Info header we showed in Table 12-1.
`
`Base-64 Username/Password Encoding
`HTTP basic authentication packs the username and password together (separated by
`a colon), and encodes them using the base-64 encoding method. If you don't know
`what base-64 encoding is, don't worry. You don't need to know much about it, and
`if you are curious, you can read all about it in Appendix E. In a nutshell, base:.64
`encoding takes a sequence of 8-bit bytes and breaks the sequence of bits irito 6-bit
`chunks. Each 6-bit piece is used to pick a character in a special 64-character alpha(cid:173)
`bet, consisting mostly of letters and numbers.
`Figure 12-4 shows an example of using base:-64 encoding for basic authentication.
`Here, the usernameis ''brian-totty" and the password is "Ow!". The browser joins the
`username and password with a colon, yielding the packed string "brian-totty:Ow!".
`This string is thenbase·64-encoded into this mouthful: "YnJpYW4tdG90dHk6T3ch".
`
`(a) Prompt for username and password .·
`
`,_.·········-----... brian-totty
`
`~--........... -····Ow!
`
`(b) Pack username and password with colon
`
`brian-t otty··-------····· ....
`~brian -totty: Ow!
`Ow! ........ ___ ...... -~
`
`(c) Base 64 encode
`
`BASE 64ENC (brian-t otty: Ow! ) ......... .,. Yn J p YW4t dG90dHk 6T3 ch
`
`{d) Send authorization
`
`Q
`
`lient
`GET /family/jeff.j~g HTTP/1.0
`Authorization: Bas1c YnJ pYW4tdG90dHk6T3ch ................... .,.
`
`Server
`
`Figure 12-4. Generating a basic Authorization header from username and password
`
`Base-64 encoding was invented to take strings of binary, text, and international char(cid:173)
`acter data (which caused problems on some systems) and convert them temporarily
`into a portable alphabet for transmission. The original strings could then be decoded
`on the remote end without fear of transmission corruption.
`
`Base-64 encoding can be useful for usernames and passwords that contain interna(cid:173)
`tional characters or other characters that are illegal in HTTP headers (such as quo(cid:173)
`tation marks, colons, and carriage returns). Also, because base-64 encoding
`trivially scrambles the username and password, it can help prevent administrators
`
`282
`
`I Chapter 12: Basic Authentication
`
`Exhibit 2002
`IPR2016-01431 - Part 2 of 2
`
`

`
`from accidentally ·viewing us ern ames and passwords while administering servers
`and networks.
`·
`
`Proxy Authentication
`Authentication also can be done by intermediary proxy servers. Some organizations
`use proxy servers to authenticate users before letting them access servers, LANs, or
`wireless networks; Proxy servers can be a convenient way to provide unified access
`control across an.organization's resources, because access policies can be centrally
`administered on the proxy server. The first step in this process is to establish the
`identity via proxy authentication,
`The steps involved in proxy authentication are identical to that of web server identifi(cid:173)
`cation. However, the headers and status codes are different. Table 12-3 contrasts the
`status codes and headers used in web server and proxy authentication.
`
`Table 12-3. Web server versus proxy authentication
`
`Unauthorized status code: 401
`WWW-Authenticate
`Authorization
`Authentication-Info
`
`Proxy-Authenticate
`Proxy-Authorization·
`Proxy-Authentication-Info
`
`The Security Flaws ofBasic Authentication
`Basic authentication is simple and convenient, but it is not secure. It should only be
`used to prevent unintentional access from nonmalicious parties or used in combina(cid:173)
`tion with an encryption technology such as SSL.
`
`Consider the following security flaws:
`
`1. Basic authentication sends the username and password across the network in a
`form that can trivially be decoded. In effect, the secret password is sent in the
`clear, for anyone to read and capture. Base-64 encoding obscures the usemame
`and password, making it less likely that friendly parties will. glean passwords by
`accidental network observation. However, given a base 64-encoded usemame
`and password, the decoding can be performed trivially by reversing the encod(cid:173)
`ing process. Decoding can even be done in seconds, by hand, with pencil and
`paper! Base 64-encoded passwords are effectively sent "in the clear." Assume
`that motivated third parties will intercept usemames and passwords sent by
`basic authentication. If this is a concern, send all your HTTP transactions over
`SSL encrypted channels, or use a more secure authentication protocol, such as
`digest authentication.
`
`The Security Flaws of Basic Authentication
`
`I 283
`
`

`
`2. Even if the secret password were encoded in a scheme that was more compli(cid:173)
`cated to decode, a third party could still capture the garbled usemame and pass(cid:173)
`word and replay the garbled information to origin servers over and over again to
`gain access. No effort is madeto prevent these replay attacks.
`3. Even if basic authentication is used for noncritical applications, such as corpo(cid:173)
`rate intranet access control or personalized content, social behavior makes this
`dangerous. Many users, overwhelmed by a multitude of password-protected ser(cid:173)
`vices, share usernames and passwords. A clever, malicious party may capture a
`username and password in the clear from a free Internet email site, for example,
`and find that the same usetname and password allow access to critical online
`banking sites!
`4. Bask authentication offers no protection against proxies or intermediaries that
`act as middlemen, leaving authentication headers intact but modifying the test of
`the message to dramatically change the nature of the transaction.
`5. Basic authentication is vulnerable to spoofing by counterfeit servers. If a user can
`be led to believe that he is connecting to a valid host protected by basic authenti(cid:173)
`cation when, in fact, he is connecting to a hostile server or gateway, the attacker
`can request a password, store it for later use, and feign an error.
`
`This all said, basic authentication still is useful for providing convenient personaliza(cid:173)
`tion or access control to documents in a friendly environment, or where privacy is
`desired but not absolutely necessary. In this way, basic authentication is used to pre(cid:173)
`vent accidental or casual access by curious users.*
`For example, inside a corporation, product management may password-protect
`future product plans to limit premature distribution. Basic authentication makes it
`sufficiently inconvenient for friendly parties to access this data.t Likewise, you might
`password-protect personal photos or private web sites that aren't top-secret or don't
`contain valuable information, but really aren't anyone else's business either.
`
`Basic authentication can be made secure by combining it with encrypted data trans;.
`mission (such as SSL) to conceal the username and password from malicious individ(cid:173)
`uals. This is a common technique.
`We discuss secure encryption in Chapter 14. The next chapter explains a more
`sophisticated HTTP authentication protocol, digest authentication, that has stron(cid:173)
`ger security properties than basic authentication.
`
`* Be careful that the username/password in basic authentication is not the same as the password on your more
`secure systems, or malicious users can use them to break into your secure accounts!
`t While not very secure, internal employees of the company usually are unmotivated to maliciously capture
`passwords. That said, corporate espionage does occur, and vengeful, disgruntled employees do exist, so it is
`wise to place any data that would be very harmful if maliciously acquired under a stronger security scheme.
`
`284 I Chapter 12: Basic Authentication
`
`

`
`For More Information
`For more information on basic authentication and LDAP, see:
`
`http://www.ietf.orglrfc!rfc2617. txt
`RFC 2617, "HTTP Authentication: Basic and Digest Access Authentication."
`http://www. ietf. orglrfc!rfc2 616. txt
`RFC 2616 "HypertextTransfer Protocol-HTTP/1.1."
`
`For More Information
`
`I 285
`
`

`
`CHAPTER 13
`Digest Authentication
`
`Basic authentication is convenient and flexible but completely insecure. Usernames
`and passwords are sent in the clear; and there is no attempt to protect messages
`from tampering. The only way to use basic authentication securely is to use it in con(cid:173)
`junction with SSL.
`
`Digest authentication was developed as a compatible, more secure alternative to
`basic authentication. We devote this chapter to the theory and practice of digest
`authentication. Even though digest authentication is not yet in wide use, the con(cid:173)
`cepts still are important for anyone implementing secure transactions.
`
`The Improvements of Digest Authentication
`Digest authentication is an alternate HTTP authentication protocol that tties to fix
`the most serious flaws of basic authentication. In particular, digest authentication:
`
`• Never sends secret passwords across the network in the clear
`• Prevents unscrupulous individuals from capturing and replaying authentication
`handshakes
`• Optionally can guard against tampering with message contents
`• Guards against several other common forms of attacks
`
`Digest authentication is not the most secure protocol possible.t Many needs for
`secure HTTP transactions cannot be met by digest authentication. For those needs,
`Transport Layer Security (TLS) and Secure HTTP (HTTPS) are more appropriate
`protocols.
`
`* Usernames and passwords are scrambled using a trivial base-64 encoding, which can be decoded easily. This
`·
`protects against unintentional accidental viewing but offers no protection against malicious parties.
`t For example, compared to public key-based mechanisms, digest authentication does not provide a strong
`authentication mechanism. Also, digest authentication offers no confidentiality protection beyond protect(cid:173)
`ing the actual password-the rest of the request and response are available to eavesdroppers.
`
`286
`
`

`
`However, digest authentication is significantly stronger than basic authentication,
`which it was designed to replace. Digest authentication also is stronger than many
`popular schemesproposed for other Internet services, such as CRAM-MD5, which
`has been proposed for usewith LDAP, POP, and IMAP.
`To date, digest authentication has not been widely deployed. However, because of the
`security risks inherent to basic authentication, the HTTP architects counsel in RFC
`2617 that "any service in present use that uses Basic should be switched to Digest as
`soon as practical."* It is not yet clear how successful this standard will become.
`
`Using Digests to Keep Passwords Secret
`The motto of digest authentication is "never send the password across the network."
`Instead of sending the password, the client sends a ''fingerprint" or "digest" of the
`password, which is an irreversible scrambling of the password. The client and the
`server both know the secret password, so the server can verify that the digest pro(cid:173)
`vided a correct match for the password. Given only the digest, a bad guy has no easy
`way to find what password it came from, other than going through every·password
`in the universe, trying each one!t
`Let's see how this works (this is a simplified version):
`
`• In Figure 13-la, the clientrequ~sts a protected document.
`• In Figure 13-lb, the server refuses to serve the document untiltheclient authen(cid:173)
`ticates its identity by proving it knows the password. The server issues a chal(cid:173)
`lenge to the client, asking for the username and a digested form of the password.
`• In Figure 13-lc, the client proves that it knows the password by passing along
`the digest of the password. The server knows the passwords for all the users,+ so
`it can verify that the user knows the password by comparing the client'-supplied
`digest with the server's own internally computed digest. Another party would
`not easily be able to make up the right digest if it didn't know the password.
`• In Figure 13-ld, the server compares the client-provided digest with the server's
`internally computed digest. If they match, it shows that the client knows the
`password (or made a really lucky guess!). The digest function can be set to gen(cid:173)
`erate so many digits that lucky guesses effectively are impossible. When the
`server verifies the match, the document is served to the client-all without ever
`sending the password over the network.
`
`• There has been significant debate about the relevance of digest authentication, given the popularity and
`widespread adoption of SSL-encrypted HTTP. Time will tell if digest authentication gains the critical mass
`required.
`t There are techniques, such as dictionary attacks, where common passwords are tried first. These cryptanal(cid:173)
`ysis techniques can dramatically ease the process of cracking passwords.
`:j: In fact, the server really needs to know only the digests of the passwords.
`
`The Improvements of Digest Authentication
`
`I 287
`
`

`
`(a} Request
`
`Q---,------------(~~;
`Client
`'&>·
`
`Please give me the internal sales fore~ast.
`
`Server
`
`Client
`Askuser for usern~me and password
`digest(" Ow!")= A3FS
`
`(<) Authorilation Q- _ _ --(JI~".S
`
`Client
`
`(d) Success
`
`\~:.··.' .. ·.· .. ··.· .. ··.
`
`· ~:~~·-····-········-~
`·
`.
`0l
`
`You requested a secret financial document.
`Please tell nie your username and
`password digest.
`
`·I Please give m~ the !nter. nal sales forecast.
`
`My username 1s "bn"
`· My digested password is "A3F5" ·
`·Server
`digeste'Ow!")= A3f5 V
`This is a match!
`OK. The digest you sent me matches the.
`digest of my internal password, so here is
`the document.
`
`Figure 13-1. Using digests for password-obscured authentication
`
`We'll discuss the particular headers used in digest authentication in more detail in
`Table 13-B.
`
`One-Way Digests
`A digest is a "condensation of a body of information."* Digests act as one-way func(cid:173)
`tions, typically converting an infinite number of possible input values into a finite
`range of condensations.t One popular digest function, MD5,:J: converts any arbitrary
`sequence of bytes, of any length, into a 128-bit digest.
`128 bits = 2128, or about 1,000,000,000,000,000,000,000,000,000,000,000,000,000
`possible distinct condensations.
`
`* Merriam-Webster dictionary, .1998.
`t In theory, because we are converting an infinite number of input values into a finite number of output values,
`it is possible to have two distinct inputs map to the same digest. This is called a collision. In practice, the
`number of potential outputs is so large that the chance of a collision in real life is vanishingly small and, for
`the purpose of password matching, unimportant.
`:j: MD5 stands for "Message Digest #5," one in a series of digest algorithms. The Secure Hash Algorithm (SHA)
`is another popular digest function.
`
`288
`
`I Chapter 13: Digest Authentication
`
`

`
`What is import<mt about these digests is that if you don't know the secret password,
`you'll ha~e an awfully hard time guessing the correct digest to send to the server. .
`And likewise, if you have the digest, you'll have an awfully hard time figuring Ol,lt
`which of the effectively infinite number of input values generated it.
`.
`
`The 128 bits of MD5 output often are written as 32 hexadecimal characters, each
`character representing 4 bits. Table 13-1 shows a few examples of MD5 digests of
`sample inputs. Notice how MD5 takes arbitrary inputs and yields a fixed-length
`digest output.
`
`Table 13-1. MDS digest examples
`
`C1A5298F939E87E8F962ASEDFC206918
`
`BEAAAOE34EBDB072F8627C038AB211F8
`
`4 758977 E19EC E E7083 SBC6DF46 F 4F6DE
`
`C617COC7D1D05 F 66 F 59 5 E 2 2A4BO EAAAS
`
`66C4EF58DA7CB956BD04233FBB64EOA4
`
`"bri:Ow!"
`"3.1415926535897"
`"http://www .http-guide.com/index~htm"
`"WE hold these Truths to be self-evident, that all Men are created equal,
`that they are endowed by their Creator with certain unalienable Rights,
`that among these are life, liberty and the Pursuit of Happiness-That to
`secure these Rights, Governments are instituted among Men, deriving their
`just Powers from the Consent of the Governed, that whenever any Form of
`Government becomes destructive of these Ends, it is the Right of the People
`to alter or to abolish it, and to institute new Government, laying its Founda-
`tion on such Principles, and organizing its Powers in such Form, as to them
`shall seem most likely to effect their Safety and Happiness."
`
`Digest functions sometimes are called cryptographic checksums, one-way hash func(cid:173)
`tions, or fingerprint functions.
`
`Using Nonces to Prevent Replays
`One-way digests save us from having to send passwords in the clear. We can just
`send a digest of the password instead, and rest assured that no malicious party can
`easily decode the original password from the digest.
`
`·Unfortunately, obscured passwords alone do not save us from danger, because a bad
`guy can capture the digest and replay it over and over again to the server, even
`though the bad guy doesn't know the password. The digest is just as good as the
`password.
`
`To prevent such replay attacks, the server can pass along to the client a special token
`called a nonce,* which changes frequently (perhaps every millisecond, or for every
`
`• The word nonce means "the present occasion" or "the time being." In a computer-security sense, the nonce
`captures a particular point in time and figures that into the security calculations.
`
`The Improvements of Digest Authentication· I · 289
`
`

`
`authentication). The client appends this nonce token to the password before com:..
`puting the digest.
`
`Mixing the nonce in with the password causes the digest to change each time the
`nonce changes. This prevents replay attacks, because the recorded password digest is
`valid only for a particular nonce value, and without the secret password; the attacker
`cannot compute the correct digest.
`Digest authentication requires the use of nonces, because a trivial replay weakness
`would make un-nonced digest authentication effectively as weak as basic authentica(cid:173)
`tion. Nonces are passed from server to client in the WWW-Authenticate challenge.
`
`The Digest Authentication Handshake
`The HTTP digest authentication protocol is an enhanced version of authentication
`that uses headers similar to those used in basic authentication. Some new options are
`added to the traditional headers, and one new optional header, Authorization-Info, is
`added.
`
`The simplified three-phase handshake of digest authentication is depicted in
`Figure 13-2.
`
`Q
`
`Oient
`
`I
`
`Server
`(1) Server generates nonce
`
`·
`
`(3) Choose algorithm from set
`[generate response digest)
`[generate client-nonce)
`
`-
`
`(7) Client verifies rspauth digest
`
`. 1 tc.ba\\engeL. ... -----·· ·
`unll\li-AUtbe~~~~~:~-----····\····:thmS
`___ !!!.~~-------d-·rea\m,nonce,a gon -
`.-_
`' •·········tl) Ser'<eT sen s
`···• .--
`<\
`t';!f\
`·········---------~uthorizatio 1
`(4J ·a:·····-·----!!.t~~~P.ollseJ
`it~
`telnt sends respon;~d:·---------·-·······• 1M~
`send algorith 1 tgest
`~:%,~
`.
`.
`~~ (S) Server venfies d1_gest
`[send client-nonm ,1
`~it [generate rspauth d1gest] .
`ceJ
`•
`~- [generate next nonce]
`tic.at\on·\~!~~~~~L------········ 1!1
`-~~~~!~--------d···ext nonce
`~-
`•··············· {6) Ser'<~T sen sa~th digest1
`_ - '1!
`tsend c\1ent rsp
`_
`
`Figure 13-2. Digest authentication handshake
`
`Here's what's happening in Figure 13-2:
`
`• In Step 1, the server computes a nonce value. In Step 2, the server sends the
`nonce to the client in a WWW -Authenticate challenge message, along with a list
`of algorithms that the server supports.
`
`290
`
`I Chapter 13: Digest Authentication
`
`

`
`• In Step 3, the client selects an algorithm and computes the digest of the se<,:ret
`password and the other data. In Step 4, it sends the digest back to the server in
`an Authorization message. If the client wants to authenticate the server, it can
`·
`send a client nonce.
`• In Step 5, .the server receives the digest, chosen algorithm, and supporting data
`and computes the same digest that the client did. The server then compares the
`locally generated digest with the network-transmitted digest and validates that
`they match. If the client symmetrically challenged the server with a client nonce,
`a client digest is created. Additionally, the next nonce can be precomputed and
`handed to the client in advance, so the client can preemptively issue the right
`digest the next time.
`
`Many of these pieces of information are optional and have defaults. To clarify things,
`Figure 13-J compares the messages sent for basic authentication (Figure 13.;,3a-d)
`with a simple example of digest authentication (Figure 13-Je-h).
`
`Now let's look a bit more closely at the internal workings of digest authentication.
`
`Digest Calculations
`The heart of digest authentication is the one-way digest of the mix of public informa.,
`tion, secret information, and a time.,.limited nonce value. Let's look riow at how the
`digests are computed. The digest calculations generally are straightforward.· Sample
`source code is provided in Appendix F.
`
`Digest Algorithm Input Data
`Digests are computed from three components:
`
`• A pair of functions consisting of a one-way hash function H(d) and digest
`KD(s,d), where s starids for secret and d stands for data
`• A chunk of data containing security information, including the secret password,
`called Al
`• A chunk of data containing nonsecret attributes of the request message, called A2
`
`The two pieces of data, Al and A2, are processed by H and KD to yield a digest.
`
`The Algorithms H(d) and KD(s,d)
`Digest authentication supports the selection of a variety of digest algorithms. The
`two algorithms suggested in RFC 2617 are MD5 and MD5-sess (where "sess" stands
`for session), and the algorithm defaults to MD5 if no other algorithm is specified.
`
`* However, they are made a little more complicated for beginners by the optional compatibility modes of RFC
`2617 and by the lack of background material in the specifications. We'll try to help ...
`
`Digest Calculations
`
`I 291
`
`

`
`Ciient
`
`· Server
`
`~:::h-0-~;~-;~;~~;;,;~;~:~~;~~;:~:;;;~--;;;:;;;~:-;-------------- -------- ---------~ 1-
`(b) Chalie~/Q ,_
`---------- __ _ ·.;;:;;,~:~- ;;;;-~;:;;;~:;:;:;;;;··--- --·--- •------------1
`Password: ---..
`I
`Q---~~~~-~~~-~~~~~~~~-~:~~-~~~~~~:~;~~~--~~~;~~-:~-----------····································.,.
`(d) Success Q,. ... , ......... c .................. , ....................................................... , •• ;.:.:H=T:::TP.::/=1.:::1.::2=0:::0.::0::;K ~-
`
`Client
`/
`Shoppi Cart
`Username:~';! ·:~;:~~1\f;~'··
`
`WWW-Authenticate: Basic realm="Shopping Cart"
`.
`
`Server
`
`(c) Response
`·.
`
`Client Authonzation: Basic YnJpYW4tdG90dHk6T3ch
`
`.
`
`Server
`
`Client
`
`Client
`
`Client
`f
`Shopping Cart
`• _,. , ... ; :. "
`U
`sername.: .. '' , <.i-
`Password: ) 'i ·
`· '
`
`WWW-Authenticate: Digest
`realw= "Shopping. Cat,t"
`qop= auth, auth -1nt
`nonce="66C4EF58DA7CB956BD04233FBB64EOA4"
`
`Server
`
`Server
`
`::.:f;i -~;~;:~;~;;;;:~;:~~:~~;:;:;::;;;~~;;;~:;••••• muu " " " " " ------~1
`----·-- _ -I.
`(fl Challen:,: --Q-- ___ ____ _ _ __ __ _ _ ~;~;;~:;·-;;;-;·;~:~;;;;;~~;~~--------
`. I.
`---...
`
`(g) Response
`
`Q---~~-;-~~~-~-~~~~;~~-~~~~-~~~~-~~~-~;~~-~--~~~;~~-:~·-················--··············--··········-~ .
`
`Client Authonzation: Digest
`username=''bri"
`realm="Shopping Cart"
`nonce="66C4EFS8DA7CB956BD04233FBB64EoA4"
`uri="/cgi-bin/checkout?cart=17854"
`qop="auth"
`nc=0000001,
`cnonce="CFA9207102EA210EA210FFC1120F6001110D073"
`response="E483C94FOB3CA29109A7BA83D10FE519"
`
`Server
`
`Q ............................................................................................................................ ;
`
`{h) Success
`
`Client
`
`HTTP/1.1 200 OK
`Authorization-Info: nextnonce=
`"29FE72D109C7EF23841AB914FOC3B831"
`qop= "auth"
`rspauth="89FSA4CE6FA932F6C4DA120CEB754290"
`cnonce="CFA9207102EA210EA210FFC1120F6001110D073"
`
`Server
`
`Figure 13-3. Basic versus digest authentication syntax
`
`292
`
`I Chapter 13: Digest Authentication
`
`

`
`If either MD5 or MD5-sess is used; the H ·function computes the MD5 of the. data,.
`and the KD digest function computes the MD5 of the colon~joined secret and nonse.:.
`cret data. In other words: .
`H(<data>) = MDS(<data>)
`KD(<secret>,<data>) = H(concatenate(<secret>:<data>))
`
`The Security-Related Data (A 1)
`The chunk of data called Al is a product of secret and protection information, such
`as the username, password, protection realm, and nonces. Al pertains only to secu(cid:173)
`rity information, not to the underlying message itself. Al is used along with H, KD,
`and A2 to compute digests.
`RFC 2617 defines two ways of computing Al, depending on the algorithm chosen:
`MD5
`One:-way hashes are run for every request; Al is the colon-joined triple of user(cid:173)
`name, realm, and secret password.
`MD5-sess
`The hash function is run only once, on the first WWW -Authenticate hand(cid:173)
`shake; the CPU-intensive hash of username, realm, and secret password is done
`once and prepended to the current nonce and client nonce (cnonce) values.
`
`The definitions ofAl are shown in Table 13-2.
`
`Table 13-2. Definitions for Al by algorithm
`
`MDS
`MDS-sess
`
`Al = <user>:<realm>:<password>
`Al = MDS(<user>:<realm>:<password>):<nonce>:<cnonce>
`
`The Message-Related Data (A2)
`The chunk of data called A2 represents information about the message itself, such as
`the URL, request method, and message entity body. A2 is used to . help protect
`against method, resource, or message tampering. A2 is used along with H, KD, and
`Al to compute digests.
`
`RFC 2617 defines two schemes for A2, depending on the quality of protection (qop)
`chosen:
`
`• The first scheme involves only the HTTP request method and URL. This is used
`when qop="auth", which is the default case.
`• The second scheme adds in the message entity body to provide a degree of mes(cid:173)
`sage integrity checking. This is used when qop="auth-int".
`
`Digest Calculations
`
`I 293
`
`

`
`The definitions of A2 are shown in Table 13-3.
`
`Table 13-3. Definitions for A2 by algorithm (request digests)
`
`undefined
`auth
`auth-int
`
`--------'-~
`
`<request-method>:<uri~directive-value>
`<request-method>:<uri-directive-value>
`<request-method>:<uri-directive-value>:H(<request-entity-body>)
`-
`-------
`
`The request-method is the HTTP request method. The uri-directive-value is the
`request URI from the request line. This may be "*,"an "absoluteURL," or an "abs_
`path,'' but it must agree with the request URI. In particular, it must be an absolute
`URL if the request URI is an absoluteURL.
`
`Overall Digest Algorithm
`RFC 2617 defines two ways of computing digests, given H, KD, Al, and A2:
`
`• The first way is intended to be compatible with the older specification RFC
`2069, used when the qop option is missing. It computes the digest using the
`hash of the secret information and the nonced message data.
`• The second way is the modem, preferred approach-it includes support for nonce
`counting and symmetric authentication. This approach is used whenever qop is
`"auth" or"auth-int". It adds nonce count, qop, and cnonce data to the digest.
`
`The definitions for the resulting digest function are shown in Table 13-4. Notice the
`resulting digests use H, KD, A1, and A2.
`
`Table 13-4. Old and new digest algorithms
`.. 9o~·-~}·'· ·.~·:·'"):~9)9~~tal~prith~;: •:·.·•·.·
`KD(H(Al), <~once>:H(A2)}
`undefined
`KD(H(Al), <honce>:<nc>:<cnonce>:<qop>:H(A2))
`author auth-int
`
`Deprecated
`Preferred
`
`It's a bit easy to get lost in all the layers of derivational encapsulation. This is one of
`the reasons that some readers have difficulty with RFC 2617. To try to make it a bit
`easier, Table 13-5 expands away the H and KD definitions, and leaves digests in
`terms of Al and A2.
`
`Table 13-5. Unfolded digest algorithm cheat sheet
`·· ~nfold~d <~lgorithm .
`MDS(MDS(A1):<nonce>:MDS(A2))
`
`. ·
`
`•
`
`.
`
`.
`
`•"J;
`
`undefined
`
`<undefined>
`MDS
`. MDS-sess
`
`294
`
`I Chapter 13: Digest Authentication
`
`

`
`Table 13~5. Unfolded digest algorithm cheat sheet (continued)
`
`auth
`
`auth-int
`
`<undefined>
`MD5
`MD5-sess
`<undefined>
`MD5
`MD5-sess
`
`MD5(MD5(A1):<nonce>:<no:<cnonce>:<qop>:MDS(A2))
`
`MDS(MDS(Al):<nonce>:<nc>:<cnonc~>:<qbp>:MDS(A2))
`
`·-----------------
`
`Digest· Authentication Session
`The client response to a WWW -Authenticate challenge for a protection space starts
`an authentication session with that protection space (the realm combined with the
`canonical root of the server being accessed defines a "protection space").
`
`The authentication session lasts until the client receives another WWW-Authenti(cid:173)
`cate challenge from any server in the protection space. A client should remember the
`username; password, nonce, nonce count, and opaque values associated with an
`authentication session to use to construct the Authorization header in future
`requests within that protection space.
`
`When the nonce expires, the server can choose to accept the old Authorization
`header information, even though the nonce value included may not be fresh. Alterna(cid:173)
`tively, the server may return a 401 response with a new nonce value, causing the cli(cid:173)
`ent to retry the request; by specifying "stale=true" with this response, the server tells
`the client to retry with the new nonce without prompting for a new username and
`password.
`
`Preemptive Authorization
`In normal authentication, each request requires a request/challenge cycle before the
`transaction can be completed. This is depicted in Figure 13-4a.
`
`This request/challenge cycle can be eliminated if the client knows in advance what
`the next nonce will be, so it can generate the correct Authorization header before the
`server asks for it. If the client can compute the Authorization header before it is
`requested, the client can preemptively issue the Authorization header to the server,
`without first going through a request/challenge. The performance impact is depicted
`in Figure 13-4b.
`Preemptive authorization is trivial (and common) for basic authentication. Browsers
`commonly maintain client-side databases of usernames and passwords. Once a user
`authenticates with a site, the browser commonly sends the correct Authorization
`header for subsequent requests to that URL (see Chapter 12).
`
`Digest Calculations
`
`I 295
`
`

`
`(b) Preemptive authorization
`
`Q
`
`Client
`Server
`·····--.......... ,.~~guest
`..........................
`
`cna\\~1.'.9~---·; .......... .
`· ........... -·················
`......... Request+
`..... .. .... --~Y.~~Q~{~~?!on
`..................... ,
`-r-l\ol\tei~,9.......... Yf~;
`sus~~?? .. -········
`;···
`................... ···<..
`~r~;;
`·······--.H~!lY.~~!:t:~Y.~horizat'
`~E;(~
`
`.
`
`·-----..?¢~=~~: ::-:~
`.................. _
`
`.
`·
`·--...... Request
`..... ·---.'i:!!Y.~~g_rization
`
`i~
`\t~
`
`j~~~~~~---···············r~
`.......... ············
`.:
`.
`
`(a).Normal request/challenge
`
`Q
`
`Client
`Server
`·····--·········---~~guest
`············--.. ,. _____ .,..
`
`(1\a\\~~q~.--············: .
`. >: ···~····················
`.
`·····-. ... 8~quest +
`· ···-----~Y.~ryp_~~~~tion
`~ ......................... ;C::~.
`
`(\\a.\\~1.'.9~-----··--······· -
`..................
`.......... -·······
`. ······· Renuest
`...... .:~. ... +auth · .
`.......... Q~t~tton
`..............
`
`Sut~~-~~---··········--
`..., ........ ··.--···········
`
`Figure 13-4. Preemptive authorization reduces message count
`
`Preemptive authorization is a bit more complicated for digest authentication,
`because of the nonce technology intended to foil replay attacks. Because the server
`generates arbitrary nonces, there isn't always a way for the client to determine what
`Authorization header to send until it receives a challenge.
`
`Digest authentication offers a few means for preemptive authorization while retain(cid:173)
`ing many of the safety features. Here are three potential ways a client can obtain the
`correct nonce without waiting for a new WWW-Authenticate challenge:
`.
`
`• Serverpre-sends the next nonce in the Authentication-Info success header.
`• Server allows the same nonce to be reused for a small window of time.
`• Both the client and server use a synchronized, predictable nonce-generation
`algorithm.
`
`296
`
`I Chapter 13: Digest Authentication
`
`

`
`Next nonce pregeneration .·
`.
`The next nonce value can be provided in advance to the client by the Authentication(cid:173)
`Info success header. This header is sent along with the 200 OK response from a pre-.
`vious successful authentication.
`Authe