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
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
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 Document Overview
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
IPSec Services
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
 Removal of trailing white space (tab and space characters)
 Padding of lines in a message to the same length
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 Transfer Encodings
7bit The data are all represented by short lines of ASCII characters.
8bit The lines are short, but there may be non-ASCII characters
(octets with the high order bit set).
binary Not only may non-ASCII characters be present but the lines are
not necessarily short enough for SMTP transport.
quoted-printable Encodes the data in such a way that if the data being encoded
are mostly ASCII text, the encoded form of the data remains
largely recognizable by humans.
base64 Encodes data by mapping 6-bit blocks of input to 8-bit blocks of
output, all of which are printable ASCII characters.
x-token A named nonstandard encoding.
S/MIME 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 in S/MIME
Function Requirement
Create a message digest MUST support SHA-1.
to be used in forming a Receiver SHOULD support MD5 for backward compatibility.
digital signature. Sending and receiving agents MUST support DSS.
Encrypt message digest Sending agents SHOULD support RSA encryption.
to form digital signature. Receiving agents SHOULD support verification of RSA signatures
with key sizes 512 bits to 1024 bits.
Encrypt session key for Sending and receiving agents SHOULD support Diffie-Hellman.
transmission with Sending and receiving agents MUST support RSA encryption with
message. key sizes 512 bits to 1024 bits.
Encrypt message for Sending and receiving agents MUST support encryption with triple
transmission with one- DES
time Sending agents SHOULD support encryption with AES.
session key. Sending agents SHOULD support encryption with RC2/40.
Create a message Receiving agents MUST support HMAC with SHA-1.
authentication code Receiving agents SHOULD support HMAC with SHA-1.