Docstoc

ARD

Document Sample
ARD Powered By Docstoc
					Motorola Software Group & BGU Project:

  Authentication Center for SDP Federation
       Proof of Concept for Extension to IMS in SDP Federation Area


    Application Requirements Document
                  (ARD)




           Name                  ID                  E-Mail             Phone
     Alina Mirinzon           306066481     alinamir@bgu.ac.il        054-4797793
     Gabi Brontvin            305988370     bruntvin@bgu.ac.il        054-7512199
     Raz Zeiber               036469419     razzi@bgu.ac.il           052-5269026
     Dadi Suissa              040580003     suissad@bgu.ac.il         052-6093601

Industrial Adviser: Mr. Yehezkel Dangoor             dangoor@motorola.com    03-5658956
Academic Adviser: Prof. Ehud Gudes                   ehud@cs.bgu.ac.il       08-6477138


The project’s website:   http://www.cs.bgu.ac.il/~razzi
                                      Page 1 of 41
                                    Revision Control


Rev.         Detailed Description          Paragraph Reference       Approved by       Date

0.1    Original draft                                  -             Industrial    7 Dec 2006
                                                                     advisers,
                                                                     Academic
                                                                     adviser,
                                                                     Projects
                                                                     assistant
0.2    Including Motorola ARD          1 – Introduce                 Industrial    13 Dec 2006
       review comments                      1.1 – Vision             advisers
                                       2 - Functional Requirements
                                            2.1 - Authentication
                                            Realms Repository
                                            2.2 - EAP Proxy
                                            2.6 - EAP-MD5
                                            Authenticator
1.0    Release                                                                     16 Dec 2006
2.0    Update use-case Connection      Section 4.2.1 – Connection    Raz Zieber    30 Dec 2006
       Request                         Request
2.1    Update use-case image           Section 4.2 use-case          Raz Zieber    30 June 2007
2.2    Remove Use Case UC7 -           Section 4.2 use-case          Raz Zieber    30 June 2007
       Initialize System
2.3    Add Use Case UC10 -             Section 4.2 use-case          Raz Zieber    30 June 2007
       Announcement of services &
       request for authorization




                                      Page 2 of 41
                                                    Table of Contents

1    Introduction .......................................................................................................................... 5
  1.1     Vision ........................................................................................................................... 6
  1.2     The Problem Domain ................................................................................................... 7
  1.3     Stakeholders ............................................................................................................... 12
  1.4     Software Context ....................................................................................................... 12
  1.5     System Interfaces ....................................................................................................... 16
     1.5.1     Hardware Interfaces ........................................................................................... 16
     1.5.2     Software Interfaces & Protocols ........................................................................ 16
     3.5.1     Events ................................................................................................................. 16
2    Functional Requirements ................................................................................................... 17
  2.1     Authentication Realms Repository ............................................................................ 17
  2.2     EAP Proxy ................................................................................................................. 17
  2.3     Converter.................................................................................................................... 17
  2.4     Network Gateway ...................................................................................................... 18
  2.5     EAP-MD5 Supplicant as OSA/Parlay compliant Application................................... 18
  2.6     EAP-MD5 Authenticator ........................................................................................... 19
  2.7     GUI ............................................................................................................................ 19
3    Non-Functional Requirements ........................................................................................... 20
  3.1     Performance constraints ............................................................................................. 20
     3.1.1     Speed, Capacity & Throughput.......................................................................... 20
     3.1.2     Reliability........................................................................................................... 20
     3.1.3     Safety & Security ............................................................................................... 20
     3.1.4     Portability........................................................................................................... 20
     3.1.5     Usability ............................................................................................................. 21
     3.1.6     Availability ........................................................................................................ 21
  3.2     Platform constraints ................................................................................................... 21
  3.3     SE Project constraints ................................................................................................ 21
  3.4     Special restrictions & limitations ............................................................................... 21
4    Usage Scenarios ................................................................................................................. 22
  4.1     User Profiles – The Actors......................................................................................... 22
  4.2     Use-cases.................................................................................................................... 22
     4.2.1     Use Case UC1 – Connection Request ................................................................ 23
     4.2.2     Use Case UC2 - Protocol Conversion ................................................................ 25
     4.2.3     Use Case UC3 – Handshake .............................................................................. 26
     4.2.4     Use Case UC4 – Initial Access .......................................................................... 27
     4.2.5     Use Case UC5 – Query Repository ................................................................... 29
     4.2.6     Use Case UC6 – View Logger ........................................................................... 30
     4.2.7     Use Case UC8 – Application Terminate Access ............................................... 31
     4.2.8     Use Case UC9 – System (Authentication Center) Terminate Access ............... 32
     4.2.9     Use Case UC10 - Announcement of services & request for authorization........ 33
     4.2.10 Use Case UC11 – Service Request .................................................................... 35
     4.2.11 Use Case UC12 – Route Request....................................................................... 37

                                                          Page 3 of 41
  4.3    Special Usage Considerations .................................................................................... 37
5    Appendices ......................................................................................................................... 38
  5.1    Additional Clarification: ............................................................................................ 38
  5.2    Project Risks .............................................................................................................. 38
  5.3    Glossary ..................................................................................................................... 38




Note:
         The remark *x beside several terms is the number and the reference to them in the
         Glossary which is placed in Appendices, Paragraph 5.3.




                                                         Page 4 of 41
