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 <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
