15-441 Computer Networking

Lecture 4 – Applications
DNS, SSL
Outline

• Security: Cryptography Introduction

• Security: Authentication

• Security: Key Distribution

• DNS

Lecture 4: 09-09-2002 2
What is Network Security?

• Confidentiality: only sender, intended receiver should

“understand” message contents
• Sender encrypts message

• Receiver decrypts message

• Authentication: sender, receiver want to confirm identity of

each other
• Message Integrity: sender, receiver want to ensure
message not altered (in transit, or afterwards) without
detection
• Access and Availability: services must be accessible and
available to users

Lecture 4: 09-09-2002 3
Friends and Enemies: Alice, Bob,
Trudy
• Well-known in network security world
• Bob & Alice want to communicate “securely”
• Trudy (intruder) may intercept, delete, add messages
Alice Bob
channel data, control
messages

data secure secure data

sender receiver

Trudy

Lecture 4: 09-09-2002 4
Who might Bob, Alice be?

• … well, real-life Bobs and Alices!

• Web browser/server for electronic transactions
(e.g., on-line purchases)
• On-line banking client/server
• DNS servers
• Routers exchanging routing table updates
• Other examples?

Lecture 4: 09-09-2002 5
There are bad Guys (and Girls) Out
There!
Q: What can a “bad guy” do?
A: A lot!
• Eavesdrop: intercept messages
• Actively insert messages into connection

• Impersonation: can fake (spoof) source address in

packet (or any field in packet)

• Hijacking: “take over” ongoing connection by

removing sender or receiver, inserting himself in

place
• Denial of service: prevent service from being used

by others (e.g., by overloading resources)

more on this later ……

Lecture 4: 09-09-2002 6
The Language of Cryptography

Alice’s Bob’s
KA encryption KB decryption
key key

plaintext encryption ciphertext decryption plaintext

algorithm algorithm

Symmetric key crypto: sender, receiver keys identical

Public-key crypto: encryption key public, decryption key
secret (private)

Lecture 4: 09-09-2002 7
Symmetric Key Cryptography

Substitution cipher: substituting one thing for another

• monoalphabetic cipher: substitute one letter for another

plaintext: abcdefghijklmnopqrstuvwxyz

ciphertext: mnbvcxzasdfghjklpoiuytrewq

E.g.: Plaintext: bob. i love you. alice

ciphertext: nkn. s gktc wky. mgsbc

Q: How hard to break this simple cipher?:

 Brute force (how hard?)
 Other?

Lecture 4: 09-09-2002 8
Symmetric Key Cryptography

KA-B
KA-B

plaintext encryption ciphertext decryption plaintext

message, m algorithm algorithm
KA-B (m) m = KA-B(KA-B (m))

Symmetric key crypto: Bob and Alice both know same

(symmetric) key: KA-B
• e.g., key is knowing substitution pattern in mono
alphabetic substitution cipher
• Q: How do Bob and Alice agree on key value?

Lecture 4: 09-09-2002 9
Public Key Cryptography

Symmetric Key Crypto Public Key Cryptography

• Requires sender, • Radically different
receiver know shared approach [Diffie-
secret key Hellman76, RSA78]
• Q: How to agree on key • Sender, receiver do
in first place not share secret key
(particularly if never • Public encryption key
“met”)? known to all
• Private decryption key
known only to receiver

Lecture 4: 09-09-2002 10
Public Key Cryptography

K+B Bob’s public

key
-
KB Bob’s private
key

plaintext encryption ciphertext decryption plaintext

message, m algorithm + algorithm message
KB (m) - +
m = KB (KB (m))

Lecture 4: 09-09-2002 11
Public Key Encryption Algorithms

Requirements:
+ -
1 Need KB( ) and KB ( ) such that
-
KB (KB+ (m)) = m

Given public key KB , it should be+impossible to compute

2 private key KB

RSA: Rivest, Shamir, Adelson algorithm

