oct. 5, 2005 csc296q network security page 1 csc 296q network security wed. 7:00 – 9:50 pm, rvr...

Oct. 5, 2005 CSc296Q Network Security

CSc 296Q Network Security

Wed. 7:00 – 9:50 PM, RVR 1010

Oct. 5, 2005

California State University, SacramentoComputer Science Department


Secure Protocols Layer 5 (Application)

Remote Access: SSH, Secure ftp, SCP WEB: HTTPS, SHTTP DNS: DNSSec Email: PGP, GPG, S/MIME, SIMAP, Secure SMTP

extension Authentication: Kerberos, RADIUS

Layer 4 (Transport) SSL/TLS, SSL VPN Stunnel

Layer 3 (Network) IPSec VPN Security mechanisms in OSPF and BGP

Layer 2 (Data Link) L2TP, PPTP VPN L2F


PGP


PGP (Pretty Good Privacy) Personal high-security cryptographic software

that allows people to exchange messages or files with privacy, authentication, and convenience.

PGP can be used to encrypt and digitally sign files and e-mail Send E-mail securely to a known recipient Digitally sign E-mail so that the recipient(s) can be sure

it is from you Strong cryptographic algorithms (IDEA, RSA, SHA-1)

can be used by corporations as well as individuals

Unlike S/MIME, it doesn’t require Public Key Infrastructure

PGP is now on an Internet standards track (RFC 3156)


PGP History First version developed by Phil Zimmermann and released on

the Internet in 1991 Original version had his own encryption routine, which was insecure Replaced with IDEA, and RSA

Big legal battle over patents -> Resulted in two versions US version which uses RSA shareware library International version based in Norway, PGP-i

Got immediate government attention. PGP appeared outside of US (naturally). In 1993 he received criminal

investigation for “munition” export without license. But it was closed without charge in 1996. (40-bit+ key is considered weapon)

Since 2000, PGP is no longer considered non-exportable weapon

In 1996, started a company, merged with ViaCrypt , changed name to PGP Inc.

PGP Inc. was purchased by Network Associates in 1998. Zimmerman left NAI in 2001, joining Hush Communications

(Hushmail) In 2002, NAI stopped support of PGP. In 2002, ex-PGP members founded PGP Corp. and bought PGP

assets from NAI


PGP Services

For Messages authentication confidentiality compression e-mail compatibility (7-bit ASCII) segmentation and reassembly

key management generation, distribution, and revocation of

public/private keys generation and transport of session keys and

IVs


Message Authentication

based on digital signatures supported algorithms: e.g., RSA/SHA and

DSS/SHA Process

1. Run your document through hash and generate a fingerprint.

2. Encrypt the fingerprint with your private key. 3. Send the document to the receiver R. 4. R runs the same hash algorithm on it, generates a

fingerprint, 5. R decrypts the received signature using your public

key 6. R compares the two. If no match, the document has

been altered in transmission.


Digitally Signing in PGP-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA256

Hello everyone!Welcome to CSc296Q Network SecurityPlease check the digital signature below.

-----BEGIN PGP SIGNATURE-----Version: PGP Desktop 9.0.2 (Build 2424)

iQEUAwUBQ0OOICGBqGhfRFh0AQiJRgf3e4NO10ZEFlfLUIwqUBIzLqYW8Vq0emhVHqI9MYCS4Ca3kIdaOTNk1QKTpWUnZmzO/8zoQlDwa3dKH3/WogUgTLuIwuS1phy2ufG0dGNvoeKUIYNyRCQ28Y0mS0nb6r1szJ2Cq7EsKYO9S6eIAweUX5SWoP1W2kfQPggQHjjAuXHYxzy8a27ZgbG6bVUQYM7wpKL5eJcRj+YLEo71V6fdQ6z+YbHs6CUPzr/1ie/P5Geu6uViLYwvkJPGhYBt4gT3Atpi5aKCm1WmNoWpCWuDE26x622yrDtBEn/jGPyFSQN5D6b4is0UOyN6KAVcrWiZRvP5QCk6r5cxKttcL2eg=xXEL-----END PGP SIGNATURE-----

