Skip Menu |
 

History Show all quoted text — Show full headers
# Wed Dec 10 14:01:00 2003 The RT System itself - Ticket #2059: - Ticket created
Download (untitled) / with headers
text/plain 2.7KiB
From kwc@babylon.citi.umich.edu Wed Dec 10 14:00:58 2003
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by krbdev.mit.edu (8.9.3p2) with ESMTP
id OAA02488; Wed, 10 Dec 2003 14:00:58 -0500 (EST)
Received: from citi.umich.edu (citi.umich.edu [141.211.133.111])
by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id hBAJ0vfD029508
for <krb5-bugs@mit.edu>; Wed, 10 Dec 2003 14:00:57 -0500 (EST)
Received: from babylon.citi.umich.edu (babylon.citi.umich.edu [141.211.133.5])
(using TLSv1 with cipher EDH-DSS-DES-CBC3-SHA (168/168 bits))
(No client certificate requested)
by citi.umich.edu (Postfix) with ESMTP id 69A74207D7
for <krb5-bugs@mit.edu>; Wed, 10 Dec 2003 14:00:57 -0500 (EST)
Received: (from kwc@localhost)
by babylon.citi.umich.edu (8.12.10/8.12.10/Submit) id hBAJ0vXs022390;
Wed, 10 Dec 2003 14:00:57 -0500
Date: Wed, 10 Dec 2003 14:00:57 -0500
Message-Id: <200312101900.hBAJ0vXs022390@babylon.citi.umich.edu>
To: krb5-bugs@mit.edu
Subject: enctype coercion should go away?
From: kwc@citi.umich.edu
Reply-To: kwc@citi.umich.edu
Cc:
X-send-pr-version: 3.99


Show quoted text
>Submitter-Id: net
>Originator: Kevin Coffman
>Organization:
University of Michigan -- CITI
Show quoted text
>Confidential: no
>Synopsis: enctype coercion results in bad enctype
>Severity: serious
>Priority: medium
>Category: krb5-libs
>Class: sw-bug
>Release: krb5-1.3.1
>Environment:

System: Linux babylon.citi.umich.edu 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686 i686 i386 GNU/Linux
Architecture: i686

Show quoted text
>Description:
When calling kadm5_decrypt_key() as follows, the enctype in the
returned encrypting_key is -1, which is invalid.

if ((retval = kadm5_decrypt_key(handle,
&server,
-1, /* -1 say "don't care" */
-1,
0,
encrypting_key, NULL, NULL))) {

Show quoted text
>How-To-Repeat:
>Fix:

It appears that this coercion should be removed, but this patch
fixed our problem.

[ 87 ] rock/.../srv% cvs diff -ub -r MIT_1_3_1 svr_principal.c
Index: svr_principal.c
===================================================================
RCS file: /afs/umich.edu/group/itd/software/packages/k/kerberos-5/cvs/krb5/src/lib/kadm5/srv/svr_principal.c,v
retrieving revision 1.1.1.4
diff -u -b -r1.1.1.4 svr_principal.c
--- svr_principal.c 21 Jul 2003 20:36:07 -0000 1.1.1.4
+++ svr_principal.c 10 Dec 2003 18:51:18 -0000
@@ -1772,6 +1772,9 @@
* inexact match on the enctype; this behavior will go away when
* the key storage architecture gets redesigned for 1.3.
*/
+#if defined(UMICH)
+ if (ktype != -1)
+#endif
keyblock->enctype = ktype;

if (kvnop)
# Wed Dec 10 14:01:02 2003 The RT System itself - Ticket #2059: - Component krb5-libs added
# Wed Dec 10 14:01:02 2003 The RT System itself - Ticket #2059: - Version_reported 1.3.1 added
# Thu Jul 14 16:39:02 2005 kwc@citi.umich.edu (Kevin Coffman) - Ticket #2059: - Correspondence added
To: rt@krbdev.mit.edu
Cc: kwc@citi.umich.edu
Subject: Re: [krbdev.mit.edu #2059] enctype coercion results in bad enctype
Date: Thu, 14 Jul 2005 16:38:55 -0400
From: Kevin Coffman <kwc@citi.umich.edu>
RT-Send-Cc:
Download (untitled) / with headers
text/plain 129B
Hi,
I was just reminded that this problem still exists in 1.4.1.

Is there any chance of someone looking at this?

Thanks,
K.C.
# Fri Nov 09 15:14:47 2007 Jeffrey Altman <jaltman@secure-endpoints.com> - Ticket created
Date: Fri, 09 Nov 2007 14:59:11 -0500
From: Jeffrey Altman <jaltman@secure-endpoints.com>
To: krb5-bugs@mit.edu
Subject: Prevent kadm5_decrypt_key() from coercing the keytype if the requested ktype == -1
Download (untitled) / with headers
text/plain 708B
Please review this patch to kadm5_decrypt_key(). This patch prevents
the returned keyblock's enctype from being coerced to the requested
'ktype' if the requested 'ktype' == -1. A ktype of -1 is to be ignored.

Index: svr_principal.c

===================================================================

--- svr_principal.c (revision 20163)

+++ svr_principal.c (working copy)

@@ -2156,7 +2156,8 @@

* inexact match on the enctype; this behavior will go away when

* the key storage architecture gets redesigned for 1.3.

*/

- keyblock->enctype = ktype;

+ if (ktype == -1)

+ keyblock->enctype = ktype;

if (kvnop)

*kvnop = key_data->key_data_kvno;
Download smime.p7s
application/x-pkcs7-signature 3.2KiB

Message body not shown because it is not plain text.

# Fri Nov 09 15:28:31 2007 raeburn (Ken Raeburn) - Correspondence added
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [krbdev.mit.edu #5840] Prevent kadm5_decrypt_key() from coercing the keytype if the requested ktype == -1
Date: Fri, 9 Nov 2007 15:28:17 -0500
To: rt@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 460B
On Nov 9, 2007, at 15:14, Jeffrey Altman via RT wrote:
Show quoted text
> Please review this patch to kadm5_decrypt_key(). This patch prevents
> the returned keyblock's enctype from being coerced to the requested
> 'ktype' if the requested 'ktype' == -1. A ktype of -1 is to be
> ignored.

Is the use of -1 here something that is already happening elsewhere,
or something you're adding? I thought we had 0 as the magic enctype
value elsewhere, maybe I'm wrong.

Ken
# Fri Nov 09 15:35:24 2007 Jeffrey Altman <jaltman@secure-endpoints.com> - Correspondence added
Date: Fri, 09 Nov 2007 15:38:24 -0500
From: Jeffrey Altman <jaltman@secure-endpoints.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5840] Prevent kadm5_decrypt_key() from coercing the keytype if the requested ktype == -1
RT-Send-Cc:
Download (untitled) / with headers
text/plain 650B
Ken Raeburn via RT wrote:
Show quoted text
> On Nov 9, 2007, at 15:14, Jeffrey Altman via RT wrote:
>> Please review this patch to kadm5_decrypt_key(). This patch prevents
>> the returned keyblock's enctype from being coerced to the requested
>> 'ktype' if the requested 'ktype' == -1. A ktype of -1 is to be
>> ignored.
>
> Is the use of -1 here something that is already happening elsewhere,
> or something you're adding? I thought we had 0 as the magic enctype
> value elsewhere, maybe I'm wrong.
>
> Ken
Please read the comment at the top of the function. -1 means that the
ktype value should be ignored when searching for the correct keyblock entry.
Download smime.p7s
application/x-pkcs7-signature 3.2KiB

Message body not shown because it is not plain text.

# Fri Nov 09 15:44:17 2007 tlyu (Taylor Yu) - Correspondence added
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5840] Prevent kadm5_decrypt_key() from coercing the keytype if the requested ktype == -1
From: Tom Yu <tlyu@MIT.EDU>
Date: Fri, 09 Nov 2007 15:44:07 -0500
RT-Send-Cc:
Download (untitled) / with headers
text/plain 232B
Show quoted text
>>>>> "jaltman" == Jeffrey Altman via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
jaltman> + if (ktype == -1)
jaltman> + keyblock->enctype = ktype;

Isn't this backwards if you want -1 to mean the enctype doesn't get
coerced?
# Fri Nov 09 15:48:17 2007 Jeffrey Altman <jaltman@secure-endpoints.com> - Correspondence added
Date: Fri, 09 Nov 2007 15:51:21 -0500
From: Jeffrey Altman <jaltman@secure-endpoints.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5840] Prevent kadm5_decrypt_key() from coercing the keytype if the requested ktype == -1
RT-Send-Cc:
Download (untitled) / with headers
text/plain 919B
Tom Yu via RT wrote:
Show quoted text
>>>>>> "jaltman" == Jeffrey Altman via RT <rt-comment@krbdev.mit.edu> writes:
>
> jaltman> + if (ktype == -1)
> jaltman> + keyblock->enctype = ktype;
>
> Isn't this backwards if you want -1 to mean the enctype doesn't get
> coerced?
>
You are correct. I manually copied the patch backward. The problem
with manually pulling patches by eyeballing them from other systems.
Corrected patch:

