Re: [kitten] PKCROSS and philosophical tangents...

[Ken Hornstein <[e-mail]>]

>Axiom: Successful large-scale Kerberos deployments authorize users to
>maintain their own authentication tokens. (e.g., I can change my own
>password)

So, that gets sort of complicated.  I'll explain what we did.

There are two general levels of access we have to our systems.
"Interactive", and "Everything else" (they don't really have these sort
of formal names, but that's what it ended up being).

"Interactive" is an interactive login.  In other words, you login in with
Kerberos rlogin/ssh/whatever and get an interactive shell to do stuff
(obviously this is all Unix based).

"Everything else" is sort of vague, but in general it refers to stuff
that doesn't require an interactive login or something that looks like
that (consider it things that don't require a Unix user account).  This
could be things like web pages or filesystem access.

We only accept interactive logins from a relatively small number of
Kerberos realms (when I say "relatively" I mean "relative to the total
number of KDCs we cross realm with").  We control the mapping from a
particular foreign-realm principal to local Unix account.  That mapping
only happens after a formal account process has been completed.  That
federated group of KDCs all have the same policies, so there's no issue
there in terms of someone not meeting your security policies.  All of the
people in this federation receive funding from the same source, which helped
generated a uniform security policy.

"Everything else" users have a lot lower access, and generally only get
used for a few things.  But it's valuable to have that ability.

>Corollary: The lack of the ability for principals (KDC admins)
>to update their own tokens in a foreign KDC has inhibited the formation
>of Kerberos federations, and requires manual coordination between admins
>which is cumbersome and causes downtime.

When you say "update their own tokens in a foreign KDC", do you mean the
cross-realm principals?  Because that is not true; we rekey our cross-realm
principals on a regular schedule.  Okay, it may be cumbersome and require
manual admin intervention, but it does not require downtime.  And actually,
you COULD rekey cross-realm principals automatically with some programming;
it's one of those things that's on my list to do.

>In this light, I understand PKCROSS to be a means of automatically
>keying your KDC's credentials in a foreign system. However, it is
>unclear to me how these credentials get updated when they inevitably
>expire (or are stolen). Is that section TBD or am I just dense? I
>took the draft to say that the initial certificate must stay the same
>forever or else risk being rejected as a MITM attack. I'm willing to
>be persuaded, but I'm not quite seeing how the draft addresses the
>deficiencies it identifies.

Assuming we're talking about draft-williams-kitten-krb5-pkcross-02.txt ...
as I read it, expiration/stolen principals are dealt with the same way
you'd deal with other stolen credentials in Kerberos.  Generally tickets
expire in a relatively short timeframe, and you'd need to do a new
PKCROSS exchange every time you get a new ticket.  Same issues you have
with Kerberos.

>It's possible that account maintenance could be facilitated
>with a series of recommendations and the corresponding security
>analyses. Expose your password-changing interface to the wide
>world and advertise which set of admin tools (MIT/heimdal/MS) are
>compatible?

Well, we already expose our password changing interface to the world,
because otherwise how are users going to change their passwords?

>My purpose in bringing up those papers was not so much to propose a
>means of getting a TGT as to ask about alternative means of trust
>evaluation for the CA which signed the foreign KDCs certificate. Does
>the standard need to specify how trust is evaluated? Should it narrow
>the field to a handful of identifiable algorithms? Should it start
>simple but allow for growth?

Hmmm ... my opinion is how trust should be evaluated is out of scope for
a document like PKCROSS.  That should be done on a site-by-site basis.

--Ken