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

Wesley,

It's not unusual for the base Java platform (J2SE) to have additional
requirements over what the JGSS API defines. Interaction with JAAS has
traditionally been one of those areas.

JGSS is unique in the sense that the API was originally defined at the IETF,
but since it is included in J2SE, it also had to go though the Java
Community Process (JCP) to be adopted. The JCP experts group placed
additional requirements that had to do with JAAS interaction. These were
only specified in the javadocs for J2SE (e.g.,
http://java.sun.com/javase/6/docs/api/org/ietf/jgss/package-summary.html#useSubjectCredsOnly),
and not in the JGSS RFC.

It was also realized at the time, that we would need a way to convert back
from GSSCredential to a JAAS Subject. So Sun provided an API specific to
Sun's JRE to do this. Please see:
http://java.sun.com/javase/6/docs/jre/api/security/jgss/spec/com/sun/security/jgss/GSSUtil.html.
It wasn't pushed through as a standard J2SE API because we were unsure if it
would suffice.

Perhaps the best thing to do would be to take the issue up with Sun and ask
if the com.sun.jgss.GSSUtil API could be moved into J2SE as part of a
standard auth package like javax.security.auth? There are already other
classes in this and its sub-packages related to this space.

-Mayank

2008/7/22 kitten-request <kitten-request@ietf.org>:

Today's Topics:

  1. Re: WGLC on draft-ietf-kitten-rfc2853bis-
>
> 04 (Wesley Leggette)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 21 Jul 2008 22:22:17 -0500
> From: Wesley Leggette <wleggette@cleversafe.com>
> Subject: Re: WGLC on draft-ietf-kitten-rfc2853bis-04
> To: <kitten@ietf.org>
> Message-ID: <C4AABC99.79C7%wleggette@cleversafe.com<C4AABC99.79C7%25wleggette@cleversafe.com>
> >
> Content-Type: text/plain;       charset="US-ASCII"
>
> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>
>
> End of Kitten Digest, Vol 46, Issue 2
> *************************************