Re: [kitten] taking on new work?

[Nico Williams <[e-mail]>]

On Tue, Apr 04, 2017 at 11:55:50PM -0500, Benjamin Kaduk wrote:
> Now that we've cleared a fair bit of backlog, publishing a few old
> documents and getting ready to kick more up to the IESG, it seems
> apropos to consider what "new" work to adopt (many of which have
> been lingering as individual documents for a while and are not
> exactly new).
> 
> To give some historical perspective on the sense of the working
> group, back in Buenos Aires the chairs had a (very broad!) list of:
> draft-williams-kitten-krb5-pkcross
> draft-williams-kitten-krb5-extra-rt
> draft-williams-kitten-generic-naming-attributes
> draft-williams-kitten-impersonation-naming-attr
> draft-vanrein-kitten-rfbsasl
> draft-vanrein-dnstxt-krb1
> draft-vanrein-krb5-kdh
> draft-vanrein-kitten-krb5-pseudonymity
> draft-mccallum-kitten-krb-spake-preauth
> draft-kaduk-kitten-des-des-des-die-die-die
> draft-howard-gssapi-aead
> draft-mccallum-kitten-krb-service-discovery

There's really a very large amount of work to do in KITTEN WG, but a
very small amount of energy.  The three primary implementors, and
several additional derivative implementors, all have different agendas
and insufficient energy for reviewing each others' work early on.

I think a lot of the above, and others not on that list, could be done
outside the IETF using IANA registries to avoid collisions and provide a
modicum of documentation.  We could then submit I-Ds and publish RFCs
after we gain deployment experience.

> What do people currently feel are the top one or two highest
> priority items for the WG to consider?

For me the highest priority areas would be:

 - AEAD (i.e., performance)

 - krb5-extra-rt (i.e., better user experience)

 - GSS naming attributes (first, because I need them, and secondly
   because I see others adding features that should be added as name
   attributes, but not doing it as name attributes, and that complicates
   my universe because I really want to pass around NAMEs or exported
   composite name tokens rather than security contexts)

 - We actually need to fix the Java bindings of GSS to say that GSSName
   implements Principal (that's a long story)

I am also very interested in various of the ones you listed above:

 - Channel bound flag...

 - SPAKE

 - KDH

 - PKCROSS

 - TLS-1.3-based GSS mechanism

 - Specification of how to use Kerberos tickets as TLS 1.3 session
   resumption tickets

I'm also interested in publishing at least an Informative track RFC
explaining how to key services using ECDH, and clustered services using
multi-party ECDH.  A combination of PKCROS, PKINIT (or SPAKE), and
ECDH-keyed services would yield a protocol that can easily recover from
KDC database compromise, and combined with periodic realm public key
rollover, and a cacheable PKIX-based LoA authz-data, could allow a level
of cryptographic assurance that can compete with PKIX.  But I wouldn't
have the energy for that any time soon.

Nico
--