Projects/Aliases

This project has been completed.

This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.

Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases.

Functional Requirements

• If a user logs into a workstation using a case representation of their principal different than that stored in the Kerberos database, then they should be successful.
• A user can use an enterprise name [1] to log into a workstation.
• Certain accent rules and normalization will be applied to principals for comparison when looking up principals in the kerberos database. The specific rules for what strings will be equal may be database backend specific and will be decided as an implementation matter.
• Servers may have multiple aliases stored in the Kerberos database; users may request any of these aliases and get a ticket.
• Users may log in with an alternate form of their username that is site or realm specific and receive tickets
• Name based authorization for client names will continue to work: the name presented in an AP-REQ needs to be the canonical form of the principal name, not some other form equal to that form.
• The same rules for finding client principals will also apply to lookups for service principals.
• Servers need not keep the implementation of normalization and case folding rules strictly in sync with clients.

Case insensitive and international friendly search

Client principals

One approach would be to return the principal the client asked for even if the database entry differed from this. The problem is that many Kerberos applications use name based authorization and will do a comparison of the client name in the authenticator against an access control list. Microsoft avoids this with the PAC. However it is not reasonable to assume that applications can be modified to compare principals the same way that the KDC does. Also doing so would break several requirements.

So, the KDC must only change the client principal when name canonicalization is enabled and only in a manner compatible with client expectations so that the client gets the modified principal.

Server principals

Server principals need to be handled differently. The problem is that the KDC cannot generally change the name of the server principal. So, instead, we must return the principal name exactly as the client asked for it. However we need to come up with a solution so that the server doesn't need to know the comparison function the KDC is using.

We do this by ignoring the server name in the ticket (except in the KDB keytab) and finding a key in the keytab that can decrypt the ticket. If the application passes in constraints about what principal names are used, we use these constraints. If not, we accept any key in the keytab. We update the context claiming that the client authenticated to whatever principal is we found in the keytab.

Canonicalization and aliases

• Implement an option to kinit to request canonicalization
• Implement a canonicalize option in krb5.conf to request canonicalization by default
• Add get_init_creds API to request canonicalization
• Implement ability of KDB backends to request that the server or client principal name change
• Canonicalization support is implied either by an enterprise name type or the canonicalize flag.

Client principals

When the KDC is looking up a client principal, it sets a canonicalize flag in the call to the KDB if canonicalization is desired. If this flag is set, the KDB may return a different alias for the client principal name. This may result from finding a canonical principal of a different case, or by finding an explicit alias. In the case of case mismatch or normalization, it is strongly desired that the KDB backend return the canonical name rather than the name requested by the user. This differs from AD behavior, but is much less likely to break name-based authorization. The KDC will generate a wrong_realm error or a AS reply with a different client name as appropriate.

If the client sets the canonicalize flag or uses an enterprise name, it will permit the client name to change in an AS reply and will process wrong_realm errors.

Server aliases

For the TGS, the KDC always returns the name of the service that the client requested. However the KDB backend may search using the supplied principal either as the canonical name for the server or as an alias.

For the AS, if the canonicalize flag is set, the KDB may change the name of the server. Unless the server is a password changing service, this will be reflected back to the client.

The service is modified to ignore the name in the ticket in krb5_rd_req.

What is not included

The KDC support includes no KDB changes to actually take advantage of the new functionality. The functionality has been tested against a proprietary KDB backend that is not being contributed to MIT Kerberos. So, there will be no way without writing a KDB backend or otherwise changing a KDB backend to take advantage of the KDC changes.

A simple approach might be to write a KDB backend that interposed itself between the KDC and the DB2 backend and looked up aliases in an alias database.

There are no changes even to the LDAP backend to support case insensitive or Unicode searches.

Security issues

Concerns have been raised regarding the security of AS canonicalization as implemented in the current code. In particular, it seems that the approach is vulnerable to phishing attacks. We are attempting to understand whether Windows is vulnerable and if not, how these concerns are addressed.

In order to address these concerns, the client has been modified to only allow the server name to change from one TGS to another in the AS. That supports the case of Windows short realm names, but does not seem to open significant phishing opportunities. This should be studied in more detail.

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.