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

Text File | 1993-08-21 | 11KB | 269 lines

CURRENT_MEETING_REPORT_

Reported by John Linn/Geer Zolot Associates and Sam Sjogren/TGV

Minutes of the Common Authentication Technology Working Group (CAT)


The CAT Working Group met for two sessions at the Amsterdam IETF,
discussing (in about equal proportion) general CAT issues and FTP
security integration.


Review of CAT Activities

We reviewed the status of CAT-related Internet-Drafts:  ``Generic
Security Service Application Program Interface'' (GSS-API) and ``Generic
Security Service API : C-bindings'' are in the hands of the RFC Editor
pending advancement to Proposed Standard status, as is ``The Kerberos
Network Authentication Service (V5).''  The Kerberos V5 GSS-API
implementation has not received recent development effort, and is not
currently compliant, but a plan to make volunteer resources available is
being explored.

Chuck McManis discussed CAT-related activities ongoing at Sun
Microsystems.  Sun currently supports Kerberos V4, and plans to migrate
to V5.  Kerberos is invoked (using its native interface, rather than
GSS-API) from RPC. Separate work on layering RPC atop GSS-API had been
ongoing at Sun, but has not yet yielded conclusive results.  One of the
US National Laboratories had ported beta 2 of Kerberos V5 to Solaris,
and Sun is working with the resultant code base.


CAT Technical Discussion

Two proposals for incremental changes to the GSS-API documents were
considered:


  1. A terminology change in response to a request from X/Open, renaming
     the per-message protection primitives from GSS_Sign to GSS_GetMIC,
     GSS_Seal to GSS_Wrap, GSS_Verify to GSS_VerifyMIC, and GSS_Unseal to
     GSS_Unwrap (to avoid conflict with other usage, without change to
     function, preserving (though deprecating use of) existing names in
     existing code for backward compatibility) was tentatively accepted
     pending e-mail review.

     In evaluating the request and considering alternatives, it was
     observed that ISO's usage of the term ``seal'' echoes the notion of
     applying a wax seal to a document.  It was also observed that the
     current Kerberos V5 implementation of GSS_Sign emits a token
     containing the entirety of the input message rather than just a
     signature.

                                   1





     It was also observed that no GSS-API per-message protection
     interface currently exists to provide confidentiality without
     integrity, and post-meeting review (GSS-API specification, Section
     1.2.2) confirmed the related point that mechanisms indicating the
     availability of per-message confidentiality services are also
     expected to indicate and offer per-message integrity.  No
     definitive conclusion was reached about the level of demand for
     confidentiality without integrity.

  2. A proposal to add GSS_set_default_cred and GSS_lookup_default_cred
     routines was rejected for reasons of semantics which were
     considered to be environment-specific (though considered as a
     likely initial entry in a set of extensions for POSIX and like
     environments).  Much of the motivation for this feature derives
     from a desire to control the set of credentials which will be
     transferred by inheritance across the UNIX fork operation.  It was
     observed that it would be difficult to implement the
     set_default_cred function within the current Kerberos V5 code base,
     and that different implementors could implement the proposal as
     defined with conflicting semantics which would not support
     application portability.  Given an observation that credentials
     structures are ephemeral, use of acquire_cred with (non-ephemeral)
     principal names as arguments was recommended as an alternative
     approach which would survive UNIX forks.

     Chuck McManis expressed interest in using set_default_cred as a
     means to spawn threads using different mechanisms for different
     threads, and saw this as a more critical priority than use of
     different identities within a single mechanism; he also expressed a
     desire that credentials be ``lightweight'' structures.



CAT Follow-On Tasks and Action Items


Follow-on tasks identified were:


   o Kerberos V5 GSS-API mechanism specification and code enhancement;

   o Kerberos V4 GSS-API implementation;

   o ``negotiated'' mechanism definition (a task to which a framework
     discussion authored by Bob Blakely and forwarded to the list was
     considered relevant);

   o CATS stream-oriented overlay definition;

   o documentation of mechanism implementor's guidance/agreements; and

                                   2





   o environment-specific specifications and extensions (e.g.,
     credential inheritance semantics).


Individuals and subset groups were associated with several of these
items.  Activity on the ``negotiated'' mechanism's design was argued as
not being critical at this time; it will assume greater importance once
multiple mechanisms are actively supported.


FTP Security

The discussion on FTP security was moderated by, and this section of the
minutes was reported by, Sam Sjogren.


Review of FTP Activities

