RE: CONSENSUS CALL: KDC certs part 1

classic Classic list List threaded Threaded
70 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Stefan Santesson
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:[hidden email]]
> Sent: den 10 augusti 2005 19:18
> To: Sam Hartman
> Cc: Paul Leach; [hidden email]; Liqiang(Larry) Zhu; ietf-krb-
> [hidden email]; Stefan Santesson
> Subject: CONSENSUS CALL: KDC certs part 1
>
>
>
> On Monday, August 01, 2005 15:53:36 +0200 Jeffrey Hutzelman
> <[hidden email]>
> 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

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Larry Zhu
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; [hidden email]; Liqiang(Larry) Zhu; [hidden email]
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 [[hidden email]]
> Sent: den 10 augusti 2005 19:18
> To: Sam Hartman
> Cc: Paul Leach; [hidden email]; Liqiang(Larry) Zhu; ietf-krb-
> [hidden email]; Stefan Santesson
> Subject: CONSENSUS CALL: KDC certs part 1
>
>
>
> On Monday, August 01, 2005 15:53:36 +0200 Jeffrey Hutzelman
> <[hidden email]>
> 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

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Stefan Santesson
In reply to this post by Stefan Santesson
RE: CONSENSUS CALL: KDC certs part 1

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; [hidden email]; [hidden email]
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; [hidden email]; Liqiang(Larry) Zhu; [hidden email]
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 [[hidden email]]
> Sent: den 10 augusti 2005 19:18
> To: Sam Hartman
> Cc: Paul Leach; [hidden email]; Liqiang(Larry) Zhu; ietf-krb-
> [hidden email]; Stefan Santesson
> Subject: CONSENSUS CALL: KDC certs part 1
>
>
>
> On Monday, August 01, 2005 15:53:36 +0200 Jeffrey Hutzelman
> <[hidden email]>
> 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

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Larry Zhu
In reply to this post by Stefan Santesson
RE: CONSENSUS CALL: KDC certs part 1

 

 

what matters most here is that which CA can issue KDC certificates for *which realm*.  Because the keyword “realm” did not appear in your text, I made the clarifications.

 

Stefan Santesson wrote:

 

> 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.

 

By RFC 3280, the CA has to be authorized, without clearly spelling out the Kerberos realm in the text, I failed to see the value added by your text.

 

> 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 keyword “MUST” is less than accurate, because if the KDC certificate is pre-shared, the client does not need do this.

 

That said, please tell me a bit more about why my text is not accurate, or modify your text to address my concerns above.

 

-- Larry


From: Stefan Santesson
Sent: Friday, August 26, 2005 12:18 PM
To: Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
Cc: Paul Leach; [hidden email]; [hidden email]
Subject: RE: CONSENSUS CALL: KDC certs part 1

 

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; [hidden email]; [hidden email]
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; [hidden email]; Liqiang(Larry) Zhu; [hidden email]
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 [[hidden email]]
> Sent: den 10 augusti 2005 19:18
> To: Sam Hartman
> Cc: Paul Leach; [hidden email]; Liqiang(Larry) Zhu; ietf-krb-
> [hidden email]; Stefan Santesson
> Subject: CONSENSUS CALL: KDC certs part 1
>
>
>
> On Monday, August 01, 2005 15:53:36 +0200 Jeffrey Hutzelman
> <[hidden email]>
> 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

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Jeffrey Hutzelman
In reply to this post by Stefan Santesson


On Friday, August 26, 2005 20:17:34 +0100 Stefan Santesson
<[hidden email]> wrote:

> 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

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Larry Zhu
In reply to this post by Stefan Santesson
The word "for example" is used to allude that the same text is
applicable when Stefan's DNS SRV x.509 name form is used, aka, it is not
limited to the existing id-pksan TGS name form.

-- Larry

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jeffrey
Hutzelman
Sent: Friday, August 26, 2005 1:09 PM
To: Stefan Santesson; Liqiang(Larry) Zhu; Sam Hartman
Cc: Paul Leach; [hidden email]; [hidden email]
Subject: RE: CONSENSUS CALL: KDC certs part 1



On Friday, August 26, 2005 20:17:34 +0100 Stefan Santesson
<[hidden email]> wrote:

> 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

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Paul Leach
In reply to this post by Stefan Santesson
RE: CONSENSUS CALL: KDC certs part 1

 

 


From: Stefan Santesson
Sent: Friday, August 26, 2005 12:18 PM
To: Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
Cc: Paul Leach; [hidden email]; [hidden email]
Subject: RE: CONSENSUS CALL: KDC certs part 1

 

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.

[Paul Leach] You mean “trusted” here, don’t you? I.e, that the chain validates to a trusted root?

 

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.

[Paul Leach] That is a form of local policy, isn’t it?

 

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; [hidden email]; [hidden email]
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; [hidden email]; Liqiang(Larry) Zhu; [hidden email]
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 [[hidden email]]
> Sent: den 10 augusti 2005 19:18
> To: Sam Hartman
> Cc: Paul Leach; [hidden email]; Liqiang(Larry) Zhu; ietf-krb-
> [hidden email]; Stefan Santesson
> Subject: CONSENSUS CALL: KDC certs part 1
>
>
>
> On Monday, August 01, 2005 15:53:36 +0200 Jeffrey Hutzelman
> <[hidden email]>
> 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

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Stefan Santesson
In reply to this post by Stefan Santesson
RE: CONSENSUS CALL: KDC certs part 1

