[CAT list members: these minutes match the draft set as sent to the list on
24 March, with an additional comment added in the summary of the
low-infrastructure minutes straw poll to note (as discussed in the session)
that it was OK for participants to support multiple options.]

Minutes, Common Authentication Technology (CAT) WG, Minneapolis IETF,
reported by John Linn (RSA Laboratories).

The CAT-WG met for one 2.25 hour session at the Minneapolis IETF, with 114
attendees. Regarding document actions, John Linn reported that the GSS-V2
and C bindings drafts have been forwarded to the IESG, with a request that
they be considered for Proposed Standard status.  Major discussion topics at
the meeting included Kerberos Public-Key Initial Authentication (PKINIT),
other Kerberos drafts, GSS Java bindings, and GSS Low-Infrastructure
mechanisms. 

Kerberos Public-Key Initial Authentication (PKINIT):

Following introductory comments by Brian Tung (ISI), Matt Hur (CyberSafe)
led discussion of the Kerberos-PKINIT document. Current draft changes and
pending issues were reviewed and discussed. Among other points, a follow-up
draft will adopt use of CMS constructs to define the request from client to
KDC as well as the KDC's response, and means for accommodating key usage
fields in certificates will be considered.

Other PKINIT issues were also discussed. John Brezak (Microsoft) had
commented that PKINIT required support for too many options, but candidate
simplifications were not indicated. Brian Tung agreed to obtain
clarification, and to inform the list. As currently specified, PKINIT error
messages collide with the space reserved for user-user authentication codes;
this will be addressed in the Kerberos-Revisions document.  There's an
ambiguity as to which error message to use if a server/KDC name in the
PKAuthenticator is wrong.  PKINIT clients must specify supported encryption
types to the KDC. It was suggested that the Kerberos enctype definition
could be changed (from its current SEQUENCE OF INTEGER), but was noted that
viable options exist which don't need changes to Kerberos-Revisions, just to
Assigned Numbers.  The working conclusion was to map the PKINIT-supported
encryption types into Kerberos enctype values without restructuring their
format.

The following changes had been incorporated in the most recent PKINIT draft:
Removed digital signature and private key storage options, modified server
response definition to incorporate CMS by reference, and added various
clarifications.  Additional planned changes include removal of references to
PKCS#6, changing "Certificate" type to "PKInitCertificate", and alignment of
wording and client-KDC request structure with CMS.  Sam Hartman
(FundsXpress) proposed that the KDC-client reply should have a CMS
EnvelopedData containing a SignedData, and plans to contribute specific text
for this proposal; as a working position, use of this approach was accepted.
A NULL method-type is to be added for the method-data structure within a
PKINIT error message, and the KDC is to return KRB_APP_ERR_MODIFIED when a
signature does not verify. 

Denis Pinkas (Bull) commented that PKINIT's introduction needs modification
to reflect Diffie-Hellman as mandatory and RSA as optional, and suggested
also including a facility for signing a users' key independently of a
certificate. He also indicated concern about the use of a single certificate
for signing and encrypting, wanting separate certificates to be used in
order to allow segregation by key usage.  There was consensus among
attendees to allow segregated support, but a specific proposal to the list
is required in order to define the approach. 

Kerberos-Revisions and related drafts:

Cliff Neuman (ISI) led discussion of various changes and issues regarding
Kerberos-Revisions (RFC-1510 successor).  He indicated his intent to send a
summary of outstanding issues and current proposals to the WG list during
the IETF week as a basis for resolution, confirmation via straw poll, and
preparation of a follow-up draft, in the hope that the follow-up draft could
be suitable for WG Last-Call. He reported that revisions were in progress on
integration of enctype specifications, numbering of error messages,
tightening definitions for optional and default values, on direction bits if
addresses are omitted, and on appropriate processing for authorization data
elements which are not understood.  Identified open issues: how to deal with
added fields in KRB-ERROR, ticket extensions, optional KRB-CRED fields,
encryption types, and the general approach for interoperability in the face
of new protocol elements. 

