Authentication applications Kerberos X.509 Authentication services E mail security IP security Web security

UNIT 4   SECURITY PRACTICE

•

Authentication applications – Kerberos 

•

_{X.509  Authentication services} 

•

_{E‐mail security}

•

_IP security 

•

_{Web security}  

Slides Courtesy of William Stallings, “Cryptography & Network Security”, Pearson Education, 4th Edition

Chapter‐1 Authentication  Applications

•

Authentication applications – Kerberos

•

_{X.509  Authentication services} 

Authentication Applications

•

will consider authentication functions

•

developed to support application‐level 

authentication & digital signatures

•

will consider Kerberos – a private‐key 

authentication service

•

_{then X.509 ‐ a public‐key directory} 

authentication service

Kerberos

•

trusted key server system from MIT 

•

provides centralised private‐key third‐party 

authentication in a distributed network

– allows users access to services distributed through  network – without needing to trust all workstations – rather all trust a central authentication server

•

two versions in use: 4 & 5

Kerberos Requirements

•

its first report identified requirements as:

– secure – reliable – transparent – scalable

•

implemented using an authentication protocol 

based on Needham‐Schroeder

Kerberos v4 Overview

•

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 TGT

Kerberos v4 Dialogue

1. obtain ticket granting ticket from AS

• once per session

2. obtain service granting ticket from TGT

• for each distinct service required

3. client/server exchange to obtain service

• on every service request

Kerberos Realms

•

a Kerberos environment consists of:

– a Kerberos server – a number of clients, all registered with server – application servers, sharing keys with server

•

_{this is termed a realm}

– typically a single administrative domain

•

if have multiple realms, their Kerberos servers 

must share keys and trust 

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

X.509 Authentication Service  • part of CCITT X.500 directory service standards – distributed servers maintaining user info database • defines framework for authentication services  – directory may store public‐key certificates – with public key of user signed by certification authority  • also defines authentication protocols  • uses public‐key crypto & digital signatures  – algorithms not standardised, but RSA recommended • X.509 certificates are widely used 

X.509 Certificates • 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

Summary

•

have considered:

– Kerberos trusted key server system – X.509 authentication and certificates

Chapter‐2 E‐Mail Security • PGP

Email Security

•

email is one of the most widely used and 

regarded network services 

•

currently message contents are not secure 

– may be inspected either in transit  – or by suitably privileged users on destination  system

Email Security Enhancements

•

confidentiality

– protection from disclosure

•

_{authentication}

– of sender of message

•

_{message integrity}

– protection from modification 

•

non‐repudiation of origin

– protection from denial by sender

Pretty Good Privacy (PGP)

•

_{widely used de facto secure email}

•

_{developed by Phil Zimmermann}

•

selected best available crypto algs to use

•

_{integrated into a single program}

•

on Unix, PC, Macintosh and other systems 

•

originally free, now also have commercial 

versions available

PGP Operation – Authentication

1. sender creates message

2. use SHA‐1 to generate 160‐bit hash of 

message 

3. signed hash with RSA using sender's private 

key, and is attached to message

4. receiver uses RSA with sender's public key to 

decrypt and recover hash code

5. receiver verifies received message using hash 

of it and compares with decrypted hash code

PGP Operation – Confidentiality

1. sender generates message and 128‐bit 

random number as session key for it

2. encrypt message using CAST‐128 / IDEA / 

3DES in CBC mode with session key

3. session key encrypted using RSA with 

recipient's public key, & attached to msg

4. receiver uses RSA with private key to decrypt 

and recover session key

5. session key is used to decrypt message

PGP Operation –

Confidentiality & 

Authentication 

•

can use both services on same message

– create signature & attach to message – encrypt both message & signature – attach RSA/ElGamal encrypted session key

PGP Operation – Compression

•

by default PGP compresses message after 

signing but before encrypting

– so can store uncompressed message & signature  for later verification – & because compression is non deterministic

•

uses ZIP compression algorithm

PGP Operation – Email 

Compatibility

• when using PGP will have binary data to send  (encrypted message etc) • however email was designed only for text • hence PGP must encode raw binary data into  printable ASCII characters • uses radix‐64 algorithm – maps 3 bytes to 4 printable chars – also appends a CRC • PGP also segments messages if too big

PGP Session Keys

•

need a session key for each message

– of varying sizes: 56‐bit DES, 128‐bit CAST or IDEA,  168‐bit Triple‐DES

•

generated using ANSI X12.17 mode

•

uses random inputs taken from previous uses 

and from keystroke timing of user

