1 6: Securing IP 1 Managing and Securing Computer Networks Guy Leduc Chapter 6: Network Layer Security For a summary, see: Computer Networking: A Top Down Approach, 7 th edition. Jim Kurose, Keith Ross Addison-Wesley, April 2016. (section 8.7) Mainly based on Network Security - PRIVATE Communication in a PUBLIC World C. Kaufman, R. Pearlman, M. Speciner Pearson Education, 2002. (chapters 17 and 18) 6: Securing IP 2 Chapter 6: Network Layer Security Chapter goals: ❒ security in practice: ❍ Security in the network layer (versus other layers) ❍ IPsec
31
Embed
Managing and Securing - Montefiore Instituteleduc/cours/ISIR/GSRI-ch6.pdf · Managing and Securing Computer Networks Guy Leduc ... DNS infrastructure ... IPsec can play a vital role
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Relative Location of Security Facilities in the TCP/IP Stack
❒ Both are general-purpose (i.e. application independent) solutions, but ❒ IPsec is NOT specific to TCP
❍ Does work with UDP, and any other protocol above IP (e.g., ICMP, OSPF) ❒ IPsec protects the whole IP payload, including transport headers (e.g. port #)
❍ Traffic analysis is thus more difficult (could be web, email, …) ❒ IPsec is from network entity to network entity, not from application process
❒ Institutions often want private networks for security ❍ Costly! Separate routers, links, DNS infrastructure
❒ VPN: institution’s inter-office traffic is sent over public Internet instead ❍ Encrypted before entering public Internet ❍ Logically separate from other traffic
sites ❍ Most serious attacks: IP spoofing and packet sniffing ❍ This justified the 2 main functions of IPsec
❒ The security capabilities were designed for IPv6 but fortunately they were also designed to be usable with the current IPv4
❒ IPsec can encrypt and/or authenticate all traffic at the IP level. Thus IPsec provides the capability to secure communications across a LAN, across private and public WANs, and across the Internet ❍ VPN (Virtual Private Networks) ❍ Secure remote access over the Internet ❍ Enhancing Extranet and Intranet connectivity with partners ❍ Enhancing Electronic Commerce
Benefits of IPsec ❒ When IPsec is implemented in a firewall or router, it
provides strong security that can be applied to all traffic crossing the perimeter
❒ IPsec is below the transport layer and so is transparent to applications ❍ No need to change software on a user or server system when
IPsec is implemented in a firewall or router ❍ No need to train users, issue keying material on a per-user basis,
or revoke keying material when users leave the organization ❒ IPsec can provide security to individual users if needed ❒ IPsec can play a vital role in the routing architecture. It
can ensure that: ❍ router and neighbour advertisements come from authorized
routers ❍ a redirect message comes from the router to which the initial
❍ select security protocols, ❍ determine the algorithm(s) to use, and ❍ put in place any cryptographic keys required
❒ IPsec services and their support by AH and ESP
AH ESP ESP encryption only encryption+authentication
Access Control x x x Connectionless integrity x x Data origin authentication x x Rejection of replayed packets x x x Confidentiality x x Limited traffic flow confidentiality x x
Security Association (2) ❒ An SA is uniquely identified by 3 parameters:
❍ Security Parameters Index (SPI): a bitstring assigned to this SA by the receiver end, and having local significance only. Used to select the SA under which a received packet will be processed.
❍ IP Destination Address: can be a router address, can be unicast or multicast.
❍ Security Protocol Identifier: indicates whether the association is an AH or ESP SA
❒ The SPI alone seems to suffice to uniquely identify the SA, but ❍ The same SPI can be assigned to both an ESP SA and an AH SA, so this
security protocol identifier is needed to remove ambiguity ❍ For multicast, the SPI is chosen by the source, so the destination
address field is also needed to remove ambiguity ❒ Hence, in any IP packet, the SA is uniquely identified by these 3
R1 stores for SA: ❒ 32-bit identifier for SA: Security Parameter Index (SPI) ❒ origin SA interface (200.168.1.100) ❒ destination SA interface (193.68.2.23) ❒ type of encryption used (e.g., 3DES with CBC) ❒ encryption key ❒ type of integrity check used (e.g., HMAC with MD5) ❒ authentication key
R1 converts original datagram into IPsec datagram ❒ Appends to back of original datagram (which includes
original header fields!) an “ESP trailer” field ❒ Encrypts result using algorithm & key specified by SA ❒ Appends to front of this encrypted quantity the “ESP
header, creating “enchilada” ❒ Creates authentication MAC over the whole enchilada,
using algorithm and key specified in SA ❒ Appends MAC to back of enchilada, forming payload ❒ Creates brand new IP header, with all the classic IPv4
SA Database (SAD) - More ❒ When sending IPsec datagram, R1 accesses SAD to determine how
to process datagram ❒ When IPsec datagram arrives to R2, R2 examines SPI in IPsec
datagram, indexes SAD with SPI, and processes datagram accordingly
❒ Parameters associated with each SA: ❍ AH information: authentication algorithm, keys, key lifetime, … ❍ ESP information: encryption and authentication algorithm, keys,
initialization values, key lifetimes, … ❍ Sequence number counter: used to generate the sequence number field
in AH and ESP headers ❍ Anti-replay window: used to determine whether an inbound AH or ESP
packet is a replay ❍ Lifetime of the SA ❍ Sequence counter overflow flag: indicates what to do when a counter
overflow occurs (usually close the SA) ❍ IPsec protocol mode: tunnel or transport mode ❍ Path MTU: any observed path maximum transmission unit (to avoid
Security Policy Database (SPD) ❒ Policy: For a given datagram, sending entity needs to know if it
should use IPsec ❍ Needs also to know which SA to use
❒ A nominal Security Policy Database (SPD) defines the means by which IP traffic is related to specific SAs (or possibly to no SA) ❍ Info in SPD indicates “what” to do with arriving datagram ❍ Then info in the SAD indicates “how” to do it
❒ An SPD contains entries, each of which defines a subset of IP traffic (via some IP and upper-layer protocol field values, called selectors) and points to an SA for that traffic
❒ Outbound processing obeys the following general sequence for each packet: ❍ Compare the values of the appropriate fields in the packet (selector
fields) against the SPD to find a matching SPD entry ❍ Determine the SA associated with that entry (if any) and its associated
SPI ❍ Do the required IPsec processing (i.e. AH or ESP processing)
Combining authentication and confidentiality ❒ First method: ESP with authentication
❍ does not authenticate the non mutable parts of the IP header (in transport mode) or new IP header (in tunnel mode)
❍ applies encryption before authentication • so authentication applies to the cyphertext, rather than the plaintext
❒ Second method: ESP (without authentication), then AH ❍ does authenticate the non mutable parts of the IP header ❍ has the disadvantage of using two SAs
❒ Third method: first AH, then ESP (without authentication) ❍ authentication applies to the plaintext
• allows to store the authentication information together with the message (without having to reencrypt the message to verify the authentication)
❍ the authentication header is protected by encryption ❍ still two SAs
❒ Usage of AH and ESP can be in transport or tunnel modes
❒ We clearly need ESP for encryption, but do we need AH?
❒ AH protects the IP header itself. But does IP header protection matter? ❍ If it were necessary, ESP in tunnel mode could provide it ❍ Note that intermediate routers cannot check header
integrity. Why? ❍ So integrity can only be checked at the other end of the SA
❒ Note also that, even with AH, an untrusted source host could still spoof its own IP address ❍ Only integrity is ensured
IPsec and NAT ❒ NAT translates the source IP address and the source
port of the IP packet! ❍ A NAT box actually does IP spoofing
❒ An IPsec SA cannot go through a NAT box ❍ With AH, the integrity check would fail ❍ With ESP, the port number is encrypted ❍ And the NAT box doesn’t have the key
❒ Need to encapsulate IPsec packets in UDP packets:
❒ So, cookies must depend on (i.e. be a keyed hash or an encryption of) the specific parties (IP source and destination addresses, UDP source and destination ports) and a locally generated secret value
c1
c2, c1
DHparam, c2
Improvement: Don’t keep a copy of c2. Possible thanks to the fact that the party can recognise that c2 is one of its own cookies!
But then the scheme is vulnerable to the following attack:
c1
c2, c1
DHparam, c’2
Spoofed IP address
Don’t know c2, but can use another c’2 recorded in a run with my address OK, c’2 is one of my cookies
DH - Defence against Man-in-the-Middle (MIM) (1) ❒ If DH parameters (YA and YB) are permanent and public numbers ❒ And if we can be sure that YA and YB are the numbers reliably
associated with A and B respectively ❍ For example, by means of a PKI (Public Key Infrastructure) ❍ That is the pairs (A, YA) and (B, YB) are certified by some trusted
authority ❍ So-called Fixed DH
❒ Then ❍ The Man-in-the-Middle attack is not possible ❍ And the exchanges of YA and YB can even be eliminated ❍ B will need to fetch the certified YA only once
❒ But this needs a PKI ❍ We lose the simplicity of the original Diffie-Hellman scheme
❒ Also, the fact that YA and YB are permanent makes them more vulnerable to brute-force attacks to find XA and XB
DH - Defence against MIM (2) ❒ Authenticated (Ephemeral) Diffie-Hellman ❒ If A and B know some sort of secret with which they can
authenticate each other (before running DH) ❍ PSK: Knowledge of a (pre-shared) secret key, or ❍ PKI: Knowledge of each other’s public key (and their own private key)
❒ Then they can use this secret to prove it was they who generated their DH values
❒ Several solutions: ❍ Encrypt the DH exchange with the pre-shared secret key ❍ Sign the transmitted DH value (Y) with own private key ❍ Encrypt the DH value (Y) with the other side’s public key
• Why does it work, knowing that anyone can so encrypt? ❍ Following the DH exchange, transmit a hash of the pre-shared key and
the DH value (Y) you transmitted ❍ Following the DH exchange, transmit a hash of the agreed-upon shared
DH value, your name and the pre-shared key ❒ Again this needs a PKI or a pre-shared key ❒ Note that the DH values can be changed often in this case
Back to IKE phase 1 - Authentication ❒ The DH exchange should be authenticated to bar the MIM
attack ❒ Several authentication methods are used
❍ Authentication with a pre-shared key ❍ Authentication based on public key cryptography
• Authentication with signatures • Authentication with public key encryption
❒ But, if one needs public key cryptography anyway, why using DH to generate a shared secret in the first place? ❍ After all, one party could have generated the secret key and sent it
encrypted with the other party’s public key! ❍ With DH, both parties contribute to the shared secret/key. So it
will be random if either side has a good random number generator.
KAB is the calculated DH shared key. Note, both computations in //.
A only reveals her identity here. Moreover, identities are hidden to passive attackers. So, a MIM will only discover A’s id. But could also be hidden. How?
Anonymous DH: no identity revealed, only the IP addresses
Negotiation of the cryptographic methods used in later exchanges
❒ Proof of identity: proof that the sender knows the key associated with the identity, which can be based on
❍ The pre-shared key ❍ The private signature key or encryption key (two pairs of asymmetric keys
are used) ❒ Typically some hash of (1) the key associated with the identity and (2) almost
all fields in previous messages (also provides integrity). With private signature keys, the proof can also be a signature on the fields
❒ Note: in both modes (main and aggressive), nonces are added to messages. ❍ The DH shared key is then computed from the DH values AND the nonces ❍ For example: KAB = hash (nonces, standard DH key)
❒ This allows IKE to reuse the same DH values in successive runs and still generate different shared keys
❍ Protection against replay attack
proof I’m A
B, YB, proof I’m B
A, YA, Crypto_proposalA
Identities revealed, even to passive attackers: no encryption.
How would you change this mode to hide identities to passive attackers (with public keys)?
Take-it-or-leave-it negotiation. In particular, A chooses a (g,p) pair.
• Peers choose their private/public key pairs ❍ they keep the secret key ❍ their public keys must be certified
• Use a notary = Certification Authority = CA • Peer must prove authenticity in front of CA • Notary signs certificates • Peers dynamically exchange certificates • Scalable: n peers requires n authentications and n