DataMuseum.dk

top - metrics - download

    Length: 15830 (0x3dd6)
    Types: TextFile
    Names: »cat-minutes-91nov.txt«

└─⟦4f9d7c866⟧ Bits:30007245 EUUGD6: Sikkerheds distributionen
    └─⟦this⟧ »./papers/IETF-drafts/cat-minutes-91nov.txt« 

TextFile

CURRENT_MEETING_REPORT_


Reported by John Linn/DEC

CAT Minutes

The meeting began with a review of the planned agenda.  The first
session was devoted to mechanism-oriented discussion, including
presentation and discussion of public-key Distributed Authentication
Security Services (DASS) architecture and consideration of weaker-level
authentication schemes which might be considered in support of CAT. The
second session was primarily devoted to interface questions and issues
pending from the Atlanta meeting.

To this point, CAT has emphasized authentication mechanisms which
provide authentication in terms of global names but which also requiring
deployment of significant supporting infrastructure.  Interest has been
expressed in enabling entry to CAT through simpler alternative
mechanisms (e.g., passwords, hand-held authenticators, Yellow Pages
(YP)), which generally authenticate in terms of local (per-host) names
rather than a global structure.  This prospect was controversial for two
basic reasons:  (1) in terms of the level of portability that would
actually be supportable for subsequent migration to stronger mechanisms,
and (2) because of concern that support within CAT could result in
institutionalizing the current weak state of authentication within the
Internet.  Evaluation and debate on these questions will continue.

DASS Architecture

Charlie Kaufman gave a presentation on the DASS architecture, which was
recently submitted to Internet-Drafts and accompanied by a letter from
Digital Equipment Corporation to the IAB ceding change control to the
IETF process.  The general scope was described as strong mutual
interactive authentication, with functionality analogous to Kerberos
(V4) but extended for elimination of the on-line Key Distribution Center
(KDC), limitation of dictionary attacks against passwords, delegation
support, hierarchic realm support, and support for various types of
principals (user, node, combination).  A login agent protocol using two
hash algorithms was incorporated to provide password guessing
protection.  DASS fits under the GSS-API, providing all CAT services as
well as additional functions.

DASS credentials cannot, if intercepted, be used to permanently
impersonate the principal they represent.  Temporary impersonation (for
credentials' lifetime, normally corresponding to the duration of a login
session) is possible in the case of an overrun workstation.  It was also
observed that execution of rlogin with the delegation option set results
in transfer of credentials to the rlogin target, and concern was
expressed that this poses danger in the case of a temporarily unattended
workstation.

Several aspects were contrasted against Kerberos.  DASS tokens are built
by using a certificate chain and the target's public key, but repeated

                                   1
\f






use of public key operations is not needed to build successive
authenticators on the same context.  Address data is placed into the
authenticator, not the predecessor ticket, permitting a deferred,
application-specific binding.  Timestamps and Kerberos-like
authenticator caches are employed to determine authenticator acceptance.

The motivation for DASS's login agent was questioned.  This agent was
described as a means to provide password guessing protection; it was
noted that other key and password protection schemes can also be used,
offering different tradeoffs.  The absence of Certificate Revocation
Lists (CRLs) from the architecture was also questioned; it was noted
that the intent was to trust the certificate store as a primary and
rapid revocation mechanism, leading to a discussion of the recognized
(though not currently implemented) need for authentication of the
certificate store.  It was also noted that hybrid models accommodating
CRL as well as store-based revocation were also possible.

