Re: Insecure WWW Access Authorization Protocol?

• Mail folder: WWW Talk Jan 94-present
• Next message: Roy T. Fielding: "Conditional GET Proposal for HTTP Caching"
• Previous message: Daniel W. Connolly: "Comments on HTTP spec"
• Maybe in reply to: Tony Sanders: "Re: Insecure WWW Access Authorization Protocol? "
• Reply: michael shiplett: "Re: Insecure WWW Access Authorization Protocol? "

Errors-To: listmaster@www0.cern.ch
Date: Wed, 9 Mar 1994 21:56:48 --100
Message-id: <199403092053.PAB01199@totalrecall.rs.itd.umich.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: michael.shiplett@umich.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: michael shiplett <michael.shiplett@umich.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Insecure WWW Access Authorization Protocol? 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1448

"ts" == Tony Sanders <sanders@BSDI.COM> writes:

ts> michael shiplett <michael.shiplett@umich.edu> writes:
>> 2) Mallet intercepts the request and sends to Alice:
>> 401 Unauthorized
>> Authenticate: KerberosV4 "http.mallet.evil.com@EVIL.COM"
>> This is the critical step, because Mallet is able to control to
>> which service Alice should authenticate herself.

ts> Would someone please explain to me why a user would enter a
ts> password at a prompt that read: "http.mallet.evil.com@EVIL.COM"
ts> (or anything thing else they didn't recoginze?
  Because it is not given that the user enters a password or actively
participates in the authentication sequence. For example, with
Kerberos, as long as the user has valid ticket-granting ticket,
Kerberos will handle getting the information needed to authenticate to
the http server--without requiring the user to actively provide *any*
information. With public key cryptography when the private key is
encrypted with a symmetric algorithm, many programs allow the user to
enter the private key password once per session instead of asking for
it each and every time the private key is needed.

ts> Wouldn't they have to have a password for that realm and don't you
ts> think they might think "gee, I don't have a password for that
ts> realm".
  The evil server could just as easily be in the user's realm. It is
not obvious nor necessary that the user is directly involved in
authenticating.

michael