Re: more on Digest Auth

I thought your comments about replay were quite valuable and on target: 
I wasn't really grokking all the implications or unencrypted replies 
and snooping.

But your scenario only considers GET.

I was actually thinking about exposing some admin functions on my 
server via POSTs of form-data.  In which case, I definitely DO care 
about replay. And about end-to-end integrity of the form-data.

I just don't see that the suggested changes are very big, and they make 
the protocol much more secure, and perhaps able to be used in 
circumstances beyond what was originally intended -- PUT, DELETE, as 
well as POST.

If this were a really hard set of changes to the draft, I'd give up.  
But they aren't.

Paul
----------
] From: John Franks  <john@math.nwu.edu>
] To: Paul Leach
] Cc:  <http-wg@cuckoo.hpl.hp.com>
] Subject: Re: more on Digest Auth
] Date: Wednesday, February 21, 1996 5:46PM
]
] On Wed, 21 Feb 1996, Paul Leach wrote:
] >
] > If the client doesn't change the nonce each time, there's no replay
] > protection without a challenge each time.  So,  the third part  of the
] > suggestion is to make the last 32 bits of the nonce not be opaque.
] >
] > Does that help?
] >
]
] Yes, now I understand what you are saying.  But I hope you understand
] my point that replay attacks are usually pointless in this protocol.
] If I can get the digest necessary for a replay attack, I can also get
] the document by the same method.  The replay could only get me the
] same document again because the URI is hashed in the digest.
]
] If the documents change frequently so that a later request for the
] same URI would give a new document then timestamps are indicated.
] At least the implementations done by Dave Kristol and the one done
] by me provide for this.
]
]
] John Franks 	Dept of Math. Northwestern University
] 		john@math.nwu.edu
]
]

Received on Wednesday, 21 February 1996 16:23:50 UTC