Subject: Comments on Larry's SPNEGO draft

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 13:49:18 -0400

Section 3.2 (d) (I) is garbled.  

 Based on 3.2 (b) I don't understand how you ever get to rule 3.2 (d)
 (I) (3).  I believe the bug is in 3.2 (b) because I believe you should
 be able to get to this rule.

 In section 3.2 you claim:

    On receipt of a negotiation token on the target side, a GSS-API
       implementation that does not support negotiation would indicate
       the
          GSS_S_BAD_MECH status as if a particular basic security
       mechanism had
          been requested but was not supported.

That's actually not true; a mechanism could just as easily return
GSS_S_BAD_TOKEN in this state.  Actually there is a possibility
involving non-standards-track mechanisms that look a lot like the
SPNEGO mechanism where you could get other responses as well, but that
will not happen in practie.

There seem to be several significant semantic changes I'd like to call to the attention of the IETF.  I believe we need explicit consensus for these changes:

1) The use of optimistic negotiation is promoted to a SHOULD.  This
    simplifies the description of the protocol because you can
    generally assume that the client does support including the
    optimistic token.

2) The mechanism requires that all target mechs support integrity
    protection.  This is a significant change and is
    non-backward-compatible.

3) prot_ready is forbidden.  I believe this is required for things to
   work out correctly.

4) There is complexity to support omitting the MIC when appropriate.
   I'm not sure this is correct; I need to actually go through the
   same reasoning that Larry and the other Microsoft folks did.

5) The API in SPNEGO for determining what set of credentials you
   support is dropped and replaced with a reference to Nico's draft.

I'd like to suggest the following improvements to the draft:

1) Write an explanation of what's going on with the safe to omit MIC
   stuff that is sufficient for the rest of us to convince ourselves
   it is secure.

2) Write an explanation of what Windows 2000 did that is sufficient
   for us to confirm the claim in Appendix A that this should
   interoperate

3) Describe what the MIC is an encoding of; I think this is still
   unclear.

4) Describe when (if ever) you can take advantage of the extensibility
   markers you've added.

I think this is a great start on a new SPNEGO spec.

--Sam

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

---

From: Martin Rex <[email-masked]>
Date: Mon, 25 Oct 2004 21:22:13 +0200 (MET DST)

Sam Hartman wrote:
>     the GSS_S_BAD_MECH status as if a particular basic security
>     mechanism had been requested but was not supported.
> 
> will not happen in practice.

I'm sorry to disagree with you, Sam, but the quote paragraph seems
to be perfectly correct.

The initial context token MUST use the generic framing with the
mechanism OID for the precise reason that a gssapi mechanism will
be able to recognize whether it supports communication with the
peer or not.  If not, then GSS_S_BAD_MECH is the required
major status response.

Btw. GSS_S_BAD_TOKEN does not exist, did you mean GSS_S_DEFECTIVE_TOKEN?
If mechanism does not recognize the SPNEGO mechanism OID, then it can
not know what the rest of the token means, so GSS_S_DEFECTIVE_TOKEN
would be a mere guess and probably the wrong guess in 99.8%.
So it is not only prohibited to return GSS_S_DEFECTIVE_TOKEN,
it is also a pretty bad idea.

> 
> There seem to be several significant semantic changes I'd like
> to call to the attention of the IETF.  I believe we need explicit
> consensus for these changes:
> 

The reasoning is maybe that Microsoft has architected some protocols
with SPNEGO that need it badly (it must fail without optimistic
negotiation because the embedding protocol doesn't support an
additional round trip...).

When Denis Pinkas originally proposes SNEGO (without P for "protected")
they had a free sample implementation.  They didn't need the "P" for
their purposes back then, and I think they also didn't need the
optimistic negotiation either.

I have strong reservations against a SHOULD instead of a MAY, because
in the next round someone could try to turn this into a MUST, and
I definitely don't ever want to see a MUST there!

One of the easiest approaches to test whether an embedding protocol
that uses SPNEGO isn't entirely broken is to switch off the optimistic
token (adding another roundtrip to the security context establishment)
and checking whether everything still works just as smooth as it
is required to by the existing spec (which, as I mentioned, isn't true
for some uses architected by Microsoft).