*** PGP SIGNATURE VERIFICATION ****** Status: Good Signature*** Signer: Ju-Yeon Jo <[email protected]> (0x5F445874)*** Signed: 10/5/2005 1:26:08 AM*** Verified: 10/5/2005 1:27:17 AM*** BEGIN PGP VERIFIED MESSAGE ***

Hello everyone!Welcome to CSc296Q Network SecurityPlease check the digital signature below.

*** END PGP VERIFIED MESSAGE ***


Message Confidentiality Symmetric key encryption with a random

session key and IV Session key and IV is encrypted with the public key of

the receiver Supported algorithms

public key:• DSA (1024 bit signing key)• RSA (2048 bit keys are popular, adequate, and interoperable)

secure hash / message digest• MD5• SHA-1

block cipher• IDEA• 3DES• CAST-128• AES-128 or AES-256 (not available in older clients)


Compression

applied after the signature applied before encryption

compression reduces redundancy makes cryptanalysis harder

supported algorithm: ZIP


PGP vs. OpenPGP

(From Wikipedia)


E-mail Compatibility

Encrypted messages and signatures may contain arbitrary octets (binary data)

As most e-mail systems support only ASCII characters, PGP converts an arbitrary binary stream into a stream of printable ASCII characters

radix 64 conversion: Three 8-bit blocks Four 6-bit blocks


PGP Key Management


Key Pairs – Public vs. Private Types of Key – RSA vs

DH/DSS Public key is widely

disseminated Private key is kept

secret with passphrase Use an actual phrase and

not just a single password. passphrases are case-

sensitive! Fingerprints Varying levels of

security 512-bit lowest. 2048-bit very secure


PGP Public Key

You can export your public key from PGPKeys with copy/paste, drag/drop, etc.

Since it’s a public key, you can put it anywhere email it in plaintext, put it on a web page, etc. put it on a “key server” for others to look up Etc.


Key IDs

a receiver may have several public key / private key pairs which private key to use to decrypt the session key? which public key to use to verify a signature?

transmitting the whole receiver’s public key back to the receiver would be wasteful (or sender’s public key in case of signature)

associating a random ID to a public key would result in management burden

PGP key ID: last 64 bits of the fingerprint unique within a user with very high probability


Private-key Ring

used to store the public key – private key pairs owned by a given user

essentially a table, where each row contains the following entries: timestamp key ID (indexed) public key encrypted private key user ID (indexed)

encencpassphrase hashhash

private key

encrypted private key


Public-key Ring Used to store public keys of other users

The ID of the key’s creator (usually name & email address).

The date the key was created & expiration date. A list of digital signatures provided by people who

attest to the key’s authenticity. Each entry contains:

timestamp key ID (indexed) public key user ID (indexed) owner trust signature(s) signature trust(s) key legitimacy


Public-key Revocation why to revoke a public key?

suspected to be compromised (private key got known by someone)

re-keying

the owner issues a revocation certificate … has a similar format to normal public-key certificates contains the public key to be revoked signed with the corresponding private key

and disseminates it as widely and quickly as possible


PGP Trust Problem


PGP: Trust Problems

How do you know a public key is really tied to a person the person it is claimed to be? no trust path from signer to you no 3rd party signatures on key unreliable 3rd party signatures on key

don’t rely on PGP key Server It is not a root Certificate Authority It means e-mail address works and possesses

the private key. But, there is no identity implication, unlike signatures from people

Fake keys exist e.g. Phil Zimmerman, Bill Gates, …


Obtaining the Key Directly from the Recipient Get the recipient’s public key, then add it to your

public keyring. Typically they do this by sending an email to you.

But what if someone in the middle gave you a fake key?

