Kerberos deliberately does not provide authorization. Conflating authentication with authorization would make applications vulnerable to bypass in environments offering other authentication options or when interoperating with modified KDCs. Applications must implement independent authorization based on the authenticated principal name.

security

Renewable tickets were introduced to limit the exposure window from stolen credentials. Long-lived tickets risk extended theft; requiring frequent password re-entry increases long-term key exposure. Renewable tickets expire frequently but can be re-issued by the KDC, which MAY consult a hot-list to refuse stolen tickets at each renewal.

security, crypto

The TGT-based architecture (AS exchange yields a TGT; subsequent TGS exchanges yield service tickets) avoids repeated use of the client's long-term secret key. After initial login, only the TGT's session key is needed, minimizing the exposure of the password-derived key over the session lifetime.

security, crypto

Existing Kerberos messages cannot be reliably extended by adding ASN.1 fields; many RFC 1510 implementations discard messages with unknown fields. New implementations SHOULD preserve unknown extensions but otherwise ignore them; recipients MUST NOT decline a request solely because an extension is present.

security

Application servers MUST either perform transited-realm checks themselves or reject cross-realm tickets without the TRANSITED-POLICY-CHECKED flag set. If any transited realm is untrusted to authenticate the client principal, the authentication attempt MUST be rejected.

security

Application servers MUST reject tickets with the INVALID flag set. Invalid (postdated) tickets MUST be validated by the KDC via a TGS request with VALIDATE option after the ticket's starttime has passed.

security

Applications MUST make a separate authorization decision after authentication based on the authenticated name, requested operation, and local access control information. Kerberos ticket issuance alone does not authorize use of a service.

security

Authenticators MUST NOT be re-used and SHOULD be rejected if replayed to a server. If the transport might deliver duplicated messages, either a new authenticator MUST be generated per retry, or the server MUST match requests and replay its first reply.

security

Clock skew correction MUST use the offset technique (recording difference between KDC authtime and local clock) rather than directly adjusting the system clock, because the KDC reply is authenticated only to the user, not the workstation.

security, ntp

If a server loses track of authenticators presented within the allowable clock skew, it MUST reject all requests until the clock skew interval has passed, preventing replay of any lost or recorded authenticators.

security

If an unknown authorization data element type is received by a server other than the TGS in an AP-REQ or in a ticket in an AP-REQ, authentication MUST fail. Optional authorization elements SHOULD be enclosed in AD-IF-RELEVANT to avoid this.

security

Implementations of Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of service principal names. Applications SHOULD provide security mechanisms with names folded to lowercase without other modifications.

dns, security

The KDC MUST be prepared to retransmit responses in case they are lost. If a KDC receives a request identical to one it has recently processed successfully, it MUST respond with a KRB_AS_REP rather than a replay error, even over reliable transports.

udp, security

The TGS MUST ignore but propagate to derivative tickets any unknown authorization data types, unless those types are embedded in a MANDATORY-FOR-KDC element, in which case the request MUST be rejected.

security

Unless the application server provides its own replay protection, the server MUST use a replay cache storing at least server name, client name, time, and microsecond fields from authenticators seen within the allowable clock skew window.

security

When the AS server includes pre-authentication data in a KRB-ERROR or AS-REP, it MUST use PA-ETYPE-INFO2 (not PA-ETYPE-INFO) if the client's AS-REQ lists at least one 'newer' encryption type; otherwise it MUST send both PA-ETYPE-INFO2 and PA-ETYPE-INFO.

security, crypto

With the exception of the INVALID flag, clients MUST ignore ticket flags that are not recognized. KDCs MUST ignore KDC options that are not recognized. Clients MUST confirm that the ticket returned by the KDC meets their needs.

security

AuthorizationData is a sequence of (ad-type, ad-data) pairs carried in tickets and authenticators. Container types include AD-IF-RELEVANT (1, elements are optional), AD-KDC-ISSUED (4, KDC-signed), AD-AND-OR (5), and AD-MANDATORY-FOR-KDC (8).

security

