Unit-IV

Kerberos
 Kerberos4 is an authentication service
 Kerberos provides a centralized authentication
server whose function is to authenticate users
to servers and servers to users.
 Kerberos relies exclusively on symmetric
encryption
 Two versions of Kerberos are in common use
 Version 4
 Version 5
A Simple Authentication Dialogue
A More Secure Authentication Dialogue
 Problems
 Number of times that a user has to enter a
password
 Plaintext transmission of the password
Summary of Kerberos Version 4 Message
Exchanges
Overview of Kerberos
 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.
 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.
Kerberos Realms
Kerberos Version 5
 developed in mid 1990’s
 specified as Internet standard RFC 1510
 provides improvements over v4
 addresses environmental shortcomings
 encryption alg, network protocol, byte order, ticket
lifetime, authentication forwarding, interrealm auth
 and technical deficiencies
 double encryption, non-std mode of use, session keys,
password attacks
. Environmental shortcomings

 Encryption system dependence: Version 4 requires the use of DES. 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 indifferent
algorithms and allowing the specification of different variations on a
given algorithm.
 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.
 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
addressIn version 5, all message structures are defined using Abstract
Syntax Notation One (ASN.1) and Basic Encoding Rules (BER), which
provide an unambiguous byte ordering.
 Ticket lifetime : Maximum lifetime is over 21 hours. This may be
