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

["Nordgren, Bryce L -FS" <[e-mail]>]

Good to hear from someone who's done it. I haven't, so I mainly have questions instead of answers. Perhaps I should "briefback" my understanding of the motivation of PKCROSS by rephrasing the intro section:

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

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.

PKCROSS to initially key your principal, plus a means to subsequently maintain the authentication tokens for your principal? Well, that addresses the problem statement.

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? Stand up a web app which lets you log in and manage your credentials? Extend the base standard with a  "principal management" message exchange? Dunno. It's probably important to specify that sites wishing to support federation SHOULD do certain things, one of which is to ensure that offsite (outside firewall), non-home-realm principals have the means to manage their credentials.


> I looked at the papers you posted; they seem interesting, but if the goal is to
> use one of those systems to get a Kerberos TGT ... well, I'd wonder what the
> advantage would be compared to one of the existing systems.

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?

Thanks for your time!
Bryce






This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.