Lecture 22 Network Security

1
Lecture 22Network Security

• CPE 401 / 601Computer Network Systems

slides are modified from Dave Hollinger
2
Terminology

• Authentication identifying someone (or
  something) reliably. Proving you are who you say
  you are.
• Authorization permission to access a resource.

3
Terminology

• Encryption Scramble data so that only someone
  with a secret can make sense of the data.
• Decryption Descrambling encrypted data.
• DES Data Encryption Standard secret key
  cryptographic function standardized by NBS (NIST).

4
Terminology (cont.)

• Secret Key Cryptography a cryptographic scheme
  where the same key is used to encrypt and
  decrypt.
• Public Key Cryptography a cryptographic scheme
  where different keys are used for encryption and
  decryption.

5
Terminology (more!)

• Firewall a network component that separates two
  networks and (typically) operates in the upper
  layers of the OSI reference model (Application
  layer).
• Screening Router a discriminating router that
  filters packets based on network layer (and
  sometimes transport layer) protocols and
  addresses.

6
Unix Network Security

• Some basic approaches
• Do nothing and assume requesting system is
  secure.
• Require host to identify itself and trust users
  on known hosts.
• Require a password (authentication) every time a
  service is requested.

7
Traditional Unix Security (BSD)

• Based on option 2 trust users on trusted hosts.
• if the user has been authenticated by a trusted
  host, we will trust the user.
• Authentication of hosts based on IP address!
  (doesnt deal with IP spoofing)

8
Reserved Ports

• Trust only clients coming from trusted hosts with
  source port less than 1024.
• Only root can bind to these ports.
• We trust the host. The request is coming via a
  trusted service (a reserved port) on the host.

9
Potential Problem

• Anyone who knows the root password can replace
  trusted services.
• Not all Operating Systems have a notion of root
  or reserved ports!
• Its easy to impersonate a host that is down.

10
Services that use the BSD security model

• lpd line printing daemon.
• rshd remote execution.
• rexec another remote execution.
• rlogin remote login.

11
BSD Config Files

• /etc/hosts.equiv list of trusted hosts.
• /etc/hosts.lpd trusted printing clients.
• /.rusers user defined trusted hosts and users.

12
lpd security

• check client's address for reserved port
• and
• check /etc/hosts.equiv for client IP
• or
• check /etc/hosts.lpd for client IP

13
rshd, rexecd, rlogind security

• As part of a request for service a username is
  sent by the client.
• The username must be valid on the server!

14
rshd security

• check clients address for reserved port
• if not a reserved port reject request.
• check for password entry on server for specified
  user.
• if not a valid username reject request.

15
rshd security (cont.)

• check /etc/hosts.equiv for clients IP address.
• if found process request.
• check users /.rhosts for client's IP address.
• if found process request, otherwise reject.

16
rexecd security

• client sends username and password to server as
  part of the request (plaintext).
• check for password entry on server for user name.
• encrypt password and check for match.
• rexecd is rarely used!

17
rlogind security

• Just like rshd.
• If trusted host (user) not found prompts for a
  password.

18
Special Cases

• If username is root requests are treated as a
  special case
• look at /.rhosts
• often disabled completely.

19
TCP Wrapper

• TCP wrapper is a simple system that provides some
  firewall-like functionality.
• A single host (really just a few services) is
  isolated from the rest of the world.
• Functionality includes logging of requests for
  service and access control.

20
TCP Wrapper Picture
Single Host
TCP wrapper (tcpd)
TCP based Servers
TCP Ports
The World
21
tcpd

• The tcpd daemon checks out incoming TCP
  connections before the real server gets the
  connection.
• tcpd can find out source IP address and port
  number (authentication).

22
tcpd (cont.)

• A log message can be generated indicating the
  service name, client address and time of
  connection.
• tcpd can use client addresses to authorize each
  service request.

23
Typical tcpd setup
SuperServer

• inetd (the ) is told to start
  tcpd instead of the real server.
• tcpd checks out the client by calling getpeername
  on descriptor 0.
• tcpd decides whether or not to start the real
  server (by calling exec).

24
tcpd configuration

• The configuration files for tcpd specify which
  hosts are allowed/denied which services.
• Entire domains or IP networks can be permitted or
  denied easily.
• tcpd can be told to perform RFC931 lookup to get
  a username.

25
(No Transcript)
26
Secret Key Cryptography

