Email Security

Question 1

What are the security properties of S/MIME clear-signed? Explain by indicating the appropriate algorithms used and if they are mandatory or optional.

Answer 1

The properties offered are:
* Non-repudiation: by signing for receipt of a document, so that the recipient of a message cannot deny having received it.
* Security label, a mechanism through which each message is classified according to a certain security hierarchy. For example, in the military, messages are classified into unclassified (readable by anyone), classified (reserved only for those who have a certain authorization), secret and top-secret.
* Secure mailing-list, which solves the problem of how to encrypt messages destined for a mailing-list (where the public keys of the recipients are not available). However, this introduces a weakness because the message is no longer end-to-end encrypted but the mailing list manager could potentially go and read its contents.
* Signature of certificate attributes.
The algorithms used are:
* Digest: SHA-1 (mandatory) or MD5.
* Digital signature: DSS (mandatory) or digest + RSA (most used solution).
* Key exchange: Diffie Hellman (required). In fact, the common practice is to calculate a message key by encrypting it with the recipient’s RSA key.
* Message encryption: 3DES or RC2 / 40 (both mandatory).

Question 2

Say what APOP has more than POP and how it implements it

Answer 2

The APOP variant introduces a new command, called APOP, which replaces the pair of USER + PASS commands. This command introduces a symmetrical-type challenge mechanism.

Question 3

Describe the S/MIME clear-signed attributes indicating which are optional and describe the various encryption algorithms and keys used.

Answer 3

• Digest: SHA-1 (mandatory) or MD5.
• Digital signature: DSS (mandatory) or digest + RSA (most used solution).
• Key exchange: Diffie Hellman (required). In fact, the common practice is to calculate a message key by encrypting it with the recipient’s RSA key.
• Message encryption: 3DES or RC2 / 40 (both mandatory).

Question 4

With reference to an Internet e-mail management system (MHS, MailHandling System), identify possible security problems and indicate which protection techniques can be applied to solve or mitigate each problem.

Answer 4

Securing email is not trivial:
* Connectionless system, ie there is no direct connection between the sender and the recipient. Indeed, we speak of a store-and-forward system, that is, the message before
being sent from one node to the other is first saved locally and only later is forwarded.
* Use of untrusted MTAs on which messages are stored (even if temporarily).
* Security level of the MS (message store) on which messages are stored before they are read.
* An encryption system could be implemented, but there would be problems if a mailing-list was used (problem of implementing encryption for all members of the mailing-list).
* Since email is now a widely used system, making changes is not such an easy thing to do.

Question 5

Authenticate the email sender: MS, MSA or MTA?

Answer 5

MSA

Question 6

How does the Message Handling System works?

Answer 6

The MHS is based on the store&froward process.

There are 4 principal components:
1. MUA = Message User Agent
It is the software component that the user uses to send emails.
2. MSA = Message Submission Agent -> outgoing mail server
This is another software to which the MUA sends the email. The MSA injects the. email in the mail transport system.
3. MTA = Message Transfer Agent
The mail transport system is composed of MTAs that are arranged in a chain. The chain ends when the email reaches the final destination, that is NOT the final user device but a server called Message Store (MS)
4. MS = Message Store -> incoming mail server
It is a server. The destination user will use its MUA to read the email from the MS.

If the destination user wants to reply to the sender, a different MSA and a different MTA chain will be used.

Question 7

Which are the options that the user has to interact with the email system?

Answer 7

There are two types of MUA implementations:
* e-mail in client-server mode
* webmail

Question 8

Email in the client-server mode

Answer 8

The MUA consists in an application that just takes care of emails.
This application MUST be configured with two important informations: the outgoing mail server address and the incoming mail server address.

Example: Thunderbird, Outlook Express

Question 9

Webmail

Answer 9

The user uses a web browser to connect, via HTTP and HTML, to a web server that contains a virtual MUA. It also contains an HTTP engine that the user can use to write the email using standard web formats.
Here the email is stored at the mail server provider and this can cause security issues.

You have not control over your mail, the provider of the virtual MUA has! Much more dangerous.

Question 10

On which protocols is the email system based? (list)

Answer 10

