Minutes for Houston CAT meetings

[John Linn <[e-mail]>]

Common Authentication Technology (CAT) minutes for Houston IETF,
compiled by John Linn (OpenVision) (sections other than FTP security),
and Sam Sjogren (TGV) (FTP Security discussion):

OVERVIEW

The CAT WG met for two sessions in Houston.  We reviewed status of
ongoing activities, including a reworked GSS-API implementation for
Kerberos V5 beta 3; this distribution and an Internet-Draft describing
its GSS-API mechanism characteristics and token formats are scheduled
to become available later this year.  Some interface clarifications
and extensions (e.g., a new GSS_Inquire_context primitive) were
discussed as inputs to Internet-Draft successors to RFCs 1508/1509,
targeting inclusion in eventual Draft Standard versions to supplant
those RFCs and comprise a "Version 2" GSS-API.  Related topics to be
discussed further on the mailing list include multi-mechanism
credential management and error reporting.  Piers McMahon gave a
presentation on SESAME's multi-mechanism implementation, and
distributed a paper for comment.  Sam Sjogren and Steve Lunt led a
discussion on the FTP Security Internet-Draft, to be updated shortly
and to be used as the basis for an interoperability test (using
Kerberos V4 technology) planned for March 1994.  Representatives from
the NAS Requirements WG described their currently-contemplated
architecture, as input to determining how the CAT WG and technology
might support their needs.  Ran Atkinson gave a presentation on the
Internet Authentication Guidelines Internet-Draft, receiving and
soliciting comment from the WG.

STATUS REVIEW

Ted Ts'o (MIT) reported that two independent implementors are
reworking the GSS-API implementation for Kerberos V5; it is expected
that the result of one of these activities will be incorporated into
Kerberos V5 beta 3, to be available as a redistributable release in
December.  (This step will replace and obsolete the "alpha quality"
GSS-API in Kerberos V5 beta 2.) Detailed documentation, including
token formats for the mechanism, is being prepared and will be
included in an Internet-Draft which John Linn (OpenVision) stated
would also be distributed in December.

No effort on a Kerberos V4 GSS-API implementation is known; should
anyone have available and motivated resources to undertake this project,
it should be technically feasible.  Ted Ts'o offered to review and 
contribute to a design spec for KV4 GSS-API, if anyone wishes to 
drive this activity. 

Piers McMahon (ICL) provided hardcopy of a memo he drafted describing
a framework for GSS-API extensions targeted for POSIX environments,
and solicited comments.

John Linn reported that the ongoing liaison with the X/Open Security
Working Group is progressing well, and that the technical content of
RFCs 1508 and 1509 is incorporated in a document currently undergoing
X/Open Company Review for publication as an X/Open Preliminary
Specification.

INTERFACE EXTENSIONS AND REFINEMENTS

We discussed the procedure through which we would reflect and
characterize any changes and extensions to be made to 1508 and 1509.
We declared the current RFCs as constituting "GSS-API Version 1", and
will generate successor Internet-Drafts enroute to the eventual next
level of RFC publication which would become "GSS-API Version 2" [aka
in these minutes as GSSV2].

The GSS_Inquire_context() primitive, as discussed on the mailing list,
was accepted as an addition for GSSV2.  Renaming of the per-message 
primitives, per X/Open terminology request and as also discussed 
previously on the mailing list, was accepted as a change for GSSV2.

The group discussed the issue of credential acquisition in a
multi-mechanism environment, including a proposal made to the mailing
list for definition of a new GSS_Add_cred() primitive to be used in 
preference to the current GSS_Acquire_cred().  Since GSS_Acquire_cred(),
like other GSS-API calls, returns only a single pair of major_status
and minor_status values, its use in a multi-mechanism environment cannot
return specific information about each of the supported mechanisms for
which credentials may or may not have been successfully acquired. 

Several attendees observed the fact that the need to disambiguate
minor_status values is primarily of interest to callers embodying
knowledge of mechanism-specific characteristics and needing to make
decisions based on those characteristics, a class of callers which
attendees sought to minimize. Despite this fact, some
mechanism-cognizant callers (or, short of this, callers seeking to
display meaningful minor_status indications to their clients) will
certainly exist, and it's appropriate to consider how they could be
better served for GSSV2.

