Information Technology Security

MSI
2017/2018

T2 – Electronic Mail Security

Email Protocols

Two types of protocols are used for transferring email:

• Used to move messages through the Internet from source to

destination

• Simple Mail Transfer Protocol (SMTP)

• Used to transfer messages between mail servers

• IMAP (Internet Message Access Protocol) and POP (Post

Office Protocol) are the most commonly used

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Internet Mail Architecture

• Defined in RFC 5598

• Message User Agent (MUA): client

email program, local email server

• Mail Submission Agent (MSA):

enforces policies and standards

• Message Transfer Agent (MTA): relays

messages

• Mail Delivery Agent (MDA): transfers

messages from MHS to the MS

• Message Store (MS): same machine

as MUA or remote server

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

SMTP (Simple Message Transfer Protocol)

Encapsulates an email
message in an envelope and
Simple Mail Transfer is used to relay the
Protocol encapsulated messages from
source to destination
through multiple MTAs

Is a text-based client-server
protocol

The term Extended SMTP

Was originally specified in (ESMTP) is often used to
1982 as RFC 821 refer to later versions of
SMTP (last revision from
2008, RFC 5321)

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Mail Access Protocols

POP3 IMAP
• Internet Mail Access Protocol
• Post Office Protocol
• Enables an email client to access
• Allows an email client to
mail on an email server
download an email from an email
server (MTA) • Also uses TCP, with server TCP
port 143
• POP3 user agents connect via TCP
to the server • Is more complex than POP3

• After authorization, the UA can • Provides stronger authentication

issue POP3 commands to retrieve and provides other functions not

and delete mail supported by POP3

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

RFC 5322 (Internet Message Format)

Defines a format for text messages that are sent using electronic mail

Messages are viewed as having an envelope and contents

• The envelope contains whatever information is needed to accomplish

transmission and delivery

• The contents compose the object to be delivered to the recipient

• RFC 5322 standard applies only to the contents

The content standard includes a set of header fields that may be used
by the mail system to create the envelope

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Example Message
Delivered-To: [email protected]
Received: by 10.202.168.7 with SMTP id r7csp406081oie;
Sat, 10 Feb 2018 07:00:05 -0800 (PST)
X-Received: by 10.223.158.193 with SMTP id b1mr5539498wrf.156.1518274804931;
Sat, 10 Feb 2018 07:00:04 -0800 (PST)
Return-Path:<[email protected]>
Received: from smtp2.dei.uc.pt (smtp.dei.uc.pt. [193.137.203.234])
by mx.google.com with ESMTPS id e25si984421wmh.124.2018.02.10.07.00.04
for<[email protected]>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 10 Feb 2018 07:00:04 -0800 (PST)
Received: from eden.dei.uc.pt (eden-out.dei.uc.pt [193.136.212.2]) by smtp2.dei.uc.pt
(8.15.2/8.14.4) with ESMTPS id w1AExuN6020603 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384
bits=256 verify=NO) for<[email protected]>; Sat, 10 Feb 2018 14:59:57 GMT
Received: from smtp.dei.uc.pt (smtp.dei.uc.pt [193.137.203.253]) by eden.dei.uc.pt
(8.14.4/8.14.4) with ESMTP id w1AExu9n018679 for<[email protected]>; Sat, 10 Feb 2018 14:59:56
GMT
Received: from xpto.com (eden-out.dei.uc.pt [193.136.212.2]) by smtp.dei.uc.pt (8.15.2/8.14.4)
with ESMTP id w1AEwBmR005461 for<[email protected]>; Sat, 10 Feb 2018 14:58:33 GMT
Date: Sat, 10 Feb 2018 14:58:11 GMT
From: [email protected]
Message-Id:<[email protected]>
Subject: A quick test

Hello, this is a simple test on how easy

it is to forge the source address of an
email message.

Best regards,
Xpto person

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Envelope vs Header FROM

