BIRLA INSTITUTE OF TECHNOLOGY & SCIENCE, PILANI

WORK INTEGRATED LEARNING PROGRAMMES

Network Security
Security at Application Layer : Email Security

Session : 2
Outline

• Recap from previous class

• Application layer security, Issues and Need
• Email security
• Threat and challenges
• Approaches
• Security application for Email implementation
• Limitation
• Summary

2
Recap from Previous Class
• Course details, structure, calendar
• Introduction to Network Security
• Goals, OSI reference architecture
• Vulnerabilities and controls for each layer
• Security attacks and mechanism
• Implementation techniques
• Cryptography - Symmetric and asymmetric cryptography
• Integrity and authentication
• Steganography
• Block and stream cipher
Security Terminology
Term Description
AES Advance Encryption Standard
CAST Symmetric Key Block Cipher (Carlisle Adams & Stafford Tavares)
CFB Cipher Feed Back
DES Data Encryption Standard
DSS Digital Signature Standard
IDEA International Data Encryption Algorithm (128 bit key block cipher)
RSA Rivest Shamir Adelman
SHA Secure Hash Algorithm
SMTP Simple Mail Transmission Protocol

4
Communication Between Layers

Application Data
Application layer Application layer
Transport payload
Transport layer Transport layer
Network Payload
Network layer Network layer Network layer Network layer
Data Link Payload
Data Link layer Data Link layer Data Link layer Data Link layer

Host A Router Router Host B

5
Application Layer

l Provides services for an application to send and recieve

data over the network, e.g., telnet (port 23), mail (port 25),
finger (port 79)

l Interface to the transport layer

– Operating system dependent
– Socket interface

6
Application Layer Security
l Advantages:
- Most flexible
- Executed in the context of a user, thus easy access to user’s credentials
– Complete access to data hence easier to ensure nonrepudation and small security
granularity
– Application-based security
l Disadvantages:
– Most intrusive
– Implemented in end hosts
– Need for each application hence Expensive & Higher probability of errors
l Require a security system that can be used by different applications – model
for authentication and key distribution

7
Authentication and Key Distribution

• Kerberos (MIT) and its extensions (Secure European System for

Application in a Multi-vendor Environment (SESAME))
• Network Security Program (IBM)
• SPX (Digital Equipment Corporation)
• Exponential Security System (University of Karlsruhe)

8
Kerberos
• User authentication service developed at MIT as part of project Athena
• Based on Needham-Schroeder (1978) protocol
• Threats to networks
• A user may gain access to a particular workstation and pretend to be another user
operating from that workstation
• A user may alter the network address of a workstation so that the requests sent from
the altered workstation appear to come from the impersonated workstation
• A user may eavesdrop on exchanges and use a replay attack to gain entrance to a
server or to disrupt operations
• Kerberos provides a centralized authentication server whose function is to
authenticate users to servers and servers to users
• Kerberos relies on symmetric encryption

9
Kerberos Requirements
• Secure: A network eavesdropper should not be able to obtain the necessary
information to impersonate a user
• Reliable: Kerberos should be highly reliable and should employ a
distributed server architecture with one system able to back up another
• Transparent: User should not be aware that authentication is taking place
beyond the requirement to enter a password.
• Scalable: The system should be capable of supporting large numbers of
clients and servers using a modular, distributed architecture

10
Kerberos Components
• Key Distribution Center (KDC)
• Authentication server (AS)
• Ticket-granting server (TGS)
• Database: users’ identifiers + secret key shared between KDC
and user

11
Ticketing System
• KDC issues tickets that clients and servers can use to mutually
authenticate themselves and agree on shared secrets.
• Ticket:
• Session key
• Name of principal
• Expiration time
• Ticket types:
• Ticket-granting ticket: issued by AS and used between client and TGS
• Service ticket: issued by TGS and used between client and server

12
Kerberos
Kerberos
1.Request ticket- granting ticket
Once per user
2. Ticket + session key logon session
KDC
Client 3. Request service- granting ticket

TGS Once per type

4. Ticket + session key
of service

6. Provide server 5. Request service

authentication

Server
Once per
Service session

