DCE

DCE Security started from an early alpha release of version 5 and the two versions have developed independently. MIT and the OSF have agreed to resolve some minor incompatibilities.

The DCE Security Server, secd, listens on UDP port 88 for standard Kerberos requests and responds appropriately. Therefore, clients of MIT Kerberos can operate in a DCE environment without modification, assuming the DCE Security database contains the appropriate principals with the correct keys.

An MIT Kerberos version 5 server cannot replace the DCE Security Server. First, DCE applications communicate with secd by way of the DCE RPC. Second, the DCE Security model includes a Privilege Server that fills in the authorization field of a principal’s ticket with DCE-specific data, and the DCE Security Server has a built-in Privilege Server. Before the MIT Kerberos version 5 server can support DCE clients it needs to talk to a stand-alone Privilege Server and no such Privilege Server presently exists, although the necessary information is available.

As an additional complication, the DCE does not officially export the Kerberos version 5 API. It only exports a DCE Security-specific API. Individual vendors can provide the Kerberos version 5 API if they want, but unless they all do (which seems unlikely), Kerberos version 5 API applications will not be compile-time portable to pure DCE environments. Only binaries will work with both versions.

Interoperability Requirements

Version 5 of the Kerberos protocol supports a myriad of options, including multiple encryption and checksum types, alternative encoding schemes, optional mechanisms for preauthentication, the handling of tickets with no addresses, options for mutual authentication, user-to-user authentication, support for proxies, forwarding, postdating and renewing tickets, formatting realm names, and handling authorization data.

You must define a minimal configuration that all implementations support to ensure the interoperability of realms. This minimal configuration is subject to change as technology does. If it is discovered at some later date that one of the required encryption or checksum algorithms is not secure, for example, it will be replaced.

Specification 1

Specification 1 is the first definition of a standard set of these options. Implementations configured in this way are said to support Kerberos version 5 Specification 1.

Encryption and Checksum Methods

The following encryption and checksum mechanisms must be supported. Implementations may support other mechanisms as well, but the additional mechanisms may only be used when communicating with principals also known to support them:

Encryption: DES-CBC-MD5

Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5

Realm Names

All implementations must understand hierarchical realms in both the Internet domain and the X.500 style. When a Ticket Granting Ticket for an unknown realm is requested, the Key Distribution Center must be able to determine the names of the intermediate realms between the Key Distribution Center’s realm and the requested realm.

Transited Field Encoding

DOMAIN-X500-COMPRESS must be supported. Alternative encodings may be supported, but they may be used only when all intermediate realms support that encoding.

Preauthentication Methods

The TGS-REQ method must be supported. The TGS-REQ method is not used on the initial request. Clients must support the PA-ENC-TIMESTAMP method, but whether it is enabled by default may be determined per realm. If not used in the initial request, and the error KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an acceptable method, the client should retry the initial request using the PA-ENC-TIMESTAMP preauthentication method. Servers need not support the PA-ENC-TIMESTAMP method, but if not supported, the server should ignore the presence of PA-ENC-TIMESTAMP preauthentication in a request.

Mutual Authentication

Mutual authentication (via the KRB_AP_REP message) must be supported.

Ticket Addresses and Flags

All Key Distribution Centers must pass on tickets that carry no addresses. If a Ticket Granting Ticket contains no addresses, the Key Distribution Center returns derivative tickets. Each realm may set its own policy for issuing such tickets, and each application server sets its own policy concerning accepting them. By default, servers should not accept them.

Proxies and forwarded tickets must be supported. Individual realms and application servers can set their own policy regarding when such tickets are accepted.

All implementations must recognize renewable and postdated tickets, but need not actually implement them. If these options are not supported, the start time and end time in the ticket specify a ticket’s entire useful life. When a server decodes a postdated ticket, all implementations make the presence of the postdated flag visible to the calling server.

User-to-User Authentication

Support for user-to-user authentication, via the ENC-TKTIN-SKEY Key Distribution Center option, is required. Individual realms can decide as a matter of policy to reject such requests on a per-principal or realm-wide basis.

Authorization Data

Implementations must pass all authorization data subfields from Ticket Granting Tickets to any derivative tickets unless directed to suppress a subfield as part of the definition of that registered subfield type. Passing on a subfield is never correct, and no registered subfield types presently specify suppression at the Key Distribution Center.

Implementations must make the contents of any authorization data subfields available to the server when a ticket is used. Implementations are not required to permit clients to specify the contents of the authorization data fields.

Recommended Key Distribution Center Values

The following list supplies recommended values for a Key Distribution Center implementation, based on the list of suggested configuration constants:

Naming Constraints

Kerberos has several different types of names. Each type of name has its own rules, structure, and limitations.