MODULE - IV

AUTHENTICATION SERVICES KERBEROS

Kerberos provides a centralized authentication server whose function is to authenticate users to

servers and servers to users. Kerberos relies exclusively on conventional encryption, making no use

of public-key encryption.

The following are the requirements for Kerberos:

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

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

To support these requirements, the overall scheme of Kerberos is that of a trusted third- party

authentication service that uses a protocol based on that proposed by Needham and Schroeder

[NEED78] It is trusted in the sense that clients and servers trust Kerberos to mediate their mutual

authentication. Assuming the Kerberos protocol is well designed, then the authentication service is

secure if the Kerberos server itself is secure.

A simple authentication dialogue

In an unprotected network environment, any client can apply to any server for service. The obvious

security risk is that of impersonation. To counter this threat, servers must be able to confirm the

identities of clients who request service. But in an open environment, this places a substantial

burden on each server.

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.

The simple authentication dialogue is as follows:

A more secure authentication dialogue

There are two major problems associated with the previous approach:

Plaintext transmission of the password.

Each time a user has to enter the password.

To solve these problems, we introduce a scheme for avoiding plaintext passwords, and anew server,

known as ticket granting server (TGS). The hypothetical scenario is as follows:

Once per user logon session:

1.C >> AS: IDel[IDtgs

2. AS >> C: Eke (Ticketigs)

Once per type of service:

3. C >> TGS: IDe||IDv||Tickettgs

4. TGS >> C: tickety

Once per service session:

5.C >> V: IDe|ltickety

Tickettgs= Ektgs(IDc||ADe||IDtgs||TS1||Lifetime1) Tickety= Eky(IDe||ADe||IDv||TS2/||Lifetime2)

C: Client, AS: Authentication Server, V: Server, IDc : ID of the client, Pc:Password of the client,

ADce: Address of client, IDv : ID of the server, Kv: secret key shared by AS and V, ||: concatenation,

IDigs: ID of the TGS server, TS1, TS2: time stamps, lifetime: lifetime of the ticket.

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. Each time the user requires access to a new service, the client applies

to the TGS, using the ticket to authenticate itself. 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. Let us look at the details of this scheme:
1. The client requests a ticket-granting ticket on behalf of the user by sending its user's ID and

password to the AS, together with the TGS ID, indicating a request to use the TGS service.

2. The AS responds with a ticket that is encrypted with a key that is derived from the user's

password.

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.

If the correct password is supplied, the ticket is successfully recovered.Because only the correct user

should know the password, only the correct user can recover the ticket. Thus, we have used the

password to obtain credentials from Kerberos without having to transmit the password in plaintext.

Now that the client has a ticket-granting ticket, access to any server can be obtained with steps 3 and

4:

3. The client requests a service-granting ticket on behalf of the user. For this purpose, the

client transmits a message to the TGS containing the user's ID, the ID of the desired service, and the

ticket-granting ticket.

4. The TGS decrypts the incoming ticket and verifies the success of the decryption by the

presence of its ID. It checks to make sure that the lifetime has not expired. Then it compares the user

ID and network address with the incoming information to authenticate the user. If the user is

permitted access to the server V, the TGS issues a ticket to grant access to the requested service.

The service-granting ticket has the same structure as the ticket-granting ticket. Indeed, because the

TGS is a server, we would expect that the same elements are needed to authenticate a client to the

TGS and to authenticate a client to an application server. Again, the ticket contains a timestamp

and lifetime. If the user wants access to the same service at a later time, the client can simply use the

previously acquired service-granting ticket and need not bother the user for a password. Note that the

ticket is encrypted with a secret key (Ky) known only to the TGS and the server, preventing

alteration.
Finally, with a particular service-granting ticket, the client can gain access to the corresponding

service with step 5:

5. 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 nd the service-granting ticket. The server authenticates

by using the contents of the ticket.

This new scenario satisfies the two requirements of only one password query per user session and
protection of the user password.

Kerbero V4 Authentication Dialogue Message Exchange

Two additional problems remain in the more secure authentication dialogue:

Lifetime associated with the ticket granting ticket. If the lifetime is very short, then the user

will be repeatedly asked for a password. If the lifetime is long, then the opponent has the greater

opportunity for replay.

Requirement for the servers to authenticate themselves to users. The actual Kerberos protocol

version 4 is as follows:

¢ a basic third-party authentication scheme

¢ have an Authentication Server (AS)

— users initially negotiate with AS to identify self

—AS provides a non-corruptible authentication credential (ticket granting ticket TGT)

¢ have a Ticket Granting server (TGS)

—users subsequently request access to other services from TGS on basis of users

Message (1) Client requests ticket-granting ticket

IDc Tells AS identity of user from this client

Digs Tells AS that user requests access to TGS

TS] Allows AS to verify that client's clock is synchronized with that of AS

Message (2) _|AS returns ticket-granting ticket

Ke Encryption is based on user's password, enabling AS and client to verify

asswo d, and p_ t ctin contents of m ssa _e (2)

Ke,tgs Copy of session key accessible to client created by AS to permit secure

exchange between client and TGS without requiring them to share a

Digs Confirms that this ticket is for the TGS
The table given below illustrates the mode of dialogue in V4

(a) Authentication Service Exchange: to obtain ticket-granting ticket

(1) C + AS: ID, | ID, 9. ITS,

