[OpenAFS] Poll: how many organizations are performing principal name mappings via krb524d, gssklogd, etc?

[Douglas E. Engert]

Jeffrey Altman wrote:

> Folks, I would like to try to get some idea of just how many
> organizations are using a translation service to map a Kerberos 5
> ticket from one realm to a Kerberos 4 ticket in another realm
> for the purposes of providing access to a local cell.
> 
> For example, yesterday it we determined that Kerberos 5 principals
> within the realm NCSA.EDU are mapped via krb524d to Kerberos 4
> principals within the realm NCSA.UIUC.EDU in order for AFS to
> recognize the local user since the cell name is ncsa.uiuc.edu.
> 
>   u@NCSA.EDU (k5) -> u@NCSA.UIUC.EDU (k4) -> u@ncsa.uiuc.edu (afs)
> 
> The core problem with this approach is that it makes access to
> the AFS cell by end users dependent upon the translation service.
> The direction that OpenAFS is taking is to move to a pure Kerberos
> 5 environment. 

So we are back to the discussion of what is a cell vs what is a realm.
I contend that the cell is an authoritative domain, and the mapping
service is the authentication entry into the cell.


> We want to use Kerberos 5 tickets as AFS (2b) tokens
> for many reasons:
> 
>   * Kerberos 4 is cryptographically weak
>   * Kerberos 4 cross-realm is a security hole
>   * Single DES keys can no longer be trusted to protect data
>   * The port used by the krb524 service is frequently blocked by
>     firewalls and ISPs because it was once used by a worm that
>     attacks Microsoft Windows
> 

I agree with all of the above. A token can be a K5 ticket, but
it could be that the token is created by the mapping service for use
in the cell. The krb524d or other mapping service of the cell,
like gssklog, could return 2b tokens. Any new translation service
based on krb524d should be considered a service of the cell, and not
of the realm, and could use RX just like any other AFS service.


> However, without the translation service, AFS will see the user as:
> 
>   u@NCSA.EDU (k5) -> u@ncsa.edu (afs)
> 
> and this name will not appear as part of any of the ACLs for the
> AFS volumes.  As a result, end users cannot gain access to their
> data when 2b tokens are used.
> 
> I want to get an idea of how wide spread this problem is.  OpenAFS
> 1.4 is going to support Kerberos 5 crypto based encryption for
> protecting AFS data exchanges.  Once this is released the
> justification for maintaining support for cryptographically
> insecure operations is going to rapidly disappear and organizations
> are going to be faced with a very hard choice.
> 

So what is the transition plan?

Will 1.4 not have a kaserver as it is only K4?

What about clients vs servers, will older clients not work
with 1.4 servers?

> In the meantime, organizations which are dependent on these
> translation services are going to have to document this dependency
> very clearly as part of their local instructions for configuring
> OpenAFS clients.  Otherwise, the number of support calls is
> going to rapidly increase.
> 
> If your organization is dependent on a translation service, please
> drop me an e-mail so that I can keep a private list.  Please indicate
> as part of your e-mail whether or not you would be willing to have
> this information made part of a public list in the Wiki.
> 

Actually we will not be dependent on a mapping service, as the
cell name is anl.gov and all our users are in the Windows AD domain
of ANL.GOV.


> Thanks.
> 
> Jeffrey Altman
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444