GSSContext with null SrcName

Question

I\'m working a web appliaction with SSO based on the Windows domain login, for this purpose I have chosen to validate Kerberos tickets. But now I\'m facing a problem for whi

Answer 1

It seems that the context is not fully established when you are trying to get SrcName. It seems to be the reason for ScrName to be null. According to https://www-01.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.security.api.doc/jgss/org/ietf/jgss/GSSContext.html, acceptSecContext() generates a token and if it's not null, this token should be sent to the peer. After the call acceptSecContext() you should check if isEstablished() returns false. If it's so,

If this method returns false it indicates that a token is needed from its peer in order to continue the context establishment phase. A return value of true signals that the local end of the context is established. This may still require that a token be sent to the peer, if one is produced by GSS-API. During the context establishment phase, the isProtReady() method may be called to determine if the context can be used for the per-message operations. This allows applications to use per-message operations on contexts which aren't fully established.

The same is explained in more details in the tutorial http://www.cs.mun.ca/java-api-1.5/guide/security/jgss/tutorials/BasicClientServer.html:

The acceptSecContext method may in turn return a token. If it does, the acceptor should send that token to the initiator, which should then call initSecContext again and pass it this token. Each time initSecContext or acceptSecContext returns a token, the application that called the method should send the token to its peer and that peer should pass the token to its appropriate method (acceptSecContext or initSecContext). This continues until the context is fully established (which is the case when the context's isEstablished method returns true).

Answer 2

I faced the same Checksum failed error when implementing my GSSAPI socket demo that is a modification of the Oracle GSSAPI tutorial code. I executed my code on a Linux machine enrolled into a FreeIPA kerberos realm. I have used the vanilla krb5.conf file of my Linux system. No constraints on ticket etype are there:

...
[libdefaults]
  default_realm = AUTHDEMO.IT
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = true
  udp_preference_limit = 0 
...

The FreeIPA realm default is to use type 18 tickets (AES-256).

About my application, it has this policy file configured:

grant CodeBase "file:./app.jar" {
        permission java.security.AllPermission;
};

grant CodeBase "file:./app.jar" 
    Principal javax.security.auth.kerberos.KerberosPrincipal 
        "servicename@AUTHDEMO.IT" {

    permission java.net.SocketPermission "*", "accept";

    permission javax.security.auth.kerberos.ServicePermission
        "servicename@AUTHDEMO.IT", "accept";
};

When executing the application I got this error on the acceptor side:

GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256CTS mode with HMAC SHA1-96 is not supported/enabled)

In my case the error arises in the GSS acceptor side. In my application I generate the Jaas configuration programmatically (I'll refer at this as DConfig) and I don't use a config file. The first solution, I found, is to use config files instead of DConfig and the problem disappeared, it worked fine. The temporary solution, Jaas Config file:

DemoServer {
  com.sun.security.auth.module.Krb5LoginModule required
   principal="servicename@AUTHDEMO.IT"
   storeKey=true
   debug=true; #not mandatory
};

With this configuration, no problem arises on the acceptor side and the application were able to check the service ticket validity and accept the connection.

I asked myself.. WHY?

I checked differences in the Subject(s) acquired with the two configurations. In the working case, with the config file, the subject contains, into the private credentials, both the password hashes credentials and the principal TGT ticket. With DConfig, I obtain a Subject with only password hashes but there is no principal TGT ticket in private credentials.

My fix

DConfig contains the same settings of the configuration file and the other options are the replica of Krb5LoginModule defaults, at first I cannot see a reason for the misbehaviour.

Setting isInitiator = true, into the acceptor side DConfig, solved the issue. `isInitiator = true has forced the persistence of TGT ticket into the subject.

With this workaround the error has disappeared with no change into the system krb5.conf.

My cent is... after Jaas login, let's check your subject private credentials for lacking creds (You need the service principal TGT into your acceptor side subject!) and in case try to set isInitiator = true to the acceptor side too.

Regards