Authentication Applications

1
Authentication Applications
In the Name of the Most High

• Behzad Akbari
• Fall 2010

2
Outline

• Introduction
• Kerberos
• X.509 Authentication Service
• Recommended reading and Web Sites

3
Authentication Applications

• Authentication functions
• developed to support application-level
  authentication digital signatures
• Kerberos
• a secret-key authentication service
• X.509
• a public-key directory authentication service

4
KERBEROS

• In Greek mythology, a many headed dog, the
  guardian of the entrance of Hades

5
KERBEROS

• Users wish to access services on servers.
• Three threats exist
• User pretend to be another user.
• User alter the network address of a workstation.
• User eavesdrop on exchanges and use a replay
  attack.

6
KERBEROS

• A centralized authentication server
• From MIT
• To authenticate users to servers and servers to
  users
• Relies on conventional encryption
• Making no use of public-key encryption
• Allows users to access services distributed in
  network
• Without needing to trust all workstations
• All trust a central authentication server
• Two versions version 4 and 5
• Version 4 makes use of DES

7
Kerberos v4 Overview

• a basic 3rd-party authentication scheme
• have an Authentication Server (AS)
• users initially negotiate with AS to identify
  self
• AS provides a non-corruptible authentication
  credential
• ticket granting ticket (TGT)
• have a Ticket Granting server (TGS)
• users subsequently request access to other
  services from TGS based on users TGT

8
Kerberos Version 4

• Terms
• 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
• TS timestamp
• concatenation

9
A Simple Authentication Dialogue

• C ? AS IDc Pc IDv
• AS ? C Ticket
• C ? V IDc Ticket
• Ticket EKvIDc Pc IDv
• Kv shared by AS and Sever (V)
• Ticket can be decrypted by Server

10
Kerberos v4 Dialogue

• obtain ticket granting ticket from AS
• once per session
• obtain service granting ticket from TGS
• for each distinct service required
• client/server exchange to obtain service
• on every service request

11
Version 4 Authentication Dialogue

• Threat
• An opponent will steal the ticket-granting ticket
  and use it before it expires
• Countermeasure
• How to decide the lifetime associated with the
  ticket-granting ticket?
• If too short ? repeatedly asked for password
• If too long ? greater opportunity to replay

12
Version 4 Authentication Dialogue

• C ? AS IDc IDtgs TS1
• AS ? C E(Kc,Kc,tgs ll IDtgs ll TS2 ll
  Lifetime2 ll Tickettgs)
• Tickettgs E (Ktgs,
  Kc,tgs ll IDc ll ADcll IDtgs ll TS2Lifetime2)

• (a) Authentication Service Exchange to obtain
  ticket-granting ticket

• C ? TGS IDv Tickettgs Authenticatorc
• TGS? C E(Kc,tgs Kc,v ll IDv ll TS4 ll
  Ticketv)
• Tickettgs E(Ktgs,Kc,tgs ll IDc
  ll ADc ll IDtgs ll TS2 ll Lifetime2)
• Ticketv E(Kv,Kc,v ll IDc ll ADc ll
  IDv ll TS4 ll Lifetime4)
• Authenticatorc E(Kc,tgs IDc ll ADc
  ll TS3)

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

• C ? V Ticketv Authenticatorc
• V ? C E(Kc,v, TS5 1) (for mutual
  authentication)
• Ticketv E (Kv, Kc,v
  ll IDc ll ADc ll IDv ll TS4 ll Lifetime4)
• Authenticatorc E (Kc,v, IDc
  ll ADc ll TS5)

(c) Client/Server Authentication Exchange to
obtain service
Summary of Kerberos Version 4 Message Exchanges
12
13
Version 4 Authentication Dialogue

• C ? AS IDc IDtgs TS1
• AS ? C E(Kc,Kc,tgs ll IDtgs ll TS2 ll
  Lifetime2 ll Tickettgs)