• Single key used to encrypt and decrypt.
• Key must be known by both parties.
• Assuming we live in a hostile environment
  (otherwise - why the need for cryptography?), it
  may be hard to share a secret key.

27
Public Key Cryptography(a.k.a. asymmetric
cryptography)

• Relatively new field - 1975 (as far as we know,
  the NSA is not talking).
• Each entity has 2 keys
• private key (a secret)
• public key (well known).

28
Using Keys

• Private keys are used for decrypting.
• Public keys are used for encrypting.
• encryption
• plaintext ciphertext
• public key
• decryption
• ciphertext plaintext
• private key

29
Digital Signature

• Public key cryptography is also used to provide
  digital signatures.
• signing
• plaintext signed message
• private key
• verification
• signed message plaintext
• public key

30
Transmitting over an insecure channel.

• Alice wants to send Bob a private message.
• Apublic is Alices public key.
• Aprivate is Alices private key.
• Bpublic is Bobs public key.
• Bprivate is Bobs private key.

31
Hello Bob,Wanna get together?
Alice
Bob
encrypt using Bpublic
decrypt using Bprivate
32
OK Alice,Your place or mine?
Alice
Bob
decrypt using Aprivate
encrypt using Apublic
33
Bobs Dilemma

• Nobody can read the message from Alice, but
  anyone could produce it.
• How does Bob know that the message was really
  sent from Alice?
• Bob may be comforted to know that only Alice can
  read his reply.

34
Alice can sign her message!

• Alice can create a digital signature and prove
  she sent the message (or someone with knowledge
  of her private key).
• The signature can be a message digest encrypted
  with Aprivate.

35
Message Digest

• Also known as hash function or one-way
  transformation.
• Transforms a message of any length and computes a
  fixed length string.
• We want it to be hard to guess what the message
  was given only the digest.
• Guessing is always possible.

36
Alices Signature

• Alice feeds her original message through a hash
  function and encrypts the message digest with
  Aprivate.
• Bob can decrypt the message digest using Apublic.
• Bob can compute the message digest himself.
• If the 2 message digests are identical, Bob knows
  Alice sent the message.

37
Revised Scheme
Alice
Bob
Sign with Aprivate
check signature using Apublic
encrypt using Bpublic
decrypt using Bprivate
38
Why the digest?

• Alice could just encrypt her name, and then Bob
  could decrypt it with Apublic.
• Why wouldnt this be sufficient?

39
Implications

• Suppose Alice denies she sent the message?
• Bob can prove that only someone with Alices key
  could have produced the message.

40
Another possible problem

• Suppose Bill receives a message from Alice
  including a digital signature.
• meet me at the library tonight
• Bill sends the same message to Joe so that it
  looks like the message came from Alice.
• Bill includes the digital signature from the
  message Alice sent to him.
• Joe is convinced Alice sent the message!

41
Solution?

• Always start your messages with
• Dear Bill,
• Create a digest from the encrypted message and
  sign that digest.
• There are many other schemes as well.

42
Speed

• Secret key encryption/decryption algorithms are
  much faster than public key algorithms.
• Many times a combination is used
• use public key cryptography to share a secret
  key.
• use the secret key to encrypt the bulk of the
  communication.

43
Secure Protocols

• There are a growing number of applications for
  secure protocols
• email
• electronic commerce
• electronic voting
• homework submission

44
Secure Protocols

• Many application protocols include the use of
  cryptography as part of the application level
  protocol.
• The cryptographic scheme employed is part of the
  protocol.
• If stronger cryptographic tools become available
  we need to change the protocol.

45
SSL and TLS

• Secure Sockets Layer (SSL) is a different
  approach - a new layer is added that provides a
  secure channel over a TCP only link.
• TLS is Transport Layer Security (IETF standard
  based on SSL).

46
SSL layer
47
Advantages of SSL/TLS

• Independent of application layer
• Includes support for negotiated encryption
  techniques.
• easy to add new techniques.
• Possible to switch encryption algorithms in the
  middle of a session.

48
HTTPS Usage

• HTTPS is HTTP running over SSL.
• used for most secure web transactions.
• HTTPS server usually runs on port 443.
• Include notion of verification of server via a
  certificate.
• Central trusted source of certificates.

49
(No Transcript)
50
Kerberos

• Part of project Athena (MIT).
• Trusted 3rd party authentication scheme.
• Assumes that hosts are not trustworthy.
• Requires that each client (each request for
  service) prove its identity.
• Does not require user to enter password every
  time a service is requested!

