Subject: FW: Draft minutes for DC CAT session

From: "Linn, John" <[email-masked]>
Date: Wed, 1 Dec 1999 09:02:15 -0500

Attached find the minutes for the CAT-WG session at the DC IETF.  WG list
members: No correction requests were received, so the content of these
minutes is identical to that posted as a draft to the list on 17 November.

--jl

CAT WG Minutes, DC IETF, 8 November 1999

Reported by John Linn (RSA Laboratories). 

SUMMARY

The CAT WG met for one session at the November 1999 IETF, with 82 attendees.
The most extensive discussion was devoted to Java GSS bindings, and
particularly to the question of the GSSManager facility.  GSSManager is to
be changed from a concrete class to an abstract class. A subgroup discussion
is to propose a conclusion to an issue on management methods, after which
point production of a revised draft for WG Last-Call is anticipated.  The
second major topic area was Kerberos documents, including Kerberos-Revisions
(RFC-1510bis), Kerberos PK-INIT, and Kerberos DNS-based server location.
Revisions to these documents are in progress or planned, after which point
WG Last-Calls are anticipated.  Additional topics, briefly discussed,
included a GSS Conversation Function, GSS-Easy mechanism, and a proposal for
a GSS mechanism based on SSL/TLS tokens. 

GSS JAVA BINDINGS

Michael Smith (TIAA-CREF) has been working on a Java GSS service provider
interface (SPI).  He recommends that GSSManager be made an interface, rather
than a concrete class as represented within the current draft.  Further, he
would prefer to remove the limited mechanism management method (setProvider)
which is currently included in the high-level GSS-Java document, instead
deferring this topic to a shim SPI specification. He anticipates two kinds
of JGSS implementations, one shim-based, one monolithic.  Michael cited
several reasons for making GSSManager an interface: if implemented as a
class, benefits of multiple inheritance would be lost; a locally installed
implementation could interfere with other subclassing implementations; and
implementation as a class could provide a possible hook for imposition of
crypto controls.   He commented that a class implementation would have the
effect of causing IETF to include a separate implementation by reference
within an API specification, which appeared anomalous.  He believed that the
problem of locating implementations is relatively easy and can be
accommodated within an interface paradigm; further, he argued that this
problem shouldn't properly be handled within the language binding spec.  

Mayank Upadhyay (Sun) asked how local resource discovery would be
accommodated within an interface model. Use of a system property had been
suggested, but this doesn't work for applets.  Alternately, a GSSFinder
class could be defined and implemented outside the GSS implementation per
se.  Ted Ts'o (VA Linux) hesitated to depend on completion of a shim SPI
specification for management facilities; he considered it critical to find
the default implementation using a quick, easy, and mandatory-to-implement
means, and doesn't think it's bad for GSSManager to be that concrete class.
While it would be possible for this to be defined in a separate document,
this approach would be procedurally inconvenient.  Michael Smith was
hesitant to build in a dependency on the use of providers, and asked whether
a GSSFinder class would need to be provided by a GSS implementer or
elsewhere in the environment.  Paul Leach (Microsoft) asked whether the
current GSSManager class definition contains a mixture of independent
functions that should be decoupled from one another; Mayank thought that
this was not the case, and offered to send follow-up mail to support this
assertion. 

Jack Kabat (ValiCert) summarized the changes in the -03 draft of the JGSS
document, and identified a list of discussion items.  About 5 attendees
indicated active interest in the ongoing discussion.  Updates include the
following: there is now an instantiable GSSManager class (allowing
customization of the manager, and making changes instance-wide rather than
JVM-wide); concrete class wrappers have been removed from GSSName,
GSSCredential, and GSSContext; GSSFactory interface and support details have
been removed and deferred to the SPI specification.  More updates: minor
status treatment in MessageProp, removed dependency on
java.security.Principal (since the Principal interface isn't always
available), general package rename to org.ietf.jgss, and updated samples. 

Mayank led further discussion of the question of GSSManager as concrete
class vs. interface.  He believes that simplicity to users is paramount, and
noted that use of a class provides something well-defined for apps to
reference.  As an alternative to a concrete class, Joe Salowey (WRQ) had
suggested making GSSManager an abstract, well-known class with one static
getInstance.  This would avoid the prospect of a GSSManager implementation
restricting extensibility.  Ted Ts'o observed that use of abstract classes
to override the default implementation might complicate administration;
Mayank pointed out that use of an SPI-supporting implementation would be a
preferable way of accomplishing such overrides.  It was also observed that
use of providers might complicate the extensibility available through use of
an abstract class. The general sense of the room was that, if a class is to
be used for GSSManager, an abstract class is preferable to a concrete class.
Michael Smith indicated that he could accept use of an abstract class rather
than an interface, but reiterated his request that management functions be
removed from the high-level specification. 

