Cryptography Reference
In-Depth Information
have not yet been informed. For instance, if the CRL is sent out at 3:00 am every
morning (a time with relatively little network traffic otherwise), a dishonest person
could have almost a whole day where a revoked certificate is still valid. To counter
this, the CRL update period can be shortened, say to one hour. However, this would
be a tremendous burden on the bandwidth of the network. This is an instructive ex-
ample for the tradeoff between costs in the form of network traffic on one hand, and
security on the other hand. In practice, a reasonable compromise must be found.
In order to keep the size of CRLs moderate, often only the changes from the last
CRL broadcast are sent out. These update-only CRLs are referred to as
delta CRLs
.
13.4 Discussion and Further Reading
Key Establishment Protocols
In most modern network security protocols, public-
key approaches are used for establishing keys. In this topic, we introduced the
Diffie-Hellman key exchange and described a basic key transport protocol in
Chap. 6 (cf. Fig. 6.5). In practice, often considerably more advanced asymmetric
protocols are used. However, most of them are based on either the Diffie-Hellman
or a key transport protocol. A comprehensive overview on this area is given in [33].
We now give a few examples of generic cryptographic protocols that are of-
ten preferred over the basic Diffie-Hellman key exchange. The
MTI
(Matsumoto-
Takashima-Imai) protocols are an ensemble of authenticated Diffie-Hellman key
exchanges which were already published in 1986. Good descriptions can be found
in [33] and [120]. Another popular Diffie-Hellman extension is the station-to-station
(STS) protocol. It uses certificates and provides both user and key authentication.
A discussion about STS variants can be found in [60]. A more recent protocol for
authenticated Diffie-Hellman is the MQV protocol which is discussed in [108]. It is
typically used with elliptic curves.
A prominent practical example for a key establishment protocol is the Internet
Key Exchange (IKE) protocol. IKE provides key material for IPsec, which is the
“official” security mechanism for Internet traffic. IKE is quite complex and offers
many options. At its core, however, is a Diffie-Hellman key agreement followed
by an authentication. The latter can either be achieved with certificates or with pre-
shared keys. A good starting point for more information on IPsec and IKE is the
RFC [128] and, more accessibly, reference [161, Chapter 16].
Certificates and Alternatives
During the second half of the 1990s there was a
belief that essentially every Internet user would need a certificate in order to com-
municate securely, e.g., for doing ebusiness transactions. “PKI” was a buzzword for
some time, and many companies were formed that provided certificates and PKI ser-
vices. However, it turned out that there are major technical and practical hurdles to a
PKI that truly encompasses all or most Internet users. What has happened instead is
that nowadays many servers are authenticated with certificates, for instance Internet
retailers, whereas most individual users are not. The needed CA verification keys
