UNIT – 4

E-Mail SECURITY
PRETTY GOOD PRIVACY
PGP is an open-source, freely available software package for e-mail security. It
provides authentication through the use of digital signature, confidentiality
through the use of symmetric block encryption, compression using the ZIP
algorithm, and e-mail compatibility using the radix-64 encoding scheme.
Notations:
Ks = session key used in symmetric encryption scheme
PRa = private key of user A, used in public-key encryption scheme
PUa = public key of user A, used in public-key encryption scheme
EP = public-key encryption
DP = public-key decryption
EC = symmetric encryption
DC = symmetric decryption
H = hash function
|| = concatenation

Z = compression using ZIP algorithm

R64 = conversion to radix 64 ASCII format

1
Operational description:
The actual operation of PGP, as opposed to the management of keys, consists of
four services: authentication, confidentiality, compression, and e-mail
compatibility.
Authentication:
The sequence of steps as follows
1. The sender creates a message.
2. SHA-1 is used to generate a 160-bit hash code of the message.
3. The hash code is encrypted with RSA using the sender’s private key, and
the result is prepended to the message.
4. The receiver uses RSA with the sender’s public key to decrypt and
recover the hash code.
5. The receiver generates a new hash code for the message and compares it
with the decrypted hash code. If the two match, the message is accepted
as authentic.
CONFIDENTIALITY Another basic service provided by PGP is confidentiality,
which is provided by encrypting messages to be transmitted or to be stored
locally as files
The sequence is as follows.

2
 1. The sender generates a message and a random 128-bit number to be used
as a session key for this message only.
2. The message is encrypted using CAST-128 (or IDEA or 3DES) with the
session key.
3. The session key is encrypted with RSA using the recipient’s public key
and is prepended to the message.
4. The receiver uses RSA with its private key to decrypt and recover the
session key.
5. The session key is used to decrypt the message.

CONFIDENTIALITY AND AUTHENTICATION As both services may be used

for the same message.
 First, a signature is generated for the plaintext message and prepended
to the message.
 Then the plaintext message plus signature is encrypted using CAST-128
(or IDEA or 3DES), and the session key is encrypted using RSA (or
ElGamal).
 This sequence is preferable to the opposite: encrypting the message and
then generating a signature for the encrypted message.
 It is generally more convenient to store a signature with a plaintext
version of a message.
 Furthermore, for purposes of third-party verification, if the signature is
performed first, a third party need not be concerned with the symmetric
key when verifying the signature.
COMPRESSION As a default, PGP compresses the message after applying the
signature but before encryption. This has the benefit of saving space both for
e-mail transmission and for file storage.
1. The signature is generated before compression for two reasons:
 It is preferable to sign an uncompressed message so that one can store
only the uncompressed message together with the signature for future
verification.
 Even if one were willing to generate dynamically a recompressed message
for verification, PGP’s compression algorithm presents a difficulty. The
algorithm is not deterministic; various implementations of the algorithm
achieve different tradeoffs in running speed versus compression ratio
and, as a result, produce different compressed forms.
2. Message encryption is applied after compression to strengthen cryptographic
security.
E-MAIL COMPATIBILITY When PGP is used, at least part of the block to be
transmitted is encrypted. If only the signature service is used, then the
message digest is encrypted (with the sender’s private key).
 If the confidentiality service is used, the message plus signature (if
present) are encrypted (with a one-time symmetric key).

3
  Thus, part or all of the resulting block consists of a stream of arbitrary
8-bit octets.
 However, many electronic mail systems only permit the use of blocks
consisting of ASCII text.
 To accommodate this restriction, PGP provides the service of converting
the raw 8-bit binary stream to a stream of printable ASCII characters.

PGP Message Generation:

4
S/MIME (Secure/Multipurpose Internet Mail Extensions)
S/MIME is a security enhancement to the MIME Internet e-mail format
standard based on technology from RSA Data Security.
Multipurpose Internet Mail Extension (MIME) is an extension to the RFC 5322
framework that is intended to address some of the problems and limitations of
the use of Simple Mail Transfer Protocol (SMTP), defined in RFC 821, or some
other mail transfer protocol and RFC 5322 for electronic mail. [PARZ06] lists
the following limitations of the SMTP/5322 scheme.
 SMTP cannot transmit executable files or other binary objects.
 SMTP cannot transmit text data that includes national language
characters, because these are represented by 8-bit codes with values of
128 decimal or higher, and SMTP is limited to 7-bit ASCII.
 SMTP servers may reject mail message over a certain size.
 SMTP gateways that translate between ASCII and the character code
EBCDIC do not use a consistent set of mappings, resulting in translation
problems.
 SMTP gateways to X.400 electronic mail networks cannot handle non-
textual data included in X.400 messages.
Header fields in MIME:

The five header fields defined in MIME are

 MIME-Version: Must have the parameter value 1.0. This field indicates
that the message conforms to RFCs 2045 and 2046.
 Content-Type: Describes the data contained in the body with sufficient
detail that the receiving user agent can pick an appropriate agent or
mechanism to represent the data to the user or otherwise deal with the
data in an appropriate manner.
 Content-Transfer-Encoding: Indicates the type of transformation that
has been used to represent the body of the message in a way that is
acceptable for mail transport.
 Content-ID: Used to identify MIME entities uniquely in multiple
contexts.
 Content-Description: A text description of the object with the body;
this is useful when the object is not readable (e.g., audio data).

IP SECURITY OVERVIEW
IP security (IPsec) is a capability that can be added to either current
version of the Internet Protocol (IPv4 or IPv6) by means of additional headers.
IPsec encompasses three functional areas: authentication, confidentiality, and
key management.
In 1994, the Internet Architecture Board (IAB) issued a report titled
“Security in the Internet Architecture”
To provide security, the IAB included authentication and encryption as
necessary security features in the next-generation IP, which has been issued as

5
IPv6. Fortunately, these security capabilities were designed to be usable both
with the current IPv4 and the future IPv6.
Applications of IPsec

IPsec provides the capability to secure communications across a LAN, across

private and public WANs, and across the Internet. Examples of its use include:
Secure branch office connectivity over the Internet: A company can build a
secure virtual private network over the Internet or over a public WAN.
Secure remote access over the Internet: An end user whose system is
equipped with IP security protocols can make a local call to an Internet Service
Provider (ISP) and gain secure access to a company network.
Establishing extranet and intranet connectivity with partners: IPsec can be
used to secure communication with other organizations, ensuring authentication
and confidentiality and providing a key exchange mechanism.
Enhancing electronic commerce security: Even though some Web and
electronic commerce applications have built-in security protocols, the use of
IPsec enhances that security.

The principal feature of IPsec that enables it to support these varied

applications is that it can encrypt and/or authenticate all traffic at the IP level.
Thus, all distributed applications (including remote logon, client/server, e-mail,
file transfer, Web access, and so on) can be secured.

Figure 19.1 is a typical scenario of IPsec usage. An organization maintains LANs

at dispersed locations. Non-secure IP traffic is conducted on each LAN. For
traffic offsite, through some sort of private or public WAN, IPsec protocols

6
are used. These protocols operate in networking devices, such as a router or
firewall, that connect each LAN to the outside world.

Benefits of IPsec
Some of the benefits of IPsec:
 When IPsec is implemented in a firewall or router, it provides strong
security that can be applied to all traffic crossing the perimeter. Traffic
within a company or workgroup does not incur the overhead of security-
related processing.
 IPsec in a firewall is resistant to bypass if all traffic from the outside
must use IP and the firewall is the only means of entrance from the
Internet into the organization.
 IPsec is below the transport layer (TCP, UDP) and so is transparent to
applications.
 IPsec can be transparent to end users.
 IPsec can provide security for individual users if needed.

Routing Applications
 Router advertisement (a new router advertises its presence) comes from
an authorized router.
 A neighbor advertisement (a router seeks to establish or maintain a
neighbour relationship with a router in another routing domain) comes
from an authorized router.
 A redirect message comes from the router to which the initial IP packet
was sent.
 A routing update is not forged.

IPsec Services
IPsec provides security services at the IP layer by enabling a system to select
required security protocols, determine the algorithm(s) to use for the
service(s), and put in place any cryptographic keys required to provide the
requested services.
 Access control
 Connectionless integrity
 Data origin authentication
 Rejection of replayed packets (a form of partial sequence integrity)
 Confidentiality (encryption)
 Limited traffic flow confidentiality

IP SECURITY ARCHITECTURE

7
IPSec (IP Security) architecture uses two protocols to secure the traffic or
data flow. These protocols are ESP (Encapsulation Security Payload) and AH
(Authentication Header). IPSec Architecture includes protocols, algorithms,
DOI, and Key Management. All these components are very important in order to
provide the three main services:

 Confidentiality
 Authentication
 Integrity

1. Architecture: Architecture or IP Security Architecture covers the general

concepts, definitions, protocols, algorithms, and security requirements of IP
Security technology.

2. ESP Protocol: ESP(Encapsulation Security Payload) provides a confidentiality

service. Encapsulation Security Payload is implemented in either two ways:

 ESP with optional Authentication.

 ESP with Authentication.

8
Packet Format:

 Security Parameter Index(SPI): This parameter is used by Security

Association. It is used to give a unique number to the connection built
between the Client and Server.
 Sequence Number: Unique Sequence numbers are allotted to every
packet so that on the receiver side packets can be arranged properly.
 Payload Data: Payload data means the actual data or the actual message.
The Payload data is in an encrypted format to achieve confidentiality.
 Padding: Extra bits of space are added to the original message in order
to ensure confidentiality. Padding length is the size of the added bits of
space in the original message.
 Next Header: Next header means the next payload or next actual data.
 Authentication Data This field is optional in ESP protocol packet format.

3. Encryption algorithm: The encryption algorithm is the document that

describes various encryption algorithms used for Encapsulation Security
Payload.

4. AH Protocol: AH (Authentication Header) Protocol provides both

Authentication and Integrity service. Authentication Header is implemented in
one way only: Authentication along with Integrity.

9
Authentication Header covers the packet format and general issues related to
the use of AH for packet authentication and integrity.

5. Authentication Algorithm: The authentication Algorithm contains the set of

documents that describe the authentication algorithm used for AH and for the
authentication option of ESP.

6. DOI (Domain of Interpretation): DOI is the identifier that supports both

AH and ESP protocols. It contains values needed for documentation related to
each other.

7. Key Management: Key Management contains the document that describes

how the keys are exchanged between sender and receiver.

AUTHENTICATION HEADER

Authentication Header (AH) is used to provide integrity and authentication to

IP datagrams. Replay protection is also possible. The services are
connectionless, that means they work on a per-packet basis.

AH is used in two modes as follows −

 Transport mode
 Tunnel mode

AH authenticates are the same as IP datagram. In transport mode, some fields

in the IP header change en-route and their value cannot be predicted by the
receiver. These fields are called mutable and they are not protected by AH.

Mutable IPv4 fields

The mutable IPv4 fields are as follows −

 Type of service (TOS)

 Flags
 Fragment offset

10
  Time to live (TTL)
 Header checksum

To protect these fields, tunnelling must be used. The payload of the IP packet
is considered immutable and is always protected by AH.

 AH processing is applied only to non-fragmented IP packets. Whereas an

IP packet with AH applied can be fragmented by intermediate routers.
 In this case, the destination first reassembles the packet and then
applies AH processing to it.
 If an IP packet that appears to be a fragment is input to AH processing,
and it is discarded.
 This prevents the overlapping fragment attack, which misuses the
fragment reassembly algorithm to create forged packets and force them
through a firewall.
 Packets that fail authentication are discarded and never delivered to
upper layers.
 This mode of operation greatly reduces the chances of successful denial-
of-service attacks.

AH format

The AH format is described in RFC 2402. The below shows the position of the
Authentication Header fields in the IP packet.

The fields are as follows −

Next header
It is an 8-bit field which identifies the type of what follows. The value of this
field is chosen from the set of IP header protocol fields, which is set to 51, and
the value that would have gone in the protocol field goes in the AH next header
field.

11
Payload length
It is an 8 bits long field and contains the length of the AH header expressed in
32-bit words, minus 2. It does not relate to the actual payload length of the IP
packet. Suppose if default options are used, the value is 4 (three 32-bit fixed
words plus three 32-bit words of authentication data minus two).
Reserved
It is reserved for future use. Its length is 16 bits and it is set to zero.
Security parameter index (SPI)
It is 32 bits in length.
Sequence number
This 32-bit field is a monotonically increasing counter, which is used for replay
protection. It is an optional field. The sender always includes this field, and it is
at the discretion of the receiver to process it or not. Starting the sequence
number is initialized to zero. The first packet transmitted using the SA has a
sequence number of 1. Sequence numbers are not allowed to repeat.
Authentication data
This is a variable-length field containing the Integrity Check Value (ICV), and is
padded to 32 bits for IPv4 or 64 bits for IPv6.

ENCAPSULATING SECURITY PAYLOAD (ESP)

ESP can be used to provide confidentiality, data origin authentication,

connection- less 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 (SA)
establishment and on the location of the implementation in a network topology.

ESP Format

Figure 19.5a shows the top-level format of an ESP packet. It contains the
following fields.

 Security Parameters Index (32 bits): Identifies a security association.

 Sequence Number (32 bits): A monotonically increasing counter value;
this provides an anti-replay function, as discussed for AH.
 Payload Data (variable): This is a transport-level segment (transport
mode) or IP packet (tunnel mode) that is protected by encryption.
 Pad Length (8 bits): Indicates the number of pad bytes immediately
preceding this field.
 Next Header (8 bits): Identifies the type of data contained in the
payload data field by identifying the first header in that payload (for
example, an extension header in IPv6, or an upper-layer protocol such as
TCP).

12
  Integrity Check Value (variable): A variable-length field (must be an
integral number of 32-bit words) that contains the Integrity Check Value
computed over the ESP packet minus the Authentication Data field.

When any combined mode algorithm is employed, the algorithm itself is

expected to return both decrypted plaintext and a pass/fail indication for the
integrity check.

Padding

The Padding field serves several purposes:

If an encryption algorithm requires the plaintext to be a multiple of som number

of bytes (e.g., the multiple of a single block for a block cipher), the Padding
field is used to expand the plaintext (consisting of the Payload Data, Padding,
Pad Length, and Next Header fields) to the required length.

13
Anti-Replay Service

A replay attack is one in which an attacker obtains a copy of an authenticated

packet and later transmits it to the intended destination. The receipt of
duplicate, authenticated IP packets may disrupt service in some way or may
have some other undesired consequence. The Sequence Number field is
designed to thwart such attacks. First, we discuss sequence number generation
by the sender, and then we look at how it is processed by the recipient.

Transport and Tunnel Modes

Figure 19.7 shows two ways in which the IPsec ESP service can be used. In the
upper part of the figure, encryption (and optionally authentication) is provided
directly between two hosts. Figure 19.7b shows how tunnel mode operation can
be used to set up a virtual private network.

In this example, an organization has four private networks interconnected

across the Internet. Hosts on the internal networks use the Internet for
transport of data but do not interact with other Internet-based hosts. By
terminating the tunnels at the security gateway to each internal network, the

14
configuration allows the hosts to avoid implementing the security capability. The
former technique is supported by a transport mode SA, while the latter
technique uses a tunnel mode SA.

COMBINING SECURITY ASSOCIATIONS

An individual SA can implement either the AH or ESP protocol but not both.
Sometimes a particular traffic flow will call for the services provided by both
AH and ESP.

Security associations may be combined into bundles in two ways:

• Transport adjacency: Refers to applying more than one security protocol to

