Ct2 Merged

Network Security
Email Security
Kamalika Bhattacharjee
E-mail Architecture
• When Alice needs to send a message to Bob,
she invokes a user agent (UA) program to
prepare the message.
• She then uses a message transfer agent (MTA)
to send the message to the mail server at her
site.
• MTA is a client/server program with the client
installed at Alice’s computer and the server
installed at the mail server.
• The message received at the mail server at
Alice’s site is queued with all other messages;
each goes to its corresponding destination. In
Alice’s case, her message goes to the mail
server at Bob’s site.
E-mail Architecture
• A client/server MTA is responsible for the e-
mail transfer between the two servers.
• When the message arrives at the destination
mail server, it is stored in Bob’s mailbox, a
special file that holds the message until it is
retrieved by Bob.
• When Bob needs to retrieve his messages,
including the one sent by Alice, he invokes a
message access agent (MAA).
• The MAA is also designed as a client/server
program with the client installed at Bob’s
computer and the server installed at the mail
server.
E-mail Architecture
• The sending of an e-mail from Alice to Bob is a store-retrieve activity. Alice can send an e-mail
today; Bob, being busy, may check his e-mail three days later. During this time, the e-mail is stored
in Bob’s mailbox until it is retrieved.
• The main communication between Alice and Bob is through two application programs: the MTA
client at Alice’s computer and the MAA client at Bob’s computer.
• The MTA client program is a push program; the client pushes the message when Alice needs to
send it. The MAA client program is a pull program; the client pulls the messages when Bob is ready
to retrieve his e-mail.
• Alice and Bob cannot directly communicate using an MTA client at the sender site and an MTA
server at the receiver site. This requires that the MTA server be running all the time, because Bob
does not know when a message will arrive.
➢This is not practical, because Bob may turn off his computer when he does not need it.
E-mail Security
• Sending an e-mail is a one-time activity.
• The nature of this activity is different than IPSec or SSL, where we assume that the two parties
create a session between themselves and exchange data in both directions.
• In e-mail, there is no session. Alice and Bob cannot create a session.
• This is security of a unidirectional message because what Alice sends to Bob is totally independent
from what Bob sends to Alice.
• Cryptographic Algorithms
• Cryptographic Secrets
• Certificates
E-mail Security
• Cryptographic Algorithms:
• If there is no session and no handshaking to negotiate the algorithms for encryption/decryption
and hashing, how can the receiver know which algorithm the sender has chosen for each
purpose?
• One solution is for the underlying protocol to select one algorithm for each cryptographic
operation and to force Alice to use only those algorithms.
• This solution is very restrictive and limits the capabilities of the two parties.
• A better solution is for the underlying protocol to define a set of algorithms for each operation
that the user used in his/her system.
• Alice includes the name (or identifiers) of the algorithms she has used in the e-mail. For example,
Alice can choose triple DES for encryption/decryption and MD5 for hashing. When Alice sends a
message to Bob, she includes the corresponding identifiers for triple DES and MD5 in her message.
• Bob receives the message and extracts the identifiers first. He then knows which algorithm to use
for decryption and which one for hashing.
E-mail Security
• Cryptographic Secrets
• The same problem for the cryptographic algorithms applies to the cryptographic secrets
(keys): If there is no negotiation, how can the two parties establish secrets between
themselves?
• Alice and Bob could use asymmetric-key algorithms for authentication and encryption, which
do not require the establishment of a symmetric key. However, the use of asymmetric-key
algorithms is very inefficient for the encryption/decryption of a long message.
• Most e-mail security protocols today require that encryption/decryption be done using a
symmetric-key algorithm and a one-time secret key sent with the message.
• But the secret key to decrypt the message is encrypted with the public key of the receiver and
is sent with the message
• Alice can create a secret key and send it with the message she sends to Bob. To protect the
secret key from interception by Eve, the secret key is encrypted with Bob’s public key.
E-mail Security
• Certificates
• It is obvious that some public-key algorithms must be used for e-mail security. For example,
we need to encrypt the secret key or sign the message.
• To encrypt the secret key, Alice needs Bob’s public key; to verify a signed message, Bob needs
Alice’s public key.
• So, for sending a small authenticated and confidential message, two public keys are needed.
• How can Alice be assured of Bob’s public key, and how can Bob be assured of Alice’s public
key?
• Each e-mail security protocol has a different method of certifying keys.
PGP
• Pretty Good Privacy (PGP) was invented by Phil Zimmermann
• provides e-mail with privacy, integrity, and authentication.
• can be used to create a secure e-mail message or to store a file securely for future retrieval.
• First Scenario: Plaintext
• no message integrity or confidentiality
• Next Improvement: Message Integrity
• Alice creates a digest of the message and signs it with her private key.
• When Bob receives the message, he verifies the message by using Alice’s public key.
An authenticated message
PGP
• Next Improvement: Compression
• to make the packet more compact
• No security benefit
• Confidentiality with One-Time Session Key
• Alice can create a session key, use the session key to encrypt the message and the digest, and
send the key itself with the message. However, to protect the session key, Alice encrypts it
with Bob’s public key.
• When Bob receives the packet, he first decrypts
the key, using his private key to remove the key.
• He then uses the session key to decrypt the rest
of the message.
• After decompressing the rest of the message,
Bob creates a digest of the message and checks
to see if it is equal to the digest sent by Alice.
• If it is, then the message is authentic.
PGP
• Code Conversion
• Another service provided by PGP is code conversion.
• Most e-mail systems allow the message to consist of only ASCII characters.
• To translate other characters not in the ASCII set, PGP uses Radix-64 conversion.
• Each character to be sent (after encryption) is converted to Radix-64 code
• Segmentation
• PGP allows segmentation of the message after it has been converted to Radix-64
• This is to make each transmitted unit the uniform size as allowed by the underlying e-mail
protocol.
PGP: Key Rings
• Alice may need to send messages to many people; she needs key rings.
• In this case, Alice needs a ring of public keys, with a key belonging to each person with whom Alice
needs to correspond (send or receive messages).
• In addition, the PGP designers specified a ring of private/public keys.
• One reason is that Alice may wish to change her pair of keys from time to time.
• Another reason is that Alice may need to correspond with different groups of people. Alice
may wish to use a different key pair for each group.
• Each user to have two sets of rings: a ring of private/public

