Subject: Draft minutes, CAT-WG Oslo meeting

From: "Linn, John" <[email-masked]>
Date: Wed, 21 Jul 1999 13:23:21 -0400

CAT fanciers and attendees:

Attached are the draft minutes for the CAT-WG Oslo session.  If any
attendees have corrections or clarifications to offer, please provide them
by next Wednesday, 28 July, to support a timely submission to the IETF
secretariat. 

DRAFT Minutes, Common Authentication Technology (CAT) WG, Oslo IETF,
reported by John Linn (RSA Laboratories).

The CAT-WG met for one session at the Oslo IETF, with approximately 110
attendees.  Discussion was concentrated in four areas: Kerberos-related
documents (pk-init and Kerberos-revisions), GSS Java bindings, GSS
low-infrastructure mechanisms, and authorization services.  Regarding the
Kerberos documents, it is planned that a few identified specific issues will
be resolved within the next week, with the intent that revised drafts (to be
issued during the week following the IETF meeting) will be suitable for
parallel last calls within the working group.  Relative to GSS Java
bindings, the new javabind-02 draft was discussed along with a set of issues
that had been raised on the mailing list; it is intended that a successor to
this draft will reflect convergence within the group. Concern was raised
about the importance of ensuring that SPI concerns are adequately and
suitably satisfied, and this topic is to be researched before proceeding
towards advancement of the higher-level document. Relative to GSS low
infrastructure mechanisms, the current intent is to proceed with progression
of LIPKEY following certain identified changes, with SSKM and GSS-Easy to be
discussed further on the mailing list. Relative to authorization services,
the current intent is not to pursue standards-track documents; a subsequent
version of the GAA-API specification may (following coordination with
candidate consumer applications) be considered for Experimental status. 

KERBEROS PK-INIT AND KERBEROS-REVISIONS

Cliff Neuman (ISI) led discussion on draft-ietf-cat-kerberos-pk-init-08 and
on the kerberos-revisions draft. 

A new version of pk-init was submitted at the submission deadline. Changes
were made to algorithm identifiers. Ephemeral-Ephemeral Diffie-Hellman is
now explicitly described as the required mode.  Wording about mandatory to
implement (MTI) algorithms was clarified, and error messages have been
coordinated.  More detail is now provided on use of alt names in
certificates, pending side resolution of comments from Paul Leach
(Microsoft).  An encryption certificate field was added. References to
pending work will be revisited, to avoid normative citations to
non-standards. Resolution will be provided to cover the case where a user's
public key may be locally available at the KDC, for which case no CA
signature need be verified in order to make use of the key.  Comments have
been received and are to be resolved from John Linn, Denis Pinkas (Bull),
and Paul Leach. Denis suggests use of 2-key 3DES as mandatory, because some
countries restrict keys differently depending on whether their lengths are
above or below 128 bits.  Sasha Medvinsky (General Instrument) suggests that
2-key 3DES can be used, but usage of 2-key 3DES by some peers and 3-key
3DES, absent other tagging, wouldn't be interoperable.

Cliff presented a plan for movement of pk-init to completion. Final issues
were to be resolved within the IETF week, followed by submission in the next
week of a new Internet-Draft reflecting changes. It was suggested, and
appeared reasonable in discussion, that pk-init and Kerberos-Revisions
proceed to WG and IETF Last-Calls in parallel, as a pair of related
documents. 

A new version of the kerberos-revisions spec is out.  In-progress revisions
can be viewed at http://www.isi.edu/people/bcn/draft-kerberos-rev.html.
Changes include: folding of e-type data into e-data; updates to registered
values; swapping of ad (authorization data) elements kdc-signed and
if-relevant; clarifications to wording; warnings for implementation choices;
fixed few remaining etype/keytype distinctions.  A new Internet-Draft and
accompanying change summary is planned for the week following the IETF
meeting, intended for WG Last-Call. 

