Chapter 18: Conclusions and Outlook

Team-Fly

OVERVIEW

In this part of the book we focus on communication security and address the major cryptographic security protocols that have been proposed, specified, implemented, and deployed for the four layers[1] of the Internet model (i.e., the network access, Internet, transport, and application layers). Finally, we elaborated on some possibilities to provide security services above the application layer (and we called the resulting protocols message security protocols).

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, we saw in the previous chapters of this part that 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 we overviewed and discussed 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. As an example, we elaborated on MS-PPTP (especially version 1) in Chapter 13. 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 security products.

If deciding which security protocol is the best is difficult if not impossible, the next question is related to the layer that is best suited to provide communication security services. This leads us to the second question listed. 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, non-repudiation 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 [1] 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).

From a practical point of view, providing security services at the lower or higher layers has several advantages and disadvantages:

  • Providing security services at the lower layers has the big advantage that the applications and application programs must not be modified (i.e., the client and server software can be left as it is). In other words, the security services can be provided transparently to all users and applications, and all applications can be made secure simultaneously. The major disadvantage of lower-layer security protocols is related to the fact that the provision of security services must be implemented inside the networking infrastructure (either at the network access or Internet layer). This is not always possible and sometimes ad hoc solutions must be used instead. For example, we saw that BITS and BITW implementations for the IPsec and IKE protocols are very common and widespread today. Hopefully, the relevant standards will be made mandatory for future releases of the corresponding protocol specifications. For example, support for the IPsec and IKE protocols is mandatory for IPv6 implementations. This will make a large difference in terms of deployment.

  • Contrary to that, providing security services at the higher layers has the distinct advantage that the networking infrastructure must not be modified and can be left as it is. This advantage is important, since it allows the provision of security services on an end-to-end basis. The major disadvantage of higher layers security protocols, however, is related to the fact that the applications or application protocols must be modified to provide the security services, and that the client and server software must also be modified accordingly. Sometimes the required modifications are moderate or negligible (e.g., if an application is layered on top of SSL/TLS), but sometimes the required modifications are quite substantial (e.g., if an application protocol is redesigned to additionally provide security services). Not all possibilities equally apply for all applications. For example, if we have to secure a UDP-based application, the use of SSL/TLS or another transport layer security protocol is generally not possible.

An analogy may help us better understand the possibilities to place security services in a communications protocol stack. Let us assume we have some valuable goods to transport from one location to another (e.g., a collection of jewelry). If we want to use a railway system to transport the goods, we have the choice of either securing the railway system as a whole and transporting the goods as they are, or securing the goods (e.g., put them in a safe and put some armed forces in front of the safe) and transporting them on the railway system as it is. In this analogy, the first possibility refers to the possibility of providing security services at the lower layers, whereas the second possibility refers to the possibility of providing security services at the higher layers. For obvious reasons, the second possibility is often more effective and more efficient.

One can also argue that the question of which layer is best suited to provide communication security services depends on and must be answered for each service individually. For example, bulk data cryptographic transformations, such as message authentication, integrity checking, and data encryption, are well suited to be provided at the network access or Internet layer, which is usually tightly coupled with the operating system kernel and thus allows for efficient employment and scheduling of potentially available dedicated hardware, random number generators, and other components. At the same time, security policies that may be defined for a site or corporate intranet may be enforced without individual users being able to circumvent them. This has to be supplemented by an API and other utilities residing in application space. The API and the utilities are to provide applications with information about the level of authenticity a connection actually has, and what algorithms for data encryption and authentication should be used. Other services, however, are better provided at higher layers. Examples include entity authentication and non-repudiation services empowered by the use of digital or electronic signatures.

Against this background, the question of which layers are best suited to provide communication security services is not an "either-or" decision but rather an "and" decision, actually traversing and encompassing multiple layers. In the future, it is possible and very likely that we will see both network and application providers have their duties and care about security requirements and corresponding solutions. From the technologist's point of view, it will be important to provide both of them with appropriate security technologies and solutions.

[1]It is very likely and possible that we will see a session layer between the transport and application layers in a future Internet model. In fact, the SSL and TLS protocols as well as the SSH transport layer protocol are session layer security protocols and could also be described under this title.


Team-Fly


Internet and Intranet Security
Internet & Intranet Security
ISBN: 1580531660
EAN: 2147483647
Year: 2002
Pages: 144

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net