Inline;

 

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 


From: Paul Leach
Sent: den 27 augusti 2005 01:07
To: Stefan Santesson; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
Cc: [hidden email]; [hidden email]
Subject: RE: CONSENSUS CALL: KDC certs part 1

 

 

 


From: Stefan Santesson
Sent: Friday, August 26, 2005 12:18 PM
To: Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
Cc: Paul Leach; [hidden email]; [hidden email]
Subject: RE: CONSENSUS CALL: KDC certs part 1

 

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.

[Paul Leach] You mean “trusted” here, don’t you? I.e, that the chain validates to a trusted root?

 

[Stefan] Not necessarily. A client can in principle also configure the trust on a lower level than on the root level. Otherwise I think my wording is equivalent to the concept of trust.

 

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.

[Paul Leach] That is a form of local policy, isn’t it?

 

[Stefan] Yes

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; [hidden email]; [hidden email]
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; [hidden email]; Liqiang(Larry) Zhu; [hidden email]
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 [[hidden email]]
> Sent: den 10 augusti 2005 19:18
> To: Sam Hartman
> Cc: Paul Leach; [hidden email]; Liqiang(Larry) Zhu; ietf-krb-
> [hidden email]; Stefan Santesson
> Subject: CONSENSUS CALL: KDC certs part 1
>
>
>
> On Monday, August 01, 2005 15:53:36 +0200 Jeffrey Hutzelman
> <[hidden email]>
> 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

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Stefan Santesson
In reply to this post by Stefan Santesson
The problem is that I may not understand what problem you mean to solve
and therefore my text may solve the wrong problem.

As PKI expert and not as Kerberos expert, I can't really follow the
logic in Larry's text.

Taking it bit by bit:

>"If a client accepts a certificate as a KDC certificate of the target
realm
>without a priori knowledge,

What is "prior knowledge"? This is not clear to me.

>for example by using id-pksan SAN and/or the presence of the
id-pkkdcekuoid
>EKU as described in Section 3.2.4,

This indicates that the so called "prior knowledge" can be obtained by
examining data in the certificate, but this does not make me understand
what "prior knowledge" means.

>it MUST verify  that the KDC certificate's CA is authorized to issue
KDC
>certificates for the target realm.

This is my main problem. The text at this stage indicates and order of
events where you only need to determine that the CA is authorized "IF"
the "prior knowledge" condition has failed. In practice you must ALLWAYS
determine if the CA is duly authorized/trusted for the purpose you are
using it. This can be done in many ways (such as just chaining to an
appropriate root certificate) but it MUST be done first.

>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."

Minor comment: I don't understand "This means" in the last sentence. It
indicates that the text before explains why it is out of scope while it
doesn't. I agree though that it should be out of scope.


