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