authentication vs authorization was Re: [OpenAFS] 1.3.70 and aklog

[Douglas E. Engert]

Jeffrey Altman wrote:

> Certainly there is much left to do to make effective use of
> 2b tokens in AFS.  The Kerberos 5 ticket format allows us to
> provide the authorization server (pts) much more information
> then was available with earlier token formats.
> 
> jhutz commented on Zephyr:
> 
>    "But I'd rather have a separate RPC for the fileserver to use for
>    mapping authentication names (probably with an auth mech type) to a
>    vice ID, and leave PR_NameToID for the task of mapping AFS
>    authorization names to vice ID's, since _that_ should remain
>    one-to-one
> 
>    "In my model, the mappings would be contained in the PRDB, though it
>    would also seem reasonable to give the ptserver configuration that
>    makes the mapping apply to an entire realm"
> 
> There is active discussion in this area.  There is clearly a lot more
> work that needs to be done before we can commit to a particular model.
> 

good.

> ----
> 
> In many ways gssklogd provides a gateway service to the AFS cell.
> As such you consider the issuance of an AFS token as an authorization
> operation.  By doing so the assumption is made that all tokens 
> regardless of how they are issued are going to go through an equivalent
> gateway service.

Yes. This can be enforced by the cell, if only the cell servers and gateways
hold the key used to encrypt the token. The current krb524d does not do
this, as it expects to use the same key to decrypt the K5 ticket as is used
to encrypt afs token.  It is really a service of the KDC.

But if the keys used for the k5 ticket is not the same as used for the token,
then the krb524d could be considered a gateway service as you could not
bypass it. We added this feature to krb524d 10 years ago. All though we
were not trying to enforce going through a gateway, just make it easier to
change keys independent of each other.

> 
> The use of Kerberos 5 tickets as tokens breaks this model.  In order to
> preserve the gateway model with 2b tokens you would need to hack the KDC
> to issue tickets with an alternate client principal name when a ticket
> for an AFS service ticket is issued. 

Not sure what you mean here.

> This is the primary reason I 
> dislike model.  By performing the mapping outside of the PTS it opens
> the door for the gateway to be bypassed by a new authentication 
> mechanism (perhaps an X.509 cert as a token) and a disruption of the
> end user experience.

Think if the mapping service as part of the PTS in general, where part
of the mapping i.e. authentication mapping to cell user is placed in
the token, along with session keys, etc. and sent to the user.

Group mappings can be done as they are now. Microsoft tried to do it
all in the ticket with the PAC. DCE tried to use the PTGT which could be
renewed on a short time frame. I don't like either as they assume
the authentication service is also the mapping service for
authorization.

The new authentication mechanism could only bypass the PTS if it can
encrypt the token with a key acceptable to the AFS servers.
Thus it would have to be added by the AFS admins.

> 
> I am not sure that most organizations which are deploying gssklogd 
> understand the distinctions between the authentication and authorization 
> models.  Without that understanding, surprises should be expected.
> 

I think they do. They know that the the gssklogd is a service run by
the cell admins to allow for alternate authentication, such as the
Globus GSI.

Even with Kerberos it might give them more control, as they could
still only allow the cell admins to come in via the kaserver, yet
allow users to use a Kerberos realm run by some larger organization.
The Kerberos realm admins could not impersonate the cell admins.
But this is similiar to good cross realm support in AFS to do the
same thing, i.e. a realm for the cell, and users in other realms.


> Jeffrey Altman
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444