CURRENT_MEETING_REPORT_

Reported by John Linn/OpenVision and Sam Sjogren/TGV

Minutes of the Common Authentication Technology Working Group (CAT)


Brief Summary

The status of ongoing GSS-API and application development and testing
was reviewed:  there are now two independent Kerberos V5 GSS-API
implementations, and minor alignments to match ``The Kerberos Version 5
GSS-API Mechanism'' (draft-ietf-cat-kerb5gss-00.txt) are expected to
enable verified interoperability.  Various demonstration applications,
rlogin, and a security layer under Sun RPC have been implemented with
GSS-API; we need to proliferate one or more of these applications,
and/or GSS-API-based FTP security, in order to validate interoperability
and in preparation for advancing RFCs 1508-1510 to Draft Standard
status.  Steve Crocker suggested that draft-ietf-cat-kerb5gss-00.txt
should reach Proposed Standard level and be considered for advancement
along with RFCs 1508-1510, but that the application(s) used to exercise
GSS-API functions would not also be required to be at Proposed Standard
level.  John Linn reported on the X/Open preliminary specification
containing the technical content of RFCs 1508 and 1509.

Sam Sjogren led FTP discussions.  Results gained from the FTP Security
virtual bakeoff in March were limited, and Sam solicited more
implementations for a follow-up event in June; several individuals
responded.  Steve Lunt's Kerberos V4 FTP security implementation at
Bellcore has been ported to several platforms and is available by
anonymous FTP. The group believes that the FTP Security Internet-Draft
is ready for advancement to Proposed Standard.

Several GSS-API technical topics were discussed as inputs to future
document revisions, including:  continuation facility for protection of
large messages (proposals being discussed by e-mail), incremental
building of credentials for multiple mechanisms (tabled for
consideration as part of broader multi-mechanism support issues),
confirmed context close facility (not adopted), features for efficient
protection of character-at-a-time protocols (modelable as QOP), ability
to operate in a non-blocking fashion (considered OS-specific, possibly a
candidate for different environment bindings), and a number of more
detailed points.


Status of Public-Key Activities

Steve Crocker recalled the fact that a public-key GSS-API mechanism had
once been under development, and that work to integrate Kerberos and
public-key technologies into a common mechanism had once been underway,
and inquired as to whether there was any recent status in these areas.
No recent development is known, although a comprehensive design for a
public-key mechanism remains available in (Experimental) RFC 1507.  It
was reported that work on development of a V6 Kerberos, incorporating
public-key cryptography, was underway, but no detailed report was
available.


Implementation Status Report

Two Kerberos V5 GSS-API implementations now exist, one developed at
Digital and the other at OpenVision; the latter implementation's GSS-API
code is also incorporated in MIT Kerberos V5 Beta 3.  Internet-Draft
draft-ietf-cat-kerb5gss-00.txt defines the token formats needed for
interoperability; minor changes to the OV code will be made to align
with the specification, after which interoperability will be verified.
Trial sample applications (e.g., a secured echo function) have been
written; further productive applications (e.g., FTP security over
GSS-API) need to be developed.  It was also reported that IBM has an
implementation of GSS-API available as a product and built atop
KryptoKnight technology.  Late in the meeting, it was noted that SESAME
has implemented a version of rlogin secured with GSS-API, and that this
might be made available for use as a testing vehicle.


Status of Specifications

John Linn presented an overview of the recently-released Kerberos V5
mechanism Internet-Draft, draft-ietf-cat-kerb5gss.txt.  A comment was
made that this draft, along with RFCs 1508-1510, was insufficient to
enable an independent implementation, but no data was available about
the areas of perceived insufficiency; further comments were solicited on
the mailing list.

An X/Open preliminary specification containing the technical content of
RFCs 1508 and 1509 has been published.  One comment made, in a likely
future directions appendix, suggested that text be added to underscore
the feasibility of mechanisms or usage modes in which no authentication
need be performed at context establishment time, although per-message
protection would be fully supported.  The group agreed that it was
appropriate to add such text.