• Tickettgs E(Ktgs, Kc,tgs ll IDc ll
  ADcll IDtgs ll TS2 Lifetime2)
• (a) Authentication Service Exchange to obtain
  ticket-granting ticket

• The client requests a TGT to AS with message(1)
• To handle the problem of captured TGT and
• the genuiness of ticket presenter,
• the AS provides both the TGS and the client with
• a secret information, called a session key,
• in a secure manner through message(2)
• then the key is used to prove the identity of
• the client to TGS

13
14
Version 4 Authentication Dialogue

• C ? TGS IDv Tickettgs Authenticatorc
• TGS? C E(Kc,tgs Kc,v ll IDv ll TS4 ll
  Ticketv)
• Tickettgs E(Ktgs,Kc,tgs ll IDc
  ll ADc ll IDtgs ll TS2 ll Lifetime2)
• Ticketv E(Kv,Kc,v ll IDc ll ADc ll
  IDv ll TS4 ll Lifetime4)
• Authenticatorc E(Kc,tgs IDc ll ADc
  ll TS3)
• (b) Ticket-Granting Service Exchange to obtain
  SGT

• C transmits an authenticator (A) used only once
  with
• very short lifetime in message(3)
• Replay attack is encountered.
• The TGS decrypts the A and the ticket with keys,
• - The contents from the both are checked
  if those match
• - The ticket is a way to distribute keys securely
• - The A proves the clients identity.
• Reply from TGS includes a session key shared b/w
  C and V.
• It says that the key can be used by only C and V
  for authentication.

14
15
Version 4 Authentication Dialogue

• C ? V Ticketv Authenticatorc
• V ? C E(Kc,v, TS5 1) (for mutual
  authentication)
• Ticketv E(Kv,Kc,v ll
  IDc ll ADc ll IDv ll TS4 ll Lifetime4)
• Authenticatorc E(Kc,v, IDc
  ll ADc ll TS5)
• (c) Client/Server Authentication
  Exchange to obtain service

• The message(5) is similar to message(3)
• V examines the contents of A and the ticket if
  the ticket presenter is genuine
• The mutual authentication is done with message(6)
• The value of timestamp from the A is incremented
  by 1 and encrypted by the session key.
• The contents of the message assures C that this
  is not a replay
• The session key is used to encrypt future
  messages b/w the two or to exchange a new random
  session key for that purpose

15
16
Version 4 Authentication Dialogue
16
17
Kerberos Realm

• A Kerberos realms is a set of managed nodes that
  share the same Kerberos DB.
• A Kerberos realm consists of
• A Kerberos server, with all user IDs and their
  passwords in its DB
• A number of clients, registered with the Kerberos
  server
• A number of application servers, sharing a key
  and registered with the Kerberos server
• Networks of clients and servers under different
  administrative organizations constitute typically
  different realms.

17
18
Kerberos Realms with Multiple Kerberi

• For two realms to support interrealm auth,
• The Kerberos server in one realm shares a secret
  key with the sever in the other realm. The two
  Kerberos servers are registered with each other
• The participating servers in the second realm
  must trust the Kerberos server in the first realm
• One problem with above approach
• It does not scale well to many realms
• It requires N(N-1)/2 secure key exchanges for
  interoperation of all realms

18
19
Request for Service in Another Realm
19
20
Password-to-key Transformation
20
21
PCBC Mode
22
Kerberos - in practice

• currently have two Kerberos versions
• v4
• restricted to a single realm
• v5
• allows inter-realm authentication
• Kerberos v5 is an Internet standard
• specified in RFC1510, and used by many utilities
• To use Kerberos
• need to have a KDC on your network
• need to have Kerberised applications running on
  all participating systems
• major problem - US export restrictions
• Kerberos cannot be directly distributed outside
  the US in source format ( binary versions must
  obscure crypto routine entry points and have no
  encryption)
• else crypto libraries must be reimplemented
  locally

23
X.509 Authentication Service

