Subject: Re: New version of kerberos clarifications

From: Nicolas Williams <[email-masked]>
Date: Fri, 7 Feb 2003 04:17:37 -0600

On Fri, Jan 24, 2003 at 01:01:07PM -0500, Sam Hartman wrote:
> >>>>> "Clifford" == Clifford Neuman <[email-masked]> writes:
> 
>     Matt> How about we change the text to state that the KDC makes the
>     Matt> decision based on policy and that the policy may be based on
>     Matt> ordinal value?
>     >>  I wouldn't feel comfortable with that, but I'd be happy with
>     >> sttating that the KDC SHOULD use the ordered value from the
>     >> list.  In the
> 
>     Clifford> In this message, I am only including enough of the
>     Clifford> discussion to identify the item.  The full text of the
>     Clifford> discussion on this topic (at least that part which I
>     Clifford> received) appears on the "issues being edited" link.
> 
> I think in section 3.1.3, changing
> 
> If there is more than one supported strong encryption type in the
> etype list, the first valid strong etype for which an encryption key is
> available is used.
> 
> to
> If there is more than one supported strong encryption type in the
> etype list, the KDC SHOULD use the first valid strong etype for which an encryption key is
> available.
> 
> should address the concern.

Assumes that there is an order of keys in a KDB entry.  IMO this amounts
to saying that the KDC should allow enctype preference to be
administratively specified on a per-principal basis.  So why not just
say that?  :)

Proposed text:

"The KDC SHOULD allow the preference order of encryption types to be
specified administratively on a per-principal basis and should pick a
strong enctype from a client's etype list accordingly."

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 07 Feb 2003 10:58:40 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Assumes that there is an order of keys in a KDB entry.
    Nicolas> IMO this amounts to saying that the KDC should allow
    Nicolas> enctype preference to be administratively specified on a
    Nicolas> per-principal basis.  So why not just say that?  :)

No, assumes there is an order in the etype list coming in from the
client.  My point is that this order SHOULD trump any order in the
KDB.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 07 Feb 2003 17:33:43 +0100

> client.  My point is that this order SHOULD trump any order in the

The etype list coming from the client is not integrity protected, so
IMHO it should not trump anything, only be used as an indication on
what the client supports.

---

From: Tom Yu <[email-masked]>
Date: Fri, 07 Feb 2003 12:08:08 -0500

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

>> client.  My point is that this order SHOULD trump any order in the

Simon> The etype list coming from the client is not integrity protected, so
Simon> IMHO it should not trump anything, only be used as an indication on
Simon> what the client supports.

While this is true, I would argue that if a site considers certain
enctypes to be unsuitable, those enctypes should not be used for
principal keys in the database, and thus would not be available to a
client requesting those enctypes.  Additionally, we could get around
the problem of integrity protection of the query enctype list when we
work on krb-extensions.

The ordering of keys in the database _is_ relevant for choosing the
key to use for encrypting the service ticket... though it is only
really important that the KDC and the application server agree on
one key, so really only the first one in the list matters.

---Tom

---

From: Sam Hartman <[email-masked]>
Date: Fri, 07 Feb 2003 12:32:09 -0500

>>  No, assumes there is an order in the etype list coming in from
    >> the client.  My point is that this order SHOULD trump any order
    >> in the KDB.

    Simon> The etype list coming from the client is not integrity
    Simon> protected, so IMHO it should not trump anything, only be
    Simon> used as an indication on what the client supports.

Any attack I can mount by moving things around in the order can be
mounted by removing all but one item from the order, so there are no
additional issues treating the client etype list as an ordered set.

RFC 1510 says it should be ordered, it's useful for it to be ordered,
so we need to have a good reason to change it.  Matt presented such a
reason: the Microsoft implementation cannot treat it as an ordered
list because of how they implemented something.  I believe changing
the text to a SHOULD is the minimum change that creates
interoperability.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 7 Feb 2003 11:48:47 -0600

> client.  My point is that this order SHOULD trump any order in the

I assumed a different context.  My apologies.

I agree with your proposed text.

Nico
--