Chapter 3. Network Domain Security

Chapter 3. Network Domain Security

A network can be considered as the physical resource for a communication system. This chapter discusses network domain security. Then the first question we need to answer will be: what is a network domain?

The terminology comes from the cellular network. Traditionally, a cellular service provider owns not only radio frequency spectrums but also certain network infrastructure, for example, base stations, switches, and servers. All of these network entities are connected through the wired network to provide telephony service. Network domain is used to distinguish from the radio wireless segments of a cellular system. That is, once a cellular phone is connected to a base station through a wireless link, the rest of the communication is conducted through a “network domain”. In this Chapter, a network domain is more generally referred to as a network for providing communication services. The main objective of this chapter is to introduce the basic mechanisms used to establish trusted communications. Even though the mechanisms can be applied to the wireless portion of the network, we will defer wireless specific protections to Chapter 5.

The term network domain also refers to as a domain based trust model. In Section 1, we will introduce the domain concept for security applications. Then in Section 2, we will discuss the security mechanisms commonly employed in establishing a protected communication tunnel between two nodes. In Section 3, we will explore some network security protocols as practical applications for the mechanisms introduced in Section 2. Section 4 discusses different protection modes. Section 5 will present security analysis and also points out some common pitfalls in designing network domain security.

1 Domain Concept

It is often that the security and trust relationships are discussed with respect to two scenarios: inter- domain or intra-domain. As we mentioned before, one network domain is used to be a territory of one service provider. In this section, we will generalize the domain concept for the security application purpose.

In general, a communication system may consist of multiple domains. Each domain is a subset of nodes and links or it may be called a subnet. A domain is usually formed based on a business relation, a geographic location, a network configuration, or other relations. Figure 1 depictures a communication system consisting of two domains.

For security discussions, the domain is defined based on a trust model, which we have introduced in Chapter 1. As we also discussed, a domain determines a trust relationship. For example, all the nodes in a particular domain may trust a single certificate authority to issue certificates for public keys. In this case, any node’s certificate can be validated by another node in the same domain.

In cellular networks, a service provider’s domain implies an authentication center holding cryp- tographic keys for all subscribers to conduct access authentication as we mentioned in Chapter 2.

A more classical example is a domain with a centralized key distribution center. In the domain, each node has a protected communication channel with the center. If one node is to communicate

0

Copyright @2008 L.D. Chen and G. Gong. All rights reserved. May be freely reproduced for educational or

personal use.

2

3

1 4

6

5

7

Domain B Domain A

Figure 1: Different Domains

with another node, it will request the key distribution center to either distribute a key to both nodes so that they can initiate communication securely, as shown in (a) of Figure 2, or the key distribution center will relay the protected information between two nodes, by decrypting with the key K I shared with node I and then encrypting with the key K J shared with node J , as shown in (b) of Figure 2. Sometimes a domain is defined based on physical protections. If a subnet is protected to prevent from accessing by outsiders, then the communications inside the domain will be considered as protected. For example, a network inside an access controlled enterprise facility may be considered as a physically protected domain. However, as wireless access is pervasive and open platform allows constant software update, communication security can never depend on physical protections.

We will also see in late of this chapter that inter-domain and intro-domain will demand different infrastructure supports in order to apply different security protections.

2 Establish Trusted Communications

Trusted communications are protected communications which satisfy the following conditions.

1. The communication parties must be assured whom each of them talks to.

2. The communication parties must establish cryptographic keys so that they can apply cryp- tographic functions.

3. The communication parties must negotiate and agree on cryptographic functions to apply for

the protections.

KDC

I J

K IJ K IJ

C = E(K

, P)

KDC

I J

C = E(K

, P) C = E(K

, P)

K I, K J

(a) KDC distributes the key (b) KDC re-encrypts and relays

Figure 2: A Domain with a Key Distribution Center

This section will introduce secure mechanisms used to establish trusted communications between communication parties. In a practical communication system, security mechanisms are executed with the network protocols, for example, Internet Protocol (IP). This section focus on the security mechanisms without including actual protocols. In Section 3, we will explore security mechanisms used in some network protocols. Furthermore, some protocols may be executed among more than two parties. Note that in this section, the security mechanisms are introduced for two parties.

Multiple party mechanisms will be discussed in Chapter 8.

2.1 Mutual Authentication

In Chapter 1, we have introduced an entity authentication to address the need of an authentication server. In order to establish trusted communications, the two parties conduct entity authentication in both directions. A mutual authentication may be a subroutine in a two-party protocol. Normally, it is conducted as the first phase of the protocol.

For convenient discussions, we will name the two parties as Alice (party A) and Bob (party B), as in the most literatures. Please notice that in the first two chapters, we have used “I and “J to name the parties, where it emphasizes that they can be any nodes in a communication system. In this chapter, we focus on establishing trusted communications for two parties. Even though they still could be any two nodes in a communication system, we name them Alice and Bob to make the discussions more personifying.

The purpose of an entity authentication is for one party to receive an assurance on another party’s claimed identity. A real life example is when a telephone conversation starts; a person claimed that she is Alice, where Alice is an identity. Then another party may recognize the voice so that be assured that it is indeed Alice. Here voice recognition can be considered as an entity authentication of identity Alice.

The identity can be defined with respect to a given communication protocol, for example, an IP address, a media access control address, etc..

In the previous example of telephone conversations, entity authentication can be done through

voice recognition, if another party knew Alice well. But in an automatic communication system,

If a cryptographic key is known only by a party with a given identity, and if a party can show that it knows the key, then the party can be authenticated with the identity. Sometimes those keys are referred to as authentication credentials. Passwords have been used to play a similar role as cryptographic keys in authentication. In order to use password for authentication, a protocol must be designed to against certain attacks, for example, dictionary attack. Please refer to [1] for the discussion of using passwords for authentication. We have assigned in the exercise as a discussion topic to find out the limitations in using passwords as credentials for authentications.

The cryptographic key used for authentication must be bound to an identity in an authentic way. The binding is crucial to validate the authentication. For a symmetric key, the verifier must share the key as we discussed in Section 2.2.1. For a public and private key pair, it depends on a trusted third party, certificate authority, to authorize the binding between the identity and the public key.

For entity authentication, a cryptographic scheme is used for one party to prove to another party it “knows a cryptographic key without giving away the key. In Section 2.1 in Chapter 2, we have introduced a method of using a message authentication code for entity authentication if both parties share a symmetric key. Digital signature can be used as a cryptographic scheme for authentication as well, assuming that the public key is certified by a certificate authority trusted by both parties.

