*FOO Conference Call*
October 25, 2002

*Participants*

Ken Klingenstein -- University of Colorado/Internet2(chair)
Peter Altermann -- Federal PKI Steering Committee/National Institute of Health
Brendan Dixon -- Microsoft
Renee Frost -- University of Michigan/Internet2
Rich Guida -- Johnson & Johnson
Michael Gettes -- Georgetown University
Keith Hazelton -- University of Wisconsin
Ingrid Melve -- UNINETT
Bob Morgan -- University of Washington
Eliot Solomon -- Securities Industry Middleware Council, Inc.
David Wasley -- University of California Office of the President
Nate Klingenstein -- Internet2 (scribe)

*Discussion*

FOO and Friends

A formal mailing list has now been created for the group at foo@internet2.edu. This subscriber-only list accepts transmissions only if the message's SMTP "From" field is equal to one of the subscribed addresses on the list. Minutes will be archived and placed on a fairly private website, but given the amount of peripheral interest, Ken expects it will be difficult to maintain a low profile. Given this interest, he suggested the construction of a peripheral foo- friends@internet2.edu e-mail list which will be used for delivery of amended minutes, handouts, etc.

SIMC's Approach and Issues

Eliot is the founder and chair of SIMC, an association of middleware and infrastructure practitioners from firms involved in the securities industry. Most of SIMC's focus has been on interoperability and connectivity in street-side interactions between firms. Many firms have looked at identity management generally, and there was a general sense that the evolution of middleware technology has presented an opportunity to develop an infrastructure that is able to interwork with other firms' in an efficient way. While B2B-style commerce has gone on between the firms for many years, it has taken place in a very constrained way.
The unique environment in which these firms interoperate has led to a fairly complex set of requirements to fulfill. It's imperative to maintain the trust and authority infrastructures implicitly in place with existing network topologies while moving into looser systems and more open network topologies. Banks have expressed a concern that if large sums of money are spent developing an internal identity management system, it should be useful for interfirm functions as well. The regulatory system and existing relationships fit naturally within a trust model which is somewhat federated. This transition has revealed a whole host of issues, none of these is insurmountable, but each requiring careful consideration. Interestingly, the approach that these requirements have yielded is somewhat similar to many important features considered by other group members.
Identity itself is very rarely the key factor in authorization decisions; additionally, the initiator of a transaction isn't accountable for its completion, tasks can be passed from one agent of the firm to another, etc. Similar to some of Bob Blakely of IBM's insights regarding security and repudiation, the important consideration in many transactions is indemnification. Generally, a firm will only trust or accept assertions from an issuing firm if the issuing firm is willing to be indemnified by the firm that relied on it with respect to failures in authorization, since these errors have the potential to be very large and costly. This means that semantics and claims used to acquire rights must be very narrowly defined to limit potential exposure for all parties involved.
There are also challenging requirements for consistency in semantics for communication and verbiage in assertions. There is a need to support auditing in a manner such that a persistent, inalterable record is created when an action is taken. This may be accomplished with some sort of digital cross-signing, but nothing has been concrete identified yet. If a firm has a policy by which it recognizes and accepts as authentic evidence from another firm, it can record only that it's recognized that, but preservation of the tokens isn't necessary. (This is a fine point of the regulatory regime surrounding securities firms which needs to be understood further, and a more general solution may be of broad interest.)

Least Privilege

