It should be possible for a client to use JGSS with Kerberos to contact 
a server if the client has the necessary service ticket but not the TGT.
In certain environments/configurations, it is desirable for security reasons
to distribute only the service ticket, not the TGT.

Right now, if null is supplied as the credentials to GSSManager.createContext(),
initSecContext() will try to create default credentails. This will then trigger
a search for the TGT, which will fail if a TGT is not available.

createContext() should first examine the acceptorName parameter to search/load
the acceptor-specific credentials (i.e., service ticket) instead of
searching for the TGT. If service ticket is not available, then search for
TGT to get service ticket.

Here's the message from the customer.
 
----------------
Date: Wed, 04 Jun 2003 15:58:20 -0400 (EDT)
From: Rob Siemborski <###@###.###>

I'm looking to use the SASL APIs provided in Java 1.4 to perform a SASL
GSSAPI authentication using a ticket cache that does not include a TGT
(but does include the appropriate service ticket).

I've tried to do this several different ways.

The first, I use the JAAS authentication APIs and create a LoginContext
that is looking at an on-disk ticket cache.  If this ticket cache contains
a TGT, all is well, however, lc.login() gets a NullPointerException if the
ticket cache does not contain a TGT.

I then attempted to build the Subject object manually by parsing the
ticket cache file myself.  Again, if the credentials in the Subject
include a TGT, everything is fine, however if there is no TGT, then I get
a stack dump that ends with

GSSException: No valid credentials provided (Mechanism level: Failed to
find any Kerberos Ticket)
        at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:143)
        at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:70)
        at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:149)
        at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:334)
        at sun.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:59)
        at sun.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:36)
        at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:96)
        at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:178)
        at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:158)
        at com.sun.security.sasl.gsskerb.GssKerberosV5.evaluateChallenge(GssKerberosV5.java:160)

However, the Kerberos 5 debug output implies that the necessary ticket was
found:

Found ticket for ###@###.### to go to imap/###@###.### expiring on Thu Jun 05 12:23:42 EDT 2003

Is there anything that can be done to allow me to not have a TGT and still
use the internal GSS code?

Any help you can offer would be appreciated,
-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * ###@###.### * 412.268.7456