MIT and Heimdal dealing with credential delegation

[Sam Hartman <hartmans@MIT.EDU>]

Hi.  Love reported that while trying to make MIT and Heimdal Kerberos
interoperate for 3DES GSSAPI, he noticed that a Heimdal client could
not delegate credentials to a MIT server.  Believing I had fixed that
problem for the 1.2.5 release of MIT Kerberos, I agreed to  see what
was up.

Preliminary investigations determines that the MIT implementation of
krb5_rd_cread does not support credentials encrypted only in the
session key if a subsession key is established.  Since Microsoft sends
such credentials I wrote a fix for this MIT behavior.

However Heimdal does seem to use the subsession key to encrypt
credentials.

I don't understand how delegated credentials work in the current
Heimdal code base, which seems to implement the following steps:

1) Set up a subsession key in do_delegated_credentials in
   init_sec_context.c

2) Create the krb_cred message

3) Set up another (different) subsession key in gss_init_sec_context

4) Build the KRB_AP_REQ message using the new subsession key.

With the following patch, the MIT code is able to decrypt the
credentials.  This patch illustrates the problem but does not
correctly fix it:

--- init_sec_context.c	Sun Feb  9 19:59:49 2003
+++ init_sec_context.c.new	Sun Feb  9 19:59:41 2003
@@ -372,15 +372,15 @@
     }
 #endif
 
-    kret = krb5_auth_con_generatelocalsubkey(gssapi_krb5_context, 
-					     (*context_handle)->auth_context,
-					     &cred->session);
-    if(kret) {
-	gssapi_krb5_set_error_string ();
-	*minor_status = kret;
-	ret = GSS_S_FAILURE;
-	goto failure;
-    }
+/*     kret = krb5_auth_con_generatelocalsubkey(gssapi_krb5_context,  */
+/* 					     (*context_handle)->auth_context, */
+/* 					     &cred->session); */
+/*     if(kret) { */
+/* 	gssapi_krb5_set_error_string (); */
+/* 	*minor_status = kret; */
+/* 	ret = GSS_S_FAILURE; */
+/* 	goto failure; */
+/*     } */
 
     kret = krb5_build_authenticator (gssapi_krb5_context,
 				     (*context_handle)->auth_context,


Now I am facing the problem that the sequence number in the
credentials structure is not what is expected for the auth context.


Question: Should the credentials structure take up a sequence number?
RFC 1964 seems somewhat unclear on this.  I think reading Kerberos
clarifications it should, but does everyone else agree with this
reading of the spec?


--Sam