Subject: SPNEGO SOMIC rules

From: Wyllys Ingersoll <[email-masked]>
Date: Thu, 11 Nov 2004 10:42:07 -0500

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.

-Wyllys

ACCEPTOR RULES
1. The initiators preferred mech is accepted by the target and acceptor
    could not have selected anything else no matter what the
    initiators sent.  Initiator included initial token and no further
    input is needed from initiator.
         - MUST NOT send MIC back to initiator
         - return GSS_S_COMPLETE

[ in short: if the target supports only 1 mechanism, and that is what
   the initiator requested, then no need for a MIC as long as
   no additional initiator tokens are needed ]

2. Initiators preferred mech is accepted, but the acceptor *could*
    have selected  a different mech if a different list had been presented.
         - send MIC and "accept incomplete" status if initial token
           was included and no further tokens are needed from initiator.
         - do NOT send MIC if initial token was not included or
           additional initiator tokens are needed.

3. Initiators non-preferred mech is accepted.
         - acceptor returns GSS_S_CONTINUE_NEEDED with negotiation token
           and "accept_incomplete" status and the selected mechanism OID.
         - no MIC in response and no response mechanism token.

INITIATOR RULES

4. Initiator gets "accept complete" from target, the selected mech
    is the original preferred mech.
         - initiator SHALL NOT reject if no MIC is present.
            * this rule is to maintain backwards compatibility ?
         - if MIC present, verify and return GSS_S_BAD_MIC if incorrect.

5. Initiator gets "accept complete" from target, but the selected mech
    is not the preferred mech and no MIC or incorrect MIC is present.
         - return GSS_S_BAD_MIC status

6. Initiator gets "accept_incomplete" and no further tokens from
    target are required to complete the context establishment.
         - if target returned a MIC, initiator must verify it
           and return GSS_S_BAD_MIC if it fails.  If MIC verifies
           correctly, return GSS_S_COMPLETE.
         - if target did not include a MIC, initiator must indicate
           GSS_S_BAD_MIC status.

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

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 11 Nov 2004 11:12:38 -0500

I am aware that Larry has spent a great deal of time over the last
couple of days working on the SPNEGO draft and the SOMIC rules in
particular.  I suggest we hold off discussions until Larry is able
to post an updated draft next week.

Jeffrey Altman

---

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Nov 2004 15:34:49 -0500

>>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:

    Jeffrey> I am aware that Larry has spent a great deal of time over
    Jeffrey> the last couple of days working on the SPNEGO draft and
    Jeffrey> the SOMIC rules in particular.  I suggest we hold off
    Jeffrey> discussions until Larry is able to post an updated draft
    Jeffrey> next week.

I actually think Larry should also post a summary of the discussions
as well as the draft.

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Nov 2004 22:41:24 +0100 (MET)

> 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

---

From: Wyllys Ingersoll <[email-masked]>
Date: Fri, 12 Nov 2004 16:42:02 -0500

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

Sorry about that.  I think there were several off-list conversations about
this stuff at IETF this past week.  Once everyone returns and has time to
digest it all, I believe a proper summary will appear on this list and in
an updated draft.

For now, I won't bother trying to explain my previous summary since
some of what I wrote was already out of date when I wrote it.

-Wyllys

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 12 Nov 2004 17:07:34 -0500

> why this particular omission does not open a vulnerability.

Martin:

The IETF meeting just finished and everyone is traveling.  Please
give Larry a few days to return to Microsoft and send an update to
the list with a summary of the in-person discussions.  I think it
will clear things up quite a bit.

As for requiring a MIC in all cases, this is a problem if we want
to ensure interoperability with the existing deployed implementations.
In the meeting there was strong consensus that interoperability is
a desired goal.  I believe that it is possible for us to maintain
a limited set of situations in which it is safe for the MIC to be
omitted.  I will give Larry time to explain early next week in a
revised draft.

Thanks.

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Nov 2004 23:17:55 +0100 (MET)

> some of what I wrote was already out of date when I wrote it.

OK.

