Re: WGLC on draft-ietf-kitten-rfc2853bis-04

[Wesley Leggette <wleggette at cleversafe.com>]

By way of introduction, I am a senior software developer at Cleversafe, Inc.
We are developing a "dispersed" storage technology called "dsNet" and have
been using GSS-API within our new security framework. Our code is written in
Java and the aspects of GSS-API we are especially interested in is the
authentication negotiation with SPNEGO and credential delegation features.

We anticipate migrating to Kerberos and SPKM authentication but realize that
our users will require support for password-based authentication as well and
to that end have implemented a password-based authentication mechanism based
heavily on SSHv2.

Working with GSS-API on an alternate mechanism (especially one that requires
multiple exchanges) has uncovered a few bugs in the Java GSS-API and SPNEGO
implementations, which is somewhat interesting. (We plan on taking this up
with Sun directly. I just mentioned it here for color.)

But to the point, because we have decided to integrate heavily with the Java
Authentication and Authorization Service we've found that the major
shortcoming of the GSS-API Java bindings is the lack of a mechanism
independent way of obtaining java Subject objects for both the local and
delegated credentials of a GSSContext.

I can anticipate that Java-specific (especially JAAS-specific) objects were
purposefully omitted from the Java bindings. Was this the case and if so
what was the rationale? If this was not purposefully omitted I would request
that this be considered for this draft.

Wesley Leggette
Senior Software Developer
Cleversafe, Inc.
http://www.cleversafe.com


_______________________________________________
Kitten mailing list
Kitten at ietf.org
https://www.ietf.org/mailman/listinfo/kitten