We discussed the steps needed to advance RFCs 1508-1510 from Proposed
Standard to Draft Standard level.  The layered interrelationship among
these documents, and the technologies they describe, implies that
several specifications' content must be implemented and integrated
before we can demonstrate interoperability; we need GSS-API
implementations as well as applications to exercise their functions.
Steve Crocker proposed that we should demonstrate and advance the
content of 1508-1510 and the Kerberos V5 GSS-API Internet-Draft
together, implying that the Internet-Draft first be advanced to Proposed
Standard, but that the calling application layered above GSS-API need
not itself be at the Proposed Standard level.  Since 1508-1510 have been
at Proposed for about six months, they have another 18 months within the
official window for advancement to Draft Standard.


FTP Security

During the CAT Working Group's session on Tuesday 29 March 1994, there
was discussion of the FTP Security section's work.  Sam Sjogren led this
part of the meeting.  The main focus of the work is the FTP Security
Internet draft authored by Steve Lunt.

At the previous CAT meeting, at the IETF meeting in Houston, a ``virtual
bakeoff'' for interoperability testing of implementations of the FTP
Security specification was proposed.  This bakeoff was intended to be
virtual in the sense of happening over the Internet instead of in a
single physical location.  With it being a scheduled event, it would
hopefully help people get work done by giving them a deadline to work
toward.  It has been observed that often most work for IETF gets done
right before meetings, so perhaps providing more ``events'' will result
in more work getting done.  It was agreed that the virtual bakeoff was a
good idea and so one was scheduled for the week of 14 March 1994.

The advantages of virtual bakeoffs are that they don't require a
physical presence by the bakers, they are easy to reschedule, are
inherently flexible overall, are done over the Internet, and easily
accommodate travel schedules.  Unfortunately, these same potential
advantages can also be disadvantages, and contributed to the relatively
low level of success of the event.  There was a very low level of
participation.  Travel and other work took precedence when the time
came; it was clear that an event with a low cost of participation is too
easy to pull people away from.  Since the event was scheduled only two
weeks before the Seattle IETF meeting, there wasn't much time available
after the scheduled bakeoff week to use the inherent flexibility of the
event to follow up on the week's experiences.  However, some porting
experience with Steve's code was obtained and it is hoped that the next
virtual bakeoff will be much more successful.  The next virtual bakeoff
is scheduled for the week of 27 June 1994 (a month before the Toronto
IETF meeting), and Sam will do more arm-twisting to get other
implementors to participate.

One of the features of the FTP Security specification is the support of
challenge/response mechanisms for one-time passwords.  This would allow
use of S/Key or various types of hand-held authentication devices.  As
long as an FTP client shows the user the full contents of the responses
received from the server and allows the user to type arbitrary FTP
commands (e.g., via the QUOT command that many FTP clients support),
then even an ``insecure'' FTP client could be used with a one-time
password system to avoid sending cleartext passwords across networks.
It may not even be necessary to send arbitrary commands to the FTP
server if, due to general policy or depending on the origin of the FTP
connection, the server assumes ``one-time-password mode'' and sends a
challenge in response to the USER command as received from the client
and then the response is sent by the user in the PASS command instead of
their real password.

Unfortunately, ``smart'' or ``friendly'' FTP clients exist, which do not
show the user all the responses from the FTP server nor allow the user
to send arbitrary commands to the server.  In particular, masking of the
USER command by client implementations complicates integration of
one-time password schemes.  [Note:  Integration of systems like SecurID
and S/Key does not require client modification or use of QQUOTE commands
since the challenge is one-way; changes are confined to the server
side.]  The question was posed to the group as to whether anyone could
think of any way to deal with such clients, perhaps through some sort of
out-of-band pre-authentication mechanism.  No one had any ideas about
how to deal with such a client, although it was suggested that such
clients usually have some way to enable a debugging mode to show the
responses received from the server.  Any other suggestions or
observations along these lines would be most welcome on this open
problem.

