Skip to main content

1.5. Extending Kerberos without Breaking Interoperability

Overview​

As the deployed base of Kerberos implementations grows, extending Kerberos becomes more important. This section provides guidelines to enable future implementations to maintain interoperability.

Extension Mechanism​

Kerberos provides a general mechanism for protocol extensibility:

  • Protocol messages contain typed holes
  • Sub-messages contain an octet-string with an integer defining interpretation
  • Integer types are registered centrally
  • Can be used for vendor extensions and IETF standardizations

Definition: In this document, "extension" refers to defining a new type to insert into an existing typed hole, not adding new fields to ASN.1 types (unless explicitly stated).

1.5.1. Compatibility with RFC 1510​

Limitations​

Existing Kerberos message formats cannot readily be extended by adding fields to ASN.1 types:

  • Sending additional fields often results in entire message being discarded
  • No error indication provided

Requirements for Implementations​

All new or modified implementations that receive an unknown message extension:

  • SHOULD: Preserve the encoding of the extension
  • SHOULD: Ignore its presence
  • MUST NOT: Decline a request simply because an extension is present

Exception: Authorization Data​

If an unknown authorization data element type is received by a server (other than ticket-granting service):

  • Either in an AP-REQ
  • Or in a ticket contained in an AP-REQ
  • Then authentication MUST fail

Rationale: Authorization data restricts ticket use. If service cannot determine whether restriction applies, security weakness may result.

Best Practice: Optional authorization elements SHOULD be enclosed in AD-IF-RELEVANT element.

Ticket-Granting Service Behavior​

The TGS:

  • MUST ignore but propagate to derivative tickets any unknown authorization data types
  • Exception: If data types are embedded in MANDATORY-FOR-KDC element, request will be rejected

1.5.2. Sending Extensible Messages​

Core Principle​

Care must be taken to ensure old implementations can understand messages sent to them, even if they don't understand an extension being used.

Rule: Unless sender knows an extension is supported, the extension cannot change the semantics of the core message or previously defined extensions.

Example Scenario​

An extension including key information necessary to decrypt encrypted part of KDC-REP:

  • Can only be used when recipient is known to support the extension
  • Client could indicate support via padata element in AS-REQ sequence
  • KDC should only use extension if padata element is present

Best Practice: If policy requires the extension, return an error indicating extension is required rather than using it when recipient may not support it. This makes debugging easier.

Reference​

For complete technical details, refer to the original RFC 4120 Section 1.5.

Last updated on