"Peter Lister, Cranfield Computer Centre" <[email protected]> writes:
pl> In a nutshell, the problem is the HTTP server saying to the client
pl> "I'm foo, you must provide me with authentication for service
pl> foo". A malevolent server can persuade the client that it is
pl> genuine, and plant false information or obtain secret information
pl> in a query. The (reasonable) assumption of Kerberos is that the
pl> client knows with which prinicpal it must mutually authenticate
pl> *before* making the connection. Since the only information known
pl> beforehand is the URL, we must map the URL to a Kerberos
pl> principal.
re> Wrong.
re> The evil HTTP server says to the client, "I'm foo, you must
re> provide me with authentication for service foo."
re> The client says, "Okay, no problem, here's my session key for
re> talking with service foo, wrapped up with foo's key."
re> The evil HTTP server says to foo, "I'm the client, here's our
re> session key wrapped in your secret key, along with some other
re> data."
You are missing the point, Rob. Reread Peter's last two
sentences. The evil HTTP server is not trying to pose as foo or even
act as an intermediary between the client and foo.
Let's see if this transaction sequence helps to clear things up:
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 [email protected].
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 "[email protected]"
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 "[email protected] along with an encrypted request
for http://bob.foo.com/restricted/file.html.
4) Mallet can decrypt the authenticator and checksum, process Alice's
request and ship back Mallet's version of file.html--which could
very well be an order form containing a field for a credit card
number.
5) Alice mutually authenticates Mallet's reply--which looks valid to
her, since her browser foolishly accepted the identity passed in
the cleartext 401 Unauthorized messsage. Alice fills out the form
and POSTS an encrypted version to Mallet's CGI program.
6) Mallet takes a Carribean cruise, courtesy of Alice's credit card
number.
The problem is that Mallet is able to intercept Alice's initial,
cleartext request and feed back a bad server identity. Unless Alice is
able to know in advance what the server identity should be (possibly
from the URL), Alice has *no* way of knowing whether the server
identity she receives is Bob's or Mallet's.
I'd like to point out (again), that this is not a problem endemic to
Kerberos. It is just as easy for Mallet to step in and present a valid
X.509 certificate causing Alice to use Mallet's public key and not
Bob's. The security protocol is not breached--the browser is given
incorrect identification information.
michael