the same IP packet without invoking tunneling. This approach to combining AH
and ESP allows for only one level of combination; further nesting yields no added
benefit since the processing is performed at one IPsec instance: the (ultimate)
destination.

• Iterated tunneling: Refers to the application of multiple layers of security

protocols effected through IP tunneling. This approach allows for multiple levels
of nesting, since each tunnel can originate or terminate at a different IPsec site
along the path.

15
The two approaches can be combined, for example, by having a transport SA
between hosts travel part of the way through a tunnel SA between security
gateways.

Basic Combinations of Security Associations

The IPsec Architecture document lists four examples of combinations of SAs

that must be supported by compliant IPsec hosts (e.g., workstation, server) or
security gateways (e.g. firewall, router). These are illustrated in Figure 19.10.

16
The lower part of each case in the figure represents the physical connectivity
of the elements; the upper part represents logical connectivity via one or more
nested SAs. Each SA can be either AH or ESP. For host-to-host SAs, the mode
may be either transport or tunnel; otherwise it must be tunnel mode.

Case 1. All security is provided between end systems that implement IPsec. For
any two end systems to communicate via an SA, they must share the appropriate
secret keys.

Case 2. Security is provided only between gateways (routers, firewalls, etc.)

and no hosts implement IPsec. This case illustrates simple virtual private
network support.

Case 3. This builds on case 2 by adding end-to-end security. The same

combinations discussed for cases 1 and 2 are allowed here. The gateway-to-
gateway tunnel provides either authentication, confidentiality, or both for all
traffic between end systems.

Case 4. This provides support for a remote host that uses the Internet to
reach an organization’s firewall and then to gain access to some server or
workstation behind the firewall.

KEY MANAGEMENT

The key management portion of IPsec involves the determination and

distribution of secret keys. A typical requirement is four keys for

17
communication between two applications: transmit and receive pairs for both
integrity and confidentiality. 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 systems. This is practical for
small, relatively static environments.

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

The default automated key management protocol for IPsec is referred to as

ISAKMP/Oakley and consists of the following elements:

• Oakley Key Determination Protocol: Oakley is a key exchange protocol based

on the Diffie-Hellman algorithm but providing added security. Oakley is generic
in that it does not dictate specific formats.

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

FEATURES OF IKE KEY DETERMINATION The IKE key determination

algorithm ischaracterized by five important features:

1. It employs a mechanism known as cookies to thwart clogging attacks.

2. It enables the two parties to negotiate a group; this, in essence, specifies the
global parameters of the Diffie-Hellman key exchange.
3. It uses nonces to ensure against replay attacks.
4. It enables the exchange of Diffie-Hellman public key values.
5. It authenticates the Diffie-Hellman exchange to thwart man-in-the-middle
attacks.
Header and Payload Formats
IKE defines procedures and packet formats to establish, negotiate, modify, and
delete security associations. As part of SA establishment, IKE defines payloads
for exchanging key generation and authentication data. These payload formats
provide a consistent framework independent of the specific key exchange
protocol, encryption algorithm, and authentication mechanism.

It consists of the following fields.

 Initiator SPI (64 bits): A value chosen by the initiator to identify a
unique IKE security association (SA).

18
  Responder SPI (64 bits): A value chosen by the responder to identify a
unique IKE SA.
 Next Payload (8 bits): Indicates the type of the first payload in the
message; payloads are discussed in the next subsection.
 Major Version (4 bits): Indicates major version of IKE in use.
 Minor Version (4 bits): Indicates minor version in use.

Exchange Type (8 bits): Indicates the type of exchange; these are discussed
later in this section.

• Flags (8 bits): Indicates specific options set for this IKE exchange. Three
bits are defined so far. The initiator bit indicates whether this packet is sent
by the SA initiator. The version bit indicates whether the transmitter is
capable of using a higher major version number than the one currently indicated.
The response bit indicates whether this is a response to a message containing
the same message ID.

• Message ID (32 bits): Used to control retransmission of lost packets and

matching of requests and responses.

• Length (32 bits): Length of total message (header plus all payloads) in octets

19