Call the receiver, and ask to read it back. Too long? Then use the fingerprint instead(MD5

hashing)

AEvil

GeniusYou

True PK Fake PK

Phony Encrypted MailTrue Encrypted mail


PGP: Web of Trust

Alice generates a key Alice gets other PGP users to sign her public key

using their private keys

Bob obtains Alice’s public key from somewhere a keyserver a web server directly from Alice

Hopefully, Bob trusts one of the signers of Alice’s key he can locally sign Alice’s key to signal he has validated it

Bob is free to decide how much to trust


Trust Path


PGP Implementation PGP, from PGP Corp

Until PGP 8.0, freeware was available From 9.0, 30-day trial. PGP Desktop Home 9.0: $99

Gnu Privacy Guard (GnuPG or GPG) Free from FSF Replacement for PGP Compliant to IETF OpenPGP (RFC 2440)

• PGP is interoperable with GPG or other OpenPGP-compliant systems

command line tools

Other implementations Hushmail, Veridis, Artisoft, Forum, Zendit, … Very good interoperability


Quiz

True / False PGP employs X.509 public key hierarchy In both PGP and S/MIME, the entire message is

encrypted using the recipient’s public key It is possible to create a fake PGP key and post

it In PGP, a sender can send email only to one

receiver at a time. Radix64 encoding converts binary data into 7-

bit ASCII by packing • 7 bytes (56 bits) into 8 7-bit ASCII (56 bits) ?• 3 bytes (24 bits) into 4 6-bit ASCII (24 bits) ?


Kerberos

Chapter 18.1


Kerberos

http://web.mit.edu/kerberos

Cer·ber·us (sûr’bər-əs) nounGreek & Roman Mythology.A three-headed dog guarding the entrance to Hades


Issues in Network Authentication Attacks

An attacker may pretend to be another user

An attacker can eavesdrop and perform a replay attack

An attacker can change source address

Key Management How do you deliver a key? Coping with key pair explosion = n*(n-1)/2


Kerberos Network authentication protocol

Authenticates the identity of users attempting to log on to a network and encrypts their communications through secret-key cryptography

provides centralized third-party authentication in a distributed network (all trust a central authentication server)

allows users access to services distributed through network

Prevents eavesdropping or replay attack and ensures data integrity

RFC 1510 - The Kerberos Network Authentication Service (V5)

Where are two other heads? (Accounting, Audit, never implemented)


History of Kerberos Designed at MIT to protect network services

provided by Project Athena Project Athena: a joint project of MIT, Digital

Equipment Corporation, and IBM, launched in 1983, and ran through June 30, 1991.

Creating a computing environment that would scale up to 10,000 networked workstations and accommodate heterogeneous hardware.

Spawned many technologies such as X Window System, Kerberos, Instant messaging, etc.

Versions Version 1-3: internal to MIT Version 4: 1987 Version 5: 1993 (RFC 1510)

Like PGP, it was considered munition and banned from export (until ~2000). A non-US implementation existed.


Kerberos Concepts

Requires a trusted third party Trusted server known as Key Distribution Center

(KDC) stores the secret keys Each entity on the network shares a secret key known

only to itself and to Kerberos• This secret passwords are not transmitted over network

Knowledge of this key serves to prove an entity's identity

• Political problem: KDC can access everyone’s secret key

Mutual authentication (Both user and server) Timestamp instead of nonces to prevent replay

attack Builds on symmetric key cryptography

Originally only secret keys, but now use public key


Kerberos Cryptography

Kerberos uses symmetric encryption and MACs.

Specifically, Version 5 (as in RFC 1510) uses DES combined with one of MD4, MD5, or a CRC (not recommended).

Release 1.2 of Kerberos Version 5 allows triple DES (3DES) in CBC-mode.


Key Distribution Center (KDC)

Authentication Server (AS) mutual authentication with client at login

based on long-term key gives client ticket granting ticket (TGT)

