Re: Insecure WWW Access Authorization Protocol?

"Peter Lister, Cranfield Computer Centre" <P.Lister@cranfield.ac.uk>
Errors-To: listmaster@www0.cern.ch
Date: Mon, 7 Mar 1994 12:29:35 --100
Message-id: <9403071124.AA02501@xdm039.ccc.cranfield.ac.uk>
Errors-To: listmaster@www0.cern.ch
Reply-To: P.Lister@cranfield.ac.uk
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Peter Lister, Cranfield Computer Centre" <P.Lister@cranfield.ac.uk>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Insecure WWW Access Authorization Protocol?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 3360

>   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.

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 ---