The concern with encryption types is that CMS usage requires the KDC to know
which algorithms a given client supports, within a potentially extensible
set.  Cliff proposed that algorithms be identified for this version within
the supported e-types of the KDC-REQ message rather than in a new pa-data
field; these types are integers (not OIDs), so Kerberos values must be
registered for algorithms which are to be used.  Regarding support for
additional or changed fields, it appeared desirable to identify all items
needing change at one time, and to require compliant implementations (as of
a certain date) to process new fields appropriately.  New fields would be
used only after a transition period, or with knowledge that the peer can
support them.  Ted Ts'o (MIT) argued that any new support requirements
should become active as of the specification's effective date, rather than
at a later point; Sam Hartman pointed out that it might be appropriate to
associate a tier of support requirements with support for new
cryptoalgorithms.  

Ted Ts'o recommended that ciphersuite constructs be incorporated, believing
that their initial omission from Kerberos has had unfortunate results. This
also affects the Kerberos GSS mechanism-2 document, and Tom Yu (MIT) is to
frame the issue within subsequent Kerberos-Revisions discussion.  Marc
Horowitz (Stonecast) solicited comments on his recent draft on
Diffie-Hellman usage in Kerberos. 

GAA-API: 

Cliff Neuman presented brief status information on the GAA-API activity;
revised drafts are planned for the Oslo IETF reflecting ongoing experience
in application of GAA constructs. ISI has been working with Xerox on
GAA-CORBA integration, and with the GLOBUS project, and seeks more groups to
work with. Work on a reference implementation has been pursued, including
integration with X.500/X.509 and SSL. Information is available at
http://gost.isi.edu/info/gaaapi, which will be updated in the next few
weeks.  Marc Horowitz (Stonecast) asked whether there was any relation
between GAA and the IETF General Area's AAA and Policy groups.  There was no
formal conclusion, but Sam Hartman noted that he intends to act as an
informal liaison to AAA's authentication group.

GSS Java Bindings:

Extended discussion took place on the GSS Java bindings, led by Mayank
Upadhyay (Sun).  The central question at issue was use of concrete classes
vs. Java interfaces.  Interfaces provide greatest power and flexibility, but
their use was considered more complex and less intuitive to some Java
programmers.  Since GSS is already considered complex in some circles, it
was considered undesirable to mandate more additional complexity than
necessary for use via JGSS.  Support for usage of multiple mechanisms within
a single invocation of an application program was considered to be an
important goal (e.g., to support applications like NFS).  The conclusion, to
be reflected in a revised draft, was to incorporate a factory approach with
Java interfaces for flexibility, but to provide a simple-to-use shim that
would instantiate classes corresponding to those interfaces.  By analogy, it
was noted that factories and interfaces are also used within JCAPI. Using
the factory approach, a given application can access multiple mechanisms
within one or more coresident JGSS implementations.  Alternately, an
application can choose to bind to a single JGSS implementation by using
CLASSPATH rather than factories.  

A separately defined service provider (SPI) layer, whose definition may be
pursued later, would enable individually developed SPI provider
implementations to be accessed through a single higher-layer JGSS
implementation. While such an SPI would be similar to JGSS, it was
recognized that it wouldn't be identical, considering, e.g., the fact that
credentials can be multi-mechanism objects. Consistent with a goal expressed
by Jeff Schiller (MIT), progress on a higher-level JGSS specification is not
to depend on an SPI definition. An SPI approach would avoid the need for
applications consuming services provided by multiple lower-layer JGSS
implementations to track the correspondence among mechanisms, their
providers, and associated objects, thereby simplifying application access to
a dynamically-variable set of available mechanisms.  

A specific issue arises for use of applets.  An applet developer may wish to
access a custom JGSS implementation via standard ("org.ietf.JGSS") class
names, but an existing JGSS implementation on the applet's platform would be
accessed instead.  As an interim approach to this problem, Mayank proposed
that the applet could invoke the custom implementation via another name,
which the applet's code would import. Eventually, a custom implementation
could be layered under SPI, downloaded, and accessed through the browser
platform's SPI-layered JGSS. 

