Secure Protocols and VPNs

1
Secure Protocols and VPNs

• Stefek Zaba
• Hewlett-Packard Labs, Bristol
• stefek_zaba_at_hp.com

2
What well cover

• This lecture
• network layering revision
• secure channel concept
• substantial example IPSec
• Next lecture
• substantial example 1 TLS/SSL
• substantial example 2 SSH
• summaries and random rants

3
Network layers

• You heard this in Lecture 1!
• Simplified Internet model
• application
• transport
• network
• link

4
Network layers
Application layer lots of protocols, e.g. HTTP
carrying Web traffic, SMTP carrying email, NNTP
carrying News, Transport layer TCP - reliable
connections (sequence nums, retransmission),
carries HTTP, FTP, Telnet, UDP unreliable
datagrams, e.g. streaming audio/video Network
(IP) layer is Internet. Carries TCP, UDP,
ICMP (ping, router control), Link layer
carries IP (and others, e.g. Appletalk, NetBUI,
IPX, ARP, ...) hop-by-hop LAN.Examples
IEEE802.3, PPP, RF LAN
5
Where shall we put security?

• Link level
• covers all traffic on that link, e.g. RF
• only one hop
• Network (IP) level
• covers all traffic, end-to-end
• transparent to applications
• little application control
• unnatural, since IP is stateless packets but
  channel is stateful

6
Where shall we put security?

• Transport (TCP) level
• end-to-end
• apps can control when its used
• apps must be modified (unless proxied)
• Application level
• can be tuned to payload requirements
• no leverage - must rework for every app

7
What security are we providing?

• A secure channel, typically offering
• Origin authentication (but of what OS? App?
  User?)
• Integrity
• Confidentiality
• Not
• Non-repudiation
• Any services once data received

8
Crypto primitives used

• Symmetric ciphers
• Asymmetric ciphers signatures
• (Keyed) hash functions
• (Keyed) pseudo-random functions
• Key agreement protocols mainly DH

9
Typical goals

• At least one party authenticated
• Shared secret established
• MAC bulk cipher keys derived from shared secret
• Further traffic protected
• Optional session re-use, rekeying,

10
IPSec overview

• Network-level all IP datagrams covered
• Mandatory for next-generation IP (v6), optional
  for current-generation (v4)
• Authentication-only or confidentiality too
• Two modes
• transport mode for IPSec-aware hosts as
  endpoints
• tunnel mode for IPSec-unaware hosts,
  established by intermediate gateways or host OS
• References RFC2401..2412 FreeSWAN

11
Authentication AH

• Authenticates whole payload and most of header
• vitally, covers source IP address
• omits only fields modified in transit
• e.g. TTL/hop-limit, fragmentation fields, some
  options

12
Encryption auth ESP

• Encrypts and optionally authenticates payload,
  but not IP header
• Combine with AH for full confauth
• Use alone for payload confauth
• There are both engineering and political reasons
  for their separate existence!

13
AH ESP, Tunnel Transport
Original unprotected datagram
AH in transport mode
ESP (conf and auth) in transport mode
ESP auth MAC
ESP auth MAC
ESP auth-only in transport mode
MAC scope
application data
len
TCP header
len
Inner IP header host-srcIP, host-destIP, TTL,
pktID,
AH SPI, seqnum, MAC.
Outer IP header gw-srcIP, gw-destIP, TTL, pktID,
len
AH in tunnel mode
MAC scope
ESP I(conf and auth) in tunnel mode carrying AH
in transport mode
ESP auth MAC
14
Why so many combinations!?

• To support different VPN arrangements, to meet
  different security and deployment-practicality
  requirements

15
Simple transport-mode usagehost-to-host(no
singing, please)
Without transport-mode IPSec
With transport-mode IPSec
16
Simple tunnel-mode usagegateway-to-gateway
17
Other combinations for other requirements
AH in transport mode Host-to-host auth-only, e.g.
network management?
ESP (conf and auth) in transport
mode Host-to-host secure channel, e.g.
encapsulated legacy apps?
ESP auth MAC
ESP auth-only in transport mode As for
AH-transport probably worse in all cases
ESP auth MAC
MAC scope
AH in tunnel mode Between-gateway VPN with no
overall confidentiality provision (may be good
performance choice)
application data
len
TCP header
len
Inner IP header host-srcIP, host-destIP, TTL,
pktID,
AH SPI, seqnum, MAC.
Outer IP header gw-srcIP, gw-destIP, TTL, pktID,
len
MAC scope
ESP in tunnel mode carrying AH in transport
mode Common road warrior VPN secure channel
across public network, and strong, continuing
authentication to end system(s)
ESP auth MAC
18
But where did the keys come from?

• SPI (security parameters index) refers to an
  SA (security association)
• SAs set up manually or by IKE IPSec Key
  Exchange
• Policy databases define how fine- or
  coarse-grained SAs are
• anything from all traffic shall use this key to
  individual combinations of source and destination
  addresses and ports
• even user-based keying supported but binding a
  user to an IP address is (very) problematic

19
Outbound processing

• Lookup policy for this datagram
• drop, pass through, or process
• Create a new SA if none exists
• Apply keys from SA for MAC and enciphering
• Add explicit IV for each datagram
• because they can be lost and arrive out-of-order
• Pass assembled datagram down to link layer
• or to next instance of IPSec processing!
• Lets ignore fragmentation, PMTU discovery,

20
Inbound processing

• Lookup policy for this datagram
• drop, pass through, or process
• SA should already exist (were the responder)
• Apply keys from SA for MAC-check and deciphering
  (using datagrams IV too)
• Raise security error if needed otherwise,
• Pass assembled datagram up to rest of normal IP
  processing
• or to next instance of IPSec processing!

21
What can be MACed?

• Immutable or predictable fields and options in
  IPv4 and IPv6
• AH-controlled all immutable, so MACed
• payload, payload length, next-header, SPI,
  sequence number, reserved fields
• IP header immutables and predictables v6
• version, payload length, next-header, source and
  destination IP addrs,
• BUT NOT class, flow label, or hop limit ( v4
  TTL)
• all v6 extension headers self-describing as to
  mutability
• IP header immutables and predictables v4
• version, header and payload lengths, packetID,
  protocol type, source and destination IP addrs
• BUT NOT ToS, flags, fragment offset, TTL, header
  checksum
• All unpredictable fields zero-filled for MAC
  calculation
• so overall length and alignment still protected

22
IPsec Key Exchange IKEor, time for a deep
breath!

• Documentation hard to follow
• IKE is specific adaptation of more general
  protocols (Oakley and ISAKMP)
• Two levels of SA negotiated
• an initial context (bidirectional, with
  heavy-duty authentication and negotiation)
• then several client SAs, negotiated quickly using
  initial SA as secure channel one for each
  direction and each AH and ESP
• initial SA also used for error traffic and
  similar management traffic

23
IKE security goals

• Authentication of parties (by digital signature,
  proof of knowledge of private key, or shared key)
• Establishment of a fresh shared secret
• Shared secret used to derive keys for channel
  confidentiality and authentication
• Perfect Forward Secrecy, at cost of using up
  shared material
• (partial) anti-clogging, against
  denial-of-service attacks
• Secure negotiation of algorithms asymmetric
  (e.g. RSA, elliptic curve), symmetric (e.g. 3DES,
  Blowfish, AES), and hash (e.g. MD5, SHA-1)

24
IKE details

• Phase 1 is the heavyweight exchange to establish
  a secure key management channel
• Main mode variant slower, more cautious, hides
  details of credentials used and allows forward
  secrecy (independence of short-term keys)
• Aggressive mode less negotiation, fewer round
  trips, more information disclosed
• Phase 2 (quick mode) established SAs for IPSec
  itself, using the Phase 1 channel

