Motorola Software Group & BGU Project:

AuthenticationCenter for SDP Federation

Proof of Concept for Extension to IMS in SDP Federation Area

Application Design Document

(ADD)

Name / ID / E-Mail / Phone
Alina Mirinzon / 306066481 / / 054-4797793
Gabi Brontvin / 305988370 / / 054-7512199
Raz Zieber / 036469419 / / 052-5269026
Dadi Suissa / 040580003 / / 052-6093601

Industrial Adviser: Mr. Yehezkel 03-5658956

Academic Adviser: Prof. Ehud 08-6477138

The project’s website:

Revision Control

Rev. / Detailed Description / Paragraph Reference / Approved by / Date
0.1 / Original draft / - / Project assistant / 10 Jan 2007
1.0 / Release / - / Academic adviser / 31 Jan 2007
1.1 / System Architecture Diagram - updated / Section 5 / Industrial adviser / 10 Mar 2007
1.2 / Databases, Main Tables - updated / Section 2.3.2 / Alina Mirinzon / 27 Apr 2007
2.1 / Remove Use Case UC7 -
“Initialize System” / Section 1.7 / Alina Mirinzon / 30 June 2007
2.2 / Update use-case image / Section 1 / Alina Mirinzon / 30 June 2007
2.3 / Remove the “RADIUSSupplicant” data object. / Section 2.1.4 / Alina Mirinzon / 30 June 2007
2.4 / Update Data Object relationship diagram / Section 2.2 / Alina Mirinzon / 30 June 2007
2.5 / Remove the “protocol” field from “SERVICES_DATA” table. / Section 2.3.2.2 / Alina Mirinzon / 30 June 2007
2.6 / Remove table”APLICATION_AA” from the system’s database. / Section 2.3.4 / Alina Mirinzon / 30 June 2007
2.7 / Remove sequence diagram of the “Initialize System” use case. / Section 3.1.7 / Alina Mirinzon / 30 June 2007
2.8 / Update class diagram of repository package. / Section 4.1 / Alina Mirinzon / 30 June 2007
2.9 / Update class diagram of Network Authentication package. / Section 4.1 / Alina Mirinzon / 30 June 2007
2.10 / Replace “RADIUSRequest” class and “RADIUSResponse” class, with one “RADIUSPacket” class. / Section 4.2.9 / Alina Mirinzon / 30 June 2007
2.11 / Replace “DIAMETERequest” class and “DIAMETERResponse” class, with one “DIAMETERPacket” class. / Section 4.2.10 / Alina Mirinzon / 30 June 2007
2.12 / Replace “RADIUSRequest” unit test and “RADIUSResponse” unit test, with unit test for “RADIUSPacket” class. / Section 4.4.7 / Alina Mirinzon / 30 June 2007
2.13 / Replace “DIAMETERRequest” unit test and “DIAMETERResponse” unit test, with unit test for “DIAMETERPacket” class. / Section 4.4.8 / Alina Mirinzon / 30 June 2007
2.14 / Remove the “Initiate system and configuration GUI” user interface. / Section 6.2 / Alina Mirinzon / 30 June 2007
2.15 / Update dates in the tasks list. / Section 8 / Alina Mirinzon / 30 June 2007

Table of contents

1Use Cases

1.1Use Case UC1 – Connection Request

1.2Use Case UC2 - Protocol Conversion

1.3Use Case UC3 – Handshake

1.4Use Case UC4 – Initial Access

1.5Use Case UC5 – Query Repository

1.6Use Case UC6 – View Logger

1.7Use Case UC8 – Application Terminate Access

1.8Use Case UC9 – System (Authentication Center) Terminate Access

1.9Use Case UC10 - Announcement of services & request for authorization

1.10Use Case UC11 – Service Request

1.11Use Case UC12 – Route Request

2Data Model

2.1Description of Data Objects

2.1.1Administrator

2.1.2Subscriber

2.1.3Supplicant

2.1.4Application

2.1.5Service

2.1.6SDP

2.1.7Registered SDP

2.1.8Authenticator

2.1.9Authentication Center

2.1.10Converter – no data members

2.2Data Objects Relationships

2.3Databases

2.3.1ERD (Entity-Relation Diagrams)

2.3.2Main Tables

2.3.3Main Transactions

3Behavioral Analysis

3.1Sequence Diagrams