Mayank and Jack Kabat (ValiCert) will continue working on the base JGSS
document, but will not also be working on an SPI definition.  It was noted
that Sun had donated C language GSS-SPI code to MIT, but Ted Ts'o reported
that he found the code unreliable and hasn't been working actively with it.
It's included in the Kerberos V5 distribution but is currently disabled;
absent inclusion of another mechanism besides Kerberos, the motivation to
debug its use was limited.  The C GSS-SPI is also included in Solaris,
enabling selection between Kerberos and a dummy mechanism. 

GSS Low-Infrastructure Mechanisms:

Extended discussion took place on the topic of low-infrastructure GSS
mechanisms. Concern was expressed about possible duplication with SASL-level
mechanisms, and John Myers (Netscape) is to send a draft concerning GSS
integration under SASL for consideration by the CAT-WG. It appears that
different communities and types of applications wish to consume services via
GSS or via SASL, even though underlying mechanisms may overlap.  It was
recognized that more communication is needed between SASL and GSS
proponents, and some SASL concerns (e.g., lack of defined service interface)
were briefly cited.  Within the session, two specific GSS mechanism
proposals, GSS-Easy and LIPKEY, were discussed. 

Denis Pinkas (Bull) led discussion about the GSS-Easy proposal, which about
10 attendees indicated that they had read. The GSS-Easy mechanism requires
no public-key infrastructure, and performs passphrase-derived exchanges
using one-way functions (OWFs); a Passkey is derived through N iterations of
an OWF, where a large N provides bandwidth limiting against guessing
attacks. A passphrase change facility is included.  Unilateral and mutual
authentication are supported. Loosely synchronized clocks are assumed
between initiator and target. Per the draft, GSS-Easy's proposed message
protection approach is OWF-based rather than being layered on existing
symmetric algorithms. This approach was controversial: while OWF-based
encryption may comprise a valuable topic for research, the sense of
discussion opposed pursuing it at this time as a basis for standardization.
Sam Hartman indicated concern about dependencies on hash algorithm
properties, observing in particular that it wasn't clear whether SHA had
been analyzed for correct properties if used within an encryption function.
Paul Leach (Microsoft) suggested that at least 2 ciphersuites be
incorporated.  Per list discussion, Denis plans to remove ASN.1 framing
around the confounder.  More generally, use of direct octet encoding was
preferred to ASN.1 representation (by an approximately 2:1 margin), but most
proponents of direct encoding would not reject an approach on the basis of
ASN usage. 

Mike Eisler (of Sun's NFS group) led discussion on the Low-Infrastructure
Public-Key (LIPKEY) proposal. About 5 attendees indicated that they had read
the draft. The LIPKEY mechanism adapts SPKM's SPKM-1 unilateral mode for an
environment where servers are registered with public-key certificates, but
where client users authenticate with passwords.  Mike cited several LIPKEY
priorities. Familiarity breeds acceptance (people will adopt what they
understand and are used to). Server authentication in Internet environments
was considered more important than client authentication. Reduced client
impact is important since there are more clients than servers. Almost all
OSs have some form of native password support, and this can and should be
leveraged without user reregistration.  LIPKEY's form is like TLS with
passwords, so uses a level of infrastructure that has achieved a status of
common practice. As a result, it may be more easily grasped and accepted
than Kerberos, though can be suitable for application protocols (e.g.,
UDP-based applications, RPC) that cannot or will not use TLS.  LIPKEY's
usage of the SPKM context establishment request varies from RFC-2025, since
certificate acquisition is assumed to take place in-band; it may be
appropriate to describe this variant usage as a new SPKM-3 mode. Mike noted
his neutrality about the general issue of encoding conventions, but does not
propose to redefine SPKM's existing ASN.1 structures to use different
encoding.  It was noted that LIPKEY usage requires that a user's password be
obtained and accessible via a user's credentials. 

At the end of the session, a straw poll of attendees was taken to determine
interest in pursuing standardization of various low-infrastructure GSS-API
alternatives.  Attendees were allowed to express support for multiple
options. Greatest interest was apparent in LIPKEY (19 attendees recorded),
followed by GSS-Easy (12 attendees), and various forms of digest
authentication (10 attendees).  One attendee indicated interest in pursuing
EKE/SPEKE/SRP methods.  No attendees indicated opposition to pursuing
standardization of one or more low-infrastructure mechanism candidates
within the GSS framework.