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

From: Shawn M Emery <[email-masked]>
Date: Tue, 08 Jul 2008 18:18:25 -0600

This message officially starts the Kitten Working Group Last Call for 
the following document:

Generic Security Service API Version 2 : Java Bindings Update
http://tools.ietf.org/html/draft-ietf-kitten-rfc2853bis-04

The Working Group Last Call for this document starts today on Tuesday, 
July 8th and will end on Tuesday, July 29th.

Please send any comments to the Kitten mailing list or directly to 
chairs.  Reviews that found no issues are also welcomed, so if you 
review the document and find it acceptable, please let the mailing 
list/authors+chairs know as well.

Thank you,

Alexey and Shawn, Kitten WG chairs
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Wesley Leggette <[email-masked]>
Date: Mon, 21 Jul 2008 22:22:17 -0500

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