`
`Applications, systems, and networks can be made secure through the use of
`security protocols, which provide a wide range of encryption and authen-
`tication services. Each protocol is placed within several layers of a com-
`puting infrastructure (that is, network, transport, and application layers).
`Figure 7-1 shows the various protocols and their locations within the
`
`TranSportation Control Protocol/Internet Protocol (TCP/IP) stack. This
`
`chapter and Chapter 8 describe these protocols and explain how they oper-
`ate within the TCP/IP stack. This chapter first covers the IPSec protocol,
`which provides security at the network layer. Then we take an in-depth look
`at the Secure Sockets Layer (SSL), which implements security at the trans-
`
`port layer.
`
`Internet Protocol Security
`
`Internet Protocol Security (IPSec) is a framework of open standards for
`
`ensuring secure private communications over IP networks. Based on stan-
`dards developed by the Internet Engineering Task Force (IETF), IPSec
`ensures confidentiality, integrity, and authenticity of data communica-
`tions across a public IP network. IPSec is a necessary component of a
`
`Apple 1121 (Part 2 of 2)
`Apple v. USR
`|PR2018—00813
`
`Apple 1121 (Part 2 of 2)
`Apple v. USR
`IPR2018-00813
`
`

`

`21 0
`
`Chapter 7
`
`Figure 7-1
`
`Protocol locations
`within TCPflP:
`
`(a) network (A) Network security
`
`
`(B) Transport security
`
`standards-based, flexible solution for deploying a network—wide security
`
`policy.
`
`IPSec implements network layer encryption and authentication, pro-
`
`viding an end-to-end security solution in the network architecture. In this
`way, and systems and applications can enjoy the advantage of strong secu—
`rity without the need to make any changes. Because IPSec encrypted
`packets look like ordinary IP packets, they can be easily routed through
`any IP network, such as the Internet, without any changes to the inter»
`
`mediate networking equipment. The only devices that know about the
`encryption are the endpoints. This feature greatly reduces the cost of
`
`implementation and management.
`
`IP Security Architecture
`
`IPSec combines several security technologies to protect the confidential—
`ity, integrity, and authenticity of IP packets. IPSec actually refers to sev-
`eral related protocols as defined in RFCs 240L241]. and 2451. Two of
`
`these standards define IPSec and Internet Key Exchange (IKE). IPSec
`defines the information that is added to an IP packet to enable confiden-
`tiality, integrity, and authenticity controls; it also defines how to encrypt
`
`the packet data. IKE is used to negotiate the security association between
`two entities and to exchange keying material. The use of IKE is optional,
`
`but it relieves users of the difficult and labor-intensive task of manually
`
`configuring security associations. IKE should be used in most real-world
`applications to enable large-scale, secure communications.
`
`

`

