[kitten] New enctypes for just RFC4121

[Nico Williams <[e-mail]>]

We have bulk data GSS apps that could use faster enctypes.

We've discussed and rejected [as unsafe for use with long-term secret
keys] modern AEAD cipher modes for Kerberos.

Maybe we could have RFC4121-only enctypes?

We could extend RFC3961 to support AEAD enctypes not to be used in
Kerberos *except* as a sub-key in AP-REPs (EncAPRepPart).  Or we could
have a completely new entype framework (very close to RFC3961 perhaps)
with distinct enctype number namespace and a new negotiation extension
for RFC4121.

Extending RFC3961 seems like a simpler way to go.

My preference is to extend RFC3961 but declare some enctypes to be only
for use in RFC4121 per-message tokens, KRB-{SAFE,PRIV,CRED}, and similar
applications, and not for use in any other RFC4120 PDUs.

Possible enctypes would include:

 - {AES, Camellia} x {GCM, OCB, Poly1305}
 - {Salsa20, Chacha} x {Poly1305}

AES-OCB with AES-NI is particularly appealing.  The need to not encrypt
more than 2^48 blocks (4PB) probably argues for synchronous re-keying
(derive new keys for a per-msg token with the Nth block, for some N <=
2^48).

I'm curious about WG participants' reactions.

Nico
--