[Note to list subscribers: this version is slightly revised from the 4 April draft, in response to posted comments re the Kerberos GSS mechanism discussion.] Minutes, Common Authentication Technology (CAT) WG, Adelaide IETF Reported by John Linn, RSA Laboratories. Thanks to Cliff Neuman and Ken Hornstein for providing their notes and slides, which were used as inputs to preparation of these minutes. GENERAL AND ADMINISTRATIVE DISCUSSION The CAT WG met for one session in Adelaide, with 88 attendees. John Linn opened the meeting with a general status overview, handing the floor to Jeff Schiller (MIT, Security AD) to present an organizational update. Jeff noted that the IETF today generally prefers tightly task-focused groups and that CAT's charter has been iteratively evolving for some time. He further observed that CAT's original focus was on the common GSS-API interface, rather than specifically on the Kerberos technology to which currently active standards-track CAT Internet-Drafts relate. It has been decided that the general CAT WG will go dormant, but with the mailing list to remain available as a forum to discuss progression of existing non-Kerberos CAT documents. Kerberos documents are to be transitioned to a new Kerberos WG, with the intent that its charter be established before the next (Pittsburgh) IETF and that an initial WG meeting without prior BOF session will take place there. Doug Engert (Argonne) has agreed to chair the group and will be doing so. Kerberos-related drafts that are ready for imminent Last-Call, in advance of establishment of the Kerberos WG, can still go to CAT. KERBEROS-REVISIONS AND PKINIT Cliff Neuman (ISI) presented a status summary on Kerberos-Revisions. A new Internet-Draft version was recently issued. Significant remaining issues include: decision on the mandatory variants of 3DES, ticket extensions, and integration of the referrals draft. Additionally, some smaller and editorial issues must also be addressed, and a change summary relative to RFC-1510 must be prepared. Updates since the last revision include integrated 3DES options, new registered types, and various edits, some of which require discussion. Cliff reported that the current 3DES description integrates all options in a single parameterized discussion, but that it references currently expired drafts and material must therefore be adapted from them. List discussion is needed to resolve whether or not to use the key derivation variant; Cliff reported that Microsoft and CyberSafe have tentatively agreed to accept key derivation, though that some skepticism was observed about its value. Cliff also reported that some coordination is pending with Microsoft on PAC usage. List discussion is required on the ticket extensions field, included in the current draft; Cliff intends to send a message to the list initiating debate on the benefits and drawbacks of its retention. Further discussion topics had been introduced on the list: whether policies on adding additional addresses to tickets should be specified, clarification on case sensitivity in names. During the Adelaide IETF week, Cliff's intent was to perform initial wordsmithing and to initiate the 3DES and ticket extensions discussions. He also anticipates referrals text pending from John Brezak (Microsoft), which will require further list discussion. Once at least the two major issues are resolved, WG Last-Call will be requested on Kerberos-Revisions and PKINIT; given the size of Kerberos-Revisions, John Linn suggested that an extended WG Last-Call period would be appropriate. PKINIT is believed to have come to consensus among active participants, and to be ready for a parallel last call with Kerberos-Revisions. Recent changes include: name encoding, application of name constraints, and SignedData and EnvelopedData structure definitions. Regarding name encoding, the section on translation between X.500 names and Kerberos structures has been changed and expanded to specify the translation between general string and UTF8. A new structure corresponding to Kerberos PrincipalName, but with general string replaced by UTF8String, was defined to enable the use of UTF8 in the additional name field when Kerberos principal names are embedded in certificates. Rules were added for checking of a Kerberos PrincipalName against certificate chains which contain name constraints. The SignedData and EnvelopedData structure explanations have been reformatted and slightly edited for clarity. The old PKCS#7 data OID has been replaced by a pkdata OID under the Kerberos-PKINIT arc. KERBEROS DNS-LOCATE Ken Hornstein (NRL) presented discussion re the Kerberos DNS-Locate document (-02 draft). He reported that dns-locate is currently implemented in two different independent Kerberos implementations, is widely used, and appears to work well in simple usage. There had been significant contention on the CAT list about security concerns with host-to-realm mapping. Ken observed that the vulnerability exists only between realms which share a cross-realm relationship, and that it can exist in many common Kerberos implementations even without the use of DNS-based host-realm mapping; use of a different naming approach would be required to resolve this. Ken believes that the facility is useful and should remain within the draft as a feature that could be activated selectively. Following the discussion which has taken place, he also believes that more clarification is needed somewhere about the relation between Kerberos and DNS, and may consider a separate informational document for this purpose. GAA Cliff Neuman presented an update on the GAA drafts. It was noted that any request for progression of these documents would target Experimental status and would follow integration results with several applications. Recent GAA work has focused on implementation and changes needed for integration with particular applications. The new drafts define new generic conditions, which generate audit records when policies containing those conditions are encountered. Also, optional parameters are now translated to appropriate types by condition evaluation functions rather than being described by the separate gaa_options structure. The new C bindings have focused on a more "object-oriented" approach, inspired by the style of Hudson and Young's SSLeay, and with three classes of functions. The draft now uses a generic gaa_stack object (with implementation-specific structure) for representation of ordered lists rather than using a separate ordered list for each type of data. OTHER TOPICS Tom Yu (MIT) asked about futures for the Kerberos GSS mechanism. He stated that Microsoft and others are interested in squeezing 3DES into RFC-1964 rather than doing a general cryptosystem-independent scheme, and asked the attendees whether they wished to voice any objections to hacking into RFC-1964 rather than pursuing a wholly new approach. (Subsequent discussion observed that work on a near-term 3DES approach with RFC-1964 need not be mutually exclusive with parallel effort on a new approach.) It was noted that interoperability issues might arise if a single OID were used. Ted Ts'o (VA Linux) would like to see an analysis of what the failure cases and modes would be. Tom plans to circulate a more detailed proposal to the list. A new version of PKCROSS is planned, but is currently blocked pending resolution on the Kerberos-Revisions ticket extensions question. Ted Ts'o asked the meeting about continued interest in specification of a GSS adjunct interface for interactive credential acquisition, such as that which had been documented in his GSS Conversation Interface draft. Approximately three attendees indicated interest. To this point, GSS' scope has excluded asynchronous callbacks to applications and their associated users, partly for reasons of OS independence. Sam Hartman (FundsXpress) observed that SASL is an important client of GSS, and that it already has its own facilities for asynchronous callbacks to applications; given these facts, he considered that it would be inappropriate to define an incompatible facility at the GSS level. Ted indicated that he was not aware of API-level convergence among SASL providers, but others commented that such convergence was progressing. Subject: Minutes, CAT-WG Adelaide meeting Date: Tue, 11 Apr 2000 08:48:03 -0400 From: "Linn, John" To: "'minutes@ietf.org'" CC: "'CAT-WG List'" [Note to list subscribers: this version is slightly revised from the 4 April draft, in response to posted comments re the Kerberos GSS mechanism discussion.] Minutes, Common Authentication Technology (CAT) WG, Adelaide IETF Reported by John Linn, RSA Laboratories. Thanks to Cliff Neuman and Ken Hornstein for providing their notes and slides, which were used as inputs to preparation of these minutes. GENERAL AND ADMINISTRATIVE DISCUSSION The CAT WG met for one session in Adelaide, with 88 attendees. John Linn opened the meeting with a general status overview, handing the floor to Jeff Schiller (MIT, Security AD) to present an organizational update. Jeff noted that the IETF today generally prefers tightly task-focused groups and that CAT's charter has been iteratively evolving for some time. He further observed that CAT's original focus was on the common GSS-API interface, rather than specifically on the Kerberos technology to which currently active standards-track CAT Internet-Drafts relate. It has been decided that the general CAT WG will go dormant, but with the mailing list to remain available as a forum to discuss progression of existing non-Kerberos CAT documents. Kerberos documents are to be transitioned to a new Kerberos WG, with the intent that its charter be established before the next (Pittsburgh) IETF and that an initial WG meeting without prior BOF session will take place there. Doug Engert (Argonne) has agreed to chair the group and will be doing so. Kerberos-related drafts that are ready for imminent Last-Call, in advance of establishment of the Kerberos WG, can still go to CAT. KERBEROS-REVISIONS AND PKINIT Cliff Neuman (ISI) presented a status summary on Kerberos-Revisions. A new Internet-Draft version was recently issued. Significant remaining issues include: decision on the mandatory variants of 3DES, ticket extensions, and integration of the referrals draft. Additionally, some smaller and editorial issues must also be addressed, and a change summary relative to RFC-1510 must be prepared. Updates since the last revision include integrated 3DES options, new registered types, and various edits, some of which require discussion. Cliff reported that the current 3DES description integrates all options in a single parameterized discussion, but that it references currently expired drafts and material must therefore be adapted from them. List discussion is needed to resolve whether or not to use the key derivation variant; Cliff reported that Microsoft and CyberSafe have tentatively agreed to accept key derivation, though that some skepticism was observed about its value. Cliff also reported that some coordination is pending with Microsoft on PAC usage. List discussion is required on the ticket extensions field, included in the current draft; Cliff intends to send a message to the list initiating debate on the benefits and drawbacks of its retention. Further discussion topics had been introduced on the list: whether policies on adding additional addresses to tickets should be specified, clarification on case sensitivity in names. During the Adelaide IETF week, Cliff's intent was to perform initial wordsmithing and to initiate the 3DES and ticket extensions discussions. He also anticipates referrals text pending from John Brezak (Microsoft), which will require further list discussion. Once at least the two major issues are resolved, WG Last-Call will be requested on Kerberos-Revisions and PKINIT; given the size of Kerberos-Revisions, John Linn suggested that an extended WG Last-Call period would be appropriate. PKINIT is believed to have come to consensus among active participants, and to be ready for a parallel last call with Kerberos-Revisions. Recent changes include: name encoding, application of name constraints, and SignedData and EnvelopedData structure definitions. Regarding name encoding, the section on translation between X.500 names and Kerberos structures has been changed and expanded to specify the translation between general string and UTF8. A new structure corresponding to Kerberos PrincipalName, but with general string replaced by UTF8String, was defined to enable the use of UTF8 in the additional name field when Kerberos principal names are embedded in certificates. Rules were added for checking of a Kerberos PrincipalName against certificate chains which contain name constraints. The SignedData and EnvelopedData structure explanations have been reformatted and slightly edited for clarity. The old PKCS#7 data OID has been replaced by a pkdata OID under the Kerberos-PKINIT arc. KERBEROS DNS-LOCATE Ken Hornstein (NRL) presented discussion re the Kerberos DNS-Locate document (-02 draft). He reported that dns-locate is currently implemented in two different independent Kerberos implementations, is widely used, and appears to work well in simple usage. There had been significant contention on the CAT list about security concerns with host-to-realm mapping. Ken observed that the vulnerability exists only between realms which share a cross-realm relationship, and that it can exist in many common Kerberos implementations even without the use of DNS-based host-realm mapping; use of a different naming approach would be required to resolve this. Ken believes that the facility is useful and should remain within the draft as a feature that could be activated selectively. Following the discussion which has taken place, he also believes that more clarification is needed somewhere about the relation between Kerberos and DNS, and may consider a separate informational document for this purpose. GAA Cliff Neuman presented an update on the GAA drafts. It was noted that any request for progression of these documents would target Experimental status and would follow integration results with several applications. Recent GAA work has focused on implementation and changes needed for integration with particular applications. The new drafts define new generic conditions, which generate audit records when policies containing those conditions are encountered. Also, optional parameters are now translated to appropriate types by condition evaluation functions rather than being described by the separate gaa_options structure. The new C bindings have focused on a more "object-oriented" approach, inspired by the style of Hudson and Young's SSLeay, and with three classes of functions. The draft now uses a generic gaa_stack object (with implementation-specific structure) for representation of ordered lists rather than using a separate ordered list for each type of data. OTHER TOPICS Tom Yu (MIT) asked about futures for the Kerberos GSS mechanism. He stated that Microsoft and others are interested in squeezing 3DES into RFC-1964 rather than doing a general cryptosystem-independent scheme, and asked the attendees whether they wished to voice any objections to hacking into RFC-1964 rather than pursuing a wholly new approach. (Subsequent discussion observed that work on a near-term 3DES approach with RFC-1964 need not be mutually exclusive with parallel effort on a new approach.) It was noted that interoperability issues might arise if a single OID were used. Ted Ts'o (VA Linux) would like to see an analysis of what the failure cases and modes would be. Tom plans to circulate a more detailed proposal to the list. A new version of PKCROSS is planned, but is currently blocked pending resolution on the Kerberos-Revisions ticket extensions question. Ted Ts'o asked the meeting about continued interest in specification of a GSS adjunct interface for interactive credential acquisition, such as that which had been documented in his GSS Conversation Interface draft. Approximately three attendees indicated interest. To this point, GSS' scope has excluded asynchronous callbacks to applications and their associated users, partly for reasons of OS independence. Sam Hartman (FundsXpress) observed that SASL is an important client of GSS, and that it already has its own facilities for asynchronous callbacks to applications; given these facts, he considered that it would be inappropriate to define an incompatible facility at the GSS level. Ted indicated that he was not aware of API-level convergence among SASL providers, but others commented that such convergence was progressing.