Secure Protocols and VPNs

fullgorgedcutΔίκτυα και Επικοινωνίες

24 Οκτ 2013 (πριν από 3 χρόνια και 11 μήνες)

49 εμφανίσεις

Secure Protocols and VPNs

Stefek Zaba

Hewlett
-
Packard Labs, Bristol

stefek_zaba@hp.com

What we’ll 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

Network layers


You heard this in Lecture 1!


Simplified Internet model:

application

transport

network

link

Network layers

application data

len

TCP header

port, seqnum,

SYN, ACK, FIN, …

application data

len

TCP header

port, seqnum,

SYN, ACK, FIN, …

len

IP header

srcIP, destIP,

TTL, pktID, …

application data

len

TCP header

port, seqnum,

SYN, ACK, FIN, …

len

IP header

srcIP, destIP,

TTL, pktID, …

Ethernet header

ether
-
addr, checksum, …

len

application data

len

TCP header

port, seqnum,

SYN, ACK, FIN, …

len

IP header’

srcIP, destIP,

TTL
-
n, pktID, …

X.25 header

Virtual
-
circuit
-
ID, …

len

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


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

Where shall we “put security”?


Transport (TCP) level:


end
-
to
-
end


apps can control when it’s used



apps must be modified (unless proxied)


Application level:


can be tuned to payload requirements



no “leverage”
-

must rework for every app

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

Crypto primitives used


Symmetric ciphers


Asymmetric ciphers & signatures


(Keyed) hash functions


(Keyed) pseudo
-
random functions


Key agreement protocols: mainly DH

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, …


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

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

Encryption + auth: ESP


Encrypts and optionally authenticates
payload, but
not

IP header


Combine with AH for “full” conf+auth


Use alone for payload conf+auth


There are both engineering and political
reasons for their separate existence!

AH & ESP, Tunnel & Transport

application data

len

TCP header

port, seqnum,

SYN, ACK, FIN, …

len

IP header

srcIP, destIP,

TTL, pktID, …

application data

len

TCP header

len

IP header

srcIP, destIP,

TTL, pktID, …

AH

SPI, seqnum,


MAC, …

MAC scope

application data

len

TCP header

len

IP header

srcIP, destIP,

TTL, pktID, …

ESP

header:

SPI,seqnum

MAC scope

ESP

trailer: pad,

padlen, …

encryption scope

application data

len

TCP header

len

IP header

srcIP, destIP,

TTL, pktID, …

ESP

header:

SPI, seqnum

MAC scope

ESP

auth: MAC

application data

len

TCP header

len

Inner IP header

host
-
srcIP, host
-
destIP,

TTL, pktID, …

AH

SPI, seqnum,

MAC. …

MAC scope

Outer IP header

gw
-
srcIP, gw
-
destIP,

TTL, pktID, …

len

application data

len

TCP header

len

Inner IP header

host
-
srcIP, host
-
destIP,

TTL, pktID, …

AH

SPI,seqnum,

MAC, …

Inner AH MAC scope

Outer IP header

gw
-
srcIP, gw
-
destIP,

TTL, pktID, …

len

ESP

trailer: pad,

padlen…

Outer ESP MAC scope

ESP

header:

SPI,seqnum

encryption scope

Original unprotected
datagram

AH in transport mode

ESP (conf and auth)

in transport mode

ESP auth
-
only

in transport mode

AH in tunnel mode

ESP I(conf and auth) in
tunnel mode

carrying AH in transport mode

ESP

auth: MAC

ESP

auth: MAC

Why so many combinations!?


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

Simple transport
-
mode usage:

host
-
to
-
host

(no singing, please)

app data

len

TCP

len

IP

app data

len

TCP

len

IP

app data

len

TCP

len

IP

len

AH

len

ESP

ESP

app data

len

TCP

len

IP

len

AH

len

ESP

ESP

Without transport
-
mode IPSec

With transport
-
mode IPSec

Simple tunnel
-
mode usage:

gateway
-
to
-
gateway

app data

len

TCP

len

IP

host
-
to
-

host

app data

len

TCP

len

IP

host
-
to
-

host

app data

len

TCP

len

IP

gw
-
to
-

gw

len

ESP

len

IP

host
-
to
-

host

ESP

app data

len

TCP

len

IP

gw
-
to
-

gw

len

ESP

len

IP

host
-
to
-

host

ESP

Other combinations for other
requirements

application data

len

TCP header

len

IP header

srcIP, destIP,

TTL, pktID, …

AH

SPI, seqnum,


MAC, …

MAC scope

application data

len

TCP header

len

IP header

srcIP, destIP,

TTL, pktID, …

ESP

header:

SPI,seqnum