(2) AS > Cz Ex [Kozgs ll ID,

as II TS Il Lifetimes l Ticketyg; |

Ticketigs, Ex. [Koygs WIDc WADG Il Dyas lI TSy Il Lifetimes |

igs ad 1S = =

tgs

(b) Ticket-Granting Service Exchange: to obtain service-granting ticket

(3) C + TGS: ID, | Ticker,,, || Authenticator,

Bs

(4) TGS > C: Ex. [Koy IIID, ITS, II Ticket, |

Ticketys =Ex, [Kejgs lWIDc WW AD¢ ll Digg lI TS ll Lifetimes |

Ticket, =Ex [K,, llID¢ WADg IID, ITS 4 Il Lifetime, |

Authenticator, = Ex... [1De I ADe Il 183]

(c) Client/Server Authentication Exchange: to obtain service

(5) CV: Ticket, |l Authenticator,

(6)V—C: Ex [TS; +1] (for mutual authentication)

Ticket, =Ex, [Key WlDe ll ADe IID, ITS, ll Lifetimes |

Authenticator, =Ex_ [ID¢ ll AD¢ IITSs |

TS2

Lifetime?

Ticketigs

Message (3)

IDV

Tickettgs

Authenticatorc

Message (4)

Ke,tgs

Kev

IDy

TS4

Tickety

Tickettgs

Ktgs

Ke,tgs

IDC

ADC

Wigs

TS2

Lifetime2

Authenticatorg

Ke,tgs
Informs client of time this ticket was issued

Informs client of the lifetime of this ticket

Ticket to be used by client to access TGS

(a) Authentication Service Exchange

Client requests service-granting ticket

Tells TGS that user requests access to server V

Assures TGS that this user has been authenticated by AS

Generated by client to validate ticket

TGS returns service-granting ticket

Key shared only by C and TGS protects contents of message (4)

Copy of session key accessible to client created by TGS to permit secure

exchange between client and server without requiring them to share a

Confirms that this ticket is for server V

Informs client of time this ticket was issued

Ticket to be used by client to access server V

Reusable so that user does not have to reenter password.

Ticket is encrypted with key known only to AS and TGS, to prevent

tampering

Copy of session key accessible to TGS used to decrypt authenticator,

therebv authenticating ticket

Indicates the rightful owner of this ticket

Prevents use of ticket from workstation other than one that initially

reauested the ticket

Assures server that it has decrypted ticket properly

Informs TGS of time this ticket was issued

Prevents replay after ticket has expired

Assures TGS that the ticket presenter is the same as the client for whom the

ticket was issued has very short lifetime to prevent replay

Authenticator is encrypted with key known only to client and TGS, to

prevent tampering
IDc

ADe

TS3

Message (5)

Tickety

Authenticatore

Message (6)

Kev

TS5 +1

Tickety

Ky

Ke,v

IDC

ADe

IDy

TS4

Lifetime4

Authenticatorc

Kg,v

IDc

ADe

TS5

Must match ID in ticket to authenticate ticket

Must match address in ticket to authenticate ticket

Informs TGS of time this authenticator was generated

(b) Ticket-Granting Service Exchange

Client requests service

Assures server that this user has been authenticated by AS

Generated by client to validate ticket

Optional authentication of server to client

Assures C that this message is from V

Assures C that this is not a replay of an old reply

Reusable so that client does not need to request a new ticket from TGS

for each access to the same server

Ticket is encrypted with key known only to TGS and server, to prevent

tampering

Copy of session key accessible to client; used to decrypt authenticator,

therebv authenticating ticket

Indicates the rightful owner of this ticket

Prevents use of ticket from workstation other than one that initially

requested the ticket

Assures server that it has decrypted ticket properly

Informs server of time this ticket was issued

Prevents replay after ticket has expired

Assures server that the ticket presenter is the same as the client for whom

the ticket was issued: has verv short lifetime to prevent replav

Authenticator is encrypted with key known only to client and server, to

prevent tampering

Must match ID in ticket to authenticate ticket

Must match address in ticket to authenticate ticket

Informs server of time this authenticator was generated

(c) Client/Server Authentication

Kerberos 4 Overview

2. AS venfies user's access night in

datubase, creates icket-granting ticket

and sessaon key. Results are enery pled

using key derived from user's password,

omer per

user logon

Session

Authenticat

> Server (AS)

1. User logs on to aa

workslation and

requests service om host

Tichet-

granting

Server (TGS)

4. TOS decrypt ticket and

aulheotcatr, venlies request,

then creates ticket for requested

SCrver,

3. Workstation prompts

fewer For erevamnho pn.

uses password to decrypt

incoming message, then

sends Lickel and

authenticator that

contains wecr’s nme,

setwork address, and

time bo TGS.

6. Server venfies that

&. Workstation semls cone —s mpcremnno

ticket and sutheaticator male, gtanis access

to server to service. I mutual

duthenbicaien ra

required, server returns

an autheaticatur
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:

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

2. The Kerberos server must share a secret key with each server. All servers are registered

with the Kerberos server.Such an environment is referred to as a Kerberos realm.

The concept of realm can be explained as follows.

Realm A

Kerberos

Client

al TGS.

Steet for LOO

mest. qicket lo! 3

“al TG

9. ticket for jocal TY

2.

3. request ticket for femote TGS

4. ticket for remote TGS

j
2 Kerberos

AS

TGS

Figure 14.2 Request for Service in Another Realm

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 read-only copy of the Kerberos database might also reside on other Kerberos computer systems.

However, all changes to the database must be made on the master computer system. Changing or

accessing the contents of a Kerberos database requires the Kerberos master password.

A related concept is that of a Kerberos principal, which is a service or user that is known to the

Kerberos system.

Each Kerberos principal is identified by its principal name. Principal names consist of three parts: a

service or user name, an instance name, and a realm name

Networks of clients and servers under different administrative organizations typically constitute

different realms.

That is, it generally is not practical, or does not conform to administrative policy, to have users and

servers in one administrative domain registered with a Kerberos server elsewhere.

However, users in one realm may need access to servers in other realms, and some servers

may be willing to provide service to users from other realms, provided that those users are

authenticated.

Kerberos provides a mechanism for supporting such interrealm authentication. For two realms to

support interrealm authentication, a third requirement is added:

3. The Kerberos server in each interoperating realm shares a secret key with the server in the

other realm. The two Kerberos servers are registered with each other.

The scheme requires that the Kerberos server in one realm trust the Kerberos server in the other

realm to authenticate its users. Furthermore, the participating servers in the second realm must also

be willing to trust the Kerberos server in the first realm.

Kerberos version 5
Version 5 of Kerberos provides a number of improvements over version 4.

« developed in mid 1990’s

* provides improvements over v4

— addresses environmental shortcomings and technical deficiencies

¢ specified as Internet standard RFC 1510

Differences between version 4 and 5

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

Environmental shortcomings

0 encryption system dependence

o internet protocol dependence

0 message byte ordering

o ticket lifetime

o authentication forwarding

o inter-realm authenticaiton

Technical deficiencies

o double encryption o PCBC encryption o Session keys

o Password attacks

The version 5 authentication dialogue

(a) Authentication Service Exchange: to obtain ticket-granting ticket

(1) C + AS: Options || ID, || Realm, || ID,,, ll Times || Nonce,

(2) AS + C: Realm, Wl 1De lI Ticket,,, \l Ex [ Res | Times ll Noncey ll Realinyg, Il Dyes |

Ticket, = ER. | Flags WK, poy Realm, ILD Il ADe Times]

(b) Ticket-Granting Service Exchange: to obtain service-granting ticket

(3) C + TGS: Options | JD, II Times lll Nence, || Ticket,,. \l Authenticator,,

(4) TGS + C: Realm, || [De \\Ticket,, WEx. [Key ll Times || Nonce, || Realm, Dy |

Ticketiys = Ex, [ Flags We pes Realm, IliDe ILADe Times]

Ticket, = Ex [Flags |IK,., llRealm, || IDc ll ADg || Times]

Authenticator, =Ex [De ll Realm, ITS]

tgs

(c) Client/Server Authentication Exchange: to obtain service

(5) C + V: Options |! Ticket, || Authenticator,

(6) V+ C: Exe, [ TS2 ll Subkey Il Seq# ]

Ticket, - Ex [Flags IIK,., Realm, ll Ig ll ADg | Times]

Authenticator, = Ey yL/Pc ll Realm, ITS ll Subkey | Seq#|

irst, consider the authentication service exchange. Message (1) is a client request for a ticket-

granting ticket. As before, it includes the ID of the user and the TGS. The following new
elements are added:

Realm: Indicates realm of user

Options: Used to request that certain flags be set in the returned ticket

Times: Used by the client to request the following time settings in the ticket:

from: the desired start time for the requested ticket

till: the requested expiration time for the requested ticket rtime: requested renew-till time

Nonce: A random value to be repeated in message (2) to assure that the response is fresh

and has not been replayed by an opponent

Message (2) returns a ticket-granting ticket, identifying information for the client, and a block

encrypted using the encryption key based on the user's password.

This block includes the session key to be used between the client and the TGS, times specified in

message (1), the nonce from message (1), and TGS identifying information.

The ticket itself includes the session key, identifying information for the client, the requested time

values, and flags that reflect the status of this ticket and the requested options.

These flags introduce significant new functionality to version 5. For now, we defer a discussion of

these flags and concentrate on the overall structure of the version 5 protocol.

Let us now compare the ticket-granting service exchange for versions 4 and 5. We see that

message (3) for both versions includes an authenticator, a ticket, and the name of the requested

service.

In addition, version 5 includes requested times and options for the ticket and a nonce, all with

functions similar to those of message (1).

The authenticator itself is essentially the same as the one used in version 4.

Message (4) has the same structure as message (2), returning a ticket plus information needed by
the client, the latter encrypted with the session key now shared by the client and the TGS.

Finally, for the client/server authentication exchange, several new features appear in version 5. In

message (5), the client may request as an option that mutual authentication is required. The

authenticator includes several new fields as follows:

Subkey: The client's choice for an encryption key to be used to protect this specific

application session. If this field is omitted, the session key from the ticket (Kc,v) is used.

Sequence number: An optional field that specifies the starting sequence number

to be use may be sequence numbered to detect replays.

If mutual authentication is required, the server responds with message (6). This message includes

the timestamp from the authenticator. Note that in version 4, the timestamp was incremented by

one. This is not necessary in version 5 because the nature of the format of messages is such that it is

not possible for an opponent to create message (6) without knowledge of the appropriate encryption

keys.

Ticket Flags

The flags field included in tickets in version 5 supports expanded functionality compared to that

available in version 4.

X.509 Certificates

Overview:

issued by a Certification Authority (CA), containing:

version (1, 2, or 3)
serial number (unique within CA) identifying certificate

signature algorithm identifier

— issuer X.500 name (CA)

— period of validity (from - to dates)

— subject X.500 name (name of owner)

— subject public-key info (algorithm, parameters, key)

— issuer unique identifier (v2+)

— subject unique identifier (v2+)

— extension fields (v3)

— signature (of hash of all fields in certificate)

* notation CA<<A>> denotes certificate for A signed by CA

X.509 defines a framework for the provision of authentication services by the X.500 directory to its

users. The directory may serve as a repository of public-key certificates. Each certificate contains

the public key of a user and is signed with the private key of a trusted certification authority. In

addition, X.509 defines alternative authentication protocols based on the use of public-key

certificates.

X.509 is an important standard because the certificate structure and authentication protocols defined

in X.509 are used in a variety of contexts. For example, the X.509 certificate format is used in

S/MIME), IP Security and SSL/TLS and SET

X.509 is based on the use of public-key cryptography and digital signatures. The standard does not
dictate the use of a specific algorithm but recommends RSA. The digital signature scheme is

assumed to require the use of a hash function.

Certificates

The heart of the X.509 scheme is the public-key certificate associated with each user. These user

certificates are assumed to be created by some trusted certification authority (CA) and placed in the

directory by the CA or by the user.

Version:

Differentiates among successive versions of the certificate format; the default is version 1. If the

Issuer Unique Identifier or Subject Unique Identifier are present, the value must be version 2. If one

or more extensions are present, the version must be version 3.

Serial number:

An integer value, unique within the issuing CA, that is unambiguously associated with this

certificate.

Signature algorithm identifier:

The algorithm used to sign the certificate, together with any associated parameters. Because this

information is repeated in the Signature field at the end of the certificate, this field has little, if any,

utility.
a a a “Iecthenes buwithns

Version | algorithm |- --------- Tete }

— | identifier 4 = |

~ Certificate Issuer Name

Slgeatern Seriai Number

. algorithm

algorithm a This Update Date

identifier : =

Issuer Name | F ee Next Update Date |

->€=

Period of || mathefore | 4 Revoked | | naa aaa ED

validity not after L: certificate revocation date

Subject Name j ®

Subject’s .

public ny — Rae —_ .

info i key - ¥

Issuer Unique Revoked

Identifier certificate

Subject Unique Signature

Identifier +

Extensions (by Certificate Revocation List

Signalure ;

(a) X20) Certificate

Issuer name:

X.500 name of the CA that created and signed this certificate.

Period of validity:

Consists of two dates: the first and last on which the certificate is valid.

Subject name:

The name of the user to whom this certificate refers. That is, this certificate certifies the public key
of the subject who holds the corresponding private key.

Subject's public-key information:

The public key of the subject, plus an identifier of the algorithm for which this key is to be used,

together with any associated parameters.

Issuer unique identifier:

An optional bit string ficld used to identify uniqucly the issuing CA in the event the

X.500 name has been reused for different entities.

Subject unique identifier:

An optional bit string field used to identify uniquely the subject in the event the

X.500 name has been reused for different entities.

Extensions:

A set of one or more extension fields. Extensions were added in version 3 and are discussed later in

this section.

Signature:

Covers all of the other fields of the certificate; it contains the hash code of the other fields,

encrypted with the CA's private key. This field includes the signature algorithm identifie

The standard uses the following notation to define a certificate: CA<<A>> = CA {V, SN, AI, CA,

TA, A, Ap} where

Y <<X>> = the certificate of user X issued by certification authority Y Y {I} = the signing of

Iby Y. It consists of I with an encrypted hash code appended

The CA signs the certificate with its private key. If the corresponding public key is known to a user,

then that user can verify that a certificate signed by the CA is valid.

Obtaining a User's Certificate

User certificates generated by a CA have the following characteristics:

Any user with access to the public key of the CA can verify the user public key that was

certified.

No party other than the certification authority can modify the certificate without this

being detected.

ecause certificates are unforgeable, they can be placed in a directory without the need for the

directory to make special efforts to protect them.

If all users subscribe to the same CA, then there is a common trust of that CA. All user certificates

can be placed in the directory for access by all users.

If there is a large community of users, it may not be practical for all users to subscribe to the same

CA. Because it is the CA that signs certificates, each participating user must have a copy of the

CA's own public key to verify signatures. This public key must be provided to each user in an

absolutely secure (with respect to integrity and authenticity) way so that the user has confidence in

the associated certificates. Thus, with many users, it may be more practical for there to be a

number of CAs, each of which securely provides its public key to some fraction of the users.

Now suppose that A has obtained a certificate from certification authority X1 and B has obtained a

certificate from CA X2. If A does not securely know the public key of X2, then B's certificate,

issued by X2, is useless to A.

A can read B's certificate, but A cannot verify the signature. However, if the two CAs have

securely exchanged their own public keys, the following procedure will enable A to obtain B's

public key:

1. A obtains, from the directory, the certificate of X2 signed by X1. Because A securely

knows X1's public key, A can obtain X2's public key from its certificate and verify it by means of

X1's signature on the certificate.

2. A then goes back to the directory and obtains the certificate of B signed by X2

Because A now has a trusted copy of X2's public key, A can verify the signature

and securely obtain B's public key.

A has used a chain of certificates to obtain B's public key. In the notation of X.509, this chain is

expressed as

X1<<X2>> X2 <<B>>

In the same fashion, B can obtain A's public key with the reverse chain: X2<<X1>>X1 <<A>>
This scheme need not be limited to a chain of two certificates. An arbitrarily long path of

CAs can be followed to produce a chain. A chain with N elements would be expressed as

X1<<X2>> K2 <<X3>>... KN<<B>>

In this case, each pair of CAs in the chain (Xj, Xi+]) must have created certificates for each

other.

All these certificates of CAs by CAs need to appear in the directory, and the user needs to know

how they are linked to follow a path to another user's public-key certificate. X.509 suggests that

CAs be arranged in a hierarchy so that navigation is straightforward.

Figure 14.5, taken from X.509, is an example of such a hierarchy. The connected circles indicate

the hierarchical relationship among the CAs; the associated boxes indicate certificates maintained

in the directory for each CA entry. The directory entry for each CA includes two types of

certificates:

Forward certificates: Certificates of X generated by other CAs

Reverse certificates: Certificates generated by X that are the certificates of other

CAs

CA Hierarchy Use

In the example given below , user A can acquire the following certificates from the directory to

establish a certification path to B:

X<<W>> W <<V>> V <<Y>> <<Z>> Z <<B>>

When A has obtained these certificates, it can unwrap the certification path in sequence to recover a

trusted copy of B's public key. Using this public key, A can send encrypted
Messages to B. If A wishes to receive encrypted messages back from B, or to sign messages sent to

B, then B will require A's public key, which can be obtained from the following certification path:

Z<<Y>> Y <<V>> V <<W>> W <<X>>X <<A>>

B can obtain this set of certificates from the directory, or A can provide them as part of its initial

message to B.

Certificate Revocation

* Certificates have a period of validity

* may need to revoke before expiry, for the following reasons eg:

1. user's private key is compromised

2. User is no longer certified by this CA

3. CA's certificate is compromised

¢ CA’s maintain list of revoked certificates

1. the Certificate Revocation List (CRL)

* users should check certs with CA’s CRL

Authentication Procedures

X.509 includes three alternative authentication procedures:

¢ One-Way Authentication

* Two-Way Authentication

¢ Three-Way Authentication

« all use public-key signatures

One-Way Authentication

* 1 message ( A->B) used to establish

— the identity of A and that message is from A

— message was intended for B

— integrity & originality of message

* message must include timestamp, nonce, B's identity and is signed by A

Two-Way Authentication

¢ 2messages (A->B, B->A) which also establishes in addition:

— the identity of B and that reply is from B

— that reply is intended for A

— integrity & originality of reply

reply includes original nonce from A, also timestamp and nonce from B

Three-Way Authentication

° 3 messages (A->B, B->A, A->B) which enables above authentication without

synchronized clocks

¢ has reply from a back to B containing signed copy of nonce from B

* means that timestamps need not be checked or relied upon

X.509 Version 3

The X.509 version 2 format does not convey all of the information that recent design and

implementation experience has shown to be needed. [FORD95] lists the following requirements not

satisfied by version 2:

1. The Subject field is inadequate to convey the identity of a key owner to a public- key user.

2. The Subject field is also inadequate for many applications, which typically recognize entities by

an Internet e-mail address, a URL, or some other Internet- related identification.

3. There is a need to indicate security policy information. There is a need to limit the damage that

can result from a faulty or malicious CA by setting constraints on the applicability of a particular

certificate.

4. It is important to be able to identify different keys used by the same owner at different

times.

The certificate extensions fall into three main categories: key and policy information, subject and

issuer attributes, and certification path constraints.

Key and Policy Information

These extensions convey additional information about the subject and issuer keys, plus indicators of

certificate policy.. For example, a policy might be applicable to the authentication of electronic

data interchange (EDI) transactions for the trading of goods within a given price range.

This area includes the following:

Authority key identifier: Identifies the public key to be used to verify the

signature on this certificate or CRL.

Subject key identifier: Identifies the public key being certified. Useful for subject

key pair updating.

Key usage: Indicates a restriction imposed as to the purposes for which, and the policies

under which, the certified public key may be used.

Private-key usage period: Indicates the period of use of the private key

corresponding to the public key.. For example, with digital signature keys, the usage period for the

signing private key is typically shorter than that for the verifying public key.

Certificate policies: Certificates may be used in environments where multiple policies

apply.
Policy mappings: Used only in certificates for CAs issued by other CAs.

Certificate Subject and Issuer Attributes

These extensions support alternative names, in alternative formats, for a certificate subject or

certificate issuer and can convey additional information about the certificate subject, to increase a

certificate user's confidence that the certificate subject is a particular person or entity. For example,

information such as postal address, position within a corporation, or picture image may be required.

The extension fields in this area include the following:

Subject alternative name: Contains one or more alternative names, using any of a variety

of forms

Subject directory attributes: Conveys any desired X.500 directory attribute values for

the subject of this certificate.

Certification Path Constraints

These extensions allow constraint specifications to be included in certificates issued for

CAs by other CAs.The extension fields in this area include the following:

Basic constraints: Indicates if the subject may act as a CA. If so, a certification path

length constraint may be specified.

Name constraints: Indicates a name space within which all subject names in

subsequent certificates in a certification path must be located.

Policy constraints: Specifies constraints that may require explicit certificate policy

identification or inhibit policy mapping for the remainder of the certification path.

ELECTRONIC MAIL SECURITY PRETTY GOOD PRIVACY (PGP)

PGP provides the confidentiality and authentication service that can be used for electronic

mail and file storage applications. The steps involved in PGP are
Select the best available cryptographic algorithms as building blocks.

Integrate these algorithms into a general purpose application that is independent of

operating system and processor and that is based on a small set of easy-to-use commands.

Make the package and its documentation, including the source code, freely

available via the internet, bulletin boards and commercial networks.

Enter into an agreement with a company to provide) a fully compatible, low cost
commercial version of PGP.

PGP has grown explosively and is now widely used. A number of reasons can be cited for this

growth.

° It is available free worldwide in versions that run on a variety of platform.

e It is based on algorithms that have survived extensive public review and are considered

extremely secure.

° e.g., RSA, DSS and Diffie Hellman for public key encryption CAST-128, IDEA and 3DES

for conventional encryption SHA-1 for hash coding.

° it has a wide range of applicability.

e It was not developed by, nor it is controlled by, any governmental or standards

organization.

Operational description

The actual operation of PGP consists of five services: authentication, confidentiality, compression,

e-mail compatibility and segmentation.

1. Authentication

The sequence for authentication is as follows:

The sender creates the message

SHA-I is used to generate a 160-bit hash code of the message

The hash code is encrypted with RSA using the sender’s private key and the result is

prepended to the message

The receiver uses RSA with the sender’s public key to decrypt and recover the hash code.
The receiver generates a new hash code for the message and compares it with the decrypted

hash code. If the two match, the message is accepted as authentic.

2. Confidentiality

Confidentiality is provided by encrypting messages to be transmitted or to be stored locally as

files. In both cases, the conventional encryption algorithm CAST-128 may be used. The 64-bit

cipher feedback (CFB) mode is used.

In PGP, each conventional key is used only once. That is, a new key is generated as a random 128-

bit number for each message. Thus although this is referred to as a session key, it is in reality a one

time key. To protect the key, it is encrypted with the receiver’s public key.

The sequence for confidentiality is as follows:

e The sender generates a message and a random 128-bit number to be used as a session key for

this message only.

e The message is encrypted using CAST-128 with the session key.

e The session key is encrypted with RSA, using the receiver’s public key and is prepended

to the message.

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

e The session key is used to decrypt the message.

Confidentiality and authentication

Here both services may be used for the same message. First, a signature is generated for the

plaintext message and prepended to the message. Then the plaintext plus the signature is

encrypted using CAST-128 and the session key is encrypted using RSA.

< Source A = a a Destination B—

ERI! HCD) RU,

ER, ws

Compare:

(a) Authentication only Exusldl

Plaga oh) Lal

(b) Confidentiality only

KUy
(ec) Confidentiality and authentication

Figure 15.1 PGP Cryptographic Functions

3. Compression

As a default, PGP compresses the message after applying the signature but before encryption. This

has the benefit of saving space for both e-mail transmission and for file storage.

The signature is generated before compression for two reasons:

It is preferable to sign an uncompressed message so that one can store only the

uncompressed message together with the signature for future verification. If one signed a

compressed document, then it would be necessary either to store a compressed version of the

message for later verification or to recompress the message when verification is required.

Even if one were willing to generate dynamically a recompressed message fro verification, PGP’s

compression algorithm presents a difficulty. The algorithm is not deterministic; various

implementations of the algorithm achieve different tradeoffs in running speed versus compression

ratio and as a result, produce different compression forms.

Message encryption is applied after compression to strengthen cryptographic security. Because the

compressed message has less redundancy than the original plaintext, cryptanalysis is more difficult.

The compression algorithm used is ZIP.

4. e-mail compatibility

Many electronic mail systems only permit the use of blocks consisting of ASCII texts. To

accommodate this restriction, PGP provides the service of converting the raw 8-bit binary

stream to a stream of printable ASCII characters. The scheme used for this purpose is radix-64

conversion. Each group of three octets of binary data is mapped into four ASCII characters.

e.g., consider the 24-bit (3 octets) raw text sequence 00100011 01011100

10010001, we can express this input in block of 6-bits to produce 4 ASCII

characters.

001000 110101 110010 010001

I L Y R =>corresponding ASCTI characters

5. Segmentation and reassembly

E-mail facilities often are restricted to a maximum length. E.g., many of the facilities accessible

through the internet impose a maximum length of 50,000 octets. Any message longer than that

must be broken up into smaller segments, each of which is mailed separately.

To accommodate this restriction, PGP automatically subdivides a message that is too large into
segments that are small enough to send via e-mail. The segmentation is done after all the other

processing, including the radix-64 conversion. At the receiving end, PGP must strip off all

e-mail headers and reassemble the entire original block before performing the other steps.

PGP Operation Summary:

X = file convert from radix 64]

X—Red! [yy

Signature generate signature . 5

ss reqived? X = signature | Y Confidentiality sent as Xx ;

a - required? K — Dx, lKsl: X — Dg, LX]

a;

att No

Las

Compress ¥

X— ZX) Decompress

X-—zZ-\x)

encrypt key, X

X— Exo,| As] ll Ex,[X]