inadequate for some applications (e.g., a 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.

Technical deficiencies

 Double encryption: tickets provided to clients are encrypted twice, once

with the secret key of the target server and then again with a secret key
known to the client. The second encryption is not necessary and is
computationally wasteful.
 PCBC encryption : Encryption in version 4 makes use of a nonstandard
mode of DES known as propagating cipher block chaining (PCBC). Version
5 provides explicit integrity mechanisms, allowing the standard CBC mode
to be used for encryption. In particular, a checksum or hash code is
attached to the message prior to encryption using CBC.
 Session keys : Each ticket includes a session key that is used by the client
to encrypt the authenticator sent to the service associated with that ticket.
In addition, the session key may subsequently be used by the client and
the server to protect messages passed during that session. n version 5, it
is possible for a client and server to negotiate a subsession key, which is to
be used only for that one connection. A new access by the client would
result in the use of a new subsession key.
 Password attacks : Both versions are vulnerable to a password attack.
Version 5 does provide a mechanism known as preauthentication, which
should make password attacks more difficult, but it does not prevent them.
Kerberos v5 Dialogue
the authentication service exchange. Message (1) is a client request for
a ticketgranting 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
 ● 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
 Kerberos 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.
 While comparing 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.
 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 used by the server
for messages sent to the client during this session. Messages
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.
Version 5 Flags
X.509 Authentication Service
 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 based on the use of public-key
cryptography and digital signatures
 X.509 Certificate
 Version: Differentiates among successive versions of
the certificate format; the default is version 1.
 Serial number: An integer value unique within the
issuing CA
 Signature algorithm identifier: The algorithm used to
sign the certificate
 Issuer name: X.500 is the name of the CA
 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.
 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
 Issuer unique identifier: Identify uniquely the issuing
CA
 Subject unique identifier: Identify uniquely the
subject in the event
 Extensions: A set of one or more extension fields.
 Signature: Covers all of the other fields of the
certificate
Obtaining a Certificate
 any user with access to CA can get any
certificate from it
 only the CA can modify a certificate
 because cannot be forged, certificates can be
placed in a public directory
Obtaining a Certificate
 any user with access to CA can get any
certificate from it
 only the CA can modify a certificate
 because cannot be forged, certificates can be
placed in a public directory
 CA Hierarchy Use

ack chains of certificates:

acquires B certificate using chain: X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>
acquires A certificate using chain: Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>
Revocation List

Reasons for Revocation:

1. The user's private key is assumed to be
compromised.
2.The user is no longer certified by this CA.
3.The CA's certificate is assumed to be compromised.
Certificate Revocation
 certificates have a period of validity
 may need to revoke before expiry, 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
 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
 2 messages (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
 has been recognised that additional
information is needed in a certificate
 email/URL, policy details, usage constraints
 rather than explicitly naming new fields
defined a general extension method
 extensions consist of:
 extension identifier
 criticality indicator
 extension value
Certificate Extensions
 key and policy information
 convey info about subject & issuer keys, plus
indicators of certificate policy
 certificate subject and issuer attributes
 support alternative names, in alternative formats
for certificate subject and/or issuer
 certificate path constraints
 allow constraints on use of certificates by other
CA’s
 Key and policy information
Authority key identifier: Identifies the public key to be used to verify the
signature on this certificate or CRL. Enables distinct keys of the same CA to be
differentiated. One use of this field is to handle CA key pair updating.
 ● Subject key identifier: Identifies the public key being certified. Useful for
subject key pair updating. Also, a subject may have multiple key pairs and,
correspondingly, different certificates for different purposes (e.g., digital signature
and encryption key agreement).
 ● Key usage: Indicates a restriction imposed as to the purposes for which,
and the policies under which, the certified public key may be used. May indicate
one or more of the following: digital signature, nonrepudiation, key encryption, data
encryption, key agreement, CA signature verification on certificates, CA signature
verification on CRLs.
 ● Private-key usage period: Indicates the period of use of the private key
corresponding to the public key. Typically, the private key is used over a different
period from the validity of 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. This extension lists policies that the certificate is
recognized as supporting, together with optional qualifier information.
 ● Policy mappings: Used only in certificates for CAs issued by other CAs.
Policy mappings allow an issuing CA to indicate that one or more of that issuer's
policies can be considered equivalent to another policy used in the subject CA's
Certificate path constraints

 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
Certificate subject and issuer attributes

 ● Subject alternative name: Contains one or

more alternative names, using any of a variety of
 forms. This field is important for supporting certain
applications, such as electronic mail, EDI,
 and IPSec, which may employ their own name forms.
 ● Issuer 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.
Public Key Infrastructure
 Public-key infrastructure (PKI) defined as the set
of hardware, software, people, policies, and
procedures needed to create, manage, store,
distribute, and revoke digital certificates based
on asymmetric cryptography.
 The principal objective for developing a PKI is to
enable secure, convenient, and efficient
acquisition of public keys
 Public Key Infrastructure X.509 (PKIX) working
group has been the driving force behind setting
up a formal (and generic) model based on X.509
that is suitable for deploying a certificate-based
architecture on the Internet
PKIX Architectural Model
Key elements of the PKIX model
 End entity: A generic term used to denote end users, devices
(e.g., servers, routers), or any other entity that can be
identified in the subject field of a public key certificate.
 Certification authority (CA): The issuer of certificates and
(usually) certificate revocation lists (CRLs). It may also
support a variety of administrative functions, although these
are often delegated to one or more Registration Authorities.
 Registration authority (RA): An optional component that can
assume a number of administrative functions from the CA.
The RA is often associated with the end entity registration
process but can assist in a number of other areas as well.
 CRL issuer: An optional component that a CA can delegate to
publish CRLs.
 Repository: A generic term used to denote any method for
storing certificates and CRLs so that they can be retrieved by
end entities.
PKIX Management Functions
 Registration
 Initialization
 Certification
 Key pair recovery
 Key pair update
 Revocation request
 Cross certification
IP Security
 Applications of Ipsec
 Secure branch office connectivity over the Internet
 Secure remote access over the Internet
 Establishing extranet and intranet connectivity
with partners
 Enhancing electronic commerce security
IPSec Scenario
Benefits of IPsec
 When IPsec is implemented in a firewall or
router, it provides strong security that can be
applied to all traffic crossing the perimeter.
 IPsec in a firewall is resistant to bypass if all
traffic from the outside must use IP and the
firewall is the only means of entrance from the
Internet into the organization.
 IPsec is below the transport layer (TCP, UDP)
and so is transparent to applications.
 IPsec can be transparent to end users.
 IPsec can provide security for individual users if
needed.
IPsec Documents
 Architecture: Covers the general concepts, security requirements,
definitions, and mechanisms defining IPsec technology.
 Authentication Header (AH): AH is an extension header to provide
message authentication.
 Encapsulating Security Payload (ESP): ESP consists of an
encapsulating header and trailer used to provide encryption or
combined encryption/authentication.
 Internet Key Exchange (IKE): This is a collection of documents
describing the key management schemes for use with IPsec.
 Cryptographic algorithms: This category encompasses a large set
of documents that define and describe cryptographic algorithms
for encryption, message authentication, pseudorandom functions
(PRFs), and cryptographic key exchange.
 Other: There are a variety of other IPsec-related RFCs, including
those dealing with security policy and management information
base (MIB) content.
IPsec Services
 Access control
 Connectionless integrity
 Data origin authentication
 Rejection of replayed packets (a form of
partial sequence integrity)
 Confidentiality (encryption)
 Limited traffic flow confidentiality
Transport and Tunnel Modes
 Transport mode
 Transport mode provides protection primarily for upper-
layer protocols. That is, transport mode protection
extends to the payload of an IP packet
 Tunnel mode
 Tunnel mode provides protection to the entire IP packet.
 To achieve this, after the AH or ESP fields are added to
the IP packet, the entire packet plus security fields is
treated as the payload of new outer IP packet with a new
outer IP header.
 The entire original, inner, packet travels through a tunnel
from one point of an IP network to another; no routers
along the way are able to examine the inner IP header.
Transport and Tunnel Modes
 Transport Mode
 to encrypt & optionally authenticate IP data
 can do traffic analysis but is efficient
 good for ESP host to host traffic
 Tunnel Mode
 encrypts entire IP packet
 add new header for next hop
 no routers on way can examine inner IP header
 good for VPNs, gateway to gateway security
Tunnel mode and Transport mode
functionality
Authentication Header (AH)
 provides support for data integrity &
authentication of IP packets
 end system/router can authenticate user/app
 prevents address spoofing attacks by tracking
sequence numbers
 based on use of a MAC
 HMAC-MD5-96 or HMAC-SHA-1-96
 parties must share a secret key
Authentication Header (AH)
Authentication Header (AH)
 Next Header (8 bits): Identifies the type of header
immediately following this header
 Payload Length (8 bits): Length of Authentication
Header in 32-bit words, minus 2.
 Reserved (16 bits): For future use
 Security Parameters Index (32 bits): Identifies a
security association
 Sequence Number (32 bits): A monotonically
increasing counter value
 Authentication Data (variable): A variable-length
field (must be an integral number of 32-bit words)
that contains the Integrity Check Value (ICV), or
MAC, for this packet
Encapsulating Security Payload
 ESP consists of an encapsulating header and
trailer used to provide encryption or combined
encryption/authentication.
ESP packet fields
 Security Parameters Index (32 bits): Identifies a security association.
 Sequence Number (32 bits): A monotonically increasing counter
value; this provides an anti-replay function, as discussed for AH.
 Payload Data (variable): This is a transport-level segment (transport
mode) or IP packet (tunnel mode) that is protected by encryption.
 Padding (0 – 255 bytes): The purpose of this field is discussed later.
 Pad Length (8 bits): Indicates the number of pad bytes immediately
preceding this field.
 Next Header (8 bits): Identifies the type of data contained in the
payload data field by identifying the first header in that payload (for
example, an extension header in IPv6, or an upper-layer protocol
such as TCP).
 Integrity Check Value (variable): A variable-length field (must be an
integral number of 32-bit words) that contains the Integrity Check
Encapsulating Security Payload
Transport vs Tunnel Mode ESP
 transport mode is used to encrypt & optionally
authenticate IP data
 data protected but header left in clear
 can do traffic analysis but is efficient
 good for ESP host to host traffic
 tunnel mode encrypts entire IP packet
 add new header for next hop
 good for VPNs, gateway to gateway security
Combining Security Associations
 SA’s can implement either AH or ESP
 to implement both need to combine SA’s
 form a security association bundle
 may terminate at different or same endpoints
 combined by
 transport adjacency
 iterated tunneling
 combining authentication & encryption
 ESP with authentication, bundled inner ESP &
outer AH, bundled inner transport & outer ESP
Combining Security Associations
IPSec Key Management
 handles key generation & distribution
 typically need 2 pairs of keys
 2 per direction for AH & ESP
 manual key management
 sysadmin manually configures every system
 automated key management
 automated system for on demand creation of keys
for SA’s in large systems
 has Oakley & ISAKMP elements
PGP
 PGP provides a confidentiality and
authentication service that can be used for
electronic mail and file storage applications
Operational Description of PGP
 The actual operation of PGP, as opposed to
the management of keys, consists of four
services:
1. authentication,
2. confidentiality,
3. compression, and
4. e-mail compatibility
PGP AUTHENTICATION
1. The sender creates a message.
2. SHA-1 is used to generate a 160-bit hash code
of the message.
3. The hash code is encrypted with RSA using the
sender’s private key, and the result is
prepended to the message.
4. The receiver uses RSA with the sender’s public
key to decrypt and recover the hash code.
5. 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.
PGP AUTHENTICATION
PGP CONFIDENTIALITY
1. The sender generates a message and a
random 128-bit number to be used as a
session key for this message only.
2. The message is encrypted using CAST-128 (or
IDEA or 3DES) with the session key.
3. The session key is encrypted with RSA using
the recipient’s public key and is prepended to
the message.
4. The receiver uses RSA with its private key to
decrypt and recover the session key.
5. The session key is used to decrypt the
message.
PGP CONFIDENTIALITY
PGP CONFIDENTIALITY &
AUTHENTICATION
PGP Message
PGP Message
 A message consists of three components:
 the message component,
 a signature (optional), and
 a session key component (optional).
 The message component includes the actual data to be stored or
transmitted, as well as a filename and a timestamp that specifies the
time of creation.
 The signature component includes the following.
 Timestamp: The time at which the signature was made.
 Message digest: The 160-bit SHA-1 digest encrypted with the sender’s
private signature key.
 Leading two octets of message digest: Enables the recipient to determine

if the correct public key was used to decrypt the message digest
for authentication by comparing this plaintext copy of the first two
octets with the first two octets of the decrypted digest.
 Key ID of sender’s public key: Identifies the public key that should be used
to decrypt the message digest
 The session key component includes the session key and the
identifier of the recipient’s public key that was used by the sender to
encrypt the session key.
PGP Message Generation
PGP Message Generation
 1. Signing the message:
 a. PGP retrieves the sender’s private key from the private-
key ring using your_userid as an index. If your_userid was
not provided in the command, the first private key on the
ring is retrieved.
 b. PGP prompts the user for the passphrase to recover the
unencrypted private key.
 c. The signature component of the message is constructed.
 2. Encrypting the message:
 a. PGP generates a session key and encrypts the message.
 b. PGP retrieves the recipient’s public key from the public-
key ring using her_userid as an index.
 c. The session key component of the message is
constructed.
PGP Message Reception
PGP Message Reception
1. Decrypting the message:
 a. 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.
 b. PGP prompts the user for the passphrase to recover the
unencrypted private key.
 c. PGP then recovers the session key and decrypts the
message.
 2. Authenticating the message:
 a. 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.
 b. PGP recovers the transmitted message digest.
 c. PGP computes the message digest for the received message
and compares it to the transmitted message digest to
authenticate.
MIME
 Multipurpose Internet Mail Extensions (MIME)
is an Internet standard that extends the
format of email to support:
 Text in character sets other than ASCII
 Non-text attachments: audio, video, images,
application programs etc.
 Message bodies with multiple parts
 Header information in non-ASCII character sets
S/MIME
 Secure/Multipurpose Internet Mail Extension (S/MIME) is a security
enhancement to the MIME Internet e-mail format standard based
on technology from RSA Data Security.
 Multipurpose Internet Mail Extension (MIME is intended to address
some of the problems and limitations of the use of Simple Mail
Transfer Protocol (SMTP)
 SMTP cannot transmit executable files or other binary objects.
 SMTP cannot transmit text data that includes national language
characters
 SMTP servers may reject mail message over a certain size.
 SMTP gateways that translate between ASCII and the character
code EBCDIC do not use a consistent set of mappings, resulting
in translation problems.
 SMTP gateways to X.400 electronic mail networks cannot handle
nontextual data included in X.400 messages.
 Some SMTP implementations do not adhere completely to the
SMTP standards defined in RFC 821. Common problems include:
 Deletion, addition, or reordering of carriage return and linefeed
 Truncating or wrapping lines longer than 76 characters
S/MIME
 The MIME specification includes the following
elements.
1. Five new message header fields are defined,
which may be included in an RFC 5322 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.
Header fields defined in MIME
 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 that the receiving user agent can pick an
appropriate agent or mechanism to represent the data to the
user or otherwise deal with the data in an appropriate
manner.
 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
 MIME – Example cont’d
--unique-boundary-1
Content-type: text/enriched

This is <bold><italic>enriched.</italic></bold><smaller>as defined in RFC 1896</smaller>

Isn’t it <bigger><bigger>cool?</bigger></bigger>

--unique-boundary-1
Content-Type: message/rfc822

From: (mailbox in US-ASCII)

To: (address in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable

... Additional text in ISO-8859-1 goes here ...

--unique-boundary-1--
/MIME / introduction

74