Therefore, for entity authentication, a key is bound to an identity, while the proof of knowledge of the key is achieved through a cryptographic scheme.

A mutual authentication is a procedure in which two parties conduct entity authentication mutually. We will introduce mutual authentication through a sample procedure. The example was essentially the same as the protocol presented first time in [2], where it is called MAP1. Then we will discuss some design rationale through some known attacks. It is very important to understand that there is no single comprehensive check list you can use to make sure that the protocol is secure.

For the practical protocol design, it is often that the precautions and pitfalls are learned through known attacks. Indeed, there are some “provably secure” protocols which may provide confidence.

However, each security proof is based on very strict assumptions. If any assumption is no longer to be true, then the security proof collapse. In many of the cases, verifying whether an assumption is true could be as complicated as conducting security analysis for the protocol itself. We will refer to some formal approach later in this section.

The following notations are used in the following schemes and discussions:

- ID _X denotes identity of party X;

- R X , random number generated by party X;

- M AC(K, U, V, W ), message authentication code generated using key K and over data fields (or values) U, V, W ; and

- Sig(X, U, V, W ), digital signature generated by party X over data fields or values U, V, W ; - [U, V, W ] _X , data fields U , V , and W with an attached authentication tag generated by party

X’s authentication key over data U , V , and W . The tag is either generated as a message

authentication code with a symmetric key or a digital signature with a private key. For