25
Main Mode IKE Phase 1using digital
signatures(see RFC2409, p.11)
Initiator Responder HDR, SA_i --gt lt-- H
DR, SA_r
Headers (HDR) include cookies CKY-I and CKY-R
respectively. Initiators SA has one or more
proposals, in preference order, for algorithms
to be used for ISAKMP, the key management channel
were building. The responder chooses exactly one
of these proposals. These SAs may refer to one of
a few standard Diffie-Hellman groups (both
integer and ECC), or may define new DH groups.
HDR, KE, Ni --gt lt-- HDR, KE, Nr
Ni, Nr are initiators and responders nonces,
respectively KE are Diffie-Hellman gx and gy
values
HDRIDii, CERT, SIG_I --gt lt-- HDRIDir,
CERT, SIG_R
HDR denotes remaining ISAKMP traffic is
encrypted. IDii, IDir are IDentifiers, typically
IP addresses.SIG_I is over HASH_I prf( SKEYID,
gx gy CKY-I CKY-R SA_i IDii )SIG_R
is over HASH_R prf(SKEYID, gy gx CKY-R
CKY-I SA_i IDir )where SKEYID prf( Ni_b
Nr_b, gxy ), and prf is the negotiated keyed
pseudo-random function Note 3 round-trips, 4 DH
modular exponentiations, 2 signature-generations
and 2 signature-verifications
26
Aggressive Mode IKE Phase 1using public-key
proof(see RFC2409, p.14)
HDR, SA_i, ltNigtPubkey_r, ltKEgtKe_i,
ltIDiigtKe_i --gt
HDR includes CKY-I. SA_i has exactly one
take-it-or-leave-it proposal. The nonce Ni is
encrypted in the responders public key KE
(thats gx) and IDII are encrypted under Ke_i
prf( Ni, CKY-I ). So, the responder can decrypt
Ni and so derive Ke_i only if it has the private
complement to Pubkey_r.
lt-- HDR, SA_r, ltNrgtPubkey_i,
ltKEgtKe_r, ltIDirgtKe_r, HASH_R
HDR includes CKY-R. SA_r must equal SA_i.
Similarly to the initiators message, the nonce
Nr is encrypted in the initiators public key,
while KE (thats gy) and IDir are encrypted
under KE_r prf( Nr, CKY-R ), requiring the
initiator to have the private complement of
Pubkey_i. HASH_R is as on the previous page.
HDR, HASH_I --gt
The hashes sent in each direction arent signed
but the ability to generate them proves receipt
and successful decryption of the nonce received
from the other party. Note 1.5 round-trips only,
still 4 DH modular exponentiations, 2 public-key
encrypts and 2 public-key decrypts. Careful
analysis shows plausible deniability the
absence of digital signatures allows either party
to disown the exchange.
27
Use of Phase 1 agreed material
Key material for the underlying ISAKMP
key-management SA were building first is derived
from the shared-secret quantity gxy and the
nonces securely exchanged during Phase 1 as
follows SKEYID prf( Ni Nr, gxy ) SKEYID_d
prf( SKEYID, gxy CKY-I CKY-R 0
) SKEYID_a prf( SKEYID, SKEYID_d gxy CKY-I
CKY-R 1 ) SKEYID_e prf( SKEYID, SKEYID_d
gxy CKY-I CKY-R 2 ) where _a refers to
Authenticator (MAC) material for the ISAKMP
channel, and _e is for Encrypting material for
the ISAKMP channel. _d is dual-purpose firstly,
its used as input for the _a and _e
pseudo-random streams secondly, its the main
source of key material for the Phase 2 SAs which
are the ones used by IPSec itself. SKEYID is used
directly as the prf key for HASH_I and HASH_R,
used to authenticate the parties. Particular
transforms (symmetric encryption algorithms,
MACs, and so on) specify exactly how SKEYID_a,
SKEYID_e, and SKEYID_d is to be used. For
example, the specification for single-key DES
uses at minimum the first 8 bytes of the PRF,
forcing the parity bits to appropriate values,
throwing away any bytes which would give rise to
the known weak or semi-weak keys. (There are only
16 out of 256 such keys, so this isnt likely to
occur in practice!) The Triple-DES definition
uses at least 24 bytes of the prf output, and the
prf definition stretches its initial result by
repeated application to produce as many bytes as
are needed.
28
Phase 2 Quick Mode
Now that we have an ISAKMP SA to define a secure
key-management channel, doing algorithm and key
agreement for client SAs such as AH and ESPis
cheap and easy (relatively speaking). As example,
this is how you get 4 SAs (one for each direction
of an AH ESP pair) - see RFC2409
p.19 HDRHASH(1), SA0, SA1, Ni --gt As
before, HDR means that all further material is
encrypted (under SKEYID_e, remember?). SA0, SA1,
etc. are proposals for client SAs for the AH
and ESP transforms each one is a
preference-ordered list of possible algorithm
combinations. Ni is a new initiator nonce.
HASH(1) prf( SKEYID_a, M-ID SA0 SA1 Ni )
see how SKEYID_a is the MAC key. M-ID is the
unique message-ID from HDR. lt-- HDRHASH(2),
SA0, SA1, Nr Back come single algorithm choices
for each SA, and a new responder nonce Nr.
HASH(2) is similar to HASH(1) HASH(2) prf(
SKEYID_a, M-ID Ni SA0 SA1 Nr ) it has Ni
added as a liveness proof. HDRHASH(3 --gt This
is a simple acknowledgement that the responders
message has been receivedHASH(3)
prf(SKEYID_a, 0 M-ID Ni Nr ) Now key
material for each IPSec SA is defined as
follows KEYMAT prf( SKEYID_d, protocol SPI
Ni Nr ) Since protocol and SPI are unique to
AH/ESP and direction respectively, this gives 4
separate chunks of KEYMAT. If necessary, they are
stretched as before by applying prf
iteratively. Note the single Phase 1 DH exchange
and public-key operations have been used to
derive key material for all four IPSec SAs,
spreading the cost of those expensive operations.
Theres an option to include a fresh DH exchange
in each Quick Mode if you prefer Forward Secrecy
to computational efficiency...
29
Final notes on IPSec

• IKE is carried over UDP hence unreliable (may
  need to be restarted) and blocked by some
  firewalls
• Managing IPSec policy and deployments isnt easy,
  and getting it wrong can be embarassing in losing
  connectivity, e.g. by making exchanges of routing
  updates unreadable
• After trying to roll-its-own with PPTP, MS has
  put IPSec into WinXP
• See FreeS/WAN for implementation (and contribute
  too, unless youre a US citizen)http//www.xs4al
  l.nl/freeswan/