Skip Menu |
 

History Show all quoted text — Show full headers
# Thu Oct 25 19:30:35 2012 Richard Basch <basch@alum.mit.edu> - Ticket created
Date: Thu, 25 Oct 2012 19:25:49 -0400
From: Richard Basch <basch@alum.mit.edu>
Subject: krb5-1.10.3: Updating krbtgt with kvno 0
To: krb5-bugs@mit.edu
Download (untitled) / with headers
text/plain 1.2KiB
Download (untitled) / with headers
text/html 3.5KiB

I was experimenting with a Kerberos database which was constructed in the early 1990s when the db_creation would create krbtgt with kvno = 0.

 

If you try to update the krbtgt, using “cpw –randkey –keepold krbtgt/XXX”, the old key cannot effectively be used by clients. *_search_enctypes and *_find_enctypes allow kvno to be passed in as a search criteria, but the default routine (in lib/kdb/kdb_default.c) will treat kvno=0 as a flag to return the latest kvno. Ironically, it also treats -1 the same way.

 

This problem with krbtgt key rotation only occurs when you have a krbtgt with kvno=0 (which again can happen if the database was created long ago but the key was never updated).

 

A quick fix is to change the KDC code to pass in kvno=-1 when searching for “latest key” and change the routine such that kvno=0 will return kvno 0 if found or latest key if not found (that way, the API is relatively cleanly preserved).

 

lib/kdb/kdb_default.c

 

Fix calls from:

plugins/kdb/hdb/kdb_windc.c

kdc/kdc_preauth.c

kdc/kdc_preauth_encts.c

kdc/do_as_req.c

kdc/do_tgs_req.c

kdc/kdc_util.c

 

If you agree with the above approach, I will send in a patch… (though it is probably not difficult to re-implement with the above description of the framework).

# Thu Oct 25 19:34:53 2012 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 633B
krb5_dbe_def_search_enctype does not currently treat kvno 0 the same way
as kvno -1. kvno -1 means "ignore the kvno", while kvno 0 means "search
only in the highest kvno". (Confusingly, if you pass kvno, stype, and
ktype all as -1, the code optimizes by setting kvno to 0 in order to look
only at entries of highest kvno, without a comment explaining what it's
doing.)

It may be that we don't need both modes of operation. Offhand, I can't
imagine a situation where you want to search for a particular enctype
and/or salt type across all key versions. But we'd need to analyze all
of the call sites to make sure of that.
# Thu Oct 25 22:06:24 2012 Richard Basch <basch@alum.mit.edu> - Comments added
Date: Thu, 25 Oct 2012 22:06:19 -0400
From: Richard Basch <basch@alum.mit.edu>
Subject: RE: [krbdev.mit.edu #7432] krb5-1.10.3: Updating krbtgt with kvno 0
To: rt-comment@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.9KiB
Admittedly, all the calls where the KDC was searching for the latest kvno,
it was also passing -1 for the other two values.

But, by having the function treat 0 as a special case for retrieving the
latest kvno, it creates issues if you are trying to do a cpw on a key with
-keepold and it was previously kvno=0. In my case, I had a database with
krbtgt where kvno=0 because it was created in the early 1990s (back when the
db_creation initialized with kvno=0 instead of kvno=1). Trying to update
the key while maintaining compatibility with clients was proving
problematic. Basically, in this case, all client caches would become
"invalid" instantly if I were to update krbtgt, whereas had kvno >= 1, there
would have been no issue.

Any ideas how we should fix this case? (I hacked the files I stated so I
didn't impact all the clients.)

You can probably infer the exact situation I am facing, since I was planning
to randomize the krbtgt in the upcoming couple weeks for a large Kerberos
installation (with hundreds of millions of authentications daily and where I
cannot simply invalidate everyone's ticket caches, even during a low-usage
period).


Show quoted text
-----Original Message-----
From: Greg Hudson via RT [mailto:rt-comment@krbdev.mit.edu]
Sent: Thursday, October 25, 2012 7:35 PM
To: basch@alum.mit.edu
Subject: [krbdev.mit.edu #7432] krb5-1.10.3: Updating krbtgt with kvno 0

krb5_dbe_def_search_enctype does not currently treat kvno 0 the same way
as kvno -1. kvno -1 means "ignore the kvno", while kvno 0 means "search
only in the highest kvno". (Confusingly, if you pass kvno, stype, and
ktype all as -1, the code optimizes by setting kvno to 0 in order to look
only at entries of highest kvno, without a comment explaining what it's
doing.)

It may be that we don't need both modes of operation. Offhand, I can't
imagine a situation where you want to search for a particular enctype
and/or salt type across all key versions. But we'd need to analyze all
of the call sites to make sure of that.
# Fri Oct 26 01:02:41 2012 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 733B
I understand the problem. For this specific deployment issue, you might
consider whether it would work to alter the krbtgt DB entry such that the
kvno in the key data 1 but the keys are the same, then wait for all of
the tickets to turn over.

Further confounding the issue, we use a kvno of 0 to represent an omitted
kvno field in the ASN.1 marshalling of krb5_enc_data, both incoming and
outgoing. So, for instance, I understand that Active Directory KDCs
generally omit the kvno in a cross-realm TGT, and we have code in the
current kdc_rd_ap_req() which handles that by checking the last few
kvnos. That code relies on the omitted kvno translating to a value which
means "the most recent kvno" to the search function.