example, [U, V, W ] _X = (U, V, W, M AC(K _XY , U, V, W ), where Y is the party who shares K _XY and can verify the M AC.

Protocol 1 (Subroutine) Assuming Alice (A) initiates the protocol, a mutual authentication subroutine can be described in the following steps.

1. A generates a random number R A and sends her identity ID A and R A to B.

2. B generates a random number R _B and sends an authenticated message [ID _B , ID _A , R _B , R _A ] _B to A.

3. A verifies the authenticated message [ID _B , ID _A , R _B , R _A ] _B : If it is valid, then compute [ID _A , R _B ] _A and send it to B. Otherwise, indicate failure and/or abort the protocol.

4. B verifies [ID A , R B ] A . If it is valid, indicate success and/or continue with the protocol.

Otherwise, indicate failure and/or abort the protocol.

The protocol message flow is shown in Figure 3.

A B

ID A , R A

[ID B , ID A , R B , R A ] B

[ID A , R B ] A

Figure 3: Mutual Authentication

Please refer to [2] for a formal proof on the security of Protocol 1. In this section, we will use some variations of Protocol 1 as an example to explain its design rationale and common security flaws.

As we discussed in Section 1.4, in order to discuss the security objectives for mutual authenti-

cation, we need to specify a threat model. First we assume that an adversary Eve (E) has limited

polynomial computing power. (Please see Appendix A for a definition on computing power and

polynomial limitation. ) Also assume that an adversary E can observe the mutual authentication

messages between A and B and between A and any of other nodes as many as polynomial times,

assuming E is to impersonate A. Obviously, E can send the first message on the behalf of A

without being detected. B will send the second message as it was to A. Then if E is able to forge

a valid authentication tag in [ID _A , R _B ] _A , then it can successfully impersonate A. See Figure 4 for

an illustration of the impersonation.

Impersonating A

E B

ID A , R A

[ID B , ID A , R B , R A ] B

[ID A , R B ] A = ?

Figure 4: Impersonation

There could be many ways to forge an authentication tag on the behalf of A. Here are some most straightforward approaches that E may take. Those approaches lead to some basic security requirements for the mutual authentication subroutine as described in Protocol 1.

Forgery means and corresponding requirements for authentication tags:

1. Discover the authentication key of party A. To prevent E from getting the key, it requires that the cryptographic scheme of generating the authentication tag is secure in the sense that even E observes polynomial number of authentication tags, it is still infeasible to recover the key.

2. Forge the authentication tag without knowing the key. To prevent E from forging the tag, it requires the employed scheme of generating authentication tag is unforgeable in the sense that even an adversary can observe polynomial number of authentication tags; the probability of successfully forging a valid tag is still negligible.

3. Re-use the tags previously sent by Party A. This is also called replay attack. To prevent replay attack, it requires the probability that a tag can be reused is negligible.

The first two requirements depend on the security of the cryptographic schemes used to gen- erate the tag. If an adversary can recover the key from the pairs of message and tag it observes, then it implies a total break of the scheme. If the key cannot be recovered, two commonly defined forgeries are described as follows.

Formal definitions of forgery:

• Selective forgery: An adversary can create a valid tag on a message selected by any one with

non-negligible probability.

• Existential forgery: An adversary can create a valid pair of message and tag with non- negligible probability. The message could be any message as long as it has never appeared in an observed message and tag pair by the adversary.

A cryptographic scheme, secure in preventing selective forgery, is not necessarily secure in pre- venting existential forgery. In other words, security against selective forgery is a weaker assumption on the scheme than security against existential forgery. In Protocol 1, it is designed to have party A (or B) to generate a tag with a random number R _B (or R _A ) selected by B (or A). It implicitly assumes that the scheme in a weaker case, that is, it is secure under selective forgery but may not necessarily secure under existential forgery.

The random numbers in Protocol 1 are also used to prevent replay attack to satisfy the third requirement in the above. For each execution, one party selects a fresh random number to force another party to generate a new tag by using the key. This is why the random number used for entity authentication is also called a challenge. The authentication tag is often called a response.

Therefore, the random number should have enough entropy so that the probability of a number repeating is low in the life time of a key.

In some protocol design, one or both random numbers used in the protocol may be replaced with monotonously increased sequence numbers. In order to prevent replay attack, the verifier must store the maximum number used in the last execution so that it can make a comparison. If the new number is larger than the stored number, then it is a valid sequence number for the current execution. The following is an example to use sequence number to generate a tag by party A. We denote the sequence number as S A .

Protocol 2 (Subroutine) Assume A initiates the protocol. A mutual authentication subrou- tine using sequence number for A’s authentication is described as follows. The message flows are illustrated in Figure 5.

1. A generates a random number R A and a sequence number S A , where R A is a random number to challenge B and S A is a sequence number to generate her own authentication tag.

2. A sends R _A and [ID _A , S _A ] _A to B.

3. B compares S _A with the stored sequence number for A. If it is larger than the stored sequence number, then replace the stored number with S A . Otherwise, indicate failure or/and abort the protocol.

4. B verifies [ID _A , S _A ] _A . If it is valid, then generate [ID _B , ID _A , R _A , S _A ] _B and send to A;

Otherwise, indicate error or/and abort the protocol.

5. A verifies the authenticated message [ID B , ID A , R A , S A ] B . If it is valid, indicate success and/or continue with the protocol. Otherwise, indicate failure or/and abort the protocol.

We must have noticed that in Figure 5, when replacing the random number with the sequence number, party A can send her authentication tag in the first message without waiting for party Bs random number to be sent. As a result, instead of three messages (or equivalently, three rounds) as in Protocol 1, the mutual authentication can be conducted in two messages (i.e., two rounds).

Using a sequence number for authentication is often in the case where the number of message flows

is restricted. However, using a sequence number requires the underline cryptographic scheme is

A B [ID A , S A ] A

[ID B , ID A , R A , S A ] B

Figure 5: Use a Sequence Number

secure against existential forgery, a stronger assumption than being secure against selective forgery.

Furthermore, each party must store two sequence numbers for every party it conducts mutual authentication, one for its own maximum used sequence number and another for another party’s maximum used sequence number, which may not be practical for a communication system with a large number of entities. In order to design a sound mutual authentication protocol, it is very important to understand that a protocol can be attacked in many different ways. The following example from [3], as shown as a subroutine of a protocol, yields that Eve can impersonate Alice in a flawed mutual authentication protocol without breaking the cryptographic schemes. The protocol is only slightly different from Protocol 1.

Protocol 3 (Subroutine) (A Flawed Mutual Authentication Protocol) Assume Alice initiates the protocol. It is described as follows.

1. A sends B identity ID _A and a random number R _A .

2. B generates a random number R _B . B generates an authentication tag over ID _B , R _A . He sends [ID _B , R _A ] _B and R _B to A, where R _B is not protected by the tag.

3. A verifies the authenticated message [ID B , R A ] B : If it is valid, then compute [ID A , R B ] A and send it to B. Otherwise, indicate failure and/or abort the protocol; (Note that A’s response has the same format as B’s response, that is, the tag is computed over its own identity and a random challenge from another party.)

4. B verifies [ID A , R B ] A . If it is valid, indicate success and/or continue with the protocol.

Otherwise, indicate failure and/or abort the protocol.

The protocol is illustrated in Figure 6.

Since the authentication response in two directions have the same format, it is easy for Eve to use Alice as a black box to generate a response to Bob so that she can impersonate Alice. E can implement an attack in the following steps.

1. E initiates the protocol with B and claims that she is A. Precisely, E sends ID _A and R _A to

B.

A B

ID A , R A

R B , [ID B , R A ] B

[ID A , R B ] A

Figure 6: Modified Mutual Authentication

2. Upon receiving B’s response R _B , [ID _B , R _A ] _B , E forwards the random number R _B together with ID _B to A.

3. As A receives ID _B , R _B , A considers that B initiates the protocol.

4. A generates a response R A 0

, [ID A , R B ] A and sends to B(E).

5. E uses the response [ID A , R B ] A from A as her own response to B.

We illustrate the attack in Figure 7. Please notice that E can use A’s response as her response, since in both directions, the authentication tags are generated on the same data fields ID _X and R _Y , where X, Y ∈ {A, B}. From such an attack we learned some tips in mutual authentication protocol design. That is, the authentication tags on two directions must be generated over different data fields such that a response generated for one direction cannot be used for another direction.

Mutual authentication is often the first step in a procedure of establishing trusted communica- tions. It must maintain the authentication in the rest of communications. Otherwise, the mutual authentication could be useless. If the mutual authentication is linked with key establishment, the cryptographic keys can be used to make sure that the rest of the communications are restricted to the mutually authenticated parties. In the next section, we will introduce key establishment mechanisms.

2.2 Key Establishment

Key establishment is a procedure for communication parties to establish cryptographic keys, which

can be used for communication protections. In this chapter, we focus on key establishment between

two parties. Chapter 8 will extend the concept to multiple parties. The trust assumption for key

establishment is that two parties are enabling to conduct a mutual authentication, which may

depend on a trusted third party for issuing public key certificates or distributing symmetric keys

such as authentication credentials. In some practical protocols, if a key is distributed to both

parties by a trusted third party, then the key is used to derive new keys, besides used for mutual

A E B ID

, R

R

, [ID

, R

]

R

’, [ID

, R

]

E needs A’s help A thinks B

initiates

ID

, R

[ID

, R

]

B believes he is executing with A

Figure 7: Reflection Attack

authentication, which can also be called a key establishment. However, in this section, we will not discuss this situation but leave it to Chapter 4.

The key establishment can be achieved mainly through either key transport or key agreement.

Key transport is to use a existing key to transport some secret value from one party, sender, to another party, receiver. Then both parties use the secret value together with other information exchanged through the protocol to generate a key or multiple keys. The existing key may be a symmetric key shared by both parties or the receiver’s certified public key.

Key agreement, also called key exchange, is for two parties to agree on a key or multiple keys through exchanging public and/or private information to generate keys. Notice that key transport may be a part of key agreement since the secret values must be protected when exchanged. However, we consider the keys established through key agreement involving contributions by both parties in such a way that one party cannot determine the value of the established keys.

There have been many different definitions on the key transport and key agreement in the literatures. Some of them emphasize whether the establishment is public key based or purely symmetric key based. In most of the practical cases, a key establishment procedure could be a combination of public key and symmetric key methods. It is impossible to exhaust all the situations.

In this section, we will introduce a few examples to explain the design rationale and principals of key establishment.

As we mentioned before, a protocol providing authentication without key establishment is sus- ceptible to an enemy who waits until the authentication is completed and then takes over one end of the communications link. Therefore, key establishment should be bound to a mutual authenti- cation so that one party has assurance that an established key, used to provide confidentiality or authenticity, is in fact shared with the authenticated another party, not an imposter.

To be efficient, it is often to conduct both authentication and key establishment in as few

message exchanges as possible. The following protocol is an example of mutual authentication and

key establishment in three messages. We will use the same notations as we used in Section 3.2.1.

However, we have some assumptions on the “existing keys, which will be described as pre-conditions in the protocol.

Protocol 4 (Mutual authentication with key transport) Assume that Alice initiates the protocol and Bob transports a secret value S to Alice. The pre-conditions and related notations are listed as follows.

• Keys for mutual authentication: Each of A and B has a pair of public and private key with the public key certified by a trusted third party; or A and B share a symmetric key. Notation [U, V, W ] X implies that the data fields U , V , and W are authenticated by party X through either digital signature or message authentication code.

• Keys for key transport: A has a pair of public and private key and the public key is certified by a trusted third party; or A and B share a symmetric key. Notation E A (S) implies the secret value S is encrypted either by A’s key transport public key or a symmetric key transport key shared by both A and B.

For security reasons, the keys used for authentication must be different from the keys used for key transport. That is, in the above two pre-conditions, the keys are different, even though they may all use public and private key pairs or all use symmetric keys.

The procedure is described as follows and illustrated in Figure 8.

1. A sends B identity ID A and a random number R A .

2. B generates a random number R _B and selects a secret value S. Then B sends an authenticated message [ID _B , ID _A , R _B , R _A , E _A (S)] _B to A.

3. A verifies the authenticated message [ID B , ID A , R B , R A , E A (S)] B : If it is valid, decrypt E _A (S) and then compute [ID _A , R _B ] _A and send [ID _A , R _B ] _A to B. Otherwise, indicate failure and/or abort the protocol.

4. B verifies [ID A , R B ] A . If it is valid, indicate success and/or continue with the protocol.

Otherwise, indicate failure and/or abort the protocol.

Upon completing the procedure described in Protocol 4, A should have received a secret value S. However, B has no way to be confirmed that A indeed has received the secret value S. A feature for key establishment, called key confirmation, is described as an assurance provided by one party to another party that it has indeed obtained the key. Obviously, the procedure in Protocol 4 does not have such a feature.

Before we try to add key confirmation to Protocol 4, we will first introduce key derivation. As

we call S a secret value, it may need to apply a key derivation function to S to derive a key or

multiple keys. A key derivation function is usually built with a pseudorandom function as a basic

block. It iterates the basic pseudorandom function multiple times and concatenates the output of

each pseudorandom function execution until enough bits are derived for the applications. We will

not get into the details for a key derivation function here. Please see [4] for discussions on key

derivation functions. We use notation KDF (S, R 1 , R 2 , · · · , R t ) for a key derivation function with

ID A , R A

[ID B , ID A , R B , R A , E A (S)] B

[ID A , R B ] A

Figure 8: Key Transport

input secret value S and other public or private data fields R 1 , R 2 , · · · , R t . Actually, in Protocol 4, if the key is derived by KDF (S, R _A ), then the procedure described is a key agreement since A contributed to the established key with the random value R A .

We will use K S to denote a key derived from the secret value S. Here K S may be a segment of the derived key. The protocol may negotiate on the length of a binary string of the derived keying material as well as how those binary strings are used. For example, the key derivation function is to derive 512 bits and the first 128 bits are used as K _S .

In Protocol 4, A can demonstrate B that she has obtained S by sending a message authentication code generated using K S , for example, M AC(K S , R A , R B , E A (S)) to B in the third message, where M AC(K _S , R _A , R _B , E _A (S)) is a message authentication code generated using K _S on data fields R _A , R _B , and E _A (S), then by verifying the M AC, B can be confirmed that A does have obtained the secret value S.

Usually, for a given key, either it has a limited life time or a new key is needed for different sessions. The key establishing protocol described in Example 3.2.2.1 may be executed as needed to establish different keys. Then it is natural to require that these keys established by different executions of the protocol are independent. That is, if something happens in the future, it should not make all the keys compromised. A feature to address this requirement is called perfect forward secrecy. The concept is first introduced in [3] and defined as follows.

Perfect Forward Secrecy: An authenticated key exchange protocol provides perfect for- ward secrecy if disclosure of long-term secret keying material does not compromise the secrecy of the exchanged keys from earlier sessions.

For Protocol 4, the long-term secret keying material could be authentication key or encryption key to transport the secret value S. If it is the former, say Alice’s authentication key is compromised, then whoever cracked the key can impersonate Alice and initiate the key transport with any party.

Of course, it can obtain secret values for the sessions initiated by the attacker. However, it cannot

decrypt the secret values transported before the key compromising to Alice. If the derived key is

to provide confidentiality, then the communications happened before the long-term authentication

key is compromised can still maintain the secrecy. But if it is the latter, that is, Alices decryption

key for key transport is compromised, then the attacker can get all the secret values transported to Alice and so to decrypt all the conversations between Alice and Bob. Therefore, the protocol described in Protocol 4 does not provide perfect forward secrecy.

In the following example, we will show that perfect forward secrecy is often achieved through Diffie-Hellman key agreement (sometimes it is called Diffie-Hellman key exchange). For the mathe- matics background and its security theory of Diffie-Hellman key agreement, please refer to Appendix A.

Assume that G is a cyclic group generated by a generator g, that is, G =< g >= {1, g, g ² , · · · , g ^q−1 }, where q is the order of the group G. In the following example, the Diffie-Hellman key agreement is operated over group G.

Protocol 5 (Key agreement with perfect forward secrecy) In this protocol, we assume that the entity authentication is conducted using digital signature, even though it can be replaced with message authentication code. We have the following pre-conditions and related notations.

Each of A and B has a pair of public and private key with the public key certified by a trusted third party. Notation Sig _X (U, V, W ) denotes a digital signature over data fields U , V , and W by party Xs private key, X = A or B.

Assume Alice initiates the protocol. The procedure is described as follows and illustrated in Figure 9. In the description, to save the space, we will omit the exchange of identities, but assuming the identities are exchanged either explicitly or implicitly.

1. A selects an integer a, 0 < a < q and selects a random number R _A . A sends R _A , and A’s Diffie-Hellman public value g ^a to B.

2. B selects an integer b, 0 < b < q and a random number R B . B computes S = (g ^a ) ^b and derive a key K _S . Then B sends R _B , B’s Diffie-Hellman public value g ^b , signature σ B = Sig B (R B , R A , g ^a , g ^b ), and M AC(K S , R A ||g ^a ||g ^b ||σ _B ) to A.

3. A verifies the signature σ B = Sig B (R B , R A , g ^a , g ^b ): If it is valid, computes S = (g ^b ) ^a and then verifies M AC(K _S , R _A ||g ^a ||g ^b ||σ _B ); if it is valid, generates signature σ _A = Sig _A (R _A , R _B , g ^a , g ^b ), M AC(K S , R B ||g ^a ||g ^b ||σ _A ) and sends them to B. Otherwise, indicate failure and/or abort the protocol.

4. B verifies signature σ _A , if it is valid, verifies M AC(K _S , , R _B ||g ^a ||g ^b ||σ _A ); if it is valid indicate success and/or continue the protocol. Otherwise, indicate failure and/or abort the protocol.

In the above protocols, the mutual authentication must be bound to the variables used for the

key agreement. In Protocol 5, if Diffie-Hellman public values g ^a and g ^b are not signed in either

direction, then it is subject to a man-in-the middle attack. Precisely, E can intercepts g ^a and

replace it with g ^a

with a ⁰ selected by herself. Then E intercepts g ^b and replace it with g ^b

with her

own choice of b ⁰ . Since the signature is not applied to g ^b , A cannot detect E’s modification. As a

result, after the mutual authenticated key agreement, A and E share keys derived from the value

g ^ab

and E and B share keys derived from value g ^a

^b . That is, E can intercept the communications

between A and B after the key establishment. Notice that E can compute the M ACs without

any problem since they are computed by the key established with A and with B respectively. The

attack is illustrated in the Figure 10, where we omitted the signature and other unrelated variable

to highlight the modifications on the exchanged Diffie-Hellman public values by the attacker E.

A B

R _A , g ^a

R B , g ^b , ! B = Sig B (R B , R A , g ^a , g ^b ), MAC(K S , R A ||g ^a ||g ^b || ! B ) S = (g ^a ) ^b S = (g ^b ) ^a ! A = Sig A (R A , R B , g ^a , g ^b ), MAC(K S , R B ||g ^a ||g ^b || ! A )

Figure 9: Key agreement

A E B

g ^a

g ^a’

MAC(K _AE , M)

S _EB = (g ^a’ ) ^b g ^b

g ^b’

S _AE = (g ^b’ ) ^a

MAC(K _EB , M)

Figure 10: Man-in-the-middle attack to key agreement

So far in this chapter, we have introduced mutual authentication and key establishment. Through some attacks, we have learnt that the protocol design for establishing trusted communications are very subtle. Everything can go wrong even you think you have done every thing right. Numerous authentication and key establishment protocols have been presented in the literature to provide different featured key establishment. You will find an excellent collection of the most well known protocols of authentication and key establishment in [5].

After key establishment, we are ready to use the keys for communication protections. However, the two parties must be able to make a series of decisions before starting to apply the protections.

The next section will introduce algorithm negotiation.

2.3 Cryptographic Algorithm Negotiation

Cryptography algorithm negotiation is also called cipher suite negotiation. It may negotiate au- thentication algorithms, key establishment algorithms, which may include key derivation functions, and protection algorithms (encryption and integrity protection to be applied for communication protection). Depending on which algorithms are negotiable in a protocol, it can be conducted in the beginning, after a mutual authentication, or after a mutual authenticated key establishment. If only protection algorithms are negotiable, then the negotiation may start after a mutual authenticated key establishment.

In the following, a cipher suite is a selection of the algorithms to be negotiated. For example, a suite may be represented as a quartet Σ = (Auth, Key, Enc, M ac), where Auth is the identifier for an authentication algorithm, Key for a key establishment algorithm, Enc for encryption, and M ac for message authentication code. For some protocols, the authentication algorithm is not negotiable, while the others may only allow negotiating encryption and integrity protection algorithm.

The main security concern for algorithm negotiation is a so-called downgrade attack. A down- grade attack is to force the two parties agreeing on a suite, which is weaker than the suite, otherwise, the two parties will use. Each party may have a set of acceptable suites determined by security policy and capacity. Sometimes, for backward compatibility and interoperability with some legacy systems, the acceptable suites have to include some weak suites.

The negotiation may start from one party as an offering party to provide a set of acceptable suites, while another party responds by selecting a suite. The following example explains how a downgrade attack works on a cipher suite negotiation.

Example 1 (Downgrade attack on cipher suite negotiation) Assume that A offers a set of suites {Σ ₁ , Σ ₂ , ..., Σ _t }, among which Σ _w is the weakest and Σ _s is the strongest. B’s security policy says to select the strongest among the offer set whenever negotiating as a responder, if it is implemented in B. In this example, assume that B implemented both Σ w and Σ s .

If an attacker E can intercept the offer set and modifies it to {Σ _w }, then B has no choice other than selecting Σ _w . This simple attack is illustrated in Figure 11.

This is a successful downgrade attack since without interception of E, A and B would have agreed on Σ _s . With E’s downgrade attack, A and B have no choice but selecting Σ _w . Usually, the purpose of the downgrade attack is to force two parties selecting a weak cipher suite so that the communication protections can be compromised through attacking the applied weaker algorithm.

If it is able to apply integrity protection to the negotiation, then the attack would have been

prevented. However, protecting the cipher suite negotiation has been in an “egg and chicken

A B {! 1 , ! 2 , …, ! t }

E

{! w } {! w } {! w }

Apply ! w (Breakable to E)

Figure 11: Downgrade Attack on Cipher Suite Negotiation

dilemma. First, if the key establishment algorithm is a part of negotiation, then the key cannot be established before the negotiation. Without a key, it cannot apply integrity protection for cipher suite negotiation. Even though the key establishment algorithm is not a part of the negotiation and the key is available, it still needs to determine which integrity protection algorithm to be used.

Post verification has been a way to detect a downgrade attack, which is to apply integrity protection to the message exchange history of the negotiation as soon as keys are available and an integrity protection algorithm is identified. For example, in Example 1, A applies an integrity protection to her own offering set and the suite accepted by the B to generate a message authen- tication code. A sends the message authentication code to B. If the message authentication code is not valid when verified, then B will detect that some one may have either modified A’s offering set or his selection. If such an attack is detected, then the negotiated suite will not be used.

Sometimes, post verification may not be able to detect a downgrade attack, if the set of cipher suites includes such a suite which is so weak that it can be broken in real time. In Example 1, if the key agreement algorithm in Σ w is so weak that it can be broken in real time, that is, the key can be recovered timely based on the message exchanged for key agreement, then no matter which integrity protection algorithm is applied, the attacker E can re-generate the message authentication code based on the modified exchange so that the modification will not be detected. Figure 12 shows that if the key establishment algorithm in Σ _w is so weak that it can be broken in real time, that is, E can crack the key soon enough to make the protocol continue without interruption, then E can replace the M AC with the modified offering set.

For further detailed discussion on cipher suite negotiation, please refer to [6]. It should be a general rule that an acceptable suite set shall not include suite which is breakable in real time.

2.4 Protected Communications

After a mutual authenticated key establishment and also cipher suite negotiation, it is ready to

apply the protections to the information to be communicated. Notice that when a cipher suite

A B {! 1 , ! 2 , …, ! t }

E

{! w } {! w } {! w }

Apply ! w for key establishment E obtains K S

MAC(K S , {! 1 , ! 2 , …, ! t }, {! w }) MAC(K S , {! w }, {! w })

Figure 12: Attack on Post Verification

is selected, for each of the algorithms, it also selects its security strength, parameters, mode of operations etc. The protection provided by the selected cryptographic algorithms will form a secure channel or sometimes it is called a protected tunnel.

When the protections are applied to a given communication protocol, it must specify which portion of the data field is to be encrypted and which portion is to be authenticated so that the receiving party can understand how to decrypt the data and how to verify the authenticity and integrity. In the following, we will present an example and explain how to apply protections to the information communicated. The example will consider a general case without specifying communication protocols.

Protocol 6 (Information protection protocol) Assume the protocol allows Alice to protect the data P sending to Bob. Without loss of generality, assume the data is formed by Alice as (H, P ), where H is the header, specified by the communication system and P is the data. The header could include the source and destination addresses, the size of the data, etc.. The pre-conditions for the protocol are described as follows.

• Two parties agreed on a pair of algorithms E and M AC, for encryption and for authenticity respectively.

• Two parties established a pair of keys K _C and K _I for encryption and message authentication code respectively.

The procedures for Alice and Bob are described as follows.

(a) Apply encryption to P with key K _C to get ciphertext C = E(K _C , P );

(b) Apply message authentication code to the header H and ciphertext C with key K I to generate T ag = M AC(K _I , H||C).

2. Alice sends (H, C, T ag) to Bob.

3. Upon receiving (H, C, T ag), Bob recovers the data through the following steps:

(a) Compute a T ag = M ac(K _I , H||C) with K _I and compare it with the received T ag. If they are equal, go to the next step. Otherwise, indicate failure and/or abort;

(b) Decrypt P = D(K _C , C) with K _C and obtain data P .

The procedure at the sender side and the receiver side are illustrated in Figures 13 and 14 respectively.

H P

K C E

H C Tag

Mac

K I

Figure 13: Apply protection by the sender

In this protocol, both encryption and authentication are applied. Please notice that it may not be able to apply encryption to the header, since when it is transferred, the intermediate nodes on the path would need to be able to read the header to determine where to forward the data or the destination node needs the information in the header to recover the data. This is similar to sending a post letter. The letter may be confidential and so encapsulated in an envelope. But the sender and receivers addresses must be presented on the envelope to be readable to all the people who handle the delivery of the letter.

The order of composing encryption and authentication may affect the security strength of the

protection. A formal analysis was conducted in [7] on the security implications on the order of

composing encryption and authentication. It showed that a secure channel protocol designed to

work with a combination of any secure encryption and any secure message authentication code

H C Tag

D

K C

Mac ^=?

K I

Tag’

H P

Figure 14: Recover data by the receiver

must use encryption-then-authentication method. That is, the security cannot be achieved for some encryption and authentication algorithms if they are composed in another order, that is, authentication-then-encryption. Intuitively, message authentication code is used to provide au- thenticity and integrity, which cannot guarantee not to leak information on the protected data.

3 Network Security Protocols

In the previous section, we have introduced the main steps in establishing trusted communications.

As we mentioned before, the protections, including encryption and integrity protection, are usually applied to a specific communication protocol. In this section we will introduce a few commonly implemented security protection protocols, defined in specific communication layers.

In order to understand how to add protections on a specific communication protocol, we will first look into the layered structure of communications. In Chapter 1, we introduced the OSI model. It consists of, from the top to the bottom, application layer, transport layer, network layer, data link layer, and physical layer. For each layer, a header is added as a prefix for the data payload to convey instructions on where to deliver the data and how to process it. Each layer in the protocol stack is tasked with a specific function. Each function will process the data based on the information carried in the header for that layer. In order to transform a piece of data from a source A to a destination B, the data will be processed from the top layer to the bottom layer at the host A and from the bottom layer to the top layer at the host B. At the host A, for each layer, a header will be added to the data payload before passing to the next layer below, while at the host B, the header is removed and only the payload is passed to the next layer above. At a given layer, the header and the payload together form the payload for the next layer below. Figure 15 illustrates the data flow from the source to the destination, where physical layer is omitted since it is unrelated to the security protocols we will discuss in this section.

From Figure 15, we can see that the header and the data payload are defined relative to a given

Data H

Payload

Payload H

Payload

Data H

Payload H

Payload

H

H

Payload

Source Destination

Figure 15: Data Processing in Source and Destination

layer. At each layer, authenticity and integrity can be applied to both the header and payload, while confidentiality may be only provided to the payload, because the header may have to be sent in plaintext so that the payload can be processed based on the information provided in the header.

This section will focus on explaining how to apply the security mechanisms to a communication protocol, rather than getting into the data formats, encoding methods, and syntax.

3.1 Internet Key Exchange and IPsec

In this section, we will introduce a suite of security protocols executed at the network layer, called IP security (IPsec). IPSec is the first and also the most well accepted network security standard for the Internet. It was developed in Internet Engineering Task Force (IETF) in 1998. As Internet Protocol was widely launched, security became the main concerns.

IPsec consists of two main protocols, Authentication Header (AH) and Encapsulating Security Payload (ESP) specified in IETF Request for Comments (RFC) 2406 and 2402 respectively (see [8]

and [9]). Both AH and ESP are information protection protocols in terms what we have used in the previous section. The two protocols provide different security functions. AH provides authenticity and integrity, while ESP provides encryption, authenticity, and integrity for the IP packet.

In IPsec, perhaps, the most important concept is so-called security association (SA). Security

associations are the basis for two communicating parties to execute IPsec protocols. Unlike the

most mathematics or cryptography concepts, security association has neither been formally defined

in IPsec RFCs, nor been represented in any data format. even though it is commonly referred

to a set of cryptographic algorithms and keys as well as their lifetimes. A security association is

defined unidirectionally. That is, for a pair of hosts to communicate, there must be at least two

security associations, one for each direction. Each SA has a security parameter index (SPI): a 32-

bit value identifying an SA. The SPI may not be globally unique but each SPI, source IP address,

and protocol (AH and ESP) will uniquely identify an SA at the receiving host. In Figure 16, it

demonstrates how to use a security association to form an IPsec packet and to recover the data

from a received IPsec packet. Here an IPsec packet is the datagram carried in an IPsec protocol.

IPsec Packet Data

SA in SA out

Data & Authenticity IPsec Packet

Receiving IPsec Packet Preparing IPsec Packet

Figure 16: Use SAs to Process IPsec Packets

Figure 16 is a simplified picture to describe the process of using security associations to process the packets. Actually, in order to implement IPsec, at each host, there must be an SA database (SADB) to hold SAs and a security policy database (SPD) to define the traffic to be protected by each SA. For each packet entering or leaving the IP stack, the SPD must be consulted for a possible application of protections. The security policy can also be represented by traffic selectors to identify the IP traffic to be protected through some characters, for example, the source IP address, the destination IP address, upper layer protocol, source and destination ports, data sensitivity level, etc. .

From the previous section, we understood that in order to apply protections, the two parties must establish cryptographic keys and also agree on cryptographic algorithms to be used. A protocol called Internet Key Exchange (IKE) is used (see [10]) together with “Internet Security Association and Key Management Protocol (ISAKMP) (see [11]) and “Internet IP Security Domain of Interpretation for ISAKMP (see [12]), to establish keys and also negotiate security associations.

The original IKE protocol was designed based on a few authentication and key establishment protocols proposed in the research literature and also IETF community, for example, Station-to- Station (STS) protocol [3]. Besides stated security rationales on the protocols on which IKE is based on, IKE has received formal security analysis, for example, by Canetti and Krawczyk (see [13]).

Recently, a new version of IKE, IKEv2, [14]), was developed in IETF to replace the aforemen- tioned protocols and mechanisms defined in [12], [11] and [10]. Compared with the original IKE, the version 2 has mainly simplified the protocol plus fixed some documented weakness. At the same time, IPsec protocols AH and ESP are also updated in RFC 4302 [15] and RFC 4303 [16]

