Minutes for Montreal Common Authentication Technology (CAT) meetings

[John Linn <[e-mail]>]

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.