Internet Standards/CD1.mdf/INET/IETF/CAT/93NOV.MIN

Text File | 1994-02-23 | 16.4 KB | 345 lines

CURRENT_MEETING_REPORT_

Reported by John Linn/OpenVision and Sam Sjogren/TGV

Minutes of the Common Authentication Technology Working Group (CAT)


Overview

The CAT Working Group met for two sessions in Houston.  The status of
ongoing activities was reviewed, 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, should be 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 and
1509, targeting inclusion in eventual Draft Standard versions to
supplant those RFCs and comprise a ``Version 2'' GSS-API. Related topics
to be discussed 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 Network Access Server
Requirements Working Group (NASREQ) described their currently
contemplated architecture as input to determining how the CAT Working
Group and technology might support their needs.  Ran Atkinson gave a
presentation on the Internet Authentication Guidelines Internet-Draft,
receiving and soliciting comment from the attendees.


Status Review

Ted Ts'o 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 stated would also be distributed in December.

No effort on a Kerberos V4 GSS-API implementation is known.  Ted Ts'o
offered to review and contribute to a design specification for KV4
GSS-API if anyone wishes to drive this activity.

Piers McMahon 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

The procedure through which any changes and extensions to be made to
1508 and 1509 would be reflected and characterized was discussed.  The
current RFCs were declared as constituting ``GSS-API Version 1,'' and
successor Internet-Drafts will be generated enroute to become ``GSS-API
Version 2'' (aka 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 attendees 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 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 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.

The level of portability to be supported by GSS-API mechanisms was
discussed, and it was agreed to take feasible and apparent measures in
the interests of supporting object-level portability across different
implementations.  Specifically, 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, it was 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 attendees 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.


Presentation on Multi-Mechanism Issues

Piers McMahon (ICL) gave a presentation entitled ``GSS-API IN A
MULTI-MECHANISM ENVIRONMENT,'' covering 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 specialization
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.


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 gave a presentation on the Internet-Draft he had
co-authored with Neil Haller (draft-haller-auth-requirements-01.txt), to
solicit comments from the 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 versus machine-oriented, orientation to
point-to-point versus 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 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 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
will 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 Internet-Draft (the
current version is draft-ietf-cat-ftpsec-03.txt) had been changed by the
author, Steve Lunt, to reflect discussions at that meeting.  The changes
were:


   o 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.

   o Changed GSS_Safe to GSS_Seal with conf_flag == False

   o Changed GSS_Verify to GSS_Unseal

   o Changed GSS_Seal to GSS_Seal with conf_flag == True

   o Changed the mailing list from [e-mail] to [e-mail].
     There is a mail reflector at TGV which will remain in existence
     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 two outstanding protocol length issues which were introduced
for discussion leading to closure.  First, the issue of the length of
buffers allowed for protected file transfers, and second, the lack of
restriction on the length of base-64 encodings.

It is desirable to have a finite buffer size 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 specification
of this to the document.

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 document 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 e-mail.

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


Interoperability Bakeoffs

Sam Sjogren led a discussion which proposed the idea of having ``virtual
Bakeoffs'' between IETF meetings to motivate implementation of standards
being worked on and interoperability testing of those implementations.
A tentative date of the week of 14 March 1993 will be the target for a
virtual bakeoff of the FTP Security work.


Attendees

Garrett Alexander        [e-mail]
Nick Alfano              [e-mail]
Alireza Bahreman         [e-mail]
Luc Boulianne            [e-mail]
Chuck de Sostoa          [e-mail]
Antonio Fernandez        [e-mail]
Steve Garritano          [e-mail]
Jisoo Geiter             [e-mail]
Chris Gorsuch            [e-mail]
Marco Hernandez          [e-mail]
Charlie Kaufman          [e-mail]
Walter Lazear            [e-mail]
Gordon Lee               [e-mail]
John Linn                [e-mail]
Kanchei Loa              [e-mail]
Steven Lunt              [e-mail]
Chip Matthes             [e-mail]
Wayne McDilda            [e-mail]
Piers McMahon            [e-mail]
Michael Michnikov        [e-mail]
Bob Morgan               [e-mail]
Clifford Neuman          [e-mail]
Rakesh Patel             [e-mail]
Allan Rubens             [e-mail]
Jeffrey Schiller         [e-mail]
Wolfgang Schneider       [e-mail]
Vincent Shekher          [e-mail]
Sam Sjogren              [e-mail]
Frank Solensky           [e-mail]
Dave Solo                [e-mail]
Don Stephenson           [e-mail]
Jerry Toporek            [e-mail]
Theodore Ts'o            [e-mail]
John Veizades            [e-mail]
John Vollbrecht          [e-mail]