Subject: RE: Issues in SPNEGO-bis draft 00

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Tue, 23 Nov 2004 16:28:39 -0800

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.

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

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

Luke Howard wrote:
> In our implementation the acceptor treats the absence of negResult as
equivalent to the initiator sending 
> accept_incomplete.

This is reasonable. The case of interest was in handling the third leg
of DCE-kerberos, but fortunately the algorithm for that case in the
current draft does not rely on the presence of this field. Thus we do
not need further change for this.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Luke Howard
Sent: Tuesday, November 23, 2004 2:20 PM
To: [email-masked]
Subject: Re: Issues in SPNEGO-bis draft 00

>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

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 23 Nov 2004 20:12:14 -0500

I agree with Larry's proposed change.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 23 Nov 2004 23:54:19 -0600

>       preferred mechanism, the mechlistMIC token is OPTIONAL.

This seems redundant and confused me earlier.  See below.

>          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: Luke Howard <[email-masked]>
Date: Wed, 24 Nov 2004 17:42:09 +1100

>second and third SPNEGO tokens, if those are required.

And the server's mechListMIC is sent in the second SPNEGO token rather
than the fourth.

eg.

C: negTokenInit { mechTypes = {foo}; mechToken = {only mech token}}
S: negTokenResp { negResult = request_mic; supportedMech = foo; mechListMIC = {MIC}}
C: negTokenResp { negResult = accept_completed; mechListMIC = {MIC}}

-- Luke

--