Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/cat/cat-minutes-94jul.txt

Text File | 1994-11-02 | 15KB | 288 lines

CURRENT_MEETING_REPORT_

Reported by John Linn/OpenVision

Minutes of the Common Authentication Technology Working Group (CAT)

The CAT Working Group met for two sessions in Toronto, with a total of
58 rostered attendees.  Approximately half of the attendees had attended
one or more previous CAT meetings, and approximately one third were
subscribed to the working group mailing list.  Carlisle Adams gave a
presentation on the Simple Public-Key Mechanism (SPKM), a proposed
GSS-API mechanism based on public-key technology, offering 2-way and
3-way authentication exchange variants, generalized use of OIDs for
flexibility, parameter negotiation, and provisions for non-repudiation
services.  Rough consensus was reached on outstanding issues of GSS-API
buffer sizes, continuation processing of long messages, and context
expiration, pending review by the mailing list.  Advancement of FTP
security is pending revision of the Internet-Draft.  We also received a
presentation on IMAP authentication by John Myers.

Topics receiving significant discussion, summarized in later sections of
these minutes, included:


   o The Simple Public-Key Mechanism (SPKM)
   o Interactive Mail Access Protocol (IMAP) authentication
   o Context expiration in Kerberos V5 mechanism and GSS-API
   o Continuation processing and large message handling in GSS-API



Short Topics

In opening agenda discussion, P. Rajaram asked whether discussion of
authorization extensions to GSS-API, such as those proposed in X/Open by
Project SESAME, was an appropriate topic for CAT Working Group
discussion.  Piers McMahon commented that the SESAME work was outside
the CAT Working Group's current scope.  It was also noted that a
separate IETF Authorization and Access Control Working Group (AAC)
exists and is chartered to pursue such activities, but has not met
recently.

Other topics, discussed briefly, included:

Kerberos principal object support:  Working group members were asked to
review the text in ``The Kerberos Version 5 GSS-API Mechanism''
(draft-ietf-cat-kerb5gss-01.txt) proposing routines for import and
export of non-printable name objects and to consider whether these
routines should be migrated to successors to RFCs 1508 and 1509.

Negotiated mechanism:  Don Stephenson and P. Rajaram to investigate
reactivation of former work, possible availability of code; any added
application requirements for negotiation solicited (one desirable:  be
able to make the negotiation messages compact for insertion within
existing size-limited protocols; another, enable ordered preferences to
be specified).

``SERVICE'' prefix for service names:  Ted Ts'o to send note to list
summarizing issues and background.  This prefix had been used to
distinguish service entities, in conjunction with a null mechanism type.
Its use now appears redundant along with the service name type, as
described in the current draft, which serves as a hint to
gss_import_name() as to how to process a name in the course of
importation.  There are some backward compatibility issues with existing
code.  We need to decide how, and whether, to preserve use of this
convention.

Store-and-forward support service extensions to GSS-API: no consensus
within group on pursuing this topic at the meeting, but discussion is
proceeding on the mailing list.  P. Kirstein and P. McMahon noted that
the European Community's TDP consortium is interested in using (or
defining, if needed) GSS-API-compatible extensions in this area, and
that there would be interest in any work which might emerge from the
IETF.

Service-to-client one-way authentication (as desired, e.g., for use by
some Mosaic services):  at present, best available approach is to
authenticate mutually from accessing client to server, even though the
client-server path is not an application requirement.  It is also
possible, if supported by an underlying mechanism, to apply one-way
authentication on a context initiated by the Mosaic service and accepted
by the Mosaic client.

Buffer sizes across GSS-API interface:  It was believed that the 2Kbyte
threshold included in draft-ietf-kerb5gss-01.txt was smaller than
desirable, and that a change to 16Kbytes would be acceptable to known
implementors and would permit more efficient operation.  It is therefore
proposed that the limit be increased to 16Kbytes.

Stream support (``CATS'' protocol):  Ted Ts'o to resend working notes to
list.

Status of FTP security draft:  Pending revision in response to posted
comments.


SPKM Presentation