`
`
`
`
`Network and Transport Security Protocols 2 1 l
`
`lPSec Services
`
`IPSec provides security services at the IP layer by enabling a system for
`selecting required security protocols, determining the a1gorithm(s) to use
`for the service(s), and implementing any cryptographic keys required to
`
`provide the following services:
`
`I Access control
`
`‘
`
`I Connectionless integrity (a detection method of the IP packet itself)
`
`I Data origin authentication
`
`i Rejection of replayed packets (a form of partial sequence integrity)
`
`I Confidentiality (encryption)
`
`I Limited traffic—flow confidentiality
`
`IPSec provides these services through the use of two protocols. The first
`one, the authentication header (AH) protocol, supports access control, data
`origin authentication, connectionless integrity, and the rejection of replay
`attacks, in which an attacker copies a packet and sends it out of sequence
`to confuse communicating nodes. The second protocol is the encapsulating
`security payload (ESP) protocol. ESP alone can support confidentiality,
`access control, limited traffic-flow confidentiality, and the rejection of
`
`replay attacks.
`
`
`
`NOTE:
`ESP and AH can be used in concert to provide all the services.
`
`The Authentication Header Protocol
`
`AH provides data integrity and authentication services for IP packets (see
`Figure 7—2). These services protect against attacks commonly mounted
`against open networks. AH uses a keyed-hash function rather than digi-
`tal signatures because digital signature technology is too slow and would
`greatly reduce network throughput. Note, however, that AH does not pro—
`vide confidentiality protection, so data can still be viewed as it travels
`across a network.
`
`

`

`
`
`2 l 2 Chapter 7
`
`
`
`The
`authentication
`header protocol
`
`
`
`
`
`
`.
`Secunty Parameters Index (SP1)
`
`
`Sequence Number
`.
`
`
`
`
`Authentication Data (variable length)
`
`AH contains the following fields:
`
`I! Next Header This field identifies the higher-level protocol
`following AH (for example, TCP, UDP, or ESP).
`
`I Payload Length This field indicates the length of the AH contents.
`
`I Reserved This field is reserved for future use. Currently, this field
`
`must always be set to zero.
`
`I Security Parameters Index This field is a fixed-length, arbitrary
`value. When used in combination with the destination IP address, this
`
`value uniquely identifies a security association for this packet (that is,
`it indicates a set of security parameters for use in this connection).
`
`a Sequence Number The field provides a monotonically increasing
`number for each packet sent with a given SPI. This value lets the
`recipient keep track of the order of the packets and ensures that the
`same set of parameters is not used for too many packets. The
`sequence number provides protection against replay attacks.
`
`I Authentication Data This variable-length field contains the
`integrity check value (ICV) (see next section) for this packet. It may
`include padding to bring the length of the header to an integral
`multiple of 32 bits (in IPv4) or 64 bits (IPv6).
`
`Integrity Check Value Calculation
`
`The ICV, a truncated version of a message authentication code (MAC), is
`
`calculated by a MAC algorithm. IPSec requires that all implementations
`support at least HMAC—MD5 and HMACK-SHAI (the HMAC symmetric
`authentication scheme supported by MD5 or SHA—l hashes; see Chap-
`ter 6. To guarantee minimal interoperability, an IPSec implementation
`must support at least these schemes.
`'
`
`
`
`

`

`
`
`Network and Transport Security Protocols 2 1 3
`
`The ICV is computed using the following fields:
`
`I The IP header fields that either do not change in transit or whose
`
`values are predictable upon arrival at the endpoint for the AH
`
`security association. Other fields are set to zero for the purpose of
`calculation.
`
`I The entire contents of the AH header except for the Authentication
`
`Data field. The Authentication Data field is set to zero for the purpose
`of calculation.
`
`I All upper-level protocol data, which is assumed to be immutable in
`transit.
`
`NOTE:
`The HMAC value13 catcalated completely, although it is truncated to
`96 bytes {the default size for the Authentication Data field).
`
`Transport, and Tunnel Modes
`
`AH services can be employed in two ways: in transport mode or in tunnel
`mode. The actual placement of the AH depends on which mode is used and
`
`on Whether the AH is being applied to an IPv4 or an IPv6 packet. Fig-
`
`ure 7«3 illustrates IPv4 and IPv6 packets before authentication services
`
`are applied.
`In transport mode, the AH applies only to host implementations and
`provides protection for upper—layer protocols in addition to selected IP
`header fields. In this mode, AH is inserted after the IP header but before
`
`Figure 7-3
`
`IPv4 and IPv6
`before AH is
`
`applied
`
`Standard IPv4 packet
`
`Original IP Header
`
`
`
`
`
`Data
`
`
`
`:
`
`
`
`Headers
`(if present)
`
`
`Standard IPv6 datagram
`Extension
`
`
`
`01.153331013515de
`y p 0
`
`
`
`

`

`
`
`2 I 4 Chapter 7W
`
`any upper—layer protocol (such as, TCP, UDP) and before any other IPSec
`headers that have already been inserted. In IPv4, this calls for placingAH
`after the original IP header but before the upper-layer protocol. In IPv6,
`AH is viewed as an end-to-end payload; this means that intermediate
`routers should not process it. For this reason, the AH should appear after
`the original IP header, hop-by-hop, routing, and fragmentation extension
`headers. This mode is provided via the transport security association (SA).
`Figure 7-4 illustrates the AH transport mode positioning in typical IPv4
`and IPv6 packets.
`
`Figure 7-4
`
`IPv4 and IPv6"
`
`header placement
`in transport mode
`
`IPv4 AH in transport mode
`
`Original IP Header
`
`
`
`
`
`IPv6 AH in transport mode
`
`
`.
`.
`HOPTby-HOP .
`Original IP Header Destination, Routing
`Fragment
`
`
`
`
`
`‘
`AH
`
`Destination
`Options
`
`TCP
`
`
`"'
`
`
`;
`
`Data
`'
`
`In tunnel mode, the AH can be employed in either host or security gate-
`ways. When AH is implemented in a security gateway (to protect transit
`traffic), tunnel mode must be used. In this mode, the AH is inserted
`between the original IP header and the new outer IP header. Whereas the
`inner IP header carries the ultimate source and destination addresses,
`
`the new outer IP header may contain distinct IP addresses (such as,
`addresses of firewalls or other security gateways). In tunnel mode, AH
`protects the entire inner IP packet, including the entire inner IP header.
`In tunnel mode, the position of AH relative to the outer IP header is the
`same as for AH in transport mode. This mode is provided Via the tunnel
`SA. Figure 7-5 illustrates AH tunnel mode positioning for typical IPv4
`
`and IPv6 packets.
`
`NOTE:
`
`ESP andAH headers can be combined in a variety of modes. The IPSec
`
`architecture document (RFC2401) describes the combinations of security
`
`associations that must be supported.
`
`
`
`

`

`
`
`Network and Transport Security Protocols 2 l 5
`
`Fi
`
`8 7-5
`
`IPv4 and IPv6
`
`IPv4 AH 111 tunnel mode
`New IP Header
`.
`
`AH
`
`Ori
`
`'nai 1P Header
`g“
`.
`
`
`header Placement --
`
`in tunnel mode
`
`_
`
`'_
`
`_
`
`_
`
`_
`
`rep
`
`Data
`
`.
`
`
`
`1PV6 AH in tune] mode
`
`New IP
`
`Extension Headers
`
`Extension Headers
`
`
`
`
`
`The Encapsulating Security Payload Protocol
`
`The encapsulating security payload (ESP) protocol provides confidential-
`ity services for IP data while in transit across untrusted networks.
`Optionally, ESP also provides authentication services. The format of ESP
`varies according to the type and mode of the encryption being used. In all
`cases the key associated with the encryption is selected using the SP1.
`Figure 7-6 illustrates the components of an ESP header.
`
`Figure 7—6
`
`Components of an
`ESP header
`
`Security Parameters Index (SP1)
`
`Sequence Number
`
`
`
`Payload Data (variable length)
`
`
`
`
`
`
`
`
`Padding (0—255 bytes)
`
`
`Authentication Data (variable length}
`
`

`

`
`
`2 l 6 Chapter 7
`
`The ESP header contains the following fields:
`
`I Security Parameters Index This field, as in the AH packet, is
`used to help uniquely identify a security association to be used.
`
`I Sequence Number This field, again as in the AH packet, contains
`a counter that increases each time a packet is sent to the same
`address using the same SPI. It lets the recipient keep track of the
`
`packet order.
`
`3 Payload Data This variable-length field contains the actual
`encrypted data contents being carried by the IP packet.
`
`l Padding This field provides space for adding bytes, as required by
`certain types of encryption algorithms (see Chapter 2). Data padding
`confuses sewers, who try to access information about encrypted data
`in transit, in this case by trying to estimate how much data is being
`transmitted.
`
`I Pad Length This field identifies how much of the encrypted
`
`payload is padding.
`
`I Next Header This field identifies the type of data carried in the
`
`Payload Data field.
`
`I Authentication Data This variable—length field contains a value
`that represents the ICV computed over the ESP packet minus the
`Authentication Data field. This field is optional and is included only if
`
`the authentication service is selected within the SA.
`
`NOTE:
`
`All the ESP header components are encrypted except for the Security
`Parameters Index and Sequence Number fields. Both of these fields, how—
`
`ever, are authenticated.
`
`Encryption Algorithms
`
`The IPSec ESP standard currently requires that compliant systems have
`two cryptographic algorithms. Systems must have the DES algorithm
`using cipher block chaining (CBC) mode (see Chapter 2); compliant sys‘
`terns that require only authentication must have a NULL algorithm.
`However, other algorithms are defined for use by ESP services. Following
`are some of the defined algorithms:
`
`
`
`

`

`
`
`
`
`Network and Transport Security Protocols 2 I 7
`
`I Triple DES
`
`I R05
`
`I IDEA
`
`I CAST
`
`I BLOWFISH
`
`I 3IDEA
`
`ESP in Transport and Tunnel Modes
`
`Like AH, ESP can be employed in two modes: transport mode and tunnel
`
`mode. These modes operate here in a similar way to their operation in AH,
`
`with one exception: with ESP, data, called trailers, are appended to the
`
`end of each packet.
`In transport mode, ESP is used only to support host implementations
`and to provide protection for upper~1ayer protocols but not for the IP
`header itself. As with AH, in an IPv4 packet the ESP header is inserted
`after the original IP header and before any upper~1ayer protocols (for
`example, TCP, UDP) and before any other existing IPSec headers. In IPv6,
`
`ESP is viewed as an end-tomend payload; that is, intermediate routers
`should not process it. For this reason, the ESP header should appear after
`the original IP header, hop—by—hop header, routing header, and fragmen-
`tation extension header. In each case, the ESP trailer is also appended to
`the packet (encompassing the Padding, Pad Length, and Next Header
`
`V
`
`fields). Optionally, the ESP authentication data field is appended if it has
`
`been selected. Figure 7J7 illustrates the ESP transport mode positioning
`in typical IPv4 and IPv6 packets.
`
`Figure 7-7
`
`IPv4 and IPv6
`
`header placement
`in transport mode
`
`IPv4 ESP in transport mode
`
`Original 1r Header
`
`ESP
`
`ESP
`
`ESP
`
`
`
`
`
`IPv6 AH in transport mode
`
`
`Hop~by-Hop
`
`‘
`
`.
`
`
`
`Ongflolfiiggsder Destination, Routing HESEI) D3232:“ TCP Data TBS?
`y p
`Fragmentation
`ea or
`p
`ra1 er
`
`
`
`_
`
`,
`
`ESP
`Authentication
`
`
`
`
`
`
`
`

`

