Uh? What's that got to do with it? Most Kerberos communications are in clear
except for the actual encrypted tickets.
> Alice wishes to access Bob's server.
OK, first of all she (alice@SOMEWHERE) gets a ticket for http.bob@SOMEWHERE
> Mallot is in position to intercept all of Alice's requests.
Kerberos assume *everyone* can hear *everything*
> Alice sends a cleartext request for a restricted file from Bob.
Alice can't very well do otherwise without a shared key (Kerberos having no
public-key encyrption). But Alice precedes the request with a ticket that she
has obtained from the Kerberos server.
> Mallot intercepts the request.
Kerberos assumes he (?) will.
> Mallot sends Alice a response containing information for
> authenticating to Mallot's server.
Mallot can try, but it won't do him any good since only Bob could have
decrypted Alice's ticket, and Alice will only accept a reply based on a ticket
that has been decrypted and modified in the correct way - which only Bob can
do.
> Alice sends a request encrypted for Mallot's server.
If Alice has any sense, she waits for Mallot to send a mutual authentication
reply, which could only have come from Bob.
> Mallot decrypts the request..
Mallot can only decrypt things he has keys for. He doesn't know either Alice
or Bob's key, so what the hell can he do? Anyway, by this time Alice has
dropped the connection since she didn't get a correct reply.
> Mallot sends valid mutual authenticator to Alice.
Which she ignores.
> Mallot has successfully spoofed Bob's server.
No he hasn't
> Unless Alice knows how to authenticate to Bob prior to initiating
> the transaction, Mallot will be able to subvert Alice's request. The
> basic flaw is Alice relies on the "401 Unauthorized" response for
> authentication information, e.g., public key, Kerberos principal, etc.
Kerberos does indeed assume that a client obtains a ticket from the Kerberos
server *before* starting the first connection is made. I'm not a real expert
on the internals of either HTTP or Kerberos, but I am a Kerberos site admin,
and have Kerberised an application, and I assure you that for any normal
Kerberos client/server connection, the server really must convince the client
that it holds the service key in question before the client sends anything.
OK, clients *can* be naively trusting if they want, but there's no point, is
there?
> I think this attack would work against any authentication
> protocol following the WWW Access Authorization protocol examples.
But not Kerberos mutual authentication. Would anyone really trust an
authentication system that *didn't* authenticate server to client?
Where are the protocol examples, anyway? I think I need to have a look.
Peter Lister Email: p.lister@cranfield.ac.uk
Computer Centre, Cranfield University Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK Fax: +44 234 750875
--- Go stick your head in a pig. (R) Sirius Cybernetics Corporation ---