Carlisle Adams gave a presentation on a proposed Simple Public-Key
Mechanism (SPKM), as described in Internet-Draft ``The Simple Public-Key
GSS-API Mechanism (SPKM)'' (draft-ietf-cat-spkmgss-00.txt).  SPKM is
based on a public key infrastructure, offers (as separate mechanisms
with different OIDs) 2-way and 3-way mutual authentication (thereby
available to environments without secure time); uses OIDs wherever
possible to allow maximum flexibility and growth; uses negotiation at
context establishment time to allow interoperability between
environments (for SPKM-specific parameter negotiation, within the
mechanism); QOP parameter (from application) selects the data integrity
mechanism to be used; non-repudiation can be applied to context if
desired.

BNR's work began with an interface for store-and-forward messaging
support, subsequently generalized for on-line, association-oriented
operation.  BNR intends to offer the proposal as the basis for an
Internet standards-track protocol.  The development and distribution
status of a reference implementation for SPKM is not currently known,
but implementation is underway at Northern Telecom and/or BNR, and
feedback on the proposed approach is solicited.

Example tokens and exchanges were presented:  A Req_Token initiates all
exchanges.  The token structure is X.509-compliant, with some elements
optional.  A key establishment OID's value describes the exchange which
is to follow.  Context_Data provides the parameters describing a
context.  The Seal token bears OIDs for each of the integrity, sequence,
and confidentiality algorithms:  it carries an explicit OID if the
parameters established at context initiation allow more than one, and is
otherwise NULL. Alignment and padding of variable-length fields was
discussed.

Issue:  How do you handle later validation of a long-term signature,
once the context handle is no longer valid?  Long-term signing was an
interest and a design consideration but is not a requirement.

Carlisle's conclusions slide summarized the following observations:
SPKM has advantages over alternatives, in terms of flexibility,
non-repudiation, negotiation support and no required reliance on secure
timestamps.


IMAP Authentication

In the CAT Working Group's second session, John Myers led a discussion
on Interactive Mail Access Protocol (IMAP) authentication.  This
approach, currently in Last Call for advancement to Proposed Standard,
implements an IMAP4 AUTHENTICATE command, based on FTP security's
AUTH/ADAT commands.  It identifies authentication mechanisms by name,
and supports an arbitrary number of base64-encoded exchanges.  Privacy
and integrity protection are supported; the authorization userid is
independent of the authentication ID. In contrast to FTP security, there
is no separate data versus control channel.  User ID, protection
mechanism and buffer size are negotiated during the authentication
exchange.  Use of a protection mechanism is optional.  IMAP
authentication has no interaction with plain-text login.

Examples were shown using Kerberos V4 and S/Key; a GSS-API mechanism is
defined as well (protecting option exchange with GSS_Seal()).  GSS-API
and S/Key mechanisms are not yet implemented; Ted Ts'o expressed
interest in integrating with the Kerberos V5 development stream via
GSS-API if the IMAP code is distributable.  In the IMAP Kerberos
mechanism, the client closes out the exchange by mutually authenticating
back to the server and declaring accepted service options.  Design
intentionally uses server-issued challenges, so as to protect against
replays even within the Kerberos 5 minute timestamp window.  Could not
use S/Key with FTP security as it stands, since the FTP security draft
demands integrity on negotiation.  It was suggested that we consider
changing the FTP security draft to enable conformant use of S/Key.



Discussion of Proposed GSS-API Continuation Processing of Long
Messages

During the course of the SPKM presentation slot, Carlisle Adams
suggested a GSS-API extension to accept segments of long buffers with
continuation flag parameters:  add to gss_seal an ``end_flag'' which can
accept GSS_S_CONTINUE_NEEDED and add to gss_unseal the ability to
indicate that non-final versus final segments are being emitted.  Ted
Ts'o noted that the primary problem in the area of long message
processing is that the sender does not know how big a token the receiver
can handle.  Carlisle was more concerned with the local interface issue
than with the issue of sizes supported by remote peers.  Bill Sommerfeld
observed that applications and GSS-API should ``cooperate'' in terms of
segment sizes.

The argument was made that the use of sequencing mechanisms and
per-message integrity versus a single binding signature spanning
multiple data units is sufficient within the scope of an
association-oriented context; the binding signature might be more
valuable in a store-and-forward document scenario.

