kDRENardwareonearth'com - PowerPoint PPT Presentation

Title: kDRENardwareonearth'com


1
Practical IPsec

• Ken Renard
• WareOnEarth Communications, Inc.

2
Tutorial Overview

• Security and Cryptography Background
• IPsec Overview
• IPsec Components
• IPsec Implementations
• Practical Examples

3
Security Overview

• Security is tough
• The smallest of details can be very important
• Encryption is not easy to do correctly
• Security can be very complex
• Many interdependent systems
• See first bullet
• Mis-Information on Security (aka marketing)
• Snake oil, techno-bable, and confusing jargon
• Youre only as good as your weakest link

4
Security Concepts

• Network Threats
• Unauthorized release of information
• Unauthorized modification of information
• Unauthorized use of service

5
Security Services

• Data Integrity (data in storage or transit)
• Integrity of data content
• Message ordering
• Data authenticity
• Data Confidentiality (data in storage or transit)
• Confidentiality of data content
• Traffic Analysis
• Access Control and Authorization
• Non-Repudiation

6
Authentication vs. Authorization

• Authentication (authN)
• Not imaginary, false, or imitated genuine,
  veritable, worthy of acceptance or belief
• Is this person really who they claim to be
• Authorization (authZ)
• Approval or permission making a course of action
  valid freedom or right granted to another
• Is this person allowed to access this service

7
Cryptography Background

• Purpose to alter information into an
  unrecognizable format such that it can be
  recovered in a known way
• Only those who are authorized to see data know
  the way
• Can be used for data confidentiality, data
  authentication, and data integrity
• Mathematical or procedural algorithms for
  altering data

8
Cryptographic Operations

• Encryption Convert plaintext to cipher text
• Decryption Convert cipher text to plaintext
• Plain text should be unreadable to unauthorized
  parties.
• Confidentiality
• Keys may be used to disturb or permute the
  output of algorithms

9
Keys and Key Management

• Strong cryptographic algorithms require the key
  to decrypt cipher text
• Encryption keys and decryption keys are related
• Keys are generally a long string of bits
• Not easily remembered by mere humans
• String-to-Key algorithms (password-generated
  keys)
• Password-protected key storage
• Key Management
• Generation, distribution, storage, destruction,
  and maintenance of keys
• Key generation usually depends on good source of
  random numbers
• Secrecy of keys is extremely important -- but
  sometimes left to the user
• Vulnerable part of any cryptographic system

10
Using Encryption in Security

• Confidentiality
• Only authorized parties have the key, therefore,
  the ability to decrypt
• Authentication
• If key distribution is limited to a known party,
  successful encryption infers data source
  authentication
• Integrity
• If key distribution is limited to a known party,
  the message could not have been decrypted,
  modified, and re-encrypted
• All of these require proper Key Management

11
Cryptographic Hashes

• Hash Data signature, or digest using a one-way
  function.
• Hash represents data, but cannot be used to
  recover it.
• Given a hash, it is nearly impossible to generate
  a similar message with the same hash
• There will be collisions, but they should not be
  predictable
• Variable length message, fixed length hash
• Practical examples Unix sum or md5sum
  commands

12
More on Hashes

• Hashes for Authentication
• Calculate hash of message, then encrypt
• Receiver decrypts and verifies hash
• Successful decryption indicates authentication of
  hash
• Authentic hash in indicator of authentic message
  content
• Cheaper to encrypt small hash versus larger
  message
• Example PGP signatures
• Keyed Hash
• Include key in data being hashed
• Receiver hashes key in with data and verifies
• Only those who possess the key can generate keyed
  hashes

13
Breaking Cryptography

• Poorly designed algorithms may be subject to many
  attacks
• Known-Plaintext Attacks having some knowledge
  of what the plaintext may look like
• Brute-Force Attacks attempt to search entire
  key space using cipher text and decryption
  algorithm
• Try every possible key until decrypted text makes
  sense
• On average, search one half of the key space
• Key space versus key length
• Attacks on Key Management
• Human factor usually the easiest to break
• Poor design or implementation of security system

14
Brute Force Attacks

• A good implementation of a good algorithm with
  good key management is still vulnerable
• Encryption and decryption require CPU time
• Trying every possible key takes a long time, but
  is possible
• Balance cost/probability of compromise versus
  time
• Key length is generally proportional to strength
  of encryption
• Given any algorithm, cipher text, and infinite
  time or infinite computing power, it can be
  broken
• Key size requirements depend on the algorithm
• 56-bit DES can be broken in less that 5 hours
• http//www.computeruser.com/newstoday/99/01/25/new
  s7.html
• 168-bit 3DES and 128- or 256-bit AES are deemed
  appropriate today

15
Some Details on Cryptography

• Stream ciphers versus Block ciphers
• Stream ciphers operate on one bit at a time
• Block ciphers operate on larger chunks of data at
  a time
• May need to pad data to block size of algorithm
• Modes of encryption algorithms
• ECB Electronic code book
• CBC Cipher block chaining
• Counter Mode encrypt a sequence of numbers and
  XOR output with plaintext (pseudo-stream cipher)

16
Cipher Block Chaining
Plaintext Block 0
Plaintext Block 1
Plaintext Block 2
Block Encrypt
Block Encrypt
Block Encrypt
Ciphertext Block 0
Ciphertext Block 1
Ciphertext Block 2
17
Cipher Block Chaining
Plaintext Block 0
Plaintext Block 1
Plaintext Block 2
Block Encrypt
Block Encrypt
Block Encrypt
Initialization Vector (IV)
Ciphertext Block 0
Ciphertext Block 1
Ciphertext Block 2
18
Counter Mode Cipher
Sequence number must not wrap!!
Sequence Number
Sequence Number 1
Sequence Number 2
Block Encrypt
Block Encrypt
Block Encrypt
Plaintext Block 1
Plaintext Block 2
Plaintext Block 3
Ciphertext Block 0
Ciphertext Block 1
Ciphertext Block 2
19
Cipher Modes

