Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/cat/cat-minutes-96jun.txt

Text File | 1996-10-07 | 22KB | 421 lines

Editor's note:  These minutes have not been edited.


COMMON AUTHENTICATION TECHNOLOGY (CAT) MINUTES,
Montreal IETF, June 1996, reported by John Linn (OpenVision).

The CAT WG met for two sessions at the Montreal IETF, on Wednesday
and Thursday.

DOCUMENT STATUS REVIEW

The status of CAT WG Internet-Drafts was summarized.

The former draft-ietf-cat-kerb5gss-07.txt is now RFC-1964.

Two CAT WG I-Ds (draft-ietf-cat-spkmgss-06.txt, draft-ietf-cat-gssv2-
06.txt) have completed IETF Last-Call and are now in IESG hands. Jeff
Schiller (MIT, Security Area Director) indicated that he expected the
IESG to vote on these drafts on 11 July and/or 25 July for advancement to
Proposed Standards, and that he anticipated positive results.
Regarding SPKM, Jeff noted that the impasse which had placed this
draft on hold for an extended period in response to public-key licensing
issues appears to have been resolved.

One I-D (draft-ietf-cat-snego-01.txt) had been offered for CAT WG
Last-Call. This draft, concerning the GSS-API negotiated mechanism,
had received only limited review and comment during the WG Last-
Call period proposed on the mailing list, and the apparent sense of the
meeting was, therefore, that no strong consensus for advancement had
yet been achieved. The comment period was extended to 20 July to
solicit review by additional WG members, and the draft's status will
be reviewed thereafter. A suggestion was made that, if active
involvement remains limited, the draft should be considered for
Experimental status.

Status of other CAT WG I-Ds:

- draft-ietf-cat-sesamemech-00.txt: Was to have been revised June
1996, per Tom Parker (ICL)'s 29 May E-mail to CAT list.
Approximately 4 attendees indicated familiarity with the draft.
Stephen Farrell (SSE) commented that a revision will be issued in
approximately 2 weeks, responding to comments which had been
received.

- draft-ietf-cat-xgssapi-acc-cntrl-00.txt: To be revised June 1996, per
Tom Parker's 29 May E-mail to CAT list. Approximately 3 attendees
indicated familiarity with the draft. Denis Pinkas (Bull) will send a
message to the mailing list, soliciting broader review and comment.