1 Introduction
  Motorola Software Group (MSG) Israel is participating in various IMS*14 (IP
  Multimedia Subsystem) projects to facilitate convergence among wireless technologies.
  The Authentication Center deals with federation aspects of authentication and security
  for Service Delivery Platforms (SDPs*4).

  Some Background:

   The concept of Service Delivery Platforms (SDP) is to facilitate extensive deployment
    of services*16 and applications*15 on top of next generation network technologies.

   The concept of Federated Service Delivery is to enable service providers to co-operate
    as a federation in order to provide unified services across administrative domains and
    networks (for example Multimedia Session Control and Mobility).

   Federation of Service Delivery Platforms (SDP), i.e. how multiple Service Delivery
    Platforms can co-operate, is a key concept for Seamless Mobility. As a federation,
    Third Party Service Providers (3PSPs) can assure end-user connection not only anytime
    and anywhere – buy with any service.

   Existing SDP Federation solutions suffer diverse authentication protocols and security
    policies between Access Networks, Service Platform Operators and Service Providers.



                                                                       “Find Friends”
                             WiFi                                        service is
                                                        PSTN
                      Enterprise Network                PLMN
                                                                        available to          Service
                                                                                           Content Providers
                                                                                          Content Providers
                                                                         end- users          Providers
                          Cellular                                     regardless of
                           Access
                        Technologies
                                                                      access network
                           CDMA 1X, DO-A                   INTERNET
                                                                                            Video
                         GSM / GPRS / HSDPA                                                 World
                                                                                          Find
                           WiMAX                                        Gateways         Friends
                       802.16e, Flarion,                                                      Find
                            Navini                                                          Restau
                                                                                              rant

                                                                        SDP
                                                     Backbone 1
       Automobile           WiFi
        Networks           Hotspot
                                                                        K-Serve

                         WiFi / DSL

                                                                       SDP
                        Home / SOHO
          Home                                       Backbone 2
         Networks
                                                                        XTerme
                           Wire line
                      FTTP/FTTC/DSL/HFC

      Devices &           Access                   Transport          Convergence       Applications
       Clients           Networks                  Networks            Networks          & Content



                                              Page 5 of 41
1.1 Vision
 The IMS*14 (IP Multimedia Subsystem) standard evolves around fast introduction of
 multimedia services, facilitating convergence and service ubiquity. It does not yet cover
 the service orchestration aspects and the interaction between service delivery platforms.
 Service delivery platforms (SDPs) are becoming important as more application*15
 servers are being introduced to multiple networks. The issue of standardization of inter
 SDP authentication becomes more critical.
 The project goal is to research, design and implement a proof of concept*12 for the
 security and authentication aspects in the SDP as a base for a future proposal for IMS
 standard extension in this area.
 The project outcome expected to be an Authentication Center for SDP (Service
 Delivery Platform) Federation serving multiple authentication decision-points and
 security policies.
 The Authentication Center shall deal with various authentication issues that are currently
 lack sufficient solutions in IMS. This project is focused on SDP authentication.


 Let's look at some usage examples:
      An application allowing video conferencing over mobile terminals and smart
         phones along with chat and presence services*16 across multiple wireless
         technologies. This service will be provided by an application service provider.
         The various cellular/wireless operators each with its own service delivery
         platform mandates each SDP*4 to “know” all other SDP and ends up in service
         denial in any case of authentication/privacy inconsistency between multiple SDPs.
      An owner of mobile phone, subscribed to cell phone Company in his country.
         While staying abroad, he will be able to connect to various local application
         service companies without replacing his mobile phone. The authentication will be
         handled by the Authentication Center without any pervious coordination between
         the two companies.
      Costumer will be able to choose any application service provider over available
         communication infrastructure according the price, quality, etc.
      A cellular company client wants to get services from a WiMAX network but he
         isn‟t registered, so the WiMAX provider refers to the Authentication Center for
         an authorization. The Authentication Center will turn to the cellular provider for
         approval of this specific user, and if permitted the client will be able to use the
         WiMAX network. The billing will be through the cellular company.
      A customer of one cellular company that doesn‟t have coverage in a certain area
         will be able to get his network services via infrastructure of another reachable
         cellular provider.




                                   Page 6 of 41
1.2 The Problem Domain
 Service Delivery Federation architecture faces issues of diverse authentication protocols
 and security policies between Access Networks, Service Platform Operators and Service
 Providers. This interaction is not covered by the current IMS*14 standard.
 MSG proposal deals with three different security issues:
 Network Authentication, SDP Authentication and Privacy Policy.

 Following is a short description of each issue, along with the traditional solution for it
 and the solution suggested in MSG‟s proposal.

 a) Network Authentication:

    Short description:
    Network authentication involves the handling of an authentication request initiated
    by the subscriber, in which it requests services*16 provided by a different SDP*4
    (belonging to the SDP federation). The request is received at the local SDP via the
    access network to which the subscriber is connected. Since the local SDP cannot
    authorize it, it has to forward it to the subscriber‟s home SDP.
    This authentication process is a precondition for establishing a connection between
    the client and the desired SDP.
    Figure 1 illustrates a subscriber that is connected to SDP#1, but wishes to receive
    services from SDP#4, which he is subscribed to.

    Traditional solution:

    Existing solution supports forwarding of authentication requests from one SDP to
    another. However, in those solutions each SDP must register to all other SDPs in the
    federation, which ends up in severe data multiplication and maintenance nightmare.
    In order to communicate, the two SDPs have to use the same authentication protocol,
    so each SDP has to support the protocols of all other SDPs. In addition, agreements
    between SDPs are needed.
    This solution causes duplicate implementation of protocols, because every SDP
    needs to know how to communicate in all protocols that are used in the network.

     User 1
          Connection
           request
                          SDP#1                            SDP#3

                                                                                          User 1
                          SDP#2                            SDP#4             Subscribed




                 Figure 1: Traditional Solution for network Authentication

                                    Page 7 of 41
Suggested solution:

The Authentication Center shall receive the request for authorization and handle it
(Figure 2). The benefit is that each SDP is registered only to the Authentication
Center rather then to all other SDPs.
In addition, the Authentication Center will handle the conversion from one protocol
to another, in case the two SDPs use different authentication protocols.
The SDPs are required to know only the center, and refer to him for any
authentication request.
All the network information (SDPs‟ addresses and protocols) is concentrated by only
one entity – the Authentication Center.



                                    Authentication/
                                    Privacy Center
User 1
     Connection
      request                        Authentication
                  SDP#1               Proxy Server                      SDP#3
                                                                                             User 1

                  SDP#2                                                 SDP#4   Subscribed




              Figure 2: Suggested solution for Network Authentication




                                Page 8 of 41
