Projects/Larger key versions - Revision history

Ghudson: /* Release notes */

2015-08-25T02:12:44Z

‎Release notes

Ghudson: /* Release notes */

2015-08-25T02:12:28Z

‎Release notes

Ghudson at 16:49, 25 March 2015

2015-03-25T16:49:52Z

Ghudson: /* Chosen improvements */

2015-03-08T23:29:06Z

‎Chosen improvements

Ghudson: /* Chosen improvements */

2015-03-08T23:27:57Z

‎Chosen improvements

Ghudson at 23:03, 8 March 2015

2015-03-08T23:03:01Z

Ghudson: /* Chosen improvements */

2015-03-08T22:57:37Z

‎Chosen improvements

Ghudson: /* Chosen improvements */

2015-03-08T22:52:03Z

‎Chosen improvements

Ghudson at 21:52, 8 March 2015

2015-03-08T21:52:42Z

Ghudson at 21:11, 8 March 2015

2015-03-08T21:11:44Z

← Older revision		Revision as of 02:12, 25 August 2015
Line 83:		Line 83:
	Administrator experience:		Administrator experience:

−	* Add support for key version numbers larger than 255 in keytab files,	+	* Add support for key version numbers larger than 255 in keytab files, and for version numbers up to 65535 in KDC databases.
−	and for version numbers up to 65535 in KDC databases.

← Older revision		Revision as of 02:12, 25 August 2015
Line 81:		Line 81:
	==Release notes==		==Release notes==

−	XXX TBD
		+	Administrator experience:
		+
		+	* Add support for key version numbers larger than 255 in keytab files,
		+	and for version numbers up to 65535 in KDC databases.

← Older revision		Revision as of 16:49, 25 March 2015
Line 1:		Line 1:
−	{{project-~~early~~}}	+	{{project-rel\|1.14}}
−	{{project-target\|1.14}}

	==Background==		==Background==

@@ Line 63: / Line 63: @@
 * In the kadmin protocol, marshal the kvno and mkvno fields as unsigned 32-bit values instead of unsigned 8-bit values.
 * Implement the 32-bit kvno extension for the FILE keytab format.
-* Change the pivot workaround to consider any small version (less than 128) to be more recent than any large version (more than 240) if the timestamp of the smaller-versioned entry is the same or greater than the larger-versioned entry.
+* Change the pivot workaround to consider any small version (less than 128) to be more recent than any large version (more than 240) if the timestamp of the smaller-versioned entry is the same or greater than the larger-versioned entry.  This pivot logic is still order-dependent, but should work for kvno wraparounds at any boundary as long as only a small number of older keys are present.
 * Change the fuzzy match workaround to remember the first match against the low 8 bits of the desired version, but to keep searching for an exact match.

@@ Line 63: / Line 63: @@
 * In the kadmin protocol, marshal the kvno and mkvno fields as unsigned 32-bit values instead of unsigned 8-bit values.
 * Implement the 32-bit kvno extension for the FILE keytab format.
-* Change the pivot workaround to consider any small version (less than 128) to be more recent than any large version (at least 128 larger) if the timestamp of the smaller-versioned entry is the same or greater than the larger-versioned entry.
+* Change the pivot workaround to consider any small version (less than 128) to be more recent than any large version (more than 240) if the timestamp of the smaller-versioned entry is the same or greater than the larger-versioned entry.
 * Change the fuzzy match workaround to remember the first match against the low 8 bits of the desired version, but to keep searching for an exact match.

@@ Line 69: / Line 69: @@
 t_keytab.py contains some existing tests for key rotation around kvno 255.  These will be expanded to verify that key versions do not wrap at 255 or 32767 and do wrap from 65535 to 1.  The tests will verify that <tt>ktrem</tt> preserves the more recent key after each rotation including after a wraparound.
 Tests will be added to verify edge cases of the FILE format 32-bit kvno extension, using hand-crafted entries.
@@ Line 81: / Line 79: @@
 {{bug|7532}}

@@ Line 28: / Line 28: @@
 * Fuzzy match: when searching for a specific key version, match against only the low 8 bits of the desired version.
