Jeffrey Altman wrote:
Douglas E. Engert wrote:
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.
I was trying to say that only one AFS service need to be aware of all the 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.
I would not call them arbitray. The mapping is under the control of the AFS admin just as the PTS is under his control.
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.
No I don't. The call can still K5 tickets directly ifno mappings are needed.
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 agree.
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.
gssklog does not.(The original gsiklog from 2001 did.) The first gssklog was from 4/24/2002 does not.
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.
The gssklogd uses "gssklog@<servername>" as input to gss_import_name. servername is one of the AFS database servers. The gssklog uses cm_SearchCellFile() or afsconf_GetCellInfo() to find the names of the servers.
So with K5 the perincipal is gssklog/<servername>@<realmofserver>
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.
It really depends on if there are some conflicts that are not acceptable to the AFS cell. In this case you would not want the K5 realm issuing afs or afs/cell tickets.
The admin could decied for example realm ANL.GOV can issue afs/anl.gov tickets which are acceptable as tokens, but will also accept tokens created by gssklog if the user authenticated to the K5 realm of OUTSIDE.ANL.GOV and these get mapped or rejected.
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.
gssklog comes as close as possible. And since the gssklogd is considered to be part of the AFS cell under the complete control of the AFS admins and runs on the AFS database servers, it currently issues tokens with afs/[EMAIL PROTECTED]
Even today with the AFS KeyFile with its set of des keys with kvnos the gssklog will create a key using one of these keys with its kvno, and the real K5 KDC will use a different key and kvno. (Our mods to krb524d dating back years also would do the same thing, decrypting using the key from the krb5.keytab shared with the KDC and encrypting the token to be returned using DES in a different key which was in the KeyFile.) So the AFS admin controls access via what keys are in the KeyFile.
So the use of the krb524d could actually be enforced if needed.
I believe we can meet what appeas to be your requirements of forcing mapping when needed and allowing no mapping if not needed on a realm by realm bases.
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.
I agree, but maybe the standard is the set of parameters to be used to passed to the "aklog" of the future when it is forked/execd.
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.
I agree.
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.
Part of the problem is that OpenAFS has not distributed the "aklog" programs, but let the Kerberos vendors do it instead, as these programs are tied more closely to Kerberos then to AFS.
What I would like to see is that the aklog of the future use gssapi to get the token. Externally it looks like aklog, internally it looks more like gssklog, with krb524d being replaced with something that functions like gssklogd, doing mappings and returning a K5 format token.
End users should not be aware of such issues.
I agree with that.
At least that is something.
I think we agree on more then you think we do.
( I will comment on you follow up note in a moment.)
Jeffrey Altman
--
Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
