Re: Insecure WWW Access Authorization Protocol?

Dave_Raggett <dsr@hplb.hpl.hp.com>
Errors-To: listmaster@www0.cern.ch
Date: Mon, 7 Mar 1994 12:20:35 --100
Message-id: <9403071112.AA28694@manuel.hpl.hp.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: dsr@hplb.hpl.hp.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
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: 2956

Michael Shiplett writes:

> 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.
>    Alice sends a request encrypted for Mallot's server.
>    Mallot decrypts the request..
>    Mallot sends valid mutual authenticator to Alice.
>    Mallot has successfully spoofed Bob's server.

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

A trusted third party is necessary to allow Alice to authenticate Bob
and Bob to authenticate Alice. It still makes sense for Bob and Alice
to send their respective public keys in their messages, but you need
an alternative means of checking that these keys are correct.

RFC1422 describes the certificate-based key management needed for this.
Alice and Bob include in their messages issuer certificates declaring
their public keys, which were sealed by a trusted third party whose public
key is known to both Alice and Bob. Mallot cannot spoof these seals.

This gives Alice confidence in Bob's avowed public key and vice versa.
Alice can now use Bob's public key to check that the response is really
from Bob and not from Mallot. Mallot can't spoof Bob's originator
certificate since Mallot doesn't know Bob's private key. Note that
including both issuer and originator certificates in HTTP requests
and replies avoids the need for out of band messages.

The format for these is defined in RFC1422 and illustrated in RFC1421.
The message body should be sent in binary using the direct output of the
symmetric encryption algorithm, since there is little point in incurring
overheads needed to circumvent the limitations of email routers.

So my advice is to use tried and tested public key management. Export
controls are a minor irritation for software distribution since it forces
US sites to unbundle the security code from the browsers and servers.
Outside the US this is not a problem as all the necessary components are
available as unrestricted freeware from a number of anonymous ftp sites.
There is, I presume, no restriction on *importing* encryption software
into the US?

Dave Raggett