Transcript Sheffer-sadna

Network Security Protocols
Yaron Sheffer, Check Point
March 2009
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
Agenda
 Proposed projects from 100K ft.
 Usage scenarios
 The big three
– SSL/TLS
– IPsec (and IKE)
– SSH
 User authentication
– EAP
– EKE
 Disclaimer: yes this is a lot; expect more width than
depth
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
2
Proposed Projects
1. Distinguish between encrypted and unencrypted IPsec
traffic and tell the network sniffer which is which
2. Enable password-based mutual authentication securely
3. Add flexible authentication into the SSL infrastructure


These are interesting programming challenges
And a unique opportunity to influence emerging Internet
standards
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
3
Network Security Protocols In Use
 Secure access to Web servers
– SSL to Amazon
 Virtual private networks (VPN)
 Remote access VPN
– VPN client on your laptop
 Access to network devices and Unix boxes
 General security infrastructure
– Still mostly an ideal
 We will discuss layer 3+4 protocols
– WEP/WPA etc. are used in layer 2
 We will only discuss unicast protocols
– Ran can tell you all about the other thing
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
4
Three Building Blocks
 Authentication
– Identifying one or both of the parties with cryptographic assurance
– Passwords, shared secrets, certificates…
– This could have been easy if it weren’t for humans
 Key management
– Key agreement, key renewal (re-key)…
– Requires some form of authentication (there are exceptions here)
– This is hard, formal proofs help
 Transport security
– Ensuring confidentiality and/or message and sender integrity, given a
strong key
– This really is quite easy, most discussion is around performance
 The three are often mixed, IPsec with IKEv2 has the cleanest
architectural layering
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
5
SSL/TLS
 Secure Socket Layer and Transport Level Security
– The same protocol, for all practical purposes




Initially defined by Netscape, 1995
Now being developed by the IETF TLS working group
Layer 4 security (“socket”), so very easy to implement
Session resumption is critical
– The “session” is per connection
– And HTTP 1.0 connections are very short
 The protocol is always end-to-end
– As opposed to IPsec, where you have gateways
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
6
SSL Layers
 The handshake protocol, just like your data, is layered
on top of a simple record protocol
 And the whole thing runs on top of TCP
– And then there’s Datagram TLS (DTLS), too
Apache HTTP Server Documentation: SSL/TLS Strong Encryption: An Introduction
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
7
SSL Handshake Steps
 Exchange “hello” messages to agree on algorithms,
exchange random values, and check for session
resumption
 Exchange cryptographic parameters to allow the
client and server to agree on a premaster secret
 Exchange certificates and cryptographic information to
allow the client and server to authenticate themselves
 Generate a master secret from the premaster secret
and exchanged random values
 Provide security parameters to the record layer
 Allow the client and server to verify that their peer has
calculated the same security parameters and that the
handshake occurred without tampering by an attacker
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
8
SSL Handshake (One Way Auth)
From Computer Desktop Encyclopedia
© 2005 The Computer Language Co. Inc.
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
9
Authentication in SSL/TLS




One way certificate based
Mutual, certificate based
Preshared key (RFC 4279)
But in reality, we all know what it is:
– Server presents a (weak) certificate
– And a clear password goes in the tunnel
 We could separate out the authentication component,
and use a general authentication framework
– TLS-EAP, draft-nir-tls-eap
– More about this project later
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
10
IPsec
 IPsec was designed in the early 1990, published 1995
– Originated with the US government
– Managed by the IETF
 Revised and republished 2005: IKEv2
 Consists of:
– IKE for key exchange
– ESP (and historically AH) for protecting traffic
 Layer 3, and a more general/clean architecture
– Separate key exchange protocol
– Separate authentication protocol in IKEv2
 Not as popular as SSL, but still many implementations
– All mainstream operating systems
– Dedicated VPN devices
– Lots of others
 Can be deployed:
– Between endpoints
– Endpoint to gateway
– Or between gateways
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
11
Tunneling in ESP
 Security at the packet level
 IP traffic is tunneled between endpoints
– Or VPN gateways
 Encryption and/or integrity protection
– ESP-null: ESP with null encryption
 Note: there are other ESP variants
IP
ESP
IP
proto=50
Next=IP
proto=6
©2009 Check Point Software Technologies Ltd. All rights reserved.
TCP
Data
ESP
Trailer
[Unrestricted]—For everyone
12
ESP Traffic Visibility
 System administrators don’t like encryption, they want
to be able to see their network’s traffic
– Control freaks?
– They also have critical boxes that need to see the traffic:
load balancers, intrusion detection devices,
optimization/QOS
 No problem, use ESP only to authenticate the packets
– Known as ESP-null (ESP with null encryption)
 Given a packet, how do I know it is not encrypted?
 This is easy for a human!
 “Simple” heuristics to detect non-random packets
– draft-kivinen-ipsecme-esp-null-heuristics
 Or a protocol extension
– Just a little wrapper in front of the ESP header
– And well, you also need to change all the
implementations…
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
13
Traffic Visibility Project
 Detection of ESP-null can be used…
– To enforce some security policies
– As infrastructure for packet sniffers, IPS, load balancers etc.
 Proposal: add the heuristics to Wireshark
– The most popular network sniffer
– Recursively parse the inner protocol for internal traffic, without
requiring an encryption key
Linux with
Strongswan
©2009 Check Point Software Technologies Ltd. All rights reserved.
Heuristics
Wireshark
Linux or
Windows
Linux with
Strongswan
[Unrestricted]—For everyone
14
IKE
 Internet Key Exchange
 Almost mutual authentication
– Certificates for both sides
– Or a preshared secret
– Or EAP…
 Uses Diffie-Hellman to generate a shared secret
 And then authenticates both sides and the actual
protocol messages
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
15
IKEv2 Negotiation (Simplified)
Initiator
HDR
SA
Responder
KE
Nonce
HDR
HDR
IDi
AUTH
SA2
HDR
SA
KE
Nonce
AUTH
SA2
TS
TS
IDr
 The end result of this is an ESP security association
 Note: multiple exchanges added when using EAP…
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
16
SSH
 Replaces the legacy Unix “rlogin”
set of commands
 But provides much more than
shell access
– General (TCP) port forwarding
 Very common on Linux and
network devices (Cisco IOS)
 Commonly uses “leap of faith”
authentication
– Accept host key without check
when connecting the first time to
the server
– Save the host key in the local
database, and
– Check against the saved key on
all future connections to the same
server
©2009 Check Point Software Technologies Ltd. All rights reserved.
Linux Journal, The OpenSSH Protocol under the Hood
[Unrestricted]—For everyone
17
Security Protocol Comparison
SSL/TLS
IPsec
SSH
Implemented
at…
Application layer Transport layer
(TCP)
Primarily used
for…
E-commerce,
protection of
specific
protocols
(email)
Site to site VPN, Remote access
remote access
to specific
into networks
devices
Network
abstraction
Secure socket
(bump in the
stack)
IP tunneling,
gateways
©2009 Check Point Software Technologies Ltd. All rights reserved.
Application layer
Port forwarding
[Unrestricted]—For everyone
18
Authentication
 Identify yourself to another party
– Client-to-server or mutual
 With strong security guarantees
–
–
–
–
Against passive/active attacker
Eavesdropping
Dictionary attacks
Man in the middle
 Some basic templates:
–
–
–
–
Showing a password
Challenge-response
Certificate with proof of possession
Zero knowledge
 Centralized identity management
– RADIUS, for example
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
19
EAP
 Extensible Authentication Protocol (but really a sub-protocol)
 A standard way to:
– Separate the authenticator from the authentication server
– Support many different authentication methods
– Provide “channel binding” between the EAP layer and the higher level
protocol
 A simple multi-round exchange between the client (“supplicant”) and
the AS
– Transparent for the Authenticator!
 Always embedded within another protocol
–
–
–
–
IEEE 802.1X for wired LAN
IEEE 802.11i (WAP) for wireless LAN
IKEv2
TLS? (draft-nir-tls-eap)
Client/
Supplicant
EAP-xxx
WPA
©2009 Check Point Software Technologies Ltd. All rights reserved.
Authenticator,
e.g. Access
Point
EAP-xxx
RADIUS
Authentication
Server
[Unrestricted]—For everyone
20
TLS-EAP Project
 Integration points on client and on server side
 Test on simplest non-trivial EAP
– EAP-MSCHAPv2?
subset of
wpa_supplicant
or Open1X
OpenSSL or
GnuTLS
FreeRADIUS Client
OpenSSL or
GnuTLS
EAP Method
FreeRADIUS
Server
Linux
Linux
TLS/EAP
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
21
Zero Knowledge Authentication
 Use a short, memorable password
– 20 bits max…
 For strong mutual authentication
– In particular, resistant to dictionary attack
 Many solutions
 Rarely used, due to patent issues
 The first workable solution was EKE
– Encrypted Key Exchange, Bellovin and Merritt 1992
– No known vulnerabilities
– Also the first patent in this space, and the first to expire (2011)
 Once the patent expires, everybody can start using EKE
 And an EAP method is an easy way to do it
– draft-sheffer-emu-eap-eke
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
22
EAP-EKE Exchange
Authenticator
HDR
ID
Supplicant
Crypto
Proposals
HDR
HDR
E(password, gx)
HDR
HDR
ID
Crypto
Selection
Nonce
E(password, gy)
Nonce
Auth
HDR
©2009 Check Point Software Technologies Ltd. All rights reserved.
Nonce
Auth
[Unrestricted]—For everyone
23
EAP-EKE Project
 Several options, one option is depicted
–
–
–
–
FreeRADIUS supplicant and server
SecureW2 on Windows
StrongSwan plus FreeRADIUS
StrongSwan stand-alone
EAP-EKE
EAP-EKE
StrongSwan IKE
Client
StrongSwan IKE
Gateway
Credential
Database
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
24
Proposed Projects - Recap
1. Distinguish between encrypted and unencrypted traffic
and tell the network sniffer which is which
2. Enable password-based mutual authentication securely
3. Add flexible authentication into the SSL infrastructure


These are interesting programming challenges
And a unique opportunity to influence emerging Internet
standards
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone
25
Thank You!
Yaron Sheffer
[email protected]
©2009 Check Point Software Technologies Ltd. All rights reserved.
[Unrestricted]—For everyone