1. Network Security

2. Today’s Universities Campus Perimeter Security
Anti-virus system
Firewalls
Anti-virus system
100 %
Remote access VPN, using IPSEC
Access control
Firewalls
96.2 %
Content filtering
Remote access VPN,
using IPSEC
Intrusion Detection System
78.8 %
Remote access VPN using SSL
Other
Access control
78.8 %
Content filtering
55.8 %
Intrusion Detection System
57.7 %
Remote access VPN
using SSL
25 %
Other *
11.5 %
* Other includes packet shapers, proxy servers and smart-card authentication.

3. Security challenges for remote offices
53.8 %
51.9 %
42.3 %
36.5 %
21.2 %
Lack of personnel/expertise
Complexity
Solution costs are too high
Lack of one-stop shopping from vendors
Management costs are too high

4. Agenda
NAT – the most common and quite effective zero-mainetnance firewall
PacketFilters and RealFirewalls
SSL/TLS: transport layer security
Easy to use
CA infrastructure
SSH
IPSec: network layer security (VPN)
Difficult to deploy
Transport or Tunnel mode

5. Use of Private Addresses
Routers in the public Internet will not route packets whose destination are private addresses
/8,
/12,
/16
However, it is possible for routers in a private network to route packets with private addresses
The same private addresses can be reused in different private networks

8. Network Address Port Translation (NAPT or Masquerading)

10. Network Address Translation
NAT is a major problem for media communications!
NAT:

11. Types of NAT
Full Cone
Restricted Cone
Port Restricted Cone
Symmetric

12. Full Cone
Any computer can send back data to an open port.

13. Restricted Cone
Any computer can send back data to an open port AFTER we send data to their IP.

14. Port Restricted Cone
Same as restricted cone but we need to first send data to their IP AND the port that will be allowed to send back.

15. Symmetric

16. Typical Call Setup
The Location Service is being queries to check that the destination IP address represents a valid registered device, and for its IP Address
DNS Server
DNS Query for the IP Address of the SIP Proxy of the Destination Domain
Location Service
The INVITE is forwarded 2 4 3
A request is sent (SIP INVITE) to ESTABLISH a session
SIP Proxy 5
The request is forwarded to the End-Device
SIP Proxy 1
SIP IP Phone 6
SIP IP Phone
Media Transport
Destination device returns its IP Address to the originating device and a media connection is opened

17. SIP Signaling and NAT SIP itself is usually not the problem.
The UAC/proxy/etc just send back SIP packets based on the “rport“ tag (the received data)
SIP signaling intervals need to be shorter than NAT timeout time.

18. Simple NAT Scenario (Bob sending data)
Private address space
Public Internet
Alice
NSIS
NAT
Bob
Application-level signaling
NSIS signaling (Reserve Mode)
Data
NSIS signaling (Create Mode)

19. STUN Tests
4 tests needed.

20. RTP-gateway

21. NAT Limitations Applications with IP-address content
Need AGL (Application Level Gateway)
Applications with inter-dependent control and and data sessions
Translation of fragmented FTP control packets
NAT device can be a target for attacks

22. Packet Filtering Packet filtering Session filtering
Access Control Lists
source/destination IP address
source/destination TCP/UDP port
protocol (TCP, UDP, ICMP, GRE,...)
IP/TCP header bits (fragmentation, QoS, Established)
Session filtering
Dynamic Packet Filtering
Stateful Inspection
Smart packet filtering
Context Based Access Control

26. SSL/TLS and IPSec

27. IPSec Security at the network layer
Can hide data and destination ports
Don’t have to rewrite applications
Using security gateways in tunnel mode, can be done without reconfiguring hosts.

28. IPSec Architecture

29. Tunnel and Transport Mode
Authentication Header (AH)
Authenticates the sender
Encapsulating Security Payload (ESP)
Data encryption
Can be done in two ways:
Transport mode: only the transport layer segment is encrypted
Tunnel mode
encrypt the entire IP datagram
put it inside another IP datagram

30. Tunnel Mode

31. SSL and TLS SSL designed by Netscape TLS IETF standard
compromise between SSL and a Microsoft protocol
SSL and TLS provide applications:
Encryption
Server authentication
(Optional) client authentication
SSL programming libraries are pretty easy to use

32. SSL Data Processing

33. SSL Record Format