and short-term key.

Ticket Granting Server (TGS) mutual authentication with client based on

short-term key and ticket granting ticket. TGS then issues tickets giving clients access

to further servers demanding authentication


Kerberos Terminology

Client user or a program

Application server (S) any computer running services (telnet, ftp,

etc) Tickets

Kerberos data structures that can be safely sent across a network that, when valid, prove to its recipient the authorization of the client to use the recipients services


C(client)

S(server)

AS(authentication

server)

TGS(ticket-

grantingserver)

1 2 34

5

6

Kerberos Protocol Overview

1. TGT Request2. Encrypted TGT3. Ticket Request, TGT4. Encrypted Ticket5. Ticket6. Service


Security Protocol Notation Notations

Set of individuals: A, B, C…. Server: S Keys: K Timestamp: T Nonce: N Lifetime: L

Subscripts Symmetric key: With two subscripts (KAB) Public Key: With one subscript (KA) Private Key: Inverse of the public key (KA

-1) Text

Clear text: X with no { } Encrypted text: within the { } Concatenation: ||


Security Protocol Notation- Examples

A-> B: {X}KAB

A sends a message to B consisting of a plain text X encrypted under shared key KAB

B->A: {NB}KA

B sends a message to A consisting of B’s Nonce encrypted using A’s public key


Keys in Kerberos

KAS,TGS is a long-term secret key shared by AS and TGS.

KAS,C is a long-term secret key shared by AS and C.

KTGS,S is a long-term secret key shared by TGS and S.

KC,TGS is a secret short-term key shared by C and TGS.

KC,S is a secret session key shared by C and S.


1. CAS : TGS || from || to || NC

2. ASC : {KC,TGS||L1||C||from||to}KAS,TGS|| {KC,TGS||NC||from||to||TGS}KAS,C

(Ticket Granting Ticket for the TGS)

3. CTGS: S||from||to||N’C || {KC,TGS||L1||C||from||to}KAS,TGS || {C||T1}KC,TGS

4. TGSC: {KC,S||L2||C||from||to}KTGS,S || {KC,S|| N’C||from||to||S}KC,TGS

(Ticket for the server S)

5. CS: {KC,S||L2||C||from||to}KTGS,S || {C||T2}KC,S

6. SC : {T2}KC,S

Kerberos Messages (not complete)

Session keysgiven by the servers


Client-AS (1 & 2)

Client and AS use long-term key KAS,C to mutually authenticate each other, derive a short-term key KC,TGS and a ticket granting ticket.

These allow Client to talk to TGS in next step. This ticket includes short-term key KC,TGS and

ticket lifetime encrypted under long-term key KAS,TGS.

Default lifetime is 10 hours, determines length of session before re-authentication required.


Client-TGS (3 & 4) Client and TGS use short-term key KC,TGS to mutually

authenticate each other, derive a session key KC,S and a ticket (session granting ticket, service ticket, real ticket…).

These allow client to talk to Server in next step. Step 3:

Client contacts TGS with a request to access server S along with TGT obtained in step 2 and a timestamp authenticating himself to TGS.

Between step 3 and 4 TGS checks validity and lifetime of TGT and extracts its

copy of the short-term key KC,TGS. TGS can now check timestamp to authenticate client.

Step 4: If OK, TGS issues a session key KC,S and ticket to Client.

Default lifetime is 5 minutes. Client nonce N’C also sent to Client, encrypted under KC,TGS, allowing Client to authenticate TGS.


Client-Server (5 & 6)

Client C and Server S use session key KC,S and ticket to mutually authenticate each other.

Success grants Client access to server, session key can be used to secure remainder of Client-Server session.

Step 5: Client presents ticket along with message authenticating

himself to S. Between step 5 and 6

S checks validity and lifetime of ticket and extracts its copy of session key KC,S. S can now authenticate Client by checking timestamp.

Step 6 If OK, S grants access to Client. Optionally, S sends

