Network Security Standards Design Fundamentals ET-IDA-082 Lecture-17 Network Security Standards IPSec, Kerberos 26.06.2019, v19 Prof. W. Adi

Outlines Network Security Standards IPSEC Kerberos Recommended reference: Network Security: Private Communication in a Public World (Prentice Hall Series in Computer Networking) Charlie Kaufman, Radia Perlman, Mike Speciner. 2nd Ed. 2002

IPSec

IPSec and SSL IPSec lives at the network layer application transport network link physical User SSL OS IPSec lives at the network layer IPSec is transparent to applications IPSec NIC

IPSec and Complexity IPSec is designed by a large group of experts resulting by a complex protocol Over-engineered Lots of extra features Some security issues Some Interoperability issues In general complex

IKE and ESP/AH Need Two steps to operate IPSec IKE: Internet Key Exchange Mutual authentication Establish shared symmetric key Two “phases”  like SSL session/connection ESP/AH ESP: Encapsulating Security Payload for encryption and/or integrity of IP packets AH: Authentication Header - integrity only (without encryption)

IKE (Internet Key Exchange) IKE has 2 phases Phase 1  IKE security association (SA) Phase 2  AH/ESP security functions Phase 1 is comparable to SSL session Phase 2 is comparable to SSL connection

IKE Phase 1 Four different “key” options Public key encryption (original version) Public key encryption (improved version) Public key with signature Symmetric key For each of these, there are two different “modes” Main mode Aggressive mode There are 8 versions of IKE Phase 1!

IKE Phase 1 We discuss just 1 of 8 phase 1 variants Public key signatures, in both main and aggressive modes Uses a type of Diffie-Hellman technique to establish session key Let g be generator (primitive element) and p prime Let a be Alice’s Diffie-Hellman exponent ( a’s secret key) Let b be Bob’s Diffie-Hellman exponent ( b’s secret key) Recall that p [GF(p) ] and g (primitive element) are public Notice: p, g as well as ga and gb have to be certified (trustable)!

IKE Phase 1: Digital Signature (Main Mode) IC, CP IC,RC, CS Alice Bob IC,RC, ga mod p, RA IC,RC, gb mod p, RB IC,RC, E(“Alice”, proofA, K) Notice: No Identity need to appear In clear on the open network channel! IC,RC, E(“Bob”, proofB, K) CP = crypto proposed, CS = crypto selected IC = initiator “cookie”, RC = responder “cookie” Session key K = h(IC,RC, gab mod p, RA, RB) proofA = { h(SKEYID,ga,gb,IC,RC,CP,“Alice”) }Alice Where SKEYID = h(RA, RB, gab mod p) IC: initiator cookie- An 8-byte pseudo-random number used for anti-clogging

IKE Phase 1: Public Key Signature (Aggressive Mode) Alice Bob IC, “Alice”, ga mod p, RA, CP IC,RC, “Bob”, RB, gb mod p, CS, proofB IC,RC, proofA Session key K = h(IC,RC, gab mod p, RA, RB) CP = crypto proposed CS = crypto selected IC = initiator “cookie” RC = responder “cookie” Main difference from main mode User Identities are not hidden (IDs are sent in clear) Cannot negotiate g or p Notice: Identity appears In clear on the open network channel!

Main vs Aggressive Modes Main mode MUST be implemented Aggressive mode SHOULD be implemented Recommended to be implemented For public key signature authentication Passive attacker knows identities of Alice and Bob in aggressive mode Active attacker required to determine Alice’s and Bob’s identity in main mode

Security Association (SA) Data SA: is the initial agreement negotiated between the communicating parties which defines: mode of authentication algorithm used in the AH and keys to be used mode of encryption algorithm used in the ESP and the keys to be used Managing cryptographic synchronisation if any the key lifetime the lifetime of the SA itself In Summary the SA defines user security profiles Security level agreed on

