Douglas E. Engert wrote:
But the need for gssklog came from AFS cells that had kaserver but not krb5 and wanted to use the Globus GSI, and where not willing to setup a krb5 cell. So I don't think you as the developer can force AFS to only work with one. You can internally with the token, but AFS may want to keep its options open to support multiple methods of obtaining a token.
I as a developer certainly can determine what mechanisms I support in the tools that I develop. Currently, the OpenAFS for Windows client only supports Kerberos 5 OR Kerberos 4. One of the primary reasons is due to the lack of resources to build a user interface capable of managing in a reasonable way all of the choices the user would have to make for each and every cell.
If organizations want this to change, I strongly urge them to make donations. I estimate the work on the new UI to take about four months.
AFS needs to work with what ever authentication method is available. It might be the default is no mapping service i.e. use k5 tickets directly with a single or multiple realms, or one that supports only K5 via gssapi, or other gssapi mechenisums.
I completely agree with the statement "AFS needs to work with whatever authentication method is available". However, our interpretation of this statement is very different. For me, this statement means that the AFS servers need to be aware of all the authentication IDs which might be presented by clients using available authentication methods.
There is a distinction between the justification you provided above for the creation of gssklogd and the mapping service you implemented within it for Kerberos 5 principals. I believe that gssklogd is a perfectly fine service for organizations that do not want to use Kerberos 5. However, once they are committed to deploying Kerberos 5 the gssklogd cannot be used to perform arbitrary principal mappings. Doing so results in the situation that many organizations who performed similar mappings in krb524d are facing.
You make it impossible for a Kerberos 5 ticket to be used directly as a token even though the KDC is more then willing to issue it. In my view, if the KDC is going to issue an "afs" or "afs/cell" service ticket, then that ticket must be usable as a token without modification by some arbitrary service.
I am not saying that you cannot use gssklogd. But if you do it should not work by requesting "afs" or "afs/cell" service tickets. Come up with some other service name and use that. By doing so you make it clear that those service tickets are not useful without the intermediate service.
If you want to push the mapping into gssklogd in which authentication is performed using GSS-Kerberos 5, then the KDC had better not issue "afs" or "afs/cell" tickets directly to clients.
Even if AFS does not provide a maping service, it can still be done as this is what the gssklog did.
In order to support all of the different authentcation mechanisms in a general way, the ptserver is going to have to provide extensions allowing a mapping of names to IDs. This does not prevent you from doing the mapping somewhere else provided that you appropriately differentiate it from the Kerberos 5 "afs" service name.
Also note the multiple akog, afslogin, PAM routines and code built into daemons today to get tokens. How would you simplify this?
This code is absolutely gross. The only way to simplify it is to develop a new standard for authenticating to cells and eventually abandoning the old code.
MIT Kerberos is going to abandon Kerberos 4. OpenAFS will have to do so as well. At some point we simply have to say that we only support Kerberos 5 or XXX and that all of the old hacks will no longer work. This is not going to happen in the next year, but it should happen within five years.
Unfortunately, which PAM you use or which mods you make to OpenSSH
are highly dependent on the infrastructure of the cell you are
attempting to authenticate to. Hence, end users or system administrators must have access to knowledge and expertise they
should not be required to know.
End users should not be aware of such issues.
I agree with that.
At least that is something.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
