An alternative plan for principal mapping greg at
Thu Aug 10 17:48:27 EDT 2006

On Aug 3, 11:27am, "Henry B. Hotz" wrote:
} Subject: Re: An alternative plan for principal mapping

Good day, hope everyone's week is going well.

> On Aug 2, 2006, at 7:35 PM, Sam Hartman wrote:

> > It's important that we don't create a situation where services expect
> > the KDC to perform authorization checks and fail insecurely if that  
> > does not happen.
> >
> > PAC like behavior is fine because a service can tell if the PAC is not
> > present.  However something where a service expects a KDC only to
> > grant tickets to authorized users would be a really bad idea, because
> > it would mean the service is only secure with certain KDCs.
> >
> > --Sam

> That's a very correct technical position to take.  That's why I
> called attention to the issue.

Correct technically but incorrect from a pragmatic implementation

Placing a keytab on an application server implies a trust relationship
between the application provider/vendor and the manager/deployer of
the KDC.  If service ticket rejection is the preferred form of
authorization the application has to trust the KDC to do the 'right'
thing if its willing to accept a key from the KDC.

Consider an alternate framing of the issue:

If the KDC cannot be trusted to properly reject service ticket
requests how can it be trusted to place correct authorization payload
information into a service ticket?

A generous characterization of current authorization support is
primitive to non-existent.  Until something happens to correct this
the big hammer approach may be the only option available.  This was
the case with our work to implement AFS authorization via service
ticket rejection.

> OTOH (at the risk of starting another long thread with Greg W. like
> I did once before) the only thing people really care about is
> authorization.  I already have problems with people believing that
> having a Kerberos ticket is sufficient to access things.  A standard
> way to solve the authorization problem without requiring another
> independent implementation/integration effort would be very nice.

My reputation proceeds me... :-)

No more long threads from me, I've given up wasting my breath.  Anyone
who doesn't understand the need for a generic architecture for
implementing authorization doesn't have a lucid assessment of the

I believe we have the model for that in Hurderos.  If anyone is
interested we are ramping up efforts with the Apache Directory people
to set that standard.

Two paragraphs, a new record.

Best wishes for a pleasant weekend to everyone.


}-- End of excerpt from "Henry B. Hotz"

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg at
"Heaven goes by favor.  If it went by merit, you would stay out and your
 dog would go in."
                                - Mark Twain

More information about the krbdev mailing list