MODULE 4

[Link] Authentication:
Remote user authentication principles:

User authentication is the basis for most types of access control and for user accountability.
RFC 4949 (Internet Security Glossary) defines user authentication as the process of verifying
an identity claimed by or for a system entity.

This process consists of two steps:

Identification step: Presenting an identifier to the security system. (Identifiers should be

assigned carefully, because authenticated identities are the basis for other security services,
such as access control service.)

Verification step: Presenting or generating authentication information that corroborates the

binding between the entity and the identifier.

The NIST Model for electronic user authentication.

❖ NIST SP 800-63-2 (Electronic Authentication Guideline, August 2013) defines

electronic user authentication as the process of establishing confidence in user
identities that are presented electronically to an information system.
❖ Systems can use the authenticated identity to determine if the authenticated individual
is authorized to perform particular functions, such as database transactions or access
to system resources.
❖ SP 800-63-2 defines a general model for user authentication that involves a num ber
of entities and procedures. We discuss this model with reference to Figure 1.

1
Dept. of CSE(Data Science)
 MODULE 4

Figure 1: The NIST SP 800-63-2 E-Authentication Architectural Model

❖ The initial requirement for performing user authentication is that the user must be
registered with the system.
❖ The following is a typical sequence for registration. An applicant applies to a
registration authority (RA) to become a subscriber of a credential service provider
(CSP).
❖ In this model, the RA is a trusted entity that establishes and vouches for the identity of
an applicant to a CSP.
❖ The CSP then engages in an exchange with the subscriber. Depending on the details of
the over all authentication system, the CSP issues some sort of electronic credential to
the subscriber.
❖ The credential is a data structure that authoritatively binds an identity and additional
attributes to a token possessed by a subscriber, and can be verified when presented to
the verifier in an authentication transaction.
❖ The token could be an encryption key or an encrypted password that identifies the
subscriber. The token may be issued by the CSP, generated directly by the subscriber,
or provided by a third party.
❖ The token and credential may be used in subsequent authentication events.
❖ The party to be authenticated is called a claimant and the party verifying that identity
is called a verifier. When a claimant successfully demonstrates possession and control
of a token to a verifier through an authentication protocol, the verifier can verify that
the claimant is the subscriber named in the corresponding credential.
❖ The verifier passes on an assertion about the identity of the subscriber to the relying
party (RP).
❖ The RP can use the authenticated information provided by the verifier to make access
control or authorization decisions.
❖ An implemented system for authentication will differ from or be more com plex than
this simplified model, but the model illustrates the key roles and functions needed for
a secure authentication system.

Means of Authentication:

2
Dept. of CSE(Data Science)
 MODULE 4

There are four general means of authenticating a user’s identity, which can be used alone or
in combination:

❖ Something the individual knows: Examples include a password, a personal

identification number (PIN), or answers to a prearranged set of questions.
❖ Something the individual possesses: Examples include cryptographic keys,
electronic keycards, smart cards, and physical keys. This type of authenticator is
referred to as a token.
❖ Something the individual is (static biometrics): Examples include recognition by
fingerprint, retina, and face.
❖ Something the individual does (dynamic biometrics): Examples include recog
nition by voice pattern, handwriting characteristics, and typing rhythm.

However, each method has problems. An adversary may be able to guess or steal a password.
Similarly, an adversary may be able to forge or steal a token.

A user may forget a password or lose a token. Furthermore, there is a significant

administrative overhead for managing password and token information on systems and
securing such information on systems.

For network-based user authentication, the most important methods involve cryptographic
keys and something the individual knows, such as a password.

Mutual Authentication.

An important application area is that of mutual authentication protocols. Such pro tocols
enable communicating parties to satisfy themselves mutually about each oth er’s identity and
to exchange session keys.

To prevent masquerade and to prevent compromise of session keys, essential identification

and session-key information must be communicated in encrypted form.

This requires the prior existence of secret or public keys that can be used for this purpose.
The second issue, timeliness, is important because of the threat of message replays.

following examples of replay attacks:

3
Dept. of CSE(Data Science)
 MODULE 4

The simplest replay attack is one in which the opponent simply copies a message and replays
it later.

An opponent can replay a timestamped message within the valid time window. If both the
original and the replay arrive within then time window, this incident can be logged.

an opponent can replay a timestamped message within the valid time window, but in addition,
the opponent suppresses the original message. Thus, the repetition cannot be detected.

Another attack involves a backward replay without modification. This is a re play back to the
message sender. This attack is possible if symmetric Encryption is used and the sender cannot
easily recognize the difference between messages sent and messages received on the basis of
content.

Because of this overhead, sequence numbers are generally not used for authentication and
key exchange. Instead, one of the following two general approaches is used:

Timestamps: Party A accepts a message as fresh only if the message contains a timestamp
that, in A’s judgment, is close enough to A’s knowledge of current time. This approach
requires that clocks among the various participants be synchronized.

Challenge/response: Party A, expecting a fresh message from B, first sends B a nonce

(challenge) and requires that the subsequent message (response) received from B contain the
correct nonce value.

This protocol must be both fault tolerant, to cope with network errors, and secure, to cope
with hostile attacks. Second, the opportunity for a successful attack will arise if there is a
temporary loss of synchronization resulting from a fault in the clock mechanism of one of the
parties.

Therefore, any timestamp-based procedure must allow for a window of time sufficiently large
to accommodate network delays yet sufficiently small to minimize the opportunity for attack.

One Way Authentication

The very nature of electronic mail, and its chief benefit, is that it is not necessary for the
sender and receiver to be online at the same time.

4
Dept. of CSE(Data Science)
 MODULE 4

Instead, the email message is forwarded to the receiver’s electronic mailbox, where it is
buffered until the receiver is available to read it.

The “envelope” or header of the email message must be in the clear, so that the message can
be handled by the store-and-forward email protocol, such as the Simple Mail Transfer
Protocol (SMTP) or X.400.

However, it is often desirable that the mail-handling protocol not require access to the
plaintext form of the message, because that would require trusting the mail-handling
mechanism. Accordingly, the email message should be encrypted such that the mail-handling
system is not in possession of the decryption key.

A second requirement is that of authentication. Typically, the recipient wants some assurance
that the message is from the alleged sender.

2. Kerberos
Kerberos is an authentication service developed as part of Project Athena at MIT.

In particular, the following three threats exist:

❖ 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.

Two versions of Kerberos are in common use. Version 4 [MILL88, STEI88] implementations
still exist. Version 5 [KOHL94] corrects some of the security deficiencies of version 4 and
has been issued as a proposed Internet Standard.

Motivation

If a set of users is provided with dedicated personal computers that have no network
connections, then a user’s resources and files can be protected by physically secur ing each
personal computer.

5
Dept. of CSE(Data Science)
 MODULE 4

When these users instead are served by a centralized time-sharing system, the time-sharing
operating system must provide the security.

In this environment, three approaches to security can be envisioned.

❖ Rely on each individual client workstation to assure the identity of its user or users
and rely on each server to enforce a security policy based on user identification (ID).
❖ Require that client systems authenticate themselves to servers, but trust the client
system concerning the identity of its user.
❖ Require the user to prove his or her identity for each service invoked. Also require
that servers prove their identity to clients.

