KRB5PrincipalName name constraints in PKINIT

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

KRB5PrincipalName name constraints in PKINIT

Stefan Santesson
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; [hidden email]; [hidden email]
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.

Reply | Threaded
Open this post in threaded view
|

Re: KRB5PrincipalName name constraints in PKINIT

Jeffrey Hutzelman
<wg chair hat off>


On Thursday, September 01, 2005 11:56:57 +0100 Stefan Santesson
<[hidden email]> 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: [hidden email]
2: @EXAMPLE.COM [one empty component]
3: @EXAMPLE.COM [zero components]
4: krbtgt/@
5: host/@EXAMPLE.COM
6: /[hidden email]
7: ldap//[hidden email]
8: ldap//@EXAMPLE.COM
9: //[hidden email]

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

Reply | Threaded
Open this post in threaded view
|

RE: KRB5PrincipalName name constraints in PKINIT

Stefan Santesson
In reply to this post by Stefan Santesson
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:[hidden email]]
> Sent: den 1 september 2005 18:17
> To: Stefan Santesson; Liqiang(Larry) Zhu; Nicolas Williams
> Cc: Paul Leach; Sam Hartman; [hidden email]; [hidden email];
> Jeffrey Hutzelman
> Subject: Re: KRB5PrincipalName name constraints in PKINIT
>
> <wg chair hat off>
>
>
> On Thursday, September 01, 2005 11:56:57 +0100 Stefan Santesson
> <[hidden email]> 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: [hidden email]
> 2: @EXAMPLE.COM [one empty component]
> 3: @EXAMPLE.COM [zero components]
> 4: krbtgt/@
> 5: host/@EXAMPLE.COM
> 6: /[hidden email]
> 7: ldap//[hidden email]
> 8: ldap//@EXAMPLE.COM
> 9: //[hidden email]
>
> 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

Reply | Threaded
Open this post in threaded view
|

RE: KRB5PrincipalName name constraints in PKINIT

Jeffrey Hutzelman


On Thursday, September 01, 2005 18:13:11 +0100 Stefan Santesson
<[hidden email]> wrote:

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


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

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?

Reply | Threaded
Open this post in threaded view
|

RE: KRB5PrincipalName name constraints in PKINIT

Larry Zhu
In reply to this post by Stefan Santesson

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

This is necessary for NT-enterprise-principal name, but where are we for
the WGLC of the referrals draft?

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jeffrey
Hutzelman
Sent: Thursday, September 01, 2005 10:29 AM
To: Stefan Santesson; Liqiang(Larry) Zhu; Nicolas Williams
Cc: Paul Leach; Sam Hartman; [hidden email]; [hidden email];
Jeffrey Hutzelman
Subject: RE: KRB5PrincipalName name constraints in PKINIT



On Thursday, September 01, 2005 18:13:11 +0100 Stefan Santesson
<[hidden email]> wrote:

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


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

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?

Reply | Threaded
Open this post in threaded view
|

Re: KRB5PrincipalName name constraints in PKINIT

Matt Crawford
In reply to this post by Stefan Santesson
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

Reply | Threaded
Open this post in threaded view
|

Re: Do we need KRB5PrincipalName name constraints in PKINIT

Sam Hartman-5
In reply to this post by Jeffrey Hutzelman


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

Reply | Threaded
Open this post in threaded view
|

Re: Do we need KRB5PrincipalName name constraints in PKINIT

Jeffrey Hutzelman


On Wednesday, September 07, 2005 09:43:50 -0400 Sam Hartman
<[hidden email]> wrote:

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

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

Reply | Threaded
Open this post in threaded view
|

RE: Do we need KRB5PrincipalName name constraints in PKINIT

Paul Leach
In reply to this post by Sam Hartman-5
A number of people on the list thought that we really should define one.

