Transcript CS 155 May 26, 2005 Security Protocols John Mitchell Topics  Application layer protocols (review) • Kerberos, SSL/TLS  Network layer security • IPsec Some details: key management.

CS 155
May 26, 2005
Security Protocols
John Mitchell
Topics
 Application layer protocols (review)
• Kerberos, SSL/TLS
 Network layer security
• IPsec
Some details: key management techniques
• 802.11
• Mobility
 Secure network infrastructure
• DNSsec
• Sender authentication for spam prevention
–
–
–
–
Sender Policy Framework (SPF)
Domain Keys
Secure ID
S/MIME
Kerberos Protocol
Kc
KDC
Ktgs
{C}Kt S {C,
Kt}Ktgs
Ticket
1
Client
{Ks}Kt
Ticket
2
{C,
Ks}Kv
TGS
Kv
Service
TLS protocol layer over TCP/IP
http
telnet
ftp
Application
SSL/TLS
Transport
Internet
(TCP)
(IP)
Network interface
Physical layer
nntp
SSL/TLS
ClientHello
ServerHello,
[Certificate],
[ServerKeyExchange],
[CertificateRequest],
ServerHelloDone
C
[Certificate],
ClientKeyExchange,
[CertificateVerify]
switch to negotiated cipher
Finished
switch to negotiated cipher
Finished
S
Two useful ideas
 Authentication using certificate authority (CA)
• CA has “widely known” verification key
– Examples: Verisign, AT&T, MCI, Keywitness Corp Canada
• CA supplies signed certificate with site’s public key
 Integrity based on hashing
• Client, server communicate
Client
Hi
Hello
How are you?
• Compare hash of all messages
– Compute hash(hi,hello,howareyou?) locally
– Exchange hash values under encryption
• Abort if intervention detected
Server
Handshake Protocol
ClientHello
CS
C, VerC, SuiteC, NC
ServerHello
SC
VerS, SuiteS, NS, signCA{ S, KS }
ClientVerify
CS
signCA{ C, VC }
{ VerC, SecretC } K
S
signC { Hash( Master(NC, NS, SecretC) + Pad2 +
Hash(Msgs + C + Master(NC, NS, SecretC) + Pad1)) }
(Change to negotiated cipher)
ServerFinished S  C { Hash( Master(NC, NS, SecretC) + Pad2 +
Hash( Msgs + S + Master(NC, NS, SecretC) + Pad1))
} Master(NC, NS, SecretC)
ClientFinished C  S
{ Hash( Master(NC, NS, SecretC) + Pad2 +
Hash( Msgs + C + Master(NC, NS, SecretC) + Pad1))
} Master(NC, NS, SecretC)
Topics
 Application layer protocols (review)
• Kerberos, SSL/TLS
 Network layer security
• IPsec
Some details: key management techniques
• 802.11
• Mobility
 Secure network infrastructure
• DNSsec
• Sender authentication for spam prevention
–
–
–
–
Sender Policy Framework (SPF)
Domain Keys
Secure ID
S/MIME
IP-level security (IPSec)
Encrypt and authenticate traffic at the IP level
Three security functions
• Authentication
• Confidentiality
• Key management
Advantages over application layer (TLS)
• Implemented at gateway, not desktop
• Transparent to application programs and users
• Data can be sent unencrypted in LAN to avoid
encryption overhead
Network level protocol
Application data
abcdefghi
abc
TCP
TCP
abc
TCP
abc
def
TCP
ghi
def
TCP
ghi
IP
IPSec
IP
IP
IPSec TCP
uvw
IP
IP
TCP
IPSec TCP
def
xyz
IP
IP
TCP
IPSec TCP
ghi
lmn
IP Security usage scenarios
IPSec overview
Security Association (SA) specifies parameters
from the sender to the receiver
• SPI: Security parameters index
• IP: the receiver’s IP address, which is the address
of a user/firewall/router/gateway
• Security protocol identifier
– AH: authentication header for authentication service only
– ESP: encapsulated security payload using encryption
– ESP with authentication: as ESP, with authentication
Transport and tunnel modes
Transport mode
• Protect only the data payload of an IP packet
• Used for end-to-end encryption between two hosts
(client/server)
Tunnel mode
• Protection for the entire IP packet (incl IP address)
• Used for firewall/secure router  firewall/secure
router
IKE: Many modes
Main mode
•
•
•
•
Authentication by pre-shared keys
Auth with digital signatures
Auth with public-key encryption
Auth with revised public-key encryption
Quick mode
• Compress number of messages
• Also four authentication options
Aug 2001 Position Statement
 In the several years since the standardization of the IPSEC
protocols (ESP, AH, and ISAKMP/IKE), … several security
problems…, most notably IKE.
 Formal and semi-formal analyses by Meadows, Schneier et al,
and Simpson, have shown … security problems in IKE stem
directly from its complexity.
 It seems … only a matter of time before serious
*implementation* problems become apparent, again due to the
complex nature of the protocol, and the complex implementation
that must surely follow.
 The Security Area Directors have asked the IPSEC working group
to come up with a replacement for IKE.
Topics
 Application layer protocols (review)
• Kerberos, SSL/TLS
 Network layer security
• IPsec
Some details: key management techniques
• 802.11
• Mobility
 Secure network infrastructure
• DNSsec
• Sender authentication for spam prevention
–
–
–
–
Sender Policy Framework (SPF)
Domain Keys
Secure ID
S/MIME
Some protocol details, for fun
Protocols that produce shared keys are
• Short, typically a few simple messages
• Rely on cryptographic primitives for authentication
and secrecy
• Subtle and prone to error
Next few slides
• We’ll look at some example issues in design of key
management protocols, including use of crypto
• This is tricky, but can be lots of fun
Needham-Schroeder Protocol
{ A, NonceA }
A
Kb
{ NonceA, NonceB }
{ NonceB}
K
a
B
Kb
Result: A and B share two private numbers
not known to any observer without Ka-1, Kb-1
Anomaly in Needham-Schroeder
[Lowe]
{ A, Na } Ke
A
E
{ Na, Nb } Ka
{ Nb } Ke
Evil agent E tricks
honest A into revealing
private key Nb from B.
Evil E can then fool B.
{ Na, Nb }
{ A, Na }
Ka
B
Kb
Needham-Schroeder Lowe
{ A, NonceA }
A
Kb
{ NonceA, B, NonceB }
{ NonceB}
Kb
Authentication?
Secrecy?
Replay attack
Forward secrecy?
Denial of service?
Identity protection?
Ka
B
STS Family
STS0
cookie
STS0H
distribute
certificates
open
responder
STSa
STSaH
JFK0
STSH
JFK1
STSPH
JFKi
m=gx, n=gy
k=gxy
STS
protect
identities
STSP
symmetric
hash
JFKr
Properties:
 Certificates from CA
ab
 Shared secret: g
 Identity protection
 DoS protection
 Reverse ID protection
Example
Construct protocol with properties:
•
•
•
•
Shared secret
Authenticated
Identity Protection
DoS Protection
Design requirements for IKE, JFK, IKEv2
(IPSec key exchange protocol)
Component 1
Diffie-Hellman
A  B: ga
B  A: gb
• Shared secret (with someone)
– A deduces:
Knows(Y, gab)  (Y = A) ۷ Knows(Y,b)
• Authenticated
• Identity Protection
• DoS Protection
Component 2
Challenge Response:
A  B: m, A
B  A: n, sigB {m, n, A}
A  B: sigA {m, n, B}
• Shared secret (with someone)
• Authenticated
– A deduces: Received (B, msg1) Λ Sent (B, msg2)
• Identity Protection
• DoS Protection
Composition
ISO 9798-3 protocol:
A  B: ga, A
B  A: gb, sigB {ga, gb, A}
A  B: sigA {ga, gb, B}
•
•
•
•
Shared secret: gab
Authenticated
Identity Protection
DoS Protection
m := ga
n := gb
Refinement
Encrypt signatures:
A  B: ga, A
B  A: gb, EK {sigB {ga, gb, A}}
A  B: EK {sigA {ga, gb, B}}
•
•
•
•
Shared secret: gab
Authenticated
Identity Protection
DoS Protection
Transformation
Use cookie: JFK core protocol
A  B: ga, A
B  A: gb, hashKB {gb, ga}
A  B: ga, gb, hashKB {gb, ga}
EK {sigA {ga, gb, B}}
B  A: gb, EK {sigB {ga, gb, A}}
•
•
•
•
Shared secret: gab
Authenticated
Identity Protection
DoS Protection
(Here B must store b in step 2, but can fix this later…)
Cookie transformation
Typical protocol
• Client sends request to server
• Server sets up connection, responds
• Client may complete session or not (DOS)
Cookie version
• Client sends request to server
• Server sends hashed data back
– Send message #2 later after client confirms
• Client confirms by returning hashed data
• Need extra step to send postponed message
Cookie in JFK
Protocol susceptible to DoS
eh1
A  B: ga, A
B  A: gb, EK {sigB {ga, gb, A}}
A  B: EK {sigA {ga, gb, B}}
eh2
Use cookie: JFK core protocol
A
B
A
B