Summary: IPSec Initiation After IKE Phase 1, we have an IKE and SA After IKE Phase 2, we have an IPSec and SA Both sides have a shared symmetric key The use of shared key Is to encrypt and protect IP datagrams But what is an IP datagram? From the perspective of IPSec…

IP Datagram Review IP datagram is of the form IP header data Where IP header is

Authentication Header AH Location: IP Header Auth. Header TCP Header Data IPv4 Paket mit AH Transport Mode IP Header Extension Header Auth. Header Extension Header TCP Header Data IPv6 Paket mit AH Transport Mode

Authentication Header AH Security Parameter Index Next Header indicates which higher level protocol follows the AH Payload Length 8-bit field specifying the size of the AH,as a multiple of 32-bit words. Reserved for future use and is currently always set to zero. Security Parameter Index (SPI) 32-bit specifies what group of security protocols the sender is using (which algorithms, keys, their life time) The sequence number gives the number of packet sent by given SPI (to resist replay attacks) ICV (Integrity Check Value) The ICV is a digital signature over the whole IP packet. may contain some padding to bring the header to an integral multiple of 32-bits in (IPv4) or 64-bit in (IPv6) 7 15 31 Next Header Payload Length Reserved Security Parameter Index Sequence Number Authentication Data (ICV) Integrity Check Value

Computation of (ICV) Integrity Check Value Includes/uses the following data: IP header fields which do not change during transmission like the version number, header length, source address. IP header fields which may change but whose final value at the destination can be deduced with certainty. These include the destination address with loose or strict source routing. All other upper layer data Do not Include changing entities: As time to live field, etc ..

Example Computation of ICV MAC: Message Authentication Code e.g MD5 Hashing Function Used as Hash functions? 128 Bit Message Digest ICV SecretKey Ka SecretKey Ka Secret Key IP Header Upper Layer Data Secret Key IP Header Upper Layer Data Sent IP-Packet

Properties of Hashing Functions One-Way Function. Collision-free for change of a single bit Collision-free for permutation of two single bits Sensitive to payload length First IPSec standard specifies SHA-1 and MD5 as mandatory Hash algorithms for authentication (Both are not more up to date)

Encapsulating Security Payload ESP SPI Identifies a set of security parameters (algorithms and keys) The sequence number gives the number of packet sent by given SPI, to (resist replay attacks) The Payload Data actual data being carried Padding 0 to 255 bytes of random padding pattern to confuse attacker Pad length Length of padding pattern Next Header Specifies the header type which follows ICV A digest of whole ESP packet (IP header is not included in ICV) as integrity check. ESP Header 7 15 31 SPI Security Parameter Index Sequence Number Payload Data PAD Length Next Header ESP Authentication Data (ICV)

AH vs ESP AH: Authentication Header Integrity only (no confidentiality) Integrity-protect everything beyond IP header and some fields of header ESP: Encapsulating Security Payload Integrity and confidentiality Protects everything beyond IP header

Why Does AH Exist? IP header cannot be encrypted as: Routers must look at the IP header IP addresses, TTL (time to live), etc. IP header exists to route packets! AH protects only immutable fields in IP header Cannot protect the integrity of all header fields TTL (Time To Live), for example must change ESP: does not protect IP header at all IPSEC is widely in use today!

Kerberos Kerberos Hades

Kerberos In Greek mythology, Kerberos is 3-headed dog that guards entrance to Hades In security, Kerberos is an authentication system based on symmetric key crypto Originated at MIT Based on work by Needham and Schroeder (1978) Relies on a trusted third party (TTP) for key management

Motivation for Kerberos Authentication using public keys requires N users  N key pairs Authentication using symmetric keys requires N users requires about N2 /2 keys Symmetric key case does not scale! Kerberos is based on symmetric keys but requires only N keys for N users! But must rely on TTP (Trusted Third Party) as a KDC (Key Distribution Center) Advantage is that no complex PKI is required (PKI: Public Key Infrastructure)

