Record Protocol
The Record Protocol is composed of several sublayers. It processes application protocol data by fragmenting the data into manageable blocks, optionally compressing the data, computing the integrity check value, encrypting the output from the previous sublayer, and finally transmitting the result. Received data is processed in the opposite order. It is decrypted, integrity checked, optionally decompressed, reassembled, and then delivered to the application. The Fragmentation sublayer breaks information into records. A record is 16,384 bytes or less. Application protocol message boundaries may not be preserved. Multiple application protocol messages of the same content type may be aggregated into a single record; also, a single application protocol message may be fragmented into several records.
The Compression sublayer performs compression and decompression on all fragments. Initially, the compression method is null, but a real compression algorithm can be negotiated. Compression must not lose data.
The Payload Protection sublayer computes an integrity check value on the compressed record and then encrypts the compressed record and the integrity check value. The integrity check value is referred to as a MAC, even though a keyed hash (HMAC) is used. On reception, decryption recovers the plaintext, and the MAC is recomputed to ensure the integrity of the plaintext. The MAC computation also includes an implicit sequence number to detect missing, extra, or repeated compressed records.
When encryption employs a block cipher with a mode that requires an IV, such as Cipher Block Chaining (CBC) mode, the IV for the first record is generated when the security parameters are set by the Handshake Protocol. The IV for subsequent records is the last ciphertext block from the previous record. This technique avoids the transmission of explicit IVs.
Figure 7-2 shows a TLS Record Protocol data unit with all of the sublayer protocol control information. The Payload Protection sublayer includes a header and a trailer; the pad and pad length fields are only present when a block cipher is used for encryption. There is no need for padding when a stream cipher, such as RC4, is used.
Fragmentation: ContentType ProtocolVersion Length Protection Head: ContentType ProtocolVersion Length Protection Tail: MAC Pad (Optional) Pad Length (Optional)
Application Protocol Data Compression: ContentType ProtocolVersion Length
Turner c07.tex V3 - 03/26/2008 5:38pm Page 133
Chapter 7 ■ Protecting Email Passwords, Headers, and Commands 133
IPsec
While TLS provides a publicly and readily available connection security protocol, the other common approach to solve connection security is IPsec. Currently though, IPsec is really only available to those who own and control their network because it is not offered by most ISPs yet.
IPsec provides security for individual IP (Layer 3) datagrams; all Internet traffic is carried by IP datagrams. IPsec protects communication from one machine to another, or it protects communications from one border of an organizational enclave to another. IPsec is the security protocol used to imple- ment virtual private networks (VPNs). There were many proprietary solutions developed before the IETF began development of the IPsec specification. Many of these proprietary solutions were studied in the development of IPsec, but none was selected. Rather, IPsec is a hybrid of the many proprietary solutions. The result is a comprehensive, but complex, IP security architecture.
IPsec is described in a series of eight documents. The series begins with an overview of the IPsec architecture [RFC4301]. Security associations (SAs) form the foundation of the cryptographic security services provided by IPsec. A security association is shared symmetric keying material and attributes that govern its use. Next, the Authentication Header (AH) is specified [RFC4302, RFC4304, RFC4305]. The AH protocol provides IP datagram authentication and integrity, and AH optionally provides anti-replay protection. Next, the
Encapsulating Security Payload (ESP) is specified [RFC4303, RFC4304, RFC4305].
The ESP protocol may provide IP datagram confidentiality, authentication, and integrity, and ESP optionally provides limited address hiding and/or anti-replay protection. Finally, the Internet Key Exchange (IKE) is specified [RFC4306, RFC4307]. The IKE protocol provides security associations for AH and ESP. Basically, IKE establishes symmetric keying material and negotiates the attributes that will govern the use of that keying material.
It makes it easy to configure IPsec, some shorthand conventions to select the most commonly used cryptographic algorithms were defined in [RFC4308].
There are several ways to implement IPsec in a host, router, or firewall. An IPsec-enabled router or firewall is called a security gateway. Common implementation alternatives include:
Integration into the native stack. Many operating system vendors will integrate IPsec capabilities directly into their IP stack. Access to the IP source code is needed, so third-party vendors cannot use this approach. In many popular operating systems, this code resides in the kernel. Replacement stack. A third-party vendor may write a complete replace-
ment for the original stack that includes IPsec capabilities in addition to the original communication capabilities. Significant effort is needed to
134 Part III ■ Secure Email
recreate the native IP capabilities, and the operating system architecture may make the installation quite difficult.
Bump-in-the-stack implementations. A third-party vendor may insert an IPsec implementation into the native IP stack. IPsec is inserted between the native IP and the local network drivers. Source code access for the IP stack is not required, making this implementation approach espe- cially appropriate for legacy systems. Using APIs can make this approach much more straightforward and avoids the tedious task of reverse engi- neering module interfaces.
Bump-in-the-wire implementations. Outboard cryptographic processors are commonly used in military and financial industry network secu- rity systems. Bump-in-the-wire implementations are usually dual-port devices with high-quality IPsec capabilities and minimal communica- tions capabilities. The bump-in-the-wire device usually has an IP address of its own. When providing security services for a single host, the bump- in-the-wire device may be quite analogous to a bump-in-the-stack implementation. However, when providing security services for a router or firewall, the bump-in-the-wire device must operate as a security gate- way.