Kerberos-Revisions issues remain regarding required algorithms: there are
several 3DES variants, hopefully to be resolved with Ted Ts'o (VA Linux) and
Marc Horowitz (Stonecast) during the IETF week. A proposal from Microsoft
had recommended an additional algorithm set.  Reportedly, Microsoft had
indicated resistance to mandatory 3DES; Paul Leach was unfamiliar with the
discussion, so had no comment on this question. Another issue concerns
handling of newly optional fields. It was reported that discussion had taken
place on the krb-protocol list, which was to be restated to the CAT list by
Tom Yu (MIT) and/or Cliff Neuman during the IETF week, about changes in
ASN.1 syntax that could result in non-interoperability for new and some
optional fields.   Ticket extensions remain as an open issue, with basically
the same status as discussed at the Minneapolis meeting. Ticket extensions
are designed to bind additional data (e.g., authorization or audit
information) to an authentication credential; issues with their adoption
include graceful transition for current client and server implementations
not supporting the extensions, and potential misuse of the extensions.
Cliff's proposal, which was to be framed to the CAT list during the IETF
week, is to allow ticket extensions only when it's known that a client
supports new encryption types.  Additional Kerberos-Revisions changes will
include a list of changes made since RFC-1510, and guidance for transition
support. 

GSS JAVA BINDINGS

Mayank Upadhyay (Sun) led discussion on GSS Java bindings.  He reported that
he had spoken with Michael Smith (TIAA/CREF), and reflected divergences
among the Java binding proposals in his discussion. As a goal, a unified GSS
Java bindings draft is desired. 

The gssv2-javabind-02 draft includes a number of changes.  Added interfaces:
IGSSName, IGSSCred, IGSSContext, GSSFactory.  Utility classes are largely
unchanged: toRFC2078String has been removed, added setSupplementaryStates
has been added.  Constructors can now be called on wrapper classes GSSName,
GSSCredential, and GSSContext.  GSSManager wraps GSSFactory.   The new draft
introduces a system-wide GSS vs. bundled GSS distinction.  Also, it now
specifies how to optionally integrate with Java's provider model. This
allows a means for vendors to register a system-wide implementation, and
offers a means for applications to discover GSS implementations, based on
standard classes from java.security (java.security.Provider class,
java.security.Security class). The providers list is read by the JVM at
startup, and can be changed dynamically. A GSSManager can get the provider
list, and can query each GSSFactory implementation about what mechanisms it
supports.  Applications can access multiple mechanisms from multiple
implementations simultaneously.  Sample applications have been added to the
draft.  

One pending issue is whether a means should be recommended for applications
to find implementations. Mayank believes that a standard means should be
specified, and that an application should be insulated from
implementation-specific details.  He recommends the provider model as
offering a solution consistent with Java practice, noting that the Java
crypto API uses providers and that an upcoming version of the Java SSL API
may also do so.  Use of providers is to be confirmed on the mailing list.