Three possible measures present themselves:


  1. Application calls a new GSS-API facility to find out how big a
     token it can pass in in order to get an output token no bigger than
     the maximum acceptable size.  Compression can introduce variability
     in the output size which will result for different data of the same
     input size.  The new facility needs to accept as input the QOP
     value which is to be requested for data protection.  Action:
     Incorporate this facility for GSSV2.

  2. Constrain mechanisms so that arbitrary fragments, split within the
     GSS-API or below, can be independently validated.  The group agreed
     not to impose this constraint.

  3. There was interest in a facility to distinguish an ordered stream
     of non-initial segments from a final segment.  P. Rajaram argued
     that this would resolve the issue of not having enough memory to
     process the data unit as a whole.  Controversy revolved around
     whether this was an appropriate facility at the level of the
     interface rather than an application-specific issue above the
     interface.  In Ted Ts'o's proposed CATS package, connection close
     was indicated explicitly by the CATS protocol, rendering moot the
     need to distinguish a final message at the level of the GSS-API
     interface.  After discussion, we resolved (pending mailing list
     confirmation) not to incorporate interface-level message
     continuation facilities.


Context Expiration

We discussed context expiration within the Kerberos mechanism,
distinguishing enforced expiration (disabling per-message protection
when expiration time is reached) versus advisory expiration (continuing
to perform per-message protection operations, with informatory status)
versus no expiration.  Advisory and enforced expiration cases can be
further subdivided into uniformly-performed expiration versus expiration
performed only if requested by a caller at context expiration time.
Much of the interest in application-selectable expiration relates to use
as a trigger to garbage collect keys and related data.  Possible inputs
to an expiration policy would include (some combination of)
user-requested time, expiration time(s) of relevant tickets, local
configuration data and input received from a peer.

In any of these scenarios, except ``no expiration,'' applications must
be able to accommodate the occurrence of a no-longer-valid context,
effectively renewing by initiating a new one.  It was suggested as a
possibly useful extension for init_context or an alternative routine
thereto to be able to accept an existing context handle as input for
renewal through establishment of a new context, but no detailed
exploration or conclusion on this suggestion was reached.

A prospect of ``soft expiration,'' where advisory errors would be
received at a point in time before the context no longer operated, was
discussed but rejected as introducing unneeded complexity and being
ineffective for recovery after a context has been idle across both of
its ``soft'' and ``hard'' expiration times (e.g., after a user walks
away from a terminal, returns sometime later, and attempts to resume a
session).  It was also observed that an application desiring a ``soft''
warning could easily pass a time value appropriately less than the
context_time output as received from init_sec_context to an OS-specific
timer facility outside GSS-API.

In initial discussion relative to the Kerberos mechanism, popular
sentiment favored no expiration, but a range of views were expressed.
Bill Sommerfeld noted that DCE enforces hard expiration (with some time
windowing), but that this appeared more feasible in the DCE RPC
environment where RPC calls are typically short-lived than in the
general GSS-API case.  In DCE RPC, expiration is enforced only for call
establishment, not within an already-established call.  Ted Ts'o
asserted that expiration should not be enforced for at least the class
of rlogin-like applications, to avoid disrupting outstanding
associations.  P. Rajaram also argued that enforced expiration was
unacceptably disruptive for certain applications, and that advisory
expiration was not a useful service for GSS-API to provide; Bill
Sommerfeld observed that advisory expiration could be a convenient
timing service, but that the motivation did not appear compelling.
Piers McMahon observed that context expiration did not enable a useful
policy enforcement mechanism, recognizing that use of all GSS-API
facilities is at an application's discretion.

Jeff Schiller proposed that no context should last forever, and that for
the Kerberos mechanism the expiration time should be no later than the
expiration of the ticket(s) which are used to establish the context;
other inputs (e.g., caller request, configuration) could result in an
earlier expiration time.  P. Rajaram argued that context expiration
should not be forced by ticket expiration times, but should instead be
based on an administratively-configurable parameter.  After active
discussion, Jeff's approach was accepted as our working proposal.
Rationales discussed included:  (a) programs like rlogin were not likely
to be using GSS-API, for reasons of performance in character-at-a-time
applications, and (b) applications for which expiration was unacceptable
could perform their own encryption outside GSS-API, possibly using a
GSS-API context as a means to securely transfer their own keys.  Mailing
list discussion on context expiration topics is continuing.