Skip to main content

1.5.1. Compatibility with RFC 1510

1.5.1. Compatibility with RFC 1510

Note that existing Kerberos message formats cannot readily be extended by adding fields to the ASN.1 types. Sending additional fields often results in the entire message being discarded without an error indication. Future versions of this specification will provide guidelines to ensure that ASN.1 fields can be added without creating an interoperability problem.

In the meantime, all new or modified implementations of Kerberos that receive an unknown message extension SHOULD preserve the encoding of the extension but otherwise ignore its presence. Recipients MUST NOT decline a request simply because an extension is present.

There is one exception to this rule. If an unknown authorization data element type is received by a server other than the ticket-granting service either in an AP-REQ or in a ticket contained in an AP-REQ, then authentication MUST fail. One of the primary uses of authorization data is to restrict the use of the ticket. If the service cannot determine whether the restriction applies to that service, then a security weakness may result if the ticket can be used for that service. Authorization elements that are optional SHOULD be enclosed in the AD-IF-RELEVANT element.

The ticket-granting service MUST ignore but propagate to derivative tickets any unknown authorization data types, unless those data types are embedded in a MANDATORY-FOR-KDC element, in which case the request will be rejected. This behavior is appropriate because requiring that the ticket-granting service understand unknown authorization data types would require that KDC software be upgraded to understand new application-level restrictions before applications used these restrictions, decreasing the utility of authorization data as a mechanism for restricting the use of tickets. No security problem is created because services to which the tickets are issued will verify the authorization data.

Implementation note: Many RFC 1510 implementations ignore unknown authorization data elements. Depending on these implementations to honor authorization data restrictions may create a security weakness.