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.
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. 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.
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.
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.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