In addition to the prior GSS_Add_cred() proposal, it was observed at
the meeting that that callers requiring unambiguous per-mechanism
status information could use the current GSS_Acquire_cred(),
explicitly specifying a single mechanism per invocation, at the cost
of losing the convenience of multi-mechanism credentials.  [Though not
cited in meeting discussion, the GSS_Indicate_mechs() primitive
provides the necessary data for a caller to perform this iteration.]
Following some discussion, John Linn accepted the action of further
summarizing options and tradeoffs in a message to the mailing list. 

We spent some time discussing the level of portability to be supported
by GSS-API mechanisms, and agreed to take feasible and apparent
measures in the interests of supporting object-level portability
across different implementations.  Specifically, we agreed that the
forthcoming Kerberos V5 mechanism Internet-Draft should define a set
of common minor_status values to be used by implementors of the
mechanism, though additional minor_status codes specific to particular
implementations are also possible.  Further, we agreed that the
"gssapi.h" header file at the end of RFC-1509 should be considered
part of the standard, noting that refinements and additional elements
(e.g., type definitions for name representations having broader scope
than a single mechanism) might be incorporated for GSSV2 and that
particular implementations would likely append their own,
implementation-specific definitions over and above gssapi.h.

The group discussed a prior request to incorporate a form of per-message
protection which would provide confidentiality without integrity, but
did not elect to incorporate such a facility.  

PIERS MCMAHON PRESENTATION ON MULTI-MECHANISM ISSUES

Piers McMahon (ICL) gave a presentation entitled "GSS-API IN A
MULTI-MECHANISM ENVIRONMENT", discussing four topics: (1) problem
domain, (2) architecture of GSS-API implementation by SESAME, (3)
API implications, and (4) approaches to credential acquisition.

Regarding the problem domain, Piers observed the following: (1a)
today's (and probably tomorrow's) problem is heterogeneity, (1b) users
expect single sign-on, and (1c) administrators expect single point of
user registration.  Regarding API implications, he cited internal
structure constructs designed to separate the GSS-API layer from
individual underlying mechanisms: internal APIs to
deposit/append/clear credential elements, credential element/security
context specialisation features (function vectors, data), and use of a
common cryptographic support facility (CSF) for all mechanisms.  In
terms of external elements (those visible to GSS-API callers), he
noted that it was necessary to provide a single common view of
timeouts and other attributes, spanning all underlying mechanisms.
Regarding credential acquisition and related login functions, he 
cited three concepts: multiple login, use of shared data elements
relevant to more than a single mechanism, and an "access manager" which
would use, e.g., passwords or credentials for one mechanism as a basis
for which to acquire credentials of another mechanism on behalf of
a user. 

The following slide presents the structure of SESAME's GSS-API
implementation:

ARCHITECTURE OF GSS-API IMPLEMENTATION BY SESAME
         
         Principal --owns-> Credential
         
                                |
                             contains one or more
                                V
                
                           Credential Element
                
                                ^
                             inherits from
                                |
                
                +---------- SESAME Credential Element
             initiate/
              accept
                |           Security Context --------uses---> Cryptographic
                |                                             Support
                |               ^                             Facility
                |            inherits from
                |               |
                |
                +---------> SESAME Security Context
         
INTERNET AUTHENTICATION GUIDELINES DRAFT

Ran Atkinson (NRL) gave a presentation on the Internet-Draft
(draft-haller-auth-requirements-01.txt) he had co-authored with Neil
Haller (Bellcore), in order to solicit comments from the interested
IETF community.  The document distinguishes four classes of
authentication: none, disclosing (subject to passive attacks),
non-disclosing (subject to active, but not to passive attacks), and
strong (resistant to passive and active attacks); its pragmatic
motivation is to encourage migration to at least the non-disclosing
level.  While this taxonomy was accepted as useful and primary, it was
noted that technologies could also be distinguished on other grounds:
human-oriented vs. machine-oriented, orientation to point-to-point vs.
distributed system usage, and requirements for shared secrets.  It was
recommended that the document retain a consistent and specific focus
on authentication, and that tutorial material be separated from
commentary and opinion.

It was noted that some of the content overlapped with sections of the
Internet Security Architecture document being prepared by the PSRG;
Jeff Schiller commented that he believed the documents were generally
aligned, but that some work would be needed in order to assure that
terminology definitions were consistent.  As a particular example, Ran
noted that he had observed U. S. Defense Department usage of the term
"digital signature" as referring to integrity protection without
non-repudiation, a form of usage inconsistent with much of the
literature.

NETWORK ACCESS SECURITY REQUIREMENTS (NASREQ)