PGP Public & Private Keys • since many public/private keys may be in use, need  to identify which is actually used to encrypt session  key in a message – could send full public‐key with every message – but this is inefficient • rather use a key identifier based on key – is least significant 64‐bits of the key – will very likely be unique • also use key ID in signatures

PGP Key Rings

•

each PGP user has a pair of keyrings:

– public‐key ring contains all the public‐keys of  other PGP users known to this user, indexed by  key ID – private‐key ring contains the public/private key  pair(s) for this user, indexed by key ID & encrypted  keyed from a hashed passphrase

•

security of private keys thus depends on the 

pass‐phrase security

PGP Key Management • rather than relying on certificate authorities • in PGP every user is own CA – can sign keys for users they know directly • forms a “web of trust” – trust keys have signed – can trust keys others have signed if have a chain of  signatures to them • key ring includes trust indicators • users can also revoke their keys

S/MIME 

(Secure/Multipurpose 

Internet Mail 

Extensions)

•

security enhancement to MIME email

– original Internet RFC822 email was text only – MIME provided support for varying content types  and multi‐part messages – with encoding of binary data to textual form – S/MIME added security enhancements

•

_{have S/MIME support in many mail agents}

– eg MS Outlook, Mozilla, Mac Mail etc

S/MIME Functions

•

enveloped data

– encrypted content and associated keys

•

_signed data

– encoded message + signed digest

•

_{clear‐signed data}

– cleartext message + encoded signed digest

•

signed & enveloped data

– nesting of signed & encrypted entities

S/MIME Cryptographic 

Algorithms

•

digital signatures: DSS & RSA

•

hash functions: SHA‐1 & MD5

•

_{session key encryption: ElGamal & RSA}

•

_{message encryption: AES, Triple‐DES, RC2/40} 

and others

•

MAC: HMAC with SHA‐1

•

_{have process to decide which algs to use}

S/MIME Messages

•

S/MIME secures a MIME entity with a 

signature, encryption, or both

•

forming a MIME wrapped PKCS object

•

have a range of content‐types:

– enveloped data – signed data – clear‐signed data – registration request – certificate only message

S/MIME Certificate Processing

•

S/MIME uses X.509 v3 certificates

•

managed using a hybrid of a strict X.509 CA 

hierarchy & PGP’s web of trust

•

each client has a list of trusted CA’s certs

•

and own public/private key pairs & certs

•

certificates must be signed by trusted CA’s

Certificate Authorities

•

have several well‐known CA’s

•

Verisign one of most widely used

•

_{Verisign issues several types of Digital IDs}

•

_{increasing levels of checks & hence trust}

Class Identity Checks Usage

1 name/email check web browsing/email

2 + enroll/addr check email, subs, s/w validate

Summary

•

have considered:

– secure email – PGP

Chapter‐3 IP Security 

IP Security

•

have a range of application specific security 

mechanisms

– eg. S/MIME, PGP, Kerberos, SSL/HTTPS

•

_{however there are security concerns that cut} 

across protocol layers

•

would like security implemented by the 

network for all applications

IPSec

•

general IP Security mechanisms

•

provides

– authentication – confidentiality – key management

•

applicable to use over LANs, across public & 

private WANs, & for the Internet

Benefits of IPSec

•

_{in a firewall/router provides strong security to} 

all traffic crossing the perimeter

•

_{in a firewall/router is resistant to bypass}

•

is below transport layer, hence transparent to 

applications

•

can be transparent to end users

•

_{can provide security for individual users}

•

secures routing architecture

IP Security Architecture

•

specification is quite complex

•

defined in numerous RFC’s

– incl. RFC 2401/2402/2406/2408 – many others, grouped by category

•

_{mandatory in IPv6, optional in IPv4}

•

_{have two security header extensions:}

– Authentication Header (AH)

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}

Security Associations

•

_{a one‐way relationship between sender &} 

receiver that affords security for traffic flow

•

_{defined by 3 parameters:}

– Security Parameters Index (SPI) – IP Destination Address – Security Protocol Identifier

•

has a number of other parameters

– seq no, AH & EH info, lifetime etc

•

have a database of Security Associations

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

Encapsulating Security 

Payload (ESP)

• provides message content confidentiality & limited  traffic flow confidentiality • can optionally provide the same authentication  services as AH • supports range of ciphers, modes, padding – incl. DES, Triple‐DES, RC5, IDEA, CAST etc – CBC & other modes – padding needed to fill blocksize, fields, for traffic flow

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 Security 

Associations

Summary

•

have considered:

– IPSec security framework – AH

Chapter‐4 Web Security 

•

SSL

•

TLS

•

_SET

