Difference between revisions of "Projects/Larger key versions"

Revision as of 15:15, 7 March 2015

Background

In some deployments it is desirable to periodically rotate keys using an automated process. Current implementation limits can cause surprising behavior when key versions exceed 255 or 31767. This project will relax some of the implementation limits to produce more predictable behavior in common scenarios.

The current implementation limits on key versions are:

8-bit limitations:

• The FILE keytab format stores the key version as an unsigned 8-bit field.
• The kadmin protocol marshals the kvno and mkvno fields of kadm5_principal_ent_rec as an unsigned 8-bit field. The kvno field is used by kadmin ktadd as the version of the newly added key, because there is no key version in the chrand reply.
• The KADM_DATA tl-data value uses 8 bits to marshal the history key version.

16-bit limitations:

• The krb5_key_data structure in kdb.h represents the key version as a signed 16-bit field. As a consequence:
  • The db2 and LDAP KDB modules marshal the key version as a signed 16-bit field.
  • The kadmin protocol marshals the key version of key_data structures as a signed 16-bit field.

32-bit limitations:

• The krb5_kvno type is unsigned int, which is usually 32 bits.
• The iprop protocol represents the version of key data as a signed 32-bit field.
• krb5_dbe_def_search_enctype(), used to retrieve keys from DB entries, accepts a signed 32-bit kvno parameter, with special meanings for negative and 0 values.

The FILE keytab code contains some pivot logic to work around 8-bit kvno limitations when retrieving keytab entries. The pivot logic is:

• When searching for the highest kvno, if any kvno values greater than 240 are seen, compare all kvno values using (kvno + 128) % 256 so that values 0-127 compare greater than values 128-255.
• When searching for a specific kvno, consider the entry kvno equal to the desired kvno if the least significant 8 bits of the version match.

The current best practice for key rotation with kadmin is to use ktadd princname to retrieve new random keys, and then ktrem princname old to remove old entries after the maximum ticket length has elapsed. With this practice, only one or two versions of the key will be in the keytab at a time, and the above