`
`
`2 l 8 Chapter 7
`
`Tunnel mode ESP can be employed by either hosts or security gate-
`ways. When ESP is implemented in a security gateway (to protect sub~
`scriber transit traffic), tunnel mode must be used. In this mode, the ESP
`header is inserted between the original IP header and the new outer IP
`header. Whereas the inner IP header carries the ultimate source and des—
`
`tination addresses, the new outer IP header may contain distinct IP
`addresses (such as, addresses of firewalls or other security gateways). In
`tunnel mode, ESP protects the entire inner IP packet, including the entire
`inner IP header. The position of ESP in tunnel mode, relative to the outer
`1P header, is the same as for ESP in transport mode. Figure 7-8 illustrates
`ESP tunnel mode positioning for typical IPv4 and IPv6 packets.
`
`sender and the receiver. For peer communications, 3 second SA is needed.
`
`IPv4 AH in tunnel mode
`
`Figure 7-8
`
`IPv4 and IPv6
`
`header placement
`in tunnel mode
`
`
`
`ESP OriginalIPHeadcr TCP
`NewIPHeadcr
`(any options) Header
`(any options)
`
`D t
`aa
`
`ESP
`ESP
`Trailer Audientication
`
`‘
`
`
`
`IPv6 All in tunnel mode
`
`VA
`
`
`
`.
`New IP . New Extensmn ESP
`
`
`
`.
`-
`Ongmal
`
`Original
`.
`
`ESP
`
`ESP
`
`:
`
`
`
`
`
`NOTE:
`
`ESP and AH headers can be combined in a variety of modes. The IPSec
`
`architecture document describes the combinations of security associations
`
`that must be supported.
`
`
`Security Associations
`
`To communicate, each pair of hosts using IPSec must establish a security
`association (SA) between them. The SA groups together all the things that
`you need to know about how to communicate securely with someone else,
`such as the type of protection used, the keys to be used, and the valid dura—
`tion of this SA. The SA establishes a one-way relationship between the
`
`

`

`
`
`Network and Transport Security Protocols 2 l 9
`
`You can think of an SA as a secure channel through the public network
`to a certain person, group of people, or network resource. It’s like a con-
`tract with whoever is at the other end. The SA also has the advantage in
`that it lets you construct classes of security channels. If you need to be a
`little more careful when talking to one party than another, the rules of
`your SA with that party can reflect extra caution—for example, specifying
`stronger encryption.
`A security association is uniquely identified by three parameters:
`
`I Security Parameters Index This bit string uniquely identifies a
`
`security association relative to a security protocol (for example, AH
`or ESP). The SP1 is located Within AH and ESP headers so that the
`
`receiving system can select the SA under which a received packet
`will be processed.
`
`I 11’ Destination Address This parameter indicates the destination
`
`IP address for this SA. The endpoint may be that of an end user
`system or a network system such as a gateway or firewall. Although
`in Concept this parameter could be any address type (multicast,
`broadcast, and so on), currently it can be only a unicast address.
`
`I Security Protocol Identifier This parameter indicates whether
`the association is that of an AH or an ESP security association.
`
`Combining Seturity Associations
`
`Using a single SA, you can deploy either AH or ESP (but not both) to
`implement security for IP packets. However, there is no restriction on the
`use of multiple SAs, usually referred to as an SA bundle. The order in
`which the SAs are bundled is defined by your security policy. IPSec does
`
`define two ways of combining SAs: transport adjacency and iterated tun-
`
`neling.
`Ykonsport adjacency refers to the process of applying multiple trans—-
`port SAs to the same IP packet without using tunneling SAs. This level of
`combination lets you apply both AH and ESP IP packets but does not
`enable further nesting. The idea is that strong algorithms are used in both
`AH and ESP, so further nesting would yield no additional benefits. The IP
`packet is processed only once: at its final destination. Figure 7~9 illus-
`trates the application of transport adjacency.
`In iterated tunneling, you apply multiple (layered) security protocols by
`using IP tunneling. This approach allows multiple levels of nesting. Each
`
`

`

