Scribd
Upload
10 views

Module 2

Uploaded by

vvce21cse0148
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
10 views

Module 2

Uploaded by

vvce21cse0148
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 31

Chapter 14: Kerberos

Kerberos 4 : A Simple Authentication Dialogue

(1) C-- AS: IDc||Pc||IDv


(2) AS- C: Ticket
(3) C -V: IDc||Ticket
Ticket = E(Kv, [IDc||ADc||IDv])
where
C = client
AS = authentication server
V =server
IDc = identifier of user on C
IDv = identifier of V
Pc= password of user on C
ADc = network address of C
Kv = secret encryption key shared by AS and V
Kerberos 4 : Authentication Dialogue

Once per user logon session:


(1) C-- AS: IDc||IDtgs
(2) AS- C: E(Kc, Tickettgs)
Once per type of service:
(3) C- TGS: IDc||IDv||Tickettgs
(4) TGS -C: Ticketv
Once per service session:
(5) C -V: IDc||Ticketv
Tickettgs = E(Ktgs, [IDc||ADc||IDtgs||TS1||
Lifetime1])
Ticketv = E(Kv, [IDc||ADc||IDv||TS2||Lifetime2])
Version 4 : Authentication Dialogue

(b) Ticket-Granting Service Exchange to obtain service-granting ticket


Version 4 : Authentication Dialogue
Kerberos Realms and Multiple Kerberi
• The Kerberos server must have the user ID and hashed passwords
of all participating users in its database. All users are registered
with the Kerberos serve

• The Kerberos server must have the user ID and hashed passwords
of all participating users in its database. All users are registered
with the Kerberos serve

• The Kerberos server in each interoperating realm shares a secret


key with the server in the other realm. The two Kerberos servers
are registered with each other

Terminologies

Kerberos realm

Kerberos principal
Kerberos Realms and Multiple Kerberi
Difference between Version4 and Version 5
Version 5 address the limitations of version 4 in two areas:
environmental shortcomings and technical deficiencies

Environmental shortcomings in Version 4:

• Encryption system dependence

• Internet protocol dependence

Message byte ordering (Abstract Syntax Notation One


(Version 5: ASN.1) and Basic Encoding Rules (BER))

• Ticket lifetime(28 x 5 = 1280 minutes)

• Authentication forwarding

• Inter realm authentication


Difference between Version4 and Version 5
Version 5 address the limitations of version 4 in two areas:
environmental shortcomings and technical deficiencies

Environmental shortcomings in Version 4:

• Encryption system dependence

• Internet protocol dependence

Message byte ordering (Abstract Syntax Notation One


(Version 5: ASN.1) and Basic Encoding Rules (BER))

• Ticket lifetime(28 x 5 = 1280 minutes)

• Authentication forwarding

• Inter realm authentication


Between different realms
(1) C --AS: IDc||IDtgs||TS1
(2) AS --C: E(Kc,[Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs])

(3) C-TGS: IDtgsrem||Tickettgs||Authenticatorc

(4) TGS-C: E(Kc,tgs,[Kc,tgsrem||IDtgsrem||TS4||


Tickettgsrem])

(5) C-- TGSrem: IDvrem||Tickettgsrem||Authenticatorc

(6) TGSrem- C: E(Kc,tgsrem, [Kc,vrem||IDvrem||TS6||


Ticketvrem])

(7) C-- Vrem: Ticketvrem||Authenticatorc


Between Realm
Between different realms
(1) C --AS: IDc||IDtgs||TS1
(2) AS --C: E(Kc,[Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs])

(3) C-TGS: IDtgsrem||Tickettgs||Authenticatorc

(4) TGS-C: E(Kc,tgs,[Kc,tgsrem||IDtgsrem||TS4||


Tickettgsrem])

(5) C-- TGSrem: IDvrem||Tickettgsrem||Authenticatorc

(6) TGSrem- C: E(Kc,tgsrem, [Kc,vrem||IDvrem||TS6||


Ticketvrem])

(7) C-- Vrem: Ticketvrem||Authenticatorc


Difference between Version4 and Version 5
Version 5 address the limitations of version 4 in two areas:
environmental shortcomings and technical deficiencies

Environmental shortcomings in Version 4:

• Encryption system dependence

• Internet protocol dependence

Message byte ordering (Abstract Syntax Notation One


(Version 5: ASN.1) and Basic Encoding Rules (BER))

• Ticket lifetime(28 x 5 = 1280 minutes)

• Authentication forwarding

• Inter realm authentication


Difference between Version4 and Version 5
Version 5 address the limitations of version 4 in two areas:
environmental shortcomings and technical deficiencies

Environmental shortcomings in Version 4:

• Encryption system dependence

• Internet protocol dependence

Message byte ordering (Abstract Syntax Notation One


(Version 5: ASN.1) and Basic Encoding Rules (BER))

• Ticket lifetime(28 x 5 = 1280 minutes)

• Authentication forwarding

• Inter realm authentication


Between Realm
Version 5 Authentication
Dialogue
Version 5 Authentication
Dialogue
Version 5 Authentication
Dialogue
X.509 Authentication Service

• X.509 is part of the X.500 series of recommendations


that define a directory service
• X.509 defines a framework for the provision of authentication
services by the X.500 directory to its users
• X.509 is an important standard because the certificate
structure and authentication protocols defined in
• X.509 are used in a variety of contexts.
• X.509 is based on the use of public-key cryptography and
digital signatures
Public-Key Certificate Use
General format of the Certificate
Standard used to define the certificate

CA<<A>> = CA {V, SN, AI, CA, TA, A, Ap}

Y <<X>> = the certificate of user X issued by


certification authority Y

Y {I} = the signing of I by Y. It consists of I with an


encrypted hash code appended
Now suppose that A has obtained a certificate from
certification authority X1 and B has obtained a
certificate from CA X2. If A does not securely know the
public key of X2, then B's certificate, issued by X2, is
useless to A. A can read B's certificate, but A cannot
verify the signature. However, if the two CAs have
securely exchanged their own public keys, the
following procedure will enable A to obtain B's public
key
• A obtains, from the directory, the certificate of X2
signed by X1. Because A securely knows X1’s public
key, A can obtain X2's public key from its certificate
and verify it by means of X1’s signature on the
certificate.
• A then goes back to the directory and obtains the certificate
of B signed by X2 Because A now has a trusted copy of
X2's public key, A can verify the signature and securely
obtain B's public key.
• A has used a chain of certificates to obtain B's public key. In
the notation of X.509, this chain is expressed as
X1<<X2>> X2 <<B>>
• B can obtain A's public key with the reverse chain
X2<<X1>> X1 <<A>>
Example:

User A can acquire the following certificates from the


directory to establish a certification path to B

X<<W>> W <<V>> V <<Y>> <<Z>> Z <<B>>

If A wishes to receive encrypted messages back from


B, or to sign messages sent to B, then B will require
A's public key, which can be obtained from the
following certification path

Z<<Y>> Y <<V>> V <<W>> W <<X>>X <<A>>


Revocation of Certificates
It may be desirable on occasion to revoke a certificate
before it expires, for one of the following reasons:

•The user's private key is assumed to be compromised

•The user is no longer certified by this CA

•The CA's certificate is assumed to be compromised


X.509 Strong Authentication Procedures
Public-Key Infrastructure

RFC 2822 (Internet Security Glossary) defines public-

key infrastructure (PKI) as the set of hardware,

software, people, policies, and procedures needed to

create, manage, store, distribute, and revoke digital

certificates based on asymmetric cryptography.


PKIX Architectural Model

You might also like