5.1. Specific Compatibility Notes on ASN.1

For compatibility purposes, implementors should heed the following specific notes regarding the use of ASN.1 in Kerberos. These notes do not describe deviations from standard usage of ASN.1. The purpose of these notes is instead to describe some historical quirks and non-compliance of various implementations, as well as historical ambiguities, which, although they are valid ASN.1, can lead to confusion during implementation.

5.1.1. ASN.1 Distinguished Encoding Rules

The encoding of Kerberos protocol messages shall obey the Distinguished Encoding Rules (DER) of ASN.1 as described in [X690]. Some implementations (believed primarily to be those derived from DCE 1.1 and earlier) are known to use the more general Basic Encoding

Rules (BER); in particular, these implementations send indefinite encodings of lengths. Implementations MAY accept such encodings in the interest of backward compatibility, though implementors are warned that decoding fully-general BER is fraught with peril.

5.1.2. Optional Integer Fields

Some implementations do not internally distinguish between an omitted optional integer value and a transmitted value of zero. The places in the protocol where this is relevant include various microseconds fields, nonces, and sequence numbers. Implementations SHOULD treat omitted optional integer values as having been transmitted with a value of zero, if the application is expecting this.

5.1.3. Empty SEQUENCE OF Types

There are places in the protocol where a message contains a SEQUENCE OF type as an optional member. This can result in an encoding that contains an empty SEQUENCE OF encoding. The Kerberos protocol does not semantically distinguish between an absent optional SEQUENCE OF type and a present optional but empty SEQUENCE OF type. Implementations SHOULD NOT send empty SEQUENCE OF encodings that are marked OPTIONAL, but SHOULD accept them as being equivalent to an omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos messages, instances of these problematic optional SEQUENCE OF types are indicated with a comment.

5.1.4. Unrecognized Tag Numbers

Future revisions to this protocol may include new message types with different APPLICATION class tag numbers. Such revisions should protect older implementations by only sending the message types to parties that are known to understand them; e.g., by means of a flag bit set by the receiver in a preceding request. In the interest of robust error handling, implementations SHOULD gracefully handle receiving a message with an unrecognized tag anyway, and return an error message, if appropriate.

In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the incorrect tag is sent over a TCP transport. The KDCs SHOULD NOT respond to messages received with an unknown tag over UDP transport in order to avoid denial of service attacks. For non-KDC applications, the Kerberos implementation typically indicates an error to the application which takes appropriate steps based on the application protocol.

5.1.5. Tag Numbers Greater Than 30

A naive implementation of a DER ASN.1 decoder may experience problems with ASN.1 tag numbers greater than 30, due to such tag numbers being encoded using more than one byte. Future revisions of this protocol may utilize tag numbers greater than 30, and implementations SHOULD be prepared to gracefully return an error, if appropriate, when they do not recognize the tag.