If anyone can better explain what the problem is that we try to solve,
then maybe I can better help crafting some words.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Liqiang(Larry) Zhu
> Sent: den 26 augusti 2005 22:15
> To: Jeffrey Hutzelman; Stefan Santesson; Sam Hartman
> Cc: Paul Leach; [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
> The word "for example" is used to allude that the same text is
applicable
> when Stefan's DNS SRV x.509 name form is used, aka, it is not limited
to

> the existing id-pksan TGS name form.
>
> -- Larry
>
> -----Original Message-----
> From: [hidden email] [mailto:owner-ietf-krb-
> [hidden email]] On Behalf Of Jeffrey Hutzelman
> Sent: Friday, August 26, 2005 1:09 PM
> To: Stefan Santesson; Liqiang(Larry) Zhu; Sam Hartman
> Cc: Paul Leach; [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
>
>
> On Friday, August 26, 2005 20:17:34 +0100 Stefan Santesson
> <[hidden email]> wrote:
>
> > 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

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Paul Leach
In reply to this post by Stefan Santesson
RE: CONSENSUS CALL: KDC certs part 1

If the following text is to go into the security considerations section, then I don’t buy the last line:

 

"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."

 

The security considerations section needs to point out ways in which it is possible to insecurely use a protocol.

 

Some things that people SHOULD do to make sure that KDC are authentic include:

1. Local policy should specify which CAs are allowed to issue KDC certs, and for each one name constraints should define for which realms it is allowed to issue them

2. Keep a list of trust anchors (which may be specific to KDC cert issuance) and validate that the KDC’s leaf cert chains up to a trust anchor.

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Paul Leach
In reply to this post by Stefan Santesson


> -----Original Message-----
> From: Stefan Santesson
> Sent: Friday, August 26, 2005 4:30 PM
> To: Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
> Cc: Paul Leach; [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
> The problem is that I may not understand what problem you mean to
solve
> and therefore my text may solve the wrong problem.
>
> As PKI expert and not as Kerberos expert, I can't really follow the
logic
> in Larry's text.
>
> Taking it bit by bit:
>
> >"If a client accepts a certificate as a KDC certificate of the target
> realm
> >without a priori knowledge,
>
> What is "prior knowledge"? This is not clear to me.
[Paul Leach] It wasn't exactly clear to me, either.
>
> >for example by using id-pksan SAN and/or the presence of the id-
> pkkdcekuoid
> >EKU as described in Section 3.2.4,
>
> This indicates that the so called "prior knowledge" can be obtained by
> examining data in the certificate, but this does not make me
understand
> what "prior knowledge" means.
[Paul Leach] Actually, the opposite -- it is prior knowledge when one
does NOT need to examine the data in the certificate to know that it is
valid for use as a KDC's certificate. Examples of such prior knowledge
would be a configuration setting that had (realm-name, certificate)
pairs, or (realm-name, public-key) pairs, or (realm-name, cert-hash)
pairs.

>
> >it MUST verify  that the KDC certificate's CA is authorized to issue
KDC
> >certificates for the target realm.
>
> This is my main problem. The text at this stage indicates and order of
> events where you only need to determine that the CA is authorized "IF"
the

> "prior knowledge" condition has failed. In practice you must ALLWAYS
> determine if the CA is duly authorized/trusted for the purpose you are
> using it. This can be done in many ways (such as just chaining to an
> appropriate root certificate) but it MUST be done first.
>
> >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."
>
> Minor comment: I don't understand "This means" in the last sentence.
It
> indicates that the text before explains why it is out of scope while
it

> doesn't. I agree though that it should be out of scope.
>
>
> If anyone can better explain what the problem is that we try to solve,
> then maybe I can better help crafting some words.
>
>
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>
>
> > -----Original Message-----
> > From: Liqiang(Larry) Zhu
> > Sent: den 26 augusti 2005 22:15
> > To: Jeffrey Hutzelman; Stefan Santesson; Sam Hartman
> > Cc: Paul Leach; [hidden email]; [hidden email]
> > Subject: RE: CONSENSUS CALL: KDC certs part 1
> >
> > The word "for example" is used to allude that the same text is
> applicable
> > when Stefan's DNS SRV x.509 name form is used, aka, it is not
limited to

> > the existing id-pksan TGS name form.
> >
> > -- Larry
> >
> > -----Original Message-----
> > From: [hidden email] [mailto:owner-ietf-krb-
> > [hidden email]] On Behalf Of Jeffrey Hutzelman
> > Sent: Friday, August 26, 2005 1:09 PM
> > To: Stefan Santesson; Liqiang(Larry) Zhu; Sam Hartman
> > Cc: Paul Leach; [hidden email]; [hidden email]
> > Subject: RE: CONSENSUS CALL: KDC certs part 1
> >
> >
> >
> > On Friday, August 26, 2005 20:17:34 +0100 Stefan Santesson
> > <[hidden email]> wrote:
> >
> > > 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

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Stefan Santesson
In reply to this post by Stefan Santesson
Paul,

I agree. If "prior knowledge" means that you already know that the
certificate you hold is appropriate, then you have already done what I
say you need to do first and you are good.

The example in the text does however not by itself provide such prior
knowledge.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Paul Leach
> Sent: den 27 augusti 2005 02:41
> To: Stefan Santesson; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam
Hartman

> Cc: [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
>
>
> > -----Original Message-----
> > From: Stefan Santesson
> > Sent: Friday, August 26, 2005 4:30 PM
> > To: Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
> > Cc: Paul Leach; [hidden email]; [hidden email]
> > Subject: RE: CONSENSUS CALL: KDC certs part 1
> >
> > The problem is that I may not understand what problem you mean to
solve
> > and therefore my text may solve the wrong problem.
> >
> > As PKI expert and not as Kerberos expert, I can't really follow the
> logic
> > in Larry's text.
> >
> > Taking it bit by bit:
> >
> > >"If a client accepts a certificate as a KDC certificate of the
target

> > realm
> > >without a priori knowledge,
> >
> > What is "prior knowledge"? This is not clear to me.
> [Paul Leach] It wasn't exactly clear to me, either.
> >
> > >for example by using id-pksan SAN and/or the presence of the id-
> > pkkdcekuoid
> > >EKU as described in Section 3.2.4,
> >
> > This indicates that the so called "prior knowledge" can be obtained
by
> > examining data in the certificate, but this does not make me
understand
> > what "prior knowledge" means.
> [Paul Leach] Actually, the opposite -- it is prior knowledge when one
does
> NOT need to examine the data in the certificate to know that it is
valid
> for use as a KDC's certificate. Examples of such prior knowledge would
be
> a configuration setting that had (realm-name, certificate) pairs, or
> (realm-name, public-key) pairs, or (realm-name, cert-hash) pairs.
>
> >
> > >it MUST verify  that the KDC certificate's CA is authorized to
issue
> KDC
> > >certificates for the target realm.
> >
> > This is my main problem. The text at this stage indicates and order
of
> > events where you only need to determine that the CA is authorized
"IF"
> the
> > "prior knowledge" condition has failed. In practice you must ALLWAYS
> > determine if the CA is duly authorized/trusted for the purpose you
are
> > using it. This can be done in many ways (such as just chaining to an
> > appropriate root certificate) but it MUST be done first.
> >
> > >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."
> >
> > Minor comment: I don't understand "This means" in the last sentence.
It
> > indicates that the text before explains why it is out of scope while
it
> > doesn't. I agree though that it should be out of scope.
> >
> >
> > If anyone can better explain what the problem is that we try to
solve,

> > then maybe I can better help crafting some words.
> >
> >
> > Stefan Santesson
> > Program Manager, Standards Liaison
> > Windows Security
> >
> >
> > > -----Original Message-----
> > > From: Liqiang(Larry) Zhu
> > > Sent: den 26 augusti 2005 22:15
> > > To: Jeffrey Hutzelman; Stefan Santesson; Sam Hartman
> > > Cc: Paul Leach; [hidden email]; [hidden email]
> > > Subject: RE: CONSENSUS CALL: KDC certs part 1
> > >
> > > The word "for example" is used to allude that the same text is
> > applicable
> > > when Stefan's DNS SRV x.509 name form is used, aka, it is not
limited

> to
> > > the existing id-pksan TGS name form.
> > >
> > > -- Larry
> > >
> > > -----Original Message-----
> > > From: [hidden email] [mailto:owner-ietf-krb-
> > > [hidden email]] On Behalf Of Jeffrey Hutzelman
> > > Sent: Friday, August 26, 2005 1:09 PM
> > > To: Stefan Santesson; Liqiang(Larry) Zhu; Sam Hartman
> > > Cc: Paul Leach; [hidden email]; [hidden email]
> > > Subject: RE: CONSENSUS CALL: KDC certs part 1
> > >
> > >
> > >
> > > On Friday, August 26, 2005 20:17:34 +0100 Stefan Santesson
> > > <[hidden email]> wrote:
> > >
> > > > 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

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Larry Zhu
In reply to this post by Stefan Santesson
s/prior/a priori/

the later assumes the knowledge is proven/secure.

-----Original Message-----
From: Stefan Santesson
Sent: Friday, August 26, 2005 5:50 PM
To: Paul Leach; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
Cc: [hidden email]; [hidden email]
Subject: RE: CONSENSUS CALL: KDC certs part 1

Paul,

I agree. If "prior knowledge" means that you already know that the
certificate you hold is appropriate, then you have already done what I
say you need to do first and you are good.

The example in the text does however not by itself provide such prior
knowledge.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Paul Leach
> Sent: den 27 augusti 2005 02:41
> To: Stefan Santesson; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam
Hartman

> Cc: [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
>
>
> > -----Original Message-----
> > From: Stefan Santesson
> > Sent: Friday, August 26, 2005 4:30 PM
> > To: Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
> > Cc: Paul Leach; [hidden email]; [hidden email]
> > Subject: RE: CONSENSUS CALL: KDC certs part 1
> >
> > The problem is that I may not understand what problem you mean to
solve
> > and therefore my text may solve the wrong problem.
> >
> > As PKI expert and not as Kerberos expert, I can't really follow the
> logic
> > in Larry's text.
> >
> > Taking it bit by bit:
> >
> > >"If a client accepts a certificate as a KDC certificate of the
target

> > realm
> > >without a priori knowledge,
> >
> > What is "prior knowledge"? This is not clear to me.
> [Paul Leach] It wasn't exactly clear to me, either.
> >
> > >for example by using id-pksan SAN and/or the presence of the id-
> > pkkdcekuoid
> > >EKU as described in Section 3.2.4,
> >
> > This indicates that the so called "prior knowledge" can be obtained
by
> > examining data in the certificate, but this does not make me
understand
> > what "prior knowledge" means.
> [Paul Leach] Actually, the opposite -- it is prior knowledge when one
does
> NOT need to examine the data in the certificate to know that it is
valid
> for use as a KDC's certificate. Examples of such prior knowledge would
be
> a configuration setting that had (realm-name, certificate) pairs, or
> (realm-name, public-key) pairs, or (realm-name, cert-hash) pairs.
>
> >
> > >it MUST verify  that the KDC certificate's CA is authorized to
issue
> KDC
> > >certificates for the target realm.
> >
> > This is my main problem. The text at this stage indicates and order
of
> > events where you only need to determine that the CA is authorized
"IF"
> the
> > "prior knowledge" condition has failed. In practice you must ALLWAYS
> > determine if the CA is duly authorized/trusted for the purpose you
are
> > using it. This can be done in many ways (such as just chaining to an
> > appropriate root certificate) but it MUST be done first.
> >
> > >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."
> >
> > Minor comment: I don't understand "This means" in the last sentence.
It
> > indicates that the text before explains why it is out of scope while
it
> > doesn't. I agree though that it should be out of scope.
> >
> >
> > If anyone can better explain what the problem is that we try to
solve,

> > then maybe I can better help crafting some words.
> >
> >
> > Stefan Santesson
> > Program Manager, Standards Liaison
> > Windows Security
> >
> >
> > > -----Original Message-----
> > > From: Liqiang(Larry) Zhu
> > > Sent: den 26 augusti 2005 22:15
> > > To: Jeffrey Hutzelman; Stefan Santesson; Sam Hartman
> > > Cc: Paul Leach; [hidden email]; [hidden email]
> > > Subject: RE: CONSENSUS CALL: KDC certs part 1
> > >
> > > The word "for example" is used to allude that the same text is
> > applicable
> > > when Stefan's DNS SRV x.509 name form is used, aka, it is not
limited

> to
> > > the existing id-pksan TGS name form.
> > >
> > > -- Larry
> > >
> > > -----Original Message-----
> > > From: [hidden email] [mailto:owner-ietf-krb-
> > > [hidden email]] On Behalf Of Jeffrey Hutzelman
> > > Sent: Friday, August 26, 2005 1:09 PM
> > > To: Stefan Santesson; Liqiang(Larry) Zhu; Sam Hartman
> > > Cc: Paul Leach; [hidden email]; [hidden email]
> > > Subject: RE: CONSENSUS CALL: KDC certs part 1
> > >
> > >
> > >
> > > On Friday, August 26, 2005 20:17:34 +0100 Stefan Santesson
> > > <[hidden email]> wrote:
> > >
> > > > 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

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Paul Leach
In reply to this post by Stefan Santesson


> -----Original Message-----
> From: Stefan Santesson
> Sent: Friday, August 26, 2005 5:50 PM
> To: Paul Leach; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
> Cc: [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
> Paul,
>
> I agree. If "prior knowledge" means that you already know that the
> certificate you hold is appropriate, then you have already done what I
say
> you need to do first and you are good.
[Paul Leach] Prior knowledge can include out-of-band communication --
the certificate contents may not really have been examined at all -- it
was just given to you by someone you trust (like a domain
administrator).

>
> The example in the text does however not by itself provide such prior
> knowledge.
[Paul Leach] As far as I can tell, it wasn't intended to be so. It was
intended to be an example of a case where the authenticity of the CA
needed to be verified.

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Larry Zhu
In reply to this post by Stefan Santesson
Updated with Paul and Stefan's suggestion:

===================================
If the KDC certificate is certified by a CA as a KDC certificate for the target ream (for example, the CA can indicate the certificate is a KDC certificate of a Kerberos realm by asserting the TGS name of that Kerberos realm as id-pksan SAN and/or restricting the certificate usage by using the id-pkkdcekuoid EKU, as described in Section 3.2.4), the KDC certificate's CA MUST be 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. The means by which the client authorizes a CA for such purpose can be one of the following:

1. Local policy can specify which CAs are allowed to issue KDC certificates, and for each one name constraints should define for which realms it is allowed to issue them.

2. The client can keep a list of trust anchors for each Kerberos realm it can contact (this list may be specific to KDC certificate issuance) and validate that the KDC's leaf certificate is path validated [RFC3280] to a trust anchor in the trust anchor list for the target realm.

===================================
Comments?

-- Larry

________________________________________
From: Paul Leach
Sent: Friday, August 26, 2005 5:26 PM
To: Stefan Santesson; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
Cc: [hidden email]; [hidden email]
Subject: RE: CONSENSUS CALL: KDC certs part 1

If the following text is to go into the security considerations section, then I don't buy the last line:

"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."

The security considerations section needs to point out ways in which it is possible to insecurely use a protocol.

Some things that people SHOULD do to make sure that KDC are authentic include:
1. Local policy should specify which CAs are allowed to issue KDC certs, and for each one name constraints should define for which realms it is allowed to issue them
2. Keep a list of trust anchors (which may be specific to KDC cert issuance) and validate that the KDC's leaf cert chains up to a trust anchor.

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Larry Zhu
In reply to this post by Stefan Santesson

Paul suggested the following text after consolidating approach 1 and approach 2.

------------------
   If the KDC's certificate 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 KDC certificate's CA MUST be 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.  

   To achieve this, local policy should specify a set of
   trust anchors for KDC certificates, and the client must verify that
   the KDC's leaf certificate is path validated [RFC3280] to an anchor
   in this set.  Each CA in the certification path between the KDC
   certificate and the trust anchor should have name constraints applied
   to it that specify for which realms it is allowed to issue KDC
   certificates.

------------------

Please comment.

Thanks,

-- Larry


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Liqiang(Larry) Zhu
Sent: Friday, August 26, 2005 6:16 PM
To: Paul Leach; Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
Cc: [hidden email]; [hidden email]
Subject: RE: CONSENSUS CALL: KDC certs part 1

Updated with Paul and Stefan's suggestion:

===================================
If the KDC certificate is certified by a CA as a KDC certificate for the target ream (for example, the CA can indicate the certificate is a KDC certificate of a Kerberos realm by asserting the TGS name of that Kerberos realm as id-pksan SAN and/or restricting the certificate usage by using the id-pkkdcekuoid EKU, as described in Section 3.2.4), the KDC certificate's CA MUST be 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. The means by which the client authorizes a CA for such purpose can be one of the following:

1. Local policy can specify which CAs are allowed to issue KDC certificates, and for each one name constraints should define for which realms it is allowed to issue them.

2. The client can keep a list of trust anchors for each Kerberos realm it can contact (this list may be specific to KDC certificate issuance) and validate that the KDC's leaf certificate is path validated [RFC3280] to a trust anchor in the trust anchor list for the target realm.

===================================
Comments?

-- Larry

________________________________________
From: Paul Leach
Sent: Friday, August 26, 2005 5:26 PM
To: Stefan Santesson; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
Cc: [hidden email]; [hidden email]
Subject: RE: CONSENSUS CALL: KDC certs part 1

If the following text is to go into the security considerations section, then I don't buy the last line:

"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."

The security considerations section needs to point out ways in which it is possible to insecurely use a protocol.

Some things that people SHOULD do to make sure that KDC are authentic include:
1. Local policy should specify which CAs are allowed to issue KDC certs, and for each one name constraints should define for which realms it is allowed to issue them
2. Keep a list of trust anchors (which may be specific to KDC cert issuance) and validate that the KDC's leaf cert chains up to a trust anchor.

Reply | Threaded
Open this post in threaded view
|

Re: CONSENSUS CALL: KDC certs part 1

Love Hörnquist Åstrand

"Liqiang(Larry) Zhu" <[hidden email]> writes:

> Paul suggested the following text after consolidating approach 1 and approach 2.
>
> ------------------
>    If the KDC's certificate 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 KDC certificate's CA MUST be authorized

by local policy

>    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.  
>
>    To achieve this, local policy should specify a set of
>    trust anchors for KDC certificates, and the client must verify that
>    the KDC's leaf certificate is path validated [RFC3280] to an anchor
>    in this set.  Each CA in the certification path between the KDC
>    certificate and the trust anchor should have name constraints applied
>    to it that specify for which realms it is allowed to issue KDC
>    certificates.
Other then that, the text seem fine to me.

Love


>
> ------------------
>
> Please comment.
>
> Thanks,
>
> -- Larry
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Liqiang(Larry) Zhu
> Sent: Friday, August 26, 2005 6:16 PM
> To: Paul Leach; Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
> Cc: [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
> Updated with Paul and Stefan's suggestion:
>
> ===================================
> If the KDC certificate is certified by a CA as a KDC certificate for the target ream (for example, the CA can indicate the certificate is a KDC certificate of a Kerberos realm by asserting the TGS name of that Kerberos realm as id-pksan SAN and/or restricting the certificate usage by using the id-pkkdcekuoid EKU, as described in Section 3.2.4), the KDC certificate's CA MUST be 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. The means by which the client authorizes a CA for such purpose can be one of the following:
>
> 1. Local policy can specify which CAs are allowed to issue KDC certificates, and for each one name constraints should define for which realms it is allowed to issue them.
>
> 2. The client can keep a list of trust anchors for each Kerberos realm it can contact (this list may be specific to KDC certificate issuance) and validate that the KDC's leaf certificate is path validated [RFC3280] to a trust anchor in the trust anchor list for the target realm.
>
> ===================================
> Comments?
>
> -- Larry
>
> ________________________________________
> From: Paul Leach
> Sent: Friday, August 26, 2005 5:26 PM
> To: Stefan Santesson; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
> Cc: [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
> If the following text is to go into the security considerations section, then I don't buy the last line:
>
> "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."
>
> The security considerations section needs to point out ways in which it is possible to insecurely use a protocol.
>
> Some things that people SHOULD do to make sure that KDC are authentic include:
> 1. Local policy should specify which CAs are allowed to issue KDC certs, and for each one name constraints should define for which realms it is allowed to issue them
> 2. Keep a list of trust anchors (which may be specific to KDC cert issuance) and validate that the KDC's leaf cert chains up to a trust anchor.

attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Stefan Santesson
In reply to this post by Stefan Santesson
This is definitely an improvement, but I'm still not satisfied :)

We should not be specific about any requirements on how to configure trust in a particular CA since it can be done in many valid ways.

You definitely do NOT have to have specific trust anchors for KDC certificates and you not have to apply name constraints. And if you apply name constraints it is never applied by all CAs in the path.

A perfectly valid example is if you have the KDC certificate chaining to a more generic root/TA while clients are configured to require a certain KDC specific intermediary CA (under that root/TA) to be present in the path.

I suggest some hopefully minor changes to the text:

"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 determine 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. Typical ways to achieve this is includes configuration of specific sets of trust anchors and intermediary CAs, possibly supported by name constraints, which have to be utilized in the certificate validation process according to RFC 3280."


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Liqiang(Larry) Zhu
> Sent: den 27 augusti 2005 04:58
> To: Paul Leach; Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
> Cc: [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
>
> Paul suggested the following text after consolidating approach 1 and
> approach 2.
>
> ------------------
>    If the KDC's certificate 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 KDC certificate's CA MUST be 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.
>
>    To achieve this, local policy should specify a set of
>    trust anchors for KDC certificates, and the client must verify that
>    the KDC's leaf certificate is path validated [RFC3280] to an anchor
>    in this set.  Each CA in the certification path between the KDC
>    certificate and the trust anchor should have name constraints applied
>    to it that specify for which realms it is allowed to issue KDC
>    certificates.
>
> ------------------
>
> Please comment.
>
> Thanks,
>
> -- Larry
>
>
> -----Original Message-----
> From: [hidden email] [mailto:owner-ietf-krb-
> [hidden email]] On Behalf Of Liqiang(Larry) Zhu
> Sent: Friday, August 26, 2005 6:16 PM
> To: Paul Leach; Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
> Cc: [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
> Updated with Paul and Stefan's suggestion:
>
> ===================================
> If the KDC certificate is certified by a CA as a KDC certificate for the
> target ream (for example, the CA can indicate the certificate is a KDC
> certificate of a Kerberos realm by asserting the TGS name of that Kerberos
> realm as id-pksan SAN and/or restricting the certificate usage by using
> the id-pkkdcekuoid EKU, as described in Section 3.2.4), the KDC
> certificate's CA MUST be 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. The means by which the client
> authorizes a CA for such purpose can be one of the following:
>
> 1. Local policy can specify which CAs are allowed to issue KDC
> certificates, and for each one name constraints should define for which
> realms it is allowed to issue them.
>
> 2. The client can keep a list of trust anchors for each Kerberos realm it
> can contact (this list may be specific to KDC certificate issuance) and
> validate that the KDC's leaf certificate is path validated [RFC3280] to a
> trust anchor in the trust anchor list for the target realm.
>
> ===================================
> Comments?
>
> -- Larry
>
> ________________________________________
> From: Paul Leach
> Sent: Friday, August 26, 2005 5:26 PM
> To: Stefan Santesson; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
> Cc: [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
> If the following text is to go into the security considerations section,
> then I don't buy the last line:
>
> "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."
>
> The security considerations section needs to point out ways in which it is
> possible to insecurely use a protocol.
>
> Some things that people SHOULD do to make sure that KDC are authentic
> include:
> 1. Local policy should specify which CAs are allowed to issue KDC certs,
> and for each one name constraints should define for which realms it is
> allowed to issue them
> 2. Keep a list of trust anchors (which may be specific to KDC cert
> issuance) and validate that the KDC's leaf cert chains up to a trust
> anchor.

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Larry Zhu
In reply to this post by Stefan Santesson

s/determine/verify/

I also would like to make this understandable by Kerberos developers, not just target at PKI experts.

----------------------

"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. Typical ways to achieve this is includes configuration of specific sets of intermediary CAs and trust anchors, one of which must be on KDC certificate's certification path [RFC 3280]. In addition, name constraints [RFC 3280] may be applied that specify for which realms a CA is allowed to issue KDC certificates."

--------------------

This text is very explicit and plain about what is the requirements; can you help to verify if I have fixed all inaccuracies you pointed out below?

Thanks,

-- larry

-----Original Message-----
From: Stefan Santesson
Sent: Saturday, August 27, 2005 2:51 AM
To: Liqiang(Larry) Zhu; Paul Leach; Jeffrey Hutzelman; Sam Hartman
Cc: [hidden email]; [hidden email]
Subject: RE: CONSENSUS CALL: KDC certs part 1

This is definitely an improvement, but I'm still not satisfied :)

We should not be specific about any requirements on how to configure trust in a particular CA since it can be done in many valid ways.

You definitely do NOT have to have specific trust anchors for KDC certificates and you not have to apply name constraints. And if you apply name constraints it is never applied by all CAs in the path.

A perfectly valid example is if you have the KDC certificate chaining to a more generic root/TA while clients are configured to require a certain KDC specific intermediary CA (under that root/TA) to be present in the path.

I suggest some hopefully minor changes to the text:

"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 determine 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. Typical ways to achieve this is includes configuration of specific sets of trust anchors and intermediary CAs, possibly supported by name constraints, which have to be utilized in the certificate validation process according to RFC 3280."


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Liqiang(Larry) Zhu
> Sent: den 27 augusti 2005 04:58
> To: Paul Leach; Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
> Cc: [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
>
> Paul suggested the following text after consolidating approach 1 and
> approach 2.
>
> ------------------
>    If the KDC's certificate 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 KDC certificate's CA MUST be 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.
>
>    To achieve this, local policy should specify a set of
>    trust anchors for KDC certificates, and the client must verify that
>    the KDC's leaf certificate is path validated [RFC3280] to an anchor
>    in this set.  Each CA in the certification path between the KDC
>    certificate and the trust anchor should have name constraints applied
>    to it that specify for which realms it is allowed to issue KDC
>    certificates.
>
> ------------------
>
> Please comment.
>
> Thanks,
>
> -- Larry
>
>
> -----Original Message-----
> From: [hidden email] [mailto:owner-ietf-krb-
> [hidden email]] On Behalf Of Liqiang(Larry) Zhu
> Sent: Friday, August 26, 2005 6:16 PM
> To: Paul Leach; Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
> Cc: [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
> Updated with Paul and Stefan's suggestion:
>
> ===================================
> If the KDC certificate is certified by a CA as a KDC certificate for the
> target ream (for example, the CA can indicate the certificate is a KDC
> certificate of a Kerberos realm by asserting the TGS name of that Kerberos
> realm as id-pksan SAN and/or restricting the certificate usage by using
> the id-pkkdcekuoid EKU, as described in Section 3.2.4), the KDC
> certificate's CA MUST be 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. The means by which the client
> authorizes a CA for such purpose can be one of the following:
>
> 1. Local policy can specify which CAs are allowed to issue KDC
> certificates, and for each one name constraints should define for which
> realms it is allowed to issue them.
>
> 2. The client can keep a list of trust anchors for each Kerberos realm it
> can contact (this list may be specific to KDC certificate issuance) and
> validate that the KDC's leaf certificate is path validated [RFC3280] to a
> trust anchor in the trust anchor list for the target realm.
>
> ===================================
> Comments?
>
> -- Larry
>
> ________________________________________
> From: Paul Leach
> Sent: Friday, August 26, 2005 5:26 PM
> To: Stefan Santesson; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
> Cc: [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
> If the following text is to go into the security considerations section,
> then I don't buy the last line:
>
> "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."
>
> The security considerations section needs to point out ways in which it is
> possible to insecurely use a protocol.
>
> Some things that people SHOULD do to make sure that KDC are authentic
> include:
> 1. Local policy should specify which CAs are allowed to issue KDC certs,
> and for each one name constraints should define for which realms it is
> allowed to issue them
> 2. Keep a list of trust anchors (which may be specific to KDC cert
> issuance) and validate that the KDC's leaf cert chains up to a trust
> anchor.

Reply | Threaded
Open this post in threaded view
|

RE: CONSENSUS CALL: KDC certs part 1

Stefan Santesson
In reply to this post by Stefan Santesson
This looks OK to me.

However, to be picky I would change the last sentence to:

"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: Liqiang(Larry) Zhu
> Sent: den 27 augusti 2005 20:23
> To: Stefan Santesson; Paul Leach; Jeffrey Hutzelman; Sam Hartman
> Cc: [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
>
> s/determine/verify/
>
> I also would like to make this understandable by Kerberos developers, not
> just target at PKI experts.
>
> ----------------------
>
> "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. Typical
> ways to achieve this is includes configuration of specific sets of
> intermediary CAs and trust anchors, one of which must be on KDC
> certificate's certification path [RFC 3280]. In addition, name constraints
> [RFC 3280] may be applied that specify for which realms a CA is allowed to
> issue KDC certificates."
>
> --------------------
>
> This text is very explicit and plain about what is the requirements; can
> you help to verify if I have fixed all inaccuracies you pointed out below?
>
> Thanks,
>
> -- larry
>
> -----Original Message-----
> From: Stefan Santesson
> Sent: Saturday, August 27, 2005 2:51 AM
> To: Liqiang(Larry) Zhu; Paul Leach; Jeffrey Hutzelman; Sam Hartman
> Cc: [hidden email]; [hidden email]
> Subject: RE: CONSENSUS CALL: KDC certs part 1
>
> This is definitely an improvement, but I'm still not satisfied :)
>
> We should not be specific about any requirements on how to configure trust
> in a particular CA since it can be done in many valid ways.
>
> You definitely do NOT have to have specific trust anchors for KDC
> certificates and you not have to apply name constraints. And if you apply
> name constraints it is never applied by all CAs in the path.
>
> A perfectly valid example is if you have the KDC certificate chaining to a
> more generic root/TA while clients are configured to require a certain KDC
> specific intermediary CA (under that root/TA) to be present in the path.
>
> I suggest some hopefully minor changes to the text:
>
> "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 determine 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. Typical
> ways to achieve this is includes configuration of specific sets of trust
> anchors and intermediary CAs, possibly supported by name constraints,
> which have to be utilized in the certificate validation process according
> to RFC 3280."
>
>
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>
>
> > -----Original Message-----
> > From: Liqiang(Larry) Zhu
> > Sent: den 27 augusti 2005 04:58
> > To: Paul Leach; Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
> > Cc: [hidden email]; [hidden email]
> > Subject: RE: CONSENSUS CALL: KDC certs part 1
> >
> >
> > Paul suggested the following text after consolidating approach 1 and
> > approach 2.
> >
> > ------------------
> >    If the KDC's certificate 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 KDC certificate's CA MUST be 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.
> >
> >    To achieve this, local policy should specify a set of
> >    trust anchors for KDC certificates, and the client must verify that
> >    the KDC's leaf certificate is path validated [RFC3280] to an anchor
> >    in this set.  Each CA in the certification path between the KDC
> >    certificate and the trust anchor should have name constraints applied
> >    to it that specify for which realms it is allowed to issue KDC
> >    certificates.
> >
> > ------------------
> >
> > Please comment.
> >
> > Thanks,
> >
> > -- Larry
> >
> >
> > -----Original Message-----
> > From: [hidden email] [mailto:owner-ietf-krb-
> > [hidden email]] On Behalf Of Liqiang(Larry) Zhu
> > Sent: Friday, August 26, 2005 6:16 PM
> > To: Paul Leach; Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
> > Cc: [hidden email]; [hidden email]
> > Subject: RE: CONSENSUS CALL: KDC certs part 1
> >
> > Updated with Paul and Stefan's suggestion:
> >
> > ===================================
> > If the KDC certificate is certified by a CA as a KDC certificate for the
> > target ream (for example, the CA can indicate the certificate is a KDC
> > certificate of a Kerberos realm by asserting the TGS name of that
> Kerberos
> > realm as id-pksan SAN and/or restricting the certificate usage by using
> > the id-pkkdcekuoid EKU, as described in Section 3.2.4), the KDC
> > certificate's CA MUST be 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. The means by which the
> client
> > authorizes a CA for such purpose can be one of the following:
> >
> > 1. Local policy can specify which CAs are allowed to issue KDC
> > certificates, and for each one name constraints should define for which
> > realms it is allowed to issue them.
> >
> > 2. The client can keep a list of trust anchors for each Kerberos realm
> it
> > can contact (this list may be specific to KDC certificate issuance) and
> > validate that the KDC's leaf certificate is path validated [RFC3280] to
> a
> > trust anchor in the trust anchor list for the target realm.
> >
> > ===================================
> > Comments?
> >
> > -- Larry
> >
> > ________________________________________
> > From: Paul Leach
> > Sent: Friday, August 26, 2005 5:26 PM
> > To: Stefan Santesson; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
> > Cc: [hidden email]; [hidden email]
> > Subject: RE: CONSENSUS CALL: KDC certs part 1
> >
> > If the following text is to go into the security considerations section,
> > then I don't buy the last line:
> >
> > "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."
> >
> > The security considerations section needs to point out ways in which it
> is
> > possible to insecurely use a protocol.
> >
> > Some things that people SHOULD do to make sure that KDC are authentic
> > include:
> > 1. Local policy should specify which CAs are allowed to issue KDC certs,
> > and for each one name constraints should define for which realms it is
> > allowed to issue them
> > 2. Keep a list of trust anchors (which may be specific to KDC cert
> > issuance) and validate that the KDC's leaf cert chains up to a trust
> > anchor.

1234