Subject: [kitten] taking on new work?

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 4 Apr 2017 23:55:50 -0500

Hi all,

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

and the sense of the room was that
draft-mccallum-kitten-krb-spake-preauth and
draft-williams-kitten-krb5-pkcross were the most promising.

(draft-mccallum-kitten-krb-service-discovery has since been adopted)

Recall that our current work items are listed at:
https://datatracker.ietf.org/wg/kitten/documents/ , some of which
are believed to be ready to send to the IESG or nearly so.

What do people currently feel are the top one or two highest
priority items for the WG to consider?  (Such items need not be
limited to the above list, of course; note that, e.g.,
draft-schmaus-kitten-sasl-ht-00 has recently appeared on the list of
related internet-drafts.)

I'll also note that we should be able to ask the curdle WG to take
on draft-kaduk-kitten-des-des-des-die-die-die, which is simple
deprecation of RC4 and 3DES (and some registry cleanup from RFC
6649).  I'll plan to do that unless people want to do it in kitten
instead.  One might also ask about moving
draft-ietf-kitten-pkinit-alg-agility to curdle (since it moves
PKINIT off SHA1), but that's a little more complicated since it
first has to add the agility to do so, and judging by the reviews
accumulated and noted at
https://github.com/kittenwg/draft-ietf-kitten-pkinit-alg-agility ,
it should be basically done already.

Thanks,

Ben
for the Chairs

---

From: Rick van Rein <[email-masked]>
Date: Wed, 05 Apr 2017 11:21:43 +0200

Hi,

Good news, Ben :)

Let me at least sort the list of drafts I wrote.

> priority items for the WG to consider?

IMHO, draft-vanrein-dnstxt-krb1would be a quick win.  It's with the RFC
Editor and I'm working on and off to get it adopted into MIT krb5.  Nico
has reviewed it and the RFC Editor is mainly waiting for a 2nd reviewer.

Also up shortly in our work is Kerberos Realm Crossover, bet there's no
I-D yet.

In the TLS WG, I'm working on TLS-KDH, which may need some discussion in
Kitten on the allocation of numbers (such as unencrypted algorithm
numbers, because TLS takes care of the encryption).

Cheers,
 -Rick

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 5 Apr 2017 08:40:27 -0400

> draft-mccallum-kitten-krb-service-discovery

Not on this list (possibly because the draft was expired at the time of
the Buenos Aires meeting) is

  https://datatracker.ietf.org/doc/draft-cantor-ietf-kitten-saml-ec/

which has an open source implementation for Shibboleth at

  https://github.com/fedushare/mech_saml_ec

> it should be basically done already.

I believe that draft-kaduk-kitten-des-des-des-die-die-die fine as-is and
should simply be published by Kitten.

I would like to see the following documents be adopted

  draft-williams-kitten-krb5-pkcross
  draft-howard-gssapi-aead
  draft-cantor-ietf-kitten-saml-ec

Jeffrey Altman

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 5 Apr 2017 10:13:36 -0500

>   https://datatracker.ietf.org/doc/draft-cantor-ietf-kitten-saml-ec/

That was adopted years ago and became
https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/ ,
though apparently no one set the right metadata to show it as
replacing the draft-cantor version.

If you think it is ready to publish, please send a review of the
latest version to the list (or a link to one you already sent), and
we can make a github repo to track reviews of that document and try
to move it forward.  I did not un-expire it with my batch from last
week because I was unsure if there was any WG interest in moving it
forward, though it seems I now have the answer to that question.

> should simply be published by Kitten.

Have you reviewed a specific revision of it so as to form that
opinion?  Again, if we don't have a number of reviews that we can
track, the document is just going to sit there and not move forward.

>   draft-cantor-ietf-kitten-saml-ec

Hmm, that is only "one or two" on a technicality (the
draft-cantor-ietf-kitten-saml-ec is already a WG item).

-Ben

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 5 Apr 2017 11:21:32 -0400

> replacing the draft-cantor version.

The document

is not listed at

  https://datatracker.ietf.org/wg/kitten/documents/

possibly because it is expired and archived.

> track, the document is just going to sit there and not move forward.

This is only one revision of

https://datatracker.ietf.org/doc/html/draft-kaduk-kitten-des-des-des-die-die-die

I have reviewed it.  Given that it is a document describing deprecation
of encryption types I don't think it requires perfection.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 5 Apr 2017 10:29:19 -0500

