Kerberized authorization service

[Ken Hornstein]

First off, let me explain my perspective.

My background has always been from a engineering perspective.  I look
at a concept and I immediately think, "How would I implement that?"  "How
would I use that?"  If I can't answer those questions, then I have a
problem with the concept, because I've seen plenty of things that seem
great on paper but fail to gain traction when the rubber meets the road.

>> - "Simple?"  Uh, you ARE kidding, right?  Right off the bat you
>>    start talking about n-bit vectors and cryptographic hashes.  And the
>>    diagram on slide 18 ... ouch.  And you use XML?  What exactly is
>>    SIMPLE about this idea?
>
>The authorization model.  Something which no one in the thread has
>addressed.

Well, hm.  Maybe this is a termology problem.  (Just to be fair, I went
back and read the original paper that is also linked to the web site).

>Since we are referring to page numbers; the authorization model was
>conceptually presented via an animated graphic on slide 8.

So, I looked at that slide (which wasn't animated on the PDF, but I
think I got the gist).

>From what I have seen, this is basically similar to all other "models" for
other authorization servers, with the exception that SIii is a concept
unique to your scheme.  But from what I can tell, the whole reason the
SIii exists is due to your desire to place that in a public directory.

Other authorization systems do not choose to do this, so they don't need
an SIii-equivalent concept.  So I'm not sure I would consider this part
of the "model", as I would use the word.  I'd almost call it an artifact
of the implementation (well, I don't know exactly what came first, the
SIii or the desire to use LDAP).  Maybe other authorization servers we've
talked about don't mention a "model" because they're self-evident.

>I've generally found non-technical types understand the model/concept
>far more quickly than most technical people.  I believe that tends to
>be a hallmark of disruptive technology.

Well, here's the problem with that: I would be one of the people you would
have to convince of your project's value before it would be deployed here.
So convincing people who think like me is likely important if you want it
to be used out in the wild (if you care about that).

>Since we are talking pragmatic experiences; a gedanken challenge for
>everyone with real world authorization experience:
>
>	An organization conveys two roles over a base of 50,000
>	users.  Implement an architecture which allows the two generic
>	roles to be custom managed at the individual user
>	level.  Overall model complexity cannot exceed the expression
>	on page 8.

You know, I never liked the term "roles".  It's a "hot" term in the
theoretical world, but I guess I never see a practical use of it when
we get down to actually assigning rights to people.  To me the easier
concept is ACL - that's something that just naturally fits into the
sort of access control decisions we want to make.  The examples I've
seen where they show "role" assignment always seem contrived, and somehow
we never end up doing things like that.

But, to answer your challenge - I think the Hascall double-secret authz
server would work just fine for this task.  How we organize the data
on the backend might need to be shuffled around a bit, but I don't
see any reason why it couldn't work.

>I will certainly grant the need to have a KDC which understands
>payload injection.  An authorization server model requires another
>platform to be deployed which by definition enters into the TCB of the
>organization with all consequent security constraints and issues.

One thing I've learned is that having a custom KDC makes your life hard.
I am personally loath to do it (we do it, but really, I hate it).  I'd
much rather add a new service to the TCB than have a KDC with Yet Another
Custom extension.

>If there is a belief IDfusion is not extensible enough its not being
>understood.  The authorization decision context and flexibility model
>is identical if not a superset to that of an authorization server
>model.

"Meh".  You have not yet convinced me of that.  I might grant you
identical (although I cannot see how you can do what I want) but a
superset?  I don't see it.

m>  Also, I cannot see how to make use of your scheme with cross-realm
>>  authentication ... and we use that a lot.
>
>Ah yes, the Reciprocal Identity Management (RIM) problem.  I can point
>people at a paper that discusses this issue in some depth.  I would
>hazard a guess we understand the issue pretty completely.

Maybe this is part of the problem we're having ... you're coming up
with these new strange terms.  "Reciprocal" Identity Management?  I've
never heard of that before, and that term doesn't even make any sense
to me!  But, you haven't really explained how this could work.  _Can_
it work?  You're using the authz field placed in the ticket during a
AS_REQ, which the "local" KDC doesn't participate in.  Does this mean
the foreign realm would have to have a KDC which placed authz data into
the ticket?

