Re: CONSENSUS CALL - #839 - KDC_ERR_KDC_NOT_TRUSTED

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

Re: CONSENSUS CALL - #839 - KDC_ERR_KDC_NOT_TRUSTED

Jeffrey Hutzelman


On Monday, April 18, 2005 02:29:13 PM -0500 Nicolas Williams
<[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: CONSENSUS CALL - #839 - KDC_ERR_KDC_NOT_TRUSTED

Nicolas Williams
On Fri, Jul 08, 2005 at 12:52:26PM -0400, Jeffrey Hutzelman wrote:

> On Monday, April 18, 2005 02:29:13 PM -0500 Nicolas Williams
> <[hidden email]> wrote:
> >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?

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


Reply | Threaded
Open this post in threaded view
|

Re: CONSENSUS CALL - #839 - KDC_ERR_KDC_NOT_TRUSTED

Jeffrey Altman
In reply to this post by Jeffrey Hutzelman
Jeffrey Hutzelman wrote:

>
>
> On Monday, April 18, 2005 02:29:13 PM -0500 Nicolas Williams
> <[hidden email]> 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?
Yes, this satisfies me.

Jeffrey Altman

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CONSENSUS CALL - #839 - KDC_ERR_KDC_NOT_TRUSTED

Jeffrey Hutzelman


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

> Jeffrey Hutzelman wrote:
>>
>>
>> On Monday, April 18, 2005 02:29:13 PM -0500 Nicolas Williams
>> <[hidden email]> 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?
>
> Yes, this satisfies me.


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


Reply | Threaded
Open this post in threaded view
|

Re: CONSENSUS CALL - #839 - KDC_ERR_KDC_NOT_TRUSTED

Jeffrey Hutzelman


On Wednesday, July 13, 2005 01:50:25 PM -0400 Jeffrey Hutzelman
<[hidden email]> wrote:

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

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