1. CS 5950/6030 Network Security Class 31 (F, 11/11/05) Leszek Lilien Department of Computer Science Western Michigan University Based on Security in Computing. Third Edition by Pfleeger and Pfleeger. Using some slides (as indicated) courtesy of: Prof. Aaron Striegel — at U. of Notre Dame Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke — at U. Washington Prof. Jussipekka Leiwo — at Vrije Universiteit (Free U.), Amsterdam, The Netherlands Slides not created by the above authors are © by Leszek T. Lilien, 2005 Requests to use original slides for non-profit purposes will be gladly granted upon a written request.

2. 2 7. Security in Networks... 7.2. Threats in Networks... 7.3. Networks Security Controls a)Introduction b)Security threat analysis c)Impact of network architecture/design and implementation on security—PART 1 c)Impact of network architecture/design and implementation on security—PART 2 d)Encryption i.Link encryption vs. end-to-end (e2e) encryption ii.Virtual private network (VPN) iii.PKI and certificates —PART 1 Class 30 © by Leszek T. Lilien, 2005

3. 3 c. Impact of network architecture/ design & implement. on security (1)  Security principles for good analysis, design, implementation, and maintenance (as discussed in sections on Pgm Security and OS Security) apply to networks  Architecture can improve security by: 1) Segmentation 2) Redundancy 3) Single points of failure 4) Other means © by Leszek T. Lilien, 2005

4. 4 d. Encryption  Arguably most important/versatile tool for network security  We have seen that it can be used for:  Confidentiality/Privacy  Authentication  Integrity  Limiting data access  Kinds of encryption in networks: i.Link encryption vs. end-to-end (e2e) encryption ii.Virtual private network (VPN) iii.PKI and certificates iv.SSH protocol v.SSL protocol (a.k.a. TLS protocol) vi.IPsec protocol suite vii.Signed code viii.Encrypted e-mail © by Leszek T. Lilien, 2005

5. 5 (i) Link vs. end-to-end encryption (1) 1)Link encryption = between 2 hosts  Data encrypted just before they are placed on physical communication links  At OSI Layer 1 (or, perhaps, Layer 2)  Fig. 7-21, p. 431  Properties of link encryption (cf. Fig. 7-21)  Msgs/pkts unprotected inside S’s/R’s host  I.e., unprotected at OSI layers 2-7 of S’s/R’s host (in plaintext)  Packets protected in transit between all hosts  Pkts unprotected inside intermediate hosts  I.e., unprotected at OSI layers 2-3 of interm. hosts => unprotected at data link and network layers at intermediate hosts (if link encryption at Layer 1)  Layers 2-3 provide addressing and routing © by Leszek T. Lilien, 2005

6. 6 (ii) Virtual private network (VPN) (1)  Virtual private network (VPN) = connection over public network giving its user impression of being on private network  It could be viewed as „logical link” encryption Could be viewed as e2e encr. between client & server  Protecting remote user’s connection with her network  Greatest risk for remote connection via public network:  Between user’s workstation (client) and perimeter of „home” network (with server)  Firewall protects network against external traffic (more later) Physically Protected Network Perimeter Firewall Internal Server User’s Workstation (Client) © by Leszek T. Lilien, 2005

7. 7 (iii) PKI and certificates (1)  Public key infrastructure (PKI) = enables use of public key cryptography (asymmetric cryptography)  Usually in large & distributed environment  Elements of PKI: 1) Policies (higher level than procedures)  Define rules of operation  E.g., how to handle keys and sensitive info  E.g., how to match control level to risk level 2) Procedures (lower level than policies)  Dictate how keys should be generated, managed, used 3) Products  Implement policies and procedures  Generate, store, manage keys © by Leszek T. Lilien, 2005

8. 8 PKI and certificates (2)  PKI services: 1) PKI creates certificates  Certificate binds entity’s identity to entity’s public key  Entity = user or system or applicationor... 2) PKI gives out certificates from its database 3) PKI signs certificates  Adding its credibility to certificate’s authenticity 4) PKI confirms/denies validity of a certificate  When queried about it 5) PKI invalidates certificates  For entities that are no longer certified by PKI OR  For entities whose private key has been exposed © by Leszek T. Lilien, 2005

9. 9 Class 30 Ended Here © by Leszek T. Lilien, 2005

