[14636] in Kerberos
Re: Principal naming.
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Fri Jul 6 17:23:40 2001
To: "Booker C. Bense" <bbense@networking.stanford.edu>
Cc: <asr@ufl.edu>, <kerberos@mit.edu>
From: Ken Raeburn <raeburn@MIT.EDU>
Date: 06 Jul 2001 17:20:38 -0400
In-Reply-To: <Pine.GSO.4.33.0107050732480.6419-100000@shred.stanford.edu>
Message-ID: <tx1lmm1daah.fsf@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
> > Greetings, all.
> >
> >
> > We're re-examining how we name some special-purpose administrative principals
> > here at UF, and wanted to evoke some comments or experiences.
> >
> > The docs seem clear that Kerberos 5 principals are:
> >
> >
> > component(/component)+@REALM
> >
> > i.e. many components are possible.
> >
>
> - The documents are clear. The code is not so clear, I seem to recall
> that there is some place where 3+ components breaks the code
> ( GSSAPI? )
I think it should mostly be okay, but we aren't really exercising this
sort of thing.
The problem with GSSAPI, as I recall, is that there's no generic
scheme for providing a name that maps to more than two components.
The most commonly used GSSAPI service name type, at least in the
Kerberos world, is host-based service names, and you get two
components, the service name and the hostname (service@host).
Providing something like "foo/bar@host" through that interface would
give you a Kerberos principal name with two components, one being
"foo/bar" and the other being "host".
There is a "Kerberos principal name" name type for GSSAPI, but
obviously it's likely to be completely useless for other
authentication schemes within GSSAPI.
If you're making a Kerberos-only service, and not planning to permit
other authentication schemes, these problems aren't relevant.
> > Has anyone encountered interoperability issues with more than two components?
> - Microsoft does this with their kerberos implementation, but they
> also provide two part aliases.
Yes, and the alias extension itself has caused us compatibility
problems (because the MIT code wasn't using or providing it), but I
don't think the multiple-component names did per se.
> > What are the circumstances in which other organizations have used these longer
> > principals?
> - I vaguely remember that DCE at least allowed/encouraged this kind of
> usage.
Yes, though I'm not familiar with DCE's approach.
> > We're contemplating using three segments to let us express:
> >
> >
> > group1/APPLICATION/application-name
> >
> > to permit differentiation between the domain of application names and some
> > other set of names we haven't thought of yet.
Our approach has generally been that service names are a single
namespace, and nothing else uses host-based service principal names.
Non-host-based services generally use some other name as the second
component to identify the instantiation, if it may not be unique
within a Kerberos realm (afs/sipb.mit.edu@ATHENA.MIT.EDU would be the
AFS service for the sipb.mit.edu AFS cell in the ATHENA Kerberos
realm), or sometimes just some other generic second component
(zephyr/zephyr@ATHENA.MIT.EDU is the Zephyr messaging service).
Users typically have one or two components (one for regular accounts,
some have two for additional principals with extra privileges). There
is some small risk of overlap there, yes.
As for "some other set of names we haven't though of yet", if they're
going to be neither users nor host-based or instance-based service
names, perhaps they should get the "weird" principal names?
I'm not clear what you're trying to accomplish with the "group1" bit
here. Different departments or development groups within an
organization? Are they allowed to define overlapping service name
spaces? Do they run services on shared machines but require separate
authentication names?
> > We'd considered something like
> >
> > group_application/APPLICATION
> >
> > to parallel foo.bar.com/host
Do you mean "host/foo.bar.com"? We've always put the application
(service) name first, and the hostname (service instance name) second.
> > but are currently thinking that, if we want to put in all three of those
> > tokens we should use the '/' delimiter.
Don't think in terms of delimiters, think in terms of multiple
components. Especially if you might be using GSSAPI -- what's a good
*generic* model for what you're trying to do, independent of Kerberos
principal naming specifically?
Ken