13
Kerberos Versions
• Version 4 (MIT) – 1992 Version 4 Limitation
• Versions 1-3 were only used at MIT • Environmental shortcomings
• Shortcomings and limited functionality • Encryption system dependence
(S. Bellovin and M. Merrit 1990) • Internet protocol dependence
• Message byte ordering
• Version 5 (RFC 1510) – 1993 • Ticket lifetime
• Improves on version 4 shortcomings • Authentication forwarding
• Inter-realm authentication
• Technical deficiencies
• Double encryption
• PCBC encryption
• Session keys
• Password attack

14
Security Enhanced Application Protocol
• Applications:
• Terminal access
• File transfer
• Electronic mail
• WWW transactions
• DNS
• Distributed file system

15
Terminal Access
• Protocols running on top of TCP/IP
• Telnet: password based authentication
• Rlogin: address-based authentication
• Security enhanced Telnet
• Kerberos-mediated Telnet encryption: difficult to achieve
• Security-enhanced Telnet e.g., Secure Telnet (STEL) Univ. Milan
• Authentication enforced by STEL is stronger than Telnet
• All data traffic is encrypted between client and server
• Secure Shell (SSH)

16
SSH (Secure Shell)
• Provides secure network communication, used for file transfer and email
• Provides similar services than SSL
• Mutual authentication
• Encrypted sessions between two endpoints
• Used to replace traditional terminal access à Application layer security
• Organized as three protocols running on top of TCP
• Transport Layer Protocol: Provides server authentication, data confidentiality, and
data integrity with forward secrecy
• User Authentication Protocol: Authenticates the user to the server
• Connection Protocol: Multiplexes multiple logical communications channels over a
single, underlying SSH connection

17
SSH Versions
• SSH v1
• Tatu Ylonen, Helsinki University of Technology, Finland
• Source code, documentation, configuration scripts: public and freely available
• SSH v2
• Specified by IETF Secure Shell WG (1st draft: 1997)
• Both version use generic transport layer security protocol over TCP/IP
• Support for Host and user authentication, Data compression, Data
confidentiality, Integrity protection
• Server listens for TCP connection on port 22, assigned to SSH
• Open source implementations: OpenSSH

18
 SSH Transport Layer Protocol547Packet Formation 17.5 / SECURE SHELL (SSH)

Payload • Packet length: Length of the packet in bytes, not including

the packet length and MAC fields
• Padding length: Length of the random padding field
COMPRESS
• Payload: Useful contents of the packet. Prior to algorithm
negotiation, this field is uncompressed. If compression is
seq # pktl pdl Compressed payload Padding
negotiated, then in subsequent packets, this field is
compressed.
• Random padding: Once an encryption algorithm has been
negotiated, this field is added. It contains random bytes of
ENCRYPT MAC
padding so that that total length of the packet (excluding
the MAC field) is a multiple of the cipher block size, or 8
bytes for a stream cipher
Ciphertext
• Message authentication code (MAC): If message
authentication has been negotiated, this field contains the
SSH Packet
MAC value. The MAC value is computed over the entire
pktl = packet length
pdl = padding length
packet plus a sequence number, excluding the MAC field
Figure 17.10 SSH Transport Layer Protocol Packet Formation

-
owing format (Figure 17.10).
19
Packet length: Length of the packet in bytes, not including the packet length
SSH Packet Exchange Steps
• Identification string exchange: client send a packet with identification
string
• Algorithm negotiation: each side send a list of supported algorithms in
order of preference (key exchange, encryption, MAC, compression)
• Key exchange: Client/server share master key
• End of key exchange: Both side start using keys generated from master key
• Service request: data exchange

20
SSH V1 Keys
• Host public key pair
• Bind connection to the desired server host
• Long-term
• Long key size (typically 1,024 bit RSA)
• Server public key pair
• Provide confidentiality
• Short-term
• Short key size (typically 768 bit RSA)
• Changes periodically (i.e. every hour by default)
• For PFS server private key cannot be saved on disk

21
SSH Sessions
• Client à Server: Authentication request
• Server à Client: Server public keys (long-term and short-term)
• Client:
• Compares received keys with its database of pre-distributed keys and accepts
keys
• Generates 256-bit random session key
• Chooses encrypting algorithm
• Pads session key
• Double encrypts session key with server and host public keys

22
SSH Sessions

• Client à Server: Sends double encrypted session key

• Server: Decrypts session key
• Server à Client: send confirmation encrypted by session key

