Date: Mon, 5 Jun 1995 19:34:07 +0001 (MDT)
To: rballard@cnj.digex.net
Message-Id:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
X-Status:
Rex,
Bill Densmore, in summarizing for me his meeting with you, mentioned
that you'd discussed Kerberos as another method of doing secure
transactions. Here is my response to Bill on that issue. Comments?
> This sounds interesting and it reminds me to talk a bit more about the
> meeting with Rex Ballard et al.
Kerberos. OK.
As I understand it, Kerberos requires EVERY PIECE of software in
the system to be modified to support it. I am familiar with the
way they handle service authentications at the Athena project at
MIT, not with any commercial applications, though.
If the industry "at large" adopts Kerberos, Kerberos is superior
to Newshare TVS in that Kerberos is a verifiably secure system.
On the other hand, it needs to be "universal" to be acceptable,
in that everyone has to cooperate on the verified service.
> Rex' argument is that this is in one respect superior to the
> Newshare implementation in that it does not requre the "appending" of
> cookies to URLs during the process of preparing a page in response to an
> httpd request. I can see his point -- there is server time associated
> with finding URLs on a page and adding cookies to them.
Finding URLs in a page is actually very straight-forward as one
can just process the HTML text serially as it goes out to the
network (I mean, the server is reading the text of the file into
a buffer, then writing the text out to the net anyway. We could
tag at this time without much overhead.
In fact, though, only with individual documents of larger than,
say, 200k, with say 100-200 URLs, will the process of tagging
take any noticable time at all.
The point of the URL tagging is that we dont want to "burden" the
client machine or the servers with authenticating every connection.
As you know, with HTML/HTTP the user is selecting lots of pages and
much of the content is very small in terms of bytes. If every one
of those connections needs to be authenticated (say, in the S-HTTPD
or Kerberos way) then we have lots of authentication time. I would
argue that over, say, 5-10 page accesses, TVS will start to "win"
in terms of time required. I may be wrong, and in fact, TVS may
"win" after just one. I am not completely comfortable with the
heavy-weight schemes.
This was one of the reasons to do TVS in the first place - to
provide an "intermediate" scheme that could be used with very
low byte-count content AND have the advantage of passing user
information among servers.
> On the other hand, however, the Kerberos notion requires two
> completely seperate queries/responses and this takes up net bandwidth.
Not really "bandwidth" so much as time. Rex maybe didnt tell you that
in reality Kerberos requires I believe 6 security transactions to
take place before the real transaction can start. This is actually
fine for a long-lived transaction like a login session, or in a place
where an "expensive" resource (like a 600dpi laser printer) are
involved. But, as above, HTML/HTTP is really about very small
transactions - at least in our business. All of the Kerberos
transactions involve either getting tokens or validating them with
encryption techniques. And this, too, takes time.
A TVS-enabled HTTP server makes one TVS transaction (two-way) to
both validate and get user preference information. Show me THAT in
Kerberos!
> So
> what's the difference.
For the application we face -- lots of small-volume, small-cost
transactions over a world-wide network of independent servers --
Kerberos will I think be slowernd, requires lots of Kerberos ticket
handling and lots of Kerberos ticket-generating machines.
Kerberos IS secure, but provides no other value added -- there is
no way, e.g., to collect access information from the universal set
of Kerberos servers (at least that I know of).
I agree that if the industry at large widely adopted Kerberos then
Kerberos could be enhanced to do what TVS will do. This involves
ALL server vendors and ALL client vendors and ALL ISPs to adopt
Kerberos. Any idea how long that will take?
> I like the simplicity of the Newshare system;
precisely. That is why I designed it. I am not "in love" with
writing my own software - after all we had this "hurdle" of my
mission in Berlin. If one of the other schemes was acceptable
then I would have said "do it".
> the
> Kerberos idea seems more appropriate for transactions involving
> significant $$$$ values and fewer transactions.
It is a nice system for a corporate-wide multi-LAN computing
environment specifically (for which it was designed).
The point is (at least to me) that we want something that creates
the lowest impact on the client side of the business. We want
there to be tons of choices for clients and aux software. But,
given the incredibly drawn-out legal wrangling surrounding an
internationally-usable encryption standard, I feel it is just not
in the Internet ethos to ram a quasi-solution down everyone's
throat in the form of RSA/PKP which is expensive, and to my
knowledge NOT international.
dave
+ ----------------------------------------------------------------------- +
| David M. Oliver | UMass/GANG Technical Director | oliver@gang.umass.edu |
+ ----------------------------------------------------------------------- +
| Technische Universitaet Berlin |
| SFB 288, MA 8-5 phone: +49 30 314 25892 |
| Strasse des 17 Juni 136 fax : +49 30 314 21577 |
| 10623 Berlin Germany email: oliver@sfb288.math.tu-berlin.de |
+ ----------------------------------------------------------------------- +
From anne@infoseek.com Mon Jun 5 16:16:28 1995
Received: from infoseek.com (root@corp-uu.infoseek.com [198.5.208.1]) by cnj.digex.net (8.6.12/8.6.12) with ESMTP id QAA18541 for ; Mon, 5 Jun 1995 16:16:26 -0400
Received: from [198.5.209.132] (alan [198.5.209.132]) by infoseek.com (8.6.11/8.6.11) with SMTP id NAA09553 for ; Mon, 5 Jun 1995 13:16:14 -0700
Message-Id: <199506052016.NAA09553@infoseek.com>
X-Sender: anne@corp
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: rballard@cnj.digex.net