jhutz at cmu.edu
Sat Apr 11 19:19:39 EDT 2009
--On Saturday, April 11, 2009 12:17:37 AM -0600 Shawn M Emery
<Shawn.Emery at Sun.COM> wrote:
> Recently there has been some ambiguity on how to handle case sensitivity
> for principal names. Various principal name components are used either
> in upper or lower case. For example the following principal names are
> considered valid:
> HTTP/host1.example.com at EXAMPLE.COM
> HOST/host1.example.com at EXAMPLE.COM
> host/host1.example.com at EXAMPLE.COM
> host/HOST1.EXAMPLE.COM at EXAMPLE.COM
> In order to prevent issues with interoperability, I believe that it
> should be made clear what we can inference from a principal name and
> that the various implementations reflect this.
You can infer nothing from a principal name. There are a number of common
conventions for _constructing_ principal names, some of which are
documented and/or standardized, but I know of no defined rules for
_deconstructing_ principal names; a name is just a name.
> The other question/issue is that there is no formal syntax to represent
> valid principal names. Currently there are a number of questionable
> principal names that can added to the database. For example:
Are those principals with empty components, or principals with single
components containing the characters '/' and/or '@' ? I suspect you mean
Empty realm names do not match any of the syntaxes described in RFC4120,
and so are forbidden. IMHO it would be fine for software to reject such
invalid realm names, though I'm not sure there's any particular reason to
do so (though there might be in the particular case of an empty realm).
Principal names with empty components _are_ valid, though I think we looked
into this before when working on draft-ietf-krb-wg-naming; you might want
to take a look in that document and/or in the krb-wg traffic that led to it.
> Some principal names can not be used with Kerberos utilities, others may
> be able to by accident. My opinion is that a formal syntax for
> principals names should exist, but should also allow for future
> extensions. The syntax can be used to enforce which principal names are
> allowed to be populated in the database and therefore supported by the
> various utilities.
The question of what are and are not valid Kerberos principal names is,
IMHO, a protocol matter. Please feel free to bring it up on the krb-wg
mailing list, but you may wish to first examine the -naming document, which
speaks to some (but not all) of these issues.
More information about the krbdev