Subject: RE: comments on clarifications

From: "Matt Hur" <[email-masked]>
Date: Sat, 16 Nov 2002 15:33:09 -0800

How about we change the text to state that the KDC makes the decision
based on policy and that the policy may be based on ordinal value?

I am concerned that the text not disallow existing implementations.  The
MS implementation has DES first in the list, but we certainly do not
want to use DES when we have something stronger (i.e. as indicated by
the client using RC4 for preauth).

--Matt

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Saturday, November 16, 2002 2:35 PM
> To: Matt Hur
> Cc: [email-masked]; [email-masked]
> Subject: Re: comments on clarifications
> 
> >>>>> "Matt" == Matt Hur <[email-masked]> writes:
> 

-- snip --

> 
>     Matt> We should change the wording to state that the KDC
>     Matt> should use the strongest etype per policy rather than basing
>     Matt> the decision on ordinal value.  For example, what is the
>     Matt> expected behavior if preauth data (encrypted timestamp) uses
>     Matt> an enctype that is different from the first enctype
>     Matt> specified in the etype field (i.e. what if preauth uses 3DES
>     Matt> or AES and the first etype in the list is DES)?
> 
> We've had this discussion before and I think we failed to reach
> consensus on a change.  I think that treating the etype list as
> ordered is important and would object to changing those semantics at
> this point in the process.
> 
> I wouldn't object to adding language clarifying that the KDC can
> discard unreasonable enctypes.  For example, if preauth data
> influences what reply key is used and the right kind of preauth isn't
> present to use some enctype then it is reasonable to ignore that
> enctype even if listed.  Similarly if the KDC wants to know that the
> client knows the key corresponding to some particular enctype, then
> not using that enctype unless the preauth for that enctype is
> presented sounds reasonable.  I think coming up with text that says
> this would be difficult and I don't think we should hold up the
> document on this issue.
> 
> 
> 
--snip --

---

From: Sam Hartman <[email-masked]>
Date: Sat, 16 Nov 2002 18:46:44 -0500

>>>>> "Matt" == Matt Hur <[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 tstating
that the KDC SHOULD use the ordered value from the list.  In the
absence of a good reason to do otherwise, it is useful for a client to
be able to express preferences about encryption types; I know this is
mostly useful for debugging, but I have seen some interoperability
problems where being able to change this order has helped
significantly.  I can certainly see cases where tradeoffs for specific
applications might have client-based ordering--for example for doing
bulk data transfers I might well prefer RC4 to AES, but for
administrative operations I might prefer AES to RC4.  That distinction
is likely to be more important for the TGS request than for the AS
request.

I certainly agree that a strong policy preference for RC4 over DES and
existing clients that express the wrong order is sufficient
justification to violate a SHOULD.

I'd also recommend that you consider changing the order in future
versions of your client, although I realize that's a long-term issue.

You might want to write up an implementation note on this issue as
well.