Transcript week7-Kerberos X509

Week 7:
Authentication Applications
Kerberos
1
Kerberos
X.509
2
How To Secure Network
How do you secure
your network and
each workstation or
server with one tool?
3
How To Secure Network
4
Assume an open distributed environment in which users at workstation
wish to access services on servers distributed throughout the network.
Question:
What kind of threats exist in this environment?
5
Assume an open distributed environment in which users at workstation
wish to access services on servers distributed throughout the network.
Question:
What kind of threats exist in this environment?
Answer:
a. A user may gain access to a particular workstation and pretend to be
another user operating from that workstation.
b. A user may alter the network address of a workstation so that the
request sent from altered workstation appear to come from the
impersonated workstation
c. A user may eavesdrop on exchanges and used replay attack to gain
entrance to a server or to disrupt operations.
6
The Answer Is
Kerberos negotiates the communication between any two points on the
Internet or an intranet. It can also encrypt the communication between
two points. Because of this, it provides a layer of security that is
independent of either side of any firewall.
7
Problem Statement
The Internet is a vast place that connects millions of people from all
corners of the globe to each other everyday.
In such a network, information can be lost, stolen, corrupted, or
misused.
Another drawback of the internet is that it is difficult for individuals
to confirm their identity to one another.
Confidentiality is very important for some types of information, such
as information related to banking and medical. It is therefore important
that a user, who wants to access this kind of information online, be
able to confirm that the user is who he/she claims to be. This process
is called authentication.
Kerberos plays a major role in authentication.
8
Problem Statement
Traditionally, a process was set in place called Authentication by
Assertion. Authentication by assertion works as follows:
When a user runs a program that accesses a network service, the
program (called the client) asserts to the service that it is running
on behalf of the user. This provides a very low level of security.
Consider the example of Berkeley rlogin. If a user rlogins to an
account under his own name, but on another machine, and if
the user's . rhosts is set correctly, the rlogin program will
assert the user's identity to the rlogin daemon on the remote
machine, and the daemon does not require a password for
login. This can become disastrous if an attacker is somehow
able either to convince the rlogin program that he/she is the
legitimate user, or to rewrite a mutant version of rlogin
asserting that identity to the remote machine.
9
Problem Statement
An alternative to this situation is to require a user to enter a password
each time he/she accesses a network service. This is a very timeconsuming process, and it is insecure when users access services on
a remote machine. When a user is logged on to a remote machine and
then logs in from there to another remote machine, the password
travels unencrypted through the network.
Kerberos fixes these problems because it provides single-sign-on,
which lets a user log in to a system and access multiple systems or
applications without the need to enter the user name and password
multiple times. In addition, Kerberos is designed so that entities have
to authenticate themselves by demonstrating possession of secret
information. In this manner, Kerberos solves traditional problems
involved with authentication.
10
Problem Statement
The problem statement discussed the problems associated with
traditional authentication methods and, in particular, how passwords
are vulnerable because they travel unencrypted over the network.
Password-based authentication is also inconvenient; users do not
want to enter a password each time they access a network service.
Kerberos is designed to eliminate the need for users to demonstrate
possession of private or secret information (the password). Instead,
Kerberos disseminates this information. Kerberos Server lets entities
authenticate themselves, without transmitting their passwords in clear
text over the network.
Commonly used to secure particularly vulnerable network
communications like ftp, telnet, and other widely used Internet
protocols that normally transmit user IDs and passwords in clear text,
Kerberos provides the "plumbing" for common authentication
services. Its scalability means that Kerberos is ideal for large networks
such as those used by governments, telecommunication networks,
and major financial institutions.
11
Problem Statement
The problem statement discussed the problems associated with
traditional authentication methods and, in particular, how passwords
are vulnerable because they travel unencrypted over the network.
Password-based authentication is also inconvenient; users do not
want to enter a password each time they access a network service.
Kerberos is designed to eliminate the need for users to demonstrate
possession of private or secret information (the password). Instead,
Kerberos disseminates this information. Kerberos Server lets entities
authenticate themselves, without transmitting their passwords in clear
text over the network.
Commonly used to secure particularly vulnerable network
communications like ftp, telnet, and other widely used Internet
protocols that normally transmit user IDs and passwords in clear text,
Kerberos provides the "plumbing" for common authentication
services. Its scalability means that Kerberos is ideal for large networks
such as those used by governments, telecommunication networks,
and major financial institutions.
12
Kerberos
Kerberos is a computer network authentication protocol which allows
individuals communicating over an insecure network to prove their identity
to one another in a secure manner. Kerberos prevents eavesdropping or
replay attacks, and ensures the integrity of the data. Its designers aimed
primarily at a client-server model, and it provides mutual authentication
— both the user and the service verify each other's identity.
 Kerberos builds on symmetric key cryptography and requires a trusted