• If you find this stuff interesting
• You are a true geek
• Check out
• Practical Cryptography -- Niels Ferguson and
  Bruce Schneier

20
Symmetric Key Cryptography

• Same key is used for both encryption and
  decryption
• Sender and receiver share a key
• Must secretly negotiate key before communications
• Out-of-band method (e.g. trusted third party)
• Secure communications depends on secrecy of
  shared key
• If adversary can intercept, guess, or steal key,
  then the communication is no longer secret
• Unfortunately, humans are usually part of key
  management
• inherently imperfect
• Popular algorithms
• 3DES, AES, Blowfish, IDEA, RC4, etc.

21
Public Key Cryptography

• Different keys are used for encryption and
  decryption
• Two mathematically-related keys are generated
• Public Key publicized, anyone can look it up
• Private Key kept private. Known only to owner
• First rule of understanding public key encryption
• What is encrypted with one key is decrypted with
  other
• Encrypt with Public Key
• Everyone can know your public key -- anyone can
  encrypt
• Only you know your private key -- only you can
  decrypt
• Encrypt with Private Key
• Only you know your private key -- only you can
  encrypt
• Everyone can know your public key -- anyone can
  decrypt

22
Public Key Encryption

• Encrypt with Public Key, decrypted with Private
  Key
• Everyone can know your public key -- anyone can
  encrypt
• Only you know your private key -- only you can
  decrypt
• Anyone can encrypt a message that only you can
  decrypt
• Must have knowledge of your public key
• Correctness of your public key is important
• Privacy of private key is important
• Example application sending private e-mail

23
Public Key Signatures

• Encrypted with Private Key, decrypted with Public
  Key
• Only you know your private key -- only you can
  encrypt
• Everyone can know your public key -- anyone can
  decrypt
• Analogous to handwritten signature (actually,
  its better!)
• Anyone can decrypt a message that only you can
  encrypt
• Must have knowledge of your public key
• Correctness of public key is important
• Privacy of private key is important
• Example Application Authenticated e-mail

24
Public Key CryptographyIn Practice

• Popular Algorithms RSA, Diffie-Hellman
• Public key encryption/decryption is
  computationally expensive
• Limit use of public key operations to symmetric
  key exchange
• Use PK ops to sign and encrypt key exchanges
• Public Key Encrypt operation
• Generate random symmetric session key

25
Public Key CryptographyIn Practice
Encrypt
Sign
26
Diffie-Hellman Key Agreement

• Anonymous key exchange algorithm
• Public parameters p and g
• p is large prime number
• Each party generates random private value a and
  b
• Each party generates public value
• (ga mod p), (gb mod p)
• Exchange public values over unsecured link
• Calculate key gab mod p
• (ga mod p)b mod p (gb mod p)a mod p gab mod p
• This is susceptible to a man-in-the-middle attack
• Authentication must be tightly coupled

27
Public Key Infrastructures (PKI)

• Security of public key encryption depends on
• Correct distribution and maintenance of public
  keys
• Privacy of private keys
• Must authenticate and verify integrity of others
  public keys
• Keys can be exchanged out of band
• Key management the same as symmetric key
• Trust some authority to introduce new keys
• Manual key management only necessary with
  authorities

28
Public Key Certificates

• A Certificate binds a public key to an identity
• Analogous to drivers license
• Binds picture to an identity
• Hologram to verify authenticity of document
• Trust authority (issuing state agency) to vouch
  for binding
• Certificate includes
• Public Key data
• Subject Identity
• Issuer Identity
• Validity period
• Signature
• Issuer signs certificate data
• We can verify that Issuer created this certificate

29
Certificate Authority (CA)

• Defines policies for verifying identity of
  subscribers
• Anyone with 50
• Provide physical proof of identity (e.g. drivers
  license)
• Subscriber provides public key data and proof of
  identity
• Certificate Authority generates signed
  certificate
• Services select which CAs they will trust
• Public CAs are available
• RSA, Thawte, Verisign, etc.

30
X.509 Certificates

• X.509 is a standard format for certificate
  information
• Uses ASN.1 encoding
• Data in certificate
• Distinguished Name (DN) in X.500 formatting
• CUS/OArmy/OUARL/CNJoe Researcher
• Certificate Serial Number
• Issuer
• Valid From / Valid Until timestamps (typical
  lifetime is 2 or 3 years)
• Public Key information
• Signature
• Extension information
• Current version of X.509 is v3

31
Certificate Revocation

• If private key is compromised, it can be used to
  steal identity or decrypt private information
• Certificate may be revoked by CA indicating that
  the binding is no longer valid
• Only necessary during certificate lifetime
• CA periodically issues CRL
• Certificate Revocation List
• Lists certificate by serial number
• CRLs have expiration time and time of next issue
• Applications must check CRL for each certificate
• Client and server side!

32
Using Certificates

• Encrypt a message to a recipient
• Obtain certificate of recipient(s)
• Verify authenticity of certificate (check
  signature chain)
• Check CRL
• Encrypt with public key
• Verifying Signature
• Obtain certificate of signer
• Verify authenticity of certificate (check
  signature chain)
• Check CRL
• Perform hash of message and compare to signed
  hash sent

33
Obtaining Certificates

• Some protocols send certificates in setup
  messages
• Certificates can be looked up in directory
• LDAP
• X.500
• DNS
• Must have prior knowledge of some certificates
• Root CA certificates
• Self-signed certificates

34
Certification Hierarchy
DoD Class 3 Root CA

• DoD CACs have 3 certificates
• Email signature
• Email encryption
• Identity

We trust that these CAs will not issue
certificates with the same identity
35
Certification Hierarchy

• Certificate chain
• List of certificates from you up to common
  trusted CA
• Must have authentic copy of trusted root CA
  certificates
• If you have bogus trusted root CA certificate,
  someone can impersonate any identity
• If a CA is compromised
• Private key of CA is known to attacker
• That CA must no longer be trusted

36
PKI and Key Management

• We can establish authenticated and encrypted
  communication with anyone
