[OpenAFS-devel] Kerberos v5 Principal Names containing dots in the first component

[Douglas E. Engert]

I agree with Ken that there may only be a handfull of special
cases. There may also be an approach 4.

4. Map compound K5 principal names, to name1/name2 rather
    then  name1.name2 in the PTS. i.e. use K5 separator and rules
    rather then K4.

This would require a site to go through there PTS and look at current
entries. But it would be much more in line with K5. The mapping of "host"
to "rcmd" and other K4 mapping should also be looked at. If AFS is
dropping K4, then it should drop its conventions in the PTS too.


Ken Hornstein wrote:
>> Clearly there is a need for many organizations to disable this
>> functionality.  Looking back through the archives of the openafs-info
>> and openafs-devel mailing lists the topic has been raised approximately
>> once per year.  During that time I have been the primary defender of
>> this code.  However, I am now convinced that although the security
>> issues are real, the usability issues are more important.
>>
>> The question therefore is which of the following should be done:
>>
>>   1. leave the code as it is and sites that wish to remove it can do so
>>      by applying the patch locally
>>   2. remove the code and sites that wish to add the check can do so by
>>      applying the patch locally
>>   3. conditionally execute the check by adding code to push command
>>      line configuration down into the rxkad security class AND one of:
>>         1. make the default be off
>>         2. make the default be on
>>
>> At this point I am tempted to say 2 but would be willing to accept
>> either of 3 provided that someone submitted an acceptable patch.
> 
> So I've been one of the more vocal criticizers of this code (mostly
> because this bit a group here very hard when the switch was made from
> V4 to V5 tickets).  I understand the reasoning behind it, but I think
> it was too broad of a check to be put into place.
> 
> I think either 2 or 3 (I'd even be happy with 3.2) is a reasonable
> approach.  But it occurs to me that maybe there is a compromise solution.
> Perhaps certain instances are the issue?  Blocking Kerberos V5 names
> that end in ".admin" is perhaps a good first-order effort.  I admit
> we can't probably come up with an exhaustive list that covers every
> situation ... but it would at least take care of the most common
> example.
> 
> --Ken
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
> 
> 

-- 

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