skip to content

In Kerberos, what does an encryption type number such as 18 or 23 actually select?

level: middleimportance: must knowfreq 52%

answer

  1. a number, not just a cipher
  2. profile, not primitive
  3. cipher, checksum and key derivation together
  4. string-to-key needs a salt
  5. pa-etype-info2 carries etype, salt, s2kparams

basics

~20 s

A Kerberos etype number names a whole cryptosystem profile from the registry: the encryption function, the key size, the string-to-key that turns a password plus salt into a long-term key, the per-message key derivation and the required checksum.

solid answer

~50 s

Etype 18 is `aes256-cts-hmac-sha1-96` (RFC 3962) and etype 23 is `rc4-hmac` (RFC 4757). The number is an index into the registry of profiles defined against the framework in RFC 3961, and a profile fixes five things at once: the encryption function and its cipher state, the key size, the `string-to-key` function that derives a principal's long-term key from a password and a salt, the key-derivation step applied per message type, and the integrity checksum bound to the ciphertext. That is why swapping 23 for 18 changes how the key was made, not only how the bytes were encrypted. A client lists the etypes it can use in the `KDC-REQ-BODY`; the KDC answers with what the target principal actually holds a key for, telling the client the salt and parameters in `pa-etype-info2 (padata-type 19)`, or refusing with `KDC_ERR_ETYPE_NOSUPP (14)`.

code

asn1 · 7 lines
asn1
ETYPE-INFO2-ENTRY ::= SEQUENCE {
    etype       [0] Int32,
    salt        [1] KerberosString OPTIONAL,
    s2kparams   [2] OCTET STRING OPTIONAL
}

ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY

go deeper

for a junior

Recall that the etype is a number identifying which cryptography protects Kerberos messages, and that 18 is an AES profile while 23 is the older rc4-hmac one.

for a middle

Explain that the number selects a whole profile — encryption, key size, string-to-key, key derivation and checksum — and that the salt plus string-to-key parameters reach the client in pa-etype-info2.

for a senior

Show you can separate the etype protecting the reply to the client from the etype sealing the ticket, and read KDC_ERR_ETYPE_NOSUPP as a statement about which principal lacks a key.

for a principal

Frame etype support as an estate-wide invariant: every principal on every authentication path must hold a key of a common profile before the weakest one can be withdrawn.

