Subject: [Fwd: NISSC panel session]

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 25 Sep 2000 13:20:26 -0500

Would anyone on the Kerberos working group car to comment on AES and Kerberos?

I would expect it would be included. Therefore should the Kerberos revisions,
at a minimum, reserve encryption types and checksum types now? 

Marcus Leech wrote:
> 
> I've been asked to be on a panel discussion at the upcoming NISSC conference,
> the topic
>   being AES, and what the future holds for it.  I want to present some sense of
>   the IETF perspective on AES.
> 
> To that end, I want some notion of direction from each of you, as WG chairs, as
> to
>   where AES would fit into your respective protocols, and whether you have
> explicit
>   plans to support AES.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Ken Raeburn <[email-masked]>
Date: 25 Sep 2000 15:03:21 -0400

>at a minimum, reserve encryption types and checksum types now? 

David Hemsath's comments agree with what I've heard too.

I haven't heard much in the way of specifics about the multiple-winner
possibility though.  Would one be a "primary" winner?  If so, we could
pre-allocate it a number anyways.  If it would be less clear which is
"the" winner (for example, if they might recommend one for certain
uses and another for other uses), perhaps we should hold off on
assigning anything as "aes".

Now, we could assign numbers for one or more of the candidates, and
wait and see what happens with AES.  If they choose one of those
already assigned, we add an alias.  If they choose a different
algorithm, we assign it a number then.  If they choose more than one,
we flail about for a bit figuring out what to do. :-)

I've been experimenting with dropping Twofish into the MIT tree and
using the current key derivation support and SHA-1 to pull together a
full "Kerberos cryptosystem".  I was thinking of asking Cliff to
assign me a number for it, but

(a) If someone else is already working on it, they might be faster;
    I've got a few other things on my plate.
(b) Twofish could wind up not getting chosen for AES, though it'd
    probably still be a decent choice for a cryptosystem.
(c) I'm wavering on whether to assert a 256-bit key size, or say that
    it can be variable (which I don't think the protocol prohibits,
    but it requires implementations to have some flexibility in that
    department, and I'm not sure we gain much).
(d) If the speed is acceptable (and I've done *no* research on this,
    but suspect it would not be the case), would a cbc-mac be
    preferable to hmac-sha1, since it reduces our dependencies purely
    to the AES algorithm strength?  Or does it weaken us?
(e) one or two other issues I wanted to discuss with some
    cryptographers

So I've been holding off...

But I expect AES will be announced before we finish reviewing the
various sections, perhaps we could make a late change to reserve a
number for AES, before the last call.

Ken