What Is a Buffer Overflow?

So what is a buffer overflow? A buffer overflow is very simply an attempt to

stuff too much information into a space in a computer’s memory. For
instance, if I create a variable that is eight characters long and I try to stuff
nine bytes into it, what happens to the ninth byte? The answer is that it is
placed in memory immediately following the eighth byte. If I try to stuff a lot
of extra data into that variable, eventually I will run into some memory that is
important to the operation of the system. In the case of buffer overflows, the
part of memory that I am interested in is called the stack and in particular,
the return address of the function to be executed next.
The stack controls switching between programs and tells the computer what
code to execute when one part of a program (or function) has competed its
task. The stack also stores variables that are local to a function. When a
buffer overflow is exploited, the hacker places instructions in a local variable
that is then stored on the stack. The information placed in the local variable
is large enough to place an instruction on the stack and overwrite the return
address to point at this new instruction (see below Figure. These instructions
may cause a shell program to run (providing interactive access), or they may
cause another application to start, or they may change a configuration file
(such as inetd.conf) and allow the hacker to gain access via the new
configuration.

Why Do Buffer Overflows Exist?

Buffer overflows come up very often as the flaw in an application that copies
user data into another variable without checking the amount of data being
copied. More and more programs seem to suffer from this type of problem.
Yet the problem seems to be able to be fixed rather quickly (once it is
identified and brought to the vendor’s attention). If buffer overflows are so
easy to fix, why are they there in the first place? If the programmer checked
the size of the user data before placing it in the predefined variable, the
buffer overflow could be prevented.
Buffer overflows can be found by examining the source code for a program.
While this sounds pretty simple, it can be a long and arduous process. It is
much easier to fix the buffer overflows while the program is being written
than to go back and find them later.

DES ALGORITHM:

The algorithm for the Data Encryption Standard (DES) was developed by IBM
in the early 1970s. DES uses a 56-bit key. The key uses seven bits of eight 8-
bit bytes (the eighth bit of each byte is used for parity). DES is a block cipher
that operates on one 64-bit block of plaintext at a time (see Figure for a block
diagram of the algorithm). There are 16 rounds of encryption in DES with a
different sub-key used in each round. The key goes through its own algorithm
to derive the 16 sub-keys (see Figure). In the DES block diagram, you can see
several blocks where permutations occur. The standard defines a specific
rearrangement of bits for each permutation. The same is true
for the sub-key generation algorithm. There are specific bit rearrangements
for permuted
Choice 1 and 2. In below Figure, you can also find a call out of the function
“f.” Within the function, there is a block that says “S” boxes. The “S” boxes
are table lookups (also defined in the standard) that change a 6-bit input into
a 4-bit output.
In this case, the plaintext must be 64 bits in length and the key is 56 bits in length.
Looking at the left-hand side of the figure, we can see that the processing of the plaintext
proceeds in three phases. First, the 64-bit plaintext passes through an initial permutation
(IP) that rearranges the bits to produce the permuted input. This is followed by a phase
consisting of 16 rounds of the same function, which involves both permutation and
substitution functions. The output of the last (sixteenth) round consists of 64 bits that are
a function of the input plaintext and the key. The left and right halves of the output are
swapped to produce the preoutput. Finally, the preoutput is passed through a permutation
(IP-1) that is the inverse of the initial permutation function, to produce the 64-bit cipher
text. With the exception of the initial and final permutations, DES has the exact structure
of a Feistel cipher, as shown in
There are four modes of operation for DES:
Electronic Code Book: This is the basic block encryption where the text
and the key are combined to form the ciphertext. Identical input produces
identicaloutput in this mode.
Cipher Block Chaining In this mode, each block is encrypted as in
electronic code book but a third factor, derived from the previous input, is
added. In this case, identical input (plaintext) does not produce identical
output.
Cipher Feedback This mode uses previously generated ciphertext as input
to DES. The output is then combined with plaintext to produce new
ciphertext.
Output Feedback This mode is similar to cipher feedback but uses DES
output and does not chain ciphertext.
There are no known attacks against the DES algorithm. However, the 56-bit
key has become a weakness. The key provides a total of 255 potential keys
(less a few keys that are known to be weak and not used). With today’s
computer systems, this entire key space can be examined within a small
amount of time.
Triple DES
In 1992, research indicated that DES could be used multiple times to create a
stronger encryption.
Thus was born the concept of Triple DES (TDES). Figure below shows how
TDES works. You will note that the second operation is actually a decryption.
This is the key that makes TDES stronger than normal DES. TDES can be used
with either three keys or two keys. In the case of two keys, K1 and K3 are
equal and K2 is different. TDES is a relatively fast algorithm as it can still be
implemented in hardware. It does take three times the overall time as DES
since there are three operations occurring. TDES
should be used instead of DES for most applications.

Password Encryption
The standard Unix password encryption scheme is a variation of DES. While
the password encryption function is actually a one-way function (you cannot
retrieve the plaintext from the ciphertext), I will include a discussion of it here
to show how DES can be used in this type of application. Each user chooses a
password. The algorithm uses the first eight characters of the password. If
the password is longer than eight characters, it is truncated. If the password
is shorter than eight characters, it is padded. The password is transformed
into a 56-bit number by taking the first 7 bits of each character. The system
then chooses a 12-bit number based on the system time. This is called the
salt. The salt and the password are used as input into the password

encryption function (see Figure). 216 Network Security: A Beginner’s Guide

The salt is used to modify one of the permutation tables in the DES algorithm
(the E Permutation) in any of 4,096 different ways based on the number of
1’s in the 12 bits. The initial plaintext is 56 zero bits and the key is the 56 bits
derived from the password. The algorithm is run 25 times with the input for
each stage being the output of the previous stage. The final output is
translated into 11 characters and the salt is translated into 2 characters and
placed before the final output. The chief weakness in this system lies in the
password choice. Since most computer users will choose passwords made up
of lowercase letters, we have a total of 268 possible combinations. This is
significantly less than the 255 possible DES keys and thus it takes significantly
less time and computing power to brute-force passwords on a Unix system.

AES ALGORITHM:

Explanation.
The Advanced Encryption Standard (AES) specifies a FIPS-approved Cryptographic
algorithm that can be used to protect electronic data. The AES algorithm is a symmetric
block cipher that can encrypt (encipher) and decrypt (decipher) information. Encryption
converts data to an unintelligible form called cipher text; decrypting the cipher text
converts the data back into its original form, called plaintext. The AES algorithm is
capable of using cryptographic keys of 128, 192, and 256 bits to encrypt
and decrypt data in blocks of 128 bits.

1. It is not a festal structure. Recall the classical feistel Structure, Half of the data
block is used to modify the other data block, and then the halves are
swapped.AES does not use fiestel structure but processes the entire data block in
parallel during each round using substitutions and permutations.
2. The key that is provided as input is expanded into an array of forty four (32-bit
words,w[i].Four distinct words (128 bits) serve as a round key for each round.
3. Four different stages are used, one for permutation and three for substitutions.
Substitute bytes:
The following algorithm parameters, symbols, and functions are used throughout this
standard:

Four different stages are used, one of permutation and three of substitution:

o Substitute bytes: Uses an S-box to perform a byte-by-byte substitution of

the block
o Shift Rows: A simple permutation
o Mix Columns: A substitution that makes use of arithmetic over GF(28)
o AddRoundKey: A simple bitwise XOR of the current block with a portion
of the expanded key

AddRoundKey ()
Transformation in the Cipher and Inverse Cipher in which a Round Key is added to the
State using an XOR operation. The length of a Round Key equals the size of the State
(i.e., for Nb = 4, the Round Key length equals 128 bits/16 bytes).
MixColumns ()
Transformation in the Cipher that takes all of the columns of the State and mixes their
data (independently of one another) to Produce new columns.
.
ShiftRows () Transformation in the Cipher that processes the State by
cyclicallyShifting the last three rows of the State by different offsets.

SubBytes () Transformation in the Cipher that processes the State using a nonlinear
Byte substitution table (S-box) that operates on each of the State bytes independently.

SubWord() Function used in the Key Expansion routine that takes a four-byte
Input word and applies an S-box to each of the four bytes to produce an output word.
XOR Exclusive-OR operation.
⊕ Exclusive-OR operation.
⊗ Multiplication of two polynomials (each with degree < 4) modulo
X4 + 1.

4. The structure is quite simple. For both encryption and decryption, the cipher
begins with an AddRound key stage, followed by nine rounds that each includes
four stages,followed by tenth round of three stages .
Diffie-Hellman Key Exchange
Whitfield Diffie and Martin Hellman developed their public key encryption system in
1976. The Diffie-Hellman system was developed to solve the problem of key distribution
for private key encryption systems. The idea was to allow a secure method of agreeing on
a private key without the expense of sending the key through another method. Therefore,
they needed a secure way of deciding on a private key using the same method of
communication that they were trying to protect. Diffie-Hellman cannot be used to encrypt
or decrypt information.
The Diffie-Hellman algorithm depends for its effectiveness on the difficulty of
computing discrete logarithms. Briefly, we can define the discrete logarithm in the
following way. First, we define a primitive root of a prime number p as one whose
powers modulo p generate all the integers from 1 to p 1. That is, if a is a primitive root of
the prime number p, then the numbers

a mod p, a2 mod p,..., ap1 mod pare distinct and consist of the integers from 1 through p 1
in some permutation.

For any integer b and a primitive root a of prime number p, we can find a unique
exponent i such that b =ai (mod p) where 0 <=i <=(p 1).

The exponent i is referred to as the discrete logarithm of b for the base a, mod p. We
express this value as dloga,p (b).

For this scheme, there are two publicly known numbers: a prime number q and an integer
that is a primitive root of q. suppose the users A and B wish to exchange a key. User A
selects a random integer XA < q and computes YA = α XA
mod q. Similarly, user B
independently selects a random integer XA < q and computes YB = α XB
mod q. Each side
keeps the X value private and makes the Y value available publicly to the other side. User
A computes the key as K = (YB)XA mod q and user B computes the key as K = (YA)XB
mod q. These two calculations produce identical results:
K = (YB)XA mod q
XB
= (α mod q)XA mod
q
= (α XB XA
) mod q by the rules of modular arithmetic
XB XA
= (α mod q
XA XB
= (α ) mod q
XA
= (α mod q)
XA
= (α mod q)XB mod
q
= (YA)XB mod q

The result is that the two sides have exchanged a secret value. Furthermore, because XA
and XB are private, an adversary only has the following ingredients to work with: q, α ,
YA, and YB. Thus, the adversary is forced to take a discrete logarithm to determine the
key. For example, to determine the private key of user B, an adversary must computeXB =
dlogα , q (YB)

The adversary can then calculate the key K in the same manner as user B calculates
it.The security of the Diffie-Hellman key exchange lies in the fact that, while it is
relatively easy to calculate exponentials modulo a prime, it is very difficult to calculate
discrete logarithms. For large primes, the latter task is considered infeasible

Example:Here is an example. Key exchange is based on the use of the prime number q =
353 and a primitive root of 353, in this case α = 3. A and B select secret keys XA = 97
and XB = 233, respectively. Each computes its public key:

A computes YA = 397 mod 353 = 40.

B computes YB = 3233 mod 353 = 248.

After they exchange public keys, each can compute the common secret key:
 A computes K = (YB)XA mod 353 = 24897 mod 353 =160.
B computes K = (YA)XE mod 353 = 40233 mod 353 = 160.

We assume an attacker would have available the following information:

q = 353; α = 3; YA = 40; YB = 248

In this simple example, it would be possible by brute force to determine the secret key
160. In particular, an attacker E can determine the common key by discovering a solution
to the equation 3a mod 353 = 40 or the equation 3b mod 353 = 248. The brute-force
approach is to calculate powers of 3 modulo 353, stopping when the result equals either
40 or 248. The desired answer is reached with the exponent value of 97, which provides
397 mod 353 = 40.

Man-in-the Middle attack:

Man-in-the-Middle Attack

The protocol depicted in Below Figure is insecure against a man-in-the-middle attack.

Suppose Alice and Bob wish to exchange keys, and Darth is the adversary. The attack
proceeds as follows:

1. Darth prepares for the attack by generating two random private keys XD1 and XD2
and then computing the corresponding public keys YD1 and YD2.
2. Alice transmits YA to Bob.
3. Darth intercepts YA and transmits YD1 to Bob. Darth also calculates K2 = (YA)XD2
mod q.
4. Bob receives YD1 and calculates K1 = (YD1)XE mod q.
5. Bob transmits XA to Alice.
6. Darth intercepts XA and transmits YD2 to Alice. Darth calculates K1 = (YB)XD1 mod
q.
7. Alice receives YD2 and calculates K2 = (YD2)XA mod q.
At this point, Bob and Alice think that they share a secret key, but instead Bob and Darth
share secret key K1 and Alice and Darth share secret key K2. All future communication
between Bob and Alice is compromised in the following way:

1. Alice sends an encrypted message M: E(K2, M).

2. Darth intercepts the encrypted message and decrypts it, to recover M.
3. Darth sends Bob E(K1, M) or E(K1, M'), where M' is any message. In the first
case, Darth simply wants to eavesdrop on the communication without altering it.
In the second case, Darth wants to modify the message going to Bob.

The key exchange protocol is vulnerable to such an attack because it does not
authenticate the participants. This vulnerability can be overcome with the use of digital
signatures and public-key certificates; these topics are explored

RSA
In 1978, Ron Rivest, Adi Shamir, and Len Adleman released the Rivest-
Shamir-Adleman (RSA) public key algorithm. Unlike the Diffie-Hellman
algorithm, RSA can be used for encryption and decryption. Also unlike Diffie-
Hellman, the security of RSA is based on the difficultly of factoring large
numbers. This is considered a hard problem when the numbers are very large
(512 bits or larger).
The basic algorithm for confidentiality is very simple:
Ciphertext = (Plaintext) e mod n
Plaintext = (Ciphertext) d mod n
Private Key = {d, n}
Public Key = {e, n}
The difficulty in calculating d given e and n provides the security. It is
assumed that the owner of the key pair keeps the private key secret and that
the public key is published. Therefore, if information is encrypted with the
public key, only the owner can decrypt it. It should also be noted that the
algorithm can be reversed to provide authentication of the sender. In this
case, the algorithm would be….
Ciphertext = (Plaintext)d mod n
Plaintext = (Ciphertext)e mod n
Private Key = {d, n}
Public Key = {e, n}
For authentication, the owner encrypts the information with the private key.
Only the owner could do this since the private key is kept secret. Anyone can
now decrypt the information and verify that it could have only come from the
owner of the key pair.

Generating RSA Keys

Care must be taken in the generation of RSA keys. To generate an RSA key
pair, followthese steps:
1. Choose two prime numbers p and q and keep them secret.
2. Calculate n = pq.
3. Calculate quantity (n) = (p – 1)(q – 1).
4. Select e such that e is relatively prime to quantity (n).
5. Determine d such that (d)(e) = 1 mod (n) and that d < (n).
The number n should be on the order of a 200-digit number or larger.
Therefore, both
p and q should be at least 100-digit numbers. Keys for real-world use should
be at least
1,024 bits. For sensitive information, 2,048 bits and larger keys should be
considered.
222 Network Security: A Beginner’s Guide
Chapter 12: Encryption 223
Worked RSA Example
To show how RSA generates keys, we will do an example calculation. Keep in
mind that I chose numbers that can be relatively easily verified for this
example. Real uses of RSA
will use much larger numbers.
1. First I choose two prime numbers. In this case, I choose p = 11 and q = 13.
2. Now I calculate n = pq. That means n = (11)(13) = 143.
3. I must now calculate (n) = (p – 1)(q – 1) = (11 – 1)(13 – 1) = (10)(12) =
120.
4. I select a number e so that e is relatively prime to  (n) = 120. For this
number, I
choose e = 7.
5. I must determine d such that (d)(e) = 1 mod  (n). Therefore, (d)(7) = 1
mod 120
and d must also be less than 120. We find that d = 103. (103 times 7 equals
721.
721 divided by 120 is 6 with 1 remaining.)
6. The private key is {103, 143}.
7. The public key is {7, 143}.
To perform an actual encryption and decryption we can use the original
formulas:
Ciphertext = (Plaintext)e mod n
Plaintext = (Ciphertext)d mod n
Let’s assume that I wish to send the message “9.” I use the encryption
formula and
end up with:
Cipher text = (9)7 mod 143 = 48
When the encrypted information is received, it is put through the decryption
algorithm:
Plaintext = (48)103 mod 143 = 9

Q) Write bout the key distribution?

Ans) For symmetric encryption to work, the two parties to an exchange must share the
same key, and that key must be protected from access by others. For two parties A and B,
key distribution can be achieved in a number of ways, as follows:

1. A can select a key and physically deliver it to B.

2. A third party can select the key and physically deliver it to A and B.
3. If A and B have previously and recently used a key, one party can transmit the
new key to the other, encrypted using the old key.
4. If A and B each has an encrypted connection to a third party C, C can deliver a
key on the encrypted links to A and B.

Options 1 and 2 call for manual delivery of a key. For link encryption, this is a reasonable
requirement, because each link encryption device is going to be exchanging data only
with its partner on the other end of the link. However, for end-to-end encryption, manual
delivery is awkward. In a distributed system, any given host or terminal may need to
engage in exchanges with many other hosts and terminals over time. Thus, each device
needs a number of keys supplied dynamically. The problem is especially difficult in a
wide area distributed system.

Returning to our list, option 3 is a possibility for either link encryption or end-to-end
encryption, but if an attacker ever succeeds in gaining access to one key, then all
subsequent keys will be revealed. Furthermore, the initial distribution of potentially
millions of keys must still be made. For end-to-end encryption; some variation on option
4 has been widely adopted. In this scheme, a key distribution center is responsible for
distributing keys to pairs of users (hosts, processes, applications) as needed. Each user
must share a unique key with the key distribution center for purposes of key distribution.

A Key Distribution Scenario

Let us assume that user A wishes to establish a logical connection with B and requires a
one-time session key to protect the data transmitted over the connection. A has a master
key, Ka, known only to itself and the KDC; similarly, B shares the master key Kb with the
KDC. The following steps occur:

1) A issues a request to the KDC for a session key to protect a logical connection to B.
The message includes the identity of A and B and a unique identifier, N1, for this
transaction.
2) The KDC responds with a message encrypted using Ka Thus, A is the only one who
can successfully read the message, and A knows that it originated at the KDC. The
message includes two items intended for A:

• The one-time session key, Ks, to be used for the session

• The original request message, including the nonce, to enable A to match this
response with the appropriate request

Thus, A can verify that its original request was not altered before reception by the KDC
and, because of the nonce, that this is not a replay of some previous request.
In addition, the message includes two items intended for B:

• The one-time session key, Ks to be used for the session

• An identifier of A (e.g., its network address), IDA

3) A stores the session key for use in the upcoming session and forwards to B the
information that originated at the KDC for B, namely, E(Kb, [Ks || IDA]). Because this
information is encrypted with Kb, it is protected from eavesdropping. B now knows the
session key (Ks), knows that the other party is A (from IDA), and knows that the
information originated at the KDC (because it is encrypted using Kb).

4) Using the newly minted session key for encryption, B sends a nonce, N2, to A.
Also using Ks, A responds with f (N2), where f is a function that performs some
transformation on N2 (e.g., adding one).

Hierarchical Key Control

A hierarchical scheme minimizes the effort involved in master key distribution, because
most master keys are those shared by a local KDC with its local entities. Furthermore,
such a scheme limits the damage of a faulty or subverted KDC to its local area only.

Session Key Lifetime

For connection-oriented protocols, one obvious choice is to use the same session key for
the length of time that the connection is open, using a new session key for each new
session. For a connectionless protocol, such as a transaction-oriented protocol, there is no
explicit connection initiation or termination. Thus, it is not obvious how often one needs
to change the session key. The most secure approach is to use a new session key for each
exchange. However, zthis negates one of the principal benefits of connectionless
protocols, which is minimum overhead and delays for each transaction. A better strategy
is to use a given session key for a certain fixed period only or for a certain number of
transactions.
Automatic key distribution:

The scheme is useful for providing end-to-end encryption at a network or transport level
in a way that is transparent to the end users. The approach assumes that communication
makes use of a connection-oriented end-to-end protocol, such as TCP. (SSM), which may
consists of functionality at one protocol layer that performs end-to-end encryption and
obtains session keys on behalf of its host or terminal.

The steps involved in establishing a connection are shown in the figure. When one host
wishes to set up a connection to another host, it transmits a connection-request packet
(step 1). The SSM saves that packet and applies to the KDC for permission to establish
the connection

(step 2). The communication between the SSM and the KDC is encrypted using a master
key shared only by this SSM and the KDC. If the KDC approves the connection request,
it generates the session key and delivers it to the two appropriate SSMs, using a unique
permanent key for each SSM

(step 3). The requesting SSM can now release the connection request packet, and a
connection is set up between the two end systems
(step 4). All user data exchanged between the two end systems are encrypted by their
respective SSMs using the one-time session key.

The automated key distribution approach provides the flexibility and dynamic
characteristics needed to allow a number of terminal users to access a number of hosts
and for the hosts to exchange data with each other.

Decentralized key Distribution:

A decentralized approach requires that each end system be able to communicate in a

secure manner with all potential partner end systems for purposes of session key
distribution. Thus, there may need to be as many as [n(n 1)]/2 master keys for a
configuration with n end systems.

A session key may be established with the following sequence of steps

1. A issues a request to B for a session key and includes a nonce, N1

2. B responds with a message that is encrypted using the shared master key. The
response includes the session key selected by B, an identifier of B, the value f(N1),
and another nonce, N2.

3. Using the new session key, A returns f(N2) to B

1. Explain the various steps involved in the HMAC ALGORITHM?
HMAC
HMAC has been issued as RFC 2104, has been chosen as the mandatory-to-implement
MAC far IP Security, and is used in other Internet protocols, such as Transport Layer
Security (TLS, soon to replace Secure Sockets Layer) and Secure Electronic Transaction
(SET).
• To use, without modifications, available hash functions. In particular, hash
functions that perform well in software, and for which code is freely and widely
available
• To allow for easy replace ability of the embedded hash function in case faster or
mare secure hash functions are found are required.
• To preserve the original performance of the hash function without incurring a
significant degradation .To use and handle keys in a simple way.
• To have a well-understood cryptographic analysis of the strength of the.
authentication mechanism based on reasonable assumptions on the embedded
hash function
The first two objectives are important to the acceptability of HMAC.
HMAC treats the hash function as a "black box." This has two benefits. First, an existing
implementation of a hash function can be used as a module in implementing HMAC. In
this way, the bulk of the HMAC code is prepackaged and ready to use without
modification. Second, if it is ever desired to replace a given hash function in an HMAC
implementation, all that is required is to remove the existing hash function module and
drop in the new module. This could be done if a faster hash function were desired. Mare
important, if the security of the embedded hash function were compromised, the security

of HMAC could be retained simply by replacing the embedded hash function with a more
secure one.
The last design objective in the preceding list is, in fact, the main advantage of HMAC
over other proposed hash-based schemes. HMAC can be proven secure provided that the
embedded hash function has some reasonable cryptographic strength. We return to this
point later in this section, but first we examine the structure of HMAC.

HMAC Algorithm
Define the following terms:
H= embedded hash function (e.g., SHA-1)
M= message input to HMAC (including the padding specified in the
Embedded hash function)
Yi= i th block of M, 0< i<(L - 1)
L= number of blocks in M
b= number of bits in a block
n= length of hash code produced by embedded hash function
K= secret key; if key length is greater than b, the key is input to the hash function to
produce an n-bit key; recommended 1ength is 2::n
K+ = K padded with zeros on the left so that the result is b bits in length
ipad = 00110110 (36 in hexadecimal) repeated biS times
opad = 01011100 (SC in hexadecimal) repeated biS times
Then HMAC can be expressed as follows:
HMAC K(M) = H[(K+ XOR opad) Il H[(K+ XOR ipad) Il M]]
In words,
1. Append zeros to the left end of K to create a b-bit string K+ (e.g., if K is of length 160
bits and b = 512, then K will be appended with 44 zero bytes 0x00).
2. XOR (bitwise exclusive-OR) K+ with ipad to produce the b-bit block Si
3. Append M to Si'
4. Apply H to the stream generated in step 3.

5. XOR K+ with opad to produce the b-bit block So

6. Append the hash result from step 4 to So
7. Apply H to the stream generated in step 6 and output the result.
Note that the XOR with ipad results in flipping one-half of the bits of K. Similarly, the
XOR with opad results in flipping one-half of the bits of K, but a different set of bits. In
effect, by passing Si and So through the hash algorithm, we have pseudo randomly
generated two keys from K. HMAC should execute in approximately the same time as the
embedded hash function for long messages. HMAC adds three executions of the basic
hash function (for Si So, and the block produced from the inner hash).

Write about message authentication?

Authentication Requirements:
1. Disclosure: once the message is send, contents of message should not see by any
one, the appropriate cryptographic key must be used.
2. Traffic analysis: In a connection oriented application, the frequency and duration
of connections could be determined .In a connection-oriented or connection less
environment, the number and length of messages and traffic generated between
parties could be determined.
3. Content Modification: If any modifications of content messages, including
insertion, deletion, transposition.
4. Sequence Modification: The sequence of messages between parties has been
modified, including insertion, deletion, and reordering.
5. Source repudation: Denial of transmission of message by source.
6. Destination Repudation: Denial of receipt of message by destination.

Authentication Functions:
There are two basic types for authentication of messages.
1. The low level authentication.
2. The higher level authentication.
1. The low level authentication: In lower –level authentication, some sort of function is
used to authenticate the message.
2. The higher level authentication: Protocol is used and that protocol enables a receiver
to check the authentication of message.
There are three types of functions that may be used to produce the authentication:
1. Message Encryption
2. Message authentication Code
3. Hash function.

Message authentication with message encryption:

Symmetric Encryption: Consider the below figure for Symmetric encryption message
M transmitted from source A to destination B which is encrypted using a secrete key K,
again it is shared by A and B. The two Parties should have secret key. If one of them does
not know, than they cannot recover the plain text of the message.

D
M E M

Symmetric encryption: confidentiality and

authentication

A MAC, is also known as check sum, is generated by a function C of the MAC=CK (M)
Form where M is a variable length message, K is a secret key shared only by sender and
receiver, and CK (M) is the fixed length authenticator. The MAC is appended to the
message at the source at a time when the message is assumed or known to be correct.

Public key encryption: Public key encryption provides confidentiality but not
authentication.
From the below figure shows the confidentiality in message encryption.
 D
M E M

Public key encryption: confidentiality

-source A uses the public key PUb of the destination B to encrypt Message M.Because
only B has the corresponding Private key PRb ,only B can Decrypt the Message.
- This method provides no authentication because any opponent could also use B’s public
key to encrypt a message, claiming to be A.
From below figure shows the authentication:

D
M E M

Public encryption: authentication

