Subject: Re: [kitten] New EncTypes?

From: Nico Williams <[email-masked]>
Date: Wed, 9 Dec 2015 03:37:54 -0600

On Wed, Nov 18, 2015 at 04:20:41PM -0800, Henry B (Hank) Hotz, CISSP wrote:
> It seems to be time to do housecleaning on algorithms selections. Is
> anyone interested in adding a new enctype to Kerberos?

Luke's working on AEAD enctypes.

> Why (else)?  Speaking strictly for myself, I’d like to see a
> mandatory-to-implement enctype that shares *nothing* with the current
> aes-sha1-hmac stuff. I’m speaking purely strategically and not from
> any mathematical suspicion of weakness. If someone discovers something
> fundamentally wrong with the math behind SHA1 or AES, then it might
> take out SHA2 or Camellia as well.

It's hard not to share AES.  Nowadays CPUs can do AES in constant time,
very fast, in hardware.  That's hard to pass up.

Yes, AES in software is terrible for security, and an alternative would
be nice for systems that don't have AES HW.

> Just to throw some straw (just straw, not an actual strawman) on the
> table, how about something that uses one of the European stream cipher
> finalists with SHA-3?

AEAD enctypes seem a lot more appealing to me.

Luke's work will reduce the RFC4121/3962 overhead on GSS wrap tokens
with confidentiality by 28 bytes, and will reduce the number of block
operations by 2 blocks per wrap w/ conf token, as well as support
parallelization (in principle anyways).  Plus AEAD cipher modes can be
quite fast.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 9 Dec 2015 03:47:47 -0600

On Thu, Nov 19, 2015 at 08:30:18AM +0100, Rick van Rein wrote:
> One thing I would like to bring into any such discussion is that it
> would be possible to use through PKCS #11, the de-facto standard for
> storing keys on tokens, including hardware keys that will never share
> keys directly but allow their use through the API.  This extends the
> range of possible uses for Kerberos, I think.

It's kinda meaningless to use hardware tokens for Kerberos.

On the KDC side you'd have to put the entire KDC in the token for it to
be meaningful.  You can leave the KDB outside, but now all KDB records
have to be signed, and keys encrypted (the latter is generally
supported, but the former would require significant rototilling).  It's
easier instead to harden a KDC, building it like a large HSM.  On the
service side (including the TGS), your hardware tokens had better be
*fast* -- if not then forget it.  A TGS can be slow, if the HW is slow,
but throughput has to be reasonable, and total latency per-request below
the point at which clients timeout.

Hardware tokens make a lot more sense for PK-based protocols.  If you
really want HW tokens, then Kerberos is not for you.

I'd be much more interested in working on a DANE-based mech_dh
replacement than in working on putting a KDC in a token.  Such a mech
could have Kerberos-compatible principal naming and even attribute
certificates to match authorization-data.  Being PK- and DNSSEC-based
would mean cross-realm functionality would be present from the get-go,
and it'd mean that HW tokens would be meaningful from day one as well
(well, as meaningful as they are with any PK today).

> For instance, AES-CTS-HMAC uses plain standard AES and HMAC, and CTS can
> be implemented in terms of standard CBC, so it ought to be possible to
> implement with PKCS #11 (not that I've already actually tried, but it
> looks possible).

Solaris/Illumos implements CTS in terms of CBC, so, yes, it can be done.
It takes up to three calls to CBC, so HW latency can be a problem.  (See
above remarks.)

Nico
--

---

From: Rick van Rein <[email-masked]>
Date: Fri, 11 Dec 2015 00:00:57 +0100

Hi Nico,

I was thinking of client-side tokens, not the KDC.
> It's kinda meaningless to use hardware tokens for Kerberos.

Symmetric keys reside on two ends, but the client will be much weaker in
its protection than the KDC; a reason for using PKCS #11 on the client
end is to uplift that level (and have better entropy than a password
supplies).  That would be an improvement even if the KDC was not changed
at all.  I agree that hardening the KDC can be pretty much comparable to
hardening an HSM.
> really want HW tokens, then Kerberos is not for you.

Yes and no... it's not a one-dimensional choice between PK and KRB5.

> replacement than in working on putting a KDC in a token.

I have a student working on that now :) and will send a project
description/proposal to at least MIT krb, and perhaps also Kitten,
sometime soon.

> Such a mech

