Editor's Note: Minutes received 7/28 CURRENT_MEETING_REPORT_ Reported by John Linn/DEC Minutes of the Common Authentication Technology Working Group (CAT) Recorded by John Linn and incorporating information from summary slides submitted by P. Rajaram. The CAT Working Group met for one session at the July 1992 IETF. Primary discussion topics were: o Document status review. o Liaison requests from other standards organizations. o Technical discussion of mechanism negotiation. Document Status Review The request to advance the base GSS-API Internet Draft to Proposed Standard was the first such request to be processed after the adoption of a security area policy requiring that specifications be submitted to independent reviewers before passing them on to the IESG. This pre-review process is currently in progress, with one set of comments so far received and forwarded to the CAT mailing list. Steve Crocker indicated that the pre-review will be complete by August 10th. Some changes to the GSS-API C Bindings Internet Draft will be required, in response to accumulated comments and to track updates to the base specification. Cliff Neuman indicated that he expects to produce an updated version of the Kerberos V5 Internet Draft by the end of July. Liaison Requests from other Standards Organizations Subsequent to the San Diego IETF, John Linn had been approached by representatives from the X/Open Security Working Group and the POSIX Distributed Security Study Group, both of which indicated interest in adopting GSS-API within their standards processes. A short hardcopy paper, ``Distributed Security Services Programme'', was received from the X/Open group; copies were distributed at the meeting. X/Open engages in activities including definition and implementation of interface test suites, and in establishment of agreements with end system vendors to encourage availability of adopted interfaces on a wide variety of platforms. These activities appear usefully complementary to IETF-CAT goals. In terms of process, Vint Cerf underscored the position that it was wholly appropriate for X/Open or other bodies to incorporate IETF specifications into their processes through reference to standards-track RFCs, but that change control to the specifications must remain within the IETF. 1 Piers McMahon attended the CAT session and has been a participant in the POSIX Distributed Security Study Group. He indicated his perception that POSIX would prefer to adopt GSS-API by way of X/Open rather than initiating a separate POSIX activity in this area. It was noted that authorization-oriented GSS-API extensions are under consideration in several forums, and that X/Open might also be a likely forum for standardization of such extensions. John Linn accepted the action to coordinate with X/Open representatives to evolve a scope and action plan for liaison activities, and to report results back to the CAT Working Group. Piers plans to send a note reporting on relevant status of the POSIX study group, which was meeting in Chicago simultaneously with the Cambridge IETF. Technical Discussion of Mechanism Negotiation P. Rajaram indicated that he had been investigating approaches on mechanism selection and negotiation within the GSS-API framework, and led a discussion on the topic. He observed that GSS-API mechanism types correspond to groupings of authentication protocol per se, associated encryption algorithm, and associated hash function, and expressed a belief that three or four basic authentication protocols would likely exist in the marketplace but with many algorithm combinations. Further, different protocol/algorithm combinations would vary in their support for per-message confidentiality and integrity features and in their performance characteristics. It was observed, however, that divergent feature support within a single mechanism could result in cases where a given GSS-API implementation might not be able to determine the feature set supported by a desired peer. (Editor's Note: I believe that this could be reconciled by design of a mechanism in which peers declared their supported features to one another in exchanged tokens, without returning an indication of the features jointly supported until the context establishment sequence is complete.) Raj suggested that the selection of appropriate mechanisms, and of feature sets within those mechanisms, should be refined based on application-stated requirements (e.g., integrity and confidentiality support, in addition to the service indicators already incorporated) and domain-administered policies (e.g., based on application and user names, initiator and target addresses, connection paths, time of day, ...). It was further suggested that GSS_Init_sec_context() be extended to allow an application to indicate a set of mechanism types as input to negotiation, rather than only a single type or a ``default'' specifier, and that a new Map_mechanisms() call accept a mechanism set and an indicator of application service requirements and return a subset of the input mechanism set suitable to satisfy the indicated requirements. Mechanism selection would be performed on an end-to-end basis, between peer applications, based on an intersection of the sets acceptable to both peers. This proposal led to an active discussion about the danger that use of negotiation to arbitrate among multiple mechanisms would generally result in the use of the weakest (``low water'') alternative. It was suggested that each end system would appropriately maintain a database identifying (individually or through wildcards) the correct 2 mechanism to use with particular peers. It was further suggested that target systems should be able to write ACLs selectively granting access based on the mechanism with which an initiator was authenticated. Given the level of controversy about the mechanism negotiation concept, no specification changes to aid its support were immediately adopted. Raj accepted an action to write a strawman proposal for a rendezvous scheme which would arbitrate mechanism selection in a secure fashion, and to distribute the result for mailing list discussion. Interface impacts would be revisited in the course of evaluating and evolving this proposal. Attendees Derek Atkins warlord@thumper.bellcore.com Tony Ballardie a.ballardie@cs.ucl.ac.uk Mark Baushke mdb@cisco.com Mark Bokhan bokhan@abitok.enet.dec.com Geetha Brown geetha@decvax.dec.com Vinton Cerf vcerf@nri.reston.va.us Stephen Crocker crocker@tis.com Michael DeAddio deaddio@thumper.bellcore.com Pierre Dupont Tom Farinelli tcf@tyco.ncsc.mil Barbara Fraser byf@cert.org Shari Galitzer shari@shari.mitre.org Gary Gaudet gaudet@zk3.dec.com Kenneth Grant kgrant@oracle.com Theodore Greene Neil Haller nmh@thumper.bellcore.com Mark Hollinger myth@ssg.lkg.dec.com William Huyck David Katinsky dmk@rutgers.edu Stephen Kent kent@bbn.com John Linn linn@erlang.enet.dec.com Ellen McDermott emcd@osf.org P.V. McMahon p.v.mcmahon@rea0803.wins.icl.co.uk Marjo Mercado marjo@cup.hp.com Clifford Neuman bcn@isi.edu Rakesh Patel rapatel@hardees.rutgers.edu Lars Poulsen lars@cmc.com Allan Rubens acr@merit.edu Jeffrey Schiller jis@mit.edu Martin Schulman mas@loyola.edu Vincent Sgro sgro@cs.rutgers.edu Robert Shirey shirey@mitre.org Jeremy Siegel jzs@nsd.3com.com Sam Sjogren sjogren@tgv.com Theodore Ts'o tytso@mit.edu John Vollbrecht jrv@merit.edu David Wang wang@xylogics.com Peter Williams p.williams@uk.ac.ucl.cs 3