Re: Insecure WWW Access Authorization Protocol?

robm@ncsa.uiuc.edu (Rob McCool)
Errors-To: listmaster@www0.cern.ch
Date: Wed, 16 Mar 1994 02:18:01 --100
Message-id: <9403160113.AA05399@void.ncsa.uiuc.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: robm@ncsa.uiuc.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: robm@ncsa.uiuc.edu (Rob McCool)
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
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
Content-Length: 1431

/*
 * Insecure WWW Access Authorization Protocol?  by michael shiplett
 *    written on Mar  6,  5:16pm.
 *
 *   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.
 *
 *   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.

 *   I think this attack would work against any authentication
 * protocol following the WWW Access Authorization protocol examples.
 */

Yes, which is why we are changing Mosaic's behavior for PGP/PEM and, in the
future, Kerberos, to not send the request unencrypted first, but to get the
authentication information from the user and allow the user to force Mosaic
to send the request encrypted the first time. 

There are more problems for privacy using 401 than the one you're focusing
on. Namely, if a form has a credit card number in it that you don't want
going out in plaintext, it will go out in plaintext anyway the first time
the browser sends the request.

--Rob

obvious problems for privacy in this model