CURRENT_MEETING_REPORT_
Reported by John Linn/Geer Zolot Associates and Sam Sjogren/TGV
Minutes of the Common Authentication Technology Working Group (CAT)
The Common Authentication Technology Working Group (CAT) met for two
sessions at the Columbus IETF. The primary Agenda item was integration
of security features into FTP, a topic for which Sam Sjogren is acting
as task leader and on which Steve Lunt has generated a working document
which will shortly be released as an Internet-Draft. Additional
discussion topics were the advancement status of currently active CAT
Internet-Drafts (GSS-API, GSS-API C bindings, and Kerberos V5), and a
working proposal by Ted Ts'o for a CATS stream-oriented protocol overlay
to be used in conjunction with GSS-API.
Status Of Specifications
The CAT Internet-Drafts have been pending administrative action for some
time, and an action plan was evolved for their advancement
recommendation. An updated Kerberos V5 specification was produced by
Cliff Neuman; comments received from its review list by April 10th will
be reflected in an Internet-Draft to be issued by April 17th. Primary
late-breaking changes include added detail on an encrypted timestamp
preauthentication type, and a new message type for credential exchange
when proxies are being provided to an end server.
Concurrently with the Kerberos specification review, an advancement memo
will be prepared for the set of Internet-Drafts (GSS-API, GSS-API C
bindings, Kerberos V5). Intended follow-on documents will include a CAT
mechanism definition (with token format) based on Kerberos V5. It was
determined that use of the mechanism tagging recommended in GSS-API
Appendix B should be adopted as mandatory, and message stream facilities
were strongly desired within GSS-API mechanisms in order to satisfy FTP
functional and integration requirements; a new appendix to the GSS-API
specification has been drafted and distributed to the CAT mailing list
codifying the results of this discussion.
CATS Stream Protocol
The CATS proposal, presented by Ted Ts'o, was engendered by a desire to
provide prospective protocol integrators with a subprotocol
specification for security, along with a stream-oriented API. An
explicit CATS goal is that it be implementable quickly and without
kernel modifications (unlike, e.g., IP- level security). CATS presents
an alternative, generic form for protocol integration, contrasting with
the protocol-specific integration being employed in Telnet options and
FTP commands. Submission of a revised CATS specification as an
Internet-Draft is planned.
In evolving CATS, Ted observed that the status of the tagging scheme in
GSS- API Appendix B as a recommendation to mechanism designers led to
1
undesirable ambiguity, and suggested making it mandatory; this
suggestion was adopted and would be integrated into the Kerberos V5
implementation. Among other discussion, it was suggested that the CATS
protocol be extended in order to exchange preamble tokens in advance of
context establishment for mechanism type negotiation, and this prospect
will be examined.
FTP Security
Sam Sjogren began the FTP part of the meeting by describing the goals
for the FTP security work, as initiated at a BOF during the previous
IETF and to be continued under the CAT Working Group framework. Support
for authentication, as well as integrity verification and privacy, via
any of a number of different mechanisms will be provided by this work.
Steve Lunt presented his proposal for extensions to the FTP protocol
(additional commands) to implement the security goals; he intends to
make an FTP security implementation publicly available. An overhead
presentation supplemented the draft that had previously been posted to
the Group's mailing list. Lively discussion occurred during and after
this presentation, to the point that an additional evening meeting was
scheduled to continue the discussions. The resulting FTP security
discussions were quite fruitful, both in terms of providing feedback for
improving the draft proposal for FTP as well as fine tuning the GSS-API
requirements and specifications. It was decided that the case of a
three-party FTP interaction is sufficiently complex and rarely enough
used that specification of how to do it securely will be deferred,
probably to a separate document to be produced later.
Once peer entity authentication has been completed (and a session key is
available), the proposed FTP security approach protects all subsequent
FTP commands for at least integrity (encapsulation of base-64 encoding
of gss_seal() output within MIC command), and optionally for
confidentiality as well as integrity (encapsulation within ENC command,
gss_seal() conf_flag TRUE). It was observed that underlying GSS-API
mechanisms must represent and protect the conf_avail flag value and
other service availability indicators within their tokens to prevent
active attacks; the to-be-written ``Kerberos Vn for GSS-API'' and other
mechanism design documents will describe how this protection is
provided. (These indicator protection requirements apply independently
of whether GSS-API is employed.) To protect against active attackers
corrupting a data or control stream by changing the order of data or
commands in the stream, protection via sequence numbers or some other
such technique must be provided by the FTP security standard or the
underlying mechanisms.
Given that the FTP control connection is a Telnet stream, questions
arose about the rationale for not using the Telnet authentication option
as an approach for FTP. Steve cited two reasons: (1) because the Host
Requirements RFC precludes use of Telnet options on the FTP control
connection, and (2) because of a desire to provide data integrity, which
Telnet security does not offer.
2
There was discussion of the fact that no facility was exposed at the
level of the FTP security commands for negotiating the type and strength
of cryptography to be used for data protection. However, it was
recognized that such features can exist within underlying mechanisms yet
remain transparent at the level of FTP. The ordering of USER and AUTH
commands will be made such that an FTP server may make a decision on
what authentication and encryption mechanisms are acceptable based on
who the user is.
Kerberos ticket granularity and naming issues were discussed. For
Kerberos V4, the form of a target FTP server's name should be
``ftp.<simple-host>'', and for Kerberos V5,
``ftp/<domain-qualified-host>''. It was noted that use of different
target names for different server processes within a host is not
primarily an access control measure, but does permit the servers to run
in different protection domains (as might be desirable for an FTP server
available to casual remote users).
Areas to be revised in the FTP draft based on discussion include:
o Additional discussion of requirements.
o Approach for transfer of arbitrarily long tokens from client to
server.
o Alignment of base-64 encoding technique with RFC1421.
o Statements regarding mechanism negotiation (including a statement
that an FTP server may refuse to accept anything less than suitably
strong authentication).
o Further work on the data stream protection approach.
Attendees
Steve Alexander stevea@lachman.com
John Campbell jrcamp@nosc.mil
William Chung whchung@watson.ibm.com
Stephen Crocker crocker@tis.com
Dave Cullerot cullerot@ctron.com
Antonio Fernandez afa@thumper.bellcore.com
James Galvin galvin@tis.com
Jisoo Geiter geiter@mitre.org
Richard Graveman rfg@ctt.bellcore.com
Frank Kastenholz kasten@ftp.com
David Katinsky dmk@pilot.njin.net
Charles Kaufman kaufman@zk3.dec.com
Stephen Kent kent@bbn.com
Zbigniew Kielczewski zbig@eicon.qc.ca
Andrew Knutsen andrewk@sco.com
3
Paul Lambert paul_lambert@email.mot.com
John Linn linn@gza.com
James Mahon mahonj@honfsi1.att.com
Cynthia Martin martin@spica.disa.mil
Evan McGinnis bem@3com.com
P.V. McMahon p.v.mcmahon@rea0803.wins.icl.co.uk
Bob Morgan morgan@networking.stanford.edu
Clifford Neuman bcn@isi.edu
Emmanuel Pasetes ekp@enlil.premenos.sf.ca.us
Christopher Provenzano proven@csi.compuserve.com
Steven Richardson sjr@merit.edu
April Richstein amr@tycho.ncsc.mil
Shawn Routhier sar@epilogue.com
Jeffrey Schiller jis@mit.edu
Wolfgang Schneider schneider@gmd.de
Sam Sjogren sjogren@tgv.com
Stuart Stanley stuarts@apertus.com
Bob Stewart rlstewart@eng.xyplex.com
Stuart Stubblebine stubblebine@isi.edu
Louisa Thomson louisa@whitney.hac.com
Klaus Truoel truoel@gmd.de
Theodore Ts'o tytso@mit.edu
James Weatherford weatherf@nosc.mil
Peter Wilson peter_wilson@3com.com
4