Ticket History #1893: krb-safe incompatability between krb5-1.2.2 and krb5-1.3.1

# Wed Sep 24 19:56:25 2003 tlyu (Taylor Yu) - Ticket created

To:	rt-krb5@krbdev.mit.edu
Subject:	[Scooter Morris <scooter@gene.COM>] Incompatability between MIT Kerberos V 1.2.2 and MIT Kerberos V 1.3.1
From:	Tom Yu <tlyu@mit.edu>
Date:	Wed, 24 Sep 2003 19:56:21 -0400

Download (untitled)
message/rfc822 14.6KiB

Return-Path: <krbdev-bounces@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@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@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@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@mit.edu>; Sat, 13 Sep 2003 13:15:24 -0700 (PDT)
Message-ID: <3F637ADB.1020307@gene.com>
Date: Sat, 13 Sep 2003 13:15:23 -0700
From: Scooter Morris <scooter@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@mit.edu
Subject: Incompatability between MIT Kerberos V 1.2.2 and MIT Kerberos V
1.3.1
X-BeenThere: krbdev@mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: Kerberos Developers Mailing List <krbdev.mit.edu>
List-Help: <mailto:krbdev-request@mit.edu?subject=help>
List-Post: <mailto:krbdev@mit.edu>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/krbdev>,
<mailto:krbdev-request@mit.edu?subject=subscribe>
List-Archive: <http://mailman.mit.edu/pipermail/krbdev>
List-Unsubscribe: <https://mailman.mit.edu/mailman/listinfo/krbdev>,
<mailto:krbdev-request@mit.edu?subject=unsubscribe>
Sender: krbdev-bounces@MIT.EDU
Errors-To: krbdev-bounces@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@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: 
 
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. 
<a class="moz-txt-link-abbreviated" href="mailto:scooter@gene.com">scooter@gene.com</a> 
</body>
</html>

--===-=-=--

--==-=-=

Show quoted text

_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

--==-=-=--

# Wed Sep 24 20:03:56 2003 tlyu (Taylor Yu) - Requestor <scooter@gene.COM> added

# Wed Sep 24 20:03:57 2003 tlyu (Taylor Yu) - Subject changed from '[Scooter Morris <scooter@gene.COM>] Incompatability between MIT Kerberos V 1.2.2 and MIT Kerberos V 1.3.1' to 'krb-safe incompatability between krb5-1.2.2 and krb5-1.3.1'

# Wed Sep 24 20:03:57 2003 tlyu (Taylor Yu) - Status changed from 'new' to 'open'

# Wed Sep 24 20:03:57 2003 tlyu (Taylor Yu) - Given to tlyu (Taylor Yu)

# Wed Sep 24 20:03:58 2003 tlyu (Taylor Yu) - Component krb5-libs added

# Wed Sep 24 20:03:58 2003 tlyu (Taylor Yu) - Version_reported 1.3.1 added

# Wed Sep 24 20:03:59 2003 tlyu (Taylor Yu) - Comments added

Download (untitled) / with headers
text/plain 229B

The encoding was updated to align with the latest internet-draft for
kerberos-clarifications, which specifies unsigned sequence numbers. The
real problem is the re-encoding of the krb-safe message, which really
shouldn't happen.

# Mon Sep 29 20:02:29 2003 tlyu (Taylor Yu) - Target_Version 1.3.2 added

# Wed Oct 08 19:53:40 2003 tlyu (Taylor Yu) - Status changed from 'open' to 'resolved'

# Wed Oct 08 19:53:41 2003 tlyu (Taylor Yu) - Tags pullup added

# Wed Oct 08 19:53:41 2003 tlyu (Taylor Yu) - Correspondence added

From:	tlyu@mit.edu
Subject:	CVS Commit

Download (untitled) / with headers
text/plain 738B

Save encoded KRB-SAFE-BODY to avoid problems caused by re-encoding it.
Also, handle correctly implemented RFC 1510 KRB-SAFE i.e., checksummed
over KRB-SAFE-BODY only.

To generate a diff of this commit:

cvs diff -r1.392 -r1.393 krb5/src/include/ChangeLog
cvs diff -r1.154 -r1.155 krb5/src/include/k5-int.h
cvs diff -r5.144 -r5.145 krb5/src/lib/krb5/asn.1/ChangeLog
cvs diff -r5.32 -r5.33 krb5/src/lib/krb5/asn.1/asn1_k_encode.c
cvs diff -r5.15 -r5.16 krb5/src/lib/krb5/asn.1/asn1_k_encode.h
cvs diff -r5.44 -r5.45 krb5/src/lib/krb5/asn.1/krb5_decode.c
cvs diff -r5.28 -r5.29 krb5/src/lib/krb5/asn.1/krb5_encode.c
cvs diff -r5.423 -r5.424 krb5/src/lib/krb5/krb/ChangeLog
cvs diff -r5.54 -r5.55 krb5/src/lib/krb5/krb/rd_safe.c

# Fri Oct 10 19:57:57 2003 tlyu (Taylor Yu) - Version_Fixed 1.3.2 added

# Fri Oct 10 19:57:58 2003 tlyu (Taylor Yu) - Correspondence added

From:	tlyu@mit.edu
Subject:	CVS Commit

Download (untitled) / with headers
text/plain 675B

pullup from trunk

To generate a diff of this commit:

cvs diff -r1.348.2.25 -r1.348.2.26 krb5/src/include/ChangeLog
cvs diff -r1.135.2.12 -r1.135.2.13 krb5/src/include/k5-int.h
cvs diff -r5.135.2.7 -r5.135.2.8 krb5/src/lib/krb5/asn.1/ChangeLog
cvs diff -r5.29.2.3 -r5.29.2.4
krb5/src/lib/krb5/asn.1/asn1_k_encode.c
cvs diff -r5.14.2.1 -r5.14.2.2
krb5/src/lib/krb5/asn.1/asn1_k_encode.h
cvs diff -r5.40.2.4 -r5.40.2.5
krb5/src/lib/krb5/asn.1/krb5_decode.c
cvs diff -r5.25.2.3 -r5.25.2.4
krb5/src/lib/krb5/asn.1/krb5_encode.c
cvs diff -r5.378.2.29 -r5.378.2.30 krb5/src/lib/krb5/krb/ChangeLog
cvs diff -r5.52.2.2 -r5.52.2.3 krb5/src/lib/krb5/krb/rd_safe.c

# Wed Dec 16 18:02:41 2015 tlyu (Taylor Yu) - CustomField pullup deleted