KRB_AP_REQ (msg-type 14) carries a ticket and an Authenticator encrypted in the session key. The Authenticator contains cname, crealm, timestamp, optional checksum, optional sequence number, and optional subkey, proving the client possesses the session key and preventing replay.

security, crypto

KRB_AS_REQ (msg-type 10) / KRB_AS_REP (msg-type 11) form the Authentication Service exchange. The request carries client/server names, encryption types, nonce, and requested times in cleartext; the reply contains a ticket and session key encrypted in the client's secret key.

security, crypto

KRB_CRED (msg-type 22) allows delegation of credentials between principals. It contains a sequence of tickets and an enc-krb-cred-part encrypted in the session key, carrying the session keys, flags, principal names, and time validity for each delegated ticket.

security, crypto

KRB_SAFE (msg-type 20) provides integrity-protected application data. The safe-body contains user-data, timestamp, optional sequence number, and sender address; the body is covered by a keyed checksum using the session or sub-session key but is not encrypted.

security, crypto

KRB_TGS_REQ (msg-type 12) / KRB_TGS_REP (msg-type 13) form the Ticket-Granting Service exchange. The client authenticates using a TGT embedded in a PA-TGS-REQ padata element, and the KDC returns a new service ticket encrypted in the TGT's session key.

security, crypto

PA-DATA is a typed extensibility mechanism used in KDC requests and replies, consisting of a padata-type integer and a padata-value octet string. Key registered types include PA-TGS-REQ (1), PA-ENC-TIMESTAMP (2), PA-ETYPE-INFO (11), and PA-ETYPE-INFO2 (19).

security, crypto

The Ticket is the central Kerberos credential, containing tkt-vno (version 5), realm (server's realm), sname (server principal name), and enc-part encrypted under the server's secret key. The encrypted part includes the session key, client identity, auth-time, start/end times, ticket flags, and authorization data.

security, crypto

Section 7.5 defines Kerberos protocol constants subject to IANA registration: key usage numbers (7.5.1), pre-authentication data types (7.5.2), address types (7.5.3), authorization data types (7.5.4), transited encoding types (7.5.5), message types (7.5.7), name types (7.5.8), and error codes (7.5.9).

registry, security

Kerberos does not solve password-guessing or denial-of-service attacks, and does not provide authorization. Each host MUST maintain a loosely synchronized clock (typically within 5 minutes); if clock synchronization runs over the network, that protocol MUST itself be secured.

security, ntp

KRB_ERROR messages are not encrypted and not integrity-protected. Clients cannot detect replays, fabrications, or modifications of error messages; a solution to this is deferred to a future version of the protocol.

security

Without pre-authentication, the AS issues a reply encrypted in the user's long-term key without verifying the requestor's identity, enabling offline password-guessing attacks. The padata field in KRB_AS_REQ SHOULD be used for pre-authentication (e.g., PA-ENC-TIMESTAMP) to mitigate this.

security, crypto

Ticket flags represent the lifecycle and capability state of a ticket. Key transitions: INVALID set at issuance for postdated tickets, cleared by KDC VALIDATE after starttime; RENEWABLE tickets must be periodically renewed via TGS RENEW before renew-till; FORWARDABLE/FORWARDED and PROXIABLE/PROXY flags control delegation chains. PRE-AUTHENT and HW-AUTHENT propagate from TGTs to derived tickets.

security

All Kerberos ASN.1 messages MUST be encoded using Distinguished Encoding Rules (DER) per X.690. BER encodings that are not also valid DER are not acceptable; this requirement is critical for interoperability and cryptographic integrity.

security

KDC messages over TCP are prefixed with a 4-octet big-endian length field giving the number of bytes in the subsequent message. Over UDP, messages are carried directly in datagrams. The KDC listens on port 88 for both transports.

tcp, udp

KerberosTime is an ASN.1 GeneralizedTime with no fractional seconds and always UTC (trailing 'Z'), e.g., '19940610060317Z'. KerberosString is a constrained IA5String limiting realm and principal names to ASCII to avoid internationalization ambiguities.