• Who has a valid certificate from a trusted CA
• Without previous secure key exchange with
  individual
• Secrecy of private keys is essential
• Storing private keys on smartcards is a good idea
• CAC stores certificates and private key
• Private key operations done on the card
• Private key never leaves the card
• Secure, authentic copy of CA certificates
  important
• Revocation checking is a must!
• CRLs or OCSP

37
Tutorial Overview

• Security and Cryptography Background
• IPsec Overview
• IPsec Components
• IPsec Implementations
• Practical Examples

38
IPsec Overview

• Security services at the IP Network (3) layer
• Hour glass model
• Lower layers are technology-dependant
• Upper layers are application-dependant
• Middle-layer security
• Can be provided by the network (router-router)
• Can be implemented in either hardware or software
• IPv4 and IPv6
• Native Support for IPsec is mandatory for IPv6
• Optional, but generally available for IPv4

39
IPsec Overview

• IPsec components
• Protection of IP packets on the wire
• Provide protection based on security policy
• Automated Key Management
• IPsec works by applying, enforcing, and managing
  Security Associations (SAs)
• Define protection applied to packets
• Enforce security policy according to processing
  model
• Maintained by key management

40
IPsec Security Services

• Authentication
• Data source authentication
• Integrity
• Message content and ordering
• Confidentiality
• Encryption of packet data
• Replay Detection
• Limited traffic flow confidentiality
• Access Control (i.e. packet filtering)

but this all depends on
41
IPsec Dependencies

• Trusted identities
• PKI or some authentication and key mgmt
  infrastructure
• Correct Implementation
• Questionable (vendor priorities, complexity,
  demand)
• Protocol changes are on-going
• Secure Platforms
• ltsighgt
• Correct Usage
• Are we doing more harm than good?

42
IPsec Is NOT

• A silver-bullet for security
• It is merely an additional tool available
• Should never be the sole security mechanism
• User-level security
• Identities are network endpoints, not users
• Application level security
• Does not replace SSL or Kerberos
• Application security is still necessary
• Applications may be unaware of IPsec services
• Viruses can be spread securely now!
• See draft-bellovin-useipsec-03.txt

If you think cryptography is the solution to
your problem, you dont know what your problem
is -- Roger Needham
43
IPsec Problems

• Implementations are still complex
• Configuration can be vastly different across
  platforms
• Some implementations lacking features
• Selector granularity
• PKI integration
• IPsec can render network security devices useless
• Firewalls may not see port numbers
• NIDS may not see packet data
• Key Management and Identity Management
• Public Perception Just IPsec it

44
IPsec and Network Security Services
Specific port/protocol on host
Firewall IDS
External Network
VPN Endpoint
Firewall IDS
VPNs
May need to duplicate security services if VPNs
are allowed to bypass traditional front-door
installations
Internal Network
45
IPsec and IPv6

• Native support for IPsec is required for IPv6
• Thats where IPv6 is secure comes from
• Many vendors do not support IPsec for IPv6 yet
• Windows Longhorn and XP patch (2nd half 2005)
• Linux (USAGI only)
• Solaris 10 (beta, with bugs)
• HP (HP-UX and Tru64), and IBM AIX claim support
• Some parts of IPv6 cannot be protected by IPsec
• Cannot use IKE for auto-configuration
• No addresses

46
IPsec History

• Idea of IPsec goes back (at least) to the early
  1990s
• Three revisions
• 1995 RFC 1825-1829 -- no key management
• 1998 RFC 2401-2412 -- IKE v1 key management
• Current -- IKE v2 key management
• RFC numbers to be assigned

47
IPsec RFCs

• 2401 Security Architecture for the Internet
  Protocol. S. Kent, R. Atkinson.
• 2402 IP Authentication Header. S. Kent, R.
  Atkinson.
• 2403 The Use of HMAC-MD5-96 within ESP and AH. C.
  Madson, R. Glenn.
• 2404 The Use of HMAC-SHA-1-96 within ESP and AH.
  C. Madson, R. Glenn.
• 2405 The ESP DES-CBC Cipher Algorithm With
  Explicit IV. C. Madson, N. Doraswamy.
• 2406 IP Encapsulating Security Payload (ESP). S.
  Kent, R. Atkinson.
• 2407 The Internet IP Security Domain of
  Interpretation for ISAKMP. D. Piper.
• 2408 Internet Security Association and Key
  Management Protocol (ISAKMP). D. Maughan, M.
  Schertler, M. Schneider, J. Turner.
• 2409 The Internet Key Exchange (IKE). D. Harkins,
  D. Carrel.
• 2410 The NULL Encryption Algorithm and Its Use
  With IPsec. R. Glenn, S. Kent.
• 2411 IP Security Document Roadmap. R. Thayer, N.
  Doraswamy, R. Glenn.
• 2412 The OAKLEY Key Determination Protocol. H.
  Orman. (Informational)

48
IPsec RFCs

• 1321 The MD5 Digest Algorithm (and 1810 Report on
  MD5 Performance)
• 1750 Randomness Recommendations for Security
  (revision in draft)
• 1828 IP Authentication using Keyed MD5
• 2094 Group Key Management Protocol (GKMP)
  (Experimental)
• 2104 HMAC Keyed Hashing for Message
  Authentication (and RFC 2202, Test Cases)
• 2284 PPP Extensible Authentication Protocol (EAP)
• 2394 IP Payload Compression Protocol (IPComp)
• 2451 The ESP CBC-Mode Cipher Algorithms
• 2460 Internet Protocol, Version 6 (IPv6)
  Specification (and related RFCs)
• 3168 The Addition of Explicit Congestion
  Notification (ECN) to IP
• 3280 Internet X.509 Public Key Infrastructure
  Certificate and Certificate Revocation List (CRL)
  Profile
• 3456 Dynamic Host Configuration Protocol (DHCPv4)
  Configuration of IPsec Tunnel Mode
• 3513 Internet Protocol Version 6 (IPv6)
  Addressing Architecture
