Back on 2002/11/15, a patch was committed to the Kerberos v5 ticket processing code in src/rxkad/ticket5.c to prevent name space collisions between two Kerberos v5 principals when mapping them to the AFS Protection database.
http://www.openafs.org/cgi-bin/wdelta/rxkad5-dont-allow-dot-in-aname-20021114 Without this code, the Kerberos v5 principals "[EMAIL PROTECTED]" and "joe/[EMAIL PROTECTED]" which are two separate entries in the Kerberos DB are both mapped to "joe.admin" in the PTS DB when the local realm of the cell is "REALM". The idea behind this patch was to prevent the issuance of the "[EMAIL PROTECTED]" principal from accidentally resulting in a non-administrator from being given administrative privileges within the AFS cell. However, this code is only triggered when the AFS token consists of a Kerberos v5 ticket. It is not triggered if either: 1. A Kerberos v4 ticket is obtained for the "[EMAIL PROTECTED]" or "joe/[EMAIL PROTECTED]" principal by the Kerberos v4 support in either the MIT or Heimdal KDCs 2. A Kerberos v4 ticket is obtained by converting a Kerberos v5 ticket via the krb524 service. As a result, the inclusion of this code in OpenAFS results inconsistent behavior and does not in fact prevent the attack it was designed for if the Kerberos realm has Kerberos v4 support. The code would prevent the attack in a purely Kerberos v5 realm (or Active Directory.) Preventing the attack comes at a significant cost. All principal names of the form "[EMAIL PROTECTED]" are considered invalid. This naming scheme is extremely common in large organizations. Especially those using Active Directory. As a result, it becomes a major hurdle to the adoption of AFS as a storage solution. 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. Comments? Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
