Kerberized authorization service

[Jeffrey Altman]

Ken Hornstein wrote:
> DCE tried to put authz data into Kerberos, and I think everyone would
> agree that DCE has been a failure.  Now obviously putting authz data
> into Kerberos is not the reason that they failed, but it just shows
> one of the fundamental problems with DCE - over-engineering.  You could
> bring up Microsoft as a counter-example.  That would be true, but Microsoft
> has the advantage of having tons of paid programmers to implement their
> designs and they control all aspects of their software at all levels.
> In the open-source world we do not have those luxuries ... we need to
> be able to have designs that are simple to implement and understand, and
> we need to be able to play nicely in heterogenous environments.
 From my perspective the problem with DCE and Active Directory is not 
that they
store authz data in the Kerberos ticket.  Doing so addresses a large 
number of issues
associated with partially connected network graphs and and mobile clients.

Where I believe there is a failure is that they do not provide the 
alternative model
as well.  A service should not have to trust the authz in the service 
ticket if it believes
that it might be out of date.  In federated environments, the authz 
decision should be
made by the organization that owns the service and that organization 
should not be
forced to stuff additional authz data into the issued service ticket.  
Note that in the
Kerberos cross-realm model the cross-realm TGT is not issued by the 
organization
performing the authz, so there is additional overhead associated for the 
KDC in
reconstructing the authz data for each service ticket that is issued.  
Finally, for compatibility
with pre-existing service protocols that have credential size 
limitations there needs
to be methods of disabling the issuance of authz not only TGS-REPs for 
general services
but for cross-realm TGTs as well.

The Kerberos API krb5_userok() comes fairly close to having the correct 
interface.
The problem with the implementation is that there is no pluggable mechanism
for calling out to an authz service.  Recompiling the libraries for each 
organization's
authz model is not usable.  I believe the model needs to have the following
components:

1. a mutually authenticated channel between the service issuing the 
query and the
    authz service
2. the protocol should provide
    a. identity of the requesting service (obtained through mutual 
authentication of the channel)
    b. name of client as trusted by the service
3. the protocol should return
    a. yes or no response
    b. reason for a no response that can be returned to the client
    c. (optional) authz data (group memberships, rights, etc.) as of the 
present time

That is my two cents worth ...

Jeffrey Altman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20080211/e3e244c5/attachment.bin