Re: Insecure WWW Access Authorization Protocol?
michael shiplett <michael.shiplett@umich.edu>
Errors-To: listmaster@www0.cern.ch
Date: Mon, 7 Mar 1994 15:22:37 --100
Message-id: <199403071417.JAB19518@totalrecall.rs.itd.umich.edu>
Errors-To: listmaster@www0.cern.ch
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>
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: 3464
"pl" == Peter Lister, Cranfield Computer Centre <P.Lister@cranfield.ac.uk> 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.
pl> Uh? What's that got to do with it? Most Kerberos communications
pl> are in clear except for the actual encrypted tickets.
Most but not all--e.g., kerberized telnet with the encryption
``on.'' I intend to use Kerberos in order to provide mutual
authentication and to use the session key to encrypt things like a
form submittal or a document request.
>> Alice wishes to access Bob's server.
pl> OK, first of all she (alice@SOMEWHERE) gets a ticket for
pl> http.bob@SOMEWHERE
This is the crux of the problem--How does Alice know for what
principal to get a ticket before initiating a transaction with Bob?
Following the WWW Access Authorization protocol, all of the initial
exchange--***including the server's identity***--is in cleartext. If
Alice knows what ticket she needs a priori, then Kerberos and other
authentication methods become trivial.
The problem is how to convey the information needed for
authentication. Using a Kerberos environment as an example, if I want
to initiate a kerberized telnet session to the machine cyber.foo.com,
the ktelnet protocol says to get a ticket for 'rcmd.cyber@FOO.COM'
(I'm not sure about the realm, but the name & instance are
correct). Anyway, the point is that the protocol specifies the
``server'' identity. In HTTP, it is the server itself which gives this
information.
After speaking with another colleague, we came up with a method of
identifying the server based on the URL. In the following, Alice is
the client, attempting to get http://bob.foo.com/docs/protected.html.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Client:
GET /docs/protected.html HTTP/1.0
UserAgent: Mosaic/X 2.2
Server:
HTTP/1.0 401 Unauthorized
WWW-Authenticate: KerberosV4 principal=``name.instance@realm''
Server: NCSA/1.1
Client:
GET / HTTP/1.0
Authorized: KerberosV4
ticket=``uuencoded authenticator and ticket''
[NOTE: Alice ignores any non-protocol ``WWW-Authenticate''
information. In this case, she gets a ticket for & creates an
authenticator for k4-http.bob_foo_com@FOO.COM.]
<the real request, encrypted with session key>
Server:
HTTP/1.0 200 OK
WWW-Authentication: KerberosV4
ticket=``uuencoded mutual authenticator response''
<the reply, encrypted with session key>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I'm not familiar enough with HTTP to know what information the
browser is ``allowed'' to get from the URL, but the browser needs to
get the authentication identity from someplace other than the
server. The advantage of using the URL is that it is already there and
should contain all the necessary authencation identity information.
Use of the URL means that the client, of course, needs to get the
URL from a trusted source (widely available documentation, an HTML
document acquired through a secure channel, etc.).
Also, the server needs to keep around replay detection information.
pl> Where are the protocol examples, anyway? I think I need to have a
pl> look.
http://info.cern.ch/hypertext/WWW/AccessAuthorization/ProtocolExamples.html
michael