oct. 5, 2005 csc296q network security page 1 csc 296q network security wed. 7:00 – 9:50 pm, rvr...
Post on 19-Dec-2015
214 views
TRANSCRIPT
Oct. 5, 2005 CSc296Q Network Security Page 1
CSc 296Q Network Security
Wed. 7:00 – 9:50 PM, RVR 1010
Oct. 5, 2005
California State University, SacramentoComputer Science Department
Oct. 5, 2005 CSc296Q Network Security Page 2
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
Oct. 5, 2005 CSc296Q Network Security Page 4
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)
Oct. 5, 2005 CSc296Q Network Security Page 5
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
Oct. 5, 2005 CSc296Q Network Security Page 6
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
Oct. 5, 2005 CSc296Q Network Security Page 7
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.
Oct. 5, 2005 CSc296Q Network Security Page 8
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 ***
Oct. 5, 2005 CSc296Q Network Security Page 9
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)
Oct. 5, 2005 CSc296Q Network Security Page 10
Compression
applied after the signature applied before encryption
compression reduces redundancy makes cryptanalysis harder
supported algorithm: ZIP
Oct. 5, 2005 CSc296Q Network Security Page 12
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
Oct. 5, 2005 CSc296Q Network Security Page 14
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
Oct. 5, 2005 CSc296Q Network Security Page 15
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.
Oct. 5, 2005 CSc296Q Network Security Page 16
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
Oct. 5, 2005 CSc296Q Network Security Page 17
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
Oct. 5, 2005 CSc296Q Network Security Page 18
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
Oct. 5, 2005 CSc296Q Network Security Page 19
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
Oct. 5, 2005 CSc296Q Network Security Page 21
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, …
Oct. 5, 2005 CSc296Q Network Security Page 22
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
Oct. 5, 2005 CSc296Q Network Security Page 23
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
Oct. 5, 2005 CSc296Q Network Security Page 25
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
Oct. 5, 2005 CSc296Q Network Security Page 26
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) ?
Oct. 5, 2005 CSc296Q Network Security Page 28
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
Oct. 5, 2005 CSc296Q Network Security Page 29
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
Oct. 5, 2005 CSc296Q Network Security Page 30
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)
Oct. 5, 2005 CSc296Q Network Security Page 31
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.
Oct. 5, 2005 CSc296Q Network Security Page 32
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
Oct. 5, 2005 CSc296Q Network Security Page 33
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.
Oct. 5, 2005 CSc296Q Network Security Page 34
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
Oct. 5, 2005 CSc296Q Network Security Page 35
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
Oct. 5, 2005 CSc296Q Network Security Page 36
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
Oct. 5, 2005 CSc296Q Network Security Page 37
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: ||
Oct. 5, 2005 CSc296Q Network Security Page 38
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
Oct. 5, 2005 CSc296Q Network Security Page 39
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.
Oct. 5, 2005 CSc296Q Network Security Page 40
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
Oct. 5, 2005 CSc296Q Network Security Page 41
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.
Oct. 5, 2005 CSc296Q Network Security Page 42
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.
Oct. 5, 2005 CSc296Q Network Security Page 43
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.
Oct. 5, 2005 CSc296Q Network Security Page 44
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
Oct. 5, 2005 CSc296Q Network Security Page 45
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
Oct. 5, 2005 CSc296Q Network Security Page 47
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
Oct. 5, 2005 CSc296Q Network Security Page 48
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
Oct. 5, 2005 CSc296Q Network Security Page 49
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
Oct. 5, 2005 CSc296Q Network Security Page 50
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
Oct. 5, 2005 CSc296Q Network Security Page 51
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
Oct. 5, 2005 CSc296Q Network Security Page 52
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
Oct. 5, 2005 CSc296Q Network Security Page 53
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