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

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 9 Sep 2005 20:20:06 +0100

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;
> [email-masked]; [email-masked]
> Subject: RE: Do we need KRB5PrincipalName name constraints in PKINIT
> 
> 
> 
> > -----Original Message-----
> > 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>
> >
> > > 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.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Sep 2005 15:43:46 -0400

>>>>> "Stefan" == Stefan Santesson <[email-masked]> 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.