Projects/domain realm referrals

An announcement has been sent to krbdev@mit.edu starting a review of this project. That review will conclude on 2008-05-12.

Comments can be sent to krbdev@mit.edu.

Desired Changes

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral support in the KDC and providing the mapping information to clients through that protocol.

Functional Requirements

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name service/canonical-fqdn@LOCAL.REALM to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (e.g., two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

Design

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:

• the request is not a user-to-user authentication request
• the server principal name is unknown
• the referral flag is set in the request
• the requested server principal has two components
• either the first component is a recognized service name (this may be hardcoded initially) or the name type is host-based
• the second component looks like a fully-qualified domain name
• (there may be additional conditions that should be imposed)

then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

Tasks/Milestones

• Library changes
• Library change test case
• KDC detection of the relevant cases
• KDC implementation of change of principal name

Testing Plan

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

Open Issues

Should the list of services to process this way be specified in the config file, or is a hardcoded set adequate at first? (Meta-issue: Should config information that is realm-specific but not KDC-specific be moved into the database from the config file?)

Should we use a list of services, or just process all two-element names where the second component looks like a domain name?

Do we want to add cross-realm test cases to the automated tests? I think currently only the DejaGnu-based tests are set up to manage running a KDC and additional client programs, and they're not set up to manage multiple realms.

Review

This section documents the review of the project according to Project policy. It is divided into multiple sections. First, approvals should be listed. To list an approval type

#~~~~

on its own line. The next section is for discussion. Use standard talk page conventions. In particular, sign comments with

--~~~~

and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with {{project-block}}. The member who raised the objection should remove this markup when their objection is handled.