Both parties use session key to encrypt traffic between server and client

23
Authentication

• After session key agreement, client assumes that the server is

authenticated
• If user authentication is required:
• Password authentication
• RSA authentication (server need to know the user’s public key)

24
Electronic Mail Security

25
Electronic Mail
• Most heavily used network-based application
• Used across different architectures and platforms
• Send e-mail to others connected directly or indirectly to the Internet
regardless of host operating systems and communication protocols
• Thus Application requires:
• Authentication
• Confidentiality

26
Secure Mail Approaches

• PGP: Pretty Good Privacy

• PEM: Privacy-Enhanced Mail
• Secure Multipurpose Internet Mail Extensions (S/MIME)

27
Pretty Good Privacy
• Largely due to efforts of one single person Phil Zimmermann
• Provides Confidentiality and authentication for
• Electronic mail
• Storage applications

• Chose best available cryptographic algorithms

• Integrated these algorithms such that
• Independent of operating system and processor
• Based on a small set of easy to use commands
• Made application and documentation available through the Internet
• Created an agreement with a company (Network Associates) to provide
compatible, low-cost commercial version of PGP

28
PGP Usage
PGP became widely used within a few years
• Available worldwide for different platforms
• Based on proven secure algorithms (RSA, DSS, Diffie-Hellman – public
key encryption, CAST-128, IDEA, 3DES for symmetric encryption, SHA-1
for hash coding)
• Wide range of applicability - encrypted files & messages, communicate
securely over Internet and other networks
• Not developed or controlled by governments or standards organizations
• It’s on Internet standards track (RFC 3156)

29
Why PGP?
• Protect privacy
• “I don’t need encryption!” = “I don’t need privacy.”
• Interception transmission to destinations
• Transparent mailbox (dial-up connection)
• You may not but other party may want privacy
• Commercial privacy
• Customer’s data
• Company data
• User’s profiling
• Signed messages
• Authentication
• Integrity

30
PGP Services
Function Algorithms Used Description
A hash code of a message is created using SHA-1. This
Digital signature DSS/SHA or RSA/SHA message digest is encrypted using DSS or RSA with the
sender’s private key and included with the message.
CAST or IDEA or A message is encrypted using CAST-128 or IDEA or 3DES
Message Three-key Triple DES with a one-time session key generated by the sender. The
encryption with Diffie-Hellman session key is encrypted using Diffie-Hellman or RSA with
or RSA the recipient’s public key and included with the message.
A message may be compressed for storage or
Compression ZIP
transmission using ZIP.
To provide transparency for e-mail applications, an
E-mail
Radix-64 conversion encrypted message may be converted to an ASCII string
compatibility
using radix-64 conversion.

31
PGP Cryptographic Functions Notation

594
Ks : Session key for symmetric encryption Source A
E[PRa, H(M)]
Destination B
PUa
PRa : Private key of user A PRa

PUa : Public key of user A M

H
|| Z Z!1
DP
EP
EP : Public key encryption M
Compare

DP : Public key decryption E[PUb, Ks]

(a) Authentication only H
EC : Symmetric key encryption PUb
PRb
DC : Symmetric key decryption
H : Hash function Ks EP DP

|| : Concatenation M
Z EC || DC Z!1
M

Z : Compression using ZIP (b) Confidentiality only

E[PUb, Ks]
PUb
R64 : Conversion to Radix64 ASCII format PRb
E[PRa, H(M)]
PUa
PRa Ks EP
H DP DP
M
EP || Z EC ||
M
DC Z!1 Compare

H
(c) Confidentiality and authentication
Figure 19.1 PGP Cryptographic Functions
32
PGP Authentication
Source A Destination B
E[PRa, H(M)]
PUa
PRa

H DP
M || Z Z!1
EP
M
Compare

E[PUb, Ks]
(a) Authentication only H

PUb
PRb

Ks EP DP
• Sender creates a message M • RSA and MD5: effective digital signature
M
Z EC || DC Z!1
• SHA-1 is used to generate 160 bit hash code of the message
(b) Confidentiality only
schema
E[PUb, Ks]
• Hash code is encrypted with RSA usingPRsender’s private key,
PUb
E[PR , H(M)] a
PUa
• Default: signatures attached to messages
and the result is prepended to the message
b