Kerberos supports this third approach. Kerberos assumes a distributed client/server

architecture and employs one or more Kerberos servers to provide an authentication service.

The first published report on Kerberos [STEI88] listed the following requirements.

❖ Secure: A network eavesdropper should not be able to obtain the necessary

information to impersonate a user. More generally, Kerberos should be strong enough
that a potential opponent does not find it to be the weak link.
❖ Reliable: For all services that rely on Kerberos for access control, lack of availability
of the Kerberos service means lack of availability of the supported services. Hence,
Kerberos should be highly reliable and should employ a distributed server architecture
with one system able to back up another.
❖ Transparent: Ideally, the 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. This suggests a modular, distributed architecture.

Kerberos version 4

Version 4 of Kerberos makes use of DES, in a rather elaborate protocol, to pro vide the
authentication service. Viewing the protocol as a whole, it is difficult to see the need for the
many elements contained therein.

A simple authentication dialogue

6
Dept. of CSE(Data Science)
 MODULE 4

The obvious security risk is that of impersonation. An opponent can pretend to be another
client and obtain unauthorized privileges on server machines.

To counter this threat, servers must be able to confirm the identities of clients who request
service.

An alternative is to use an authentication server (AS) that knows the passwords of all users
and stores these in a centralized database.

In addition, the AS shares a unique secret key with each server. These keys have been
distributed physicaly or in some other secure manner. Consider the following hypothetical
dialogue:

❖ In this scenario, the user logs on to a workstation and requests access to server V. The
client module C in the user’s workstation requests the user’s password and then sends
a message to the AS that includes the user’s ID, the server’s ID, and the user’s
password.
❖ The AS checks its database to see if the user has supplied the proper password for this
user ID and whether this user is permitted access to server V.
❖ If both tests are passed, the AS accepts the user as authentic and must now convince
the server that this user is authentic. To do so, the AS creates a ticket that con tains the
user’s ID and network address and the server’s ID. This ticket is encrypted using the
secret key shared by the AS and this server.
❖ This ticket is then sent back to C. Because the ticket is encrypted, it cannot be altered
by C or by an opponent.

7
Dept. of CSE(Data Science)
 MODULE 4

❖ With this ticket, C can now apply to V for service. C sends a message to V con taining
C’s ID and the ticket.
❖ V decrypts the ticket and verifies that the user ID in the ticket is the same as the
unencrypted user ID in the message. If these two match, the server considers the user
authenticated and grants the requested service.
❖ Each of the ingredients of message (3) is significant. The ticket is encrypted to
prevent alteration or forgery. The server’s ID (IDV) is included in the ticket so that the
server can verify that it has decrypted the ticket properly.
❖ IDC is included in the ticket to indicate that this ticket has been issued on behalf of C.
Finally, ADC serves to counter the following threat. An opponent could capture the
ticket transmitted in message (2), then use the name IDC and transmit a message of
form (3) from another workstation.

A More secure authentication dialogue:

If user C logs on to a workstation in the morning and wishes to check his or her mail at a mail
server, C must supply a password to get a ticket for the mail server.

If C wishes to check the mail several times during the day, each attempt requires re entering
the password. We can improve matters by saying that tickets are reusable.

If a user wished to access a print server, a mail server, a file server, and so on, the first
instance of each access would require a new ticket and hence require the user to enter the
password.

The second problem is that the earlier scenario involved a plaintext transmis sion of the
password [message (1)].

To solve these additional problems, we introduce a scheme for avoiding plain text passwords
and a new server, known as the ticket-granting server (TGS). The new (but still hypothetical)
scenario is as follows.

8
Dept. of CSE(Data Science)
 MODULE 4

The new service, TGS, issues tickets to users who have been authenticated to AS. Thus, the
user first requests a ticket-granting ticket (Tickettgs) from the AS. The client module in the
user workstation saves this ticket.

The TGS then grants a ticket for the particular service. The client saves each service-granting
ticket and uses it to authenticate its user to a server each time a particular service is requested.

❖ The client requests a ticket-granting ticket on behalf of the user by sending its user’s
ID to the AS, together with the TGS ID, indicating a request to use the TGS service.
❖ The AS responds with a ticket that is encrypted with a key that is derived from the
user’s password (Kc), which is already stored at the AS. When this response arrives at
the client, the client prompts the user for his or her password, generates the key, and
attempts to decrypt the incoming message.
❖ The client requests a service-granting ticket on behalf of the user. For this pur pose,
the client transmits a message to the TGS containing the user’s ID, the ID of the
desired service, and the ticket-granting ticket.
❖ The TGS decrypts the incoming ticket using a key shared only by the AS and the TGS
(Ktgs) and verifies the success of the decryption by the presence of its ID. It checks to
make sure that the lifetime has not expired.
❖ The client requests access to a service on behalf of the user. For this purpose, the
client transmits a message to the server containing the user’s ID and the service
granting ticket. The server authenticates by using the contents of the ticket.

The Version 4 Authentication dialogue

9
Dept. of CSE(Data Science)
 MODULE 4

If this lifetime is very short (e.g., minutes), then the user will be repeatedly asked for a
password.

If the lifetime is long (e.g., hours), then an opponent has a greater opportunity for replay.

An opponent could eavesdrop on the network and capture a copy of the ticket-granting ticket
and then wait for the legitimate user to log out.

Thus, we arrive at an additional requirement. A network service (the TGS or an application

service) must be able to prove that the person using a ticket is the same person to whom that
ticket was issued.

The second problem is that there may be a requirement for servers to authenticate themselves
to users. Without such authentication, an opponent could sabotage the configuration so that
messages to a server were directed to another location.

Table 1: provide a simplified overview.

Table 1: Summary of Kerberos Version 4 Message Exchanges

10
Dept. of CSE(Data Science)
 MODULE 4

Figure 3: Overview of Kerberos

Table 1 shows the technique for distributing the session key. As before, the client sends a
message to the AS requesting access to the TGS.

The AS responds with a message, encrypted with a key derived from the user’s password
(Kc), that contains the ticket. The encrypted message also contains a copy of the session key,
Kc,tgs, where the subscripts indicate that this is a session key for C and TGS.

Because this session key is inside the message encrypted with Kc, only the user’s client can
read it. The same session key is included in the ticket, which can be read only by the TGS.
Thus, the session key has been securely delivered to both C and the TGS.

Armed with the ticket and the session key, C is ready to approach the TGS. As before, C
sends the TGS a message that includes the ticket plus the ID of the requested service
[message (3) in Table 1].

This ticket indicates that user C has been provided with the session key Kc,tgs. In effect, the
ticket says, “Anyone who uses Kc,tgs must be C.” The TGS uses the session key to decrypt
the authenticator.

11
Dept. of CSE(Data Science)
 MODULE 4

The TGS can then check the name and address from the authenticator with that of the ticket
and with the network address of the incoming message.

If all match, then the TGS is assured that the sender of the ticket is indeed the ticket’s real
owner. In effect, the authenticator says, “At time TS3, I hereby use Kc,tgs.” Note that the
ticket does not prove anyone’s identity but is a way to distribute keys securely. It is the
authenticator that proves the client’s identity.

