MODULE 5

Network security: Electronic Mail Security: Pretty good privacy- S/MIME. IP

Security: Architecture- authentication Header- Encapsulating Security payload-

Combining Security associations- Key management.

Topics to learn:
Network security: Electronic Mail Security:

 Pretty good privacy

o notations:
o services
o transmission and reception of pgp messages
 S/MIME
o Description
o E-mail History
 SMTP
 MIME (Multipurpose Internet Mail Extensions)
o S/MIME: SECURE MIME
 S/MIME Functions
 S/MIME Security Functionality: Simplified View
 S/MIME content types
 S/MIME certificate processing
 IP SECURITY
o Description
o applications of ipsec
o an ip security scenario
o benefits of ipsec
o IP SECURITY ARCHITECTURE
 SECURITY ASSOCIATION DATABASE (SAD)
 SECURITY POLICY DATABASE(SPD)
o IPSec services
o transport and tunnel modes
 AUTHENTICATION HEADER (AH)
o Description
o transport and tunnel mode
 ENCAPSULATING SECURITY PAYLOAD (ESP)
o Description
o encryption & authentication algorithms & padding
o transport mode and tunnel mode
 COMBINING SECURITY ASSOCIATIONS
o 4 different cases
  IPSec key management
o Oakley
o ISAKMP

NETWORK SECURITY: ELECTRONIC MAIL SECURITY

PGP
Zimmermann developed PGP (Pretty Good Privacy) in the late 1980’s and early 1990’s.

Some characteristics include:

 Uses the best available cryptographic algorithms as building blocks.

 Integrates these into a general-purpose algorithm that is processor-independent and easy to use.

 Package and documentation, including source code, are freely available on-line.

 PGP is now provided by Viacrypt in a compatible, low-cost commercial version.

 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

 PGP supplies FOUR basic services:

 Authentication

 Confidentiality

 Compression
  Email compatibility

 AUTHENTICATION

 This is a digital signature function.

 Sender creates a message M.

 Sender generates a hash of M.

 Sender signs the hash using his private key and prepends the result to the
message.

 Receiver uses the sender’s public key to verify the signature and recover the
hash code.

 Receiver generates a new hash code for M and compares it with the decrypted
hash code.

 CONFIDENTIALITY

 PGP provides encryption for messages sent or stored as files.

 Sender generates a message M and a random session key K.

 M is encrypted using key K.

 K is encrypted using the recipient’s public key, and prepended to the message.

 Receiver uses his private key to recover the session key.

 The session key is used to decrypt the message.

 CONFIDENTIALITY & AUTHENTICATION

 can use both services on same message

 create signature & attach to message

 encrypt both message & signature

 attach RSA/ElGamal encrypted session key

1. Apply the authentication step to the original message.

2. Apply the confidentiality step to the resulting message.

 COMPRESSION

 by default PGP compresses message after signing but before encrypting

 so can store uncompressed message & signature for later

verification

 because compression is non deterministic (result of compression

depends upon user preferences)

 uses ZIP compression algorithm

 EMAIL COMPATIBILITY

 when using PGP will have binary data to send (encrypted message etc.)

 however email was designed only for text

 hence PGP must encode raw binary data into printable ASCII characters

 uses radix-64 algorithm (aka "ASCII Armour")

 maps 3 bytes to 4 printable chars (it's the Base64 of MIME)

 also appends a 24-bit CRC

 PGP also segments messages if too big

 Summary of PGP Services

  Transmission and Reception of PGP Messages

(a) Generic transmission diagram (from A) (b) Generic reception diagram (to B)

S/MIME
• Secure/Multipurpose Internet Mail Extensions

• S/MIME is security enhancement to the MIME Internet e-mail format standard.

• A standard way for email encryption and signing

• S/MIME will emerge as the industry standard for commercial and organizational use,
while PGP remains for personal e-mail security for many users.

 E-mail History

 SMTP and RFC 822 (later RFC 5322)

o SMTP is the email transfer protocol running over TCP

o RFC 822/5322 defines the message format and headers

  only ASCII messages (7-bit)

o SMTP cannot transmit executable files.

o SMTP cannot transmit text data that includes national language

characteristics

o SMTP servers may reject mail message over a certain size

 MIME (Multipurpose Internet Mail Extensions)

o Addresses the limitations of SMTP/5322 scheme

o Five header fields defined

o MIME version

 Field that indicates message conforms to RFC 2015 and

2046

o content type

 Almost any type of information can appear in an email

message

o Content transfer encoding

 specifies how the message body is encoded into textual

form

o Content-ID

 Used to identify MIME entities uniquely in multiple

contexts.

o Content-description

 A text description of the object with the body this is useful

when the object is not readable(eg: audio data)

• MIME Content Types

 MIME Transfer Encodings

The objective is to provide reliable delivery across the largest range of environments.

S/MIME: SECURE MIME

• new content types, like signature, encrypted data

• S/MIME Functions

• enveloped data

• Consists of encrypted content and associated encrypted keys

 • signed data

• Digital signature is formed by taking message digest of the content and

encrypting that with the private key of the signer.

• i.e; encoded message + encoded signed message digest

• clear-signed data

• cleartext message + encoded signed message digest

• Recipients without S/MIME capability can view the message but cannot
verify the signature.

• signed and enveloped data

• Encrypted data may be signed and signed data or clear signed data may
be encrypted.

• Nested signed and encrypted entities

• S/MIME Security Functionality: Simplified View

 S/MIME CONTENT TYPES

1. ENVELOPED DATA

Steps for preparing an enveloped data MIME entity are:

1. Generate a pseudorandom session key for a particular symmetric encryption algorithm

2. For each recipient, encrypt the session key with the recipient’s public RSA key.

3. For each recipient, prepare a block known as RecipientInfo that contains an identifier of
the recipient’s public-key certificate, an identifier of the algorithm used to encrypt the
session key, and the encrypted session key.

4. Encrypt the message content with the session key.

Content-Type:application/pkcs7-mime;smime-type=envelopeddata;
name=smime.p7m

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=smime.p7m

• To recover the encrypted message, the recipient first strips off the base64
encoding.Then the recipient’s private key is used to recover the session key.Finally, the
message content is decrypted with the session key.

2. SIGNED DATA

• The signedData smime-type can be used with one or more signers.

• .The steps for preparing a signedData MIME entity are

1. Select a message digest algorithm (SHA or MD5).

2. Compute the message digest (hash function) of the content to be signed.

3. Encrypt the message digest with the signer’s private key.

4. Prepare a block known as SignerInfo that contains the signer’s publickey

certificate,an identifier of the message digest algorithm, an identifier of the
algorithm used to encrypt the message digest, and the encrypted message
digest.

Content-Type:application/pkcs7-mime;smime-type=signeddata;
name=smime.p7m

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=smime.p7m

• To recover the signed message and verify the signature, the recipient first strips off the
base64 encoding.Then the signer’s public key is used to decrypt the message
digest.The recipient independently computes the message digest and compares it to the
decrypted message digest to verify the signature

3. CLEAR SIGNING

• Clear signing is achieved using the multipart content type with a signed subtype

• A multipart/signed message has two parts.

• The first part can be any MIME type but must be prepared so that it will not be altered
during transfer from source to destination.

• The second part has a MIME content type of application and a subtype of pkcs7-
signature

Content-Type: multipart/signed;

protocol="application/pkcs7-signature";

micalg=sha1; boundary=boundary42

—boundary42

Content-Type: text/plain

This is a clear-signed message.

—boundary42

Content-Type: application/pkcs7-signature; name=smime.p7s

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=smime.p7s

• The protocol parameter indicates that this is a two-part clear-signed entity. The micalg
parameter indicates the type of message digest used. The receiver can verify the
signature by taking the message digest of the first part and comparing this to the
message digest recovered from the signature in the second part.

4. REGISTRATION REQUEST

• The certification request includes certification RequestInfo block, followed by an identifier

of the public-key encryption algorithm, followed by the signature of the
certificationRequestInfo block made using the sender’s private key.
 • The certificationRequestInfo block includes a name of the certificate subject (the entity
whose public key is to be certified) and a bit-string representation of the user’s public
key.

5. CERTIFICATES-ONLY MESSAGE

• The steps involved are the same as those for creating a signedData message, except
that there is no message content and the signerInfo field is empty.

S/MIME CERTIFICATE PROCESSING

Key management functions are:

1. Key generation: the user of some related administrative utility must be able of
generating separate Diffie-Hellman and DSS key pairs and should be capable of
generating RSA key pairs

2. Registration: A user’s public key must be registered with a certification authority in

order to receive an X509 public key certificate

3. Certificate storage and retrieval: A user requires access to a local list of certificates
in order to verify incoming signature and to encrypt outgoing messages

IP SECURITY
• In CERTs(Computer emergency response team) 2001 annual report it listed 52,000
security incidents

• the most serious involving:

 IP spoofing

 intruders creating packets with false address then taking advantages of

OS exploits

 eavesdropping and sniffing

 attackers listen for userids and passwords and then just walk into target
systems

 as a result the IAB(Internet architecture Board) included authentication and

encryption in the next generation IP (IPv6)

• The Internet community has developed application-specific security mechanisms in a

number of application areas, including electronic mail (S/MIME, PGP), client/server
(Kerberos), Web access (Secure Sockets Layer), and others.

• users have some security concerns that cut across protocol layers.
 • By implementing security at the IP level, an organization can ensure secure networking
not only for applications that have security mechanisms but also for the many security-
ignorant applications.

• general IP Security mechanisms

• provides

• authentication

• confidentiality

• key management

APPLICATIONS OF IPSec

• Provides the capability to secure communications across a LANs, across public &
private WANs, & across the Internet

• Examples of its use includes:

• Secure branch office connectivity over the internet

• Secure remote access over the internet

• Establishing extranet and intranet connectivity with partners

• Enhancing electronic mail security

An IP security Scenario

An organization maintains LANs at dispersed locations. Nonsecure IP traffic is conducted on

each LAN. For traffic offsite, through some sort of private or public WAN, IPSec protocols are
used. These protocols operate in networking devices, such as a router or firewall, that connect
each LAN to the outside world. The IPSec networking device will typically encrypt and compress
all traffic going into the WAN, and decrypt and decompress traffic coming from the WAN; these
operations are transparent to workstations and servers on the LAN. Secure transmission is also
possible with individual users who dial into the WAN. Such user workstations must implement
the IPSec protocols to provide security.
BENEFITS OF IPSec

Some of the benefits of IPSec include:

 IPSec is implemented in a firewall/router provides strong security to all traffic crossing

the perimeter

 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.
There is no need to change software on a user or server system when IPsec is
implemented in the firewall or router

 can be transparent to end users. There is no need to train users on security

mechanisms, issue keying material on a per-user basis, or revoke keying material when
users leave the organization

 can provide security for individual users. This is useful for offsite workers and for setting
up a secure virtual subnetwork within an organization for sensitive applications.

 It also plays a vital role in the routing architecture required for internetworking.

 assure that router advertisments come from authorized routers

 neighbor advertisments come from authorized routers

 insure redirect messages come from the router to which initial packet was sent

 insure no forging of router updates

IP SECURITY ARCHITECTURE
  The IPSec specification consists of numerous documents

 The documents are divided into seven groups

1. Architecture: Covers the general concepts, security requirements, definitions,

and mechanisms defining IPsec technology,

2. Authentication Header (AH): Covers the packet format and general issues
related to the use of the AH for packet authentication.

3. Encapsulating Security Payload (ESP): Covers the packet format and general
issues related to the use of the ESP for packet encryption and optionally
authentication.

4. Encryption Algorithm: A set of documents that describe how various encryption

algorithm are used.

5. Authentication Algorithm: A set of documents that describe how various

authentication algorithms are used for AH and for authentication option of ESP.

6. Key management: Documents that describe key management schemes

7. Domain of Interpretation(DOI): Contains values needed for other documents to

relate to each other. Includes identifiers for approved encryption and
authentication algorithms

A security association is uniquely identified by three parameters.

• Security Parameters Index (SPI): A bit string assigned to this SA and having local
significance only. The SPI is carried in AH and ESP headers to enable the receiving system to
select the SA under which a received packet will be processed.

• IP Destination Address: This is the address of the destination endpoint of the SA,which may
be an end-user system or a network system such as a firewall or router.

• Security Protocol Identifier: This field from the outer IP header indicates whether the
association is an AH or ESP security association. Hence, in any IP packet, the security
association is uniquely identified by the Destination Address in the IPv4 or IPv6 header and the
SPI in the enclosed extension header (AH or ESP).

SECURITY ASSOCIATION DATABASE (SAD)

 Security Parameter Index: A 32-bit value selected by the receiving end of an SA to

uniquely identify the SA.

 Sequence Number Counter: A 32-bit value used to generate the Sequence Number
field in AH or ESP required for all implementations).

 Sequence Counter Overflow: A flag indicating whether overflow of the Sequence

Number Counter should generate an auditable event and prevent further transmission of
packets on this SA (required for all implementations).

 Anti-Replay Window: Used to determine whether an inbound AH or ESP packet is a

replay

 AH Information: Authentication algorithm, keys, key lifetimes, and related parameters

being used with AH (required for AH implementations).

 ESP Information: Encryption and authentication algorithm, keys, initialization values,

key lifetimes, and related parameters being used with ESP (required for ESP
implementations).

 Lifetime of this Security Association: A time interval or byte count after which an SA
must be replaced with a new SA (and new SPI) or terminated, plus an indication of
which of these actions should occur (required for all implementations).

 IPsec Protocol Mode: Tunnel,transport,or wildcard.

 Path MTU: Any observed path maximum transmission unit (maximum size of a packet
that can be transmitted without fragmentation) and aging variables (required for all
implementations).

SECURITY POLICY DATABASE

The following selectors determine an SPD entry:

 Remote IP Address: This may be a single IP address, an enumerated list or range of

addresses, or a wildcard (mask)

 Local IP Address: This may be a single IP address, an enumerated list or range of

addresses, or a wildcard (mask)

 Next Layer Protocol: The IP protocol header (IPv4,IPv6,or IPv6 Extension) includes a
field (Protocol for IPv4, Next Header for IPv6 or IPv6 Extension) that designates the
protocol operating over IP.
  Name: A user identifier from the operating system. This is not a field in the IP or upper-
layer headers but is available if IPsec is running on the same operating system as the
user.

 Local and Remote Ports: These may be individual TCP or UDP port values, an
enumerated list of ports,or a wildcard port.

IPSec SERVICES

 Two protocols are used to provide security:

 Authentication Header Protocol (AH)

 Encapsulation Security Payload (ESP)

 Services provided are:

 Access control

 Connectionless integrity

 Data origin authentication

 Rejection of replayed packets

o a form of partial sequence integrity

 Confidentiality (encryption)

 Limited traffic flow confidentiality

TRANSPORT AND TUNNEL MODES

 Transport Mode

 to encrypt & optionally authenticate IP data

 can do traffic analysis but is efficient

 good for ESP host to host traffic

 Tunnel Mode

 encrypts entire IP packet

 add new header for next hop

 no routers on way can examine inner IP header

 good for VPNs, gateway to gateway security

 Transport and Tunnel Modes

1. AUTHENTICATION HEADER (AH)

 provides support for data integrity & authentication of IP packets

 end system/router can authenticate user/app

 prevents address spoofing attacks by tracking sequence numbers

 based on use of a MAC (message authentication code)

 parties must share a secret key

Fields included in Authentication Header are:

 Next Header(8 bits): Identifies the type of header immediately following this header.

 Payload length(8 bits): Length of the Authentication header.

 Reserved(16 bits): For future use

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

 Sequence Number(32 bits): An increasing counter value.

 Authentication Data(variable): A variable length field that contains the MAC for this
packet.

TRANSPORT AND TUNNEL MODE

• transport mode is used to encrypt & optionally authenticate IP data

• data protected but header left in clear

• can do traffic analysis but is efficient

• good for ESP host to host traffic

• tunnel mode encrypts entire IP packet

• add new header for next hop

• good for VPNs, gateway to gateway security

For transport mode AH using IPv4, the AH is inserted after the original IP header and before the
IP payload (e.g., a TCP segment); Authentication covers the entire packet, excluding mutable
fields in the IPv4 header that are set to zero for MAC calculation.

In the context of IPv6, AH is viewed as an end-to-end payload; that is, it is not examined or
processed by intermediate routers. Therefore, the AH appears after the IPv6 base header and
the hop-by-hop, routing, and fragment extension headers.
• For tunnel mode AH, the entire original IP packet is authenticated, and the AH is
inserted between the original IP header and a new outer IP header (Figure 1.6c). The
inner IP header carries the ultimate source and destination addresses, while an outer IP
header may contain different IP addresses (e.g., addresses of firewalls or other security
gateways).

• The outer IP header (and in the case of IPv6, the outer IP extension headers) is
protected except for mutable and unpredictable fields.

2. ENCAPSULATING SECURITY PAYLOAD (ESP)

 provides message content confidentiality & limited traffic flow confidentiality

 can optionally provide the same authentication services as AH

 supports range of ciphers, modes, padding

 incl. DES, Triple-DES, RC5, IDEA, CAST etc

 Figure shows the format of an ESP packet, with 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

• Payload Data (variable): This is a transport-level segment (transport mode) or IP

packet (tunnel mode) that is protected by encryption

• Padding (0–255 bytes): for various reasons

• Pad Length (8 bits): the number of pad bytes immediately preceding this field

• Next Header (8 bits): identifies the type of data in the payload data field

• Integrity check value (variable): a variable-length field that contains the Integrity
Check Value computed over the ESP packet

ENCRYPTION & AUTHENTICATION ALGORITHMS & PADDING

• ESP can encrypt payload data, padding, pad length, and next header fields

• if needed have IV at start of payload data

• ESP can have optional ICV for integrity

• is computed after encryption is performed

• ESP uses padding

• to expand plaintext to required length

• to align pad length and next header fields

 • to provide partial traffic flow confidentiality

TRANSPORT MODE AND TUNNEL MODE

TRANSPORT MODE

• Transport mode ESP is used to encrypt and optionally authenticate the data carried by
IP

• Using IPv4,the ESP header is inserted into the IP packet immediately prior to the
transport-layer header (e.g., TCP, UDP, ICMP), and an ESP trailer (Padding, Pad
Length, and Next Header fields) is placed after the IP packet.

• In the context of IPv6,ESP is viewed as an end-to-end payload;that is,it is not examined

or processed by intermediate routers.Therefore,the ESP header appears after the IPv6
base header and the hop-by-hop, routing, and fragment extension headers.

TUNNEL MODE
 • Tunnel mode ESP is used to encrypt an entire IP packet (Figure 19.8c). For this mode,
the ESP header is prefixed to the packet and then the packet plus the ESP trailer is
encrypted.This method can be used to counter traffic analysis.

COMBINING SECURITY ASSOCIATIONS

• SA’s(Security assosciations) can implement either AH or ESP

• to implement both need to combine SA’s

• form a security association bundle

• may terminate at different or same endpoints

• combined by

• transport adjacency

• iterated tunneling

• combining authentication & encryption

• ESP with authentication, bundled inner ESP & outer AH, bundled inner transport
& outer ESP

Combining Security Associations

a. AH in transport mode
b.ESP in transport mode

c. AH followed by ESP in transport mode(ESP SA inside an AH SA)

d. any one a, b, c inside an AH or ESP in tunnel mode

• The IPSec Architecture document lists four examples of combinations of SAs that must
be supported by compliant IPSec hosts or security gateways.

• 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 security is provided between end systems that implement IPSec, who share suitable
keys, using AH tunnel, ESP transport, ESP + AH transport, any of above inside AH/ESP tunnel;
to support authentication, encryption, authentication before encryption, and authentication after
encryption.

Case 2 security is provided only between gateways (routers, firewalls,etc.) and no hosts
implement IPSec, a simple VPN using a single AH or ESP tunnel SA

Case 3 builds on Case 2 by adding end-to-end security .The same combinations discussed for
cases 1 and 2 are allowed here.

Case 4 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. Only tunnel
mode is required between the remote host and the firewall..

IPSec KEY MANAGEMENT

• handles key generation & distribution

• typically need 2 pairs of keys

• 2 per direction for AH & ESP

• manual key management

• sysadmin manually configures every system

• automated key management

• automated system for on demand creation of keys for SA’s in large systems

• has Oakley & ISAKMP elements

• Oakley

• a key exchange protocol

 • based on Diffie-Hellman key exchange

• adds features to address weaknesses

• no info on parties, man-in-middle attack, cost

• so adds cookies, groups (global params), nonces, DH key exchange with

authentication

• can use arithmetic in prime fields or elliptic curve fields

• ISAKMP

• Internet Security Association and Key Management Protocol

• provides framework for key management

• defines procedures and packet formats to establish, negotiate, modify, & delete
SAs

• independent of key exchange protocol, encryption alg, & authentication method

• IKEv2 no longer uses Oakley & ISAKMP terms, but basic functionality is same

Initiator SPI (64 bits): chosen by the initiator to identify a unique SA

• Responder Cookie (64 bits): chosen by responder to identify unique IKE SA

• Next Payload (8 bits): type of the first payload in the message.

• Major/Minor Version (4 bits): Indicates major/minor version of IKE in use

• Exchange Type (8 bits): type of exchange.

• Flags (8 bits): specific options set for this IKE exchange.

• Message ID (32 bits): control retransmission, matching of requests /responses.

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

All ISAKMP payloads begin with the same generic payload .The Next Payload field has a value
of 0 if this is the last payload in the message; otherwise its value is the type of the next payload.
The Payload Length field indicates the length in octets of this payload, including the generic
payload header. The critical bit is zero if the sender wants the recipient to skip this payload if it
does not understand the payload type code in the Next Payload field of the previous payload. It
is set to one if the sender wants the recipient to reject this entire message if it does not
understand the payload type.

IKE Payloads & Exchanges

• have a number of ISAKMP payload types:

• Security Association, Key Exchange, Identification, Certificate, Certificate

Request, Authentication, Nonce, Notify, Delete, Vendor ID, Traffic Selector,
Encrypted, Configuration, Extensible Authentication Protocol

• payload has complex hierarchical structure

• may contain multiple proposals, with multiple protocols & multiple transforms