- draft-ietf-cat-wingss-00.txt: To be revised by Piers McMahon (ICL)
and/or Ted Ts'o (MIT), per 3 June E-mail to CAT list. Ted Ts'o is willing
to take this draft and update it to reflect GSS-V2 and to support both
Win16 and Win32 environments, assuming that the nroff source can be
obtained (John Linn and Ted Ts'o to coordinate with Piers McMahon).

- draft-ietf-cat-gssv2-cbind-01.txt: I-D revision in progress; July
availability target.

- draft-ietf-cat-kerberos-pk-init-01.txt: Revised Internet-Draft posted.
Further discussion was held later in the meeting (see separate section of
minutes).

- draft-ietf-cat-ftpsec-08.txt: I-D revision in progress. I-D currently
expired; to be renewed or revised.

- Pending revision of RFC-1510. Revision targeted for early July.
Further discussion was held later in the meeting (see separate section of
minutes).

- draft-ietf-cat-kerberos-passwords-xx.txt (draft currently expired.)
Approximately 8 attendees indicated familiarity with the draft. Glen
Zorn (Microsoft), the draft's editor, indicated that Denis Pinkas'
comments were the only ones currently pending against this document,
and some mailing list discussion ensued during the meeting week. Denis
considers the draft a framework, which is not in itself sufficient to
support independent implementations, but Glen believes that the
document is suitable as a basis for implementation and essentially
ready for advancement. The draft is to be renewed, made available to
the list, or revised within two weeks as a basis for continuing
discussion.

GSS TOKENS IN CONNECTIONLESS ENVIRONMENTS

Denis Pinkas gave a presentation on a proposed approach for use of GSS
tokens in connectionless environments. His goal was to define procedures
for using GSS tokens in a special manner, only for use with mechanisms
supporting this optional technique. Use of this approach is restricted to
mechanisms which can establish a context with a single context
establishment token and which can send a protected message along
with that token. Such mechanisms cannot, therefore, engage in
challenge/response interactions at context establishment time. It was
noted that mechanisms already exist for which single-token context
establishment cases can be valid; this facility allows usage of this
characteristic, when known, to be optimized. Ted Ts'o criticized such
usage as intrinsically non-portable across the general set of GSS-API
mechanisms and thereby contributing to mechanism specificity on the
part of callers.

Considering specifics of Denis' proposal, his suggestion was to send a
fixed-length header (64 bits) in front of tokens, to be used as a reference
to cached tokens. The header would be a 32-bit Unix time concatenated
with a 32-bit random number, and would effectively be used to define a
security context and make subsequent references to it. Denis suggested
that return of GSS_COMPLETE status from an initial
GSS_Init_sec_context() call could be used to recognize a mechanism's
inclusion of the caching support facility, without requisite changes to
the current GSS-V2 document, but John Linn observed that this would be
ambiguous, given the fact of currently-existing mechanisms for which
single token context establishment sequences were valid. Marc
Horowitz (Cygnus) asked what standards status was desired for this
proposal; Denis did not have a specific position on this question. Marc
also commented on his perception that the proposal's goal was more
appropriately construed as an application issue than a security issue.

Ted Ts'o commented that his perception of the proposal's motivation
was targeted towards support for an "academic definition of
connectionless protocols", and further stated a premise that, by design
and intent, replayed context establishment tokens (or references
thereto) should be rejected. Bill Sommerfeld (HP) commented that he
didn't view the proposal as simplifying to applications, and suggested
that GSS usage in connectionless environments requires instead
assignment and management of IDs by a layer above. An attendee asked
whether a facility such as Denis proposed might be applicable to usage
in CGI proxies, but no clear conclusion was apparent; Simon Cooper
posed the question of whether GSS-IDUP would be suited to satisfy
such requirements.

IDUP

Carlisle Adams (NorTel) led a discussion on current status and issues for
IDUP. Approximately 6 attendees indicated that they were tracking
the documents. Related drafts: draft-ietf-cat-idup-gss-05.txt, draft-
ietf-cat-idup-cbind-02.txt, and
draft-ietf-cat-pim-01.txt. Carlisle provided an overview of IDUP
facilities, and then summarized and responded to a set of questions
which he'd received about IDUP from various sources. Carlisle's
questions and answers about IDUP rationale (paraphrased here by
editor):

- Q: We already have MOSS, MIME, etc, and applications now using
these don't need a new API, so is it useful to define one? A: All of these
protocols exist, and don't appear likely to converge, so an API enables
useful portability.

- Q: I've heard that IETF doesn't do APIs, so why is this a valid
activity? A: IDUP's scope is consistent with GSS-API, which is an
accepted IETF activity.

- Q: I'm just interested in authentication and confidentiality, so why
does IDUP provides functionality which I don't really need? A: If not
already needed, non-repudiation facilities will be needed soon in order
to support electronic commerce.

- Q: IDUP looks too complicated. Can't it be simpler? A: In simple cases,
many parameters accept default and "don't care" values.

David Kurn (Tandem) commented that, in working with IDUP, he had
encountered needs to use mechanism-specific facilities more frequently
than with base GSS-API; he acknowledged, however, more detailed
familiarity with IDUP than with base GSS. Denis Pinkas commented
that he would like to remove mechanism-specific parameters from the
IDUP specification. Carlisle asserted that selection of the default
mechanism allows a sufficiently rich service to be useful.

Technical issues were discussed regarding the facts that (1) some IDUP
mechs (PGP/MIME, e.g.) do their own transport encoding, and (2) that
interoperability between IDUP-based and non-IDUP peers was
functionally desirable but might not always be achievable. The current
IDUP specification uses the same token framing as is defined for base
GSS-API; it was suggested that perhaps IDUP framing should become
7-bit safe. Ted Ts'o requested more clarification about how IDUP mechs
are to be used.

Minor changes have been made in the idup-05 draft, including new
"File_Protect" and "File_Unprotect" calls which reference file
handles. Carlisle commented that he had recommended against
inclusion of these calls, which were incorporated in response to
implementor requests. The apparent sense of attendees was that these
file-level calls should be deprecated for standardization purposes.

Regarding status of IDUP mechanism specifications, the recent and
current P7IM I-D describes one IDUP mechanism. Carlisle suggested
that PIM should transition to Experimental status; Informational
and/or Historic status was suggested by others. Carlisle stated that a
specification for a MOSS IDUP mechanism spec may be coming by
December and that implementation work is underway. Nortel has a
currently-internal MSP IDUP mechanism spec; some interest was
indicated by attendees in publication of this material as an
Informational RFC if the text can be made available.

Re implementation status: most implementations have been done by
Nortel, and are not public domain, but interoperability testing is
solicited. Implementation activity re the PEM-based mechanism is on
hold, an MSP implementation is complete, and PKCS#7 alpha code is
complete; MOSS-based mechanism (not by Nortel) development is in
progress. Carlisle anticipates that a PGP mechanism will be done, but
this work hasn't started yet.

SASL

John Myers (CMU) led a discussion on his SASL draft (successor to RFC-
1731), which about 4-5 attendees have been following. SASL adds a
command to a protocol to identify a named mechanism (Kerberos V4,
GSS-API, SKEY). A SASL server and client exchange a sequence of
challenges and responses. Upon completion, the peers have negotiated
authentication, an authorization identity (username), protection
mechanism, and a buffer size. If a session layer is negotiated, it applies
to the rest of the protocol session.

Changes since RFC-1731: specification of how to apply to protocols
other than IMAP, use of the service name namespace as defined for GSS
host-based services, establishment of a first-come, first-serve registry
of mechanism names. John Linn's comments on SASL were the only set
which had so far been posted to the CAT mailing list.

Marc Horowitz asked, "why wasn't SASL being discussed in the TLS
WG?" John Myers responded that TLS approaches define and use new
port numbers, while SASL (like GSS-API) is intended for integration
within a self-contained protocol. Denis Pinkas offered some
terminology comments, and referenced the fact that security is
explicitly excluded from the ISO session layer and therefore suggested
renaming the SASL specification. Usage and implementation: John
Myers has done POP3 and IMAP with Kerberos V4; Ted Ts'o said that
GSS-ized POP is being considered; someone else commented that he's
implemented SASL with an "SSL-like" mechanism; it was reported
that Ned Freed was implementing with Diffie-Hellman and that an
SKEY implementation has also been done. John Myers commented that
several other activities, previously blocked pending advancement of
GSS-V2, are now blocking on advancement of the SASL document.

KERBEROS V5 BETA 6 UPDATE

Ted Ts'o (MIT) presented a status summary of KerberosV5 beta 6, which
was released on 6 June 1996. The FTP reference is ftp://athena-
dist.mit.edu/pub/kerberos/README_BETA6. This version supports
UNIX (with OSF/1, SunOS, Solaris, and SGI known to work) and
Win16; Win32 and Macintosh support are on the way but not in beta 6.
FSF's autoconf facility is used. Client interfaces are stable; work is
currently in progress to incorporate an administration server donated by
OpenVision, which will be integrated into the distribution as of beta 7.
A Kerberos V4 backward compatibility server is available now, so it is
possible to drop in a V5B6 KDC as a replacement for a V4 KDC without
making client changes. GSSAPI V2 support is "almost but not quite
there"; the most recently added V2 calls are not included. It is still
necessary to fix a previously-typo'd reference to an OID (which had
been unintentionally usurped from the U.S. General Services
Administration (GSA) arc, but which, fortunately, was being
transitioned away from). Code for this fix has been written but is not in
the beta 6 distribution. Beta 6 has the beginnings, but not the
completion, of triple-DES support.