3.1.1Connection Request

3.1.2Protocol Conversion

3.1.3Handshake

3.1.4Initial Access

3.1.5Query Repository

3.1.6View Logger

3.1.7Application Terminate Access

3.1.8System Terminate Access

3.1.9Announcement of services and request for authorization

3.1.10Service Request

3.1.11Route Request

3.2Events

3.3States

4Object-Oriented Analysis

4.1Class Diagram

4.2Class Description

4.2.1Converter

4.2.2EAPProxyManager

4.2.3StateGUI

4.2.4RADIUSServer

4.2.5DIAMETERClient

4.2.6Protocol (abstract)

4.2.7RADIUS (extends Protocol)

4.2.8DIAMETER (extends Protocol)

4.2.9RADIUSPacket(implements Packet)

4.2.10DIAMETERPacket (implements Packet)

4.2.11EAPStateMachine

4.2.12StateGUI

4.2.13ConfigSystem

4.2.14ParlayFacade

4.2.15ApplicationServer802.1x

4.2.16IMSService (interface)

4.2.17IMSServiceStub (implements IMSService)

4.2.18ClientCommWithSDP (interface)

4.2.19DIAMETERClient (implements ClientCommWithSDP)

4.2.20CsapiInterface (interface)

4.2.21Initial (interface extends CsapiInterface)

4.2.22Access (interface extends CsapiInterface)

4.2.23APILevelAuthentication (interface extends Authentication)

4.2.24ClientAccess(extendsCsapiInterface)

4.2.25ClientAPILevelAuthentication (extendsCsapiInterface)

4.3Packages

4.4Unit Testing

4.4.1Converter

4.4.2EAPProxyManager

4.4.3RADIUSServer

4.4.4DIAMETERClient

4.4.5RADIUS

4.4.6DIAMETER

4.4.7RADIUSPacket

4.4.8DIAMETERPacket

4.4.9ParlayFacade

4.4.10ApplicationServer802.1x

4.4.11IMSServiceStub

4.4.12DIAMETERClient

4.4.13ACInitial

4.4.14ACAccess

4.4.15ACAPILevelAuthentication

4.4.16ACClientAccess

4.4.17ACClientAPILevelAuthentication

5System Architecture

6User Interface Draft

6.1Network Connection Request GUI

6.2Service Request GUI

6.3Authentication process GUI

6.4A form that shows an example of using a service

7Testing

7.1Test Protocols Conversion

7.2Route Message

7.3Test Network Authentication Process

7.4Test SDP Authentication Process

7.5Reliability Testing

7.6Test GUI

7.7Test Logger

7.8Safety Testing

7.9Platform Constrains Testing

8Task List

9Appendix

9.1System establishment

9.2RADIUS and DIAMETER protocols

9.2.1RADIUS message:

9.2.2DIAMETER message

1Use Cases

1.1Use Case UC1 – Connection Request

The story:

SDP supplicant (device) receives network connection request from SDP subscriber.

Primary Actor:

SDP subscriber

Stakeholders and Interests:

Subscriber - wants to connect to the network.

SDP gives network services only to known Subscriber.

Preconditions:

The AuthenticationCenter is initialized and running.

The required SDP has registered to the AuthenticationCenter.

Post conditions:

The subscriber receives accept or reject connection to the SDP.

Actor – SDP Subscriber / System
1. connection request
15. Received response and connect to the network. /
  1. The supplicant sends to the Authentication Enforcer initialize event – request for establishing connection.
  1. The Authentication Enforcer suspends supplicant from connecting.
  2. Handshake(UC 3) between supplicant andAuthentication Enforcer.
  3. Authentication Enforcer sends the authentication request to the AuthenticationCenter.
  4. The AuthenticationCenter parses the authentication request in order to get the SDP realm.
  5. Repository Query (UC 5) by the AuthenticationCenter.
  6. Protocol Conversion(UC 2).
  7. Route request(UC 12) to target SDP.
  8. Receive answer from SDP.
  9. Protocol Conversion(UC 2) on the received answer.
  10. AuthenticationCenter sends the converted answer to the Authentication Enforcer.
  11. Authentication Enforcerenables supplicant connecting to the network.
  12. Send response "accept".
  1. Update logger.

Alternative: Reject Connection

Actor – SDP Subscriber / System

