Subject: RE: CONSENSUS CALL: KDC certs part 1

From: "Paul Leach" <[email-masked]>
Date: Thu, 1 Sep 2005 16:04:17 -0700

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-krb-
> [email-masked]] On Behalf Of Jeffrey Hutzelman
> Sent: Thursday, September 01, 2005 1:23 PM
> To: Paul Leach; Liqiang(Larry) Zhu; Stefan Santesson; Sam Hartman
> Cc: [email-masked]; [email-masked]; Jeffrey Hutzelman
> Subject: RE: CONSENSUS CALL: KDC certs part 1
> 
> Speaking mostly without the chair hat...
> 
> On Thursday, September 01, 2005 12:30:57 -0700 Paul Leach
> <[email-masked]> wrote:
> 
> These two paragraphs appear to say almost the same thing in slightly
> different ways:
> 
> > In addition, if any CA is trusted to issue KDC certificates can also
> > issue other kinds of certificates, then local policy must be able to
> > distinguish between them: for example, it could require that KDC
> > certificates contain the id-pkkdcekuoid EKU or that the realm be
> > specified with the id-pksan SAN.
> 
> > If any CA can issue certificates for both KDCs and other purposes,
then
> > it must guarantee that the two kinds can be differentiated. To do
this,
> > it could either issue certificates containing the id-pkkdcekuoid
EKU, or
> > specify the realm using the id-pksan SAN. (Other means of doing this
may
> > exist in the future and would also be acceptable.)
> 
> I think only one of these is needed, and I prefer the latter.
[Paul Leach] The former is about what the client has to do, and the
latter about what the PKI admins have to do. Note that even though you
juxtaposed these here, they are separated by several paragraphs in the
proposed text.

> 
> 
> > If there is more than one CA that can issue KDC certificates, and
the
> > organizations running those CAs do not fully trust one another, then
> > name constraints [RFC 3280] should be used to limit the realms for
which
> > each CA can issue KDC certificates. This will reduce the reliance on
> > local policy being correct in this regard. (Note: currently, name
> > constraints can only be used with the dNSName SAN, because only for
it
> > are name constraint matching rules defined at the time of writing.)
> 
> <chair hat on>
> To date, the only name type called out explicitly by PKINIT for KDC
certs
> is the KRB5PrincipalName SAN, for which name constraint semantics are
not
> defined.  There is an open consensus call on the question of whether
other
> name forms should be specified, and dNSName was one of those
postulated.
> My presumption in issuing that call was that the consensus would be
that
> no
> other name forms needed to be specified; if you disagree with that
> presumption you need to make that clear so we can talk about it.
> </chair hat on>
[Paul Leach] I missed that. Are other name forms allowed (by local
policy, I would guess).

> 
> If we do decide to specify use of dNSName, your Note should be amended
to
> indicate that it is the only form _of those specified for use with
PKINIT_
> for which name constraints are defined.
[Paul Leach] Agreed.
> 
> If we do not decide to specify use of dNSName, then even that
statement
> would not be true.  I would suggest that in this case, the Note should
not
> mention the use of dNSName, since that would not be specified.
Instead,
> it
> would have to make some note about name constraints not currently
being
> defined for KRB5DNSName, and that constraints would thus only be
suitable
> for name forms for which a local policy was in place.
> 
> Or, we could instead specify that there must be _some_ means of
> distinguishing which CA's are authorized for which realms, and perhaps
> mention name constraints as one way of doing this.
[Paul Leach] If other names forms are allowed, even if only by local
policy, then I would want a proper security considerations section to
mention the security considerations that would apply when using such
name forms.

> 
> 
> > In addition, CAs that the PKI administration does not trust to issue
KDC
> > certificates should be constrained from issuing certificates
containing
> > the id-pkkdcekuoid EKU or the id-pksan SAN.
> 
> Can you constrain a CA from issuing a particular SAN type?  How?
[Paul Leach] Not sure -- perhaps only by specify name constraint
matching rules for the name type (as implied by you below). I was hoping
that if I'd made a PKI mistake here that Stefan would step in and
elucidate.

> 
> Also, I don't believe this is good advice.  CA's which are trusted to
> issue
> client certs but not KDC certs should still be permitted to issue the
> id-pksan SAN.  They simply should not be configured to be treated by
> clients as trust anchors for KDC certs.  If you believe this is
> insufficient, then perhaps we do need to define the name constraint
> semantics, so it is possible to allow a CA to issue client certs while
> constraining it from issuing KDC certs.
[Paul Leach] I believe it to be insufficient, in the sense of less than
optimally robust. Such worries were why (as far as I can see) name
constraints (and EKU constraints) were invented for other name types.

