Subject: Draft minutes, Adelaide CAT session

From: "Linn, John" <[email-masked]>
Date: Tue, 4 Apr 2000 15:08:12 -0400

Attached are my draft minutes for the Adelaide CAT session. If any attendees
have additions or corrections to offer, please send them no later than next
Monday, 10 April, to support timely submission to the secretariat.

Thanks, ...

--jl

Minutes, Common Authentication Technology (CAT) WG, Adelaide IETF

Reported by John Linn, RSA Laboratories.  Thanks to Cliff Neuman and Ken
Hornstein for providing their notes and slides, which were used as inputs to
preparation of these minutes. 

GENERAL AND ADMINISTRATIVE DISCUSSION

The CAT WG met for one session in Adelaide, with 88 attendees. 

John Linn opened the meeting with a general status overview, handing the
floor to Jeff Schiller (MIT, Security AD) to present an organizational
update. Jeff noted that the IETF today generally prefers tightly
task-focused groups and that CAT's charter has been iteratively evolving for
some time.  He further observed that CAT's original focus was on the common
GSS-API interface, rather than specifically on the Kerberos technology to
which currently active standards-track CAT Internet-Drafts relate.  It has
been decided that the general CAT WG will go dormant, but with the mailing
list to remain available as a forum to discuss progression of existing
non-Kerberos CAT documents.  Kerberos documents are to be transitioned to a
new Kerberos WG, with the intent that its charter be established before the
next (Pittsburgh) IETF and that an initial WG meeting without prior BOF
session will take place there.  Doug Engert (Argonne) has agreed to chair
the group and will be doing so.  Kerberos-related drafts that are ready for
imminent Last-Call, in advance of establishment of the Kerberos WG, can
still go to CAT. 

KERBEROS-REVISIONS AND PKINIT

Cliff Neuman (ISI) presented a status summary on Kerberos-Revisions. A new
Internet-Draft version was recently issued. Significant remaining issues
include: decision on the mandatory variants of 3DES, ticket extensions, and
integration of the referrals draft.  Additionally, some smaller and
editorial issues must also be addressed, and a change summary relative to
RFC-1510 must be prepared.

Updates since the last revision include integrated 3DES options, new
registered types, and various edits, some of which require discussion.
Cliff reported that the current 3DES description integrates all options in a
single parameterized discussion, but that it references currently expired
drafts and material must therefore be adapted from them.  List discussion is
needed to resolve whether or not to use the key derivation variant; Cliff
reported that Microsoft and CyberSafe have tentatively agreed to accept key
derivation, though that some skepticism was observed about its value. Cliff
also reported that some coordination is pending with Microsoft on PAC usage.
List discussion is required on the ticket extensions field, included in the
current draft; Cliff intends to send a message to the list initiating debate
on the benefits and drawbacks of its retention. Further discussion topics
had been introduced on the list: whether policies on adding additional
addresses to tickets should be specified, clarification on case sensitivity
in names.  During the Adelaide IETF week, Cliff's intent was to perform
initial wordsmithing and to initiate the 3DES and ticket extensions
discussions.  He also anticipates referrals text pending from John Brezak
(Microsoft), which will require further list discussion.  Once at least the
two major issues are resolved, WG Last-Call will be requested on
Kerberos-Revisions and PKINIT; given the size of Kerberos-Revisions, John
Linn suggested that an extended WG Last-Call period would be appropriate.  

PKINIT is believed to have come to consensus among active participants, and
to be ready for a parallel last call with Kerberos-Revisions. Recent changes
include: name encoding, application of name constraints, and SignedData and
EnvelopedData structure definitions. Regarding name encoding, the section on
translation between X.500 names and Kerberos structures has been changed and
expanded to specify the translation between general string and UTF8.  A new
structure corresponding to Kerberos PrinicipalName, but with general string
replaced by UTF8String, was defined to enable the use of UTF8 in the
additional name field when Kerberos principal names are embedded in
certificates. Rules were added for checking of a Kerberos PrincipalName
against certificate chains which contain name constraints.  The SignedData
and EnvelopedData structure explanations have been reformatted and slightly
edited for clarity.  The old PKCS#7 data OID has been replaced by a pkdata
OID under the Kerberos-PKINIT arc. 

KERBEROS DNS-LOCATE