10. 10 7. Security in Networks... 7.2. Threats in Networks... 7.3. Networks Security Controls... c) Impact of network archit./design and implem. on security—PART 2 d)Encryption i.Link encryption vs. end-to-end (e2e) encryption ii.Virtual private network (VPN) iii.PKI and certificates—PART 1 iii.PKI and certificates—PART 2 iv.SSH protocol v.SSL protocol (a.k.a. TLS protocol) vi.IPsec protocol suite—PART 1 Class 30 © by Leszek T. Lilien, 2005 Class 31

11. 11 PKI and certificates (3)  PKI sets up: 1) Certificate authorities (CAs) 2) Registration authority 1) Certificate authority (CA)  CA can be in-house or external (commercial TTP = trusted third party)  CA is trusted  Entities delegate to CA creation, issuance, acceptance, and revocation of their certificates  CA actions:  Managing public key certificates (whole life cycle)  Issuing certificates by binding entity’s identity to its public key  Binding is done via CA’s digital signature  Determining expiration dates for certificates  Revoking certificates when necessary  By publishing revocation lists © by Leszek T. Lilien, 2005

12. 12 PKI and certificates (4)  Example of CA analog: credit card company (CCC) Certificate analog: credit card (binds identity to account) Revocation list analog: lists of invalid credit cards  CCC is trusted  Customers delegate to CCC creation, issuance, acceptance, and revocation of their credit cards  CCC actions:  Managing credit cards (whole life cycle)  Issuing credit cards by binding customer’s identity to customer’s account  Binding is done via CCC’s protected databases  Determining expiration dates for credit cards  Revoking credit cards when necessary  By checking list of invalid credit cards (before computer-verification transaction era, CCC published booklets of invalidated credit cards) © by Leszek T. Lilien, 2005

13. 13 PKI and certificates (5) 2) Registration authority (RA) = interface between user and CA  Duties:  Capture and authenticate user’s identity  Submit certificate requests to appropriate CA  Analog: U.S. Citizen applying for passport and U.S. Postal Service (USPS) Passport (official U.S. authentication) certificate  USPS authenticates citizen  By verifies citizen’s driver license + other proofs of identity  USPS submits passport request forms to appropriate passport office of the U.S. Gov’t  Passport office CA  USPS brings passport to customer’s home  Note: Trustworthiness of USPS authentication determines level of trust that can be placed in passports © by Leszek T. Lilien, 2005

14. 14 PKI and certificates (6)  PKI efforts stateside and overseas  Building PKI for various purposes  E.g., Federal PKI Initiative – to provide secure communication to U.S. gov’t agencies  It also specifies how commercial s/w using PKI should operate (so gov’t can use off-the-shelf products)  Major PKI product vendors in the U.S.:  Baltimore Technologies  Northern Telecom/Entrust  Identrus  Certificates can bind:  Identity to public key – classic, most common  Other bindings under research  E.g., binding financial status to key (credit card companies)  Draft standards: ANSI X9.45, Simple Public Key Infrastructure (SPKI) © by Leszek T. Lilien, 2005

15. 15 PKI and certificates (7)  PKI is not yet mature  Many outstanding issues  Cf. Table 7-6, p. 439 Still, many points are clear :  CA should be approved/verfied by independent body  CA’s private keys must be stored in tamper-resistant security module (maybe with h/w support)  Access to CAs and RAs should be tightly controlled  Using strong authentication (e.g., 2FA or 3FA with smart cards) © by Leszek T. Lilien, 2005

16. 16 (iv) SSH protocol (SSH = Secure SHell)  SSH protocol (newer: v.2) – provides authenticated and encrypted communication with shell/OS command interpreter  Originally defined for Unix  Replaced insecure utilities for remote access  Such as Telnet / rlogin / rsh  Protects against spoofing attacks (falsifying one end of communication, incl. masquerading, sesssion hijacking, MITM) & message modification / falsification  Involves negotiation between local and remote sites  Negotiate which encryption algorithm to use  E.g., DES? IDEA? AES?  Negotiate which authentication technique to use  E.g., public key? Kerberos? © by Leszek T. Lilien, 2005

17. 17 (v) SSL protocol (a.k.a. TLS prot.) (1)  SSL protocol (v3) = (approx.) TLS protocol - interfaces betwen app (on client C) and TCP/IP protocols to provide server S authentication, optional C authentication, and encrypted communication channel between C and S for session between C and S SSL = Secure Sockets Layer / TLS = Transport Layer Security  Originally defined by Netscape to protect browser-to-server communication  Simple but effective – most widely used secure commu- nication protocol on Internet (incl. WWW browsers/servers)  Involves negotiation between C and S  Negotiate which encryption suite to use for session  E.g., DES? RC4 w/ 128-bit/40-bit key? RC2? Fortezza? [Bishop]  Negotiate which hashing technique to use for session  E.g., SHA1 or MD5? © by Leszek T. Lilien, 2005

