Transcript Authentication Center for SDP Federation Motorola Israel Project: ARD
Motorola Israel Project:
Authentication Center for SDP Federation
ARD
The Team:
Alina Mirinzon Dadi Suissa Gabi Brontvin Raz Zieber
Introduction
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.
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.
Vision
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.
Problem Domain
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.
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.
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
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 .
Connection request SDP#1 SDP#2 SDP#3 SDP#4 Subscribed
Problem Domain – cont.
Network Authentication – cont.
Problems:
Duplicate implementation of protocols. Severe data duplication.
Connection request SDP#1 SDP#2 SDP#3 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.
Connection request SDP#1
Authentication/ Privacy Center
SDP#3 Authentication Proxy Server SDP#2 SDP#4 Subscribed
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).
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).
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.
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.
Client Application Service SDP#1 SDP#2
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.
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.
Client Application EAP Supplicant
SDP#1
Authentication/ Privacy Center
Authenticator Proxy OSA Gateway EAP Authenticator
Service SDP#2
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.
Architecture & Technologies
Architecture & Technologies
Access Network Gateway - Demo Application - Demo
Network Authentication Convertor EAP Proxy Repository SDP Authentication EAP-MD5 Authenticator – Parlay framework
Repository
Functional Requirements
Functional Requirements Repository
Select SDP record Select record of application's server
Functional Requirements – cont.
EAP Proxy
Receive authentication details.
Select the record from the repository.
Execute converter.
Send authorization request to SDP.
Return the response.
Functional Requirements – cont.
Converter
RADIUS-DIAMETER conversion.
DIAMETER-RADIUS conversion.
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.
Functional Requirements – cont.
Supplicant Application (Parlay)
Request for service.
Selects a service.
Receive a service .
Functional Requirements – cont.
Server Authenticator
Parlay Interface - Framework
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.
Non-Functional Requirements
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.
Non-Functional Requirements Portability –
different operating systems: Supplicants - EAP Supplicant in Windows Parlay Supplicant in Linux SDPs – Linux, RADIUS \ DIAMETER Programming Languages -
Use-Cases
Use-Cases 1 Network authentication
The story: A SDP supplicant wants to connect to the network.
Post conditions: authorize network access.
1: handshake Network Gateway
Use-Cases 1
Authentication Center 2: handshake 3: RADIUS authentication request 4: quary repository for SDP 11: response (accept / reject) 5: convert protocol 6: DIAMETER authentication request 7: authenticate user 8: DIAMETER response 9: re-converte protocol 10: RADIUS response
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.
Client Application
Use-Cases 2
Authentication Framework (Parlay) Authentication Server choosing services suitable to the application needs 1: Service request (according to parlay interface) 2: query repository for server details according to service's SDP 3: authentication request (application,service) 4: response (accept/reject) 5: response the application gets a service
Risks
Proof Of Concept – possible won’t be implemented A lot of advanced networking technologies – wide knowledge needed (Parlay, DIAMETER, RADIUS, EAP-MD5…)