Jack Kabat led discussion on the question of allowing applications to pass
and accept object-level representations of tokens.  Jack objected to this
proposal for several reasons: non-portability, complexity of required object
registration scheme, and the observation that (unlike prior GSS), it would
make application protocol logic part of JGSS.  Michael Smith noted that byte
array representations are a special case and would always be supported, with
other supplementary representations optional.  He proposed to add new
methods that would allow applications to determine whether/what
supplementary formats are supported.  The supplementary representations were
intended for use with legacy protocols and for applications that are tied to
particular authentication protocols (e.g., digest); he found them
particularly useful in a servlet environment where, e.g., http knowledge can
reasonably be assumed. Marc Horowitz (Stonecast) observed that it can't
reasonably be assumed that GSS can support applications and protocols which
were not designed for GSS.  In a straw poll, approximately 3 attendees
indicated their support for the supplementary, object-level approach while
approximately 5 followers of Java bindings development wished to exclude the
approach, so consensus for its inclusion was not apparent. 

The final Java topic discussed concerned JGSS provider management methods,
which Michael Smith had requested be removed from the JGSS specification.
Only two methods now remain, and Jack Kabat believes that they're necessary.
While these functions could be accomplished within an application-specific
class, a facility would then be required to locate that class.  It was left
to an ad hoc Java group to discuss the issue further and propose a
resolution to the mailing list, in order that the JGSS specification can
proceed towards WG Last-Call. Ted Ts'o commented that prior agreement had
been reached to defer SPI issues for later consideration, but Paul Leach
reiterated a prior concern that SPI-related concerns be adequately addressed
within the JGSS document.  Mayank indicated his belief that the SPI-JGSS
dependencies have been suitably constrained.  

KERBEROS TOPICS

Cliff Neuman (ISI) led discussion on Kerberos topics, beginning with a
summary of the relationships among the large number of currently posted
drafts related to Kerberos.  He considered DNS-Locate and Set Passwd drafts
to be independent of Kerberos-Revisions (1510bis) and free to proceed; they
will be cited in 1510bis if they have advanced at the time of 1510bis'
advancement, but no dependencies link in either direction between 1510bis
and these documents.  He believes that Extra TGT should remain a separate
spec, not to be included in 1510bis although extending the basic Kerberos
protocol.  He described IAKERB as a separate spec, extending basic Kerberos
protocols and dependent on a minor loosening in the base spec, which may be
specified either in 1510bis or IAKERB; as a result, IAKERB and 1510bis
should proceed in parallel. PKINIT depends on and extends 1510bis, and
should move along with 1510bis.  PKCROSS and PKTAPP have been on hold
pending PKINIT, on which they depend, and will not proceed before PKINIT is
finalized. 

Regarding PKINIT, confirmation was requested that the comments made by John
Linn, Denis Pinkas, and Paul Leach against an earlier draft have been
suitably addressed.  The final known issue concerns transited field
processing, as has been discussed on the WG list.  Cliff strongly believes
that this data needs to be encoded, but Microsoft had noted interoperability
problems with the proposed approach and old Kerberos realms.  It would be
useful to include clarifying examples in the text. Cliff is to circulate
proposed changes among the other draft authors, and then send those proposed
changes to the WG list.  Cliff reported that one of his students has a
reference implementation of the current PKINIT draft, which will be fed to
MIT.

Regarding 1510bis, Cliff reported that a recent focus of activity has been
on 3DES and SHA1 variants. Cliff proposed that two variants be defined, with
and without key derivation.  Ted Ts'o believed that this would be an
unfortunate result.  Cliff's preference is that both variants be specified,
with a subsequent group vote to determine which will be specified as
mandatory.  Some backward compatibility questions exist relative to existing
code, which was shipped before definitions became stable.  The last
Internet-Draft version was issued before the Oslo meeting; revisions have
been made to the live working document, which was not yet finalized as of
the WG session, but final changes were to be integrated during the IETF
week.  

