Subject: [kitten] On the disadvantages of gs2 and Kerberos

From: Sam Hartman <[email-masked]>
Date: Wed, 1 Sep 2010 16:40:38 -0400 (EDT)

Monday, the MIT Kerberos release meeting got into an involved
discussion of replay caches.  It was our opinion that properly
designed protocols should not require a replay cache.

I'd like to point out that it's kind of dubious whether gs2 meets this
requirement.

One obvious failure is that if GS2 is used over a channel that does
not provide confidentiality, then a replay cache is required.  Even if
the channel provides integrity, an attacker could replay the Kerberos
GSS-API exchange and gain access to the service.

We could not have fixed this in the design of GS2 without requiring
security layers.  I think this is not an issue for SCRAM because the
server needs to send a challenge.

This is also not an issue if you're using unique channel bindings.
However, the most common current use of GS2 will be for endpoint
channel bindings.

We could create a new Kerberos GSS-API mechanism to add an extra half
round trip.
(we could fix this with a special SASL mechanism, but Nico at least is off designing protocols that look a lot like GS2 and I think I'm starting down that path myself. So, a SASL specific solution is unattractive.)

Meanwhile it's beginning to sound like we should write a GSS-API mechanism design guide. There are enough things that are true in practice with deployed applications that are worth writing down somewhere.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Sep 2010 15:54:57 -0500

On Wed, Sep 01, 2010 at 04:40:38PM -0400, Sam Hartman wrote:
> round trip.  (we could fix this with a special SASL mechanism, but
> Nico at least is off designing protocols that look a lot like GS2 and
> I think I'm starting down that path myself. So, a SASL specific
> solution is unattractive.)
> 
> 
> Meanwhile it's beginning to sound like we should write a GSS-API
> mechanism design guide. There are enough things that are true in
> practice with deployed applications that are worth writing down
> somewhere.

I agree with everything you wrote.  I'd add that the typical replay
cache is woefully sub-optimal, performance-wise, because it does an
fsync() for every addition to the cache.

I recently committed a tiny fix to the replay cache in Solaris that
removes the need for most fsync()s while remaining secure.  The diffs
are still available.  And I can explain the algorithm if you like.

Nico
--