The relation between DASS and Privacy-Enhanced Mail (PEM) was discussed.
At the moment, DASS diverges from the most recent PEM selection of
signature algorithm representation within X.509 certificates; DASS will
likely align with PEM. Different hierarchic traversal rules are employed
(including DASS's use of uplink as well as downlink certificates), but
DASS and PEM should be able to use a common infrastructure.  Sharing of
keys and certificate stores should also be possible, given resolution of
credential management issues.

The DASS usage of uplink as well as downlink certificates has trust
implications, and builds on a premise that closer points in the trust
hierarchy will generally be viewed by users and administrators as more
trusted than more remote points.  Pairwise cross-certification makes it
possible to manifest pairwise relationships between different
Certification Authorities (CAs), even if remote from each other in the
namespace.  Compromise of a high-level CA can compromise a large number
of authentication paths, but does not impact local or cross-certified
authentications lower in the tree.

DASS futures include:  DASS/PEM alignment, replacement of the
Certificate Distribution Center (CDC) with a standard directory,
serverless ``PEM-like'' modes of operation in which certificates are
transferred between peers, and supplemental options to the login agent
mechanism, allowing different security vs.  convenience tradeoffs (it
was noted that standardization in this area, while useful, is less
critical than standardization of tokens.  A question arose as to whether
DASS and PEM should share long-term private keys, given DASS's goal of
minimizing such keys' exposure and PEM's requirement (unless, e.g., a
password is demanded for each processed PEM message) to keep such keys
available and accessible for use.  Questions also exist about the
logistics of infrastructure sharing with PEM.

Discussion was given to revocation, and how storage and use of CRLs
could reduce the need to trust the certificate store.  It was asserted
that store- based revocation is better suited to rapid revocation (e.g.,
of a terminated employee) than is the (generally schedule-based) CRL
model.  While unscheduled CRLs can be generated at any time, it is hard

                                   2
\f






to assure their propagation to all necessary points.  Multi-tiered
revocation, including CRLs for highly trusted mid- to long-term
revocation and store-based short-term revocation, may be an appropriate
hybrid.

Discussion was given to partial (limited) delegation.  It is desirable
to constrain the set of delegated rights, but difficult to predetermine
a useful set of restrictions to be supported or to identify what rights
particular servers will require in order to carry out user requests.
Group affiliations are one possibility (as employed, e.g., in the OSF
DCE). It was noted that delegation crosses the boundary from
authentication towards authorization.  Kerberos V4 requires password
re-entry to delegate; in V5, login-time flags permit various
alternatives, but there is yet little operational experience with what
flag options will be most used.  Vint Cerf cited a digital library
service example, motivating the need for delegation by the fact that a
requester cannot generally determine where actions must be taken in
order to satisfy their requests; for this example, a controllable
charging right is desired.

Lower-Function Mechanisms

There are a large range of authentication schemes with lower function
than the powerful cryptographic schemes so far emphasized within CAT. A
key controversial question arose:  should such schemes, even at the
level of unprotected passwords, be construed or explicitly supported
within the CAT model?  Arguments in favor include easy caller adoption
with potential migration path to later use of stronger mechanisms.
Arguments opposed include technical issues which could constrain later
migration, and the prospect that institutionalization of weak mechanisms
could in fact deter deployment of stronger security mechanisms within
the Internet (conflicting with the goal of facilitating deployment of
stronger authentication within the Internet).

In discussion, most working group attendees opposed recommendation of ]
unprotected passwords as a CAT mechanism.  It was observed, for example,
that ``CAT should provide security services matching caller
expectations'', and that extension down to the level of unprotected
passwords was not perceived as k qualifying.  There was also an
assertion that CAT integration within protocol implementations was
unlikely to be performed if no security benefits would directly result.
Extension to intermediate mechanisms providing enhancement over
passwords, but requiring little infrastructure for deployment, was
received more positively.

Many members of the lower-function mechanism class raise technical
concerns for CAT integration.  They do not normally authenticate in
terms of global names, but rather in terms of names local to the
verifier system.  While it is fairly straightforward to distinguish
mechanisms to callers in terms of the security services they provide,
there is no comparable means to rank mechanisms providing a particular
service in terms of the quality with which that service is provided.  It
was observed that different classes of mechanisms might be admissible
into mutually-trusting threat environments such as those for which

                                   3
\f






RFC-931 was designed.  It may be appropriate to recognize the
distinction and ordering between two suggested equivalence classes:
``non-disclosing'' (cryptographically strong) and ``disclosing''
mechanisms, even though metrics for ordering of strengths within these
classes are lacking.

Accommodation of hand-held authenticators and like technologies within
CAT would require the ability for such a CAT mechanism to call out for
user input at context establishment time.  The input required varies on
a basis which is target-specific, in contrast to Kerberos or DASS
credentials which are typically established in conjunction with user
login in a target-independent fashion.  Simple passwords could also be
user-entered at context establishment time on a target-specific basis,
or an encrypted password file (containing multiple target-specific
entries) could be unlocked at credential establishment time.

It was noted that Kerberos is the only presently-proposed mechanism
which does not require the use of patented public-key technology.  NNTP
(not developed on a product basis) was cited as an interested client
effectively barred from access to such technology.  [Note:  Plans
announced at the IETF Privacy Enchanced Mail Working Group by RSA Data
Security to provide a freely-available public-key implementation may
modify this situation, should this implementation's interfaces and
characteristics prove suitable as a basis for CAT usage.]  It was noted
that users lacking source code for their operating systems are impeded
from authentication system integration requiring, e.g., modification to
/bin/login.

A desire was voiced for a ``Strategic Plan for CAT Deployment'' document
to be developed, documenting the pieces and steps required for this
process.  It was noted that a perception exists that integration of CAT
is being construed within the IETF as a prerequisite for advancement of
an application protocol on the standards track, and that other working
groups may not be fully cognizant of CAT scope, directions, and
schedule.  It was also noted that a claim of ``CAT conformance'' is not
in itself meaningful, but that ``CAT with specific mechanism(s)'' is
well-formed.

Discussion of Issues List

We discussed identified issues flagged on the CAT mailing list, and
considered the interface specification suitable for advancement as a
basis for follow-on work.

[(D1) Suggestion that CAT mechanisms should incorporate additional token
exchanges into context establishment sequences so as to avoid returning
COMPLETE status before it is known that the CAT peer has successfully
accepted the context.]:  It was accepted as a desirable recommendation
to mechanism designers that context establishment should be
self-contained and modular, providing full bidirectional peer-entity
authentication (and assurance of cryptographic token acceptance) without
need to invoke CAT per-message protection primitives in order to
validate context setup.


                                   4
\f






[(D2) Desire to make identification of set of intermediaries involved in
context establishment available to CAT caller.]:  Such a CAT extension
would be technically feasible, but its value for mechanism-independent
interpretation was questioned.  Since its primary advocate was not
available for discussion, the topic was tabled for the present.

[(D3) Suggested optional overlay of calls to integrate CAT
authentication with data stream calls, analogous to Kerberos' send_auth
interface.]:  No new status was reported on this work item.

[(D4) Discussion of alternative coding schemes (character sets, etc.)
for CAT tokens.]:  This suggestion had been intended as a means to
support CAT-based integration of password mechanisms in a manner which
would be interoperable with non-CAT peers implementing like schemes.  It
was recognized in discussion that CAT's scope cannot extend in general
to interoperation with peers not supporting CAT and its token exchange
paradigm.

[(D5) Specifics of shared-mechanism determination approaches, including
combinations of negotiation, directory entries, configuration data, and
user/caller input.]:  It was proposed that negotiation schemes be
considered in follow-on work on an identified ``negotiated'' mechanism,
which would itself exchange tokens in order to identify a shared
mechanism and then perform authentication under that shared mechanism.

[(D6) CAT naming portability issues and approaches, in advance of
IETF-level agreement as cited in (H1)]:  Discussion explored aspects of
this problematic area and of the GSS-API facilities incorporated for
portability support absent agreement on a common global naming format.

Attendees

Jim Barnes               barnes@Xylogics.COM
Charles Bazaar           bazaar@emulex.com
Larry Blunk              ljb@merit.edu
Thomas Boorman           tmb@lanl.gov
David Borman             dab@cray.com
Ken Carlberg             carlberg@cseic.saic.com
Lida Carrier             lida@apple.com
Vinton Cerf              vcerf@nri.reston.va.us
Jim Clifford             jrc@lanl.gov
Robert Cooney            cooney@wnyose.nctsw.navy.mil
Curtis Cox               ccox@wnyose.nctsw.navy.mil
Stephen Crocker          crocker@tis.com
Jim DeMarco              jdemarco@ftp.com
Steve Dusse              spock@rsa.com
Barbara Fraser           byf@cert.sei.cmu.edu
L. Dain Gary             ldg@cert.sei.cmu.edu
Jisoo Geiter             geiter@gateway.mitre.org
Joseph Godsil            jgodsil@ncsa.uiuc.edu
Neil Haller              nmh@bellcore.com
Charles Kaufman          kaufman@dsmail.enet.dec.com
Stephen Kent             kent@bbn.com
Peter Kirstein           kirstein@cs.ucl.ac.uk

                                   5
\f






Deidre Kostick           dck2@sabre.bellcore.com
John Linn                linn@zendia.enet.dec.com
Ellen McDermott          emcd@osf.org
Glenn McGregor           ghm@merit.edu
Bill Melohn              melohn@auspex.com
Andy Nicholson           droid@cray.com
Brad Passwaters          bjp@sura.net
Robert Purvy             bpurvy@us.oracle.com
Jeffrey Schiller         jis@mit.edu
William Simpson          Bill_Simpson@um.cc.umich.edu
Richard Smith            smiddy@pluto.dss.com
Sven Tafvelin            tafvelin@ce.chalmers.se
Theodore Tso             tytso@mit.edu
Sally Wilkins            sfw@lanl.gov
Preston Wilson           preston@i88.isc.com
C. Philip Wood           cpw@lanl.gov



                                   6