Securing Email
Outline
Electronic mail protocols
 Electronic mail content security

 PGP -- Pretty Good Privacy
 PEM -- Privacy Enhanced Mail
 S/MIME
2

Structure of email servers
 Usually the sender does not directly talk
to the receiver
 Dedicated mail server (in x.400 structure,
it is called message transfer agents: MTA)
 The source and destination are called
mail user agents (MUA)
 The email could go through several MTAs
 There are problems of this “open relay”
3

Advantages of multiple store-andforward MTAs
 Adaptable to temporary network
partitions
 Easy to form chain of trust
 Easy to implement traffic control within a
company
 Easy to connect partitions of networks
using different protocols
4

Disadvantages:
 Spam email
 Other security concerns
5
outgoing
message queue
Electronic Mail
user mailbox
Three major components:
 user agents
 mail servers
 simple mail transfer
protocol: SMTP
user
agent
mail
server
SMTP
User Agent
 a.k.a. “mail reader”
mail
 composing, editing, reading
server
mail messages
 e.g., Eudora, Outlook, elm,
pine, Netscape Messenger
user
 outgoing, incoming
agent
messages stored on server
SMTP
SMTP
user
agent
user
agent
mail
server
user
agent
user
agent
Electronic Mail: mail servers
user
agent
Mail Servers




mailbox contains incoming
messages for user
message queue of outgoing
(to be sent) mail messages
SMTP protocol between
mail servers to send email
messages
 client: sending mail
server
 “server”: receiving mail
server
Note that “mail server”
behaves both as SMTP
server and SMTP client
mail
server
SMTP
SMTP
mail
server
user
agent
SMTP
user
agent
mail
server
user
agent
user
agent
user
agent
7
Electronic Mail: SMTP [RFC 5321]





uses TCP to reliably transfer email message from client
to server, port 25/587
direct transfer: sending server to receiving server
three phases of transfer
 handshaking (greeting)
 transfer of messages
 closure
command/response interaction
 commands: ASCII text
 response: status code and phrase
 Delivery receipt and return receipt
messages must be in 7-bit ASCII (several companies
design their own representation)
8
Scenario 1: Alice sends message to Bob
1) Alice uses UA to compose
message and “to”
bob@someschool.edu
2) Alice’s UA sends message
to her mail server;
message placed in
message queue
3) Client side of SMTP opens
TCP connection with Bob’s
mail server
1
user
agent
2
mail
server
3
4) SMTP client sends Alice’s
message over the TCP
connection
5) Bob’s mail server places
the message in Bob’s
mailbox
6) Bob invokes his user agent
to read message
mail
server
4
5
6
user
agent
9
Scenario 2: Alice sends message to Bob
1) Alice runs a telnet client
4) SMTP client (mail server 3)
sends Alice’s message over
the TCP connection to mail
server 5 (Bob’s mail server)
5) Bob’s mail server places the
message in Bob’s mailbox
6) Bob invokes his user agent
to read message
2) Alice’s telnet client opens a
TCP connection to some
mail server (could be
Bob’s mail server) at port
25
3) Alice uses SMTP
commands to compile a
message which will be
sent to Bob.
1
telnet
client
2
mail
server
3
mail
server
4
5
6
user
agent
10
S: 220 smtp.example.com ESMTP Postfix
/* 220: service ready */
C: HELO relay.example.org
/* identify urself */
S: 250 Hello relay.example.org, I am glad to meet you
/* request ok */
C: MAIL FROM:<bob@example.org>
S: 250 Ok
C: RCPT TO:<alice@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
/* start mail input */
C: From: "Bob Example" <bob@example.org>
C: To: Alice Example <alice@example.com>
C: Date: Tue, 15 Jan 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye {The server closes the connection}
/* close channel */
11
SMTP: final words



SMTP uses persistent
connections
SMTP requires
message (header &
body) to be in 7-bit
ASCII
SMTP server uses
CRLF.CRLF to
determine end of
message (CRLF
stands for carriage
return and line feed)
Comparison with HTTP:


HTTP: pull
SMTP: push

both have ASCII
command/response
interaction, status codes

HTTP: each object
encapsulated in its own
response msg
SMTP: multiple objects
sent in multipart msg

12

Distribution lists
 You may need to send to a group of
people
 Can be summarized as distribution lists
 How to map a single list name to a group
of real email address:
 Remote exploder
 Local exploder
 Can form a hierarchy: list in list
13
Two distribution lists may contain
each other: we need to handle
duplicated sending
 Advantages of local exploder:

 It is easy to prevent mail forwarding loops
 It is easy for the sender to avoid sending
multiple copies to the same user
 It is easier to handle billing issues
14

Advantages of remote exploder
 You can send email to a list of users
whose identities are not known to you
 Reduce the amount of traffic sent by
sender
 Improve efficiency: multiple lists can be