For multi-mechanism implementations, the concept of an intermediate context
layer arises.  When the default mechanism is requested, a context isn't
bound to a mechanism until context establishment is performed.  Thereafter,
a means is needed to get at the actual selected mechanism.  Several
alternatives were discussed:  (1) pass all required information when
creating context object (but even this isn't sufficient if SPNEGO is used,
so didn't seem workable); (2) use a different interface for context
establishment, returning a new one for per-message calls (prot-ready might
further complicate this choice, though it may still be possible); (3) live
with the indirection.  Ted Ts'o asked whether the indirection cost of (3)
really constitutes a barrier.  Mayank believes that no buffer copy would be
necessarily be needed. The apparent sense of the room was to accept the
indirection of (3). 

Another issue concerns input-output parameters for the GSS per-message
calls.  The javabind-02 draft has a container class that is used to pass and
return parameters.  Usage of this approach is somewhat complicated by the
fact that different calls accept and return different combinations of
parameters.  As an alternative, required input parameters could be passed
directly with an interface (e.g.,, MessageResult) returned.  Sentiment was
neutral; the working position is to keep the approach as currently proposed.

An issue arises for channel bindings, as Java doesn't support non-Inet
addresses. Peers could, however, agree to insert non-Internet addresses
themselves in an externally specified format.  As an alternative, the
current definition could be modified, defining 22 static constants for
different address types analogous to those defined in the GSS C bindings.
It was unknown whether any existing implementations interpret channel
bindings for non-Inet address types.  It was also believed that few if any
non-IP GSS apps exist, though Appletalk might be an exception.  Ted Ts'o
asked whether the current approach would support IPV6 and interoperability
between C and Java GSS implementations for either IPV4 or IPV6. It appeared
that Java needs an extensible address class (including both IPV4 and IPV6,
even though not non-Internet address forms), which Jeff Schiller (MIT)
believes it has.  Question: does the Java equals method compare Ipv4 and
Ipv6 addresses correctly?  Some further Java research is needed here.   

A few other issues are to be considered.  The first is whether GSS names
should stand free of the Java principal interface. In the javabind-02 draft,
java.security.Principal is used for tighter integration with Java security
APIs.  Mayank considers that this integration might be an issue in browsers
where principal constructs are unavailable, and intends to research this
point.  A request was received on the list for use of type safe constants:
an advantage of this approach is compile-time checking, but a disadvantage
is switch or case statements cannot be used on such values; this question is
to be considered further.  Currently, a single exception returns both major
and minor status.  As an alternative, an exception hierarchy could be
constructed. At the cost of complexity, this approach could allow selective
dispatch on different errors.  A GSS-level question arises here, which John
Linn plans to investigate: in what (if any) combinations are different major
status codes conformantly permitted to exist in conjunction with one
another?  It was also pointed out that some implementations may apply
different interpretations for minor codes depending on the major status
values with which they occur.  

A question arose as to whether the group should wait to finalize the SPI
before advancing the higher-level Java bindings document?  Paul Leach, Ted
Ts'o, and at least one other individual argued that there's risk in having
the high-level doc lead, lest its facilities prove inappropriate and
provision of multiple providers prove important. It was noted that prior
lessons demonstrate that extensibility is hard, and that it's difficult to
anticipate what provisions may be needed.   In the interests of balancing
these concerns with the agreed intent to advance the high-level document
promptly, it was agreed that the appropriate next step was to solicit list
discussion of features and characteristics desired in a Java GSS SPI.  It
was hoped that this would enable determination of whether or not conflicts
exist with the high-level Java bindings design. 

GSS LOW-INFRASTRUCTURE MECHANISMS

Wes Doonan (Surety) led discussion on the SSKM draft
(draft-ietf-cat-sskm-00.txt), which is based on secret-key cryptography
within an SPKM framework. As a general premise, he asserted that GSS is
good, and should be used by more applications.  He perceives the following
deterrents: deployment of some mechanisms requires that many changes be made
simultaneously, and uncertainty breeds resistance.  He believes that a
simple-to-deploy mechanism would help, and that reuse of SPKM and other
known technologies is good.  SSKM has no changes to SPKM's messages or
syntax, or to confidentiality or OWF algorithms, but integrity algorithms
are changed to mandate HMAC-SHA.  Key establishment algorithms are also
changed in SSKM. While rsaEncryption is mandatory in SPKM, SSKM recommends
Bellare/Rogaway AKEP2 with DES or 3DES as K-ALGs.  Wes believes that this
approach is built on a solid cryptographic basis, with a proof of security
already in place. Paul Leach believed that exportability isn't an issue for
the key size used in key derivation, but noted that the use of different
OWFs would impact the ability to share a common password data store. Bob
Blakley pointed out the general cryptographic principle that it may be
dangerous to reuse the same key within different protocols.  Ted Ts'o
commented that he doesn't believe that there have been any open source SPKM
implementations, so there may not be an apparent straightforward path for
deriving an open source SSKM implementation. Wes has implemented SSKM, but
doesn't know whether this implementation can be made freely available.  It
was observed that IBM's free PKI implementation might be a useful basis in
this area. 

Reviewing the sense of the WG as recorded at the Minneapolis meeting, the
active position is that advancement of a LIPKEY-based mechanism should be
pursued.  Mike Eisler (Sun) gave an update on LIPKEY.  As high-level review,
he described LIPKEY as following the basic SSL model within an SPKM
framework, using server-side certificates.  Regarding prospective
LIPKEY-SSKM integration, his consideration was that this wouldn't be very
meaningful, since password usage is different in the two mechanisms.  LIPKEY
is intended to work over any existing password schemes. SSKM assumes that
the target knows the client's password, but LIPKEY assumes that the target
knows how to verify the client's password. 

Other LIPKEY changes and change candidates were presented.  The current -01
draft adds an SPKM-3 definition (allowing a secure channel without prior
knowledge of a target certificate) and support for anonymous LIPKEY
initiators. Changes are planned for OID assignments (SPKM-3 and a NULL-MAC
I-ALG) and for an unencumbered signature algorithm.  Incorporation of a
stronger integrity algorithm than DES-MAC is to be considered. 

Some discussion took place on LIPKEY's value to the IETF community in
general.  A GSS-based mechanism is applicable to applications such as NFSV4
(to which LIPKEY is being presented as a potential solution), as well as FTP
and some others, but it appears that the general E-mail and web community is
implementing and using digest authentication directly rather than adopting
GSS.  Paul Leach commented, therefore, that provision through GSS isn't
solving the broad problem.  It was asked whether anyone was interested in
specifying a GSS-based digest mechanism. Jeff Schiller, as area director,
believed that interest by the NFSV4 WG would be sufficient to motivate
proceeding with LIPKEY; Mike believed that such interest does exist. Jeff
also observed that the security of LIPKEY is stronger than that of digest. 

Denis Pinkas presented an update on GSS-EASY, an OWF-based mechanism
proposal.  Relative to the previous version, the current draft (now
available as draft-ietf-cat-gsseasy-00) adds a confounder prefixed before
the first block to be encrypted.  In prior discussion, concerns had been
raised about ASN.1 usage, and about GSS-EASY's encryption scheme.  Denis
noted that other mechanisms under discussion also use ASN.1, and that a free
SNACC ASN.1 compiler is available (see
ftp://ftp.fokus.gmd.de/pub/freeware/snacc/). Denis stated that GSS-EASY's
encryption scheme has been presented to some knowledgeable experts, and that
no flaws have been identified. 

John Linn summarized the current WG status re low-infrastructure mechanisms
as follows: the intent is to proceed on LIPKEY, and to discuss SSKM and
GSS-EASY further on the mailing list to decide on future actions for these
mechanisms.

AUTHORIZATION SERVICES

Cliff Neuman gave an update on GAA activities, followed by a broader
discussion led by John Linn on authorization directions for the CAT-WG. 

A new GAA draft is available. ISI has a reference GAA implementation, which
is to be released soon.  Integration work with the U.S Department of
Energy's Globus project is concerned with defining CA policy, and for
running remote applications.  ISI would also like to integrate GAA with
other targets on a case-by-case basis; NT ACLs and Diameter were proposed as
candidates. It was recognized that a strong set of integrated applications
is necessary in order for the approach to be validated.  Cliff commented
that the GAA document might be ready for a final edit following the upcoming
Washington, DC IETF meeting.  

Changes in the recent GAA draft include the following points. Goals include
support for existing ACL and policy formats.  The set of defined CA types
now includes a CA, and trust constraints for CAs have been added.  It is now
stated that policy inheritance is to be supported by policy retrieval
function and included ACLs.  Parameterized operation is supported.  Denis
Pinkas pointed out the comments he had recently made to the mailing list
regarding GAA, and also suggested that it would be worth consulting with Bob
Blakley (Dascom) regarding the relationship between GAA and the
authorization API contributed by Dascom into the Open Group and currently
being discussed there. Bob Blakley stated that he would plan to make this
specification available to the CAT WG on an informational basis, and
commented that he believes that GAA could be layered under this API.  

Authorization services and interfaces are a large and important topic.
While the CAT WG has long-standing interest in this topic, and approximately
5 attendees expressed possible interest in making active contributions in
the area, group discussion of currently existing drafts has been very
limited.  The demonstrated constituency for CAT's current authorization
documents has been small, and significant further effort is required to
determine their suitability to satisfy application needs.  Webdav was cited
as one candidate worthy of investigation.  Candidate priorities for
authorization services are being discussed on the mailing list, and a
summary slide was presented; one attendee commented that ability to support
distributed objects and DCOM would be an additional useful criterion. It was
recognized that current work merits further visibility and investigation.
Marcus Leech (Nortel), for example, observed that GAA might comprise a
convergence point between policy and attribute certificates. Given these
factors, the WG's current intent (per a suggestion from Jeff Schiller) is to
target authorization-related documents produced within CAT for Experimental
publication once a suitable level of stability is reached. 

--jl

==========================================================================
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]