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