34. SSL Handshake Pretty complicated Server (and client) authentication
why HTTPS websites seem sooooooo slow.
Server (and client) authentication
Negotiation of:
Encryption algorithm
MAC algorithm
Encryption key
Must be done before any data transmission

35. SSL/TLS Overview SSL = Secure Sockets Layer.
unreleased v1, flawed but useful v2, good v3.
TLS = Transport Layer Security.
TLS1.0 = SSL3.0 with minor tweaks (see later).
Defined in RFC 2246.
Open-source implementation at
SSL/TLS provides security ‘at TCP layer’.
Uses TCP to provide reliable, end-to-end transport.
Applications need some modification.
In fact, usually a thin layer between TCP and HTTP.

36. SSL/TLS Basic Features
SSL/TLS widely used in Web browsers and servers to support ‘secure e-commerce’ over HTTP.
Built into Microsoft IE, Netscape, Mozilla, Apache, IIS,…
The (in)famous browser lock.
SSL architecture provides two layers:
SSL Record Protocol
Provides secure, reliable channel to upper layer.
Upper layer carrying:
SSL Handshake Protocol, Change Cipher Spec. Protocol, Alert Protocol, HTTP, any other application protocols.

37. SSL Protocol Architecture
SSL Change Cipher Spec Protocol
SSL Handshake Protocol
SSL Alert Protocol
HTTP, other apps
SSL Record Protocol
TCP

38. TLS: Transport Layer Security
formerly known as SSL: Secure Sockets Layer
Addresses issues of privacy, integrity and authentication
What is it?
How does it address the issues?
How is it used
Will discuss changes later
SSL created at Netscape, TLS is IETF draft standard
SSL 3.0 -> TLS 3.1

39. What is TLS? Protocol layer
Requires reliable transport layer (e.g. TCP)
Supports any application protocols IP
TCP
TLS
HTTP
Telnet
FTP
LDAP
Reliable transport layer delivers data without duplicates or missing data, and in order.
Not really transparent to applications
Application must understand desired security level and if TLS cannot
provide that must not assume a secure connection
Application must communicate security parameters to TLS
Application may introduce security issues
e.g. HTTP 1.0 connection close with empty Content-Length

40. TLS: Privacy Encrypt message so it cannot be read
Use conventional cryptography with shared key
DES, 3DES
RC2, RC4
IDEA
Most block ciphers (64 bit blocks) except for RC4 stream cipher
CBC cipher block chaining
use IV (initialization vector)
XOR previous encrypted block with block then encrypt … A
Message B

41. TLS:Key Exchange Need secure method to exchange secret key
Use public key encryption for this
“key pair” is used - either one can encrypt and then the other can decrypt
slower than conventional cryptography
share one key, keep the other private
Choices are RSA or Diffie-Hellman

42. TLS: Integrity Compute fixed-length Message Authentication Code (MAC)
Includes hash of message
Includes a shared secret
Include sequence number
Transmit MAC with message
Secret is used so that someone cannot replace both message and MAC, putting a new matching MAC in place of the original

43. TLS: Integrity Receiver creates new MAC TLS allows MD5, SHA-1
should match transmitted MAC
TLS allows MD5, SHA-1 A B
Message’
MAC’
MAC =?
Message

44. TLS: Authentication Verify identities of participants
Client authentication is optional
Certificate is used to associate identity with public key and other attributes A
Certificate B

45. TLS: Overview Establish a session Transfer application data
Agree on algorithms
Share secrets
Perform authentication
Transfer application data
Ensure privacy and integrity

46. TLS: Architecture
TLS defines Record Protocol to transfer application and TLS information
A session is established using a Handshake Protocol
TLS Record Protocol
Handshake Protocol
Alert Protocol
Change
Cipher Spec
Operational and pending states

47. TLS: Record Protocol Currently no compression defined but could be
client boundaries are not preserved
2^14 bytes or less in protocol unit
md5, sha-1, none MAC
des, 3des, des40, rc2, rc4, idea none encryption

48. TLS: Handshake Negotiate Cipher-Suite Algorithms
Symmetric cipher to use
Key exchange method
Message digest function
Establish and share master secret
Optionally authenticate server and/or client
Encryption mac key exchange
Des/3des/des40 md5, sha1, none rsa, dh
rc2 rc4
idea
none

49. Handshake Phases Hello messages Certificate and Key Exchange messages
Change CipherSpec and Finished messages