PR a K EP s

DP
• Support detached signatures
• Receiver uses RSA with sender’s public key to decrypt and
H DP
M
EP || Z EC ||
• User may want to maintain separate
recover hash code DC Z
M !1
Compare signature files
• Receiver generates a new hash code for message and • Detect virus infection of executable
H
programs
compares it with decrypted hash code. If the two match,
(c) Confidentiality and authentication

message is accepted as authentic

Figure 19.1 PGP Cryptographic Functions • Support multiple signature of a message

SHANNON.IR 33
 PRa

PGP Confidentiality
M
H
EP
|| Z Z!1
M
DP

Compare

Source A Destination B
E[PUb, Ks] E[PRa, H(M)]
(a) Authentication only PUaH
PRa
PUb
PRb
H DP
M || Z Z!1
Ks EP EP M DP
Compare
M M
Z EC || DC Z!1
E[PUb, Ks]
(a) Authentication only H
(b) Confidentiality only
E[PUb, Ks]
PUb PUb
PRb a, H(M)]
E[PR
PRb PUa
PRa Ks
• Sender H
generates
Ks EPa message and a random
EP
DP 128-bit
DP number to be used
DP
• IDEA: secret-key encryption
as
M
M
a session EP key || for this
Z message
EC || only M M • Key-distribution:
Z DC DC Z !1 !1
• Message is encrypted using CAST-128 (or IDEA or 3DES) with the Compare
EC || Z
• Randomly generated, one-time session keys
session key
(b) Confidentiality only
E[PU , K ] b s H • Encrypted by receiver’s public key
PU
• Session key is encrypted with RSA using PR
(c) Confidentiality and authentication
b
the recipient’s public keyPUand
E[PR , H(M)]
• Attached to the message
a
b a

is prepended
Figure 19.1 PGPPR
to the message EP
Cryptographic Functions K
a s

• Receiver H uses RSA with its private key to decrypt DP

and recover theDP • Double encryption : IDEA & One-time key
M
session key EP || Z EC ||
SHANNON.IR DC Z
M !1 • RSA key size: Casual (384 bits), Commercial
Compare
• Session key is used to decrypt the message. (512 bits), Military (1024 bits)
H
(c) Confidentiality and authentication
Figure 19.1 PGP Cryptographic Functions

34
PGP Authentication and Confidentiality
Source A Destination B
E[PRa, H(M)]
PR
Source
a A
E[PRa, H(M)]
PUa
Destination B • Signature generated and prepended to
Source A Destination B
H PRa
E[PRa, H(M)]
PU DP
a
PUa plaintext message
M PRa || Z Z!1

M
H
H
EP
Z
M
DP
DP • Plain text message and signature
||
M
EP
EP
|| Z Z!1 Z!1
M
M
Compare
encrypted using CAST-128, IDEA or 3DES
(a) Authentication only
E[PUb, Ks]
H
Compare
Compare and session key encrypted using RSA
PUb E[PU
E[PU ,K]
b, Kbs] s
(a) Authenticationonly
(a) Authentication only PRb H H

PU
PU b b
Ks PRb PRb
EP DP

M KKs s EPEP DP DP M
Z EC || DC Z!1

MConfidentiality only
(b)M M M
ZZ EC | || | DC DCZ!1
EC E[PUb, Ks] Z!1
PUb
(b) Confidentiality E[PRa, H(M)]
(b) Confidentialityonly
only PRb PUa
E[PUb, Ks]
PRa Ks PUb E[PUb, Ks]
PU
EPb E[PRa, H(M)]
PRb E[PRa, H(M)] PUa
H DPPRb DP PUa
M PRa Ks EP
PRa
EP || Z ECKs | | EP
H DP M DP
DP DC Z!1
M H Compare
DP
M EP || Z EC ||
EP || Z EC || M
DC Z!1 M
DC !1 Compare
Z H Compare
(c) Confidentiality and authentication
H
Figure 19.1 PGP Cryptographic Functions H
(c) Confidentiality and authentication
(c) Confidentiality and authentication
Figure 19.1 PGP Cryptographic Functions
Figure 19.1 PGP Cryptographic Functions
SHANNON.IR 35
Compression
• Compression is done after signature and before encryption
• Preferable to sign uncompressed message -> store them together for future
verification
• PGP’s compression algorithm is not deterministic – various implementation
methods run at different speed versus compression ratio
• Encryption after compression strengthen cryptographic security. Compressed
message has less redundancy than original plain text message hence crypto
analysis becomes more difficult
• Compression algorithm used is ZIP

36
Email Compatibility
• Under PGP at least part of block to be transmitted is encrypted
• Part or all of blocks contain an arbitrary 8-bit binary octets stream
• Several e-mail system allow only ASCII text
• PGP converts the binary octets to printable ASCII characters
• Uses Radix-64 conversion which expands the message by 33%
• Radix-64 blindly converts the overall message to ASCII text providing a
certain level of confidentiality
• ZIP with a 2.0 compression ration still generates an overall 35%
compression of the overall message
• PGP can be configured to convert only the signature portion to ASCII

37
Segmentation and Reassembly
• E-mail: restriction on maximum message length
• Long messages broken into segments
• Segments are mailed separately
• PGP automatically divides a long message
• Segmentation is done after all other processing
• Receiving PGP reassembles the original message

38
PGP: Transmission and Reception of Messages
X file Convert from radix 64
X R64!1 [X]

Decrypt key, X
Yes Confidentiality Yes
Signature Generate signature Ks D(PRb, E(PUb, Ks))
required? X signature || X required?
X D(Ks, E(Ks, X))
No No

Compress
X Z(X) Decompress
X Z!1 (X)

Confidentiality Yes Encrypt key, X

Yes Strip signature from X
required? X E(PUb, Ks) || E(Ks, X) Signature
required? verify signature
No
No

Convert to radix 64
X R64[X]

(a) Generic transmission diagram (from A) (b) Generic reception diagram (to B)
Figure 19.2 Transmission and Reception of PGP Messages

39
 mon use. In the RFC 5322 context, messages are viewed as having an envelope and

Secure / Multipurpose Internet Mail Extensions

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 con-
• RFC 5322 : Standard for Internet based text messages
tent 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.
• Message contains Envelope + Content
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 unre-
• Content has header information to help create an Envelope
stricted 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 as-
• There is a unique message id
sumed to be header lines used by the user agent part of the mail system.
A header line usually consists of a keyword, followed by a colon, followed by
• Normally has a keyword followed by colon and keyword arguments
the keyword’s arguments; the format allows a long line to be broken up into several
lines. The most frequently used keywords are From, To, Subject, and Date. Here is
an example message:

Date: October 8, 2009 2:15:49 PM EDT

From: “William Stallings” <[email protected]>
Subject: The Syntax in RFC 5322
To: [email protected]
Cc: [email protected]
Hello. This section begins the actual
message body, which is delimited from the
message heading by a blank line.

SHANNON.IR
40
Multipurpose Internet Mail Extensions
• Extension to RFC 5322 and SMTP
• Limitations of SMTP:
• Can’t transmit executable files or binary objects
• Can’t transmit text data which includes national language characters
• Server may reject a message over a certain size
• Gateways responsible to translate from ASCII to character code EBCDIC don’t use consistent
mapping rules causing translation problems
• Gateways to X.400 electronic mail network can’t handle non-textual data
• Some SMTP implementation don’t adhere fully to SMTP standards
• 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 resolves these issues in a manner compatible to RFC 5322 standard. It has five
additional headers

41
Multipurpose Internet Mail Extensions
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 represen-
tations of the same information. The following is an example:

The five header fields defined in MIME are From: Nathaniel Borenstein <[email protected]>
To: Ned Freed <[email protected]>
• MIME-Version: Must have the parameter value 1.0. This Subject: Formatted text mail

field indicates that the message conforms to RFCs 2045 and

MIME-Version: 1.0
Content-Type: multipart/alternative;
2046 boundary = boundary42
—boundary42
• Content-Type: Describes the data contained in the body Content-Type: text/plain; charset = us-ascii

with sufficient detail that the receiving user agent can pick . . . plain text version of message goes here . . ..
—boundary42
an appropriate agent or mechanism to represent the data Content-Type: text/enriched
to the user or otherwise deal with the data in an . . . RFC 1896 text/enriched version of same message
goes here . . .
appropriate manner —boundary42—

• Content-Transfer-Encoding: Indicates the type of 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
transformation that has been used to represent the body of 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 inter-
the message in a way that is acceptable for mail transport preted 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
• Content-ID: Used to identify MIME entities uniquely in group might collect e-mail messages from participants, bundle these messages, and
send them out in one encapsulating MIME message.
multiple contexts The message type provides a number of important capabilities in MIME.
The message/rfc822 subtype indicates that the body is an entire message, including

• Content-Description: A text description of the object with 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 body; this is useful when the object is not readable (i.e. 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,
audio data) 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 con-
42 the
veyed in this message are not contained in the body. Instead, the body contains
information needed to access the data. As with the other message types, the mes-
S/MIME Functionality
• Enveloped data: This consists of encrypted content of any type and encrypted
content encryption keys for one or more recipients.
• Signed data: A digital signature is formed by taking the message digest of the
content to be signed and then encrypting that with the private key of the signer.
The content plus signature are then encoded using base64 encoding. A signed
data message can only be viewed by a recipient with S/MIME capability.
• Clear-signed data: As with signed data, a digital signature of the content is
formed. However, in this case, only the digital signature is encoded using base64.
As a result, recipients without S/MIME capability can view the message content,
although they cannot verify the signature.
• Signed and enveloped data: Signed-only and encrypted-only entities may be
nested, so that encrypted data may be signed and signed data or clear-signed
data may be encrypted.

43
S/MIME Cryptographic Functions
Function Requirement
Create a message digest to be used in MUST support SHA-1.
forming a digital signature Receiver SHOULD support MD5 for backward compatibility.
Sending and receiving agents MUST support DSS. Sending agents
Encrypt message digest to form a SHOULD support RSA encryption.
digital signature Receiving agents SHOULD support verification of RSA signatures with
key sizes 512 bits to 1024 bits.
Sending and receiving agents SHOULD support Diffie-Hellman.
Encrypt session key for transmission
Sending and receiving agents MUST support RSA encryption with key
with a message
sizes 512 bits to 1024 bits.
Sending and receiving agents MUST support encryption with 3DES.
Encrypt message for transmission
Sending agents SHOULD support encryption with AES. Sending agents
with a one-time session key
SHOULD support encryption with RC2/40.
Receiving agents MUST support HMAC with SHA-1. Sending agents
Create a message authentication code
SHOULD support HMAC with SHA-1.

44
Functional Modules and Standardized Protocols
CHAPTER 19 / ELECTRONIC MAIL SECURITY

• Message User Agent (MUA): This is referred to as a client e-mail

• program or a local network e-mail server. MUA formats a message
Message Transfer Message Transfer Message Transfer
Agent (MTA) Agent (MTA) Agent (MTA)
and performs initial submission into the MHS via a MSA. The
SMTP SMTP recipient MUA processes received mail for storage and/or display
to the recipient user.
SMTP (SMTP, • Mail Submission Agent (MSA): Accepts the message submitted by
local) an MUA and enforces the policies of the hosting domain and the
Mail Submission
requirements of Internet standards. This function may be located
Mail Delivery
Agent (MSA) Message handling Agent (MDA) together with the MUA or as a separate functional model. In the
system (MHS) latter case, the Simple Mail Transfer Protocol (SMTP) is used
between the MUA and the MSA.
SMTP
(SMTP, • Message Transfer Agent (MTA): Relays mail for one application-
local) level hop. It is like a packet switch or IP router in that its job is to
Message User Message Store make routing assessments and to move the message closer to the
Message
Agent (MUA) author (MS) 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.
(IMAP, POP,
local) • Mail Delivery Agent (MDA): Responsible for transferring the
message from the MHS to the MS.
Message Message User • Message Store (MS): An MS can be located on a remote server or
recipient Agent (MUA) on the same machine as the MUA. Typically, an MUA retrieves
messages from a remote server using POP (Post Office Protocol) or
Figure 19.4 Function Modules and Standardized Protocols Used Between Them IMAP (Internet Message Access Protocol).

program or a local network e-mail server. The author MUA formats a mes-
sage and performs initial submission into the MHS via a MSA. The recipient 45
MUA processes received mail for storage and/or display to the recipient user.
Summary

What we covered in this lecture?

ü Application layer security
ü Kerberos system
ü Email security
ü PGP
ü S/MIME
THANK YOU

47