Ticket History #897: lossage from SUPPORT_DESMD5 (long-ish)

From jrudd@kzin.ucsc.edu Fri Oct 20 17:07:05 2000
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
by rt-11.mit.edu (8.9.3/8.9.3) with SMTP id RAA09244
for <bugs@RT-11.MIT.EDU>; Fri, 20 Oct 2000 17:07:01 -0400 (EDT)
Received: from kzin.ucsc.edu by MIT.EDU with SMTP
id AA24844; Fri, 20 Oct 00 17:06:46 EDT
Received: (from jrudd@localhost)
by kzin.ucsc.edu (8.9.3/8.9.3) id OAA03988
for krb5-bugs@mit.edu; Fri, 20 Oct 2000 14:06:58 -0700
Message-Id: <200010202106.OAA03988@kzin.ucsc.edu>
Date: Fri, 20 Oct 2000 14:06:58 -0700
From: John Rudd <jrudd@cats.ucsc.edu>
To: krb5-bugs@MIT.EDU
Subject: Problem with Bad Encryption Type errors.

University of California Santa Cruz


System: SunOS cerebus.ucsc.edu 5.8 Generic sun4u sparc SUNW,Ultra-5_10
Architecture: sun4


I'm using MIT k5 v 1.2.1 on all of the k5 hosts in question. I'm not
sure what version my k4 hosts are using, but they're not the problem.

Whenever I try to ksu, or invoke a kerberized rlogin, I get the following
error:

# ksu
WARNING: Your password may be exposed if you enter it here and are logged
in remotely using an unsecure (non-encrypted) channel.
Kerberos password for jrudd/secure@CATS.UCSC.EDU:
ksu: Generic error (see e-text) while geting credentials from kdc
Authentication failed.

And here's what shows up in the kerberos logs:

Oct 20 13:36:44 cerebus.ucsc.edu krb5kdc[1885](info): TGS_REQ 128.114.2.122(88):
PROCESS_TGS: authtime 0, <unknown client> for host/kzin.ucsc.edu@CATS.UCSC.EDU,
Bad encryption type


Note: support of V4 clients works just one. This is only happening with
V5 clients.

Here's my kdc.conf (indents are tabs in the actual file):

[kdcdefaults]
kdc_ports = 88,750
v4_mode = full

[realms]
CATS.UCSC.EDU = {
database_name = /usr/local/var/krb5kdc/principal.db
admin_keytab = /usr/local/var/krb5kdc/kadm5.keytab
acl_file = /usr/local/var/krb5kdc/kadm5.acl
dict_file = /usr/local/var/krb5kdc/kadm5.dict
key_stash_file = /usr/local/var/krb5kdc/.k5.CATS.UCSC.EDU
kadmind_port = 749
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des-cbc-crc
encryption_type = des-cbc-crc
supported_keytypes = des-cbc-crc:normal des-cbc-crc:v4
}


here's my krb5.conf:

[libdefaults]
default_tgs_enctypes = des-cbc-crc
default_tkt_enctypes = des-cbc-crc
default_realm = CATS.UCSC.EDU
ticket_lifetime = 600
krb4_srvtab = /etc/athena/srvtab
krb4_config = /etc/athena/krb.conf
krb4_realms = /etc/athena/krb.realms



[realms]
CATS.UCSC.EDU = {
kdc = krb5.ucsc.edu:88
admin_server = krb5.ucsc.edu:749
default_domain = ucsc.edu
}

[domain_realm]
.ucsc.edu = CATS.UCSC.EDU
ucsc.edu = CATS.UCSC.EDU

[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log




Do a ksu, or try to use your V5 tickets to rlogin to another host.


Wish I had one.

I have tried changing the supported keytypes in kdc.conf to include
"des:normal", since that's how the _FAQ_ lists it (even though the
html documentation included with the distribution says "des-cbc-crc:normal").
Different documentation provided by MIT conflicts about the names of
the supported_keytypes (or is it sypported_enctypes? depends on which
documentation you read) field names, etc. (the man pages for the kdc
even conflict with the documentation as to which port is supposed to
be named kerberos-sec vs kerberos in an env. with v4 compatability)

So, what I'm asking for is:

1) how to fix the problem I'm having with my k5 clients, and


2) please update, fix, and synchronize all of your different documentation
so that even if they're wrong, they all agree with eachother.


From: Ken Raeburn <raeburn@MIT.EDU>
To: John Rudd <jrudd@cats.ucsc.edu>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-kdc/897: Problem with Bad Encryption Type errors.
Date: 20 Oct 2000 17:14:34 -0400

John Rudd <jrudd@cats.ucsc.edu> writes:


Could you try "klist -e" and let us know the session key type in your
ticket-granting ticket, in a session where rlogin has broken this way?
(ksu is kind of, well, "special" in a number of ways; I'd rather look
at the rlogin situation, and after that's working see if ksu is still
broken.)

Your config files looked good to me.


Ugh. I knew our documentation had some problems, but I didn't realize
we had so many inconsistencies...

From: John Rudd <jrudd@cats.ucsc.edu>
To: raeburn@mit.edu
Cc: krb5-bugs@mit.edu
Subject: Re: krb5-kdc/897: Problem with Bad Encryption Type errors.
Date: Fri, 20 Oct 2000 16:37:13 -0700

(re-sending this because I realized I only replied to Ken, and not to
the krb5-bugs address as well)

Hi Ken,

Long time no type (in case you don't remember me, I used to be a
sysadmin at Cygnus).


Ken Raeburn wrote:

Here's the "klist -e" output:

# klist -e
Ticket cache: FILE:/tmp/krb5cc_11654
Default principal: jrudd@CATS.UCSC.EDU

Valid starting Expires Service principal
10/20/00 14:24:27 10/21/00 00:24:27 krbtgt/CATS.UCSC.EDU@CATS.UCSC.EDU
Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with
RSA-MD5


Kerberos 4 ticket cache: /tmp/tkt11654
Principal: jrudd@CATS.UCSC.EDU

Issued Expires Principal
10/13/00 15:45:03 10/14/00 01:45:03 krbtgt.CATS.UCSC.EDU@CATS.UCSC.EDU



The interesting thing here to me is that it has the thing about
RSA-MD5. The supported_keytypes line in my kdc.conf used to read:

supported_enctypes = des-cbc-crc:normal des-cbc-crc:v4
des-cbc-md5:normal des-cbc-md5:v4

(note: supported_enctypes instead of supported_keytypes)

This was at Eric Mumpower's suggestion when I was trying to figure out
why krb524init wasn't working (and still isn't ... also giving a Bad
Encryption Type error). In the last week, I took those out because I
was trying to reduce the number of choices for where things might be
failing (and, I was under the impression the md5 stuff wasn't actually
being used).

The krb5.conf used to also have the following lines:

default_tkt_enctypes = des-cbc-crc des-cbc-md5
default_tgs_enctypes = des-cbc-crc des-cbc-md5
permitted_enctypes = des3-cbc-hmac-sha1 des-cbc-crc des-cbc-md5

And, again, that extra type was at Eric's suggestion. I was having the
same problem before I removed these extra types.

(though, I wonder if the original problem was "supported_enctypes", and
when I made 2 changes at once (supported_enctypes -> supported_keytypes,
and removing md5) I fixed one and broke the other in one step ... but
I'm not really knowledgable enough about kerberos to know if that's a
reasonable thought on my part ... in order to keep from giving you a
moving target, I'll wait to reverse that until you say it's worth
trying)



I'll try to document as many as I can and send in pr's for them. But I
understand how things get that way.


Thanks for any help,

John

--
John "kzin" Rudd http://www.domain.org/users/kzin
Truth decays into beauty, while beauty soon becomes merely charm. Charm
ends up as strangeness, and even that doesn't last. (Physics of Quarks)
-----===== Kein Mitleid Fu:r MicroSoft (www.kmfms.com) ======-----

From: John Rudd <jrudd@cats.ucsc.edu>
To: raeburn@MIT.EDU, krb5-bugs@MIT.EDU
Cc: Subject: Re: krb5-kdc/897: Problem with Bad Encryption Type errors.
Date: Mon, 30 Oct 2000 12:15:37 -0800

