Common Authentication Technology (CAT) WG minutes, Chicago IETF, reported by John Linn (RSA Laboratories). SUMMARY The CAT WG met for one session at the Chicago IETF, with approximately 130 attendees. The SNEGO document, which has been through IETF Last-Call, will be issued for ballot within the IESG shortly. Final alignment changes to RFC2078bis and the GSS-V2 C bindings were agreed, and versions of this pair of documents are to be submitted to the IESG following the meeting to be considered for advancement to Proposed Standards. The Kerberos PKINIT and PKCROSS drafts were discussed. A revised version of PKINIT is to be issued after the meeting reflecting evaluation of a patent issue concerning KDC private key storage and (consistent with the Munich Doctrine) removal of the specified requirement for mandatory (vs. optional) RSA support. Following these changes, the PKINIT draft is to be considered for WG Last-Call. A revised version of the Kerberos-Revisions document is expected soon after the meeting week for working group review, reflecting results of a focus group discussion scheduled after the CAT session. The recently reactivated Kerberos-Passwords draft was presented briefly. Two prospective new work areas were presented: significant attendee interest appeared in a proposal on GSS Java bindings and moderate interest appeared in authorization interface proposals (GAA); ongoing review and discussion of these documents was solicited on the WG mailing list. GENERAL AND ADMINISTRATIVE DISCUSSION According to information available at the meeting, the SNEGO draft is to be balloted within the IESG shortly. The IDUP draft was in discussion within the IESG, with no status to be reported. The current WG mailing list administrators at Stanford University were thanked for their efforts and support; list-targeted traffic can now be addressed directly to ietf-cat-wg@lists.stanford.edu with Majordomo list management facilities accessible at ietf-cat-wg-request@lists.stanford.edu. (The existing addresses at mit.edu now autoforward to these addresses.) RFC2078BIS AND C BINDINGS John Linn led brief discussion on these documents (which have already been through WG Last-Calls), in advance of their planned submission to the IESG. Two specific changes, resulting from alignment review between the documents, were agreed. It was accepted (despite a recognized backward incompatibility, which will be documented) that integ_req_flag and conf_req_flag inputs to GSS_Init_sec_context() will operate as currently specified in RFC2078bis. Per-message tokens are not to be emitted along with an error major_status value. Security considerations will be added to the documents, including: the fact that no security is provided by GSS itself rather than the underlying mechanism, that applications must check status indicators to be cognizant of what security services are being provided, and concerning the security implications of context transfer. A revised pair of RFC2078bis and C bindings documents, reflecting these edits, is to be prepared and submitted to the IESG following the meeting. KERBEROS-REVISIONS UPDATE Cliff Neuman (ISI) summarized status of the Kerberos-Revisions (RFC1510bis) draft, indicating a desire to clean up final topics during the meeting week. An informal session was scheduled later during the week for this purpose, with issues to include the following: - ticket extensions and how they should be included (point: whether old implementations would drop them or treat them incompatibly or inappropriately), - authorization data for required ticket extensions - triple-DES string-to-key transform to achieve MIT compatibility - possible mandated support for TCP transport - PKINIT-driven issue re mapping of X.509 names to principals - name referrals (topic of a draft authored by Mike Swift). Approximately 10 WG attendees indicated interest in attending this informal session, and Cliff is to circulate notes from that discussion to the WG mailing list. KERBEROS-PASSWORDS Ken Hornstein (NRL) presented a brief discussion on the kerberos-passwords draft ("Integrating Single-Use Authentication Mechanisms with Kerberos"), which defines means for using challenge-response and authenticator token technologies with Kerberos preauthentication. Ken had recently revised and reissued this document, which was originally co-authored by Cliff Neuman, Glen Zorn, and Jonathan Trostle. Ken observed that there are several deployed realms with significant user sets making use of this protocol. Approximately 14 attendees indicated interest in progressing the document. Marc Horowitz (Stonecast) pointed out that the currently-specified checksumming procedure for PA-SAM-CHALLENGE is anomalous, as its coverage is unclear and its method implies violation of ASN.1 conventions. It was proposed that a new ASN.1 type be defined in order to make checksum computation more straightforward. PKINIT AND PKCROSS Brian Tung (ISI) led discussion on the Kerberos PKINIT and PKCROSS drafts. New aspects in PKINIT include: - PKCS-7/CMS have been copied in by value, with appropriate algorithm identifiers added - servers now see the same name for both PKINIT and non-PKINIT clients - added text on key requirements. Issues to resolve: - patent issue on the optional KDC private key storage facility; reportedly, Charlie Kaufman (Iris) is to attempt to identify a Compaq contact who would be able to address intellectual property concerns regarding the relevant patent, originally issued to Digital Equipment Corporation - possibly mandating support for signature-only users (intent is already to make it mandatory for PKINIT KDCs). Denis Pinkas (Bull) noted that signature-only usage is important to contemplated DCE usage of PKINIT in OpenGroup. - Password changing The removal of a mandatory requirement for RSA support, for conformance with the Munich Doctrine, was also discussed. It was noted that existing implementations have been RSA-based. Brian proposed that Diffie-Hellman be made mandatory, RSA optional; this proposal was carried unanimously within a straw poll of about 10 attendees. Frank Siebenlist (Dascom) noted that he was working on an X/Open (Open Group) activity related to PKINIT, needed access to data on ongoing revision plans, and was concerned about the limited amount of PKINIT discussion on the public WG mailing list. Denis Pinkas noted that Open Group discussion was scheduled to progress through 15 September, so it would be undesirable for any WG Last-Call on PKINIT to close before that point. Following resolution on the identified patent issue, Brian proposes to submit a revised PKINIT draft, adding mandatory Diffie-Hellman support, with the result to be targeted for a working group Last-Call. PKCROSS is dependent on PKINIT, so cannot advance before it. The most recent PKCROSS revision added clarifying text about ASN.1 parsers and ticket extensions. PROPOSED NEW WORK: GSS-API JAVA BINDINGS Jack Kabat (Sun) led discussion on a recently submitted draft for GSS-API Java bindings. Its objectives include satisfying functionality defined in RFC-2078 and 2078bis, providing Java orientation, and allowing easier usage within a Java environment. Defined classes include GSSCredential, GSSContext (encapsulates context management), GSSName (encapsulates name representations), Oid, GSSManager (general class, no constructors), GSSException, and other utility classes. Initiator-side and acceptor-side code examples were shown. Jack noted the following areas in which the Java draft deviates from RFC-2078: error handling is accommodated via GSSExceptions; memory management relies on garbage collection; calling conventions differ; java.io stream classes are supported. In defining Java bindings for GSS, he encountered the following challenges: adapting functional API into an object-oriented model, hiding complexity, and integration with existing Java security classes (observation: most Java classes assume certificate-based). Ted Ts'o (MIT) commented that it would be interesting to explore RMI integration. Sam Hartman (FundsXpress) observed that it would be nice to have a shim between a C GSS implementation and exporting the Java API, but was concerned about possible conflicts with OID representations. Bob Morgan (Stanford) stated that the Open Group is working on a Kerberos V5 implementation in Java, which might merit investigation. About 18 attendees indicated interest in progressing this draft within the CAT WG, if this can be accommodated within the WG charter. Further review and comment on the draft was solicited. PROPOSED NEW WORK: AUTHORIZATION INTERFACE Tatyana Ryutov (ISI) led discussion on two documents related to authorization services and interfaces. The work was motivated by the following goals: a need for fine-grained AC to resources, integrating local and distributed models, user and domain-level policies, support for various authorization models and authentication policies, and of facilitating authorization decisions. In the proposed approach, local policies are expressed via ACLs, and distributed policies via credentials. Optional conditions fields can be added to both ACLs and credentials. Once obtained, credentials (which may be based on GSS or other forms of authentication) are placed into a GAA security context. The Check_authorization call returns one of "authorized", "not authorized", or "more info needed". Several principal types are defined: user, group, host, application, and anybody. A GAA context is composed of credentials and per-connection information reflecting attributes of the would-be accessor. Several generic conditions are proposed, some of which occur only in credentials rather than ACLs; review and comment was particularly solicited on the condition constructs. ISI has implemented a GAA prototype based on Kerberos. A discussion list was announced specifically for these documents: g3api@isi.edu; further information is available on url http://gost.isi.edu/info/gaa_api.html. Proposed areas for future work include refinements to the evaluation facility. Group discussion on GAA followed. Marc Horowitz didn't see that GAA can support a distributed authorization server model, where ACLs don't reside at the application. Cliff Neuman responded that some models of this nature could be supported, invisibly to the caller; alternatively, a client could request a particular set of operations and corresponding credentials could be forwarded. Cliff indicated a belief that, in any case, standardizing ACL formats would be valuable. John Wray (Iris) asked whether and how container ACLs could be supported. Another question: Has work been done to layer over existing ACLs (e.g., POSIX, NT), as this would affect the practical value of GAA? Mary Ellen Zurko (Iris) asked whether multi-personal control was supported; Cliff responded that this support was possible. About 8 attendees endorsed progressing GAA within the CAT group, if this can be accommodated within the WG charter; discussion was encouraged on the WG mailing list. Cliff observed that there was a significant relationship between GSS and GAA security contexts. Several attendees commented that a number of other WGs and BOFs were considering ACLs and authorization, including (as examples) webdav, LDAP extensions, and a trust management BOF taking place later in the meeting week. OTHER TOPICS Richard Ward (Microsoft) noted that Kerberos tickets are becoming increasingly larger as more elements are carried, and larger, and that some protocols have fixed limits. He posed the prospect that token reassembly might be considered below the GSS interface. Ted Ts'o and John Wray opposed this suggestion, given compatibility and protocol layering concerns. Cliff Neuman noted that GAA has upcall functions to obtain information incrementally as needed, but this was recognized as a separate and longer term consideration. Bob Morgan observed that the SASL framework is being incorporated in a number of protocols, and that SASL allows GSS. Ambiguities had been observed about what service principal names are to be used; the SASL recommendation is that names of the host-based service form be used. John Linn recalled discussion with Chris Newman some months prior, which had led to tightened specification of host-based service name usage in rfc2078bis. Ted Ts'o observed that this handles some cases, but not those which are truly application-specific.