W8NS
akhilesh7593
CH08NetSec6e_accessiblePPT.pptxNetwork Security Essentials: Applications and Standards
Sixth Edition
Chapter 8
Electronic Mail Security
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
If this PowerPoint presentation contains mathematical equations, you may need to check that your computer has the following installed:
1) MathType Plugin
2) Math Player (free versions available)
3) NVDA Reader (free versions available)
There are application-specific security mechanisms for a number of application
areas, including electronic mail (S/MIME, PGP), client/server (Kerberos), Web access
(Secure Sockets Layer), and others. However, users have security concerns that
cut across protocol layers. For example, an enterprise can run a secure, private IP
network by disallowing links to untrusted sites, encrypting packets that leave the
premises, and authenticating packets that enter the premises. 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.
IP-level security encompasses three functional areas: authentication, confidentiality,
and key management. The authentication mechanism assures that a received
packet was, in fact, transmitted by the party identified as the source in the packet
header. In addition, this mechanism assures that the packet has not been altered in
transit. The confidentiality facility enables communicating nodes to encrypt messages
to prevent eavesdropping by third parties. The key management facility is concerned
with the secure exchange of keys.
We begin this chapter with an overview of IP security (IPsec) and an introduction
to the IPsec architecture. We then look at each of the three functional areas in
detail. Appendix D reviews Internet protocols.
Internet Mail Architecture
Defined in R F C 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 (M U A)
And the transfer world, in the form of the Message Handling Service (M H S), which is composed of Message Transfer Agents (M T A)
The M H S accepts a message from one user and delivers it to one or more other users, creating a virtual M U A-to-M U A exchange environment
This architecture involves three types of interoperability
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
For an understanding of the topics in this chapter, it is useful to have a basic grasp of
the Internet mail architecture, which is currently defined in RFC 5598 (Internet Mail
Architecture , July 2009). This section provides an overview of the basic concepts.
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. One is directly between users:
messages must be formatted by the MUA on behalf of the message author so that
the message can be displayed to the message recipient by the destination MUA.
There are also interoperability requirements between the MUA and the MHS—
first when a message is posted from an MUA to the MHS and later when it is delivered
from the MHS to the destination MUA. Interoperability is required among the
MTA components along the transfer path through the MHS.
2
Figure 8.1 Function Modules and Standardized Protocols Used Between Them in the Internet Mail Architecture
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 8.1 illustrates the key components of the Internet mail architecture,
which include the following.
■ Message User Agent (MUA): Operates on behalf of user actors and user
applications. It is their representative within the e-mail service. Typically, this
function is housed in the user’s computer and is referred to as a client e-mail
program or a local network e-mail server. The author MUA formats a message
and performs initial submission into the MHS via a MSA. The recipient MUA
processes received mail for storage and/or display to the recipient user.
■ 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.
■ 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).
3
E-Mail Components
Administrative management domain (A D M D)
Internet e-mail provider
Examples include a department that operates a local mail relay, an I T department that operates an enterprise mail relay, and an I S P that operates a public shared e-mail service
Each A D M D can have different operating policies and trust-based decision making
Domain name system (D N S)
A directory lookup service that provides a mapping between the name of a host on the Internet and its numerical address
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Two other concepts need to be defined. An administrative management
domain
(ADMD) is an Internet e-mail provider. Examples include a department
that operates a local mail relay (MTA), 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. One obvious
example is the distinction between mail that is exchanged within an organization
and mail that is exchanged between independent organizations. The rules for
handling the two types of traffic tend to be quite different.
The Domain Name System (DNS) is a directory lookup service that provides
a mapping between the name of a host on the Internet and its numerical address.
DNS is discussed subsequently in this chapter.
4
E-Mail Protocols S M T P (1 of 2)
Simple Mail Transfer Protocol (S M T P)
Encapsulates an e-mail message in an envelope and is used to relay the encapsulated messages from source to destination through multiple M T As
Was originally specified in 1982 as R F C 821
Has undergone several revisions, the most current being R F C 5321 (October 2008)
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Two types of protocols are used for transferring e-mail. The first type is used to
move messages through the Internet from source to destination. The protocol used
for this purpose is SMTP, with various extensions and in some cases restrictions. The
second type consists of protocols used to transfer messages between mail servers,
of which IMAP and POP are the most commonly used.
SMTP encapsulates an e-mail message in an
envelope
and is used to relay the encapsulated messages from source to destination
through multiple MTAs. SMTP was originally specified in 1982 as RFC 821 and
has undergone several revisions, the most current being RFC 5321 (October 2008).
These revisions have added additional commands and introduced extensions. The
term Extended SMTP (ESMTP) is often used to refer to these later versions of
SMTP.
SMTP 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 (and additional ASCII text) returned by the server.
The transfer of a message from a source to its ultimate destination can occur
over a single SMTP client/server conversation over a single TCP connection.
Alternatively, an SMTP server may be an intermediate relay that assumes the role
of an SMTP client after receiving a message and then forwards that message to an
SMTP server along a route to the ultimate destination.
The operation of SMTP consists of a series of commands and responses
exchanged
between the SMTP sender and receiver. The initiative is with the SMTP
sender, who establishes the TCP connection. Once the connection is established,
the SMTP sender sends commands over the connection to the receiver. Each command
consists of a single line of text, beginning with a four-letter command code
followed in some cases by an argument field. Each command generates exactly one
reply from the SMTP receiver. Most replies are a single-line, although multiple-line
replies are possible. Each reply begins with a three-digit code and may be followed
by additional information.
5
E-Mail Protocols S M T P (2 of 2)
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 A S C I I text messages sent by the client and a resulting return code returned by the server
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 8.2 illustrates the SMTP exchange between a client (C) and server (S).
The interchange begins with the client establishing a TCP connection to TCP port
25 on the server (not shown in figure). This causes the server to activate SMTP
and send a 220 reply to the client. The HELO command identifies the sending
domain, which the server acknowledges and accepts with a 250 reply. The SMTP
sender is transmitting mail that originates with the user [email protected]. The MAIL
command identifies the originator of the message. The message is addressed to
three users on machine foo.com, namely, Jones, Green, and Brown. The client
identifies each of these in a separate RCPT command. The SMTP receiver indicates
that it has mailboxes for Jones and Brown but does not have information on Green.
Because at least one of the intended recipients has been verified, the client proceeds
to send the text message, by first sending a DATA command to ensure the server
is ready for the data. After the server acknowledges receipt of all the data, it issues
a 250 OK message. Then the client issues a QUIT command and the server closes
the connection.
A significant security-related extension for SMTP, called STARTTLS, is
defined in RFC 3207 (SMTP Service Extension for Secure SMTP over Transport
Layer Security , February 2002). STARTTLS 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 communications from eavesdroppers
and attackers. If the client does initiate the connection over a TLS-enabled port
(e.g., port 465 was previously used for SMTP over SSL), the server may prompt with
a message indicating that the STARTTLS option is available. The client can then
issue the STARTTLS command in the SMTP command stream, and the two parties
proceed to establish a secure TLS connection. An 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 running TLS over IMAP and POP protocols.
Historically, MUA/MSA message transfers have used SMTP. The standard
currently preferred is SUBMISSION, defined in RFC 6409 (Message Submission
for Mail , November 2011). Although SUBMISSION derives from SMTP, it uses a
separate TCP port and imposes distinct requirements, such as access authorization.
6
Figure 8.2 Example SMTP Transaction Scenario
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 8.2 illustrates the SMTP exchange between a client (C) and server (S).
The interchange begins with the client establishing a TCP connection to TCP port
25 on the server (not shown in figure). This causes the server to activate SMTP
and send a 220 reply to the client. The HELO command identifies the sending
domain, which the server acknowledges and accepts with a 250 reply. The SMTP
sender is transmitting mail that originates with the user [email protected]. The MAIL
command identifies the originator of the message. The message is addressed to
three users on machine foo.com, namely, Jones, Green, and Brown. The client
identifies each of these in a separate RCPT command. The SMTP receiver indicates
that it has mailboxes for Jones and Brown but does not have information on Green.
Because at least one of the intended recipients has been verified, the client proceeds
to send the text message, by first sending a DATA command to ensure the server
is ready for the data. After the server acknowledges receipt of all the data, it issues
a 250 OK message. Then the client issues a QUIT command and the server closes
the connection.
A significant security-related extension for SMTP, called STARTTLS, is
defined in RFC 3207 (SMTP Service Extension for Secure SMTP over Transport
Layer Security , February 2002). STARTTLS 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 communications from eavesdroppers
and attackers. If the client does initiate the connection over a TLS-enabled port
(e.g., port 465 was previously used for SMTP over SSL), the server may prompt with
a message indicating that the STARTTLS option is available. The client can then
issue the STARTTLS command in the SMTP command stream, and the two parties
proceed to establish a secure TLS connection. An 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 running TLS over IMAP and POP protocols.
Historically, MUA/MSA message transfers have used SMTP. The standard
currently preferred is SUBMISSION, defined in RFC 6409 (Message Submission
for Mail , November 2011). Although SUBMISSION derives from SMTP, it uses a
separate TCP port and imposes distinct requirements, such as access authorization.
7
Mail Access Protocols (1 of 2)
Post Office Protocol (P O P 3)
Allows an e-mail client (user agent) to download an e-mail from an e-mail server (M T A)
P O P 3 user agents connect via T C P to the server (usually port 110)
The user agent enters a username and password
After authorization, the U A can issue P O P 3 commands to retrieve and delete mail
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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 (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 e-mail
client to access mail on an e-mail 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.
8
Mail Access Protocols (2 of 2)
Internet Mail Access Protocol (I M A P)
Enables an e-mail client to access mail on an e-mail server
Uses T C P, with server T C P port 143
Is more complex than P O P 3
Provides stronger authentication that P O P 3 and provides other functions not supported by P O P 3
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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 (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 e-mail
client to access mail on an e-mail 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.
9
E-Mail Formats (1 of 3)
R F C 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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
RFC 5322 defines a format for text messages that are sent using electronic mail. It
has been the standard for Internet-based text mail messages and remains in common
use. In the RFC 5322 context, 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. The RFC 5322 standard applies only to the contents. However, the content
standard includes a set of header fields that may be used by the mail system to
create the envelope, and the standard is intended to facilitate the acquisition of such
information by programs.
The overall structure of a message that conforms to RFC 5322 is very simple.
A message consists of some number of header lines (the header ) followed
by unrestricted text (the body ). The header is separated from the body
by a blank line. Put differently, a message is ASCII text, and all lines up to the
first blank line are assumed to be header lines used by the user agent part of the
mail system.
10
E-Mail Formats (2 of 3)
R F C 5322 standard applies only to the contents
Multipurpose Internet Mail Extensions (M I M E)
Extension to the R F C 5322 framework
R F Cs 2045 through 2049 define M I M E
The M I M E specification includes the following elements:
Five new message header fields are defined, which may be included in an R F C 5322 header, providing information about the body of the message
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Multipurpose Internet Mail Extension (MIME) is an extension to the RFC 5322
framework that is intended to address some of the problems and limitations of the
use of Simple Mail Transfer Protocol (SMTP) or some other mail transfer protocol
and RFC 5322 for electronic mail. RFCs 2045 through 2049 define MIME, and there
have been a number of updating documents since then.
As justification for the use of MIME, [PARZ06] lists the following limitations
of the SMTP/5322 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, including the popular UNIX UUencode/
UUdecode scheme. However, none of these is a standard or even a de facto
standard.
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. SMTP gateways to X.400 electronic mail networks cannot handle nontextual
data included in X.400 messages.
6. 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
MIME is intended to resolve these problems in a manner that is compatible
with existing RFC 5322 implementations.
The MIME specification includes the following elements.
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.
11
E-Mail Formats (3 of 3)
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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
12
Header Fields Defined in M I M E (1 of 2)
M I M E-Version
This field indicates that the message conforms to R F Cs 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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
The five header fields defined in MIME are as follows:
■ 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).
Any or all of these fields may appear in a normal RFC 5322 header. A compliant
implementation must support the MIME-Version, Content-Type, and Content-
Transfer-Encoding fields; the Content-ID and Content-Description fields are
optional and may be ignored by the recipient implementation.
13
Header Fields Defined in M I M E (2 of 2)
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-I D
Used to identify M I M E entities uniquely in multiple contexts
Content-Description
A text description of the object with the body
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
The five header fields defined in MIME are as follows:
■ 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).
Any or all of these fields may appear in a normal RFC 5322 header. A compliant
implementation must support the MIME-Version, Content-Type, and Content-
Transfer-Encoding fields; the Content-ID and Content-Description fields are
optional and may be ignored by the recipient implementation.
14
Table 8.1 M I M E Content Types (1 of 2)
| Type | Subtype | Description |
| Text | Plain | Unformatted text; may be A S C I I or I S O 8859. |
| blank | Enriched | Provides greater format flexibility. |
| Multipart | Mixed | The different parts are independent but are to be transmitted together. They should be presented to the receiver in the order that they appear in the mail message. |
| Blank | Parallel | Differs from Mixed only in that no order is defined for delivering the parts to the receiver. |
| Blank | Alternative | The different parts are alternative versions of the same information. They are ordered in increasing faithfulness to the original, and the recipients mail system should display the "best" version to the user. |
| blank | Digest | Similar to Mixed, but the default type/subtype of each part is message/rfc822. |
| Message | rfc822 | The body is itself an encapsulated message that conforms to R F C 822. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
The bulk of the MIME specification is concerned with
the definition of a variety of content types. This reflects the need to provide standardized
ways of dealing with a wide variety of information representations in a
multimedia environment.
Table 8.1 lists the content types specified in RFC 2046. There are seven different
major types of content and a total of 15 subtypes. In general, a content type declares the
general type of data, and the subtype specifies a particular format for that type of data.
For the text type of body, no special software is required to get the full meaning
of the text aside from support of the indicated character set. The primary subtype is
plain text , which is simply a string of ASCII characters or ISO 8859 characters. The
enriched subtype allows greater formatting flexibility.
The multipart type indicates that the body contains multiple, independent
parts. The Content-Type header field includes a parameter (called boundary) that
defines the delimiter between body parts. This boundary should not appear in
any parts of the message. Each boundary starts on a new line and consists of two
hyphens followed by the boundary value. The final boundary, which indicates the
end of the last part, also has a suffix of two hyphens. Within each part, there may be
an optional ordinary MIME header.
There are four subtypes of the multipart type, all of which have the same
overall syntax. The multipart/mixed subtype is used when there are multiple independent
body parts that need to be bundled in a particular order. For the multipart/
parallel subtype , the order of the parts is not significant. If the recipient’s system is
appropriate, the multiple parts can be presented in parallel. For example, a picture
or text part could be accompanied by a voice commentary that is played while the
picture or text is displayed.
For the multipart/alternative subtype , the various parts are different representations
of the same information.
In this subtype, the body parts are ordered in terms of increasing preference.
For this example, if the recipient system is capable of displaying the message in the
text/enriched format, this is done; otherwise, the plain text format is used.
The multipart/digest subtype is used when each of the body parts is interpreted
as an RFC 5322 message with headers. This subtype enables the construction
of a message whose parts are individual messages. For example, the moderator of a
group might collect e-mail messages from participants, bundle these messages, and
send them out in one encapsulating MIME message.
The message type provides a number of important capabilities in MIME.
The message/rfc822 subtype indicates that the body is an entire message, including
header and body. Despite the name of this subtype, the encapsulated message may
be not only a simple RFC 5322 message, but also any MIME message.
The message/partial subtype enables fragmentation of a large message into a
number of parts, which must be reassembled at the destination. For this subtype,
three parameters are specified in the Content-Type: Message/Partial field: an id
common to all fragments of the same message, a sequence number unique to each
fragment, and the total number of fragments.
The message/external-body subtype indicates that the actual data to be conveyed
in this message are not contained in the body. Instead, the body contains the
information needed to access the data. As with the other message types, the message/
external-body subtype has an outer header and an encapsulated message with
its own header. The only necessary field in the outer header is the Content-Type
field, which identifies this as a message/external-body subtype. The inner header is
the message header for the encapsulated message. The Content-Type field in the
outer header must include an access-type parameter, which indicates the method of
access, such as FTP (file transfer protocol).
The application type refers to other kinds of data, typically either uninterpreted
binary data or information to be processed by a mail-based application.
Table can be found on page 245 in the textbook
15
Table 8.1 M I M E Content Types (2 of 2)
| Type | Subtype | Description |
| blank | Partial | Used to allow fragmentation of large mail items, in a way that is transparent to the recipient. |
| blank Blank | External-body | Contains a pointer to an object that exists elsewhere. |
| Image | jpeg | The image is in J P E G format, J F I F encoding. |
| Blank | gif | The image is in G I F format. |
| Video | mpeg | M P E G format. |
| Audio | Basic | Single-channel 8-bit I S D N mu-law encoding at a sample rate of 8 kHz. |
| Application | PostScript | Adobe Postscript format. |
| blank blank | octet-stream | General binary data consisting of 8-bit bytes. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
The bulk of the MIME specification is concerned with
the definition of a variety of content types. This reflects the need to provide standardized
ways of dealing with a wide variety of information representations in a
multimedia environment.
Table 8.1 lists the content types specified in RFC 2046. There are seven different
major types of content and a total of 15 subtypes. In general, a content type declares the
general type of data, and the subtype specifies a particular format for that type of data.
For the text type of body, no special software is required to get the full meaning
of the text aside from support of the indicated character set. The primary subtype is
plain text , which is simply a string of ASCII characters or ISO 8859 characters. The
enriched subtype allows greater formatting flexibility.
The multipart type indicates that the body contains multiple, independent
parts. The Content-Type header field includes a parameter (called boundary) that
defines the delimiter between body parts. This boundary should not appear in
any parts of the message. Each boundary starts on a new line and consists of two
hyphens followed by the boundary value. The final boundary, which indicates the
end of the last part, also has a suffix of two hyphens. Within each part, there may be
an optional ordinary MIME header.
There are four subtypes of the multipart type, all of which have the same
overall syntax. The multipart/mixed subtype is used when there are multiple independent
body parts that need to be bundled in a particular order. For the multipart/
parallel subtype , the order of the parts is not significant. If the recipient’s system is
appropriate, the multiple parts can be presented in parallel. For example, a picture
or text part could be accompanied by a voice commentary that is played while the
picture or text is displayed.
For the multipart/alternative subtype , the various parts are different representations
of the same information.
In this subtype, the body parts are ordered in terms of increasing preference.
For this example, if the recipient system is capable of displaying the message in the
text/enriched format, this is done; otherwise, the plain text format is used.
The multipart/digest subtype is used when each of the body parts is interpreted
as an RFC 5322 message with headers. This subtype enables the construction
of a message whose parts are individual messages. For example, the moderator of a
group might collect e-mail messages from participants, bundle these messages, and
send them out in one encapsulating MIME message.
The message type provides a number of important capabilities in MIME.
The message/rfc822 subtype indicates that the body is an entire message, including
header and body. Despite the name of this subtype, the encapsulated message may
be not only a simple RFC 5322 message, but also any MIME message.
The message/partial subtype enables fragmentation of a large message into a
number of parts, which must be reassembled at the destination. For this subtype,
three parameters are specified in the Content-Type: Message/Partial field: an id
common to all fragments of the same message, a sequence number unique to each
fragment, and the total number of fragments.
The message/external-body subtype indicates that the actual data to be conveyed
in this message are not contained in the body. Instead, the body contains the
information needed to access the data. As with the other message types, the message/
external-body subtype has an outer header and an encapsulated message with
its own header. The only necessary field in the outer header is the Content-Type
field, which identifies this as a message/external-body subtype. The inner header is
the message header for the encapsulated message. The Content-Type field in the
outer header must include an access-type parameter, which indicates the method of
access, such as FTP (file transfer protocol).
The application type refers to other kinds of data, typically either uninterpreted
binary data or information to be processed by a mail-based application.
Table can be found on page 245 in the textbook
16
Table 8.2 M I M E Transfer Encodings
| 7bit | The data are all represented by short lines of ASCII characters. |
| 8bit | The lines are short, but there may be non-ASCII characters(octets with the high-order bit set). |
| Binary | Not only may non-ASCII characters be present but the lines are not necessarily short enough for S M T P transport. |
| quoted-printable | Encodes the data in such a way that if the data being encoded are mostly ASCII text, the encoded form of the data remains largely recognizable by humans. |
| base64 | Encodes data by mapping 6-bit blocks of input to 8-bit blocks of output, all of which are printable ASCII characters. |
| x-token | A named nonstandard encoding |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
The other major component of the MIME specification,
in addition to content type specification, is a definition of transfer encodings
for message bodies. The objective is to provide reliable delivery across the largest
range of environments.
The MIME standard defines two methods of encoding data. The Content-
Transfer-Encoding field can actually take on six values, as listed in Table 8.2.
However, three of these values (7-bit, 8-bit, and binary) indicate that no encoding
has been done but provide some information about the nature of the data. For
SMTP transfer, it is safe to use the 7-bit form. The 8-bit and binary forms may be
usable in other mail transport contexts. Another Content-Transfer-Encoding value
is x-token, which indicates that some other encoding scheme is used for which
a name is to be supplied. This could be a vendor-specific or application-specific
scheme. The two actual encoding schemes defined are quoted-printable and base64.
Two schemes are defined to provide a choice between a transfer technique that is
essentially human readable and one that is safe for all types of data in a way that is
reasonably compact.
The quoted-printable transfer encoding is useful when the data consists largely
of octets that correspond to printable ASCII characters. In essence, it represents
nonsafe characters by the hexadecimal representation of their code and introduces
reversible (soft) line breaks to limit message lines to 76 characters.
The base64 transfer encoding , also known as radix-64 encoding, is a common
one for encoding arbitrary binary data in such a way as to be invulnerable to the
processing by mail-transport programs. It is also used in PGP and is described in
Appendix H.
Table can be found on page 248 in the textbook
17
Figure 8.3 Example M I M E Message Structure
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 8.3, taken from RFC 2045, is the outline of a complex
multipart message. The message has five parts to be displayed serially: two
introductory plain text parts, an embedded multipart message, a richtext part, and
a closing encapsulated text message in a non-ASCII character set. The embedded
multipart message has two parts to be displayed in parallel: a picture and an audio
fragment. Figure 8.3 can be found on page 249 in the textbook
18
Canonical and Native Forms
Canonical form is a format, appropriate to the content type, that is standardized for use between systems
The entire body, including out-of-band information such as record lengths and possibly file attribute information, is converted to a universal canonical form. The specific media type of the body as well as its associated attributes dictates the nature of the canonical form that is used. Conversion to the proper canonical form may involve character set conversion, transformation of audio data, compression, or various other operations specific to the various media types.
Native form is a format that may be peculiar to a particular system
The body to be transmitted is created in the system’s native format. The native character set is used and, where appropriate, local end-of-line conventions are used as well. The body may be any format that corresponds to the local model for the representation of some form of information.
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
An important concept in MIME and S/MIME is that of canonical
form. Canonical form is a format, appropriate to the content type, that is standardized
for use between systems. This is in contrast to native form, which is a format that
may be peculiar to a particular system. RFC 2049 defines these two forms as follows:
■ Native form: The body to be transmitted is created in the system’s native format.
The native character set is used and, where appropriate, local end-of-line
conventions are used as well. The body may be any format that corresponds to
the local model for the representation of some form of information. Examples
include a UNIX-style text file, or a Sun raster image, or a VMS indexed file, and
audio data in a system-dependent format stored only in memory. In essence,
the data are created in the native form that corresponds to the type specified
by the media type.
■ Canonical form: The entire body, including out-of-band information such as
record lengths and possibly file attribute information, is converted to a universal
canonical form. The specific media type of the body as well as its associated
attributes dictates the nature of the canonical form that is used. Conversion to
the proper canonical form may involve character set conversion, transformation
of audio data, compression, or various other operations specific to the
various media types.
19
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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
For both organizations and individuals, e-mail is both pervasive and especially vulnerable
to a wide range of security threats. In general terms, e-mail security threats
can be classified as follows:
■ 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.
20
Table 8.3 Email Threats and Mitigations (1 of 3)
| Threat | Impact on Purported Sender | Impact on Receiver | Mitigation |
| Email sent by unauthorized M T A in enterprise (e.g. malware botnet) | Loss of reputation, valid email from enterprise may be blocked as possible spam/phishing attack. | U B E and/or email containing malicious links may be delivered into user inboxes | Deployment of domain-based authentication techniques. Use of digital signatures over email. |
| Email message sent using spoofed or unregistered sending domain | Loss of reputation, valid email from enterprise may be blocked as possible spam/phishing attack. | U B E and/or email containing malicious links may be delivered into user inboxes | Deployment of domain-based authentication techniques. Use of digital signatures over email. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
A useful list of specific e-mail threats, together with approaches to mitigation,
is provided in SP 800-177 (Trustworthy E-mail , September 2015) and is shown in
Table 8.3.
SP 800-177 recommends use of a variety of standardized protocols as a means
for countering these threats. These include:
■ 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 e-mail
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.
■■ 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. It is a simple matter
for receivers to check the SPF TXT record in the DNS to confirm that the purported
sender of a message is permitted to use that source address and reject
mail that does not come from an authorized IP address.
■ 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.
Table can be found on page 251 in the textbook
21
Table 8.3 Email Threats and Mitigations (2 of 3)
| Threat | Impact on Purported Sender | Impact on Receiver | Mitigation |
| Email message sent using forged sending address or email address (i.e. phishing, spear phishing) | Loss of reputation, valid email from enterprise may be blocked as possible spam/phishing attack. | U B E and/or email containing malicious links may be delivered. Users may inadvertently divulge sensitive information or P I I. | Deployment of domain-based authentication techniques. Use of digital signatures over email. |
| Email modified in transit | Leak of sensitive information or P I I. | Leak of sensitive information, altered message may contain malicious information | Use of T L S to encrypt email transfer between server. Use of end-to-end email encryption. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
A useful list of specific e-mail threats, together with approaches to mitigation,
is provided in SP 800-177 (Trustworthy E-mail , September 2015) and is shown in
Table 8.3.
SP 800-177 recommends use of a variety of standardized protocols as a means
for countering these threats. These include:
■ 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 e-mail
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.
■■ 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. It is a simple matter
for receivers to check the SPF TXT record in the DNS to confirm that the purported
sender of a message is permitted to use that source address and reject
mail that does not come from an authorized IP address.
■ 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.
Table can be found on page 251 in the textbook
22
Table 8.3 Email Threats and Mitigations (3 of 3)
| Threat | Impact on Purported Sender | Impact on Receiver | Mitigation |
| Disclosure of sensitive information (e.g. P l l) via monitoring and capturing of email traffic | Leak of sensitive information or P I I. | Leak of sensitive information, altered message may contain malicious information | Use of T L S to encrypt email transfer between server. Use of end-to-end email encryption. |
| Unsolicited Bulk Email (i.e. spam) | None, unless purported sender is spoofed. | U B E and/or email containing malicious links may be delivered into user inboxes | Techniques to address U B E |
| D o S/D D o S attack against an enterprises’ email servers | Inability to send email. | Inability to receive email. | Multiple mail servers, use of cloud-based email providers. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
A useful list of specific e-mail threats, together with approaches to mitigation,
is provided in SP 800-177 (Trustworthy E-mail , September 2015) and is shown in
Table 8.3.
SP 800-177 recommends use of a variety of standardized protocols as a means
for countering these threats. These include:
■ 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 e-mail
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.
■■ 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. It is a simple matter
for receivers to check the SPF TXT record in the DNS to confirm that the purported
sender of a message is permitted to use that source address and reject
mail that does not come from an authorized IP address.
■ 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.
Table can be found on page 251 in the textbook
23
Figure 8.4 The Interrelationship of D N S S E C, S P F, D K I M, D M A R C, D A N E and S/M I M E for assuring message authenticity and integrity
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 8.4 shows how these components interact to provide message authenticity
and integrity. Not shown, for simplicity, is that S/MIME also provides message
confidentiality by encrypting messages.
24
S/M I M E
Secure/Multipurpose Internet Mail Extension
Is a security enhancement to the M I M E Internet e-mail format standard based on technology from R S A Data Security
S/M I M E is a complex capability that is defined in a number of documents
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Secure/Multipurpose Internet Mail Extension (S/MIME) is a security enhancement
to the MIME Internet e-mail format standard based on technology from RSA Data
Security. S/MIME is a complex capability that is defined in a number of documents.
The most important documents relevant to S/MIME include the following:
■ RFC 5750, S/MIME Version 3.2 Certificate Handling: Specifies conventions
for X.509 certificate usage by (S/MIME) v3.2.
■ RFC 5751, S/MIME) Version 3.2 Message Specification: The principal defining
document for S/MIME message creation and processing.
■ RFC 4134, Examples of S/MIME Messages: Gives examples of message bodies
formatted using S/MIME.
■ RFC 2634, Enhanced Security Services for S/MIME: Describes four optional
security service extensions for S/MIME.
■ RFC 5652, Cryptographic Message Syntax (CMS): Describes the Cryptographic
Message Syntax (CMS). This syntax is used to digitally sign, digest,
authenticate, or encrypt arbitrary message content.
■ RFC 3370, CMS Algorithms: Describes the conventions for using several
cryptographic
algorithms with the CMS.
■ RFC 5752, Multiple Signatures in CMS: Describes the use of multiple, parallel
signatures for a message.
■ RFC 1847, Security Multiparts for MIME—Multipart/Signed and Multipart/
Encrypted: Defines a framework within which security services may be applied
to MIME body parts. The use of a digital signature is relevant to S/MIME, as
explained subsequently.
25
Table 8.4 Summary of S/M I M E Services (1 of 2)
| Function | Typical Algorithm | Typical Action |
| Digital signature | R S A/S H A-256 | A hash code of a message is created using S H A-256. This message digest is encrypted using S H A-256 with the senders private key and included with the message. |
| Message encryption | A E S- 128 with C B C | A message is encrypted using A E S-128 with C B C with a one-time session key generated by the sender. The session key is encrypted using R S A with the recipient’s public key and included with the message. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
S/MIME provides for four message-related services: authentication, confidentiality,
compression, and e-mail compatibility (Table 8.4). This subsection provides
an overview. We then look in more detail at this capability by examining message
formats and message preparation.
26
Table 8.4 Summary of S/M I M E Services (2 of 2)
| Function | Typical Algorithm | Typical Action |
| Compression | unspecified | A message may be compressed for storage or transmission. |
| E-mail compatibility | Radix-64 conversion | To provide transparency for e-mail applications, an encrypted message may be converted to an ASCII string using radix-64 conversion. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
S/MIME provides for four message-related services: authentication, confidentiality,
compression, and e-mail compatibility (Table 8.4). This subsection provides
an overview. We then look in more detail at this capability by examining message
formats and message preparation.
27
Authentication
Authentication is provided by means of a digital signature
Most commonly R S A with S H A-256 is used
The sender creates a message
S H A-256 is used to generate a 256-bit message digest of the message
The message digest is encrypted with R S A 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 R S A 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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Authentication is provided by means of a digital signature,
using the general scheme discussed in Chapter 3 and illustrated in Figure 3.15. Most
commonly RSA with SHA-256 is used. The sequence is as follows:
The sender creates a message.
SHA-256 is used to generate a 256-bit message digest of the message.
3. 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.
4. The receiver uses RSA with the sender’s public key to decrypt and recover the
message digest.
5. 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.
The combination of SHA-256 and RSA provides an effective digital signature
scheme. Because of the strength of RSA, the recipient is assured that only the possessor
of the matching private key can generate the signature. Because of the strength
of SHA-256, the recipient is assured that no one else could generate a new message
that matches the hash code and, hence, the signature of the original message.
Although signatures normally are found attached to the message or file that
they sign, this is not always the case: Detached signatures are supported. A detached
signature may be stored and transmitted separately from the message it signs. This
is useful in several contexts. A user may wish to maintain a separate signature log
of all messages sent or received. A detached signature of an executable program
can detect subsequent virus infection. Finally, detached signatures can be used
when more than one party must sign a document, such as a legal contract. Each
person’s signature is independent and therefore is applied only to the document.
Otherwise, signatures would have to be nested, with the second signer signing both
the document and the first signature, and so on.
28
Confidentiality (1 of 2)
S/M I M E provides confidentiality by encrypting messages
Most commonly A E S with a 128-bit key is used, with the cipher block chaining (C B C) mode
The key itself is also encrypted, typically with R S A
In S/M I M E 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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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, as explained below.
As always, one must address the problem of key distribution. In S/MIME,
each symmetric key, referred to as a content-encryption key, is used only once. That
is, a new key is generated as a random number for each message. Because it is to be
used only once, the content-encryption key is bound to the message and transmitted
with it. To protect the key, it is encrypted with the receiver’s public key. The
sequence can be described as follows:
1. The sender generates a message and a random 128-bit number to be used as a
content-encryption key for this message only.
2. The message is encrypted using the content-encryption key.
3. 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.
5. The content-encryption key is used to decrypt the message.
Several observations may be made. First, to reduce encryption time, the combination
of symmetric and public-key encryption is used in preference to simply
using public-key encryption to encrypt the message directly: Symmetric algorithms
are substantially faster than asymmetric ones for a large block of content. Second,
the use of the public-key algorithm solves the session-key distribution problem,
because only the recipient is able to recover the session key that is bound to the
message. Note that we do not need a session-key exchange protocol of the type
discussed in Chapter 4, because we are not beginning an ongoing session. Rather,
each message is a one-time independent event with its own key. Furthermore, given
the store-and-forward nature of electronic mail, the use of handshaking to assure
that both sides have the same session key is not practical. Finally, the use of onetime
symmetric keys strengthens what is already a strong symmetric encryption
approach. Only a small amount of plaintext is encrypted with each key, and there is
no relationship among the keys. Thus, to the extent that the public-key algorithm is
secure, the entire scheme is secure.
29
Confidentiality (2 of 2)
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 R S A using the recipient’s public key and is attached to the message
The receiver uses R S A with its private key to decrypt and recover the content-encryption key
The content-encryption key is used to decrypt the message
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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, as explained below.
As always, one must address the problem of key distribution. In S/MIME,
each symmetric key, referred to as a content-encryption key, is used only once. That
is, a new key is generated as a random number for each message. Because it is to be
used only once, the content-encryption key is bound to the message and transmitted
with it. To protect the key, it is encrypted with the receiver’s public key. The
sequence can be described as follows:
1. The sender generates a message and a random 128-bit number to be used as a
content-encryption key for this message only.
2. The message is encrypted using the content-encryption key.
3. 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.
5. The content-encryption key is used to decrypt the message.
Several observations may be made. First, to reduce encryption time, the combination
of symmetric and public-key encryption is used in preference to simply
using public-key encryption to encrypt the message directly: Symmetric algorithms
are substantially faster than asymmetric ones for a large block of content. Second,
the use of the public-key algorithm solves the session-key distribution problem,
because only the recipient is able to recover the session key that is bound to the
message. Note that we do not need a session-key exchange protocol of the type
discussed in Chapter 4, because we are not beginning an ongoing session. Rather,
each message is a one-time independent event with its own key. Furthermore, given
the store-and-forward nature of electronic mail, the use of handshaking to assure
that both sides have the same session key is not practical. Finally, the use of onetime
symmetric keys strengthens what is already a strong symmetric encryption
approach. Only a small amount of plaintext is encrypted with each key, and there is
no relationship among the keys. Thus, to the extent that the public-key algorithm is
secure, the entire scheme is secure.
30
Figure 8.5 Simplified S/M I M E Functional Flow
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
As Figure 8.5 illustrates, both confidentiality
and encryption may be used for the same message. The figure shows a sequence
in which a signature is generated for the plaintext message and appended to the
message. Then the plaintext message and signature are encrypted as a single block
using symmetric encryption and the symmetric encryption key is encrypted using
public-key encryption.
S/MIME allows the signing and message encryption operations to be performed
in either order. If signing is done first, the identity of the signer is hidden
by the encryption. Plus, it is generally more convenient to store a signature with a
plaintext version of a message. Furthermore, for purposes of third-party verification,
if the signature is performed first, a third party need not be concerned with the
symmetric key when verifying the signature.
If encryption is done first, it is possible to verify a signature without exposing
the message content. This can be useful in a context in which automatic signature
verification is desired, as no private key material is required to verify a signature.
However, in this case the recipient cannot determine any relationship between the
signer and the unencrypted content of the message.
31
E-mail Compatibility
Many electronic mail systems only permit the use of blocks consisting of A S C I I text
To accommodate this restriction, S/M I M E provides the service of converting the raw 8-bit binary stream to a stream of printable A S C I I 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 A S C I I characters
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
When S/MIME is used, at least part of the block to be transmitted
is encrypted. If only the signature service is used, then the message digest is
encrypted (with the sender’s private key). If the confidentiality service is used, the
message plus signature (if present) are encrypted (with a one-time symmetric key).
Thus, part or all of the resulting block consists of a stream of arbitrary 8-bit octets.
However, 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. See Appendix K for
a description.
One noteworthy aspect of the Base64 algorithm is that it blindly converts the
input stream to Base64 format regardless of content, even if the input happens to
be ASCII text. Thus, if a message is signed but not encrypted and the conversion
is applied to the entire block, the output will be unreadable to the casual observer,
which provides a certain level of confidentiality.
RFC 5751 also recommends that even if outer 7-bit encoding is not used, the
original MIME content should be 7-bit encoded. The reason for this is that it allows
the MIME entity to be handled in any environment without changing it. For example,
a trusted gateway might remove the encryption, but not the signature, of a message,
and then forward the signed message on to the end recipient so that they can
verify the signatures directly. If the transport internal to the site is not 8-bit clean,
such as on a wide area network with a single mail gateway, verifying the signature
will not be possible unless the original MIME entity was only 7-bit data.
32
Compression
S/M I M E also offers the ability to compress a message
This has the benefit of saving space both for e-mail transmission and for file storage
Compression can be applied in any order with respect to the signing and message encryption operations
R F C 5751 provides the following guidelines:
Compression of binary encoded encrypted data is discouraged, since it will not yield significant compression; Base64 encrypted data could very well benefit, however
If a lossy compression algorithm is used with signing, you will need to compress first, then sign
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
S/MIME also offers the ability to compress a message. This has
the benefit of saving space both for e-mail transmission and for file storage.
Compression can be applied in any order with respect to the signing and message
encryption operations.
RFC 5751 provides the following guidelines:
■ Compression of binary encoded encrypted data is discouraged, since it will not
yield significant compression. Base64 encrypted data could very well benefit,
however.
■ If a lossy compression algorithm is used with signing, you will need to compress
first, then sign.
33
S/M I M E Message Content Types (1 of 2)
S/M I M E uses the following message content types, which are defined in R F C 5652, Cryptographic Message Syntax
Data
Refers to the inner M I M E-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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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 encryptedcontent
encryption keys for one or more recipients.
■ CompressedData: Used to apply data compression to a message.
The Data content type is also used for a procedure known as clear signing.
For clear signing, a digital signature is calculated for a MIME-encoded message and
the two parts, the message and signature, form a multipart MIME message. Unlike
SignedData, which involves encapsulating the message and signature in a special
format, clear-signed messages can be read and their signatures verified by e-mail
entities that do not implement S/MIME.
34
S/M I M E Message Content Types (2 of 2)
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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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 encryptedcontent
encryption keys for one or more recipients.
■ CompressedData: Used to apply data compression to a message.
The Data content type is also used for a procedure known as clear signing.
For clear signing, a digital signature is calculated for a MIME-encoded message and
the two parts, the message and signature, form a multipart MIME message. Unlike
SignedData, which involves encapsulating the message and signature in a special
format, clear-signed messages can be read and their signatures verified by e-mail
entities that do not implement S/MIME.
35
Table 8.5 Cryptographic Algorithms Used in S/M I M E (1 of 2)
| Function | Requirement |
| Create a message digest to be used in forming a digital signature. | Must support S H A-256 Should support S H A-I Receiver Should support M D5 for backward compatibility |
| Use message digest to form a digital signature. | Must support R S A with S H A-256 Should support D S A with S H A-256 R S A S S A.P S S with S H A-256 R S A with S H A-I D S A with S H A-I R S A with M D S |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 8.5 summarizes the cryptographic algorithms used in S/MIME. S/MIME uses
the following terminology taken from RFC 2119 (Key Words for use in RFCs to
Indicate Requirement Levels , March 1997) to specify the requirement level:
■ MUST: The definition is an absolute requirement of the specification. An
implementation
must include this feature or function to be in conformance
with the specification.
■ SHOULD: There may exist valid reasons in particular circumstances to ignore
this feature or function, but it is recommended that an implementation include
the feature or function.
The S/MIME specification includes a discussion of the procedure for deciding
which content encryption algorithm to use. In essence, a sending agent has two decisions
to make. First, the sending agent must determine if the receiving agent is capable
of decrypting using a given encryption algorithm. Second, if the receiving agent is only
capable of accepting weakly encrypted content, the sending agent must decide if it is
acceptable to send using weak encryption. To support this decision process, a sending
agent may announce its decrypting capabilities in order of preference for any message
that it sends out. A receiving agent may store that information for future use.
The following rules, in the following order, should be followed by a sending agent.
1. If the sending agent has a list of preferred decrypting capabilities from an
intended recipient, it SHOULD choose the first (highest preference) capability
on the list that it is capable of using.
2. If the sending agent has no such list of capabilities from an intended recipient
but has received one or more messages from the recipient, then the outgoing
message SHOULD use the same encryption algorithm as was used on the last
signed and encrypted message received from that intended recipient.
3. If the sending agent has no knowledge about the decryption capabilities of the
intended recipient and is willing to risk that the recipient may not be able to
decrypt the message, then the sending agent SHOULD use triple DES.
4. If the sending agent has no knowledge about the decryption capabilities of the
intended recipient and is not willing to risk that the recipient may not be able
to decrypt the message, then the sending agent MUST use RC2/40.
If a message is to be sent to multiple recipients and a common encryption
algorithm cannot be selected for all, then the sending agent will need to send two
messages. However, in that case, it is important to note that the security of the
message is made vulnerable by the transmission of one copy with lower security.
36
Table 8.5 Cryptographic Algorithms Used in S/M I M E (2 of 2)
| Function | Requirement |
| Encrypt session key for transmission with a message. | Must support R S A encryption Should support R S A E S-O A E P Diffie-Hellman ephemeral-static mode |
| Encrypt message for transmission with a one-time session key. | Must support A E S-128 with C B C Should support A E S-192 CBC and A E S-256 C B C Triple D E S C B C |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 8.5 summarizes the cryptographic algorithms used in S/MIME. S/MIME uses
the following terminology taken from RFC 2119 (Key Words for use in RFCs to
Indicate Requirement Levels , March 1997) to specify the requirement level:
■ MUST: The definition is an absolute requirement of the specification. An
implementation
must include this feature or function to be in conformance
with the specification.
■ SHOULD: There may exist valid reasons in particular circumstances to ignore
this feature or function, but it is recommended that an implementation include
the feature or function.
The S/MIME specification includes a discussion of the procedure for deciding
which content encryption algorithm to use. In essence, a sending agent has two decisions
to make. First, the sending agent must determine if the receiving agent is capable
of decrypting using a given encryption algorithm. Second, if the receiving agent is only
capable of accepting weakly encrypted content, the sending agent must decide if it is
acceptable to send using weak encryption. To support this decision process, a sending
agent may announce its decrypting capabilities in order of preference for any message
that it sends out. A receiving agent may store that information for future use.
The following rules, in the following order, should be followed by a sending agent.
1. If the sending agent has a list of preferred decrypting capabilities from an
intended recipient, it SHOULD choose the first (highest preference) capability
on the list that it is capable of using.
2. If the sending agent has no such list of capabilities from an intended recipient
but has received one or more messages from the recipient, then the outgoing
message SHOULD use the same encryption algorithm as was used on the last
signed and encrypted message received from that intended recipient.
3. If the sending agent has no knowledge about the decryption capabilities of the
intended recipient and is willing to risk that the recipient may not be able to
decrypt the message, then the sending agent SHOULD use triple DES.
4. If the sending agent has no knowledge about the decryption capabilities of the
intended recipient and is not willing to risk that the recipient may not be able
to decrypt the message, then the sending agent MUST use RC2/40.
If a message is to be sent to multiple recipients and a common encryption
algorithm cannot be selected for all, then the sending agent will need to send two
messages. However, in that case, it is important to note that the security of the
message is made vulnerable by the transmission of one copy with lower security.
37
S/M I M E Content Types –EnvelopedData
The steps for preparing an envelopedData M I M E entity are:
Generate a pseudorandom session key for a particular symmetric encryption algorithm (R C 2/40 or triple D E S)
For each recipient, encrypt the session key with the recipient’s public R S 2 A 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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
An application/pkcs7-mime subtype is used for one of four categories
of S/MIME processing, each with a unique smime-type parameter. In all
cases, the resulting entity, (referred to as an object ) is represented in a form known
as Basic Encoding Rules (BER), which is defined in ITU-T Recommendation
X.209. The BER format consists of arbitrary octet strings and is therefore binary
data. Such an object should be transfer encoded with base64 in the outer MIME
message. We first look at envelopedData.
The steps for preparing an envelopedData MIME entity are:
1. Generate a pseudorandom session key for a particular symmetric encryption
algorithm (RC2/40 or triple DES).
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.
Encrypt the message content with the session key.
The RecipientInfo blocks followed by the encrypted content constitute the
envelopedData . This information is then encoded into base64. A sample message
(excluding the RFC 5322 headers) is given below.
Content-Type: application/pkcs7-mime; smime-type=envelopeddata;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V
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.
38
S/M I M E Content Types- SignedData
The steps for preparing a signedData M I M E entity are as follows:
Select a message digest algorithm (S H A or M D 5)
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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
The signedData smime-type can be used with one or more signers.
For clarity, we confine our description to the case of a single digital signature. The
steps for preparing a signedData MIME entity are as follows.
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 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.
The signedData entity consists of a series of blocks, including a message
digest algorithm identifier, the message being signed, and SignerInfo . The
signedData entity may also include a set of public-key certificates sufficient to
constitute a chain from a recognized root or top-level certification authority to the
signer. This information is then encoded into base64. A sample message (excluding
the RFC 5322 headers) is the following.
Content-Type: application/pkcs7-mime; smime-type=signeddata;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75
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.
39
S/M I M E Certificate Processing (1 of 2)
A S/M I M E 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 D S S key pairs and Should be capable of generating R S A 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 R S A key pairs with a length in the range of 768 to 1024 bits and Must Not generate a length of less than 512 bits
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
S/MIME uses public-key certificates that conform to version 3 of X.509 (see Chapter 4).
S/MIME managers and/or users must configure each client with a list of trusted keys
and with certificate revocation lists. That is, the responsibility is local for maintaining
the certificates needed to verify incoming signatures and to encrypt outgoing messages.
On the other hand, the certificates are signed by certification authorities.
An S/MIME user has several key management functions to
perform.
■ Key generation: The user of some related administrative utility (e.g., one
associated with LAN management) 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.
40
S/M I M E Certificate Processing (2 of 2)
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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
S/MIME uses public-key certificates that conform to version 3 of X.509 (see Chapter 4).
S/MIME managers and/or users must configure each client with a list of trusted keys
and with certificate revocation lists. That is, the responsibility is local for maintaining
the certificates needed to verify incoming signatures and to encrypt outgoing messages.
On the other hand, the certificates are signed by certification authorities.
An S/MIME user has several key management functions to
perform.
■ Key generation: The user of some related administrative utility (e.g., one
associated with LAN management) 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.
41
Enhanced Security Services (1 of 3)
R F C 2634 defines four enhanced security services for S/M I M E:
Signed receipts
A signed receipt may be requested in a SignedData object
Returning a signed receipt provides proof of delivery to the originator of a message and allows the originator to demonstrate to a third party that the recipient received the message
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
RFC 2634 defines four enhanced security services for S/MIME:
■ Signed receipts: A signed receipt may be requested in a SignedData object.
Returning a signed receipt provides proof of delivery to the originator of a
message and allows the originator to demonstrate to a third party that the
recipient received the message. In essence, the recipient signs the entire
original message plus the original (sender’s) signature and appends the new
signature to form a new S/MIME message.
■ Security labels: A security label may be included in the authenticated attributes
of a SignedData object. A security label is a set of security information
regarding the sensitivity of the content that is protected by S/MIME encapsulation.
The labels may be used for access control, by indicating which users are
permitted access to an object. Other uses include priority (secret, confidential,
restricted, and so on) or role based, describing which kind of people can see
the information (e.g., patient’s health-care team, medical billing agents).
■ Secure mailing lists: When a user sends a message to multiple recipients, a
certain amount of per-recipient processing is required, including the use of
each recipient’s public key. The user can be relieved of this work by employing
the services of an S/MIME Mail List Agent (MLA). An MLA can take a
single incoming message, perform the recipient-specific encryption for each
recipient, and forward the message. The originator of a message need only
send the message to the MLA with encryption performed using the MLA’s
public key.
■ Signing certificates: This service is used to securely bind a sender’s certificate
to their signature through a signing certificate attribute.
42
Enhanced Security Services (2 of 3)
Security labels
A set of security information regarding the sensitivity of the content that is protected by S/M I M E encapsulation
The labels may be used for access control, by indicating which users are permitted access to an object
Other uses include priority or role based, describing which kind of people can see the information
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
RFC 2634 defines four enhanced security services for S/MIME:
■ Signed receipts: A signed receipt may be requested in a SignedData object.
Returning a signed receipt provides proof of delivery to the originator of a
message and allows the originator to demonstrate to a third party that the
recipient received the message. In essence, the recipient signs the entire
original message plus the original (sender’s) signature and appends the new
signature to form a new S/MIME message.
■ Security labels: A security label may be included in the authenticated attributes
of a SignedData object. A security label is a set of security information
regarding the sensitivity of the content that is protected by S/MIME encapsulation.
The labels may be used for access control, by indicating which users are
permitted access to an object. Other uses include priority (secret, confidential,
restricted, and so on) or role based, describing which kind of people can see
the information (e.g., patient’s health-care team, medical billing agents).
■ Secure mailing lists: When a user sends a message to multiple recipients, a
certain amount of per-recipient processing is required, including the use of
each recipient’s public key. The user can be relieved of this work by employing
the services of an S/MIME Mail List Agent (MLA). An MLA can take a
single incoming message, perform the recipient-specific encryption for each
recipient, and forward the message. The originator of a message need only
send the message to the MLA with encryption performed using the MLA’s
public key.
■ Signing certificates: This service is used to securely bind a sender’s certificate
to their signature through a signing certificate attribute.
43
Enhanced Security Services (3 of 3)
Secure mailing lists
A Mail List Agent (M L A) can take a single incoming message, perform the recipient-specific encryption for each recipient, and forward the message
Signing certificates
This service is used to securely bind a sender’s certificate to their signature through a signing certificate attribute
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
RFC 2634 defines four enhanced security services for S/MIME:
■ Signed receipts: A signed receipt may be requested in a SignedData object.
Returning a signed receipt provides proof of delivery to the originator of a
message and allows the originator to demonstrate to a third party that the
recipient received the message. In essence, the recipient signs the entire
original message plus the original (sender’s) signature and appends the new
signature to form a new S/MIME message.
■ Security labels: A security label may be included in the authenticated attributes
of a SignedData object. A security label is a set of security information
regarding the sensitivity of the content that is protected by S/MIME encapsulation.
The labels may be used for access control, by indicating which users are
permitted access to an object. Other uses include priority (secret, confidential,
restricted, and so on) or role based, describing which kind of people can see
the information (e.g., patient’s health-care team, medical billing agents).
■ Secure mailing lists: When a user sends a message to multiple recipients, a
certain amount of per-recipient processing is required, including the use of
each recipient’s public key. The user can be relieved of this work by employing
the services of an S/MIME Mail List Agent (MLA). An MLA can take a
single incoming message, perform the recipient-specific encryption for each
recipient, and forward the message. The originator of a message need only
send the message to the MLA with encryption performed using the MLA’s
public key.
■ Signing certificates: This service is used to securely bind a sender’s certificate
to their signature through a signing certificate attribute.
44
Pretty Good Privacy (P G P) (1 of 2)
An alternative e-mail security protocol
Has essentially the same functionality as S/M I M E
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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
An alternative e-mail security protocol is Pretty Good Privacy (PGP), 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 quite popular for personal use. The initial PGP protocol was
proprietary and used some encryption algorithms with intellectual property restrictions.
In 1996, version 5.x of PGP was defined in IETF RFC 1991, PGP Message
Exchange Formats . Subsequently, OpenPGP was developed as a new standard
protocol based on PGP version 5.x. OpenPGP is defined in RFC 4880 (OpenPGP
Message Format , November 2007) and RFC 3156 (MIME Security with OpenPGP ,
August 2001).
There are two significant differences between S/MIME and OpenPGP:
■ Key Certification: S/MIME uses X.509 certificates that are issued by Certificate
Authorities (or local agencies that have been delegated authority by a CA to
issue certificates). In OpenPGP, users generate their own OpenPGP public
and private keys and then solicit signatures for their public keys from individuals
or organizations to which they are known. Whereas X.509 certificates are
trusted if there is a valid PKIX chain to a trusted root, an OpenPGP public key
is trusted if it is signed by another OpenPGP public key that is trusted by the
recipient. This is called the Web-of-Trust .
■ Key Distribution: OpenPGP does not include the sender’s public key with
ach message, so it is necessary for recipients of OpenPGP messages to separately
obtain the sender’s public key in order to verify the message. Many
organizations post OpenPGP keys on TLS-protected websites: People who
wish to verify digital signatures or send these organizations encrypted mail
need to manually download these keys and add them to their OpenPGP
Clients. Keys may also be registered with the OpenPGP public key servers,
which are servers that maintain a database of PGP public keys organized by
e-mail address. Anyone may post a public key to the OpenPGP key servers,
and that public key may contain any e-mail address. There is no vetting of
OpenPGP keys, so users must use the Web-of-Trust to decide whether to trust
a given public key.
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.
Appendix H provides an overview of PGP.
45
Pretty Good Privacy (P G P) (2 of 2)
The initial P G P protocol was proprietary and used some encryption algorithms with intellectual property restriction
There are two significant differences between S/M I M E and OpenP G P:
Key certification
Key distribution
S P 800-177 recommends the use of S/M I M E rather than P G P because of the greater confidence in the C A system of verifying public keys
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
An alternative e-mail security protocol is Pretty Good Privacy (PGP), 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 quite popular for personal use. The initial PGP protocol was
proprietary and used some encryption algorithms with intellectual property restrictions.
In 1996, version 5.x of PGP was defined in IETF RFC 1991, PGP Message
Exchange Formats . Subsequently, OpenPGP was developed as a new standard
protocol based on PGP version 5.x. OpenPGP is defined in RFC 4880 (OpenPGP
Message Format , November 2007) and RFC 3156 (MIME Security with OpenPGP ,
August 2001).
There are two significant differences between S/MIME and OpenPGP:
■ Key Certification: S/MIME uses X.509 certificates that are issued by Certificate
Authorities (or local agencies that have been delegated authority by a CA to
issue certificates). In OpenPGP, users generate their own OpenPGP public
and private keys and then solicit signatures for their public keys from individuals
or organizations to which they are known. Whereas X.509 certificates are
trusted if there is a valid PKIX chain to a trusted root, an OpenPGP public key
is trusted if it is signed by another OpenPGP public key that is trusted by the
recipient. This is called the Web-of-Trust .
■ Key Distribution: OpenPGP does not include the sender’s public key with
ach message, so it is necessary for recipients of OpenPGP messages to separately
obtain the sender’s public key in order to verify the message. Many
organizations post OpenPGP keys on TLS-protected websites: People who
wish to verify digital signatures or send these organizations encrypted mail
need to manually download these keys and add them to their OpenPGP
Clients. Keys may also be registered with the OpenPGP public key servers,
which are servers that maintain a database of PGP public keys organized by
e-mail address. Anyone may post a public key to the OpenPGP key servers,
and that public key may contain any e-mail address. There is no vetting of
OpenPGP keys, so users must use the Web-of-Trust to decide whether to trust
a given public key.
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.
Appendix H provides an overview of PGP.
46
Domain Name System (D N S) (1 of 2)
A directory lookup service that provides a mapping between the name of a host on the Internet and its numeric I P address
Is essential to the functioning of the Internet
Is used by M U As and M T As to find the address of the next hop server for mail delivery
Comprised of four elements:
Domain name space
D N S uses a tree-structured name space to identify resources on the Internet
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
DNS is a directory lookup service that provides a mapping between the name of a
host on the Internet and its numeric IP address. DNS is essential to the functioning
of the Internet. The DNS is used by MUAs and MTAs to find the address of the
next hop server for mail delivery. Sending MTAs query DNS for the Mail Exchange
Resource Record (MX RR) of the recipient’s domain (the right hand side of the
“@” symbol) in order to find the receiving MTA to contact.
Four elements comprise the DNS:
■ 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 (e.g., IP address, name server for this domain
name) 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.
47
Domain Name System (D N S) (2 of 2)
D N S 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 R Rs 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 R Rs
Resolvers
These are programs that extract information from name servers in response to client requests. A typical client request is for an I P address corresponding to a given domain name
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
DNS is a directory lookup service that provides a mapping between the name of a
host on the Internet and its numeric IP address. DNS is essential to the functioning
of the Internet. The DNS is used by MUAs and MTAs to find the address of the
next hop server for mail delivery. Sending MTAs query DNS for the Mail Exchange
Resource Record (MX RR) of the recipient’s domain (the right hand side of the
“@” symbol) in order to find the receiving MTA to contact.
Four elements comprise the DNS:
■ 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 (e.g., IP address, name server for this domain
name) 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.
48
D N S Database (1 of 2)
D N S is based on a hierarchical database containing resource records (R Rs) that include the name, I P address, and other information about hosts
Key features of the database:
Variable-depth hierarchy for names
D N S allows essentially unlimited levels and uses the period (.) as the level delimiter in printed names
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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 as follows:
■ Variable-depth hierarchy for names: DNS allows essentially unlimited levels
and uses the period (.) as the level delimiter in printed names, as described
earlier.
■ Distributed database: The database resides in DNS servers scattered throughout
the Internet.
■ Distribution controlled by the database: The DNS database is divided into
thousands of separately managed zones, which are managed by separate
administrators.
Distribution and update of records is controlled by the database
software.
Using this database, DNS servers provide a name-to-address directory service
for network applications that need to locate specific servers. For example, every
time an e-mail message is sent or a Web page is accessed, there must be a DNS
name lookup to determine the IP address of the e-mail server or Web server.
49
D N S Database (2 of 2)
Distributed database
The database resides in D N S servers scattered throughout the Internet
Distribution controlled by the database
The D N S database is divided into thousands of separately managed zones, which are managed by separate administrators
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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 as follows:
■ Variable-depth hierarchy for names: DNS allows essentially unlimited levels
and uses the period (.) as the level delimiter in printed names, as described
earlier.
■ Distributed database: The database resides in DNS servers scattered throughout
the Internet.
■ Distribution controlled by the database: The DNS database is divided into
thousands of separately managed zones, which are managed by separate
administrators.
Distribution and update of records is controlled by the database
software.
Using this database, DNS servers provide a name-to-address directory service
for network applications that need to locate specific servers. For example, every
time an e-mail message is sent or a Web page is accessed, there must be a DNS
name lookup to determine the IP address of the e-mail server or Web server.
50
Table 8.6 Resource Record Types (1 of 3)
| Type | Description |
| A | A host address. This R R type maps the name of a system to its I Pv4 address. Some systems (e.g.. routers) have multiple addresses, and there is a separate R R for each. |
| A A A A | Similar to A type, but for I Pv6 addresses. |
| C N A M E | Canonical name. Specifies an alias name for a host and maps this to the canonical (true) name. |
| H I N F O | Host information. Designates the processor and operating system used by the host. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 8.6 lists the various types of resource records.
51
Table 8.6 Resource Record Types (2 of 3)
| Type | Description |
| MINFO | Mailbox or mail list information. Maps a mailbox or mail list name to a host name. |
| MX | Mail exchange. Identifies the system(s) via which mail to the queried domain name should be relayed. |
| NS | Authoritative name server for this domain. |
| PTR | Domain name pointer. Points to another part of the domain name space. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 8.6 lists the various types of resource records.
52
Table 8.6 Resource Record Types (3 of 3)
| Type | Description |
| S O A | Start of a zone of authority (which part of naming hierarchy is implemented). Includes parameters related to this zone. |
| S R V | For a given service provides name of server or servers in domain that provide that service. |
| T X T | Arbitrary text. Provides a way to add text comments to the database. |
| W K S | Well-known services. May list the application services available at this host. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 8.6 D N S Name Resolution
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
DNS operation typically includes the following steps (Figure 8.6):
1. A user program requests an IP address for a domain name.
2. A resolver module in the local host or local ISP queries a local name server in
the same domain as the resolver.
3. The local name server checks to see if the name is in its local database or cache,
and, if so, returns the IP address to the requestor. Otherwise, the name server
queries other available name servers, if necessary going to the root server, as
explained subsequently.
4. When a response is received at the local name server, it stores the name/address
mapping in its local cache and may maintain this entry for the amount
of time specified in the time-to-live field of the retrieved RR.
The user program is given the IP address or an error message.
The distributed DNS database that supports the DNS functionality must be
updated frequently because of the rapid and continued growth of the Internet.
Further, the DNS must cope with dynamic assignment of IP addresses, such as is
done for home DSL users by their ISP. Accordingly, dynamic updating functions
for DNS have been defined. In essence, DNS name servers automatically send out
updates to other relevant name servers as conditions warrant.
54
D N S Security Extensions (1 of 2)
D N S S E C:
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 D N S 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 D N S protocol
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
55
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. In particular, DNSSEC 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. DNSSEC consists of
a set of new resource record types and modifications to the existing DNS protocol,
and is defined in the following documents:
■ RFC 4033, DNS Security Introduction and Requirements: Introduces the
DNS security extensions and describes their capabilities and limitations. The
document also discusses the services that the DNS security extensions do and
do not provide.
■ RFC 4034, Resource Records for the DNS Security Extensions: Defines four
new resource records that provide security for DNS.
D N S Security Extensions (2 of 2)
Defined in:
R F C 4033, D N S Security Introduction and Requirements
R F C 4034, Resource Records for the D N S Security Extensions
R F C 4035, Protocol Modifications for the D N S Security Extensions
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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. In particular, DNSSEC 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. DNSSEC consists of
a set of new resource record types and modifications to the existing DNS protocol,
and is defined in the following documents:
■ RFC 4033, DNS Security Introduction and Requirements: Introduces the
DNS security extensions and describes their capabilities and limitations. The
document also discusses the services that the DNS security extensions do and
do not provide.
■ RFC 4034, Resource Records for the DNS Security Extensions: Defines four
new resource records that provide security for DNS.
56
D N S-Based Authentication of Named Entities (D A N E)
D A N E is a protocol to allow X.509 certificates, commonly used for Transport Layer Security (T L S), to be bound to D N S names using D N S S E C
It is proposed in R F C 6698 as a way to authenticate T L S client and server entities without a certificate authority (C A)
The purpose of D A N E is to replace reliance on the security of the C A system with reliance on the security provided by D N S S E C
D A N E defines a new D N S record type, T L S A, that can be used for a secure method of authenticating S S L/T L S certificates
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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 rationale for DANE is the vulnerability of the use of CAs in a global PKI
system. Every browser developer and operating system supplier maintains a list of
CA root certificates as trust anchors. These are called the software’s root certificates
and are stored in its root certificate store. The PKIX procedure allows a certificate
recipient to trace a certificate back to the root. So long as the root certificate
remains trustworthy, and the authentication concludes successfully, the client can
proceed with the connection.
However, if any of the hundreds of CAs operating on the Internet is compromised,
the effects can be widespread. The attacker can obtain the CA’s private key,
get issued certificates under a false name, or introduce new bogus root certificates
into a root certificate store. There is no limitation of scope for the global PKI and
a compromise of a single CA damages the integrity of the entire PKI system. In
Addition, some CAs have engaged in poor security practices. For example, some
CAs have issued wildcard certificates that allow the holder to issue sub-certificates
for any domain or entity, anywhere in the world.
The purpose of DANE is to replace reliance on the security of the CA system
with reliance on the security provided by DNSSEC. Given that the DNS administrator
for a domain name is authorized to give identifying information about the
zone, it makes sense to allow that administrator to also make an authoritative binding
between the domain name and a certificate that might be used by a host at that
domain name.
DANE defines a new DNS record type, TLSA, that can be used for a secure method
of authenticating SSL/TLS certificates.
57
Figure 8.7 T L S A R R Transmission Format
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
DANE defines a new DNS record type, TLSA, that can be used for a secure method
of authenticating SSL/TLS certificates. The TLSA provides for:
■ Specifying constraints on which CA can vouch for a certificate, or which
specific PKIX end-entity certificate is valid.
■ Specifying that a service certificate or a CA can be directly authenticated in
the DNS itself.
The TLSA RR enables certificate issue and delivery to be tied to a given
domain. A server domain owner creates a TLSA resource record that identifies the
certificate and its public key. When a client receives an X.509 certificate in the TLS
negotiation, it looks up the TLSA RR for that domain and matches the TLSA data
against the certificate as part of the client’s certificate validation procedure.
Figure 8.7 shows the format of a TLSA RR as it is transmitted to a requesting
entity. It contains four fields. The Certificate Usage field defines four different
usage models, to accommodate users who require different forms of authentication.
The usage models are:
■ PKIX-TA (CA constraint): Specifies which CA should be trusted to authenticate
the certificate for the service. This usage model limits which CA can be
used to issue certificates for a given service on a host. The server certificate
chain must pass PKIX validation that terminates with a trusted root certificate
stored in the client.
■ PKIX-EE (service certificate constraint): Defines which specific end entity
service certificate should be trusted for the service. This usage model limits
which end entity certificate can be used by a given service on a host. The server
certificate chain must pass PKIX validation that terminates with a trusted root
certificate stored in the client.
■ DANE-TA (trust anchor assertion): Specifies a domain-operated CA to be
used as a trust anchor. This usage model allows a domain name administrator
to specify a new trust anchor—for example, if the domain issues its own certificates
under its own CA that is not expected to be in the end users’ collection
of trust anchors. The server certificate chain is self-issued and does not need to
verify against a trusted root stored in the client.
■ DANE-EE (domain-issued certificate): Specifies a domain-operated CA to
be used as a trust anchor. This certificate usage allows a domain name administrator
to issue certificates for a domain without involving a third-party CA.
The server certificate chain is self-issued and does not need to verify against a
trusted root stored in the client.
The first two usage models are designed to co-exist with and strengthen
the public CA system. The final two usage models operate without the use of
public CAs.
The Selector field indicates whether the full certificate will be matched or just
the value of the public key. The match is made between the certificate presented
in TLS negotiation and the certificate in the TLSA RR. The Matching Type field
indicates how the match of the certificate is made. The options are exact match,
SHA-256 hash match, or SHA-512 hash match. The Certificate Association Data is
the raw certificate data in hex format.
58
Sender Policy Framework (S P F)
S P F is the standardized way for a sending domain to identify and assert the mail senders for a given domain
Addresses the problem of any host being able to use any domain name for each of the various identifiers in the mail header, not just the domain name where the host is located
Defined in R F C 7208
S P F works by checking a sender’s I P address against the policy encoded in any S P F record found at the sending domain
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
SPF is the standardized way for a sending domain to identify and assert the mail
senders for a given domain. The problem that SPF addresses is the following: With
the current e-mail infrastructure, any host can use any domain name for each of the
various identifiers in the mail header, not just the domain name where the host is
located. Two major drawbacks of this freedom are:
■ It is a major obstacle to reducing unsolicited bulk e-mail (UBE), also known
as spam. It makes it difficult for mail handlers to filter out e-mails on the basis
of known UBE sources.
■ ADMDs (see Section 8.1) are understandably concerned about the ease with
which other entities can make use of their domain names, often with malicious
intent.
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 “HELO”
identities. Compliant ADMDs publish Sender Policy Framework (SPF) records in
the DNS specifying which hosts are permitted to use their names, and compliant
mail receivers use the published SPF records to test the authorization of sending
Mail Transfer Agents (MTAs) using a given “HELO” or “MAIL FROM” identity
during a mail transaction.
SPF works by checking a sender’s IP address against the policy encoded in any
SPF record found at the sending domain. The sending domain is the domain used
in the SMTP connection, not the domain indicated in the message header as displayed
in the MUA. This means that SPF checks can be applied before the message
content is received from the sender.
59
Figure 8.8 Example in Which S M T P Envelope Header Does Not Match Message Header
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 8.8 is an example in which SPF would come into play. Assume that the
sender’s IP address is 192.168.0.1. The message arrives from the MTA with domain
mta.example.net. The sender uses the MAIL FROM tag of [email protected],
indicating that the message originates in the example.org domain. But the message
header specifies [email protected]. The receiver uses SPF to query for the
SPF RR that corresponds to example.com to check if the IP address 192.168.0.1 is
listed as a valid sender, and then takes appropriate action based on the results of
checking the RR.
60
Table 8.7 Common SPF Mechanisms and Modifiers (1 of 2)
(a) S P F Mechanisms
| Tag | Description |
| ip4 | Specifies an I Pv4 address or range of addresses that are authorized senders for a domain. |
| ip6 | Specifies an I Pv6 address or range Of addresses that are authorized senders for a domain. |
| mx | Asserts that the listed hosts for the Mail Exchange R Rs are also valid senders for the domain. |
| include | Lists another domain where the receiver should look for an S P F R R for further senders. This can be useful for large organizations with many domains or sub-domains that have a single set of shared senders. The include mechanism is recursive, in that the S P F check in the record found is tested in its entirety before proceeding. It is not simply a concatenation of the checks. |
| all | Matches every I P address that has not otherwise been matched. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 8.7 Common SPF Mechanisms and Modifiers (2 of 2)
(b) S P F Mechanism Modifiers
| Modifier | Description |
| + | The given mechanism check must pass. This is the default mechanism and does not need to be explicitly listed. |
| − | The given mechanism is not allowed to send email on behalf of the domain. |
| ~ | The given mechanism is in transition and if an email is seen from the listed host/I P address, that it should be accepted but marked for closer inspection. |
| ? | The S P F R R explicitly states nothing about the mechanism. In this case, the default behavior is to accept the email. (This makes it equivalent to '+' unless some sort of discrete or aggregate message review is conducted). |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 8.9 Sender Policy Framework Operation
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
If SPF is implemented at a receiver, the SPF entity uses the SMTP envelope MAIL
FROM: address domain and the IP address of the sender to query an SPF TXT RR.
The SPF checks can be started before the body of the e-mail message is received,
which may result in blocking the transmission of the e-mail content. Alternatively,
the entire message can be absorbed and buffered until all the checks are finished.
In either case, checks must be completed before the mail message is sent to the end
user’s inbox.
The checking involves the following rules:
1. If no SPF TXT RR is returned, the default behavior is to accept the message.
2. If the SPF TXT RR has formatting errors, the default behavior is to accept the
message.
3. Otherwise the mechanisms and modifiers in the RR are used to determine
disposition of the e-mail message.
Figure 8.9 illustrates SPF operation.
63
DomainKeys Identified Mail (D K I M)
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 R F C 6376
Has been widely adopted by a range of e-mail providers and Internet Service Providers (I S Ps)
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
DomainKeys Identified Mail (DKIM) is a specification for cryptographically signing
e-mail messages, permitting a signing domain to claim responsibility for a message
in the mail stream. Message recipients (or agents acting in their behalf) can verify
the signature by querying the signer’s domain directly to retrieve the appropriate
public key and thereby can confirm that the message was attested to by a party in
possession of the private key for the signing domain. DKIM is a proposed Internet
Standard (RFC 6376: DomainKeys Identified Mail (DKIM) Signatures ). DKIM has
been widely adopted by a range of e-mail providers, including corporations, government
agencies, gmail, yahoo, and many Internet Service Providers (ISPs).
64
E-mail Threats (1 of 2)
R F C 4686 (Analysis of Threats Motivating DomainKeys Identified Mail)
Describes the threats being addressed by D K I M in terms of the characteristics, capabilities, and location of potential attackers
Characterized on three levels of threat:
The most sophisticated and financially motivated senders of messages are those who stand to receive substantial financial benefit, such as from an e-mail based fraud scheme
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
RFC 4686 characterizes the range of attackers on a spectrum of
three levels of threat.
1. At the low end are attackers who simply want to send e-mail that a recipient
does not want to receive. The attacker can use one of a number of commercially
available tools that allow the sender to falsify the origin address of
messages. This makes it difficult for the receiver to filter spam on the basis of
originating address or domain.
2. At the next level are professional senders of bulk spam mail. These attackers
often operate as commercial enterprises and send messages on behalf of third
parties. They employ more comprehensive tools for attack, including Mail
Transfer Agents (MTAs) and registered domains and networks of compromised
computers (zombies) to send messages and (in some cases) to harvest
addresses to which to send.
3. The most sophisticated and financially motivated senders of messages are
those who stand to receive substantial financial benefit, such as from an
E-mail-based fraud scheme. These attackers can be expected to employ all of
the above mechanisms and additionally may attack the Internet infrastructure
itself, including DNS cache-poisoning attacks and IP routing attacks.
65
E-mail Threats (2 of 2)
The next level are professional senders of bulk spam mail and often operate as commercial enterprises and send messages on behalf of third parties
At the low end are attackers who simply want to send e-mail that a recipient does not want to receive
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
RFC 4686 characterizes the range of attackers on a spectrum of
three levels of threat.
1. At the low end are attackers who simply want to send e-mail that a recipient
does not want to receive. The attacker can use one of a number of commercially
available tools that allow the sender to falsify the origin address of
messages. This makes it difficult for the receiver to filter spam on the basis of
originating address or domain.
2. At the next level are professional senders of bulk spam mail. These attackers
often operate as commercial enterprises and send messages on behalf of third
parties. They employ more comprehensive tools for attack, including Mail
Transfer Agents (MTAs) and registered domains and networks of compromised
computers (zombies) to send messages and (in some cases) to harvest
addresses to which to send.
3. The most sophisticated and financially motivated senders of messages are
those who stand to receive substantial financial benefit, such as from an
E-mail-based fraud scheme. These attackers can be expected to employ all of
the above mechanisms and additionally may attack the Internet infrastructure
itself, including DNS cache-poisoning attacks and IP routing attacks.
66
D K I M Strategy (1 of 2)
D K I M 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 R F C 5322 message headers
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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. At the
receiving end, the MDA can access the corresponding public key via a DNS and
verify the signature, thus authenticating that the message comes from the claimed
administrative domain. Thus, mail that originates from somewhere else but claims
to come from a given domain will not pass the authentication test and can be
rejected. 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:
1. S/MIME depends on both the sending and receiving users employing S/MIME.
For almost all users, the bulk of incoming mail does not use S/MIME, and the
bulk of the mail the user wants to send is to recipients not using S/MIME.
2. S/MIME signs only the message content. Thus, RFC 5322 header information
concerning origin can be compromised.
3. DKIM is not implemented in client programs (MUAs) and is therefore transparent
to the user; the user need not take any action.
4. DKIM applies to all mail from cooperating domains.
5. DKIM allows good senders to prove that they did send a particular message
and to prevent forgers from masquerading as good senders.
67
D K I M Strategy (2 of 2)
This approach differs from that of S/M I M E and P G P, which use the originator’s private key to sign the content of the message
The motivation for D K I M is based on the following reasoning: D K I M is not implemented in client programs (M U As) and is therefore transparent to the user; the user need not take any action
D K I M applies to all mail from cooperating domains
D K I M allows good senders to prove that they did send a particular message and to prevent forgers from masquerading as good senders
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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. At the
receiving end, the MDA can access the corresponding public key via a DNS and
verify the signature, thus authenticating that the message comes from the claimed
administrative domain. Thus, mail that originates from somewhere else but claims
to come from a given domain will not pass the authentication test and can be
rejected. 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:
1. S/MIME depends on both the sending and receiving users employing S/MIME.
For almost all users, the bulk of incoming mail does not use S/MIME, and the
bulk of the mail the user wants to send is to recipients not using S/MIME.
2. S/MIME signs only the message content. Thus, RFC 5322 header information
concerning origin can be compromised.
3. DKIM is not implemented in client programs (MUAs) and is therefore transparent
to the user; the user need not take any action.
4. DKIM applies to all mail from cooperating domains.
5. DKIM allows good senders to prove that they did send a particular message
and to prevent forgers from masquerading as good senders.
68
Figure 8.10 Simple Example of D K I M Deployment
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 8.10 is a simple example of the operation of DKIM. We begin with a
message generated by a user and transmitted into the MHS to an MSA that is within
the user’s administrative domain. An e-mail message is generated by an e-mail client
program. The content of the message, plus selected RFC 5322 headers, is signed
by the e-mail provider using the provider’s private key. The signer is associated
with a domain, which could be a corporate local network, an ISP, or a public e-mail
facility such as gmail. The signed message then passes through the Internet via a
sequence of MTAs. At the destination, the MDA retrieves the public key for the
incoming signature and verifies the signature before passing the message on to the
destination e-mail client. The default signing algorithm is RSA with SHA-256. RSA
with SHA-1 also may be used.
69
Figure 8.11 D K I M Functional Flow
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 8.11 provides a more detailed look at the elements of DKIM operation. Basic
message processing is divided between a signing Administrative Management Domain
(ADMD) and a verifying ADMD. At its simplest, this is between the originating ADMD
and the delivering ADMD, but it can involve other ADMDs in the handling path.
Signing is performed by an authorized module within the signing ADMD and
uses private information from a Key Store. Within the originating ADMD, this
might be performed by the MUA, MSA, or an MTA. Verifying is performed by
an authorized module within the verifying ADMD. Within a delivering ADMD,
verifying might be performed by an MTA, MDA, or MUA. The module verifies
the signature or determines whether a particular signature was required. Verifying
the signature uses public information from the Key Store. If the signature passes,
reputation information is used to assess the signer and that information is passed
to the message filtering system. If the signature fails or there is no signature using
the author’s domain, information about signing practices related to the author can
be retrieved remotely and/or locally, and that information is passed to the message
filtering system. For example, if the sender (e.g., gmail) uses DKIM but no DKIM
signature is present, then the message may be considered fraudulent.
The signature is inserted into the RFC 5322 message as an additional header
entry, starting with the keyword Dkim-Signature . You can view examples from
your own incoming mail by using the View Long Headers (or similar wording)
option for an incoming message.
Before a message is signed, a process known as canonicalization is performed
on both the header and body of the RFC 5322 message. Canonicalization is necessary
to deal with the possibility of minor changes in the message made en route,
including character encoding, treatment of trailing white space in message lines, and
the “folding” and “unfolding” of header lines. The intent of canonicalization is to
make a minimal transformation of the message (for the purpose of signing; the message
itself is not changed, so the canonicalization must be performed again by the
verifier) that will give it its best chance of producing the same canonical value at the
receiving end. DKIM defines two header canonicalization algorithms (“simple” and
“relaxed”) and two for the body (with the same names). The simple algorithm tolerates
almost no modification, while the relaxed tolerates common modifications.
The signature includes a number of fields. Each field begins with a tag consisting
of a tag code followed by an equals sign and ends with a semicolon.
70
Domain-Based Message Authentication, Reporting, and Conformance (D M A R C)
D M A R C allows e-mail 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
Is defined in R F C 7489, Domain-based Message Authentication, Reporting, and Conformance, March 2015
Works with S P F and D K I M
D M A R C standardizes how e-mail receivers perform e-mail authentication using S P F and D K I M mechanisms
D M A R C authentication deals with the From domain in the message header, as defined in R F C 5322
D M A R C requires that From address match (be aligned with) an Authenticated Identifier from D K I M or S P F
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
allows e-mail 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 works with SPF and DKIM. SPF and DKM enable senders to advise
receivers, via DNS, whether mail purporting to come from the sender is valid, and
whether it should be delivered, flagged, or discarded. However, neither SPF nor
DKIM include a mechanism to tell receivers if SPF or DKIM are in use, nor do they
have feedback mechanism to inform senders of the effectiveness of the anti-spam
techniques. For example, if a message arrives at a receiver without a DKIM signature,
DKIM provides no mechanism to allow the receiver to learn if the message is
authentic but was sent from a sender that did not implement DKIM, or if the message
is a spoof. DMARC addresses these issues essentially by standardizing how
e-mail receivers perform e-mail authentication using SPF and DKIM mechanisms.
DKIM, SPF, and DMARC authenticate various aspects of an individual message.
DKIM authenticates the domain that affixed a signature to the message. SPF
focuses on the SMTP envelope, defined in RFC 5321. It can authenticate either the
domain that appears in the MAIL FROM portion of the SMTP envelope or the
HELO domain, or both. These may be different domains, and they are typically not
visible to the end user.
DMARC authentication deals with the From domain in the message header,
as defined in RFC 5322. This field is used as the central identity of the DMARC
mechanism because it is a required message header field and therefore guaranteed
to be present in compliant messages, and most MUAs represent the RFC 5322
From field as the originator of the message and render some or all of this header
field’s content to end users. The e-mail address in this field is the one used by end
users to identify the source of the message and therefore is a prime target for abuse.
DMARC requires that From address match (be aligned with) an Authenticated
Identifier from DKIM or SPF. In the case of DKIM, the match is made between
the DKIM signing domain and the From domain. In the case of SPF, the match is
between the SPF-authenticated domain and the From domain.
71
Figure 8.12 D M A R C Functional Flow
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
A mail sender that uses DMARC must also use SPF or DKIM, or both. The sender
posts a DMARC policy in the DNS that advises receivers on how to treat messages
that purport to originate from the sender’s domain. The policy is in the form of
a DNS TXT resource record. The sender also needs to establish e-mail addresses
to receive aggregate and forensic reports. As these e-mail addresses are published
unencrypted in the DNS TXT RR, they are easily discovered, leaving the poster
subject to unsolicited bulk e-mail. Thus, the poster of the DNS TXT RR needs to
employ some kind of abuse countermeasures.
Similar to SPF and DKIM, the DMARC policy in the TXT RR is encoded
in a series of tag=value pairs separated by semicolons. Table 8.8 describes the
common tags.
Once the DMARC RR is posted, messages from the sender are typically
processed as follows:
The domain owner constructs an SPF policy and publishes it in its DNS
database. The domain owner also configures its system for DKIM signing.
Finally, the domain owner publishes via the DNS a DMARC message-handling
policy.
2. The author generates a message and hands the message to the domain owner’s
designated mail submission service.
3. The submission service passes relevant details to the DKIM signing module in
order to generate a DKIM signature to be applied to the message.
4. The submission service relays the now-signed message to its designated transport
service for routing to its intended recipient(s).
A message generated on the sender side may pass through other relays but eventually
arrives at a receiver’s transport service. The typical processing order for
DMARC on the receiving side is the following:
1. The receiver performs standard validation tests, such as checking against IP
blocklists and domain reputation lists, as well as enforcing rate limits from a
particular source.
2. The receiver extracts the RFC 5322 From address from the message. This must
contain a single, valid address or else the mail is refused as an error.
3. The receiver queries for the DMARC DNS record based on the sending domain.
If none exists, terminate DMARC processing.
4. The receiver performs DKIM signature checks. If more than one DKIM signature
exists in the message, one must verify.
5. The receiver queries for the sending domain’s SPF record and performs SPF
validation checks.
6. The receiver conducts Identifier Alignment checks between the RFC 5321
From and the results of the SPF and DKIM records (if present).
7. The results of these steps are passed to the DMARC module along with the
Author’s domain. The DMARC module attempts to retrieve a policy from the
DNS for that domain. If none is found, the DMARC module determines the
organizational
domain and repeats the attempt to retrieve a policy from the DNS.
8. If a policy is found, it is combined with the Author’s domain and the SPF and
DKIM results to produce a DMARC policy result (a “pass” or “fail”) and can
optionally cause one of two kinds of reports to be generated.
9. Recipient transport service either delivers the message to the recipient inbox
or takes other local policy action based on the DMARC result.
10. When requested, Recipient transport service collects data from the message
delivery session to be used in providing feedback.
Figure 8.12, based on one at DMARC.org, summarizes the sending and
receiving functional flow.
72
Table 8.8 D M A R C Tag and Value Descriptions (1 of 3)
| Tag(Name) | Description |
| v=(Version) | Version field that must be present as the first element. By default the value is always D M A R C I. |
| p=(Policy) | Mandatory policy field. May take values none or quarantine or reject. This allows for a gradually tightening policy where the sender domain recommends no specific action on mail that fails D M A R C checks (p=none), through treating failed mail as suspicious (p=quarantine), to rejecting all failed mail (p=reject), preferably at the S M T P transaction stage. |
| aspf=(S P F Policy) | Values are r (default) for relaxed and s for strict S P F domain enforcement. Strict alignment requires an exact match between the From address domain and the (passing) S P F check must exactly match the MailFrom address (H E L O address). Relaxed requires that only the From and MailFrom address domains be in alignment. For example, the MailFrom address domain smtp.example.org and the From address [email protected] are in alignment, but not a strict match. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 8.8 DMARC Tag and Value Descriptions
Table can be found on page 281 in the textbook
73
Table 8.8 D M A R C Tag and Value Descriptions (2 of 3)
| Tag(Name) | Description |
| adkim=(DKIM Policy) | Optional. Values are r (default) for relaxed and s for strict D K I M domain enforcement. Strict alignment requires an exact match between the From domain in the message header and the DKIM domain presented in the d= D K I M tag. Relaxed requires only that the domain is in alignment (as in aspf). |
| f0=(Failure reporting options) | Optional. Ignore if a ruf argument is not also present. Value 0 indicates the receiver should generate a D M A R C failure report if all underlying mechanisms fail to produce an aligned pass result. Value 1 means generate a DMARC failure report if any underlying mechanism produces something other than an aligned pass result. Other possible values are d (generate a DKIM failure report if a signature railed evaluation), and s (generate an SPF failure report if the message failed SPF evaluation). These values are not exclusive and may be combined. |
| ruf= | Optional, but requires the fo argument to be present. Lists a series of U R Is (currently just mailto:<emailaddress>) that list where to send forensic feedback reports. This is for reports on message specific failures. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 8.8 DMARC Tag and Value Descriptions
Table can be found on page 281 in the textbook
74
Table 8.8 D M A R C Tag and Value Descriptions (3 of 3)
| Tag(Name) | Description |
| rua= | Optional list or URIs (like in ruf=, using the mailto: U R I) listing where to send aggregate feedback back to the sender. These reports are sent based on the interval requested using the ri= option, with a default of 86400 seconds if not listed. |
| ri=(Reporting interval) | Optional with the default value of 86400 seconds. The value listed is the reporting interval desired by the sender. |
| pct=(Percent) | Optional with the default value of 100. Expresses the percentage of a sender's mail that should be subject to the given D M A R C policy. This allows senders to ramp up their policy enforcement gradually and prevent having to commit to a rigorous policy before getting feedback on their existing policy. |
| sp=(Receiver policy) | Optional with a default value of none. Other values include the same range of values as the p= argument. This is the policy to be applied to mail from all identified subdomains of the given D M A R C R R. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Summary
Internet mail architecture
E-mail formats
E-mail threats and comprehensive e-mail security
Pretty good privacy
DomainKeys Identified Mail
S/M I M E
D N S S E C
D N S-based authentication of named entities
Sender policy framework
Domain-based message authentication, reporting, and conformance
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
76
Chapter 8 summary.
Copyright
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
77