Index: svr_principal.c

===================================================================

--- svr_principal.c (revision 20163)

+++ svr_principal.c (working copy)

@@ -2156,7 +2156,8 @@

* inexact match on the enctype; this behavior will go away when

* the key storage architecture gets redesigned for 1.3.

*/

- keyblock->enctype = ktype;

+ if (ktype != -1)

+ keyblock->enctype = ktype;

if (kvnop)

*kvnop = key_data->key_data_kvno;
Download smime.p7s
application/x-pkcs7-signature 3.2KiB

Message body not shown because it is not plain text.

# Fri Nov 09 16:16:59 2007 kwc@citi.umich.edu (Kevin Coffman) - Correspondence added
Date: Fri, 9 Nov 2007 16:16:52 -0500
From: "Kevin Coffman" <kwc@citi.umich.edu>
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5840] Prevent kadm5_decrypt_key() from coercing the keytype if the requested ktype == -1
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.2KiB
FYI, this is a dup of RT#2059.

On Nov 9, 2007 3:48 PM, Jeffrey Altman via RT <rt-comment@krbdev.mit.edu> wrote:
Show quoted text
> Tom Yu via RT wrote:
> >>>>>> "jaltman" == Jeffrey Altman via RT <rt-comment@krbdev.mit.edu> writes:
> >
> > jaltman> + if (ktype == -1)
> > jaltman> + keyblock->enctype = ktype;
> >
> > Isn't this backwards if you want -1 to mean the enctype doesn't get
> > coerced?
> >
> You are correct. I manually copied the patch backward. The problem
> with manually pulling patches by eyeballing them from other systems.
> Corrected patch:
>
> Index: svr_principal.c
>
> ===================================================================
>
> --- svr_principal.c (revision 20163)
>
> +++ svr_principal.c (working copy)
>
> @@ -2156,7 +2156,8 @@
>
> * inexact match on the enctype; this behavior will go away when
>
> * the key storage architecture gets redesigned for 1.3.
>
> */
>
> - keyblock->enctype = ktype;
>
> + if (ktype != -1)
>
> + keyblock->enctype = ktype;
>
> if (kvnop)
>
> *kvnop = key_data->key_data_kvno;
>
>
> _______________________________________________
>
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs
>
>
# Fri Nov 09 16:17:00 2007 kwc@citi.umich.edu (Kevin Coffman) - Comments added
Date: Fri, 9 Nov 2007 16:16:52 -0500
From: "Kevin Coffman" <kwc@citi.umich.edu>
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5840] Prevent kadm5_decrypt_key() from coercing the keytype if the requested ktype == -1
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.2KiB
FYI, this is a dup of RT#2059.

On Nov 9, 2007 3:48 PM, Jeffrey Altman via RT <rt-comment@krbdev.mit.edu> wrote:
Show quoted text
> Tom Yu via RT wrote:
> >>>>>> "jaltman" == Jeffrey Altman via RT <rt-comment@krbdev.mit.edu> writes:
> >
> > jaltman> + if (ktype == -1)
> > jaltman> + keyblock->enctype = ktype;
> >
> > Isn't this backwards if you want -1 to mean the enctype doesn't get
> > coerced?
> >
> You are correct. I manually copied the patch backward. The problem
> with manually pulling patches by eyeballing them from other systems.
> Corrected patch:
>
> Index: svr_principal.c
>
> ===================================================================
>
> --- svr_principal.c (revision 20163)
>
> +++ svr_principal.c (working copy)
>
> @@ -2156,7 +2156,8 @@
>
> * inexact match on the enctype; this behavior will go away when
>
> * the key storage architecture gets redesigned for 1.3.
>
> */
>
> - keyblock->enctype = ktype;
>
> + if (ktype != -1)
>
> + keyblock->enctype = ktype;
>
> if (kvnop)
>
> *kvnop = key_data->key_data_kvno;
>
>
> _______________________________________________
>
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs
>
>
# Fri Nov 09 16:21:56 2007 jaltman (Jeffrey Altman) - Ticket #2059: - Ticket 2059 MergedInto ticket 5840.
# Fri Nov 09 16:22:46 2007 jaltman (Jeffrey Altman) - Status changed from 'new' to 'open'
# Fri Nov 09 16:22:46 2007 jaltman (Jeffrey Altman) - Correspondence added
Download (untitled) / with headers
text/plain 13B
ticket merged
# Mon Jul 14 21:18:37 2008 jaltman (Jeffrey Altman) - Component krb5-admin added
# Mon Jul 21 16:33:58 2008 jaltman (Jeffrey Altman) - Given to jaltman (Jeffrey Altman)
# Mon Jul 21 16:33:59 2008 jaltman (Jeffrey Altman) - Status changed from 'open' to 'review'
# Mon Jul 21 16:33:59 2008 jaltman (Jeffrey Altman) - Tags pullup added
# Mon Jul 21 16:33:59 2008 jaltman (Jeffrey Altman) - Correspondence added
From: jaltman@mit.edu
Subject: SVN Commit
Download (untitled) / with headers
text/plain 307B

kadm5_decrypt_key(). This patch prevents the returned keyblock's
enctype from being coerced to the requested 'ktype' if the requested
'ktype' == -1. A ktype of -1 is documented as meaning "to be ignored".


Commit By: jaltman



Revision: 20558
Changed Files:
U trunk/src/lib/kadm5/srv/svr_principal.c
# Fri Jul 25 17:08:01 2008 tlyu (Taylor Yu) - Status changed from 'review' to 'resolved'
# Fri Jul 25 17:08:02 2008 tlyu (Taylor Yu) - Version_Fixed 1.6.4 added
# Fri Jul 25 17:08:03 2008 tlyu (Taylor Yu) - Correspondence added
From: tlyu@mit.edu
Subject: SVN Commit
Download (untitled) / with headers
text/plain 468B

pull up r20558 from trunk

r20558@cathode-dark-space: jaltman | 2008-07-21 16:33:53 -0400
ticket: 5840
tags: pullup

kadm5_decrypt_key(). This patch prevents the returned keyblock's
enctype from being coerced to the requested 'ktype' if the requested
'ktype' == -1. A ktype of -1 is documented as meaning "to be ignored".




Commit By: tlyu



Revision: 20584
Changed Files:
_U branches/krb5-1-6/
U branches/krb5-1-6/src/lib/kadm5/srv/svr_principal.c
# Wed Dec 16 18:02:51 2015 tlyu (Taylor Yu) - CustomField pullup deleted