b) SDP Authentication

   Short description:
   Application*15 wants to use a specific service*16. In order to get it, the application
   needs to authenticate with the service provider (the required service and the
   application can be on the same or on different SDPs).
   In some cases a single application can request more then one service, where each
   service can be provided by different SDP.
   For example, the user operates an application of searching restaurants in his current
   location. This application "find_a_ restaurants" uses the service “get_location”
   provided by other SDP. The application is required to identify itself in order to get
   the service.

   Traditional solution:
   The application tries to find all available services with the same functionality.
   It has to ask each server what it supports, in order to reject those that aren‟t suitable
   to its needs.
   Therefore the application has to authorize with all servers, and only then choose the
   most suitable and profitable service (Figure 3).

   The main problems in this solution are:
    Repetition of the authentication process.
    Application will check servers that will appear to be irrelevant.
    No standard for service request protocols.
    Application service request should suite to Server protocol.




        Client
                                                                            Service
      Application
                                SDP#1                 SDP#2

                 Figure 3: Traditional solution for SDP Authentication




                                  Page 9 of 41
          Suggested solution:
          An Authentication Center shall implement the authentication process and service
          request, using standard API – OSA/Parlay *5 (Figure 4).
          An application provides a list of desired services to the framework and the
          framework should provide to the application a list of SDPs that implement those
          services and which the application is authorized to use.
          The center shall give to application only the available and relevant services (defined
          by OSA/Parlay framework).

          Resolve Issues:
           The Authentication Center enables no repetition of the authentication process.
             The application will authenticate only with the provider of the chosen service
             through the Authentication Center.
           By implementing standard API (OSA/Parlay, EAP-MD5*9) we get rid of the
             diversity of authentication protocols and standardize the process of service
             requests.
           The center provides only the relevant services according to parameters given by
             the application (out of our scope).



                                             Authentication/
                                             Privacy Center

                     EAP Supplicant           Authenticator           EAP Authenticator
                                               Proxy OSA
                                                Gateway
                                                                                              Service

Client Application       SDP#1                                                 SDP#2


                         Figure 4: Suggested solution for SDP Authentication




     c) Privacy Policy

          Encrypted traffic is not available due to diversity of privacy policies.
          The authentication center shall provide communication solution on subjects of
          security policy regulator and privacy gateway.
          This component is included in MSG‟s proposal, but was left outside the scope of the
          BGU project we were requested to perform (see Figure 5).




                                         Page 10 of 41
      The following Figure 5 describes the traditional solution vs. the suggested one, on all
      three subjects in the MSG proposal. We can see that all the presented issues handled by
      one unified authentication center.

      The authentication center solves all three issues: SDP authentication, network
      authentication and privacy diversion. The BGU project is aimed to provide a proof of
      concept*12 for the first two issues: network authentication and SDP authentication.



             Traditional Solutions                                                            Suggested Solution
                                       Issue addressed: Either each SDP shall know
   a) Network Authentication           all SDP or sequential request/response                        Authentication/             Access
                                                                                                                                 Network
                                                                                                     Privacy Center
                                       Access
       SDP#1           SDP#3           Network                                       SDP#1                                    SDP#3
                                                                                                     •Authentication
       SDP#2           SDP#4                                                         SDP#2           Proxy Server            SDP#4
                                     Issue addressed: Diversity of authentication
   b) SDP Authentication             protocols.                                                      •Authenticator
                                                                                    EAP Supplicant   Proxy OSA         EAP Authenticator
                                                                                                     Gateway
      SDP#1            SDP#2
                                                                                     SDP#1           •Security               SDP#2
                                                                                                     Policy
                                                                                                     Regulator
   c) Privacy Policy                 Issue Addressed: Encrypted traffic
                                     not available due to diversity of
                                     privacy policies.                                VPN            •Privacy                  SSL
       VPN               SSL
                                                                                     SDP#1           Gateway                  SDP#2
     SDP#1             SDP#2
                        Subscriber                                                                                              Subscriber
                         of SDP#1                                                                                                of SDP#1



      Figure 5: Traditional solution vs. suggested solution, and BGU scope in the full MSG proposal




Common and different in the two issues of the BGU scope:

In the high-level point of view you can see Authentication Center as one entity that is
responsible for authentication, it gets an authentication request as an input from the end-user
(supplicant*13 or application) and returns accept or reject response.

In our scope, this high-level functionality can be separated into two main missions of
authentication that have different inputs and are processed differently:
a) Network Authentication – Responsible for entering the user to the network (access
    authentication). It's using conversion of authentication protocols if needed.
b) SDP Authentication – Responsible for authentication of applications in order to provide the
    desired service. It's using the OSA/Parlay*5 APIs for applications authentication.




                                                 Page 11 of 41
1.3 Stakeholders

 Target Population: Users of wireless network services.
 Customers: Motorola Software Group (MSG), Israel.
 Experts: Technical advisers of MSG.
 Sponsors: MSG, the Department of Software Engineering -University of
           Ben Gurion.


1.4 Software Context
 Our project, as defined by MSG, is aimed at providing a proof of concept*12 for
 Network and SDP authentication. Privacy aspects are outside the scope of this project.

 The Authentication Center that we develop for the proof of concept illustrates the
 following two functions:

 a) Network Access Authentication -
         The Authentication Center proof of concept shall illustrate Network
         authentication for subscriber of SDP whose Authentication server is the
         DIAMETER*3 one, while the Network Gateway may interface only with
                   2
         RADIUS* .

 b) SDP Authentication -
         The proof of concept shall illustrate an application which authenticate with
         another SDP in order to use one of its services.
         For this purpose, the proof of concept shall implement OSA/Parlay*5
         authentication interfaces using EAP-MD5*9 standard authentication protocol.


 Functionality of Network Access Authentication

 Input:
        Authentication request initiated by subscriber's unit.
 Output:
        Authentication response - accept or reject.

 High-level Process description:
 In the proof of concept there is no subscriber. There is a host that simulates a
 supplicant*13 (a) for a subscriber of SDP (c). This simulated subscriber wants to get
 services from a specific network. Therefore, he sends a request to the Network Gateway
 running EAP-MD5*9 authenticator (b). In order to connect the subscriber, permission of
 its SDP is needed.



                                   Page 12 of 41
Network Gateway (b) blocks the network connection until the subscriber is
authenticated. It sends request to the supplicant for the authentication identity.
Upon receiving the authentication request the supplicant sends the subscriber‟s identity
to the Network Gateway (handshake).
                                                                                     2