PKINIT makes PK usable already, so I'm not sure why you bring
DNSSEC/DANE in here?  Do you want to improve on the cryptographic
strength of the initial password to protect AS?

Three is the total; encryption takes one CBC call, decryption takes two:
https://github.com/arpa2/kerberos-pkcs11/blob/master/aes128-cts-pkcs11.c#L221
https://github.com/arpa2/kerberos-pkcs11/blob/master/aes128-cts-pkcs11.c#L236
https://github.com/arpa2/kerberos-pkcs11/blob/master/aes128-cts-pkcs11.c#L241

Thanks,
 -Rick

---

From: Nico Williams <[email-masked]>
Date: Thu, 10 Dec 2015 17:36:32 -0600

> I was thinking of client-side tokens, not the KDC.

There's no need for KITTEN to be involved in making Kerberos clients use
a token.

> description/proposal to at least MIT krb, and perhaps also Kitten,

Oh, that's interesting.

> strength of the initial password to protect AS?

DNSSEC/DANE is to get a PKI.  DNSSEC is a PKI, a true hierarchical one,
and one using domainnames as issuer and end entity names.  The WebPKI is
not really hierarchical, doesn't deal well with domainnames, and has
other shortcomings.  Using DNSSEC/DANE means instant "PKCROSS" for a
modern mech_dh.  The key is to staple DNS responses that contain all the
necessary RRs, with the trust chain mostly as additional RRs.

Nico
--

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Thu, 10 Dec 2015 16:11:57 -0800

> On Dec 10, 2015, at 3:00 PM, Rick van Rein <[email-masked]> wrote:
> 
> Hi Nico,
> 

There’s no reason you can’t build a smart card that will do AES on supplied data once unlocked with a PIN.  Keys importable, but not exportable. I think the right comparison is to a keytab, so it’s not even that radical.

Agree that X.509/PKIX has a lot of distracting complexities (I’m being polite), and DNSSEC is a better PKI for us. I like the possibility of a more scalable cross-realm alternative. The existing one is good for small scale, like single-hop relationships. 

Is there actually interest in a HSM/KDC combination? I toyed with the idea once. . .

More to the point of the thread, I’m not sure any of these things necessitate EncType or protocol changes. Defining a relationship between DNSSEC and PKINIT/PKCROSS is a new area. While we’re at it, could we define the user’s Principal to be a functional email address in DNSSEC and make signed/encrypted email usable? I could argue that this is the way things are supposed to work!