`220
`
`Chapter 7
`
`Figure 7-9
`
`Transport
`
`adjacency
`
`tunnel can originate or terminate at a different IPSec site along the path.
`Figure 7-10 shows three basic cases of iterated tunneling supported by the
`IPSec protocol.
`
`NOTE:
`
`You, can also combine transport adjacency and iterated tunneling. For
`example, you could construct an SA bundle from one tunnel SA and one
`or two transport SAs applied in sequence.
`
`Security Databases
`
`IPSec contains two nominal databases: the Security Policy Database
`(SPD) and the Security Association Database (SAD). SPD specifies the
`policies that determine the disposition of all 1]? traffic, inbound or out-
`bound. SAD contains parameters that are associated with each currently
`active security association.
`
`

`

` Network and Transport Security Protocols
`
`22 1
`
`Security
`gateway 1
`‘-
`
`Security
`gateway 2
`
`Host 2
`
`.
`F1m 7'10
`Three cases of
`iterated
`
`tunneling
`
`
`Host 1
`
`Secufity
`gateway 1
`
`Security
`gateway 2
`
`Host 2
`
` Security assmiatim l
`
`
`(ESP tunnel)
`
`C3822
`
`Host 1
`
`Security
`atewa 1
`g
`3’
`
`Security
`gateway 2
`
`Host 2
`
`
`
`

`

