Message-Id: <9404261508.AA06010@ulua.hal.com>
To: pays@faugeres.inria.fr
Subject: Need for Authentication [Re: Time to split?]
In-Reply-To: Your message of "26 Apr 1994 09:02:19 +0200."
<767343739.25354.0-faugeres.inria.fr*@MHS>
Date: Tue, 26 Apr 1994 10:08:51 -0500
From: "Daniel W. Connolly" <connolly@hal.com>
In message <767343739.25354.0-faugeres.inria.fr*@MHS>, pays@faugeres.inria.fr w
rites:
>
>Given the current state of the (non?)progress in this group,
>given the conflicting requirements expressed, my question is:
>
>Is it not time that we have roughly two broad sets
>of requirements and contributers groups
> . the one related with traditional publishers and librarians
> . the other (much more modest) just willing to have
> some form of Directory Names for Documents on the Network
>
...
>
>What about this proposal?
>
It's a good observation (that we've got two distinct camps), but I
disagree with the conclusion (that they shouldn't keep discussing the
issues).
I'd suggest that in stead it is time for making some attempts to
deploy technology. I think the MD5-in-archie mechanism is long overdue
(though let's not discount the "birthday problem" -- md5 is a good way
to tell if a given file has changed, but it's not sufficient to
uniquely identify all the files out there)
On the other hand, we can't get too quick-and-dirty. We're dealing
with information here -- the gold of the '90s.
All this stuff about which servers are "authoritative" vs. "default",
and editorial bias, forgery, misinformation, libel -- it all comes
down to the fact that authentication is an essential feature.
The way I look at it, the essential feature in the Integration of
Internet Information Resources is reliable links. The old way to look
at lots of data is to have it on the local machine; distribution meant
copying it from machine to machine. The new way is to store parts of
the info all over the place, and use "pointers" or "links" -- in
general, references from one piece of info to another.
In general, you start with a piece of information from a trusted
source -- say a file you own on your local machine. You want to be
able to resolve references from that information and DETECT FAULTS
(including network partitions, incorrect answers, forgery, etc.) in
doing so.
In order to detect faults, we must (1) decide what the correct
behaviour is, and (2) implement a spectrum of redundancy and fault
detection/tolerance mechanisms -- everything from a noop "I believe
everything I'm told" to simple bytecounts to MD5 signatures to PGP
signatures to kerberos to DES encryption of all packets... so that
folks can (1) protect their information, and (2) express hi-integrity
references. References like:
"The FTP file /dir1/dir2/file on host.com at 1994-04-26-09-52-00GMT,
which was last modified 1994-04-02-07-30-00GMT,
and which has a bytecount of 32452
and which has an md5 signature of '2342lkjl34kj2l3kj4l2k3j4'
and which was PGP-signed by <author@host.com>,
and which was given the Message-ID <lkjsdlkj.12.34@host.com> by
<author@host.com> on 'Fri, Dec 22, 1993 10:34 PM GMT'"
allow the client to (1) detect a version and/or size mismatch before
trasferring the data (2) detect forgery/corruption between the time
the reference was made and the time of transmission (3) detect
forgery/corruption between the time the indicated principal last
signed the data and the time of transmission. The client can even do
things like "sorry, this file has changed since the reference was
made... retrieve it anyway?" and then the client can check the
integrity of the new version by checking its PGP signature.
Such references should also allow the client (or any proxy servers
along the way...) to locate a more convenient copy of the referenced
entity, and/or cache the entity for later use.
Note that some of these techniques (pgp-signature) even work on
references like "get whatever version of ftp:/host.com/dir/file is
current when you're reading this" -- the reference can include "... ,
which will be signed by owner@host.com."
About URN namspace authority.. all these techniques involving
centralized control over any information are silly, if you ask me. The
IP protocol is not secure. It's perfectly possible to forge servers.
The way to ensure data integrity is through authentication, not
centralized access.
We need to be able to express things like "web-master@host.com
certifies that ftp://host.com/gatekeeper mirrors
ftp://gatekeeper.dec.com with a lag-time <= 7 days." in
machine-processable terms. Kerberos, TAOS, and other implemetations
demonstrate that it is possible to send such certificates around the
network without loss of integrity.
Daniel W. Connolly "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010
<connolly@hal.com> http://www.hal.com/%7Econnolly/index.html