The purpose of the protection in SPNEGO was to assure *BOTH* sides
that the negotiation wasn't doctored by an active attacker.  The
mechListMic is supposed to provide this assurance for both at least
as long as the receiver of the mechListMIC will reliably abort
when either the mechListMIC is missing or when it doesn't match.

You will break the general scheme as soon as you allow one side to
continue without having either sent a mechListMIC or received
and verified a mechListMIC.

Therefore, if it is to be permitted -- an explanation is necessary
why or how there still is **MUTUAL** assurance that the negotiation
was not doctored.

Keep in mind that the initiator never knows which or how many
mechanisms the acceptor has available.

An active attacker would be able to modify the initial token sent
by the initiator (remove mechanisms, reorder mechanisms, remove
optimistic token), and remove a mechListMic from later negotiation
tokens.

Personally, I have the feeling that allowing the omission of the
mechListMic token breaks the protection scheme...

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 12 Nov 2004 18:23:21 -0500

Martin:

Please be assured that the working group, myself and the area
directors are very aware of the requirement to ensure that only
cases in which we can prove that both the client and server will
choose the desired mechanism without outside influence can be
sent without a MIC.  There are a sufficient set of cases in which
this is true that we can provide interoperability with the existing
deployed implementations in the common cases.

I expect you will be happy with the outcome.

Jeffrey Altman

---

From: Sam Hartman <[email-masked]>
Date: Sat, 13 Nov 2004 18:04:56 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    >>  Sorry about that.  I think there were several off-list
    >> conversations about this stuff at IETF this past week.  Once
    >> everyone returns and has time to digest it all, I believe a
    >> proper summary will appear on this list and in an updated
    >> draft.
    >> 
    >> For now, I won't bother trying to explain my previous summary
    >> since some of what I wrote was already out of date when I wrote
    >> it.

    Martin> OK.

    Martin> The purpose of the protection in SPNEGO was to assure
    Martin> *BOTH* sides that the negotiation wasn't doctored by an
    Martin> active attacker.  The mechListMic is supposed to provide
    Martin> this assurance for both at least as long as the receiver
    Martin> of the mechListMIC will reliably abort when either the
    Martin> mechListMIC is missing or when it doesn't match.

Thanks for hitting so quickly on the crux of the issue.
I'd like your help in understanding exactly which guarantee SPNEGO makes.

I'd like to draw your attention to section 3.2.2 of RFC 2478.  This
section describes the processing of the mechListMIC field.  Let's
consider a mechanism with an even number of tokens.

If I'm reading that section correctly, then the acceptor will return
the mechListMIC to the initiator at the same time it returns complete
to the application.  In particular, it seems like an attacker could
change the initiator's mechanism list and the acceptor would still
return complete to its application.  The initiator could never be made
to return complete  to its application.

Still, this attack would be valuable against a protocol that used GSS
authentication but did not later use gss_wrap or gss_getmic.

Is my understand correct?  If so, it sounds like the guarantee that
RFC 2748 makes is that at least one party must fail the authentication
if the negotiation is attacked, but the other party may complete the
negotiation.

Thanks,

--Sam

---

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

> I expect you will be happy with the outcome.

I'm not so sure whether there really are situation where the
mechListMic can be omitted without loosing the protection.

As Wyllys indicated, an acceptor might want to use a different mechanism
even if it supports the optimistic token provide by the initiator,
so the mechListMIC is even required for the case where the acceptor
uses the optimistic token in order to ensure that the acceptor
really got to see the undoctored mechanism list of the client.

-Martin

---

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

> if the negotiation is attacked, but the other party may complete the

Yes, this is correct.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Nov 2004 10:53:59 -0600

> mechListMic can be omitted without loosing the protection.

The meta-rule is this:

    If the acceptor selects the initiator's preferred mechanism (i.e.,
    the first one on the mechList) and there is no mechanism which, had
    it been present in mechList, the acceptor wouldn't have preferred
    over the initiator's preferred mech, then no mechListMIC exchange is
    needed.

The reason this works is that though an MITM may change the mechList
seen by the acceptor, as long as what it did had no material impact on
the negotiation then the attack is irrelevant.  And if the attack would
have a material impact on the negotiation, then one, the other or both
peers will insist on a mechListMIC exchange (unless both are legacy
implementations).