Discussions on the CAT mailing list as well as at the Columbus IETF
meeting in March resulted in changes to the specification for security
in FTP. Steve Lunt revised the ``FTP Security Extensions''
Internet-Draft and submitted it to the IETF Secretariat for
announcement.  A list of changes made to the document was also produced
and was sent to the CAT mailing list.  Since Steve was not able to
physically attend the group's meeting in Amsterdam, arrangements were
made to allow Steve to participate via speakerphone.  The list of
changes was the focus of most of the group's discussions.


FTP Technical Discussion

One of the additions to the FTP security document is a specification
using the GSS-API authentication type.  This specification needs to be
reviewed in detail and any problems corrected.  John Linn will
communicate his observations to Steve on this.

Although the interaction of the AUTH, PASS, and USER commands have been
clarified somewhat, it was agreed that the various possible cases
(including those involving users for whom passwords (which should be
protected) may be required in addition to other forms of authentication)
should be more rigorous.

The form of Base-64 encoding used by FTP security has been brought into
line with that used by PEM. One concern is that the length of a Base-64
string is currently unbounded, and that may cause problems for
small-machine implementations.  This will be addressed in the
small-machine discussion on the mailing list.

For the time being, proxy file transfers are deferred.  One of the
effects of this is that the requirements for negotiating session keys
are eased.  However, the negotiating of session keys with the various

                                   3





possible mechanisms should still be investigated to make sure that in
the future we will not be precluded from supporting this feature.

It is necessary for a server to indicate to a client, somehow, what
levels of security are supported (e.g., integrity but not encryption).
Although this has been left purely to the particular mechanism, there is
a feeling that the protocol itself should provide some support for
determination of this when mechanisms themselves do not support it.  So,
a 402 reply code is defined which indicates to a client that ENC and/or
MIC commands are not accepted, thereby allowing a client to probe a
server to determine the levels of security it supports.  Note that this
even allows a server to force the use of privacy but not allow mere
integrity assurance.  This method is authentication-mechanism
independent.

In the case of a server allowing integrity but not privacy, implementors
are encouraged to warn the user that the level of security available is
less than they have requested.

Another potential small-machine issue surfaced in the specification of
buffer size and length for protected file transfers.  Although the
length field in the specification has been reduced from 4 bytes to 2
bytes, thereby reducing the buffer size from 4 gigabytes to 64
kilobytes, even a 64-kilobyte buffer may prove to be a problem for some
small machines.  This issue will be discussed further on the mailing
list.

Instead of the commonly used `rcmd' principal that is usually used with
Kerberized TELNET and R-Utilities, the principal name `ftp' has been
specified for use with FTP security.  There was a feeling that a number
of sites may wish to avoid the additional overhead of creating another
principal for each machine, so there should be some capability to
fallback to use of the `rcmd' principal.  This would appear to be an
issue left to particular implementations and site policy.  Perhaps it
should be mentioned in the Internet-Draft that clients are recommended
to first try the `ftp' principal and if the `ftp' principal does not
exist or the FTP server will not accept the `ftp' principal, then try
the `rcmd' principal.

Various other small changes were made to the Internet-Draft that were
either corrections or clarifications and are not worth mentioning in the
minutes.


FTP Follow-On Tasks and Action Items

There will be discussion on the CAT Working Group mailing list regarding
the buffer size issues and how a small-system implementation may be
affected by large buffers or buffers of indefinite size.

Steve will incorporate the changes that arose from the group's
discussions into the Internet-Draft and produce a new revision of the
document and a list of changes.

                                   4





The most important thing to do at this stage is to gain more
implementation experience.  Sam will solicit implementors through
various e-mail lists and other channels.


Attendees

Matti Aarnio             [e-mail]
David Arneson            [e-mail]
Stefan Braun             [e-mail]
Richard Graveman         [e-mail]
Neil Haller              [e-mail]
Thomas Hutton            [e-mail]
John Johnston            [e-mail]
Nada Kapidzic            [e-mail]
John Larson              [e-mail]
Arjen Lenstra            [e-mail]
John Linn                [e-mail]
Kim Chr.  Madsen         [e-mail]
Chuck McManis            [e-mail]
Clifford Neuman          [e-mail]
John Penners             [e-mail]
Robert Reschly           [e-mail]
Jeffrey Schiller         [e-mail]
Wolfgang Schneider       [e-mail]
Sam Sjogren              [e-mail]
Theodore Ts'o            [e-mail]
Erik Zegwaart            [e-mail]
James Zmuda              [e-mail]



                                   5