Subject: Re: CONSENSUS CALL - #839 - KDC_ERR_KDC_NOT_TRUSTED

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 08 Jul 2005 12:52:26 -0400

On Monday, April 18, 2005 02:29:13 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

> On Mon, Apr 18, 2005 at 03:08:52PM -0400, Jeffrey Altman wrote:
>> I certainly agree with (b).  However, I am still uncomfortable with (a).
>>  I understand the desire to not penalize the clients which choose to
>> include the trustedCertifiers field when all they would need to do is
>> try again without.  There is something nagging at me that says that it
>> is better for the client to receive the KDC_ERR_KDC_NOT_TRUSTED error
>> and try again then to simply be given the positive response.  If the
>> client wins even when sending trustedCertifiers which are not trusted
>> or are no longer trusted, how is the client supposed to know?
>
> The client will know that the KDC lacked certs from the requested PKIs
> by the fact that the KDC did not use any such certs for the reply.  The
> client then gets to decide if whatever cert the KDC used is good enough.

Jeff, does this answer your concern?  Can we call this done?

> What bothers me is that the trustedCertifiers field doesn't seem to be
> integrity protected (pre-extensions).  If the client might be inclined
> to accept certs not within its trust anchors then this might make for a
> downgrade attack.

As you noted, it's a hint to help the KDC select the right certificate. 
Since certificate validatation either succeeds or fails, I fail to see how 
getting a different cert via a different trust path is a "downgrade".  Is 
this something you want to have more discussion on before we call this item 
done?

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Jul 2005 11:23:26 -0500

> this something you want to have more discussion on before we call this item 

Well, whether there is a downgrade attack will depend on the specifics
of the certificates in question, but in general I agree, this is not
much of a downgrade attack.  So, no, I don't see a need for further
discussion of this.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 13 Jul 2005 03:38:59 -0400

> Jeff, does this answer your concern?  Can we call this done?

Yes, this satisfies me.

Jeffrey Altman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Jul 2005 13:50:25 -0400

On Wednesday, July 13, 2005 03:38:59 AM -0400 Jeffrey Altman 
<[email-masked]> wrote:

>>>> I certainly agree with (b).  However, I am still uncomfortable with
>>>> (a). I understand the desire to not penalize the clients which choose
>>>>  to include the trustedCertifiers field when all they would need to do
>>>> is try again without.  There is something nagging at me that says that
>>>> it is better for the client to receive the KDC_ERR_KDC_NOT_TRUSTED
>>>> error and try again then to simply be given the positive response.  If
>>>> the client wins even when sending trustedCertifiers which are not
>>>> trusted or are no longer trusted, how is the client supposed to know?
>>>
>>>

OK; then I am declaring consensus on this issue.  I'll update the ticket 
once I've verified whether the new text already appears in the draft.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Jul 2005 18:22:28 -0400

> once I've verified whether the new text already appears in the draft.

The text for part (b) does appear in pkinit-26.

The "new text" for part (a) does not appear in -26, but neither does the 
"old text" describing the error code.  What we have instead is another copy 
of the part (b) new text in section 3.2.3.1 paragraph 5, describing how the 
KDC constructs its certificate chain.  I believe the text in -26 achieves 
the intended effect.

So, unless I hear an objection, I am closing this ticket with no further 
changes needed to the document.

-- Jeff