Kerberos KDC Kerberos Key Distribution Center or KDC Acts as a TTP (Trusted Third Party) TTP assumed to be secure and not compromised! KDC shares secret symmetric key KA with Alice, key KB with Bob, key KC with Carol, etc. Master key KKDC known only to KDC KDC enables authentication and generating session keys Keys for confidentiality and integrity In practice, the basic crypto algorithm used is DES

Kerberos Tickets KDC issues a ticket containing info needed to access a network resource KDC also issues ticket-granting tickets or TGTs that are used to obtain tickets Each TGT contains Session key User’s ID Expiration time Every TGT is encrypted with KKDC TGT can only be read by the KDC

Kerberized Login Alice enters her password… …then Alice’s workstation Derives KA from Alice’s password Uses KA to get TGT for Alice from the KDC Alice can then use her TGT (credentials) to securely access network resources Plus: Security is transparent to Alice Minus: KDC must be secure  it’s trusted!

Step 1: Kerberized Login (Ticket Granting Ticket : TGT ) KDC Alice wants Alice’s Password a TGT Alice’s Secret key is: KA = h(Password) Alice M1=E(SA,TGT,KA) SA,TGT are encrypted By using the key KA Alice decrypts M1 to get: SA,TGT Computer Login steps: Alice secret key KA derived from Alice’s password KDC creates a fresh session key SA to communicate with A. and TGT Computer/Workstation decrypts SA, TGT by using the secret key KA Now Alice has a TGT = E(“Alice”,SA, KKDC) and SA E(X,Y,Z, K) means that data XYZ are encrypted using the key K

Step 2: Alice Requests Ticket to Bob I want to talk to Bob Computer KDC REQUEST= (TGT, authenticator) Talk to Bob REPLY = E(“Bob”,KAB, ticket to Bob, SA) Alice REQUEST = (TGT, authenticator) where authenticator = E(timestamp, SA) KDC gets SA from TGT to verify Alice timestamp REPLY = E(“Bob”,KAB, ticket to Bob, SA), where KAB proposed key for AB-link ticket to Bob = E(“Alice”,KAB,KB) generated by KDC TGT = E(“Alice”,SA, KKDC)

Step 3: Alice Communicates with Bob ticket to Bob = E(“Alice”,KAB,KB), authenticator = E(timestamp, KAB) E(timestamp + 1,KAB) Bob (Knows KB From KDC ) Alice’s Computer (Session key KAB = shared authenticated secret key) Secured A-B link between A and B Alice sends ticket to Bob = E(“Alice”,KAB, KB) and authenticator = E(timestamp, KAB) Bob decrypts “ticket to Bob” to get KAB which he then uses to verify Alice’s timestamp. Then authenticates himself by sending back encrypted (timestamp+1) by KAB. Notice: KDC has full access to the built A-B link

Kerberos Session key SA used for authentication Can also be used for confidentiality/integrity Timestamps used for mutual authentication Recall that timestamps reduce number of messages Acts like a nonce that is known to both sides Note: time is a security-critical parameter!

KERBEROS Versions Two Versions available V4 and V5 .. etc Difference Between Version 4 and 5 Encryption system dependence (V.4 DES) Internet protocol dependence Message byte ordering Ticket lifetime Authentication forwarding Interrealm authentication

Request for Service in Another Realm Kerberos V5 Realm A Realm B

Kerberos - in practice Currently have two Kerberos versions: V4 : restricted to a single realm V5 : allows inter-realm authentication Kerberos v5 is an Internet Standard Specified in RFC1510, and used by many utilities To use Kerberos: need to have a KDC on your network (TTP) need to have Kerberised applications running on all participating systems US export restrictions: Kerberos cannot be directly distributed outside the US in source format (& binary versions must obscure crypto routine entry points and have no encryption) else crypto libraries must be reimplemented locally

Kerberos Ciphering PCBC Mode (PCBC: Propagating Cipher Block Chaining

Conclusion TCP/IP very flexible TCP/IP not designed for security Highly “hackable” SSL, IPSec, Kerberos etc., help But many problems still remain