Subject: RE: CONSENSUS CALL: KDC certs part 1

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 26 Aug 2005 17:25:44 +0100

Jeff,

I recall that I was requested to suggest some wording on the need to
determine/limit the number of CAs trusted to issue kdc certificates,
which is a fundamental assumption for this protocol.

A first try at this would be:

"A client MUST determine that any KDC certificate it accepts is issued
by a CA that is authorized to issue KDC certificates for the intended
purpose. The means to implement and enforce such policy is outside the
scope of this standard but all mechanisms of this standard depend on the
condition that this has been done appropriately."

I'm not sure whether such statement is best suited in the security
considerations section or in the body of the standard.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]]
> Sent: den 10 augusti 2005 19:18
> To: Sam Hartman
> Cc: Paul Leach; [email-masked]; Liqiang(Larry) Zhu; ietf-krb-
> [email-masked]; Stefan Santesson
> Subject: CONSENSUS CALL: KDC certs part 1
> 
> 
> 
> On Monday, August 01, 2005 15:53:36 +0200 Jeffrey Hutzelman
> <[email-masked]>
> wrote:
> 
> >>> 1) Is this cert appropriate to use as a pkinit cert
> >>>
> >>> 2) Does this cert refer to the KDC who I as a client want to talk
to.
> >>
> >> Here are some possible tests for question (1):
> >> (a) Correct TGS principal name in id-pksan(*)
> >> (b) Presence of id-pkkdcekuoid
> >> (c) Local policy
> >>
> >> Here are some possible tests for question (2):
> >> (a) Correct TGS principal name in id-pksan
> >> (b) Realm name in dnsName SAN
> >> (c) Stefan's SRV RR SAN
> >> (d) Realm name in CN
> >> (e) Local policy
> 
> 
> > The sense of the room was that my statement of the problem was
correct,
> > as was my interpretation of the language in PKINIT-26 (and now,
-27).
> >
> > No one proposed adding any tests which are not already described in
-27.
> > And, no one disagreed that the 1a/2a test combination should be
REQUIRED
> > for clients to implement.
> 
> This means that for question 2, the only specified tests are and will
> continue to be 2a and 2e.  For question 1, test 1a is clearly
permitted;
> resolution of which of tests 1b and 1c to permit in what circumstances
is
> unresolved.  The REQUIRED tests are 1a and 2a.
> 
> This is a consensus call to validate the above decisions as made
during
> the
> working group meeting.  Please comment on whether you agree or
disagree
> with the above decisions.  Note that the EKU issue is still
outstanding
> and
> will be handled separately.
> 
> -- Jeff

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 26 Aug 2005 11:24:13 -0700

I suggest to limit the scope and spell out the consequence in plain english. This issue is not applicable to preshared KDC certificates.
 
s/determine/verify/
s/purpose/realm/

"If a client accepts a certificate as a KDC certificate of the target realm without a priori knowledge, for example by using id-pksan SAN and/or the presence of the id-pkkdcekuoid EKU as described in Section 3.2.4, it MUST verify  that the KDC certificate's CA is authorized to issue KDC certificates for the target realm. Otherwise, the binding between the KDC certificate and the KDC of the target realm is not established. The means how to authenticate and authorize a CA for such purpose is outside the scope of this specification."
 
I propose to add this text into the security consideration section.
 
-- Larry

________________________________

From: Stefan Santesson
Sent: Fri 8/26/2005 9:25 AM
To: Jeffrey Hutzelman; Sam Hartman
Cc: Paul Leach; [email-masked]; Liqiang(Larry) Zhu; [email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

Jeff, 

I recall that I was requested to suggest some wording on the need to determine/limit the number of CAs trusted to issue kdc certificates, which is a fundamental assumption for this protocol.

"A client MUST determine that any KDC certificate it accepts is issued by a CA that is authorized to issue KDC certificates for the intended purpose. The means to implement and enforce such policy is outside the scope of this standard but all mechanisms of this standard depend on the condition that this has been done appropriately."

I'm not sure whether such statement is best suited in the security considerations section or in the body of the standard.

Stefan Santesson 

> >>> 2) Does this cert refer to the KDC who I as a client want to talk to. 
> >> 
> > The sense of the room was that my statement of the problem was correct, 
> > as was my interpretation of the language in PKINIT-26 (and now, -27). 
> > 
> > No one proposed adding any tests which are not already described in -27. 
> > And, no one disagreed that the 1a/2a test combination should be REQUIRED 
> continue to be 2a and 2e.  For question 1, test 1a is clearly permitted; 
> resolution of which of tests 1b and 1c to permit in what circumstances is 
> This is a consensus call to validate the above decisions as made during 
> the 
> working group meeting.  Please comment on whether you agree or disagree 
> with the above decisions.  Note that the EKU issue is still outstanding 
> and