keys and a ring of public keys of other people
• Everyone can have more than one public key
PGP: Key Rings
• Case 1:
• Alice needs to send a message to another person in the community.
• She uses her private key to sign the digest.
• She uses the receiver’s public key to encrypt a newly created session key.
• She encrypts the message and signed digest with the session key created.
• Case2:
• Alice receives a message from another person in the community.
• She uses her private key to decrypt the session key.
• She uses the session key to decrypt the message and digest.
• She uses her public key to verify the digest.
PGP Algorithms
Hash Algorithms
Public-key algorithms
Symmetric-key algorithms
Compression methods
X.509 Certificates
• Protocols that use X.509 certificates depend on the hierarchical structure of the trust.
• There is a predefined chain of trust from the root to any certificate.
• Every user fully trusts the authority of the CA at the root level (prerequisite).
• The root issues certificates for the CAs at the second level, a second level CA issues a certificate for
the third level, and so on.
• Every party that needs to be trusted presents a certificate from some CA in the tree.
• If Alice does not trust the certificate issuer for Bob, she can appeal to a higher level authority up to
the root (which must be trusted for the system to work).
• There is one single path from a fully trusted CA to a certificate.
root
PGP Certificates
• In PGP, there is no need for CAs; anyone in the ring can sign a certificate for anyone else in ring.
• There is no hierarchy of trust in PGP; there is no tree.
• The lack of hierarchical structure may result in the fact that Ted may have one certificate from Bob
and another certificate from Liz. 1 person can have multiple certificates
• If Alice wants to follow the line of certificates for Ted, there are two paths:
• one starts from Bob and one starts from Liz.
• Alice may fully trust Bob, but only partially trust Liz.
• There can be multiple paths in the line of trust from a fully or partially trusted authority to a
certificate.
• In PGP, the issuer of a certificate is usually called an introducer.
• The entire operation of PGP is based on introducer trust, the certificate trust, and the legitimacy
of the public keys.
PGP Certificates
Introducer Trust Levels
• With the lack of a central authority, it is obvious that the ring cannot be very large if every
user in the PGP ring of users has to fully trust everyone else
• To solve this problem, PGP allows different levels of trust.
• The number of levels is mostly implementation dependent, but for simplicity, let us assign
three levels of trust to any introducer: none, partial, and full.
• The introducer trust level specifies the trust levels issued by the introducer for other people in
the ring. Example: Alice may fully trust Bob, partially trust Anne, and not trust John at all.
• There is no mechanism in PGP to determine how to make a decision about the
trustworthiness of the introducer; it is up to the user to make this decision.
PGP Certificates
Certificate Trust Levels
• When Alice receives a certificate from an introducer, she stores the certificate under the name of the
subject (certified entity).
• She assigns a level of trust to this certificate. The certificate trust level is normally the same as the
introducer trust level that issued the certificate.
• Assume that Alice fully trusts Bob, partially trusts Anne and Janette, and has no trust in John.
• The following scenarios can happen:
• Bob issues two certificates, one for Linda (with public key K1) and one for Lesley (with public key
K2).
• Alice stores the public key and certificate for Linda under Linda’s name and assigns a full level
of trust to this certificate.
• Alice also stores the certificate and public key for Lesley under Lesley’s name and assigns a full
level of trust to this certificate.
PGP Certificates
Certificate Trust Levels
• Anne issues a certificate for John (with public key K3).
• Alice stores this certificate and public key under John’s name, but assigns a partial level for this
certificate.
• Janette issues two certificates, one for John (with public key K3) and one for Lee (with public key
K4).
• Alice stores John’s certificate under his name and Lee’s certificate under his name, each with a
partial level of trust.
• John now has two certificates, one from Anne and one from Janette, each with a partial level
of trust.
• John issues a certificate for Liz.
• Alice can discard or keep this certificate with a signature trust of none.
PGP Certificates
Key Legitimacy
• The purpose of using introducer and certificate trusts is to determine legitimacy of a public key.
• The procedure for determining key legitimacy in PGP is: The level of the key legitimacy for a user is the
weighted trust levels of that user.
• For example, suppose we assign the following weights to certificate trust levels:
1. A weight of 0 to a nontrusted certificate
2. A weight of 1/2 to a certificate with partial trust
3. A weight of 1 to a certificate with full trust
• Then to fully trust an entity, Alice needs one fully trusted certificate or two partially trusted certificates for that
entity. For example, Alice can use John’s public key in the previous scenario because both Anne and Janette
have issued a certificate for John, each with a certificate trust level of 1/2.
• Legitimacy of a public key belonging to an entity does not have anything to do with the trust level of that
person.
• Although Bob can use John’s public key to send a message to him, Alice cannot accept any certificate issued by John because, for
Alice, John has a trust level of none.
PGP Certificates
Starting the Ring
• key legitimacy of a trusted or partially trusted entity can be also determined by other methods
1. Alice can physically obtain Bob’s public key–> meeting or via call.
2. Bob can send his public key to Alice by e-mail.
• Both Alice and Bob make a 16-byte MD5 (or 20-byte SHA-1) digest from the key. The digest is normally
displayed as eight groups of 4 digits (or ten groups of 4 digits) in hexadecimal and is called a fingerprint.
• Alice can then call Bob and verify the fingerprint on the phone. If the key is altered or changed during
the e-mail transmission, the two fingerprints do not match.
• PGP has created a list of words, each representing a 4-digit combination. When Alice calls Bob, Bob can
pronounce the eight words (or ten words) for Alice.
• The words are carefully chosen by PGP to avoid those similar in pronunciation
4. In PGP, nothing prevents Alice from getting Bob’s public key from a CA in a separate procedure. She
can then insert the public key in the public key ring
PGP Key Ring Tables
Private Key Ring Table UKPET
• User ID. The user ID is usually the e-mail address of the user. However, the user may designate a
unique e-mail address or alias for each key pair. The table lists the user ID associated with each pair.
• Key ID. This column uniquely defines a public key among the user’s public keys. In PGP, the key ID for
each pair is calculated as (key mod 2^{64}).
• The key ID is needed for the operation of PGP because Bob may have several public keys belonging
to Alice in his public key ring. When he receives a message from Alice, Bob must know which key
ID to use to verify the message.
• Sending just 8 bytes reduces the size of the message.
• Public Key. lists the public key belonging to a particular private key/public key pair.
• Encrypted Private Key. shows the encrypted value of the private key in the private key/public key pair.
PGP saves only the encrypted version of the private key.
• Timestamp. This column holds the date and time of the key pair creation. It helps the user decide
when to purge old pairs and when to create new ones.
PGP Key Ring Tables
Public Key Ring Table UK (PC)^2 KT
• User ID, Key ID. As in the private key ring table

• Public Key. This is the public key of the entity.
• Producer Trust. This column defines the producer level of trust. In most implementations, it can
only be of one of three values: none, partial, or full.
• Certificate(s). This column holds the certificate or certificates signed by other entities for this entity.
A user ID may have more than one certificate
• Certificate Trust(s). This column represents the certificate trust or trusts. If Anne sends a certificate
for John, PGP searches the row entry for Anne, finds the value of the producer trust for Anne,
copies that value, and inserts it in the certificate trust field in the entry for John.
• Key Legitimacy. This value is calculated by PGP based on the value of the certificate trust and the
predefined weight for each certificate trust.
• Timestamp. This column holds the date and time of the column creation.
Trust Model in PGP
• PGP can create a trust model for any user in a
ring with the user as the center of activity.
• The diagram may change with any changes in
the public key ring table.
➢ Nine entities have a legitimate key. Alice can encrypt a
message to any one of these entities or verify a
signature received from one of these entities (Alice’s
key is never used in this model).
➢ There are also three entities that do not have any Trust model for Alice
legitimate keys with Alice.
Web of Trust
• PGP can eventually make a web of trust between a group of people.
• If each entity introduces more entities to other entities, the public key ring for each entity
gets larger and larger and entities in the ring can send secure e-mail to each other.
Example
Example
Example
Example
Example
Key Revocation
• It may become necessary for an entity to revoke his or her public key from the ring.
• This may happen if the owner of the key feels that the key is compromised (stolen, for example) or
just too old to be safe.
• To revoke a key, the owner can send a revocation certificate signed by herself.
• The revocation certificate must be signed by the old key and disseminated to all the people in the
ring that use that public key.
Extracting Information from Rings
• Sender Site
• Alice needs five pieces of information: the key ID of
the public key she is using, her private key, the
session key, Bob’s public key ID, and Bob’s public key.
• To obtain these five pieces of information, Alice
needs to feed four pieces of information to PGP: her
user ID (for this e-mail), her passphrase, a sequence
of key strokes with possible pauses, and Bob’s user
ID.
• Alice’s public-key ID (to be sent with the message) and her private key (to sign
the message) are stored in the private key ring table. Alice selects the user ID
(her e-mail address) that she wants to use as an index to this ring.
• PGP extracts the key ID and the encrypted private key. PGP uses the predefined
decryption algorithm and her hashed passphrase (as the key) to decrypt this
private key.
• Sender Site
• The session key in PGP is a random number with a size
defined in the encryption/decryption algorithm. PGP
uses a random number generator to create a random
session key; the seed is a set of arbitrary keystrokes
typed by Alice on her keyboard.
• Each key stroke is converted to 8 bits and each pause
between the keystrokes is converted to 32 bits. The
combination goes through a complex random number
generator to create a very reliable random number as
the session key. Note that the session key in PGP is a
one-time random key and used only once.
• Alice also needs Bob’s key ID (to be sent with the message) and Bob’s public key (to encrypt the
session key). These two pieces of information are extracted from the public key ring table using
Bob’s user ID (his e-mail address).
• Receiver Site
• At the receiver site, Bob needs three pieces of information:
Bob’s private key (to decrypt the session key), the session
key (to decrypt the data), and Alice’s public key (to verify
the signature).
• Bob uses the key ID of his public key sent by Alice to find
his corresponding private key needed to decrypt the
session key. This piece of information can be extracted
from Bob’s private key ring table.
• The private key is encrypted when stored. Bob needs to
use his passphrase and the hash function to decrypt it.
• The encrypted session key is sent with the message; Bob
uses his decrypted private key to decrypt the session key.
• Bob uses Alice’s key ID sent with the message to extract
Alice’s public key, which is stored in Bob’s public key ring
table
PGP Packets: Header
• Tag. The recent format for this field defines a tag as an 8-bit flag; the first bit (most significant) is always 1. The
second bit is 1 for latest version. The remaining six bits can define up to 64 different packet types
• Length. It is length of entire packet in bytes. Size is variable; it can be 1, 2, or 5 bytes. The receiver can
determine the number of bytes of the length field by looking at the value of the byte immediately following
the tag field. SSP Pe CD LU
Some commonly used packet types

