Subject: CONSENSUS CALL - #839 - KDC_ERR_KDC_NOT_TRUSTED

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 18 Apr 2005 14:31:40 -0400

This was discussed last month, and I think there's been enough discussion 
to issue a consensus call now.  This message is actually about two separate 
questions related to the KDC's behavior in selecting certs to use:

(a) Does the working group agree to drop the KDC_ERR_KDC_NOT_TRUSTED error 
code, and instead REQUIRE the KDC to ignore trustedCertifiers in cases 
where it would be returned, by making the following change:

Old Text:
   The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
   did not include a kdcCert field, but did include a trustedCertifiers
   field, and the KDC does not possesses a certificate issued by one of
   the listed certifiers.

New Text:
   If the client included a trustedCertifiers field, and the KDC does
   not possesses a certificate issued by one of the listed certifiers,
   the KDC MUST ignore the trustedCertifiers field as if the client did
   not include any.

(b) Does the working group agree to RECOMMEND (but not REQUIRE) that the 
KDC use the trustedCertifiers to select an appropriate certificate chain, 
by adding the following text:

New Text:
                -- The information contained in the
                -- trustedCertifiers SHOULD be used by the KDC
                -- to guide its selection of an appropriate
                -- certificate chain to return to the client.

Note that as of PKINIT-25, there is no text requiring the KDC to make use 
of the trustedCertifiers field when it is present, so while it may have 
been the previous intent to REQUIRE this field to be obeyed, there was 
nothing in the spec to that effect.

PLEASE, respond to this message even if you have commented on this issue 
before.  My life is a lot easier if I can review responses to a binary 
consensus call instead of having to interpret past discussion and comments.

-- Jeff

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 18 Apr 2005 15:08:52 -0400

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?

If the trustedCertifiers field is optional to send and required to
ignore, why even bother including it in the spec?

Jeffrey Altman

Jeffrey Hutzelman wrote:

> This was discussed last month, and I think there's been enough
> discussion to issue a consensus call now.  This message is actually
> about two separate questions related to the KDC's behavior in selecting
> certs to use:
> 
> 
> 
> (a) Does the working group agree to drop the KDC_ERR_KDC_NOT_TRUSTED
> error code, and instead REQUIRE the KDC to ignore trustedCertifiers in
> cases where it would be returned, by making the following change:
> 
> Old Text:
> KDC use the trustedCertifiers to select an appropriate certificate
> chain, by adding the following text:
> 
> New Text:
> Note that as of PKINIT-25, there is no text requiring the KDC to make
> use of the trustedCertifiers field when it is present, so while it may
> have been the previous intent to REQUIRE this field to be obeyed, there
> was nothing in the spec to that effect.
> 
> 
>

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 Apr 2005 14:29:13 -0500

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

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.

> ignore, why even bother including it in the spec?

It helps the client help the KDC pick the right KDC cert.  It's a hint.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Apr 2005 21:43:00 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> This was discussed last month, and I think there's been
    Jeffrey> enough discussion to issue a consensus call now.  This
    Jeffrey> message is actually about two separate questions related
    Jeffrey> to the KDC's behavior in selecting certs to use:

    Jeffrey> (a) Does the working group agree to drop the
    Jeffrey> KDC_ERR_KDC_NOT_TRUSTED error code, and instead REQUIRE
    Jeffrey> the KDC to ignore trustedCertifiers in cases where it
    Jeffrey> would be returned, by making the following change:

I do not object to this change.
    Jeffrey> (b) Does the working group agree to RECOMMEND (but not
    Jeffrey> REQUIRE) that the KDC use the trustedCertifiers to select
    Jeffrey> an appropriate certificate chain, by adding the following
    Jeffrey> text:

I support this change.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 19 Apr 2005 18:01:26 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> about two separate questions related to the KDC's behavior in
> selecting certs to use:
>
>
>

I support this change.

> (b) Does the working group agree to RECOMMEND (but not REQUIRE) that
> the KDC use the trustedCertifiers to select an appropriate certificate

I support this change.

Love