[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:
> 
>> Its not a question of "lying"  That implies that that there is some
>> some question of the trust relationship between the fileserver and the 
>> mapping
>> server. All the mapping that has been done so far are under the 
>> control of the
>> AFS cell admins, and is part of AFS. Maybe not from the AFS 
>> developer's point
>> of view, but it is from the administrator's and user's view. For a trust
>> relationship its not a third party.
> 
> 
> There is a difference in the points of view here.  Doug, in your 
> deployment you place the gssklogd within the trust zone of the AFS servers.
> 
> When I and jhutz look at this, we do not because we do not trust that 
> the people deploying this solution understand the consequences. Evidence 
> has shown that the people who are deploying things such as
> gssklogd and krb524ds which perform mapping do not understand this.
> 

Good point, but it is just one of many complexity issues the admins have
to deal with. Hopefully your new methods will simplify things.


> There has not be a clear understanding (at least with krb524d mapping)
> that the "afs" service name must be reserved for tickets which are used
> without mapping.
> 
> The lying occurs when the user thinks she is authenticating as 
> "user@FOO" but the server thinks she is authenticated as "user@BAR".
> In this situation, the server is being lied to.  It is a lie being
> performed by a trusted source but it is still a lie.  The fact that the
> lie is occurring makes providing support to end users when access to the 
> server is not available increasingly difficult.
> 

But this happens all the time. Some of the preauths on Kerberos for example.
A secureID or even PKINIT where x509 names are mapped into principals. I know
that there will be some info in the tranisted field to identify the
original user. But how much can the final server actually check?

> 
>> You are arguing that the final server needs to do the mapping, I am 
>> arguing
>> that it can be done before and put into the token. I believe that it 
>> is more
>> of a implementation/performance issue then a security issue.
> 
> 
> This would be an interesting question to raise on the SAAG list.
> Is it a security issue or not?  I believe that jhutz and I both believe
> that performing an authentication mapping for the purpose of gaining
> authorization prior to the final server is a choice which can frequently
> result in a security issue.  As such we believe it should be avoided.

Yes it should be avoided, and it looks like the rxgk is headed in that
direction. But its not here yet. When it is and the PTS can specify
these names, then I will use it.

> 
> You have your solution for your environment today.  We do not believe 
> that this model is appropriate for wide spread use.  Love, Derrick, 
> Jeff, and others are working on a long term solution.  Unfortunately.
> as has been often pointed out there are only so many hours in the day
> and those hours are most often spent doing the jobs that pay the bills.
> So if the community wants to see a long term general purpose solution
> which provides strong data protection for AFS and other RX based 
> services, members of the community must step up and provide resources
> to ensure that it can be completed in a reasonable period of time.
>

And as I pointed out gsslog was developed for Globus, and I am not
being funded to work on it either.

Also at our site the AFS cell name and W2003 AD have the same name
and the userids match, so we really don't need a mapping service at our
site today.

> 
> Given what you said yesterday regarding gssklogd using its own service
> name, I believe it is possible to implement a client which can determine
> without end user interaction whether or not gssklog should be used when
> a traditional "afs" Kerberos 5 ticket is not available.  However, since
> the krb524d mapping hacks do not use a private service name, there is no
> ability to support it without special configuration and the krb524d 
> mappings will only continue to cause problems for end users and those
> who attempt to support them.
> 
> Jeffrey Altman
> 

-- 

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