Our model is built on the premise that defensive,
or exclusionary, security must be aligned with
inclusionary tools and practices that allow users to
access systems and information anytime, anywhere.
We illustrate the architecture of the access for an
end User Authentication as follows:
1 The “early request ticket for the key exchange
authentication from the DBMS unit” that
provides identification that lives beyond the
span of single first level authorizations or
interaction
2 Level two makes it possible to associate
successive message or request to third level.
3 The single use authorization, which conceals
user’s identities and also limits linkage among
given users successive actions is in third level.
4 The three different units (Unit 1, Unit 2 and
Unit 3) verify the user in application-level by
sending different request in each unit.
2.1 Message Exchange Algorithm
We analyze the semantics basing on Kerberos
authentication technique key exchange (Palmgren,
2005) and Diffie-Hellman Key exchange of each
security transcoding by using an online contracting
scenario.
Basic notations
C = Client, ADBMS = Authentication database
Management System, WS = Web Source, IDc =
Identifier of user on C, Idws= Identifier of Web
source, P
c
= Password of user on C, Kws
= secret
encryption key shared by ADBMS and WS, TS =
timestamp, || = concatenation
Steps
(6) With the ticket, C can now apply to (WS) for
service by sending a message to (WS)
containing C’s ID and the ticket.
(6.1) (Ws) decrypts the ticket and verifies that
the user ID in the ticket is the same as the
unencrypted user ID in the message.
(6.2) If the two matches, the server considers
the user authenticate and grant the
requested service.
(7) Simply stated:
(6.1)
C Ú ADB : IDc || Pc || IDws
(6.2)
ADBMS Ú
C: Ticket
(6.3)
C Ú WS: IDc || Ticket
Authentication Service Exhange: To obtain Ticket-
Granting Ticket.
(1)
C Ú ADBMS: IDc || IDtgs ||TS1
(2) ADBMS Ú
C:EKc [Kc,tgs|| IDtgs || TS2 || Lifetime2 || Tickettgs]
Ticket-Granting Service Exchange: To obtain
Service-Granting Ticket.
(3)
C Ú TGS: IDv ||Tickettgs ||Authenticator C
(4) TGS Ú
C: EKc [Kc,
¨ws
|| IDws || TS4 || Ticketv]
Client/WebService Authentication Exhange: To
Obtain Service
(5)
C Ú WS: Ticketv || Authenticator C
(6) WS Ú C: EKc,v[TS5 +1]
3 EUA ASSESSMENT
Considering today’s pervasiveness of malicious
software (Viruses, Trojan horses) and phishing
attacks, any authentications solution must be
resistant against offline credential stealing attacks.
For this we propose a Challenge/response-based
one-time passwords authentication.
3.1 Passwords
We represent these requirements (Jermyn et al 1999)
in an authentication system consisting of five
components. Components are defined inductively as
follow:
1.
The set A of authentication Information is the set
of specific information with which entities prove
their identities.
2.
The set C of complementary Information is the set
of information that the system stores and uses to
validate the authentication information.
3.
The set F of complementation functions that
generate the complimentary from the
authentication information that is: -
For
F, F : A C
→f
The set L of
authentication functions that verify
identity. That is for
L, : A × C {true, false}∈→
The set S of
selection functions that enable an entity
to create or alter the authentication and
complementary information.
The goal is to find an
a
A such that, for f
F,
f (a) =
c
c and c is associated with a particular
entity (or any entity).Because one can determine
weather
a is associated with and entity only by
computing
f (a) or by authenticating via | (a) we
have two approaches for protecting the password,
used simultaneously
1.
Hide enough information so that one of a, c, or f
can not be found.
2. Prevent access to the authentication functions L
END USER AUTHENTICATION (EUA)
407