[OpenAFS-devel] Aklog/krb5 mappings

Troy Benjegerdes hozer@hozed.org
Tue, 5 Jul 2005 19:32:19 -0500


On Tue, Jul 05, 2005 at 10:38:38AM -0400, Ken Hornstein wrote:
> >This doesn't fix the problem.  This opens the security hole for aklog
> >with krb5 tickets as well.  The problem is that there is no way to
> >distiguish between two krb5 principals;
> >
> >	user.admin@REALM
> >	user/admin@REALM
> >
> >Two identities in Kerberos should not be treated as the same identity in
> >AFS.
> 
> This code here is ONLY for aklog's client-side PTS lookup, which really
> exists for two reasons:
> 
> - Historical (this is the "ID xxxx" output in tokens), which apparantly is
>   only used by some components of the Andrew Mail System.
> - Determining if the cross-realm PTS entry needs to be created.
> 
> It doesn't affect the contents of the Kerberos ticket, which is the only
> thing that matters in terms of security.  There is no security hole in
> aklog (let me rephrase that: _this_ is not a security hole in aklog).
> 
> And didn't we already have this discussion six months ago?  The reality
> is that the Kerberos 524 daemon has been happily mapping V5 principals
> with a "." in them SINCE DAY ONE, and OpenAFS is the one that
> arbitrarily rejects V5 principals with a "." in them.

So before the 1.4 release, why don't we correct this ambiguity (which
seems to confuse a lot of people), and use a (default disabled) option
to allow the old mapping behavior. Looking back at some old messages,
would I be correct in saying, the only place we do these mappings is 
in aklog, fileserver, and ptserver? In regards to the mapping in aklog,
can we just ask the fileserver or ptserver.. that would reduce user
confusion if aklog thought the site mapping policy was one way, and the
servers used another.