The reply from the TGS in message (4) follows the form of message (2). The message is
encrypted with the session key shared by the TGS and C and includes a session key to be
shared between C and the server V, the ID of V, and the time stamp of the ticket. The ticket
itself includes the same session key.

C now has a reusable service-granting ticket for V. When C presents this ticket, as shown in
message (5), it also sends an authenticator. The server can decrypt the ticket, recover the
session key, and decrypt the authenticator.

KERBEROS REALMS AND MULTIPLE KERBERI:

A full-service Kerberos environment consisting of a Kerberos server, a number of clients, and

a number of application servers requires the following:

The Kerberos server must have the user ID and hashed passwords of all participating users in
its database. All users are registered with the Kerberos server.

12
Dept. of CSE(Data Science)
 MODULE 4

Figure 4: Kerberos Exchanges

Table: Rationale for the Elements of the Kerberos Version 4 Protocol

13
Dept. of CSE(Data Science)
 MODULE 4

A Kerberos realm is a set of managed nodes

that share the same Kerberos database. The Kerberos database resides on the

Kerberos master computer system, which should be kept in a physically secure room.

A Kerberos realm is a set of managed nodes that share the same Kerberos database. The
Kerberos database resides on the Kerberos master computer system, which should be kept in
a physically secure room.

Figure 5: Request for Service in Another Realm

The details of the exchanges illustrated in Figure 5:

14
Dept. of CSE(Data Science)
 MODULE 4

The ticket presented to the remote server (Vrem) indicates the realm in which the user was
originally authenticated. The server chooses whether to honor the remote request.

KERBEROS VERSION 5:

DIFFERENCE BETWEEN VERSION 4 & VERSION 5

Version 5 is intended to address the limitations of version 4 in two areas: environmental

shortcomings and technical deficiencies.

Let us briefly summarize the improvements in each area.

1. Encryption system dependence: Version 4 requires the use of DES. Export

restriction on DES as well as doubts about the strength of DES were thus of concern.
In version 5, ciphertext is tagged with an encryption-type identifier so that any
encryption technique may be used. Encryption keys are tagged with a type and a
length, allowing the same key to be used in different algorithms and allowing the
specification of different variations on a given algorithm.
2. Internet protocol dependence: Version 4 requires the use of Internet Protocol (IP)
addresses. Other address types, such as the ISO network address, are not
accommodated. Version 5 network addresses are tagged with type and length,
allowing any network address type to be used.
3. Message byte ordering: In version 4, the sender of a message employs a byte
ordering of its own choosing and tags the message to indicate least significant byte in
lowest address or most significant byte in lowest address.
4. Ticket lifetime: Lifetime values in version 4 are encoded in an 8-bit quantity in units
of five minutes. Thus, the maximum lifetime that can be expressed is 28 * 5 = 1280
minutes (a little over 21 hours). This may be inadequate for some applications (e.g., a

15
Dept. of CSE(Data Science)
 MODULE 4

long-running simulation that requires valid Kerberos credentials throughout

execution). In version 5, tickets include an explicit start time and end time, allowing
tickets with arbitrary lifetimes.
5. Authentication forwarding: Version 4 does not allow credentials issued to one client
to be forwarded to some other host and used by some other client. This capability
would enable a client to access a server and have that server access another server on
behalf of the client. For example, a client issues a request to a print server that then
accesses the client’s file from a file server, using the client’s credentials for access.
Version 5 provides this capability.
6. Inter realm authentication: In version 4, interoperability among N realms requires
on the order of N2 Kerberos-to-Kerberos relationships, as described earlier. Version 5
supports a method that requires fewer relationships, as described shortly.

REMOTE USER AUTHENTICATION USING ASYMMETRIC ENCRYPTION

MUTUAL AUTHENTICATION
This protocol assumes that each of the two parties is in possession of the current
public key of the other. It may not be practical to require this assumption.

In this case, the central system is referred to as an authentication server (AS),because

it is not actually responsible for secret-key distribution. Rather, the AS provides
public-key certificates. The session key is chosen and encrypted by A; hence, there is
no risk of exposure by the AS. The timestamps protect against replays of
compromised keys.

This protocol is compact but, as before, requires the synchronization of clocks.

Another approach, proposed by Woo and Lam [WOO92a], makes use of nonces.
The protocol consists of the following steps.

16
Dept. of CSE(Data Science)
 MODULE 4

In step 1, A informs the KDC of its intention to establish a secure connection

with B.
The KDC returns to A a copy of B’s public-key certificate (step 2).
Using B’s
public key, A informs B of its desire to communicate and sends a nonce Na (step 3).
In step 4, B asks the KDC for A’s public-key certificate and requests a session key;
B includes A’s nonce so that the KDC can stamp the session key with that nonce.
The nonce is protected using the KDC’s public key.
In step 5, the KDC returns to B a copy of A’s public-key certificate, plus the
information {Na, Ks, IDB}. This information basically says that Ks is a secret key
generated by the KDC on behalf of B and tied to Na; the binding of Ks and Na will
assure A that Ks is fresh. This triple is encrypted using the KDC’s private key to allow
B to verify that the triple is in fact from the KDC. It is also encrypted using B’s public
key so that no other entity may use the triple in an attempt to establish a fraudulent
connection with A.
In step 6, the triple {Na, Ks, IDB}, still encrypted with the KDC’s private key, is
relayed to A, together with a nonce Nb generated by B. All the foregoing are
encrypted using A’s public key. A retrieves the session key Ks, uses it to encrypt Nb,
and returns it to B. This last message assures B of A’s knowledge of the session key.

This seems to be a secure protocol that takes into account the various attacks.
However, the authors themselves spotted a flaw and submitted a revised version of the
algorithm

17
Dept. of CSE(Data Science)
 MODULE 4

ONE WAY AUTHENTICATION:

These approaches require that either the sender know the recipient’s public key
(confidentiality), the recipient know the sender’s public key (authentication), or both
(confidentiality plus authentication). In addition, the public-key algorithm must be
applied once or twice to what may be a long message.
If confidentiality is the primary concern, then the following may be more efficient:

In this case, the message is encrypted with a one-time secret key. A also encrypts this
one-time key with B’s public key. Only B will be able to use the corresponding
private
key to recover the one-time key and then use that key to decrypt the message. This
scheme is more efficient than simply encrypting the entire message with B’s public
key.

To counter such a scheme, both the message and signature can be encrypted with the
recipient’s public key:

The latter two schemes require that B know A’s public key and be convinced
that it is timely. An effective way to provide this assurance is the digital certificate.

In addition to the message, A sends B the signature encrypted with A’s private key and
A’s certificate encrypted with the private key of the authentication server. The
recipient of the message first uses the certificate to obtain the sender’s public key and
verify that it is authentic and then uses the public key to verify the message itself. If
confidentiality is required, then the entire message can be encrypted with B’s public
key

18
Dept. of CSE(Data Science)
 MODULE 4

WEB SECURITY CONSIDERATION:

The World Wide Web is fundamentally a client/server application running over the
Internet and TCP/IP intranets. As such, the security tools and approaches discussed
so far in this book are relevant to the issue of Web security. However, the following
characteristics of Web usage suggest the need for tailored security tools:

Table 1: A Comparison of Threats on the Web

WEB SECURITY THREATS:
❖ Table provides a summary of the types of security threats faced when using
the Web. One way to group these threats is in terms of passive and active
attacks. Passive attacks include eavesdropping on network traffic between
browser and server and gaining access to information on a Web site that is
supposed to be restricted.
❖ Active attacks include impersonating another user, altering messages in transit
between client and server, and altering information on a Web site.
WEB TRAFFIC SECURITY APPROACHES.
❖ A number of approaches to providing Web security are possible. The various
approaches that have been considered are similar in the services they provide
and, to some extent, in the mechanisms that they use, but they differ with
respect to them scope of applicability and their relative location within the
TCP/IP protocol stack.

19
Dept. of CSE(Data Science)
 MODULE 4

Figure 1: Relative Location of Security Facilities in the TCP/IP Protocol Stack

illustrates this difference. One way to provide Web security is to use IP security
(IPsec) (Figure 1a). The advantage of using IPsec is that it is transparent to end
users and applications and provides a general-purpose solution. Furthermore,
IPsec includes a filtering capability so that only selected traffic need incur the
overhead of IPsec processing.

Another relatively general-purpose solution is to implement security just above

TCP (Figure 17.1b). The foremost example of this approach is the Secure

Sockets Layer (SSL) and the follow-on Internet standard known as Transport

Layer Security (TLS). At this level, there are two implementation choices. For full