At this point we have rough consensus and some running code.  In
addition to Steve Lunt's Kerberos V4 implementation, which has been
ported to several platforms, it was reported that Prem Tirilok is
working on FTP security with Kerberos V5.  We have decided to recommend
that the FTP Security draft be advanced, in its current state, to
Proposed Standard status.  There was some question over whether the
appendices, which specify the Kerberos V4 and GSS-API mechanisms, should
be included in the advanced document, especially since there does not
yet exist an implementation of the GSS-API mechanism for FTP. There
seems to be no problem advancing the draft in this state to Proposed
Standard, as either or both appendices can be removed from the document
at the time it is proposed for further advancement.  We hope that once
the draft becomes a Proposed Standard it will attract more attention in
the form of independent implementations.


CAT Technical Issues

1.  Asynchronous, Non-Blocking Support

This topic concerns the idea of providing support in V2 for
asynchronous, non-blocking operation.  It was considered an OS-specific
issue, possibly a candidate for different sets of environment bindings
and/or use of separate, environment-specific, libraries enabling support
for asynchrony.  Further discussion on the mailing list was solicited.

Ted Ts'o raised the topic, following some discussions he had had with
Kerberos developers working on a Macintosh platform.  As a premise,
Macintosh driver calls must be non-blocking to avoid locking the system
as a whole.  Commonly, this is achieved by passing the Macintosh kernel
a pointer to a callback function to be invoked when a packet is
received.

GSS-API evolved in a UNIX environment, where other means (e.g., select,
multi-threading) to support asynchrony are commonly available, but no
such facilities can be assumed in the Mac world or in various other
non-UNIX environments (e.g., Windows?).  The X-Windows system uses an
OS-specific select call within its implementation to respond to this
issue.  Piers McMahon (ICL) noted that GSS-API's present synchronous
behavior works well in a multi-threaded environment, that it was
preferable for callers in such an environment, and that callbacks can't
be generalized.  Steve Lunt noted that support for asynchrony was
properly the job of an implementor within a particular environment.
Generally, we observed that issues of support for asynchrony are quite
OS-specific, and are not specific to implementation of security versus
other services on the same platforms.


2.  Large Messages

This issue concerns a desire for a continuation facility on per-message
calls so that an entire, possibly-large, buffer doesn't have to be
passed in and processed in a single ``gulp,'' and so that a single
integrity check can enclose the entirety of such a large message.  Such
a facility could be implemented either in a manner similar to the
CONTINUE_NEEDED facility used for context establishment, or through
callbacks.  Proposals were presented at the meeting (by John Linn) and
by e-mail (by Steve Lunt); discussion is ongoing on the mailing list.
About half of the meeting's attendees believed that we should proceed
with a means to support a continuation facility in V2.  Steve Lunt noted
that his proposal would eliminate the need for the size negotiation
facility currently built into the FTP Security Internet-Draft.

Several aspects of the issue are noteworthy:  the local issue of a
caller wishing to protect a message greater than the local size limit,
the distributed issue of a caller at an endpoint with a larger buffer
size sending a protected message to another endpoint whose maximum size
is smaller, the potential inefficiency of declaring and preallocating a
fixed-size buffer rather than applying dynamic (though unpredictable)
allocation when needed, and mechanisms' placement of checksums at the
beginning versus at the end of a token.

It was agreed that, minimally, GSS-API should provide callers with a
facility which enables them to determine a safely-small size buffer
processable locally.  This could be accomplished with a new INQUIRE_SIZE
primitive, as new outputs from INIT_SEC_CONTEXT and ACCEPT_SEC_CONTEXT,
and/or as a new output from INQUIRE_CONTEXT.

The next level of function, indicating a safe buffer size processable by
both peers to a context, was discussed but consensus was not reached at
the meeting and discussion was remanded to the mailing list.  It was
noted that the maximum size could likely be mechanism-specific, and
there was controversy within the group as to whether size negotiation
should be performed within GSS-API and its mechanisms.  Clearly, GSS-API
cannot and should not handle the fully general problem of message
segmentation between applications; it's likely, however, appropriate to
inform callers of size limits imposed by the security service
implementation in order that the callers may factor those limits into
their processing or negotiation.  It was observed that
application-visible size issues would not arise if, as in DNSIX,
security features were embedded below the application layer.

