Re: Insecure WWW Access Authorization Protocol?

Rob Earhart <earhart+@CMU.EDU>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 8 Mar 1994 23:49:46 --100
Message-id: <shTDy6a00WC7NC6fdy@andrew.cmu.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: earhart+@CMU.EDU
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Rob Earhart <earhart+@CMU.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: 2161

michael shiplett <michael.shiplett@umich.edu> writes:
>   With the current HTTP Access Authentication this is what happens
> when Alice attempts to retrieve a given URL, let's say:
>                http://bob.foo.com/restricted/file.html.
>   Let's also assume that to authenticate to Bob's server, one must
> authenticate to the service http.bob.foo.com@FOO.COM.
> 
>  1) Alice sends a cleartext request to Bob for /restricted/file.html.
> 
>  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.
> 
>  3) Alice, who has a naive, trusting browser which doesn't attempt to
>     do any matching between a URL and the alleged server
>     authentication identity, goes ahead and sends the authenticator
>     for "http.mallet.evil.com@EVIL.COM along with an encrypted request
>     for http://bob.foo.com/restricted/file.html.

  Heh.  Don't exchange realm keys with EVIL.COM unless you trust them
to not do such things. :-)

  Okay... and as long as we're assuming that Alice's browser is dumb
enough to not tell Alice who it's authenticating to, let's also not have
it tell Alice the URL (after all, URL's are nasty protocol things that
should be kept away from the user, right?).

  Then Mallet intercepts the request, and sends to Alice:
	301 Moved
	URI: http://mallet.evil.com:/restricted/file.html

  So Alice's oh-so-helpful browser jumps over there, and Mallet sends back:
	401 Unauthorized
	Authenticate: KerberosV4 "http.mallet.evil.com@EVIL.COM"

  At which point, it doesn't matter whether or not you're doing URL
checking; you still lose.

  Before sending a document that requires security to a server, the
client needs to tell the user what form of authentication it's using,
and whom it's authenticating itself to.  If you really feel the need to
show the user the URL, and do URL checking, fine; I'd rather just give
the user the information directly, and allow the server to use any name
it wants for authentication.

  )Rob