respectively.

In this section, we will first introduce IKEv2 before explaining how to use AH and ESP to

protect communications at the IP layer.

IKEv2 performs mutual authentication between two parties and establishes two sets of security associations. The first set of security associations is called IKE SAs, which are used to protect the rest of the IKEv2 exchanges, when the keys are available. Under the protection of the IKE SAs, the second set of security associations is negotiated for protocols AH or ESP, which are called CHILD SAs.

The IKEv2 are defined for two parties, Initiator and Responder. Each of the initiator and responder is an IP host, that is, an entity implementing Internet Protocol. All IKE communications consist of pairs of messages, a request, from Initiator to Responder, and a response, from Responder to Initiator. The pair is called an exchange. Four main exchanges are defined in [14] for IKE:

• IKE SA INIT: Negotiate parameters for IKE SAs;

• IKE AUTH: Transmit identities and prove knowledge of authentication credits corresponding to the identities;

• CREATE CHILD SA: Create CHILD SAs for ESP, AH, or both; and

• INFORMATIONAL: Delete an SA, report error condition, or pass other housekeeping infor- mation.

In the following, we explain each of the base exchanges. Depending on the special features, the variations are described in [14]. Some of the notations used in this section may be different from what we have used in the previous sections in order to make the notations as similar to notations in [14] as possible, even though the notations used there are extremely informal. We will explain each of the notations using the terms appeared in the previous sections. The following notations are used for IKE header and different payloads. Here we do not distinguish a notation for a payload and a value carried inside a payload. We use subscript to indicate the value is for or from the initiator or the responder.