On the basis of the supplicant‟s response, the Network Gateway forms RADIUS*
message and sends it to the Authentication Center (c).
Authentication center (c) receives RADIUS message, extract from it the authentication
realm (extension, e.g. for "joe@bgu.ac.il" identity the "bgu.ac.il" is the authentication
realm), finds in the Repository the proper Authentication Server, converts message to the
one matching the Authentication Server protocol(in the proof of concept it‟s the
DIAMETER*3) and sends it to the required Authentication Server.
The Authentication Server verifies the subscriber and sends the appropriate DIAMETER
message back to the Authentication center.
Authentication center converts the message to RADIUS response and sends it to
Network Gateway, which in its turn converts the RADIUS message to the one for the
supplicant.
This authentication process involving Authentication Center behaves according to the
given EAP protocol. EAP-MD5 protocol is most fitting one for the sake of the Proof of
Concept.




                                                        c  Linux
                                                        Authentication center
                                                  UDP    EAP proxy
a  Windows                      b                          U
                                                        RADI S-DIAMETER
                                                                           Repository
                     Layer 2     EAP-MD5                    Converter
    EAP                           Authenticator
  supplicant                                i
                                  RADIUS clent
                                                                         TCP
(open source)                  Network Gateway                   SDP
                                                                 d    Linux
                                                                   DIAMET ER
                                                                  (open source)



                 Installation/Customization
                 Stub Development
                 Development/Integration


                   Figure 6: Components of Network Authentication

                                  Page 13 of 41
Functionaries:

     a. Supplicant*13 - The client's application supplying identity of a subscriber to
        Network Gateway under its request.
     b. Network Gateway - Authentication Enforcement Point (i.e. enforce
        authentication on the subscriber) requesting the subscriber‟s identity from the
        supplicant.
     c. Authentication Center - Authentication Proxy Point providing and forwarding
        the proper request to the required the following:
             Finding subscriber‟s Authentication server
             Conversion of Authentication Protocols (If required)
             Forwarding the authentication request to the subscriber‟s Authentication
               server
     d. The subscriber‟s authentication server belonging to SDP. This server is a
        Authentication Decision Point.



Functionality of SDP Authentication
Input:
          Request for authentication (in order to receive a service).
          Selected service.

Output:
          Authentication response - accept or reject.

High-level Process description:
Application*15 (a.a) is registered to several services (a.d). Before it can use a certain
service, authentication process is required for identification and billing. This process
determines whether the application is permitted to use the requested service.
Services are given by SDPs. The servers of the SDPs a.c) holding the services are
registered in the Authentication Center.
The application (a.a) refers to the Authentication Center (a.b) with a request for services
(a.d) and variety of parameters. The Authentication Center finds services that match the
given parameters and selects the most suitable services. Selecting the services is out of
our scope, we will handle the authentication process after the services and the owner
SDPs are already chosen.
Now, the Authentication Center (a.b) will refer to the authentication server (a.e) of the
specific SDP with an authentication request for the defined application and service (for
each required service).
It (a.b) will suspend the application from using the service until the authentication
process is completed. After getting the response it (a.b) will link the application and the
service's server so that the use of the service can proceed.
The OSA/Parlay*5 is API standard that will be implemented with standard protocols
(EAP-MD5*9).

                                   Page 14 of 41
                                                                     Services Server
                                        b                             c SDP #1
                                                                                              Services   d
        a  Linux                                Linux
          Parlay               J2SE         Authenticator       .           .     .
                                                                .           .     .
         Supplicant                       Parlay Framework      .           .     .
                                                                     Services Server
                                                   Repository         c SDP #n
                                                                                              Services   d


                                             TCP                        DIAMETER
  Framework Access                                                       Protocol
  Session Interfaces:
  IpInitial ; IpAccess ;              Authentication Server
  IpClientAccess ;
  IpAuthentication ;
                                       (Linux, DIAMETER)
  IpAPILevelAuthentication ;          e
                                                                                 Stub Development
                                                                                Installation/Customization
                                                                                 Development/Integration


                               Figure 7: Components of SDP Authentication

     Functionaries:

            a.   Supplicant*13 (SDP) - Application that uses OSA/Parlay API.
            b.   The Authentication Center - OSA/Parlay Authenticator.
            c.   Services Servers of different SDPs.
            d.   Suggested services*16.
            e.   The Authentication server of the SDP that provides the selected service.




Comment:
All functionaries mentioned in both parts above (except Authentication Center) will be
simulated for the proof of concept. Therefore, when we refer to SDP we mean – "The host that
simulates the SDP" and Application – "The software that simulates the application".




                                            Page 15 of 41
    1.5 System Interfaces
      1.5.1       Hardware Interfaces
                  Irrelevant. All the hardware of the system shall be simulated in software.

      1.5.2       Software Interfaces & Protocols
                 OSA/Parlay –An existing open API for the telephone network
                  (fixed and mobile). Applications shall refer to Authentication Center using the
                  OSA/Parlay interfaces.
                  The following interfaces1 shall be implemented:
                  a) IpInitial
                  b) IpAccess
                  c) IpClientAccess
                  d) IpAuthentication
                  e) IpAPILevelAuthentication

                  Usage: Activation of services by applications in a standard way. The interfaces
                  are implemented by the application and the Authentication Center.

                 EAP-MD5 (Message-Digest algorithm 5) - A widely used cryptographic hash
                  function with a 128-bit hash value. MD5 has been employed in a wide variety of
                  security applications.

                  Usage: The communication between Supplicant*13 and the Authentication
                  Center via Access Point that uses EAP-MD5.
                  Also, the OSA/Parlay shall be implemented with EAP-MD5 standard protocol.
                             2
                 RADIUS* (Remote Authentication Dial In User Service) - Radius is an AAA
                  (authentication, authorization and accounting) protocol for applications such as
                  network access or IP mobility. It is intended to work in both local and roaming
                  situations. Radius is extensible and uses UDP as the transport layer.
                  Usage: The SDPs of the network may use the RADIUS Authentication protocol.

                 DIAMETER*3 - Advanced version for RADIUS, uses TCP as transport layer.
                  Usage: The SDPs of the network may use the RADIUS Authentication protocol.

      1.5.3       Events
                 Establish connection – subscriber's unit initiates authentication request.
                 Request for service - By Application.


1
 Reference: The Parlay interfaces are specified in the document "3GPP TS 29.198-3 V5.8.0 (2004-09)" , which
can be found in the file "29198-03-580.doc" in the link:
http://www.3gpp.org/ftp/Specs/archive/29_series/29.198-03/29198-03-580.zip

                                             Page 16 of 41
