RFC 3365 (rfc3365) - Page 3 of 8

Strong Security Requirements for Internet Engineering Task Force Standard Protocols

RFC 3365            Encryption Security Requirements         August 2002


   * Data integrity service: A security service that protects against
     unauthorized changes to data, including both intentional change
     (including destruction) and accidental change (including loss), by
     ensuring that changes to data are detectable.

4.  Some Properties of the Internet

   As mentioned earlier, the Internet provides no inherent security.
   Enclaves of networking exist where users believe that security is
   provided by the environment itself.  An example would be a company
   network not connected to the global Internet.

   One might imagine that protocols designed to operate in such an
   enclave would not require any security services, as the security is
   provided by the environment.

   History has shown that applications that operate using the TCP/IP
   Protocol Suite wind up being used over the Internet.  This is true
   even when the original application was not envisioned to be used in a
   "wide area" Internet environment.  If an application isn't designed
   to provide security, users of the application discover that they are
   vulnerable to attack.

5.  IETF Security Technology

   The IETF has several security protocols and standards.  IP Security
   (IPsec [RFC 2411]), Transport Layer Security (TLS [RFC 2246]) are two
   well known protocols.  Simple Authentication and Security Layer (SASL
   [RFC 2222] and the Generic Security Service Application Programming
   Interface (GSSAPI [RFC 2743]) provide services within the context of a
   "host" protocol.  They can be viewed as "toolkits" to use within
   another protocol.

   One of the critical choices that a protocol designer must make is
   whether to make use of one of the existing protocols, engineer their
   own protocol to use one of the standard tools or do something
   completely different.

   There is no one correct answer for all protocols and designers really
   need to look at the threats to their own protocol and design
   appropriate counter-measures.  The purpose of the "Security
   Considerations" Section required to be present in an RFC on the
   Internet Standards Track is to provide a place for protocol designers
   to document the threats and explain the logic to their security
   design.






Schiller                 Best Current Practice