• AU T H _i and AU T H _r : Authentication payload, carrying a digital signature or a message authentication code for Initiator and Responder respectively. The data fields over which the signature or MAC is generated will be specified when explaining the exchanges.

• CERT : Certificate payload, carrying a public key certificate.

• CERT REQ: Certificate request payload, carrying a request for a certificate. It is an optional payload since the certificate may be obtained through other bandwidth.

• HDR: IKE header, carrying the Security Parameter Indexes (SPI), version numbers, and flags of various sorts.

• ID _i and ID r : Identification payload, carrying an identification for Initiator and Responder

respectively. (Note that in some literatures, term identification is used as the identity we

used in the previous sections. )

• KE _i and KE _r : Key exchange payload, carrying a Diffie-Hellman key exchange variable for Initiator and Responder respectively. If G is a cyclic group of order q and g is a generator of G, then KE i = g ⁱ , where i is an integer randomly selected by the initiator, 1 < i < q, and KE _r = g ^r , where r is an integer randomly selected by the responder, 1 < r < q.

• N _i and N r : Nonce payload, carrying a nonce generated by the initiator and the responder respectively.

• SA _i and SA _r : Security association payload, carrying a set of proposed protocols and crypto- graphic algorithms from Initiator and a set of accepted protocols and cryptographic algorithms by Responder respectively. Notice that an SA payload is different from a security association (SA) defined in [14] even though they use the same abbreviation. A security association may include not only algorithms but also the keys. However, the security association payload does not carry any secret information, for example, symmetric keys. In other words, the secu- rity association payload is used to negotiate security associations, but not to carry security associations, even though in [14], it uses the same notations.