Web Security

•

_{Web now widely used by business,} 

government, individuals

•

_{but Internet & Web are vulnerable}

•

have a variety of threats

– integrity – confidentiality – denial of service – authentication

•

need added security mechanisms

SSL (Secure Socket Layer)

•

_{transport layer security service}

•

_{originally developed by Netscape}

•

version 3 designed with public input

•

_{subsequently became Internet standard} 

known as TLS (Transport Layer Security)

•

_{uses TCP to provide a reliable end‐to‐end} 

service

•

SSL has two layers of protocols

SSL Architecture

•

SSL connection

– a transient, peer‐to‐peer, communications link – associated with 1 SSL session

•

SSL session

– an association between client & server – created by the Handshake Protocol – define a set of cryptographic parameters – may be shared by multiple SSL connections

SSL Record Protocol Services

•

_{message integrity}

– using a MAC with shared secret key – similar to HMAC but with different padding

•

_{confidentiality}

– using symmetric encryption with a shared secret  key defined by Handshake Protocol – AES, IDEA, RC2‐40, DES‐40, DES, 3DES, Fortezza,  RC4‐40, RC4‐128 – message is compressed before encryption

SSL Change Cipher Spec 

Protocol

•

one of 3 SSL specific protocols which use the 

SSL Record protocol

•

a single message

•

causes pending state to become current

•

hence updating the cipher suite in use

SSL Alert Protocol • conveys SSL‐related alerts to peer entity • severity • warning or fatal • specific alert • fatal: unexpected message, bad record mac,  decompression failure, handshake failure, illegal  parameter • warning: close notify, no certificate, bad certificate,  unsupported certificate, certificate revoked, certificate  expired, certificate unknown • compressed & encrypted like all SSL data

SSL Handshake Protocol

•

allows server & client to:

– authenticate each other – to negotiate encryption & MAC algorithms – to negotiate cryptographic keys to be used

•

_{comprises a series of messages in phases}

1. Establish Security Capabilities 2. Server Authentication and Key Exchange 3. Client Authentication and Key Exchange 4. Finish

TLS (Transport Layer Security)

•

_{IETF standard RFC 2246 similar to SSLv3}

•

_{with minor differences}

– in record format version number – uses HMAC for MAC – a pseudo‐random function expands secrets – has additional alert codes – some changes in supported ciphers – changes in certificate types & negotiations – changes in crypto computations & padding

Secure Electronic 

Transactions (SET)

•

open encryption & security specification

•

to protect Internet credit card transactions

•

_{developed in 1996 by Mastercard, Visa etc}

•

_{not a payment system}

•

_{rather a set of security protocols & formats}

– secure communications amongst parties – trust from use of X.509v3 certificates – privacy by restricted info to those who need it

SET Transaction 1. customer opens account 2. customer receives a certificate 3. merchants have their own certificates 4. customer places an order 5. merchant is verified 6. order and payment are sent 7. merchant requests payment authorization 8. merchant confirms order 9. merchant provides goods or service 10. merchant requests payment

Dual Signature

•

customer creates dual messages

– order information (OI) for merchant – payment information (PI) for bank

•

neither party needs details of other

•

_{but must know they are linked}

•

_{use a dual signature for this}

– signed concatenated hashes of OI & PI DS=E(PR_c, [H(H(PI)||H(OI))])

SET Purchase Request

•

SET purchase request exchange

consists of four messages

1. Initiate Request - get certificates

2. Initiate Response - signed response 3. Purchase Request - of OI & PI

Purchase Request – Merchant 1. verifies cardholder certificates using CA sigs 2. verifies dual signature using customer's public  signature key to ensure order has not been  tampered with in transit & that it was signed using  cardholder's private signature key 3. processes order and forwards the payment  information to the payment gateway for  authorization (described later) 4. sends a purchase response to cardholder

Payment Gateway  Authorization 1. verifies all certificates 2. decrypts digital envelope of authorization block to obtain  symmetric key & then decrypts authorization block 3. verifies merchant's signature on authorization block 4. decrypts digital envelope of payment block to obtain  symmetric key & then decrypts payment block 5. verifies dual signature on payment block 6. verifies that transaction ID received from merchant matches  that in PI received (indirectly) from customer 7. requests & receives an authorization from issuer 8. sends authorization response back to merchant

Payment Capture

•

merchant sends payment gateway a payment 

capture request

•

gateway checks request

•

then causes funds to be transferred to 

merchants account

•

_{notifies merchant using capture response}

Summary

•

have considered:

– need for web security

– SSL/TLS transport layer security protocols – SET secure credit card payment protocols