• 3526 More Modular Exponential (MODP)
  Diffie-Hellman Groups for Internet Key Exchange
  (IKE)
• 3554 On the Use of Stream Control Transmission
  Protocol (SCTP) with IPsec
• 3566 The AES-XCBC-MAC-96 Algorithm and Its Use
  With IPsec
• 3602 The AES-CBC Cipher Algorithm and Its Use
  With IPsec
• 3664 The AES-XCBC-PRF-128 Algorithm for the
  Internet Key Exchange Protocol (IKE)
• 3686 Using Advanced Encryption Standard (AES)
  Counter Mode With IPsec Encapsulating Security
  Payload (ESP)

49
Tutorial Overview

• Security and Cryptography Background
• IPsec Overview
• IPsec Components
• IPsec Implementations
• Practical Examples

50
IPsec Components

• AH - Authentication Header
• ESP - Encapsulating Security Payload
• SA - Security Associations
• SPD - IPsec Policy
• IKE - Key Management

51
IPsec Authentication Header

• Can provide
• Connectionless Integrity
• Data origin authentication
• Replay Detection
• Partial Sequence Integrity (anti-replay
  detection)
• AH after IP packet header, before IP payload
• IPPROTO_AH 51
• Integrity Check Value (ICV) covers
• Immutable fields of the IP packet header
• Entire AH (authentication data set to all zeros)
• All upper layer data
• Improper encapsulation (layer violation)

52
AH Header Diagram
8
16
8
53
Authentication Header Fields

• Next Header protocol of the header that follows
  the AH as defined in most recent Assigned
  Numbers RFC
• Payload Length length of AH in 32-bit words
  minus 2
• IPv6 extension header standard is minus 1 64-bit
  word
• Security Parameters Index (SPI)
• Used to uniquely identify Security Association
  (SA)
• Sequence Number
• Set to zero at initialization of SA
• Sender monotonically increases value per packet
  (must not cycle)
• Receiver may disregard SN
• Authentication Data -- variable length (multiple
  of 32-bits)
• Interpretation based on SA

54
IPsec ESPEncapsulating Security Payload

• Can provide
• Connectionless Integrity
• Data Origin authentication
• Replay Detection
• Partial Sequence Integrity (anti-replay
  detection)
• Confidentiality
• Partial traffic flow confidentiality
• ESP after IP packet header, before IP payload
• IPPROTO_ESP 50
• Authentication and encryption covers
• Entire ESP header (authentication data set to all
  zeros)
• All upper layer data

Same as AH
55
ESP Header Diagram
32
authenticated
encrypted
56
ESP Header Fields

• Security Parameters Index (SPI) (same as AH)
• Used to uniquely identify Security Association
  (SA)
• Sequence Number (same as AH)
• Set to zero at initialization of SA
• Sender monotonically increases value per packet
  (must not cycle)
• Receiver may disregard SN
• Payload Data
• IP payload data (possibly including
  initialization vector)
• Padding
• For alignment of pad length and next header
  fields
• Ciphers which require plaintext to be a multiple
  of block size
• Partial traffic flow confidentiality

57
ESP Header Fields (cont)

• Pad length
• Length in bytes
• Next Header protocol of the header encapsulated
  by the ESP as defined in most recent Assigned
  Numbers RFC
• Note that this field is encrypted
• Authentication Data -- variable length (multiple
  of 32-bits)
• Interpretation based on SA

58
Transport and Tunnel Modes

• AH and ESP have 2 modes of operation
• Transport Mode
• AH and/or ESP is placed between IP header and
  next higher level header
• IP-TCP -gt IP-AH-TCP
• IP-TCP -gt IP-ESP-TCP
• AH in transport mode authenticates parts of
  preceding IP header and all of IP payload
• ESP in transport mode protects only IP payload
• Can only be used host-to-host
• Term transport does not restrict application to
  just TCP/UDP

59
Transport and Tunnel Modes

• Tunnel Mode
• Creates new IP header (IP)
• Encapsulates existing IP packet
• IP-UDP --gt IP-AH-IP-UDP
• IP-UDP --gt IP-ESP-IP-UDP
• AH in tunnel mode authenticates parts of IP and
  all of existing IP packet
• Existing IP packet is not changed in transit
• ESP in tunnel mode encrypts all of the existing
  packet
• May be used host-to-host, host-to-router,
  router-to-router
• Common way to implement VPNs
• BITW -- Bump-In-The-Wire

60
Host-to-Host Modes
Transport Mode
Host A
Host B
Tunnel Mode
61
Host-to-Gateway Tunnel Mode

• Security Gateway performs IPsec services on
  behalf of Host A
• Offloads IPsec processing and policy enforcement
  from Host A
• Road-warrior VPN

Host A
ESP Tunnel
Security Gateway
Host B
62
Gateway-to-Gateway Tunnel Mode
Network A
Network B

• Security Gateways perform IPsec services on
  behalf of Network A B
• Offloads IPsec processing and policy enforcement
  from hosts
• Inter-site VPN

ESP Tunnel
Security Gateway
Security Gateway
63
Ordering of Packet Headers (AH)
IPv4
IPv4 hdr
IP opts
TCP data
TCP hdr
IPv4 hdr
IP opts
TCP data
TCP hdr
AH
IPv6
IPv6 hdr
IPv6 ext
TCP data
TCP hdr
IPv6 hdr
IPv6 ext
TCP data
TCP hdr
AH
IPv6 ext

• Hop-by-Hop
• Dest opts
• Routing
• Fragmentation

• Dest opts

Dest opts can be before or after ESP/AH
64
Ordering of Packet Headers (ESP)
IPv4
IPv4 hdr
IP opts
TCP data
TCP hdr
IPv4 hdr
IP opts
TCP data
TCP hdr
ESP
ESP authN
ESP trailer
IPv6
IPv6 hdr
IPv6 ext
TCP data
TCP hdr
IPv6 hdr
IPv6 ext
TCP data
TCP hdr
ESP
ESP authN
ESP trailer
IPv6 ext