• T S _i and T S _r : Traffic selector payload, carrying traffic selector. Traffic selector payload is used to exchange the information on which IP packets the negotiated CHILD SA will be applied to. We will further explain the meaning of the notations T S i and T S r when introducing exchange.

• N : Notation payload, carrying housekeeping information.

If any of the above payload is optional, then it will be shown in brackets. For example, [CERT REQ]

indicates that optionally a certificate request payload can be included.

IKE SA INIT

Initiator Responder

HRD, SA i1 , KE i , N i −→

←− HRD, SA _r1 , KE r , N r , [CERT REQ]

In the above initial exchange, SA _i1 payload carries a set of algorithms that the initiator sup- ports for IKE SA. For IKE, there are four algorithms: a Diffie-Hellman group, a pseudorandom function (PRF), an integrity protection algorithm (message authentication code), and an encryp- tion algorithm. The key exchange payload KE _i is the initiators Diffie-Hellman public value. When the first request is formed, the initiator will use his best guessed Diffie-Hellman group, that is, the group which is most likely to be selected by the responder, to generate the value for KE i .

The Responder chooses a cryptographic suite from the initiator proposed set and expresses the choice in SA _r1 payload. If the initiators guess on the Diffie-Hellman group is correct, the responder generates KE r in the same group to complete the Diffie-Hellman key agreement. Otherwise, the responder will reject the proposal.