SUNSOFT WORK ON GSS-API SECURITY FOR ONC RPC

Mike Eisler (SunSoft, [e-mail]) gave a talk on SunSoft's work
on GSS-API Security for ONC RPC, which is being formally discussed
within the ONC RPC working group. The new authentication flavor is
called RPCSEC_GSS. An Internet-Draft is being written, and the work
will also be the subject of a presentation at the USENIX Security
Symposium in July.

The work was motivated by the fact that previously existing ONC
security flavors were weak, and had designed-in (unintended)
limitations. The former AUTH_UNIX (now AUTH_SYS) supported
only a fixed number of UNIX group IDs (gids), a limitation which
conflicted with operating system practice and was not extensible in a
standards-compatible fashion, AUTH_DES had too small a key, and
neither provided authentication or integrity. Mike believes that a
GSS-based solution satisfies requisite requirements. Most GSS-level
interfaces are exposed to ONC applications, but the GSS-API channel
binding facility wasn't well understood and was therefore omitted. The
rpc_gss_seccreate() call takes, among other arguments: name of target
service, string name of mechanism, QOP value. Using GSS-V2 calls, a
mapping can be accomplished from GSS mechanism-provided names
into UIDs; this library may be generalized for broader usage by non-
RPC GSS-API callers.

The RPCSEC_GSS protocol is session-based like AUTH_DES and
AUTH_KERB, and is based on OpenVision's prior AUTH_GSSAPI
work. Context setup iterations are supported, with RPC-layer critical
sections around GSS calls. Data copies are optimized away for the
integrity-only verification case, using gss_sign(). When privacy is
provided, gss_seal() is used; both integrity and privacy cases prepend
sequence numbers to data. The server side verifies the following data:
version number of RPCSEC_GSS, service, context handle, sequence
number, checksum, and maintains a sequence number window. The ONC
level doesn't pass RPC credentials with replies; the verifier contains a
signature (generated with gss_sign()) of a request's sequence number.