Any time more than one CA can issue KDC certs and the CAs do not fully
trust one another, the realm names which each can certify MUST be
specified. That specification does not have to be in the form of name
constraints, but even if it isn't, client policy would have to implement
the moral equivalent. It may be obvious to us how to do that -- will it
be obvious to every reader of the RFC? Experience tells us it won't be.



-----Original Message-----
From: Sam Hartman [mailto:[hidden email]]
Sent: Wednesday, September 07, 2005 6:44 AM
To: Jeffrey Hutzelman
Cc: Stefan Santesson; Liqiang(Larry) Zhu; Nicolas Williams; Paul Leach;
[hidden email]; [hidden email]
Subject: Re: Do we need KRB5PrincipalName name constraints in PKINIT



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

Reply | Threaded
Open this post in threaded view
|

RE: Do we need KRB5PrincipalName name constraints in PKINIT

Paul Leach
In reply to this post by Sam Hartman-5
I disagree that it is out of scope to talk about name constraints -- a
security considerations section should discuss all the relevant and
significant things needed to do a secure implementation and deployment.

I will also reiterate that either the PKI or local policy MUST apply
name constraints when there is more than one CA issuing KDC certs (and
the CAs are run by orgs that don't fully trust one another). Absent an
applicability statement that says PKINIT shouldn't be used in such a
situation, that seems to make it our responsibility to say how such
restrictions work.

Reply | Threaded
Open this post in threaded view
|

RE: Do we need KRB5PrincipalName name constraints in PKINIT

Jeffrey Hutzelman
On Wednesday, September 07, 2005 Paul Leach <[hidden email]>
wrote:

<wg chair hat on>

> A number of people on the list thought that we really should define one.

Well, I've seen you say this over and over again.  One person does not make
a consensus of the WG.  If there are other people who feel that it is
essential to define name constraints for KRB5PrincipalName in the core
PKINIT document, please speak up.  The same goes, of course, for those who
feel it is not essential.

> I disagree that it is out of scope to talk about name constraints -- a
> security considerations section should discuss all the relevant and
> significant things needed to do a secure implementation and deployment.

It is not out of scope to mention name constraints.
It is out of scope to change or override the requirements of RFC3280.

<wg chair hat off>

And it is inappropriate to say that they SHOULD be used, because

- MUST (and SHOULD) are for implementors
- SHOULD means "do this unless you have a very good reason not to", which
  is not the same thing as "do it if your deployment situation calls for it"



> I will also reiterate that either the PKI or local policy MUST apply
> name constraints when there is more than one CA issuing KDC certs (and
> the CAs are run by orgs that don't fully trust one another). Absent an
> applicability statement that says PKINIT shouldn't be used in such a
> situation, that seems to make it our responsibility to say how such
> restrictions work.

The client MUST apply name constraints if they are present in the cert.  It
cannot apply them if they are not present in the cert.


BTW, I disagree that it is at all relevant how many CA's there are or
whether their operators trust each other.  The question is which CA's (or
their operators) are trusted by the _client_ to issue certs for which
KDC's.  And yes, if there is a CA that is trusted by the client to issue
certs for some KDC's but not for others, then it must not accept certs
issued by that CA for KDC's for which it does not trust that CA to issue
certs.  However, name constraints are not the only way to implement such a
policy.  For example, relatively simple configuration can be used to
indicate which trust anchors are used for which realms.  (for the
CS.CMU.EDU realm, use anchor X; for the ANDREW.CMU.EDU realm, use anchor Y;
for the ATHENA.MIT.EDU realm, use anchor Z).

By all means, propose text that requires that clients actually have and
implement policy about which CA's are trusted for which realms.  But please
do not assert either here or in proposed text that the only way to
accomplish this is by use of the name constraints extension, or that it is
impossible to define suitable policy if we fail to define name constraints.

-- Jeff

Reply | Threaded
Open this post in threaded view
|

RE: Do we need KRB5PrincipalName name constraints in PKINIT

Paul Leach
In reply to this post by Sam Hartman-5


> -----Original Message-----
> From: [hidden email] [mailto:owner-ietf-krb-
> [hidden email]] On Behalf Of Jeffrey Hutzelman
> Sent: Wednesday, September 07, 2005 10:47 AM
> To: Paul Leach; Sam Hartman
> Cc: Stefan Santesson; Liqiang(Larry) Zhu; Nicolas Williams;
> [hidden email]; [hidden email]; Jeffrey Hutzelman
> Subject: RE: Do we need KRB5PrincipalName name constraints in PKINIT
>
> On Wednesday, September 07, 2005 Paul Leach
<[hidden email]>
> wrote:
>
> <wg chair hat on>
>
> > A number of people on the list thought that we really should define
one.
>
> Well, I've seen you say this over and over again.  One person does not
> make
> a consensus of the WG.  If there are other people who feel that it is
> essential to define name constraints for KRB5PrincipalName in the core
> PKINIT document, please speak up.  The same goes, of course, for those
who
> feel it is not essential.
[Paul Leach] I thought I heard support from other people... I didn't
think I was counting myself more than once. :-)

