Chapter 3. Network Domain Security

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 1 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: interdomain 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 cryptographic 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.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 2 2 3 1 4 5 6 Domain A 7 Domain B 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 cryptographic functions. 3. The communication parties must negotiate and agree on cryptographic functions to apply for the protections.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 3 K I, K J KDC C = E(K I, P) KDC C = E(K J, P) K IJ K IJ I C = E(K IJ, P) J I 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,

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 4 this may not be the case since the communication parties may be two devices and must find some electronic way to recognize each other. 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; - MAC(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

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 5 example, [U, V, W ] X = (U, V, W, MAC(K XY, U, V, W ), where Y is the party who shares K XY and can verify the MAC. 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 ID A, R A B [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 authentication, 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.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 6 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 generate 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.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 7 Existential forgery: An adversary can create a valid pair of message and tag with nonnegligible 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 preventing 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 subroutine 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

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 8 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.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 9 A ID A, R A B 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, [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 communications. 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

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 10 A E B ID A, R A A thinks B initiates ID B, R B R B, [ID B, R A ] B E needs A s help R A, [ID A, R B ] A [ID A, R B ] A 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 susceptible 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 authentication 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.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 11 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

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 12 A ID A, R A B [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, MAC(K S, R A, R B, E A (S)) to B in the third message, where MAC(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 MAC, 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 forward 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

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 13 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 mathematics 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 2,, 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 MAC(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 MAC(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 ), MAC(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 MAC(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 MACs 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.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 14 A R A, g a B 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 b ) a! A = Sig A (R A, R B, g a, g b ), MAC(K S, R B g a g b! A ) S = (g a ) b Figure 9: Key agreement A E B g a g a g b g b S EB = (g a ) b S AE = (g b ) a MAC(K AE, M) MAC(KEB, M) Figure 10: Man-in-the-middle attack to key agreement

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 15 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 authentication 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, Mac), 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 downgrade 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 {Σ 1, Σ 2,..., Σ 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

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 16 A E B {! 1,! 2,,! t } {! 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 authentication 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 MAC 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

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 17 A E B {! 1,! 2,,! t } {! 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 MAC, 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.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 18 1. Alice applies the protection through the following steps: (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 = MAC(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 = Mac(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 K I Mac 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

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 19 H C Tag K I Mac =? K C D 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 authenticity 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

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 20 Data Data H T Payload H T Payload H IP Payload H IP Payload H L Payload H L 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.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 21 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 aforementioned 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.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 22 3.1.1 IKEv2 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 information. 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. AUT H i and AUT 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. )

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 23 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 i, 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 cryptographic 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 security 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 supports 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 encryption 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

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 24 SKEY SEED = P RF (N i N r, g ir ). 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 ], AUT H i, SA i2, T S i, T S r } HRD, SK{ID r, [CERT ], AUT 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 AUT 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 AUT H r is generated over the second message of IKE SA INIT concatenated 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 authenticated 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.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 25 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 MAT = KDF (SK d, N i N r ), where N i and N r are nonce exchanged in IKE SA INIT and the KEY MAT 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 MAT = 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 information of certain events. Each message may contain none to multiple payloads, for example,

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 26 notification, delete, and configuration payloads. The exchange is protected by the IKE SA and therefore only occurs after the initial exchanges. 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), SA i1, KE i, N i HRD, N(COOKIE) 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 ersionidofsecret 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

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 27 storing the value < secret >. Incorporating SP I i into the calculation ensures that if multiple IKE SAs are being set up in parallel, then they will all get different cookies. It also includes N i to the calculation of cookies so that if an attacker can only observe the second message, it cannot forge the third message 3. In other words, if an attacker observes the message 2, then it can get the cookies. However, it must select an N i to form the third message. If N i is different, then the responder will generate different cookies. Notice that using cookies to prevent from DoS attack is based on an implicit assumption on the network that the attacker who sends massive initiate requests must not be able to receive all the responses to different forged IP addresses. This assumption probably is true in the IP networks. It also tells that not all the security solutions can be based on mathematics functions or cryptographic mechanisms. When designing a network protocol, all possible attacks using the specific properties of the network must be considered, besides employing robust security schemes. As we mentioned before, from security point of view, IKEv2 has not made significant changes from the original IKE as presented in [10]. Some research results appeared on their performance comparisons. It seems that employing IKEv2 can improve its performance by reducing network traffic and delays. 3.1.2 IPsec Modes IPsec protocols can be executed in either transport mode or tunnel mode. For transport mode, it assumes that the source and the destination for IPsec protocols are also the actual source and destination of the IP packets as indicated in Figure 17. In other word, the host with the given IP address will execute both IPsec protocol and Internet protocol. As we explained in the beginning of this section, at the source host, an IP header is added to the transport layer packet before passing to the data link layer. When IPsec is applied, an IPsec header will be added to the transport layer packet before IP header is added as illustrated in Figure 18. Here we do not specify whether the IPsec header is an ESP header, an AH header or both. We use IP header AB to indicate the header is from the source host A (or B) to destination host B (or S). IPsec SA (A!B) IPsec SA (B!A) Host A Host B Figure 17: Transport mode Tunnel mode is designed to handle the situation that the IPsec protection is applied between two different IP hosts than the source and the destination of the IP packets as illustrated in Figure 19. This is a typical situation when Virtual Private Network (VPN) is applied. The protection is applied only when the IP packets travel through public Internet. In this case, the IPsec destination may be a security gateway for an enterprise network, instead of the real destination for the data.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 28 IP header AB IPsec header TCP header Data Figure 18: IPsec header in transport mode The packet for tunnel mode will include two IP headers as illustrated in Figure 20. Please notice that the first IP header have the same pair of source and destination addresses as the IPsec packet, which are two Internet routers R 1 and R 2, as illustrated in Figure 19 where R 1 and R 2 are two ends of the tunnel. The second IP header will have IP addresses for host A and host B, which are the source and destination addresses for the IP packet. IPsec SA (R 1! R 2 ) R 1 R 2 IPsec SA (R 2! R 1 ) Host A Host B Figure 19: Tunnel mode IP header R 1 R 2 IPsec header IP header AB TCP header Data Figure 20: IPsec header in tunnel mode The two IPsec modes allow either end-to-end or hop-by-hop protections. By transport mode, it applies end-to-end protection to the network layer payload. Please notice that this may or may not implies an end-to-end protection to the data, since the destination IP host may not be the final destination of the data. It may process the IP packet and pass the payload to the next host. 3.1.3 Authentication Header (AH) Authentication Header (AH) is an IPsec protocol to provide message origin authentication, integrity protection, and anti-replay attack for the IP datagrams. It is called header because the message authentication code, even though in [15], it is called Integrity Check Value (ICV), together with other information is inserted to the header. We have called a message authentication code as a tag. In AH, the tag is inserted in the header as illustrated in Figure 21. For each AH, a monotonically increasing sequence number is used for anti-replay purpose. It proposes certain challenge since the IPsec packets may arrive to the destination in a different order

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 29 Next Payload Preserved Header Length Security parameter Index (SPI) Sequence number Integrity Check Value (ICV) Figure 21: Authentication Header from the order they are formed. It allows a window in certain size to accommodate the different orders. In AH, it will be ideal if the data over which ICV is generated includes all the data fields in the IP header. However, some of the data fields in the IP header may be modified during the transition. Therefore, AH can only apply protection on the data fields in the IP header which are immutable. AH can be applied in either transport mode or tunnel mode. Figure 22 illustrates an IP packet before and after protection, where the left frame includes everything to be authenticated. The IP header with a star denotes that it only covers the immutable data fields. The second header with a doted frame will not appear when it is in transport mode. There is a difference in handling IPv4 and IPv6 packets when applying AH. The difference will not be related to security principles and therefore is not introduced in this section. Please refer to [15] for the details. 3.1.4 Encapsulating Security Payload (ESP) Encapsulating Security Payload (ESP) is an IPsec protocol. Differently from AH, it can provide multiple protection combinations, including confidentiality only, integrity (plus data origin authentication) only, confidentiality and integrity (plus data origin authentication). It has anti-replay feature, when integrity is provided. If it is in tunnel mode and confidentiality is provided, then it can also provide traffic flow confidentiality (TFC). In the rest of this section, integrity implies both integrity and data origin authentication. If both confidentiality and integrity are provided, then the encryption will be applied to data payload first before applying message authentication code to the ciphertext together with other data fields. According to [7], this order will provide the most broad applicability to different mode of operations for the underlying encryption and mac algorithms. Figure 23 illustrates ESP in either transport mode or in tunnel mode. When it is in transport mode, the IP header in the doted frame does not appear. For ESP, the authenticated data does not include IP header. The message authentication code, also called integrity check value (ICV) in [?] is attached at the end of the packet as a tag. For some encryption algorithms, an initialization vector is needed to decrypt the ciphertext. Therefore, it has to be sent in plaintext, even though in some literature, IV is considered as a part

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 30 IP header 1 * IP header 1 Next Header Payload Length Preserved Next Header Payload Length Preserved Security parameter Index (SPI) Sequence number Integrity Check Value (ICV) = 000 0 IP header 2 TCP header Security parameter Index (SPI) Sequence number Integrity Check Value (ICV) IP header 2 TCP header Data Data MAC K Figure 22: An IP packet protected with AH

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 31 IP header 1 Security parameter Index (SPI) Sequence number Initiation vector (IV) Integrity protected IP header 2 TCP header Data Encrypted Padding Pad length Next header Integrity Check Value (ICV) Figure 23: An IP packet protected with ESP

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 32 of ciphertext. ESP can be applied alone or together with AH. The integrity provided by AH is over more data fields than the fields provided by ESP. Therefore, when both AH and ESP are applied to the same IP packet in transport mode (with the same source and destination), it is suggested to apply ESP first so that the integrity will be applied to as much data as possible. The readers can, as an exercise, figure out the format for an IP packet protected by both ESP and AH. Similarly, there is a difference in applying ESP to IPv4 and IPv6, which we have omitted in this section. The IPsec protocol suite has been launched to secure Internet and become an inseparable part of Internet protocols. It serves as an excellent example of establish trusted computations. It is worth to notice that the Internet protocol treats the TCP packet as its payload. Therefore, the security protection is considered as in a hop-by-hop manner even though transport mode is end-to-end relative to both IP addresses. In the next section, we will introduce another well launched security protocol applied on one layer above network layer. 3.2 Transport Layer Security (TLS) In this section, we will introduce another well launched network security protocol called Transport Layer Security (TLS). TLS was first standardized by IETF between 1997 and 1999 based on Secure Socket Layer (SSL). SSL is a protocol developed by Netscape to provide security connections through Internet. Its earliest version can be traced back to 1994. SSL has gone through a number of revisions before it was adopted by IETF and specified in IETF by RFC 2246 [17] in 1999. Please see [19] for a comprehensive history from SSL to TLS and other related protocols. SSL was designed for a user to establish a security connection through Internet to a server. Therefore, the two parties are named as client and server in both SSL and TLS. Especially, when SSL was designed, it is to make sure that a server the client connected to through Internet is indeed the one the client wants to communicate. This is also the reason that in TLS, client authentication through public key certificate is optional, while server authentication is required. Differently from IPsec, TLS itself is a layered protocol consisting of a record protocol and client protocols. The record protocol is on the top of a transport protocol, for example, TCP. The TLS record protocol encapsulates four upper layer protocols, also called client protocols. The four TLS upper layer protocols are handshake protocol, change cipher spec protocol, alert protocol, and application data protocol. The record layer will take messages from the upper client to be transmitted, fragment to the manageable blocks, optionally compress, applies message authentication and encryption, and then transmit. The received data will be decrypted, verified, decompressed, re-constructed and delivered to the upper client. Figure 24 illustrates the TLS record layer and other client protocols. TLS has been the most widely adopted protocol to protect application data and therefore also gone through several revisions. In this lecture note, the introduction on TLS is based on the latest version of TLS published as IETF RFC [?]. 3.2.1 TLS Handshake In this section, we will first introduce the message flows for the full handshake, including cipher suite negotiation, mutual authentication, key establishment, and using the keys to protect application

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 33 Handshake Change Application Alert cipher spec Data Record Layer TCP Figure 24: TLS Protocol Stack data. The full handshake consists of the following messages. Handshake Protocol Client Server ClientHello ServerHello Certif icate ServerKeyExchange Certif icaterequest ServerHelloDone Certif icate ClientKeyExchange Certif icatev erif y {ChangeCipherSpec} F inished {ChangeCipherSpec} F inished Application data Application data The messages marked * are optional and situation-dependent. They are not always sent. {ChangeCipherSpec} is a single message protocol by itself and not a handshake message. It is sent with other handshake messages to improve performance. In the next few subsections, we will explain what is carried in each of the messages and what cryptographic functions each of them executes.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 34 3.2.2 Hellos and TLS Cipher Suites The ClientHello and ServerHello are the two messages for the client and the server to negotiate a cipher suite as well as a compression method. Each of the client and the server generates a random number and exchange them in the hello messages. The client hello message provides a list of supported cipher suites. A typical TLS cipher suite consists of four algorithms, key establishment, authentication, symmetric key encryption, and a hash function. For example, a cipher suite denoted as T LS DHE RSA W IT H AES 128 CBC SHA implies that the key establishment will use ephemeral Diffie-Hellman key exchange method, the authentication will use RSA digital signature, the symmetric key based encryption will use AES CBC mode with key size 128 bits, and hash function is SHA. For a given TLS cipher suite, the hash function will be used to form a keyed hash message authentication code, called HMAC. The HMAC may also be used as a pseudo-random function (PRF) to form a key derivation function. The server hello message carries a selected cipher suite in the list proposed by the client, if there is a match with the cipher suites the server supports. Otherwise, it will response with a failure alert. Here we will not goto details on alert messages. 3.2.3 KeyExchange and Key Establishment If a cipher suite is selected, then it will use the selected algorithm to generate key exchange messages. With messages ClientKeyExchange and ServerKeyExchange, the client and the server will establish a secret value, called pre-master secret. TLS mainly provide three options for key exchange, DHE (ephemeral Diffie-Hellman), DH (Diffie-Hellman, where the server s Diffie-Hellman public value may be certified together with its parameters), and RSA (key transport). For DHE, messages ClientKeyExchange and ServerKeyExchange carries the ephemeral Diffie-Hellman public values from the client and the server respectively. Then the client and the server generate a pre-master secret value through an ephemeral Diffie-Hellman key exchange. Especially, ServerKeyExchange will carry cryptographic parameters for the Diffie-Hellman key exchange. For DH, it is always assume that the server s public Diffie-Hellman value is included in the server s certificate and delivered in message Certif icate. Therefore, ServerKeyExchange will not be sent. If the client s Diffie-Hellman public value is also certified, then it will be delivered with Certif icate message and ClientKeyExchange message is sent but empty. Otherwise, the client will generate a Diffie-Hellman public value using the parameters provided in the server s Certif icate and send it in ClientKeyExchange. For RSA, the client will generate a pre-master secret value, encrypt it with the server s RSA public key, and send it in the ClientKeyExchange message. For RSA, ServerKeyExchange will not be sent. The following table summerizes which values are exchanged in the key exchange messages and how the pre-master secret is generated in each of the key exchange algorithms. The operations are conducted in the specified mathematics structures by each algorithm, which we omitted in the table. The public key or public value are obtained from the Certificate if they are not sent through key exchange messages.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 35 KeyExchange and Key Establishment Protocol ServerKeyExchange ClientKeyExchange P re-m astersecret DHE Y s = g s Y c = g c Z = g sc DH n/a [Y c = g c ] Z = g sc RSA n/a E(P k s, Z) Z The pre-master secret is used to derive a value called mater secret through a pseudo-random function. The value master secret has a fixed length for any negotiated cipher suite. For a given cipher suite, the value master secret is expended to keying materials with required length by the cipher suite. The keying material will be segmented to multiple keys. In TLS, for a given algorithm, a key is used as a write key for either the client or the server. In other words, a key is used unidirectionally. Therefore, for an encryption algorithm, it requires a client write key and a server write key. Similarly, for a MAC algorithm, it requires a client mac key and a server mac key. For some algorithms, the initiation vectors (IVs) are also generated through the keying material so that it will not need to be transported. Figure 25 describes how the TLS keys are derived. Client random Pre-master secret Server random KDF Master secret KDF Keying material Client write key Server write key Figure 25: Key Derivation in TLS TLS also specified an anonymous Diffie-Hellman key exchange, denoted in the cipher suite as DHanon. We will not discuss it in this section but will wait to Chapter 4.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 36 3.2.4 Certificate and Authentication The server authentication can be conducted explicitly or implicitly, depending on the selected cipher suite. When key exchange algorithm is an ephemeral Diffie-Hellman key exchange, that is, DHE, the server authentication is conducted explicitly by including a digital signature in the message ServerKeyExchange. In order to prevent replay attack, the random numbers exchanged in hello messages are included in the message to be signed. If the server authentication is conducted explicitly through digital signature, then the signature public key and its certificate is sent in Certif icate. For key exchange DH and RSA, the message ServerKeyExchange is not sent. In this case, the server is authenticated implicitly through the established key. In the message F inished, the server will prove that it owns the private key corresponding to the certified Diffie-Hellman public value or certified RSA public key by confirming that it can correctly establish the key. If the server is authenticated implicitly, then message Certif icate will carry the certificate for either the Diffie-Hellman public value or the RSA public key. As we mentioned before, the Client authentication has been optional due to the original intention of SSL design. The server can optionally send Certif icaterequest to the Client. Then the client can conduct an explicit authentication by sending a digital signature in Certif icatev erif y message. The signature is generated over all the handshake messages, sent and received, starting at ClientHello. If the client conducts an explicit authentication by Certif icatev erif y, then a certificate for digital signature must be included in message Certif icate. 3.2.5 Finished and Post-Verification Notice that the message CertificateV erify can also serve as a post verification of the cipher suite negotiation provided by the client. However, since client authentication is optional, this message may or may not be sent. The post-verification for the cipher suite negotiation is provided in message F inished. A finished message is always sent immediately after a change cipher spec message to conduct key confirmation, implicit authentication, and post verification of the cipher suite negotiation. The message F inished carries a message authentication code over all the handshake messages sent and received before this F inished message using the master secret. The computation of the message authentication code for client and server includes different labels. Especially, the message authentication code by the server covers the F inished message of the client. 3.2.6 Application Data Protection Application data are processed by the record layer before it is transmitted. It breaks the data string to fragments. For each fragment, a message authentication code is first generated using the mac key. The mac is concatenated with the data. Then the data and mac will be encrypted by an encryption key with the selected algorithm. The procedure is illustrated in Figure 26. The order of encryption and authentication in TLS is different from ESP in IPsec. It generates message authentication code over the plaintext data and then encrypt both the data and the mac. This order has been considered as not generally secure by [7]. However, when the encryption algorithm is a block cipher with CBC mode or a stream cipher, such an order will provide the security as defined in [7].

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 37 K mac Mac Data MAC K enc Enc Record Header Data MAC Encrypted Figure 26: Data Protection in TLS 3.2.7 Security Analysis on TLS As we mentioned before, TLS is a protocol to provide a security connection through internet to a server. Its primary security goal is to make sure that the server a client application is connecting to is indeed the one it wants to connect. When the client authentication is not conducted, TLS protocol as it is specified in [18] cannot be considered as a trusted communication as you will find in the exercise 1 of the following. However, TLS is often used to establish a protected channel for user to enter password. The application data will not be exchanged unless the client enters a right password. Remember that the password is protected by the keys generated during the handshake. If the handshake is hijacked, then the server will not be able to get a right password and the application data will not be exchanged. This is a good example to demonstrate that a security protocol must be used in its designed scenarios. Otherwise, it will not achieve its security goals. In Chapter 22 of [20], more pitfalls are elaborated in transplanting a security protocol to an application which the protocol is not designed for. 4 Protection Modes For a given path from one node to another, it may consist of multiple links. Each link is called a hop. In Figure 27, the path from node 1 to node n consists of n 1 links. If data is transported from node 1 to node n, it can be protected in two ways. For encryption, it can have node 1 and node n establish keys so that when it is encrypted by node 1, only node n can decrypt it. For the communication path from node 1 to node n, this is called end-to-end encryption. We can define end-to-end integrity protection and authenticity in the same way. We will call it an end-to-end protection when not specifying encryption or integrity protection and authenticity.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 38 Hop-by-hop 1 2 3 n End-to-end Figure 27: Protection Modes Another way to protect the communications between node 1 and node n is to have each link, between node i and node i + 1, i = 1, 2,, n 1, establish keys to apply protections. If the data is encrypted by node i 1 using K i 1,i, then node i must decrypt it using key K i 1,i and then encrypt again using K i,i+1. When the data is transported from node 1 to node n, it is encrypted at every link and processed, decrypted and encrypted again at each intermediate node. This kind of encryption is called hop-by-hop encryption. In the same way, we can define hop-by-hop integrity protection and authenticity. In general we will call it, encryption or integrity protection and authenticity, a hop-by-hop protection. The way to apply protections, either hop-by-hop or end-to-end, is called a protection mode. In this section, we will discuss protection modes. In this chapter so far, we have discussed the main schemes in establishing trusted communications between two entities. When the keys are established and algorithms are agreed, the communications can be protected between these two entities. Each of the protocols we have introduced are for communications over a specific layer. For example, IPsec applies protections in IP layer, while TLS applies protections in transport layer. We will see that for a given path, the protection mode is often determined by the communication protocol where the protections are applied. Furthermore, it may be the case that hop-by-hop and end-to-end protections co-exist. For example, when a client and a server establish a TLS session, the data is protected between the client and the server. In IP layer, during the data is transported, it may go through several IP routers. Assume that both the client and the server are IP entities, that is, they have IP addresses and execute IP. For each link between two IP entities, it may be protected through IPsec. Figure 28 describes such a situation. For the TLS session, it has the property that if data is encrypted by the client, then it can only be decrypted by the server. The routers in the middle, even though they are also involved in processing the IP packets, have no way to know the actual data since they are protected at a higher layer. Similarly, if the client applies the integrity protection and authenticity, then the server can verify it. In this case, we would say the data is protected end-to-end between the client and the server. As we have discussed in IPsec, the two IP entities have pairwise (unidirectional) IPsec SAs and will process IPsec packets transported from one entity to another based on SAs. As a result, the packets will be processed at each router. For example, in Figure 28, for an IPsec packet passing through router R 1 from the client to the server, it will use SA C1, security association from the client

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 39 Client Server TLS session R 1 R 2 IPsec SA C1, SA 1C IPsec SA 12, SA 21 IPsec SA 2S, SA S2 Figure 28: Protections by TLS and IPsec to R 1, to decrypt or/and verify and then use SA 12, security association from R 1 to R 2 to encrypt or/and authenticate before routing it to R 2. At router R 2, it will be processed again before routing to its final destination, the server. Therefore, at IPsec layer, it provides hop-by-hop protections. Please notice that it may not have to use hop-by-hop mode at IPsec layer. It can use tunnel mode for IPsec to make it end-to-end from the client to the server. Here we use transport mode IPsec between two IP entities to explain the difference between TLS and IPsec. For a path between two nodes, it may take only one hop in one layer but may take multiple hops when considered in another layer. As we have illustrated in Figure 28, in TLS layer, the client and the server are connected in one hop. However, the client and the server are connected at IP layer with three hops. With existing security protocols and mechanisms in each layer, an obvious dilemma appears: whether we should depend on hop-by-hop protections or enforce end-to-end protections. In this section, we will discuss the different aspects of hop-by-hop and end-to-end protections as well as how to determine which protection is suitable for a given scenario. 4.1 Hop-by-hop Protections Hop-by-hop protections have the following aspects. 1. Transport based: Hop-by-hop protections are often provided through transport protocols. Some of the communication protocols transport the information in a hop-by-hop manner. For example, Internet Protocol routes IP packets hop-by-hop from one router to another. If transport mode IPsec is used, hop-by-hop protections are established between different nodes to protect the transported information. The protections are determined by its two end nodes without considering any specific security aspects of the data to be transported. For example, IPsec will use the same protections on different kinds of data. That is, no matter it is some one s credit card number or a piece of public news, as long as it is transported in IP packets from one given router to another, it will be protected in the same way. Actually, the routers will not be able to distinguish the difference. On the other hand, protections in a transport

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 40 protocol are more efficient since an established trust communications between two nodes can be provided for all kinds of traffic and last for a relatively longer time period. 2. Media dependent: Sometimes, the information is transported through different links by different media. The protections on the certain media can only protect one hop. For example, if a wireless link is involved, then it can be protected in a wireless specific protection on that wireless hop. Therefore, hop-by-hop protection may not be concatenated to cover the whole path since some protections are applied only on a specific hop. 3. Access control: Hop-by-hop protections are often a built-in part of certain communication protocols. They are designed to fit special features for the communication media and also provide special countermeasures. They are often a part of service together with the transport media. For the media specific protections, they may also provide access control. We will look into these aspects in Chapter 4. 4. Service centric: The trust model for hop-by-hop is transport centric not application or user centric. The objective of a hop-by-hop protection is to protect the transport in order to provide a reliable service. It assumes that the nodes who process the security protected data is trustworthy in the sense that it is faithful to conduct such a service. The hop-by-hop protections are against attacks by outsiders. 4.2 End-to-end Protection End-to-end protections have the following aspects. 1. Application/user based: End-to-end protections are often established for a specific application or user. The trust model for end-to-end protections is application centric or user centric. The protections are exclusive in the sense that only the two end nodes are trusted to access the information. 2. Media independent: By the nature, end-to-end protections are usually applied in a relatively higher layer so that it does not need to be processed on the way to reach its final destination. Therefore, end-to-end protection is often media independent and can be used for different scenarios. 3. Exclusive trust: End-to-end protections are often needed dynamically. It demands efficient protocol to establish such protections. Once the trusted communications are established, the path may dedicate to a specific application and a pair of entities. 4.3 Landscape on Protection Modes As we have mentioned before, in a communication system, both protection modes may co-exist. When a transport protocol is designed, the protections shall be a part of original design, instead of an add on, so that its performance and security can both considered together with the transport protocols. However, the security policy and the security strength may not be able to differentiate for different applications. On the other hand, for a given application, the protections will be designed based on the trust model of the application and the assumptions on each parties. The protections

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 41 shall deal with the security threats proposed to the application and satisfy the requirements of the application. Some of the security protocols provide tunnel mode, for example, IPsec, that is, the security will not be processed by the intermediate nodes such that the security protection is end-to-end even though the transport is executed in a hop-by-hop manner. It is often that end-to-end and hop-byhop are combined in the same protocol layer. For example, it uses tunnel IPsec mode to provide end-to-end protections between two gateways of different domains and IPsec transport mode to provide hop-by-hop protections once the IP packets entered intranet of an enterprise network. When conducting a security analysis on an application, it must be based on its own trust model and the protections designed specifically for the application, instead of hop-by-hop protections at the lower layer. Hop-by-hop protections usually depend on a more complicated trust model. However, on the other hand, hop-by-hop protections are considered as a part of the transport itself. Without a reliable transport protocol, any security protections applied to an application will not work. Therefore, each of the protection modes, hop-by-hop and end-to-end protections plays its own role in a system. One cannot replace another. Exercises 1. Security Analysis on IKE Auth: (a) Try to find a man-in-the-middle attack on the above exchanges with the modification that the data fields where AUT H i and AUT H r are generated exclude value P RF (SK pi, ID i ) and P RF (SK pr, ID r ) respectively. (b) Try to find an alternative way to bind the authentication with Diffie-Hellman key exchange without using the values P RF (SK pi, ID i ) and P RF (SK pr, ID r ). 2. Security Analysis on TLS: (a) Assume the key establishment algorithm is RSA, and the client authentication is not conducted, that is, message Certif icatev erif y is not sent. Try to identify an attack which hijacks the session by sending an attacker generated pre-master secret to the server, where the messages F inished can carry along without being detected by either the client and the server. (b) Explain the attack identified in 1 will not gain access to the server, if the client must enter password before any further application data will be exchanged. (c) Try to explain why key establishment algorithms RSA and DH cannot provide perfect forward secrecy. References [1] P. Wang, Y. Kim, V. Kher, and T. Kwon, Strengthen Password-based Authentication Protocols Against Online Dictionary Attacks, ACNS 2005, Lecture Notes in Computer Science, Volume 3531, Springer-Verlag, 2005.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 42 [2] M. Bellare and P. Rogaway. Entity Authentication and Key Distribution. Advances in Cryptology- Crypto 1993 pp. 110 125. Lecture Notes in Computer Science, Volume 773, Springer-Verlag. 1994. [3] W. Diffie, P.C. Van Oorschot, and M.J. Wiener, Authentication and authenticated key exchanges. Design, Codes, and Cryptography, 2(1992), pp.107-128. [4] Y. Dodis, R. Gennaro, J. Hastad, H. Krawczyk, and T. Rabin. Randomness Extraction and Key Derivation Using the CBC, Cascade and HMAC Modes, Advances in Cryptology- Crypto 2004 pp. 494 510. Lecture Notes in Computer Science, Volume 3152, Springer-Verlag. 2004. [5] C. Boyd and A. Mathuria. Protocols for Authentication and Key Establishment Springer-Verlag, 2003. [6] K. Hoeper and L. Chen. Where EAP Security Claimes Fail, Proceeding of QShine, 2007. [7] H. Krawczyk The Order of Encryption and Authentication for Protecting Communications (Or: How Secure is SSL?), Advances in Cryptology- Crypto 2001 pp. 310 331. Lecture Notes in Computer Science, Volume 2139, Springer-Verlag. 2001. [8] S. Kent and R. Atkinson. IP Authentication Header, IETF Request for Comments 2402, 1998. [9] S. Kent and R. Atkinson. IP Encapsulating Security Payload, IETF Request for Comments 2406, 1998. [10] D. Harkins and D. Carrel. Internet Key Exchange, IETF Request for Comments 2409, 1998. [11] D. Maughan, M. Schertler, M. Schneider, and J. Turner. Internet Security Association and Key Management Protocol (ISAKMP), IETF Request for Comments 2408, 1998. [12] D. Piper. The Internet IP Security Domain of Interpretation for ISAKMP, IETF Request for Comments 2407, 1998. [13] R. Canetti and H. Krawczyk Security Analysis of IKE s Signature-based Key-Exchange Protocol, Advances in Cryptology- Crypto 2002 pp. 143 161. Lecture Notes in Computer Science, Volume 2442, Springer-Verlag. 2002. [14] C. Kaufman. Internet Key Exchange (IKEv2) Protocol, IETF Request for Comments 4306, 2005. [15] S. Kent. IP Authentication Header, IETF Request for Comments 4302, 2005. [16] S. Kent. IP Encapsulating Security Payload (ESP), IETF Request for Comments 4303, 2005. [17] T. Dierks and C. Allen. The TLS Protocol (Version 1.0), IETF Request for Comments 2246, 1999. [18] T. Dierks and E. Rescorla. The Transport Layer Security (TLS) Protocol (Version 1.1), IETF Request for Comments 4346, 2006. [19] E. Rescorla. SSL and TLS - Designing and Building Secure Systems, Addison-Wesley, 2001.

Communication System Security, Chapter 3, Draft, L.D. Chen and G. Gong, 2008 43 [20] C. Douligeris and D. N. Serpanos. Network Security - Current Status and Future Directions, IEEE Press by Wiley-Interscience, 2007.