[Unrestricted]—For everyone ©2009 Check Point Software Technologies Ltd. All rights reserved. Network Security Protocols Yaron Sheffer, Check Point March

[Unrestricted]—For everyone©2009 Check Point Software Technologies Ltd. All rights reserved.

Network Security Protocols

Yaron Sheffer, Check Point

March 2009

2[Unrestricted]—For everyone

©2009 Check Point Software Technologies Ltd. All rights reserved.

AgendaAgenda

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



Proposed ProjectsProposed 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



Network Security Protocols In UseNetwork 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



Three Building BlocksThree 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



SSL/TLSSSL/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



SSL LayersSSL 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



SSL Handshake StepsSSL 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



SSL Handshake (One Way Auth)SSL Handshake (One Way Auth)

From Computer Desktop Encyclopedia

© 2005 The Computer Language Co. Inc.



Authentication in SSL/TLSAuthentication 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



IPsecIPsec

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



Tunneling in ESP

IPproto=6

TCPDataIP

proto=50ESPNext=IP

ESPTrailer

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



ESP Traffic VisibilityESP 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…



Traffic Visibility ProjectTraffic 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 withStrongswan

Linux withStrongswanWireshark

Linux orWindows

Heuristics



IKEIKE

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



IKEv2 Negotiation (Simplified)IKEv2 Negotiation (Simplified)

Initiator Responder

KEHDR SA Nonce

KEHDR SA Nonce

AUTHHDR IDi SA2 TS

AUTHHDR IDr SA2 TS

The end result of this is an ESP security association Note: multiple exchanges added when using EAP…



SSHSSH

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 Linux Journal, The OpenSSH Protocol under the Hood



Security Protocol ComparisonSecurity Protocol Comparison

SSL/TLS IPsec SSH

Implemented at…

Application layer (TCP)

Transport layer Application layer

Primarily used for…

E-commerce, protection of specific protocols (email)

Site to site VPN, remote access into networks

Remote access to specific devices

Network abstraction

Secure socket (bump in the stack)

IP tunneling, gateways

Port forwarding



AuthenticationAuthentication

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



EAPEAP

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

Authenticator,e.g. Access

Point

EAP-xxx

RADIUS

AuthenticationServer



TLS-EAP ProjectTLS-EAP Project

Integration points on client and on server side Test on simplest non-trivial EAP

– EAP-MSCHAPv2?

OpenSSL orGnuTLS

subset ofwpa_supplicant

or Open1X

OpenSSL orGnuTLS

FreeRADIUS Client

FreeRADIUSServer

Linux Linux

TLS/EAP

EAP Method



Zero Knowledge AuthenticationZero 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



EAP-EKE ExchangeEAP-EKE Exchange

Authenticator Supplicant

CryptoProposals

HDR ID

CryptoSelection

HDR ID

HDR E(password, gx)

HDR E(password, gy) Nonce

HDR

HDR

Nonce Auth

Nonce Auth



EAP-EKE ProjectEAP-EKE Project

Several options, one option is depicted– FreeRADIUS supplicant and server– SecureW2 on Windows– StrongSwan plus FreeRADIUS– StrongSwan stand-alone

StrongSwan IKEClient

StrongSwan IKEGateway

EAP-EKE EAP-EKE

CredentialDatabase



Proposed Projects - RecapProposed 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

[Unrestricted]—For everyone©2009 Check Point Software Technologies Ltd. All rights reserved.

Thank You!

Yaron Sheffer

[email protected]

Documents

[Unrestricted]—For everyone ©2009 Check Point Software Technologies Ltd. All rights reserved. Network Security Protocols Yaron Sheffer, Check Point March