‘Confidentiality

required?

strip signature from XX)

venly signature

Signature

required?

No

ail: No
oat

=i

convert to radix 64 ¥

X —RA4LX]

(a) Generic Transmission Diagram (from A) (b) Generic Reception Diagram (to B)

Cryptographic keys and key rings

Three separate requirements can be identified with respect to these keys:

A means of generating unpredictable session keys is needed.

It must allow a user to have multiple public key/private key pairs.

Each PGP entity must maintain a file of its own public/private key pairs as well as a file of

public keys of correspondents.

We now examine each of the requirements in turn.

1. Session key generation

Each session key is associated with a single message and is used only for the purpose of encryption

and decryption of that message. Random 128-bit numbers are generated using CAST-128 itself.

The input to the random number

generator consists of a 128-bit key and two 64-bit blocks that are treated as plaintext to be

encrypted. Using cipher feedback mode, the CAST-128 produces two 64-bit cipher text blocks,

which are concatenated to form the 128-bit session key. The plaintext input to CAST-128 is itself

derived from a stream of 128-bit randomized numbers. These numbers are based on the keystroke

input from the user.

2. Key identifiers

If multiple public/private key pair are used, then how does the recipient know which of the public

keys was used to encrypt the session key? One simple solution would be to transmit the public key

with the message but, it is unnecessary wasteful of space. Another solution would be to