---

From: "Paul Leach" <[email-masked]>
Date: Thu, 1 Sep 2005 19:01:54 -0700

That's all I've been asking for, too.

> [email-masked]] On Behalf Of Nicolas Williams
> Sent: Thursday, September 01, 2005 6:40 PM
> To: Timothy Hahn
> Cc: [email-masked]
> Subject: Re: CONSENSUS CALL: KDC certs part 1
> 
> On Thu, Sep 01, 2005 at 08:47:38AM -0400, Timothy Hahn wrote:
> > Nico,
> >
> > I would encourage the workgroup to include a non-normative example
of
> how
> > to implement a "local policy".
> 
> Non-normative, sure.
[Paul Leach] Just to be clear, that's all I've been asking for, too.
Otherwise, it's just too easy to get it wrong, and we'll end up with
lots of insecure implementations.

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 2 Sep 2005 13:45:43 +0100

I'll have a go at describing an example of a local policy that hopefully
shows how local policy at client side can enable an organization to
control trust through its PKI administration (including name
constraining).

This is not intended as a text proposal, just a scenario description.

In this example, company A enforces trust in KDC certificates through
configuring their clients to require a specific intermediary CA to be
part of the certification path. Company A also use cross certification
and name constraints to control trust in external KDCs. Since name
constraints is only available for dNSName at this stage they enforce
presence of dNSName SAN through local policy and its consistency with
realm name.

Client local policy algorithm steps deployed at company A:
1) Verify the cert path and verify that one of the required intermediary
CAs is present in the path.
2) Verify that the KDC certificate contains either the pkinit EKU or the
krb5principal SAN.
3) Verify that the KDC certificate has a dNSName SAN containing a DNS
name that is consistent with the realm name claimed by the KDC.

PKI structure for company A designed to support the client local policy:
1) An intermediary CA is created/appointed as the CA that client local
policy requires to be present in any KDC cert path.
2) A KDC certificate is issued from a local CA that chains through the
required intermediary CA. This certificate contains the Kerberos EKU and
a dNSName consistent with the local realm.
3) Cross certificates for other KDC CAs are issued, including name
constraints (where applicable) on dNSName consistent with the realm each
external CA is trusted to represent.

Company A has now, with a combination of local policy AND PKI
configuration ensured that local trust in KDC certificates is
appropriately enforced.

Name constraining and chaining through the appointed intermediary CA is
implemented only as a local trust configuration for clients at company
A. Other companies participating in the same structure can define their
local policy independent of company A.

Through this local policy, the PKI administrators can dynamically
control clients trust in KDC certificates through the way they issue
cross certificates with or without name constraints. Clients do not need
to be aware of this. They only process path validation according to RFC
3280.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> [email-masked]] On Behalf Of Paul Leach
> Sent: den 2 september 2005 04:02
> To: Nicolas Williams; Timothy Hahn
> Cc: [email-masked]

---

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

In line;

Stefan Santesson

> From: Nicolas Williams [mailto:[email-masked]]
> Sent: den 2 september 2005 21:12
> To: Paul Leach
> Cc: Liqiang(Larry) Zhu; Jeffrey Hutzelman; Stefan Santesson; Sam
Hartman;
> [email-masked]; [email-masked]
> On Thu, Sep 01, 2005 at 06:15:57PM -0700, Paul Leach wrote:
> > > From: Nicolas Williams [mailto:[email-masked]]
> > > Sent: Wednesday, August 31, 2005 8:43 PM
> > >
> > > On Wed, Aug 31, 2005 at 08:28:30PM -0700, Liqiang(Larry) Zhu
wrote:
> > > > We do need to describe "a" way how to implement this policy in
the
> > > > security consideration section.
> > >
> > > Since all such ways, short of name constrainsts or directories,
pretty
> > > much amount to "local policy" I do think that "local policy" is
> > enough,
> > [Paul Leach] I'll note that "local policy" could mean two things:
client
> > (or server) local policy (which is what I usually think of) and
> > organization local policy (which is where I would categorize setting
of
> > name constraints on issued certificates by an org's PKI admins).
Making
> > it clear of which kind one is speaking will usually help people to
> > understand.
> 
> I've been taking "local policy" to mean policy that is local to a
> device -- name constraints in certificates do not qualify as local
> policy.  I would expect the WG to specify any form of policy might
> impact interoperability, thus a non-normative example of local policy
> using tables is fine, but anything to do with certificate extensions
> (which name constraints are) would have to be specified in a normative
> way.
> 

[Stefan] I agree that local policy in the context of PKINIT relates to
local client policies. However local client policies may enable use of
name constraints, which I tried to show in my scenario example.

I don't understand why an example that has anything to do with a
certificate extension have to be normative. Can you explain? 

> > > though we could also include a model of local policy (kinda like
> > > RFC2401bis has an ASN.1 model of the SPD).  While the latter would
be
> > > nice I don't think we have to do it (anymore than we have to
specify
> > > name constraints matching for KRB5Principal).
> > [Paul Leach] Given that improper implementation of the "local
policy" of
> > either kind can easily render a deployment of PKINIT totally
insecure, I
> > think that providing a model of the kind you describe is more than
just
> > a "nice to have".
> 
> Ok.
> 
> > I also think that if we're going to specify a new SAN form, then we
have
> > an obligation to define the name constraint matching rules, since
not
> > having them makes it more difficult to secure certain scenarios.
> 
> I agree.  Does RFC3280 (or any other PKIX RFC or BCP ) recommend or
> require that name constraints be defined for new SANs?
> 
[Stefan] No, but unless you define name constraints matching rules for
new name forms, you can't apply name constraints to them.