• SMTP
• POP
• IMAP
• MIME

+ there is RFC-822 that is a message format

Question 11

SMTP

Answer 11

SMTP stands for Simple Mail Transfer Protocol.
* push protocol
* TCP based
* text based
* used between MUA - MSA and MSA - MTA
* port 25/TCP from MSA to MTA
* port 587/TCP from MUA to MSA

Question 12

POP

Answer 12

Post Office Protocol

• used to get a mail from the MS and placing it into the MUA ( = IMAP)
• port 110/TCP
• POP-2 (RFC-937), POP-3 (RFC-1939) user authentication by means of a password in clear (!!!)
• APOP: user authentication via symmetric challenge-response (MD5)
• K-POP: mutual authentication by means of tickets

POP-3 example
~~~
telnet pop.polito.it 110
+OK POP3 server ready 7831.84549@pop.polito.it
USER lioy
+OK password required for lioy
PASS antonio
+OK lioy mailbox locked and ready
STAT
+OK 2 320
……….
QUIT
+OK POP3 server signing off
~~~

Stat: status -> response “you have two emails for a total of 320 bytes”

This has not security! A solution is using TLS for POP and IMAP

Question 13

IMAP

Answer 13

Internet Message Access Protocol

• used to get a mail from the MS and placing it into the MUA ( = POP)
• port 143/TCP
• default authN: username and password in clear
• can use OTP, Kerberos or GSS-API

This has not security! A solution is using TLS for POP and IMAP

Question 14

RFC-822

Answer 14

This is not aa protocol but a message FORMAT that provides pure text mails.

• only US-ASCII
• characters on 7 bits, the 8-th one is used as parity bit and this is really dangerous because each MTA can modify it and, if the message was digitally signed, the signature wont correspond anymore.
• each line must terminate with <CR> <LF> to make mails be **system independent**. This is the necessary because we dont know which will be the receiving operating system (the new line command is translated differently in each of them) we have to define a neutralmform. At destination they will be translated based on the operating system standard.</LF></CR>

The parity bit is also dangerous because if we look for example at accented characters, they have an ASCII code that is major that 128 so they will have the parity bit set to 1. If some MTA changes it the character will be wrong and the signature, if present, wont correspond anymore.

RFC-822 message
A message is composed by an header and a body.
* header: it is made of keywords at the beginning of the line and, if the line is too long, the continuation lines start with a space. The interface used could be in a language different from english but the actual mail will be sent just with english headers.
The headers are: From, Sender, Organization, To, Subject, Date, Received, Message-id, CC, Bcc, Return-Receipt-To where From is the logical sender, Sender is the operational one, date is declared by the MUA, CC stands for Carbon Copies and BCC for Blind Carbon Copies, and Return-Receipt-to is true if the sender wants to receive an ack.
The received header shows all the MTAs that have been used.

The headers are terminated when a line with just CR and LF is found.

• body: it is separated from the header by an empty line and containes the actual message

This format gives a lot of opportunities to create fake mails because in the “Form” field it is possible to write anything.

Question 15

MIME

Answer 15

Multipurpose Internet Mail Extensions

Main characteristics:
* various data encodings: non-USA alphabets, “long” lines, binary data
* multipart format: distinct parts, parts of different type
* recursive format: each part can be a multipart object

Types of secure email messages:
* signed: the message is signed with a digital signature in S/MIME format
* encrypted: encrypted envelope in S/MIME format
* encrypted and signed: the digital signature in S/MIME format is applied to the message and then everything is transformed in a encrypted envelope in S/MIME format

It uses RFC-1847 extension.

Question 16

SMTP/RFC-822 example

Answer 16

this example wants to show how easy it easy to create fake emails. There is no verification at all.

Question 17

Security problems in the standard email system

Answer 17

• it is a connectionless system that operates with a succession of store&forward
• MTA’s are untrusted
• messages are stored in MS and this leads to security issues
• mailing-list encryption: Encrypting an email for a single recipient is straightforward, but encrypting it for multiple recipients on a mailing list can be complex. Each recipient might use a different email client and public key infrastructure.
• Compatibility with what is already installed

