Subject: Re: Issues in SPNEGO-bis draft 00

From: Luke Howard <[email-masked]>
Date: Wed, 24 Nov 2004 09:20:16 +1100

>Folks, I have great news to report: Luke Howard implemented SPNEGO-bis
>in Heimdal, and we have the protocol verified independently. 

Of course, the proof will be in the pudding (when we do some interop
testing).

>Also "negResult" field need to remain OPTIONAL based on Luke's
>experiments.

This behaviour may only be necessary for Windows interop. If is
optional then the behaviour should be specified.

In our implementation the acceptor treats the absence of negResult
as equivalent to the initiator sending accept_incomplete.

-- Luke

--

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

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Tue, 23 Nov 2004 22:43:18 -0800

Nicolas Williams wrote:
> >       In the case that the optimistic
> >       mechanism token is the only mechanism token for the
initiator's
> >       preferred mechanism, the mechlistMIC token is OPTIONAL.

> This seems redundant and confused me earlier.  See below.

This is clear if we see the whole text together:

   c) In the case that the chosen mechanism uses an odd number of
      mechanism tokens (namely the initiator sends the last mechanism
      token), the initiator does the following when emitting the
      negotiation message containing the last mechanism token: if the
      negResult state was request_mic in the first reply from the
      target, a mechlistMIC token MUST be included, otherwise the
      mechlistMIC token is OPTIONAL.  In the case that the optimistic
      mechanism token is the only mechanism token for the initiator's
      preferred mechanism, the mechlistMIC token is OPTIONAL.
      GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED.
      Initiators who wish to be compatible with legacy Windows SPNEGO
      implementations as described in Appendix B shall not generate a
      mechlistMIC token when the MIC token exchange is not required.
      The acceptor then processes the last mechanism token, and does one
      of the following:

As you can see that the first sentence below is sufficient for
describing the "rules": 

      if the
      negResult state was request_mic in the first reply from the
      target, a mechlistMIC token MUST be included, otherwise the
      mechlistMIC token is OPTIONAL.

The second sentence as you pointed out is indeed redundent, but was
added as clarifications only, it is not "normative".

> I agree.  But it might be better to state that this case is like the
other odd-mech-token exchanges, only > 
> responseToken is missing from the second and third SPNEGO tokens, if
those are required.

This case is different only in that the last mechanism token is not
accompanied with a mechlistMIC when the MIC token exchange is
*required*.

Yes, you might be able to deduce this from the rest of rules, but this
stanza would make it easier for implementers to interpret the rules.

> Would it be safe to make it DEFAULT to the accept-incomplete value?

The rules do not rely on the value of this field (except that of the
first reply, where this field is required), this is because this field
is not protected. 

I made small adjustments below to make this a bit clearer.

4.2.2  negTokenResp

       NegTokenResp ::= SEQUENCE {
           negResult       [0] ENUMERATED {
               accept_completed    (0),
               accept_incomplete   (1),
               reject              (2),
               request_mic         (3)
           }                                 OPTIONAL,
             -- REQUIRED in the first reply from the target
           supportedMech   [1] MechType      OPTIONAL,
             -- present only in the first reply from the target
           responseToken   [2] OCTET STRING  OPTIONAL,
           mechListMIC     [3] OCTET STRING  OPTIONAL,
           ...
       }

   This is the syntax for all subsequent negotiation messages.

   negResult

         This field, if present, contains the state of the negotiation.
         This can be:

         accept_completed
            No further negotiation message from the peer is expected,
            and the security context is established for the sender.

         accept_incomplete
            At least one more negotiation message from the peer is
            needed to establish the security context.

         reject
            The sender terminates the negotiation.

         request_mic
            The sender indicates that the exchange of MIC tokens, as
            described in Section 5, will be REQUIRED if per-message
            integrity services are available on the mechanism context to
            be established.  This value SHALL only be present in the
            first reply from the target.

Zhu, et al.               Expires May 24, 2005                 [Page 11]


         This field is REQUIRED in the first reply from the target, and
         it is OPTIONAL thereafter.

-- larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Tuesday, November 23, 2004 9:54 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]
Subject: Re: Issues in SPNEGO-bis draft 00