PGP Packets: Header
• Tag. The recent format for this field defines a tag as an 8-bit flag; the first bit (most significant) is always 1. The
second bit is 1 for latest version. The remaining six bits can define up to 64 different packet types
• Length. It is length of entire packet in bytes. Size is variable; it can be 1, 2, or 5 bytes. The receiver can
determine the number of bytes of the length field by looking at the value of the byte immediately following
the tag field.
Some commonly used packet types

PGP Packets: Literal Data Packet
• This carries or holds the actual data that is being transmitted or stored.
• It is the most elementary type of message; that is, it cannot carry any other
packet
• Mode. This one-byte field defines how data is written to the packet. The
value of this field can be “b” for binary, “t” for text, or any other locally
defined value.
• Length of next field. This one-byte field defines the length of the next field
(file name field).
• File name. This variable-length field defines the name of the file or
message as an ASCII string.
• Timestamp. This four-byte field defines the time of creation or last
modification of the message. The value can be 0, which means that the
user chooses not to specify a time.
• Literal data. This variable-length field carries the actual data (file or
message) in text or binary (depending on the value of the mode field).
PGP Packets: Compressed Data Packet
• Compression method. This one-byte field defines the
compression method used to compress the data (next field). The
values defined for this field so far are 1 (ZIP) and 2 (ZLIP). Also, an
implementation can use other experimental compression
methods.
• Compressed data. This variable-length field carries the data after
compression. Data in this field can be one packet or the
concatenation of two or more packets. The common situation is
a single literal data packet or a combination of a signature packet
followed by a literal data packet.
PGP Packets: Data Packet Encrypted with
Secret Key
• Carries data from one packet or a combination of packets that have been encrypted using a
conventional symmetric key algorithm.
• A packet carrying the one-time session key must be sent before this packet
PGP Packets: Signature Packet
• Version. one-byte field defines the PGP version used
• Length. This field was originally designed to show the length of the next
two fields, but because the size of these fields is now fixed, the value of
this field is 5.
• Signature type. one-byte field defines purpose of the signature, the
document it signs.
• Timestamp. four-byte field defines the time the signature was calculated.
• Key ID. This eight-byte field defines the public-key ID of the signer. It
indicates to the verifier which signer public key should be used to decrypt
the digest.
• Public-key algorithm. This one-byte field gives the code for the public-key
algorithm used to encrypt the digest. The verifier uses the same algorithm
to decrypt the digest. • First two bytes of message digest. These
• Hash algorithm. This one-byte field gives the code for the hash algorithm
two bytes are used as a kind of checksum.
used to create the digest. They ensure that the receiver is using the
right key ID to decrypt the digest.
• Signature. variable-length field, it is
encrypted digest signed by the sender
PGP Packets: Signature Packet
Some signature values
PGP Packets: Session-Key Packet Encrypted
with Public Key
• used to send the session key encrypted with the receiver
public key.
• Version. one-byte, defines the PGP version being used.
• Key ID. eight-byte field defines the public-key ID of the
sender. It indicates to the receiver which sender public key
should be used to decrypt the session key.
• Public-key algorithm. This one-byte field gives the code for
the public-key algorithm used to encrypt the session key. The
receiver uses the same algorithm to decrypt the session key.
• Encrypted session. This variable-length field is the encrypted
value of the session key created by the sender and sent to 1. One-octet symmetric encryption algorithm
the receiver. The encryption is done on the following: 2. The session key
3. A two-octet checksum equal to the sum of
the preceding session-key octets
PGP Packets: Public-Key & User ID
Public Key
• Version. one-byte field defines PGP version being used.
• Timestamp. four-byte field defines the time the key was created.
• Validity. two-byte field shows the number of days the key is valid. If
the value is 0, it means the key does not expire.
• Public-key algorithm. This one-byte field gives the code for the
public-key algorithm.
• Public key. variable-length field holds the public key itself. Its
contents depend on the public-key algorithm used.
User ID
• This packet identifies a user and can normally associate the user ID
contents with a public key of the sender. User ID is normally the
name of the user followed by an e-mail address.
PGP Messages
• Signed Message
• Encrypted Message
• Certificate Message
• session-key packet is just a single packet.

The encrypted data packet is made of a
compressed packet.
• The compressed packet is made of a literal
data packet. The last one holds the literal
data.
S/MIME
• Another security service designed for electronic mail
• It is an enhancement of the Multipurpose Internet Mail Extension (MIME) protocol
• MIME
• supplementary protocol that allows non-ASCII data to be sent through e-mail.
• transforms non-ASCII data at the sender site to NVT ASCII data and delivers it to the client MTA
to be sent through the Internet.
• The message at the receiving side is transformed back to the original data.
• It is a set of software functions that transform non-ASCII data to ASCII data, and vice versa
S/MIME: Cryptographic Message Syntax (CMS)
• S/MIME adds some new content types to include security services to the MIME. All of these new
types include the parameter “application/pkcs7-mime,” in which “pkcs” defines “Public Key
Cryptography Specification.”
• Cryptographic Message Syntax (CMS)
• To define how security services, such as confidentiality or integrity, can be added to MIME
content types, S/MIME has defined Cryptographic Message Syntax (CMS).
• The syntax in each case defines the exact encoding scheme for each content type.
Data Content Type This is an arbitrary string. The object created is called Data
Signed-Data Content Type This type provides only integrity of data. It contains any type
and zero or more signature values. The encoded result is an object called signedData.
1. For each signer, a message digest is created from the content using the specific
hash algorithm chosen by that signer.
2. Each message digest is signed with the private key of the signer.
3. The content, signature values, certificates, and algorithms are then collected to
create the signedData object.
S/MIME
Signed-data content type Enveloped-data content type

Enveloped-Data Content Type

• This type is used to provide privacy for the message.
• It contains any type and zero or more encrypted keys and certificates. The encoded result is an
object called envelopedData.
• Steps:
1. A pseudorandom session key is created for the symmetric-key algorithms to be used.
2. For each recipient, a copy of the session key is encrypted with the public key of each recipient.
3. The content is encrypted using the defined algorithm and created session key.
4. The encrypted contents, encrypted session keys, algorithm used, and certificates are encoded
using Radix-64.
Digested-Data Content Type

• This type is used to provide integrity for the message.
• The result is normally used as the content for the enveloped-data content type. The encoded result
is an object called digestedData.
• Steps:
1. A message digest is calculated from the content.
2. The message digest, the algorithm, and the content are added together to create the
digestedData object.
Encrypted-Data Content Type

• This type is used to create an encrypted version of any content type.
• Although this looks like the enveloped-data content type, the encrypted-data content type has no
recipient.
• It can be used to store the encrypted data instead of transmitting it.
• The process is very simple, the user employs any key (normally driven from the password) and any
algorithm to encrypt the content.
• The encrypted content is stored without including the key or the algorithm. The object created is
called encryptedData.
Authenticated-Data Content Type

• This type is used to provide authentication of the
data. The object is called authenticatedData.
• Steps:
1. Using a pseudorandom generator, a MAC key is
generated for each recipient.
2. The MAC key is encrypted with the public key
of the recipient.
3. A MAC is created for the content.
4. The content, MAC, algorithms, and other
information are collected together to form the
authenticatedData object.
S/MIME
Key Management Cryptographic Algorithms

• The key management in S/MIME is a • S/MIME defines several cryptographic
combination of key management used by algorithms. The term “must” means an
X.509 and PGP. absolute requirement; the term “should”
means recommendation.
• S/MIME uses public-key certificates signed by
the certificate authorities defined by X.509.
• However, the user is responsible to maintain
the web of trust to verify signatures as defined
by PGP.
S/MIME
• An example of an enveloped-data in which a small message is encrypted using triple DES
• Applications of S/MIME
• It is predicted that S/MIME will become the industry choice to provide security for commercial e-
mail.
• Applications of PGP
• PGP has been extensively used for personal e-mails. It will probably continue to be.
S/MIME Services
Simplified S/MIME Functional Flow
Radix-64
• Radix-64 divides the binary data (made of streams of bits) into 24-bit blocks. Each block is then
divided into four sections, each made of 6 bits
• Each 6-bit section is interpreted as one character according to the following table:
Radix-64 conversion
Radix-64 encoding table

DNSSEC
• DNS Security Extensions (DNSSEC) are used by several protocols that provide email security.
Domain Name System

