Subject: RE: Issues in SPNEGO-bis draft 00

From: Luke Howard <[email-masked]>
Date: Thu, 25 Nov 2004 09:16:04 +1100

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

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.

-- Luke

--

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

---

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

> 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