Subject: KRB5PrincipalName name constraints in PKINIT

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

Starting a separate thread on KRB5PrincipalName name constraining for PKINIT.

I'll try my best to address all raised issues on this.

Some facts:
Yes, only one instance of a name constraints extension can be present in a cert, but that extension can contain any number of permitted and excluded subtrees for any name form. So there is never any need for multiple extensions.

Name constraints is based on hierarchal name forms with root, nodes and subtrees for each node. If a name form is not hierarchial that does not mean that name constraining is impossible, but it means that each name is treated as its own root and thus that no name spaces can be defined. Only single names can be permitted and excluded.

Name constraints is part of basic path processing and as such it can only process defined and detectable rules. A name form is either defined as hierarchical or it is not. There is no way we can write a standard for name constraints matching that says "when domain style realms are used, do this ....., else do that...." unless those options are tagged and defined as part of the name syntax. 

Some assumptions and observations:
Looking through RFC 4120 I find that the combination of Realm and PrincipalName actually forms a basic hierarchical structure where the name-string part of the PrincipalName MUST be unique within a Realm (regardless of name-type which is only a hint). 2 entities can however have the same PrincipalName if they belong to different Realms.

So one could assume that it could be useful to constrain on realm name but allow any principal name under that realm. However to specify such constraints using the KRB5PrincipalName, the PrincipalName component of KRB5PrincipalName must be optional, which it isn't. And since it isn't, name constraints can't be specified for just Realm.

This could be easily fixed if KRB5PrincipalName could be changed to:

       KRB5PrincipalName ::= SEQUENCE {
           realm                   [0] Realm,
           principalName           [1] PrincipalName OPTIONAL
       }

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.

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 can't understand however why we should disallow excluded subtrees.

These are the name constraints matching rules I can see as reasonable:

A KRB5PrincipalName listed under permittedSubtrees or excludedSubtrees MUST include a Realm name and MAY include a PrincipalName. When PrincipalName is absent, the constrain apply to all possible PrincipalName values for the specified Realm. When PrincipalName is present, then name constraining of that name is processed disregarding any name-type value.

KerberosString matching rule caseExactMatch (X.520). 
name-type matching is omitted from name constraints processing.

When one or more KRB5PrincipalName are present under permittedSubtrees, then only listed Realms with specified PrincipalNames are allowed.
When one or more KRB5PrincipalName are present under excludedSubtrees, then none of the listed Realms with specified PrincipalNames are allowed

If two KRB5PrincipalName, specifying the same Realm are listed, one in permittedSubtrees and the other in excludedSubtrees, then all name-string values under that realm listed under permittedSubtrees are allowed except for those listed under excludedSubtrees.

Stefan Santesson 
Program Manager, Standards Liaison 
Windows Security 
  