14. Received response - end session. / …
12. Disable supplicant connecting to the network.
13. Send response "reject".
15. Drop the connection - end session.
16. Update logger.

1.2Use Case UC2 - Protocol Conversion

The story:

AuthenticationCenter operates the converter with the authentication request and the destination protocol. The converter converts the request if needed and returns the new request.

Primary Actor:

Converter

Stakeholders and Interests:

AuthenticationCenter should send authentication request in a known protocol to the SDP.

Preconditions:

Converter supports source and destination protocols.

AuthenticationCenter knows destination SDP protocol.

Post conditions:

Authentication request is in destination protocol.

AuthenticationCenter / Converter
  1. Handle authentication request with destination protocol.
5. Receive converted request.
6. Update logger. /
  1. Check if conversion is needed[1].
  2. Convert authentication request to destination protocol.
  3. Return the converted request.

1.3Use Case UC3 – Handshake

The story:

The System identifies the subscriber or an application that want to access the network or use services respectively.

Primary Actor:

System (Authentication Enforcer, AuthenticationCenter –EAP-MD5 Authenticator[2]).

Stakeholders and Interests:

SDPs give network access and services only to known users, therefore AuthenticationCenter needs to identify the user (subscriber , application) .

Preconditions:

- The system and client support the same identification protocols (In P.O.C the system/client support EAP-MD5 protocol).

- Client has already triggered the connection to the system.

Post conditions:

System has information that can be used to identify the client by the SDP.

Client
(subscriber , Application) / System
(Authentication Enforcer, EAP-MD5 Authenticator)
  1. Return hash client ID with his password and the challenge + SDP server.
/ 1. Create and Send randomized challenge.
3. Received message and append the challenge.
4. Query Repository (get SDP authentication server address) (UC5).
5. Send hashed message to the SDP authentication server and wait for answer (valid/not valid).
6. Update logger.

1.4Use Case UC4 – Initial Access

The story:

Before application is being authorized to use the service, must first authenticate itself with the AuthenticationCenter. For this purpose the application needs a reference to the Initial Contact interfaces of the AuthenticationCenter;

Primary Actor:

Client Application

Stakeholders and Interests:

Application shall obtain a reference to AuthenticationCenter interface that supports the required functionality.

SDP’s Subscriber who uses the application shall get the service.

Preconditions:

The AuthenticationCenter is initialized and running.

Post conditions:

The application obtains a reference to the Initial Contact interfaces.

Actor – Client Application / System –AuthenticationCenter
(EAP-MD5 Authenticator)
1. Send initiate authentication
3. Select Authentication Mechanism (EAP-MD5[3]).
4. Send challenge– identify the AuthenticationCenter.
6. Authenticate the “AuthenticationCenter”, send authentication succeeded.
8. Request access
10. Select signing algorithm
12. Ask for reference of the interface that supports the required service functionality. / 2. Return a reference to its authentication interface.
5. Return challenge response.
7. Handshake(UC 3) – identify the Application
9. Return a reference to the access interface.
11. Return signing algorithm confirmation.
13. Return reference of the interface.
14. Update logger.

Alternative: Authenticate the “AuthenticationCenter” failed

Actor – Client Application / System - EAP-MD5 Authenticator

  1. Authenticate the “AuthenticationCenter”, send authentication failed.
9. Close session. /
  1. Close session.
  2. Update logger.

1.5Use Case UC5 – Query Repository

The story:

Repository contains details about all registered SDPs. In order to send authentication request, the AuthenticationCenter selects records from the repository. The repository record contains the following details: SDP address, SDP authentication protocol, unique id, etc.

Primary Actor:

AuthenticationCenter

Stakeholders and Interests:

The AuthenticationCenter shall know the SDP’s details.

Preconditions:

The AuthenticationCenter is initialized and running.

The AuthenticationCenter received authentication request for supplicant or application authentication with specified SDP

(by SDP realm or service).

Post conditions:

Answer is returned (SDP record details or null).

AuthenticationCenter / Repository
1.Get connection to the repository
3. Send ‘select’ query to the repository.
6. Receive SDP details
7. Update logger. / 2.Allocate connection
4. Execute query
5. Return SDP details

Alternative: Requested record doesn’t exist

AuthenticationCenter / Repository

6. Receive null object answer
7. Update logger. / …
5. Return null object

1.6Use Case UC6 – View Logger