• DNS is a directory lookup service that provides a mapping between the name of a host on the
Internet and its numeric IP address.
• Essential to the functioning of the Internet.
• DNS is used by UAs 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 database, Name servers and Resolvers
DNS Components
• 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.
The DNS Database
• 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
• 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.
The DNS Database
• Using this database, DNS servers provide a name-to-
address directory service for network applications that
need to locate specific servers.
• Example: every time an email message is sent or a Web
page is accessed, there must be a DNS name lookup to
determine the IP address of the email server or Web server.
• The distributed DNS database that supports the DNS
functionality must be updated frequently because of the
rapid and continued growth of the Internet.
• 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.
• DNS name servers automatically send out updates to other
relevant name servers as conditions warrant. Resource Record Types
DNS Operation
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.
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.
5. The user program is given the IP address or an
error message.
DNSSEC
• DNSSEC provides end-to-end protection
• Uses digital signatures that are created by responding zone administrators and verified by a recipient’s
resolver software.
• 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.
• It 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.
• RFC 4035, Protocol Modifications for the DNS Security Extensions: Defines the concept of a signed zone,
along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-
aware resolver to authenticate both DNS resource records and authoritative DNS error indications
DNSSEC Operation
DNSSEC is designed to protect DNS clients from accepting forged or altered DNS resource records. It does
this by using digital signatures to provide:
• Data origin authentication: Ensures that data has originated from the correct source.
• Data integrity verification: Ensures that the content of a RR has not been modified.
• The DNS zone administrator digitally signs every Resource Record set (RRset) in the zone, and
publishes this collection of digital signatures, along with the zone administrator’s public key, in the DNS
itself.
• In DNSSEC, trust in the public key (for signature verification) of the source is established not by going
to a third party or a chain of third parties (as in public key infrastructure [PKI] chaining)
• It is done by starting from a trusted zone (such as the root zone) and establishing the chain of trust
down to the current source of response through successive verifications of signature of the public key
of a child by its parent.
• The public key of the trusted zone is called the trust anchor.
DNSSEC Resource Records
• DNSKEY: Contains a public key.
• RRSIG: A resource record digital signature.
• NSEC: Authenticated denial of existence record.
• DS: Delegation signer.
• An RRSIG is associated with each RRset, where an RRset is the set of resource records that have the
same label, class, and type.
• When a client requests data, an RRset is returned, together with the associated digital signature in an
RRSIG record.
• The client obtains the relevant DNSKEY public key and verifies the signature for this RRset.
DNSSEC
• DNSSEC depends on establishing the authenticity of the DNS hierarchy leading to the domain name in
question
• Its operation depends on beginning the use of cryptographic digital signatures in the root zone.
• The DS resource record facilitates key signing and authentication between DNS zones to create an
authentication chain, or trusted sequence of signed data, from the root of the DNS tree down to a
specific domain name.
• To secure all DNS lookups, including those for non-existent domain names and record types, DNSSEC
uses the NSEC resource record to authenticate negative responses to queries.
• NSEC is used to identify the range of DNS names or resource record types that do not exist among the
sequence of domain names in a zone.
Email Treats and Mitigations
SP 800-177 recommends use of a variety of
standardized protocols as a means for
countering these threats.
• 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 email
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.
• Domain Keys 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.
The Interrelationship between Protocols
• The Interrelationship of DNSSEC, SPF, DKIM,
DMARC, DANE, and S/MIME for Assuring
Message Authenticity and Integrity
Network Security
Web Security: Network and Transport layers
Kamalika Bhattacharjee
Web Security Considerations
• Need for tailored security tools:
• Underlying software is extraordinarily complex. This complex software may hide
many potential security flaws. The short history of the Web is filled with examples of
new and upgraded systems, properly installed, that are vulnerable to a variety of
security attacks.
• A Web server can be exploited as a launching pad into the corporation’s or agency’s
entire computer complex. Once the Web server is subverted, an attacker may be able
to gain access to data and systems not part of the Web itself but connected to the
server at the local site.
• Casual and untrained (in security matters) users are common clients for Web based
services. Such users are not necessarily aware of the security risks that exist and do
not have the tools or knowledge to take effective countermeasures.
Web Security Threats
Web Traffic Security Approaches
IP Security (IPSec)
• Collection of protocols designed by the Internet Engineering Task Force (IETF) to
provide security for a packet at the network level.
• Helps to create authenticated and confidential packets for the IP layer
• Usefulness:
• Enhance the security of those client/server programs, such as electronic mail, that use their
own security protocols.
• Enhance the security of those client/server programs, such as HTTP, that may or may not use
the security services provided at the transport layer.
• Provide security for node-to-node communication programs such as routing protocols.
Modes of IPSec
• Transport Mode
• Here IPSec protects what is delivered from the transport layer to the network layer.
• Protects the network layer payload, the payload to be encapsulated in the network layer
• Does not protect the IP header; it only protects the information coming from the transport
layer. In this mode, the IPSec header (and trailer) are added to the information coming from
the transport layer. The IP header is added later.
• Normally used for host-to-host (end-to-end) protection of data.
• The sending host uses IPSec to authenticate and/or encrypt the payload delivered from the
transport layer. The receiving host uses IPSec to check the authentication and/or decrypt the
IP packet and deliver it to the transport layer.
Modes of IPSec
• Tunnel Mode
• Here, IPSec protects the entire IP packet. It takes an IP packet, including the header, applies
IPSec security methods to the entire packet, and then adds a new IP header
• The new IP header has different information than the original IP header.
• Normally used when either the sender or the receiver is not a host; example: between two
routers, between a host and a router, or between a router and a host.
• Entire packet is protected from intrusion between the sender and the receiver, as if the whole
packet goes through an imaginary tunnel
Modes of IPSec
Transport mode vs. tunnel mode