B:
A:
B:
A:
g a, A
gb, hashKB {gb, ga}
ga, gb, hashKB {gb, ga}, eh2
gb, eh1
Efficiency: Reuse D-H key
Costly to compute ga, gb, gab
Solution
• Keep medium-term ga, gb
(change ~10 min)
• Replace ga by pair ga, nonce
JFKi, JFKr protocols (except cert or grpinfo, …)
A  B: Na, ga, A
B  A: Nb, gb, hashKB {Nb, Na, gb, ga}
A  B: Na, Nb, ga, gb, hashKB {Nb, Na, gb, ga},
EK {sigA {Na, Nb, ga, gb, B}}
B  A: gb, EK {sigB {Na, Nb, ga, gb, A}}
Note: B does not need to store any short-term data in step 2
Topics
 Application layer protocols (review)
• Kerberos, SSL/TLS
 Network layer security
• IPsec
Some details: key management techniques
• 802.11
• Mobility
 Secure network infrastructure
• DNSsec
• Sender authentication for spam prevention
–
–
–
–
Sender Policy Framework (SPF)
Domain Keys
Secure ID
S/MIME
802.11i Wireless link-layer protocol
Wireless
Access Point
Radius Server
Ethernet
Laptop computer
(1) MAC Disabled, Port Blocked
802.11 Association
(2) MAC Enabled, Port Blocked
802.11x Authentication
(3) MAC Enabled, Port Blocked, PMK generated in STA and AS
AS move PMK to AP
4-way Key management
(4) MAC Enabled, Port Allowed, PTK := KCK|KEK|TK
Secure Communication
Mobile IPv6 Architecture
Mobile Node (MN)
IPv6
Direct connection via
binding update
Corresponding Node (CN)
Home Agent (HA)
 Authentication is a
requirement
 Early proposals weak
Topics
 Application layer protocols (review)
• Kerberos, SSL/TLS
 Network layer security
• IPsec
Some details: key management techniques
• 802.11
• Mobility
 Secure network infrastructure
• DNSsec
• Sender authentication for spam prevention
–
–
–
–
Sender Policy Framework (SPF)
Domain Keys
Secure ID
S/MIME
Recall: DNS address resolution
Question: www.cnn.com
.
www.cnn.com A ?
dns.cs.umass.edu
lab.cs.umass.edu
stub
resolver
ask .com server
the ip address of .com server
www.cnn.com A ?
xxx.xxx.xxx.xxx
resolver
www.cnn.com A ?
.com
ask cnn.com server
the ip address of cnn.com server
add to cache
www.cnn.com A ?
xxx.xxx.xxx.xxx
www.cnn.com
cnn.com
DNS Data flow
Zone administrator
Zone file
master
Dynamic
updates
slaves
resolver
stub resolver
DNS Vulnerabilities
Cache impersonation
Corrupting data
Impersonating master
Zone
administrator
Zone file
master
Dynamic
updates
slaves
resolver
stub resolver
Unauthorized updates
Server
Protection
Cache pollution by
Data spoofing
Data
Protection
DNSSEC
 Goals
• Authenticate servers and requests
• Integrity against data spoofing and corruption
 PK-DNSSEC (Public Key)
• DNS server signs hash of resource record set
• PKI based on DNS hierarchy: only root key must be distributed out
of band
 SK-DNSSEC (Symmetric Certificates)
•
•
•
•
Combine encryption and MAC, roughly Ek(m, MAC(m))
Each message contains a nonce to avoid replay attack
Each DNS node shares a key with its parent, called master key
The root domain has an asymmetric key pair
 Hybrid approach
• The root servers use PK-DNSSEC
• The top-level domains use SK-DNSSEC
Augment DNS for SPAM detection
SPF is most successful so far; advocated by AOL, available as open source
Domain Keys
SPF
Microsoft Sender ID
S/MIME Signatures
Anti-Spam Summary
 Domain keys: PKI based on DNS hierarchy
• Server makes public key available via DNS
• Outgoing server signs message
• Inbound mail servers check signatures
 SPF
• Concise text records stored in DNS designate which servers send
email from a domain, using IP address ranges, or established mail
exchange (MX) records.
 Caller ID
• Uses XML records stored in DNS, which list the IP address ranges
that send e-mails legitimately from a particular domain.
 Sender ID:
• The convergence of Microsoft's Caller ID for E-Mail proposal and
Meng Wong's SPF. Microsoft has submitted this to the IETF.
 S/MIME
• Public-key signatures using separate PKI
Topics
 Application layer protocols (review)
• Kerberos, SSL/TLS
 Network layer security
• IPsec
Some details: key management techniques
• 802.11
• Mobility
 Secure network infrastructure
• DNSsec
• Sender authentication for spam prevention
–
–
–
–
Sender Policy Framework (SPF)
Domain Keys
Secure ID
S/MIME