Ken Hornstein (NRL) presented discussion re the Kerberos DNS-Locate document
(-02 draft).  He reported that dns-locate is currently implemented in two
different independent Kerberos implementations, is widely used, and appears
to work well in simple usage.  There had been significant contention on the
CAT list about security concerns with host-to-realm mapping.   Ken observed
that the vulnerability exists only between realms which share a cross-realm
relationship, and that it can exist in many common Kerberos implementations
even without the use of DNS-based host-realm mapping; use of a different
naming approach would be required to resolve this. Ken believes that the
facility is useful and should remain within the draft as a feature that
could be activated selectively. Following the discussion which has taken
place, he also believes that more clarification is needed somewhere about
the relation between Kerberos and DNS, and may consider a separate
informational document for this purpose. 

GAA

Cliff Neuman presented an update on the GAA drafts. It was noted that any
request for progression of these documents would target Experimental status
and would follow integration results with several applications.  Recent GAA
work has focused on implementation and changes needed for integration with
particular applications.  The new drafts define new generic conditions,
which generate audit records when policies containing those conditions are
encountered. Also, optional parameters are now translated to appropriate
types by condition evaluation functions rather than being described by the
separate gaa_options structure. The new C bindings have focused on a more
"object-oriented" approach, inspired by the style of Hudson and Young's
SSLeay, and with three classes of functions. The draft now uses a generic
gaa_stack object (with implementation-specific structure) for representation
of ordered lists rather than using a separate ordered list for each type of
data.

OTHER TOPICS

Tom Yu (MIT) asked about futures for the Kerberos GSS mechanism.  He stated
that Microsoft and others are interested in squeezing 3DES into RFC-1964
rather than doing a general cryptosystem-independent scheme, and asked the
attendees whether they wished to voice any objections to hacking into
RFC-1964 rather than pursuing a wholly new approach.  It was noted that
interoperability issues might arise if a single OID were used.  Ted Ts'o (VA
Linux) would like to see an analysis of what the failure cases and modes
would be. Tom plans to circulate a more detailed proposal to the list. 

A new version of PKCROSS is planned, but is currently blocked pending
resolution on the Kerberos-Revisions ticket extensions question. 

Ted Ts'o asked the meeting about continued interest in specification of a
GSS adjunct interface for interactive credential acquisition, such as that
which had been documented in his GSS Conversation Interface draft.
Approximately three attendees indicated interest. To this point, GSS' scope
has excluded asynchronous callbacks to applications and their associated
users, partly for reasons of OS independence. Sam Hartman (FundsXpress)
observed that SASL is an important client of GSS, and that it already has
its own facilities for asynchronous callbacks to applications; given these
facts, he considered that it would be inappropriate to define an
incompatible facility at the GSS level. Ted indicated that he was not aware
of API-level convergence among SASL providers, but others commented that
such convergence was progressing.  

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Ken Raeburn <[email-masked]>
Date: 04 Apr 2000 20:54:28 -0400

> RFC-1964 rather than pursuing a wholly new approach.

Shouldn't have been "rather", but "in addition to" or "while".  The
goal is to get 3DES available *now*, and a better
cryptosystem-independent scheme available when we've banged out the
details of little issues like whether ASN.1 sucks or whether 32-bit
numbers are big enough or whether we should use already-defined
Kerberos message structures or whether we can extend RFC1964 to be
more cryptosystem-independent or whether we should order pizza for
late-night meetings where go back and forth endlessly on such things
without making any decisions.

>    It was noted that

IMHO the interoperability problems are similar to those that come up
when adding new cryptosystems to Kerberos.

Client side:

Request from the KDC a session key from a list of cryptosystem types
that your GSSAPI mechanism supports.  DES must be on the list, unless
you simply don't want to talk to a non-updated service; we now add
3DES as an option.  If you haven't upgraded your software, you'll be
asking for DES only.

MIT's 1.0 release didn't do this, in fact it lacked a lot of
compatibility support for cryptosystem additions, in the krb5 core as
well as GSSAPI.  The 1.1.1 release should fare much better -- it asks
for DES only.

Server side:

Until the server-side software is updated for 3DES support, tell the
KDC not to issue 3DES session keys for its services even if clients
ask.  If the KDC has 3DES support, it must include somewhere, somehow,
an indication of whether a given application server can support 3DES.
(Worst case, a flag saying "turn 3des support off".  Best case,
separate data for each principal.)  This is needed for a smooth
upgrade of Kerberos, even ignoring GSSAPI issues.

If a client initiates a connection using a 3DES session key, and the
server's krb5 code supports it but the GSSAPI code does not (meaning
IMHO that the KDC isn't configured right), context establishment will
probably succeed, and all following messages will fail to be
understood.  The end result of that depends entirely on how the GSSAPI
library used and the application are written.  If they're written
poorly, a crash or security compromise could result; that's always the
case though.  If they're written well, they should print or log an
error message, and fail.

