Re: Authenticated Transactions: Why Wait Another Year?

On Sun, 8 Sep 1996, John C. Mallery wrote:

> My main complaint about digest authentication is that it should
> not just authenticate the user but also authenticate the entire http
> transaction.  The current specification is vulnerable to man in the middle
> attacks.
> 
> This can be fixed by adding the following two items:
> 
> 	1. a digest header on the server responses that hashes the request,
> 	the secret etc with the response code.

I am not sure if you intended this header to include a hash of the
returned entity-body.  If not, it is not clear what the point of
authenticating the URI and headers is if the entity body could have
been changed.

If you meant to include the entity-body in the hash then the header
you want exists in the spec.  It is the Authentication-Info header of
section 2.1.3.  It includes an "entity-digest" as described below.
This header is optional because many valid uses of authentication
don't need it and don't want the overhead of calculating the digest of
every document.

> 
> 	2. digest headers whenever an entity is transfered in this
> 	mode so we know we're really getting the right bits.

This is the function of the "entity-info" part of the entity-digest.
Digesting headers is tricky because caches may change headers, but
the Date, Content-type, Content-length, Content-encoding, Last-mod-date,
and Expiration-date are not supposed to be altered by proxies and
are all included.  

Here is the BNF for the entity-digest from section 2.1.3.  H(A1) is
the shared secret -- a digest of password, username and realm.


    entity-digest = <"> KD (H(A1), unquoted nonce-value ":" Method ":" 
                               date ":" entity-info ":" H(entity-body)) <">
           ; format is <"> *LHEX <">

    date = = rfc1123-date            ; see section 3.3.1 of [2]
    entity-info = H(
              digest-uri-value ":"
              media-type ":"         ; Content-type, see section 3.7 of [2]
              *DIGIT ":"             ; Content length, see 10.12 of [2]
              content-coding ":"     ; Content-encoding, see 3.5 of [2]
              last-modified ":"      ; last modified date, see 10.25 of [2]
              expires                ; expiration date; see 10.19 of [2]
              )

    last-modified   = rfc1123-date  ; see section 3.3.1 of [2]
    expires         = rfc1123-date



John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Tuesday, 10 September 1996 06:15:14 UTC