-A uses its Private Key to encrypt the message, and B uses A’s public key to decrypt.
-It only authentication, the message must have come from A because A is the only party

that possesses PRa.

-it is also provides digital signature. Only A could have constructed the cipher text

because only A possesses PRa. Not even B,the recipient could have constructed the cipher
text.
-To provide both confidentiality and authentication, A can encrypt M First using its
private key,which provides the digital signature and then using B’s public key,which
provides confidentiality.
-It provides confidentiality because of PUb.

-it provides authentication and signature because of PRa.

-A uses its Private Key to encrypt the message, and B uses A’s public key to decrypt.
-It only authentication, the message must have come from A because A is the only party

that possesses PRa..

E
M E D D M

Public encryption

Authentication with MAC (Message Authentication code).

One authentication technique involves the use of a secret key to generate a small block
of data, known as a message authentication code, that is appended to the message. This
technique assumes that two communicating parties, say A and B, Share a
common"secretkey KAB then A has a message to send to B, it 'calculates the message
authentication. Code asa.fuiiCt1Oll'of the message and the key: MACM = F(KAB,,M). The
message plus code are transmitted to the intended recipient. The recipient performs the
same ca1culation on the received message, using the same seq~key, to generate a new
message authentication code.

MAC=CK (M)
Where M=Message or Plain Text
K=Secret key by sender and receiver.
CK (M) =Fixed length Authenticator.
Requirements for MAC;
1. The receiver is assured that the message has not been altered. If an attacker alters the
message, but does not alter the code, then receiver calculation code will defer from the
receiver code.
2. The receiver is assured that the message is from the alleged sender. Because no one
else knows the secret key, no one e1se could prepare a message with a proper code.

4. If the message includes a sequence number (such as is used with X. 25, HDLC,
and TCP), then the receiver can be assured of the proper sequence number.

A MAC function is similar to encryption. One difference is that the MAC algorithm need
not be reversible, as it must for decryption. In general, the MAC function is a many-to-
one function. The domain of the function consists of messages of some arbitrary length,
whereas the range consists of all possible MACs and all possible keys. If an n-bit MAC is
used, then there are 2n possible MACs, whereas there are N possible messages with N >>
2n.

Example: suppose that we are using 100-bit messages and a 10-bit MAC. Then, there
are a total of 2100 different messages but only 210 different MACs. So, on average, each
MAC value is generated by a total of 2100/210 = 290 different messages. If a 5-bit key is
used, then there are 25 = 32 different mappings from the set of messages to the set of
MAC values.

Q) Explain what kerbrose is and give its requirements?

Assume an open distributed environment in which users at workstations wish to access

services on servers distributed throughout the network. We would like for servers to be
able to restrict access to authorized users and to be able to authenticate requests for
service. In this environment, a workstation cannot be trusted to identify its users correctly
to network services. In particular, the following three threats exist:

• user may gain access to a particular workstation and pretend to be another user
operating from that workstation.
• A user may alter the network address of a workstation so that the requests sent
from the altered workstation appear to come from the impersonated workstation.
 • A user may eavesdrop on exchanges and use a replay attack to gain entrance to a
server or to disrupt operations.

In any of these cases, an unauthorized user may be able to gain access to services and
data that he or she is not authorized to access.

Requirements:

• Secure: A network eavesdropper should not be able to obtain the necessary

information to impersonate a user. More generally, Kerberos should be strong
enough that a potential opponent does not find it to be the weak link.
• Reliable: For all services that rely on Kerberos for access control, lack of
availability of the Kerberos service means lack of availability of the supported
services. Hence, Kerberos should be highly reliable and should employ distributed
server architecture, with one system able to back up another.
• Transparent: Ideally, the user should not be aware that authentication is taking
place, beyond the requirement to enter a password.
• Scalable: The system should be capable of supporting large numbers of clients
and servers. This suggests a modular, distributed architecture

To support these requirements, the overall scheme of Kerberos is that of a trusted third-
party authentication service that uses a protocol based on that proposed by Needham and
Schroeder, which was discussed later. It is trusted in the sense that clients and servers
trust Kerberos to mediate their mutual authentication. Assuming the Kerberos protocol is
well designed, and then the authentication service is secure if the Kerberos server itself is
secure.

Kerberos Version 4

Version 4 of Kerberos makes use of DES, in a rather elaborate protocol, to provide the
authentication service. Viewing the protocol as a whole, it is difficult to see the need for
the many elements contained therein.
A Simple Authentication Dialogue

In an unprotected network environment, any client can apply to any server for service.
The obvious security risk is that of impersonation. An opponent can pretend to be another
client and obtain unauthorized privileges on server machines. To counter this threat,
servers must be able to confirm the identities of clients who request service. Each server
can be required to undertake this task for each client/server interaction, but in an open
environment, this places a substantial burden on each server.

IDC||PC||IDV
(1) C AS:
Ticket
(2) AS C:
IDC||Ticket
(3) C V:
Ticket = E(Kv, [IDC||ADC||IDV])

where

C = client
AS = authentication server
V =server
IDC = identifier of user on C
IDV = identifier of V
PC = password of user on C
ADC = network address of C
Kv = secret encryption key shared by AS and V

In this scenario, the user logs on to a workstation and requests access to server V. The
client module C in the user's workstation requests the user's password and then sends a
message to the AS that includes the user's ID, the server's ID, and the user's password.
The AS checks its database to see if the user has supplied the proper password for this
user ID and whether this user is permitted access to server V. If both tests are passed, the
AS accepts the user as authentic and must now convince the server that this user is
authentic. To do so, the AS creates a ticket that contains the user's ID and network
address and the server's ID. This ticket is encrypted using the secret key shared by the AS
and this server. This ticket is then sent back to C. Because the ticket is encrypted, it
cannot be altered by C or by an opponent.

With this ticket, C can now apply to V for service. C sends a message to V containing C's
ID and the ticket. V decrypts the ticket and verifies that the user ID in the ticket is the
same as the unencrypted user ID in the message. If these two match, the server considers
the user authenticated and grants the requested service.

A More Secure Authentication Dialogue

Two in particular stand out. First, we would like to minimize the number of times that a
user has to enter a password. Suppose each ticket can be used only once. If user C logs on
to a workstation in the morning and wishes to check his or her mail at a mail server, C
must supply a password to get a ticket for the mail server. If C wishes to check the mail
several times during the day, each attempt requires reentering the password. We can
improve matters by saying that tickets are reusable.

However, under this scheme it remains the case that a user would need a new ticket for
every different service. If a user wished to access a print server, a mail server, a file
server, and so on, the first instance of each access would require a new ticket and hence
require the user to enter the password.

The second problem is that the earlier scenario involved a plaintext transmission of the
password [message (1)]. An eavesdropper could capture the password and use any
service accessible to the victim.

To solve these additional problems, we introduce a scheme for avoiding plaintext

passwords and a new server, known as the ticket-granting server (TGS). The new but still
hypothetical scenario is as follows:
Once per user logon session:
IDC||IDtgs
(1) C AS:
E(Kc, Tickettgs)
(2) AS C:
Once per type of service:
IDC||IDV||Tickettgs
(3) C TGS:
Ticketv
(4) TGS C:
Once per service session:
IDC||Ticketv
(5) C V:
Tickettgs = E(Ktgs, [IDC||ADC||IDtgs||TS1||Lifetime1])
Ticketv = E(Kv, [IDC||ADC||IDv||TS2||Lifetime2])

The new service, TGS, issues tickets to users who have been authenticated to AS.

1)The client requests a ticket-granting ticket on behalf of the user by sending its user's ID
and password to the AS, together with the TGS ID, indicating a request to use the TGS
service.

2) The AS responds with a ticket that is encrypted with a key that is derived from the
user's password. When this response arrives at the client, the client prompts the user for
his or her password, generates the key, and attempts to decrypt the incoming message. If
the correct password is supplied, the ticket is successfully recovered.

Now that the client has a ticket-granting ticket, access to any server can be obtained with
steps 3 and 4:

3) The client requests a service-granting ticket on behalf of the user. For this purpose, the
client transmits a message to the TGS containing the user's ID, the ID of the desired
service, and the ticket-granting ticket.
4) The TGS decrypts the incoming ticket and verifies the success of the decryption by the
presence of its ID. It checks to make sure that the lifetime has not expired. Then it
compares the user ID and network address with the incoming information to authenticate
the user. If the user is permitted access to the server V, the TGS issues a ticket to grant
access to the requested service

Finally, with a particular service-granting ticket, the client can gain access to the
corresponding service with step 5:

The client requests access to a service on behalf of the user. For this purpose, the client
transmits a message to the server containing the user's ID and the service-granting ticket.
The server authenticates by using the contents of the ticket.

Q).Difference between the Version 4 and version 5:

ANS) Version 5 is intended to address the limitations of version 4 in two areas:

environmental shortcomings and technical deficiencies

Kerberos Version 4 was developed for use within the Project Athena environment and,
accordingly, did not fully address the need to be of general purpose.

1. Encryption system dependence: Version 4 requires the use of DES. Export