• Hop-by-Hop
• Dest opts
• Routing
• Fragmentation

• Dest opts

Dest opts can be before or after ESP/AH
65
Security Associations

• A simplex connection that specifies an IPsec
  security protocol
• AH or ESP, not both
• Typical bi-directional security requires (at
  least) 2 SAs
• Contains all the needed parameters
• Selectors, algorithms, keys, replay counters,
  expiration, modes
• Source applies security, destination verifies
• Can be established manually or negotiated by IKE
• Each node maintains a Security Association
  Database (SAD)
• Indexed by 3-tuple
• 32-bit Security Parameter Index (SPI) chosen by
  receiver
• IP Destination Address
• Security Protocol (AH or ESP) not for long

66
Security Association Information

• Addresses
• Sequence Number Counter -- 32 bit
• Sequence Counter Overflow -- flag
• Anti-replay window
• AH authentication algorithm
• ESP encryption algorithm
• ESP authentication algorithm
• Lifetime
• Time and/or byte count
• New SAs (with new SPI) replace expiring SAs
• Protocol mode (transport v. tunnel)
• Path MTU

Specific algorithms and their usage with IPsec
are detailed in separate RFCs
67
Security Policy Database (SPD)

• List of policy rules that determine actions to
  take for inbound and outbound traffic
• Separate list for each direction for each
  interface
• List is ordered
• Wildcards are allowed, ordering matters
• Selectors designate specific traffic
• Discard, bypass IPsec, or apply/verify IPsec
• Map traffic to a specific SA (or new one is
  created)
• Addresses, port numbers, protocols, sub-protocols
• Think stateless firewall rules

68
IKE for Key Management

• Internet Key Exchange
• Actually does entire SA negotiation
• Manual configuration of SAs become too difficult
• IKE is no picnic, either
• Allows for flexible policy and usage
• Multiple algorithms, authentication methods
• Integrates entity authentication with key exchange

69
IKE Hierarchical Key Management

• Long term keys
• Usually public/private key pairs
• Use certificates to bind public key to identity
• Certificates may belong to hosts, people, etc.
• Support for shared keys
• Typical lifetime months to a few years
• Short term keys
• Usually symmetric keys
• Unilaterally or cooperatively generated
• Could be based on authentication exchange
• Typical lifetime few minutes to a few days

70
IKE Version 1

• Design based on Photuris, SKEME, ISAKMP, and
  Oakley
• Mutual authentication based on certificates or
  pre-shared secrets (pre-shared keys - PSK)
• SA setup and maintenance
• Features
• Identity hiding
• Forward secrecy
• Negotiated parameters
• Re-keying
• Support added for
• NAT traversal
• Legacy authentication
• DHCP

71
IKEv1

• ISAKMP -- Internet Security Association and Key
  Management Protocol
• Framework for authentication and key exchange
• Initiator and Responder (I and R) -- either side
  can initiate
• Send multiple proposals
• Select common preferred proposal
• Two phases
• Phase 1 established ISAKMP SA
• Main Mode (6) and Aggressive Mode (3)
• Phase 2 uses ISAKMP SA to establish further SAs
• Quick Mode and New Group Mode
• Oakley
• Series of Key Exchanges called modes
• Combined with SKEME key exchange technique

72
ISAKMP Phases

• Phase 1
• Creates bi-directional SA
• Negotiated Parameters
• Encryption algorithm
• Hash algorithm
• Authentication Method
• Signature, Public Key, PSK
• Information about Diffie-Hellman group
• Sets up secure channel to create further SAs
• Phase 2
• Negotiates parameters for non-ISAKMP SA
• Protected by ISAKMP SA established in phase 1

73
Oakley Key Determination Protocol

• Used in both phases of IKE
• Provides keying material for encryption, hashing
  and authentication
• Perfect Forward Secrecy
• Compromise of long-term key will not expose
  previous short-term (session) keys
• Identity hiding
• Authentication is done after encryption has
  started
• Available in Main Mode, but not Aggressive Mode
• Efficient re-keying in Quick Mode
• SAs can be quickly re-keyed
• Oakley Groups
• Specify DH parameters (p, g) or EC parameters
• Groups 1,2,5 are common DH (768-, 1024-, and
  1536-bit mod p)

74
IKE in Action

• IKE exchanges messages on UDP port 500
• Traffic is encrypted where possible
• Cannot be protected by normal IPsec SAs
• When policy requires outbound packet to be
  protected
• Look for existing SA
• If none exists, contact IKE to negotiate SA
• SPD has policy data for required SA
• If ISAKMP SA does not exist, negotiate it
• Policy for ISAKMP SA generation

75
Putting It All Together
Original Packet
SPD
Discard
Bypass IPsec
Apply IPsec
SAD
Look Up SA
(AH/ESP)
No SA
IKE
UDP 500
Interface
76
Extended Authentication for IKE

• IKE requires mutual authentication using the same
  methods
• PSK most are password-based and assumed weak
• RSA encryption, RSA signature requires extensive
  PKI or key mgmt
• Need for legacy authentication
• XAUTH -- extended authentication
• Do normal phase 1 IKE authentication with PSK or
  RSA
• Additional authentication with external server
  (RADIUS, SecurID, etc)
• Aggressive mode to renegotiate without
  re-authenticating user
• Weak PSKs can render IKE authentication useless
• Widely deployed by VPN vendors (Cisco, NetScreen,
  etc.)
• draft-beaulieu-ike-xauth-02.txt (expired April
  2002)
• Availability limited (OpenSWAN for Linux, most
  appliances)

77
IPsec and NAT Problems

• AH authenticates invariant fields of outer IP
  packet
• These fields are no longer invariant with NAT
• ESP in transport mode
• NAT may need to modify port numbers in TCP/UDP
• TCP/UDP packets may be encrypted (non-NULL
  cipher)
• ESP authentication would break if NAT changes
  ports (NULL cipher)
• ESP tunnel mode can still work
• IKE and NAT
• To and from UDP/500
• Identities with PSKs are usually IP addresses

