Subject: RE: KRB5PrincipalName name constraints in PKINIT

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 1 Sep 2005 18:13:11 +0100

Jeff,

I'm not sure but from what I see in your examples I wander if you
wouldn't be much better off if KRB5PrincipalName was defined just as an
IA5String (or UTFString) expressing principalName and realm in the one
string format you use in your examples (Separated by "@").

That would probably make name constraints definition and processing a
lot easier.

I think we agree in principle. My shortage of functionality is simply
related to my lack of knowledge of conventions defined for name
semantics in principalName. As long as these semantics are well defined,
they can be used in name constraining matching rules.

The relative complex structure of KRB5PrincipalName does however
complicate things since all fields are mandatory which creates problem
when you want to allow any value without using wild card characters.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]]
> Sent: den 1 september 2005 18:17
> To: Stefan Santesson; Liqiang(Larry) Zhu; Nicolas Williams
> Cc: Paul Leach; Sam Hartman; [email-masked]; [email-masked];
> Jeffrey Hutzelman
> Subject: Re: KRB5PrincipalName name constraints in PKINIT
> 
> <wg chair hat off>
> 
> 
> On Thursday, September 01, 2005 11:56:57 +0100 Stefan Santesson
> <[email-masked]> wrote:
> 
> > This could be easily fixed if KRB5PrincipalName could be changed to:
> >
> >        KRB5PrincipalName ::= SEQUENCE {
> >            realm                   [0] Realm,
> >            principalName           [1] PrincipalName OPTIONAL
> >        }
> 
> I don't actually think that's necessary, but I won't object.
> 
> > The same problem applies to name-type and name-string for
PricipalName
> > (defined in RFC 4120). Since both components are mandatory, a name
> > constraint can't be expressed using this format only for name-type
or
> > only for name-string. This brings the reasonable conclusion that
name
> > constraining on Principal should be limited to the distinguishing
> > name-string component, disregarding any name-type.
> 
> Agree.
> 
> 
> 
> > My conclusion:
> > Provided that PrincipalName is made OPTIONAL, I think defining name
> > constraints matching for KRB5PrincipalName is possible and that
rules
> > should be rather straight forward (stated below).
> 
> I think your rules are insufficient to express the common cases I
> described
> in an earlier message.  Kerberos principal names are more complex than
a
> simple heirarchy, and that needs to be reflected in any constraint
form we
> adopt.
> 
> 
> 
> > I can't understand however why we should disallow excluded subtrees.
> 
> Nor can I.  I don't expect doing so would actually make anything any
> easier
> for implementors; the algorithm is basically "if it matches any thing
in
> permitted subtrees, and doesn't match anything in excluded subtrees,
then
> it is allowed.  Otherwise not".  The use of the word "subtrees" is
> somewhat
> shortsighted, probably because the designers were thinking only of
purely
> heirarchical name forms like those for which constraints are defined
in
> RFC3280.
> 
> Last night I wrote up these proposed rules for KRB5PrincipalName:
> 
> 
> Matching Rules:
> (a) A name with zero components matches any principal in that realm
> (b) An empty component matches any component
> (c) An empty realm matches any realm
> 
> Examples:
> 1 Only a specific principal name
> 2 Any single-component principal in a specified realm
> 3 Any principal in a specified realm, with any number of components
> 4 Any krbtgt instance in any realm
> 5 A host-based SPN for a specific service and any host
> 6 A host-based SPN for any service on a specific host
> 7 A domain-based SPN for a specific service and domain and any host
> 8 A domain-based SPN for a specific service and any domain and host
> 9 A domain-based SPN for any service and host with a specific domain
> 
> 1: [email-masked]
> 2: @EXAMPLE.COM [one empty component]
> 3: @EXAMPLE.COM [zero components]
> 4: krbtgt/@
> 5: host/@EXAMPLE.COM
> 6: /[email-masked]
> 7: ldap//[email-masked]
> 8: ldap//@EXAMPLE.COM
> 9: //[email-masked]
> 
> Note that if we make the PrinicpalName part optional, then rule (a)
could
> be replaced with "A constraint with no PrincipalName matches any
principal
> in that realm".
> 
> 
> Note that these rules are not strictly heirarchical.  I tried to come
up
> with rules that were, and found that examples 6,7, and 9 were
impossible
> to
> represent, and examples 4, 5, and 8 could only be represented
inexactly.
> 
> I don't object to using DNS-style matching for DNS-style realm names,
and
> requiring exact matching for other styles.  Note that RFC4120 makes it
> possible to distinguish between different types of realm names
> syntactically.
> 
> It _might_ be possible to construct something more heirarchical by
> considering name types, but I don't think it would be elegant, or rich
> enough for principal naming conventions we haven't thought of.  I also
> don't think it's necessary; instead of heirarchical "subtrees", we
simply
> have "patterns" which are just as easy to match deterministically, but
> don't happen to have a heirarchical relationship on which the
constraint
> algorithm doesn't really depend anyway.
> 
> -- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 01 Sep 2005 13:28:38 -0400

> That would probably make name constraints definition and processing a

I don't think so.  My examples use the traditional string-representation 
syntax for Kerberos principal names, just to make it them easier to 
understand for discussion purposes.  The current definition of 
KRB5PrincipalName is consistent with the way principal names are 
represented on the wire in the rest of the Kerberos protocol.

> when you want to allow any value without using wild card characters.

Well, I think we safely can give empty components and realm names wildcard 
meaning, and similarly allow a zero-length list of components to mean "any 
number of components" (alternately, we could make the PrincipalName part 
optional, as you suggested).  If we wanted pattern matching within a 
component name, we'd have to do something more complex; I'm not sure that's 
necessary, but I'm willing to hear comments from others on that.

Part of the problem is that while there are some widely-followed principal 
naming conventions (host-based service names, and single-component names 
for users, and two-component names like "jhutz/admin" for privileged or 
special-purpose principals), there may be other conventions in use at some 
sites.  And we've already invented one new principal name since work on 
4120 began (the domain-based service name, which IIRC was actually 
orginially a Microsoft proposal); who's to say there won't be more?