2 Functional Requirements

 2.1 Authentication Realms Repository

  The Authentication Center maintains a repository of authentication servers.
  The repository enables adding, removing (out of our scope) and selecting records. The
  system shall route authentication requests from/to authentication servers of various
  SDPs. It selects from repository the authentication server‟s address by the server‟s
  unique identifier.

  2.1.1 Selecting
         2.1.1.1 Select SDP record.
         2.1.1.2 Select record of application's server.


 2.2 EAP Proxy
  The proxy shall query its local repository upon a request.
  The proxy receives authentication details (application, client). It selects from the
  repository the record that is needed for the authentication.
  In case supplicant (the one who asks the connection) and the destination server support
  various protocols, the proxy shall execute conversion on the request. Once the message is
  converted, the proxy sends it to the destination SDP.
  Return response – Accept or Reject.

  2.2.1. Receive authentication details (ID + password + SDP details).
  2.2.2. Select the record from the repository.
  2.2.3. Execute conversion (if needed).
  2.2.4. Send the message to SDP.
  2.2.5. Return the response.



 2.3 Converter
  The converter converts authentication protocol 'A' to authentication protocol 'B' and vice
  versa. The converter is needed in case the gateway (Access Point) and server implement
  various authentication protocols.
  In the MSG proposal the converter supports additional authentication protocols (our
  scope includes RADIUS-DIAMETER authentication protocols conversion).

  2.3.1. RADIUS-DIAMETER conversion.
  2.3.2. DIAMETER-RADIUS conversion.




                                    Page 17 of 41
2.4 Network Gateway
 Get connection request from supplicant. Manage EAP-MD5 protocol handshake through
 layer 2. In the end, sends connection request details to the Authentication Center via
 RADIUS protocol. While waiting for response, the gateway suspends the user from
 entering the network. Once the answer is received the network gateway will permit the
 user to enter the network or refuse respectively to the answer.

 2.4.1. Get an authentication request from the client in layer 2.
 2.4.2. Manage protocol handshake.
 2.4.3. Sends authentication request to the Authentication Center through RADIUS
         protocol.
 2.4.4. Suspend the user from entering the network.
 2.4.5. Enter the user or refuse, according to authentication response.



2.5 EAP-MD5 Supplicant as OSA/Parlay compliant Application
 The purpose of the client application is to provide a human-machine interface with one
 or more end-users. Since network protocols are rarely a good way for humans to
 communicate, the application must ensure that a request from a user is translated into an
 operation in the underlying telecoms network.
 This software talks to the network using network protocols. Unfortunately, there are
 many types of network and corresponding protocols. OSA/Parlay hides the nature of the
 underlying network. So a OSA/Parlay client application transmits OSA/Parlay operation
 into user events and vice versa. The transmissions to the network will be based on MD5
 standard.

 2.7.1. Request for service.
 2.7.2. Select a service.
 2.7.3. Receive a service.




                                  Page 18 of 41
    2.6 EAP-MD5 Authenticator
      The authenticator shall be implemented using OSA/Parlay Framework Authentication
      Interfaces. In order to allow the system to be robust and flexible there are number of
      functions that belong to a OSA/Parlay Framework.
      Given an application and a selected service, the Authenticator will forward the
      authentication request to the SDP Authentication server that is providing the service.
      While waiting for response, the framework suspends the application from getting the
      service. Once the request is permitted the application receives the service.

      OSA/Parlay includes many existing interfaces2. In our scope, the following OSA/Parlay
      interfaces shall be implemented based on MD5 standard:

      2.6.1. IpInitial
      2.6.2. IpAccess
      2.6.3. IpClientAccess
      2.6.4. IpAuthentication
      2.6.5. IpAPILevelAuthentication


    2.7 GUI
      The GUI shall show states of the authentication process for both Network and SDP
      authentication. The purpose of the GUI in the system is to display the simulation flow.
      The GUI will be consisted from:

        2.7.1. User connection.
               2.7.1.1. Insert user personal details
               2.7.1.2. Insert user connection details

               2.7.2. Connection and Application process notification.
               2.7.2.1. Initializing
               2.7.2.2. Connecting
               2.7.2.3. Accept\Reject
               2.7.2.4. Disconnecting

        2.7.3. Show Reports.




2 Reference: The Parlay interfaces are specified in the document "3GPP TS 29.198-3 V5.8.0 (2004-09)" , which
can be found in the file "29198-03-580.doc" in the link:
http://www.3gpp.org/ftp/Specs/archive/29_series/29.198-03/29198-03-580.zip

                                             Page 19 of 41
3 Non-Functional Requirements
 The system will be developed as a Proof of Concept in order to demonstrate the
 realizability of the idea. Therefore, the most of the Non-Functional Requirements are
 irrelevant to the purpose of our project.
 The MSG proposal (not in this proof of concept) has more strict Non-Functional
 Requirements.
 The Authentication Center proposed by MSG will involve redundant hosts schema with
 Load Balancing and High Availability functionalities.
 To each SDP, registered to the Authentication Center, there are number of subscribers.
 The number of subscribers determines the quantity of hosts.
 One Authentication Center is capable of authenticate simultaneously 50000 subscribers.
 The Network Gateway will consist of the IP address of the virtual Authentication Center
 host that will be responsible for Load Balancing and High Availability.



 3.1 Performance constraints


  3.1.1    Speed, Capacity & Throughput
           Irrelevant.


  3.1.2    Reliability
           99.999% correctness in supplying services and network access to entitled users
           only.


  3.1.3    Safety & Security
           3.1.3.1. The system uses RADIUS and DIAMETER authentication protocols.
           3.1.3.2. Identify clients by EAP-MD5 hash functions.


  3.1.4    Portability
           The components of the system will be developed on different operating systems:

           3.1.4.1. The Authentication Center - developed on Linux
           3.1.4.2. Supplicants - Windows EAP Supplicant and Linux OSA/Parlay
                   Supplicant
           3.1.4.3. SDPs – Linux RADIUS\DIAMETER




                                   Page 20 of 41
 3.1.5    Usability
          Irrelevant since the project is a proof of concept and no human interaction with
          the system is needed.


 3.1.6    Availability
          Irrelevant.



3.2 Platform constraints
 3.2.1. Most of the system will be implemented on Linux due to open source constrains.
 3.2.1. OSA/Parlay interfaces will be implemented with Java to enable local invoking.



