Secure Protocols and VPNs

Document Sample
Secure Protocols and VPNs Powered By Docstoc
					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
                                                                                                        TCP header
Application layer: lots of protocols, e.g.                                                                                       application data




                                                                                                                           len
                                                                                                          port, seqnum,

HTTP carrying Web traffic, SMTP carrying
                                                                                                        SYN, ACK, FIN, …


email, NNTP carrying News, …
                                                                                IP header               TCP header
                                                                                                                                 application data




                                                                                                  len




                                                                                                                           len
                                                                                srcIP, destIP,            port, seqnum,
                                                                                TTL, pktID, …           SYN, ACK, FIN, …

Transport layer: TCP - reliable connections
(sequence nums, retransmission), carries
HTTP, FTP, Telnet, …; UDP – unreliable        Ethernet header                   IP header               TCP header
                                                                                                                                 application data




                                                                          len




                                                                                                  len




                                                                                                                           len
                                                                                srcIP, destIP,            port, seqnum,
datagrams, e.g. streaming audio/video
                                              ether-addr, checksum, …
                                                                                TTL, pktID, …           SYN, ACK, FIN, …




                                                  X.25 header                   IP header’              TCP header
Network (IP) layer: “is” Internet. Carries:                                                                                      application data




                                                                          len




                                                                                                  len




                                                                                                                           len
                                                                                 srcIP, destIP,           port, seqnum,
                                                  Virtual-circuit-ID, …
                                                                                TTL-n, pktID, …         SYN, ACK, FIN, …
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
                                                                  IP header                   TCP header
                                                                                                                       application data                                Original unprotected




                                                                                        len




                                                                                                                 len
                                                                  srcIP, destIP,                port, seqnum,
                                                                  TTL, pktID, …               SYN, ACK, FIN, …
                                                                                                                                                                             datagram


                                                IP header                          AH
                                                                                              TCP header               application data                                 AH in transport mode



                                                                        len




                                                                                                                 len
                                                 srcIP, destIP,               SPI, seqnum,
                                                 TTL, pktID, …                  MAC, …

                                                                                              MAC scope

                                                IP header                       ESP                                                         ESP            ESP          ESP (conf and auth)
                                                                                              TCP header               application data
                                                                        len




                                                                                                                 len
                                                 srcIP, destIP,                 header:                                                   trailer: pad,
                                                 TTL, pktID, …                SPI,seqnum                                                  padlen, …
                                                                                                                                                          auth: MAC
                                                                                                                                                                         in transport mode
                                                                                                  MAC scope

                                                                                                            encryption scope

                                                IP header                       ESP                                                         ESP                            ESP auth-only
                                                                                              TCP header               application data
                                                                        len




                                                                                                                 len
                                                 srcIP, destIP,                 header:
                                                 TTL, pktID, …                SPI, seqnum
                                                                                                                                          auth: MAC                      in transport mode
                                                                                              MAC scope


             Outer IP header                    AH          Inner IP header
                                                                                              TCP header               application data                                  AH in tunnel mode
                                       len




                                                                                        len




                                                                                                                 len



                gw-srcIP, gw-destIP,         SPI, seqnum,    host-srcIP, host-destIP,
                   TTL, pktID, …               MAC. …             TTL, pktID, …

                                                                                              MAC scope


Outer IP header                 ESP          Inner IP header                       AH                                                       ESP                           ESP I(conf and auth) in
                                                                                                                                                            ESP
                                                                                              TCP header               application data                                         tunnel mode
                        len




                                                                        len




                                                                                                                 len




 gw-srcIP, gw-destIP,           header:      host-srcIP, host-destIP,         SPI,seqnum,                                                 trailer: pad,    auth: MAC
    TTL, pktID, …             SPI,seqnum          TTL, pktID, …                MAC, …                                                      padlen…
                                                                                                                                                                       carrying AH in transport mode
                                                                               Inner AH MAC scope
                                                                                   Outer ESP MAC scope
                                                                                                        encryption scope
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)

                IP          TCP         app data
                      len



                                  len




                                                                                                   IP          TCP         app data




                                                                                                         len



                                                                                                                     len
                                                          Without transport-mode IPSec




                             With transport-mode IPSec



IP         AH         ESP         TCP         app data   ESP
     len



                len



                            len



                                        len




                                                                             IP         AH         ESP         TCP         app data   ESP
                                                                                  len



                                                                                             len



                                                                                                         len



                                                                                                                     len
                     Simple tunnel-mode usage:
                        gateway-to-gateway

                 IP
                                                                                        IP
                                TCP            app data
                          len



                                        len




               host-to-
                                                                                                        TCP              app data




                                                                                                 len



                                                                                                               len
                host                                                                  host-to-
                                                                                       host




 IP                           IP                                            IP                            IP
               ESP                            TCP         app data   ESP                  ESP                            TCP         app data   ESP
         len



                      len



                                       len



                                                    len




                                                                                    len



                                                                                                  len



                                                                                                                   len



                                                                                                                               len
gw-to-                      host-to-                                       gw-to-                       host-to-
 gw                          host                                           gw                           host
                                  Other combinations for other
                                         requirements
                                                                                                                                                                       AH in transport mode
                                                                                                                                                                   Host-to-host auth-only,
                                                IP header                        AH
                                                                                              TCP header         application data                                e.g. network management?



                                                                        len




                                                                                                           len
                                                 srcIP, destIP,               SPI, seqnum,
                                                 TTL, pktID, …                  MAC, …

                                                                                              MAC scope
                                                                                                                                                                  ESP (conf and auth) in transport
                                                IP header                       ESP                                                   ESP                                     mode
                                                                                                                                                     ESP
                                                                                              TCP header         application data                                Host-to-host secure channel,
                                                                        len




                                                                                                           len
                                                 srcIP, destIP,                 header:                                             trailer: pad,   auth: MAC
                                                 TTL, pktID, …                SPI,seqnum                                            padlen, …
                                                                                                                                                                  e.g. encapsulated legacy
                                                                                                MAC scope
                                                                                                                                                                            apps?
                                                                                                      encryption scope
                                                                                                                                                                  ESP auth-only in transport mode
                                                IP header                       ESP                                                   ESP
                                                                                                                                                                      As for AH-transport;
                                                                                              TCP header         application data
                                                                        len




                                                                                                           len
                                                 srcIP, destIP,
                                                 TTL, pktID, …
                                                                                header:
                                                                              SPI, seqnum
                                                                                                                                    auth: MAC                         probably worse in all
                                                                                              MAC scope                                                                     cases…
                                                                                                                                                                         AH in tunnel mode
                                                                                                                                                                 Between-gateway VPN with
             Outer IP header                    AH          Inner IP header
                                                                                              TCP header         application data                                 no overall confidentiality
                                       len




                                                                                        len




                                                                                                           len



                gw-srcIP, gw-destIP,         SPI, seqnum,    host-srcIP, host-destIP,
                   TTL, pktID, …               MAC. …             TTL, pktID, …
                                                                                                                                                                   provision (may be good
                                                                                              MAC scope                                                             performance choice)
                                                                                                                                                                         ESP in tunnel mode
Outer IP header                 ESP          Inner IP header                     AH                                                   ESP                           carrying AH in transport mode
                                                                                                                                                      ESP
                                                                                              TCP header         application data                                   Common “road warrior”
                        len




                                                                        len




                                                                                                           len




 gw-srcIP, gw-destIP,           header:      host-srcIP, host-destIP,         SPI,seqnum,                                           trailer: pad,    auth: MAC
    TTL, pktID, …             SPI,seqnum          TTL, pktID, …                MAC, …                                                padlen…
                                                                                                                                                                     VPN: secure channel
                                                                               Inner AH MAC scope
                                                                                   Outer ESP MAC scope
                                                                                                                                                                   across public network, and
                                                                                                                                                                       strong, continuing
                                                                                                    encryption scope
                                                                                                                                                                      authentication to end
                                                                                                                                                                           system(s)
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/

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:9/6/2011
language:English
pages:29