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

[Douglas E. Engert]

Jeffrey Altman wrote:

> 
>> OK, that would be acceptable.  I would also agrue that the krb524d
>> or gssklogd where principals in a k5 realm where mapped to users
>> in a AFS realm was in effect an extension of the PTS authorization.
>> Maping authentication names to a authorization name.
>

I think there is some gray area here as to how mapping fits in, and
the practicality of carrying forward as much authentication information
as possible for authorization decisions.

> 
> This is where we disagree.  Names are not a authorization entity.
> The entry of a name in a .k5login file is an authorization entity.
> The entry of a name in an acl is an authorization entity.  A name
> itself is not.
> 
> A token is not an authorization entity; it is an authentication
> entity. As such the authenticated name should not be altered until
> such time as it is presented to the authorization database.

OK, but being pratical, AFS in the past has not had the ability to
handle additional authentication information. If it could then the
additional information should be pushed down to allow for more
informed authorization desisions. AFS ACLs have been limited to
mapping by the PTS to a single number. DCE tried to address this
by having a UUID for the user, and a UUID for the realm, thus
you could add these two numbers to an ACL. (I am not saying that
this is a good idea, but that they tried to address the issue
of giving the authz more information.)


> Otherwise, you give up the ability to audit and distinguish between
> two different trust paths.  The path running though gssklogd via
> FOO.COM and BAR.COM are different paths.  The path which runs through
> krb524d is a different one.  The path which uses straight klog is
> an additional one.

I agree, these are alternate security paths. and they all mapped into
issuing a V4 token with as much information as AFS could handle.
Now that AFS can handle a krb5 ticket, what will it take for the
PTS to be better at handling the additional information, in the
ticket? But then again, how much does it cost to check and when is it
checked?

Would AFS be better off to actually issue a token itself after having
done much of the authorization mapping once, rather then use a k5 ticket
as the token?

The gssklog was originaly written to allow the use of x509 certificates
for authenticaiton to AFS. As such it tried to store as much
information as possible from the certificate chain as possible
into the the V4 token. (i.e. almost nothing only a name.) It was being
pratical about this.

Also note the the gssklogd was run by the AFS admins, so it could be
considered authz functions of mapping an authnetication to a authz name
to be used for authorization, preserving as much infor as possible.
This is is exactly what the kaserver did when it was part of the cell.

The gssklog or krb524d if run by the AFS admins serves this purpose.
They in effect can be part of the authorization process. You authenticate
to them and get a token.

> 
> This very much parallels the discussions related to PKINIT.  We
> are converting an authentication entity from one format to another.
> It is very important for there to be a well-defined mapping and
> for the trust path to be validated by the authorization service.

And this is exactly what we are talking about here. How to use
some authentication method and preserve as far as possible the
information so it can be used for authorization. How much of this
information is AFS willing to use. Will it check the transited field,
or trust its KDC when it set TRANSITED-POLICY-CHECKED. If the
authentication was done by PKINIT, will AFS look at the
certificate chains, or trust the KDC to have done this already.

> 
> The only thing which can be preserved in the k4 style token is the
> name.  There is no other path information we can use to determine
> whether or not that name is trustworthy.  Therefore, distinctions
> between different authentication identities should be preserved
> up until the time the authorization database needs to make a
> decision on what access to grant.

I agree. Just how much information will the PTS or AFS ACLs
be able to use?

> 
> Jeffrey Altman
> 

-- 

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