Incompatability between MIT Kerberos V 1.2.2 and MIT Kerberos V 1.3.1

[Scooter Morris]

I have found an incompatability between 1.2.2 and 1.3.1 that has been 
causing us problems.  The specific example is using a 1.2.2 Master KDC 
and replicating to a 1.3.1 slave (although I suspect that the problem is 
more general).  In our case, we are running 1.2.2 on a Tru64 Cluster and 
I was trying to replicate to a Solaris machine running 1.3.1 using the 
standard kprop/kpropd.  Sometimes this worked (i.e. the database was 
correctly transmitted and loaded into the slave machine), but sometimes 
I get a checksum error (message was changed...).  After a lot of 
debugging, it turns out that this can be traced to a single change in 
src/lib/krb5/asn.1/asn1_k_encode.c:

RCS file: 
/usr/src/cvs/cvsroot/contrib/Kerberos/src/lib/krb5/asn.1/asn1_k_encode.c,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 asn1_k_encode.c
*** asn1_k_encode.c     11 Aug 2003 22:28:46 -0000      1.1.1.3
--- asn1_k_encode.c     13 Sep 2003 19:51:45 -0000
***************
*** 643,658 ****
    if(val->r_address != NULL)
      asn1_addfield(val->r_address,5,asn1_encode_host_address);
    asn1_addfield(val->s_address,4,asn1_encode_host_address);
    if(val->seq_number)
!     asn1_addfield(val->seq_number,3,asn1_encode_unsigned_integer);
    if(val->timestamp){
      asn1_addfield(val->usec,2,asn1_encode_integer);
      asn1_addfield(val->timestamp,1,asn1_encode_kerberos_time);
    }
    if (val->user_data.length && val->user_data.data == NULL)
          return ASN1_MISSING_FIELD;
!   
asn1_addlenfield(val->user_data.length,val->user_data.data,0,asn1_encode_charstring)
! ;
 
    asn1_makeseq();
    asn1_cleanup();
--- 643,664 ----
    if(val->r_address != NULL)
      asn1_addfield(val->r_address,5,asn1_encode_host_address);
    asn1_addfield(val->s_address,4,asn1_encode_host_address);
+
+ /*
+  * WARNING!!!  This needs to be asn1_encode_integer to be compatable
+  * with older versions!!
+  * if(val->seq_number)
+  *   asn1_addfield(val->seq_number,3,asn1_encode_unsigned_integer);
+  */
    if(val->seq_number)
!     asn1_addfield(val->seq_number,3,asn1_encode_integer);
    if(val->timestamp){
      asn1_addfield(val->usec,2,asn1_encode_integer);
      asn1_addfield(val->timestamp,1,asn1_encode_kerberos_time);
    }
    if (val->user_data.length && val->user_data.data == NULL)
          return ASN1_MISSING_FIELD;
!   
asn1_addlenfield(val->user_data.length,val->user_data.data,0,asn1_encode_charstring);
 
    asn1_makeseq();
    asn1_cleanup();

When the sequence number is large (i.e. negative), the 1.2.2 system 
encodes it as an integer and sends it.  The 1.3.1 system correctly 
receives and decodes it.  So far, so good.  Not, the 1.3.1 system 
re-encodes the message to calculate and compare the checksums.  This is 
where the change causes problems.  The asn1_encode_unsigned_integer 
routine will insert an extra byte in the encoded stream to preserve the 
high-order bit without making it negative.  This, unfortunately, causes 
the checksums not to validate and the data is rejected.

Its certainly true that for this limited circumstance (kprop/kpropd) we 
will be moving to an all 1.3.1 system fairly quickly, so this problem 
will go away (the current replication is part of our testing for the 
eventual move to 1.3.1).  However, I suspect that other clients and 
services use mk_safe and rd_safe and this problem will be exhibited in 
other circumstances.  For now we've applied the patch described above, 
but I would be interested in the rationale for changing the encoding for 
safe_body...

-- scooter

Scooter Morris
Genentech, Inc.
scooter at gene.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/krbdev/attachments/20030913/ad6654bc/attachment.htm