Subject: RE: Do we need KRB5PrincipalName name constraints in PKINIT

From: "Paul Leach" <[email-masked]>
Date: Wed, 7 Sep 2005 10:16:38 -0700

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:[email-masked]] 
Sent: Wednesday, September 07, 2005 6:44 AM
To: Jeffrey Hutzelman
Cc: Stefan Santesson; Liqiang(Larry) Zhu; Nicolas Williams; Paul Leach;
[email-masked]; [email-masked]
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

---

From: "Paul Leach" <[email-masked]>
Date: Wed, 7 Sep 2005 13:11:03 -0700

> From: [email-masked] [mailto:owner-ietf-krb-
> [email-masked]] 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;
> [email-masked]; [email-masked]; Jeffrey Hutzelman
> Subject: RE: Do we need KRB5PrincipalName name constraints in PKINIT
> 
> On Wednesday, September 07, 2005 Paul Leach
<[email-masked]>
> wrote:
> <wg chair hat on>
> 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.

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 20 Sep 2005 22:52:58 +0100

Hi Martin,

Thanks for the interesting thoughts exchange.
I do believe however that you have misunderstood me quite a bit.
I'm not trying to impose a particular management model. I'm just describing one possible model that technically would work.

The purpose is to show HOW you actually can use constraining of dNSName under certain conditions and what those conditions would be.

Many systems and their management models are different and one management model may fit one system or organization but not another.

More comments in-line;

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> [email-masked]] On Behalf Of Martin Rex
> Sent: den 20 september 2005 16:39
> To: Stefan Santesson
> Cc: [email-masked]; Paul Leach; [email-masked]; Liqiang(Larry) Zhu;
> [email-masked]; [email-masked]; [email-masked]
> 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.
> 
[Stefan] The term local policy has been used consistently throughout this discussion (not invented by me) so that's why I used that term. Local policy is used here to describe a policy that is local to an organization or community (administrative domain).

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

[Stefan] The picture of a CA as a detached entity that is driven by how it protects its liability is frequently mentioned in discussions but is a rare case in real life except for some few public CAs who probably never will issue a single KDC certificate. 

An absolute majority of CAs are just a local security service within an organization to support and enforce its authentication framework and its security policies. Liability is not an issue here more than it is for a Kerberos server, a RADIUS server or even a firewall.

As such, name constraints may be an extremely effective management tool for an organization to configure and enforce trust policies at the CA management level.

> 
> (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).
> 
[Stefan] Name constraints may enforce an organizational trust policy. When doing so they protect the users and possibly also the integrity of their clients.

> 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.
> 
[Stefan] This is does not have to be so. Dependent on how you configure client trust policies, you may choose to totally control all trust paths for those clients using a single CA by the means of cross certification.

> 
> 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.
> 
[Stefan] Could be true for some systems and organizations but not for others. One size does not fit all. Sometimes you have to play around with the toolsets you have available to find the most reasonable solution given your threat model. Ruling out use of name constraints is a bit naïve. Those who need it can and will use it, regardless of what PKINIT says. RFC 3280 already give them that capability if they are just a little creative.

My question was if we should give the reader the service to informatively describe how it can be done to support KDC cert validation. Personally I don't really mind which. But I'm willing to help writing it if the WG whishes.

/Stefan

> -Martin