third party.
 Kerberos is a real-world implementation of a symmetric cryptographic
protocol whose propose is to provide levels of authentication and security
in key exchange between users in a network.
Kerberos is a network authentication protocol which utilizes symmetric
cryptography to provide authentication for client-server applications.
13
Kerberos Architecture
The Kerberos Standard Definition
Kerberos is defined in RFC 1510 - The Kerberos Network Authentication
Service (V5).
The core of a Kerberos architecture is the KDC (Key Distribution Server). The
KDC stores authentication information and uses it to securely authenticate
users and services.
This authentication is called secure because it:
Does not occur in plaintext
Does not rely on authentication by the host operating system
Does not base trust on IP addresses
Does not require physical security of the network hosts
The KDC acts as a trusted third party in performing these authentication
services.
Due to the critical function of the KDC, multiple KDC's are normally utilized.
Each KDC stores a database of users, servers, and secret keys.
Kerberos clients are normal network applications which have been modified to
use Kerberos for authentication. In Kerberos slang, they have been Kerberized.
14
Kerberos Protocol
Kerberos defines ten messages that make up the Kerberos protocol:
KRB_AS_REQ Kerberos Authentication Service Request
KRBAS_REP
Kerberos Authentication Service Reply
KRB_AP_REQ Kerberos Application Request
KRB_AP_REP
Kerberos Application Reply
KRB_TGS_REQ Kerberos Ticket Granting Service Request
KRB_TGS_REP Kerberos Ticket Granting Service Reply
KRB_SAFE
Kerberos Safe (Checksummed) Application Message
KRB_PRIV
Kerberos Private (Encrypted) Application Message
KRB_CRED
Kerberos Credentiials
KRB_ERROR
Kerberos Error
15
Kerberos Implementations
MIT Kerberos is the reference implementation. MIT Kerberos supports
DEC Unix, Linux, Irix, Solaris, Windows and MacOS.
Several other commercial and non-commercial Kerberos
implementations are also available.
Microsoft added a slight modified version of Kerberos v5
authentication in Windows 2000.
16
Kerberos Weaknesses
Because the KDC's store secret keys for every user and server on the
network, they must be kept completely secure. If an attacker were to
obtain administrative access to the KDC, he would have access to the
complete resources of the Kerberos realm.
Kerberos tickets are cached on the client systems. If an attacker gains
administrative access to a Kerbos client system, he can impersonate
the authenticated users of that system.
17
Kerberos Encryption Protocols
Kerberos uses the DES algorithm for encryption. Kerberos also
supports the CRC-32, MD4, MD5, and DES algorithms for checksums.
Kerberos implementations are free to add additional algorithms for
encryption and checksumming.
18
Authentication Process
AS
TGS
Key Table File
APPLICATION
SERVER
Secured Service
Kerberos
Server
1
2
4
5
6 7
Credentials
Cache
3
Client Workstation
19
Authentication Process
Step 1. The user begins to use a Kerberized
application by entering the user name and
password. Optionally, the user can request
for specific ticket flags and specify the key
type to be used for constructing the secret
key. The user can also accept the default,
configured for the client.
AS
Kerberos
Server
1
The user sends the following information to
the Authentication Service (AS) to obtain
credentials:
Client, Server, T, N; where
Client indicates the user name, also
referred to as the principal name
Server indicates the Application
Server
T indicates the time stamp and
N indicates nonce
Client Workstation
20
Authentication Process
Step 2. If the AS can decrypt the message
successfully, it issues a temporary session
key, which is encrypted with the user’s
secret key (a key derived from the user
password, which is stored in the KDC), and
a TGT encrypted with the TGS’s secret key.
The TGT contains the name of the user and a
copy of the session key (a randomly
generated temporary encryption key) to be
used by the user and the Server for any
subsequent communication.
AS
Kerberos
Server
2
Client Workstation
21
Authentication Process
Step 3. The user decrypts the session key. The TGT and the session key
are stashed in the user’s credential cache. The credentials are used to
obtain tickets for each network service the principal wants to access.
This protocol exchange has two important features:
The authentication scheme does not require that the password be
sent across the network,
either in encrypted form or in clear text.
The client (or any other user) cannot view or modify the contents
of the TGT.
Credentials
Cache
3
Client Workstation
22
Authentication Process
Step 4. To obtain access to a secured
network service such as rlogin, rsh, rcp, ftp,
or telnet, the requesting client application
uses the previously obtained TGT in a
dialogue with the TGS to obtain a service
ticket. The protocol is the same as used
while obtaining the TGT, except that the
messages contain the name of the server
and a copy of the previously obtained TGT.
TGS
Kerberos
Server
4
Client Workstation
23
Authentication Process
Step 5. The TGS returns a new service ticket
that the application client can use to
authenticate the service.
TGS
Kerberos
Server
5
Client Workstation
24
Authentication Process
Step 6. The application client tries to
authenticate to the service on the
application server using the service ticket
obtained from the TGS.
The secure application validates the service
ticket using the server’s service key present
in the key tab file.
Using this service key, the server decrypts
the authenticator and verifies the identity of
the user.
It also verifies that the user’s service ticket
has not expired. If the user does not have a
valid service ticket, then the server will
return an appropriate error code to the
client.
Key Table File
Client Workstation
APPLICATION
SERVER
Secured Service
6
25
Authentication Process
Step 7. (Optional) At the client’s request, the
application server can also return the time
stamp the client sent encrypted in the
session key. This ensures a mutual
authentication between the client and the
application server.
APPLICATION
SERVER
Key Table File
Secured Service
7
Client Workstation
26
Authentication Process
AS
TGS
Key Table File
APPLICATION
SERVER
Secured Service
Kerberos
Server
1
2
4
5
6 7
Credentials
Cache
3
Client Workstation
27
Kerberos
28
Basic Kerberos System
Cliff – a client
Serge – a server
Trent – a trusted authority (as an authentication server)
Grant – a ticket-granting server
29
Kerberos Protocol Operation
Cliff to Trent
Cliff sends a message to Trent that contains his name and the name
of the ticket-granting server that he will use (in this case is Grant)
Trent to Cliff
Trent looks up Cliff’s name in his database. If he finds it, he generates
a session key KCG that will be used between Cliff and Grant. Trent also
has a secret key KC with which he can communicate with Cliff, so he
uses this to encrypt the Cliff-Grant session key:
T = e KC (KCG).
In addition, Trent creates a Ticket Granting Ticket (TGT), which will allow
Cliff to authenticate himself to Grant. This ticket encrypted using Grant’s
personal key KG (which Trent also has):
TGT = Grant’s name || eKC (Cliff’s name, Cliff’s Address, Timestamp1, KCG).
Here || is used to denote concatenation. The ticket that Cliff receives is
the concatenation of these two subtickets:
Ticket = T||TGT
30
Kerberos Protocol Operation
Cliff to Grant
Cliff can extract KCG using the key KC, which he shares with the Trent.
Using KCG, Cliff can now communicate securely with Grant.
Cliff now creates an authenticator, which will consist of his name, his
address, and a timestamp. He encrypts this using KCG to get:
AuthCG = eKCG (Cliff’s name, Cliff’s Address, Timestamp2).
Cliff now sends AuthCG as well as TGT to Grant so that Grant can
administer a service ticket.
31
Kerberos Protocol Operation
Grant to Cliff
Grant now has AuthCG and TGT.
(Part of TGT was encrypted using Grant’s secret key, so Grant can extract
this portion and can decrypt it. Thus he can recover
Cliff’s name, Cliff’s address, Timestamp1, as well as KCG)
Grant can now use KCG to decrypt AuthCG in order to verify the
authenticity of Cliff’s request.
That is, dKCG (AuthCG) will provide another copy of Cliff’s name,
Cliff’s address, and a different timestamp.
If two versions of Cliff’s name and address match, and if Timestamp1
and Timestamp2 are sufficiently close to each other, then Grant will
declare Cliff valid.
32
Kerberos Protocol Operation
Grant to Cliff
Now that Cliff is approved by grant, Grant will generate a ssession key
KCS for Cliff to communicate with Serge and will also return a service
ticket. Grant has a secret key KS which he shares with Serge. The service
ticket is
ServTicket = eKS (Cliff’s name, Cliff’s Address, Timestamp3, ExpirationTime, KCS).
Here ExpirationTime is a quantity that describes the length of validity
for this service ticket.
The session key is ecrypted using a session key between Cliff and Grant:
eKCG (KCS)
Grant sends ServTicket and eKCG (KCS) to Cliff.
33
Kerberos Protocol Operation
Cliff to Serge
Cliff is now ready to start making use of Serge’s services.
He starts by decrypting eKCG (KCS) in order to get the session key KCS
that he will use while communicating with Serge. He creates an
authenticator to use with Serge:
AuthCS = eKCS (Cliff’s name, Cliff’s Address, Timestamp4)
Cliff now sends Serge AuthCS as well as ServTicket.
Serge can decrypt ServTicket and extract from this session key KCS
that he is to use with Cliff.
34
Kerberos Protocol Operation
Cliff to Serge
Using this session key, he can decrypt AuthCS and verify that Cliff is
who says he is, and that Timestamp4 is within ExpirationTime of Stamp3.
If Timestamp4 is not within ExpirationTime of Timestamp3, then cliff’s
ticket is stale and Serge rejects his request for service. Otherwise, Cliff
and Serge may make use of KCS to perform their exchange.
35
Kerberos Protocol Operation
Trent
Trent has a database of
Password, information for
all the clients.
7. Serge provide the service
Serge
Cliff
6. Cliff sends Serge the service ticket
with the authentication credential to
make sure it is valid.
Grant
5. Now cliff has a service
ticket which he can
present to serge
Server
A ticket-granting server
36
Kerberos
X.509
37
X.509 Authentication Service
part of CCITT X.500 directory service standards
distributed servers maintaining some info database
defines framework for authentication services
directory may store public-key certificates
with public key of user
signed by certification authority
also defines authentication protocols
uses public-key crypto & digital signatures
algorithms not standardised, but RSA recommended
38
X.509 Certificates
issued by a Certification Authority (CA), containing:
version (1, 2, or 3)
serial number (unique within CA) identifying certificate
signature algorithm identifier
issuer X.500 name (CA)
period of validity (from - to dates)
subject X.500 name (name of owner)
subject public-key info (algorithm, parameters, key)
issuer unique identifier (v2+)
subject unique identifier (v2+)
extension fields (v3)
signature (of hash of all fields in certificate)
notation CA<<A>> denotes certificate for A signed by CA
39
X.509 Certificates
40
Obtaining a Certificate
any user with access to CA can get any certificate from it
only the CA can modify a certificate
because cannot be forged, certificates can be placed in a public
directory
41
CA Hierarchy
if both users share a common CA then they are assumed to know its
public key
otherwise CA's must form a hierarchy
use certificates linking members of hierarchy to validate other CA's
each CA has certificates for clients (forward) and parent
(backward)
each client trusts parents certificates
enable verification of any certificate from one CA by users of all
other CAs in hierarchy
42
CA Hierarchy Use
Y<<X>> :
Cert of user X
issued by CA Y
43
Certificate Revocation
certificates have a period of validity
may need to revoke before expiry, eg:
1. user's private key is compromised
2. user is no longer certified by this CA
3. CA's certificate is compromised
CA’s maintain list of revoked certificates
the Certificate Revocation List (CRL)
users should check certs with CA’s CRL
44
Authentication Procedures
X.509 includes three alternative authentication
procedures:
One-Way Authentication
Two-Way Authentication
Three-Way Authentication
all use public-key signatures
45
One-Way Authentication
1 message ( A->B) used to establish
the identity of A and that message is from A
message was intended for B
integrity & originality of message
message must include timestamp, nonce, B's identity
and is signed by A
46
Two-Way Authentication
2 messages (A->B, B->A) which also establishes in addition:
the identity of B and that reply is from B
that reply is intended for A
integrity & originality of reply
reply includes original nonce from A, also timestamp and nonce from B
47
Three-Way Authentication
3 messages (A->B, B->A, A->B) which enables above authentication
without synchronized clocks
has reply from A back to B containing signed copy of nonce from B
means that timestamps need not be checked or relied upon
48
X.509 Version 3
has been recognised that additional information is needed in a
certificate
email/URL, policy details, usage constraints
rather than explicitly naming new fields defined a general extension
method
extensions consist of:
extension identifier
criticality indicator
extension value
49
Certificate Extensions
key and policy information
convey info about subject & issuer keys, plus indicators of
certificate policy
certificate subject and issuer attributes
support alternative names, in alternative formats for certificate
subject and/or issuer
certificate path constraints
allow constraints on use of certificates by other CA’s
50
Cloud Security Issues: Authentication
51
Cloud Security Issues: Authentication
52
Cloud Security Issues: Access Control
53
Cloud Security Issues: Data Security
54
Summary
have considered:
Kerberos trusted key server system
X.509 authentication and certificates
Examples of Cloud Security Issue on authentication
55
How Do You Want Protect Your Network System
Thank You
56