Subject: Minutes, CAT-WG Adelaide meeting

From: "Linn, John" <[email-masked]>
Date: Tue, 11 Apr 2000 08:48:03 -0400

[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.  

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]