THE ENVELOPE THE HEADER

• Communication between the SMTP • An email is divided in at least two
Client and Server parts: Header and Body

• The client and server first greet each • The sender's email address and name
other with a HELO command is specified in the FROM header

• Client uses MAIL FROM to represent • The sender's email address can be
the sender's address. different from the envelope's MAIL

• Client sends one or more recipient's FROM

email address using the RCPT TO • An email client will only display the
command. FROM header, the user will never

• It is very easy to specify a fake/forged know what was the value for the

address in the MAIL FROM command MAIL FROM in the envelope

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Example SMTP Transaction Scenario

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Email (in)security (a quick demo)

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

STARTTLS

• A significant security-related extension for SMTP

• Defined in RFC 3207 (SMTP Service Extension for Secure

SMTP over Transport Layer Security, February 2002)

• Enables the addition of confidentiality and authentication in

the exchange between SMTP agents

• This gives SMTP agents the ability to protect some or all of

their communication from eavesdroppers and attackers

• Advantage of using STARTTLS is that the server can offer

SMTP service on a single port, rather than requiring
separate port numbers for secure and cleartext operations

• Similar mechanisms are available for IMAP and POP

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

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

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

data included in X.400 messages

• Some SMTP implementations do not adhere completely to the SMTP

standards defined in RFC 821

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Multipurpose Internet Mail Extensions (MIME)
MIME specification includes the following elements:

An extension to the RFC 5322

framework that is intended to address
some of the problems and limitations
Transfer encodings Five new message
of the use of Simple Mail Transfer header fields are
are defined that
Protocol (SMTP) enable the defined, which may
conversion of any be included in an
content format into RFC 5322 header;
• Is intended to resolve these
a form that is these fields provide
problems in a manner that is protected from information about
compatible with existing RFC 5322 alteration by the the body of the
mail system message
implementations

• The specification is provided in RFCs

A number of content
2045 through 2049 formats are defined, thus
standardizing
representations that
support multimedia
electronic mail

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

MIME Specifications

The MIME specification includes the following elements:

• Five new message header fields are defined, which may be included in an RFC
5322 header

• A number of content formats are defined, thus standardizing representations

that support multimedia electronic mail

• Transfer encodings are defined that enable the conversion of any content
format into a form that is protected from alteration by the mail system

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

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

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 MIME
Content
Types
(RFC 2046)

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved. © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
 Table 19.2
MIME Transfer Encodings

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved. © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
Example MIME message structure

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Email Security Threats

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 mail

Specific email threats (together with approaches to mitigation) provided in

NIST SP 800-177 (Trustworthy Email, Sep 2015)

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

 Email Threats
and
Mitigations

© 2017 Pearson Education, Inc., Hoboken, NJ. All

rights reserved. © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
Counter Threat Protocols
SP800-177 recommends use of a variety of standardized protocols as a means for countering threats:

• STARTTLS

• An SMTP security extension that provides authentication, integrity, non-repudiation and confidentiality for
the entire SMTP message by running SMTP over TLS

• S/MIME and PGP

• Provides authentication, integrity, non-repudiation and confidentiality 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

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Counter Threat Protocols (cont.)

• 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

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Interaction between Counter Threat Protocols

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Secure/Multipurpose Internet Mail Extension (S/MIME)

A security enhancement to the MIME Internet e-mail format standard based on technology from
RSA Data Security

The most important documents relevant to S/MIME include:

• RFC 5750, S/MIME Version 3.2 Certificate Handling

• RFC 5751, S/MIME Version 3.2 Message Specification

• RFC 4134, Examples of S/MIME Messages

• RFC 2634, Enhanced Security Services for S/MIME

• RFC 5652, Cryptographic Message Syntax (CMS)

• RFC 3370, CMS Algorithms

• RFC 5752, Multiple Signatures in CMS