78
IPsec and NAT Solutions

• Dont use NAT
• Use IPv6 if address space is a concern
• NAT before IPsec is applied
• IPsec NAT in a box
• ESP encapsulated in UDP
• Allows for tunnel and transport ESP
• No NAT support for AH -- use ESP authentication
• draft-ietf-ipsec-nat-t-ike
• IKE and NAT
• Float IKE ports and mux/demux by leaving
  initiator cookie zero
• Static NAT for IKE ports -- keep-alive packets
  necessary
• Use certificates to get around IP identity
  problem
• Supported by quite a few implementations

79
Future Changes to AH and ESP

• Larger sequence numbers
• 64-bit sequence numbers
• Set to zero at SA establishment
• Higher order 32-bits
• Stored internally by sender and receiver (never
  transmitted)
• Used in ICV calculation
• SA Naming
• Currently identified by SPI, dest address and
  protocol (AH or ESP)
• Just SPI and dest address are sufficient
• Better multicast support
• Separate algorithm specification

80
Future Changes to ESP

• Traffic Flow Protection
• Extended Padding
• More than 255 bytes
• Dummy protocol
• Next Header (IPPROTO) 59
• Receiver will disregard packet
• Allow sending of fake packets
• Next Header field is encrypted

81
IKE Redesign

• IKE is a complex beast
• IKEv2 is being designed
• All retro-fits for IKEv1 (NAT, legacy authN)
• New algorithms
• More efficient exchanges (reduce of msgs)

82
Tutorial Overview

• Security and Cryptography Background
• IPsec Overview
• IPsec Components
• IPsec Implementations
• Practical Examples

83
IPsec Implementations

• Kernel Module
• Modifications to network stack
• PF_KEY interface
• Built-in or available as a kernel module
• Policy Tool
• For managing SPD
• Manage SA policies
• IKE daemon
• Negotiates Security Associations with remote
  machines
• Usually define identity and authentication here

84
Working With IPsec

• Setting up IPsec can be best described as
  experimental
• Especially across OSes
• IPsec-protect all traffic between 2 machines
• Use a third for control so you dont lose
  connection!
• Start with simple configurations and work your
  way up to policy
• PSK authentication, basic selectors
• Use tcpdump or ethereal to watch and verify
  traffic
• Ethereal has good decoders for ISAKMP
• Ping is a good test
• Make sure you re-initialize appropriate daemons
• /dev/random is a good source of PSK material
• dd if/dev/random bs1 count24 od -x

85
Tutorial Overview

• Security and Cryptography Background
• IPsec Overview
• IPsec Components
• IPsec Implementations
• Practical Examples

86
Linux IPsec

• Main distributions only do IPv4
• USAGI is primary IPv6 IPsec source
• http//www.linux-ipv6.org
• FreeS/WAN project replaced by OpenSWAN and
  strongSwan
• http//www.openswan.org
• http//www.strongswan.org
• IKE daemon is pluto
• KLIPS (Kernel Level IP Security)
• Loadable kernel module
• /usr/sbin/ipsec
• Front-end script for everything else

87
Linux IPsec

• You can do completely manual keying
• Static keys for SA encryption
• Please dont use
• Turn off route filtering!!!
• echo 0 gt /proc/sys/net/ipv4/conf/ltiface_namegt/rp_f
  ilter
• Due to routing of packets inside kernel
• Will get martian source errors
• No longer supports single-DES
• Main files
• ipsec.conf
• ipsec.secrets

88
Linux ipsec.conf

• Almost all of ipsec configuration is done here
• Major exception is authentication secrets
• config setup section
• Specifies interfaces and file parsing attributes
• Connection sections
• Defines almost all parameters of a Security
  Association
• left and right identities
• Makes it easy to go from drawing to connection
  file
• Can copy configuration from one host to other
  without swapping
• Determination of who is left and who is right
  is done internally
• Transport or Tunnel
• AH or ESP

89
Linux ipsec.conf connection
conn dude-raven afinet typetunnel
authesp authbyrsasig
leftrsasigkeycert leftcert/etc/ipsec.d/dud
e_cert.pem right192.168.51.6
left192.168.151.102 rightid"CUS, STMD,
LAbingdon, OWareOnEarth, gt CNraven.ab.ware
onearth.com" leftid192.168.151.102
leftprotoport17/2049 NFS UDP
leftprotoport6/2049 NFS TCP
90
Linux ipsec.conf connections

• type
• tunnel, transport, passthrough, drop, reject
• Reject is drop with ICMP message
• This allows more complete policy definition
  (firewall-like)
• left
• IP address of left participant
• defaultroute local address of default route
  interface
• Only one of left or right can be set this way
• any address to be filled in during IKE
  negotiation
• opportunistic both left and leftnexthop from IKE

91
Linux ipsec.conf connections

• leftsubnet
• Private subnet behind left
• Specifies that left will provide IPsec services
  for this subnet
• Format network/netmask
• Defaults to left/32 (or left/128)
• auth
• Specifies whether authentication is done with AH
  or as part of ESP
• keylife and ikelifetime
• Security Association and ISAKMP SA key lifetime
• Seconds, minutes, hours, days (s, m, h, d)
• leftprotoport
• Protocol and port numbers (TCP6, UDP17)
• /usr/include/netinet/in.h

92
Linux ipsec.conf connections

• authby
• How endpoints with authenticate during IKE
• secret and rsasig (rsasig for RSA secret or
  certificate)
• leftid
• Identity to be used in IKE authentication
• IP address, _at_FQDN, X.500 name
• leftrsasigkey
• Allows RSA key to be used outside of PKI
• Can be looked up via DNS
• cert along with leftcert to specify PEM-encoded
  file
• leftrsasigkey2 for 2nd key to be used for rollover

93
Linux ipsec.secrets file

• Specifies secrets used to authenticate IKE
  daemons (file permissions!)
• Identities are addresses, FQDNs, user_at_FQDN,
  any, or any6
• Keys are PSK or RSA