>
> > I disagree that it is out of scope to talk about name constraints --
a
> > security considerations section should discuss all the relevant and
> > significant things needed to do a secure implementation and
deployment.
>
> It is not out of scope to mention name constraints.
> It is out of scope to change or override the requirements of RFC3280.
[Paul Leach] I completely agree.

>
> <wg chair hat off>
>
> And it is inappropriate to say that they SHOULD be used, because
>
> - MUST (and SHOULD) are for implementors
> - SHOULD means "do this unless you have a very good reason not to",
which
>   is not the same thing as "do it if your deployment situation calls
for
> it"

[Paul Leach] The last proposed text I sent did not use MUST or SHOULD
about name constraints.

>
>
> > I will also reiterate that either the PKI or local policy MUST apply
> > name constraints when there is more than one CA issuing KDC certs
(and
> > the CAs are run by orgs that don't fully trust one another). Absent
an
> > applicability statement that says PKINIT shouldn't be used in such a
> > situation, that seems to make it our responsibility to say how such
> > restrictions work.
>
> The client MUST apply name constraints if they are present in the
cert.
> It
> cannot apply them if they are not present in the cert.
[Paul Leach] Sorry -- bad choice of words -- what I meant was that if
the PKI doesn't use name constraints, then the local policy must have
some other mechanism to constrain the names of the realms for which CAs
can issue KDC certs (if there is more than one).

>
>
> BTW, I disagree that it is at all relevant how many CA's there are or
> whether their operators trust each other.  The question is which CA's
(or
> their operators) are trusted by the _client_ to issue certs for which
> KDC's.  And yes, if there is a CA that is trusted by the client to
issue
> certs for some KDC's but not for others, then it must not accept certs
> issued by that CA for KDC's for which it does not trust that CA to
issue
> certs.  However, name constraints are not the only way to implement
such a
> policy.  For example, relatively simple configuration can be used to
> indicate which trust anchors are used for which realms.  (for the
> CS.CMU.EDU realm, use anchor X; for the ANDREW.CMU.EDU realm, use
anchor
> Y;
> for the ATHENA.MIT.EDU realm, use anchor Z).
[Paul Leach] Yes, that's true -- I think of those as constraints on the
(realm) names that the CA can issue. Conceptually, they serve the same
purpose as name constraints -- just locally specified instead of
specified by the PKI admins.

The reason that the PKI admins care is that they may not want to leave
it up to client policy which CAs to trust -- as admins of an
organizations PKU, it is their job to make sure than clients that rely
on the org's PKI do the right thing. As you pointed out, if name
constraints are present, the client MUST apply them.

>
> By all means, propose text that requires that clients actually have
and
> implement policy about which CA's are trusted for which realms.  But
> please
> do not assert either here or in proposed text that the only way to
> accomplish this is by use of the name constraints extension, or that
it is
> impossible to define suitable policy if we fail to define name
> constraints.
[Paul Leach] I believe the text I proposed (in my message sent Thu
9/1/2005 12:23 PM) meets those requirements. It was my intent that it do
so. If it has failed, I'd be happy to try to clarify anything that
people find confusing.

Reply | Threaded
Open this post in threaded view
|

RE: Do we need KRB5PrincipalName name constraints in PKINIT

Stefan Santesson
In reply to this post by Sam Hartman-5
Jeff,

Counting you, me and Paul I count to at least 3 voices expressing a
desire to specify name constraints matching rules for id-pksan.

If we do it, I think it can be done as a separate effort and no specific
reference to this have to be included in PKINIT.

In my mind, all that PKINIT reasonably can do is to point out the need
for a client to determine that a CA issuing a KDC certificate is
authorized to do so for a particular realm and at most provide an
example of how you can use constraining of dNSname to support such
client policy.

A name constraints RFC for id-pksan would then add to the available
means to enforce and manage enforcement the client policies that meets
the intent of PKINIT.

I could volunteer as editor for such name constraints draft but I would
appreciate a co-editor with more genuine Kerberos experience while I
would cover and ensure RFC 3280 consistency and accuracy of PKI aspects.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Paul Leach
> Sent: den 7 september 2005 13:11
> To: Jeffrey Hutzelman; Sam Hartman
> Cc: Stefan Santesson; Liqiang(Larry) Zhu; Nicolas Williams;
> [hidden email]; [hidden email]
> Subject: RE: Do we need KRB5PrincipalName name constraints in PKINIT
>
>
>
> > -----Original Message-----
> > From: [hidden email] [mailto:owner-ietf-krb-
> > [hidden email]] On Behalf Of Jeffrey Hutzelman
> > Sent: Wednesday, September 07, 2005 10:47 AM
> > To: Paul Leach; Sam Hartman
> > Cc: Stefan Santesson; Liqiang(Larry) Zhu; Nicolas Williams;
> > [hidden email]; [hidden email]; Jeffrey Hutzelman
> > Subject: RE: Do we need KRB5PrincipalName name constraints in PKINIT
> >
> > On Wednesday, September 07, 2005 Paul Leach
> <[hidden email]>
> > wrote:
> >
> > <wg chair hat on>
> >
> > > A number of people on the list thought that we really should
define
> one.
> >
> > Well, I've seen you say this over and over again.  One person does
not
> > make
> > a consensus of the WG.  If there are other people who feel that it
is
> > essential to define name constraints for KRB5PrincipalName in the
core
> > PKINIT document, please speak up.  The same goes, of course, for
those
> who
> > feel it is not essential.
> [Paul Leach] I thought I heard support from other people... I didn't
think
> I was counting myself more than once. :-)
>
> >
> > > I disagree that it is out of scope to talk about name constraints
-- a
> > > security considerations section should discuss all the relevant
and
> > > significant things needed to do a secure implementation and
> deployment.
> >
> > It is not out of scope to mention name constraints.
> > It is out of scope to change or override the requirements of
RFC3280.

