[OpenAFS-devel] Anyone supporting multiple realms in a "all realms are equal" type of setup?

[Douglas E. Engert]

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/cell@cell.

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  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444