• A distributed set of servers that maintains a
  database about users.
• Each certificate contains the public key of a
  user and is signed with the private key of a CA.
• used in S/MIME, IP Security, SSL/TLS and SET.
• RSA is recommended to use.

24
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 CAltltAgtgt
• denotes certificate for A signed by CA

25
X.509 Formats
26
Obtaining a Users Certificate

• Characteristics of certificates generated by CA
• Any user with access to the public key of the CA
  can recover the user public key that was
  certified.
• Nobody other than the CA can modify the
  certificate without this being detected.

27
CA Hierarchy

• both users share a common CA
• they are assumed to know its public key
• If XltltAgtgt and XltltBgtgt, then A has Bs certificate
  (public key)
• otherwise CA's must form a hierarchy
• A signed by X1, B signed by X2
• If A doesnt know X2s public key
• Bs certificate is useless to A
• A can obtain X2s public key from X1 if X2 is
  also signed by X1
• X1ltltX2gtgtX2ltltBgtgt -- certification path
• 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

28
X.509 CA Hierarchy
If XltltAgtgt, then (i) A knows Xs public key and
(ii) A can get all the public keys signed by X.
A establishes a certification path to
B XltltWgtgtWltltVgtgtVltltYgtgtYltltZgtgtZltltBgtgt B establishes a
certification path to A ZltltYgtgtYltltVgtgtVltltWgtgtWltltXgtgtX
ltltAgtgt
29
Revocation of Certificates

• Reasons for revocation
• The users private key is assumed to be
  compromised.
• The user is no longer certified by this CA.
• The CAs certificate is assumed to be
  compromised.

30
Authentication Procedures

• X.509 includes three alternative authentication
  procedures
• intended for use across a variety of applications
• to use public-key signature
• assumed for the two parties to know each others
  KU
• The three procedures
• One-way authentication
• Two-way authentication
• Three-way authentication

31
One-Way Authentication
1. AtA,rA,IDB,sgnData,EPUb,Kab
A
B

• A single transfer of information from A to B
• Verification of the followings
• 1. As identity and the message generated by A
• 2. the message intended for B
• 3. the integrity and originality of the message
• At minimum TS tA, nonce rA, Bs identity, As
  signature

32
Two-Way Authentication
1. AtA,rA,IDB,sgnData,EPUb,Kab
A
B
2. BtB,rB,IDA,rA,sgnData,EPUa,Kba

• Verification of the followings
• 4. Bs identity and the message generated by B
• 5. the message intended for A
• 6. the integrity and originality of the reply
• Permission of verification for both parties
• Reply includes As nonce, TS and nonce from B

33
Three-Way Authentication
1. AtA,rA,IDB,sgnData,EPUb,Kab
A
B
2. BtB,rB,IDA,rA,sgnData,EPUa,Kba
3. ArB

• The signed copy of the nonce rB in the final MSG
• TS need not to be checked
• Replay attack can be detected by nonces echoed
• to each other

34
X.509 Version 3

• Has been recognized that additional information
• is needed in a certificate
• e-mail/URL, policy details, usage constraints
• Include a number of optional extensions added to
  version 2 format
• rather than continue to add fields to a fixed
  format
• Each extension consists of extension identifier,
  criticality indicator, extension value

35
Public Key Infrastructure

• PKI the set of hardware, software, people,
  policies, and procedures needed to create,
  manage, store, distribute, and revoke digital
  certificates based on asymmetric cryptography.
• based on X.509

36
Recommended Reading and WEB Sites

• www.whatis.com (search for kerberos)
• Bryant, W. Designing an Authentication System A
  Dialogue in Four Scenes. http//web.mit.edu/kerber
  os/www/dialogue.html
• Kohl, J. Neuman, B. The Evolotion of the
  Kerberos Authentication Service
  http//web.mit.edu/kerberos/www/papers.html
• http//www.isi.edu/gost/info/kerberos/