Chapter 3. Network Domain Security - University of...

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 chapterdiscusses network domain security. Then the first question we need to answer will be: what is anetwork domain?

The terminology comes from the cellular network. Traditionally, a cellular service providerowns 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 wirednetwork to provide telephony service. Network domain is used to distinguish from the radio wirelesssegments of a cellular system. That is, once a cellular phone is connected to a base station througha wireless link, the rest of the communication is conducted through a “network domain”. In thisChapter, a network domain is more generally referred to as a network for providing communicationservices. The main objective of this chapter is to introduce the basic mechanisms used to establishtrusted communications. Even though the mechanisms can be applied to the wireless portion ofthe 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, wewill introduce the domain concept for security applications. Then in Section 2, we will discussthe security mechanisms commonly employed in establishing a protected communication tunnelbetween two nodes. In Section 3, we will explore some network security protocols as practicalapplications for the mechanisms introduced in Section 2. Section 4 discusses different protectionmodes. Section 5 will present security analysis and also points out some common pitfalls in designingnetwork domain security.

1 Domain Concept

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

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

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

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

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

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


23

1 4

6

5

7

Domain B Domain A

Figure 1: Different Domains

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

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

2 Establish Trusted Communications

Trusted communications are protected communications which satisfy the following conditions.

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

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

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


KDC

I J

KIJ KIJ

C = E(KIJ, P)

KDC

I J

C = E(KI, P) C = E(KJ, P)

KI, KJ

