Sebery J.Cryptography.An introduction to computer security.1989

18.1.5 Virtual Private Networks

The Internet is a driving force for new network-based applications and services. It spans over the globe and connects most organizations, institutions, and private users. The main weakness of the Internet is the lack of security. The concept of a virtual private network (VPN) repeats a well known idea of a private network built over insecure leased public communication lines. The Internet provides insecure communication links that can be used to build a secure and private subnetwork using IPsec. IPsec can be used directly (IPv6) or indirectly (jointly with IPv4) to provide authentication and con dentiality.

Consider a collection of basic VPN con gurations:

{host-to-host secure communication

{gateway-to-gateway secure communication

{multiple nested secure communication

The host-to-host con guration is used to create a bidirectional secure channel (with authentication or privacy or both). To implement an authentication channel, two security associations (in each direction) with the AH protocol must be used. To provide authentication and privacy, four security associations have to be applied. This con guration is the basic one which is used for other more complex once.

Most international companies and organizations have many branches or divisions, each of which is typically supported by one or more LANs with the access to the Internet. It is reasonable to assume that a company needs to establish from time to time a secure communication between two or more LANs. Consider the simplest case when two LANs are to be integrated into a single VPN. If the LANs already have access to the Internet, then the traÆc to and from the Internet is passing through a nominated host, called a gateway. It is enough to establish a secure channel between two security gateways in order to integrate the two LANs into a VPN.

Assume that we have already two LANs integrated into a VPN. It can be expected that two hosts residing in two di erent LANs may need to establish a secure channel. In this case, the traÆc between the two hosts will be protected locally (within the LANs) and externally (outside their LANs). The local protection is provided by the host-to-host secure channel. The external security is guaranteed jointly by the host-to-host and gateway-to-gateway secure channels.

602 18 NETWORK SECURITY

SSL Record Protocol

TCP

Fig. 18.2. SSL Protocol Layers

This kind of nested secure channels makes sense if, for example, the authentication channel is requested within the VPN while the transmitted information between LANs is to be kept secret from the outside world.

18.2 Secure Sockets Layer

Secure Sockets Layer (SSL) protocol has been developed by Netscape to provide a secure communication channel between two applications interacting in the client-server mode. The SSL protocol is a suite of protocols arranged in two layers (Figure 18.2).

{The rst one consists of a single protocol which is SSL Record Protocol. It sits on the top of a reliable transport protocol such as TCP and provides con dentiality and integrity services for the protocols from the second layer.

{The second layer includes three protocols:

{Handshake Protocol { used for mutual authentication of client and server.

{Change Cipher Spec Protocol { enables parties to choose a proper cryptographic options.

{Alert Protocol { exchanges warnings.

18.2.1 States of SSL

The protocol uses sessions and connections.

{A session is an association between a client and a server that de nes the security environment (such as cryptographic algorithms). A session is established by the Handshake Protocol.

{A connection provides a suitable type of service within a single session. Normally, a new connection starts after the Change Cipher Spec Protocol is executed.

Sessions and connections provide a convenient way of splitting the security options negotiated by the parties into two collections: long term (session state) and short term (connection state). The session state includes the following parameters:

{Session identi er { an arbitrary byte sequence chosen by the server to identify an active or resumable session.

{Peer certi cate { an X509.v3 certi cate of the peer. This element of the state can be null.

{Compression method { the algorithm used to compress data prior to encryption.

{Cipher spec { speci es the bulk data encryption algorithm (such as null, DES, etc.) and a message authentication code (MAC) algorithm (based on MD5 or SHA). It also de nes cryptographic attributes such as hash size.

{Master secret { 48-byte secret shared between the client and server.

{Is resumable { a ag indicating whether the session can be used to initiate new connections.

The connection state determines the following parameters:

{Server and client random { a byte sequence that is chosen by the server and client for each connection.

{Server write MAC secret { the secret used in MAC operations on data written by the server.

{Client write MAC secret { the secret used in MAC operations on data written by the client.

{Server write key { the bulk cipher key for data encrypted by the server and decrypted by the client.

{Client write key { the bulk cipher key for data encrypted by the client and decrypted by the server.

{Initialization vectors { when a block cipher in CBC mode is used, an initialization vector (IV) is maintained for each key. This eld is rst initialized by the SSL Handshake Protocol. Thereafter the nal ciphertext block from each record is preserved for use with the following record.

{Sequence numbers { each party maintains separate sequence numbers for transmitted and received messages for each connection. When a party sends

and receives a change cipher spec message, the appropriate sequence number is set to zero. Sequence numbers may not exceed 264 1.

604 18 NETWORK SECURITY

data

fragmentation

SSL plaintext records

compression

SSL compressed records

authentication

MAC SSL authenticated records

encryption

SSL ciphertext records

addition of headers

Header

Fig. 18.3. SSL records and operations

18.2.2 SSL Record Protocol

The protocol provides the two basic security services:

{Authentication { messages received from higher layers are authenticated and SSL records coming from the underlying TCP protocol are veri ed. MACs are obtained using a collision-resistant hash function (such as MD5).

{Con dentiality { messages are encrypted if they are coming from higher layers or decrypted if coming from the TCP layer. Cryptographic operations are based on a private-key cryptosystem (such as DES) and the cryptographic key is generated by the Handshaking Protocol.

Being more speci c, the protocol accepts uninterpreted data of arbitrary size from higher layers and (Figure 18.3)

{Splits the data into SSL records of 214 bytes or less. This is called fragmentation.

{Compresses (this is optional) the received records. Compression must be lossless and may not increase the content length by more than 1024 bytes. Note that one would expect that compression always shortens the length of data. However, for already short records, compression may actually increase the size of output data.

{Appends MACs to SSL compressed records.

{Encrypts authenticated records (compressed records with MACs).

{Adds headers to SSL records.

The rst two steps are pretty obvious and need no further clari cation. Consider the next two, as they are essential for this protocol. MACs are generated according to the following formula:

hash(MAC write secretkpad 2khash(MAC write secretk pad 1kseq numklengthkcontent));

where k stands for concatenation,

MAC write secret is a secret key shared between parties

(and generated by the Handshaking Protocol), is a constant character 0x36 repeated 48 times for MD5 or 40 times for SHA,

is a constant character 0x5c repeated the same number of times,

is the sequence number of this message, is either MD5 or SHA-1,

gives the length in bytes of the compressed record, and is the compressed record.

The encryption is performed on compressed and authenticated records using a private-key algorithm (either block or stream cipher). The following cryptographic algorithms are supported

{block ciphers { DES (two variants with 40-bit and 56-bit keys), Triple DES, IDEA, RC2 (with 40-bit keys) and Fortezza,

{stream ciphers { RC4 with keys either 40 bits or 128 bits long.

In the last step of the protocol, a header is attached to the record. It consists of four elds (Figure 18.4), namely,

{ Content Type, which describes the type of data,

606 18 NETWORK SECURITY

Fig. 18.4. SSL record header

{Major Version, which gives the major version number of the SSL. If SSLv3 is used the number is 3,

{Minor Version, which allows to determine versions within the major one,

{Compressed Length, which speci es the overall length in bytes of authenticated (and compressed) SSL records. It must not exceed 214 + 2048 bytes.

18.2.3 Handshake Protocol

The protocol initiates cryptographic parameters of the session state and runs through the following three stages.

Handshake protocol

Initialization: a client and server exchange client hello and server hello messages, respectively or

Attributes Established: protocol version, session ID, cipher suite, compression method and two random values (ClientHello.random and ServerHello.random).

Mutual authentication and key exchange: server rst sends certificate, server key exchange, certificate request and server hello done messages. The client replies by sending certificate, client key exchange, and certificate verify messages. In other words,

3. Client Server: certificate, server key exchange, certificate request, server hello done.

4.Client ! Server: certificate, client key exchange, certificate verify.

Final: the parties exchange change cipher spec and finished messages or 5. Client

6. Client

Consider the initialization stage in more details. The rst message sent from Client to Server is client hello together with the following parameters:

Version { the highest SSL version supported by the client.

Random { a random structure generated by the client containing 32-bit timestamp and 28-byte pseudorandom string.

SessionID { a variable length session identi er. If the identi er is not empty, the value determines an existing session between the same parties whose security parameters the client wishes to reuse. A zero value can be used if the client wants to establish a new session.

CipherSuite { a list of of the combinations of cryptographic algorithms supported by the client and ordered according to the client's preference. The session fails if none of the algorithms speci ed by the client is supported by the server.

CompressionMethod { a list of compression methods supported by the client and ordered according to the client's preference.

If there is no chance to agree on some parameters, the server replies with a handshake failure message. Otherwise it sends its server hello message which is accompanied with the same parameters, which are

Version { the lower of that suggested by the client.

Random { a random structure generated by the server and di erent (independent) from ClientHello.random.

SessionID { if the identi er is not empty, the server looks in its session cache for a match and reuses it if found.

CipherSuite { a single cipher suite selected by the server from the list suggested by the client.

CompressionMethod { a single compression algorithm selected by the server from the list suggested by the client.

The CipherSuite lists pairs of (a key exchange algorithm and a CipherSpec identi er of cipher). The following key exchange algorithms can be chosen:

608 18 NETWORK SECURITY

{RSA { a secret key is encrypted using the RSA encryption.

{Fixed Diffie-Hellman { parties exchange messages containing certi cates of DH parameters.

{Ephemeral DH { the DH keys are signed by the sender and veri ed by the receiver.

{Anonymous DH { this algorithm uses no authentication and is insecure against the man-in-the-middle attack.

{Fortezza.

Mutual authentication and key exchange is started by the server who sends its certificate (this is optional). The certi cate type must be appropriate for the chosen key exchange algorithm and is typically an X509.v3 certi cate. If the server does not have its certi cate (or has a certi cate only used for signing), then the server key exchange message is sent. The message includes the following parameters:

{RSA { the modulus and exponent of the server temporary RSA key.

{Diffie-Hellman { the modulus, generator and the server public key (this is for anonymous DH). These three elements are signed for ephemeral DH.

A certificate request message is sent by an nonanonymous server to the client. The message includes two parameters

{certificate type { a list of the types of certi cates requested (RSA signature only, DSS only, RSA for DH, DSS for DH),

{certificate authorities { a list of the names of acceptable certi cate authorities.

A server hello done indicates the end of the message strings generated by the server. After sending it, the server waits for a client response.

The client sends the certificate message only if the server has requested it. If the client has no proper certi cate, then it warns the server by transmitting a no certificate alert. Next the client key exchange message is sent. The form of the message depends on the agreed key exchange algorithm and thus, there are three options:

{RSA { the client generates a 48-byte premaster secret, encrypts it using the public key (derived from the server certi cate or from temporary RSA key).

{DH { the client sends the public value of DH key (if it was not already included in the client certi cate).

{Fortezza { the client derives a Token Encryption Key (TEK) using Fortezza's key exchange algorithm.

A certificate verify message asks for explicit veri cation of a client certi cate. This message is sent only if any of the client certi cates has signing capability.

The nal stage of the protocol starts from a change cipher spec message, which sets up the current CipherSpec and is considered to be part of the Change Cipher Spec Protocol. Next the party communicates a finished message, which is cryptographically protected using the just-negotiated algorithms, keys and secrets.

18.2.4 Change Cipher Spec and Alert Protocols

The Change Cipher Spec Protocol is very simple and consists of a single message, which is encrypted and compressed under the current (not the pending) CipherSpec. The message is a single byte of value 1. Once the message is received, the pending state of CipherSpec is copied into the current state.

The Alert Protocol distributes alerts with the information about their severity (1 byte) and description (1 byte). The severity takes on two forms:

{ warning(1),

{fatal(2) { the connection is immediately terminated The description of alerts includes:

{close notify { the recipient is noti ed that the sender will no longer send any message on this connection.

{unexpected message { an inappropriate message was received (this alert is always fatal).

{bad record mac { this alert occurs whenever a SSL record is received with incorrect MAC (always fatal).

{decompression failure { the decompression function received improper input (always fatal).

{handshake failure { the sender was unable to negotiate an acceptable set of security parameters (always fatal).

{no certificate { this alert is normally sent in response to a certi cate request if no appropriate certi cate is available.

{bad certificate { a certi cate has failed the veri cation procedure.