## What an encryption type is An **encryption type**, written `etype` on the wire, is an integer that names a *complete cryptosystem profile* — not a cipher. **RFC 3961** defines the framework a profile must fill in, and every Kerberos etype is an instance of it. One number fixes all of the following together: - the **encryption function** and the cipher state it carries between blocks; - the **key size** and what a valid key for that profile looks like; - the **`string-to-key`** function, which turns a password plus a salt plus optional string-to-key parameters into the principal's **long-term key**; - a **key-derivation** step that produces a distinct key per message usage from that long-term or session key, so the same key is never used raw for two purposes; - the **checksum** mechanism that provides integrity, and which checksums are allowed with that profile. Because all five travel under one number, an etype cannot be compared element by element with a cipher suite on a transport connection. Choosing etype 18 over etype 23 changes how the long-term key came into being, which is usually the part that matters. ## The numbers you will meet | etype | name | defined by | status | |---|---|---|---| | 17 | `aes128-cts-hmac-sha1-96` | RFC 3962 | current | | 18 | `aes256-cts-hmac-sha1-96` | RFC 3962 | current, the common default | | 19 | `aes128-cts-hmac-sha256-128` | RFC 8009 | current, SHA-2 family | | 20 | `aes256-cts-hmac-sha384-192` | RFC 8009 | current, SHA-2 family | | 23 | `rc4-hmac` | RFC 4757 | deprecated, still widely present | | 24 | `rc4-hmac-exp` | RFC 4757 | export-weakened variant, obsolete | Etype numbers appear in decimal in the protocol and sometimes in hexadecimal in operational records, where 23 is written `0x17` and 18 is `0x12`. ## Two choices, not one A single exchange involves **two separate etype decisions**, and collapsing them is the usual error: 1. The client lists the etypes it supports in the `KDC-REQ-BODY` of its `AS-REQ` or `TGS-REQ`. 2. The part of the reply addressed **to the client** — the `enc-part` carrying the session key — must be encrypted under a key the *client* holds, so it uses an etype the client's own key exists for. 3. The **ticket** inside that reply is sealed under a key of the *target* principal: `krbtgt` for a ticket-granting ticket, the service principal's long-term key for a service ticket. Its etype is chosen from the keys **that** principal holds, and it need not be the same one. 4. If no etype the requester offered matches a key the KDC or the target principal holds, the KDC answers `KDC_ERR_ETYPE_NOSUPP (14)`. This is why a client can be fully AES-capable and still be handed a ticket sealed with etype 23: the weakness lives with the principal whose key seals the ticket. ## The salt, and why the profile needs one `string-to-key` takes a password, a **salt** and string-to-key parameters. The salt is a public value, not a secret; its job is to make sure two principals who happen to choose the same password do not end up with the same long-term key, and that work done against one principal's password cannot be reused against another's. Kerberos derives a **default salt** from the realm and the principal's name components, which is why renaming a principal can invalidate keys derived earlier. The KDC tells the client what to use rather than letting it guess: - `pa-etype-info2 (padata-type 19)` — a list with one entry per etype the principal has a key for, each carrying the etype, its salt and its string-to-key parameters; - `pa-etype-info (padata-type 11)` — the older form, without string-to-key parameters; - `pa-pw-salt (padata-type 3)` — a bare salt string with no per-etype structure. These arrive as `METHOD-DATA in e-data` on a `KRB-ERROR`, typically the `KDC_ERR_PREAUTH_REQUIRED (25)` that tells the client to try again with pre-authentication. ## What this buys you when something breaks When an authentication fails after a change, the etype is the first thing to establish, because three different failures look alike from a distance: the requester and the KDC share no etype (`KDC_ERR_ETYPE_NOSUPP (14)`), the client derived its key with the wrong salt and the pre-authentication ciphertext does not verify (`KDC_ERR_PREAUTH_FAILED`), or a service was handed a ticket sealed under a key it no longer holds and reports `KRB_AP_ERR_MODIFIED` because the integrity check on decryption fails. Each names a different party holding the wrong key. **Version note.** The single-DES etypes are historic. Etype 23 is deprecated but not absent; the SHA-2 profiles 19 and 20 were added later by RFC 8009 and are not present in every deployment, so a migration plan cannot assume them.

  • Where in a Kerberos AS exchange does the client learn which etype and salt to derive its key with?
    In the `e-data` of the `KRB-ERROR` the KDC returns, normally `KDC_ERR_PREAUTH_REQUIRED (25)`. The `e-data` carries `METHOD-DATA`, inside which `pa-etype-info2 (padata-type 19)` lists one entry per etype the principal has a key for, each with its salt and string-to-key parameters. The client picks an etype it supports, derives the key with that salt, and retries with pre-authentication.
  • Some operational records print the encryption type in hexadecimal. Which etypes are 0x17 and 0x12?
    `0x17` is decimal 23, `rc4-hmac`, and `0x12` is decimal 18, `aes256-cts-hmac-sha1-96`. The protocol itself uses the decimal registry numbers; the hexadecimal form is only a rendering choice, so the same ticket can be described two ways in two places.
  • A client that supports only AES etypes is still issued a service ticket sealed with etype 23. How?
    The etype protecting the reply to the client and the etype sealing the ticket are chosen against two different principals' keys. The client's part uses a key the client holds; the ticket is sealed under the service principal's long-term key, so if that principal only has an `rc4-hmac` key, the ticket is sealed with etype 23 regardless of what the client can do.

saying these in an interview costs you the question

  • Says etype 18 means AES-256 and nothing else changes
  • Treats a Kerberos etype as a transport cipher suite
  • Thinks the client picks the etype and the KDC obeys
  • Believes the salt is a secret rather than a public uniquifier
  • Assumes every principal holds a key for every enabled etype
  • Reads one etype per exchange instead of one per sealed part