associate an identifier with each public key that is unique at least within each user.

The solution adopted by PGP is to assign a key ID to each public key that is, with very high

probability, unique within a user ID. The key ID associated with each public key consists of its

least significant 64 bits. i.c., the key ID of public key KUa is (KUg mod 2°),

A message consists of three components.

Message component — includes actual data to be transmitted, as well as the filename and a

timestamp that specifies the time of creation.

Signature component — includes the following

o Timestamp — time at which the signature was made.

o Message digest — hash code.

O Two octets of message digest — to enable the recipient to determine if the correct public key was

used to decrypt the message.

o Key ID of sender’s public key — identifies the public key

Session key component — includes session key and the identifier of the recipient public key.
Content Operation

Rot

' ZIP Ex.

Message

Exev, = encryption wilh user b's public key

Exe, - S™TYpton with aser a's private key

Ex = encryption with sesuon key

Zap compresuen Mancoon

Radixn-¢+ convertion function

Figure 15.3 General Format of PGP Message (from A to B)

3. Key rings

PGP provides a pair of data structures at each node, one to store the public/private key pair owned

by that node and one to store the public keys of the other users known at that node. These data

structures are referred to as private key ring and public key ring.

The general structures of the private and public key rings are shown below: Timestamp — the

date/time when this entry was made.

