Authentication of published docs
"Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>
Message-id: <9305250858.AA10944@xdm039>
To: www-talk@nxoc01.cern.ch
Cc: ccprl@xdm001.ccc.cranfield.ac.uk
Subject: Authentication of published docs
In-Reply-To: Your message of "Mon, 24 May 93 19:17:48 BST."
<9305241817.AA13007@xdm001>
Date: Tue, 25 May 93 09:58:54 BST
From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>
> There needs to be a major infrastructure of authenticating and authorizing
> capabilities on the Internet to support "publishing." It is not simply a
> question of client/server (consumer/producer) because the model does not scale.
Well put. At Cranfield we are interested in the first instance in
restricting a small area of our web to privileged local users only;
simple Kerberos 4 will do that fine. In the future, however, we
definitely want electronic subscription to journals etc, which requires
widespread the authentication described. However.....
> The idea here is that Kerberos by itself is not an authentication
> service. It is a mechanism which can be used to develop such a service.
No. What you just described was (effectively) cross-realm
authentication, and the authentication in your example *did* happen via Kerberos!!
ServerB has to contact serverA, and ask it for credentials for aUser.
ServerB can only trust those credentials if the servers trust each
other (or at least B trusts A), so each must hold a key for the other's
TGT service. This requires that their administrators communicate the
keys out-of-band (just like a new user being verbally told their inital password).
It's impractical for every Kerberos server to exchange tickets with
every other, so there needs to be a hierarchy, just like the domain
name scheme (especially since kerberos realms are conventionally
domains name UPPERCASED) - so, if want to authenticate to ORA, I do so
by a multi-hop authentication - cranfield shares keys with a UK auth
server, which shares keys with a US auth server, which shares keys with
ORA. As a detail, the actual servers themselves don't actually talk;
like DNS, each passes a reference and a ticket back to the client,
which then talks to the next server in the chain.
Cross-realm authentication is well understood, and is not limited to
electronic publishing. However, I think the lack of an application
which needs cross-realm authentication has limited it's use and not
justified large-scale organisation. Hopefully, WWW is that app. If they
aren't doing so, I implore ORA not to re-invent this particular Kerberos wheel.
Peter Lister p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology, Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK Fax: +44 234 750875