handled by different DL maintainers
15
Mail message format
SMTP (RFC 5321): protocol
for exchanging email msgs
RFC 822: Standard for the
header
format of ARPA Internet text
messages:

header lines, e.g.,
 To:
 From:
 Subject:
different from SMTP
commands!

blank
line
body
body
 the “message”, ASCII
characters only
16
Message format: multimedia extensions


MIME: multipurpose Internet mail extension,
RFC 2045, 2046, 2049 etc
additional lines in msg header declare MIME
content type
MIME version
method used
to encode data
multimedia data
type, subtype,
parameter declaration
encoded data
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
17

How is base64 working:
Turn every three bytes to four 6-bit
sequences
 Each 6-bit sequence is mapped to a
printable character: A—Z, a—z, 0—9,
+,/
How to handle padding
 Add “=“ at the end
 Number of “=“ depends on the
original message


18
MIME types
Content-Type: type/subtype; parameters
Text

example subtypes: plain,
html (e.g.,
text/plain;
charset=“ISO-8859-1”)
Image

example subtypes: jpeg,
gif (e.g, image/gif)
Audio

Video

example subtypes: mpeg,
quicktime
Application


other data that must be
processed by reader
before “viewable”
example subtypes:
msword, octet-stream
example subtypes: basic
(8-bit mu-law encoded),
32kadpcm (32 kbps
coding), RCF 1911
19
Multipart Type
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=StartOfNextPart
--StartOfNextPart
Dear Bob, Please find a picture of a crepe.
--StartOfNextPart
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--StartOfNextPart
Do you want the recipe?
20

Annoying text format issues
 There is no single standard for text
representation
 E.g.: new line, line length, high bits, etc
 Intermediate server may change your email
format
 Problem: email ruined, integrity and
signature not working
 Reformat data for such issues
21
Mail access protocols
user
agent
SMTP
SMTP
sender’s mail
server



access
protocol
user
agent
receiver’s mail
server
SMTP: delivery/storage to receiver’s server
SMTP is a push protocol, and it is good for message sending
— we need a separate protocol for message retrieval
Mail access protocol: retrieval from server
 POP: Post Office Protocol [RFC 1939]
 authorization (agent <-->server) and download
 IMAP: Internet Message Access Protocol [RFC 3501][port
143]
 more features (more complex)
 manipulation of stored msgs on server
 HTTP: Hotmail , Yahoo!, etc.
22

POP3 [tcp port 110]
 Can work with temporary network
connections, view and manipulate email
offline
 Retrieve and delete from the server
 POP3 UIDL can leave a copy
 Use a unique identifier to represent an
email
 Support encryption through SSL or TLS
23
POP3 protocol (port 110)
telnet xxxxxx.uncc.edu 110
authorization phase


client commands:
 user: declare username
 pass: password
server responses
 +OK
 -ERR
transaction phase, client:




list: list message
numbers
retr: retrieve message by
number
dele: delete
quit
S:
C:
S:
C:
S:
+OK POP3 server ready
user yonwang
+OK
pass *******
+OK user successfully logged
C:
S:
S:
S:
C:
S:
S:
C:
C:
S:
S:
C:
C:
S:
list
1 498
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 2 contents>
.
dele 2
quit
+OK POP3 server signing off
on

IMAP: Internet Message Access Protocol








Support both online and offline operation
Leave copy of email on server
Multiple clients access the same mailbox
Support encrypted login
Access to MIME parts and partial fetch
Message state information
Create directory in your mailbox
Server side search
25

Problems of IMAP
 The search algorithm on the server can
consume a lot of resources
 Complexity of the software
26
POP3 and IMAP
More about POP3





Previous example uses
“download and delete”
mode.
Bob cannot re-read e-mail
if he changes client
“Download-and-keep”:
copies of messages on
different clients
POP3 is stateless across
sessions
Create folders and see the
same view from any
computer? Not possible!
IMAPv4 (port 143)



Keep all messages in one
place: the server
Allows user to organize
messages in folders
IMAP keeps user state
across sessions:
 names of folders and
mappings between
message IDs and folder
name
27

Some expected security features of secure
email








Privacy: only the receiver can read the message
Authentication: authenticate the sender identity
Integrity
Non-repudiation
Proof of submission
Proof of delivery
Hiding the existence of the message
Anonymity: even the receiver does not know
who the sender is
28

More features of secure email
 Accounting
 Self-destruct
 Message sequence integrity
29
Details of secure email

Establishing keys
 There are many possibilities of keys:
sender, receiver, MTA, distribution list
exploder, etc
 Public key approach
 Sender can get receiver’s public key by
 Out-of-band mechanism
 Through PKI
 Piggybacking of certificates
 Secret key approach
 Through KDC or tickets
30

Confidentiality
 Many sources to violate email
confidentiality: eavesdropper, MTA,
company network administrator
 End-to-end privacy
 It is not efficient to use public key to encrypt
the whole message
 It is not efficient when you have multiple
