OTP II Project Presentation
Roman Kecher (roman.kecher@gmail.com)
Ophir Etzion (ophir86@gmail.com)
Supervised by: Zeev Schneider (zeev@technion.ac.il)
Software Lab, EE Technion. 08-02-2009
Introduction
Remote Authentication Dial In User
Service (RADIUS) is a networking protocol
that provides centralized access for people
or computers to connect and use a
network service.
 In the user’s authentication process we
would like to use a One Time Password
(OTP) for security reasons.

The OTP Concept (or, OTP I)
The idea is to use a different, one time,
password each time a password is
required.
 The OTP is created using a cryptographic
hash function (which is one-way) MD5, on
a string built from known parameters that
are updated each time, thus providing a
different hash each invocation.

Solution Characteristics
Internet Authentication Service (IAS) is
Microsoft’s implementation of RADIUS.
 IAS allows any developer to write custom
extensions to the authentication process.
 Our solution is an extension to the IAS that
allows a user to authenticate with an OTP
instead of his static, fixed password.

OTP IAS Extension
The IAS communicates with an Active
Directory (AD) server that stores all users
data.
 Our OTP data is stored in that very same
AD and fetched by the extension, prior to
computing the current OTP.
 After a successful connection attempt, the
OTP data in the AD is updated in order to
get a different OTP next time around.

How does it look?
Wireless Access Point,
acting as a RADIUS
client.
User’s computer, wishing to
connect to the wireless network
using the 802.1x wireless protocol.
AD Server, this is where
all the OTP data of the
users is stored.
IAS, acting as a RADIUS
Server. This is where our
product is installed.
Cellphone with “OTP I”:
Java applet to produce
current OTP.
Development tools in use
For the whole development process, from
start to end, we have used the Visual
Studio 2005 IDE (Integrated Development
Environment) by Microsoft.
 We’re not big fans of debugging, therefore
the only debugging tools in use were a
Debug class written by us which provided
logging of everything, so we could check
up on suspicious behavior.

Technologies



The solution consists of pure C++ code, with use
of the MFC, ATL, and STL, along with some
Microsoft specific structures (like VARIANT).
We used ADSI (Active Directory Services
Interface) – an interface that allowed us to
conduct easy and correct communication with
the AD.
We have used the MD5 (Message Digest 5)
algorithm as part of the OTP generation process.
Implementation
As our solution is an extension to the IAS,
we had to implement it as a DLL (Dynamic
Linked Library).
 That DLL had to implement and export at
least one mandatory function, which is in
charge of returning the accept/reject
decision to the IAS:

RadiusExtensionProcess (Radius_attrs, Radius_action)
Encountered Problems

The MMC (Microsoft Management Console)
doesn’t allow a user to view/edit custom
attributes (such as ours).


Solution: we wrote an extension to the MMC that
allows us to view and edit our own custom attributes.
Debugging a DLL can be pretty tricky, even
more so when the executing machine isn’t the
one we’re compiling on.

Solution: we wrote an internal logging facility for the
whole extension, so we could see all the relevant data
when an inspection is needed.
Design Review
The chosen design is pretty much dictated
to us since we’re writing an extension to
an already existing product; therefore we
must implement it as a DLL, and have the
correct functions exported.
 The rest of the design conforms to the
principles of OOP (Object Oriented
Design) and is well divided into logical
modules, exactly the way it should be.

Code, Briefly
Here are the major modules(/classes):
 Main – this is the main entry point of the dll. It
interacts with the IAS.
 MD5 – Implementation of MD5.
 OTP – This module is in charge of computing
the current OTP (per user).
 MyADSI – This module is in charge of the
communication with the AD.
 MyAux – Auxiliary module. Contains some useful
functionality, serving everybody.
 Dbg – Debug class for logging purposes.
Interaction of Code
The IAS
The AD
Main
OTP
MyADSI
MD5
MyAux
Dbg
A
B
Means: A uses B.
The MMC Extension Code



The MMC Extension is far more trivial code
wise.
The extension consists of a single MFC based
dialog, UserPropPage. In this dialog we have the
three relevant properties (or attributes): PIN,
Seed, Iteration.
All the code in the project is C++ code with MFC
in use, which implements the functionality of
reading the custom attributes from the AD and
writing them back.
Installing the MMC Extension
We have to extend the AD Schema with
three new attributes: otpseed, otppin,
otpiteration.
 Once this is done, the new MMC
extension DLL must be registered and
added to the user-display Properties,
under AdminPropertyPages.
 This is all well explained in the supplied
documents.

The New MMC Extension
Demonstration
Relevant Courses
Security knowledge:
 236350 Computer Security.
 236506 Modern Cryptology.
Implementation and practice:
 236703 Object Oriented Programming.
 236700 Software Design.
Network related:
 236341 Internet Networking.
Gains from the project

We learned an entire system and the
technologies within entirely from scratch:
IAS, AD, and more. This benefits us in at
least two ways:
We got acquainted with a whole range of new
technologies and systems that can be useful
in the future.
 We learned how to cope with an totally new
and challenging environment in which we
have to work and find our own way.

More gains!
In this project we have put to practice
some of the theoretical knoweldge we had
before.
 We learned how to deal with a very
practical and well defined demand for a
working product – this defers greatly from
any demands we faced in normal courses.
 We learned much from Zeev and his
experience 

Summary
This project was a really beneficial
experience that really assured us we are
ready to handle anything we may face, no
matter how new and challenging it is.
 At the bottom line, we have a working
product here, that has a demand in the
market! We may consider trying to sell it,
or continue working in the field.

Suggestions for OTP III ?
Some studies show that MD5 has quite a
few weaknesses, so basing the OTP on a
different hash algorithm may be a smart
direction to go in.
 Another nice suggestion could be building
a hardware device for creating the OTPs.
Perhaps even one that is based on the
time of creation, rather then on the number
of invocations, to create the OTP.