SPGENO is only useful when it is allowed to negotiate, i.e. when it
is allowed to add round-trips to the security context exchange to
accomodate the negotiation.  If the embedding protocol doesn't have
provisions to accomodate that, then it is pointless to call SPNEGO,
it just adds complexity with zero value.

Essentially what I wanted to say:  The benefit of the optimistic token
should be obvious to implementors of SPNEGO.  The absence does not give
applications the permission to fail.  Technically, the MAY is perfectly
sufficient.

>     protection.  This is a significant change and is

Wasn't that already sufficiently addressed in the security considerations
of the existing spec?  I do NOT see a need to require integrity protection
either.

> 3) prot_ready is forbidden.  I believe this is required for things to

prot_ready was never easy, not even for the regular GSS-API.

The problem with prot_ready is the message sequencing interference
of SPNEGO's use of the get_mic() primitive with the applications
use of message protection facilities.

Except for the situation where the optimistic negotiation is used,
security context establishment consists of at most 2 token exchanges
and actually succeeds -- in all other situations the would be interference.

... and I need to read the document before commenting on the rest.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 16:24:00 -0400

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

    Martin> Sam Hartman wrote:
    >> That's actually not true; a mechanism could just as easily
    >> return GSS_S_BAD_TOKEN in this state.  Actually there is a
    >> possibility involving non-standards-track mechanisms that look
    >> a lot like the SPNEGO mechanism where you could get other
    >> responses as well, but that will not happen in practice.

    Martin> I'm sorry to disagree with you, Sam, but the quote
    Martin> paragraph seems to be perfectly correct.

    Martin> The initial context token MUST use the generic framing
    Martin> with the mechanism OID for the precise reason that a
    Martin> gssapi mechanism will be able to recognize whether it
    Martin> supports communication with the peer or not.  

Section 3.1 of RFC 2743 requires a specific context token framing for
IETF standards-track mechanisms.  However no such requirement is made
for non-standards-track mechanisms.  We're aware of non-standards
track mechanisms that do not use the framing described in this
section.

If the default mechanism happens not to be a standards-track
mechanism, it seems unreasonable to require that mechanism to
understand the IETF framing.  Moreover in particularly pathalogical
cases, the non-standards-track mechanism may have a context token that
conflicts in semantics with the IETF framing.  I believe this will
never happen in practice.

  However
    Martin> If not, then
    Martin> GSS_S_BAD_MECH is the required major status response.

Can you cite part of RFC 2743 that supports this claim?  The closest I
can find is section 2.2.2.  That section says that

   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks
   performed
      on the input_token failed, preventing further processing from
   being
      performed based on that token.

         o  GSS_S_BAD_MECH indicates receipt of a context
         establishment token
            specifying a mechanism unsupported by the local system or
         with the
            caller's active credentials.

I think both of these return status seem appropriate in the case where
the token does not correspond to the mechanism ID passed into
gss_accept_sec_context.  Our implementation returns
GSS_S_DEFECTIVE_TOKEN because the consistency check of confirming the
OID in the token header matches the expected value fails.  I suspect
other implementations return GSS_S_BAD_MECH.

I'd agree with a proposal to require that standards-track mechanisms
(or other mechanisms that use the IETF framing described in section
3.2) return GSS_S_BAD_MECH in this case.  However absent text in the
standard to the contrary, such a proposal would be a
change/clarification of current behavior.

--Sam

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Nov 2004 22:17:38 +0100 (MET)

Ooops -- blush.  You're correct, Sam.

> track mechanisms that do not use the framing described in this

And if I'm not mistaken, then there is actually a large installed base
of an SPNEGO implementation that may send security context tokens
from a non-IETF "mechanism" which does not use the generic
token framing.  That "mechanism" is also known as
Microsoft "NT Lan Manager" (NTLM).

So you're correct, implementations of SPNEGO that receive an initial
security context token from a non-IETF (gssapi) mechanism that lacks
the generic framing will likely return GSS_S_DEFECTIVE_TOKEN rather
than GSS_S_BAD_MECHANISM.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 16:59:26 -0400

