[krbdev.mit.edu #1893] [Scooter Morris <scooter@gene.COM>] Incompatability between MIT Kerberos V 1.2.2 and MIT Kerberos V1.3.1
Tom Yu via RT
rt-comment at krbdev.mit.edu
Wed Sep 24 19:56:26 EDT 2003
Return-Path: <krbdev-bounces at MIT.EDU>
Received: from po9.mit.edu (po9.mit.edu [18.7.21.65])
by po9.mit.edu (Cyrus v2.1.5) with LMTP; Sat, 13 Sep 2003 16:17:29 -0400
X-Sieve: CMU Sieve 2.2
Received: from fort-point-station.mit.edu by po9.mit.edu (8.12.4/4.7) id
h8DKHOpA026189; Sat, 13 Sep 2003 16:17:24 -0400 (EDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h8DKGpSg012418;
Sat, 13 Sep 2003 16:16:51 -0400 (EDT)
Received: from pch.mit.edu (localhost [127.0.0.1])
by pch.mit.edu (8.12.8p1/8.12.8) with ESMTP id h8DKFTk3025370;
Sat, 13 Sep 2003 16:15:30 -0400 (EDT)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
[18.7.7.76])
by pch.mit.edu (8.12.8p1/8.12.8) with ESMTP id h8DKFRk0025366
for <krbdev at PCH.mit.edu>; Sat, 13 Sep 2003 16:15:27 -0400 (EDT)
Received: from djinn.gene.com (socks-open.gene.com [192.12.78.2])
h8DKFPSg012083
for <krbdev at mit.edu>; Sat, 13 Sep 2003 16:15:26 -0400 (EDT)
Received: from leavenworth.gene.com (leavenworth.gene.com [128.137.56.15])
by djinn.gene.com (8.12.9/8.12.9) with ESMTP id h8DKFPDe062531
for <krbdev at mit.edu>; Sat, 13 Sep 2003 13:15:25 -0700 (PDT)
Received: from gene.com (dhcpXisdn225-10.gene.com [128.137.225.10])
by leavenworth.gene.com (8.12.9/8.12.8) with ESMTP id h8DKFN9I1032849
for <krbdev at mit.edu>; Sat, 13 Sep 2003 13:15:24 -0700 (PDT)
Message-ID: <3F637ADB.1020307 at gene.com>
Date: Sat, 13 Sep 2003 13:15:23 -0700
From: Scooter Morris <scooter at gene.COM>
Organization: Genenetech, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.5b) Gecko/20030903
X-Accept-Language: en-us, en
To: krbdev at mit.edu
Subject: Incompatability between MIT Kerberos V 1.2.2 and MIT Kerberos V
1.3.1
X-BeenThere: krbdev at mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: Kerberos Developers Mailing List <krbdev.mit.edu>
List-Help: <mailto:krbdev-request at mit.edu?subject=help>
List-Post: <mailto:krbdev at mit.edu>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/krbdev>,
<mailto:krbdev-request at mit.edu?subject=subscribe>
List-Archive: <http://mailman.mit.edu/pipermail/krbdev>
List-Unsubscribe: <https://mailman.mit.edu/mailman/listinfo/krbdev>,
<mailto:krbdev-request at mit.edu?subject=unsubscribe>
Sender: krbdev-bounces at MIT.EDU
Errors-To: krbdev-bounces at MIT.EDU
X-Spam-Score: -2.9
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Lines: 269
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==-=-="
--==-=-=
Content-Type: multipart/alternative; boundary="===-=-="
--===-=-=
Content-Type: text/plain; format=flowed
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
--===-=-=
Content-Type: text/html
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
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:<br>
<br>
<span style="font-family: monospace;">RCS file:
/usr/src/cvs/cvsroot/contrib/Kerberos/src/lib/krb5/asn.1/asn1_k_encode.c,v</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">retrieving revision 1.1.1.3</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">diff -c -r1.1.1.3 asn1_k_encode.c</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">*** asn1_k_encode.c 11 Aug
2003 22:28:46 -0000 1.1.1.3</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">--- asn1_k_encode.c 13 Sep
2003 19:51:45 -0000</span><br style="font-family: monospace;">
<span style="font-family: monospace;">***************</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">*** 643,658 ****</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> if(val->r_address != NULL)</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
asn1_addfield(val->r_address,5,asn1_encode_host_address);</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
asn1_addfield(val->s_address,4,asn1_encode_host_address);</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> if(val->seq_number)</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">!
asn1_addfield(val->seq_number,3,asn1_encode_unsigned_integer);</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> if(val->timestamp){</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
asn1_addfield(val->usec,2,asn1_encode_integer);</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
asn1_addfield(val->timestamp,1,asn1_encode_kerberos_time);</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> }</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> if (val->user_data.length
&& val->user_data.data == NULL)</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> return
ASN1_MISSING_FIELD;</span><br style="font-family: monospace;">
<span style="font-family: monospace;">!
asn1_addlenfield(val->user_data.length,val->user_data.data,0,asn1_encode_charstring)</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">! ;</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> </span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> asn1_makeseq();</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> asn1_cleanup();</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">--- 643,664 ----</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> if(val->r_address != NULL)</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
asn1_addfield(val->r_address,5,asn1_encode_host_address);</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
asn1_addfield(val->s_address,4,asn1_encode_host_address);</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">+ </span><br
style="font-family: monospace;">
<span style="font-family: monospace;">+ /*</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">+ * WARNING!!! This needs to be
asn1_encode_integer to be compatable</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">+ * with older versions!!</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">+ * if(val->seq_number)</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">+ *
asn1_addfield(val->seq_number,3,asn1_encode_unsigned_integer);</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">+ */</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> if(val->seq_number)</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">!
asn1_addfield(val->seq_number,3,asn1_encode_integer);</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> if(val->timestamp){</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
asn1_addfield(val->usec,2,asn1_encode_integer);</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">
asn1_addfield(val->timestamp,1,asn1_encode_kerberos_time);</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> }</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> if (val->user_data.length
&& val->user_data.data == NULL)</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> return
ASN1_MISSING_FIELD;</span><br style="font-family: monospace;">
<span style="font-family: monospace;">!
asn1_addlenfield(val->user_data.length,val->user_data.data,0,asn1_encode_charstring);</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> </span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> asn1_makeseq();</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"> asn1_cleanup();</span><br
style="font-family: monospace;">
<br>
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 <span
style="font-style: italic;">re-encodes</span> 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.<br>
<br>
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...<br>
<br>
-- scooter<br>
<br>
Scooter Morris<br>
Genentech, Inc.<br>
<a class="moz-txt-link-abbreviated" href="mailto:scooter at gene.com">scooter at gene.com</a><br>
</body>
</html>
--===-=-=--
--==-=-=
_______________________________________________
krbdev mailing list krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
--==-=-=--
More information about the krb5-bugs
mailing list