Principal naming

[Shawn M Emery]

Thanks to all for the replies.  Comments in-line...

Jeffrey Hutzelman wrote:
> --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.

Ok, I will check with at least one known implementor that uses upper and 
lower case for service and host components to see if they are actually 
semantically different.  Greg mentioned that the spnego-auth draft 
defines the service component in upper case, but not in lower case.

>> 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:
>>
>> host/@EXAMPLE.COM
>> host/@
>> /@
>> //@
>> user@
>
> Are those principals with empty components, or principals with single 
> components containing the characters '/' and/or '@' ?  I suspect you 
> mean the former.

Yes, the former.

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

Yes, a mechanism could interpret an empty realm (non transitive) with an 
unknown outcome, ergo I believe that there should be some sanity 
checking during creation.

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

Thanks for the reminder, I will take a look.  Yes, I wasn't against this 
particular element, as I could see that empty components could be useful 
in wild carding in authorization based on services, host names, domain 
names, etc.

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

Ok, thanks.  I will read this and come back with anything that still may 
not be clear.

Shawn.
--