Subject: Security Considerations for SPNEGO

From: Sam Hartman <[email-masked]>
Date: Sat, 13 Nov 2004 18:13:45 -0500

Eventually I'm going to have to take the SPNEGO document to the IESG
and convince them that what we propose is secure.  I'll also have to
convince them that the complexity Larry is introducing is necessary.
I will need the cooperation of the working group in several areas in
order to do that.  I think that providing answers to the questions I'm
asking will also help all of us be sure that we are approaching the
problem reasonably.

Larry is introducing rules describing when it is safe to omit the MIC.
Before the first rule is presented, the document needs to explain why
we are introducing this complexity.  I believe that the answer is
roughly that we are able to maintain interoperability with older
broken implementations of the SPEC while maintaining the security
guarantees if we introduce this complexity.  Presumably we believe
this interoperability is necessary to get the new version deployed.

We should have an answer to the question of why we don't provide a
simple solution in the case where the implementation is known to be
new.  We could choose to offer such a solution.  We could also decide
that an optional simple mode would be more error-prone than always
requiring the complexity.

Next, in the security considerations section, the document must
explain what security guarantees SPNEGO will make.  The document must
argue that Larry's rules will meet these guarantees.

--Sam

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