Mike presented a graph of observed performance; authentication-only
was almost the same as AUTH_NONE, integrity (with Kerberos V5,
DES_MD5) was about half the authentication-only throughput, and
privacy about half the integrity throughput. Mike commented that he
would like the GSS-API C bindings to accomodate operations which
didn't require buffer copies, and noted that cryptographic processing
bandwidth dominates for software implementations but that data
copies can assume greater relative significance in hardware-based
implementations. Martin Rex (SAP) commented that he would like
string-level references to mech OIDs.

A general comment was made in discussion that it would be valuable to
unify different references to crypto algorithms in different contexts
within the IETF. In RPCSEC_GSS, a shorthand table is used to
translate text strings into mechanism OIDs. Comment (Marc Horowitz):
it would be preferable to use native GSS constants for, e.g., QOP
representations. Initially, Sun plans to do its own multi-mechanism
packaging, but this might later be generalized to a more general
binding facility.

KERBEROS PK-INIT DISCUSSION

Brian Tung (ISI) led discussion on the Kerberos public-key initial
authentication (pk-init) draft, co-authored by Cliff Neuman, Brian
Tung, and John Wray. Changes made in the -01 version were
summarized. Pending issues include: incorporation of separate keys for
encryption and signature (accepted), addition of signature support for
DSS, and others. A new draft is to be submitted in 4-6 weeks; other
ongoing plans include prototype implementation, integration with
Kerberos V5 beta7, attempted demonstration of interoperability with
DCE public-key login, targeted advancement to Proposed Standard.
Bill Sommerfeld is also implementing pk-init.

It was observed that pk-init affects initial ticket acquisition only, and
therefore provides (for Kerberos purposes) the same level of single sign-
on (SSO) functionality as other login protocols. Currently, a client must
sign requests, and must decrypt responses. Brian Tung believes that
Denis Pinkas' issues have been addressed; John Linn suggested that a
cover message summarizing changes be sent along with (or before) the
new I-D. Cliff Neuman requested a WG Last-Call by end of summer.

