Motorola Israel Project: Authentication Center for SDP Federation ARD

1. Motorola Israel Project:Authentication Center for SDP FederationARD The Team: Alina Mirinzon Dadi Suissa Gabi Brontvin Raz Zieber

2. Introduction

3. Introduction • Network & SDP Authentication Center : Universal system based on AAA principle for authentication and authorization of users and applications that want to receive services that provider by SDP. • What is AAA?Authentication, Authorization, Accounting • What is SDP? Service Delivery Platform - The network infrastructure provider who gives AAA.

4. Introduction - cont. Each time user wants to access a network, in order to establish the connection, an AAA process is needed. AAA process: • Interests: identify user, user permissions, billing. • Functionaries: • SDP • Users - The clients • Applications - activate services supplied by the SDPs.

5. Vision

6. Vision • The project goal is to research, design and implement a proof of concept for authentication aspects of the SDP. • The project outcome expected to be an Authentication Center for SDP Federation, serving multiple authentication decision-points and security policies.

7. Problem Domain

8. Problem Domain Our project deals with three subjects: • Network Authentication • SDP Authentication • Privacy Policy (out of our scope) All the above will be resolved by a Single Authentication Center.

9. Problem Domain – cont. Network Authentication: Description: A client (supplicant) of one SDP wants to use infrastructure of any SDP. This authentication process is a precondition for establishing a connection between the client and the desired SDP.

10. Problem Domain – cont. Network Authentication – cont.Examples: • You go on a trip oversea. You forgot to tell your mom (Polish mom) that you got married in Las-Vegas with a Christian lady. You reach for your mobile phone but you forgot to make the arrangement for using your phone in U.S. - OOOOOOOOPS. • You are driving by bus in Beer-Sheva and want to send urgent talkback via your laptop (will be possible in the near future - WiMax technology) about the exam in compilation (it was a piece of cake). Beer-Sheva is covered by provider A but you are subscribed to provider B. - BASA

11. Connection request SDP#1 SDP#3 Subscribed SDP#2 SDP#4 Problem Domain – cont. Network Authentication – cont. Traditional solution: • Every SDP shall know all other SDPs. • Each SDP Supports the protocols of all other SDPs. • Agreements between SDPs in advance .

12. Connection request SDP#1 SDP#3 Subscribed SDP#2 SDP#4 Problem Domain – cont. Network Authentication – cont. Problems: • Duplicate implementation of protocols. • Severe data duplication.

13. Authentication/ Privacy Center Authentication Proxy Server Connection request SDP#1 SDP#3 SDP#2 SDP#4 Subscribed Problem Domain – cont. Network Authentication – cont. Suggested solution: One Authentication Center will receive all requests for authorization and handle it: • protocols conversion • Routes authentication request to DSP who user is subscribed to.

14. Problem Domain – cont. Network Authentication – cont. Solve Problems: • Convertor - Duplicate implementation of protocols. • The SDPs are required to know only the center and its private subscribers - (Severe data duplication).

15. Problem Domain – cont. SDP Authentication : Description: Application needs to use a specific service. The same service is provided and available in several servers. In order to learn about the capabilities of the service and choose the most suitable one, the application needs to authenticate with each server. (For a “get location“ service, capabilities parameters can be - location accuracy, location update frequency, service cost).

16. Problem Domain – cont. SDP Authentication – cont. Example: User operates an application of searching restaurants in his current position. This application uses the service “get location”. High Accuracy and frequent update isn’t relevant for this application.

17. Client Application Service SDP#1 SDP#2 Problem Domain – cont. SDP Authentication – cont. Existing solution: • Application trying to find all available services with the same functionality. • Application needs to authorize with all servers. • Application has to ask each server what it supports, rejecting those that aren’t suitable to its needs. • Application chooses the most suitable and profitable service.

18. Problem Domain – cont. SDP Authentication – cont. Problems: • Repetition process authentication. • Application will check servers that some of them aren’t relevant at all. • No standard for service request protocols. • Application service request should suite to Server protocol.

19. Authentication/ Privacy Center Authenticator Proxy OSA Gateway EAP Supplicant EAP Authenticator Client Application Service SDP#1 SDP#2 Problem Domain – cont. SDP Authentication – cont. Suggested solution: An authentication center will implement the authentication process and service request, using standard API. The center will give to application only the available and relevant services.

20. Problem Domain – cont. SDP Authentication – cont. Solve Problems: • One Authentication center - Repetition process authentication. • Implementing Standard API - Diversity of authentication protocols and No standard for service requests. • The center provides only the relevant services -Application will check servers that some of them aren’t relevant at all.

21. Architecture & Technologies

22. Authentication Center Network Authentication Convertor Access EAP Proxy Repository SDP Authentication Application - Demo EAP-MD5 Authenticator – Parlay framework Repository Architecture & Technologies

23. Functional Requirements

24. Functional Requirements • Repository • Select SDP record • Select record of application's server

25. Functional Requirements – cont. • EAP Proxy • Receive authentication details. • Select the record from the repository. • Execute converter. • Send authorization request to SDP. • Return the response.

26. Functional Requirements – cont. • Converter • RADIUS-DIAMETER conversion. • DIAMETER-RADIUS conversion.

27. Functional Requirements – cont. • Network Gateway - Access Point • Get an authentication request from the client in layer 2. • Manage protocol handshake. • Sends authentication request to the Authentication Center through RADIUS protocol. • Block the user from entering the network. • Enter the user or refuse, according to authentication response.

28. Functional Requirements – cont. • Supplicant Application (Parlay) • Request for service. • Selects a service. • Receive a service .

29. Functional Requirements – cont. • Server Authenticator • Parlay Interface - Framework

30. Functional Requirements – cont. • GUI • User connection. • Insert user personal details • Insert user connection details • Connection and Application process notification. • Initializing • Connecting • Accept\Reject • Disconnecting • Show Reports.

31. Non-Functional Requirements

32. Non-Functional Requirements • Speed, Capacity & Throughput, Availability, Usability– Irrelevant • Reliability – 100% correctness in supplying services and network access to entitled users only. • Safety & Security • RADIUS & DIAMETER authentication protocols • Identify EAP-MD5 hash function.

33. Non-Functional Requirements • Portability – different operating systems: • Supplicants - EAP Supplicant in Windows Parlay Supplicant in Linux • SDPs – Linux, RADIUS \ DIAMETER • Programming Languages - C++

34. Use-Cases

35. Use-Cases 1 Network authentication • The story: A SDP supplicant wants to connect to the network. • Post conditions: authorize network access.

36. Use-Cases 1

37. Use-Cases 2 Application authentication • The story: The application wants to use a service and needs to be authenticated. • Post conditions: The application is authenticated and is able to get the desired service.

38. Use-Cases 2

39. Risks

40. Risks • Proof Of Concept – possible won’t be implemented • A lot of advanced networking technologies – wide knowledge needed (Parlay, DIAMETER, RADIUS, EAP-MD5…)

41. Thank You !!!