`2 2 2
`
`Chapter 7
`
`Security Policy Database
`
`An SA is nothing more than a management construct that is used to
`
`enforce a security policy. Because SPD is responsible for all IP traffic, it
`
`must be consulted during the processing of all traffic (inbound and out—
`
`bound), including non-IPSec traffic. To support this, SPD requires distinct
`entries for inbound and outbound traffic; these entries are defined by a set
`
`of selectors, or IP and upper—layer protocol field values. The following
`
`selectors determine an SPD entry:
`
`I Destination IP Address This can be a single IP address, a list of
`addresses, or a wildcard address. Multiple and Wildcard addresses
`
`are used when you have more than one source system sharing the
`
`same SA (for example, behind a gateway).
`
`a Source IP Address This can be a single IP address, a range of
`addresses, or a wildcard address. Multiple and wildcard addresses are
`
`used when you have more than one source system sharing the same
`
`SA (for example, behind a gateway).
`
`ll Name This can be either an X500 distinguished name or a user
`
`identifier from the operating system.
`
`a Data Sensitivity Level This is used for systems that provide
`information flow security (for example, unclassified or secret).
`
`I Transport Layer Protocol This is obtained from the IPv4 Protocol
`
`field or IPv6 Next Header field. It can be an individual protocol
`number, a list of protocol numbers, or a range of protocol numbers.
`
`I Source and Destination Ports These can be individual UDP or
`
`TCP port values, or a wildcard port.
`
`Security Association Database
`
`Each implementation of IPSec contains a nominal SAD, which is used to
`define the parameters associated with each SA. The following parameters
`are used to define an SA:
`
`3 Sequence Number Counter A 32-bit value used to generate the
`Sequence Number field in AH or ESP headers.
`
`a Sequence Counter Overflow A flag indicating whether overflow
`
`of the sequence number counter should generate an auditable event
`and prevent transmission of additional packets on the SA.
`
`
`
`
`
`
`
`