> Nico
> --

---

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

I think the text below is correct and adequate up to the point starting
with "This leads to the following considerations"

I think the rest could be deleted.
I'll comment on the rest in-line,

Stefan Santesson

> From: Paul Leach
> Sent: den 1 september 2005 12:31
> To: Liqiang(Larry) Zhu; Stefan Santesson; Jeffrey Hutzelman; Sam
Hartman
> Cc: [email-masked]; [email-masked]
> I propose the following text, which I think meets everyone's
fundamental
> objections (but which of course might have errors):
> =====================================================
> There are two sets of security considerations relevant to PKINIT: one
for
> the client and one for the administrators of the PKI for an
organization.
> 
> In order to trust a KDC certificate that is certified by a CA as a KDC
> certificate for a target ream (for example, by asserting the TGS name
of
> that Kerberos realm as an id-pksan SAN and/or restricting the
certificate
> usage by using the id-pkkdcekuoid EKU, as described in Section 3.2.4),
the
> client MUST verify that the KDC certificate's issuing CA is authorized
to
> issue KDC certificates for that target realm.  Otherwise, the binding
> between the KDC certificate and the KDC of the target realm is not
> established.
> 
> How to validate this authorization is a matter of local policy. A way
to
> achieve this is the configuration of specific sets of intermediary CAs
and
> trust anchors, one of which must be on the KDC certificate's
certification
> path [RFC 3280]; and for each CA or trust anchor the realms for which
it
> is allowed to issue certificates.
> 
issue
> other kinds of certificates, then local policy must be able to
distinguish
> between them: for example, it could require that KDC certificates
contain
> the id-pkkdcekuoid EKU or that the realm be specified with the
id-pksan
> SAN.
> 
> It is the responsibility of the PKI administrators for an organization
to
> ensure that KDC certificates are only issued to KDCs, and that clients
can
> ascertain this using their local policy. This leads to the following
> considerations.
> 
> If there is more than one CA that can issue KDC certificates, and the
name
> constraints [RFC 3280] should be used to limit the realms for which
each
> CA can issue KDC certificates.

[Stefan] I agree with Jeff that this has nothing to do with how many CAs
that can issue KDC certificates or whether these CAs trust each other or
not. Each organization can administer trust in KDC CAs independently and
constraining trust in locally cross certified CAs can be done in many
ways.

> This will reduce the reliance on local
> policy being correct in this regard. (Note: currently, name
constraints
> can only be used with the dNSName SAN, because only for it are name
> constraint matching rules defined at the time of writing.)
> 

[Stefan] This is the point. It is hard to say that you should constrain
on realm without providing an example of how that can be done. The use
case in my previous mail to the list intends to show such example, but
in absence of such example this guidance is confusing.

> If any CA can issue certificates for both KDCs and other purposes,
then it
> must guarantee that the two kinds can be differentiated. To do this,
it
> could either issue certificates containing the id-pkkdcekuoid EKU, or
may
> exist in the future and would also be acceptable.)

[Stefan] this is a repetition of statements above in the section
starting with " In addition, if any CA..."

KDC
containing
> the id-pkkdcekuoid EKU or the id-pksan SAN.

[Stefan] This is not possible. There are no EKU constraining mechanisms
and no defined way to specify constraints on id-pksan that would have
this effect.

