Subject: SPNEGO-bis: a summary of discussions at the DC and changes since -00

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Mon, 22 Nov 2004 00:18:05 -0800

The updated version was submitted, and it was based on discussions we
had at IETF61. 

The following is a summary of major changes since -00.  This is also the
summary of the discussions among Sam, Wyllys, Nico, Jeff, me and others
at the Washington DC.

1) The support of security mechanisms that do not support integrity
services is back.
2) The request_mic state is added as an optimization for avoiding an
extra message.
3) The MIC request now contains a MIC itself.
4) The security invariants are summarized in the security
considerations, and the security of SPNEGO is discussed.
5) Legacy windows SPNEGO implementations are described.
6) Discussions on extensibility were added.
7) The Safe-to-omit MIC rules are consolidated into a separate/new
section.
8) Out-of-band negotiation as mentioned by Luke did not make into this
version (was not considered needed).
9) The computation of mechlistMIC is further clarified.
10) Discussions on the use of the optimistic token were added: pros and
cons.
11) The use of reqFlags remains unchanged.

Note that implementers can promote the "OPTIONAL" MIC token exchange to
be "REQUIRED", if so desirable. 

The complexity as the result of maintaining backward compatibility is
kept to minimal.

Thanks,

-- Larry

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

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 22 Nov 2004 09:20:46 -0500

> 1) The support of security mechanisms that do not support integrity

Although this decision has not been validated on the list yet, according 
to the minutes of the IETF 61 meeting there was a strong preference to 
maintain the MUST NOT restriction on the use of security mechanisms 
without integrity protection.

I will also point out that no consensus has yet been reached on whether 
the use of an optimistic token in SPNEGO will be SHOULD or MAY in the 
document.

I will be issuing a CALL FOR CONSENSUS on these issues and other 
decisions from IETF 61 later today.

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Mon, 22 Nov 2004 22:49:57 +0100 (MET)

> without integrity protection.

... MUST NOT ... without ...
I'm not sure I understand.

Keep in mind that base GSS-API does not have a MUST support integrity
protection, so a requirement in SPNEGO would exclude those mechanisms
entirely from negotiation.

Personally, I think the warning in the security considerations that
the absense of integrity protection on any single mechanism of the
clients mechanism list makes the handshake vulnerable to a
downgrade attack should be sufficient.

> the use of an optimistic token in SPNEGO will be SHOULD or MAY in the 

My clear preference is to stick with MAY, as in the original SPNEGO spec.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Nov 2004 17:24:15 -0500

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

    Martin> Personally, I think the warning in the security
    Martin> considerations that the absense of integrity protection on
    Martin> any single mechanism of the clients mechanism list makes
    Martin> the handshake vulnerable to a downgrade attack should be
    Martin> sufficient.

Speaking as an individual, I agree.

--Sam