> related internet-drafts.)

Taking off my chair hat, I think that
draft-mccallum-kitten-krb-spake-preauth is the most pressing item.
Currently, our claims to security rely on users selecting strong
passwords, which is a laughable assumption given dumps from password
database leaks/etc.  Being able to close off avenues for offline
attacks, which also providing an integrated way to include a second
factor that cannot be attacked separately from the password, seems
like a huge security win.

When I talked to Kenny Paterson about the potential impact of RC4
weaknesses on Kerberos, he said that directly using password-derived
keys is a far bigger problem than the statistical weakenesses of
RC4.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 5 Apr 2017 10:34:58 -0500

> possibly because it is expired and archived.

Yes, the datatracker has in the past year or two gotten more
aggressive about not displaying expired/archived documents.  They
still show up in a document search, though.

I will take an action item to post a new no-change revision to
un-expire it and return it to the WG dashboard, since you have
expressed interest in it.

> of encryption types I don't think it requires perfection.

I see a -00 and a -01 available at that link, though the diff
(https://tools.ietf.org/rfcdiff?url2=draft-kaduk-kitten-des-des-des-die-die-die-01.txt)
is just updating for external events, such as the publication of RFC
7465 deprecating RC4 for TLS, and the end-of-life of Windows Server
2003.

-Ben

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 5 Apr 2017 11:38:49 -0400

> 7465 deprecating RC4 for TLS, and the end-of-life of Windows Server

To be explicit, I reviewed -01.

Jeff

---

From: Greg Hudson <[email-masked]>
Date: Wed, 5 Apr 2017 12:52:20 -0400

> draft-mccallum-kitten-krb-spake-preauth is the most pressing item.

I agree.

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Apr 2017 14:10:35 -0500

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

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 5 Apr 2017 14:26:46 -0500

> and insufficient energy for reviewing each others' work early on.

Yes, there's a lot of work to do.

>    implements Principal (that's a long story)

but maybe you could narrow it down to a top two?

-Ben

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Apr 2017 15:59:12 -0500

> but maybe you could narrow it down to a top two?

I'll take any two of the above that others also want to work on.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 5 Apr 2017 21:23:58 -0500

> has reviewed it and the RFC Editor is mainly waiting for a 2nd reviewer.

Hmm, perhaps you mean Independent Submission Editor instead of RFC
Editor?  (I am not terribly familiar with that path to RFC
publication.)  In that case, it's unclear that pulling it into the
WG at this late stage would be productive, though folks here are of
course welcome to review it and help the ISE out.

> numbers, because TLS takes care of the encryption).

Sure, we'll talk about that as it comes up.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 5 Apr 2017 21:34:33 -0500

> related internet-drafts.)

To sum up today's traffic, it looks like SPAKE (Greg/Me/Nico's
second tier) and GSS AEAD (Jeffrey/Nico) are the leaders, though of
course it would be good to get input from more people.

-Ben

---

From: Robbie Harwood <[email-masked]>
Date: Thu, 06 Apr 2017 08:56:42 -0400

>> priority items for the WG to consider?

Biased of course, but this is my highest.

>  - Channel bound flag...

This is my second.

>  - TLS-1.3-based GSS mechanism

Also consider this one important.

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 6 Apr 2017 14:00:53 +0000

Re: saml-ec

> expressed interest in it.

Or I can, I'm still around. I just don't have reviewers I can offer up. I can make time to address issues if they're raised by any reviews. I have no outstanding edits that I'm aware of.

-- Scott

---

From: Matt Rogers <[email-masked]>
Date: Thu, 6 Apr 2017 11:24:23 -0400

> Also consider this one important.

I agree with this list as well.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 21 Apr 2017 17:25:24 -0500

> course it would be good to get input from more people.

Now that the input has died down and the chairs have had a chance to
confer, it seems we have consensus to adopt
draft-mccallum-kitten-krb-spake-preauth and reinvigorate attention
on draft-ietf-kitten-channel-bound-flag.

Authors, please submit a new version of
draft-mccallum-kitten-krb-spake-preauth as
draft-ietf-kitten-krb-spake-preauth at your convenience.

Everyone is encouraged to (re)review these documents, and those
interested in a TLS 1.3-related GSS mechanism are encouraged to
formulate such thoughts in the form of a draft.

Thanks,

Ben
for the chairs