3.3 SE Project constraints
 3.3.1. The demo of the system shall demonstrate the Authentication Center activities.
 3.3.2. The input will come from the user and from the application.
 3.3.3. The system is interactive: The user enters the input and starts the authentication
        process. The application generates the input to the Authentication Center.
 3.3.4. The system shall simulate the client, the application and the services.
 3.3.5. The data in our simulation will be samples of actual data.



3.4 Special restrictions & limitations
 Conformance to various standards: OSA/Parlay and MD5.




                                   Page 21 of 41
4 Usage Scenarios
 4.1 User Profiles – The Actors

  4.1.1. SDP authentication server.
  4.1.2. SDP subscriber.
  4.1.3. Application – Operated by the user.
  4.1.4. Administrator


 4.2 Use-cases




                                   Page 22 of 41
     4.2.1    Use 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 Authentication Center is initialized and running.
                     The required SDP has registered to the Authentication Center.
              Post conditions:
                     The subscriber receives accept or reject connection to the SDP.

              Actor – SDP Subscriber                                     System
1. connection request
                                                       2. The supplicant sends to AC initialize
                                                           event – request for establishing
                                                           connection.
                                                       3. Suspend supplicant from connecting.
                                                       4. Handshake (UC 3).
                                                       5. Repository Query (UC 5).
                                                       6. Protocol Conversion (UC 2).
                                                       7. Route request (UC 12).
                                                       8. Receive answer from SDP.
                                                       9. Protocol Conversion (UC 2).
                                                       10. Enable supplicant connecting to the
                                                           network.
                                                       11. Send response "accept".
12. Received response and connect to the network.
                                                       13. Update logger.


Alternative: Reject Connection
              Actor – SDP Subscriber                                     System
…                                                      …
                                                       10. Disable supplicant connecting to the
                                                            network.
                                                       11. Send response "reject".
12. Received response - end session.
                                                       13. Drop the connection - end session.
                                                       14. Update logger.

                                       Page 23 of 41
Page 24 of 41
      4.2.2      Use Case UC2 - Protocol Conversion

                 The story:
                       Authentication Center 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:
                         Authentication Center should send authentication request in a known
                         protocol to the SDP.
                 Preconditions:
                         Converter supports source and destination protocols.
                         Authentication Center knows destination SDP protocol.
                 Post conditions:
                         Authentication request is in destination protocol.


                  Authentication Center                                                Converter
4. Handle authentication request with destination
   protocol.
                                                                   5. Check if conversion is needed3.
                                                                   6. Convert authentication request to
                                                                      destination protocol.
                                                                   7. Return the converted request.
8. Receive converted request.
9. Update logger.




3
 In the P.O.C, system shall convert every request/response, meaning the condition predicate always returns
“TRUE”. The “if” is intended for generic solution – MSG proposal implementation.

                                              Page 25 of 41
         4.2.3     Use 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 (gateway –access point, Authentication Center –EAP-MD5
                                   Authenticator4).
                   Stakeholders and Interests:
                           SDPs give network access and services only to known users, therefore
                           Authentication Center 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                                                     System
                  (subscriber , Application)                           (gateway, EAP-MD5 Authenticator)
                                                                    1. Create and Send randomized challenge.
3. Return encrypted client ID with his password and
   the challenge + SDP server.
                                                                    3. Received message and append the
                                                                    challenge.
4. Update logger.




4
    In the P.O.C, system support EAP-MD5 protocol but it can be extended to more protocols.

                                               Page 26 of 41
         4.2.4     Use Case UC4 – Initial Access
                   The story:
                          Before application is being authorized to use the service, must first
                          authenticate itself with the Authentication Center. For this purpose the
                          application needs a reference to the Initial Contact interfaces of the
                          Authentication Center;
                   Primary Actor:
                          Client Application
                   Stakeholders and Interests:
                          Application shall obtain a reference to Authentication Center interface
                          that supports the required functionality.
                          SDP’s Subscriber who uses the application shall get the service.
                   Preconditions:
                          The Authentication Center is initialized and running.
                   Post conditions:
                          The application obtains a reference to the Initial Contact interfaces.


                  Actor – Client Application                                System – Authentication Center
                                                                              (EAP-MD5 Authenticator)
1. Send initiate authentication
                                                                    2. Return a reference to its authentication
                                                                     interface.
3. Select Authentication Mechanism (5EAP-MD5).
4. Send challenge – identify the Authentication Center.


                                                                    5. Return challenge response.
6. Authenticate the “Authentication Center”, send
authentication succeeded.
                                                                    7. Handshake – identify the Application (UC 3)
8. Request access
                                                                    9. Return a reference to the access interface.
10. Select signing algorithm
                                                                    11. Return signing algorithm confirmation.
12. Obtain reference of the interface that supports the
    required service functionality.
                                                                    13. Return reference of the interface.
                                                                    14. Update logger.




5
    In the P.O.C, system support EAP-MD5 protocol but it can be extended to more protocols.


                                               Page 27 of 41
         Alternative: Authenticate the “Authentication Center” failed
             Actor – Client Application                     System - EAP-MD5 Authenticator
…
6. Authenticate the “Authentication Center”, send
   authentication failed.
                                                     7. Close session.
                                                     8. Update logger.
9. Close session.




                                     Page 28 of 41
      4.2.5    Use Case UC5 – Query Repository
               The story:
                      Repository contains details about all registered SDPs. In order to send
                      authentication request, the Authentication Center selects records from
                      the repository. The repository record contains the following details: SDP
                      address, SDP authentication protocol, unique id, etc.

               Primary Actor:
                      Authentication Center

               Stakeholders and Interests:
                      The Authentication Center shall know the SDP’s details.

               Preconditions:
                     The Authentication Center is initialized and running.
                     The Authentication Center received authentication request with SDP‟s id
                     from client (supplicant or application).

               Post conditions:
                       Answer is returned (SDP record details or null).


              Authentication Center                                        Repository
1. Parse the authentication request in order to get the
   SDP id.
2. Get connection to the repository
                                                          3. Allocate connection
4.   Send „select‟ query to the repository.
                                                          5. Execute query
                                                          6. Return SDP details
7. Receive SDP details
8. Update logger.



          Alternative: Requested record doesn‟t exist
               Authentication Center                                       Repository