Following a discussion with Warwick Ford, John Linn summarized this
proposal:  provide a ``continue'' versus ``final'' flag to be used as an
input to Sign and Seal.  Elements of a continuation message must be
presented in order, and no other messages may be interspersed on a
context while a continuation message is being processed; applications
(likely in conspiracy with their underlying transports) are responsible
for providing ordered, complete delivery of elements to Verify and
Unseal, which would report errors if misordered or missing elements were
detected.  Verify and Unseal would return CONTINUE_NEEDED status after
processing non-final tokens; integrity check would not be valid except
when final token is processed.  Context establishment tokens should
declare a guaranteed buffer size to a peer, which could be retrieved
through INQUIRE_CONTEXT; a new GSS_TOKEN_TOO_BIG MAJOR_STATUS value seems
warranted.


3.  Iteratively Appending Credentials

This topic relates to a suggested ADD_CRED facility, which would be used
to append credential elements, associated with a different mechanism, to
a different credential set.  Iterative use of ADD_CRED would enable
unambiguous error reporting on credential acquisition in multi-mechanism
environments.  The topic was tabled for future consideration as part of
broader multi-mechanism support matters.

Difficult issues include the acceptable relations among the identities
which the different credentials may represent, further complicated by
the fact that their name types may not necessarily be identical or even
comparable.  An ADD_CRED facility would need to accept only the same
name as used by other elements in the credential set to which it was
appending, given the fact that INQUIRE_CRED outputs only one name as an
output.  Much of the motivation for iterative credential set building
derives from the desire to shape the default credentials which will be
used when INIT_CONTEXT is called without an explicit CRED_HANDLE; Ted
Ts'o suggested that we consider whether reconstruing the default
credential construct as a default credential set might provide a
feasible approach to this issue.


4.  Graceful, Confirmed Context Shutdown; Context Deletion Semantics

This issue relates to a suggestion that DELETE_SEC_CONTEXT support
CONTINUE status and, by implication, that PROCESS_CONTEXT_TOKEN be able
to return an output token in order to accomplish a graceful, confirmed
context shutdown.  It was argued that handshaking to accomplish an
effective multi-phase commit before tearing down context resources
should be considered wholly an application-level matter, above GSS-API.
Beliefs were also expressed that the context deletion token which
DELETE_SEC_CONTEXT may now emit is superfluous, and that a context
deletion primitive should have a wholly local effect.

Three tiers of possible function were identified:  (1) release local
resources, generating no token; (2) generate a token to notify the
remote peer to release its resources (if used, (2) should be invoked
before (1), so the context's resources can still be used to protect the
generated token); (3) confirmed close with semantics as used in ACSE.
Relative to FTP Security as an example, Steve Lunt noted that an
explicit close as in (3) wouldn't be needed; its applicability could be
somewhat more apparent for applications which use multiple security
contexts serially within a communications association.  Little sentiment
appeared among attendees for case (3); the current proposal in this area
is that we add, in V2, a new, additional RELEASE_SEC_CONTEXT call which
would be wholly local in significance and recommended in preference to
DELETE_SEC_CONTEXT.


5.  Stream Protocol Support

This topic concerns extensions for efficient support of data protection
in stream-oriented protocols like TELNET, where the size of an
individual data unit to be processed is often only a single byte and
where optimization of cryptographic processing cycles can be a
significant issue.  (There was debate, however, about whether encrypted
rlogin, which typically executes a full DES cycle per character, was
unacceptably slow in operational use.)  Use of OFB mode encryption, as
has been used to protect TELNET traffic, was discussed but does not
directly provide integrity.  After discussion, it was recommended that
mechanisms could (optionally) support such features through use of
special QOP values.


OID Assignments

Formal OID assignments for Kerberos V5 mechanism name types will be made
by MIT.


