Exchanging Keys

CH05-P374463.indd 141

142 CHAPTER 5 Concepts in IP Security

ISAKMP common header with two payloads. The initiator and responder cookies identify the SA at the end points. The protocol version defi ned by RFC 2408 is 1.1. The Message ID is a randomly generated number created by the sender of a request message and echoed in a response, allowing correlation with minimal risk of collision. The Message Length is given in bytes and covers the whole message, including the header. The Exchange Type indicates the ISAKMP mode of opera- tion and so dictates which payloads are required—possible values for this fi eld are shown in Table 5.3 . Three fl ags are used as follows:

A—Authentication Only: The payloads of this message should be subjected to authentication but not encryption.

C—Commit: Used to request (force) a complete message exchange before the contents of a message are put into use.

E—Encrypted: Indicates that the payloads are encrypted using the agreed encryption algorithm.

Table 5.3 ISAKMP Exchange Types Carried in the Common Message Header Exchange Type Meaning

0 None.

1 The Base Exchange is designed to allow the Key Exchange and Authentication-related information to be transmitted together. Combining the Key Exchange and Authentication-related infor- mation into one message reduces the number of round-trips at the expense of not providing identity protection.

2 The Identity Protection Exchange separates the Key Exchange from the Identity and Authentication-related information providing protection of the identity information at the expense of two additional messages since identities are exchanged under the protection of a previously established common shared secret. 3 The Authentication Only Exchange provides for the transmission

of only authentication-related information. This exposes the authentication feature without the extra expense of computing keys. When using this exchange during negotiation, none of the transmitted information will be encrypted.

4 The Aggressive Exchange allows the security association, key exchange, and authentication payloads to be transmitted together in a single message. This reduces the number of round-trips at the expense of not providing identity protection.

5 The Informational Exchange provides a one-way transmission of information that can be used for security association management.

CH05-P374463.indd 142

143

Table 5.4 ISAKMP Payload Types Identify the Components of Messages Payload Type Meaning

0 No more payloads.

1 Security Association Parameters. Sets the context for the establishment of a security association by specifying the use to which this association will be put. Contains a Domain of

Interpretation (DOI) fi eld that is set to the value 1 to indicate IPsec. 2 The Proposal payload defi nes the identity of the security association

and includes the operational protocol (IPsec, TLS, OSPF, etc.) and the cookies (sometimes known as the Security Parameter Index, or SPI) used in that protocol to represent the association.

3 The Transform payload suggests or agrees on the security processes and algorithms available or chosen for use on the security association.

4 The Key Exchange payload is used to exchange keys. 5 The end points identify themselves using the Identifi cation

payload, which is context specifi c depending on the Domain of Interpretation and the identity type chosen.

6 A Certifi cate payload provides strong authentication of the identity of an end point using one of a variety of standardized means. 7 The Certifi cate Request payload can be included in any message

and requests that the remote node immediately respond with a message that includes a Certifi cate payload. (Compare with the Certifi cate Request in the TLS handshake protocol.)

8 The Hash payload is included in messages if the use of message authentication has been agreed to. The payload contains the output of the hashing algorithm applied to all or part of the message as negotiated using the Transform payload. 9 The transform payload may also negotiate the use of digital

signatures. If so, the Signature payload is included in all messages to authenticate their origins.

10 A pseudorandom identifi er is included in the Nonce payload to help prevent against replay attacks. The value of this identifi er is changed for each instance of the security association, but is constant for the life of one association. Since the Nonce is only present in encrypted messages it is not externally visible and can be verifi ed to be consistent on all messages in one association and a super-security-conscious end node can keep track of previous values to protect against an intruder replaying previous messages.

(Continued)

5.8 Exchanging Keys

CH05-P374463.indd 143

144 CHAPTER 5 Concepts in IP Security

Table 5.4 (Continued) Payload Type Meaning

11 The Notifi cation payload contains information data specifi c to the DOI context.

12 The Delete payload offi cially “ contains a protocol-specifi c security association identifi er that the sender has removed from its security association database and is, therefore, no longer valid. ” That is to say, it is used to terminate a security association.

13 ISAKMP messages may optionally include Vendor ID payloads to identify the communicating implementations.

The First Payload fi eld of the ISAKMP header indicates the type of the fi rst payload element in the message body. Each payload element also contains a Next Payload fi eld to indicate the type of the next payload. These types are listed in Table 5.4 . Each payload also includes a Length fi eld that indicates the length of the payload in bytes, including the Next Payload and Length fi elds.