Personal:  [email-masked]
Business: [email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Dec 2015 23:28:44 -0500 (EST)

> be nice for systems that don't have AES HW.

You don't see potential in a chacha/poly scheme?  Not that I'm
volunteering to write the draft, mind you...

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Dec 2015 23:30:52 -0500 (EST)

On Thu, 10 Dec 2015, Henry B (Hank) Hotz, CISSP wrote:

>
> More to the point of the thread, I’m not sure any of these things
> necessitate EncType or protocol changes. Defining a relationship between
> DNSSEC and PKINIT/PKCROSS is a new area. While we’re at it, could we
> define the user’s Principal to be a functional email address in DNSSEC
> and make signed/encrypted email usable? I could argue that this is the
> way things are supposed to work!

I have not been following particularly closely, but I thought there was a
lot of trouble finding a reasonable way to present email addresses in the
DNS and get continuity of keying -- the DNS administrator may not have a
good connection to where the user's key gets set, etc..

I forget where this discussion was going on, though ... maybe perpass,
though that doesn't quite feel right.

-Ben

---

From: [email-masked]
Date: Fri, 11 Dec 2015 07:26:22 +0000

> though that doesn't quite feel right.

DANE

S.

> -Be

---

From: Rick van Rein <[email-masked]>
Date: Fri, 11 Dec 2015 12:02:10 +0100

Hi Henry,

> I like the possibility of a more scalable cross-realm alternative. The
> existing one is good for small scale, like single-hop relationships.
>
I will put it up soon, and sounds like I should also post that MIT krb5
project here.  Writing to do for me...

> Is there actually interest in a HSM/KDC combination? I toyed with the
It's a design alternative I'm looking into for InternetWide.org identity
management.  So, I'm also toying with it and thought when discussing new
enctypes it would be good to bring up as a potential avenue.

As for email-style names, interesting, we generally look at the concept
of a NAI, RFC 7542.  The difference being, it's not necessarily possible
to send email to this [email-masked] style address.  We defined
general patterns for those as well, http://donai.arpa2.net/selector.html

Cheers,
 -Rick

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 11 Dec 2015 11:52:22 -0500

> volunteering to write the draft, mind you...

I would like to see a chacha/poly enctype but I'm not going to fund its
development in the short term.

It would be good to have a non-AES enctype in our back pocket even if we
aren't using it regularly today.

Jeffrey Altman

---

From: Simo Sorce <[email-masked]>
Date: Fri, 11 Dec 2015 12:12:23 -0500

> aren't using it regularly today.

MIT implements Camellia ...

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Fri, 11 Dec 2015 09:36:32 -0800

IIUC Camillia is based on the same math as AES. I was advocating for something unrelated. I think chacha/poly qualifies, so I’m interested.

> On Dec 11, 2015, at 9:12 AM, Simo Sorce <[email-masked]> wrote:
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

Personal:  [email-masked]

---

From: Luke Howard <[email-masked]>
Date: Sat, 12 Dec 2015 09:17:48 +1100

> On 12 Dec 2015, at 3:52 AM, Jeffrey Altman <[email-masked]> wrote:
> 

I can’t promise an implementation, but RFC 7539 looks similar enough to AES-GCM that I could profile it in the {krb,gss}-aead drafts I’m writing.

— Luke

---

From: Luke Howard <[email-masked]>
Date: Sun, 13 Dec 2015 12:49:07 +1100

> development in the short term.

As soon as OpenSSL 1.1.0 is released and supported by Heimdal, an implementation of chacha20-poly1305 will be trivial in the aes-gcm branch.

— Luke

---

From: Rick van Rein <[email-masked]>
Date: Sun, 13 Dec 2015 09:25:08 +0100

Hi

> IIUC Camillia is based on the same math as AES. I was advocating for
> something unrelated. I think chacha/poly qualifies, so I’m interested.
>
That is actually a very good idea. Such a good idea, that one wonders
why only one of the AES contestors was standardised. Could any of the
alternatives to Rijndael be worth a further look? This effort would
probably be beneficial for protocols other than Kerberos.

-Rick

---

From: Rick van Rein <[email-masked]>
Date: Sun, 13 Dec 2015 09:47:00 +0100

Hi,

> one wonders
> why only one of the AES contestors was standardised.

Following up on this thought, I selected some trivia from WikiPedia:

All five algorithms, commonly referred to as "AES finalists", were designed by cryptographers considered well-known and respected in the community. The AES2 conference votes were as follows:

 * Rijndael: 86 positive, 10 negative
 * Serpent: 59 positive, 7 negative
 * Twofish: 31 positive, 21 negative
 * RC6: 23 positive, 37 negative
 * MARS: 13 positive, 84 negative

All have the same interface as AES, a block size of 128 bits and support for a key size of 128, 192 or 256 bits.

The official NIST report on AES competition classified Serpent as having a high security margin along with MARS and Twofish, in contrast to the adequate security margin of RC6 and Rijndael (currently AES).[3] In final voting, Serpent had the least number of negative votes among the finalists, but scored second place overall because Rijndael had substantially more positive votes, the deciding factor being that Rijndael allowed for a far more efficient software implementation.

[3] Report on the Development of the Advanced Encryption Standard (AES)
    http://csrc.nist.gov/archive/aes/round2/r2report.pdf

Sources:
    https://en.wikipedia.org/wiki/Advanced_Encryption_Standard_process
    https://en.wikipedia.org/wiki/Serpent_(cipher)

Cheers,
 -Rick

---

From: Luke Howard <[email-masked]>
Date: Sun, 13 Dec 2015 22:48:31 +1100

As a historical note, the early RFC3961 drafts did specify Serpent and Twofish as well as AES:

https://tools.ietf.org/html/draft-raeburn-krb-rijndael-krb-01

— Luke

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 13 Dec 2015 23:08:24 -0500 (EST)

> probably be beneficial for protocols other than Kerberos.

Perhaps, but one should probably assume that people working on other
protocols are clever enough to have the same idea and have discarded it
for one reason or another.  If there is a need for it in Kerberos, by all
means go ahead, but I do not think we are necessarily the leaders of
crypto primitive usage in software, anymore.

-Ben