(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 betweencommunication parties. In a practical communication system, security mechanisms are executedwith the network protocols, for example, Internet Protocol (IP). This section focus on the securitymechanisms without including actual protocols. In Section 3, we will explore security mechanismsused in some network protocols. Furthermore, some protocols may be executed among more thantwo 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 authenticationserver. In order to establish trusted communications, the two parties conduct entity authenticationin 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 toname the parties, where it emphasizes that they can be any nodes in a communication system. Inthis chapter, we focus on establishing trusted communications for two parties. Even though theystill could be any two nodes in a communication system, we name them Alice and Bob to makethe discussions more personifying.

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

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

In the previous example of telephone conversations, entity authentication can be done throughvoice recognition, if another party knew Alice well. But in an automatic communication system,


this may not be the case since the communication parties may be two devices and must find someelectronic way to recognize each other.

If a cryptographic key is known only by a party with a given identity, and if a party can showthat it knows the key, then the party can be authenticated with the identity. Sometimes those keysare referred to as authentication credentials. Passwords have been used to play a similar role ascryptographic keys in authentication. In order to use password for authentication, a protocol mustbe designed to against certain attacks, for example, dictionary attack. Please refer to [1] for thediscussion of using passwords for authentication. We have assigned in the exercise as a discussiontopic 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 authenticway. The binding is crucial to validate the authentication. For a symmetric key, the verifier mustshare the key as we discussed in Section 2.2.1. For a public and private key pair, it depends ona trusted third party, certificate authority, to authorize the binding between the identity and thepublic key.

For entity authentication, a cryptographic scheme is used for one party to prove to anotherparty 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 ifboth parties share a symmetric key. Digital signature can be used as a cryptographic scheme forauthentication as well, assuming that the public key is certified by a certificate authority trustedby both parties.

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

A mutual authentication is a procedure in which two parties conduct entity authenticationmutually. We will introduce mutual authentication through a sample procedure. The example wasessentially the same as the protocol presented first time in [2], where it is called MAP1. Then wewill discuss some design rationale through some known attacks. It is very important to understandthat 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 throughknown 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 tobe true, then the security proof collapse. In many of the cases, verifying whether an assumption istrue could be as complicated as conducting security analysis for the protocol itself. We will referto some formal approach later in this section.

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

- IDX denotes identity of party X;

- RX , 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 partyX’s authentication key over data U , V , and W . The tag is either generated as a messageauthentication code with a symmetric key or a digital signature with a private key. For


example, [U, V,W ]X = (U, V,W, MAC(KXY , U, V, W ), where Y is the party who shares KXY

and can verify the MAC.

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

1. A generates a random number RA and sends her identity IDA and RA to B.

2. B generates a random number RB and sends an authenticated message [IDB, IDA, RB, RA]Bto A.

3. A verifies the authenticated message [IDB, IDA, RB, RA]B: If it is valid, then compute[IDA, RB]A and send it to B. Otherwise, indicate failure and/or abort the protocol.

4. B verifies [IDA, RB]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.

B A IDA, RA

[IDB, IDA, RB, RA]B

[IDA, RB]A

Figure 3: Mutual Authentication

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

As we discussed in Section 1.4, in order to discuss the security objectives for mutual authenti-cation, we need to specify a threat model. First we assume that an adversary Eve (E) has limitedpolynomial computing power. (Please see Appendix A for a definition on computing power andpolynomial limitation. ) Also assume that an adversary E can observe the mutual authenticationmessages 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 Awithout being detected. B will send the second message as it was to A. Then if E is able to forgea valid authentication tag in [IDA, RB]A, then it can successfully impersonate A. See Figure 4 foran illustration of the impersonation.


Impersonating A

E B IDA, RA

[IDB, IDA, RB, RA]B

[IDA, RB]A = ?

Figure 4: Impersonation

There could be many ways to forge an authentication tag on the behalf of A. Here are somemost straightforward approaches that E may take. Those approaches lead to some basic securityrequirements 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 requiresthat the cryptographic scheme of generating the authentication tag is secure in the sense thateven E observes polynomial number of authentication tags, it is still infeasible to recover thekey.

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

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

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

Formal definitions of forgery:

• Selective forgery : An adversary can create a valid tag on a message selected by any one withnon-negligible probability.


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

A cryptographic scheme, secure in preventing selective forgery, is not necessarily secure in pre-venting existential forgery. In other words, security against selective forgery is a weaker assumptionon the scheme than security against existential forgery. In Protocol 1, it is designed to have partyA (or B) to generate a tag with a random number RB (or RA) selected by B (or A). It implicitlyassumes that the scheme in a weaker case, that is, it is secure under selective forgery but may notnecessarily secure under existential forgery.

The random numbers in Protocol 1 are also used to prevent replay attack to satisfy the thirdrequirement in the above. For each execution, one party selects a fresh random number to forceanother party to generate a new tag by using the key. This is why the random number used forentity 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 numberrepeating is low in the life time of a key.

In some protocol design, one or both random numbers used in the protocol may be replacedwith monotonously increased sequence numbers. In order to prevent replay attack, the verifiermust store the maximum number used in the last execution so that it can make a comparison. Ifthe new number is larger than the stored number, then it is a valid sequence number for the currentexecution. The following is an example to use sequence number to generate a tag by party A. Wedenote the sequence number as SA.

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

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

2. A sends RA and [IDA, SA]A to B.

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

4. B verifies [IDA, SA]A. If it is valid, then generate [IDB, IDA, RA, SA]B and send to A;Otherwise, indicate error or/and abort the protocol.

5. A verifies the authenticated message [IDB, IDA, RA, SA]B. If it is valid, indicate successand/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 sequencenumber, party A can send her authentication tag in the first message without waiting for party Bsrandom 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 flowsis restricted. However, using a sequence number requires the underline cryptographic scheme is


A B [IDA, SA]A

[IDB, IDA, RA, SA]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 mutualauthentication, one for its own maximum used sequence number and another for another party’smaximum used sequence number, which may not be practical for a communication system witha large number of entities. In order to design a sound mutual authentication protocol, it is veryimportant to understand that a protocol can be attacked in many different ways. The followingexample from [3], as shown as a subroutine of a protocol, yields that Eve can impersonate Alice in aflawed mutual authentication protocol without breaking the cryptographic schemes. The protocolis only slightly different from Protocol 1.

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

1. A sends B identity IDA and a random number RA.

2. B generates a random number RB. B generates an authentication tag over IDB, RA. Hesends [IDB, RA]B and RB to A, where RB is not protected by the tag.

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


The protocol is illustrated in Figure 6.

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

1. E initiates the protocol with B and claims that she is A. Precisely, E sends IDA and RA toB.


B A IDA, RA

RB, [IDB, RA]B

[IDA, RB]A

Figure 6: Modified Mutual Authentication

2. Upon receiving B’s response RB, [IDB, RA]B, E forwards the random number RB togetherwith IDB to A.

3. As A receives IDB, RB, A considers that B initiates the protocol.

4. A generates a response RA′, [IDA, RB]A and sends to B(E).

5. E uses the response [IDA, RB]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 IDX andRY , where X, Y ∈ {A,B}. From such an attack we learned some tips in mutual authenticationprotocol design. That is, the authentication tags on two directions must be generated over differentdata fields such that a response generated for one direction cannot be used for another direction.

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

2.2 Key Establishment

Key establishment is a procedure for communication parties to establish cryptographic keys, whichcan be used for communication protections. In this chapter, we focus on key establishment betweentwo parties. Chapter 8 will extend the concept to multiple parties. The trust assumption for keyestablishment is that two parties are enabling to conduct a mutual authentication, which maydepend on a trusted third party for issuing public key certificates or distributing symmetric keyssuch as authentication credentials. In some practical protocols, if a key is distributed to bothparties by a trusted third party, then the key is used to derive new keys, besides used for mutual


A B E IDA, RA

RB, [IDB, RA]B

RA’, [IDA, RB]A

E needs A’s help A thinks B initiates

IDB, RB

[IDA, RB]AB 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 notdiscuss 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 informationexchanged through the protocol to generate a key or multiple keys. The existing key may be asymmetric 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 keysthrough exchanging public and/or private information to generate keys. Notice that key transportmay 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 insuch 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 theliteratures. Some of them emphasize whether the establishment is public key based or purelysymmetric key based. In most of the practical cases, a key establishment procedure could be acombination 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 ofkey establishment.

As we mentioned before, a protocol providing authentication without key establishment is sus-ceptible to an enemy who waits until the authentication is completed and then takes over one endof the communications link. Therefore, key establishment should be bound to a mutual authenti-cation so that one party has assurance that an established key, used to provide confidentiality orauthenticity, 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 fewmessage exchanges as possible. The following protocol is an example of mutual authentication andkey establishment in three messages. We will use the same notations as we used in Section 3.2.1.


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

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

• Keys for mutual authentication: Each of A and B has a pair of public and private key withthe 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 througheither 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 bya trusted third party; or A and B share a symmetric key. Notation EA(S) implies the secretvalue S is encrypted either by A’s key transport public key or a symmetric key transport keyshared by both A and B.

For security reasons, the keys used for authentication must be different from the keys used forkey transport. That is, in the above two pre-conditions, the keys are different, even though theymay 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 IDA and a random number RA.

2. B generates a random number RB and selects a secret value S. Then B sends an authenticatedmessage [IDB, IDA, RB, RA, EA(S)]B to A.

3. A verifies the authenticated message [IDB, IDA, RB, RA, EA(S)]B: If it is valid, decryptEA(S) and then compute [IDA, RB]A and send [IDA, RB]A to B. Otherwise, indicate failureand/or abort the protocol.


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

Before we try to add key confirmation to Protocol 4, we will first introduce key derivation. Aswe call S a secret value, it may need to apply a key derivation function to S to derive a key ormultiple keys. A key derivation function is usually built with a pseudorandom function as a basicblock. It iterates the basic pseudorandom function multiple times and concatenates the output ofeach pseudorandom function execution until enough bits are derived for the applications. We willnot get into the details for a key derivation function here. Please see [4] for discussions on keyderivation functions. We use notation KDF (S, R1, R2, · · · , Rt) for a key derivation function with


B A IDA, RA

[IDB, IDA, RB, RA, EA(S)]B

[IDA, RB]A

Figure 8: Key Transport

input secret value S and other public or private data fields R1, R2, · · · , Rt. Actually, in Protocol4, if the key is derived by KDF (S, RA), then the procedure described is a key agreement since Acontributed to the established key with the random value RA.

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

In Protocol 4, A can demonstrate B that she has obtained S by sending a message authenticationcode generated using KS , for example, MAC(KS , RA, RB, EA(S)) to B in the third message, whereMAC(KS , RA, RB, EA(S)) is a message authentication code generated using KS on data fields RA,RB, and EA(S), then by verifying the MAC, B can be confirmed that A does have obtained thesecret value S.

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

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

For Protocol 4, the long-term secret keying material could be authentication key or encryptionkey 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 cannotdecrypt the secret values transported before the key compromising to Alice. If the derived key isto provide confidentiality, then the communications happened before the long-term authenticationkey is compromised can still maintain the secrecy. But if it is the latter, that is, Alices decryption


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

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

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

Protocol 5 (Key agreement with perfect forward secrecy) In this protocol, we assumethat the entity authentication is conducted using digital signature, even though it can be replacedwith 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 trustedthird party. Notation SigX(U, V,W ) denotes a digital signature over data fields U , V , and W byparty Xs private key, X = A or B.

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

1. A selects an integer a, 0 < a < q and selects a random number RA. A sends RA, and A’sDiffie-Hellman public value ga to B.

2. B selects an integer b, 0 < b < q and a random number RB. B computes S = (ga)b

and derive a key KS . Then B sends RB, B’s Diffie-Hellman public value gb, signatureσB = SigB(RB, RA, ga, gb), and MAC(KS , RA||ga||gb||σB) to A.

3. A verifies the signature σB = SigB(RB, RA, ga, gb): If it is valid, computes S = (gb)a and thenverifies MAC(KS , RA||ga||gb||σB); if it is valid, generates signature σA = SigA(RA, RB, ga, gb),MAC(KS , RB||ga||gb||σA) and sends them to B. Otherwise, indicate failure and/or abort theprotocol.

4. B verifies signature σA, if it is valid, verifies MAC(KS , , RB||ga||gb||σA); if it is valid indicatesuccess 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 thekey agreement. In Protocol 5, if Diffie-Hellman public values ga and gb are not signed in eitherdirection, then it is subject to a man-in-the middle attack. Precisely, E can intercepts ga andreplace it with ga′

with a′ selected by herself. Then E intercepts gb and replace it with gb′with her

own choice of b′. Since the signature is not applied to gb, A cannot detect E’s modification. As aresult, after the mutual authenticated key agreement, A and E share keys derived from the valuegab′

and E and B share keys derived from value ga′b. That is, E can intercept the communicationsbetween A and B after the key establishment. Notice that E can compute the MACs withoutany problem since they are computed by the key established with A and with B respectively. Theattack is illustrated in the Figure 10, where we omitted the signature and other unrelated variableto highlight the modifications on the exchanged Diffie-Hellman public values by the attacker E.


B A

RA, ga

RB, gb, !B = SigB(RB, RA, g

a, g

b), MAC(KS, RA||g

a||g

b||!B)

S = (ga)b

S = (gb)a

!A = SigA(RA, RB, ga, gb), MAC(KS, RB||ga||gb||!A)

Figure 9: Key agreement

A B E

ga

ga’

MAC(KAE, M)

SEB = (ga’ )bgbgb’

SAE = (gb’ )a

MAC(KEB, M)

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


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

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

2.3 Cryptographic Algorithm Negotiation

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

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

The main security concern for algorithm negotiation is a so-called downgrade attack. A down-grade attack is to force the two parties agreeing on a suite, which is weaker than the suite, otherwise,the two parties will use. Each party may have a set of acceptable suites determined by securitypolicy and capacity. Sometimes, for backward compatibility and interoperability with some legacysystems, 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 acceptablesuites, while another party responds by selecting a suite. The following example explains how adowngrade attack works on a cipher suite negotiation.

Example 1 (Downgrade attack on cipher suite negotiation) Assume that A offers a setof suites {Σ1,Σ2, ...,Σt}, among which Σw is the weakest and Σs is the strongest. B’s securitypolicy says to select the strongest among the offer set whenever negotiating as a responder, if it isimplemented 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 otherthan 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 haveagreed on Σs. With E’s downgrade attack, A and B have no choice but selecting Σw. Usually, thepurpose of the downgrade attack is to force two parties selecting a weak cipher suite so that thecommunication 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 beenprevented. However, protecting the cipher suite negotiation has been in an “egg and chicken


A B

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

E

{!w}

{!w}{!w}

Apply !w (Breakable to E)

Figure 11: Downgrade Attack on Cipher Suite Negotiation

dilemma. First, if the key establishment algorithm is a part of negotiation, then the key cannot beestablished before the negotiation. Without a key, it cannot apply integrity protection for ciphersuite negotiation. Even though the key establishment algorithm is not a part of the negotiationand 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 integrityprotection to the message exchange history of the negotiation as soon as keys are available andan integrity protection algorithm is identified. For example, in Example 1, A applies an integrityprotection to her own offering set and the suite accepted by the B to generate a message authen-tication code. A sends the message authentication code to B. If the message authentication codeis not valid when verified, then B will detect that some one may have either modified A’s offeringset 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 ciphersuites includes such a suite which is so weak that it can be broken in real time. In Example 1, ifthe key agreement algorithm in Σw is so weak that it can be broken in real time, that is, the keycan be recovered timely based on the message exchanged for key agreement, then no matter whichintegrity protection algorithm is applied, the attacker E can re-generate the message authenticationcode based on the modified exchange so that the modification will not be detected. Figure 12 showsthat if the key establishment algorithm in Σw is so weak that it can be broken in real time, thatis, E can crack the key soon enough to make the protocol continue without interruption, then Ecan replace the MAC with the modified offering set.

For further detailed discussion on cipher suite negotiation, please refer to [6]. It should be ageneral 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 toapply the protections to the information to be communicated. Notice that when a cipher suite


A B

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

E

{!w}

{!w}{!w}

Apply !w for key establishment

E obtains KS

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

Figure 12: Attack on Post Verification

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

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

Protocol 6 (Information protection protocol) Assume the protocol allows Alice to protectthe 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 couldinclude the source and destination addresses, the size of the data, etc.. The pre-conditions for theprotocol are described as follows.

• Two parties agreed on a pair of algorithms E and MAC, for encryption and for authenticityrespectively.

• Two parties established a pair of keys KC and KI for encryption and message authenticationcode respectively.

The procedures for Alice and Bob are described as follows.


1. Alice applies the protection through the following steps:

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

(b) Apply message authentication code to the header H and ciphertext C with key KI togenerate Tag = MAC(KI ,H||C).

2. Alice sends (H,C, Tag) to Bob.

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

(a) Compute a Tag = Mac(KI ,H||C) with KI and compare it with the received Tag. Ifthey are equal, go to the next step. Otherwise, indicate failure and/or abort;

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

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

H P

E KC

H C Tag

Mac KI

Figure 13: Apply protection by the sender

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

The order of composing encryption and authentication may affect the security strength of theprotection. A formal analysis was conducted in [7] on the security implications on the order ofcomposing encryption and authentication. It showed that a secure channel protocol designed towork with a combination of any secure encryption and any secure message authentication code


H C Tag

D KC

Mac =? KI

Tag’

H P

Figure 14: Recover data by the receiver

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

3 Network Security Protocols

In the previous section, we have introduced the main steps in establishing trusted communications.As we mentioned before, the protections, including encryption and integrity protection, are usuallyapplied to a specific communication protocol. In this section we will introduce a few commonlyimplemented security protection protocols, defined in specific communication layers.

In order to understand how to add protections on a specific communication protocol, we willfirst look into the layered structure of communications. In Chapter 1, we introduced the OSImodel. 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 datapayload to convey instructions on where to deliver the data and how to process it. Each layer inthe protocol stack is tasked with a specific function. Each function will process the data based onthe information carried in the header for that layer. In order to transform a piece of data from asource A to a destination B, the data will be processed from the top layer to the bottom layer atthe 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 thehost B, the header is removed and only the payload is passed to the next layer above. At a givenlayer, the header and the payload together form the payload for the next layer below. Figure 15illustrates the data flow from the source to the destination, where physical layer is omitted since itis unrelated to the security protocols we will discuss in this section.

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


Data

HT Payload

Payload HIP

Payload

Data

HT Payload

HIP Payload

HL HL 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 sentin 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 communicationprotocol, 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, calledIP security (IPsec). IPSec is the first and also the most well accepted network security standardfor the Internet. It was developed in Internet Engineering Task Force (IETF) in 1998. As InternetProtocol was widely launched, security became the main concerns.

IPsec consists of two main protocols, Authentication Header (AH) and Encapsulating SecurityPayload (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 theprevious section. The two protocols provide different security functions. AH provides authenticityand 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). Securityassociations are the basis for two communicating parties to execute IPsec protocols. Unlike themost mathematics or cryptography concepts, security association has neither been formally definedin IPsec RFCs, nor been represented in any data format. even though it is commonly referredto a set of cryptographic algorithms and keys as well as their lifetimes. A security association isdefined unidirectionally. That is, for a pair of hosts to communicate, there must be at least twosecurity 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, itdemonstrates how to use a security association to form an IPsec packet and to recover the datafrom a received IPsec packet. Here an IPsec packet is the datagram carried in an IPsec protocol.


IPsec Packet Data

SAin SAout

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 processthe 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 protectedby each SA. For each packet entering or leaving the IP stack, the SPD must be consulted for apossible application of protections. The security policy can also be represented by traffic selectors toidentify 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 sensitivitylevel, etc. .

From the previous section, we understood that in order to apply protections, the two partiesmust establish cryptographic keys and also agree on cryptographic algorithms to be used. Aprotocol called Internet Key Exchange (IKE) is used (see [10]) together with “Internet SecurityAssociation and Key Management Protocol (ISAKMP) (see [11]) and “Internet IP Security Domainof 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 establishmentprotocols 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 isbased on, IKE has received formal security analysis, for example, by Canetti and Krawczyk (see[13]).

Recently, a new version of IKE, IKEv2, [14]), was developed in IETF to replace the aforemen-tioned protocols and mechanisms defined in [12], [11] and [10]. Compared with the original IKE,the version 2 has mainly simplified the protocol plus fixed some documented weakness. At thesame 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 toprotect communications at the IP layer.


3.1.1 IKEv2

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

The IKEv2 are defined for two parties, Initiator and Responder. Each of the initiator andresponder is an IP host, that is, an entity implementing Internet Protocol. All IKE communicationsconsist of pairs of messages, a request, from Initiator to Responder, and a response, from Responderto 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 correspondingto the identities;

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

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

In the following, we explain each of the base exchanges. Depending on the special features, thevariations are described in [14]. Some of the notations used in this section may be different fromwhat 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 eachof the notations using the terms appeared in the previous sections. The following notations areused for IKE header and different payloads. Here we do not distinguish a notation for a payloadand a value carried inside a payload. We use subscript to indicate the value is for or from theinitiator or the responder.

• AUTHi and AUTHr: Authentication payload, carrying a digital signature or a messageauthentication code for Initiator and Responder respectively. The data fields over which thesignature or MAC is generated will be specified when explaining the exchanges.

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

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

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

• IDi and IDr: Identification payload, carrying an identification for Initiator and Responderrespectively. (Note that in some literatures, term identification is used as the identity weused in the previous sections. )


• KEi and KEr: Key exchange payload, carrying a Diffie-Hellman key exchange variable forInitiator and Responder respectively. If G is a cyclic group of order q and g is a generator ofG, then KEi = gi, where i is an integer randomly selected by the initiator, 1 < i < q, andKEr = gr, where r is an integer randomly selected by the responder, 1 < r < q.

• Ni and Nr: Nonce payload, carrying a nonce generated by the initiator and the responderrespectively.

• SAi and SAr: Security association payload, carrying a set of proposed protocols and crypto-graphic algorithms from Initiator and a set of accepted protocols and cryptographic algorithmsby 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 mayinclude not only algorithms but also the keys. However, the security association payload doesnot carry any secret information, for example, symmetric keys. In other words, the secu-rity association payload is used to negotiate security associations, but not to carry securityassociations, even though in [14], it uses the same notations.

• TSi and TSr: Traffic selector payload, carrying traffic selector. Traffic selector payload is usedto exchange the information on which IP packets the negotiated CHILD SA will be appliedto. We will further explain the meaning of the notations TSi and TSr when introducingexchange.

• N : Notation payload, carrying housekeeping information.

If any of the above payload is optional, then it will be shown in brackets. For example, [CERTREQ]indicates that optionally a certificate request payload can be included.

IKE SA INIT

Initiator Responder

HRD, SAi1, KEi, Ni −→←− HRD, SAr1, KEr, Nr, [CERTREQ]

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

The Responder chooses a cryptographic suite from the initiator proposed set and expresses thechoice in SAr1 payload. If the initiators guess on the Diffie-Hellman group is correct, the respondergenerates KEr in the same group to complete the Diffie-Hellman key agreement. Otherwise, theresponder will reject the proposal.

The pseudorandom function (PRF) is used for key derivation. After the initial exchange, eachparty can generate a shared secret value SKEY SEED such as


SKEY SEED = PRF (Ni||Nr, gir).

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

SK = KDF (SKEY SEED,Ni||Nr||SPIi||SPIr) = SKd||SKai||SKar||SKei||SKer||SKpi||SKpr,

where SKd is the key to be used to generate keys for CHILD SAs, SKai and SKar are authentication(a.k.a. integrity protection) keys, SKei and SKer are encryption keys, SKpi and SKpr are keys tobe used to generate entity authentication data in the authentication exchange, for the initiator andthe responder respectively. KDF is the key derivation function using the PRF as the basic blockto iterate for as many times as it is needed to derive enough bits required by the sum of length forall the keys.

While the keys are generated and the cryptographic algorithms are negotiated, it is ready toapply the protections to the rest of the exchanges. The notation SK{U, V, W, · · · , Y } indicatesthat the payloads U, V,W, · · · , Y are encrypted and integrity protected using the keys SKe andSKa 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 mutualauthenticated key establishment. The intention, according to [14], is to protect the identificationsand provide privacy. This model was referred as “post-specified model” in [13] to be analyzed. Theidentities are exchanged in the following authentication exchange.

IKE Auth

Initiator Responder

HRD, SK{IDi, [CERT ], [CERTREQ], [IDr],

AUTHi, SAi2, TSi, TSr} −→←− HRD, SK{IDr, [CERT ],

AUTHr, SAr2, TSi, TSr}

In this exchange, the initiator and the responder exchange their identifications and optionallycertificates. The value in the authentication payload AUTH is either a message authenticationcode or a digital signature. If certificates are exchanged, then authentication payload AUTH shallcarry a digital signature and the certificate used to verify authentication data AUTH.

The authentication payload from the initiator AUTHi is generated over the first message ofIKE SA INIT concatenated with Nr and the value PRF (SKpi, IDi). Similarly, the authenticationpayload from the responder AUTHr is generated over the second message of IKE SA INIT con-catenated with Ni and the value PRF (SKpr, IDr). Here Ni, IDi, Nr, IDr are only the values notthe corresponding payloads.

By exchanging the authentication payload, the initiator and the responder mutually authenti-cated each other and also bind the authentication with the key establishment. The nonce Ni andNr serve as implicit challenges to prevent replay attack.


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

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

The notations TSi and TSr are used differently from other notations. Two payloads TSi andTSr are sent in both directions in the exchange. In each direction, TSi and TSr specify the sourceaddress of the traffic forwarded from or the destination address of traffic forwarded to the initiatorand 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 bederived as

KEY MAT = KDF (SKd, Ni||Nr),

where Ni and Nr are nonce exchanged in IKE SA INIT and the KEY MAT will have the lengthat 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 establishedthrough CREATE CHILD SA as described in the follows.

CREATE CHILD SA

Initiator Responder

HRD, SK{[N ], SA, Ni, [KEi], [TSi, TSr]} −→←− HRD, SK{SA,Nr, [KEr], [TSi, TSr]}

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

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

KEY MAT = KDF (SKd, gir(new)||Ni||Nr).

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

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

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

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


notification, delete, and configuration payloads. The exchange is protected by the IKE SA andtherefore only occurs after the initial exchanges.

So far we have introduced all the IKEv2 exchanges. An IKE protocol includes all the subroutinesto 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 targetedon information protections. However, some of the security issues must be considered even thoughthey may not threat the confidentiality and integrity of the information communicated. At thispoint, we like to introduce a security issue on resource exhaustion of legal parties. This is an attackthrough 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 generateresponses. Sometimes, it is also called a denial of service (DoS) attack. The main idea to preventfrom such an attack is to let the responder first make sure that the initiator’s IP address is valid andreal before committing to “heavy duty” operations. In both IKEv1 and IKEv2, it uses a randombinary string called cookies for the responder to confirm the initiator’s IP address. In IKEv2, thecookies is carried in “Notify” payload. With cookies, the initial exchange of IKEv2 can be describedas follows.

IKE SA INIT with Cookies

Initiator Responder

HDR, SAi1,KEi, Ni −→←− HRD, N(COOKIE)

HRD, N(COOKIE), SAi1,KEi, Ni −→←− HDR, SAr1,KEr, Nr, [CERTREQ]

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

Cookie =< V ersionIDofSecret||Hash(Ni||IPi||SPIi|| < secret >,>

where IPi is the IP address of the initiator and < secret > is a randomly generated value by theresponder. The value < secret > will be updated from time to time. It does not need to be sharedwith any party but maintained in the responder. Therefore, it can be used with multiple partiesat a period of time. In this way, the responder will not need to maintain the state of cookies but


storing the value < secret >. Incorporating SPIi into the calculation ensures that if multiple IKESAs are being set up in parallel, then they will all get different cookies. It also includes Ni to thecalculation of cookies so that if an attacker can only observe the second message, it cannot forge thethird message 3. In other words, if an attacker observes the message 2, then it can get the cookies.However, it must select an Ni to form the third message. If Ni is different, then the responder willgenerate different cookies.

Notice that using cookies to prevent from DoS attack is based on an implicit assumption on thenetwork that the attacker who sends massive initiate requests must not be able to receive all theresponses to different forged IP addresses. This assumption probably is true in the IP networks. Italso tells that not all the security solutions can be based on mathematics functions or cryptographicmechanisms. When designing a network protocol, all possible attacks using the specific propertiesof the network must be considered, besides employing robust security schemes.

As we mentioned before, from security point of view, IKEv2 has not made significant changesfrom the original IKE as presented in [10]. Some research results appeared on their performancecomparisons. It seems that employing IKEv2 can improve its performance by reducing networktraffic 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 weexplained in the beginning of this section, at the source host, an IP header is added to the transportlayer packet before passing to the data link layer. When IPsec is applied, an IPsec header will beadded to the transport layer packet before IP header is added as illustrated in Figure 18. Here wedo not specify whether the IPsec header is an ESP header, an AH header or both. We use “IPheader 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 twodifferent 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 isapplied only when the IP packets travel through public Internet. In this case, the IPsec destinationmay be a security gateway for an enterprise network, instead of the real destination for the data.


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 noticethat the first IP header have the same pair of source and destination addresses as the IPsec packet,which are two Internet routers R1 and R2, as illustrated in Figure 19 where R1 and R2 are twoends of the tunnel. The second IP header will have IP addresses for host A and host B, which arethe source and destination addresses for the IP packet.

IPsec SA (R1 ! R2)R1 R2

IPsec SA (R2 ! R1)

Host B Host A

Figure 19: Tunnel mode

IP header R1R2 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 maynot implies an end-to-end protection to the data, since the destination IP host may not be the finaldestination 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, integrityprotection, and anti-replay attack for the IP datagrams. It is called “header” because the messageauthentication code, even though in [15], it is called Integrity Check Value (ICV), together withother 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. Itproposes certain challenge since the IPsec packets may arrive to the destination in a different order


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 differentorders.

In AH, it will be ideal if the data over which ICV is generated includes all the data fields in theIP 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 includeseverything to be authenticated. The IP header with a star denotes that it only covers the immutabledata 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 willnot 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 providemultiple protection combinations, including confidentiality only, integrity (plus data origin authen-tication) only, confidentiality and integrity (plus data origin authentication). It has anti-replayfeature, when integrity is provided. If it is in tunnel mode and confidentiality is provided, then itcan also provide traffic flow confidentiality (TFC). In the rest of this section, integrity implies bothintegrity and data origin authentication.

If both confidentiality and integrity are provided, then the encryption will be applied to datapayload first before applying message authentication code to the ciphertext together with otherdata fields. According to [7], this order will provide the most broad applicability to different modeof operations for the underlying encryption and mac algorithms. Figure 23 illustrates ESP in eithertransport mode or in tunnel mode. When it is in transport mode, the IP header in the dotedframe does not appear. For ESP, the authenticated data does not include IP header. The messageauthentication code, also called integrity check value (ICV) in [?] is attached at the end of thepacket 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


Next Header

Payload Length

Preserved


Sequence number

Integrity Check Value (ICV) = 000…0

IP header1*

IP header2

Data

TCP header

Next Header

Payload Length

Preserved


Sequence number


IP header1

IP header2

Data

TCP header

MACK

Figure 22: An IP packet protected with AH


IP header1


Sequence number Integrity protected


Initiation vector (IV)

IP header2

TCP header

Data

Pad length

Padding

Next header

Encrypted

Figure 23: An IP packet protected with ESP


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 thesame IP packet in transport mode (with the same source and destination), it is suggested to applyESP first so that the integrity will be applied to as much data as possible. The readers can, as anexercise, 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 inthis section.

The IPsec protocol suite has been launched to secure Internet and become an inseparable part ofInternet protocols. It serves as an excellent example of establish trusted computations. It is worthto notice that the Internet protocol treats the TCP packet as its payload. Therefore, the securityprotection is considered as in a hop-by-hop manner even though transport mode is end-to-endrelative to both IP addresses. In the next section, we will introduce another well launched securityprotocol 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 TransportLayer Security (TLS). TLS was first standardized by IETF between 1997 and 1999 based on SecureSocket Layer (SSL). SSL is a protocol developed by Netscape to provide security connectionsthrough Internet. Its earliest version can be traced back to 1994. SSL has gone through a numberof revisions before it was adopted by IETF and specified in IETF by RFC 2246 [17] in 1999. Pleasesee [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, whenSSL was designed, it is to make sure that a server the client connected to through Internet is indeedthe one the client wants to communicate. This is also the reason that in TLS, client authenticationthrough 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 clientprotocols. The record protocol is on the top of a transport protocol, for example, TCP. The TLSrecord protocol encapsulates four upper layer protocols, also called client protocols. The four TLSupper layer protocols are handshake protocol, change cipher spec protocol, alert protocol, andapplication data protocol. The record layer will take messages from the upper client to be trans-mitted, fragment to the manageable blocks, optionally compress, applies message authenticationand 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 andother client protocols.

TLS has been the most widely adopted protocol to protect application data and therefore alsogone through several revisions. In this lecture note, the introduction on TLS is based on the latestversion 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 suitenegotiation, mutual authentication, key establishment, and using the keys to protect application


Application Data

Record Layer

Handshake Change Alert cipher spec

TCP

Figure 24: TLS Protocol Stack

data. The full handshake consists of the following messages.

Handshake Protocol

Client Server

ClientHello −→ServerHello

Certificate∗ServerKeyExchange∗CertificateRequest∗

←− ServerHelloDone

Certificate∗ClientKeyExchange

CertificateV erify∗{ChangeCipherSpec}

Finished −→{ChangeCipherSpec}

←− Finished

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 issent with other handshake messages to improve performance. In the next few subsections, we willexplain what is carried in each of the messages and what cryptographic functions each of themexecutes.


3.2.2 Hellos and TLS Cipher Suites

The ClientHello and ServerHello are the two messages for the client and the server to negotiate acipher suite as well as a compression method. Each of the client and the server generates a randomnumber and exchange them in the hello messages.

The client hello message provides a list of supported cipher suites. A typical TLS cipher suiteconsists of four algorithms, key establishment, authentication, symmetric key encryption, and ahash function. For example, a cipher suite denoted as

TLS DHE RSA WITH AES 128 CBC SHA

implies that the key establishment will use ephemeral Diffie-Hellman key exchange method, theauthentication will use RSA digital signature, the symmetric key based encryption will use AESCBC mode with key size 128 bits, and hash function is SHA. For a given TLS cipher suite, thehash function will be used to form a keyed hash message authentication code, called HMAC. TheHMAC 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 thereis a match with the cipher suites the server supports. Otherwise, it will response with a failurealert. 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 mes-sages. With messages ClientKeyExchange and ServerKeyExchange, the client and the serverwill 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 itsparameters), and RSA (key transport).

For DHE, messages ClientKeyExchange and ServerKeyExchange carries the ephemeralDiffie-Hellman public values from the client and the server respectively. Then the client andthe server generate a pre-master secret value through an ephemeral Diffie-Hellman key exchange.Especially, ServerKeyExchange will carry cryptographic parameters for the Diffie-Hellman keyexchange.

For DH, it is always assume that the server’s public Diffie-Hellman value is included in theserver’s certificate and delivered in message Certificate. Therefore, ServerKeyExchange willnot be sent. If the client’s Diffie-Hellman public value is also certified, then it will be deliveredwith Certificate message and ClientKeyExchange message is sent but empty. Otherwise, theclient will generate a Diffie-Hellman public value using the parameters provided in the server’sCertificate and send it in ClientKeyExchange.

For RSA, the client will generate a pre-master secret value, encrypt it with the server’s RSApublic key, and send it in the ClientKeyExchange message. For RSA, ServerKeyExchange willnot be sent.

The following table summerizes which values are exchanged in the key exchange messages andhow the pre-master secret is generated in each of the key exchange algorithms. The operationsare conducted in the specified mathematics structures by each algorithm, which we omitted in thetable. The public key or public value are obtained from the Certificate if they are not sent throughkey exchange messages.


KeyExchange and Key Establishment Protocol

ServerKeyExchange ClientKeyExchange Pre-MasterSecret

DHE Ys = gs Yc = gc Z = gsc

DH n/a [Yc = gc] Z = gsc

RSA n/a E(Pks, Z) Z

The pre-master secret is used to derive a value called mater secret through a pseudo-randomfunction. The value master secret has a fixed length for any negotiated cipher suite. For a givencipher suite, the value master secret is expended to keying materials with required length by thecipher 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 aclient write key and a server write key. Similarly, for a MAC algorithm, it requires a client mac keyand a server mac key. For some algorithms, the initiation vectors (IVs) are also generated throughthe keying material so that it will not need to be transported. Figure 25 describes how the TLSkeys are derived.

Pre-master secret Client random

KDF

Master secret

KDF

Server random

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 asDHanon. We will not discuss it in this section but will wait to Chapter 4.


3.2.4 Certificate and Authentication

The server authentication can be conducted explicitly or implicitly, depending on the selected ciphersuite. 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 messageServerKeyExchange. In order to prevent replay attack, the random numbers exchanged in hellomessages are included in the message to be signed. If the server authentication is conductedexplicitly through digital signature, then the signature public key and its certificate is sent inCertificate.

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 Finished, theserver will prove that it owns the private key corresponding to the certified Diffie-Hellman publicvalue or certified RSA public key by confirming that it can correctly establish the key. If theserver is authenticated implicitly, then message Certificate will carry the certificate for either theDiffie-Hellman public value or the RSA public key.

As we mentioned before, the Client authentication has been optional due to the original inten-tion of SSL design. The server can optionally send CertificateRequest to the Client. Then theclient can conduct an explicit authentication by sending a digital signature in CertificateV erifymessage. The signature is generated over all the handshake messages, sent and received, startingat ClientHello. If the client conducts an explicit authentication by CertificateV erify, then acertificate for digital signature must be included in message Certificate.

3.2.5 Finished and Post-Verification

Notice that the message CertificateV erify can also serve as a post verification of the cipher suitenegotiation provided by the client. However, since client authentication is optional, this messagemay or may not be sent. The post-verification for the cipher suite negotiation is provided in messageFinished.

A finished message is always sent immediately after a change cipher spec message to conductkey confirmation, implicit authentication, and post verification of the cipher suite negotiation.The message Finished carries a message authentication code over all the handshake messagessent and received before this Finished message using the master secret. The computation of themessage authentication code for client and server includes different labels. Especially, the messageauthentication code by the server covers the Finished 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 datastring to fragments. For each fragment, a message authentication code is first generated using themac key. The mac is concatenated with the data. Then the data and mac will be encrypted by anencryption 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 generatesmessage 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 encryptionalgorithm is a block cipher with CBC mode or a stream cipher, such an order will provide thesecurity as defined in [7].


Kmac Mac

Data MAC

Enc Kenc

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 aserver. Its primary security goal is to make sure that the server a client application is connectingto is indeed the one it wants to connect. When the client authentication is not conducted, TLSprotocol as it is specified in [18] cannot be considered as a trusted communication as you will findin the exercise 1 of the following. However, TLS is often used to establish a protected channelfor user to enter password. The application data will not be exchanged unless the client entersa right password. Remember that the password is protected by the keys generated during thehandshake. If the handshake is hijacked, then the server will not be able to get a right passwordand the application data will not be exchanged. This is a good example to demonstrate that asecurity protocol must be used in its designed scenarios. Otherwise, it will not achieve its securitygoals. In Chapter 22 of [20], more pitfalls are elaborated in transplanting a security protocol to anapplication 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 ahop. In Figure 27, the path from node 1 to node n consists of n − 1 links. If data is transportedfrom 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 encryptedby node 1, only node n can decrypt it. For the communication path from node 1 to noden, this is called end-to-end encryption. We can define end-to-end integrity protection andauthenticity in the same way. We will call it an end-to-end protection when not specifyingencryption or integrity protection and authenticity.


Hop-by-hop

1 2 n3 … …

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 thedata is encrypted by node i−1 using Ki−1,i, then node i must decrypt it using key Ki−1,i andthen encrypt again using Ki,i+1. When the data is transported from node 1 to node n, it isencrypted at every link and processed, decrypted and encrypted again at each intermediatenode. This kind of encryption is called hop-by-hop encryption. In the same way, we candefine hop-by-hop integrity protection and authenticity. In general we will call it, encryptionor 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. Inthis section, we will discuss protection modes.

In this chapter so far, we have discussed the main schemes in establishing trusted commu-nications between two entities. When the keys are established and algorithms are agreed, thecommunications can be protected between these two entities. Each of the protocols we have in-troduced are for communications over a specific layer. For example, IPsec applies protections inIP layer, while TLS applies protections in transport layer. We will see that for a given path, theprotection mode is often determined by the communication protocol where the protections areapplied.

Furthermore, it may be the case that hop-by-hop and end-to-end protections co-exist. Forexample, when a client and a server establish a TLS session, the data is protected between theclient and the server. In IP layer, during the data is transported, it may go through several IProuters. Assume that both the client and the server are IP entities, that is, they have IP addressesand execute IP. For each link between two IP entities, it may be protected through IPsec. Figure 28describes such a situation.

For the TLS session, it has the property that if data is encrypted by the client, then it canonly be decrypted by the server. The routers in the middle, even though they are also involved inprocessing the IP packets, have no way to know the actual data since they are protected at a higherlayer. Similarly, if the client applies the integrity protection and authenticity, then the server canverify it. In this case, we would say the data is protected end-to-end between the client and theserver.

As we have discussed in IPsec, the two IP entities have pairwise (unidirectional) IPsec SAs andwill process IPsec packets transported from one entity to another based on SAs. As a result, thepackets will be processed at each router. For example, in Figure 28, for an IPsec packet passingthrough router R1 from the client to the server, it will use SAC1, security association from the client


Server Client

IPsec SA12, SA21

R1 R2

TLS session

IPsec SAC1, SA1C IPsec SA2S, SAS2

Figure 28: Protections by TLS and IPsec

to R1, to decrypt or/and verify and then use SA12, security association from R1 to R2 to encryptor/and authenticate before routing it to R2. At router R2, it will be processed again before routingto 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 modefor IPsec to make it end-to-end from the client to the server. Here we use transport mode IPsecbetween 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 multiplehops when considered in another layer. As we have illustrated in Figure 28, in TLS layer, the clientand the server are connected in one hop. However, the client and the server are connected at IPlayer with three hops. With existing security protocols and mechanisms in each layer, an obviousdilemma appears: whether we should depend on hop-by-hop protections or enforce end-to-endprotections.

In this section, we will discuss the different aspects of hop-by-hop and end-to-end protectionsas 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. Iftransport mode IPsec is used, hop-by-hop protections are established between different nodesto protect the transported information. The protections are determined by its two end nodeswithout 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 someone’s credit card number or a piece of public news, as long as it is transported in IP packetsfrom one given router to another, it will be protected in the same way. Actually, the routerswill not be able to distinguish the difference. On the other hand, protections in a transport


protocol are more efficient since an established trust communications between two nodes canbe 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 dif-ferent 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 thatwireless hop. Therefore, hop-by-hop protection may not be concatenated to cover the wholepath 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 communicationprotocols. They are designed to fit special features for the communication media and alsoprovide special countermeasures. They are often a part of service together with the transportmedia. For the media specific protections, they may also provide access control. We will lookinto these aspects in Chapter 4.

4. Service centric: The trust model for hop-by-hop is transport centric not application or usercentric. The objective of a hop-by-hop protection is to protect the transport in order toprovide a reliable service. It assumes that the nodes who process the security protected datais trustworthy in the sense that it is faithful to conduct such a service. The hop-by-hopprotections 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 applicationor user. The trust model for end-to-end protections is application centric or user centric. Theprotections are exclusive in the sense that only the two end nodes are trusted to access theinformation.

2. Media independent : By the nature, end-to-end protections are usually applied in a relativelyhigher 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 differentscenarios.

3. Exclusive trust : End-to-end protections are often needed dynamically. It demands efficientprotocol to establish such protections. Once the trusted communications are established, thepath 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 ofan add on, so that its performance and security can both considered together with the transportprotocols. However, the security policy and the security strength may not be able to differentiate fordifferent applications. On the other hand, for a given application, the protections will be designedbased on the trust model of the application and the assumptions on each parties. The protections


shall deal with the security threats proposed to the application and satisfy the requirements of theapplication.

Some of the security protocols provide tunnel mode, for example, IPsec, that is, the securitywill not be processed by the intermediate nodes such that the security protection is end-to-end eventhough the transport is executed in a hop-by-hop manner. It is often that end-to-end and hop-by-hop are combined in the same protocol layer. For example, it uses tunnel IPsec mode to provideend-to-end protections between two gateways of different domains and IPsec transport mode toprovide 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 modeland the protections designed specifically for the application, instead of hop-by-hop protectionsat 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 transportitself. Without a reliable transport protocol, any security protections applied to an application willnot work.

Therefore, each of the protection modes, hop-by-hop and end-to-end protections plays its ownrole 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 thatthe data fields where AUTHi and AUTHr are generated exclude value PRF (SKpi, IDi)and PRF (SKpr, IDr) respectively.

(b) Try to find an alternative way to bind the authentication with Diffie-Hellman key ex-change without using the values PRF (SKpi, IDi) and PRF (SKpr, IDr).

2. Security Analysis on TLS:

(a) Assume the key establishment algorithm is RSA, and the client authentication is notconducted, that is, message CertificateV erify is not sent. Try to identify an attackwhich hijacks the session by sending an attacker generated “pre-master secret” to theserver, where the messages Finished can carry along without being detected by eitherthe client and the server.

(b) Explain the attack identified in 1 will not gain access to the server, if the client mustenter password before any further application data will be exchanged.

(c) Try to explain why key establishment algorithms RSA and DH cannot provide perfectforward secrecy.

References

[1] P. Wang, Y. Kim, V. Kher, and T. Kwon, Strengthen Password-based Authentication ProtocolsAgainst Online Dictionary Attacks, ACNS 2005, Lecture Notes in Computer Science, Volume3531, Springer-Verlag, 2005.


[2] M. Bellare and P. Rogaway. Entity Authentication and Key Distribution. Advances inCryptology- 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 KeyDerivation Using the CBC, Cascade and HMAC Modes, Advances in Cryptology- Crypto 2004pp. 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 inComputer 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 Comments2406, 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 andKey Management Protocol (ISAKMP), IETF Request for Comments 2408, 1998.

[12] D. Piper. The Internet IP Security Domain of Interpretation for ISAKMP, IETF Request forComments 2407, 1998.

[13] R. Canetti and H. Krawczyk Security Analysis of IKE’s Signature-based Key-Exchange Pro-tocol, 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), IETFRequest for Comments 4346, 2006.

[19] E. Rescorla. SSL and TLS - Designing and Building Secure Systems, Addison-Wesley, 2001.


[20] C. Douligeris and D. N. Serpanos. Network Security - Current Status and Future Directions,IEEE Press by Wiley-Interscience, 2007.

Date post:	07-Jun-2018
Category:	Documents
Upload:	dangcong
View:	217 times
Download:	0 times

Chapter 3. Network Domain Security - University of...

Documents