18. 18 SSL protocol (a.k.a. TLS protocol) (2)  SSL use scenario (handshake protocol)  C requests an SSL session by sending: Hello-C, Rand-C (random nr), list of cipher (encryption) algorithms & hash algorithms known to C  Hash used to checksum messages  S responds with msgs including: Hello-S, Rand-S, cipher & hash algorithm selected by S (from C’s list), S’s certificate, K PUB-S, [OPTIONAL: request for cert. fr. C]  C can use S’s certificate (X.509v3 cert.) to verify S’s authenticity  [OPTIONAL: C replies with: C’s certificate]  C returns „pre-master secret” encrypted under K PUB-S  Pre-master secret - e.g., 48 random B if selected cipher is RSA [Bishop- CompSec-A&S, p.296]...continued... © by Leszek T. Lilien, 2005

19. 19 SSL protocol (a.k.a. TLS protocol) (3)...continued...  C and S calculate „master secret” using:  „Pre-master secret”  Constant strings ‘A’, ‘BB’ and ‘CCC’  Rand-C and Rand-S,  SHA hashing algorithm [ibid, p. 294]  C and S switch to encrypted communication using „master secret” as session key  C and S exchange application data for session duration (i.e., for as long as they stay connected)  TLS is potentially vulnerable to MITM attacks [Conklin eta al., p.163] © by Leszek T. Lilien, 2005

20. 20 (vi) IPsec protocol suite (1)  IPsec (IP Security Protocol Suite) = standard for securing IP communications by encrypting and/or authenticating all IP packets  IPsec is public (published / scrutinized)  By design, protects against threats including: spoofing (incl. session hijacking) / eavesdropping  Choice of ciphers/hash protocols  Communicating parties negotiate which ones to use  IPsec defines some ciphers/hash as required in every IPsec implementaion © by Leszek T. Lilien, 2005

21. 21 IPsec protocol suite (2)  IPsec provides security at IP layer in IPv6 or IPv4 [Stall.p.499]  IP versions:  IPv4 = v.4 — older IP protocol version (still in use)  IPv6 = v.6 — newer IP protocol version  IPv6 — larger address space  Developed (1992-1998) since IPv4 runs out of address space — IPv4 has 32-bit source/destination addresses — IPv6 has 128-bit source/destination addresses  IPv6 — also other functional enhancements  To accommodate faster networks  To accommodate mix of multimedia data streams  IPsec protects all layers above IP layer (where it „resides”)  In particular, protects TCP or UDP protocols  Protects „automatically”  Protects transparently (no modifications to TCP, UDP needed) © by Leszek T. Lilien, 2005

22. 22 IPsec protocol suite (3)  Basis of IPsec: security association (SA) = set of security parameters for a secured 1-way communication channel  2 SAs needed for 2-way communication [St,487]  Components of SA: 1)Encryption algorithm and „mode”  E.g., for DES, mode = CDC – cipher bloc chaining 2)Encryption key 3)Encryption params (e.g., initialization vector for encryption) 4)Authentication protocol and key 5)SA lifespan  Allows long-running sessions to select new crypto key 6)Address of opposite end of SA (source destination) 7)Sensitivity level of protected data  (e.g., unclassified / restricted / confidential / secret / top secret) © by Leszek T. Lilien, 2005

23. 23 IPsec protocol suite (4)  Security parameter index (SPI) data structure  Resides on each host H running IPsec  Used to select 1 of n SAs that exist on H  Different SAs for concurrent communications with different remote Hs  Fundamental IPsec data structures / protocols 1) AH = authentication header / AH protocol  For authentication-only IPsec service:  Authenticates S (sender ) 2)ESP = encapsulated security payload / ESP protocol  For encryption-only IPsec service OR  For combined encryption/authentication IPsec service © by Leszek T. Lilien, 2005

24. 24 IPsec protocol suite (5)  IPsec can be used for various crypto sessions:  VPN  e2e (incl. app 2 app)  For network mgmt (e.g., for routing)  IPsec scenario  TCP layer passes conventional TCP Header & Data down to IP layer  IP layer calls upon IPsec to encapsulate conventional TCP Header & Data into ESP (encapsulated security payload)  Fig. 7-28, p. 441  IP layer adds IP Header  IP layer passes packet down to physical layer  Physical layer adds Physical Header & Physical Trailer © by Leszek T. Lilien, 2005

25. 25 End of Class 31 © by Leszek T. Lilien, 2005