This could be a problem with code that negotiates for one of several
authentication mechanisms -- the GSSAPI-KERBEROS context establishment
will presumably be enough for both sides to agree on the use of that
mechanism, and move on to exchanging data, but the data exchanges
would fail because the messages couldn't be decoded.  But as I said,
this situation is assuming a KDC that's misconfigured for that
application server.

Ken

---

From: Martin Rex <[email-masked]>
Date: Fri, 7 Apr 2000 14:42:41 +0200 (METDST)

Just comments, no corrections (I wasn't at the meeting).

> imminent Last-Call, in advance of establishment of the Kerberos WG, can

I must admit that we in the CAT WG have not really played by the IETF
rules regarding the "timely fashion" and "focus" when discussing and
finalizing most of our documents.  Therefore I can fully understand Jeff's
position procedurally (wearing his IESG hat).  On the other hand I would
really miss a single forum with the full scope that CAT had de-facto
gathered over the last couple of years (that I remember).

Could we retain this forum with its broad scope as it has been, even
if we don't carry-on a formal active IETF WG status -- but still remain
an IETF(-related) activity?  I think it would be ok to spin off actual
IETF WGs with a clear focus every once in a while when a specific need
has gained enough momentum and interested parties to get some work
done in short time -- while reporting WG status and results back to
the CAT forum in a similar fashion as its currently done with rfc1510bis
progress.  What worries me: if CAT is no longer a working group,
the "push" of 3 IETF meetings per year for the progress reports on all
the individual issues within the current CAT scope may disappear,
and the forum itself may loose significant value.  While I was going
to IETF meetings, there was a SAAG slot every time.  And the scope
of SAAG was even broader than CAT, it was about all of the security
area in the IETF.  And I really liked the overall wrap-up.  SAAG
is not an IETF WG, therefore no charter and no timelines either,
and I still consider it a useful forum within the IETF.

Security is complex and takes more time that a simple "feature-du-jour"
protocol extension in the applications area.  And over the past few years
I've learned that defining an API and _getting_it_right_ is a difficult
task; and for a security-related API it is extremely difficult.
In the past I've built application support for arbitrary gss-api
mechanisms, and I was really impressed about the quality of the
abstraction of the API in most areas.  Three years ago I basically
finalized the GSS-API support within our "portable" application,
based on the experience with two particular gssapi mechanism,
Kerberos 5 and a public key based mechanism similar to SPKM.
In the meantime 5 more gssapi mechanism are being used with our
application, and I didn't touch my code at all.  And I might add
that I am using EXACTLY the same code on all of our supported
platforms: Win32, OS/2, AppleMac, 6 different Unix, AS/400, OS/390.

These days, I'm trying to provide the same vendor-independent interface
for SSL libraries, and I can tell you it is a BIG MESS!  I have made
the first prototypes with OpenSSL, and I tell you that it is no fun.
Not only is the code buggy as hell, the API is spread over ~2000 calls
(pick what you need), seriously inconsistent (some get() calls return
standalone copies, some return readonly references) and not really
defined at all (what calls do you need to make to achieve an authentication
with certain constraints -- most of the included sample code appears to
allow client authentication, but is missing important prerequisite calls).

Read it like that: I'm not a Kerberos guru, and I don't want to
subscribe to any kerberos-bugs or kerberos-developers mailing lists,
because I would have a hard time sorting out information relevant to me.
However I am exceptionally pleased with the amount and contents of
information that was compiled and distributed in this forum about
all of the developments in the Kerberos area, because of a relatively
low number of messages with high informational value.

In the second half of 1999 I wrote a SSPI to GSS-API v2 translator
for Microsoft Windows 2000, and my company has agreed to publish
this code with a BSD-style copyright.  It already does most of
what our application needs and makes W2K Kerberos look just like
MIT Kerberos 5 to our application, however there still are some
open issues (and a few bugs).  One of those is the resolution of
hostbased service names and how it should be done.  Currently
the code performs the processing from RFC2743, Section 4.1,
but it doesn't know how to come up with a REALM name.
I'm still looking for volunteers to try and comment, however
because of current job-related time constraints I may show
significant delays in response over the next two months. 

Although technically, I know little about Kerberos protocol details,
the broad scope of information discussed in CAT during the past years,
and the expertise of the participants provided enough information
to write this wrapper in a fashion that makes our application happy.

On a related issue, I'm very interested in how the 3DES encryption
will be integrated into Kerberos, because some of the issues will
matter for the interoperability and upgrade/migration when running
our GSS-API based application with Kerberos.

> such convergence was progressing.  

Independent of what the SASL providers are doing, if SASL was using
GSS-API as one of its methods, it could only use callbacks provided
via GSS-API anyways (which we currently don't have).  So the SASL
guys should be *requesting* a gss-api level callback from us that
they can pass through.  And in order to make things interoperable
they can discuss their ideas with us.  :)

As a kind of library and "middleware" provider in our company, I'm
not totally comfortable with Ted's callback proposal.  But it's probably
nothing about the details of the proposal itself, rather than the
situation when this stuff is going to happen, and the way in which
gssapi mechanism implementors are going to use it.

In distributed environments, where gssapi security contexts may be
established and destroyed very freqently, some sort of Single Sign-On
will usually be required to be usable (=acceptable to users).
GSS-API mechanisms that perform a credentials callback for every
single security context won't fly in most distributed environments.

Most everyone has probably seen or heard of "SecurID" cards, which
may have helped Security Dynamics to buy out RSA.  Now if one such
beast was used by a gssapi mechanism to "authenticate" a user directly
during security context establishment, there is no chance that such
a mechanism would fly with applications like ours.  If instead one
was using a certain commercial Kerberos and used the SecurID card
for initial authentication to obtain a TGT, the applications
wouldn't notice a difference to other Kerberi and be happy.

One of the things why I dislike the callback method is because
the application will loose control for an indeterminate time,
being locked within context establishment, tying resources of the
server.  And since during a callback were way down the call stack,
so you can't just go on processing all other events that your
application may be expected to process.  I would really like the
option to handle the user interaction in an asynchronous fashion,
just like I'm doing it with GUI events and Network I/O events.

-Martin

---

From: Assar Westerlund <[email-masked]>
Date: 09 Apr 2000 18:55:05 +0200

"Linn, John" <[email-masked]> writes:
> derivation, though that some skepticism was observed about its value.

I would think it a really bad idea having tow different kinds of 3DES
in the spec.  And since, as I'm lead to believe from the minutes,
everybody agrees on using 3DES with key-derivation, I propose that we
just keep that in the spec, of course letting the assignment of the
etype to the old 3DES stay.  Any comments?

/assar

---

From: "Clifford Neuman" <[email-masked]>
Date: Mon, 10 Apr 2000 18:46:55 -0700

Cliff reported that the current 3DES description integrates all options
in a
     single parameterized discussion, but that it references currently
expired
     drafts and material must therefore be adapted from them.  List
discussion is
     needed to resolve whether or not to use the key derivation variant;
Cliff
     reported that Microsoft and CyberSafe have tentatively agreed to accept
key
     derivation, though that some skepticism was observed about its value.

Then perhaps you would like to reopen the debate about whether key
derivation should be the must implement version.  In the discussions I
reported, the general feeling was that there was not significant benefit to
key dervation, but there was a willingness to go along with it to put the
discussion behind us and to move forward.  It was not an agreement that the
kd version was the better choice.  If you are proposing now that the non kd
version shouldn't even be included in the spec, then you will find them more
likely to push the issue, and less willing to go along with the compromise.

Clifford Neuman

---

From: Assar Westerlund <[email-masked]>
Date: 11 Apr 2000 04:03:15 +0200

"Clifford Neuman" <[email-masked]> writes:
> derivation should be the must implement version.

That was what I thought I had just done. :-)

> In the discussions I reported, the general feeling was that there
> was not significant benefit to key dervation, but there was a
> willingness to go along with it to put the discussion behind us and
> to move forward.

I think, as I have said, that the most important thing is to have just
one mandatory-to-implement 3DES variant and I would really like it to
be implemented (and interoperable) in all the implementations.

> It was not an agreement that the kd version was the better choice.

ok

> If you are proposing now that the non kd version shouldn't even be
> included in the spec, then you will find them more likely to push
> the issue, and less willing to go along with the compromise.

As I understood it from reading the minutes and the mailing-list,
Cybersafe and Microsoft were talking about implementing 3DES, in other
words, that they haven't done so.  In that case, I frankly don't see
the point of implementing two different mechanisms.  If the case is
that it's already implemented, then I think it should be in the
specification, regardless of which mechanism turns out to be the
mandatory.

So what I'm after here is consensus on the mandatory 3DES mechanism.
What are the arguments for and against the kd-variant here?  It's some
more code, but it gives compatibility with the MIT and Heimdal
implementations.

/assar