16.3 CONCLUSIONS

Team-Fly

In this chapter, we overviewed and briefly discussed various application layer security protocols (either security-enhanced application protocols or authentication and key distribution systems). In Chapter 18, we talk about the end-to-end argument [48] that basically says that the application layer is the appropriate layer to provide services, such as security services.

From a theoretical point of view, the use of authentication and key distribution systems that provide a standardized API is advantageous, as it minimizes the parts that are application-specific and must be implemented for each application individually. But implementation and deployment of authentication and key distribution systems have turned out to be difficult and slow in practice. One of the main reasons is that applications and application programs must be modified to use the systems or the corresponding APIs (i.e., "Kerberized" in the case of the Kerberos system).

This modification is neither simple nor always possible. For example, if an organization is running a proprietary application for which it does not possess the source code, it is generally not possible to modify the application. Also, for applications that are available in source, the modification process is not always possible. Consequently, security-enhanced application protocols have become more and more popular during the last decade. For example, SSH is a very popular tool that is widely used as a security-enhanced replacement for Telnet and Rlogin in the intranet environment. Also, security extensions for the DNS (i.e., DNSSEC) are becoming increasingly important from the point of view of infrastructure security. Without a secure version of the DNS, almost all security technologies, mechanisms, and services can be circumvented by corresponding spoofing attacks.

In either case, adding security to an application protocol remains a difficult and error-prone task. To put it into the words of RFC 2316, "Security is not and cannot be a cookie cutter process. There is no magic pixie dust that can be sprinkled over a protocol to make it secure. Each protocol must be analyzed individually to determine what vulnerabilities exist, what risks they may lead to, what palliative measures can be taken, and what the residual risks are" [49].

Because of the difficulty of enhancing the application layer protocols with security features, it has become increasingly popular to leave the protocols as they are and to layer security on top of them. In Chapter 17, we overview and discuss some of the resulting message security protocols.

Team-Fly