W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1998

Re: Digest mess

From: Scott Lawrence <lawrence@agranat.com>
Date: Tue, 06 Jan 1998 11:42:44 -0500
Message-Id: <199801061642.LAA07904@devnix.agranat.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5076

>> I would like to be able to implement it in a single parsing pass
>> over the message, which is certainly impossible if arbitrary
>> headers may be included by an attribute in a field that may be sent
>> in a trailer.

>>>>> "JF" == John Franks <john@math.nwu.edu> writes:

JF> I see no problem with a single pass.  Remember the actual message
JF> headers are irrelevant for authentication purposes.  Conversely, the
JF> "origin-headers" play no role as HTTP headers, but are used only for
JF> authentication.[...]  A point worth emphasizing is that
JF> the actual HTTP headers never get used in any way in the authentication
JF> process.

  If this is the case then the mechanism has not accomplished

  Attacker sits in the middle and replaces the HTTP headers except the
  authentication headers - client then validates message based on the
  authentication headers (including the encapsulated origin headers
  which have not been touched) and then acts on the HTTP headers as
  thought they were authentic even though they don't match the origin

  If you're going to protect the headers then you have to ensure that
  either the protected value is the only one used, or that they are
  semantically equivalent - the former is a pain because it means you
  need to parse the same headers twice, and the latter gets even more
  sticky when you might not know the semantics of the header at all.

>> Getting back to the original problem - the prevention of the replay
>> of a valid message in response to a different request.  The server
>> can already prevent replay of a past client message by changing the
>> nonce value included in the challenge.

JF> I don't understand this.  Why wouldn't a man-in-the-middle replay
JF> an earlier challenge with a valid, but old, nonce?  In fact the
JF> MIM would have to do this for the replay attack to work.

  It can, but then the client generates a request including a
  client-generated nonce of its own.  The man in the middle can pass
  that on or not, but cannot generate a valid response afterward
  because the upstream server nonce will be different.

  Transaction 1 (attacker is passive):

    Client                     Attacker                     Server
      |                           |                           |
      | request1 >--------------- | ------------------------->|
      |                           |                           |
      |<------------------------- | --------------< challenge |
      |                           |                 (snonce1) |
      |                           |                           |
      | request1 >--------------- | ------------------------->|
      | (snonce1,cnonce1)         |                           |
      |                           |                           |
      |<------------------------- | --------------- response1 |
      |                           |          (snonce1,cnonce1)|
      |                           |                           |

  Transaction 2 (attempted replay)

      |                           |                           |
      | request2 >--------------> |                           |
      |                           |                           |
      |<--------------< challenge |                           |
      |                 (snonce1) |                           |
      |                           |                           |
      | request2 >--------------> |                           |
      | (snonce1,cnonce2)         |                           |
      |                           |                           |
      *<--------------- response1 |                           |
      |          (snonce1,cnonce1)|                           |
      |                           |                           |

  When the replayed response1 using cnonce1 is received, the client
  detects the attack because it does not use cnonce2.  The attacker
  cannot generate a valid response using cnonce2 because it does not
  have the secret authentication information.  Even it it forwards
  the cnonce2 request to the server, it will get back a response using
  a different server nonce so it still cannot authenticate to the

  It is true that this scheme relies on each participant never reusing
  a nonce, but that was already true before and is easy.

Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/
Received on Tuesday, 6 January 1998 08:45:04 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC