Security Protocols John Mitchell CS 155May 26, 2005.

transcript

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 1

Kerberos Protocol

Client

Service

{Kt}Kc

{Ks}Kt

{C}Kt S

{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

SSL/TLS

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)) }

Master(NC, NSS, SecretC)

Topics

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

abcTCPIP defTCPIP ghiTCPIP

Application data

uvwTCPIP IPSec xyzTCPIP IPSec lmnTCPIP 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

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}

Result: A and B share two private numbers

not known to any observer without Ka-1, Kb-1

Anomaly in Needham-Schroeder

{ A, Na }

{ A, Na }{ Na, Nb }

{ Na, Nb }

{ Nb }

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}

Authentication?Secrecy?Replay attackForward secrecy?Denial of service?Identity protection?

STS Family

m=gx, n=gy

STSa STSaH

STSHSTS

distributecertificates

cookie

openresponder

symmetrichash

protect identities

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}}

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}}

(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

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

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

Mobile Node (MN)

Corresponding Node (CN)

Home Agent (HA)

Direct connection via binding update

Authentication is a requirement

Early proposals weak

Topics

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

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

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

Security Protocols John Mitchell CS 155May 26, 2005.

Documents