OTP II Project Presentation

1. 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

2. 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.

3. 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.

4. 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.

5. 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.

6. 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. Cellphone with “OTP I”: Java applet to produce current OTP. 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.

7. 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.

8. 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.

9. 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)

10. 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.

11. 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.

12. 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.

13. Interaction of Code The IAS Main The AD OTP MyADSI MD5 MyAux Dbg A B Means: A uses B.

14. 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.

15. 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.

16. The New MMC Extension

17. Demonstration

18. 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.

19. 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.

20. 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 

21. 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.

22. 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.