Subject: SPNEGO issues to be addressed in the next version

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Sun, 7 Nov 2004 22:05:15 -0800

As I promised, the next version should be out shortly after IETF61.

1) Sam: section 3.2 (b) and (d) seemed to be self inconsistent, this is
corrected/clarified now.

2) Sam and Martin: consideration of non-standard track mechanisms: if
the target does not support negotiation, should we return BAD_MECH or
DEFFECTIVE_TOKEN? 

3) Martin and Sam: the support of negotiation without integrity. Perhaps
this should be added back.

4) Sam, Ken, and Martin: SHOULD or MAY? on the use of optimistic token.
Wyllys requested an example where the optimistic token is not used. The
latest draft is updated with new details.

5) Sam and Martin: the support of partially established context, no
disagreement, but Martin suggested pre-emptive clarifications.

6) Sam and Wyllys: on the rules for when it is safe to omit MIC. This
was designed to interop with Windows2000/WindowsXP/Windows2003 SPNEGO
when there is no interference.  This is perhaps the most controversial
part of this draft. Sam and Wyllys were looking into these. We should
discuss these in details in the next few days.  I am putting down a
separate section to discuss these now.

7) Sam, further clarifications on how the MIC token is computed.

8) Sam, what is the possible use of extensibility marker

9) Wyllys: fair amount of editorial issues, these are fixed now.

10) Wyllys: should the MIC token be used to protect reqFlags as well?

11) Luke, should we use out-of-band mechanisms for SPNEGO to negotiate
whether the implementations are updated to support mechListMIC? Aka the
GSS_C_EXPECTING_MECH_LIST_MIC_FLAG GssChecksum flag.

-- Larry

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