How would you sequence a Kerberos migration off etype 23 across depot services whose owners you cannot compel to change?

## Why this is a sequencing problem, not a setting A Kerberos encryption type is not negotiated afresh per connection. It is decided by **which keys each principal actually holds**, and a key for a given etype only comes into existence when that principal's long-term key is set, because `string-to-key` runs **per profile**, with that profile's salt and parameters. Enabling etype 18 on a KDC therefore creates nothing. Until a principal's key is set again, that principal still has only its `rc4-hmac` key, and the KDC will keep using etype 23 for anything sealed under it — because the alternative is to fail. That single fact sets the order of the whole programme, and inverting it is the classic outage. ## The three phases and what each one costs to get wrong 1. **Capability.** Every KDC, every client and every service on an authentication path must be able to use an AES profile. Anything that cannot keeps etype 23 alive for every exchange it takes part in, however modern the rest of the estate is. 2. **Keys.** Each principal's long-term key is set again so that a key exists for the new profile. For human principals this is a password change; for service principals it is a key rotation the service owner has to accept and pick up, because the service must load the new key to open tickets sealed with it. 3. **Withdrawal.** Only now is etype 23 removed from the permitted set — and only for principals and paths where phase 2 is complete. | mis-ordering | what happens | how it shows | |---|---|---| | Withdraw before keys exist | no shared profile between requester and the key held | `KDC_ERR_ETYPE_NOSUPP (14)` at the KDC | | Rotate a service key the service does not pick up | tickets sealed with a key the service cannot open | `KRB_AP_ERR_MODIFIED` reported by the service | | Rename or re-home a principal mid-flight | derived keys no longer match the salt used | pre-authentication failures, `KDC_ERR_PREAUTH_FAILED` | | Declare done on the KDC's setting alone | principals still holding only etype 23 keys | tickets still sealed with etype 23 | The third row is worth dwelling on: the default salt is built from the realm and the principal's name components, so a change to the principal's name is a change to the derivation input. ## Services whose owners you cannot compel This is the part that makes it a judgment call rather than a runbook. You have no change control over the other team's release, and a forced rotation breaks them at a time you chose. What you do have: - **Visibility.** Publish, per service principal, which etypes it holds a key for and when that key was last set. The list is the argument; nobody defends a position they can see. - **A deadline with a demonstrated cost.** Tie it to something the owner already cares about, and be explicit that the failure mode after the deadline is authentication failure, not degraded security. - **Sequencing by path, not by inventory.** Migrate one authentication path end to end rather than one class of principal across the estate, so that any breakage is bounded to a path you chose and can reverse. - **A reversible step.** Keeping etype 23 permitted while AES keys are created is what makes the programme safe; the irreversible step is the withdrawal, and it belongs last and per-path. - **A replacement for the weak input.** Where a service principal's key is derived from a password a person chose, the migration is the moment to replace it with a long machine-generated key. Otherwise you have repriced offline guessing without removing it. ## What to measure - The count of principals holding **only** an etype 23 key — the real backlog. - The count of tickets actually issued sealed with etype 23 — the residual exposure, which can be non-zero long after the backlog looks small, because one unmigrated party on a path is enough. - The count of `KDC_ERR_ETYPE_NOSUPP (14)` refusals after each withdrawal — the signal that a path was withdrawn too early. The programme is finished when the second number is zero and stays zero for a full business cycle, not when the first one is. ## The trade-off to state out loud Withdrawing etype 23 removes a profile whose key derivation is unsalted and single-pass, so it cuts the cost of every offline guess against every principal on the estate by orders of magnitude and ends the reuse of precomputed work. It does not, by itself, protect any principal whose password a person chose badly. A lead who runs the migration and leaves the password-derived service keys in place has bought a large improvement and should say which risk remains rather than declaring the class closed. **Version note.** Etype 23 is deprecated, not absent, which is why the withdrawal is a decision rather than an upgrade. The SHA-2 profiles 19 and 20 defined by RFC 8009 are a further step and are not present everywhere, so a migration target of etype 18 and a later move to the SHA-2 family are two programmes, not one.