Re: Authentication issue CNONCE: Proposed resolution
Scott Lawrence (lawrence@agranat.com)
Fri, 07 Aug 1998 17:38:56 +0000
Paul Leach wrote:
>
> This is a MUST on the client in order for it to ensure its own
> security, not in order to interoperate. It imposes no burden on
> servers.
>
> In order to be safe, it is indeed true that the client should never
> send the same value, even to different servers. If a server can
> predict what the client will send, then we're back in
> chosen-plaintext-attack land.
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
7. Security Considerations
These terms are frequently used to specify behavior with security
implications. The effects on security of not implementing a MUST or
SHOULD, or doing something the specification says MUST NOT or SHOULD
NOT be done may be very subtle. Document authors should take the time
to elaborate the security implications of not following
recommendations or requirements as most implementors will not have
had the benefit of the experience and discussion that produced the
specification.
I read that to say that no matter how we write it up we have to have
something in the security considerations section that says that if you blow
this part you are messing yourself up. It is my personal preference that we
not use MUST where there is no harm to interoperability or to other parties
- shooting yourself in the foot should be allowed. I am concerned that (as
Daves query exemplifies) using a MUST may mislead servers into thinking that
there is something there to enforce, which is not our intent.
That having been said - you make the call Paul; I can live with it either
way.
--
Scott Lawrence Consulting Engineer <lawrence@agranat.com>
Agranat Systems, Inc. Embedded Web Technology http://www.agranat.com/