50. X.509 Certificate Issues Certificate Administration is complex
Hierarchy of Certification Authorities
Mechanisms for requesting, issuing, revoking certificates
X.500 names are complicated
Description formats are cumbersome (ASN.1)
Mention different kinds of certificates
identity
encryption etc

51. X.509 Alternative: SDSI
SDSI: Simple Distributed Security Infrastructure (Rivest, Lampson)
Merging with IETF SPKI: Simple Public-Key Infrastructure in SDSI 2.0
Eliminate X.500 names - use DNS and text
Everyone is their own CA
Instead of ASN.1 use “S-expressions” and simple syntax
Name and Authorization certificates

52. TLS “Alternatives” S-HTTP: secure HTTP protocol, shttp://
IPSec: secure IP
SET: Secure Electronic Transaction
Protocol and infrastructure for bank card payments
SASL: Simple Authentication and Security Layer (RFC 2222)
S-HTTP
inter-operates with http
signature
authentication
encryption
public key key exchange, & externally arranged
Secure * Secure-HTTP/1.4 : Request URI
Secure-HTTP/ OK response
header lines convey information
e.g. Certificate-Info: has cert, Encryption-Identity: x500 name
IPSec RFC
required for IPv6, optional for IPv4
transport mode - protect contents of IP packet
tunnel mode - protect entire IP packet
encryption, MAC
SASL
Means to add authentication to connection-based protocol
Variety of mechanisms
Kerberos V4, GSSAPI, “External”
Allows separation of authorization identity from client identity in credentials
Permits authenticated state in protocol

53. 6.2 SSH SSH overview SSH architecture SSH security
Port forwarding with SSH
SSH applications

54. SSH Overview SSH = Secure Shell.
Initially designed to replace insecure rsh, telnet utilities.
Secure remote administration (mostly of Unix systems).
Extended to support secure file transfer and .
Latterly, provide a general secure channel for network applications.
SSH-1 flawed, SSH-2 better security (and different architecture).
SSH provides security at Application layer.
Only covers traffic explicitly protected.
Applications need modification, but port-forwarding eases some of this (see later).
Built on top of TCP, reliable transport layer protocol.

55. SSH Overview SSH Communications Security (SCS).
Founded by Tatu Ylonen, writer of SSH-1.
SSH is a trademark of SCS.
Open source version from OpenSSH.
IETF Secure Shell (SECSH) working group.
Standard for SSH in preparation.
Long-running confusion and dispute over naming.

56. SSH-2 Architecture SSH-2 adopts a three layer architecture:
SSH Transport Layer Protocol.
Initial connection.
Server authentication (almost always).
Sets up secure channel between client and server.
SSH Authentication Protocol
Client authentication over secure transport layer channel.
SSH Connection Protocol
Supports multiple connections over a single transport layer protocol secure channel.
Efficiency (session re-use).

57. SSH-2 Architecture Applications SSH Connection Protocol
SSH Authentication Protocol
SSH Transport Layer Protocol
TCP

58. SSH-2 Security Goals
Server (nearly) always authenticated in transport layer protocol.
Client (nearly) always authenticated in authentication protocol.
By public key (DSS, RSA, SPKI, OpenPGP).
Or simple password for particular application over secure channel.
Establishment of a fresh, shared secret.
Shared secret used to derive further keys, similar to SSL/IPSec.
For confidentiality and authentication in SSH transport layer protocol.
Secure ciphersuite negotiation.
Encryption, MAC, and compression algorithms.
Server authentication and key exchange methods.

59. SSH-2 Algorithms
Key establishment through Diffie-Hellman key exchange.
Variety of groups supported.
Server authentication via RSA or DSS signatures on nonces (and other fields).
HMAC-SHA1 or HMAC-MD5 for MAC algorithm.
3DES, RC4, or AES finalists (Rijndael/Serpent).
Pseudo-random function for key derivation.
Small number of ‘official’ algorithms with simple DNS-based naming of ‘private’ methods.

60. SSH-1 versus SSH-2 Many vulnerabilities have been found in SSH-1 .
SSH-1 Insertion attack exploiting weak integrity mechanism (CRC-32) and unprotected packet length field.
SSHv1.5 session key retrieval attack (theoretical).
Man-in-the-middle attacks (using e.g. dsniff).
DoS attacks.
Overload server with connection requests.
Buffer overflows.
But SSH-1 widely deployed.
And SSH-1 supports:
Wider range of client authentication methods (.rhosts and Kerberos).
Wider range of platforms.

