foolproof method of determining Kerberos version?

[Wyllys Ingersoll]

On Wed, 2004-01-21 at 09:41, Wyllys Ingersoll wrote:
> On Mon, 2004-01-19 at 11:09, Kevin Coffman wrote:
> > CITI's NFSv4 code for Linux needs to pass GSS-API context information
> > to/from the kernel.  This requires knowledge of the private Kerberos
> > structure krb5_gss_ctx_id_rec which is defined in
> > lib/gssapi/krb5/gssapiP_krb5.h.  This structure changes in 1.3.2.  Is there
> > a foolproof way to determine at compile-time and/or run-time what version of
> > Kerberos we are using so we can deal with this?  Is there a better way for
> > us to deal with this?
> > 
> > The [de]serialization routines don't help us since they keep the output
> > opaque.
> > 
> > BTW, just looking at this, these routines don't appear to have been updated
> > to match the changes to the context structure changes in 1.3.2?  i.e. the
> > code in kg_ctx_externalize() still assumes integers for initiate, seed_init,
> > and established.
> 
> 
> I think there is another problem with the serialization routines
> (internalize/externalize) - they are not handling the new "proto" field.

I also noticed that the 'cksumtypes' field is also not covered by
the serialization code either.  

Again, the solution can be to either copy the fields as part
of the internalize/externalize routines or to determine
the correct values in the 'internalize' routine by 
checking the ctx->subkey->enctype field and setting them
accordingly.

For now, I added the following block to the end of 'kg_ctx_internalize'
(ser_sctx.c):

            switch (ctx->subkey->enctype) {
		case ENCTYPE_DES_CBC_MD5:
		case ENCTYPE_DES_CBC_CRC:
		case ENCTYPE_DES3_CBC_SHA1:
		case ENCTYPE_ARCFOUR_HMAC:
      			ctx->proto = 0;
			break;
		default:
                        ctx->proto = 1;
			kret = krb5int_c_mandatory_cksumtype(kcontext,
				ctx->subkey->enctype,
				&ctx->cksumtype);
			break;
            }
     	    /* Get trailer */


-Wyllys


> 
> I suppose 'proto' could be set after the serialization by examining the 
> enctypes (as its done in accept_sec_context, for example), but it should
> probably be serialized along with everything else in the structure.
> 
> Also - the large block comment describing the contents to be serialized
> needs to be updated to show the new 64 bit values.
> 
> -Wyllys