This rule translates easily into actual rules to be implemented by
initiators and acceptors.  The interesting twist is how to perform the
mechListMIC exchange in a way that is, er, friendly to legacy
implementations.  I'll let Larry provide the remaining details, and
maybe an alternate view of the above.

> really got to see the undoctored mechanism list of the client.

The meta-rule applies, and works, regardless of whether the initiator
sends an optimistic context token or not.

Nico
--

---

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 16 Nov 2004 12:03:14 -0500

> really got to see the undoctored mechanism list of the client.

I do think it is safe to omit the MIC in certain situations.
For example, the initiator sends only 1 mechanism in the list.
If the acceptor returns a token for a different mech, the client would
just reject this immediately and the that session would fail.  Even if a
MITM had altered the list and the acceptor chose the altered mech list,
the initiator would notice the change and kill the session, so the
attack effectively would have failed.

Forcing the use of the MIC in all cases will certainly break backwards
compat, so we are trying hard to define this such that backwards
compat is maintained in addition to clarifying the spec and making
it more secure for future implementors.

-Wyllys

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Nov 2004 20:24:53 +0100 (MET)

> attack effectively would have failed.

That's an assessment that an observer with meta-knowledge can do!

However where is the programmatic assurance for the acceptor in
this case that the client only supports a single mechanism
(and not more, but the others got removed from the list by an attacker).

Your example looks like a situation where the "protection" of
the negotiation is lost.

> it more secure for future implementors.

Forcing the MIC will *NOT* break backwards compatibility, but
removing the requirement will undoubtedly break backwards compatibility!

Forcing the MIC unconditionally as in the original spec may break
interoperability with an installed based of a particular broken
implementation.

You have to keep in mind that not all implementors of an IETF spec are
going to participate in IETF discussions or activities!  In fact, in
the GSS-API area, the majority of vendors that have done interoperability
certification with our app based on the GSS-API v2 spec are *NOT*
active in the IETF.

So just because *we* here only know about one particular broken
implementation doesn't mean that there are correct implementations
out there that we're going to break by making a non-backwards
compatible change of the spec.  And that change is *NOT* to fix
the spec (in fact, from the engineering point of view this change
is a bad idea), but to get around fixing that one broken implementation.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Tue, 16 Nov 2004 15:25:43 -0500

Martin> Wyllys Ingersoll wrote:
    >> If the acceptor returns a token for a different mech, the
    >> client would just reject this immediately and the that session
    >> would fail.  Even if a MITM had altered the list and the
    >> acceptor chose the altered mech list, the initiator would
    >> notice the change and kill the session, so the attack
    >> effectively would have failed.

    Martin> That's an assessment that an observer with meta-knowledge
    Martin> can do!

    Martin> However where is the programmatic assurance for the
    Martin> acceptor in this case that the client only supports a
    Martin> single mechanism (and not more, but the others got removed
    Martin> from the list by an attacker).

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.

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.

---

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

> Again, how the client demands a MIC is something Larry's draft will

OK, I'll wait and see.

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

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: Sam Hartman <[email-masked]>
Date: Tue, 16 Nov 2004 16:02:56 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

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

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

we need to mandate that a server receieving a normal mechanism token
but expecting an SPNEGO token should respond appropriately if we're
going to allow this optimization.  I don't mind mandating that, but I
don't think we do today.

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Nov 2004 22:21:29 +0100 (MET)

> going to allow this optimization.  I don't mind mandating that, but I

It has always been a(n implicit) requirement that SPNEGO makes a well-behaved
multi-mechanism with the underlying real gss-api mechanisms,
i.e. that the OID in the generic framing of the initial security
context token is passed to and processed by the respective
gssapi mechanism on the server side.

-Martin

---

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 16 Nov 2004 16:25:49 -0500

> and will become interoperable with peers that do not support SPNEGO.

Technically it's not broken, though it is clearly not a very useful or efficient
use of the protocol.

> when doing the HTTP-authentication, he claimed this should work.