10.1.0.1 10.2.0.1 PSK secret_password www.foo
.com PSK 0x6f3603c109de728e883ac1f092... 1.2.3.
4 RSA /etc/ipsec.d/private/my_key
abc123 99.100.101.102 RSA Modulus
0syXpo/6waamZhSs8Lt6jnBzu3C4grtt...
PublicExponent 0sAw PrivateExponent
0shlGbVR1m8Z7rhzSyenCaBN... Prime1
0s8njV7WTxzVzRz7AP0OraDxmEAt1BL5l...
Prime2 0s1LgR7/oUMo9BvfU8yRFNos1s211KX5K0...
Exponent1 0soaXj85ihM5M2inVf/NfHmtLutVz4r...
Exponent2 0sjdAL9VFizFBKU4ohguJFzOd55OG6...
Coefficient 0sK1LWwgnNrNFGZsS/2GuMBg9nYVZ...
string-to-key
192-bit 3DES
Dont worry about key parity
DNS names not good
Private key file with passphrase
Private key data from ipsec tools
94
Linux ipsec command

• ipsec auto --add ltconn-namegt
• ipsec auto --up ltconn-namegt
• ipsec auto --down ltconn-namegt
• ipsec auto --delete ltconn-namegt
• ipsec look
• Brief, netstat -rn-style output
• ipsec barf
• Lots of status info (no kidding, LOTS!!!)
• ipsec pluto --debug-
• --debug-all, --debug-crypt, --debug-control, etc
• ipsec klipsdebug

95
Linux IPsec Details

• Host-to-host tunneling is allowed
• protoport support is less than reliable
• No DES support
• Newer versions dont allow AH only
• Use ESP with null encryption (espnull-md6-96)
• tcpdump on ethX devices can be a bit unreliable
• ipsecX interface should see un-protected traffic
• www.freeswan.org
• www.strongswan.org (has AES, OCSP, LDAP)

96
Solaris IPsec

• IPsec support in Solaris 8, 9, and 10
• Solaris 10 is first to have IPsec for IPv6
• IPsec comes up before networking (cant use
  hostnames in config)
• IKE daemon is in.iked
• /etc/inet/ike/config is main config file
• /usr/sbin/ikeadm
• /usr/sbin/ipsecconf -- policy tool
• /etc/inet/ipsecinit.conf is standard startup
  config
• ipsecconf -a /etc/inet/ipsecinit.conf
• Default file has some good examples
• /usr/sbin/ipseckey
• Direct manipulation of SA database

97
Solaris IKE Configuration

• /etc/inet/ike/config entry
• Global configuration parameters for
• Certificate root and LDAP servers
• Phase 1 lifetimes
• Specifies how IKE will authenticate and create SAs

label otto-raven local_addr
20014803111a0020fffed8f1e3 remote_addr
2001480311020a85fffeda960 p1_xform
auth_method preshared oakley_group 5 auth_alg
sha1 encr_alg 3des p2_pfs 5
98
Solaris IKE Authentication PSK

• /etc/inet/secret/ike.preshared
• ID types IP, IPv6
• Preshared keys must be hexadecimal values (no
  strings)
• To use strings echo authN-string od -x

localidtype ipv6 localid
20014803111a0020fffed8f1e3 remoteidtype
ipv6 remoteid 2001480311020a85fffeda960
key 60863d20fbad110327b2ca63cd3d12d1bd39adb8eb348
aee
dd bs1 count24 if/dev/random od -x
99
Solaris IKE Authentication PKI

• Files
• /etc/inet/secret/ike.privatekeys/
• /etc/inet/ike/publickeys
• /etc/inet/ike/crls/
• ikecert tool
• ikecert certlocal -- for dealing with private
  keys
• add, create, extract, list, remove private keys
• add function requires Solaris-only key format
  
• ikecert certdb -- for dealing with public-key
  repository
• add, extract, list, remove public keys from
  database (PEM or ASN.1 BER)
• ikecert certrldb -- for CRLs
• add, extract, list, remove CRLs
• ikecert tokens -- for PKCS11 token interface
• New to Solaris 10

100
Solaris ipsecconf Configuration

• SPD manipulation tool
• ipsecconf -a ltfilegt
• Add policies in ltfilegt
• ipsecconf -ln
• list policies (-n for no hostname lookup)
• Individual policies versus file policy entries
  (also ordered)
• ipsecconf -f
• Flush all policies
• ipsecconf -d ltindexgt
• Delete individual policy

101
Solaris ipsecconf Configuration

• Policy format pattern action properties
• Listed in order of application
• Pattern is selector
• saddr/daddr ltaddressgt/ltprefixgt
• sport/dport
• ulp proto ltprotocol numbergt
• Action
• apply (outbound), permit (inbound), ipsec (both)
• bypass, pass, drop
• pass/bypass take precedence in ordering

102
Solaris ipsecconf Configuration

• Properties
• auth_algs -- Use AH
• HMAC-MD5, HMAC-SHA
• encr_algs -- Use ESP encryption
• DES-CBC, 3DES-CBC, BLOWFISH-CBC, AES-CBC
• encr_auth_algs -- Use ESP authentication
• HMAC-MD5, HMAC-SHA
• dir -- if not implied
• in out both
• sa -- Use existing SA or create new SA for this
  policy
• unique, shared
• Use ipsecalgs to show supported encryption and
  authentication algorithms

103
Solaris ipsecconf Configuration
otto and raven, ESP encr and ESP authN for
everything laddr otto.ab.wareonearth.com
raddr raven.ab.wareonearth.com ipsec
encr_algs 3des encr_auth_algs sha1 IPv6 to
Moonv6 host -- AH only (this demonstrates
Sol_10_b54 IPv6 AH-only failure) laddr
20014803111a0020fffed8f1e3 raddr
200148026140015 ipsec auth_algs any sa
shared
104
Solaris IPsec Tunneling

• All IPsec associations are assumed transport
  unless specific tunnels are set up
• Set up tunnel pseudo-devices
• In /etc/hostname6.ip6.tun0

