On Tuesday, July 05, 2005 07:32:19 PM -0500 Troy Benjegerdes
<[EMAIL PROTECTED]> 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;
>
> [EMAIL PROTECTED]
> user/[EMAIL PROTECTED]
>
> 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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
