Skip to main content

1.3. Choosing a Principal with Which to Communicate

Overview​

The Kerberos protocol provides the means for verifying that the entity with which one communicates is the same entity registered with the KDC using the claimed identity (principal name). However, it is still necessary to determine whether that identity corresponds to the entity with which one intends to communicate.

Determination Methods​

Syntactic Determination​

When appropriate data has been exchanged in advance, the application may perform determination syntactically based on:

  • Application protocol specification
  • Information provided by the user
  • Configuration files

Example: Server principal name for a telnet server might be derived from:

  • User-specified host name (from telnet command line)
  • "host/" prefix (from application protocol specification)
  • Mapping to Kerberos realm derived from domain part of hostname

Trusted Third Parties​

One can rely on trusted third parties for determination, but ONLY when:

  • Data obtained from third party is suitably integrity-protected
  • Data is protected while resident on third-party server
  • Data is protected during transmission

Security Requirements​

DNS and Hostname Canonicalization​

MUST NOT:

  • Implementations MUST NOT use insecure DNS queries to canonicalize hostname components of service principal names
  • MUST NOT use insecure DNS queries to map one name to another

MAY:

  • In environments without secure name service, applications MAY append statically configured domain names to unqualified hostnames
  • Should do no more than that

Secure Name Service:

  • Secure name service facilities, if available, might be trusted for hostname canonicalization
  • Such canonicalization by client SHOULD NOT be required by KDC implementations

Implementation Note​

Many current implementations perform some degree of canonicalization of the provided service name, often using DNS. This creates security problems. However, there is no consistency among implementations regarding:

  • Whether service name is case-folded to lowercase
  • Whether reverse resolution is used

Best Practice: To maximize interoperability and security, applications SHOULD provide security mechanisms with names that result from folding the user-entered name to lowercase without performing any other modifications or canonicalization.

Reference​

For complete technical details, refer to the original RFC 4120 Section 1.3.

Last updated on