The pseudorandom function (PRF) is used for key derivation. After the initial exchange, each

party can generate a shared secret value SKEY SEED such as

i r

The SKEY SEED is used as a key derivation key to generate a binary string SK, called keying material, where

SK = KDF (SKEY SEED, N _i ||N _r ||SP I _i ||SP I _r ) = SK _d ||SK _ai ||SK _ar ||SK _ei ||SK _er ||SK _pi ||SK _pr , where SK _d is the key to be used to generate keys for CHILD SAs, SK ai and SK ar are authentication (a.k.a. integrity protection) keys, SK _ei and SK _er are encryption keys, SK _pi and SK _pr are keys to be used to generate entity authentication data in the authentication exchange, for the initiator and the responder respectively. KDF is the key derivation function using the PRF as the basic block to iterate for as many times as it is needed to derive enough bits required by the sum of length for all the keys.

While the keys are generated and the cryptographic algorithms are negotiated, it is ready to apply the protections to the rest of the exchanges. The notation SK{U, V, W, · · · , Y } indicates that the payloads U, V, W, · · · , Y are encrypted and integrity protected using the keys SK _e and SK a respectively for each direction.

We noticed that in the initial exchange, the identifications for each party are not exchanged, which is different from the examples presented in the previous section to demonstrate the mutual authenticated key establishment. The intention, according to [14], is to protect the identifications and provide privacy. This model was referred as “post-specified model” in [13] to be analyzed. The identities are exchanged in the following authentication exchange.