This is where the "traditional" authz server works just fine.  All that
gets communicated to the authz server is the principal identity.

>The only role LDAP has in IDfusion is to manage authorization data.

But hold on a sec ... I mean, that's really just shifting things around
slightly.  I mean, you have a choice between two alternatives:

- Present the identity information to an authz server, the authz server
  says "yes/no".
- Ask the LDAP server for some authz data that the app uses to decide "yes/no".

(I'm ignoring ancillary attributes right now).

Those look pretty close to me.  Why is one better than the other?

>IDfusion reduces the TCB of the IAA infra-structure of an organization
>to two components; LDAP and Kerberos, two well understood and widely
>implemented services.  An authorization server adds an additional
>security sensitive component.

This is a bit of a red herring, and I think you know it.

- IDfusion TCB - Kerberos and LDAP
- Traditional authz TCB - Kerberos and <insert your authz server here>

Again ... the difference is ...?

>In its most simple implementation IDfusion has the authorization
>question asked and answered by a single query using an IETF ratified
>protocol with multiple heterogenous implementations.  An authorization
>server uses a custom developed protocol which has no guarantee of
>inter-operability beyond its implementation site and platform.

"Meh".  I do not consider the blessing of the IETF of any particular
worth when I decide to use a protocol (or write my own).  I pick the
best tool for the job.  The number of implementations also is of little
consequence ... competition is nice, but I only need one.  And in this
particular case, I have realized that I don't really _care_ about
interoperability beyond my site.  Let me put it another way: if I had
an account at Iowa State and I connected to it from NRL, would I care
that they use the Hascall double-secret authz server?  No, because it
would be the Iowa State servers who would be talking to that authz
server.  Perhaps other sites feel differently, but I want to be in
complete control of all aspects of authorization decisions at my site.
I don't expect anyone outside of my administrative boundary to be
querying my authz server.

>There are no extensions to the Kerberos protocol required.  In its
>current implementation 20 bytes are added into a field which is
>required to exist in an IETF ratified standard.

Well ... that is true _in theory_, I can tell you from hard-learned
experience that when you start using fields that have not traditionally
been used in the Kerberos protocol, you may run into "exciting" new bugs.
But I think I used the wrong term ... perhaps I should have said
"nontraditional" instead of "extension".

>> BTW, there is a "simple" way to prove that I am full of crap.  All
>> you have to do is implement your design and get people to use it.
>> Clearly there is a desire for a reasonable authorization service
>> that ties into Kerberos, so if what you come up with is workable you
>> should have plenty of users.
>
>Unfortunately this simplistic assessment neglects the network effect
>which may be at its strongest in the field of enterprise IAA
>architectures.  As I stated before and will re-state somewhat
>colloquially, it may be all over with except for the shouting.

Well, hm .... okay, I don't follow you, at all.  "network effect"?

Here's my bottom line, for what it's worth.  I have listened to the
presentation, I've read the white paper and the slides, and I've tried
to understand what you're doing.  So far as I can tell, it is roughly
the same in function as a "traditional" authz server.  I can't see an
advange to your scheme over the traditional authz server.  You might
say that it's use of LDAP is an advantage - I would say that is just an
implementation detail.  You have some hand-waving about controlling
fine-grained user access with 50,000 users, but again ... I don't
see anything inherent in that scenario that makes a traditional authz
server not be able to perform that job.

If IDfusion and a traditional authz server were the same, then the
choice would probably go to the more mature codebase.  But from my
perspective IDfusion has some significant practical disadvantages.  It
requires a custom KDC, and how you would deal with cross-realm users is
simply not discussed (you say "we understand the issue completely".  I
will notice you didn't say, "IDfusion can deal with it", or even, "We
know how to solve this problem with IDfusion").

You have said that IDfusion is not being understood.  Well, I've done what
I think is a fair job of trying to understand it.  I don't know what more
I can do to understand it, so I have a hard time believing the problem is
all on my end.

--Ken