On Tue, Nov 23, 2004 at 04:28:39PM -0800, Liqiang(Larry) Zhu wrote:
> The original email did not get through, so here I sent again.
> 
> =======
> Luke found that it was underspecified what to do if the mechanism has 
> a single mechanism token, to address that, I added the following text:
> 
>       
> Section 5, c)
> 
> 
>       In the case that the optimistic
>       mechanism token is the only mechanism token for the initiator's
>       preferred mechanism, the mechlistMIC token is OPTIONAL.

This seems redundant and confused me earlier.  See below.

>       (IV) In the case that the optimistic mechanism token is also the
>          last mechanism token (when the initiator's preferred
mechanism
>          is accepted by the target), and the target sends a
request_mic
>          state, the target MUST include a mechlistMIC token in that
>          first reply.  GSS_Accept_sec_context() indicates
>          GSS_S_CONTINUE_NEEDED.  The initiator MUST then verify this
>          mechlistMIC token, and generate a mechlistMIC token to send
>          back to the target, who SHALL in turn verify the returned
>          mechlistMIC token and complete the negotiation.

I agree.  But it might be better to state that this case is like the
other odd-mech-token exchanges, only responseToken is missing from the
second and third SPNEGO tokens, if those are required.

> Also "negResult" field need to remain OPTIONAL based on Luke's 

Would it be safe to make it DEFAULT to the accept-incomplete value?

Nico
--

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Wed, 24 Nov 2004 13:37:53 -0800

Martin Rex wrote:
>  The following description extends a single-token security context
establishment into a 3-token security context 
> establishment.

Have you noticed that the protocol can end up with two negotiation
messages/tokens in the following two ways?

1) The initiator includes a mechlistMIC token in the first message.
2) The acceptor omits the mic_token exchange because it is safe to do
so.

You can avoid the third token if you do one of the above, but this
protocol allows having at most 3 tokens in the worst scenario (not in
the above two cases).

By the way, the vanilla 2478 allows 4 tokens for the above single
mechanism token case (2 tokens for negotiation, then one for the
mechanism token, another for the mechlistMIC), right?

-- Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, November 24, 2004 1:29 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]
Subject: Re: Issues in SPNEGO-bis draft 00

I'm sorry for replying before having read Larry newest draft:

The following sounds incompatibly strange to me:  rfc2478 did extend a
security context establishment by at most one token if the optimistic
token was used and was accepted by the acceptor.

The following description extends a single-token security context
establishment into a 3-token security context establishment, which is a
significant change from rfc2478 and incurs an additional round-trip,
something that rfc2478 tried to avoid.

-Martin

mechanism
request_mic

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Wed, 24 Nov 2004 15:40:03 -0800

Haven't we explicitly masked out prot_ready_state in section 3.1?

   To avoid conflicts with the use of MIC tokens by SPNEGO,
   partially-established contexts are not used for per-message calls:
   the prot_ready_state [RFC2743] will be false even if the underlying
   mechanism would return true natively.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, November 24, 2004 3:31 PM
To: [email-masked]
Cc: Liqiang(Larry) Zhu; [email-masked]; [email-masked]
Subject: Re: Issues in SPNEGO-bis draft 00

> >so.
> 
> Martin argues that in 2) the server should not send back a response.
> 
> I haven't looked at RFC 2478 closely, but it seems to me that even in 
> in this case case the server should send back a NegTokenResp with the 
> negResult (accept_completed) and supportedMech elements.
 
What I'm actually worried about is the synchronization of when both
sides think the security context establishment is complete.

Because once the security context establishment is complete, the
implementation must return GSS_S_COMPLETE from either
gss_init_sec_context() or gss_accept_sec_context() and at that point the
application is free to start using the message protection facilities.

Different from GSS-API v2,  a GSS-API mechanism is therefore not longer
permitted to return an additional (=optional) security context token,
because that would create a prohibited interference of the applications
permitted use of the message protection primitives after GSS_S_COMPLETE
and SPNEGOs use of gss_getmic() to integrity protect the mechListMIC.

So basically the negotiation token must reflect the state information
whether an additional security token MUST be sent by the peer, or
whether it MUST NOT be sent.  There is no option.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 25 Nov 2004 00:50:56 +0100 (MET)

Martin.Rex wrote:
> Maybe I was just confused by the wording above?
> 
> Omitting a token exchange would break the architecture.
> Omitting a specific content in a token exchange (like a particular
> mechListMIC) would be ok.

Ooops, I meant to say that Omitting a specific content in a token
exchange would be ok with the GSS-API architecture.

One would still have to check whether it breaks the SPNEGO protection
promise or backwards compatibility.

-Martin