[kitten] PKCROSS and philosophical tangents...

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

Nico and company.

I hope this isn't out of line. I spend quite a lot of time thinking about this, as much of my job involves trying to collaborate with others.

Tangent #1: What is "authentication"?

I would like to propose that authentication is not sharing a secret with a KDC. In my organization, authentication is a background check by law enforcement. Once the paperwork has completed with a successful result, the CIO is then instructed to create an account for the authenticated user. Other organizations will have different processes, but the domain admins rarely authenticate users themselves. At the very least, HR and the employee's supervisor does that.

In a closed corporate/enterprise environment, this is the whole story. However, when you must collaborate with external partners, different authentication methods are introduced.

PKCROSS introduces a paradigm where entire foreign domains are authenticated by a certificate authority, to varying degrees of rigor. The essential characteristics of this paradigm are: 1] granular authentication: entire domains are accepted or rejected as an atomic unit; and 2] delegated authentication: the user's identity is only as certain as the policies and procedures employed to verify that identity prior to giving them an account. In this situation as with internal users, domain admins will probably not be afforded the discretion to choose which foreign domains will be cooperated with.

I would like to propose a third type of authentication: a "Sponsored external user". This paradigm assumes a home-user-driven need to cooperate with very specific groups of individuals from other institutions on specific activities. These external users are authenticated to the sponsor by the sponsor's ongoing observations of their actions during the execution of the project. Such projects usually occur because the sponsor interacts with the external user during the formulation of the project proposal, and there is usually some formal definition of project roles and distribution of money to the various participants. Some projects may be informal, and may not involve funds. However, it is almost certain that prior to sponsoring the external user, the individuals in question have been authenticated to the sponsor by some means other than their home domain's credentials. A human web of trust may be established, where the sponsor knows the leaders from the foreign institutions, and these leaders have requested that their support staff or graduate students be provided access to the project's resources.

Characteristics of the "sponsored external user" paradigm are: 1] fine-grained authentication: individuals are accepted or rejected; 2] delegated authentication: the "trust anchor" in this case is the sponsor, who may then delegate the choice of participants to leaders from other institutions; 3] accountability and responsibility: the buck stops with the sponsor; 4] human trust anchor aggregation: if several sponsors affirm several identities from the same foreign realm, confidence in that realm's identity should be high; 5] sponsored external users may or may not come from a foreign realm (e.g., the home realm may configure a "collaboration realm" to contain all the untrusted users and hosts as part of a larger effort to manage risk to the corporate systems.)

The bottom line is that cross-realm operation fragments the authentication process. More tools may be necessary to manage this fragmentation and reduce or distribute the administrative burden over the principals in the home realm. To reduce administrative burden, PKCROSS delegates authentication to a certificate authority and further delegates to the unspecified vetting process of the foreign institution. "Sponsored external users" keeps the trust anchors closer to home, focuses authentication decisions on a smaller group, and distributes rather than reduces the administrative burden.

I think what I would like to see in an RFC or draft is a general discussion of how to securely set up a collaborative environment using Kerberos, which then dives into specific, standardized technical solutions. I am certain that PKCROSS will play a large role, but I want to see such a document also handle the case where the external user does not have a home Kerberos realm. How does that user get injected into a Kerberized environment in a way that does not imply that any of the large Kerberized organizations are taking responsibility for them?

Ok, I'd better stop with tangent #1. ;) Thanks for your patience.

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.