Subject: RE: CONSENSUS CALL: KDC certs part 1

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

Larry,

I'm afraid your text is not a correct description of the issue at hand.

The point that I was trying to make is that checking "id-pksan SAN
and/or the presence of the id-pkkdcekuoid EKU as described in Section
3.2.4" ONLY provides you with any useful information IF you first has
determined that the KDC certificate is issued by an authorized CA.

The reverse is also true, that is, once you have determined that the
certificate is issued by an appropriate CA you may not have to check
anything else (referred to as local policy). That could be the case e.g.
if you only recognize and accept just one specific authorized CA which
sole purpose to issue a certificate to the KDC.

Stefan Santesson 
Program Manager, Standards Liaison 
Windows Security 

________________________________

From: Liqiang(Larry) Zhu 
Sent: den 26 augusti 2005 20:24
To: Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
Cc: Paul Leach; [email-masked]; [email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

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 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: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 26 Aug 2005 16:08:47 -0400

> I'm afraid your text is not a correct description of the issue at hand.

Actually, I think Larry's text does correctly describe the problem; it's 
just not as clear as yours.  Remove the "for example..." and I think you'll 
see what I mean.

<wg chair hat off>

I think I prefer your text, but with the two one-word changes Larry 
suggested (s/determine/verify/ and s/purpose/realm/).  I don't object to 
adding the "without a priori knowledge" exception, which basically covers a 
pre-shared KDC certificate, but I also don't object to leaving it out.

-- Jeff