luotonen@ptsun00.cern.ch (Ari Luotonen) sez:
> In regards to the proposed "basic" scheme, I certainly wouldn't protect
> important documents that way.
I wouldn't either, if they were that important. However, something
is not quite clear to me. When discussing the protection of documents
it seems that authentication is more important than protecting the
contents of the documents. If someone can listen to the ethernet and
catch my cleartext password and use it to access protected documents,
then what prevents him from catching the cleartext documents flying by
even if I use Kerberos to authenticate myself. Ethernet-listeners just
have to eavesdrop long enough and the chances are they may get the
entire protected documentation this way.
I may have misunderstood something, and please correct me if I'm wrong,
but I think encrypting documents is exactly as important as encrypting
authentication information, and there should be no talk about using
non-cleartext authentication with cleartext server replies. Currently
Yes, you're exactly right. I didn't bring up encryption since my
> Authentication by public key is
There is no more infrastructure needed for using public keys than using,
The server must have the public key of the client in order to
As to authenticating the server to the client, the server itself
Now, about access control. I agree that it's important to have a
For example, HTTP (the protocol) needs to support a variety of
In the EINet scenario, our customers don't have to support the Kerberos
As you point out, some people only need a "little" control, and have to
On the other hand, EINet customers and commercial publishers need
Cheers,
reply was already very long. A Kerberos-authenticated connnection
also has an associated session key which is unique to the connection,
and known only to the two connected (software) parties. This session
key can be used to encrypt the data stream using any fast, symetric
algorithm such
> fine, but the infrastructure necessary for wide-spread use of such
> a system is not yet in place. EINet will eventually support this form
say Kerberos, as long as the servers don't have to authenticate
themselves to the clients. There is only one public key needed, and
that is the server's. It does not have to be distributed in some
special way, it is simply transferred to the client in the server reply.
authenticate the client. The authentication process in this case is
the successful decryption of the clients private-key message with the
client's (ostensible) public key. The infrastructures I refer to are
the publishing and certification mechanisms and (human) organizations
associated with the distribution of the client's public key. This
infrastructure is of comparable order to a Kerberos infrastructure,
and simply has a different
problems you prefer to live with ;-).
cannot provide the server's public key in the message - the public key
must be provided to the client by a trusted third party (certified) in
order to have validity. Server authentication is only really important
when the information a client is retrieving may significantly
influence the client's commercial or financial actions.
simple mechanism that a wide variety of people can use. However, I
think it's important to keep in mind that authentication is a somewhat
separate issue from authorization.
authentication mechanisms, but the authorization process need not
involve the protocol definition at all. Once an identity has been
authenticated, any number of algorithms for authorizing access based
on that identity can be used. These might vary from a simple file with
a list of identities and directories, to an comprehensive access
control server like the one EINet provides to its customers.
infrastructure (we do that for them), but they do have to maintain
their authorization database if they want to protect their data.
support both the authentication database (id/password?) as well as
the authorization database (object/id/rights association). In these
cases, they accept "weak" access control for simplified support.
stronger authentication and protection. They can afford the added
complication and cost. The Web should be able to support this entire
range of users.
--
wa | Wayne Allen, EINet - wa@mcc.com FAX: (512)338-3897
| MCC/ISD, 3500 West Balcones Center Dr, Austin, Tx 78759 (512)338-3754