Key ID — the least significant bits of the public key.

Public key — public key portion of the pair. Private key — private key portion of the pair. User ID —

the owner of the key.

Key legitimacy field — indicates the extent to which PGP will trust that this is a valid

public key for this user.

Private Key Ring

Timestamp Key ID* Public Key Encrypted User ID*

Private Key

.....

Ti PU; mod 2 PU; E(H(P)), PR) User i

...:.

Public Key Ring

[Timestamp Key ID* Public Key =| Owner Trust User ID* Key Signatures) Signature

Legitimacy Trust(s)

:*..:...

........

Tj PU, mod 2% PU; trust_flag, User i trust_flag;

........

* = field used to index table

Figure 15.4 General Structure of Private and Public Key Rings

Signature trust field — indicates the degree to which this PGP user trusts the signer to certify

public key.

Owner trust field — indicates the degree to which this public key is trusted to sign other public

key certificates.

PGP message generation

First consider message transmission and assume that the message is to be both signed and

encrypted. The sending PGP entity performs the following steps:

1. signing the message

PGP retrieves the sender’s private key from the private key ring using user ID as an index. If user

ID was not provided, the first private key from the ring is retrieved.

PGP prompts the user for the passpharse (password) to recover the unencrypted

private key.

The signature component of the message is constructed.