RFC-1510 UPDATE DISCUSSION

Cliff Neuman led discussion on the ongoing update to RFC-1510.
Identified purposes: integrate previous errata, update assigned
numbers, align specification with implementations regarding
encryption types, add new encryption types for triple-DES and SHA,
explain more clearly often-misunderstood aspects of protocol,
highlight often-overlooked areas of protocol, and explain means
through which certain hooks are intended to be used by separate
specifications. This update will not integrate OTP or PK-INIT, but will
list PA-DATA identifiers therefor.

Cliff posed the following questions (also to be sent to CAT list,
soliciting inputs for phase-in strategies):

- Should/must compliant implementations support triple-DES SHA
encryption? Serious export problems were noted, suggesting that this
shouldn't be a "must". Marc Horowitz asserted that single-DES is
sufficient as an interoperability basis. Apparent sense of room:
"should".

- How much to deprecate single DES MD5, single DES MD4, single-DES
CRC? Apparent sense of room: "deprecate MD4, CRC, maintain single
DES MD5 as must".

- Where all existing implementations implement one of the deprecated
methods incorrectly, how do we fix?

Draft Internet Standard status requires independent implementation of
all features, and many Kerberos implementations share common code.
While this characteristic could complicate validation of
independence, Jonathan Trostle (CyberSAFE) and Stephen Farrell
commented that the CyberSAFE and SESAME implementations of RFC-
1510, respectively, were independent of the MIT code base. Ted Ts'o
further commented that Richard Ward at Microsoft was also working
on an independent implementation of RFC-1510.

Lively discussion ensued about migration to new cryptographic
algorithms. One suggestion for a "sunset clause", pre-establishing a
date beyond which use of particular algorithms would be discouraged,
was made. Glen Zorn argued for backward compatibility as a primary
requirement, and that technical decisions should not be driven by export
laws. Marc Horowitz asserted that the successor to RFC-1510 shouldn't
attempt to rank algorithms by strength. Ted Ts'o noted that the cross-
product of all possible algorithm choices, independently defined,
would imply a need for large numbers of specifications, given the means
through which algorithm usage is structured in Kerberos. This dictated
a need for volunteers to specify new e-types. Jonathan Trostle
volunteered to provide new e-type definition, and also commented on a
possible need for definition of a general intra-Kerberos negotiation
facility which is not currently present; Ted questioned the requirement
for such a facility. No negotiation extension is currently planned,
though the errata will discuss some implementation-level issues,
related to key types and e-types, which concern a limited level of
negotiation-related function.

CANDIDATE FUTURE WORK ITEMS

The concluding 15 minutes of the meeting were devoted to discussion of
possible future work items for the CAT WG, and determination as to
whether corresponding motivated volunteers were available. The
following candidate areas were identified. Unless noted otherwise, no
volunteers were identified to drive follow-on activities:

- Further actions, if any, required to support binary compatibility
between GSS-API implementations: it was hoped that the upcoming
GSS-V2 C bindings document will satisfy requirements in this area and
was encouraged that it be reviewed from this perspective.

- Asynchronous version of GSS-API interface

- Further work on authorization extensions

- Facilities to support installation-level configuration of multi-
mechanism support using mechanism modules supplied independently
by different providers

- Kerberos extension for inter-realm authentication via public-key
technology (Brian Tung and Jonathan Trostle interested)

- Kerberos extension for intra-mechanism negotiation of algorithms
(Jonathan Trostle interested)

- Streams-oriented interface: it was suggested that John Myers' SASL
interface be reviewed for sufficiency and appropriateness in this area.

- SSH GSS-API mechanism definition: given that SSH is becoming a
visibly popular technology (and is distributed from crypto-friendly
Finland), there might be interest in constructing a GSS-API mechanism
layered on SSH's underlying cryptographic technology. Ted Ts'o is
discussing this prospect with Tatu Ylonen, keeper of SSH.