Lecture 4: 09-09-2002 12
RSA: Another Important Property

The following property will be very useful later:

- + + -
KB(KB(m)) = m = KB (KB(m))

Use public key Use private key

first, followed by first, followed by
private key public key

Result is the same!

Lecture 4: 09-09-2002 13
Outline

• Security: Cryptography Introduction

• Security: Authentication

• Security: Key Distribution

• DNS

Lecture 4: 09-09-2002 14
Authentication

“The Doors of Durin, Lord of Moria. Speak, friend,

and enter.”
- Words on the gate to Moria

Password?  Mellon (Elvish for friend)

“Too simple for a learned lore master in these

suspicious days. Those were happier times.”
- Gandalf

Lecture 4: 09-09-2002 15
Authentication

Goal: Bob wants Alice to “prove” her identity to him

Protocol ap1.0: Alice says “I am Alice”

In a network,
Bob can not “see” Alice,
so Trudy simply
“I am Alice” declares
herself to be Alice

Lecture 4: 09-09-2002 16
Authentication: Another Try

Protocol ap2.0: Alice says “I am Alice” in an IP packet

containing her source IP address

Alice’s
IP address
“I am Alice”

Failure scenario??

Lecture 4: 09-09-2002 17
Authentication: Another Try

Protocol ap2.0: Alice says “I am Alice” in an IP packet

containing her source IP address

Trudy can create

a packet “spoofing”
Alice’s address

Alice’s
IP address
“I am Alice”

Lecture 4: 09-09-2002 18
Authentication: Another Try

Protocol ap3.0: Alice says “I am Alice” and sends her

secret password to “prove” it.

Alice’s Alice’s
“I’m Alice”
IP addr password

Alice’s Failure scenario??

OK
IP addr

Lecture 4: 09-09-2002 19
Authentication: Another Try

Protocol ap3.0: Alice says “I am Alice” and sends her

secret password to “prove” it.

Alice’s Alice’s
“I’m Alice”
IP addr password
Playback attack: Trudy
Alice’s records Alice’s packet
OK
IP addr and later
plays it back to Bob

Alice’s Alice’s
“I’m Alice”
IP addr password

Lecture 4: 09-09-2002 20
Authentication: Yet Another Try

Protocol ap3.1: Alice says “I am Alice” and sends her

encrypted secret password to “prove” it.

Alice’s encrypted
“I’m Alice”
IP addr password

Alice’s Failure scenario??

OK
IP addr

Lecture 4: 09-09-2002 21
Authentication: Another Try

Protocol ap3.1: Alice says “I am Alice” and sends her

encrypted secret password to “prove” it.

Alice’s encrypted
“I’m Alice” Record
IP addr password
and
Alice’s
OK playback
IP addr
still works!

Alice’s encrypted
“I’m Alice”
IP addr password

Lecture 4: 09-09-2002 22
Authentication: Yet Another Try

Goal: avoid playback attack

Nonce: number (R) used only once-in-a-lifetime
ap4.0: to prove Alice “live”, Bob sends Alice nonce, R. Alice
must return R, encrypted with shared secret key

“I am Alice”

R
KA-B(R) Alice is live, and
only Alice knows
key to encrypt
nonce, so it must
Failures, drawbacks? be Alice!

Lecture 4: 09-09-2002 23
Authentication: ap5.0

ap4.0 requires shared symmetric key

• Can we authenticate using public key techniques?
ap5.0: use nonce, public key cryptography

“I am Alice”
Bob computes
R + -
- KA(KA(R)) = R
KA(R)
and knows only Alice
“send me your public key”
could have the private
key, that encrypted R
KA+ such that
+ -
KA(KA(R)) = R

Lecture 4: 09-09-2002 24
ap5.0: Security Hole

ap5.0 only as “secure” as the

distribution of public keys

