[OpenAFS-devel] Aklog/krb5 mappings

[Jeffrey Hutzelman]

On Tuesday, July 05, 2005 07:32:19 PM -0500 Troy Benjegerdes 
<hozer@hozed.org> wrote:

> 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.


AFS does not name users with principal names; it names them with usernames, 
which are single strings.  The UserList file and the ptserver protocol both 
use usernames on the wire, not principal names (ACL's are actually 
represented using numeric viceID's, but these are represented as usernames 
on the wire for the purpose of the getacl/setacl operations).

Various things, including the fileserver, know how to construct an AFS 
username from a {name,inst,cell} tuple, which for the purpose of this 
discussion can be treated as equivalent to a V4 principal name.  They do 
_not_ know anything about V5 principal names; the conversion from a V5 
principal name to a {name,inst,cell} tuple is done in krb524d for 
traditional V4 tokens, and in rxkad for V5 and 2B tokens.

The set of valid V5 principal names is considerably larger than the set of 
valid V4 names -- V5 permits more than 2 components, more than 40 
characters per component, and allows characters not permitted in V4.  This 
means that it is impossible to map every valid V5 principal name to a 
unique, valid V4 principal name (and thus to a unique, valid AFS username). 
So, we must make a choice -- we can either map multiple V5 principals to 
the same V4 principal, or permit only a subset of V5 principal names to be 
mapped to V4 names.

Since mapping multiple distinct V5 principals to the same V4 principal 
could result in all sorts of nasty security problems, the approach taken by 
both krb524d and rxkad is to restrict the set of V5 principal names that 
can be mapped to V4 names.  Particularly, mapping fails for the following 
cases:
- Principals with 0 components
- Principals with more than 2 components
- Principals in which any component is longer than 40 characters
- Principals in which the realm is longer than 40 characters

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.



Changing the mapping behavior to do something more complex depending on the 
authentication mechanism used is on the roadmap, but will require some 
design work, changes to the ptserver protocol, and probably 
backward-incompatible changes to the PRDB.  Even doing something as simple 
as mapping multi-component V5 principal names to strings containing "/" 
would require a change to the rxkad API and all the places that call it. 
That's not something that I want to do more than once, and it's certainly 
not something that's appropriate to do this late in the release cycle.


Having the default mapping behavior for existing names change as a result 
of a software upgrade to 1.4 would violate the principal of least surprise. 
A subtle change like allowing multiple principal names to map to the same 
username where previously they did not would be particularly bad, since 
such a change has security implications that might not be noticed for some 
time.

I would have no problem if, as a result of the upcoming naming overhaul, we 
started mapping V5 principals to usernames containing slashes.  I would 
have no problem with allowing principals with "." in the first component to 
be mapped as a result of an explicit mapping or of a configured 
name-mapping pattern (both features I hope to see).  And I would have no 
problem with a configuration option or even compile-time option which 
enabled mapping these names by default.

However, it is unacceptable for a software upgrade with no configuration 
change to result in users unexpectedly gaining privileges or access rights 
which they did not previously have.




Finally, I'm getting a little tired of hearing "well, let's just do XXX 
right before 1.4".  We are very close to a 1.4 release.  This late in the 
release cycle, it is appropriate to fix bugs but not to add features or 
make behavioral changes.  This is particularly important for this version, 
which will be the first "stable" version to include support for several 
significant platforms.  At this point, new features, behavior changes, and 
"improvements" should wait for the next development cycle.

-- Jeff