Authentication Header (AH) Protocol
• Designed to authenticate the source host and to ensure the integrity of the payload
carried in the IP packet.
• Uses a hash function and a symmetric key to create a message digest; the digest is
inserted in the authentication header (AH). The AH is then placed in the appropriate
location, based on the mode (transport or tunnel).
• Steps:
• An authentication header is added to the payload with the authentication data field set to 0.
• Padding may be added to make the total length even for a particular hashing algorithm.
• Hashing is based on the total packet. However, only those fields of the IP header that do not change
during transmission are included in the calculation of the message digest (authentication data).
• The authentication data are inserted in the authentication header.
• The IP header is added after changing the value of the protocol field to 51 to show that the packet
carries an authentication header.
• The next header field inside authentication header holds the original value of the protocol field.
Authentication Header (AH) Protocol
• Next header: defines the type of payload carried by
the IP datagram (such as TCP, UDP, ICMP, or OSPF).
The process copies the value of the protocol field in
the IP datagram to this field.
• Payload length: defines the length of the
authentication header in 4-byte multiples excluding
the first 8 bytes.
• Security parameter index: plays the role of a virtual
circuit identifier and is the same for all packets sent
during a connection called a Security Association. • Sequence number: provides ordering
information for a sequence of datagrams.
• Authentication data: result of applying a hash
function to the entire IP datagram except for the • prevent a playback: sequence number
fields that are changed during transit (e.g., time-to- is not repeated even if a packet is
live). retransmitted and does not wrap
around after it reaches 232; a new
connection must be established.
Encapsulating Security Payload (ESP)
• AH protocol does not provide privacy, only source authentication and data
integrity.
• ESP provides source authentication, integrity, and privacy.
• Adds a header and trailer. Authentication data are added at the end of the
packet, which makes its calculation easier.
• Steps:
• An ESP trailer is added to the payload.
• The payload and the trailer are encrypted.
• The ESP header is added.
• The ESP header, payload, and ESP trailer are used to create the authentication data.
• The authentication data are added to the end of the ESP trailer.
• The IP header is added after changing the protocol value to 50.
Encapsulating Security Payload (ESP)
• Security parameter index and Sequence number:
Similar to that defined for the AH protocol.
• Padding: This variable-length field (0 to 255 bytes)
of 0s serves as padding.
• Pad length: The 8-bit pad-length field defines the
number of padding bytes. The value is between 0
and 255; the maximum value is rare.
• Next header: Similar to that defined in the AH The difference between authentication data in AH and
protocol and serves the same purpose as the
ESP is: in AH, part of the IP header is included in the
protocol field in the IP header before
calculation of the authentication data; in ESP, it is not.
encapsulation.
• Authentication data: Result of applying an
IPSec supports both IPv4 and IPv6. In IPv6, however,
authentication scheme to parts of the datagram.
AH and ESP are part of the extension header
Services Provided by IPSec
• Access Control: IPSec provides access control indirectly using a Security
Association Database (SAD). If a packet arrives at a destination with no Security
Association already established for this packet, the packet is discarded.
• Message Integrity: Message integrity is preserved in both AH and ESP. A digest of
data is created and sent by the sender to be checked by the receiver.
• Entity Authentication: The Security Association and the keyed-hash digest of the
data sent by the sender authenticate the sender of the data in both AH and ESP.
• Confidentiality: The encryption of the message in ESP provides confidentiality. AH,
however, does not provide confidentiality.
• Replay Attack Protection: In both protocols, the replay attack is prevented by
using sequence numbers and a sliding receiver window.
Replay Attack Protection
• Each IPSec header contains a unique sequence number when the Security
Association is established.
• The number starts from 0 and increases until 232− 1.
• When the sequence number reaches the maximum, it is reset to 0 and, at the
same time, the old Security Association is deleted and a new one is established.
• To prevent processing duplicate packets, IPSec mandates the use of a fixed-size
window at the receiver.
• The size of the window is determined by the receiver with a default value of 64.
The shaded packets signify
received packets that have been
checked and
authenticated
Replay Attack Protection
• Case 1: The sequence number of the packet is less than N. This puts the packet to the left of the
window. In this case, the packet is discarded. It is either a duplicate or its arrival time has expired.
• Case 2: The sequence number of the packet is between N and (N + W − 1), inclusive. This puts the
packet inside the window. In this case, if the packet is new (not marked) and it passes the
authentication test, the sequence number is marked and the packet is accepted. Otherwise, it is
discarded.
• Case 3: The sequence number of the packet is greater than (N + W − 1). This puts the packet to the
right of the window. In this case, if the packet is authenticated, the corresponding sequence
number is marked and the window slides to the right to cover the newly marked sequence
number. Otherwise, the packet is discarded.
• If a packet arrives with a sequence number much larger than (N + W), then the sliding of the
window may cause many unmarked numbers to fall to the left of the window. These packets,
when they arrive, will never be accepted; their time has expired.
Transport Layer Security (TLS)
• An Internet standard evolved from a commercial protocol known as Secure Sockets Layer (SSL).
• Current version is Version 1.3
• Although SSL implementations are still around, it has been deprecated by IETF and is disabled by
most corporations offering TLS software.
• TLS is a general purpose service implemented as two layers of protocols that rely on TCP.
• There are two implementation choices:
• For full generality, TLS could be provided as part of the underlying protocol suite and
therefore be transparent to applications.
• Alternatively, TLS can be embedded in specific packages. For example, most browsers come
equipped with TLS, and most Web servers have implemented the protocol.
• Designed to make use of TCP to provide a reliable end-to-end secure service
• The TLS Record Protocol provides basic security services to various higher layer protocols. In
particular, the Hypertext Transfer Protocol (HTTP), which provides the transfer service for Web
client/server interaction, can operate on top of TLS.
• Three higher-layer protocols are defined as part of TLS and used in the management of TLS
exchanges
• Handshake Protocol
• Change Cipher Spec Protocol
• Alert Protocol
• Heartbeat Protocol is defined in a separate RFC
TLS Protocol Stack

• Connection: A connection is a transport (in the OSI layering model definition) that
provides a suitable type of service.
• For TLS, such connections are peer-to-peer relationships.
• The connections are transient.
• Every connection is associated with one session.
• Session: A TLS session is an association between a client and a server.
• Sessions are created by the Handshake Protocol.
• Sessions define a set of cryptographic security parameters, which can be shared among
multiple connections.
• Used to avoid the expensive negotiation of new security parameters for each connection.
A session state is defined by the following parameters:
• Session identifier: An arbitrary byte sequence chosen by the server to identify an active or
resumable session state.
• Peer certificate: An X509.v3 certificate of the peer. This element of the state may be null.
• Compression method: The algorithm used to compress data prior to encryption.
• Cipher spec: Specifies the bulk data encryption algorithm (such as null, AES, etc.) and a hash
algorithm (such as MD5 or SHA-1) used for MAC calculation. It also defines cryptographic
attributes such as the hash_size.
• Master secret: 48-byte secret shared between the client and server.
• Is resumable: A flag indicating whether the session can be used to initiate new connections.
A connection state is defined by the following parameters:
• Server and client random: Byte sequences that are chosen by the server and client for each
connection.
• Server (resp. Client) write MAC secret: The secret key used in MAC operations on data sent by the
server (resp. Client).
• Server (resp. Client) write key: The symmetric encryption key for data encrypted by the server
(resp. Client) and decrypted by the client (resp. server).
• Initialization vectors: first initialized by the TLS Handshake Protocol. Thereafter, the final
ciphertext block from each record is preserved for use as the IV with the following record. When a
block cipher in CBC mode is used, an initialization vector (IV) is maintained for each key.
• Sequence numbers: Each party maintains separate sequence numbers for transmitted and
received messages for each connection. When a party sends or receives a “change cipher spec
message,” the appropriate sequence number is set to zero. Sequence numbers may not exceed 264
- 1.
• In theory, there may also be multiple simultaneous sessions between parties, but this feature is
not used in practice.
• Once a session is established, there is a current operating state for both read and write (i.e.,
receive and send).
• In addition, during the Handshake Protocol, pending read and write states are created.
• Upon successful conclusion of the Handshake Protocol, the pending states become the current
states.
Cipher block chaining (CBC) is a mode of operation for a block cipher -- one in which a sequence of
bits are encrypted as a single unit, or block, with a cipher key applied to the entire block. It uses an
initialization vector (IV) of a certain length.
TLS Record Protocol
• Takes an application message to be transmitted, fragments the data into manageable blocks,
optionally compresses the data, applies a MAC, encrypts, adds a header, and transmits the resulting
unit in a TCP segment.
• Received data are decrypted, verified, decompressed, and reassembled before being delivered to
higher-level users.
TLS Record Protocol Operation

Provides two services for TLS connections:
• Confidentiality: The Handshake Protocol defines a shared
secret key that is used for conventional encryption of TLS
payloads.
• Message Integrity: The Handshake Protocol also defines a
shared secret key that is used to form a message
authentication code (MAC).
TLS Record Protocol
TLS Record Protocol Operation
• Each upper-layer message is fragmented into blocks of 214 =16,384
bytes or less.
2^14 2^14 2^14
• Compression must be lossless and may not increase the content length
by more than 1024 bytes. In TLSv2, no compression algorithm is
lossless <=2^14+2048
specified, so the default compression algorithm is null.
• The next step in processing is to compute a message authentication
code over the compressed data. TLS makes use of the HMAC
algorithm:
• Compressed message plus the MAC are encrypted using symmetric

encryption. Encryption may not increase the content length by more
than 1024 bytes, so that the total length may not exceed 214 + 2048
bytes
TLS Record Protocol
The final step of TLS Record Protocol processing is to prepend
a header consisting of the following fields:
• Content Type (8 bits): The higher-layer protocol used to TLS Record Format
process the enclosed fragment.
• Major Version (8 bits): Indicates major version of TLS in use.
For TLSv2, the value is 3.
• Minor Version (8 bits): Indicates minor version in use. For
TLSv2, the value is 1.
• Compressed Length (16 bits): The length in bytes of the
plaintext fragment (or compressed fragment if compression
is used).
Change Cipher Spec Protocol
• One of the four TLS-specific protocols that use the TLS Record Protocol, and it is the simplest.
• Consists of a single message which consists of a single byte with the value 1.
• The sole purpose of this message is to cause the pending state to be copied into the current state,
which updates the cipher suite to be used on this connection.
Alert Protocol
• The Alert Protocol is used to convey TLS-related alerts to the peer entity.
• As with other applications that use TLS, alert messages are compressed and
encrypted, as specified by the current state.
• Each message in this protocol consists of two bytes
• The first byte takes the value warning (1) or fatal (2) to convey the severity of
the message.
• If the level is fatal, TLS immediately terminates the connection. Other
connections on the same session may continue, but no new connections on this
session may be established.
• The second byte contains a code that indicates the specific alert.
Alert Protocol
• Fatal Alerts
Alert Protocol
• Fatal Alerts
Alert Protocol
• Warning
Handshake Protocol
• The most complex part of TLS
• Allows the server and client to authenticate each other and to negotiate an encryption and MAC
algorithm and cryptographic keys to be used to protect data sent in a TLS record
• Used before any application data is transmitted
• Consists of a series of messages exchanged by client and server
• Each message has three fields:
• Type (1 byte): Indicates one of 10 messages.
• Length (3 bytes): The length of the message
in bytes.
• Content (>= 0 bytes): The parameters
associated with this message
Handshake Protocol Action
Handshake Protocol Action version(tls)
Phase 1. Establish security capabilities random(nonce)
Sess id(0/not)
cipher suite (algo desc)
comp methd (algo)
• Phase 1 initiates a logical connection and establishes the security capabilities that will be associated
with it.
• The exchange is initiated by the client, which sends a client_hello message with the following
parameters:
• Version: The highest TLS version understood by the client.
• Random: A client-generated random structure consisting of a 32-bit timestamp and 28 bytes generated by
a secure random number generator. These values serve as nonces and are used during key exchange to
prevent replay attacks.
• Session ID: A variable-length session identifier. A nonzero value indicates that the client wishes to update
the parameters of an existing connection or to create a new connection on this session. A zero value
indicates that the client wishes to establish a new connection on a new session.
Phase 1. Establish security capabilities
• Phase 1 initiates a logical connection and establishes the security capabilities that will be associated
with it.
• The exchange is initiated by the client, which sends a client_hello message with the following
parameters:
■ CipherSuite: This is a list that contains the combinations of cryptographic algorithms supported by the
client, in decreasing order of preference. Each element of the list (each cipher suite) defines both a key
exchange algorithm and a CipherSpec.
■ Compression Method: This is a list of the compression methods the client supports.
• After sending the client_hello message, the client waits for the server_hello message, which
contains the same parameters as the client_hello message.
Phase 1. Establish security capabilities
For the server_hello message, the following conventions apply