2. encrypting the message

PGP generates a session key and encrypts the message.

PGP retrieves the recipient’s public key from the public key ring using user

ID as index.

The session key component of the message is constructed. The receiving PGP entity performs

the following steps:

Decrypting the message

PGP retrieves the receiver’s private key from the private key ring, using the key ID field in

the session key component of the message as an index.

PGP prompts the user for the passpharse (password) to recover the unencrypted

private key.

PGP then recovers the session key and decrypts the message.

2. Authenticating the message

PGP retrieves the sender’s public key from the public key ring, using the key ID field in the

signature key component of the message as an index.

PGP recovers the transmitted message digest.

PGP computes the message digest for the received message and compares it to the transmitted

message digest to authenticate.

Public-Key Management
This whole business of protecting public keys from tampering is the single most difficult problem in

practical public key applications. PGP provides a structure for solving this problem, with several

suggested options that may be used.

Approaches to Public-Key Management

The essence of the problem is this: User A must build up a public-key ring containing the public

keys of other users to interoperate with them using PGP. Suppose that A's key ring contains a

public key attributed to B but that the key is, in fact, owned by C. This could happen if, for
example, A got the key from a bulletin board system (BBS) that was used by B to post the public

key but that has been compromised by C. The result is that two threats now exist. First, C can send

messages to A and forge B's signature, so that A will accept the message as coming from B.

Second, any encrypted message from A to B can be read by C.

A number of approaches are possible for minimizing the risk thaf-a user's public-key ring contains

false public keys. Suppose that A wishes to obtain a reliable public key for B. The following are

some approaches that could be used:

1. Physically get the key from B. B could store her public key (PUb) on a floppy disk and hand it

to A.

2. Verify a key by telephone. If A can recognize B on the phone, A could call B and ask her to

dictate the key, in radix-64 format, over the phone.

3. Obtain B's public key from a mutual trusted individual D. For this purpose, the introducer,

D, creates a signed certificate. The certificate includes B's public key, the time of creation of the

key, and a validity period for the key.

4. Obtain B's public key from a trusted certifying authority. Again, a public key certificate is

created and signed by the authority. A could then access the authority, providing a user name

and receiving a signed certificate.

For cases 3 and 4, A would already have to have a copy of the introducer's public key and trust that

this key is valid. Ultimately, it is up to A to assign a level of trust to anyone who is to act as an

introducer.

The Use of Trust

Although PGP does not include any specification for establishing certifying authorities or for

establishing trust, it does provide a convenient means of using trust, associating trust with public
keys, and exploiting trust information.

The basic structure is as follows. Each entry in the public-key ring is a public-key certificate.

Associated with each such entry is a key legitimacy field that indicates the extent to which

PGP will trust that this is a valid public key for this user; the higher the level of trust, the stronger

is the binding of this user ID to this key.

This field is computed by PGP.Also associated with the entry are zero or more signatures that the

key ring owner has collected that sign this certificate. In turn, each signature has associated
with it a signature trust field that indicates the degree to which this PGP user trusts the signer to

certify public keys.The key legitimacy field is derived from the collection of signature trust

fields in the entry.Finally, each entry defines a public key associated with a particular owner, and

an owner trust field is included that indicates the degree to which this public key is trusted to sign

other public-key certificates; this level of trust is assigned by the user.

The three fields mentioned in the previous paragraph are each contained in a structure referred to as

a trust flag byte.

Suppose that we are dealing with the public-key ring of user A. We can describe the operation of

the trust processing as follows:

1. When A inserts a new public key on the public-key ring, PGP must assign a value to the trust