“I am Alice”
Bob computes
R + -
- KT(KT(R)) = R
KT (R)
and authenticates
“send me your public key” Trudy
+
KT

Lecture 4: 09-09-2002 25
Outline

• Security: Cryptography Introduction

• Security: Authentication

• Security: Key Distribution

• DNS

Lecture 4: 09-09-2002 26
Trusted Intermediaries

Symmetric key problem: Public key problem:

• How do two entities • When Alice obtains Bob’s
establish shared secret key public key (from web site,
over network? e-mail, diskette), how
Solution: does she know it is Bob’s
public key, not Trudy’s?
• Trusted key distribution
center (KDC) acting as Solution:
intermediary between • Trusted certification
entities authority (CA)

Lecture 4: 09-09-2002 27
Key Distribution Center (KDC)

• Alice, Bob need shared symmetric key.

• KDC: server shares different secret key with each
registered user (many users)
• Alice, Bob know own symmetric keys, KA-KDC KB-KDC , for
communicating with KDC.
KDC

KA-KDC KP-KDC
KX-KDC
KP-KDC KB-KDC
KY-KDC

KZ-KDC
KA-KDC KB-KDC

Lecture 4: 09-09-2002 28
Key Distribution Center (KDC)

Q: How does KDC allow Bob, Alice to determine shared

symmetric secret key to communicate with each other?
KDC
generates
KA-KDC(A,B)
R1

Alice KA-KDC(R1, KB-KDC(A,R1) ) Bob knows to

knows use R1 to
R1 KB-KDC(A,R1) communicate
with Alice

Alice and Bob communicate: using R1 as

session key for shared symmetric encryption

Lecture 4: 09-09-2002 29
Certification Authorities

• Certification authority (CA): binds public key to

particular entity, E.
• E (person, router) registers its public key with CA.
• E provides “proof of identity” to CA.
• CA creates certificate binding E to its public key.
• Certificate containing E’s public key digitally signed by CA –
CA says “this is E’s public key”

Bob’s digital +
public signature KB
+
key KB (encrypt)
CA
certificate for
K-
Bob’s private
identifying key CA Bob’s public key,
information signed by CA

Lecture 4: 09-09-2002 30
Certification Authorities

• When Alice wants Bob’s public key:

• Gets Bob’s certificate (Bob or elsewhere).
• Apply CA’s public key to Bob’s certificate,
get Bob’s public key
+ digital Bob’s
KB signature public
+
(decrypt) KB key

CA
public +
KCA
key

Lecture 4: 09-09-2002 31
Certificate Contents
• Serial number (unique to issuer)
• info about certificate owner, including algorithm and
key value itself (not shown) • Info about certificate
issuer
• Valid dates
• Digital signature by
issuer

Lecture 4: 09-09-2002 32
Secure Sockets Layer (SSL)

• Transport layer security • Server authentication:

to any TCP-based app • SSL-enabled browser
includes public keys for
using SSL services. trusted CAs.
• Used between Web • Browser requests server
browsers, servers for e- certificate, issued by trusted
CA.
commerce (shttp). • Browser uses CA’s public
• Security services: key to extract server’s public
• Server authentication key from certificate.
• Data encryption • Check your browser’s
• Client authentication security menu to see its
(optional) trusted CAs.

Lecture 4: 09-09-2002 33
SSL (continued)

Encrypted SSL session: • SSL: basis of IETF

• Browser generates Transport Layer
symmetric session key, Security (TLS).
encrypts it with server’s • SSL can be used for
public key, sends encrypted non-Web applications,
key to server. e.g., IMAP.
• Using private key, server • Client authentication
decrypts session key. can be done with client
• Browser, server know certificates.
session key
• All data sent into TCP socket
(by client or server) encrypted
with session key.

Lecture 4: 09-09-2002 34
Network Security (Summary)

• Cryptography (symmetric and public)

