Date post: | 21-Dec-2015 |
Category: |
Documents |
View: | 215 times |
Download: | 0 times |
Security Protocols
John Mitchell
CS 155 May 26, 2005
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
Ticket 2
Ticket 2
Ticket 1
Ticket 1
Kerberos Protocol
Client
KDC
Service
TGS
{Kt}Kc
C TGS
{Ks}Kt
{C}Kt S
{C}Ks
Ktgs
Kc
Kv
{C, Ks}Kv
{C, Kt}Ktgs
{C, Ks}Kv
{C, Kt}Ktgs
TLS protocol layer over TCP/IP
Network interface
Transport (TCP)
Physical layer
Internet (IP)
Applicationtelnet
http ftp
nntp
SSL/TLS
SSL/TLS
C
ClientHello
ServerHello, [Certificate],[ServerKeyExchange],[CertificateRequest],ServerHelloDone
S[Certificate],ClientKeyExchange,[CertificateVerify]
Finished
switch to negotiated cipher
Finished
switch to negotiated cipher
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
• Compare hash of all messages– Compute hash(hi,hello,howareyou?) locally– Exchange hash values under encryption
• Abort if intervention detected
Client ServerHi
HelloHow are you?
Handshake Protocol
ClientHello CS C, VerC, SuiteC, NC
ServerHello S C VerS, Suite, SuiteSS, N, NSS,, signCA{ S, KS, KSS }
ClientVerify C S signCA{ C, VC }
{ VerC, SecretC }
signC { Hash( Master(NC, NNSS, SecretC) + Pad2 + Hash(Msgs + C + Master(NC, NNSS, SecretC) + Pad1)) }
(Change to negotiated cipher)
ServerFinished S C { Hash( Master(NC, NNSS, SecretC) + Pad2 + Hash( Msgs + S + Master(NC, NNSS, SecretC) + Pad1)) }
ClientFinished C S { Hash( Master(NC, NNSS, SecretC) + Pad2 + Hash( Msgs + C + Master(NC, NNSS, SecretC) + Pad1)) }
KSS
Master(NC, NSS, SecretC)
Master(NC, NSS, 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
abcdefghi
abc def ghi
abcTCP defTCP ghiTCP
TCP
IP
abcTCPIP defTCPIP ghiTCPIP
Application data
uvwTCPIP IPSec xyzTCPIP IPSec lmnTCPIP IPSec
IPSec
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 }
{ NonceA, NonceB }
{ NonceB}
Ka
Kb
Result: A and B share two private numbers
not known to any observer without Ka-1, Kb-1
A B
Kb
Anomaly in Needham-Schroeder
A E
B
{ A, Na }
{ A, Na }{ Na, Nb }
{ Na, Nb }
{ Nb }
Ke
KbKa
Ka
Ke
Evil agent E trickshonest A into revealingprivate key Nb from B.
Evil E can then fool B.
[Lowe]
Needham-Schroeder Lowe
{ A, NonceA }
{ NonceA, B, NonceB }
{ NonceB}
Ka
Kb
A BKb
Authentication?Secrecy?Replay attackForward secrecy?Denial of service?Identity protection?
STS Family
m=gx, n=gy
k=gxy
STS0H
STSa STSaH
STSHSTS
STS0
STSPH
JFK1
distributecertificates
cookie
openresponder
JFK0
symmetrichash
JFKi
protect identities
JFKr
STSP
Properties: Certificates from CA Shared secret: gab
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 protocolA 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 A B: ga, A B A: gb, EK {sigB {ga, gb, A}}
A B: EK {sigA {ga, gb, B}}
Use cookie: JFK core protocolA B: ga, A
B A: gb, hashKB {gb, ga}
A B: ga, gb, hashKB {gb, ga}, eh2
B A: gb, eh1
eh1
eh2
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
Ethernet
Access Point
Radius ServerLaptop computer
Wireless
4-way Key management
802.11 Association
802.11x Authentication
(1 )MAC Disabled, Port Blocked
(2 )MAC Enabled, Port Blocked
(3 )MAC Enabled, Port Blocked, PMK generated in STA and AS
AS move PMK to AP
Secure Communication
(4 )MAC Enabled, Port Allowed, PTK := KCK|KEK|TK
Mobile IPv6 Architecture
IPv6
Mobile Node (MN)
Corresponding Node (CN)
Home Agent (HA)
Direct connection via binding update
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
stub resolver
Question: www.cnn.com
www.cnn.com A ?
resolver
. www.cnn.com A ?
ask .com server the ip address of .com server
.comwww.cnn.com A ?
ask cnn.com serverthe ip address of cnn.com server
cnn.com
www.cnn.com A ?
xxx.xxx.xxx.xxx
xxx.xxx.xxx.xxx
add to cache
www.cnn.com
lab.cs.umass.edudns.cs.umass.edu
DNS Data flow
master resolver
stub resolver
Zone administrator
Zone file
slavesDynamicupdates
DataProtectionServer
Protection
DNS Vulnerabilities
Zone file
slaves
master resolver
stub resolver
Zone administrator
Dynamicupdates
Cache pollution byData spoofingUnauthorized updates
Corrupting data Impersonating master
Cache impersonation
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