Re: choosing principal names

On Thu, Oct 6, 2011 at 5:37 PM, Russ Allbery <[email protected]> wrote:
> Nico Williams <[email protected]> writes:
>> It's a very good performance optimization, first of all, but also it's
>> good for privacy: the issuer can change the PAC contents according not
>> just to who is the client principal, but also according to who is the
>> service principal (or what realm you transit to/through).
>
> You can do that even better, and more flexibly, with LDAP, and have the
> additional advantage that LDAP updates immediately whereas the PAC is
> created at the issuance of the ticket and then doesn't change.

One of the nice things about Kerberos is that once you have a service
ticket you don't need to talk to infrastructure again until the ticket
expires -- predictable performance.  OTOH the service has to talk to
name services, and this makes up for Kerberos' lack of revocation.
(I've seen environments where name service data is pushed to all
servers so it can be accessed locally, again with predictable
performance.  This effectively provides revocation, though not for
current sessions, and it doesn't scale well.)

A PAC certainly makes the lack of revocation worse.  I would like to
see an async revocation protocol for Kerberos, but even such a
protocol would have difficulty servicing systems outside a realm or
forest.

> I think LDAP lookups are superior to the PAC in every possible respect
> except for performance and the requirement to contact a central service
> (PAC data can work in a more decoupled network environment).

Except for Simo's use case, where the application server can't talk to
the client principal's LDAP server for policy reasons.

I suppose that if LDAP servers implemented suitable filtering policy
languages, then the privacy issues could be addressed without a PAC.

You might want to make this comment at KRB-WG...  If you don't, I might.

Nico
--