Subject: [kitten] Feature creep in GSS mechanisms? [was Re: Consensus calls]

From: Thomas Maslen <[email-masked]>
Date: Thu, 8 Sep 2011 20:13:49 +0000

This is probably half-baked, but:

I agree that obviating replay caches would be a fine thing and I think the explicit third leg is a fine idea (even though it won't help for the GSS uses that I mostly deal with, e.g. HTTP Negotiate authentication).

However, I am suspicious of trying to shoehorn more and more goodies into the existing GSS KRB5 mech (1.2.840.113554.1.2.2).

I agree with the approach that draft-swift-win2k-krb-user2user took:  it was doing something substantially new / different, so it used a new mechanism (1.2.840.113554.1.2.2.3) rather than adding to the existing one.

So, rather than trying to fit explicit-third-leg etc etc into the venerable and rather crufty existing GSS KRB5 mech, is it time to define a new mechanism?

I understand that naive application of the "use a new mechanism" approach could lead to a combinatorial explosion of mechanism OIDs and that would be absurd...  so don't do that.  Instead, for GSS KRB5, maybe just define one new mechanism for all the proposed tasty new stuff, including explicit-third-leg.  I haven't thought about non-KRB5 mechanisms.

That having been said, I'm going to disappear on an E-mail-free vacation for a week.

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 Sep 2011 16:39:01 -0500

I would rather extend the mech we have than add new mechs.  The reason
is that mechanism negotiation tends to bleed into UIs, and negotiating
from variants of mechanisms where the credentials and technology are
substantively the same is not something that users should have to see
at all unless there's a downgrade attack that we can't protect against
without user intervention.

Think of SSL/TLS version radio buttons in various apps that use TLS.

If, OTOH, we didn't have this UI bleed issue and all the GSS apps we
care about were to transparently handle mechanism negotiation without
additional user intervention (via configuration, say), then I'd agree
that adding new mechanisms would be preferable to extending existing
ones.

Nico
--