Subject: RE: CONSENSUS CALL: KDC certs part 1

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 30 Aug 2005 11:31:53 +0100

I have no problem with this approach in principle.

However, I have a little problem with "SHOULD use name constraints"

Name constraints is a protective measure by a CA and not by a client.
The client MUST "use" any name constraints present in the validated
path. A CA however only applies name constraints when it is relevant
(When it does not fully control or trust cross certified CAs)

Name constraints in the context of constraining on realm is really only
useful when constraining dNSName SubjAlt name. But use of this SAN isn't
directly specified or recommended in the document. Name constraints is
not a reasonable thing to recommend for most otherName forms such as
KRB5PrincipalName SAN or an SRV_RR SAN.

The reason is that a path validation process must reject a certificate
with a critical name constraints (this extension MUST be critical)
unless it knows how to process matching rules for all constrained name
forms that appears in subsequent certificates. So any path validation
software that does not have explicit name constraints matching rules for
these name forms will have to fail the validation.

I'm a big fan of name constraints, but in the context of this
specification, I would either leave it out or limit to the original
sentence: 

"In addition, name constraints  [RFC 3280] may be applied to constrain
for which realms a CA is allowed to issue KDC certificates"

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-krb-
> [email-masked]] On Behalf Of Liqiang(Larry) Zhu
> Sent: den 30 augusti 2005 03:07
> To: Paul Leach; Jeffrey Hutzelman; Stefan Santesson; Sam Hartman
> Cc: [email-masked]; [email-masked]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
> 
> I support this text.
> 
> -- larry
> 
> -----Original Message-----
> From: Paul Leach
> Sent: Monday, August 29, 2005 6:01 PM
> To: Jeffrey Hutzelman; Liqiang(Larry) Zhu; Stefan Santesson; Sam
Hartman
> Cc: [email-masked]; [email-masked]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
> 
> I'm a little concerned about the vagueness of the second paragraph. As
> Stefan correctly points out, there are lots of ways to configure trust
> securely in a PKI environment. Unfortunately, very few people know
even
> _one_ way.
> 
> One purpose of a security considerations section is to help people
avoid
> common security errors in implementation and deployment. Hence, while
I
> agree that we should allow leeway for people who know what they are
> doing, we should also be more prescriptive for those who don't.
> 
> I would propose this:
> 
> How to validate this authorization is a matter of local policy.
However,
> absent careful consideration of alternatives that provide such
> validation, implementations SHOULD support configuration of specific
> sets of
> intermediate CAs and trust anchors, one of which must be on the KDC
> certificate's certification path [RFC 3280], and SHOULD use name
> constraints  [RFC 3280] to constrain for which realms a CA is
> allowed to issue KDC certificates.
> 
> 
> 
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 30 Aug 2005 11:49:27 -0400

<chair hat off>

> KRB5PrincipalName SAN or an SRV_RR SAN.

... until someone decides that being able to constrain KRB5PrincipalName is 
important enough to get a specification published for that constraint form. 
I can certainly think of some valuable uses for constrants on that SAN:

- an intermediate CA that can issue certs for single-component principals,
  but not for principals with more than one component (i.e. it can issue
  certs to ordinary users but not prvilieged instances or most services)

- an intermediate CA that can issue certs for any instance of a specific
  service or, using the domain-based service name form, certs for a
  specific service and domain running on any host

Yes, such constraints would need to be critical, and that means the 
resulting certs wouldn't work with an acceptor that did not understand the 
constraint form.  For client certs that wouldn't be a big deal.  For a KDC, 
I agree it would be significant, and most sites probably would not want to 
use KDC certs with constraints on KRB5PrincipalName even if that constraint 
form were defined.

> for which realms a CA is allowed to issue KDC certificates"

I do agree this formulation is better.  Name constraints aren't something 
you can decide to use or not at validation time; the decision is made when 
the intermediate CA certificate is issued.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Aug 2005 23:10:54 -0500

> (When it does not fully control or trust cross certified CAs)

PKINIT is a very special PKI application though.  I think the client
really does want to apply/verify name constraints in the cert chain of a
KDC cert because the KDC cert is a like a CA cert and the client has to
talk the KDC.  Otherwise PKINIT clients will need more configuration, in
a large PKI, than just trust anchors.

> directly specified or recommended in the document.

Indeed.  Sadness.

>                                                    Name constraints is

A form of name constraints for KRB5PrincipalName SAN would be reasonable
to use -- if we had one.  Can we add one?  Or would that be too painful?

> these name forms will have to fail the validation.

But such name constraints wouldn't have to be criticial since the one
application they are intended for would be required to check them.

> for which realms a CA is allowed to issue KDC certificates"

Well, before we can argue about"may," "MAY," "SHOULD" or "MUST" we have
to figure out how to apply name constraints to id-pksan.

So, a new problem, though we may punt.  Punting means condemning PKINIT
clients to require more configuration than it would to just solve the
problem, but maybe that's not so bad.  Thoughts?

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 31 Aug 2005 00:33:25 -0400

> a large PKI, than just trust anchors.

I'm afraid you're not making any sense.  The question of whether to pay 
attention to name constraints is not up to us, or to the PKINIT client. 
The name constraints extension MUST be critical, and verifiers MUST check 
them.  These requirements come from RFC3280.

The problem here is much simpler than folks are making it out to be. 
Stefan's original text suggests that a CA MAY wish to use name constraints 
when issuing certificates to intermediates which certify PKINIT KDC's. 
Larry's version makes it sound like this is something for the client to 
decide, which it is not.  The use of name constraints is solely at the 
descretion of the issuer of an intermediate CA certificate; if they are 
present they MUST be checked, and if not, well, there's nothing to check.

> to use -- if we had one.  Can we add one?  Or would that be too painful?

This question was raised once before, and the conclusion was that it did 
not need to be done as part of the core PKINIT document.  Personally, I 
would like to see a document describing a name constraint form for 
KRB5PrincipalName.  Preferably this would be written by someone with enough 
experience in both the Kerberos and PKI communities to know what sorts of 
restrictions are likely to be useful in Kerberos, and how best to encode 
them in a constraint.  Any volunteers?

> application they are intended for would be required to check them.

Again, I don't think you're making sense here.  But it doesn't matter; name 
constraints are always REQUIRED to be critical.

> to figure out how to apply name constraints to id-pksan.

We're not arguing about MAY vs SHOULD.

The sentence quoted about says CA's MAY include name constraints in 
intermediate certs they issue, which is true whether we say it or not.

The sentence Stefan was objecting to says clients SHOULD apply name 
constraints, which is in direct conflict with RFC3280, which says that 
clients MUST apply name constraints if they are present.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Aug 2005 01:14:31 -0500

> them.  These requirements come from RFC3280.

I misread something Stefan wrote.  But we still have the problem that we
either can't apply name constraints to id-pksan or we have to explain
how.  Looking at RFC3280 it does seem like we could specify how to apply
name constraints to id-pksan.