John Rudd wrote:

So, I did some more foot work trying to figure some of this out.

I created a seperate test realm and ran it using the same software, but
a completely new and clean database. Everything works fine in that
realm (rlogin, ksu, krb524init ... all things that aren't working in the
production realm, all giving bad encryption type errors). I was
wondering if maybe I had build in an environment that had something
missing and was thus causing an obscure failure, or if there was some
new hoop I had to jump through for supporting Solaris 8 and/or Redhat
6.1 ... but neither of those seem to be the case now that I've
sucessfully tested the same software using a different realm.

So, that makes me wonder about the encryption types that are stored in
the production realm.


I checked on the krbtgt/CATS.UCSC.EDU@CATS.UCSC.EDU principle vs. the on
in the test realm (TEST.UCSC.EDU), and I noticed a couple interesting
differences:

Key: vno 2, DES cbc mode with CRC-32, Version 4
Attributes: SUPPORT_DESMD5


The first part I expect, but I don't know if it causes a problem for the
krbtgt to be in v4 format in a v5 realm. The second part threw me off.
My tes realm doesn't have any Attributes set on krbtgt principle. Could
this be why kinit is issuing a md5 ticket for the tkt? and, could that
be what's wrong with the bad encryption type? I know I can try doing a
modprinc to get rid of that attribute (though, I don't know if there's
an actual option for that particular attribute in kadmin), but would
there be any strange side effects to doing so?


If that's NOT the problem, and I need to search through the entire
database to find out who might have non- des-cbc-crc:(normal,v4) keys,
how would I search the entire database for that? does getprincs allow
searches on something other than principle name? (the man page would
indicate it doesn't) I know that if I dump the database, I don't get
any plain text indication of key types.


--
John "kzin" Rudd http://www.domain.org/users/kzin
Truth decays into beauty, while beauty soon becomes merely charm. Charm
ends up as strangeness, and even that doesn't last. (Physics of Quarks)
-----===== Kein Mitleid Fu:r MicroSoft (www.kmfms.com) ======-----

From: John Rudd <jrudd@cats.ucsc.edu>
To: Ken Raeburn <raeburn@MIT.EDU>, krb5-bugs@MIT.EDU
Cc: Subject: Re: krb5-kdc/897: Problem with Bad Encryption Type errors.
Date: Wed, 01 Nov 2000 15:04:47 -0800

So, after my last message, the presence of that Attribute in the krbtgt
for my realm was really bugging me. So I created a test realm, deleted
the krbtgt in that realm, and created a new one with a -randkey.
Nothing seemed to break, so then I moved on to another test. I copied
my production realm over to a test server, and did the same thing to
that copy of the production realm.

1) again, nothing seems to have broken in that copy of the production
realm

2) the bad encryption type errors were initially showing up in the copy
realm, and then went away after I performed this magic (leading me to
believe it will fix the production realm too). The new krbtgt didn't
have the "SUPPORT_MD5" attribute set, either.

However, my tests were pretty trivial. I just did an rlogin and a ksu,
and it all worked. But that doesn't mean there aren't other side
effects to quickly replacing the krbtgt that I'm not aware of... so
that's what I'm asking you now:

Do you know of any side effects to doing this?

I expect that anyone with a current ticket granting ticket session will
need to renew themselves, so I'm going to do it at an off time. But
otherwise, I don't know what to expect. I was suprised that recreating
it didn't seem to have any affect on my test realm as it was (though, I
wouldn't try doing that with the master key ;-) ).

I just want to be sure that, before I do this on the production realm, I
wont have to worry about strange side effects (though, I do plan to
backup the database before I do it, just in case).


John

--
John "kzin" Rudd http://www.domain.org/users/kzin
Truth decays into beauty, while beauty soon becomes merely charm. Charm
ends up as strangeness, and even that doesn't last. (Physics of Quarks)
-----===== Kein Mitleid Fu:r MicroSoft (www.kmfms.com) ======-----