IKE Auth

Initiator Responder

HRD, SK{ID _i , [CERT ], [CERT REQ], [ID _r ], AU T H i , SA i2 , T S i , T S r } −→

←− HRD, SK{ID _r , [CERT ], AU T H r , SA r2 , T S i , T S r }

In this exchange, the initiator and the responder exchange their identifications and optionally certificates. The value in the authentication payload AU T H is either a message authentication code or a digital signature. If certificates are exchanged, then authentication payload AU T H shall carry a digital signature and the certificate used to verify authentication data AU T H.

The authentication payload from the initiator AU T H _i is generated over the first message of IKE SA INIT concatenated with N _r and the value P RF (SK _pi , ID _i ). Similarly, the authentication payload from the responder AU T H r is generated over the second message of IKE SA INIT con- catenated with N _i and the value P RF (SK _pr , ID _r ). Here N _i , ID _i , N _r , ID _r are only the values not the corresponding payloads.

By exchanging the authentication payload, the initiator and the responder mutually authenti-

cated each other and also bind the authentication with the key establishment. The nonce N _i and

N r serve as implicit challenges to prevent replay attack.

The authentication payload also enables a post-verification for the cipher suite negotiation, because it authenticates the SA payload sent previously.

In this exchange, the initiator and the responder start to negotiate CHILD SAs with payloads SA _i2 and SA _r2 . This negotiation will be completed in the following CREATE CHILD SA exchange.

The notations T S _i and T S _r are used differently from other notations. Two payloads T S _i and T S _r are sent in both directions in the exchange. In each direction, T S _i and T S _r specify the source address of the traffic forwarded from or the destination address of traffic forwarded to the initiator and the responder of the CHILD SA pair respectively.

The IKE AUTH exchange can create a single CHILD SA. The keys for this CHILD SAs can be derived as

KEY M AT = KDF (SK d , N i ||N _r ),

where N _i and N _r are nonce exchanged in IKE SA INIT and the KEY M AT will have the length at least the sum of the lengths of different keys for the CHILD SA.

The above four messages are called initial exchanges. Additional CHILD SAs can be established through CREATE CHILD SA as described in the follows.

CREATE CHILD SA

Initiator Responder

HRD, SK{[N ], SA, N _i , [KE _i ], [T S _i , T S _r ]} −→

←− HRD, SK{SA, N _r , [KE r ], [T S i , T S r ]}

The CREATE CHILD SA exchange can be initiated by either of the two parties which have conducted initial exchanges. In other words, whoever initiates the above exchange will be the initiator of CREATE CHILD SA exchange, which is not necessarily to be the same party as in the initial exchanges.

The CREATE CHILD SA exchange is protected by IKE SAs. The notification N tells whether this is to re-key an existing CHILD SA. In this exchange, it is optional to conduct a new Diffie- Hellman key exchange with payload KE i and KE r . Again, the same “best guess” rule applies when the initiator generating KE i . If the new Diffie-Hellman key exchange is conducted, then the keying material for the CHILD SAs is derived as

KEY M AT = KDF (SK _d , g ^ir (new)||N _i ||N _r ).

Four SAs can be created through a single negotiation, one pair of SAs for ESP and another pair for AH.

The CREATE CHILD SA exchange can be used to change the keys of existing IKE SA. In this case, the traffic selector payload is omitted in each direction.

INFORMATIONAL

Informational exchange is used to convey control message between the pair, like error infor-

mation of certain events. Each message may contain none to multiple payloads, for example,

So far we have introduced all the IKEv2 exchanges. An IKE protocol includes all the subroutines to establish trusted communications we introduced in Section 3.2, that is, mutual authentication, key establishment, cipher suite negotiation, and communication protections.

The security mechanisms to establish trusted communications we have introduced are targeted on information protections. However, some of the security issues must be considered even though they may not threat the confidentiality and integrity of the information communicated. At this point, we like to introduce a security issue on resource exhaustion of legal parties. This is an attack through flooding a target host with IKE initiation requests from forged IP addresses. As a result, the targeted host will exhaust its CPU by engaging in a huge amount of operations to generate responses. Sometimes, it is also called a denial of service (DoS) attack. The main idea to prevent from such an attack is to let the responder first make sure that the initiator’s IP address is valid and real before committing to “heavy duty” operations. In both IKEv1 and IKEv2, it uses a random binary string called cookies for the responder to confirm the initiator’s IP address. In IKEv2, the cookies is carried in “Notify” payload. With cookies, the initial exchange of IKEv2 can be described as follows.

IKE SA INIT with Cookies

Initiator Responder

HDR, SA _i1 , KE _i , N _i −→

←− HRD, N (COOKIE)

HRD, N (COOKIE), SA i1 , KE i , N i −→

←− HDR, SA _r1 , KE _r , N _r , [CERT REQ]

In the modified initial exchange, the responder, instead of generating its Diffie-Hellman value for the response, it generates a cookie and waits for the confirmation. If the initiator can send the cookie back, then it implies that the initiator is indeed at the claimed IP address. Then there are a few related issues here. First of all, generating a cookie shall be significantly less complicated than generating a regular response, including a Diffie-Hellman value KE r and also selecting the SA r . Otherwise, it will not make sense to play this trick. Second, there must be a way to maintain the state of cookies. When the initiator sends the cookies back, the responder must be able to compare it with the cookies sent. In a network with a large scale of nodes, maintaining states with communication parties may not be a realistic task. In IKEv2, the cookies are generated as

Cookie =< V ersionIDof Secret||Hash(N _i ||IP _i ||SP I _i || < secret >, >

where IP i is the IP address of the initiator and < secret > is a randomly generated value by the

responder. The value < secret > will be updated from time to time. It does not need to be shared

with any party but maintained in the responder. Therefore, it can be used with multiple parties

at a period of time. In this way, the responder will not need to maintain the state of cookies but