Client a timestamp allowing authentication of S to Client.


1. CAS : TGS || from || to || NC

2. ASC : {KC,TGS||L1||C||from||to}KAS,TGS|| {KC,TGS||NC||from||to||TGS}KAS,C

(Ticket Granting Ticket for the TGS)

3. CTGS: S||from||to||N’C || {KC,TGS||L1||C||from||to}KAS,TGS || {C||T1}KC,TGS

4. TGSC: {KC,S||L2||C||from||to}KTGS,S || {KC,S|| N’C||from||to||S}KC,TGS

(Ticket for the server S)

5. CS: {KC,S||L2||C||from||to}KTGS,S || {C||T2}KC,S

6. SC : {T2}KC,S

Kerberos Messages (repeated)

Session keysgiven by the servers


Authentication in Kerberos

How do they know they are talking to the right entity?

1. C to AS: implicit – C can only decrypt {KC,TGS||NC||from||

to||TGS}KAS,C if he has KAS,C.

2. AS to C: encrypted nonce sent by C: {…||NC||…}KAS,C

3. C to TGS: C’s identity: {C||T1}KC,TGS

4. TGS to C: encrypted nonce sent by C: {…||N’C||…}KC,TGS

5. C to S: C’s identity: {C||T2}KC,S

6. S to C: timestamp: {T2}KC,S


Kerberos 4 Overview Fig 4.1Summary


Kerberos Realms

Single user/team managing one KDC is not desirable or practical Solved by logically subdividing the large

organization network into distinct realms

A Realm a Kerberos environment consists of:

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

typically a single administrative domain


Authentication Across Realms Authentication across realms is

complicated Each organization wishing to run a

Kerberos server establishes its own "realm".

By establishing "inter-realm" keys, the administrators of two realms can allow a client authenticated in the local realm to use its authentication remotely


Kerberos Benefits

Benefits No password transmitted on the network (The initial password? By secure channel) Protection against spoofing

• Only the user can decrypt the ticket with her secret key

Each ticket has finite lifetime Timestamps to prevent replay attack Mutual authentication

Kerberos has been extensively studied in the cryptography community, and held up well


Kerberos Weaknesses

KDC’s security is super critical Must guard at all cost!

Availability and reliability Only user-to-host authentication, not host-to-

host Trusted relationship between TGS and every

server Password Attack

Client-AS long-term key usually based on password entered by user: vulnerable to dictionary attacks

Time stamping All parties must have secure and (loosely)

synchronized clocks


Kerberos Weaknesses Ticket and session key cache

In multi-ser environment, cached session key can be used to impersonate a user

Requires timely transaction: during the lifetime of a ticket, replay attack possible. If too short repeatedly asks for password If too long greater opportunity for replay

attack Poor scalability problem

Solved by hierarchical authentication structure• E.g., Department KDC – University KDC - regional KDC• Only the regional KDCs form complete mesh


Implementation

TCP/UDP Port 88, 750 Implementation from MIT freely available Kerberos is integrated into many versions

of Unix Apple's MAC OS X

Windows 2000, XP, Server 2003 uses variants of Kerberos as their default authentication method Proprietary and not compatible


Quiz

Are the long-term shared passwords transmitted through the network?

TGT is encrypted with client’s shared key Interpretation?

B->A: {NB}KAB

The clients authenticate the servers, but not vice versa.

What ticket is this? (ticket granting ticket or the final ticket)

{KC,S||L2||C||from||to}KTGS,S


Next Topics

Network Attacks and Defense Hacking procedure, tools, methods Related to Chapter 5 and 6

Firewall Chapter 9, 10, 11

IDS Chapter 15

oct. 5, 2005 csc296q network security page 1 csc 296q network security wed. 7:00 – 9:50 pm, rvr...

Documents

pgp history r

pgp services r

individuals r

r zimmerman

pgp slide

r key management

radius r layer

bgp r layer