Subject: etype info vs etype info 2

From: [email-masked] (Sam Hartman)
Date: Wed, 5 Feb 2003 15:14:24 -0500 (EST)

While discussing implementing the AES draft, Ken and I realized we had
a very different interpretation of how etype info2 would be used.
This combined with Cliff's question leads me to believe that we may
not have a consensus on the issue.

I'm going to propose something and see who yells at me.

I believe that AES and other new enctypes MUST NOT appear in the etype
info message and that new KDCs MUST support etype info2.  

The reasoning behind this is that we want to eventually permit clients
to drop support for etype info, but we can only do that if we require
the new message to be sent.

I think that we also need to require that etype info2 list all
enctypes that would be supported.  I.E. a client should not have to
combine the lists.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 5 Feb 2003 15:01:40 -0600

IMO, if the client did not list any "new" enctypes in its AS-REQ then
the KDC MUST send etype-info and etype-info2, but if the client listed
any new enctypes, then the KDC MUST send only etype-info2 for all of
them, even the old ones.  This should apply to KRB-ERROR and AS-REP
generation.

By referencing a "new" enctype the client indicates full support for
etype-info2; if the client does not reference "new" enctypes then the
KDC cannot know whether the client supports etype-info2.

How should "new" enctypes be defined?  As any enctype other than the
DES, 3DES and RC4 types?

Further comments inline:

> info message and that new KDCs MUST support etype info2.  

Agreed.

> enctypes that would be supported.  I.E. a client should not have to

Agreed.

To this I would add the above, that a client that does not reference
"new" enctypes in its AS-REQ should get etype-info and etype-info2 for
all enctypes it did reference.

Where should the text go?  Sections 3.1.3 and 8.1 come to mind; section
5.2.7.5 should refer the reader to whichever section deals with this
matter.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 05 Feb 2003 16:10:49 -0500

I completely agree with Nico's additions.