> [Paul Leach] I completely agree.
>
> >
> > <wg chair hat off>
> >
> > And it is inappropriate to say that they SHOULD be used, because
> >
> > - MUST (and SHOULD) are for implementors
> > - SHOULD means "do this unless you have a very good reason not to",
> which
> >   is not the same thing as "do it if your deployment situation calls
for
> > it"
>
> [Paul Leach] The last proposed text I sent did not use MUST or SHOULD
> about name constraints.
>
> >
> >
> > > I will also reiterate that either the PKI or local policy MUST
apply
> > > name constraints when there is more than one CA issuing KDC certs
(and
> > > the CAs are run by orgs that don't fully trust one another).
Absent an
> > > applicability statement that says PKINIT shouldn't be used in such
a
> > > situation, that seems to make it our responsibility to say how
such
> > > restrictions work.
> >
> > The client MUST apply name constraints if they are present in the
cert.
> > It
> > cannot apply them if they are not present in the cert.
> [Paul Leach] Sorry -- bad choice of words -- what I meant was that if
the
> PKI doesn't use name constraints, then the local policy must have some
> other mechanism to constrain the names of the realms for which CAs can
> issue KDC certs (if there is more than one).
>
> >
> >
> > BTW, I disagree that it is at all relevant how many CA's there are
or
> > whether their operators trust each other.  The question is which
CA's
> (or
> > their operators) are trusted by the _client_ to issue certs for
which
> > KDC's.  And yes, if there is a CA that is trusted by the client to
issue
> > certs for some KDC's but not for others, then it must not accept
certs
> > issued by that CA for KDC's for which it does not trust that CA to
issue
> > certs.  However, name constraints are not the only way to implement
such
> a
> > policy.  For example, relatively simple configuration can be used to
> > indicate which trust anchors are used for which realms.  (for the
> > CS.CMU.EDU realm, use anchor X; for the ANDREW.CMU.EDU realm, use
anchor
> > Y;
> > for the ATHENA.MIT.EDU realm, use anchor Z).
> [Paul Leach] Yes, that's true -- I think of those as constraints on
the
> (realm) names that the CA can issue. Conceptually, they serve the same
> purpose as name constraints -- just locally specified instead of
specified
> by the PKI admins.
>
> The reason that the PKI admins care is that they may not want to leave
it
> up to client policy which CAs to trust -- as admins of an
organizations
> PKU, it is their job to make sure than clients that rely on the org's
PKI
> do the right thing. As you pointed out, if name constraints are
present,
> the client MUST apply them.
>
> >
> > By all means, propose text that requires that clients actually have
and
> > implement policy about which CA's are trusted for which realms.  But
> > please
> > do not assert either here or in proposed text that the only way to
> > accomplish this is by use of the name constraints extension, or that
it
> is
> > impossible to define suitable policy if we fail to define name
> > constraints.
> [Paul Leach] I believe the text I proposed (in my message sent Thu
> 9/1/2005 12:23 PM) meets those requirements. It was my intent that it
do
> so. If it has failed, I'd be happy to try to clarify anything that
people
> find confusing.

Reply | Threaded
Open this post in threaded view
|

Re: Do we need KRB5PrincipalName name constraints in PKINIT

Sam Hartman-5
>>>>> "Stefan" == Stefan Santesson <[hidden email]> writes:


    Stefan> In my mind, all that PKINIT reasonably can do is to point
    Stefan> out the need for a client to determine that a CA issuing a
    Stefan> KDC certificate is authorized to do so for a particular
    Stefan> realm and at most provide an example of how you can use
    Stefan> constraining of dNSname to support such client policy.

Speaking as an individual, I am uncomfortable with a dnsname constraint because we are not
suggesting that people use or support dnsnames to name their realms.

Reply | Threaded
Open this post in threaded view
|

RE: Do we need KRB5PrincipalName name constraints in PKINIT

Paul Leach
In reply to this post by Sam Hartman-5


-----Original Message-----
From: Sam Hartman [mailto:[hidden email]]
Sent: Friday, September 09, 2005 12:44 PM
To: Stefan Santesson


Speaking as an individual, I am uncomfortable with a dnsname constraint
because we are not
suggesting that people use or support dnsnames to name their realms.
[Paul Leach] It isn't necessary that we suggest that they use DNS names
to name their realms in order to suggest that _if_ they happen to name
their realms with DNS names they might want to use dNSName SAN in their
KDC certs and also use name constraints on the dNSName SAN.

Especially since quite a lot of people in fact use DNS names for their
realms.

Reply | Threaded
Open this post in threaded view
|

RE: Do we need KRB5PrincipalName name constraints in PKINIT

Stefan Santesson
In reply to this post by Sam Hartman-5
Sam,

I think you misunderstand my intent.

My intent is not to suggest that dNSName by default work as a
placeholder for realm names, because it can't.

But that does not prevent dNSName name constraints from being useful to
support certain local client policies.

Say that the clients of an organization are configured (under certain
conditions) to require the realm name of the KDC to be "consistent" with
a present dNSName in the KDC certificate. "Consistent" could in this
example be that there is a successful caseIgnore match between the realm
name and the dNSName in the KDC certificate.

_IF_ this policy is enforced in all clients of an organization, then the
PKI of that organization could constrain accepted realms for KDCs by
applying name constraints to the dNSName SAN when cross certifying CAs.

But you are right that the usefulness of constraining on dNSName SAN is
totally dependent on the local policy deployed in clients and that the
issuing CAs also support the policy by including dNSNAmes in the KDC
certificates.

But despite that, I still think this is a valid use case to show how
name constraints can be used and enforced in line with local agreements
and policies.



Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> -----Original Message-----
> From: Sam Hartman [mailto:[hidden email]]
> Sent: den 9 september 2005 12:44
> To: Stefan Santesson
> Cc: Paul Leach; Jeffrey Hutzelman; Liqiang(Larry) Zhu; Nicolas
Williams;

> [hidden email]; [hidden email]
> Subject: Re: Do we need KRB5PrincipalName name constraints in PKINIT
>
> >>>>> "Stefan" == Stefan Santesson <[hidden email]> writes:
>
>
>     Stefan> In my mind, all that PKINIT reasonably can do is to point
>     Stefan> out the need for a client to determine that a CA issuing a
>     Stefan> KDC certificate is authorized to do so for a particular
>     Stefan> realm and at most provide an example of how you can use
>     Stefan> constraining of dNSname to support such client policy.
>
> Speaking as an individual, I am uncomfortable with a dnsname
constraint
> because we are not
> suggesting that people use or support dnsnames to name their realms.

Reply | Threaded
Open this post in threaded view
|

RE: Do we need KRB5PrincipalName name constraints in PKINIT

Jeffrey Hutzelman
In reply to this post by Paul Leach


On Friday, September 09, 2005 18:27:00 -0700 Paul Leach
<[hidden email]> wrote:



> [Paul Leach] It isn't necessary that we suggest that they use DNS names
> to name their realms in order to suggest that _if_ they happen to name
> their realms with DNS names they might want to use dNSName SAN in their
> KDC certs

<chair hat on>
Except that we've already decided not to say this...

> and also use name constraints on the dNSName SAN.

<chair hat off>
So I don't think we should say this either.


> Especially since quite a lot of people in fact use DNS names for their
> realms.

No one suggested otherwise.  Sam wasn't talking about realms with DNS-style
realm names; he was talking about KDC certificates with the dnsName SAN,
which is not something described by PKINIT.

-- Jeff

Reply | Threaded
Open this post in threaded view
|

RE: Do we need KRB5PrincipalName name constraints in PKINIT

Paul Leach
In reply to this post by Sam Hartman-5


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jeffrey
Hutzelman
Sent: Sunday, September 11, 2005 9:34 PM

On Friday, September 09, 2005 18:27:00 -0700 Paul Leach
<[hidden email]> wrote:

> [Paul Leach] It isn't necessary that we suggest that they use DNS
names
> to name their realms in order to suggest that _if_ they happen to name
> their realms with DNS names they might want to use dNSName SAN in
their
> KDC certs

<chair hat on>
Except that we've already decided not to say this...

[Paul Leach] With all the talk about dNSName on the list, I didn't
realize that the draft doesn't mention it at all. (I apologize. Now I
realize why some of my name constraint comments weren't making sense to
people.)