51
Kerberos Design

• User must identify itself once at the beginning
  of a workstation session (login session).
• Passwords are never sent across the network in
  cleartext (or stored in memory)

52
Kerberos Design (cont.)

• Every user has a password.
• Every service has a password.
• The only entity that knows all the passwords is
  the Authentication Server.

53
Server
Server
Ticket Granting Server
Server
Server
Workstation
Authentication Server
Kerberos Key Distribution Service
54
Secret Key Cryptography

• The encryption used by current Kerberos
  implementations is DES, although Kerberos V5 has
  hooks so that other algorithms can be used.
• encryption
• plaintext ciphertext
• key
• ciphertext plaintext
• decryption

55
Tickets

• Each request for a service requires a ticket.
• A ticket provides a single client with access to
  a single server.

56
Tickets (cont.)

• Tickets are dispensed by the Ticket Granting
  Server (TGS), which has knowledge of all the
  encryption keys.
• Tickets are meaningless to clients, they simply
  use them to gain access to servers.

57
Tickets (cont.)

• The TGS seals (encrypts) each ticket with the
  secret encryption key of the server.
• Sealed tickets can be sent safely over a network
  - only the server can make sense out of it.
• Each ticket has a limited lifetime (a few hours).

58
Ticket Contents

• Client name (user login name)
• Server name
• Client Host network address
• Session Key for Client/Server
• Ticket lifetime
• Creation timestamp

59
Session Key

• Random number that is specific to a session.
• Session Key is used to seal client requests to
  server.
• Session Key can be used to seal responses
  (application specific usage).

60
Authenticators

• Authenticators prove a clients identity.
• Includes
• Client user name.
• Client network address.
• Timestamp.
• Authenticators are sealed with a session key.

61
Bootstrap

• Each time a client wants to contact a server, it
  must first ask the 3rd party (TGS) for a ticket
  and session key.
• In order to request a ticket from the TGS, the
  client must already have a TG ticket and a
  session key for communicating with the TGS!

62
Authentication Server

• The client sends a plaintext request to the AS
  asking for a ticket it can use to talk to the
  TGS.
• REQUEST
• login name
• TGS name
• Since this request contains only well-known
  names, it does not need to be sealed.

63
Authentication Server

• The AS finds the keys corresponding to the login
  name and the TGS name.
• The AS creates a ticket
• login name
• TGS name
• client network address
• TGS session key
• The AS seals the ticket with the TGS secret key.

64
Authentication Server Response

• The AS also creates a random session key for the
  client and the TGS to use.
• The session key and the sealed ticket are sealed
  with the user (login name) secret key.

Sealed with TGS key
Ticket login name TGS name net address TGS
session key
TGS session key
Sealed with user key
65
Accessing the TGS

• The client decrypts the message using the users
  password as the secret key.
• The client now has a session key and ticket that
  can be used to contact the TGS.
• The client cannot see inside the ticket, since
  the client does not know the TGS secret key.

66
Accessing a Server

• When a client wants to start using a server
  (service), the client must first obtain a ticket.
• The client composes a request to send to the TGS

sealed with TGS key
TGS Ticket
Authenticator
sealed with session key
Server Name
67
TGS response

• The TGS decrypts the ticket using its secret
  key. Inside is the TGS session key.
• The TGS decrypts the Authenticator using the
  session key.
• The TGS check to make sure login names, client
  addresses and TGS server name are all OK.
• TGS makes sure the Authenticator is recent.

68
TGS Response

• Once everything checks out - the TGS
• builds a ticket for the client and requested
  server. The ticket is sealed with the server key.
• creates a session key
• seals the entire message with the TGS session key
  and sends it to the client.

69
Client accesses Server

• The client now decrypts the TGS response using
  the TGS session key.
• The client now has a session key for use with the
  new server, and a ticket to use with that server.
• The client can contact the new server using the
  same format used to access the TGS.

70
Kerberos Summary

• Every service request needs a ticket.
• Tickets come from the TGS (except the ticket for
  the TGS!).
• Workstations cannot understand tickets, they are
  encrypted using the server key.
• Every ticket has an associated session key.
• Tickets are reusable.

71
Kerberos Summary (cont.)

• Tickets have a finite lifetime.
• Authenticators are only used once (new connection
  to a server).
• Authenticators expire fast !
• Server maintains list of authenticators (prevent
  stolen authenticators).
• There is a lot more to Kerberos!!!