David Miller (CyberSafe) plans to submit a draft concerning use of 3DES in
Kerberos V5 and GSS after the meeting, which will be co-authored by
CyberSafe and Microsoft. This draft will address both Kerberos V5 and GSS
layers, in the interests of achieving interoperable 3DES.   Tentatively, it
is to propose three 3DES Encryption Types: 2 mandatory SHA types and 1
optional MD5 type, but the set to be specified may be revisited on the
mailing list.  GSS issues were identified: new flags are desired to reflect
crypto strength at per-context level; new QOPs are to be defined; token
formats need to be adjusted to reconcile limitations of the checksum
algorithm structure as defined in RFC-1964.  It was noted that Tom Yu (MIT)
had been working on a successor to RFC-1964, which would be represented with
a new OID, and may be undertaking a new revision of this document. 

KRB-DNS-SRV  (Jeffrey Altman (Columbia University)): About 10-15 attendees
indicated familiarity with this activity, and all recommend advancing on
standards track.   Jeff considers its greatest value to be avoidance of the
need for preconfiguration of data in clients. The most recent draft adds a
_kpasswd name.  The approach is currently supported in Kerberos
implementations including MIT, Heimdal, and Windows 2000 RC2.  A
recently-arising issue: should a workaround for KDB propagation delays be
included in the draft?  Sense of room: yes.  Following integration of this
change, the draft may be ready for WG Last-Call. 

OTHER TOPICS

Cliff Neuman reported that no recent updates have been made to the GAA
specification.  Currently-ongoing GAA activities include Globus integration,
policies for a group signature authority, and XML policy representation. 

Denis Pinkas (Bull) presented a brief update on the GSS-Easy mechanism
proposal, currently represented in draft-ietf-cat-gsseasy-01. The primary
change in this version makes it unnecessary for the server to know a shared
PassPhrase with the client.  A subsequent change is anticipated to prevent
server-side dictionary attacks. 

Ted Ts'o (VA Linux) led brief discussion on the GSS Conversation Function
draft, which was issued a few weeks before the meeting.  He observes that
many prospective mechanisms (e.g., IAKERB if realized at the GSS level,
GSS-Easy) need user input at context establishment.  The draft proposes a
variant of GSS_acquire_cred which takes a pointer to a callback function.
The approach is similar to Pluggable Authentication Modules (PAM), is
suitable for TTY or GUI interfaces, and doesn't currently deal with
internationalization issues.  Iterated, multi-step user interaction rituals
can be supported.   Approximately 5 attendees indicated that they had read
the draft, and approximately 10 indicated interest in pursuing work in this
area as a standards track item, with none indicating opposition. 

Frank Siebenlist (Dascom) led brief discussion of a GSS-SSL mechanism
concept.  Preparation of a draft is in progress.  The goal is to adapt
SSL/TLS tokens and runtime support to provide a transport-independent,
GSS-based public-key mechanism.  Frank does not perceive SPKM as having
broad support, and therefore wishes to leverage the broad SSL/TLS base.  It
was reported that Argonne Labs (Globus) has a reference implementation,
based on SSLeay and due to Doug Engert and Steve Tuecke, and that similar
functionality was implemented by Microsoft within Windows 2000. Paul Leach
confirmed that Microsoft supports SSL under its GSS variant (SSPI), but
specifications therefor have not been available and interoperability with
the Argonne implementation hasn't been tested.  At a high level, the SSL/TLS
handshake corresponds to GSS's Init and Accept sec context calls, and
SSL/TLS application data to GSS's Wrap and Unwrap calls.   At lower levels,
issues arise: SSL/TLS framing is arbitrary, while a GSS token corresponds to
a delimited application message; token format issues also need to be
considered.  SSL/TLS doesn't have GSS naming constructs, but Frank doesn't
consider this area a major problem.  Big misfits between GSS and SSL/TLS:
SSL/TLS can mix control frames with application data, GSS doesn't support
session resumption.  Frank's proposed next steps were as follows:
standardize through IETF, seek buy-in from SSL vendors and implementers,
contribute Argonne implementation to OpenSSL, solicit comments.  Progression
of the LIPKEY mechanism to WG Last-Call is pending on a revision to the
document, and possibly also on prototyping work. 

Approximately 25 attendees indicated that they would likely attend a CAT
session if held at the Adelaide IETF in March 2000. 

==========================================================================
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]