1.5.2. Sending Extensible Messages

1.5.2. Sending Extensible Messages

Care must be taken to ensure that old implementations can understand messages sent to them, even if they do not understand an extension that is used. Unless the sender knows that an extension is supported, the extension cannot change the semantics of the core message or previously defined extensions.

For example, an extension including key information necessary to decrypt the encrypted part of a KDC-REP could only be used in situations where the recipient was known to support the extension. Thus when designing such extensions it is important to provide a way for the recipient to notify the sender of support for the extension. For example in the case of an extension that changes the KDC-REP reply key, the client could indicate support for the extension by including a padata element in the AS-REQ sequence. The KDC should only use the extension if this padata element is present in the AS-REQ. Even if policy requires the use of the extension, it is better to return an error indicating that the extension is required than to use the extension when the recipient may not support it. Debugging implementations that do not interoperate is easier when errors are returned.