-The current best practice for key rotation with kadmin is to use <tt>ktadd </tt>''princname'' to retrieve new random keys, and then <tt>ktrem </tt>''princname''<tt> old</tt> to remove old entries after the maximum ticket length has elapsed.  As long as only a few versions of the key are present in the keytab at a time, and <tt>ktrem</tt> will correctly pick the most recent key version to preserve even after a wraparound from 255 to 0.  If old versions are not regularly pruned, the pivot logic may not function correctly and <tt>ktrem</tt> could select an incorrect key version to preserve.  The pivot logic can have different outcomes based on entry order; for example, if a keytab contains key versions 80, 160, and 242 in that order, version 242 will be selected, whereas if the entries are ordered 160 242 80, version 80 will be selected.
+The current best practice for key rotation with kadmin is to use <tt>ktadd </tt>''princname'' to retrieve new random keys, and then <tt>ktrem </tt>''princname''<tt> old</tt> to remove old entries after the maximum ticket length has elapsed.  As long as only a few versions of the key are present in the keytab at a time, and <tt>ktrem</tt> will correctly pick the most recent key version to preserve even after a wraparound from 255 to 0.  If old versions are not regularly pruned, the pivot logic may not function correctly and <tt>ktrem</tt> could select an incorrect key version to preserve.  The pivot logic can have different outcomes based on entry order; for example, if a keytab contains key versions 80, 160, and 242 in that order, version 242 will be selected, whereas if the entries are ordered 160 242 80, version 80 will be selected.  Entry order in keytab files is unpredictable because new entries can replace deleted entries.
 When the key version reaches 32767, a subsequent <tt>ktadd</tt> operation will report kvno 0 to the client and store kvno 0 in the FILE keytab, as one would expect from an 8-bit wraparound.  However, the key data in the database stores the new key version as -32768.  Because of the special meaning for negative kvno values in krb5_dbe_def_search_enctype(), the server principal will not work (TGS requests will receive "KDC has no support for encryption type").  The next <tt>ktadd</tt> operation will use kvno value 1 and service resumes.
@@ Line 54: / Line 54: @@
 * We could disable the pivot logic upon seeing key versions greater than 255 but add new pivot logic around 16-bit boundaries.  This would be working around KDC limitations in the FILE keytab code, which is inelegant, and would also be complicated.
-* We could replace the old pivot logic with new logic based explicitly on the order of keytab entries rather than (or in addition to) the key versions themselves.  That is, if we see a small key version following a large key version, we could treat the small key version as highest, perhaps with some conditions such as if the large key version being near an 8-bit or 16-bit boundary.
+* We could replace the old pivot logic with new logic based on the timestamps of keytab entries rather than (or in addition to) the key versions themselves.
 There are also some considerations for the fuzzy match logic.  Since we know that the entry might have been written with a truncated key version, either due to a pre-1.14 kadmind or because the keytab was written by a pre-1.14 library, we should continue to allow fuzzy matches.  However, we can continue reading to see if there is an exact match in a later entry.
@@ Line 63: / Line 63: @@
 * In the kadmin protocol, marshal the kvno and mkvno fields as unsigned 32-bit values instead of unsigned 8-bit values.
 * Implement the 32-bit kvno extension for the FILE keytab format.
-* Change the pivot workaround to look for a precipitous drop (by at least 128 versions) to a small value (less than 128) from one matching entry to the next.
+* Change the pivot workaround to look for a precipitous drop (by at least 128 versions) to a small value (less than 128) from one matching entry to the next. (XXX reconsider since entry order is unpredictable)
 * Change the fuzzy match workaround to accept either an exact match or a match against the low 8 bits of the desired version, and to keep searching after an inexact match.

@@ Line 26: / Line 26: @@
 The FILE keytab code contains some workarounds for 8-bit key version limitations in krb5_ktfile_get_entry() which retrieves keytab entries.  The workarounds are:
 * Pivot: when searching for the highest key version, if any versions greater than 240 are seen, begin applying <tt>(kvno + 128) % 256</tt> to each version before comparing them, so that values 0-127 compare greater than values 128-255.
-* Fuzzy match: when searching for a specific key version, consider an entry's version equal to the desired kvno if the least significant 8 bits of the value match.
+* Fuzzy match: when searching for a specific key version, match against only the low 8 bits of the desired version.
 The current best practice for key rotation with kadmin is to use <tt>ktadd </tt>''princname'' to retrieve new random keys, and then <tt>ktrem </tt>''princname''<tt> old</tt> to remove old entries after the maximum ticket length has elapsed.  As long as only a few versions of the key are present in the keytab at a time, and <tt>ktrem</tt> will correctly pick the most recent key version to preserve even after a wraparound from 255 to 0.  If old versions are not regularly pruned, the pivot logic may not function correctly and <tt>ktrem</tt> could select an incorrect key version to preserve.  The pivot logic can have different outcomes based on entry order; for example, if a keytab contains key versions 80, 160, and 242 in that order, version 242 will be selected, whereas if the entries are ordered 160 242 80, version 80 will be selected.
@@ Line 57: / Line 57: @@
 There are also some considerations for the fuzzy match logic.  Since we know that the entry might have been written with a truncated key version, either due to a pre-1.14 kadmind or because the keytab was written by a pre-1.14 library, we should continue to allow fuzzy matches.  However, we can continue reading to see if there is an exact match in a later entry.
 ==References==