Skip to main content

2.7. Transited Policy Checking

Overview​

In Kerberos, the application server is ultimately responsible for accepting or rejecting authentication, and it SHOULD check that only suitably trusted KDCs are relied upon to authenticate a principal.

The Transited Field​

The transited field in the ticket:

  • Identifies which realms (and thus which KDCs) were involved in the authentication process
  • Should normally be checked by application server
  • If any realms are untrusted to authenticate the indicated client principal (determined by realm-based policy), the authentication attempt MUST be rejected
  • Presence of trusted KDCs in this list does not provide guarantee; an untrusted KDC may have fabricated the list

TRANSITED-POLICY-CHECKED Flag​

Although the end server ultimately decides whether authentication is valid, the KDC for the end server's realm MAY:

  • Apply a realm-specific policy for validating the transited field
  • Accept credentials for cross-realm authentication
  • When KDC applies such checks and accepts cross-realm authentication, it will set the TRANSITED-POLICY-CHECKED flag in service tickets

Client Options​

  • Client MAY request that KDCs not check the transited field by setting the DISABLE-TRANSITED-CHECK flag
  • KDCs are encouraged but not required to honor this flag

Application Server Requirements​

Application servers MUST either:

  • Do the transited-realm checks themselves, OR
  • Reject cross-realm tickets without TRANSITED-POLICY-CHECKED set

Reference​

For complete technical details, refer to RFC 4120 Section 2.7.

Last updated on