…                                                         …
                                                          6. Return null
7. Receive null answer
8. Update logger.




                                         Page 29 of 41
     4.2.6   Use 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 Authentication Center is initialized and running.

             Post conditions:
                     Logger records are shown.


               Actor - Administrator                           System - Authentication Center
1. Send „show logger‟ request.
                                                        2. Show the logger records.




                                       Page 30 of 41
     4.2.7     Use Case UC8 – Application Terminate Access

               The story:
                      Application can terminate use of all service. 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 Authentication Center deletes all agreements with the application -
                      updates the new application's status.

               Preconditions:
                     The application has been already authenticated by Authentication
                     Center.
                     The application received access permission (UC 4 Initial access is done).


               Post conditions:
                      The application is no longer authenticated with the Authentication
                      Center. Authentication Center destroyed all service interfaces that were
                      used by the application.


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




                                           Page 31 of 41
     4.2.8    Use Case UC9 – System (Authentication Center) Terminate Access

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

              Primary Actor:
                     Authentication Center

              Stakeholders and Interests:
                     SDPs want high level security and assurance that services are provided
                     to approved applications only.
                     In a security model, where the Authentication Center 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 Authentication
                    Center.
                    The application received access permission (UC 4 Initial access is done).

              Post conditions:
                     The application is now no longer authenticated with the Authentication
                     Center. Authentication Center destroyed all service interfaces were using
                     by the application.


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




                                       Page 32 of 41
         4.2.9       Use 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 Authentication Center 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 Authentication Center 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
                                                                    2. for each service6:
                                                                        2.1 Insert new Application-Server
                                                                           record into the repository
                                                                        2.2 Repository Query (UC 5).
                                                                        2.3 Route request (UC 12).
                                                                        2.4 Receive answer from SDP
                                                                           authentication server.
                                                                        2.5 Update authentication status in the
                                                                            repository



   6
     In case the same SDP gives more than one required service, there shall be one authentication request for all
   those services.

                                                  Page 33 of 41
                                                       3. Send "authorization finished" message
4. Receive "authorization finished".
                                                       5. Update logger.




                                       Page 34 of 41
         4.2.10    Use 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 (UC 10).
                         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 activated service.

                  Actor – Application                                          System
1. Activates a service.
                                                             2. Suspend the application from using the
                                                                service.

                                                             3. Select from repository the authentication
                                                                status of the application for using the
                                                                required service.

                                                             4. Return "accept" and permit the use of the
                                                                service.
5. Received "accept" and gets the service.

                                                             6. Update logger.




                                            Page 35 of 41
    Alternative: Application is not permitted to use the required service
              Authentication Center                                       Repository
…                                                          …
                                                           4. Return "reject" and block the application
                                                              from using the service.
5. Received "reject" and doesn't get the service.
                                                           6. Update logger.




                                           Page 36 of 41
     4.2.11    Use Case UC12 – Route Request

               The story:
                      The Authentication Center 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 (Authentication Center)

               Stakeholders and Interests:
                      The Authentication Center uses the knowledge and the responsibilities
                      of the SDP authentication server by sending it authentication requests
                      which 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 (Authentication Center)                         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.
                                                           3. Receive the request, check permissions
                                                              and send response.
4. Receive response and return to the component that
  started the transaction.




   4.3 Special Usage Considerations
      Irrelevant.




                                         Page 37 of 41
    5 Appendices

      5.1 Additional Clarification:

             MSG proposal regards to authentication center as the system and the components
             surrounding it: supplicant, access point (gateway), SDP authentication server,
             application, services and the servers providing them, as external entities (actors).
             Because we are implementing a proof of concept, we shall simulate (develop) those
             components and therefore we refer to them as part of our developed system. From
             our point of view, relatively to the system the access point is internal and the SDP
             authentication servers are external. Both clients - supplicant and application are
             external.


      5.2 Project Risks

            A lot of advanced networking technologies – wide knowledge and profound
             understanding is needed (OSA/Parlay, DIAMETER, RADIUS, EAP-MD5…).
            A lot of the project‟s components that are used for the simulation are open source.
             Integration between the developed and the open source is a weak point (for example:
             DIAMETER server and client, they are open source and might be incompatible).
            Open source is unsupported.


      5.3 Glossary7

         1. Authentication – The confirmation that a user who is requesting services is a valid
             user of the network services requested. Authentication is accomplished via the
             presentation of an identity and credentials. Examples of types of credentials are
             passwords, one-time tokens, digital certificates, and phone numbers (calling/called).

         2. RADIUS – Remote Authentication Dial In User Service is an AAA
             (authentication, authorization and accounting) protocol for applications such as
             network access or IP mobility. It is intended to work in both local and roaming
             situations.
             Some ISPs (commonly modem, DSL, or wireless 802.11 services) require you to
             enter a username and password in order to connect to the Internet. Before access to
             the network is granted, this information is passed to a Network Access Server
             (NAS) device over the Point-to-Point Protocol (PPP), then to a RADIUS server
             over the RADIUS protocol. The RADIUS server checks that the information is


7
    The Glossary based on Wikipedia - the free encyclopedia. http://en.wikipedia.org/wiki/Main_Page

                                               Page 38 of 41
     correct using authentication schemes like PAP, CHAP or EAP. If accepted, the
     server will then authorize access to the ISP system and select an IP address, L2TP
     parameters, etc.
     The RADIUS server will also be notified if and when the session starts and stops,
     so that the user can be billed accordingly; or the data can be used for statistical
     purposes.

3. DIAMETER – The name is a pun on the RADIUS protocol, which is the predecessor
    (a diameter is twice the radius). Diameter is not directly backwards compatible, but
    provides an upgrade path for RADIUS.

4. Service Delivery Platform (SDP) – A recently embraced architectural style applied
    to telecommunications infrastructure problems. It is intended to enable rapid
    development and deployment of new converged multimedia services, from basic
    POTS phone services to complex audio/video conferencing for multiplayer games
    (MPGs). SDPs typically provide a service creation environment, a service execution
    environment, and abstractions for media control, presence/location, integration, and
    other low-level communications capabilitities. SDPs are applied to both consumer
    and business applications, with the latter set often focused on the integration of
    telecom and IT capabilitities.