• The Version field contains the lowest of the version suggested by the client and the highest supported by the
server.
• The Random field is generated by the server and is independent of the client’s Random field.
• If the SessionID field of the client was nonzero, the same value is used by the server; otherwise the server’s
SessionID field contains the value for a new session.
• The CipherSuite field contains the single cipher suite selected by the server from those proposed by the client.
The first element of the Ciphersuite parameter is the key exchange method for conventional encryption and MAC.
The supported methods are RSA, Fixed Diffie–Hellman, Ephemeral Diffie-Hellman, Anonymous Diffie–Hellman
• The Compression field contains the compression method selected by the server from those proposed by the
client.
Phase 2. Server authentication and key exchange
• The server begins this phase by sending its certificate if it needs to be authenticated
• The message contains one or a chain of X.509 certificates. The certificate message is required for any agreed-
on key exchange method except anonymous Diffie–Hellman.
• If fixed Diffie–Hellman is used, this certificate message functions as the server’s key exchange message
because it contains the server’s public Diffie–Hellman parameters.
• Next, a server_key_exchange message may be sent if it is required.
• It is not required in two instances: (1) The server has sent a certificate with fixed Diffie–Hellman
parameters; or (2) RSA key exchange is to be used.
• The server_key_exchange message is needed for: Anonymous Diffie–Hellman, Ephemeral Diffie–Hellman,
RSA key exchange (in which the server is using RSA but has a signature-only RSA key)
Phase 2. Server authentication and key exchange
• Next, a nonanonymous server (server not using anonymous Diffie–Hellman) can request a certificate from
the client
• The certificate_request message includes two parameters: certificate_type and certificate_authorities.
• The certificate_type indicates the public-key algorithm and its use
• The second parameter is a list of the distinguished names of acceptable certificate authorities
• The final message in phase 2, and one that is always required, is the server_done message
• Sent by the server to indicate the end of the server hello and associated messages
• After sending this message, the server will wait for a client response. This message has no parameters
Phase 3. Client authentication and key exchange
• Upon receipt of the server_done message, the client should verify that the server provided a valid
certificate (if required) and check that the server_hello parameters are acceptable.
• If all is satisfactory, the client sends one or more messages back to the server.
• If the server has requested a certificate, the client begins this phase by sending a certificate message. If no
suitable certificate is available, the client sends a no_certificate alert instead.
• Next is the client_key_exchange message, which must be sent in this phase. The content of the message
depends on the type of key exchange.
• Finally, in this phase, the client may send a certificate_verify message to provide explicit verification of a
client certificate. This message is only sent following any client certificate that has signing capability (i.e., all
certificates except those containing fixed Diffie–Hellman parameters).
Phase 4. Finish
• Phase 4 completes the setting up of a secure connection.

• The client sends a change_cipher_spec message and copies the pending CipherSpec into the current
CipherSpec.
• This is not part of the Handshake Protocol but is sent using the Change Cipher Spec Protocol.
• The client then immediately sends the finished message under the new algorithms, keys, and secrets.
• The finished message verifies that the key exchange and authentication processes were successful.
• In response to these two messages, the server sends its own change_ cipher_spec message, transfers
the pending to the current CipherSpec, and sends its finished message.
• At this point, the handshake is complete and the client and server may begin to exchange application-
layer data.
Heartbeat Protocol
• With respect to networks, a heartbeat is a periodic signal generated by hardware or software to
indicate normal operation or to synchronize other parts of a system.
• A heartbeat protocol is typically used to monitor the availability of a protocol entity.
• In the specific case of TLS, a Heartbeat protocol was defined in 2012 inRFC 6250 (Transport Layer
Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension).
• Heartbeat protocol runs on top of the TLS Record Protocol and consists of two message types:
heartbeat_request and heartbeat_response.
• The use of the Heartbeat protocol is established during Phase 1 of the Handshake protocol.
Each peer indicates whether it supports heartbeats.
• If heartbeats are supported, the peer indicates whether it is willing to receive
heartbeat_request messages and respond with heartbeat_response messages or only willing
to send heartbeat_request messages.
Heartbeat Protocol
• A heartbeat_request message can be sent at any time. Whenever a request message is received, it
should be answered promptly with a corresponding heartbeat_response message.
• The heartbeat_request message includes payload length, payload, and padding fields.
• The payload is a random content between 16 bytes and 64 Kbytes in length.
• The corresponding heartbeat_response message must include an exact copy of the received
payload.
• The padding is also random content.
• The padding enables the sender to perform a path MTU (maximum transfer unit) discovery
operation, by sending requests with increasing padding until there is no answer anymore, because
one of the hosts on the path cannot handle the message.
• The heartbeat serves two purposes.
• First, it assures the sender that the recipient is still alive, even though there may not have been
any activity over the underlying TCP connection for a while.
• Second, the heartbeat generates activity across the connection during idle periods, which
avoids closure by a firewall that does not tolerate idle connections.
HTTPS
• HTTPS (HTTP over SSL) refers to the combination of HTTP and SSL to implement secure communication between a
Web browser and a Web server.
• The HTTPS capability is built into all modern Web browsers. Its use depends on the Web server supporting HTTPS
communication.
• The principal difference seen by a user of a Web browser is that URL (uniform resource locator) addresses begin with
https:// rather than http://.
• A normal HTTP connection uses port 80. If HTTPS is specified, port 443 is used, which invokes SSL.
• When HTTPS is used, the following elements of the communication are encrypted:
• URL of the requested document
• Contents of the document
• Contents of browser forms (filled in by browser user)
• Cookies sent from browser to server and from server to browser
• Contents of HTTP header
• HTTPS is documented in RFC 2818, HTTP Over TLS. Implementations over both SSL/TLS are referred to as HTTPS.
Connection Initiation
• For HTTPS, the agent acting as the HTTP client also acts as the TLS client.
• The client initiates a connection to the server on the appropriate port and then sends the TLS
ClientHello to begin the TLS handshake.
• When the TLS handshake has finished, the client may then initiate the first HTTP request.
• All HTTP data is to be sent as TLS application data. HTTP client->server connection
• Normal HTTP behavior, including retained connections, should be followed. TLS client->server session
TCP entity client->server connection
• There are three levels of awareness of a connection in HTTPS. TLS connection
• At the HTTP level, an HTTP client requests a connection to an HTTP server by sending a
connection request to the next lowest layer. Typically, the next lowest layer is TCP, but it also may
be TLS/SSL.
• At the level of TLS, a session is established between a TLS client and a TLS server. This session can
support one or more connections at any time.
• A TLS request to establish a connection begins with the establishment of a TCP connection
between the TCP entity on the client side and the TCP entity on the server side.
Connection Closure
• An HTTP client or server can indicate the closing of a connection by including the following line in
an HTTP record: Connection: close.
• This indicates that the connection will be closed after this record is delivered.
• The closure of an HTTPS connection requires that TLS close the connection with the peer TLS entity
on the remote side, which will involve closing the underlying TCP connection.
• At the TLS level, the proper way to close a connection is for each side to use the TLS alert protocol
to send a close_notify alert.
• TLS implementations must initiate an exchange of closure alerts before closing a connection.
• A TLS implementation may, after sending a closure alert, close the connection without waiting for
the peer to send its closure alert, generating an “incomplete close”.
• An implementation that does this may choose to reuse the session.
• This should only be done when the application knows (typically through detecting HTTP
message boundaries) that it has received all the message data that it cares about.
Connection Closure
• HTTP clients also must be able to cope with a situation in which the underlying TCP connection is
terminated without a prior close_notify alert and without a Connection: close indicator.
• Such a situation could be due to a programming error on the server or a communication error that
causes the TCP connection to drop.
• However, the unannounced TCP closure could be evidence of some sort of attack.
• So the HTTPS client should issue some sort of security warning when this occurs.
Secure Shell (SSH)
• A protocol for secure network communications designed to be relatively simple and inexpensive to
implement.
• The initial version, SSH1 was focused on providing a secure remote logon facility to replace TELNET
and other remote logon schemes that provided no security.
• SSH also provides a more general client/server capability and can be used for such network
functions as file transfer and email.
• A new version, SSH2, fixes a number of security flaws in the original scheme. SSH2 is documented
as a proposed standard in IETF RFCs 4250 through 4256.
• SSH client and server applications are widely available for most operating systems.
• It has become the method of choice for remote login and X tunneling and is rapidly becoming one
of the most pervasive applications for encryption technology outside of embedded systems
• SSH is organized as three protocols that typically run on top of TCP
Secure Shell (SSH)
3 Protocol of SSH
• Transport Layer Protocol: Provides server