• Basic techniques & tradeoffs
• Authentication
• Common styles of attack
• Key distribution
• Why needed
…. used in many different security scenarios
• secure email, secure transport (SSL), IP sec, 802.11
WEP

Lecture 4: 09-09-2002 35
Outline

• Security: Cryptography Introduction

• Security: Authentication

• Security: Key Distribution

• DNS

Lecture 4: 09-09-2002 36
Naming

• How do we efficiently locate resources?

• DNS: name  IP address
• Service location: description  host
• Other issues
• How do we scale these to the wide area?
• How to choose among similar services?

Lecture 4: 09-09-2002 37
Obvious Solutions (1)

Why not centralize DNS?

• Single point of failure
• Traffic volume
• Distant centralized database
• Single point of update

• Doesn’t scale!

Lecture 4: 09-09-2002 38
Obvious Solutions (2)

Why not use /etc/hosts?

• Original Name to Address Mapping
• Flat namespace
• /etc/hosts
• SRI kept main copy
• Downloaded regularly
• Count of hosts was increasing: machine per
domain  machine per user
• Many more downloads
• Many more updates

Lecture 4: 09-09-2002 39
Domain Name System Goals

• Basically building a wide area distributed

database
• Scalability
• Decentralized maintenance
• Robustness
• Global scope
• Names mean the same thing everywhere
• Don’t need
• Atomicity
• Strong consistency

Lecture 4: 09-09-2002 40
DNS Records

RR format: (class, name, value, type, ttl)

• DB contains tuples called resource records (RRs)
• Classes = Internet (IN), Chaosnet (CH), etc.
• Each class defines value associated with type

FOR IN class:
• Type=A • Type=CNAME
• name is hostname • name is an alias name for some
“canonical” (the real) name
• value is IP address
• value is canonical name
• Type=NS
• Type=MX
• name is domain (e.g. foo.com) • value is hostname of mailserver
• value is name of authoritative associated with name
name server for this domain

Lecture 4: 09-09-2002 41
Hierarchical Name Space

• Administrative hierarchy
barracuda.cmcl.cs.cmu.edu • “.” as separator
• Host name to address section
• Top-level domains  edu, gov, ca, us,
root etc.
org ca • Sub-domains = subtrees
net edu com uk • Human readable name = leaf  root path

gwu ucb cmu bu mit

cs ece
cmcl
barracuda

Lecture 4: 09-09-2002 42
DNS Design: Zone Definitions

• Zone = contiguous
section of name space
root
• E.g., Complete tree,
org ca
single node or subtree
net edu com uk • A zone has an associated
set of name servers
gwu ucb cmu bu mit
Subtree
cs ece
cmcl Single node
barracuda
Complete
Tree

Lecture 4: 09-09-2002 43
DNS Design: Cont.

• Zones are created by convincing owner node to

create/delegate a subzone
• Records within zone stored multiple redundant name
servers
• Primary/master name server updated manually
• Secondary/redundant servers updated by zone transfer
of name space
• Zone transfer is a bulk transfer of the “configuration” of a DNS
server – uses TCP to ensure reliability
• Example:
• CS.CMU.EDU created by CMU.EDU administrators

Lecture 4: 09-09-2002 44
Servers/Resolvers

• Each host has a resolver

• Typically a library that applications can link to
• Local name servers hand-configured (e.g.
/etc/resolv.conf)
• Name servers
• Either responsible for some zone or…
• Local servers
• Do lookup of distant host names for local hosts
• Typically answer queries about local zone

Lecture 4: 09-09-2002 45
DNS: Root Name Servers

• Responsible for
“root” zone
• Approx. dozen root
name servers
worldwide
• Currently {a-m}.root-
servers.net
• Local name servers
contact root servers
when they cannot
resolve a name
• Configured with well-
known root servers

Lecture 4: 09-09-2002 46
Next Lecture

• How DNS resolves names

• How well does DNS work today

• HTTP intro and details

Lecture 4: 09-09-2002 47