receivers
 Solution: use a symmetric key to encrypt
message, and use public key to encrypt the
symmetric key
31

Privacy with the distribution list
exploder
 Remote DLE: the sender only needs to
share a key with the DLE
 Local DLE: establish key with every
receiver in the list
32

Authenticating sender
 Signing the message digest with sender’s
private key
 Encrypt the digest with pair wise key
 Source authentication with distribution
lists
 It is easy if we use digital signature
 If we are using secret key, DLE will attach its
authentication information
33

Message integrity
 Most of time it is integrated with source
authentication
 Integrity without source authentication
 Ransom
 The problem when you sign a hash result
 How is the hash result calculated (attack with
the signatures)
34

Non-repudiation
 With public keys
 With the digital signature
 Deniability based on public key technology




Alice generates a symmetric key
E pub-B ( Sign-A (key) )
Use this key to encrypt the message
Bob can prove that Alice generates the key, but not
Alice sends that message
 Non-repudiation with secret keys
 through notary (trusted third party)
35

Proof of submission
 The sending MTA provides a signed
digest of the email

Proof of delivery
 Receiver signs a receipt

A famous problem in cryptography
 Simultaneous contract signing
36

Anonymity




Through a proxy
Onion routing issues
Anonymous email service: craigslist
Anonymous IETF mailing list
37
Possible attacks

Spoofing (unbelievably easy!)
 a third party may impersonate Alice and send a fake/modified
message to Bob

Eavesdropping
 a party sitting between Alice’s UA and Bob’s mail server may
peep communications between them

Replay
 a party sitting between Alice and Bob may re-send to Bob an old
message from Alice




Attacks on mail access protocols such as POP3, IMAP, etc
Other attacks such as DoS
Traffic analysis
Last one: should Bob trust his mail server? Or in another
word: do you trust the postman who delivers a letter to you?
38
Achieve secure email in the network stack
Appl
Content security
S/MIME, Proxies, SET, PGP
TCP
SSL, TLS,
SOCKS
IP
Network
driver
AH, ESP (in IPSec),
Packet filtering,
Tunneling (L2TP, PPTP, L2F),
CHAP (challenge handshake protocol)
PAP (password auth. protocol),
MS-CHAP
Application
Layer
Transport
Layer
Network
Layer
Data link
Layer
39
Use electronic mail securely

Preventing spoofing and replay
 Digital signature with one-way hash
 Timestamps etc.

Preventing eavesdropping
 Encryption (transport layer or application layer)

Preventing attacks on mail access protocols
 SSL (openSSL)

Preventing other attacks: general network
security problems (DoS on a mail server)
40
Use Email securely

Content layer security:




Transparent on the underlying layer
PEM
PGP
S/MIME
41
Privacy Enhanced Mail (PEM)
Attempt to add security to SMTP
 Text only: MIME didn’t exist yet
 Attempt to build a CA hierarchy along
X.500 lines

 Hierarchy with a single root !!

Solved the data formatting problem
with base64 encoding
 Encode 3 binary bytes as 4 NVT ASCII
characters
 The same encoding was later used in PGP 2.X,
mime...
42

PEM certificate hierarchy
 Want to use a centralized root
 Three types of certificate authorities
 High assurance
 Discretionary Assurance
 No Assurance
43
PGP
By Phil Zimmermann
 Check out http://www.pgp.com or
http://web.mit.edu/network/pgp.html
Available for Windows/Linux/Macintosh
 Getting the PGP and install it on your
computer
 Crypto is useful only if it is USED!!

44
S/MIME

Who will win?
 PGP for personal email security
 S/MIME for commercial and organization
use
Standards page:
http://www.ietf.org/html.charters/smim
e-charter.html
 Main RFCs: 3369, 3370, 3850, 3851

45
Reminder: Multipart Type
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=StartOfNewPart
--StartOfNewPart
Dear Bob, Please find a picture of a crepe.
--StartOfNextPart
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--StartOfNewPart
Do you want the reciple?
46
S/MIME


Similar to PGP, offers signature and
encryption functions. It cryptographically
protects MIME entity
Based on CMS (cryptographic message
syntax)
 Encapsulation syntax for data protection
47
Protocols
Content encryption algorithm: 3DES
(DES EDE3 CBC), RC2/40 (more
algorithms are being added)
 Key encryption algorithm: Diffiehellman
 Message digest algorithm: SHA-1,
MD5
 Signature algorithm: DSA, RSA

48
User Agent

S/MIME user agents should handle the
following tasks:
 Key generation
 Registration
 Certificate storage and retrieval including
certificate management
49
Applications
Secure e-mail
 EDI (Electronic Data Interchange)
 Online Services
 Healthcare applications
 Internet push products
 Indeed, used for any kind of data
content protection

50
Adopted in:
Microsoft Exchange
 Lotus Notes
 Novell Groupwise
 Netscape Communicator
 Eudora
 etc..

51