Proposed solutions
* PGP, PEM, MOSS, S/MIME, X.400 (by OSI)

Nowadays the only two survivors are S/MIME and PGP

MIME IS A SOLUTION TO THE SECURITY PROBLEMS THAT THE MAIL SYSTEM HAS

Question 18

ESMTP

Answer 18

Extended SMTP
The baase protocol and the communication channel are the same as SMTP.

This is tipically used by the MSA before accepting an email to send from a MUA. THE MSA wants to authenticate di MUA and then accept its request.

The ESMTP clients must identify themselves to the communicating parties with EHLO hostname. If the receiving server speaks ESMTP, it must declare the extensions that it supports, one per line, in its response to EHLO.
For example one line can be occupied by the AUTH extension:
AUTH PLAIN LOGIN

One of the most important extensions is the AUTH extension.
Another one is STARTTLS. Both are offered after the HELO command with code 250

So it is MSA that sends the supported extensions list.

Question 19

AUTH extension

Answer 19

It is one of the possible extensions used in ESMTP.

It consists of the command AUTH plus options of MAIL FROM.
It is typically used by a MSA to authenticate a client before accepting messages from it.

Steps:
* after the EHLO command the server sends the authentication mechanisms supported
* the client chooses one
* the authentication protocol is executed
* if the authentication fails, the communication channel is closed

Example: no method found
220 example.polito.it - SMTP service ready
EHLO mailer.x.com
250-example.polito.it
250 AUTH LOGIN CRAM-MD5 DIGEST-MD5
AUTH PLAIN
504 Unrecognized authentication type

Possible euthentication methods are:
* LOGIN
* PLAIN
* challenge-response methods: CRAM-MD5, DIGEST-MD5

Question 20

ESMTP, LOGIN and PLAIN methods

Answer 20

LOGIN
The client chooses the login method: AUTH LOGIN. The server sends 334 VXNlcm5hbWU6 where 3xx is a positive intermediate which corresponds to a question. The server sends multiple questions and the client responds to these questions with a base64 string that the server. can decode using openssl. Questions can be, for example, username and password, and each of them is encoded Base64.
If the client responds correctly the sever confirm its authentication by sending 235 authenticated

PLAIN
This method uses base64 encoding too but it requires that the client sends every needed parameter in the same line it chooses the authentication method.