restriction on DES as well as doubts about the strength of DES were thus of
concern. In version 5, cipher text is tagged with an encryption type identifier so
that any encryption technique may be used.
2. Internet protocol dependence: Version 4 requires the use of Internet Protocol (IP)
addresses. Version 5 network addresses are tagged with type and length, allowing
any network addresses type to be used.
3. Message byte ordering: In version 4, the sender of a message employs a byte
ordering of its own choosing and tags the message to indicate least significant
byte in lowest address or most significant byte in lowest address. In version 5, all
message structures are defined using Abstract Syntax Notation One (ASN.1) and
Basic Encoding Rules (BER), which provide an unambiguous byte ordering.
4. Ticket lifetime: Lifetime values in version 4 are encoded in an 8-bit quantity in
units of five minutes. Thus, the maximum lifetime that can be expressed is 28 x 5
= 1280 minutes, or a little over 21 hours. This may be inadequate for some
applications (e.g., a long-running simulation that requires valid Kerberos
credentials throughout execution). In version 5, tickets include an explicit start
time and end time, allowing tickets with arbitrary lifetimes.
5. Authentication forwarding: Version 4 does not allow credentials issued to one
client to be forwarded to some other host and used by some other client. For
example, a client issues a request to a print server that then accesses the client's
file from a file server, using the client's credentials for access. Version 5 provides
this capability.
6. Interrealm authentication: In version 4, interoperability among N realms requires
on the order of N2 Kerberos-to-Kerberos relationships, as described earlier.
Version 5 supports a method that requires fewer relationships, as described.

Apart from these environmental limitations, there are technical deficiencies in the
version 4 protocol itself. Most of these deficiencies, and version 5 attempts to address
these shortly.

Version 5:

7. Double encryption: Note in [messages (2) and (4)] that tickets provided to clients
are encrypted twice, once with the secret key of the target server and then again
with a secret key known to the client.
8. PCBC encryption: Encryption in version 4 makes use of a nonstandard mode of
DES known as propagating cipher block chaining (PCBC). Version 5 provides
explicit integrity mechanisms, allowing the standard CBC mode to be used for
encryption. In particular, a checksum or hash code is attached to the message
prior to encryption using CBC.
 9. Session keys: Each ticket includes a session key that is used by the client to
encrypt the authenticator sent to the service associated with that ticket. In
addition, the session key may subsequently be used by the client and the server to
protect messages passed during that session. However, because the same ticket
may be used repeatedly to gain service from a particular server, there is the risk
that an opponent will replay messages from an old session to the client or the
server. In version 5, it is possible for a client and server to negotiate a subsession
key, which is to be used only for that one connection. A new access by the client
would result in the use of a new subsession key.
10. Password attacks: Both versions are vulnerable to a password attack. The message
from the AS to the client includes material encrypted with a key based on the
client's password. An opponent can capture this message and attempt to decrypt it
by trying various passwords. If the result of a test decryption is of the proper
form, then the opponent has discovered the client's password and may
subsequently use it to gain authentication credentials from Kerberos. This is the
same type of password attack described in, with the same kinds of
countermeasures being applicable.

The Version 5 Authentication Dialogue

Options||IDc||Realmc||IDtgs||Times||Nonce1
1) C AS
Realmc||IDC||Tickettgs||E(Kc, [Kc,tgs||Times||Nonce1||Realmtgs||IDtgs])
(2) AS C
Tickettgs = E(Ktgs, [Flags||Kc,tgs||Realmc||IDc||ADc||Times])
(a) Authentication Service Exchange to obtain ticket-granting ticket
Options||IDv||Times||||Nonce2||Tickettgs||Authenticatorc
(3) C TGS
Realmc||IDc||Ticketv||E(Kc,tgs, [Kc,v||Times||Nonce2||Realmv||IDv])
(4) TGS C
Tickettgs = E(Ktgs, [Flags||KC,tgs||Realmc||IDC||ADC||Times])
Ticketv = E(Kv, [Flags||Kc,v||Realmc||IDC||ADc||Times])
 Authenticatorc = E(Kc,tgs, [IDC||Realmc||TS1])
(b) Ticket-Granting Service Exchange to obtain service-granting ticket
Options||Ticketv||Authenticatorc
(5) C V
EKc,v[TS2||Subkey||Seq#]
(6) V C
Ticketv = E(Kv, [Flags||Kc,v||Realmc||IDC||ADC||Times])

Authenticatorc = E(Kc,v,[IDC||Realmc||TS2||Subkey||Seq#])
(c) Client/Server Authentication Exchange to obtain service

First, consider the authentication service exchange. Message (1) is a client request for a
ticket-granting ticket. As before, it includes the ID of the user and the TGS. The
following new elements are added:

• Realm: Indicates realm of user

• Options: Used to request that certain flags be set in the returned ticket

• Times: Used by the client to request the following time settings in the ticket:

from: the desired start time for the requested ticket

till: the requested expiration time for the requested ticket

rtime: requested renew-till time

The authenticator includes several new fields as follows:

 • Subkey: The client's choice for an encryption key to be used to protect this
specific application session. If this field is omitted, the session key from the ticket
(Kc,v) is used.
• Sequence number: An optional field that specifies the starting sequence number
to be used by the server for messages sent to the client during this session.
Messages may be sequence numbered to detect replays.

V unit
1) When tunnel mode is used, a new outer IP header is constructed, For both IPV4 and
IPV6, indicate the relationship of each outer IP header field and each extension header in
the outer packet to the corresponding field or extension header of the inner IP packet.
That is, indicate which outer values are derived from inner values and which are
constructed independently of the inner values?
Ans:
These transition design efforts resulted in a basic Transition
Mechanisms specification for IPv6 hosts and routers [4]
that specifies
the use of a Dual IP layer providing complete support for both IPv4 and
IPv6 in hosts and routers, and IPv6-over-IPv4 tunneling, encapsulating
IPv6 packets within IPv4 headers to carry them over IPv4 routing
infrastructures. These concepts are heavily relied on for transition from
the traditional IPv4-based Internet as we know it today, to an IPv6-
based Internet. It is expected that IPv4 and IPv6 will coexist for many
years during this
IPV6 EXTENSION HEADERS
This section reviews the headers used by the IPv6 protocol.
The Concept
IPv6 is using two distinct types of headers: Main/Regular IPv6 Header and IPv6
Extension Headers. The main IPv6 header is equivalent to the basic IPv4 one despite
some field differences that are the result of lessons learned from operating IPv4. Figure1
presents the IPv4 and IPv6 main headers.

The options field in the IPv4 header is used to convey additional information on the
packet or on the way it should be processed. Routers, unless instructed otherwise [1],
must process the options in the IPv4 header. The processing of most header options
pushes the packet into the slow path leading to a forwarding performance hit.
Commonly Used Extension Headers
The Extension Header should not be viewed as an esoteric feature of IPv6 that would be
encountered only at later stages of the network and service deployment. Extension
headers are an intrinsic part of the IPv6 protocol and they support some basic functions
and certain services. The following is a list of circumstances where EHs are commonly
used:
● Hop-by-Hop EH is used for the support of Jumbo-grams or, with the Router Alert
option; it is an integral part in the operation of MLD. Router Alert [3] is an integral part
in the operations of IPv6 Multicast through Multicast Listener Discovery (MLD) and
RSVP for IPv6.
● Destination EH is used in IPv6 Mobility as well as support of certain applications.
● Routing EH is used in IPv6 Mobility and in Source Routing. It may be necessary to
disable “IPv6 source routing” on routers to protect against DDoS.
● Fragmentation EH is critical in support of communication using fragmented packets
(in IPv6, the traffic source must do fragmentation routers do not perform fragmentation
of the packets they forward)
● Mobility EH is used in support of Mobile IPv6 service
● Authentication EH is similar in format and use to the IPv4 authentication header
defined in RFC2402 [4].
● Encapsulating Security Payload EH is similar in format and use to the IPv4 ESP
header defined in RFC2406 [5]. All information following the Encapsulating Security
Header (ESH) is encrypted and for that reason, it is inaccessible to intermediary network
devices. The ESH can be followed by an additional Destination Options EH and the
upper layer datagram.
This document reviews the concepts of IPv6 Extension Header (EH). It focuses on
the implications that the presence of extension headers have on the native IPv6
traffic forwarding performance of network devices.

Q) Discuss the scope of ESP encryption and authentication in IPV4 and

IPV6?
Ans) The Encapsulating Security Payload (ESP) header is designed to provide a mix of
security services in IPv4 and IPv6. ESP may be applied alone, in combination with the
IP Authentication Header (AH) [KA97b], or in a nested fashion, e.g., through the use of
tunnel mode (see "Security Architecture for the Internet Protocol" [KA97a], here after
referred to as the Security Architecture document). Security services can be provided
between a pair of communicating hosts, between a pair of communicating security
gateways, or between a security gateway and a host. For more details on how to use ESP
and AH in various network environments, see the Security Architecture document
[KA97a].
The ESP header is inserted after the IP header and before the upper layer protocol header
(transport mode) or before an encapsulated IP header (tunnel mode). These modes are
described in more detail below.

ESP is used to provide confidentiality, data origin authentication, connectionless

integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic
flow confidentiality. The set of services provided depends on options selected at the time
of Security Association establishment and on the placement of the implementation.
Confidentiality may be selected independent of all other services. However, use of
confidentiality without integrity/authentication (either in ESP or separately in AH) may
subject traffic to certain forms of active attacks that could undermine the confidentiality
service (see [Bel96]).

ESP header formate:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number erage
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data* (variable) |
|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Authentication Data (Varible)
If included in the Payload field, cryptographic synchronization data, e.g., an Initialization
Vector (IV, see Section 2.3), usually is not encrypted per se, although it often is referred
to as being part of the cipher text.
IPv4, this translates to placing ESP after the IP header (and an options that it contains),
but before the upper layer protocol. (Note that the term "transport" mode should not be
misconstrued as restricting its use to TCP and UDP. For example, an ICMP message
MAY be sent using either "transport" mode or "tunnel" mode.) The following diagram
illustrates ESP transport mode positioning for typical IPv4 packet, on a "before and after"
basis. (The "ESP trailer" encompasses any Padding, plus the Pad Length, and Next
Header fields.)

BEFORE APPLYING ESP

----------------------------
IPv4 | orig IP hdr | | |
| (any options)| TCP | Data |
----------------------------

AFTER APPLYING ESP

-------------------------------------------------
IPv4 | orig IP hdr | ESP | | | ESP | ESP|
| (any options)| Hdr | TCP | Data | Trailer | Auth|
-------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|
In the IPv6 context, ESP is viewed as an end-to-end payload, and thus should appear after
hop-by-hop, routing, and fragmentation extension headers.The destination options
extension header(s) could appear either before or after the ESP header depending on the
semantics desired. However, since ESP protects only fields after the ESP header, it
generally may be desirable to place the destination options header(s) after the ESP
header. The following diagram illustrates ESP transport mode positioning for a typical
IPv6 packet.

BEFORE APPLYING ESP

---------------------------------------
IPv6 | | ext hdrs | | |
 | Orig IP hdr |if present| TCP | Data |
---------------------------------------

AFTER APPLYING ESP

AFTER APPLYING ESP

---------------------------------------------------------
IPv6 | orig |hop-by-hop, dest*,| |dest| | | ESP | ESP|
|IP hdr|routing, fragment.|ESP|opt*|TCP|Data|Trailer|Auth|
---------------------------------------------------------
|<---- encrypted ---->|
|<---- authenticated ---->|

* = if present, could be before ESP, after ESP, or both

ESP and AH headers can be combined in a variety of modes. The IPsec Architecture
document describes the combinations of security associations that must be supported.
Tunnel mode ESP may be employed in either hosts or security gateways.
When ESP is implemented in a security gateway (to protect subscribe transit traffic),
tunnel mode must be used. In tunnel mode, the” inner" IP header carries the ultimate
source and destination addresses, while an "outer" IP header may contain distinct
IPaddresses, e.g., addresses of security gateways. In tunnel mode, ESP protects the entire
inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode,
relative to the outer IP header, is the same as for ESP in transport mode. The following
diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets.

IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|

|(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
-----------------------------------------------------------
|<--------- encrypted ---------->|
|<----------- authenticated ---------->|

IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|

|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer|Auth|
------------------------------------------------------------
|<--------- encrypted ----------->|
|<---------- authenticated ---------->|

Packet Encryption
 In this section, we speak in terms of encryption always being applied because of the
formatting implications. This is done with the understanding that "no confidentiality" is
offered by using the NULL encryption algorithm. Accordingly, the sender:
1. encapsulates (into the ESP Payload field):
- For transport mode -- just the original upper layer Protocol information.
- For tunnel mode -- the entire original IP datagram.
2. Adds any necessary padding.
3. encrypts the result (Payload Data, Padding, Pad Length, and Next Header) using the
key, encryption algorithm, algorithm mode indicated by the SA and cryptographic
synchronization data (if any).
- If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is
input to the encryption algorithm per the algorithm specification and placed in the
Payload field.
- If implicit cryptographic synchronization data, e.g. an IV, is indicated, it is
constructed and input to the encryption algorithm as per the algorithm specification.

The exact steps for constructing the outer IP header depend on the mode (transport or
tunnel) and are described in the Security Architecture document.

If authentication is selected, encryption is performed first, before the authentication, and

the encryption does not encompass the Authentication Data field.

This order of processing facilitates rapid detection and rejection of replayed or bogus
packets by the receiver, prior to decrypting the packet, hence potentially reducing the
impact of denial of service attacks. It also allows for the
Possibility of parallel processing of packets at the receiver, i.e., decryption can take place
in parallel with authentication. Note that since the Authentication Data is not protected
by encryption, a keyed authentication algorithm must be employed to compute the ICV.

Q) Explain about Modes of operations in IP Sec?

Ans) IPSec Modes

We have talked about IPSec in transport mode and tunnel mode without explaining when
and how IPSec protocols are used in these modes. In this section, we describe how the
IPSec protocols, AH and ESP, implement the tunnel and transport modes. There are four
possible combinations of modes and protocol: AH in transport mode, AH in tunnel mode,
ESP in transport mode, and ESP in tunnel mode. In practice, AH in tunnel mode is not
used because it protects the same data that AH in transport mode protects.

The AH and ESP header do not change between tunnel or transport mode. The difference
is more semantic in nature‹what it is they are protecting, IP packet or an IP payload. The
guidelines for deciding what mode to use and some examples of using IPSec in various
modes, is discussed in later chapters.

Transport Mode

In transport mode, AH and ESP protect the transport header. In this mode, AH and ESP
intercept the packets flowing from the transport layer into the network layer and provide
the configured security.

Let us consider an example. In Figure 4.5, A and B are two hosts that have been
configured so that all transport layer packets flowing between them should be encrypted.
In this case, transport mode of ESP is used. If the requirement is just to authenticate
transport layer packets, then transport mode of AH is used.

Figure : Hosts with Transport ESP

When security is not enabled, transport layer packets such as TCP and UDP flow into the
network layer, IP, which adds the IP header and calls into the data link layer. When
security in transport layer is enabled, the transport layer packets flow into the IPSec
component. The IPSec component is implemented as part of the network layer (when
intergrated with OS). The IPSec component adds the AH, ESP, or both headers, and
invokes the part of the network layer that adds the network layer header.

The transport mode of IPSec can be used only when security is desired end to end. As
stated earlier, the routers look mostly at the network layer in making routing decisions
and the routers do not and should not change anything beyond the network layer header.
Inserting transport mode IPSec header for packets flowing through a router is a violation
of this rule.

When both AH and ESP are used in transport mode, ESP should be applied first. The
reason is obvious. If the transport packet is first protected using AH and then using ESP,
the data integrity is applicable only for the transport payload as the ESP header is added
later on as shown in Figure 4.6. This is not desirable because the data integrity should be
calculated over as much data as possible.

Figure A: Packet format with ESP and AH

If the packet is protected using AH after it is protected using ESP, then the data integrity
applies to the ESP payload that contains the transport payload as shown in Figure 4.7.

Figure B: Packet format with AH and ESP

The transport mode for BITS implementation is not as clean, as the ESP and AH headers
are inserted after the IP payload is constructed. This implies the BITS implementation has
to duplicate the IP functionality because it has to recalculate the IP checksum and
fragment the packet if necessary. Many BITS implementations may not support transport
mode but support only tunnel mode.

Tunnel Mode

IPSec in tunnel mode is normally used when the ultimate destination of the packet is
different from the security termination point as shown in Figure 4.8 or in case of BITS or
BITW implementations. The tunnel mode is used in cases when security is provided by a
device that did not originate packets - as in the case of VPNs - or when the packet needs
to be secured to a destination that is different from the actual destination.

Figure: IPSec in tunnel mode

It is also used when a router provides security services for packets it is forwarding. The
operation of tunnel mode is discussed in detail in the IPSec implementation chapter.

In the case of tunnel mode, IPSec encapsulates an IP packet with IPSec headers and adds
an outer IP Header as shown in Figure 4.9.

Figure: IPSec tunneled Mode packet format

An IPSec tunneled mode packet has two IP headers‹inner and outer. The inner header is
constructed by the host and the outer header is added by the device that is providing the
security services. This can be either the host or a router. There is nothing that precludes a
host from providing tunneled mode security services end to end. However, in this case
there is no advantage to using tunnel mode instead of transport mode. In fact, if the
security services are provided end to end, transport mode is better because it does not add
an extra IP header.

IPSec defines tunnel mode for both AH and ESP. IPSec also supports nested tunnels. The
nested tunneling is where we tunnel a tunneled packet as shown in Figure A.

Figure: A Nested tunnel example

Figure: B Nested packet format

In this example, host A is sending a packet to host B. The policy says it has to
authenticate itself to router RB. In addition, there is a VPN between the two networks
bordered by RA and RB. The packet seen by router RB is shown in Figure B. The
outermost header is the tunneled ESP packet. It is carrying a tunneled AH packet. The
tunneled AH packet is carrying the IP packet destined for the host B generated by host A.

Figure A: A Valid tunnel

Figure B: B Invalid tunnel

