*MACE-WebISO Conference Call* October 2, 2001 *Participants* Nathan Dors -- Washington(chair) Susan Bramhall -- Yale Tom Dopirak -- CMU Jim Farmer -- JA-SIG Scott Fullerton -- Wisconsin Dan Jones -- Colorado Bob Morgan -- Washington Ryan Muldoon -- Wisconsin Russ Tokuyama -- Hawaii Russell Yount -- CMU Steve Willey -- Washington Nate Klingenstein -- Internet2(scribe) *Discussion* Logistics MACE-WebISO will be conducting routine bi-weekly calls at 20:30 UTC Tuesdays, of which this is the second. The website, maintained by the group's chair, Nathan, is hosted at http://middleware.internet2.edu/webiso. This website will eventually host informational documents, previous conference call minutes, a to-do list, and other materials produced by the group. The group also agreed that this site will be open to the general public. [AI] Jim asked to be added to the MACE-WebISO mailing list. The scribe also humbly requests patience as he learns the nuances and parlance of a new field. Interfacing and Information Bob introduced a new area of interest for the Pubcookie project; instead of merely providing the Pubcookie ISO system, the Pubcookie team will be working on developing common interfaces for the Pubcookie system so that places which have analogous programs to Pubcookie which provide similar functions will be able to use Pubcookie for other functions relatively seamlessly. This is compounded by the question of where the WebISO system ends and where applications, portals, and similar web systems begin. Around the realm as an effort to further informational dissemination, [AI] Nathan offered to post some documents by Ryan to the website providing more of a general background to WebISO, which Ryan agreed to continue to refine, and Bob offered what knowledge he had of the Michigan efforts. [AI] Carnegie Mellon and the University of Hawaii volunteered to try installing Pubcookie ISAPI filter for IIS in their local environments. Susan discussed how she envisioned Pubcookie working as an initial authentication method for uPortal. In uPortal, there is a series of classes and interfaces defined so that any authentication can be provided easily as a front-end to the uPortal. One of the greatest difficulties in using Pubcookie as a thin authentication layer in front of uPortal is that Pubcookie attempts to provide session management, which is something that uPortal would generally allow the application to perform itself as a matter of simplicity. In an effort to give more information, and citing that the uPortal source code needs supplementary documentation, [AI] Susan offered to distribute two documents on the security provider interface of uPortal and on the use of ISO with portals. [AI] Russ bravely agreed to attempt to unify uPortal and Pubcookie in a functional implementation. There was brief consideration of addressing the problem of delegation. Common to many authorization procedures is the issue of a primary entity authorizing a secondary entity to perform certain restricted actions for which that primary entity has been authorized by the central service. This is inherent for portals, as the portal performs requests and authentication on behalf of the user. The topic of delegation has been the subject of, in Bob's words, "a great deal of work over the last 20 to 30 years. It would be a truly wonderful thing for an Internet2 group of some kind to write something up around that, but this may not be the group." He recommended the group focus more on ISO best practices and implementation before solving these further problems. Yale has come up with several approaches to delegation in their implementations to date; most notable are uPortal channels, which are able to perform authorized actions on behalf of an authenticated user to certain services. Threat Models and Security Requirements The Pubcookie team recently spent a great deal of time working to refine the key management model of Pubcookie, which currently distributes the same private key to every server that wishes to use Pubcookie in Washington's implementations. The group was attempting to find a threat model which would encourage any reason to require a different form of key distribution and assignment, e.g. PKCs issued to individual servers. There is no apparent need for the benefits to security and accompanying greater difficulty of this style of issuance. The team is generating a document that will propose eliminating the need for encryption of information in transit and making modifications to the way the current cookies are signed. The question of whether keys would be done by logical or physical layers was also approached; physical key management would entail giving a key to a server, and logical key management would be giving a key to each service. These are currently, in Nathan's words, "mangled to be specific to the physical layer." There are many reasons to prefer providing keys by application, instead, and this ability may be part of future Pubcookie design. At Yale, the reduction of security is taken even further where they have begun to attempt to support ISO for some web servers without requiring that these servers authenticate themselves or register with the central server. There may be some instances in which providing this ability is appropriate. Ideally, there would be a full write-up detailing the advantages and drawbacks of this approach for some servers, but this has not been developed yet. Bob likened coding the requirement for server authentication to the WebISO system as similar to forcing people to run an anti-virus system; obviously, it is recommended in many ways, but it is not necessary. This is part of separating campus policy from software policy which will be important for Pubcookie so that each adopting campus can implement its own campus policy along with the Pubcookie necessities. *Action Items* 1. Carnegie Mellon and the University of Hawaii volunteered to try installing Pubcookie ISAPI filter for IIS in their local environments. 2. Susan will send out documentation on both the security interface at Yale and a document on the use of an ISO system with uPortal. 3. Nathan will post basic information developed by Ryan about WebISO systems on the website. Ryan also agreed to further develop these writings based on feedback the group should submit. 4. Bob offered to disseminate what he knows of Michigan's WebISO efforts. 5. Russ Tokoyama from the University of Hawaii also offered to try uniting Pubcookie and uPortal.