Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs)
updates
- rfc-4120 — The Kerberos Network Authentication Service (V5)
Extracted elements (22)
AD-KDC-ISSUED is insufficient for S4U2Proxy (Constrained Delegation) because the service knows the symmetric key used for the checksum, so the KDC cannot detect whether the service tampered with the authorization data in an evidence ticket presented during a TGS-REQ.
The kdc-verifier uses a key known only to the KDC, allowing the KDC to verify authorization data it previously inserted without recomputing it — important when the data includes ephemeral information such as authentication method strength that may not be reconstructible.
The other-verifiers element enables a lesser-privileged service to extract the AD-CAMMAC and present it to a higher-privileged 'trusted service' on the same host, which can validate the CAMMAC without communicating with the KDC.
AD-CAMMAC supersedes AD-KDC-ISSUED (RFC 4120) but must be wrapped in AD-IF-RELEVANT for backward compatibility with Kerberos implementations that do not recognize ad-type 96, unless the KDC has out-of-band knowledge that the application server supports CAMMAC.
A KDC MAY omit the kdc-verifier from the CAMMAC when not needed per realm policy — for example, for a local-realm TGT where all local KDCs filter client-submitted CAMMACs, or for services that neither use nor are permitted to use S4U2Proxy.
Application servers and KDCs MAY ignore the AD-CAMMAC container and the authorization data elements it contains.
For compatibility with older Kerberos implementations, a KDC issuing an AD-CAMMAC SHOULD enclose it in an AD-IF-RELEVANT container unless the KDC knows that the application server is likely to recognize AD-CAMMAC.
In other-verifiers, the kvno and enctype SHOULD be specified to disambiguate which long-term key of the trusted service is used.
In the other-verifiers element, the PrincipalName identifier MUST be present and be a valid principal in the realm.
The svc-verifier MUST be present if the service principal of the ticket is not the local TGS, including when the ticket is a cross-realm Ticket-Granting Ticket (TGT).
Unless otherwise administratively configured, the KDC SHOULD determine the 'trusted service' principal name for other-verifiers by replacing the service identifier component of the sname element with 'host'.
AD-CAMMAC is an ASN.1 SEQUENCE containing: elements (AuthorizationData issued by the KDC), an optional kdc-verifier (Verifier-MAC using a TGS long-term key), an optional svc-verifier (Verifier-MAC using the service key), and an optional other-verifiers sequence of additional Verifier-MACs.
The kdc-verifier MAC is computed over the ASN.1 DER encoding of a modified EncTicketPart where the authorization-data field is replaced with the AuthorizationData from the AD-CAMMAC elements field (not the full ticket authorization-data). This binds the kdc-verifier to the ticket context and prevents a malicious service from substituting a mismatched AD-CAMMAC from another ticket.
The svc-verifier MAC uses the same long-term service key that the KDC uses to encrypt the surrounding ticket, with the required checksum type for that key's enctype. The key usage number for all Verifier-MAC checksums is 64.
Ad-type number 96 is assigned for AD-CAMMAC, updating the table in Section 7.5.4 of RFC 4120. The table in Section 5.2.6 of RFC 4120 is also updated to map ad-type 96 to 'DER encoding of AD-CAMMAC'.
Key usage number 64 is assigned for the Verifier-MAC checksum, updating the table in Section 7.5.1 of RFC 4120.
A KDC verifies a CAMMAC as originating from a local-realm KDC if: (1) the kdc-verifier validates, or (2) the svc-verifier validates using a key known only to local-realm KDCs, or (3) no verifiers are present but the ticket-encrypting key is KDC-only and all local KDCs filter client-submitted CAMMACs.
An entity with access to keys of two different service principals can decrypt a ticket for one service and re-encrypt it under the other service's key, altering the svc-verifier to match. Both kdc-verifier and svc-verifier would still validate despite the ticket being fabricated. If an authenticated binding between the service principal name and the CAMMAC is required, the KDC MUST include an authorization data element naming the service principal.
Extracting a CAMMAC from a ticket for use as a credential removes it from the ticket's context, potentially turning it into a bearer token. The CAMMAC also does not necessarily contain sufficient information to identify the client principal, so application protocols relying on extracted CAMMACs may need to duplicate substantial ticket contents inside the CAMMAC.
Mixed CAMMAC support during incremental KDC upgrades requires particular caution: if some KDCs do not filter client-submitted CAMMACs, the no-verifier local-origin criterion (criterion 3) cannot be safely relied upon.
The kdc-verifier binds only to the authorization data within the AD-CAMMAC elements field, not to any authorization data outside the CAMMAC in the ticket. It also does not bind to the service principal name, since the service name is not part of EncTicketPart.
The ad-data of AD-CAMMAC is the ASN.1 DER encoding of the AD-CAMMAC type. Verifier-MAC is a SEQUENCE with optional identifier (PrincipalName, tag [0]), optional kvno (UInt32, tag [1]), optional enctype (Int32, tag [2]), and mandatory mac (Checksum, tag [3]).