Subject: RE: SPNEGO SOMIC rules

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Fri, 12 Nov 2004 14:06:56 -0800

I am working on this right now.

-- larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Friday, November 12, 2004 1:41 PM
To: Wyllys Ingersoll
Cc: [email-masked]
Subject: Re: SPNEGO SOMIC rules

Wyllys Ingersoll wrote:
> 
> I've attempted to condense and summarize the rules for when an 
> acceptor and initiator need to process the MIC tokens (section 3.2).
> 
> I'm not certain I've captured every nuance, but the goal is to 
> simplify the text and clarify the rules.

I'm sorry, but I find your description quite difficult to understand.

As I said, I would really prefer if the spec itself unconditionally
required to create and send the MIC as in the original spec.

In addition, I'd like to see a precise list of all scenarios for which
one has to omit the mechListMic in order to interoperate with a
particular broken implementation and an explanation for each case why
this particular omission does not open a vulnerability.

-Martin

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

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

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Nov 2004 23:03:12 +0100 (MET)

Sam Hartman wrote:
> 
>     Martin> It has always been a(n implicit) requirement that SPNEGO
>     Martin> makes a well-behaved multi-mechanism with the underlying
>     Martin> real gss-api mechanisms, i.e. that the OID in the generic
>     Martin> framing of the initial security context token is passed to
>     Martin> and processed by the respective gssapi mechanism on the
>     Martin> server side.
> 
> This requirement has not been clear to the rest of the IETF.  The most
> notable example of this is the dnsext working group's interpretation
> of the spec, but none of us who were at the meeting were able to come
> up with text to convince them they were wrong.

This requirement is implicit from the GSS-API architecture that
allowed for multi-mechanisms even before SPNEGO was invented.
The server/acceptor MUST always look at the mechanism OID of the
initial context token and dispatch the token accordingly

Before SPNEGO, a client with multiple mechanism was required to
choose a particular mechanism and try that (and possibly fail).

SPNEGO was added to allow to negotiate among the set of available
mechanisms, not having to go through failures at the application
level when trying to find a matching mechanism.

However SPNEGO was never designed to preclude direct selection
of a particular mechanism and was never allowed to force itself
onto the application.

The prerequisite for SPNEGO to get used at all is mentioned in rfc2478:

4.1.  Initial steps

   (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).

   (I) invokes GSS_Init_sec_context() with :

   Input
     mech_type = OID for negotiation mechanism or NULL, if the
     negotiation mechanism is the default mechanism.

In case that the input mech_type is *NOT* SPNEGO (or NULL and teh local
default mechanism is not SPNEGO), then the initial security context
token will not be an SPNEGO token.  It is as simple as that.

-Martin

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Wed, 17 Nov 2004 18:34:52 -0800

Martin Rex wrote:
> OK, I'll wait and see.

The next version of this draft is still in review by the authors. It
should be available to publish soon, but I just sent Martin a copy of
the initial version.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Tuesday, November 16, 2004 12:51 PM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: SPNEGO SOMIC rules

Sam Hartman wrote:
> 
> The server knows (because the new protocol will mandate this behavior)

> that a client will demand a MIC if the client sees the server trying 
> to negotiate anything other than the most preferred mechanism of the 
> client.  That's part of the meta-rule Nico proposes.
> 
> Again, how the client demands a MIC is something Larry's draft will 
> explain.

OK, I'll wait and see.

> 
> It should be clear thought that the situation where the client offers 
> only one mechanism is secure provided that the client can demand a MIC

> and correctly coded clients do demand a MIC in the appropriate 
> situations.

I think that a client that has only a single mechanism an uses SPNEGO is
broken, it should be using the underlying gss-api mechanism directly,
and will become interoperable with peers that do not support SPNEGO.

Actually, the client's SPNEGO implementation could make that
optimization instead of going for the SPNEGO exchange with optimistic
token.  That way it will not only omit/save the mechListMIC, but all the
SPNEGO overhead and complexity.

When I asked Larry whether their IIS would correctly handle a Kerberos
token instead of a Kerberos-optimistic-token-within-SPNEGO
when doing the HTTP-authentication, he claimed this should work.

Suggesting such a change for *initiators* would *not* impair backwards
compatibility with correct implementations of SPNEGO (which may exist).

-Martin

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Wed, 17 Nov 2004 18:43:04 -0800

> I think that a client that has only a single mechanism an uses SPNEGO
is broken, it should be using the underlying gss-
> api mechanism directly, and will become interoperable with peers that
do not support SPNEGO.

You are correct, SPNEGO is useful when the client supports more than one
mechanism. Our clients have two mechanism to offer, we want to 1)
interoperate with other implementations, 2) allow negotiation. 

-- Larry

-----Original Message-----

OK, I'll wait and see.

-Martin

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Wed, 24 Nov 2004 09:38:35 -0800

On Wed, Nov 17, 2004 at 01:37:48PM -0500, Sam Hartman wrote:
> I wonder if SPNEGO needs to pick up a copy of the standard 
> multi-layer-negotiation considered harmful argument?  I wonder if 
> we're getting to a point where we need a single version of that 
> document to reference.

nothing from here so far, but here are my thoughts:

If the SPNEGO target accepts a single mechanism token without the SPNEGO
framing, it will prevent the acceptor from demanding the mechlistMIC.

Using a two-token mechanism A in the following example, the initiator
supports mechanism A, and the acceptor supports mechanism A and
mechanism B, but prefers B if offered. The initiator sends negTokenInit
with an optimistic token of A, the attacker strips out the optimistic
token and sends it to the acceptor; the acceptor processes this
optimistic token and sends a response token of A and returns complete;
the attacker then puts the response token of A into negTokenResp with an
accept_complete state. An attack was successfully just launched.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas Williams
Sent: Wednesday, November 17, 2004 1:27 PM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: SPNEGO SOMIC rules

On Wed, Nov 17, 2004 at 01:37:48PM -0500, Sam Hartman wrote:
> I wonder if SPNEGO needs to pick up a copy of the standard 
> multi-layer-negotiation considered harmful argument?  I wonder if 
> we're getting to a point where we need a single version of that 
> document to reference.

Yes, yes.

> 
> (I bring up this comment because Martin's discussion of GSSAPI 
> variants reminds me that doing stuff like that at the SPNEGO layer is 
> the only safe way to do it in a case where you have the SPNEGO layer 
> at all.  Probably not so true for crypto algorithms, but true for 
> anything that can influence the choice of mechanism.)

"only" is a bit strong, but I digress :)

Nico
--

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Wed, 24 Nov 2004 09:58:44 -0800

Note that although the attack via the single-mech-token below is valid,
it is harmful only when the initiator supports both A and B but prefers
A.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Liqiang(Larry) Zhu
Sent: Wednesday, November 24, 2004 9:39 AM
To: Nicolas Williams; Sam Hartman
Cc: [email-masked]
Subject: RE: SPNEGO SOMIC rules

-- Larry

-----Original Message-----

Yes, yes.

Nico
--