Re: Insecure WWW Access Authorization Protocol?

Rob Earhart <earhart+@CMU.EDU>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 8 Mar 1994 22:30:31 --100
Message-id: <ohTCowm00WC7JC6ds8@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: 2185

"Peter Lister, Cranfield Computer Centre" <P.Lister@cranfield.ac.uk> writes:
> In a nutshell, the problem is the HTTP server saying to the client "I'm foo, 
> you must provide me with authentication for service foo". A malevolent server 
> can persuade the client that it is genuine, and plant false information or 
> obtain secret information in a query. The (reasonable) assumption of Kerberos 
> is that the client knows with which prinicpal it must mutually authenticate 
> *before* making the connection. Since the only information known beforehand is 
> the URL, we must map the URL to a Kerberos principal. 

  Wrong.

  The evil HTTP server says to the client, "I'm foo, you must provide me
with authentication for service foo."

  The client says, "Okay, no problem, here's my session key for talking
with service foo, wrapped up with foo's key."

  The evil HTTP server says to foo, "I'm the client, here's our session
key wrapped in your secret key, along with some other data."

  Foo says, "The IP address in that packet you just sent me isn't the
IP address that it came from; I don't believe you.  EOF"

  And even in environments that don't check IP addresses... Foo says,
"Okay, just to make sure you are who you say you are, wrap the md5 key
of every request with that session key that you think you know."

  (And if foo doesn't do mutual authentication, foo is being very very
insecure; this isn't a problem that HTTP can do anything about).

  At this point, the evil HTTP server is at a loss, because it never
actually had the session key, just the ticket containing the session key
wrapped with foo's secret key.  It looses.  Yes, it can monitor
unencrypted information; this is why you encrypt sensitive data.  It can
replay requests, but this doesn't give it any more information than it
originally saw passing over the wire.

  The evil HTTP server is nothing more or less than a network
sniffer, sitting between the client and foo.  Kerberos is already
designed to defeat this.  It doesn't matter that it's the server telling
you who to authenticate to; if it doesn't have the secret key of the
service it's asking for, it can't do anything with it.

  )Rob