• RFC 1847, Security Multiparts for MIME – Multipart/Signed and Multipart/Encrypted

S/MIME provides four message-related services: authentication, confidentiality, compression and

email compatibility

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Summary of S/MIME Services

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

S/MIME functional flow

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Pretty Good Privacy (PGP)

• Alternative email security protocol which has essentially the same functionality as S/MIME

• PGP was created by Phil Zimmerman and implemented as a product first released in 1991

• It was made available free of charge and became popular for personal use

• The initial protocol was proprietary and used some encryption algorithms with intellectual
property restrictions

• OpenPGP was developed as a new standard protocol based on PGP version 5.x

• OpenPGP is defined in RFC 4880 and RFC 3156

• There are two significant differences between S/MIME and OpenPGP:

• Key Certification (X.509 in S/MIME, versus web of trust with OpenPGP public keys)
• Key Distribution (Certification Authorities versus OpenPGP public key servers)
• NIST 800-177 recommends the use of S/MIME rather than PGP because of the greater
confidence in the CA system of verifying public keys

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Web of Trust versus PKI (Certification Authorities)

• The user decide whom trust and whom not

• It is thus a cumulative trust model

• When any user signs another’s key, he or she becomes an introducer of that key.

• As this process goes on, it establishes a web of trust

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Domain Name System (DNS)

• A directory lookup service that provides a mapping between the name of a

host on the Internet and its numeric IP address

• Is essential to the functioning of the Internet

• Is used by MUAs and MTAs to find the address of the next hop server for
mail delivery (MTAs query DNS for MX Resource Records of the recipient’s
domain)

• Is comprised of four elements:

• Domain name space

• DNS database

• Name servers

• Resolvers
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
DNS Database

• DNS is based on a hierarchical database containing resource records (RRs)

that include the name, IP address, and other information about hosts

The key features of the database are:

• Variable-depth hierarchy for names

• Distributed database

• Distribution controlled by the database

• Using this database, DNS servers provide a name-to-address directory service

for network applications that need to locate specific servers

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Resource Records (RR) types

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

DNS Name Resolution

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

DNSSEC
• DNS Security Extensions

• Provides end-to-end protection through the use of digital signatures that are created
by responding zone administrators and verified by a recipient’s resolver software

• Avoids the need to trust intermediate name servers and resolvers that cache or route
the DNS records originating from the responding zone administrator before they reach
the source of the query

• Consists of a set of new resource record types and modifications to the existing DNS
protocol

• Defined in these documents:

• RFC 4033, DNS Security Introduction and Requirements

• RFC 4034, Resource Records for the DNS Security Extensions

• RFC 4035, Protocol Modifications for the DNS Security Extensions

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

DNSSEC Operation

• In essence, DNSSEC is designed to protect DNS clients from accepting forged or

altered DNS resource records

• It does this by using digital signatures to provide:

• Data origin authentication

• Ensures that data has originated from the correct source

• Data integrity verification

• Ensures that the content of a RR has not been modified

• Trust in the public key of the source is established by starting from a trusted zone and
establishing the chain of trust down to the current source of response through
successive verifications of signature of the public key of a child by its parent

• The public key of the trusted zone is called the trust anchor

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

DANE

Is a protocol to allow X.509

certificates, commonly used
DNS-Based Authentication
for Transport Layer Security
of Named Entities
(TLS) to be bound to DNS
names using DNSSEC

It is proposed in RFC 6698 as The purpose of DANE is to

a way to authenticate TLS replace reliance on the
client and server entities security of the CA system
without a certificate with reliance on the security
authority (CA) provided by DNSSEC

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

TLSA RR Transmission Format

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Sender Policy Framework (SPF)
• SPF is the standardized way for a sending domain to identify and assert the
mail senders for a given domain

• SPF addresses a problem with the current email infrastructure any host can
use any domain name for various identifiers in the mail header (a major
cause of spam).

• RFC 7208 defines the SPF