> Finally, local policy should only configure a trust anchor for KDC
> certificate issuance if the administrators of that anchor observe the
> above considerations.

[Stefan] Since I express disbelief in the considerations above for CAs I
don't believe this is feasible. Further, Root certificates are not
capable of specifying constraining mechanism since no extensions from
root certificate are enforced in RFC 3280 or X.509 path validation.

> ====================================================
> The above text would be improved by giving an example of how to
constrain
> CAs not trusted by the PLI admins to issue KDC certs from doing so.
> 
> Comments?
> 
> 
> 
> 
> 
> 
>

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sat, 10 Sep 2005 14:09:20 -0700

Thanks Paul for providing the fine text below, if no one objects, I will
include the following into -28.

------------------------------------------
In order to trust a KDC certificate that is certified by a CA as a KDC
certificate for a target ream (for example, by asserting the TGS name of
that Kerberos realm as an id-pksan SAN and/or restricting the
certificate usage by using the id-pkkdcekuoid EKU, as described in
Section 3.2.4), the client MUST verify that the KDC certificate's
issuing CA is authorized to issue KDC certificates for that target
realm.  Otherwise, the binding between the KDC certificate and the KDC
of the target realm is not established.

How to validate this authorization is a matter of local policy. A way to
achieve this is the configuration of specific sets of intermediary CAs
and trust anchors, one of which must be on the KDC certificate's
certification path [RFC 3280]; and for each CA or trust anchor the
realms for which it is allowed to issue certificates.

It is the responsibility of the PKI administrators for an organization
to ensure that KDC certificates are only issued to KDCs, and that
clients can ascertain this using their local policy.
----------------------------------------

Paul Leach wrote:

> The first order question here is whether a security considerations
section 
> of an RFC defining how to use certificates to authenticate AS_REQs
should > contain advice to an organization's PKI administrators on at
least one way 
> that they can securely set up their organization's PKI for that
purpose.

It does contain such advice, but I assume it is out of scope for this
document to specify how organizations can set up their PKI securely. It
would be confusing, as Stefan pointed out, to describe a way that is
technically inaccurate. 

If you provide a detailed solution to a specific scenario, that scenario
has to be generic enough to be useful for implementers and
administrators. It can not be too specific to one particular
organization's deployment environment. In other words, I am not
enthusiastic about including a case study into a RFC that is on the
standards track.
 
We only provide considerations, in our best intent, that likely lead to
secure deployments but we do not attempt to describe a solution for
every deployment issue, if either the issue or the solution is not
generic enough. 

> If in fact the consensus is that we should not provide such 
> considerations, then I will desist (or ask the Security AD for his > 
> opinion).

We do provide such consideration; the question is whether the
consideration we already provided is sufficient. Is that more accurate?

> It seems I have not been successful at stating to people's
satisfaction 
> what > those considerations should be, but I don't think that the
solution 
> is to > 
> remove any and all such considerations.

We should ask ourselves if the PKINIT RFC should provide a non-normative
solution for a non-generic scenario, I argue that is harmful instead of
useful; and whether the PKINIT RFC should address all deployment issues,
I argue that is infeasible and inappropriate.

So all this boils to a judgment call, Stefan and I made the call not to
include a case study.  

We have to recognize that not all solution to the deployment issues can
be or should be standardized.

> But until then, I'm going to keep trying to take everyone's objections

> into account and to provide better text.

Well Stefan provided detailed objections to the reminder of your
original text in the email dated as "Friday, September 09, 2005 12:02
PM". Can you address those comments to his satisfaction?

-----Original Message-----
From: Paul Leach 
Sent: Friday, September 09, 2005 6:19 PM
To: Stefan Santesson; Liqiang(Larry) Zhu; 'Jeffrey Hutzelman'; 'Sam
Hartman'
Cc: [email-masked]'; [email-masked]'
Subject: RE: CONSENSUS CALL: KDC certs part 1

Lets step back a bit.

The first order question here is whether a security considerations
section of an RFC defining how to use certificates to authenticate
AS_REQs should contain advice to an organization's PKI administrators on
at least one way that they can securely set up their organization's PKI
for that purpose.

It seems I have not been successful at stating to people's satisfaction
what those considerations should be, but I don't think that the solution
is to remove any and all such considerations.

If in fact the consensus is that we should not provide such
considerations, then I will desist (or ask the Security AD for his
opinion). 

But until then, I'm going to keep trying to take everyone's objections
into account and to provide better text.

> From: Stefan Santesson
> Sent: Friday, September 09, 2005 12:02 PM
> To: Paul Leach; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman