An Information Model for Kerberos Version 5
Extracted elements (26)
Keys are separated from principal data and grouped into KeySet objects (indexed by kvno) rather than stored as flat attributes, because this grouping naturally supports key rollover scenarios where a principal may temporarily have multiple active KeySets.
RFC 2119 normative keywords are redefined for this document because it describes an abstract information model, not a protocol or schema. 'MUST' means the feature must be representable in any implementing schema and must be supported by any KDC implementing the model, but the schema element itself may be optional in the schema definition language.
The information model is explicitly not a schema; it describes objects, properties, and relationships as an abstract view of KDC data. Implementations are expected to produce a mapping to a concrete schema language (e.g., LDAP, SQL, YAML) rather than implement the model directly.
The information model is intentionally mappable to multiple schema representations including LDAP (backend or frontend to KDC), SOAP/XML, and NETCONF/YAML. LDAP implementations SHOULD incorporate existing LDAP schema where functional overlap exists rather than defining Kerberos-specific duplicates.
Each principal MAY be associated with zero or more KeySets. Implementations MUST NOT assume a principal has exactly one KeySet; they MUST support the general case of multiple KeySets per principal (e.g., to support key rollover).
If keys are implemented, adequate protection from unauthorized modification and disclosure MUST be available and is REQUIRED of the implementation, as the security of Kerberos 5 is an absolute requirement.
Implementations MUST facilitate placing more restrictive access controls on KeySets than on other principal data, and MUST support more secure backup arrangements for KeySets, given that Kerberos 5 security depends absolutely on the confidentiality and integrity of key objects in the KDC.
Implementations of this model MUST NOT force keys to be represented; a schema that required a key to be present would not meet this constraint.
Implementations that change attribute names from those defined in this document MUST provide a name-to-name mapping to the names in this specification, and MUST explicitly call out typographical conventions such as camelCase vs. underscore-separated names.
policyIdentifier MUST be globally unique. Acceptable identifier types include an OID (RFC 4517), a URI (RFC 3986), or a UUID (RFC 4122). Implementations MUST assign globally unique identifiers to standard policies using best practices for the target schema language.
policyIsCritical is a boolean attribute indicating that the KDC MUST be able to correctly interpret and apply the policy before allowing the associated principal to be used.
The Principal entity MUST be implemented in full and MUST NOT be OPTIONAL in any implementation; it is the fundamental entity stored in a KDC, associating a named identity with keys and policies.
A KeySet groups symmetric secret keys for a principal by key version number (kvno). Each KeySet is associated with exactly one principal and MUST contain one or more Keys. For any given enctype, a KeySet MUST NOT contain more than one key with that enctype.
All implementations that represent policy objects MUST support four mandatory-to-implement policy types: (1) Password Quality Policy — requirements on new passwords; (2) Password Management Policy — controls how passwords are changed; (3) Keying Policy — determines enctypes and keys assigned to new principals; (4) Ticket Flag Policy — specifies ticket flags allowed for a principal.
keyEncryptionType SHOULD be represented as an enumeration using the string name of the enctype from the IANA Kerberos Encryption Type Numbers registry (e.g., 'aes128-cts-hmac-sha1-96'). keyValue is a single-valued mandatory octet string holding the binary key material.
keyNotUsedBefore and keyNotUsedAfter are single-valued RFC 3339 date/time attributes controlling the validity window of an individual key. keyIsDisabled is a boolean that SHOULD default to FALSE; when TRUE, the key MUST NOT be used.
keySaltValue is a single-valued octet string holding the binary key salt. keyStringToKeyParameter is a single-valued opaque octet string representing an enctype-specific parameter used with the string-to-key method defined in RFC 3961 Section 3.
kvno is the single-valued key version number attribute of a KeySet, represented as a non-negative integer. It is incremented by one each time any key within the KeySet is changed.
principalAllowedEnctype is an OPTIONAL multivalued attribute listing the encryption types permitted for this principal for all key uses (client, server, session). If empty or absent, any enctype supported by the implementation is allowed.
principalIsDisabled is a boolean attribute used to disable a principal; it SHOULD default to FALSE. principalLastCredentialChangeTime, principalCreateTime, and principalModifyTime are single-valued RFC 3339 timestamps tracking credential changes, creation, and non-credential modifications respectively.
principalMaximumTicketLifetime holds the maximum ticket lifetime in seconds for tickets issued to this principal. principalMaximumRenewableTicketLifetime holds the maximum renewal delta in seconds.
principalName MUST uniquely identify the principal within the KDC's administrative context and MUST be equivalent to the string representation of the principal name per RFC 1964 Section 2.1.1, including the realm when applicable. The attribute MAY be multivalued to support aliases or enterprise names, with at most one canonical value and one canonical salting value.
principalNotUsedBefore and principalNotUsedAfter are single-valued date/time attributes whose syntax MUST conform to Internet date/time format from RFC 3339; the principal MUST NOT be used outside the window they define.
The Policy object is modeled as a typed opaque binary value ('typed hole') paired with a globally unique identifier. Both the type identifier and the value must be present. Implementations SHOULD implement policies but MAY allow them to be OPTIONAL.
Access control is paramount: deleting or modifying critical principals (e.g., krbtgt/REALM@REALM) can disable an entire Kerberos realm. This document does not mandate an access control model, and access control is explicitly out of scope. Exposing access control objects via extensions may itself leak information about privileged principals.
Keys MUST NOT be transported in the clear over the network, and keys MUST be treated as write-only attributes modifiable only through the Kerberos set/change-password protocol. The model assumes keys are never readable via the administrative interface.