Security protocols
Lecture 11 Electronic Mail Security
Outline
• Internet mail architecture
• E-mail formats
• E-mail threats and comprehensive e-mail
security
• S/MIME
• DNSSEC
• DomainKeys Identified Mail
Internet mail architecture
• Defined in RFC 5598 (Internet Mail Architecture,
July 2009)
• E-mail components:
• At its most fundamental level, the internet mail
architecture consists of a user world in the form of
Message User Agents (MUA)
• And the transfer world, in the form of the Message
Handling Service (MHS), which is composed of Message
Transfer Agents (MTA)
• The MHS accepts a message from one user and delivers it to
one or more other users, creating a virtual MUA-to-MUA
exchange environment
• This architecture involves three types of interoperability
Function Modules and standardised protocols used in Internet
Mail Architecture
[email protected]
[email protected]
E-Mail components
• Administrative management domain (ADMD)
• Internet e-mail provider
• Examples include a department that operates a
local mail relay, an IT department that operates
an enterprise mail relay, and an ISP that operates
a public shared e-mail service
• Each ADMD can have different operating policies
and trust-based decision making
• Domain name system (DNS)
• A directory lookup service that provides a
mapping between the name of a host on the
Internet and its numerical address
E-Mail Protocols SMTP
• Simple Mail Transfer Protocol (SMTP)
• Encapsulates an e-mail message in an envelope and is used to relay
the encapsulated messages from source to destination through
multiple MTAs
• Was originally specified in 1982 as RFC 821
• Has undergone several revisions, the most current being RFC5321
(October 2008)
• Is a text-based client-server protocol where the client (e-mail sender)
contacts the server (next-hop recipient) and issues a set of commands
to tell the server about the message to be sent, then sending the
message itself
• The majority of these commands are ASCII text messages sent by
the client and a resulting return code returned by the server
Example SMTP Transaction Scenario
Mail access protocols
Post Office Protocol (POP3)
• Allows an e-mail client (user agent) to download an e-mail from an e-
mail server (MTA)
• POP3 user agents connect via TCP to the server (usually port 110)
• The user agent enters a username and password
• After authorization, the UA can issue POP3 commands to retrieve and
delete mail
Internet Mail Access Protocol (IMAP)
• Enables an e-mail client to access mail on an e-mail server
• Uses TCP, with server TCP port 143
• Is more complex than POP3
• Provides stronger authentication that POP3 and provides other
functions not supported by POP3
E-mail Formats I
• RFC 5322
• Defines a format for text messages that are sent using electronic mail
• Has been the standard for Internet-based text mail messages
• 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
E-mail Formats II
• Multipurpose Internet Mail Extensions (MIME)
• Extension to the RFC 5322 framework
• RFCs 2045 through 2049 define MIME
• The MIME specification includes the following elements:
• Five new message header fields are defined, which may be
included in an RFC 5322 header, providing information about
the body of the message
• 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
E-mail threats
E-mail security threats can be classified as:
Authenticity-related threats
• Could result in unauthorized access to an enterprise’s e-mail system
Integrity-related threats
• Could result in unauthorized modification of e-mail 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 e-mail
Email Threats and Mitigations
DNSSEC, SPF, DKIM, DMARC, DANE, and S/MIME
S/MIME
S/MIME is a complex
capability that is defined
in a number of documents
MIME is specified in
Secure/Multipurpose RFCs 2045 through
Internet Mail Extension 2049
Is a security enhancement
to the MIME Internet e-
mail format standard
based on technology from
RSA Data Security
Summary of S/MIME Services
Authentication
• Authentication is provided by means of a digital signature
• Most commonly RSA with SHA-256 is used
• The sender creates a message
• SHA-256 is used to generate a 256-bit message digest of the
message
• The message digest is encrypted with RSA using the sender’s
private key, and the result is appended to the message; also
appended is identifying information for the signer, which will
enable the receiver to retrieve the signer’s public-key
• The receiver uses RSA with the sender’s public key to decrypt and
recover the message digest
• The receiver generates a new message digest for the message and
compares it with the decrypted hash code; if the two match, the
message is accepted as authentic
Confidentiality
• S/MIME provides confidentiality by encrypting messages
• Most commonly AES with a 128-bit key is used, with the cipher block
chaining (CBC) mode
• The key itself is also encrypted, typically with RSA
• In S/MIME each symmetric key, referred to as a content-encryption key, is
used only once
• To protect the key, it is encrypted with the receiver’s public key
• Sequence:
• The sender generates a message and a random 128-bit number to be used as a
content-encryption key for this message only
• The message is encrypted using the content-encryption key
• The content-encryption key is encrypted with RSA using the recipient’s public key
and is attached to the message
• The receiver uses RSA with its private key to decrypt and recover the content-
encryption key
• The content-encryption key is used to decrypt the message
Simplified S/MIME Functional Flow
E-mail compatibility
• Many electronic mail systems only permit the use
of blocks consisting of ASCII text
• To accommodate this restriction, S/MIME provides
the service of converting the raw 8-bit binary
stream to a stream of printable ASCII characters
• A process referred to as 7-bit encoding
• The scheme typically used for this purpose is
Base64 conversion
• Each group of three octets of binary
data is mapped into four ASCII characters
S/MIME messages
S/MIME uses the following message content types, which are
defined in RFC 5652, Cryptographic Message Syntax
Data
• Refers to the inner MIME-encoded message content, which may then be encapsulated in a
SignedData, EnvelopedData, or CompressedData content type
SignedData
• Used to apply a digital signature to a message
EnvelopedData
• This consists of encrypted content of any type and encrypted-content encryption keys for
one or more recipients
CompressedData
• Used to apply data compression to a message
S/MIME Content types –envelopedData
• The steps for preparing an envelopedData MIME
entity are:
• Generate a pseudorandom session key for a particular
symmetric encryption algorithm (RC2/40 or triple DES)
• For each recipient, encrypt the session key with the
recipient’s public RSA key
• For each recipient, prepare a block known as
RecipientInfo that contains an identifier of the
recipient’s public-key certificate
• Encrypt the message content with the session key
S/MIME Content types –signedData
The steps for preparing a signedData
MIME entity are as follows:
Select a message digest algorithm (SHA or MD5)
Compute the message digest (hash function) of the content to be signed
Encrypt the message digest with the signer’s private key
Prepare a block known as SignerInfo that contains the signer’s public-key
certificate, an identifier of the message digest algorithm, an identifier of the
algorithm used to encrypt the message digest, and the encrypted message digest
S/MIME certificate processing
• A S/MIME user has several key management functions to
perform:
• Key generation
• The user of some related administrative utility MUST be capable of
generating separate Diffie-Hellman and DSS key pairs and SHOULD be
capable of generating RSA key pairs
• Each key pair MUST be generated from a good source of nondeterministic
random input and be protected in a secure fashion
• A user agent SHOULD generate RSA key pairs with a length in the range of
768 to 1024 bits and MUST NOT generate a length of less than 512 bits
• Registration
• A user’s public key must be registered with a certification authority in order
to receive an X.509 public-key certificate
• Certificate storage and retrieval
• A user requires access to a local list of certificates in order to verify incoming
signatures and to encrypt outgoing messages
• Such a list could be maintained by the user or by some local
administrative entity on behalf of a number of users
Pretty good privacy (pgp)
• An alternative e-mail security protocol
• Has essentially the same functionality as S/MIME
• Created by Phil Zimmerman and implemented as a product first
released in 1991
• It was made available free of charge and became quite popular for
personal use
• The initial PGP protocol was proprietary and used some encryption
algorithms with intellectual property restriction
• There are two significant differences between S/MIME and OpenPGP:
• Key certification
• Key distribution
• SP 800-177 recommends the use of S/MIME rather than PGP because
of the greater confidence in the CA system of verifying public keys
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. It is essential to the functioning of the Internet. It
is used by MUAs and MTAs to find the address of the next hop server for mail delivery
• Comprised of four elements:
• Domain name space
• DNS uses a tree-structured name space to identify resources on the Internet
• DNS database
• Conceptually, each node and leaf in the name space tree structure names a set of
information that is contained in resource record. The collection of all RRs is organized
into a distributed database
• Name servers
• These are server programs that hold information about a portion of the domain name
tree structure and the associated RRs
• Resolvers
• These are programs that extract information from name servers in response to client
requests. A typical client request is for an IP address corresponding to a given domain
name
DNS Name Resolution
DNS security extensions
• DNSSEC:
• 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:
• 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
DNS-based authentication of named entities
(DANE)
• DANE is a protocol to allow X.509 certificates, commonly used for
Transport Layer Security (TLS), to be bound to DNS names using DNSSEC
• It is proposed in RFC 6698 as a way to authenticate TLS client and server
entities without a certificate authority (CA)
• The purpose of DANE is to replace reliance on the security of the CA
system with reliance on the security provided by DNSSEC
• DANE defines a new DNS record type, TLSA, that can be used for a
secure method of authenticating SSL/TLS certificates
E-mail Threats
• RFC 4686 (Analysis of
Threats Motivating The most sophisticated and financially
DomainKeys Identified motivated senders of messages are
those who stand to receive substantial
Mail) financial benefit, such as from an e-
mail based fraud scheme
• Describes the threats
being addressed by
DKIM in terms of the The next level are professional
senders of bulk spam mail and often
characteristics, operate as commercial enterprises
and send messages on behalf of third
capabilities, and parties
location of potential
attackers
At the low end are attackers who
• Characterized on three simply want to send e-mail that a
recipient does not want to
levels of threat: receive
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)
DKIM strategy
• DKIM is designed to provide an e-mail authentication technique that is transparent
to the end user
• In essence, a user’s e-mail message is signed by a private key of the administrative
domain from which the e-mail originates
• The signature covers all of the content of the message and some of the RFC 5322
message headers
• This approach differs from that of S/MIME and PGP, which use the originator’s
private key to sign the content of the message
• The motivation for DKIM is based on the following reasoning: DKIM is not
implemented in client programs (MUAs) and is therefore transparent to the user;
the user need not take any action
• DKIM applies to all mail from cooperating domains
• DKIM allows good senders to prove that they did send a particular message
and to prevent forgers from masquerading as good senders
DKIM Deployment Example
Summary
• Secure email
• S/MIME
• DNSSEC
• PGP
• Domain-keys identified email