tsrc 20014803111a0020fffed8f1e3 tdst
200148026140015 up addif fe8011 fe8022 up

• Set up transport SA between tunnel endpoints

laddr 20014803111a0020fffed8f1e3
raddr 200148026140015 ipsec encr_algs
3des encr_auth_algs sha1 sa shared
105
Solaris IPsec Debugging

• IKE deamon can be run in foreground with
  debugging
• /usr/lib/inet/in.iked -d
• Also ikeadm can turn on debugging info
• ikeadm set debug all /tmp/foo
• cert, key, op, phase1, phase2, pfkey, policy,
  prop, door, config
• Kernel-level debugging
• ndd /dev/ipsecah \?
• also ndd /dev/ipsecesp \?
• Turn on logging for different AH/ESP facilities
• Output usually through syslog

106
Macintosh OS X IPsec (BSD)

• OS 10 and later
• IKE daemon is racoon
• /etc/racoon/racoon.conf configuration file
• Policy tool is setkey
• For SPD and SAD

107
Mac OS X racoon.conf

• General IKE config
• Includes /etc/racoon/remote/.conf
• Use these for configuration of specific endpoints
  
• remote section
• Phase 1 configuration
• sainfo section
• Phase 2 configuration

108
Mac OS X racoon.conf
remote 200148026140015
exchange_mode main, base lifetime time
52 min proposal_check obey
my_identifier address 2001480311020a95fffeda
960 peers_identifier address
200148026140015 proposal
encryption_algorithm 3des
hash_algorithm sha1
authentication_method pre_shared_key
dh_group modp1536 sainfo
address 2001480311020a95fffeda960 any
address 200148026140015 any
pfs_group 2 lifetime time 10 min
encryption_algorithm 3des
authentication_algorithm hmac_sha1, hmac_md5
compression_algorithm deflate
109
Mac OS X IKE Authentication

• Preshared Keys
• /etc/racoon/psk.conf

20014803111a0020fffed8f1e3
0x857bf308c6ec374ad9bf5b95f... 192.168.51.5
abc123

• Certificate Authentication
• In racoon.conf include

my_identifier asn1dn peers_identifier
asn1dn certificate_type x509 "/etc/racoon/certs/r
aven_cert.pem" "/etc/racoon/certs/raven_priv_de
crypted.pem" peers_certfile "/etc/racoon/certs/du
de_cert.pem" send_cert on send_cr
on verify_cert on
110
Mac OS X setkey

• Direct SAD management
• dump to list all SAs -- setkey dump
• setkey add src dst protocol spi extensions
  algorithm...
• recommend using policy definitions instead
• SPD rules

ESP tunnel host-to-host spdadd 192.168.51.6
192.168.151.102 any -P out ipsec
esp/tunnel/192.168.51.6-192.168.151.102/require
spdadd 192.168.151.102 192.168.51.6 any -P in
ipsec esp/tunnel/192.168.151.102-192.168.51.6/re
quire ESP IPv6 transport spdadd
2001480311020a95fffeda960
200148026140015 any -P out
ipsec esp/transport//require spdadd
200148026140015 2001480311020a95fffeda
960 any -P in ipsec esp/transport//require
ESP transport to Windows XP spdadd 192.168.51.6
192.168.51.5 any -P out ipsec esp/transport//requi
re spdadd 192.168.51.6 192.168.51.5 any -P in
ipsec esp/transport//require
111
Mac OS X setkey

• setkey -f ltfilenamegt
• setkey -D -- dump SAD
• setkey -F -- flush all SAs in SAD
• setkey -FP -- flush all policies in SPD
• setkey -x -- dump all PF_KEY messages
• For debugging
• Algorithms
• authN hmac-md5, hmac-sha1, keyed-md5,
  keyed-sha1, null, hmac-sha2-256, hmac-sha2-384,
  hmac-sha2-512
• encr des-cbc, 3des-cbc, simple, blowfish-cbc,
  cast128-cbc, des-deriv, 3des-deriv, rijndael-cbc

112
Windows IPsec

• Windows 2000 SP2 and XP
• Create an IPsec and Certificates MMC
• Start/Run/MMC
• Click on File, then Add/Remove Snap-in
• Click on Add
• Click on Certificates, then Add
• Select Computer Account and Next
• Select Local Computer and Finish
• Select IP Security Policy Management and Add
• Select Local Computer and Finish
• Click Close and OK

113
Windows IPsec

• Add certificate
• Click the plus arrow by Certificates (Local
  Computer)
• Right-click Personal and click All Tasks,
  then Import
• Click Next
• Browse and select .p12 file and click Next
• Type the export password and click Next
• Select Automatically select the certificate
  store based on the type of certificate and click
  next
• Click Finish and say yes to any prompts that
  pop up
• Exit the MMC and save as a file

114
Windows IPsec

• Create new IPsec policy
• Default policies are just about worthless
• From MMC console
• Right-click on IP Security Policies on Local
  Computer
• Select Create IP Security Policy, then Next
• Create name and/or description, then Next
• Un-check Activate the default response rule,
  then Next
• Click Finish to complete wizard and edit
  properties of new rule

115
Windows IPsec
Security Policy

• Rules
• Add
• Edit

General

• Rules
• Add
• Edit

• Rules
• Add
• Edit

Name
Advanced

• Security Methods
• AH alg
• ESP encr alg
• ESP authN alg
• Key lifetime

• Tunnel
• Setting
• Endpoint

IKE PFS

• Authentication
• Methods
• Kerberos-v5
• Certificate
• PSK

• IP Filter List
• src/dst
• proto
• ports

• IKE Method
• AuthN alg
• Encr alg
• DH group

• Connection
• Type
• All
• LAN
• Remote Access

Filter Action
116
Windows IPsec

• MMC IP Security Policies on Local Computer
• You select one policy to be assigned or in use
• In the Office policy
• On the Road policy
• This policy will have one or more rules
• Each rule has
• IP Filter list -- Create and select filter
  (addrs, proto, ports)