Motorola Israel Project:

Authentication Center for SDP

Federation

ARDThe Team:Alina Mirinzon

Dadi Suissa

Gabi Brontvin

Raz Zieber

Introduction

IntroductionNetwork & 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

VisionThe 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 AuthenticationSDP AuthenticationPrivacy 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 .

Subscribed

SDP#4

SDP#3

SDP#2

SDP#1

Connection request

Problem Domain – cont.Network Authentication – cont.

Problems:Duplicate implementation of protocols.

Severe data duplication.

Subscribed

SDP#4

SDP#3

SDP#2

SDP#1

Connection request

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.

Subscribed

SDP#1

SDP#2

Authentication/Privacy Center

Authentication Proxy Server

SDP#4

SDP#3

Connection request

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

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

SDP#1

Authentication/Privacy Center

Authenticator Proxy OSA

GatewaySDP#2

EAP AuthenticatorEAP Supplicant

Client Application

Service

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

EAP-MD5Authenticator –

Parlay framework

Repository

Convertor

EAP Proxy

Repository

Application

- Demo

Network Gateway- Demo

Access

SDP Authentication

Network Authentication

Functional Requirements

Functional Requirements

Repository Select SDP recordSelect record of application's server

Functional Requirements – cont.

EAP ProxyReceive 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 authenticationThe story: A SDP supplicant wants to connect to the network.Post conditions: authorize network access.

Use-Cases 1SupplicantSupplicant Network

GatewayNetwork Gateway

Authentication Center

Authentication Center

SDPSDP

1: handshake

2: handshake 3: RADIUS authentication request

4: quary repository for SDP

5: convert protocol

6: DIAMETER authentication request

8: DIAMETER response

7: authenticate user

9: re-converte protocol

10: RADIUS response

11: response (accept / reject)

Use-Cases 2

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

Use-Cases 2Client

ApplicationClient

ApplicationAuthentication

Framework (Parlay)Authentication

Framework (Parlay)Authentication

ServerAuthentication

Server

details according to service's SDP

(according to parlay interface)

(application,service)

1: Service request

2: query repository for server

3: authentication request

4: response (accept/reject)5: response

choosing services suitable to the application needs

the application gets a service

Risks

Risks

Proof Of Concept – possible won’t be implemented

A lot of advanced networking technologies – wide knowledge needed (Parlay, DIAMETER, RADIUS, EAP-MD5…)

Thank You !!!