I believe IIS does indeed handle this correctly.   If you send IIS a
GSSAPI/Kerberos initial token without SPNEGO, it will accept it and respond with
GSSAPI/Kerberos tokens accordingly.    I have tested this myself
in the past.  This is how Mozilla is able to implement Microsoft's
HTTP "Negotiate" authentication without requiring SPNEGO on the
clients, it just sends GSSAPI/KRB5 tokens instead.

> compatibility with correct implementations of SPNEGO (which may exist).

Right.

-Wyllys

---

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 16 Nov 2004 16:28:29 -0500

> going to allow this optimization.  I don't mind mandating that, but I

Perhaps there should be some sort of statement in the new SPNEGO
draft that clearly states that initiators who only send 1 mech in the
mechlist should not use SPNEGO at all and just use their preferred
mechanism.  Likewise, servers that accept SPNEGO should also be
able to accept initial tokens for any of their supported mechanisms
without SPNEGO wrapping.

-Wyllys

---

From: Martin Rex <[email-masked]>
Date: Wed, 17 Nov 2004 19:18:00 +0100 (MET)

When it was designed, SPNEGO was *NOT* supposed to be an additional
protocol layer, but instead a special-purpose pseudo- mechanism
of a gssapi multi-mechanism implementation.  As an additional protocol
level, it would require a flag day, while as a multi-mechanism there
is a migration path (i.e. you start adding SPNEGO to the servers
and later on clients at your convenience, still maintaining
interoperability with non-SPNEGO clients because of the
multi-mechanism capabilities of GSS-API where the server/acceptor
recognizes the actual gssapi mechanism by looking at the mechanism
OID in the initial security context token. 

Maybe we should explicitly describe this in the successor document
as the absence of this appears to have caused some people to
make flawed assumptions.

It seems that I also forgot about one special feature of SPNEGO
which the SESAME guys were actually using:  "mechanism variants".
Although it's a non-portable (implementation specific) extension,
I have no objections.

Therefore, I would appreciate something like a "MAY" or at most
a "SHOULD" for entirely omitting SPNEGO framing when there's only
a single mechanism availble for the initiator, but never a MUST.

Quoting from rfc2478:

   2.  NEGOTIATION MODEL

   2.1.  Negotiation description

      The model for security mechanism negotiation reuses a subset of the
      concepts specified in [2].

      Each OID represents one GSS-API mechanism or one variant of it.

Did anyone wonder what the "variant of it" was supposed to mean?

When the guys from Bull designed SNEGO (the protection "P" was added
to their proposal when it was disussed in the cat-ietf wg), then
they did not only use it to negotiate among seperate mechanisms,
but also for variants of a single mechanism (their mechanism seemed
to lack the capability to negotiate crypto algorithms).  So they
proposed to append further elements to the gssapi mechanism ASN.1 OID
to indicate crypto algorithms (QOPs) or other mechanism specific
options (in a non-portable fashion).  The original description was
dropped from rfc2478, but I assume it was used like that by SESAME.
(When the SNEGO proposal was originally brought up (~1997), there was
 a sample implementation available for download from Bull.)

The original text about mechanism variants was this:

    As most existing GSS-API security mechanisms can support different
    options (such as differing cryptographic algorithms due to policy or
    legislative constraints), the Simple and Protected GSS-API Negotiation
    Mechanism allows to negotiate security mechanisms including their
    options (i.e. variants). Mechanism options can be considered as
    providing a type of "quality of protection" for security contexts.
    
    To facilitate mechanism negotiation, the OID which currently defines a
    security mechanism is "extended" to be able to specify options within a
    security mechanism rather than simply the basic mechanism. When the OID
    specifies the mechanism only and no explicit option, then this means
    that the default option is used. The default option and the specific
    options for a given mechanism are as defined in the IETF GSS-API
    specification(s) for the mechanism.
    
    This allows to negotiate basic security mechanisms, different options
    within a given security mechanism or different options from several
    basic security mechanisms.

That approach was dropped from the spec by the cat-ietf wg because
would have

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Nov 2004 13:37:48 -0500

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.

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 17 Nov 2004 15:27:18 -0600

> we're getting to a point where we need a single version of that

Yes, yes.

> anything that can influence the choice of mechanism.)

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

Nico
--