>>  3) prot_ready is forbidden.  I believe this is required for
    >> things to work out correctly.

    Martin> prot_ready was never easy, not even for the regular
    Martin> GSS-API.

    Martin> The problem with prot_ready is the message sequencing
    Martin> interference of SPNEGO's use of the get_mic() primitive
    Martin> with the applications use of message protection
    Martin> facilities.

    Martin> Except for the situation where the optimistic negotiation
    Martin> is used, security context establishment consists of at
    Martin> most 2 token exchanges and actually succeeds -- in all
    Martin> other situations the would be interference.

I think we're in agreement here.

---

From: Wyllys Ingersoll <[email-masked]>
Date: Fri, 29 Oct 2004 13:51:07 -0400

My thoughts on the new SPNEGO draft...

Many of my comments are editorial, just trying to make it easier to read.
The original SPNEGO RFC was very difficult to read and follow in many places
and we should strive to make this draft easier to read and thus to implement.

Where are the SOMIC rules?  Is that a separate document or something?

-Wyllys Ingersoll

3.1 paragraph 3 -
    Seems contradictory when read the first time, could it be rewritten to be a little.
    clearer ?
    My suggestion...

	   The first negotiation token sent by the acceptor contains the result
	   of the negotiation (accept_completed, accept_incomplete or reject)
	   and, in case of accept, the agreed security mechanism.   If the first
	   proposed mechanism from the initiator was selected and the initiator
	   included an initial mechanism token, the response MUST include the
	   response mechanism token.   Otherwise, the target will not emit a
            response mechanism token in the first reply.

3.2 (d)(I)
     Would it add security if the GSS_GetMIC covered other fields from the
     NegTokenInit such as the reqFlags?

3.2 (d)(I)(2) garbled and unnecessarily verbose...
      Rewrite suggestion...
           2) If the initiator's preferred mechanism is accepted and
             policy exists on the target such that a different
             mechanism couuld have been selected given a different list of
             mechanisms, GSS_Accept_sec_context() MUST indicate
             GSS_S_CONTINUE_NEEDED with the accept_incomplete state, and
             a MIC MUST be generated by the target.  This MIC is to be
             verified by the initiator and the result will be sent back
             to the acceptor.  This is referred in this document as the
             Safe to Omit MIC (SOMIC) rule number 2.  The resulting
             negotiation token MUST include the security token if one is
             returned by the selected mechanism.

3.2 (d) (III)
     s/mechanism is sent/mechanism was sent/
     s/token need to be transferred/token needs to be transferred/
     s/establish the context,/establish the context./

3.2 (e) - is this paragraph necessary?  All of the scenarios from 3.2 (d)
      already explain that the target app must return the negotiation token to the
      intiator.

3.2 (f) (III)
      When you say "deposit the security token" - what does this mean, where is
      it being deposited?  The rest of this section is a little unclear as well.
      suggestion...

          When the negotiation token carries a reject result with a
          response security token, the initiator MUST deposit the
          security token.  GSS_Init_sec_context() MUST indicate a
          failure status as reported by the underlying mechanism, and the
          mech_type output parameter from GSS_Init_sec_context must
          indicate the mechanism that was rejected.

3.2 (f) (IV)
       s/complete context establishment,/complete context establishment./

3.2 (f) (V)
       s/mechanism token/mechanism tokens/
       s/establishment, the/establishment. The/

3.2 (h) Perhaps clarify that the "mech_type" output param is for the
     GSS_Init_sec_context call.  Its easy to become disoriented with all of the
     various talk of "mech types" being passed around.

4.2.2 paragraph 6 under "negResult" is a little confusing.
      suggestion...

          For those targets that support piggybacking the initial
          mechToken, an optimistic negotiation response is possible. This
          response includes a responseToken which MAY continue the
          authentication exchange (e.g.  when mutual authentication has
          been requested or when unilateral authentication requires
          several round trips).  Otherwise the responseToken is used to
          carry the tokens specific to the mechanism selected.

4.2.2 paragraph 7 - The MIC should include the reqFlags as well as the MechTypes.

Appendix A paragraph 1
       s/should be ale/should be able/

Under what circumstance would an app NOT do optimistic negotiation?  I'm
sure there are examples, but maybe it would be good to document a situation
where optimistic negotiation could not be used.