________________________________________
From: Liqiang(Larry) Zhu 
Sent: den 1 september 2005 07:24
To: Nicolas Williams
Cc: Paul Leach; Jeffrey Hutzelman; Stefan Santesson; Sam Hartman; [email-masked]; [email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

> It's clear that NameConstraints's subtrees are SEQUENCEs and so should
> allow for what I'm proposing.

sure, but your text does not allow that, because KDC cert name constraints and client principal name constraints are mutually exclusive in your text, it does have to be that way.
also, I should have add "when domain style realms are used", also I notice that the client principal name constraints do not work with referrals, aka nt-enterprise-princial name type, but I can fix these.
 
On Wed, Aug 31, 2005 at 10:12:25PM -0700, Liqiang(Larry) Zhu wrote:
> > >    permittedSubtrees MUST be present and excludedSubtrees MUST be
> > > absent.
>
> > Why?
> 
> this is because your text seemed to imply permittedSubtrees, and I believe it would be fine to limit
> name constraints to permittedSubtrees only in this ID, to reduce complexity.
> 
> if you need excludedSubtrees too, you need to modify the text  a bit.

If we want to reduce complexity then we can allow implementors to ignore
name constraints provided that local policy mechanisms exist to provide
control over what CAs can issue what KDC certs.

Consider an implementation that is pluggable with respect to matching
rules for name constraints on AnotherName etc.  What you propose would
add complexity, rather than remove it.

> > > Note that a CA certificate can only have one instance of the name
> > > constraints extension. So this definition could mean that we can not
> > > have a CA issue client certs and KDC certs at the same time.
>
> > I don't agree.  First, I'm not sure about the first part
> 
> section 4.2 of RFC 3280, it says
> 
>  A certificate MUST NOT include more than
>    one instance of a particular extension.

Ok.

> >  the ones that match on KRB5Principals of type
> > NT-UNKNOWN would not (as I would have it) match TGS names, and...
> well have you noticed that the two name constraints are mutually excusively.

?

It's clear that NameConstraints's subtrees are SEQUENCEs and so should
allow for what I'm proposing.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 01 Sep 2005 12:16:44 -0400

<wg chair hat off>

>            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: Matt Crawford <[email-masked]>
Date: Fri, 02 Sep 2005 13:59:21 -0500

Could someone spare two minutes to tell me whether this seems to be a  
SubjectAltName extension containing a correctly implemented  
KRB5PrincipalName?

$ openssl asn1parse -i -in mc.pem
     0:d=0  hl=4 l=1061 cons: SEQUENCE
     4:d=1  hl=4 l= 781 cons:  SEQUENCE
     8:d=2  hl=2 l=   3 cons:   cont [ 0 ]
    10:d=3  hl=2 l=   1 prim:    INTEGER           :02
    13:d=2  hl=2 l=   3 prim:   INTEGER           :03AFCA
    18:d=2  hl=2 l=  13 cons:   SEQUENCE
    20:d=3  hl=2 l=   9 prim:    OBJECT            :md5WithRSAEncryption
    31:d=3  hl=2 l=   0 prim:    NULL
[...etc...]
   724:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Subject  
Alternative Name
   729:d=5  hl=2 l=  58 prim:      OCTET STRING
   789:d=1  hl=2 l=  13 cons:  SEQUENCE
   791:d=2  hl=2 l=   9 prim:   OBJECT            :md5WithRSAEncryption
   802:d=2  hl=2 l=   0 prim:   NULL
   804:d=1  hl=4 l= 257 prim:  BIT STRING
$ openssl asn1parse -i -in mc.pem -strparse 729
     0:d=0  hl=2 l=  56 cons: SEQUENCE
     2:d=1  hl=2 l=  16 prim:  cont [ 1 ]
    20:d=1  hl=2 l=  36 cons:  cont [ 0 ]
    22:d=2  hl=2 l=   6 prim:   OBJECT            :1.3.6.1.5.2.2
    30:d=2  hl=2 l=  26 cons:   cont [ 0 ]
    32:d=3  hl=2 l=  24 cons:    SEQUENCE
    34:d=4  hl=2 l=   8 prim:     GENERALSTRING
    44:d=4  hl=2 l=   1 prim:     INTEGER           :00
    47:d=4  hl=2 l=   9 cons:     SEQUENCE
    49:d=5  hl=2 l=   7 prim:      GENERALSTRING

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Sep 2005 09:43:50 -0400

I thought we explicitly had a consensus (probably at IETf 61) that we
did not want to define a name constraint form for Kerberos.

When did we reverse that decision?

--Sam

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Sep 2005 13:10:34 -0400

> When did we reverse that decision?

My memory may be poor, but my recollection was that we decided not to do it 
"now" (i.e. in PKINIT) because we didn't see an immediate need and there 
was nothing to prevent it from being done later if necessary.

So far, we haven't reversed that decision.  But there do seem to be several 
people arguing that we should do so.

However, that should not hold up the remainder of the work unnecessarily. 
Therefore, I would like to see proposed text for PKINIT-28 which addresses 
the remaining issues in the "KDC certs part 1" thread, without making 
references to name constraint forms that do not exist.

If CA's wish to use name constraints, they can already do so.
If clients do not with to apply name constraints, that's tough.
Changing either of these things is OUT OF SCOPE for this WG.

If we want to define a name constraint form for Kerberos, we can do so. 
But unless and until there is a consensus in this WG to reverse the earlier 
decision, we will _not_ sit around arguing indefinitely about what we 
should say in PKINIT about name constraints.

-- Jeff