The story:

The administrator shall view all the activities and the processes in the system.

Primary Actor:

The administrator

Stakeholders and Interests:

The administrator wants to trace the activeness of the system.

Preconditions:

The AuthenticationCenter is initialized and running.

Post conditions:

Logger records are shown.

Actor - Administrator / System - AuthenticationCenter
1. Send ‘show logger’ request. / 2. Show the logger records.

1.7Use Case UC8 – Application Terminate Access

The story:

Application can terminate use of all services. This type of termination is unusual, but possible.

Primary Actor:

Application

Stakeholders and Interests:

The application decides to terminate its access session and all its service agreements in one go.

The AuthenticationCenter deletes all agreements with the application - updates the new application's status.

Preconditions:

The application has been already authenticated by AuthenticationCenter.

The application received access permission (UC 4 Initial access is done).

Post conditions:

The application is no longer authenticated with the AuthenticationCenter. AuthenticationCenter destroyed all service interfaces that were used by the application.

Actor – Application / System – AuthenticationCenter
(EAP-MD5 Authenticator)
1. Send request to terminate the access.
3. Close the connection. / 2. Destroy all interface agreements (service manager) with the application.
4. Close the connection.
5. Update logger.

1.8Use Case UC9 – System (AuthenticationCenter) Terminate Access

The story:

The AuthenticationCentercan terminate an application's use of all service instances. This type of termination is unusual, but possible. Note that if at any point the AuthenticationCenter’s level of confidence in the identity of the application becomes too low, perhaps due to re-authentication failing, the AuthenticationCentershould terminate all outstanding service agreements for that application.

Primary Actor:

AuthenticationCenter

Stakeholders and Interests:

SDPs want high level security and assurance that services are provided to approved applications only.

In a security model, where the AuthenticationCenter has decided that it can no longer trust the application and will therefore terminate all contact with it.

Preconditions:

The application has been already authenticated by AuthenticationCenter.

The application received access permission (UC 4 Initial access is done).

Post conditions:

The application is now no longer authenticated with the AuthenticationCenter. AuthenticationCenter destroyed all service interfaces were using by the application.

System – AuthenticationCenter
(EAP-MD5 Authenticator) / Actor – Application
1. Send access termination message.
3. Destroy all interface agreements (service manager) with the application.
4. Drop connection.
5. Update logger. / 2. Receive message and disconnect (accepted behavior).

1.9Use Case UC10 - Announcement of services & request for authorization

The story:

An application uses external services in order to carry out its own purpose. It registers to the Authentication center with a list of services she is going to use during the session.

The AuthenticationCenter shall check the application's permissions for each service by authenticating it with the service's provider, namely the SDP.

Selecting the most suitable service from all same purpose services is out of our scope.

Primary Actor:

An Application

Stakeholders and Interests:

Application needs information/services that it can't reach by itself (for example: compute services, information that depends on technologies such as 'get_location').

SDPs provide services and charge the application.

Preconditions:

The application has already identified by authentication center and it got initial access (UC 4).

Post conditions:

The application is registered within the AuthenticationCenter for the list of services she declared. For each service the Center knows weather the application is authenticated to use it or otherwise.

Actor – Application / System
  1. Send list of required services
4. Receive "authorization finished". / 2. for each service[4]:
2.1 Insert new Application-Server
record into the repository
2.2 Repository Query (UC 5).
2.3Route request (UC 11).
2.4 Receive answer from SDP
authentication server.
2.5 Update authentication status in the
repository
3. Send "authorization finished" message
  1. Update logger.

1.10Use Case UC11 – Service Request

The story:

Application activates a service.

Primary Actor:

An Application

Stakeholders and Interests:

Application needs information/services that it can't reach by itself (for example: compute services, information that depends on technologies such as 'get_location').

SDPs provide services and charge the application.

Preconditions:

The application has already Announcement of services and request for authorization (UC10).

The required service exists on the list of services which the application asked to use (UC 10).

Post conditions:

The application receives accept or reject for use of the activatedservice.

Actor – Application / System
1. Activates a service.
  1. Received "accept"and gets the service.
/
  1. Suspend the application from using the service.
  1. Select from repository the authentication status of the application for using the required service.
  1. Return "accept" and permit the use of the
service.
  1. Update logger.

Alternative: Application is not permitted to use the required service