authentication, data confidentiality, and data
integrity with forward secrecy (i.e., if a key is
compromised during one session, the
knowledge does not affect the security of
earlier sessions). It may optionally provide
compression.
• User Authentication Protocol: Authenticates
the user to the server.
• Connection Protocol: Multiplexes multiple
logical communications channels over a single,
underlying SSH connection.
SSH Protocol Stack

Transport Layer Protocol Host keys
pkt exchange
key exchange
During key exchange, server is authenticated. Client must know server’s key gen
HOST KEYS : public host key. It can maintain DB of host->pb key or CA can do it.
• Server authentication occurs at the transport layer, based on the server possessing a public/private key
pair.
• A server may have multiple host keys using multiple different asymmetric encryption algorithms.
• Multiple hosts may share the same host key.
• The server host key is used during key exchange to authenticate the identity of the host. For this to be
possible, the client must have a priori knowledge of the server’s public host key.
• RFC 4251 dictates two alternative trust models that can be used:
1. The client has a local database that associates each host name (as typed by the user) with the
corresponding public host key.
Advantage • This method requires no centrally administered infrastructure and no third-party coordination.
Disadvantage The downside is that the database of name-to-key associations may become burdensome to
maintain.
Transport Layer Protocol
HOST KEYS :
• Server authentication occurs at the transport layer, based on the server possessing a public/private key
pair.
• A server may have multiple host keys using multiple different asymmetric encryption algorithms.
• Multiple hosts may share the same host key.
• The server host key is used during key exchange to authenticate the identity of the host. For this to be
possible, the client must have a priori knowledge of the server’s public host key.
• RFC 4251 dictates two alternative trust models that can be used:
2. The host name-to-key association is certified by a trusted certification authority (CA). The client
only knows the CA root key and can verify the validity of all host keys certified by accepted CAs.
• This alternative eases the maintenance problem, since ideally, only a single CA key needs to be
securely stored on the client. On the other hand, each host key must be appropriately certified
by a central authority before authorization is possible.
Transport Layer Protocol*
PACKET EXCHANGE:
Each packet is in the following format
• Packet length: Length of the packet in bytes, not including the packet length and MAC fields.
• Padding length: Length of the random padding field.
• Payload: Useful contents of the packet. Prior to algorithm negotiation, this field is uncompressed. If
compression is 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 padding so that the total length of the packet (excluding the MAC field) is
a multiple of the cipher block size, or 8 bytes for a stream cipher.
• Message authentication code (MAC): If message authentication has been negotiated, this field
contains the MAC value. This value is computed over the entire packet plus a sequence number,
excluding the MAC field.
• The sequence number is an implicit 32-bit packet sequence that is initialized to zero for the first
packet and incremented for every packet. The sequence number is not included in the packet sent
over the TCP connection.
PACKET EXCHANGE:
Once an encryption algorithm has

been negotiated, the entire packet
(excluding the MAC field) is
encrypted after the MAC value is
calculated.
SSH Transport Layer Protocol Packet Formation

PACKET EXCHANGE:
• First, the client establishes a TCP connection to the server. This is

done via the TCP protocol and is not part of the Transport Layer
Protocol.
• Once the connection is established, the client and server exchange
data, referred to as packets, in the data field of a TCP segment.
• The SSH Transport Layer packet exchange consists of a sequence of
steps.
• The first step, the identification string exchange, begins with
the client sending a packet with an identification string of the
form:
SSH-protoversion-softwareversion SP comments CR LF
SP,CR, and LF are space character, carriage return, and line feed,
respectively.
SSH Transport Layer Protocol Packet Exchang

PACKET EXCHANGE:
• The server responds with its own identification string. These
strings are used in the Diffie–Hellman key exchange.
• Next comes algorithm negotiation. Each side sends an
SSH_MSG_KEXINIT
containing lists of supported algorithms in the order of
preference to the sender.
• There is one list for each type of cryptographic algorithm. The
algorithms include key exchange, encryption, MAC algorithm,
and compression algorithm.
• For each category, the algorithm chosen is the first algorithm on
the client’s list that is also supported by the server.
SSH Transport Layer Protocol Packet Exchang

• The next step is key exchange. The

specification allows for alternative
methods of key exchange, but at
present, only two versions of Diffie–
Hellman key exchange are specified.
• Both versions are defined in RFC 2409

and require only one packet in each
direction.
SSH Transport Layer Cryptographic Algorithms
• KEY EXCHANGE STEPS:
• C is client
• S is server
• p is a large safe prime
• g is a generator for a
subgroup of GF(p)
• q is order of the subgroup
• V_S is S’s identification string;
V_C is C’s identification string
• K_S is S’s public host key
• I_C is C’s SSH_MSG_KEXINIT
message
• I_S is S’s SSH_MSG_KEXINIT
• The values of p, g, and q are known to both client and server as a result of message
the algorithm selection negotiation.
• The hash function hash() is also decided during algorithm negotiation.
➢ A safe prime is a prime number p of the form p = 2q + 1 where q is also prime. In such a case, q is called a Sophie Germain prime
• As a result of these steps, the two sides now share a master key K.
• The server has been authenticated to the client, because the server has used its private key to sign
its half of the Diffie-Hellman exchange.
• The hash value H serves as a session identifier for this connection. Once computed, the session
identifier is not changed, even if the key exchange is performed again for this connection to obtain
fresh keys.
• The end of key exchange is signalled by the exchange of SSH_MSG_NEWKEYS packets. At this
point, both sides may start using the keys generated from K
• The final step is service request.
• The client sends an SSH_MSG_SERVICE_REQUEST packet to request either the User
Authentication or the Connection Protocol.
• Subsequent to this, all data is exchanged as the payload of an SSH Transport Layer packet,
protected by encryption and MAC.
KEY GENERATION:
• The keys used for encryption and MAC (and any needed IVs) are generated from the shared secret
key K, the hash value from the key exchange H, and the session identifier, which is equal to H
unless there has been a subsequent key exchange after the initial key exchange.
where HASH() is the hash function determined during algorithm negotiation.

User Authentication Protocol*
• Provides the means by which the client is authenticated to the server. Three types of message.
• Authentication requests from the client have the format:
• user name is the authorization identity the client is claiming,
• service name is the facility to which the client is requesting
access (typically the SSH Connection Protocol)
• method name is authentication method being used in the
request.
• The first byte has decimal value 50, which is interpreted as
SSH_MSG_USERAUTH_REQUEST
• Server either rejects the authentication request or accepts the request but requires one or more additional authentication
methods.
• Server sends a message with the format:
• name-list is a list of methods that may

