IPSec mit freeswan

Aus Bits'n'Bugs Wiki
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

IPSec Security Services

IPSec adds an additional Security Layer in the TCP/IP Stack, in order to protect TCP/IP-Traffic

  • Data Origin Authentication
  • Data Integrity Authentication
  • Data Content Confidentiality
  • Anti Replay Protection
  • Limited Traffic Flow Confidentiality

IPSec Protocols

  • AH (proof of data origin, data integrity, anti replay protection)
  • ESP (all that AH provides, plus optional data confidentiality)

IPSec Modes

  • Tunnel Mode
  • Transport Mode

Cryptography

IPSec needs Shared Keys (symmetric keys) for confidentiality and authentication, needed for symmetric cipher and keyed MAC

You can add those shared keys manually (in ipsec.conf) or you can use IKE (pluto) to let the keys being negotiated automatically:

  • manual keys
    • both security gateway's share a secret key
    • see espenckey= and espauthkey= in ipsec.conf
  • automatic (the gateway's authenticate each other and exchange a secret key)
    • authentication based on shared secrets
      • PSK=Preshared Key, see ipsec.secrets
    • or digital signatures

IKE

IKE (a mixture of Oakley and SKEME) is based on ISAKMP (Internet Security Association Key Management Protocol) which is the transport mechanism (i.e. packet format) for negotiating shared keys and security services by IKE

tasks:

  • authenticating IPSec peers
  • negotiating Security Services
  • generating shared keys

Phase I: Generating IKE SA

2 Modes available: Aggresive Mode (needs 3 Messages), Main Mode (needs 6 Messages and provide limited protection)

  1. negotiate Protections suite (what algorithm, what group)
  2. exhange shared key
  3. authenticate shared key

Phase II: Generating IPSec SA

1 Mode: Quick Mode

  1. exchanging key (optionally with Perfect Forward Secrecy)
  2. exchanging the selector that matched the IP-Paket
  3. --> constructing IPSec SA

Security Association

  • The association between security services and the IP-Traffic to be protected and the remote destination of the communication
    • Security Services (authenticator and encryptor)
    • Session Key for both authenticator and cipher (symmetric)
    • SPI
    • sequence number
    • tunnel or transport mode
    • ah or esp
    • What IP-Traffic to protect
    • Remote Peer (you need that when constructing the new IP-packet with the destination ip from the remote security gateway)
  • after a packet produces a hit in the SPD, that packet is processed with the corresponding SA (e.g. the packet encrypted with the key the SA holds)
  • SA's are unidirectional! They exist in pairs, one for each direction
  • identified by the SPI (Security Parameter Index)
  • SA's reside in SADB. Every implementation has to provide an interface to manipulate the SADB when adding SA's manually the user configures the parameters, when IKE is used to negotiate parameters the IKE daemon invokes the interface to automatically add the SA
  • can be created automatically (IKE) or manually
  • SA's have a lifetime, when created dynamically (important for security issues)
  • SA's contain a sequence number which is used by the recipient to check for packet replaying


IPSec Policy

  • you can imagine the IPSec Policy as Packet Filter rules, e.g. you can define a Rule (Policy) for a packet destined for specific IP-Adress and a unique port
  • The Policy is stored in the SPD (Security Policy Database) every implementation has to provide an interface to manipulate the SPD
  • Each Packet entering the IP-Stack, has to be compared with the Secutiy Policy Database in order to decide wether matched traffic should be bypassed ( no security services are applied ), discarded ( IP-datagram is dropped ) or protected ( IP-Processing is done: apply security services defined in the associated SA. If there is no SA, IKE has to negotiate one)
  • Selectors map IP-traffic to IPSec Policy

some explaining pictures (dia is a nice program!)

outbound packet processing

Datei:Oubound.png

inbound packet processing

Datei:Inbound.png

there are four interesting cases:

  1. received packet has no ESP-Header and Policy is bypass => give packet to the IP-Layer which hands it out to upper-layer protocols (TCP) or routes it to other hosts
  2. no ESP-Header and Policy is apply => process packet with appropriate SA and hand it out to IP-Layer, which routes it to the other ends security gateway
  3. received packet has ESP-Header and corresponding SA exists => process packet with SA and hand it out to IP-Layer which routes it to the final destination or sends it to the Transport-Layer
  4. packet has ESP-Header and no SA exists => packet has to be dropped, because you were unable to get SA by SPI and you cannot dictate IKE to negotiate one because you don't know the selector-parameters used to determine the right Policy
Meine Werkzeuge