Subject: [kitten] New enctypes for just RFC4121

From: Nico Williams <[email-masked]>
Date: Thu, 2 Oct 2014 18:40:14 -0500

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
--

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 02 Oct 2014 21:04:36 -0400

3961 was split from Kerberos so the framework could be used by
application protocols other than Kerberos.  I believe that includes
the ability to define enctypes within the framework that are not
applicable for use with Kerberos itself.

Jeffrey Altman

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 3 Oct 2014 12:33:38 -0400 (EDT)

> I'm curious about WG participants' reactions.

The thought of having RFC 3961 enctypes specified that are forbidden for
use with generic RFC 4120 messages does not inherently make me cringe.

I do have some concerns about an "enctype explosion", i.e., doing the full
cartesian product spaces you listed above would be way too many for my
taste.

Partially as a consequence of that, but partially on its own merit, I
think we would want to see some (performance) metrics to justify the
addition of a new enctype before we would adopt such a proposal.  "It
seems like a neat idea" is not really a sufficient justification, but "we
can get 100% more throughput" probably is.

We should probably get feedback from more people before asking you to go
off and prototype something and gather metrics, though.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Fri, 3 Oct 2014 11:44:19 -0500

> use with generic RFC 4120 messages does not inherently make me cringe.

Good.  As Jeff points out, RFC3961 is not just for Kerberos.

> cartesian product spaces you listed above would be way too many for my

Unlike TLS, there's only two variables for the cartesian product here,
so I'm not concerned about this, but I'd be happy to pare down the list.

> can get 100% more throughput" probably is.

AES-OCB is much faster than AES-CTS-HMAC-SHA1-96.  (This should be
obvious, numbers or no.)

> off and prototype something and gather metrics, though.

Yes, exactly.  I don't want to spend a lot of effort on failing.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 3 Oct 2014 11:56:59 -0500

Another possibility would be to create a new framework now and extend
RFC3961 to encompass it later.  The new framework would share the
enctype number namespace with RFC3961, thus making it possible to not
have to extend the mechanism's enctype negotiation (and, for example,
not have to extend AP-REP).

OTOH, it's about time we extended AP-REP.

There are a few choices to make here before prototyping if the prototype
is to have a chance of not having to get thrown out later:

0) extend RFC3961 or not

   (if yes, stop here)

1) if not, share the enctype number namespace with RFC3961 so as to
   permit future extension of RFC3961 to encompass AEAD ciphers, or not

   (if yes, stop here)

2) if not, we must extend AP-REP.

Help me make these decisions :)

For now I'm looking to estimate implementation costs, not necessarily to
implement.  Any choices we make that tend to lower those costs will tend
to increase the chances of any implementations materializing.

I don't really want to bother with an I-D first, but the high-level
design should be settled as soon as possible, if at all possible.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 3 Oct 2014 14:44:25 -0500

An RFC3961 extension for AEAD enctypes would actually be
straightforward.

AEAD enctypes would:

 - provide new authenticated_encryption and authenticated_decryption
   functions

   and

 - not provide the old encryption, decryption, get_mic, and verify_mic
   functions

This should suffice to keep Kerberos from using these enctypes, though
we'd have to say something about the AS/TGS clients and servers (KDCs)
not attempting to negotiate these new enctypes (else they'd fail hard).

Nico
--