productively continue the dialog
• If the server accepts authentication, it sends a single byte message: SSH_MSG_USERAUTH_SUCCESS (52)
User Authentication Protocol
MESSAGE EXCHANGE
50,name,service,auth method
1. The client sends a SSH_MSG_USERAUTH_REQUEST with a requested method of none.
2. The server checks to determine if the user name is valid. If not, the server returns SSH_MSG_USERAUTH_FAILURE
with the partial success value of false. If the user name is valid, the server proceeds to step 3.
3. The server returns SSH_MSG_USERAUTH_FAILURE with a list of one or more authentication methods to be used.
4. The client selects one of the acceptable authentication methods and sends a SSH_MSG_USERAUTH_REQUEST
with that method name and the required method-specific fields. At this point, there may be a sequence of
exchanges to perform the method.
5. If the authentication succeeds and more authentication methods are required, the server proceeds to step 3,
using a partial success value of true. If the authentication fails, the server proceeds to step 3, using a partial
success value of false.
6. When all required authentication methods succeed, the server sends a SSH_MSG_USERAUTH_SUCCESS message,
and the Authentication Protocol is over.
At this point server and client have been authenticated
Connection Protocol
• The SSH Connection Protocol runs on top of the SSH Transport Layer Protocol and assumes that a
secure authentication connection is in use.
• That secure authentication connection, referred to as a tunnel, is used by the Connection Protocol
to multiplex a number of logical channels.
• CHANNEL MECHANISM:
• All types of communication using SSH, such as a terminal session, are supported using
separate channels.
• Either side may open a channel. For each channel, each side associates a unique channel
number, which need not be the same on both ends.
• Channels are flow controlled using a window mechanism.
• No data may be sent to a channel until a message is received to indicate that window space is
available.
Channel->Connection->Session
Connection Protocol
CHANNEL MECHANISM:
• The life of a channel progresses through three stages: opening a channel, data transfer, and
closing a channel.
• When either side wishes to open a new channel, it allocates a local number for the channel
and then sends a message of the form:
• The channel type identifies the application for this channel
• The sender channel is the local channel number
• initial window size specifies how many bytes of channel data
can be sent to the sender of this message without adjusting
the window
• Maximum packet size specifies the maximum size of an
individual data packet that can be sent to the sender
Connection Protocol
CHANNEL MECHANISM:
• If the remote side is able to open the channel, it returns a
SSH_MSG_CHANNEL_OPEN_CONFIRMATION message, which includes the sender channel
number, the recipient channel number, and window and packet size values for incoming
traffic.
• Otherwise, the remote side returns a SSH_MSG_CHANNEL_OPEN_FAILURE message with a
reason code indicating the reason for failure.
• Once a channel is open, data transfer is performed using a SSH_MSG_CHANNEL_DATA
message, which includes the recipient channel number and a block of data.
• These messages, in both directions, may continue as long as the channel is open.
• When either side wishes to close a channel, it sends a SSH_MSG_CHANNEL_CLOSE message,
which includes the recipient channel number.
Connection Protocol
Completion of Transport Layer

Protocol & User Auth Protocol
sender& recipient channel no, pkt size, window size
Example of SSH Connection recipient channel no & data

Protocol Message Exchange
recipient channel no
Connection Protocol
CHANNEL TYPES
Four channel types are recognized in the SSH Connection Protocol specification.
• session: The remote execution of a program. The program may be a shell, an application such as
file transfer or email, a system command, or some built-in subsystem. Once a session channel is
opened, subsequent requests are used to start the remote program.
• x11: This refers to the X Window System, a computer software system and network protocol that
provides a graphical user interface (GUI) for networked computers. X allows applications to run on
a network server but to be displayed on a desktop machine.
• forwarded-tcpip: This is remote port forwarding

• direct-tcpip: This is local port forwarding
Connection Protocol
PORT FORWARDING
• One of the most useful features of SSH is port forwarding.
• Provides the ability to convert any insecure TCP connection into a secure SSH connection. This is also
referred to as SSH tunneling.
• A port is an identifier of a user of TCP.
• Any application that runs on top of TCP has a port number.
• Incoming TCP traffic is delivered to the appropriate application on the basis of the port number.
• An application may employ multiple port numbers.
• For example, for the Simple Mail Transfer Protocol (SMTP), the server side generally listens on port
25, so an incoming SMTP request uses TCP and addresses the data to destination port 25.
• TCP recognizes that this is the SMTP server address and routes the data to the SMTP server
application.
Connection Protocol
• A client application identified by port number x and a server
application identified by port number y
• At some point, the client application invokes the local TCP entity and
requests a connection to the remote server on port y.
• The local TCP entity negotiates a TCP connection with the remote TCP
entity, such that the connection links local port x to remote port y.
• To secure this connection, SSH is configured so that the SSH Transport
Layer Protocol establishes a TCP connection between the SSH client
and server entities, with TCP port numbers a and b, respectively.
• A secure SSH tunnel is established over this TCP connection.
• Traffic from the client at port x is redirected to the local SSH entity
and travels through the tunnel where the remote SSH entity delivers
the data to the server application on port y. Traffic in the other
direction is similarly redirected.
Connection Protocol
• SSH supports two types of port forwarding: local forwarding and remote
forwarding.
• Local forwarding allows the client to set up a “hijacker” process.
• This will intercept selected application-level traffic and redirect it from an unsecured TCP
connection to a secure SSH tunnel.
• SSH is configured to listen on selected ports.
• SSH grabs all traffic using a selected port and sends it through an SSH tunnel.
• On the other end, the SSH server sends the incoming traffic to the destination port dictated by
the client application.
Connection Protocol
• Local forwarding Example:
Suppose you have an email client on your desktop and use it to get email from your mail server via the Post Office
Protocol (POP). The assigned port number for POP3 is port 110. We can secure this traffic in the following way:
1. The SSH client sets up a connection to the remote server.
2. Select an unused local port number, say 9999, and configure SSH to accept traffic from this port destined for port
110 on the server.
3. The SSH client informs the SSH server to create a connection to the destination, in this case mailserver port 110.
4. The client takes any bits sent to local port 9999 and sends them to the server inside the encrypted SSH session.
The SSH server decrypts the incoming bits and sends the plaintext to port 110.
5. In the other direction, the SSH server takes any bits received on port 110 and sends them inside the SSH session
back to the client, who decrypts and sends them to the process connected to port 9999.
Connection Protocol
Remote Forwarding
• With remote forwarding, the user’s SSH client acts on the server’s behalf.
• The client receives traffic with a given destination port number, places the traffic on the correct port
and sends it to the destination the user chooses.
• Example:
You wish to access a server at work from your home computer. Because the work server is behind a
firewall, it will not accept an SSH request from your home computer. However, from work you can set up
an SSH tunnel using remote forwarding. This involves the following steps.
1. From the work computer, set up an SSH connection to your home computer. The firewall will allow
this, because it is a protected outgoing connection.
2. Configure the SSH server to listen on a local port, say 22, and to deliver data across the SSH
connection addressed to remote port, say 2222.
3. You can now go to your home computer, and configure SSH to accept traffic on port 2222.
4. You now have an SSH tunnel that can be used for remote logon to the work server.

Ct2 Merged

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ct2 Merged

Uploaded by

Copyright:

Available Formats

Network Security

• Each user to have two sets of rings: a ring of private/public

• User ID, Key ID. As in the private key ring table

Some commonly used packet types

Some commonly used packet types

• session-key packet is just a single packet.

Signed-data content type Enveloped-data content type

Enveloped-Data Content Type

Digested-Data Content Type

Encrypted-Data Content Type

Authenticated-Data Content Type

Key Management Cryptographic Algorithms

Radix-64 encoding table

Domain Name System

Transport mode vs. tunnel mode

TLS Protocol Stack

TLS Record Protocol Operation

• Compressed message plus the MAC are encrypted using symmetric

For the server_hello message, the following conventions apply

• Phase 4 completes the setting up of a secure connection.

• Transport Layer Protocol: Provides server

SSH Protocol Stack

Once an encryption algorithm has

SSH Transport Layer Protocol Packet Formation

• First, the client establishes a TCP connection to the server. This is

SSH Transport Layer Protocol Packet Exchang

SSH Transport Layer Protocol Packet Exchang

• The next step is key exchange. The

• Both versions are defined in RFC 2409

where HASH() is the hash function determined during algorithm negotiation.

• name-list is a list of methods that may

Completion of Transport Layer

sender& recipient channel no, pkt size, window size

Example of SSH Connection recipient channel no & data

• forwarded-tcpip: This is remote port forwarding

You might also like