- From: Scott Lawrence <lawrence@agranat.com>
- Date: Tue, 06 Jan 1998 11:42:44 -0500
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>> 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
anything.
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
headers?
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
client.
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