61. Without SSH or port forwarding.
SSH Port Forwarding
Without SSH or port forwarding.
LS Login server
UM User’s machine
MI Mail in server
Src: UM Dest: LS Port: 23
MO Mail out server
Src: UM Dest: MI Port: 113
Src: UM Dest: MO Port: 25

62. SSH Port Forwarding Recall: TCP port number ‘identifies’ application.
SSH on local machine:
Intercepts traffic bound for server.
Translates standard TCP port numbers.
E.g. port 113  port 5113.
Sends packets to SSH-enabled server through SSH secure channel.
SSH-enabled server:
Receives traffic.
Re-translates port numbers.
E.g. port 5113  port 113.
Forwards traffic to appropriate server using internal network.

63. With SSH and port forwarding.
SSH Port Forwarding
With SSH and port forwarding.
MI Mail in server
UM User’s machine LS
SSH-enabled
login server
MO Mail out server
Src: UM Dest: LS Port: 23
Src: UM Dest: MI Port: 113 Src: UM Dest: LS Port: 5113 Src: LS Dest: MI Port: 113
Src: UM Dest: MO Port: 25 Src: UM Dest: LS Port: 5025 Src: LS Dest: MO Port: 25

64. SSH Applications Anonymous ftp for software updates, patches...
No client authentication needed, but clients want to be sure of origin and integrity of software.
Secure ftp.
E.g.upload of webpages to webserver using sftp.
Server now needs to authenticate clients.
Username and password may be sufficient, transmitted over secure SSH transport layer protocol.
Secure remote administration.
SysAdmin (client) sets up terminal on remote machine.
SysAdmin password protected by SSH transport layer protocol.
SysAdmin commands protected by SSH connection protocol.
Guerilla Virtual Private Network.
E.g. use SSH + port forwarding to secure communications.

65. 6.3 Comparing IPSec, SSL/TLS, SSH
All three have initial (authenticated) key establishment then key derivation.
IKE in IPSec
Handshake Protocol in SSL/TLS (can be unauthenticated!)
Authentication Protocol in SSH
All protect ciphersuite negotiation.
All three use keys established to build a ‘secure channel’.

66. Comparing IPSec, SSL/TLS, SSH
Operate at different network layers.
This brings pros and cons for each protocol suite.
Recall `Where shall we put security?’ discussion.
Naturally support different application types, can all be used to build VPNs.
All practical, but not simple.
Complexity leads to vulnerabilities.
Complexity makes configuration and management harder.
Complexity can create computational bottlenecks.
Complexity necessary to give both flexibility and security.

67. Comparing IPSec, SSL/TLS, SSH
Security of all three undermined by:
Implementation weaknesses.
Weak server platform security.
Worms, malicious code, rootkits,…
Weak user platform security.
Keystroke loggers, malware,…
Limited deployment of certificates and infrastructure to support them.
Especially client certificates.
Lack of user awareness and education.
Users click-through on certificate warnings.
Users fail to check URLs.
Users send sensitive account details to bogus websites (“phishing”) in response to official-looking .

68. Secure Protocols – Last Words
A (mis)quote from Eugene Spafford:
“Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit-card information from someone living in a cardboard box to someone living on a park bench.”

69. What is a VPN
Public networks are used to move information between trusted network segments using shared facilities like frame relay or atm
A VIRTUAL Private Network replaces all of the above utilizing the public Internet Performance and availability depend on your ISP and the Internet

70. VPN Implementations

71. VPN as your Intranet

72. VPN Components

73. Technologies

74. Application Layer: SSL

75. Tunnel vs Transport Transport Tunnel
Implemented by the end point systems
Real address to real address
Cannot ‘go through’ other networks
Tunnel
Encapsulation of the original IP packet in another packet
Can ‘go through’ other networks
End systems need not support this
Often PC to a box on the ‘inside’

76. PPTP: Free from Microsoft

77. PPTP: Security

78. Outgoing PPTP Client Through NAT
Internet
web server a
NAT b
204.x.1.10 c

79. VPN Comparisons

80. So why have a private network: QOS not fully cooked
Very dependent on your ISP
Real hard to do across ISPs
So no guarantee of performance