MAC scope

ESP

trailer: pad,

padlen, …

encryption scope

application data

len

TCP header

len

IP header

srcIP, destIP,

TTL, pktID, …

ESP

header:

SPI, seqnum

MAC scope

ESP

auth: MAC

application data

len

TCP header

len

Inner IP header

host
-
srcIP, host
-
destIP,

TTL, pktID, …

AH

SPI, seqnum,

MAC. …

MAC scope

Outer IP header

gw
-
srcIP, gw
-
destIP,

TTL, pktID, …

len

application data

len

TCP header

len

Inner IP header

host
-
srcIP, host
-
destIP,

TTL, pktID, …

AH

SPI,seqnum,

MAC, …

Inner AH MAC scope

Outer IP header

gw
-
srcIP, gw
-
destIP,

TTL, pktID, …

len

ESP

trailer: pad,

padlen…

Outer ESP MAC scope

ESP

header:

SPI,seqnum

encryption scope

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
-
only in transport mode

As for AH
-
transport;
probably worse in all
cases…

AH in tunnel mode

Between
-
gateway VPN with
no overall confidentiality
provision (may be good
performance choice)


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

ESP

auth: MAC

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…

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!


Let’s ignore fragmentation, PMTU discovery, …

Inbound processing


Lookup policy for this datagram


drop, pass through, or process


SA should already exist (we’re the responder)


Apply keys from SA for MAC
-
check and
deciphering (using datagram’s 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!

What can be MAC’ed?


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


IPsec Key Exchange


IKE

or, 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

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)


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

Main Mode IKE Phase 1

using digital signatures

(see
RFC2409, p.11)

Initiator





Responder

HDR, SA_i



--
>





<
--


HDR, SA_r

Headers (HDR) include “cookies” CKY
-
I and CKY
-
R respectively. Initiator’s SA has one or more “proposals”, in
preference order, for algorithms to be used for ISAKMP, the key management channel we’re 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



--
>





<
--


HDR, KE, Nr

Ni, Nr are initiator’s and responder’s nonces, respectively; KE are Diffie
-
Hellman g^x and g^y values

HDR*{IDii, [CERT,] SIG_I}

--
>





<
--

HDR*{IDir, [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, g^x | g^y | CKY
-
I | CKY
-
R | SA_i | IDii )

SIG_R is over HASH_R = prf(SKEYID, g^y | g^x | CKY
-
R | CKY
-
I | SA_i | IDir )

where SKEYID = prf( Ni_b | Nr_b, g^xy ), and prf is the negotiated keyed pseudo
-
random function

Note 3 round
-
trips, 4 DH modular exponentiations, 2 signature
-
generations and 2 signature
-
verifications

Aggressive Mode IKE Phase 1

using public
-
key proof

(see
RFC2409, p.14)

HDR, SA_i, <Ni>Pubkey_r,


<KE>Ke_i, <IDii>Ke_i


--
>

HDR includes CKY
-
I. SA_i has exactly one “take
-
it
-
or
-
leave
-
it” proposal. The nonce Ni is encrypted in the
responder’s public key; KE (that’s g^x) 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.



<
--


HDR, SA_r, <Nr>Pubkey_i, <KE>Ke_r,





<IDir>Ke_r, HASH_R

HDR includes CKY
-
R. SA_r must equal SA_i. Similarly to the initiator’s message, the nonce Nr is encrypted in
the initiator’s public key, while KE (that’s g^y) 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

--
>

The hashes sent in each direction aren’t 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.

Use of Phase 1 agreed material

Key material for the underlying ISAKMP key
-
management SA we’re building first is derived from the shared
-
secret
quantity g^xy and the nonces securely exchanged during Phase 1 as follows:

SKEYID = prf( Ni | Nr, g^xy )

SKEYID_d = prf( SKEYID, g^xy | CKY
-
I | CKY
-
R | “0” )

SKEYID_a = prf( SKEYID, SKEYID_d | g^xy | CKY
-
I | CKY
-
R | “1” )

SKEYID_e = prf( SKEYID, SKEYID_d | g^xy | 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, it’s used as input for the _a and _e pseudo
-
random streams; secondly,
it’s 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 2^56 such keys, so this isn’t 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.

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:


HDR*{HASH(1), SA0, SA1, Ni}

--
>

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.





<
--

HDR*{HASH(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.


HDR*{HASH(3}


--
>

This is a simple acknowledgement that the responder’s message has been received;

HASH(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. There’s an option to include a fresh DH exchange in each Quick Mode if you prefer Forward Secrecy to
computational efficiency...

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 isn’t 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 you’re a US citizen):

http://www.xs4all.nl/~freeswan/