I had a colleague look over a proposed Kerberos-based HTTP
authentication protocol I had closely based on the PEM/PGP & RIPEM
exchanges. He pointed out that a man-in-the-middle attack could allow
an evil entity to masquerade as the server since the exchange goes
from cleartext to encrypted.
Alice wishes to access Bob's server.
Mallot is in position to intercept all of Alice's requests.
Alice sends a cleartext request for a restricted file from Bob.
Mallot intercepts the request.
Mallot sends Alice a response containing information for
authenticating to Mallot's server.
You seem to be implying that Mallot's information can cause Alice's
client to attempt authentication by contacting Mallot's (evil)
Kerberos server to get a spoofed ticket for Mallot's server, since
Alice's realm server obviously won't deliver one.
In the case of Kerberos, Alice already knows the address of the
service she wants (Bob's address), and does not need any additional
information except the service (principle) name and the name of the
realm the server is *registered* in (*not*, as is commonly thought,
the realm in which Alice must authenticate). If this realm is
different from her own, Alice asks her *own* realm server for
cross-athentication between her realm and the server's target realm.
If there is a pre-existing agreement between the realms (either in V4
or V5 style), authentication can proceed, otherwise not.
Mallot cannot re-direct Alice's ticket request in any case. If
Mallot's fake Kerberos server does not have *Alice's* secret service
key, it cannot generate a valid ticket that Alice's client can
decrypt.
Unless Mallot has conspired with Alice's realm administrator allow cross-
authentication with his rogue realm, it's not possible for Mallot to
spoof Alice in this way.
Cheers,
--
wa | Wayne Allen, EINet - wa@einet.net
| MCC/ISD, 3500 West Balcones Center Dr, Austin, Tx 78759