John Vollbrecht (Merit) attended a portion of the CAT meeting in order
to inform attendees on NASREQ's environment and concerns, to solicit
comment, and to explore possible areas of overlap between the groups.
Review of anticipated design documents was solicited; the NASREQ mailing 
list is [e-mail].

The NASREQ environment includes Network Access Clients (NACs,
typically PCs) accessing Network Access Servers (NASs) via dial-up.
It is planned that the NASs will communicate with authentication
servers across a network, perhaps indirectly by way of "helper"
devices. PPP is used across the dial-up link, presently with PAP and
CHAP but with new KAP (Kerberos), PKAP (public key) and SCAP (smart
card) authentication schemes contemplated but not yet documented; a
brief explanatory memo is to be distributed shortly.  The "RADIUS"
protocol is being considered as a basis for interaction between NASs
and authentication servers.  Mobility support, enabling users to
connect to NASs in foreign domains (with multiple intermediary helpers
between the access point and a user's home NAS) is desired and
introduces inter-domain trust considerations.

Two authentication types are currently distinguished within user
records: "UNIX" (password-level) and "Kerberos" (in which a Kerberos
server is involved in the process of authenticating a user for access
to network resources via a NAS).  It was suggested that Derek Atkins'
MIT thesis on use of Kerberos in a dial-up environment represents an
alternate approach worthy of consideration.  GSS-API might be useful
as a means to protect traffic between NASs and helpers and/or
authentication servers, but its current underlying mechanisms are not
oriented to operation across a dial-up link where clients lack
independent access to authentication servers.

FTP SECURITY

Since the Amsterdam IETF meeting the FTP security draft (the
current version is draft-ietf-cat-ftpsec-03.txt) had been changed
by the author, Steve Lunt (Bellcore), to reflect discussions at
that meeting.  The changes were:

    - Principal name fallback (use "rcmd" if "ftp" doesn't exist)

	This would allow maximal flexibility for an administrator
	to restrict an FTP server and the environment it runs in,
	while allowing for simplification of administration by not
	requiring the configuration of new principals if a site
	wished to just use the "rcmd" principal which they would
	already have for use by Kerberized R-Services and Telnet
	and the like.  Any restrictions on what principal must be
	used and other configuration issues would be implementation
	and site specific.

    - Changed GSS_Safe to GSS_Seal with conf_flag == FALSE

    - Changed GSS_Verify to GSS_Unseal

    - Changed GSS_Seal to GSS_Seal with conf_flag == TRUE

    - Changed the mailing list from [e-mail] to [e-mail].

	There is a mail reflector at TGV which will remain in
	existance indefinitely.  So, mail sent to [e-mail]
	will merely get forwarded to [e-mail].	It is
	recommended, however, that the cat-ietf address be used.

There were a couple of outstanding protocol length issues which were
then introduced for discussion leading to closure.  First, the issue
of the length of buffers allowed for protected file transfers, and
secondly the lack of restriction on the length of base-64 encodings.

It is desirable to have a finite buffer size be used for protected
file transfers, as there may be situations in which a system would
need to read an entire buffer into memory before being able to operate
on it and some systems have far more finite memory resources than
others.  However, specifying some arbitrarily small buffer size could
have an impact on performance and even functionality.  It was decided
that a negotiation would be added to the protocol which would allow
the client and server to agree on a buffer size.  Steve will add the
specificiation of this to the draft.

A base-64 encoding may be of arbitrary length.	The binary authentication
data that is encoded may be of arbitrary length.  Although a line-wrapping
scheme could be specified that would wrap lines and thereby limit the
clear-text line length while allowing the arbitrarily long binary data,
it was not felt that there was any need to do that.  The draft will be
modified to note that the base-64 encoded data lines can be arbitrarily
long without line-wrapping being used.

The issue of a fall-back targ_name for the GSS-API specification for FTP
was not resolved.  The name "SERVICE:ftp@hostname" is currently specified,
but it is unclear what would be a more common name to fall back to (as
with the "ftp" to "rcmd" fallback in the Kerberos V4 specification).  This
issue will be resolved via email.

A request for adding state diagrams was made.  This will be satisfied in
a future revision of the draft.

INTEROPERABILITY BAKEOFFS

Following technical discussion of FTP security, Sam Sjogren led a
discussion which proposed the idea of having "virtual Bakeoffs"
between IETF meetings to motivate implementation of the standards
being worked on and interoperability testing of those implementations.
A tentative date of the week of 14 March '93 will be the target for a
virtual Bakeoff of the FTP Security work before the next IETF meeting.