`

`
`
`
`
`Network and Transport Security Protocols 2 23
`
`I Anti-Replay Window A 32-bit counter that is used to determine
`Whether an inbound AH or ESP packet is a replay.
`
`I AH Information Parameters relating to the use of AH (such as
`
`authentication algorithms, keys, and key lifetimes).
`
`I ESP Information Parameters relating to the use of E8]? (such as
`
`encryption algorithms, keys, key lifetimes, and initialization values).
`
`3 Lifetime of This Security Association A time interval or byte
`count that specifies an SA’s duration of use. When the duration is
`complete the SA must be replaced with a new SA (and new SP1) or
`terminated, and this parameter includes an indication of which of
`these actions should occur.
`‘
`
`NOTE:
`
`If a time interval is employed, and ifIKE employs X509 certificates for
`SA establishment, the SA lifetime must be constrained by the validity
`
`intervals of the certificates and by the ‘WextIssueDate” of the CRLS used
`in the IKE exchange for the SA. For more about CRLs, see Chapter 6.
`
`I IPSec Protocol Mode Specifies the mode—tunnel, transport, or
`Wildcard-of AH or ESP that is applied to traffic on this SA.
`
`I Path MTU Any observed path maximum transferable unit (MTU)
`
`and aging variables. (The MTU is the maximum size of a packet
`without fragmentation.)
`
`Key Management
`
`As With any security protocol, when you use IPSec you must provide key
`management, such as supplying a means of negotiating with other people
`the protocols, encryption algorithms, and keys to be used in data
`exchange. In addition, lPSec requires that you keep track of all such
`agreements between the entities. IETF’s IPSec working group has speci—
`fied that compliant systems must support both manual and automated SA
`
`and cryptographic key management.
`
`

`

`
`
`.
`i
`E
`
`2 2 4
`
`Chapter ”I
`
`Following are brief descriptions of these techniques:
`
`I Manual Manual key and SA management are the simplest forms
`
`of key management. A person (usually a systems administrator)
`manually configures each system, supplying the keying material and
`SA management data relevant to secure communication with other
`systems. Manual techniques can work effectively in small, static
`
`environments, but this approach is not very practical for larger
`networks.
`
`I Automated By using automated key management protocols, you
`can create keys as needed for your SAs. Automated management also
`
`,
`
`gives you a great deal of scalability for larger distributed systems
`that are still evolving. You can use various protocols for automated
`
`management, but IKE seems to have prevailed as the current
`industry standard.
`
`Internet Key Exchange
`
`IKE is not a single protocol; rather, it is a hybrid of two protocols. IKE
`
`integrates the Internet Security Association and Key Management Proto-
`col (ISAKMP) with the Oakley key exchange protocol.
`
`IKE performs its services in two phases. In the first phase, two IKE
`peers establish a secure, authenticated channel for communication by
`using a common IKE security association. IKE provides three modes of
`exchanging keying information and setting up SAs (see next section); in
`this first phase, only main or aggressive mode is employed.
`In the second phase, SAs are negotiated on behalf of services such as
`IPSec or any other service that needs keying material or parameter nego-
`tiation. The second phase is accomplished via a quick mode exchange.
`
`Main Mode
`
`IKE’S main mode provides a three-stage mechanism for establishing the
`first-phase IKE SA, which is used to negotiate future communications. In
`this mode, the parties agree on enough things (such as authentication and
`
`confidentiality algorithms, hashes, and keys) to be able to communicate
`
`securely long enough to set up an SA for future communication. In this
`
`mode, three two-way messages are exchanged between the SA initiator
`
`and the recipient.
`
`As shown in Figure 7—11, in the first exchange, the two parties agree on
`basic algorithms and hashes. In the second, they exchange public keys for
`
`

`