• It provides a protocol by which ADMDs can authorize hosts to use their

domain names in the “MAIL FROM” or “HELLO” identities

• SPF works by checking a sender’s IP address against the policy encoded in

any SPF record found at the sending domain

• This means that SPF checks can be applied before the message content is
received from the sender
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
Example SMTP envelope vs message header
A sending domain identifies all the senders (MTAs) via appropriate SPF DNS records

At a receiver, the SMTP envelope MAIL FROM: address and the IP address of the
sender are used to query an SPF TXT RR

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

SPF mechanisms and modifiers

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

SPF records (example for domain dei.uc.pt)

jgranjal$ nslookup
> set query=txt
> dei.uc.pt
Server:10.0.1.254
Address:10.0.1.254#53

Non-authoritative answer:
dei.uc.pt text = "v=spf1 ip4:193.137.203.253 ip4:193.137.203.234 mx ?all"
dei.uc.pt text = "U.C. Dep. Eng. Informatica"
dei.uc.pt text = "MS=ms12952510"

>

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

SPF operation

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

DomainKeys Identified Mail (DKIM)

• A specification for cryptographically signing e-mail messages, permitting a

signing domain to claim responsibility for a message in the mail stream

• Message recipients can verify the signature by querying the signer’s

domain directly to retrieve the appropriate public key and can thereby
confirm that the message was attested to by a party in possession of the
private key for the signing domain

• Proposed Internet Standard RFC 6376

• Has been widely adopted by a range of e-mail providers and Internet

Service Providers (ISPs)

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

DKIM deployment example

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

DKIM functional flow

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

DMARC

• Domain-Based Message Authentication, Reporting, and Conformance

• Allows email senders to specify policy on how their mail should be handled, the
types of reports that receivers can send back, and the frequency those reports
should be sent

• It is defined in RFC 7489 (Domain-based Message Authentication, Reporting, and

Conformance, March 2015)

• DMARC reporting provides the sender’s feedback on their SPF, DKIM, Identifier
Alignment and message disposition policies, which enable the sender to make these
policies more effective

• Two type of reports are sent: aggregate reports and forensic reports
© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
DMARC functional flow

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

DMARC Tag
and Value
Descriptions

© 2017 Pearson Education, Inc., Hoboken, NJ.

All rights reserved. © 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
Using SPF, DKIM and DMARC (Example from Google Mail)

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Review Questions

What are the four principle services provided by S/MIME?

S/MIME (Secure/Multipurpose Internet Mail Extension) is a security enhancement to the MIME Internet e-
mail format standard, and provides authentication, confidentiality, compression and email compatibility

What is the basic difference between X.509 and PGP in terms of key hierarchies and key trust?

In X.509 there is a hierarchy of Certificate Authorities. Another difference is that in X.509 users will only trust
Certificate Authorities while in PGP users can trust other users.

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Summary
Internet mail architecture S/MIME

• Email components • Operational description

• Email protocols • S/MIME message content types

Email formats • Cryptographic algorithms

• RFC 5322 • Certificate processing

• Multipurpose internet mail extensions Enhanced security services

Email threats and comprehensive email security • DNS-based authentication of named entities

Pretty good privacy • SPF

DNSSEC • DomainKeys Identified mail

• Domain name system • Email threats

• DNS security extensions • DKIN strategy

• Functional flow

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

PGP in the movies..

https://www.wired.com/2014/10/laura-poitras-crypto-tools-made-snowden-film-possible/

© 2017 Pearson Education, Inc., Hoboken, NJ. All rights reserved.

Bibliography

Cryptography and network security, Stallings,

Pearson, 2017, Chapter 16: Electronic Mail Security

Segurança em Redes Informáticas, Capítulo 3: Gestão

de Chaves Públicas

Segurança Prática em Sistemas e Redes com Linux,

Capítulo 2: Segurança em Correio Eletrónico