~~~
AUTH PLAIN base64([authorize_id \0 authentication_id \0 psw])
```. The first parameter is optional.

\0 is the null ASCII character

The problem with these two method is that parameters are sent in cleartext and just obfuscated with base64 encoding -> need for challenge-response methods (symmetric)

Question 21

ESMTP, CRAM-MD5 and DIGEST-MD5 methods

Answer 21

CRAM–MD5
* challenge = base64 ( nonce )
* response = base64 (usr SP hmac-md5( pwd, nonce )LHEX )
* SP = space
* LHEX: the hmca-md5 is encoded in lower case hexadeciamal

The server sends the encoded nonce with code 334.

AUTH CRAM-MD5
334 PDY5LjIwMTIwMTAzMjAxMDU4MDdAeC5wb2xpdG8uaXQ+ (server, nonce)
bGlveSA1MGUxNjJiZDc5NGZjNDNjZmM1Zjk1MzQ1NDI3MjA5Nw== (response)
235 Authentication successful

Advantages:
* client authentication (password)
* no replay
* resistant to sniffing (hash is not invertible)

Disadvantages:
* no server authentication (but OK if used over TLS which always provides server authentication)
* cleartext storage of the pwd, unless the intermediate steps of HMAC are stored (i.e. K’ XOR opad and K’ XOR ipad)
* dictionary attack still possible if pwd copied
* possible MITM (channel takeover after CRAM) but this is a general problem of peer authentication …

DIGEST–MD5
* similar to HTTP/1.1 digest-authentication
* declared obsolete in RFC-6331 (2011) and replaced with SCRAM

no sniffing attacks but an attacker could try every password for the string

Question 22

SMTP and TLS

Answer 22

SMTP offers the STARTTLS option, that is a option of EHLO ad that is a command to start TLS negotiation inside a SMTP channel.
If the TLS negotiation is successful, the protocol status is reset (starts again from EHLO and the extensions supported can be different). Fonexample if I have TLS with confidentiality I can propose LOGIN and PLAIN too.

So the TLS connection is INSIDE THE SMTP CHANNEL (strange, usually it is the opposite)

If the negotiated security level is insufficient:
* the client sends immediately QUIT and closes the connection
* the server responds to each command with code 554 (refused due to low security)

220 example.polito.it - SMTP service ready
EHLO mailer.x.com
250-example.polito.it
250-STARTTLS
250 DSN
STARTTLS
220 Go ahead
… TLS negotiation is started between client and server
… and new ESMTP connection is negotiated (because extensions may be different over a secure channel)

Question 23

Which are the needed secuirty properties (security services) for an e-mail?

Answer 23

• integrity (without direct communication): the receiver will detect if the message was modified in transit
• authentication: the receiver can exactly identify the sender (not looking at the From header but having some digital identity)
• non repudiation: the sender cannot deny of having sent the mail
• confidentiality (optional): messages are not readable both in transit and when stored in the mailbox

Question 24

Which are the types of secure e-mail messages?

Answer 24

PGP, S/MIME, etc. share some secure email messages formats:

• clear-signed: msg in clear (so that anybody is able to read it) + digital signature (as an attachment or inside the msg) -> only who has a secure MUA can verify the signature
• signed: [ msg + dsig ] encoded (e.g. base64, uuencode): only who has a secure MUA (or performs operations manually) can decode and verify the signature
• encrypted / enveloped: [ encrypted msg + encrypted key ] encoded -> only who has a secure MUA (and the keys!) can decrypt the message. Here the encrypted key is the key used to encrypt the mail message encrypted with the public key of the destination
• signed and enveloped: you can decide the order

Question 25

How to create a secure e-mail message?

Answer 25

1. transform in canonical form = standard format, independent from OS / host / net
2. compute the MIC (Message Integrity Code) that gives integrity and authentication. Typically: msg + { h(msg) } SK_sender. Optionally you can also attach the X.509 certificate.
3. encryption (just if you want confidentiality): typically { msg } KM + { KM } PK_receiver1 + ... and for all the receivers
4. If after the operations the message is binary you have to transform it into text by encoding it to avoid modification by the MTA, typically: base64 (in the past uuencode, binhex)

Question 26

Standards proposed for secure emails

Answer 26

• from IETF: PEM -> MOSS -> S/MIME
• from DOD + EC: X.400 -> X.421
• from underground communities: PGP -> MIME-PGP

Question 27

RFC-1847

Answer 27

MIME (Multipurpose Internet Mail Extensions) is a standard for formatting email messages that allows the inclusion of text, images, audio, video, and other types of content. For message security, MIME can be extended to include digital signatures and encryption.
This standard takes care of MIME multipart/signed and multipart/encrypted types of message.

The RFC-1847 extension allows to apply security features to the email message.
When using MIME for digital signatures, the message includes specific headers and structures to indicate that the content is digitally signed

Content-Type: multipart/signed;
     protocol="TYPE/STYPE"; 
     micalg="..."; 
     boundary="..."

This MIME content type indicates that the message is digitally signed. The Content-Type header includes several parameters to specify the signature protocol and the digest (hash) algorithm used:
* protocol=”TYPE/STYPE”: Specifies the protocol used for the digital signature.
* micalg=”…”: Specifies the message integrity check algorithm (hash algorithm) used to create the digital signature.
* boundary=”…”: Defines the boundary that separates the different parts of the message.

With N body parts:
* the first N-1 ones are those to be protected (content-type: …)
* the last one contains the digital signature (content-type: TYPE/STYPE)

Question 28

MIME versions

Question 29

S/MIME Architecture

Answer 29

The architecture of S/MIME is based on several key standards and specifications:

• PKCS-7 (S/MIME v2) / CMS (Cryptographic Message Syntax since S/MIME v3): Specifies the cryptographic characteristics and message types. Equivalent to PEM (Privacy-Enhanced Mail).
• PKCS-10: Format of the certificate request.
• X.509: Format to attach public key certificates.

Question 30

S/MIME v4.0 algorithms

Answer 30

Digital signature
* (MUST) ECDSA with curve P-256 and SHA-256
* (MUST) EdDSA with curve 25519
* (MUST–) RSA with SHA-256
* (SHOULD) RSASSA-PSS with SHA-256

Key exchange
* (MUST) ECDH with curve P-256
* (MUST) ECDH with curve X25519 with HKDF-256
* (MUST–) RSA encryption
* (SHOULD+) RSAES-OAEP

Confidentiality
* (MUST) AES-128-GCM e AES-256-GCM
* (MUST–) AES-128-CBC
* (SHOULD+) ChaCha20-Poly1305

Micalg (depends also upon digital signature)
* SHA-256
* SHA-512

Question 31

MIME Types in S/MIME

Answer 31

When you apply S/MIME to a message the MIME type of the message changes. We saw for example multipart/signed.

application/pkcs7-mime, used for:
* msg. encrypted (envelopedData)
* msg. signed (signedData) addressed only to S/MIME users because it is encoded in base64
* msg. that contains only a public key (= certificate, in a degenerate signedData body). This means that you send an email without any content, then you sign it and you put your certificate. This is a way to send your certificate to the destination that can replay with an encrypted message using your public key.
* standard extension: .p7m
* always base64-encoded

multipart/signed
* signed messages addressed also to users not supporting S/MIME
* the message is in clear
* the last MIME part is the signature (per RFC-1847) and its base64-encoded
* standard extension for the signature: .p7s

application/pkcs10
* used to send a certification request to a CA
* base64-encoded

Question 32

S/MIME examples

Answer 32

• encrypted: B64( P7_enveloped( msg ))
• signed (only for S/MIME users): B64( P7_signed( msg ))
• signed (for generic users): MIME( msg ) + B64( P7_signed_detached( msg ))
• signed and encrypted: B64( P7_enveloped( P7_signed( msg ))) or B64( P7_signed( P7_enveloped( msg )))

note: msg is the RFC-822 body of the message

62
Content-Type: multipart/signed;
protocol=“application/pkcs7-signature”;
micalg=sha1;
boundary=“—–aaaaa”
—–aaaaa
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hello!
—–aaaaa
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: base64
MIIN2QasDDSdwe/625dBxgdhdsf76rHfrJe65a4f
fvVSW2Q1eD+SfDs543Sdwe6+25dBxfdER0eDsrs5
—–aaaaa-

Question 33

Naming in S/MIME

Answer 33

In S/MIME there is a requirement: the X.509 certificate that is used fto perform the signature must match the From field of the email. So the Naming in S/MIME is used for selecting the certificate and verifying the sender’s address.

• S/MIMEv2 uses the Email= or E= fields in the DN of the X.509 certificate, but it is possible to use the extension subjectAltName with rfc822 encoding
• S/MIMEv3 mandates the use of the subjectAltName extension with rfc822 encoding

Question 34

TLS for POP / IMAP

Answer 34

First the communication channel is opened then the security characteristics are negotiated by means of a dedicated command:
* STARTTLS for IMAP and ACAP
* STLS for POP3
Client and server must allow to be configured to reject user and password.
The client compares the identity in the certificate with the identity of the server

Question 35

Separate ports for SSL/TLS?

Answer 35

It is discouraged by IETF due to the following reasons:
* involve different URLs (e.g. http and https. If you use https you are not sure to have security, you should look at the algorithms used, etc.)
* involve an incorrect secure / insecure model (e.g. is 40-bit SSL secure? is it insecure an application without TLS but with SASL?)
* not easy to implement “use TLS if available”
* doubles the number of necessary ports

But it presents some advantages:
* simple to filter traffic on packet-filter firewalls cause they filter based on addresses, ports, etc
* TLS with client-authentication allows not to expose the applications to attacks

Question 36

Security between MUA and MS when wanting to access an email

Answer 36

Client-server
* authentication of the user: the MS has to be sure that that is the right MUA
* authentication of the server: is it the right MS?
* confidentiality/integrity of mail messages: on the server and while in transit

Question 37

What does a code 3xx indicates?

Answer 37

An intermediate positive step.