The requirement for the tunnel is that inner header is completely encompassed by the
outer header. The valid and invalid tunnels examples are shown in Figures A and B.

The example shown in Figure A is valid as the inner tunnel (tunnel 2) is completely
encompassed by tunnel 1. The example shown in Figure 4.11B is invalid because neither
tunnel completely encompasses the other. To understand why this is invalid, let us trace
the packet flow. After RA constructs the tunneled packet, the packet format is as shown
in Figure A.

Figure A: A Tunneled packet

When the packet reaches RB, it tunnels the packet to host C. The packet format when the
packet leaves RB is shown in Figure B.

Figure B: B Invalid tunnel packet

Clearly, this is incorrect because the packet now reaches host C before it reaches RC.
When the packet reaches host C, it processes the AH header. When the second IP header
is exposed, the host drops the packet because the destination is RC and not itself. Nested
tunnels are difficult to build and maintain and should be used sparingly.

Q IP Security document mandates two types of key management. what

are they?

The key management portion of IPSec involves the determination and distribution of
secret keys. The IPSec Architecture document mandates support for two types of key
management:
 • Manual : A system administrator manually configures each system with its own
keys and with the keys of other communicating sys-tems. This is practical for
small, relatively static environments.

Advantages: dhoc implementation is easier.

Disadvantages:

1. it is not scalable.

2. This System Will not support some of the IP Security Features.This system Will
not support Anti-replay feature in both AH and ESP.

• Automated : An automated system enables the on-demand creation of keys for

SAs and facilitates the use of keys in a large distributed system with an evolving
configuration. An automated system is the most flexible but requires more effort
to configure and requires more software, so smaller installations are likely to opt
for manual key management.

Advantages: This system is scalable to large networks and across administrative

boundaries.

Disadvantages: This system requires PKI for complete Authentication.

The default automated key management protocol for IPSec is referred to as Internet Key
Exchange (IKE). IKE provides a standardized method for dynamically authenticating
IPSec peers, negotiating security services, and generating shared keys.One of these
capabilities is based on the Internet Security Association and Key Management Protocol
(ISAKMP). ISAKMP provides a framework for Internet key management and provides
the specific protocol support, including formats, for negotiation of security attributes.
ISAKMP by itself does not dictate a specific key exchange algorithm; rather, ISAKMP
consists of a set of message types that enable the use of a variety of key exchange
algorithms. The actual key exchange mechanism in IKE is derived from Oakley and
several other key exchange protocols that had been proposed for IPSec.

OAKLEY KEY Exchange protopcol:

The Diffie-Hellman key exchange algorithm provides such a mechanism. It allows two
parties to agree on a shared value without requiring encryption. The shared value is
immediately available for use in encrypting subsequent conversation, e.g. data
transmission and/or Authentication.
The protocol allows two parties to use all or some of the anti-clogging and perfect
forward secrecy features. It also permits the use of authentication based on symmetric
encryption or non-encryption algorithms. This flexibility is included in order to allow the
parties to use the features that are best suited to their security and performance
requirements.
The Essential Key Exchange Message Fields

There are 12 fields in an OAKLEY key exchange message. Not all the fields are relevant
in every message; if a field is not relevant it can have a null value or not be present (no
payload).

CKY-I originator cookie.

CKY-R responder cookie.
MSGTYPE for key exchange, will be ISA_KE&AUTH_REQ or
ISA_KE&AUTH_REP; for new group definitions,
Will be ISA_NEW_GROUP_REQ or ISA_NEW_GROUP_REP
GRP the name of the Diffie-Hellman group used for
the exchange
g^x (or g^y) variable length integer representing a power of group generator.
EHAO
or
EHAS encryption, hash, authentication functions,
Offered and selected, respectively
 IDP an indicator as to whether or not encryption with
g^xy follows (perfect forward secrecy for ID's)
ID(I) the identity for the Initiator
ID(R) the identity for the Responder
Ni nonce supplied by the Initiator
Nr nonce supplied by the Responder
Features of diffie-Hellman Algorithm:
1. Secret keys are created only whenever it is need .there is needed to store secret
keys for longer period of time.
2. The exchange requires no preexisting infrastructure other than an agreement on to
global parameters.
Weaknesses to Diffie –Hellmann algorithm:
1. It does provide any information about the identies of the parties.
2. It is subject to a man –in middle attack, In which is third party C impersonates B
with communication with A while impersonates A while communicating with C.Both
and B end up negotiation a key with C, which can then listen to and ppass on traffic.
The man-in –middle attack proceeds as follows.
3. It is computationally incentive. As a result it is vulnerable to clogging attack, in
while an opponent requests a high number of keys. Then the victim spends
considerable Computing resources doing unless modular exoneration rather then real
works.

Oakley is a refinement of the Diffie-Hellman key exchange algorithm. Recall that Diffie-
Hellman involves the following interaction between users A and B. There is prior
agreement on two global parameters: q, a large prime number; and α a primitive root of
q. A selects a random integer XA as its private key, and transmits to B its public key YA =
α XA
mod q. Similarly, B selects a random integer XB as its private key and transmits to A
its public key YB = α XB
mod q. Each side can now compute the secret session key:
Features of oakly: five important features characterizer the Oakley algorithm:
1. It employs a mechanism known as “cookies “to oppose algorithm:
2. It enables two parties to negotiate a group. This specifies the global parameters
the Diffie-Hellman key exchange.
3. It uses Nonces to ensure against reply attacks.
4. It enables the exchange of Diffie –Hellman public key values.
5. It authenticates the Diffie-Hellman exchange to oppose man –in –middle attacks.
Now we explain each feature in detail.
1. Cookies: In clogging attack, an opponent forges the source address of the
authenticated user and sends the public Diffie-Hellman key to the victim .The
victim performs the modular exponentiation to compute the secret the key. The
cookie exchange requires that both the server and stored at the Clint send a
pseudorandom number called cookie the initial message .if the opponent forges
the sources address ,he will not get the answer the opponent can only force the
user to generate acknowledgement and will perform the Diffie –Hellmann
calculations.
2. Group: Oakley supports the use of different groups for Diffie-
Hellman exchange. Each group includes the definition of the two parameters
and the identity of algorithm. The current specification gives some of the
groups. Modular exponentiation with 768 bit moduls:the two parameters are
q =2768_2704_1+264*(2638*pl+149686)
α =2
Modular exponentiation with 1024 bit modulus: the two parameters are
q = 21024_2960 – 1/ 264*(2894 *pl +1290930)
α=2
Elliptic curve group over 2155
The elliptic curve generate X= 7 B and Y = 1C8
The elliptic curve parameters A = 0, Y =7338F.
 3. Nonces: Okely employs nonces to ensure against the reply attacks .Each nonce
is locally generated is completed pseudorandom number, nonce appear in
responses and are encrypted during certain portions of exchange to secure their
use.

4. Oakley key Exchange: The following example shows an aggressive exchange

the key exchange is completed after three messages. Therefore the identities are
not protected. Figuere shows the message and data which is transmitted in this
exchange.
5. Authentication: Three Different authentication methods can be used with
Oakley.
a) Digital Signature: The Exchange is authenticating by signing a mutually
obtainable hash: in this the initiator and the responder Encrypts the hash with its
private key. The hash I generated over important parameters like user Ids and nonce.
b) Public key Encryption: In this the initiator and responders exchange is
authenticated by encrypting parameters such as user’s ID and nonces with initiator’s
private key.
c) Private key Encryption: A key is derived by some out-of-band mechanism can be
used to authenticate the exchange by symmetric encryption of exchange parameters.

ISAKMP HEADER FORMATE:

ISAKMP defines procedures and packet formats to establish, negotiate, modify and
delete Security Associations. SAs contain all the information required for execution of
various network security services, such as the IP layer services (such as header
authentication and payload encapsulation), transport or application layer services, or self-
protection of negotiation traffic. ISAKMP defines payloads for exchanging key
generation and authentication data. These formats provide a consistent framework for
transferring key and authentication data which is independent of the key generation
technique, encryption algorithm and authentication mechanism.

ISAKMP is distinct from key exchange protocols in order to cleanly separate the details
of security association management (and key management) from the details of key
exchange. There may be many different key exchange protocols, each with different
security properties. However, a common framework is required for agreeing to the format
of SA attributes, and for negotiating, modifying, and deleting SAs. ISAKMP serves as
this common framework.

ISAKMP header:

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Initiator cookie
-
Responder cookie
-
Mjr
Next payload Mnr version Exchange type Flags
version
Message ID
Length

Initiatorcookie.8bytes.
The cookie of the entity that initiated SA establishment, SA notification, or SA deletion.

Respondercookie.8bytes.
The cookie of the entity that is responding to an SA establishment request, SA
notification, or SA deletion.

Nextpayload.8bits.
Indicates the type of the first payload in the message.
Mjrversion.4bits.
The major version of the ISAKMP protocol in use.

Mnrversion.4bits.
the minor version of the ISAKMP protocol in use.

Exchangetype.8bits.
indicates the type of exchange being used. This dictates the message and payload
orderings in the ISAKMP exchanges.

Flags.8bits.
Indicates the options that are set for the ISAKMP exchange.

