logo_kerberos.gif

Projects/Aliases

From K5Wiki
< Projects
Revision as of 20:42, 20 November 2008 by SamHartman (talk | contribs) (New page: {{project-early}} This project proposes to add support for '''Unicode principal names and case insensitive principal search'''. The goal of this project is to get behavior more similar t...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.


This project proposes to add 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.

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.
  • 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.
  • 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.

Design Limitations

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.