generality, SSL (or 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, virtually all browsers come equipped with
TLS,

and most Web servers have implemented the protocol.

Application-specific security services are embedded within the particular

application. Figure 17.1c shows examples of this architecture. The advantage of

this

approach is that the service can be tailored to the specific needs of a given
application.

20
Dept. of CSE(Data Science)
 MODULE 4

TRANSPORT LAYER SECURITY

[Link] ARCHITECTURE:

TLS is designed to make use of TCP to provide a reliable end-to-end secure service. TLS is
not a single protocol but rather two layers of protocols, as illustrated in figure 1:

Figure: TLS Protocol Stack

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: the Handshake Protocol; the Change Cipher Spec Protocol; and the
Alert Protocol.

Two important TLS concepts are the TLS session and the TLS connection, which are defined
in the specification as follows:

TLS Connection

➢ A connection is a transport service (according to the OSI model).

➢ TLS connections are peer-to-peer.

➢ Connections are temporary (transient).

➢ Each connection is linked to one TLS session.

TLS Session

➢ A TLS session is an association between a client and a server.

21
Dept. of CSE(Data Science)
 MODULE 4

➢ Sessions are created by the TLS Handshake Protocol.

➢ Sessions contain a set of cryptographic security parameters.

➢ These parameters can be shared by multiple connections.

➢ Sessions help avoid repeating expensive security negotiations for every connection.

Connections and Sessions in Practice

➢ Between two communicating applications (e.g., HTTP client and server), multiple
secure connections may exist.

➢ Multiple sessions could theoretically exist at the same time, but this is not used in
practice.

A session state is defined by the following parameters:

Session Identifier

➢ An arbitrary byte sequence chosen by the server.

➢ Used to identify an active or resumable session.

Peer Certificate

➢ The X.509 v3 certificate of the peer (client or server).

➢ This value may be null if no certificate is provided.

Compression Method

➢ Algorithm used to compress data before encryption.

Cipher Spec

➢ Specifies the bulk data encryption algorithm (e.g., null, AES).

➢ Specifies the hash algorithm used for MAC calculation (e.g., MD5, SHA-1).

➢ Defines cryptographic attributes such as hash_size.

Master Secret

➢ A 48-byte secret shared between the client and server.

22
Dept. of CSE(Data Science)
 MODULE 4

Is Resumable

➢ A flag indicating whether the session can be reused to start new connections.

Server and Client Random

➢ Random byte sequences independently chosen by server and client for each
connection.

Server Write MAC Secret

➢ Secret key used for MAC operations on data sent by the server.

Client Write MAC Secret

➢ Secret key used for MAC operations on data sent by the client.

Server Write Key

➢ Symmetric encryption key used to encrypt data from server to client.

Client Write Key

➢ Symmetric encryption key used to encrypt data from client to server.

Initialization Vectors (IVs)

➢ Used when block ciphers operate in CBC mode.

➢ First initialized during the TLS handshake.

➢ After that, the last ciphertext block of each record becomes the IV for the next
record.

Sequence Numbers

➢ Each party keeps separate sequence numbers for sent and received messages.

➢ Sequence numbers reset to zero when a “change cipher spec” message is received or
sent.

➢ Sequence numbers must not exceed 2⁶⁴ − 1.

[Link] RECORD PROTOCOL SERVICES

23
Dept. of CSE(Data Science)
 MODULE 4

Confidentiality

Achieved using a shared secret key defined during the Handshake Protocol.

Used for conventional encryption of TLS payloads.

Message Integrity

Achieved using a shared secret key defined during the Handshake Protocol.

Used to create a Message Authentication Code (MAC) to verify integrity.

TLS Record Protocol Overall Operation

It Takes an application message and processes it for secure transmission.

➢ Steps include: fragmentation → optional compression → MAC calculation →

encryption → header addition → transmission in a TCP segment.
➢ On receipt: decryption → MAC verification → decompression → reassembly →
delivery to higher-layer protocols.

[Link]

➢ Each upper-layer message is fragmented into 1024-byte blocks.

➢ TLSv2 specifies no default compression algorithm, so the default is null.

[Link] Authentication Code (MAC)

24
Dept. of CSE(Data Science)
 MODULE 4

➢ MAC ensures message integrity.

➢ Uses HMAC algorithm (RFC 2104).
➢ HMAC formula:
➢ HMACK(M) = H[(K+ ⊕ opad) || H[(K+ ⊕ ipad) || M]]

▪ H: embedded hash function (MD5 or SHA-1)

▪ M: message input

▪ K+: secret key padded to 512 bits

▪ ipad: 0x36 repeated 64 times

▪ opad: 0x5C repeated 64 times

➢ MAC calculation covers:

▪ seq_num || [Link] || [Link] ||

[Link] || [Link]

[Link]

Symmetric encryption applied to compressed message + MAC.

Total encrypted length ≤ 214 + 2048 bytes.

Supported algorithms:

➢ Block ciphers: AES (128, 256), 3DES (168)

➢ Stream cipher: RC4-128 (128)

AC is computed before encryption.

Block ciphers may include padding:

➢ Padding ensures total length is a multiple of the cipher’s block length.

➢ Maximum padding: 255 bytes.

➢ Example: If total length = 79 bytes and block size = 16 → padding can

be 1, 17, 33… up to 161 bytes.

25
Dept. of CSE(Data Science)
 MODULE 4

➢ Variable padding length helps prevent attacks based on message

lengths.

[Link] Record Header

Prepended to the encrypted fragment.

Fields:

➢ Content Type (8 bits): Higher-layer protocol (e.g., application_data,

handshake).

➢ Major Version (8 bits): TLS major version (TLSv2 = 3).

➢ Minor Version (8 bits): TLS minor version (TLSv2 = 1).

➢ Compressed Length (16 bits): Length of plaintext/compressed

fragment. Max = 214 + 2048.

➢ Content types: change_cipher_spec, alert, handshake, application_data.

➢ TLS treats application data as opaque (does not interpret application-specific

content).

[Link] (Optional)

Must be lossless.

Cannot increase content length by more than the original size.

[Link]

Processed record is sent in a TCP segment.

On receiving side, steps are reversed: decrypt → verify MAC → decompress → reassemble
→ deliver.

Figure illustrates the TLS record format.

26
Dept. of CSE(Data Science)
 MODULE 4

[Link] CIPHER SPEC PROTOCOL:

The Change Cipher Spec (CCS) Protocol is a TLS-specific protocol that updates the cipher
suite for a connection by copying the pending state into the current state.

It consists of a single 1-byte message with the value 1, whose sole purpose is to activate the
new cipher settings.

Figure illustrates:

[Link] PROTOCOL

➢ The Alert Protocol is used to convey TLS-related alerts to the peer entity. Like other
applications that use TLS, alert messages are compressed and encrypted according to
the current state.
➢ Each message in this protocol consists of two bytes. The first byte indicates the
severity of the message, taking the value warning (1) or fatal (2). If the alert is fatal,
TLS immediately terminates the connection.
➢ Other connections on the same session may continue, but no new connections on this
session can be established.
➢ The second byte contains a code that specifies the particular alert. Certain alerts are
always fatal, including: unexpected_message, which occurs when an inappropriate
message is received; bad_record_mac, triggered by an incorrect MAC;

27
Dept. of CSE(Data Science)
 MODULE 4

decompression_ failure, which happens when the decompression function receives

improper input, such as being unable to decompress or decompressing beyond the
maximum allowable length;
➢ handshake_ failure, indicating the sender could not negotiate an acceptable set of
security parameters; and illegal_ parameter, which occurs when a field in a handshake
message is out of range or inconsistent with other fields.

Figure : TLS Record Protocol Payload

TLS Alert Descriptions:

➢ decryption_failed: Ciphertext decrypted incorrectly; either not a multiple of the

block length or padding values were incorrect.

➢ record_overflow: TLS record received has payload exceeding limits (214 + 2048
bytes) or decrypted length greater than 214 + 1024 bytes.

➢ unknown_ca: Certificate chain received but not accepted because CA certificate

could not be found or matched with a trusted CA.

➢ access_denied: Valid certificate received but sender refused to proceed after applying
access control.

➢ decode_error: Message could not be decoded due to field out of range or incorrect
length.

➢ export_restriction: Negotiation detected that violates export restrictions on key

length.

➢ protocol_version: Client attempted a protocol version recognized but not supported.

➢ insufficient_security: Negotiation failed because the server requires more secure

ciphers than the client supports.

28
Dept. of CSE(Data Science)
 MODULE 4

➢ internal_error: Internal error unrelated to the peer or protocol correctness prevents

continuation.

Other Alerts:

➢ close_notify: Notifies the recipient that no more messages will be sent on this
connection; must be sent before closing the write side.

➢ bad_certificate: Received certificate is corrupt or signature verification failed.

➢ unsupported_certificate: Received certificate type is not supported.

➢ certificate_revoked: Certificate has been revoked by its signer.

➢ certificate_expired: Certificate has expired.

➢ certificate_unknown: Unspecified issue with the certificate makes it unacceptable.

➢ decrypt_error: Handshake cryptographic operation failed (e.g., signature

verification, key decryption, or finished message validation).

➢ user_canceled: Handshake canceled for reasons unrelated to protocol failure.

➢ no_renegotiation: Sent by client/server in response to a hello request after initial

handshaking, indicating no renegotiation

HANDSHAKE PROTOCOL

Figure shows the initial exchange needed to establish a logical connection between client and
server. The exchange can be viewed as having four phases.

PHASE 1. ESTABLISH SECURITY CAPABILITIES

PHASE 2. SERVER AUTHENTICATION AND KEY EXCHANGE

PHASE 3. CLIENT AUTHENTICATION AND KEY EXCHANGE

PHASE 4. FINISH

29
Dept. of CSE(Data Science)
 MODULE 4

PHASE 1. ESTABLISH SECURITY CAPABILITIES

➢ The TLS handshake begins when the client initiates a connection to the server. This is
done by sending a client_hello message, which indicates the client’s highest supported
TLS version and provides a random value consisting of a 32-bit timestamp and 28
bytes generated securely.
➢ This random value acts as a nonce to prevent replay attacks during key exchange. The
message also includes a session ID, which tells the server whether the client wants to
resume an existing session (nonzero value) or establish a new session (zero value).
➢ This phase sets the foundation for the security parameters that will govern the session.

PHASE 2. SERVER AUTHENTICATION AND KEY EXCHANGE

➢ After receiving the client’s hello, the server responds with a server_hello message.
This message specifies the TLS version chosen for the session and includes a server-

30
Dept. of CSE(Data Science)
 MODULE 4

generated random value, which will be used in key generation along with the client’s
random value.
➢ The server may either echo the client’s session ID or provide a new one if a fresh
session is being created. To authenticate itself, the server sends its digital certificate,
which may include intermediate certificates forming a chain of trust.
➢ If required by the selected key exchange algorithm, the server also sends key
exchange parameters. The server concludes this phase with a server_hello_done
message, signaling that it has finished its part of the negotiation.

PHASE 3. CLIENT AUTHENTICATION AND KEY EXCHANGE

➢ Once the server has responded, the client proceeds with the key exchange. If the
server requests client authentication, the client sends its certificate along with a
certificate_verify message to prove ownership of its private key.
➢ The client also sends a pre-master secret or other key exchange parameters, which
both parties will use to derive the session keys. Afterward, both client and server
send a change_cipher_spec message to indicate that future communications will
be encrypted using the negotiated parameters.
➢ Finally, each side sends a finished message, which contains a verification of all
previous handshake messages to ensure integrity.
➢ Once these steps are complete, a secure TLS session is established, allowing
encrypted communication between client and server.

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. Note that this message is not considered 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.

CRYPTOGRAPHIC COMPUTATION

Two further items are of interest: (1) the creation of a shared master secret by means of the
key exchange; and (2) the generation of cryptographic parameters from the master secret.

31
Dept. of CSE(Data Science)
 MODULE 4

Master Secret Creation

Once the key exchange has been completed in a TLS handshake, a shared master secret is
created for the session. This master secret is a one-time, 48-byte (384-bit) value generated to
secure communications between the client and server. Its creation occurs in two stages: first,
a pre_master_secret is exchanged between the parties; second, both sides compute the master
secret from this pre_master_secret using a pseudorandom function (PRF).

Pre-Master Secret Exchange

There are two main methods for exchanging the pre_master_secret:

• RSA: The client generates a 48-byte pre_master_secret and encrypts it with the
server’s public RSA key. The server then decrypts it using its private key to recover
the pre_master_secret.

• Diffie–Hellman (DH): Both client and server generate DH public keys and exchange
them. Each side then performs the Diffie–Hellman calculation to create the shared
pre_master_secret.

Master Secret Computation

After the pre_master_secret is shared, both client and server compute the master_secret
using the PRF:

master_secret = PRF(pre_master_secret, "master secret", [Link] ||

[Link])

Here, the random values from the initial ClientHello and ServerHello messages are combined
as nonces to ensure uniqueness. The PRF is run until a total of 48 bytes of pseudorandom
output are produced, forming the master secret.

Key Block Generation

From the master secret, the session derives all cryptographic parameters (MAC keys,
encryption keys, and initialization vectors) using another PRF calculation called the key
block:

key_block = PRF(master_secret, "key expansion", [Link] ||

[Link])

32
Dept. of CSE(Data Science)
 MODULE 4

This process continues until enough pseudorandom output is generated to provide the
required cryptographic keys for the session. The resulting key block ensures that all
encryption and integrity mechanisms for the TLS session are securely derived from the
shared master secret.

PSEUDORANDOM FUNCTION (PRF) IN TLS

TLS uses a pseudorandom function (PRF) to expand relatively small shared secret values
into larger blocks of data. These expanded blocks are used for key generation, verification,
and other cryptographic purposes. The goal of the PRF is to securely produce longer
sequences of data from a small secret in a way that resists attacks on hash functions and
MACs.

P_hash Function
The PRF relies on a data expansion function called P_hash, which iteratively applies the
HMAC algorithm with an underlying hash function (such as MD5 or SHA-1). The function is
defined as:

P_hash(secret, seed) = HMAC_hash(secret, A(1) || seed) ||

HMAC_hash(secret, A(2) || seed) ||

HMAC_hash(secret, A(3) || seed) || …

Here, the sequence A() is defined recursively:

• A(0) = seed

• A(i) = HMAC_hash(secret, A(i-1))

This iterative approach allows P_hash to generate as much data as needed. Each iteration
produces one segment of pseudorandom output, and multiple iterations are concatenated until
the required number of bytes is reached.

33
Dept. of CSE(Data Science)
 MODULE 4

HEARTBEAT PROTOCOL

The Heartbeat protocol operates on top of the TLS Record Protocol and consists of two
message types: heartbeat_request and heartbeat_response. Its use is negotiated during Phase
1 of the TLS Handshake, where each peer indicates whether it supports heartbeats. If supported,
a peer also specifies whether it is willing to both send and receive heartbeat messages or only
send them.

A heartbeat_request message can be sent at any time. When received, it should be promptly
answered with a heartbeat_response message that includes an exact copy of the payload from
the request. The heartbeat_request message contains three fields: payload length, payload,
and padding. The payload is a random content block between 16 bytes and 64 Kbytes. The
padding is also random and is used to help perform path MTU (Maximum Transfer Unit)
discovery, by allowing the sender to determine the largest message size that can traverse the
path without being dropped.

The Heartbeat protocol serves two main purposes:

1. It assures the sender that the recipient is still active, even if there has been no recent
activity over the TCP connection.

34
Dept. of CSE(Data Science)
 MODULE 4

2. It generates network activity during idle periods to prevent idle connections from being
closed by firewalls.

SSL/TLS ATTACKS

Since SSL was first introduced in 1994 and later standardized as TLS, many attacks have been
discovered that target different parts of the protocol.

Each newly discovered vulnerability has forced updates to the protocol design, cryptographic
algorithms, and implementation practices.

These attacks highlight how complex and sensitive secure communication protocols are, and
why constant improvement is necessary to maintain security.

[Link] on the Handshake Protocol

One major category of attacks targets the TLS handshake, which is responsible for
negotiating keys and authenticating parties.

As early as 1998, researchers found weaknesses in the RSA encryption scheme used during
the handshake. These weaknesses allowed attackers to manipulate the formatting or exploit
flaws in how RSA was implemented. Over the years, these attacks were refined to bypass
countermeasures and execute more efficiently. Such vulnerabilities typically stem from poor
padding validation, weak randomness, or incorrect RSA implementation.

[Link] on the Record and Application Data Protocols

Several significant attacks have targeted the record layer, where actual encrypted data is
exchanged. A well-known example is the BEAST attack (Browser Exploit Against
SSL/TLS) discovered in 2011, which turned a theoretical chosen-plaintext vulnerability in
TLS 1.0 into a practical exploit.

BEAST allowed attackers to guess encrypted content by manipulating chosen plaintext

blocks. Soon after, the same researchers introduced the CRIME attack, which exploited data
compression to leak sensitive information like session cookies. By analyzing compression
ratios, attackers could infer secret data, enabling session hijacking. These attacks forced
browser vendors and TLS implementations to disable certain compression and modify
handling of cipher modes.

35
Dept. of CSE(Data Science)
 MODULE 4

[Link] on the Public Key Infrastructure (PKI)

SSL/TLS relies heavily on certificate validation, and this process has also been a target of
many attacks. Research in 2012 showed that multiple widely used TLS libraries—such as
OpenSSL, GnuTLS, JSSE, cURL, PHP, and Python—contained flawed certificate validation
logic. These vulnerabilities could lead to accepting forged or invalid certificates, allowing
attackers to perform man-in-the-middle attacks. Weaknesses in PKI can compromise the
entire TLS ecosystem, as trust in certificates underpins secure communication

[Link] Attacks (Including DoS on TLS Handshake)

Some attacks do not fit neatly into the previous categories. One example is a
denial-of-service (DoS) attack discovered by The Hackers Choice in 2011. This attack
overwhelms a server by sending a flood of TLS handshake requests or triggering
renegotiations. Since the server performs most of the computational work during a
handshake—such as generating random numbers and computing keys—the attack forces the
server to consume excessive CPU resources. As a result, even a modest attacker can overload
a server, making it unable to serve legitimate clients.

TLSv1.3

TLS 1.3 Overview

In 2014, the IETF TLS working group began developing TLS version 1.3, with the primary
goal of improving the security and efficiency of TLS. Although it was still in draft form at the
time of writing, the final standard was expected to closely follow the draft. TLS 1.3
introduces several significant changes compared to TLS 1.2 to strengthen security and reduce
vulnerabilities.

Removal of Legacy Features

TLS 1.3 removes support for many legacy options and functions that are no longer necessary.
By eliminating unused code, TLS 1.3 reduces the likelihood of coding errors and shrinks the
attack surface. Among the features removed are: compression, ciphers that do not provide
authenticated encryption, static RSA and Diffie–Hellman key exchange, the 32-bit timestamp
in the client_hello random parameter, renegotiation, the Change Cipher Spec protocol, RC4,
and the use of MD5 or SHA-224 with signatures.

36
Dept. of CSE(Data Science)
 MODULE 4

Key Exchange Improvements

TLS 1.3 exclusively uses Diffie–Hellman (DH) or Elliptic Curve Diffie–Hellman (ECDH)
for key exchange, eliminating the use of RSA key exchange. This change ensures that each
handshake negotiates a fresh key, preventing the compromise of past sessions even if a
private key is exposed. RSA, in contrast, exposes all handshakes that use the same key if it is
compromised.

Faster Handshake (“1 Round Trip Time”)

TLS 1.3 also optimizes handshake efficiency by allowing a “1 round trip time” (1-RTT)
handshake. The client can send its cryptographic parameters for key establishment in a
Client Key Exchange message before a cipher suite is negotiated. This enables the server to
compute session keys and prepare encryption and authentication before sending its first
response. As a result, the handshake requires fewer packets, reducing latency and further
minimizing the attack surface.

37
Dept. of CSE(Data Science)
 MODULE 4

EMAIL THREATS AND COMPREHENSIVE EMAIL SECURITY

In general terms, email security threats can be classified as follows:

38
Dept. of CSE(Data Science)
 MODULE 4

Email Security Threats

➢ Authenticity threats: Allow unauthorized access to an organization’s email system.

➢ Integrity threats: Allow unauthorized modification of email content.

➢ Confidentiality threats: Lead to disclosure of sensitive information.

➢ Availability threats: Prevent users from sending or receiving emails.

Email Security Protocols (as per NIST SP 800-177)

➢ STARTTLS: Secures SMTP messages with authentication, integrity, non-repudiation,

and encryption.

➢ S/MIME: Protects the message body with authentication, integrity, non-repudiation,

and encryption.

➢ DNSSEC: Ensures authentication and integrity of DNS data, supporting email

security protocols.

➢ DANE: Authenticates public keys using DNSSEC to overcome limitations of

certificate authorities.

➢ SPF (Sender Policy Framework): Allows domain owners to authorize IP addresses for
sending emails; helps verify sender authenticity.

➢ DKIM (DomainKeys Identified Mail): Signs email headers and body to validate the
source domain and ensure message integrity.

➢ DMARC: Monitors effectiveness of SPF and DKIM; guides receivers on actions to

take for email attacks.

S/MIME

Important Documents Relevant to S/MIME

➢ RFC 5750 – S/MIME v3.2 Certificate Handling: Specifies conventions for using
X.509 certificates in S/MIME v3.2.

➢ RFC 5751 – S/MIME v3.2 Message Specification: Main defining document for
S/MIME message creation and processing.

39
Dept. of CSE(Data Science)
 MODULE 4

➢ RFC 4134 – Examples of S/MIME Messages: Provides examples of message bodies

formatted using S/MIME.

➢ RFC 2634 – Enhanced Security Services for S/MIME: Describes four optional
security service extensions for S/MIME.

➢ RFC 5652 – Cryptographic Message Syntax (CMS): Defines CMS for digitally
signing, digesting, authenticating, or encrypting message content.

➢ RFC 3370 – CMS Algorithms: Details conventions for using various cryptographic
algorithms with CMS.

➢ RFC 5752 – Multiple Signatures in CMS: Explains the use of multiple, parallel
signatures for a message.

➢ RFC 1847 – Security Multiparts for MIME (Multipart/Signed and

Multipart/Encrypted): Defines a framework for applying security services to MIME
body parts; relevant to digital signatures in S/MIME.

OPERATIONAL DESCRIPTION:

40
Dept. of CSE(Data Science)
 MODULE 4

Authentication: Ensures the sender’s identity using digital signatures.

Confidentiality: Protects message content from unauthorized access.

Compression: Reduces message size for efficient transmission.

Email Compatibility: Ensures messages are compatible with standard email systems.

AUTHENTICATION IN S/MIME

Digital signatures provide authentication (commonly using RSA with SHA-256).

Process sequence:

1. Sender creates the message.

2. SHA-256 generates a 256-bit message digest of the message.

3. Digest Creation: The sender generates a 256-bit message digest of the email
using SHA-256 and encrypts it with their private RSA key, attaching it along
with signer information.

4. Digest Recovery: The receiver uses the sender’s public RSA key to decrypt
and retrieve the original message digest.

5. Verification: The receiver generates a new digest from the received message
and compares it with the decrypted digest; if they match, the message is
authentic.

CONFIDENTIALITY:

1. The sender generates a message and a random 128-bit number to be used as a

41
Dept. of CSE(Data Science)
 MODULE 4

content-encryption key for this message only.

2. The message is encrypted using the content-encryption key.

3. The content-encryption key is encrypted with RSA using the recipient’s public

key and is attached to the message.

4. The receiver uses RSA with its private key to decrypt and recover the

content-encryption key.

5. The content-encryption key is used to decrypt the message.

CONFIDENTIALITY AND AUTHENTICATION:

Combined Use of Signing and Encryption:

➢ A digital signature can be generated for the plaintext message and appended.

➢ The message and signature are then encrypted as a single block using symmetric
encryption.

➢ The symmetric key is encrypted using the recipient’s public key.

Signing First, Then Encryption:

➢ Hides the signer’s identity through encryption.

➢ Convenient for storing a signature with plaintext.

➢ Allows third-party verification without access to the symmetric key.

Encryption First, Then Signing:

➢ Signature can be verified without exposing the message content.

➢ Useful for automatic signature verification.

➢ Recipient cannot link the signer to the unencrypted message content.

EMAIL COMPATIBILITY:

Encryption in S/MIME:

42
Dept. of CSE(Data Science)
 MODULE 4

➢ If only the signature service is used, the message digest is encrypted with the
sender’s private key.

➢ If confidentiality is used, the message and signature (if present) are encrypted with a
one-time symmetric key.

Binary to ASCII Conversion:

➢ Many email systems allow only ASCII text, so S/MIME converts 8-bit binary data to
printable ASCII using 7-bit encoding.

➢ Base64 is commonly used: every 3 octets of binary data are mapped to 4 ASCII
characters.

Side Benefit of Base64:

➢ Base64 converts all data blindly, even if it’s already ASCII.

➢ If a message is signed but not encrypted, the Base64 output is unreadable to casual
observers, providing a level of confidentiality.

COMPRESSION:

➢ Compression of binary encoded encrypted data is discouraged, since it will not yield
significant compression. Base64 encrypted data could very well benefit, however.
➢ If a lossy compression algorithm is used with signing, you will need to compress first,
then sign.

S/MIME MESSAGE CONTENT TYPE:

➢ Cryptographic Message Syntax (CMS) defines different content types used in S/MIME.
The Data type refers to the inner MIME-encoded message content, which can be
encapsulated in other security formats.
➢ SignedData is used to apply a digital signature, providing authentication and integrity
for the message.
➢ EnvelopedData contains encrypted message content and encrypted content-encryption
keys for one or more recipients, ensuring confidentiality.
➢ CompressedData is used to reduce the size of the message before transmission. The
Data content type is also used for a technique known as clear signing, where a signature

43
Dept. of CSE(Data Science)
 MODULE 4

is generated for a MIME-encoded message and the message and signature are sent as
separate MIME parts.
➢ Unlike SignedData, clear-signed messages remain readable and their signatures can still
be verified even by email applications that do not support S/MIME, providing
compatibility while maintaining authentication.

APPROVED CRYPTOGRAPHIC ALGORITHMS:

cryptographic algorithms used in S/MIME. S/MIME uses the following terminology taken
from RFC 2119 (Key Words for use in RFCs to Indicate Requirement Levels, March 1997) to
specify the requirement level:

➢ MUST: The definition is an absolute requirement of the specification. An

implementation must include this feature or function to be in conformance with the
specification.
➢ SHOULD: There may exist valid reasons in particular circumstances to ignore this
feature or function, but it is recommended that an implementation include the feature
or function.

The S/MIME specification includes a discussion of the procedure for deciding which content
encryption algorithm to use. In essence, a sending agent has two decisions to make. First, the
sending agent must determine if the receiving agent is capable of decrypting using a given
encryption algorithm.

Second, if the receiving agent is only capable of accepting weakly encrypted content, the
sending agent must decide if it is acceptable to send using weak encryption. To support this
decision process, a sending agent may announce its decrypting capabilities in order of
preference for any message that it sends out. A receiving agent may store that information for
future use.

44
Dept. of CSE(Data Science)
 MODULE 4

Known Recipient Capabilities (Preferred List):

➢ If the sender has a list of the recipient’s preferred decryption algorithms, the sender
should choose the highest-priority algorithm from that list that it also supports.

Based on Previous Messages:

➢ If there is no preference list but the sender has earlier received signed and encrypted
mail from the recipient, the sender should use the same algorithm used in the most
recent such message.

Unknown Capabilities — Sender Willing to Take Risk:

➢ If the recipient’s supported algorithms are unknown and the sender accepts the risk
that the recipient might not decrypt the message, the sender should use Triple DES.

Unknown Capabilities — No Risk Accepted:

➢ If the sender does not want to risk decryption failure, the sender must use RC2/40,
ensuring maximum compatibility.

S/MIME MESSAGES:

SECURING MIME ENTITY:

1. Security Processing of MIME Content

➢ S/MIME secures a MIME entity using a digital signature, encryption, or both.

45
Dept. of CSE(Data Science)
 MODULE 4

➢ The MIME content is first prepared in canonical form, then combined with
security-related data (like certificates and algorithm identifiers) to create a
PKCS object.

➢ This PKCS object is wrapped in MIME with proper headers for transmission.

2. Transfer Encoding Considerations

➢ Security operations may produce binary data, so transfer encoding (typically Base64)
is applied to ensure safe transport over email systems that support only ASCII.
➢ In multipart signed messages, the signed content remains unchanged; therefore, any
non-ASCII data must be encoded (Base64 or quoted-printable) beforehand to preserve
the validity of the signature.

ENVELOPED DATA:

The steps for preparing an enveloped Data MIME entity are:

1. Generate a pseudorandom session key for a particular symmetric encryption algorithm

(RC2/40 or triple DES).

2. For each recipient, encrypt the session key with the recipient’s public RSA key.

3. For each recipient, prepare a block known as RecipientInfo that contains

an identifier of the recipient’s public-key certificate,1 an identifier of the

algorithm used to encrypt the session key, and the encrypted session key.

4. Encrypt the message content with the session key.

SIGNED DATA:

1. Select a message digest algorithm (SHA or MD5).

2. Compute the message digest (hash function) of the content to be signed.

3. Encrypt the message digest with the signer’s private key.

4. Prepare a block known as SignerInfo that contains the signer’s public-key certificate, an
identifier of the message digest algorithm, an identifier of the algorithm used to encrypt the
message digest, and the encrypted message digest.

46
Dept. of CSE(Data Science)
 MODULE 4

CLEAR SIGNING:

Clear signing is achieved using the multipart content type with a signed subtype. As was
mentioned, this signing process does not involve transforming the message to be signed, so that
the message is sent “in the clear.” Thus, recipients with MIME capability but not S/MIME
capability are able to read the incoming message.

REGISTRATION REQUEST:

The certification request includes certification Request Info block, followed by an identifier

of the public-key encryption algorithm, followed by the signature of the certification Request
Info block, made using the sender’s private key. The certification Request Info block includes
a name of the certificate subject (the entity whose public key is to be certified) and a bit-string
representation of the user’s public key.

CERTIFICATES ONLY MESSAGES:

A message containing only certificates or a certificate revocation list (CRL) can be sent in
response to a registration request. The message is an application/pkcs7-mime type/subtype with
an s/mime-type parameter of degenerate. The steps involved are the same as those for creating
a signed Data message, except that there is no message content and the signer Info field is
empty.

S/MIME CERTIFICATE PROCESSING:

USER AGENT ROLE An S/MIME user has several key management functions to perform.

➢ Key generation: The user of some related administrative utility (e.g., one associated
with LAN management) MUST be capable of generating separate Diffie–Hellman and
DSS key pairs and SHOULD be capable of generating RSA key pairs. Each key pair
MUST be generated from a good source of nondeterministic random input and be
protected in a secure fashion. A user agent SHOULD generate RSA key pairs with a
length in the range of 768 to 1024 bits and MUST NOT generate a length of less than
512 bits.
➢ Registration: A user’s public key must be registered with a certification authority in
order to receive an X.509 public-key certificate.

47
Dept. of CSE(Data Science)
 MODULE 4

➢ Certificate storage and retrieval: A user requires access to a local list of certificates
in order to verify incoming signatures and to encrypt outgoing messages. Such a list
could be maintained by the user or by some local administrative entity on behalf of a
number of users.

ENHANCED SECURITY SERVICES:

➢ Signed receipts: A signed receipt may be requested in a Signed Data object. Returning
a signed receipt provides proof of delivery to the originator of a message and allows
the originator to demonstrate to a third party that the recipient received the message.
➢ Security labels: A security label is a set of security information regarding the sensitivity
of the content that is protected by S/MIME encapsulation. The labels may be used for
access control, by indicating which users are permitted access to an object.
➢ Secure mailing lists: When a user sends a message to multiple recipients, a certain
amount of per-recipient processing is required, including the use of each recipient’s
public key. The user can be relieved of this work by employing the services of an
S/MIME Mail List Agent (MLA). An MLA can take a single incoming message,
perform the recipient-specific encryption for each recipient, and forward the message
➢ Signing certificates: This service is used to securely bind a sender’s certificate to their
signature through a signing certificate attribute.

PRETTY GOOD PRIVACY

An alternative email security protocol is Pretty Good Privacy (PGP), which has essentially the
same functionality as S/MIME. PGP was created by Phil Zimmerman and implemented as a
product first released in 1991.

There are two significant differences between S/MIME and OpenPGP:

Key Certification: S/MIME uses X.509 certificates that are issued by Certificate Authorities
(or local agencies that have been delegated authority by a CA to issue certificates). In OpenPGP,
users generate their own OpenPGP public and private keys and then solicit signatures for their
public keys from individuals or organizations to which they are known. Whereas X.509
certificates are trusted if there is a valid PKIX chain to a trusted root, an OpenPGP public key

is trusted if it is signed by another OpenPGP public key that is trusted by the recipient. This is
called the Web-of-Trust.

48
Dept. of CSE(Data Science)
 MODULE 4

Key Distribution: OpenPGP does not include the sender’s public key with each message, so
it is necessary for recipients of OpenPGP messages to separately obtain the sender’s public key
in order to verify the message. Many organizations post OpenPGP keys on TLS-protected
websites: People who wish to verify digital signatures or send these organizations encrypted
mail need to manually download these keys and add them to their OpenPGP clients. Keys may
also be registered with the OpenPGP public key servers, which are servers that maintain a
database of PGP public keys organized by email address.

NIST 800-177 recommends the use of S/MIME rather than PGP because of the greater
confidence in the CA system of verifying public keys.

49
Dept. of CSE(Data Science)