`
`
`
`
`Network and Transport Security Protocols 225
`
`
`
`Figure 7-11
`
`Transactions in
`IKE’s main mode
`
`Initiator
`
`Responder
`
`
`
`
`
`
`
`
`
`--lfl
`
`* Indicates inclusion of optional certificate payload
`
`a Diffie-Hellman exchange and pass each other nonces (random numbers
`
`signed and returned by the other party to prove its identity). In the third
`exchange, they verify those identities.
`
`Aggressive Mode
`
`Aggressive mode is similar to main mode in that aggressive mode is used
`to establish an initial IKE SA. However, aggressive mode differs in the
`
`way the messages are structured, thereby reducing the number of
`
`exchanges from three to two.
`In aggressive mode, the proposing party generates a Diffie—Hellman
`pair at the beginning of the exchange and does as much as is practical
`with that first packet: proposing an SA, passing the Diffie-Hellman pub-
`lic value, sending a nonce for the other party to sign, and sending an ID
`packet that the responder can use to check the initiator’s identity with a
`third party (see Figure 7-12). The responder then sends back everything
`needed to complete the exchange. All that’s left for the initiator to do is to
`
`confirm the exchange.
`The advantage of aggressive mode is its speed, although aggressive
`mode does not provide identity protection for the communicating parties.
`This means that the parties exchange identification information before
`
`

