RE: Final Review of Digest Authentication

FYI -- here's a summary of the changes from draft 3:

1. In order to allow more general keyed digest functions than MD5, the
algorithm name actually defines two functions -- a keyed digest function
and a hash function. The keyed digest function takes two arguments -- a
secret and some data. This allows keyed digest functions that don't just
concatenate the secret and data and take the hash of it.

Here's the relevant changed text (between the "========"):
========
algorithm

     A string indicating a pair of algorithms used to produce the digest
     and a checksum.  If this not present it is assumed to be "MD5". In
     this document the string obtained by applying the digest algorithm
to
     the data "data" with secret "secret" will be denoted by KD(secret,
     data), and the string obtained by applying the checksum algorithm
to
     the data "data" will be denoted H(data).

     For the "MD5" algorithm 

        H(data) = MD5(data)

     and 

        KD(secret, data) = H(concat(secret, ":", data))

     i.e., the digest is the MD5 of the secret concatenated with a colon
     concatenated with the data.
========
2. The length of the digest or checksum is allowed to be algorithm
dependent; it used to be fixed at 32.

3. The KD function is used in the definition of response-digest and
entity-digest. The relevant changed text:
========
    response-digest     =
          <"> < KD ( H(A1), unquoted nonce-value ":" H(A2) > <">

    entity-digest = <"> KD (H(A1), unquoted nonce-value ":" Method ":" 
                               date ":" entity-info ":" H(entity-body))
<">
           ; format is <"> *LHEX <">
========
4. Some text was added to the security considerations for
"man-in-the-middle" and counterfeit servers, to better explain these
attacks and what browsers might want to do about them. The relevant
changed text in sections 3.3 and 3.4(each section between "========"):

========
3.3 Man in the Middle

  Both Basic and Digest authentication are vulnerable to "man in the
  middle" attacks, for example, from a hostile or compromised proxy.
  Clearly, this would present all the problems of eavesdropping.  But
  it could also offer some additional threats.

  A simple but effective attack would be to replace the Digest challenge
  with a Basic challenge, to spoof the client into revealing their
  password. To protect against this attack, clients should remember if a
  site has used Digest authentication in the past, and warn the user if
  the site stops using it. It might also be a good idea for the browser
  to be configured to demand Digest authentication in general, or from
  specific sites.

  Or, a hostile proxy might spoof the client into making a request the
  attacker wanted rather than one the client wanted.  Of course, this is
  still much harder than a comparable attack against Basic
  Authentication.

  [... rest of section unchanged]
========
3.4 Spoofing by Counterfeit Servers

  Basic Authentication is vulnerable to spoofing by counterfeit
  servers. If a user can be led to believe that she is connecting to a
  host containing information protected by a password she knows, when in
  fact she is connecting to a hostile server, then the hostile server
  can request a password, store it away for later use, and feign an
  error.  This type of attack is more difficult with Digest
  Authentication -- but the client must know to demand that Digest
  authentication be used, perhaps using some of the techniques described
  above to counter "man-in-the-middle" attacks.
========

Note -- this mail corrects an editing oversight in the definition of
"entity-digest" that will soon also be fixed in the URL below.

Paul
>----------
>From: 	John Franks[SMTP:john@math.nwu.edu]
>Sent: 	Monday, June 10, 1996 1:35 PM
>To: 	www-security@ns2.rutgers.edu;
>http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Subject: 	Final Review of Digest Authentication
>
>
>Version 04 of the Digest Authentication is now available at
>
>	http://hopf.math.nwu.edu/draft-ietf-http-digest-aa-04.txt
>
>We are now asking for final review and will request the WTS and HTTP
>working group chairs for "last call" on this draft.  At this 
>point new ideas and substantitive changes are not possible.  Only
>serious technical objections can be considered.
>
>If you have such objections please post to the HTTP working list,
>or the WWW-security list.
>
>John Franks 	Dept of Math. Northwestern University
>		john@math.nwu.edu
>
>
>
>
>

Received on Monday, 10 June 1996 15:01:56 UTC