flag that is associated with the owner of this public key. If the owner is A, and therefore this public

key also appears in the private-key ring, then a value of ultimate trust is automatically assigned to

the trust field. Otherwise, PGP asks A for his assessment of the trust to be assigned to the owner of

this key, and A must enter the desired level. The user can specify that this owner is unknown,

untrusted, marginally trusted, or completely trusted.

2. When the new public key is entered, one or more signatures may be attached to it.

More signatures may be added later. When a signature is inserted into the entry, PGP searches the

public-key ring to see if the author of this signature is among the known public-key owners. If

so, the OWNERTRUST value for this owner is assigned to the SIGTRUST field for this signature.

If not, an unknown user value is assigned.

3. The value of the key Icgitimacy ficld is calculated on the basis of the signature trust ficlds

present in this entry. If at least one signature has a signature trust value of ultimate, then the key

legitimacy value is set to complete.

F4 S t

O = key's owner is trusted by you to sign keys ino af

OQ = key's owner is partly trusted by you to sign keys

(#) = key is deemed legitimate by you

Figure 15.7 PGP Trust Model Example

The node labeled "You" refers to the entry in the public-key ring corresponding to this user. This

key is legitimate and the OWNERTRUST value is ultimate trust. Each other node in the key ring

has an OWNERTRUST value of undefined unless some other value is assigned by the user. In this

example, this user has specified that it always trusts the following users to sign other keys: D, E, F,

L. This user partially trusts users A and B to sign other keys.

So the shading, or lack thercof, of the nodes in Figure 15.7 indicates the level of trust assigned

by this user. The tree structure indicates which keys have been signed by which
other users. If a key is signed by a user whose key is also in this key ring, the arrow joins the signed

key to the signatory. If the key is signed by a user whose key is not present in this key ring, the arrow

joins the signed key to a question mark, indicating that the signatory is unknown to this user.

Note that all keys whose owners are fully or partially trusted by this user have been signed by this

user, with the exception of node L.

1. We assume that two partially trusted signatures are sufficient to certify a key. Hence, the key

for user H is deemed legitimate by PGP because it is signed by A and B, both of whom are partially

trusted.

2. A key may be determined to be legitimate because it is signed by one fully trusted or two partially

trusted signatories, but its user may not be trusted to sign other keys. For example, N's key is

legitimate because it is signed by E, whom this user trusts, but N is not trusted to sign other keys

because this user has not assigned N that trust value. Therefore, although R's key is signed by N,

PGP does not consider R's key legitimate. This situation makes perfect sense. If you wish to send

a private message to some individual, it is not necessary that you trust that individual in any respect. It

is only necessary that you are sure that you have the correct public key for that individual.

3. Figure 15.7 also shows an example of a detached "orphan" node S, with two unknown

signatures. Such a key may have been acquired from a key server. PGP cannot assume that this key is

legitimate simply because it came from a reputable server. The user must declare the key legitimate

by signing it or by telling PGP that it is willing to trust fully one of the key's signatories.

S/MIME

S/MIME (Secure/Multipurpose Internet Mail Extension) is a security enhancement to the MIME

Internet e-mail format standard, based on technology from RSA Data Security. S/MIME is defined in a

number of documents, most importantly RFCs 3369, 3370, 3850 and 3851.

Multipurpose Internet Mail Extensions

MIME is an extension to the RFC 822 framework that is intended to address some of the problems and
limitations of the use of SMTP (Simple Mail Transfer Protocol) or some other mail transfer protocol

and RFC 822 for electronic mail. Following are the limitations of SMTP/822 scheme:
1. SMTP cannot transmit executable files or other binary objects.

2. SMTP cannot transmit text data that includes national language characters because these

are represented by 8-bit codes with values of 128 decimal or higher, and SMTP is limited to 7-bit

ASCIL

3. SMTP servers may reject mail message over a certain size.

4. SMTP gateways that translate between ASCII and the character code EBCDIC do not use a

consistent set of mappings, resulting in translation problems.

5. SMTP gateways to X.400 electronic mail networks cannot handle nontextual data included in

X.400 messages.

6. Some SMTP implementations do not adhere completely to the SMTP standards defined in RFC

821. Common problems include:

o Deletion, addition, or reordering of carriage return and linefeed

o Truncating or wrapping lines longer than 76 characters

o Removal of trailing white space (tab and space characters)

o Padding of lines in a message to the same length

o Conversion of tab characters into multiple space characters

MIME is intended to resolve these problems in a manner that is compatible with existing RFC 822

implementations. The specification is provided in RFCs 2045 through 2049.

Overview

The MIME specification includes the following elements:

1. Five new message header fields are defined, which may be included in an RFC

822 header. These fields provide information about the body of the message.
2. A number of content formats are defined, thus standardizing representations that support

multimedia electronic mail.

3. Transfer encodings are defined that enable the conversion of any content format into a form that

is protected from alteration by the mail system.

In this subsection, we introduce the five message header fields. The next two subsections deal with

content formats and transfer encodings.

The five header fields defined in MIME are as follows:

MIME-Version: Must have the parameter value 1.0. This field indicates that the message

conforms to RFCs 2045 and 2046.

Content-Type: Describes the data contained in the body with sufficient detail
Content-Transfer-Encoding: Indicates the type of transformation that has been used to

represent the body of the message in a way that is acceptable for mail transport.

Content-ID: Used to identify MIME entities uniquely in multiple contexts.

Content-Description: A text description of the object with the body; this is useful when the

object is not readable (e.g., audio data).

MIME Content Types

The bulk of the MIME specification is concerned with the definition of a variety of content types. This

reflects the need to provide standardized ways of dealing with a wide variety of information

representations in a multimedia environment.

Table 15.3 lists the content types specified in RFC 2046. There are seven different major types of

content and a total of 15 subtypes

Type Subtype

Text Plain

Enriched

Multipart Mixed

Parallel

Alternative

Digest

Message rfc822
Partial

External-

body

Image jpeg

Description

Unformatted text; may be ASCII or ISO 8859.

Provides greater format flexibility.

The different parts are independent but are to be transmitted

together. They should be presented to the receiver in the order

edn rd De re ee ee Se de a a i

Differs from Mixed only in that no order is defined for

delivering the parts to the receiver.

The different parts are alternative versions of the same

information. They are ordered in increasing faithfulness to the

original, and the recipient's mail system should display the

Similar to Mixed, but the default type/subtype of each part is

message/rfc822.

The body is itself an encapsulated message that conforms to

RFC 822.

Used to allow fragmentation of large mail items, in a way that is

transparent to the recipient.

Contains a pointer to an object that exists elsewhere.

The image is in JPEG format, JFIF encoding.

gif The image is in GIF format.

Video mpeg MPEG format.

Audio Basic Single-channel 8-bit ISDN mu-law encoding at a sample rate of

8 kHz.

Application PostScript |Adobe Postscript.

octet- stream General binary data consisting of 8-bit bytes.

For the text type of body, no special software is required to get the full meaning of the text, aside

from support of the indicated character set. The primary subtype is plain text, which is simply a

string of ASCII characters or ISO 8859 characters. The enriched subtype allows greater formatting

flexibility.

The multipart type indicates that the body contains multiple, independent parts. The Content-Type

header field includes a parameter, called boundary, that defines the delimiter between body parts.

The multipart/digest subtype is used when each of the body parts is interpreted as an RFC

822 message with headers. This subtype enables the construction of a message whose parts are

individual messages. For example, the moderator of a group might collect e- mail messages from

participants, bundle these messages, and send them out in one encapsulating MIME message.

The message type provides a number of important capabilities in MIME. The message/rfc822 subtype

indicates that the body is an entire message, including header and body. Despite the name of this

subtype, the encapsulated message may be not only a simple RFC 822 message, but also any MIME

message.

The message/partial subtype enables fragmentation of a large message into a number of parts, which

must be reassembled at the destination. For this subtype, three parameters are specified in the

Content-Type: Message/Partial field: an id common to all fragments of the same message, a sequence

number unique to each fragment, and the total number of fragments.

the message/external-body subtype indicates that the actual data to be conveyed in this message are not

contained in the body. Instead, the body contains the information needed to access the data. As with the

other message types, the message/external-body subtype has an outer header and an encapsulated

message with its own header. The only necessary field in the outer header is the Content-Type field,

which identifies this as a message/external-body subtype. The inner header is the message header for
the encapsulated message. The Content-Type field in the outer header must include an access-type

parameter, which indicates the method of access, such as FTP (file transfer protocol).

The application type refers to other kinds of data, typically either uninterpreted binary data or

information to be processed by a mail-based application.

MIME Transfer Encodings

The other major component of the MIME specification, in addition to content type specification, is a

definition of transfer encodings for message bodies. The objective is to provide reliable delivery across

the largest range of environments.

The MIME standard defines two methods of encoding data. The Content-Transfer- Encoding field can

actually take on six values, as listed in Table 15.4. For SMTP transfer, it is safe to use the 7bit form.

The 8bit and binary forms may be usable in other mail transport contexts. Another Content-

Transfer-Encoding value is x-token, which indicates that some other encoding scheme is used, for

which a name is to be supplied. The two actual encoding schemes defined are quoted-printable and

base64.

MIME Transfer Encodings

Tbit The data are all represented by short lines of ASCII characters.

Sbit The lines are short, but there may be non-ASCII characters (octets with the

high-order bit set).

binary Not only may non-ASCI characters be present but the lines are not

necessarilv short enough for SMTP transport.

quoted- Encodes the data in such a way that if the data being encoded are mostly

printable ASCT text, the encoded form of the data remains largely recognizable by

base64 Encodes data by mapping 6-bit blocks of input to 8-bit blocks of output, all

of which are printable ASCTI characters.

x-token A named nonstandard encoding.

The quoted-printable transfer encoding is useful when the data consists largely of octets that

correspond to printable ASCII characters. In essence, it represents nonsafe characters by the

hexadecimal representation of their code and introduces reversible (soft) line breaks to limit

message lines to 76 characters.

The base64 transfer encoding, also known as radix-64 encoding, is a common one for encoding

arbitrary binary data in such a way as to be invulnerable to the processing by mail transport programs.

Canonical Form

An important concept in MIME and S/MIME is that of canonical form. Canonical form is a format,

appropriate to the content type that is standardized for use between systems. This is in contrast to

native form, which is a format that may be peculiar to a particular system.

S/MIME Functionality

In terms of general functionality, S/MIME is very similar to PGP. Both offer the ability to sign and/or

encrypt messages. In this subsection, we briefly summarize S/MIME capability. We then look in more

detail at this capability by examining message formats and message preparation.

Functions

S/MIME provides the following functions:

Enveloped data: This consists of encrypted content of any type and encrypted- content

encryption keys for one or more recipients.

Signed data: A digital signature is formed by taking the message digest of the content to

be signed and then encrypting that with the private key of the signer. The content plus signature are

then encoded using base64 encoding. A signed data message can only be viewed by a recipient with

S/MIME capability.

Clear-signed data: As with signed data, a digital signature of the content is formed.

However, in this case, only the digital signature is encoded using base64. As a result, recipients

without S/MIME capability can view the message content, although they cannot verify the signature.

Signed and enveloped data: Signed-only and encrypted-only entities may be nested, so
that encrypted data may be signed and signed data or clear-signed data may be encrypted.

Cryptographic Algorithms

¢ hash functions: SHA-1 & MD5

« digital signatures: DSS & RSA

* session key encryption: ElGamal & RSA

* message encryption: Triple-DES, RC2/40 and others

¢ have a procedure to decide which algorithms to use.

Table 15.6 summarizes the cryptographic algorithms used in S/MIME. S/MIME uses the following

terminology, taken from RFC 2119 to specify the requirement level:

Must: The definition is an absolute requirement of the specification.

implementation must include this feature or function to be in conformance with the specification.

An

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.

S/MIME Messages

S/MIME makes use of a number of new MIME content types, which are shown in Table

15.7, All of the new application types use the designation PKCS. This refers to a set of public-key

cryptography specifications issued by RSA Laboratories and made available for the S/MIME effort.

Function Requirement

Create a message digest to be used in MUST support SHA-1.

forming a digital signature.

Receiver SHOULD support MDS for backward

Encrypt message digest to form compatibility.

digital signature.

Sending and receiving agents MUST support DSS.

Sending agents SHOULD support RSA encryption.

Receivins ascents SHOULD sunnort verification of

Encrypt session key for transmission Sending and receiving agents SHOULD support

with message. Diffie-Hellman.

Sending and _receivinoe ascents MUST sunnaort RSA

Encrypt message for transmission Sending and receiving agents MUST support

with one-time session key. encryption with triple DES

Sending agents SHOULD support encryption with

AES.
Create a message authentication codeReceiving agents MUST support HMAC with

SHA-1.

Rece_ino a ents SHOTILD sunnort HMAC with

Type Subtype smime Parameter Description

Multipart Signed A clear-signed message in two parts: one is

the message and the other is the signature.

Application pkcs 7- mimesignedData A signed S/MIME