--- a/jdk/src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java	Mon Nov 07 13:46:02 2011 -0800
+++ b/jdk/src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java	Wed Nov 09 09:30:13 2011 +0800
@@ -375,7 +375,7 @@
         }
         AuthorizationDataEntry[] auDataEntry = readAuth();
         AuthorizationData auData = null;
-        if (auData != null) {
+        if (auDataEntry != null) {
             auData = new AuthorizationData(auDataEntry);
         }
         byte[] ticketData = readData();

--- a/jdk/src/share/classes/sun/security/krb5/internal/ccache/Credentials.java	Mon Nov 07 13:46:02 2011 -0800
+++ b/jdk/src/share/classes/sun/security/krb5/internal/ccache/Credentials.java	Wed Nov 09 09:30:13 2011 +0800
@@ -209,6 +209,16 @@
     }
 
     public sun.security.krb5.Credentials setKrbCreds() {
+        // Note: We will not pass authorizationData to s.s.k.Credentials. The
+        // field in that class will be passed to Krb5Context as the return
+        // value of ExtendedGSSContext.inquireSecContext(KRB5_GET_AUTHZ_DATA),
+        // which is documented as the authData in the service ticket. That
+        // is on the acceptor side.
+        //
+        // This class is for the initiator side. Also, authdata inside a ccache
+        // is most likely to be the one in Authenticator in PA-TGS-REQ encoded
+        // in TGS-REQ, therefore only stored with a service ticket. Currently
+        // in Java, we only reads TGTs.
         return new sun.security.krb5.Credentials(ticket,
                 cname, sname, key, flags, authtime, starttime, endtime, renewTill, caddr);
     }