I think that means there's an interop problem. Section 3.2.2 of the
draft says:

   "In addition to validating the client's signature, the KDC MUST also
   check that the client's public key used to verify the client's
   signature is bound to the client's principal name as specified in the
   AS-REQ as follows:

   1. If the KDC has its own binding between either the client's
      signature-verification public key or the client's certificate and
      the client's Kerberos principal name, it uses that binding.

   2. Otherwise, if the client's X.509 certificate contains a Subject
      Alternative Name (SAN) extension carrying a KRB5PrincipalName
      (defined below) in the otherName field of the type GeneralName
      [RFC3280], it binds the client's X.509 certificate to that name."

Similarly, section 3.2.4 says:
   "In addition, unless the client
   can otherwise verify that the public key used to verify the KDC's
   signature is bound to the KDC of the target realm, the KDC's X.509
   certificate MUST contain a Subject Alternative Name extension
   [RFC3280] carrying an AnotherName whose type-id is id-pksan (as
   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
   matches the name of the TGS of the target realm (as defined in
   Section 7.3 of [RFC4120])."

However, the draft does not say that support of id-pksan is
mandatory-to-implement. I.e., in both these places, private
implementation agreements are allowed, but an standard interoperable
mechanism is not required to be implemented. (At least as far as I could
see.)

Reply | Threaded
Open this post in threaded view
|

RE: Do we need KRB5PrincipalName name constraints in PKINIT

Jeffrey Hutzelman


On Sunday, September 11, 2005 22:04:13 -0700 Paul Leach
<[hidden email]> wrote:

> However, the draft does not say that support of id-pksan is
> mandatory-to-implement. I.e., in both these places, private
> implementation agreements are allowed, but an standard interoperable
> mechanism is not required to be implemented. (At least as far as I could
> see.)

Hm; indeed.
This is now ticket #1133.

-- Jeff

Reply | Threaded
Open this post in threaded view
|

Re: Do we need KRB5PrincipalName name constraints in PKINIT

Martin Rex
In reply to this post by Stefan Santesson
Stefan Santesson wrote:

>
> But that does not prevent dNSName name constraints from being useful to
> support certain local client policies.
>
> Say that the clients of an organization are configured (under certain
> conditions) to require the realm name of the KDC to be "consistent" with
> a present dNSName in the KDC certificate. "Consistent" could in this
> example be that there is a successful caseIgnore match between the realm
> name and the dNSName in the KDC certificate.
>
> _IF_ this policy is enforced in all clients of an organization, then the
> PKI of that organization could constrain accepted realms for KDCs by
> applying name constraints to the dNSName SAN when cross certifying CAs.

I strongly dislike the use of the term "local policy" for both,
(1) an individual and independent client configuration
(2) and an an organization-scoped level.

because (1) is primarily to protect the client
and (2) is primarily to enslave client and enforce organization-level
"policies", and (2) always impairs the real security of the client
in some way.


Name constraints by their very nature are a means for CAs to protect
their business model and restrict the use of specific certs to specific
scenarios.  This might protect the CA from certain liabilities and
misappropriation of specific certs.  But it is entirely up to the CA
to add extensions to individual certs, and a model where the client
security relies on a CA never ever issuing a single cert without
a particular set of extensions is IMHO completely broken.


(Name) constraints don't really protect a client, however.
One may conceive such extensions as "security features" if the client
software offer only a very a primitive trust configurability, but
it really isn't (a security feature).

It is entirely up to the CA to add any such extension to every single
certificate they issue, and only one of the trusted CAs has issued
some certs without them in the past, then there is a gaping hole.


A client configuration which enumerates all trusted KDC certs and
their realms is the most secure and most reliable configuration,
the most simple to implement, and it's the configuration that is
the easiest to explain to (novice) admins and end-users, and
(as far as the PKINIT document is concerned) to PKINIT implementors.

-Martin

12