[OpenAFS-devel] Aklog/krb5 mappings

[Jeffrey Hutzelman]

On Wednesday, July 06, 2005 05:11:56 PM -0400 Ken Hornstein 
<kenh@cmf.nrl.navy.mil> wrote:

>> For AFS, the problem is made somewhat worse by the fact that we
>> construct  usernames by concatenating the V4 name and instance with a
>> dot, but only  when the instance has non-zero length.  This behavior
>> depends on the  premise that a V4 principal name will never contain a
>> ".".  While krb524d  is broken and does not enforce this restriction,
>> the V5 ticket handling  code in rxkad does.  The reasoning is the same
>> as above -- mapping multiple  distinct V5 principals to the same AFS
>> username could result in all sort of  nasty security problems.
>
> This is going to be my last message on this topic, honest.

That sort of makes it hard to come to any agreement.


> - Clearly neither of the two open-source Kerberos implementations consider
>   this a security problem, as they do not perform this checking.  If it
>   was a "nasty security problem", we'd see CERT warnings issued and
>   patches to correct the problem.

Neither of the two open-source Kerberos implementations contains a function 
which maps a Kerberos V5 principal to a string containing an AFS username. 
They contain functions which map V5 principals to V4 principals represented 
as a set of three strings, in which it is easy to distinguish between a 
principal with name "jhutz.admin" and instance "" and a principal with name 
"jhutz" and instance "admin".  AFS usernames don't have that property, and 
so there are additional possible collisions which AFS needs to detect.

Probably rxkad should reject _V4_ principals with a "." in the name, since 
there are things (like krb524d) which do not conform to what AFS assumes is 
an invariant.  But I'm not insisting that we fix this problem, only that we 
don't create new ones.


> - This could only conceivably be an issue if you allow users to create
>   arbitrary principal names.  I know that CMU allows users to create
>   arbitrary instances for some strange reason, but even you have to
>   admit that this is a rather uncommon practice.

Huh?  Where did you get that idea?


> For sites that don't
>   allow users to create arbitrary principals, the only thing this check
>   accomplishes is that it breaks things for V5 sites that have created
>   principals with "." in their names (it doesn't even do a mapping to
>   something else; it just silently rejects them!)

It prevents the case where a new user at mondo-big-site says "I want my 
userid to be foo.root", and accounts, not knowing any better, creates it. 
It also prevents the case where a site assumed that "foo.root" and 
"foo/root" were different principals gets screwed becaose AFS decides they 
really aren't.

I'm not asking for those sites to be broken.  I'm happy to give them a 
feature that makes things suck less for them.  However, I want

- no new complex changes before 1.4
- no hidden time bombs as a result of upgrading to 1.4


I think I'd be OK with making a change as part of a larger naming overhaul, 
which I expect/hope will happen anyway.  I expect that such a change will 
require that administrators pay attention before they get any new behavior, 
since it will likely moving mapping into the ptserver and making a change 
to the prdb format.