Transcript Lecture 22 Network Security CPE 401 / 601 Computer Network Systems slides are modified from Dave Hollinger.

Lecture 22
Network Security
CPE 401 / 601
Computer Network Systems
slides are modified from Dave Hollinger
Terminology
 Authentication: identifying someone (or
something) reliably. Proving you are who
you say you are.
 Authorization: permission to access a
resource.
Netprog: Security
2
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).
Netprog: Security
3
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.
Netprog: Security
4
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.
Netprog: Security
5
Unix Network Security
Some basic approaches:
1.
2.
3.
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.
Netprog: Security
6
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! (doesn’t deal with IP spoofing)
Netprog: Security
7
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.
Netprog: Security
8
Potential Problem
 Anyone who knows the root password can
replace trusted services.
 Not all Operating Systems have a notion of
root or reserved ports!
 It’s easy to impersonate a host that is
down.
Netprog: Security
9
Services that use the BSD
security model
 lpd – line printing daemon.
 rshd – remote execution.
 rexec – another remote execution.
 rlogin – remote login.
Netprog: Security
10
BSD Config Files
 /etc/hosts.equiv – list of trusted hosts.
 /etc/hosts.lpd – trusted printing clients.
 ~/.rusers – user defined trusted hosts and
users.
Netprog: Security
11
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
Netprog: Security
12
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!
Netprog: Security
13
rshd security
1. check client’s address for reserved port
if not a reserved port – reject
request.
2. check for password entry on server for
specified user.
if not a valid username – reject
request.
Netprog: Security
14
rshd security (cont.)
3. check /etc/hosts.equiv for client’s IP
address.
if found – process request.
4. check users ~/.rhosts for client's IP
address.
if found – process request, otherwise
reject.
Netprog: Security
15
rexecd security
client sends username and password to
server as part of the request (plaintext).
1. check for password entry on server for
2.
user name.
encrypt password and check for match.
rexecd is rarely used!
Netprog: Security
16
rlogind security
 Just like rshd.
 If trusted host (user) not found – prompts
for a password.
Netprog: Security
17
Special Cases
 If username is
root requests are treated
as a special case:

look at /.rhosts

often disabled completely.
Netprog: Security
18
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.
Netprog: Security
19
TCP Wrapper Picture
Single Host
TCP based
Servers
TCP
wrapper
(tcpd)
TCP
Ports
The World
Netprog: Security
20
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).
Netprog: Security
21
tcpd (cont.)
 A log message can be generated indicating
the service name, client address and time
of connection.
 tcpd can use client addresses to
each service request.
authorize
Netprog: Security
22
Typical tcpd setup
 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).
Netprog: Security
23
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.
Netprog: Security
24
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.
Netprog: Cryptgraphy
26
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).

Netprog: Cryptgraphy
27
Using Keys
•
•
Private keys are used for decrypting.
Public keys are used for encrypting.
plaintext
encryption
ciphertext
public key
ciphertext
decryption
plaintext
private key
Netprog: Cryptgraphy
28
Digital Signature
•
Public key cryptography is also used to
provide digital signatures.
plaintext
signing
signed message
private key
signed message
verification
plaintext
public key
Netprog: Cryptgraphy
29
Transmitting over an insecure
channel.
Alice wants to send Bob a private message.
Apublic is Alice’s public key.
Aprivate is Alice’s private key.
Bpublic is Bob’s public key.
Bprivate is Bob’s private key.
Netprog: Cryptgraphy
30
Hello Bob,
Wanna get together?
Alice
encrypt using Bpublic
Bob
decrypt using Bprivate
Netprog: Cryptgraphy
31
OK Alice,
Your place or mine?
Alice
decrypt using Aprivate
Bob
encrypt using Apublic
Netprog: Cryptgraphy
32
Bob’s 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.
Netprog: Cryptgraphy
33
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.
Netprog: Cryptgraphy
34
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.
Netprog: Cryptgraphy
35
Alice’s 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.
Netprog: Cryptgraphy
36
Revised Scheme
Alice
Sign with Aprivate
encrypt using Bpublic
Bob
check signature using Apublic
decrypt using Bprivate
Netprog: Cryptgraphy
37
Why the digest?
•
Alice could just encrypt her name, and then
Bob could decrypt it with Apublic.
•
Why wouldn’t this be sufficient?
Netprog: Cryptgraphy
38
Implications
•
Suppose Alice denies she sent the
message?
•
Bob can prove that only someone with
Alice’s key could have produced the
message.
Netprog: Cryptgraphy
39
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!
Netprog: Cryptgraphy
40
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.
Netprog: Cryptgraphy
41
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.

Netprog: Cryptgraphy
42
Secure Protocols
•
There are a growing number of applications
for secure protocols:
email
 electronic commerce
 electronic voting
 homework submission

Netprog: Cryptgraphy
43
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.

Netprog: Cryptgraphy
44
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).
Netprog: Cryptgraphy
45
SSL layer
Application
SSL
TCP
IP
Application
SSL
TCP
IP
Netprog: Cryptgraphy
46
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.
Netprog: Cryptgraphy
47
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.

Netprog: Cryptgraphy
48
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 it’s identity.
Does not require user to enter password
every time a service is requested!
Netprog: Kerberos
50
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)
Netprog: Kerberos
51
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.
Netprog: Kerberos
52
Ticket Granting
Server
Kerberos
Database
Server
Server
Server
Server
Workstation
Authentication
Server
Kerberos Key Distribution Service
Netprog: Kerberos
53
Secret Key Cryptography
•
The encryption used by current Kerberos
implementations is DES, although Kerberos
V5 has hooks so that other algorithms can
be used.
plaintext
ciphertext
encryption
key
decryption
ciphertext
plaintext
Netprog: Kerberos
54
Tickets
•
Each request for a service requires a
ticket.
•
A ticket provides a single client with
access to a single server.
Netprog: Kerberos
55
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.
Netprog: Kerberos
56
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).
Netprog: Kerberos
57
Ticket Contents
•
•
•
•
•
•
Client name (user login name)
Server name
Client Host network address
Session Key for Client/Server
Ticket lifetime
Creation timestamp
Netprog: Kerberos
58
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).
Netprog: Kerberos
59
Authenticators
•
•
Authenticators prove a client’s identity.
Includes:
Client user name.
 Client network address.
 Timestamp.

•
Authenticators are sealed with a session
key.
Netprog: Kerberos
60
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!
Netprog: Kerberos
61
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.
Netprog: Kerberos
62
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.
Netprog: Kerberos
63
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
TGS session key
Sealed with user key
Ticket:
login name
TGS name
net address
TGS session key
Netprog: Kerberos
64
Accessing the TGS
•
•
•
The client decrypts the message using the
user’s 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.
Netprog: Kerberos
65
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 Ticket
TGS key
Authenticator
sealed with
session key
Server Name
Netprog: Kerberos
66
TGS response
•
•
•
•
The TGS decrypts the ticket using it’s
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.
Netprog: Kerberos
67
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.
Netprog: Kerberos
68
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.
Netprog: Kerberos
69
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.
Netprog: Kerberos
70
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!!!
Netprog: Kerberos
71