- •Table of Contents
- •Preface
- •What This Book Covers
- •What You Need for This Book
- •Conventions
- •Reader Feedback
- •Customer Support
- •Errata
- •Questions
- •The Need for Cryptography
- •Privacy
- •Security
- •A History of the Internet
- •Holding the Internet Together
- •The Creation of ICANN
- •ICANN Bypassed
- •The Root Name Servers
- •Running the Top-Level Domains
- •History of Internet Engineering
- •The Internet Engineering Task Force (IETF)
- •RFCs—Requests For Comments
- •IETF and Crypto
- •The War on Crypto
- •Dual Use
- •Public Cryptography
- •The Escrowed Encryption Standard
- •Export Laws
- •The Summer of '97
- •The EFF DES Cracker
- •Echelon
- •The End of the Export Restrictions
- •Free Software
- •Free as in Verifiable
- •The Open Source Movement
- •The History of Openswan
- •IETF Troubles over DNS
- •Super FreeS/WAN
- •The Arrival of Openswan
- •NETKEY
- •Further Reading
- •Using Openswan
- •Copyright and License Conditions
- •Writing and Contributing Code
- •Legality of Using Openswan
- •International Agreements
- •International Law and Hosting Openswan
- •Unrecognized International Claims
- •Patent Law
- •Expired and Bogus Patents
- •Useful Legal Links
- •Summary
- •A Very Brief Overview of Cryptography
- •Valid Packet Rewriting
- •Ciphers
- •Algorithms
- •Uniqueness
- •Public-Key Algorithms
- •Exchanging Public Keys
- •Digital Signatures
- •Diffie-Hellman Key Exchange
- •Avoiding the Man in the Middle
- •Session Keys
- •Crypto Requirements for IPsec
- •IPsec: A Suite of Protocols
- •Kernel Mode: Packet Handling
- •Authentication Header (AH)
- •Encapsulated Security Payload (ESP)
- •Transport and Tunnel Mode
- •Choosing the IPsec Mode and Type
- •The Kernel State
- •Encryption Details
- •Manual Keying
- •Final Note on Protocols and Ports
- •Usermode: Handling the Trust Relationships
- •The IKE Protocol
- •Phase 1: Creating the ISAKMP SA
- •Phase 2: Quick Mode
- •The NAT Problem
- •Summary
- •Linux Distributions
- •Debian
- •SuSE
- •Slackware
- •Gentoo
- •Linux 'Router' Distributions
- •Deciding on the Userland
- •Pluto
- •Racoon
- •Isakmpd
- •More Reasons to Pick Pluto
- •Choosing the Kernel IPsec Stack
- •KLIPS, the Openswan Stack
- •ipsecX Interfaces
- •First Packet Caching
- •Path MTU Discovery
- •KLIPS' Downside
- •NETKEY, the 2.6 IPsec Stack
- •The USAGI / SuSE IPsec Stack
- •Making the Choice
- •GPL Compliance and KLIPS
- •Binary Installation of the Openswan Userland
- •Checking for Old Versions
- •Installing the Binary Package for Openswan
- •Building from Source
- •Using RPM-based Distributions
- •Rebuilding the Openswan Userland
- •Building src.rpm from Scratch
- •Openswan Options
- •Building the Openswan Userland from Source
- •Downloading the Source Code
- •Configuring the Userland Tools
- •Optional Features
- •Compile Flags
- •File Path Options
- •Obscure Pluto Options
- •Compiling and Installing
- •Binary Installation of KLIPS
- •Building KLIPS from Source
- •Kernel Prerequisites
- •Identifying your Kernel's Abilities
- •Using Both KLIPS and NETKEY
- •The Kernel Build Options
- •Required Kernel Options
- •Desired Options
- •NETKEY Stack Options
- •KLIPS Stack Options
- •L2TP Options
- •Patching the Kernel
- •NAT-Traversal Patch
- •KLIPS Compile Shortcut
- •Activating KLIPS
- •Determining the Stack in Use
- •Building KLIPS into the Linux Kernel Source Tree
- •Building a Standard Kernel
- •NAT Traversal
- •Patching KLIPS into the Linux Kernel
- •Verifying the Installation
- •Summary
- •Manual versus Automatic
- •PSK versus RSA
- •Pitfalls of Debugging IPsec
- •Pre-Flight Check
- •The ipsec verify Command
- •NAT and Masquerading
- •Checking External Commands
- •Opportunistic Encryption
- •The ipsec livetest Command
- •Configuration of Openswan
- •The ipsec.conf File
- •Host-to-Host Tunnel
- •Left and Right
- •The type Options
- •The auto Option
- •The rsasigkey Options
- •Bringing Up the IPsec Tunnels
- •Listing IPsec Connections
- •Testing the IPsec Tunnel
- •Connecting Subnets Through an IPsec Connection
- •Testing Subnet Connections
- •Testing Properly
- •Encrypting the Host and the Network Behind It
- •Employing Advanced Routing
- •Creating More Tunnels
- •Avoiding Duplication
- •The Also Keyword
- •KLIPS and the ipsecX Interfaces
- •Pre-Shared Keys (PSKs)
- •Proper Secrets
- •Dynamic IP Addresses
- •Hostnames
- •Roadwarriors
- •Multiple Roadwarrior Connections
- •Dynamic IP and PSKs
- •Mixing PSK and RSA
- •Connection Management
- •Subnet Extrusion
- •NAT Traversal
- •Deprecated Syntax
- •Confirming a Functional NAT-T
- •Dead Peer Detection
- •DPD Works Both Ways
- •Configuring DPD
- •Buggy Cisco Routers
- •Ciphers and Algorithms
- •Using ike= to Specify Phase 1 Parameters
- •Using esp= to Specify Phase 2 Parameters
- •Defaults and Strictness
- •Unsupported Ciphers and Algorithms
- •Aggressive Mode
- •XAUTH
- •XAUTH Gateway (Server Side)
- •XAUTH Client (Supplicant Side)
- •Fine Tuning
- •Perfect Forward Secrecy
- •Rekeying
- •Key Rollover
- •Summary
- •X.509 Certificates Explained
- •X.509 Objects
- •X.509 Packing
- •Types of Certificates
- •Passphrases, PIN Codes, and Interactivity
- •IKE and Certificates
- •Using the Certificate DN as ID for Openswan
- •Generating Certificates with OpenSSL
- •Setting the Time
- •Configuring OpenSSL
- •Be Consistent with All Certificates
- •OpenSSL Commands for Common Certificate Actions
- •Configuring Apache for IPsec X.509 Files
- •Creating X.509-based Connections
- •Using a Certificate Authority
- •Using Multiple CAs
- •Sending and Receiving Certificate Information
- •Creating your own CA using OpenSSL
- •Creating Host Certificates with Your Own CA
- •Host Certificates for Microsoft Windows (PKCS#12)
- •Certificate Revocation
- •Dynamic CRL Fetching
- •Configuring CRL
- •Online Certificate Status Protocol (OCSP)
- •Summary
- •History of Opportunistic Encryption
- •Trusting Third Parties
- •Trusting the DNS?
- •OE in a Nutshell
- •An OE Security Gateway
- •DNS Key Records
- •Forward and Reverse Zones
- •The OE DNS Records
- •Different Types of OE
- •Policy Groups
- •Internal States
- •Configuring OE
- •Configuring Policies
- •Full OE or Initiate-Only
- •Generating Correct DNS Records
- •Name Server Updates
- •Verifying Your OE Setup
- •Testing Your OE Setup
- •The trap eroute
- •The pass eroute
- •The hold eroute
- •Manipulating OE Connections Manually
- •Advanced OE Setups
- •Caveats
- •Summary
- •Where to Firewall?
- •Allowing IPsec Traffic
- •NAT and IPsec Passthrough
- •Configuring the Firewall on the Openswan Host
- •Firewalling and KLIPS
- •Firewalling and NETKEY
- •Packet Size
- •Summary
- •Microsoft Windows
- •Layer 2 Tunneling Protocol (L2TP)
- •Assigning an IP for VPN Access
- •L2TP Properties
- •Pure IPsec versus L2TP/IPsec
- •Client and Server Configurations for L2TP/IPsec
- •The L2TP Openswan Server
- •Configuring Openswan for L2TP/IPsec
- •Linux Kernel Runtime Parameters for L2TP/IPsec
- •Protecting the L2TP Daemon with IPsec using iptables
- •Choosing an L2TP Daemon
- •Configuring L2TPD
- •Configuring User Authentication for pppd
- •Microsoft Windows XP L2TP Configuration
- •Microsoft Windows 2000 L2TP Configuration
- •Apple Mac OS X L2TP Configuration
- •Server Configuration for X.509 IPsec without L2TP
- •Openswan Configuration for X.509 without L2TP
- •Client Configuration for X.509 IPsec without L2TP
- •Microsoft's IKE Daemon
- •Microsoft's Certificate Store
- •Clients using Microsoft Native IPsec Implementation
- •The ipsec.exe Wrapper
- •The Linsys IPsec Tool (lsipsectool)
- •Securepoint IPsec Client
- •TauVPN (iVPN)
- •The WaveSEC Client
- •Third-Party Replacement Clients for Windows
- •The GreenBow VPN Client
- •Astaro Secure Client
- •Mac OS X IPSecuritas
- •VPNtracker
- •Manual Racoon Configuration
- •Importing X.509 Certificates into Windows
- •Importing X.509 Certificates on Mac OS X (Tiger)
- •Summary
- •Openswan as a Client to an Appliance
- •Preparing the Interop
- •The Human Factor
- •Terminology
- •Preparation
- •IPsec Passthrough
- •Tunnel Limitations
- •Anticipate Known Problems
- •Update the Firmware
- •GUI Issues
- •Keepalives
- •ISP Filtering
- •Frequently used VPN Gateways
- •Webmin with Openswan
- •Cisco VPN 3000
- •Cisco PIX Concentrator
- •Nortel Contivity
- •Checkpoint
- •WatchGuard Firebox
- •Symantec
- •Frequently used VPN Client Appliances
- •ZyXEL
- •DrayTek Vigor
- •The Vigor Web Interface
- •Windows Logon Issues
- •Other Vigorisms
- •Unresolved Issues
- •NetScreen
- •Known Issues
- •SonicWALL
- •BinTec
- •LANCOM
- •Linksys
- •Lucent Brick
- •NETGEAR
- •KAME/Racoon
- •Aftercare
- •Summary
- •Methods of Encryption
- •Host-to-Host Mesh
- •Host-to-Gateway Setup
- •Single IP Extrusiautomation or L2TP
- •Opportunistic Encryption in the LAN
- •Non-OE-Capable Machines
- •Designing a Solution for Encrypting the LAN
- •Design Goals
- •Separation of WiFi and Crypto
- •Link Layer Protection
- •The Logical Choice: IPsec
- •Hotspot
- •WaveSEC
- •Full WaveSEC
- •Catch 22 Traffic
- •Building a WaveSEC Server
- •DHCP Server Setup
- •DNS Server Setup
- •Openswan Server Setup
- •Catch 22 Traffic Setup
- •Building a WaveSEC Client
- •DH Client Setup
- •Openswan Setup
- •Testing the WaveSEC
- •Starting the WaveSEC Connection
- •Known Issues with WaveSEC
- •WaveSEC for Windows
- •Design Limitations
- •Building a WaveSEC for Windows Server
- •Obtaining the Certificate and Client Software
- •Our Prototype Experiences
- •Openswan Issues
- •Windows Kernel Issues
- •Summary
- •Cipher Performance
- •Handling Thousands of Tunnels
- •Managing Large Configuration Files
- •Standard Naming Convention
- •The also= Parameter
- •The include Parameter
- •Openswan Startup Time
- •Limitations of the Random Device
- •Other Performance-Enhancing Factors
- •Logging to Disk
- •Disable Dead Peer Detection
- •Reducing the Number of Tunnels
- •OSPF Setup
- •BGPv4 Setup
- •High Availability
- •Heartbeat
- •Xen Migration
- •Using Anycast
- •Summary
- •Do Not Lock Yourself Out!
- •Narrowing Down the Problem
- •Host Issues
- •Configuration Problems
- •Connection Names
- •Interoperability
- •Hunting Ghosts
- •Rekey Problems (After an Hour)
- •Openswan Error Messages
- •IKE: Unknown VendorIDs
- •Network Issues
- •Firewalls
- •MTU and Fragmentation Issues
- •Debugging IPsec on Apple Mac OS X
- •Debugging IPsec on Microsoft Windows
- •Oakley Debugging
- •Debugging ipsec.exe
- •Microsoft L2TP Errors
- •You Suddenly Cannot Log in Anymore over the VPN
- •Software Bugs
- •Userland Issues: Assertion Failed or Segmentation Faults
- •Kernel Issues: Crashes and Oopses
- •Memory Issues
- •Common IKE Error Messages
- •Common Kernel-Related Error Messages
- •Common Errors when Upgrading
- •Using tcpdump to Debug IPsec
- •Situation A: No Communication on Port 500
- •Situation B: Failure at Third Exchange
- •Situation C: QUICK Mode Initiates, but Never Completes
- •Situation D: All IKE Messages Occur, but no Traffic Flows
- •A Final tcpdump Example
- •User Mode Linux Testing
- •Preparing the Openswan for the UML Build Process
- •Running the UMLs
- •Writing a UML Test Case
- •Debugging the Kernel with GDB
- •Asking the Openswan Community for Help
- •Internet Relay Chat (IRC)
- •The Openswan Mailing Lists
- •Posting to the Lists
- •Research First, Ask Later
- •Free, as in Beer
- •Do not Anonymize
- •Summary
- •Linux Kernel Developments
- •Kernel API Changes between 2.6.12 and 2.6.14
- •Red Hat Kernel Developments
- •Fedora Kernel Source/Headers Packaging Change
- •MD5 Insecurities
- •Discontinuation of Openswan 1 by the End of 2005
- •Update on UML Testing Suite Installation
- •Openswan GIT Repositories
- •Openswan on Windows and Mac OS X Updates
- •Known Outstanding Bugs
- •Vulnerability Fixes in Openswan 2.4.4
- •The OSI Model and the IP Model
- •No Layers, Just Packets
- •The Protocol
- •IP Network Overview
- •IP Address Management
- •The Old IP Classes
- •Classless IP Networks
- •The Definition of a Subnet
- •Calculating with Subnets: The Subnet Mask
- •The Rest of the Network
- •Linux Networking Commands
- •Routing
- •Routing Decisions
- •Peering
- •Network Address Translation
- •Port Forwarding
- •Openswan Links
- •Community Documentation
- •Generic Linux Distributions Containing Openswan
- •Specialized Linux Distributions Containing Openswan
- •Overview RFCs
- •Basic Protocols
- •Key Management
- •Procedural and Operational RFCs
- •Detailed RFCs on Specific Cryptographic Algorithms and Ciphers
- •Dead Peer Detection RFCs
- •NAT-Traversal and UDP Encapsulation RFCs
- •RFCs for Secure DNS Service, which IPSEC May Use
- •RFCs Related to L2TP, Often Used in Combination with IPsec
- •RFCs on IPsec in Relation to Other Protocols
- •RFCs Not in Use or Implemented across Multiple Vendors
- •Index
Introduction
RFC 1984 has been complemented by RFC 2804, Policy on Wiretapping, where the IETF announced its stance that wiretapping had no place in the protocol standards, and should be achieved using alternative means. This position was not based on a consensus of political opinion, but was based purely on technical arguments.
The War on Crypto
In the late eighties, with the increased use of the Internet, then still mostly limited to governments, military, big corporations, and universities, the friendly nature of the Internet and its old trust in everyone was disappearing. Protocols such as Telnet and FTP that used plaintext passwords were becoming a big problem. The Internet was becoming too big to trust.
Everyone was further abandoning expensive secure private leased lines in favor of cheaper Internet connections, just as now people are switching from classic phone lines to Voice over IP telephony. These things all need security and they need privacy. In other words, they needed cryptography.
Dual Use
Cryptography has always been enshrouded in secrecy. What started as the art of concealing a secret has now bloomed into protecting secrets out in the open in plain view of everyone, using near-unbreakable mathematical formulae. Of course, the early adopters of these technologies were the military, but in the 70s it became clear that companies would need cryptography, and today just about everyone is communicating using electronic means, and has a need for privacy.
Researchers at IBM invented DES, the Digital Encryption Standard, and the NSA gave in. They allowed American companies to use DES, and even suggested that IBM slightly change its new encryption scheme, to make the protocol far more robust against a certain attack than it would have otherwise been.
Public Cryptography
One by one, all inventions made secretly within the military were being re-invented by non-military cryptanalysts. And new algorithms and ciphers were being designed at universities and private companies. Rivers, Shamir, and Adelman invented RSA public key encryption. In 1976 Diffie and Hellman came up with a technique which has become known as DH key exchange, enabling the safe exchange of public keys. Unbeknownst to them, the technique had already been discovered a few years earlier by Malcolm J. Williamson of GHCQ, the British version of the NSA, who kept it secret. Phil Zimmerman wrote PGP, the first simple-to-use encryption program for the PC. And in 1994 Bruce Schneier published his book on the once-secret science of cryptography, completely letting the genie out of the bottle. The book, Applied Cryptography (John Wiley & Sons, 1995, ISBN 0-471-11709-9), quickly became the standard work for anyone who needed or wanted to learn and understand cryptography.
12
Chapter 1
The Escrowed Encryption Standard
Under the Clinton administration, the US government adopted a strategy of containment to control the spread of unbreakable cryptography. The idea was to allow a broken cryptography standard to be used by the general public, with a built-in backdoor for governmental use. The Escrowed Encryption Standard, with its now infamous Clipper Chip, was signed into law in 1994.
The Clipper Chip was designed by the NSA and implemented the Skipjack algorithm, which contained a backdoor accessible to the US government. Perhaps not surprisingly, few foreign entities embraced this crippled security. Other governments and organizations, especially in Europe, were working hard on making unbreakable crypto, and in the end the US Government gave into pressure and the Clipper Chip never saw the light of day.
Export Laws
Encryption methods not requiring the Clipper Chip were still legal for US companies and citizens, but in order to try to prevent everyone else from using cryptography, cryptography was classed as munitions, an item on the list of controlled weapons and resources that may not be exported to other countries without explicit government permission. Cryptography was treated exactly the same way as nuclear bombs.
But the export laws could not prevent the world from obtaining cryptographic software independently. The European countries still do not recognize software patents, meaning encryption algorithms patented in the US can be freely used by anyone outside the US. This included the RSA and IDEA algorithms, both used by the PGP software, though Phil Zimmerman never actually licensed RSA for this.
Other countries, especially Europe and Israel, were working hard to catch up with the US. Companies from these countries were free to sell strong cryptographic software to the US, but US companies were not getting the government permission they needed to export their products outside the US. The result was that many products existed in two versions: a US version, with full encryption, which usually meant 128-bit encryption, and an international version, which was usually limited to 40-bit encryption. This was most visible when Netscape invented the Secure Socket Layer (SSL), a method allowing a browser to talk securely to a web server without anyone being able to eavesdrop on the content of the communication. This was essential for doing business on the Internet, allowing users to give a web server their credit card information with the confidence that it could not be read by an unauthorized party.
Netscape had to release two browser versions, one with 40-bit encryption and one with 128-bit encryption. But since its browser program was freely downloadable, it was impossible for Netscape to restrict the 128bit version to the US alone, but it still needed to make some effort in order to comply with the US export laws. It was not really practical to stop the spread of the 128-bit encryption version of their browser. People mirrored the software in Europe, others wrote software to tweak the 40-bit version to enable its 128-bit encryption that was built into the software binaries.
The Linux Debian distribution started a non-US branch, which contained the cryptographic software, and only non-US Debian download sites could have this software. Cryptography in the Linux kernel existed for a while as a separate patch on a non-US site, www.kerneli.org.
13
Introduction
Pressure from researchers at universities in the US increased. With help of the EFF, Prof. Bernstein, then still a graduate student at Berkeley, sued the US government in 1995, claiming that talking about cryptography was a right protected by the First Amendment. He followed up with another lawsuit in 2002 claiming that "it's inexcusable that the government is continuing to interfere with my research in cryptography and computer security." But while Bernstein was fighting to liberate crypto, someone else had found a loophole in the law.
The Summer of '97
The munitions laws that restricted cryptography were focused on software. Bernstein was suing the US government so he would be able to teach cryptography in his classes. But exporting paperwork, such as research material, was never covered by the export restrictions. Two groups of hackers, the Dutch 'Hacktic' group and the San Francisco 'Cypherpunks', took on a project and printed the entire source code of the PGP program, with checksums on every page.
They then took this stack of paper and flew to The Netherlands to an open-air hacker event called 'Hacking In Progress'. They scanned the papers, ran character recognition software on them, manually fixing letters that were not read correctly, aided by the checksum printed on each page. At the end of the five-day event, the PGP source code had been reconstructed in digital form. PGP had now been legally exported from the US.
The export laws came under more and more pressure, mostly from US companies who were crippled in selling their software abroad. They could still only sell crippled 40-bit encryption outside the US, and nobody wanted it, since a lot of European software with strong cryptography had become commercially available. Then the EFF put the final nail in the coffin of weak crypto.
The EFF DES Cracker
In a basement room of John Gilmore in San Francisco, a machine was built, the DES Cracker. It consisted of a Linux machine that acted as console for a large array of specially-designed DES cracking chips. The costs, including all R&D, were $250,000. On July 18 1998, it took 'Deep Crack' only three days to crack RSA Laboratory's 'DES Challenge II'. On January 19 1999, it cracked the 'DES Challenge III' in 22 hours. The previous record on that challenge had taken 56 hours using 100,000 PCs worldwide. The US government could no longer claim that DES was good enough for encryption. A few months later it became clear why the US government wanted the international community to use weak crypto.
Echelon
In April 1999, Duncan Campbell, a British journalist, handed over his report entitled Interception Capabilities 2000 to the Director General for Research of the European Parliament. Campbell reported that, after years of research all over the world, he had uncovered the existence of Echelon, a massive top-secret network of interception capabilities built and operated by the US and the UK, aimed at their allies in Europe. Tension between Europe and the US rose. Accusations of industrial espionage were highlighted in a case where US airplane manufacturer Boeing underbid the European Airbus in a very large contract, apparently after having inside information handed to it by the NSA.
14