AuthenticationCenter / Repository

  1. Received "reject"and doesn't get the service.
/ …
  1. Return "reject" and block the application from using the service.
  1. Update logger.

1.11Use Case UC12 – Route Request

The story:

The AuthenticationCenter needs to connect to SDP authentication server for every authentication request. The SDP authentication server knows all its subscribers and which applications are authorized to use its services.

Primary Actor:

System (AuthenticationCenter)

Stakeholders and Interests:

The AuthenticationCenteruses the knowledge and the responsibilities of the SDP authentication serverby sending it authentication requestswhich it is authorized to approve or refuse.

Preconditions:

SDP address is known.

Protocol conversion is done (if needed).

Post conditions:

Received response to the authentication request.

System (AuthenticationCenter) / SDP Authentication Server
1. Establish connection (according to the address) to desired SDP Authentication Server.
2. Send request that contains: client id (application or subscriber that wants the service), mandatory parameters.
4. Receive response. / 3. Receive the request, check permissions and send response.

2Data Model

2.1Description of Data Objects

2.1.1Administrator

Field Name / Type / Description
ID / String / The administrator identity card number
First Name / String / The administrator first name
Last Name / String / The administrator last name
User Name / String / The administrator login name to the system
Password-Hash / String / The administrator password hash to the system

2.1.2Subscriber

Field Name / Type / Description
ID / String / The subscriber identity card number
User Name / String / The subscriber login name to the system
From Date / Date / The date the subscriber got his subscription to the SDP
Expired Date / Date / The date the subscriber's subscription to the SDP ends
Shared-Secret / String / The shared secret key which will be used to encrypt the messages

2.1.3Supplicant

Field Name / Type / Description
ID / String / The supplicant Domain address
Chap-Password / String / The supplicant chap password for identification
Protocol Type / String / The supplicant authentication protocol type
Authenticator / Object / The supplicant knows the authenticator

2.1.4Application

Field Name / Type / Description
Id / String / The application identity number
Name / String / The application's name
Services-List / Objects Collection / The application holds a list of services it uses

2.1.5Service

Field Name / Type / Description
Id / String / The service identity number
Type / Enum / The type of the service
Description / String / The service description

2.1.6SDP

Field Name / Type / Description
Id / String / The SDPidentity number
Domain / String / The SDP domain name
Authentication-Center-Port / String / The SDPAuthenticationCenterPort
Protocol-Type / Collection / The SDP’s authentication protocol type
Services-List / Objects Collection / The SDP holds a list of services it provides
Subscribers-List / Objects Collection / The SDP holds a list of its subscribers

2.1.7Registered SDP

Field Name / Type / Description
AuthenticationCenter / Object / The registered SDP knows the authentication center

2.1.8Authenticator

Field Name / Type / Description
IP / String / The IP address of the Authenticator
Port / Number / The port of the Authenticator
AuthenticationCenter / Object / The authenticator knows the authentication center

2.1.9AuthenticationCenter

Field Name / Type / Description
IP / String / The IP address of the Authenticator
Port / Number / The port of the Authenticator
Registered-SDP-List / Objects Collection / The AC holds a list of its registered SDPs
Converter / Object / The AC knows the converter
Authenticator / Object / The AC knows the Authenticator

2.1.10Converter – no data members

2.2Data Objects Relationships

2.3Databases

2.3.1ERD (Entity-Relation Diagrams)

2.3.2Main Tables

2.3.2.1SDPs_DATA

This table describes the SDPs’ Authentication servers. For every SDP, the table stores its realm (SDP’s unique identifier), the address of its authentication server and authentication server protocol.

Fields:

Field Name / Type / Note
SDP_Authentication_Realm / Text / Primary Key. (e.g. " bgu.ac.il ")
Protocol / Text / Primary Key.
Permitted Values: RADIUS, DIAMETER
SDP_Authentication_Server_Address / Text / IP address format
Port / Number
2.3.2.2SERVICES_DATA

This table describes services provided by the SDPs. For every service, the table stores its details and the Address of SDP Authentication Server belonging to SDP which provides the service.

Fields:

Field Name / Type / Note
Service_ID / Number / Primary Key
SDP_Authentication_Realm / Text / Foreign Key.
Service_Type / Text
Service_Description / Text
2.3.2.3LOG_FILE

This table stores information about operations executed in the system.

Fields: