0% found this document useful (0 votes)
15 views

Ch7-Electronic Mail Security

Uploaded by

k95003538
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views

Ch7-Electronic Mail Security

Uploaded by

k95003538
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 28

NETWORK SECURITY Chapter Seven:

Electronic Mail Security

29/12/2024
WEB TRAFFIC SECURITY APPROACHES
INTERNET MAIL ARCHITECTURE
❑Message User Agent (MUA): Operates on behalf of user actors and user
applications. It is their representative within the email service. Typically, this
function is housed in the user’s computer and is referred to as a client email
program or a local network email server.

❑Mail Submission Agent (MSA): Accepts the message submitted by an MUA


and enforces the policies of the hosting domain and the requirements of
Internet standards. This function may be located together with the MUA or as
a separate functional model. In the latter case, the Simple Mail Transfer
Protocol (SMTP) is used between the MUA and the MSA.
INTERNET MAIL ARCHITECTURE
❑Message Transfer Agent (MTA): Relays mail for one application-level hop.
It is like a packet switch or IP router in that its job is to make routing
assessments and to move the message closer to the recipients. Relaying is
performed by a sequence of MTAs until the message reaches a destination
MDA. An MTA also adds trace information to the message header. SMTP is
used between MTAs and between an MTA and an MSA or MDA.
❑Mail Delivery Agent (MDA): Responsible for transferring the message from
the MHS to the MS.
❑Message Store (MS): An MUA can employ a long-term MS. An MS can be
located on a remote server or on the same machine as the MUA. Typically, an
MUA retrieves messages from a remote server using POP (Post Office
Protocol) or IMAP (Internet Message Access Protocol).
INTERNET MAIL
ARCHITECTURE
ELECTRONIC MAIL PROTOCOLS
❑Simple Mail Transfer Protocol: SMTP encapsulates an email message in an
envelope and is used to relay the encapsulated messages from source to destination through
multiple MTAs. The term Extended SMTP (ESMTP) is often used to refer to these later
versions of SMTP.
❑Mail Access Protocols (POP 3, IMAP ) Post Office Protocol (POP3) allows an
email client (user agent) to download an email from an email server (MTA). POP3 user
agents connect via TCP to the server (typically port 110). The user agent enters a username
and password (either stored internally for convenience or entered each time by the user for
stronger security). After authorization, the UA can issue POP3 commands to retrieve and
delete mail.

❑ As with POP3, Internet Mail Access Protocol (IMAP) also enables an email client to access
mail on an email server. IMAP also uses TCP, with server TCP port 143. IMAP is more
complex than POP3. IMAP provides stronger authentication than POP3 and provides other
functions not supported by POP3.
MULTIPURPOSE INTERNET MAIL EXTENSION (MIME)
❑ As justification for the use of MIME, lists the following limitations of the SMTP scheme.
1. SMTP cannot transmit executable files or other binary objects. A number of schemes are in
use for converting binary files into a text form that can be used by SMTP mail systems.
2. 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.
3. SMTP servers may reject mail message over a certain size.
4. SMTP gateways that translate between ASCII and the character code EBCDIC do not use a
consistent set of mappings, resulting in translation problems.
5. 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
1. Five new message header fields are defined, which may be included in an
RFC 5322 header. These fields provide information about the body of the
message.
2. A number of content formats are defined, thus standardizing
representations that support multimedia electronic mail.
3. Transfer encodings are defined that enable the conversion of any content
format into a form that is protected from alteration by the mail system.
THE FIVE HEADER FIELDS DEFINED IN MIME
❑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).
MIME CONTENT
TYPES
MIME TRANSFER ENCODINGS
EMAIL THREATS AND COMPREHENSIVE
EMAIL SECURITY
❑ Authenticity-related threats: Could result in unauthorized access to an enterprise’s email system.

❑ Integrity-related threats: Could result in unauthorized modification of email content.

❑ Confidentiality-related threats: Could result in unauthorized disclosure of sensitive information.

❑ Availability-related threats: Could prevent end users from being able to send or receive email.
EMAIL STANDARDIZED PROTOCOLS FOR SECURITY
❑ STARTTLS: An SMTP security extension that provides authentication, integrity, non-repudiation
(via digital signatures) and confidentiality (via encryption) for the entire SMTP message by running
SMTP over TLS.
❑ S/MIME: Provides authentication, integrity, non-repudiation (via digital signatures) and
confidentiality (via encryption) of the message body carried in SMTP messages.

❑ DNS Security Extensions (DNSSEC): Provides authentication and integrity protection of DNS data,
and is an underlying tool used by various email security protocols.

❑ DNS-based Authentication of Named Entities (DANE): Is designed to overcome problems in the


certificate authority (CA) system by providing an alternative channel for authenticating public keys
based on DNSSEC, with the result that the same trust relationships used to certify IP addresses are
used to certify servers operating on those addresses.
EMAIL STANDARDIZED PROTOCOLS FOR SECURITY

❑ Sender Policy Framework (SPF): Uses the Domain Name System (DNS) to allow domain owners
to create records that associate the domain name with a specific IP address range of authorized
message senders
❑ DomainKeys Identified Mail (DKIM): Enables an MTA to sign selected headers and the body of a
message. This validates the source domain of the mail and provides message body integrity.

❑ Domain-based Message Authentication, Reporting, and Conformance (DMARC): Lets senders


know the proportionate effectiveness of their SPF and DKIM policies, and signals to receivers what
action should be taken in various individual and bulk attack scenarios.
THE
INTERRELATIONSHIP OF
DNSSEC, SPF, DKIM,
DMARC, DANE, AND
S/MIME FOR ASSURING
MESSAGE AUTHENTICITY
AND INTEGRITY
S/MIME
S/MIME
S/MIME
PGP VS S/MIME
Features PGP S/MIME

Uses a decentralized "Web of Relies on a centralized Public


Trust" where individuals sign Key Infrastructure (PKI) with
Encryption Model
each other’s keys. certificates issued by trusted
Certificate Authorities (CAs).
Key Management Users generate their own key CAs manage key pairs and
pairs and exchange public keys distribute certificates for
manually. authentication.
Compatibility Standalone tool; requires Integrated into most modern
specific email plugins (e.g., email clients like Outlook and
GnuPG). Apple Mail.
Usability May require more technical Easier for end users due to
knowledge to set up and automated key and certificate
manage. management.
PGP VS S/MIME CONTINUED..
Features PGP S/MIME
Time Consumption Key management and Web of Faster setup due to automated
Trust verification can be time- key and certificate management
consuming. via trusted CAs.

Limitations Requires manual trust Depends on trusted Certificate


establishment; challenging for Authorities; may face trust issues
large-scale use. with compromised or untrusted
CAs.

File Format Uses OpenPGP standard (.asc, Uses X.509 certificates.


.gpg).
Primary Use Popular with individual users and Widely adopted in corporate and
open-source communities. enterprise environments.

You might also like