Subject: Bill told us so: stackable mechs, SPNEGO and substitutions

From: Sam Hartman <[email-masked]>
Date: Mon, 11 Apr 2005 18:16:58 -0400

During the security review of SPNEGO, Bill brought up a concern.  The
windows compatibility is only secure if you cannot mechanically
transform the mechanism token of one mechanism into the token of
another mechanism.

I'm concerned that for many stackable mechanisms it would be
relatively easy to push or pop something onto the stack and manipulate
the tokens without cryptographic knowledge.

Also, at least some of the mechanisms we have been discussing in the
EAP context would be mechanisms that do not provide integrity unless
properly stacked with a mechanism that spins integrity out of raw PRF.

In short, there are a lot of security concerns surrounding stacking
and negotiation.

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Apr 2005 17:47:55 -0500

> transform the mechanism token of one mechanism into the token of

Right.  IIRC Bill said this during lunch on Wednesday or Thursday.

Bill is correct.

As an aside, we first noted such a problem when designing the new
Kerberos V GSS mechanism (CFX).  We had to figure out how to deal with
extensibility.  In the end we punted on extensibility but provided the
mechanism by which it could be added: we defined a slot where extensions
could be requested by the initiator and declared that any such
extensions will have to have the acceptor produce a context token that
cannot be mechanically transformed into a non-extended context reply
token.

The issue there, and here, is quite similar: it's about protecting
negotiation of security parameters.

> the tokens without cryptographic knowledge.

Note that this issue arises, so far, only from negotiation above the
GSS-API.  SPNEGO, in particular, because of its historic brokenness, is
what forces us to consider this.

Now.  We have two choices: design stackable mechanisms so that the
context tokens of composite mechanisms cannot be easily manipulated into
context tokens of different mechanisms (e.g., the underlying concrete
mechanism's), OR, indicate that a given stackable mechanism doesn't have
that property and so SPNEGO should insist on a mechListMIC exchange.

> In short, there are a lot of security concerns surrounding stacking

Well, you've identified *one* such concern here -- Bill's.  We need to
think about others though :)

Nico
--