5.6 Conclusions

In this chapter we overviewed and briefly discussed some cryptographic security protocols that can be used to provide communication security services for TCP/IP-based networks. While most of these protocols are similar in terms of security services they provide as well as cryptographic algorithms and techniques they employ , they vary fundamentally in the manner in which they provide the security services and their placement within the TCP/IP communications protocol suite. In particular, we have seen protocols for the network access, Internet, transport, and application layer.

Given this variety of cryptographic security protocols, we ask at least two questions:

Which security protocol is the best?
Which layer is best suited to provide communication security services?

With regard to the first question, the cryptographic security protocols have unique and partly incomparable advantages and disadvantages. For example, the IPsec and IKE protocols provide support for many parameters and options that are negotiable between the communicating peers, whereas the SSL and TLS protocols are rather strict in terms of parameters and options that must be implemented and supported. Given this situation and its diversity, it is very difficult or even impossible to have the protocols compete with each another and to actually decide which one is the best. Fortunately, most security protocols provide a reasonable level of security. In fact, most of them use the same or very similar cryptographic techniques and algorithms (e.g., the HMAC construction for message authentication, DES, 3DES, or AES for bulk data encryption, and RSA for entity authentication and key exchange). Only a few protocols have been shown to be weak and have serious security problems (e.g., MS-PPTP). Note, however, that this is only an example and that there are probably more weak than strong protocols in use today. This is particularly true for proprietary and unpublished security protocols that one sometimes finds in commercial products.

If deciding which security protocol is the best is difficult if not impossible, the next question is which layer is best suited to provide communication security services. This question is simpler to answer mainly because it addresses classes of security protocols (instead of individual security protocols). In order to further simplify the discussion (and to reduce the variety of layers that can provide communication security services), one usually distinguishes between lower layers (i.e., the network access and Internet layers) and higher layers (i.e., the transport and application layers, as well as the provision of security services above the application layer). In either case, there are arguments to provide security services at either the lower or higher layers in a given protocol stack:

In short, the proponents of providing security services at the lower layers argue that lower-layer security can be implemented transparently to users and application programs, effectively killing many birds with a single stone.
Contrary to that, the proponents of providing security services at the higher layers argue that lower-layer security attempts to do too many things, and that only protocols that work at higher layers can meet application-specific security needs and provide corresponding security services both effectively and efficiently .

Unfortunately, both arguments are true in some sense and there is no generally agreed-upon best layer to provide security services. The best layer actually depends on the security services that are required in a given environment and the application environment in which the services must be implemented and deployed. For example, nonrepudiation services are typically provided at the higher layers, whereas data confidentiality services can also be provided at the lower layers. Also, in an application environment where one can assume users to have smartcards and public key certificates the implementation and provision of non- repudiation services is usually simple and straightforward. In either case, the end-to-end argument originally proposed in [71] also applies for security and provides a strong argument for providing security services at the higher layers. In short, the end-to-end argument says that the function in question (e.g., a security function) can completely and correctly be implemented only with the knowledge of the application standing at the endpoints of the communications system. Therefore, providing that function as a feature of the communications system itself is not possible (sometimes an incomplete version of the function provided by the communications system may be useful as a performance enhancement).