5. Open System Architecture (OSA) - A part of the 3rd generation mobile
   telecommunications network or UMTS (Universal Mobile Telecommunications
   System - one of the third-generation (3G) mobile phone technologies).
   OSA describes how services are architected in an UMTS network.
   The standards for OSA are being developed as part of the 3rd Generation Partnership
   Project (3GPP).
   The API for OSA is called Parlay (or Parlay/OSA or OSA/Parlay). The APIs
   developed jointly in collaboration by 3GPP, ETSI, and the Parlay Group. These APIs
   can be freely downloaded from the web.


6. Parlay – An open API for the telephone network (fixed and mobile).
    The Parlay Group is a technical industry consortium (founded 1998) that specifies
    APIs for the telephone network. These APIs enable the creation of services by
    organizations both inside and outside of the traditional carrier environment. In fact,
    it is hoped that services can be created by IT developers, rather than telephony
    experts.
    Important Parlay APIs include: call control, conferencing, user interaction (audio
    and text messaging), and charging. The APIs are specified in the CORBA Interface
    definition language and WSDL. The use of CORBA enables remote access between
    the Parlay gateway and the application code. A set of Java mappings allow the APIs
    to be invoked locally as well. A major goal of the APIs is to be independent of the
    underlying telephony network technology (e.g. CDMA vs GSM vs landline SS7).



                                 Page 39 of 41
7. IEEE - The Institute of Electrical and Electronics Engineers - an international non-
   profit, professional organization for the advancement of technology related to
   electricity.

8. IEEE 802 – Family of IEEE standards dealing with local area networks and
   metropolitan area networks. The IEEE 802 standards restricted to networks carrying
   variable-size packets. (By contrast, in cell-based networks data is transmitted in short,
   uniformly sized units called cells. Isochronous networks, where data is transmitted as
   a steady stream of octets, or groups of octets, at regular time intervals, are also out of
   the scope of this standard.)
   The services and protocols specified in IEEE 802 map to the lower two layers (Data
   Link and Physical) of the seven-layer OSI networking reference model. In fact, IEEE
   802 splits the OSI Data Link Layer into two sub-layers named Logical Link Control
   (LLC) and Media Access Control (MAC), so that the layers can be listed like this:

   Data link layer
        LLC Sublayer
        MAC Sublayer
   Physical layer
   The IEEE 802 family of standards is maintained by the IEEE 802 LAN/MAN
   Standards Committee (LMSC). The most widely used standards are for the Ethernet
   family, Token Ring, Wireless LAN, Bridging and Virtual Bridged LANs.

9. Extensible Authentication Protocol (EAP) – Universal authentication framework
   frequently used in wireless networks and Point-to-Point connections. Although the
   EAP protocol is not limited to wireless LAN networks and can be used for wired
   LAN authentication, it is most often used in wireless LAN networks.
   EAP is an authentication framework, not a specific authentication mechanism. The
   EAP provides some common functions and a negotiation of the desired authentication
   mechanism. Such mechanisms are called EAP methods and there are currently about
   40 different methods.
   When EAP is invoked by an 802.1X enabled NAS (Network Access Server) device,
   such as an 802.11 a/b/g Wireless Access Point, modern EAP methods can provide a
   secure authentication mechanism and negotiate a secure PMK (Pair-wise Master Key)
   between the client and NAS. The PMK can then be used for the wireless encryption
   session which uses TKIP (Temporal Key Integrity Protocol - a security protocol used
   in Wi-Fi Protected Access (WPA)) or AES (Advanced Encryption Standard)
   encryption.

10. EAP-MD5 - An IETF (IETF - Internet Engineering Task Force - develops and
    promotes Internet standards) open standard. The standard is based on the
    cryptographic hash function with a 128-bit hash value, a 32-character hexadecimal
    number.
    This EAP method offers minimal security - vulnerable to dictionary attacks, and does
    not support mutual authentication or key generation.


                                  Page 40 of 41
11. Fourth Generation (4G) -
    The WWRF (Wireless World Research Forum) defines 4G as a network that operates
    on Internet technology, combines it with other applications and technologies such as
    Wi-Fi and WiMAX, and runs at speeds ranging from 100 Mbps (in cell-phone
    networks) to 1 Gbits (in local Wi-Fi networks).
    4G is not just one defined technology or standard, but rather a collection of
    technologies and protocols to enable the highest throughput, lowest cost wireless
    network possible.
    The goal is to provide quality of service and rate requirements set by the forth coming
    applications like - multimedia messaging, mobile TV, High definition TV content,
    DVB, and also minimal service like voice and data at anytime and anywhere.
    Motivated by this target the 4G working groups defined objectives of the 4G wireless
    communication standard, such as -High network capacity ; All IP system, packet
    switched network …
    According to 4G working groups, the infrastructure and the terminals will have
    almost all the standards from 2G to 3G implemented. The system will also serve as an
    open platform where the new innovations can go with it.

12. Proof of Concept (P.O.C) - Short and/or incomplete realization (or synopsis) of a
    certain method or idea(s) to demonstrate its feasibility. It can be a demonstration in
    principle, whose purpose is to verify that some concept or theory is probably capable
    of exploitation in a useful manner.
    The proof of concept is usually considered a milestone on the way of a fully
    functioning prototype.

13. Supplicant - The term is used in the IEEE 802.1X standard. The supplicant is an
    entity at one end of a point-to-point LAN segment that seeks to be authenticated by
    an authenticator attached to the other end of that link

14. IMS (IP Multimedia Subsystem) - A standard architecture for telecom operators
    that want to provide mobile and multimedia services. The implementation based on a
    3GPP (3rd Generation Partnership Project) standardized implementation - uses open
    standard IP protocols. The aim of IMS is to provide current and future services. IMS
    gives network operators and service providers the ability to control and charge for
    each service. In addition, users have to be able to execute all their services when
    roaming or at home.

15. Application - Applications are tools that customers use over a network. They serve as
    alternative to web sites which, dynamic as they may be - have static content at their
    core. Applications, on the other hand, no matter how static they are in appearance -
    have dynamic data at their core.

16. Service - Services are a set of functions that permits easier development of
    applications. Example of services are: obtaining location of customer, obtaining status
    of customer (connected or turned off?), call control (for example: join a customer to a
    conference call), etc.

                                  Page 41 of 41

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:21
posted:3/31/2011
language:English
pages:41