Access Authorization

Wayne Allen (
Wed, 15 Sep 93 14:55:49 CDT

Hi, Ari. (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
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 the data in a fashion proportial to the authentication of the receiver.

> Authentication by public key is
> fine, but the infrastructure necessary for wide-spread use of such
> a system is not yet in place. EINet will eventually support this form

There is no more infrastructure needed for using public keys than using,
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.

The server must have the public key of the client in order to
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 Kerberos. I suppose a choice is best made based on which set of
problems you prefer to live with ;-).

As to authenticating the server to the client, the server itself
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.

Now, about access control. I agree that it's important to have a
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.

For example, HTTP (the protocol) needs to support a variety of
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.

In the EINet scenario, our customers don't have to support the Kerberos
infrastructure (we do that for them), but they do have to maintain
their authorization database if they want to protect their data.

As you point out, some people only need a "little" control, and have to
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.

On the other hand, EINet customers and commercial publishers need
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 -		 	 FAX: (512)338-3897
    | MCC/ISD, 3500 West Balcones Center Dr, Austin, Tx 78759 (512)338-3754