Unit-5

Email Security and IP

Security
BY
Dr. Janardhana D R
Assistant Professor, Dept. of CSE, NMIT
 S/MIME
• Secure/Multipurpose Internet Mail Extension (S/MIME) is a security enhancement to the
MIME Internet e-mail format standard.
• S/MIME is based on technology from RSA Data Security and is on an IETF standards track.
• S/MIME is likely to be the industry standard for commercial and organizational use, while
PGP remains popular for personal e-mail security.
• S/MIME is defined in important documents such as RFCs 3370, 3850, 3851, and 3852.
• Understanding S/MIME requires a general understanding of the underlying e-mail format,
MIME.
• MIME builds upon the traditional e-mail format standard, RFC 822, which is still widely
used.
• The most recent version of the e-mail format specification is RFC 5322 (Internet Message
Format).
 Multipurpose Internet Mail Extensions
• SMTP cannot transmit executable files or binary objects directly.

• Various schemes are used to convert binary files into text for SMTP transmission, such as
UNIX UUencode/UUdecode, but none are standard.

• SMTP cannot handle text data with 8-bit codes above 127, limiting it to 7-bit ASCII.

• SMTP servers may reject emails over a certain size.

• SMTP gateways translating between ASCII and EBCDIC may have inconsistent mappings.

• SMTP gateways to X.400 mail networks may struggle with nontextual X.400 message data.

• Some SMTP implementations have limitations or issues.

Some SMTP implementations do not adhere completely to the SMTP standards
defined in RFC 821. Common problems include:

• Deletion, addition, or reordering of carriage return and linefeed

• Truncating or wrapping lines longer than 76 characters

• Removal of trailing white space (tab and space characters)

• Padding of lines in a message to the same length

• Conversion of tab characters into multiple space characters

The MIME specification includes the following elements.
• Five new message header fields are defined for inclusion in an RFC 5322 header, offering
details about the message body.
• Content formats are specified to standardize representations supporting multimedia email.
• Defined transfer encodings facilitate the conversion of content formats into secure forms
resistant to alteration by mail systems.
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).
S/MIME provides the following functions.

• Enveloped data: This consists of encrypted content of any type and encrypted content
encryption keys for one or more recipients.

• Signed data: A digital signature is formed by taking the message digest of the content to be
signed and then encrypting that with the private key of the signer. The content plus signature
are then encoded using base64 encoding. A signed data message can only be viewed by a
recipient with S/MIME capability.

• Clear-signed data: As with signed data, a digital signature of the content is formed. However,
in this case, only the digital signature is encoded using base64. As a result, recipients without
S/MIME capability can view the message content, although they cannot verify the signature.
• Signed and enveloped data: Signed-only and encrypted-only entities may be
nested, so that encrypted data may be signed and signed data or clear-signed data
may be encrypted.
•Strong security for all traffic at the perimeter when IPsec is implemented in a
firewall or router.
•No processing overhead for traffic within a company or workgroup.
•Resistant to bypass if all external traffic must use IP and the firewall is the only
entrance from the Internet
•Transparent to applications as it operates below the transport layer (TCP, UDP)
•No need to change software on user or server systems when implementing IPsec in
a firewall or router
•End-user transparency, no need to train users on security mechanisms or issue
keying material per user
• Organization maintains LANs at dispersed locations with nonsecure IP traffic

• IPsec protocols used for offsite traffic via private or public WAN

• IPsec protocols operate in networking devices like routers or firewalls connecting LANs to
the outside

• IPsec device encrypts/compresses outbound traffic, decrypts/decompresses inbound traffic

• Operations transparent to workstations and servers on LAN

• Secure transmission for individual users dialling into WAN

• User workstations must implement IPsec protocols for security

Applications of IPsec
• Secure branch office connectivity over the Internet:
• Build a secure virtual private network over the Internet or public WAN
• Reduces the need for private networks, saving costs and management overhead
• Secure remote access over the Internet:
• End users with IP security protocols can access company network securely
• Reduces toll charges for traveling employees and telecommuters
• Establishing extranet and intranet connectivity with partners:
• Use IPsec to secure communication with other organizations
• Ensures authentication, confidentiality, and provides key exchange mechanism
• Enhancing electronic commerce security:
• IPsec enhances security for Web and e-commerce applications
• Encrypts and authenticates designated traffic, adding an extra layer of security
Benefits of IPsec
• IPsec in firewall or router provides strong security for all traffic at the perimeter.

• No security-related processing overhead for internal company/workgroup traffic.

• IPsec in firewall is resistant to bypass if all external traffic must use IP via the firewall.

• Transparent to applications as it is below the transport layer (TCP, UDP).

• No need to change software on user/server systems when IPsec is implemented.

• Implementation in end systems does not affect upper-layer software including applications.

• Transparent to end users, no need to train on security mechanisms or issue keying material per
user.
• Can provide security for individual users, useful for offsite workers or setting up a secure
virtual subnetwork for sensitive applications
Routing Applications
• A router advertisement (a new router advertises its presence) comes from an authorized
router.

• A neighbor advertisement (a router seeks to establish or maintain a neighbor 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 Documents
IPsec encompasses three functional areas: authentication, confidentiality, and key
management.
• Architecture: General concepts, security requirements, definitions, and mechanisms of
IPsec technology
• Current specification: RFC 4301, Security Architecture for the Internet Protocol
• Authentication Header (AH): Provides message authentication (Deprecated in favor of
ESP)
• Current specification: RFC 4302, IP Authentication Header
• Encapsulating Security Payload (ESP): Provides encryption or combined
encryption/authentication
• Current specification: RFC 4303, IP Encapsulating Security Payload (ESP)
• Internet Key Exchange (IKE): Describes key management schemes for IPsec
• Main specification: RFC 5996, Internet Key Exchange (IKEv2) Protocol
• Various related RFCs available
IPsec Services
• IPsec provides security services at the IP layer
• Enables system to select required security protocols and algorithms
• Puts in place cryptographic keys for the requested services
• Uses two protocols for security:
• Authentication Header (AH) for authentication
• Combined encryption/authentication protocol for encryption and authentication
• Encapsulating Security Payload (ESP). RFC 4301 lists the following services:
• • Access control
• • Connectionless integrity
• • Data origin authentication
• • Rejection of replayed packets (a form of partial sequence integrity)
• • Confidentiality (encryption)
• • Limited traffic flow confidentiality
Transport and Tunnel Modes
Both AH and ESP support two modes of use: transport and tunnel mode.
Transport Mode:
• Transport mode protects upper-layer protocols by extending to the payload of an IP packet
• Examples include TCP, UDP, or ICMP packets operating above IP in the protocol stack
• Used for end-to-end communication between two hosts (e.g., client-server or workstations)
• When AH or ESP is used over IPv4, the payload includes data after the IP header
• For IPv6, the payload includes data after the IP header and any IPv6 extension headers
• ESP in transport mode encrypts and optionally authenticates the IP payload, excluding the
IP header
• AH in transport mode authenticates the IP payload and selected portions of the IP header
Tunnel Mode:
• Tunnel mode provides protection to the entire IP packet
• After adding AH or ESP fields to the IP packet, the entire packet with security fields
becomes the payload of a new outer IP packet with a new outer IP header
• The original, inner packet travels through a tunnel in an IP network from one point to
another without routers examining the inner IP header
• Encapsulation of the original packet allows for different source and destination addresses,
enhancing security
• Used when one or both ends of a security association (SA) are a security gateway like a
firewall or router implementing IPsec
• Allows multiple hosts behind firewalls to communicate securely without implementing
IPsec individually
• Unprotected packets from such hosts are tunneled through external networks via tunnel
mode SAs set up by IPsec software in the firewall or secure router at the network
boundary.
IP Security Policy
• Fundamental to IPsec operation is the concept of a security policy for each IP packet
from source to destination
• IPsec policy is defined through the interaction of two databases:
• Security Association Database (SAD)
• Security Policy Database (SPD)
Security Association (SA): A one-way logical connection between a sender and receiver
providing security services to the traffic.

• Two SAs are needed for two-way secure exchange

• Security Association uniquely identified by three parameters:

• Security Parameters Index (SPI): A 32-bit integer for local significance, carried in AH and
ESP headers to select the SA for processing received packets
• IP Destination Address: Address of the destination endpoint of the SA

• Security Protocol Identifier: Indicates if the association is AH or ESP in the outer IP

header

• In an IP packet, the SA is uniquely identified by the Destination Address in the IPv4 or IPv6
header and the SPI in the enclosed AH or ESP extension header.
Security Association Database:
• Security Parameter Index (SPI): 32-bit value selected by the receiving end of an SA to
uniquely identify the SA; used to construct AH or ESP header in outbound SA's SAD entry and
map traffic to appropriate SA in inbound SA's SAD entry
• Sequence Number Counter: 32-bit value used to generate the Sequence Number field in AH
or ESP headers, with overflow flag for preventing further transmission on overflow
• Anti-Replay Window: Used to detect replayed inbound AH or ESP packets, a required feature
for all implementations
• AH Information: Authentication algorithm, keys, key lifetimes, and related parameters for AH
implementations
• ESP Information: Encryption and authentication algorithm, keys, initialization values, key
lifetimes, and related parameters for ESP implementations
• Lifetime of Security Association: Time interval or byte count after which an SA must be
replaced with a new one or terminated, with indication of the action to take
• IPsec Protocol Mode: Tunnel, transport, or wildcard mode
• Path MTU: Observed path Maximum Transmission Unit (MTU) and aging variables, required
for all implementations
IP Traffic Processing
•IPsec operates on a packet-by-packet basis.
•Outbound IP packets are processed by IPsec logic before transmission.
•Inbound packets are processed by IPsec logic after reception and before passing them to the
next higher layer (e.g., TCP or UDP).
1.IPsec searches the Security Policy Database (SPD) for a match to the packet.
2.If no match is found in the SPD, the packet is discarded, and an error message is
generated.
3.Upon finding a match in the SPD, further processing is determined by the first matching
entry:
• If the policy is DISCARD, the packet is discarded.
• If the policy is BYPASS, no further IPsec processing occurs; the packet is forwarded
for transmission.
4.If the policy is PROTECT, the Security Association Database (SAD) is searched for a
matching entry:
• If no entry is found, Internet Key Exchange (IKE) is initiated to create a Security
Association (SA) with the required keys and an entry is added to the SAD.
5.The matching SAD entry dictates the processing for the packet:
• Encryption, authentication, or both may be applied.
• Transport or tunnel mode may be used.
• The processed packet is then forwarded for transmission on the network.
1.IPsec differentiates between unsecured IP packets and those with ESP or AH
headers/trailers by examining the IP Protocol field (IPv4) or Next Header field (IPv6).
2.For unsecured packets:
IPsec searches the Security Policy Database (SPD) for a match:
 If the first matching entry has a BYPASS policy, the IP header is processed and
stripped off, and the packet body is delivered to the next higher layer like TCP.
 If the first matching entry has a PROTECT or DISCARD policy, or no match is
found, the packet is discarded.
3.For secured packets:
IPsec checks the Security Association Database (SAD):
 If there is no match, the packet is discarded.
 If a match is found, IPsec applies the appropriate ESP or AH processing.
 The IP header is processed and stripped off, and the packet body is delivered to the
next higher layer such as TCP.
Encapsulating Security Payload
• ESP (Encapsulating Security Payload) can offer various security features:
• Confidentiality: Ensuring the data remains confidential during transmission
• Data origin authentication: Verifying the source of the data
• Connectionless integrity: Ensuring the integrity of the data
• Anti-replay service: Preventing replay attacks by ensuring the sequence integrity of
messages
• Limited traffic flow confidentiality: Providing some level of confidentiality on traffic
patterns
• The specific services provided by ESP depend on the options chosen during SA
establishment and the network's topology.
• ESP supports a range of encryption and authentication algorithms, including authenticated
encryption methods like GCM.
ESP Format
• Security Parameters Index (32 bits): Identifies a security association within the ESP
header.
• Sequence Number (32 bits): Monotonically increasing counter for anti-replay protection.
• Payload Data (variable): Contains the transport-level segment in transport mode or the IP
packet in tunnel mode, encrypted for protection.
• Padding (0–255 bytes): Field used for padding to meet encryption requirements.
• Pad Length (8 bits): Indicates the number of pad bytes preceding the Pad Length field.
• Next Header (8 bits): Identifies the type of data in the payload data field, such as an
extension header in IPv6 or an upper-layer protocol like TCP.
• Integrity Check Value (variable): Field containing the ICV computed over the ESP
packet except for the Authentication Data field.
• For combined mode algorithms, both decrypted plaintext and integrity check results are
expected. The ICV, usually at the end of the ESP packet, may be excluded with combined
mode algorithms.
• Transport Mode ESP:
• Encrypts and optionally authenticates data carried by IP (e.g., TCP segment).
• In IPv4, ESP header is inserted before the transport-layer header (e.g., TCP, UDP,
ICMP), with ESP trailer (Padding, Pad Length, Next Header) after the IP packet.
• If authentication is chosen, ESP Authentication Data field follows the ESP trailer.
• Encryption encompasses the entire transport-level segment along with the ESP trailer;
authentication covers ciphertext and the ESP header.
• In IPv6, ESP is considered an end-to-end payload and is not processed by intermediate
routers.
• ESP header follows the IPv6 base header and certain extension headers (like hop-by-
hop and routing headers).
• Destination options extension header may precede or follow the ESP header based on
requirements.
• For IPv6, encryption envelops the transport-level segment, ESP trailer, and possibly
the destination options extension header after the ESP header.
• Authentication covers ciphertext and the ESP header.
Tunnel Mode ESP:
• Encrypts the entire IP packet to counter traffic analysis.
• ESP header is added at the beginning of the packet, and the packet plus ESP trailer are
then encrypted.
• Due to sensitive IP header content, encrypted IP packets can't be directly transmitted
as they would be unprocessable by intermediate routers.
• Encapsulation is required to include ESP header, ciphertext, and Authentication Data
within a new IP header for proper routing without revealing contents for traffic
analysis.
• Tunnel mode is beneficial for setups with a security gateway or firewall protecting a
trusted network from external networks.
• Encryption is typically between an external host and the security gateway or between
security gateways, relieving internal hosts of encryption processing.
• Simplifies key distribution by reducing the number of required keys and hinders traffic
analysis based on ultimate destination.
Combining Security Association
• An individual Security Association (SA) can implement either the Authentication Header
(AH) or Encapsulating Security Payload (ESP) protocol, but not both.

• Sometimes, a particular traffic flow may require both AH and ESP services.

• A specific traffic flow may need IPsec services between hosts and separate services
between security gateways, such as firewalls. In such cases, multiple SAs must be
employed for the same traffic flow to achieve the desired IPsec services.

• A Security Association bundle refers to a sequence of SAs that traffic must pass through to
provide a desired set of IPsec services. These SAs in a bundle can terminate at different
endpoints or the same endpoints.
• Security associations can be combined into bundles through two methods: Transport adjacency
and Iterated tunneling.
• Transport adjacency involves applying multiple security protocols to the same IP packet
without tunneling, allowing for only one level of combination.
• Iterated tunneling refers to the application of multiple layers of security protocols through IP
tunneling, enabling multiple levels of nesting.

• Both approaches can be combined, for instance, by having a transport SA between hosts travel
through a tunnel SA between security gateways.

• When considering SA bundles, an interesting issue is the order in which authentication and
encryption can be applied between a given pair of endpoints and the methods of doing so.

• Combinations of SAs may involve at least one tunnel in some scenarios.

Authentication Plus Confidentiality
• Encryption and authentication can be combined to transmit an IP packet with both
confidentiality and authentication between hosts.

• ESP with Authentication Option:

• In this approach, ESP is applied to the data to be protected, followed by the addition
of the authentication data field.
• Two subcases:

• Transport mode ESP: Authentication and encryption apply to the IP payload

delivered to the host, but the IP header is not protected.
• Tunnel mode ESP: Authentication applies to the entire IP packet delivered to the
outer IP destination address, and encryption is applied for delivery to the inner IP
destination.
• Authentication applies to the ciphertext rather than the plaintext in both cases.

• Transport Adjacency:

• Another way to apply authentication after encryption is to use two bundled transport
SAs, with the inner being an ESP SA and the outer being an AH SA.
• ESP is used without its authentication option, and AH is applied in transport mode to
cover the ESP plus the original IP header except for mutable fields.
• The advantage is that authentication covers more fields, including the source and
destination IP addresses, while the disadvantage is the overhead of two SAs versus
one SA.
Transport-Tunnel Bundle

• Using authentication before encryption prevents interception and alteration of authentication

data without detection and allows for storing authentication information with the message for
later reference.

• Authentication applied to the unencrypted message makes it more convenient for verification
without the need for re-encryption.

• Approach involving a bundle with an inner AH transport SA and an outer ESP tunnel SA
allows authentication to be applied to the IP payload and header (excluding mutable fields)
before encryption.

• Resulting IP packet is processed in tunnel mode by ESP, encrypting the entire authenticated
inner packet and adding a new outer IP header.
Internet Key Exchange
• IPsec's key management involves determining and distributing secret keys for secure
communication.
• Typically, four keys are required for communication between two applications: transmit
and receive pairs for integrity and confidentiality.
• Two types of key management in IPsec:
• Manual: System administrator manually configures keys for each system and
communicating systems, suitable for small, static environments.
• Automated: Enables on-demand key creation for Security Associations (SAs) in
large, evolving systems.
• Default automated key management protocol in IPsec is ISAKMP/Oakley, comprising
Oakley Key Determination Protocol and Internet Security Association and Key
Management Protocol (ISAKMP).
• ISAKMP includes a set of message types allowing the use of different key exchange
algorithms and does not dictate a specific algorithm.

• Oakley is the key exchange algorithm mandated for the initial version of ISAKMP.

• In IKEv2, the terms Oakley and ISAKMP are not utilized, and there are notable differences
compared to their use in IKEv1, though the basic functionality remains the same.
Key Determination Protocol

• IKE key determination refines the Diffie-Hellman key exchange algorithm.

• Diffie-Hellman involves an interaction where each user selects a private key, computes
and exchanges public keys, and then derives a shared secret session key.

• Diffie-Hellman has attractive features including on-demand key creation and minimal
need for pre-existing infrastructure.
Features of IKE key determination
The IKE key determination algorithm is characterized by five important features:

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

• It enables the two parties to negotiate a group; this, in essence, specifies the global
parameters of the Diffie-Hellman key exchange.

• It uses nonces to ensure against replay attacks.

• It enables the exchange of Diffie-Hellman public key values.

• It authenticates the Diffie-Hellman exchange to thwart man-in-the-middle attacks.

IKE Header Format
• Initiator SPI (64 bits): A value chosen by the initiator to identify a unique IKE security
association (SA).
• 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
• Flags (8 bits): Indicates specific options set for this IKE exchange
• 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.