`

`
`
`2 2 6 Chapter 7
`
`
`
`Responder
`
`2
`III-ml:
`
`
`
`
`
`Figure 7-12
`
`Aggressive mode
`transactions
`
`Initiator
`
`1
`
`
`
`an..-
`
`
`
`* Indicates inclusion of optional certificate payload
`
`establishing a secure SA in which to encrypt it. As a result, someone mon-
`itoring an aggressive mode exchange can identify the entity that has just
`formed a new SA.
`
`Quick Mode
`
`After two communicating entities have established an IKE SA using
`either main or aggressive mode, they can use quick mode. Quick mode,
`unlike the other two modes, is used solely to negotiate general IPSec secu-
`rity services and to generate fresh keying material.
`Because the data is already inside a secure tunnel (every packet is
`encrypted), you can afford to be a little more flexible in quick mode. Quick
`mode packets are always encrypted and always start with a hash payload,
`Which is composed using the agreed-upon pseudo—random function and
`the derived authentication key for the IKE SA. The hash payload is used
`to authenticate the rest of the packet. Quick mode defines which parts of
`the packet are included in the hash.
`As shown in Figure 7-13? the initiator sends a packet with the quick
`mode hash; this packet contains proposals and a nonce. The responder
`
`Figure 7-13
`
`Quick mode
`transactions
`
`
`
`
`
`
`[mM
`
`
`
`Initiator
`
`Responder
`
`,
`
`l
`
`‘ 2
`
`
`
`
`
`

`

`
`
`
`
`Network and TranSport Security Protocols 22 7
`
`then replies with a similar packet, this time generating its own nonce and
`including the initiator’s nonce in the quick mode hash for confirmation.
`
`The initiator then sends back a confirming quick mode hash of both
`nonces, completing the exchange. Finally, using the derivation key as the
`key for the hash, both parties perform a hash of a concatenation of the fol-
`lowing: the nonces, the SPI, and the protocol values from the ISAKMP
`header that initiated the exchange. The resulting hash becomes the new
`
`password for that SA.
`
`Secure Sockets Layer
`
`Secure Sockets Layer (SSL),
`
`the Internet protocol for session-based
`
`encryption and authentication, provides a secure pipe between two par-
`ties (the client and the server). SSL provides server authentication and
`
`optional client authentication to defeat eavesdropping, tampering, and
`message forgery in client-server applications. By establishing a shared
`secret between the two parties, SSL provides privacy.
`SSL works at the transport layer (below the application layer) and is
`
`independent of the application protocol used. Therefore, application pro-
`tocols (HTTP, FTP, TELNET, and so on) can transparently layer on top of
`SSL, as shown in Figure 7-14.
`
`Figure 7-14
`
`SSL in the
`TCP/IP stack
`
`
`
`The History of SSL
`
`Netscape originally developed SSL in 1994. Since then, SSL has become
`widely accepted and is now deployed and supported in all major Web
`browsers and servers as well as various other software and hardware
`
`products (see Figure 7-15). This protocol currently comes in three ver-
`sions: SSLVZ, SSLv3, and TLSvl (also known as SSLv3.1). Although all
`three can be found in use around the world, SSLV3, released in 1995, is
`
`the predominant version.
`
`

`

`Z 2 8
`
`Chapter 7
`
`Figure 7-15
`
`The padlock
`symbol in this
`browser denotes
`the use of SSL for
`
`Web security
`
`El
`Vite—m
`
`SSE. Secured [123 Bit
`
`SSLV3 solved many of the deficiencies in the SSLv2 release. SSLVB
`
`enables either party (client or server) to request a new handshake (see
`
`next section) at any time to allow the keys and ciphers to be renegotiated.
`
`Other features of SSLVB include data compression, a generalized mecha-
`
`nism for Diffie-Hellman and Fortezza key exchanges and non-RSA cer-
`
`tificates, and the ability to send certificate chains.
`
`In 1996, Netscape turned the SSL specification over to the IETF. Cur-
`rently, the IETF is standardizing SSLVS in its Transport Layer Security
`
`(TLS) working group. TLSVl is very similar to SSLV3, with only minor pro-
`tocol modifications. The first official version of TLS was released in 1999.
`
`Session and Connection States
`
`Any system of the type discussed in this chapter is composed of two parts:
`
`its state and the associated state transitions. The system’s state describes
`
`the system at a particular point in time. The state transitions are the
`
`processes for changing from one state to another. The combination of all
`possible states and state transitions for a particular object is called a state
`
`machine. SSL has two state machines: one for the client side of the proto-
`col and another for the server side. Each endpoint must implement the
`
`matching side of the protocol. The interaction between the state machines
`is called the handshake.
`
`It is the responsibility of the SSL handshake protocol to coordinate the
`
`states of the client and server, thereby enabling each one’s protocol state
`
`machine to operate consistently even though the state is not exactly par-
`
`allel. Logically, the state is represented twice: once as the current operat-
`
`ing state and (during the handshake protocol) a second time as the
`
`pending state. Additionally, separate read and write states are main-
`
`

`

`
`
`
`
`Network and Transport Security Protocols 2 29
`
`tained. An SSL session can include multiple secure connections, and par-
`ties can have multiple simultaneous sessions.
`
`The SSL specification defines the elements of a session state as follows:
`
`I Session Identifier An arbitrary byte sequence chosen by the
`server to identify an active or resumable session state.
`
`I Peer Certificate X.509V3 certificate of the peer. This element of the
`state can be null.
`
`I Compression Method The algorithm used to compress data before
`encryption.
`
`I Cipher Spec Specifies the bulk data encryption algorithm (null,
`DES, and so on) and a MAC algorithm (such as MD5 or SHA-l) used
`
`for message authentication. It also defines cryptographic attributes
`such as the hash size.
`
`I Master Secret
`server.
`
`48—byte secret shared between the client and the
`
`I Is Res