Detailed Points RE: RFC 1509

In the final minutes of the meeting, Marc Horowitz raised for discussion
some detailed points regarding RFC 1509 which had previously been posted
in a message to the mailing list.  Only a subset of the list was
covered.  Two specific points raised and accepted include:  should
legitimately be able to pass a zero-length token as input to an initial
call to INIT_SEC_CONTEXT, and need to fix RFC 1509's erroneous
typographic segue (p. 40) from a call's description into gssapi.h.  It
was observed as desirable that GSS-API implementations be shippable as
shared libraries without source code.  Such object-level compatibility
would require at least uniformly-accepted structures for four typedef
values; Marc will make a follow-up proposal to the mailing list for
discussion.


Attendees

Garrett Alexander        gda@tycho.ncsc.mil
Perkins Bass             bass@eskimo.com
Kym Blair                kdblair@dockmaster.ncsc.mil
Uri Blumenthal           uri@watson.ibm.com
Michael Bringmann        michael@rd.qms.com
J. Nevil Brownlee        nevil@ccu1.aukuni.ac.nz
David Carrel             carrel@cisco.com
Wallace Colyer           wally+@cmu.edu
Stephen Crocker          crocker@tis.com
Shane Davis              shane@delphi.com
Terry Davis              tld5032@commanche.ca.boeing.com
Cheri Dowell             cdowell@atlas.arc.nasa.gov
Havard Eidnes            havard.eidnes@runit.sintef.no
Antonio Fernandez        afa@bellcore.com
Jerome Freedman          jfjr@mbunix.mitre.org
Dennis Glatting          dpg@ocsg.com
Chris Gorsuch            chrisg@lobby.ti.com
Richard Graveman         rfg@ctt.bellcore.com
Dragan Grebovich         dragan@bnr.ca
Marco Hernandez          marco@cren.net
Jeff Hodges              hodges@jessica.stanford.edu
Marc Horowitz            marc@security.ov.com
Jim Hughes               hughes@network.com
Vince Jones              72077.1615@compuserve.com
Robert Karsten           robert@lachman.com
Charlie Kaufman          kaufman@zk3.dec.com
Hiroshi Kawazoe          kawazoe@trl.ibm.co.jp
Sean Kennedy             liam@nic.near.net
Edwin King               eek@atc.boeing.com
Peter Kirstein           P.Kirstein@cs.ucl.ac.uk
John Larson              jlarson@parc.xerox.com
Seung-Hwa Lee            shlee@garam.kreonet.re.kr
Ben Levy                 seven@ftp.com
John Linn                linn@security.ov.com
Wen-Pai Lu               wpl@bss.com
Steven Lunt              lunt@bellcore.com
Yosi Mass                yosi@ubique.co.il
Piers McMahon            p.v.mcmahon@rea0803.wins.icl.co.uk
Marjo Mercado            marjo@cup.hp.com
Michael Michnikov        mbmg@mitre.org
Keith Moore              moore@cs.utk.edu
Bob Morgan               morgan@networking.stanford.edu
Stephen Nahm             sxn@sun.com
Clifford Neuman          bcn@isi.edu
Chris Newman             chrisn+@cmu.edu
Hilarie Orman            ho@cs.arizona.edu
Peter Phillips           pphillip@cs.ubc.ca
Derrell Piper            piper@tgv.com
Michael Ressler          mpr@ctt.bellcore.com
Chris Seabrook           cds@ossi.com
Sam Sjogren              sjogren@tgv.com
Don Stephenson           don.stephenson@sun.com
Tony Valle               valle@huntsville.sparta.com
Raymond Vega             rvega@cicese.mx
Dale Walters             walters@osi3.ncsl.nist.gov
Grace Wiechman           gw@cray.com
John Wray                wray@tuxedo.enet.dec.com
Suguru Yamaguchi         yamaguti@wide.ad.jp
Kisong Yoon              kysoon@garam.kreonet.re.kr
Dan Zerkle               zerkle@cs.ucdavis.edu
Glen Zorn                glenz@ocsg.com