Insecure WWW Access Authorization Protocol?Date: Sun, 6 Mar 1994 17:15:34 --100

wa@mcc.com (Wayne Allen)
Errors-To: listmaster@www0.cern.ch
Date: Mon, 7 Mar 1994 18:55:00 --100
Message-id: <9403071648.AA29773@coyote.mcc.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: wa@mcc.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: wa@mcc.com (Wayne Allen)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Insecure WWW Access Authorization Protocol?Date: Sun, 6 Mar 1994 17:15:34 --100
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2246


   Reply-To: michael.shiplett@umich.edu
   Originator: www-talk@info.cern.ch
   Sender: www-talk@www0.cern.ch
   Precedence: bulk
   From: michael shiplett <michael.shiplett@umich.edu>
   X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
   Content-Length: 1212

     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