The Exchange Types listed in Table 5.4 dictate how the ISAKMP end points exchange information—that is, which payload elements they send in which mes- sages. The main differences are in how the elements are combined and therefore how much protection is available to the information that is sent. In general there is a trade-off between sending a few messages packed with unprotected informa- tion, and sending more messages in which the information in the later messages is protected by security negotiated by the earlier messages.

Figure 5.16 illustrates the messages exchanged when an SA is established using the Base Exchange. In step 1 the initiator sends a request carrying the Security Association, Proposal, and Transform payloads to show that it wants to establish a Security Association and to advertise the types of security it wants to apply and the algorithms that it supports. It also includes a Nonce payload to randomize the message. The responder checks that the Nonce is new and, if it is willing to estab- lish a Security Association, responds with the precise subset of security options and algorithms that will be applied (step 2). The initiator then generates keys and sends them together with proof of its identity (step 3) and the responder com- pletes the exchange with its keys and proof that it is who it says it is. The SA is now fully established and data transfer can begin. Note that since the identities and keys are sent on the same message, the identities cannot actually be protected by the security mechanisms.

The Identity Protection Exchange provides protection for the identity exchange. This is achieved by introducing an additional message exchange and sharing out the payloads as shown in Figure 5.17 . The Nonce is moved from the initial exchange (steps 1 and 2) to the new exchange (steps 3 and 4) that also swaps keys. Once the

CH05-P374463.indd 144

145

Initiator Responder

IP Network

Security Association, Proposal, Transform, Nonce

Security Association, Proposal, Transform, Nonce

Key Exchange, Identity, Signature, Certificate

Key Exchange, Identity, Signature, Certificate 1

4 3

2

FIGURE 5.16

The ISAKMP messages and payloads exchanged during the establishment of a security association using the Base Exchange.

Initiator Responder

IP Network

Security Association, Proposal, Transform

Security Association, Proposal, Transform

Key Exchange, Nonce

Key Exchange, Nonce 1

4 3

2

Identity, Signature, Certificate, Hash

Identity, Signature, Certificate, Hash

6 5

FIGURE 5.17

The ISAKMP Identity Protection Exchange provides additional security during the establishment of a security association.

5.8 Exchanging Keys

CH05-P374463.indd 145

146 CHAPTER 5 Concepts in IP Security

Initiator Responder

IP Network

Security Association, Proposal, Transform, Key Exchange, Nonce, Identity

Security Association, Proposal, Transform, Key Exchange, Nonce, Identity, Signature, Certificate

Signature, Certificate, Hash 1

3

2

FIGURE 5.18

The number of messages exchanged to set up a security association can be kept down to just three using the Aggressive Exchange.

keys are known they can be applied to all subsequent messages and so the identity exchanges (steps 5 and 6) can be protected by the authentication algorithms and sent along with a Hash payload.

Alternatively, the Aggressive Exchange cuts the number of messages sent to a bare minimum, as shown in Figure 5.18 . In this case, the initiator reduces its Proposal and Transform options so that the responder has no choice other than acceptance or refusal. The initiator can therefore generate its keys up front and it sends these on the initial message along with its identity (step 1). The responder replies with all information in one go (step 2), leaving the initiator to certify its iden- tity and maybe use the authentication algorithm to protect this fi nal stage (step 3).

nonce \'nän(t)s\ n [ ME nanes, alter. (fr. incorrect division of then anes in such phrases as to then anes for the one purpose) of anes one purpose, irreg. fr. an one, fr. OE an ]: the one, particular, or present occasion, purpose, or use < for the ~ >.

FURTHER READING

Personal Encryption Clearly Explained , by Pete Loshin (1998). IP Professional. This book provides a comprehensive introduction to the use of security in the Internet and other networks.

Virtual Private Networks—Making the Right Connection , by Dennis Fowler (1999). Morgan Kaufmann. Fowler describes the use of IPsec to provide secure connections between pri- vate networks. It also provides a good introduction to user authentication and to key man- agement and exchange.

Applied Cryptography: Protocols, Algorithms, and Source Code in C , by Bruce Schneier (1995). John Wiley & Sons. This is a good starting point for those who want to dig deeper into the way that encryption is made to work.

CH05-P374463.indd 146

147

The following lists show specifi c RFCs and other standards broken down by topic.