RFC 3365 (rfc3365) - Page 3 of 8
Strong Security Requirements for Internet Engineering Task Force Standard Protocols
Alternative Format: Original Text Document
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
