Re: Authentication issue CNONCE: Proposed resolution

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.

>From RFC 2119 RFC Key Words:

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/

Received on Friday, 7 August 1998 10:40:40 UTC