00 01 02 03 04 05 06 07
reserved A C E

A,Authenticationonly.1bit.
Intended for use with the Informational Exchange with a Notify payload and will allow
the transmission of information with integrity checking, but no encryption.

C,Commit.1bit.
Used to signal key exchange synchronization. It is used to ensure that encrypted material
is not received prior to completion of the SA establishment.

E,Encryption.1bit.
If set, all payloads following the header are encrypted using the encryption algorithm
identified in the ISAKMP SA.

MessageID.4bytes.
A unique value used to identify the protocol state during Phase 2 negotiations. It is
randomly generated by the initiator of the Phase 2 negotiation.

Length.4bytes.
The total length of the ISAKMP header and the encapsulated payloads in bytes.
Q) ISAKMP payload types
1. Security association payload: The security association payload is used negotiate
security attributes and to indicate the domain of interpretation (DO1) and situation
under which the negotiation is taking place. below figure shows the format
of the security association payload

Next pay load RESERVED Payload length

Domain of interpretation DOI
SITUATION

Figuere: security association

2. Proposal payload: The proposal payload contains information used due in
security association negotiation. The proposal consists of security mechanisms,
transforms to secure the communications channel. Below figure show the format
of the proposal payload.

Next payload RESERVED Payload length

Proposal# Protocol-ID SPI size Transform#

SPI (variable)

Figure: proposal payload

3. Transform payload: The Transform payload contains information used durin
security Association negotiation. The transform payload consists of a specific
security mechanism, or transformas.to be used to secure the communications
channel The Transform payload also contains the security association attributes
Associates with the specific transform. These SA attributes are DOI-specific.
Below figure shows the format of the Transform payload.

Next payload RESERVED Payload length

Transform# Transform-ID RESERVED2
SA (variable)
 Figure: Transform payload
4. Key exchange payload: The key exchange payload supports a variety of key
Exchange techniques. Example key exchange are Oakley, Diffie- Hellman,The
enhanced diffie-hellman key exchanges described in previous section, And the
RSA-based key exchange used by PGP.below figure shows the format Of the key
exchange payload.

Next payload RESERVED Payload length

Key Exchange Data

Figure: key Exchange payload

5. Identification payload : The Identification payload contains DOI specific data

Used to exchange Identification information. This information is used for
determining the identities of communicating peers and may be used for
determining authenticity of information. Figure shows the of the identification
payload.

Next payload RESEVRED Payload length

ID type DOI specific I D data
Identification Data

Figure: Identification payload

ISAKMP Exchanges:
Base Exchange:
The Base Exchange is designed to allow the Key Exchange and Authentication related
information to be transmitted together. Combining the Key Exchange and Authentication
related information into one message reduces the number of round-trips at the expense of
not providing identity protection. Identity protection is not provided because identities
are exchanged before a common shared secret has been established and, therefore,
encryption of the identities is not possible. The following diagram shows the messages
With the possible payloads sent in each message and notes for an example of the Base
Exchange.
BASE EXCHANGE

# Initiator Direction Responder NOTE

(1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation

(2) <= HDR; SA; NONCE

Basic SA agreed upon
(3) HDR; KE; =>
IDii; AUTH Key Generated (by responder)
Initiator Identity Verified by
Responder
(4) <= HDR; KE;
IDir; AUTH
Responder Identity Verified by
Initiator Key Generated (by
Initiator) SA established

Identity Protection Exchange

The Identity Protection Exchange is designed to separate the Key Exchange information
from the Identity and Authentication related information. Separating the Key Exchange
from the Identity and Authentication related information provides protection of the
communicating identities at the expense of two additional messages.Identities is
exchanged under the protection of a previously established common shared secret. The
following diagram shows the messages with the possible payloads sent in each message
and notes for an example of the Identity Protection Exchange.

IDENTITY PROTECTION EXCHANGE

 # Initiator Direction Responder NOTE
(1) HDR; SA => Begin ISAKMP-SA or
Proxy negotiation
(2) <= HDR; SA
Basic SA agreed upon
(3) HDR; KE; NONCE =>
(4) <= HDR; KE; NONCE
Key Generated (by
Initiator and
Responder)
(5) HDR*; IDii; AUTH =>
Initiator Identity
Verified by
Responder
(6) <= HDR*; IDir; AUTH
Responder Identity
Verified by
Initiator
SA established

In the first message (1), the initiator generates a proposal it considers adequate to protect
traffic for the given situation. The Security Association, Proposal, and Transform
payloads are included in the Security Association payload (for notation purposes).

In the second message (2), the responder indicates the protection suite it has accepted
with the Security Association, Proposal, and Transform payloads. Local security policy
dictates the action of the responder if no proposed protection suite is accepted. One
possible action is the transmission of a Notify payload as part of an Informational
Exchange.
In the third (3) and fourth (4) messages, the initiator and responder, respectively,
exchange keying material used to arrive at a common shared secret and random
information which is used to guarantee liveness and protect against replay attacks.
Random information provided by both parties SHOULD be used by the authentication
mechanism to provide shared proof of participation in the exchange. Local security
policy dictates the action if an erroroccurs during these messages. One possible action is
the transmission of a Notify payload as part of an Informational Exchange. In the fifth (5)
and sixth (6) messages, the initiator and responder, respectively, exchange identification
information and the results of the agreed upon authentication function.
Authentication Only Exchange

The Authentication Only Exchange is designed to allow only Authentication related

information to be transmitted. The benefit of this exchange is the ability to perform only
authentication without the computational expense of computing keys. Using this
exchange during negotiation, none of the transmitted information will be encrypted.
However, the information may be encrypted in other places. For example, if encryption
is negotiated during the first phase of a negotiation and the authentication only exchange
is used in the second phase of a negotiation, then the authentication only exchange will be
encrypted by the ISAKMP SAs negotiated in the first phase. The following diagram
shows the messages with possible payloads sent in each message and notes for an
example of the Authentication Only Exchange.

AUTHENTICATION ONLY EXCHANGE

# Initiator Direction Responder NOTE

(1) HDR; SA; NONCE => Begin ISAKMP-SA or
Proxy negotiation
(2) <= HDR; SA; NONCE;
IDir; AUTH
Basic SA agreed upon
Responder Identity
Verified by Initiator
(3) HDR; IDii; AUTH =>
Initiator Identity
Verified by Responder
SA established

In the first message (1), the initiator generates a proposal it considers adequate to
protect traffic for the given situation. The Security Association, Proposal, and Transform
payloads are included in the Security Association payload (for notation purposes).
Random information which is used to guarantee liveness and protect against replay
attacks is also transmitted. Random information provided by both parties SHOULD be
used by the authentication mechanism to provide shared proof of participation in the
exchange. In the second message (2), the responder indicates the protection suite it has
accepted with the Security Association, Proposal, and Transform payloads. Again,
random information which is used to
Aggressive exchange:
Aggressive Exchange is designed to allow the Security Association, Key Exchange and
Authentication related payloads to be transmitted together. Combining the Security
Association, Key Exchange, and Authentication-related information into one message
reduces the number of round-trips at the expense of not providing identity protection.
Identity protection is not provided because identities are exchanged before a common
shared secret has been established and, therefore, encryption of the identities is not
possible. Additionally, the Aggressive Exchange is attempting to establish all security
relevant information in a single exchange. The following diagram shows the messages
with possible payloads sent in each message and notes for an example of the Aggressive
Exchange.
AGGRESSIVE EXCHANGE

# Initiator Direction Responder NOTE

(1) HDR; SA; KE; => Begin ISAKMP-SA or
Proxy negotiation
NONCE; IDii and Key Exchange

(2) <= HDR; SA; KE;

NONCE; IDir; AUTH
Initiator Identity
Verified by Responder
Key Generated
Basic SA agreed upon
(3) HDR*; AUTH =>
Responder Identity
Verified by Initiator
SA established
(1), the initiator generates a proposal it considers adequate to protect traffic for the given
situation. The Security Association, Proposal, and Transform payloads are included in
the Security Association payload (for notation purposes).
In the second message (2), the responder indicates the protection suite it has accepted
with the Security Association, Proposal, and Transform payloads. Keying material used
to arrive at a common shared secret and random information which is used to guarantee
live ness and protect against replay attacks is also transmitted.

The Informational Exchange is designed as a one-way transmittal of information that can

be used for security association management. The following diagram shows the messages
with possible payloads sent in each message and notes for an example of the
Informational Exchange.

INFORMATIONAL EXCHANGE

# Initiator Direction Responder NOTE

(1) HDR*; N/D => Error Notification or Deletion

In the first message (1), the initiator or responder transmits an ISAKMP Notify or Delete
payload

6. Certificate payload: The certificate payload provides a means to transport

certificates or other certificate- related information via ISAKMP and can appear
in any ISAKMP message. Certificate payloads SHOULD be included in an
exchange whenever an appropriate directory service (example: secure DNS
(DNSSEC) is not available to distribute certificates. The certificate payload
MUST be accepted at any point during an exchange. Figure shows the certificate
payload.

Next payload RESERVED Payload length

Cert Encoding
Certificate Data
Figure: Certification payload