A prominent concept that has appeared in SIMC's work which had great appeal to the rest of the group was that of least privilege. In an idea that could be applied to Shibboleth, least privilege holds that any permissions granted to a principle should be the minimum necessary to perform the principle's duty. While this may seem like an obvious desire, it is exceedingly difficult to use in practice today. Eliot mentioned that "SIMC was founded by eight angry DCE users."
For the middleware systems in use today such as passwords and traditional PKI that store authn/z information in a common, relatively static credential, least privilege is very difficult to achieve. The ideal solution would be to have an individual authenticate once with a new authorization credential generated for every transaction the principle is involved in which contains only the bare information necessary to grant the appropriate authz. This is a fairly difficult mechanical load for a system to support, and it is difficult to create the policy infrastructure necessary to make this degree of privilege reissuance useful.
The ticketing model is a classic and powerful solution to the problem, but as the underlying technology moves closer to a certificate style, the frequent credential issuance that this requires becomes so heavy that it must last for a long time. Some reasonable compromises which people have arrived at are ideas such as role-based access control and the assignment of credentials for single application sessions. This sort of hybrid model is, in Eliot's words, "a great thing, but theory and process have a long way to go to match each other."
These are insufficient for SIMC's purposes, however; giving someone a role to trade stock, for example, immediately yields a massive degree of exposure. Simply adding another bound to the stock-trading role, such as a timeframe or a dollar amount, greatly decreases the amount of potential liability. David put forth the interesting idea of implementing liability caps in relationships between companies that work on a bulk level, but Eliot indicated this is not a viable solution: the objective is to ensure that all risks are properly and completely covered. If this sort of cap is implemented, the uncovered risk has to end up somewhere, and this proves an uncomfortable proposition.
The concept of least privilege resonated strongly with Brendan, who further expanded on the idea by describing how Microsoft slices the problem. First, they try to state that what you believe is based upon three trust relationships: the user with their local authentication authority, another between the two authenticating realms, and a third between the foreign realm and whichever application is mediating the interaction. This leads to the notion of a per-message model around granting rights to a principal, which could be carried in a token with a lifetime attached as dictated by OOB agreements. A goal is to allow for the expression of all the information in the token in such a way that the attributes of the keys used to secure the message, the lifetime of the ticket, and even the vocabulary used to express permissions can change from moment to moment.

Authorization Authorities

Peter made the general observation that the part of the discussion on least privileges breaks down into two discrete approaches. The authorization mechanism can be contained within the token exchanged, or handled by an independent background process, each technique with its own advantages. Building on the successful model of the login server or authentication authority, which provides a single, authoritative point of authentication for principals within a security domain, one solution which arises somewhat naturally out of SIMC's problems is that of the authorization authority.
Assuming that principals in these transactions will belong to some sort of organization which dictates the principal's privileges, a trader could be given a token which represents a role or authorization, a timeframe, and some sort of credit limit. This token would then be repeatedly presented to the authorization authority which would examine it, compare it against some sort of information store and logic, and return an authorization decision. The model is somewhat lighter-weight than presenting individual transactions and authentications to an authorization authority with no context and no prior issuance, although the trade-off between least privilege and issuance burden will likely need to be considered for other applications.

UNINETT

Ingrid described some of UNINETT's requirements, which can be as unique as some of those posed for SIMC. Based on a network with no gateways, few firewalls, and a belief that "nothing is more dangerous than a student with a proper network at her hands," UNINETT needs to design a common credential for students at Norway universities. This is mixed in with other requirements for distance education and other trust structures present in the educational environment. In many situations there will be no clean borders, and the system has to be location-independent, supporting wireless access and other capabilities. Roaming of principals between identity service providers will be a common occurrence.
The main goal at present is to try to clean up the user management system, and establish the sort of directory service infrastructure at the local level that will be necessary for future applications and possibilities such as affiliated directories. The next step will be making a number of authn/z which scale to the degree required for UNINETT's constituency and interface with other systems around the world decently well. This will involve not only logins for various servers, but federated services like a common library.

*Action Items*

1. Ken will add some discrete names to foo-friends@internet2.edu, and invites interested parties to join the list as well.

2. Ken will try to find a common time for FOO calls, and work to enlist a member from the Liberty Alliance.

3. Brendan will send out a roadmap on Microsoft's web services vision.

4. Eliot will send out SIMC's business scenarios and requirements for interoperability once they're reviewed by participants.

5. MACE-Dir's inter-domain data exchange white paper will be published as part of the NMIR2, and URL will be sent then to the FOO list.