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
