; 34TD046_SSoS_RDS
Learning Center
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>



  • pg 1
									ETSI/TIPHON(03)#34                                                                   Temporary Document 046
                                                                                                                  page 1 of 9
                 Source: 3031R5 Editor, Paul Sijben
                   Title: RDS on Single Sign-on System
                 Notice: The author of this document declares that ETSI may make the document publicly available.
           Document for:       Decision:
                               Discussion:            X
                               Meeting Report:

  Contact details:
      First Name, Last Name    Paul Sijben
                     e-mail:   Paul@sijben.net

1 Decision/Action Requested
This document contains a first stab at a requirements definition study of the Single Sign-on System. It is proposed to
discuss the text and insert it into DTS 3031R5 to advance progress on this work item and identify gaps that require

2 Definitions
AS           Application Server
IMP         Instant Messaging & Presence
IP          Internetworking Protocol
RpoA        Registration point of Attachment
SLA         Service Level Agreement
SIP         Session Initiation Protocol
SpoA        Service point of Attachment

3 References
[1] ITU-T Recommendation H.323v4, 2001

[2] ITU-T recommendation H.225 v4, 2001

[3] SIP IETF Standards Track RFC 2543 bis 08, 2002

[4]     David P. Kormann and Aviel               D,       Rubin   Risks   of   the   Passport   Single   Signon     Protocol,
[5] ETSI TR-101 301 [1], TIPHON Release 3 definition (see also www.tiphon.org), 2001[6] ETSI TS 101 882
    TIPHON Protocol Framework , 2002

[7] ETSI RTR-101 301,TIPHON Release 3 definition, 2002

[8] Dynamic Host Configuration Protocol IETF RFC 2131

[9] PANA http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-00.txt

[10] IEE 802.1x

                                                                                                             : 3031R5 Editor, Paul Sijben
ETSI/TIPHON(03)#34                                                              Temporary Document 046
                                                                                                              page 2 of 9

4 Introduction
The purpose of the Single Sign-on System is to provide a coherent set of protocols to enable the user to easily address
one multiple services from multiple service providers and system integrators on one terminal.

Commercial telecommunications services require the establishment of the entitlement of a user to a service prior to its
usage. In traditional PSTN systems and in Enterprise data networks, this right is established by associating a port on a
switch to a user, and revocation of service entitlement is done by disconnecting the phone line or port suspension in
the telephone exchange. On a multi-service network carrying multiple services over the same access medium, a user
may be entitled to some services but not to other services offered over the same access medium. We, therefore, need
a protocol to that can be used to establish this entitlement on a per-service basis: we call this activity Registration.
Successful registration requires a number of steps,

1.   there needs to be a mechanism to Authenticate the user.

2.   Protection of the service provider‟s business model requires that users need to be Authorised: making sure the
     user is allowed the access to the requested services. For instance, during authorisation, the service provider may
     ensure that the user has enough credit in a pre-paid account for the requested service to be provided.

3.   Finally, once the user is authorised, resources may need to be reserved to provide the requested service reliably,
     and the user must be able to Attach to the dedicated Service Node. Please note that these resources may be
     reserved dynamically upon registration rather than static upon sign-up as is common on the switched networks.

The Single sign-on system eases the registration and attachment of a user to a number of services, by offering one
meta-service. We can not expect that there will be one provider of a single-sign on service. The increasingly
unbundled telecommunications environment requires that any solution in this space needs to support competition
between service providers that provide a sign-on system.

4.1 Context
This section lists a number of issues that need to be considered when evaluating registration mechanisms. In the
commercial context that we assume, we see that each user has a contract with at least one service provider regarding a
Service Offering (a commercial context in which to offer a specific service or set of services).

This contract will identify:

1.   The Service Offering, that the contract pertains to.

2.   The identity or identities (i.e. names) that the user will use for these services. The user will be reachable under
     these names and may use these as legal identities for outgoing sessions.

3.   An authentication secret that the user will use when seeking access to the service applications in the service

Not all services require prior registration, there may also be services for which no (user) contract needs to be
available. The most relevant of these are emergency services (for instance the 112 or 911 services on the public
telephone networks). Other non-contract services are (free) information services or other services that do not require
payment or authentication through a service provider.

When users are not connecting to their service provider directly they are roaming. This mechanism is well known
from GSM and other 2G cellular systems. Even on IP networks we can not assume that the service provider is
reachable because the local service provider may withhold access to the Internet until the identity of the user can be
established and sometimes not even after that. We therefore require a mechanism that allows roaming users to register
with local service providers who are affiliated with their home service provider.

ETSI/TIPHON(03)#34                                                                    Temporary Document 046
                                                                                                                      page 3 of 9

The single sign-on protocol (SSP) system has been developed for the ETSI/TIPHON project [5,6,7]. In the TIPHON
service-model, a user has a contract with one (or more) service provider(s). Prior to using the service, the user
attaches to the Service Node that provides the service. The Service Node that will be used for a particular service
may be known a-priori or may be selected dynamically, based on the context like user location, user permissions &
preferences and load-sharing.

5.1 General structure
Formalising the relationships described, Figure 1 shows how we can identify four separate roles in the sign-on, these
roles are:

1.   Registrant, the user at a terminal requesting service        Registrant           1- User Registration         Registrar
                                                                 (User at terminal)
2.   (Home) Registrar, the service provider with whom
     the user has a contract for the delivery of service                                                              2- Service
                                                               3- Service                Service Node/
3.   Service Provider, the company owning the entity
                                                               Attachment              Application Server
     (Service Node) that will deliver the service once                                   (Soft-Switch)          Service Node/
     entitlement has been established.
                                                                                                              Application Server
                                                                                                                 (IMP server)
4.   Visited Registrar, the service provider that will
     provide local access to the requested service offering
     (This role is covered in section 7.2, and figure 3).            Figure 1: General structure of SSP registration

The registration service allows a user at a terminal (Registrant) to register with a Registrar. The registration service
includes the authentication and authorisation of a subscriber (Registrant) to access a service. As a commercial pre-
requisite we state that a successful registration would normally lead to access to services a user is entitled to;
whereas, an unsuccessful registration would normally lead to refusal of service. The latter may however not apply in
certain cases, e.g. accessing emergency services.

There are four steps involved in the SSP registration process.

0.   Registrar discovery. The user terminal locates the appropriate registrar.

1.   User registration: The user registers for the service and shows entitlement for the service used.

2.   Service preparation: The registrar selects a Service Node at which the user shall use the service and informs the
     Service Node that the user is entitled to use the service.

3.   Service attachment: The user (terminal) attaches to the Service Node and the service can be delivered.

6 Relevant meta-protocols
Based on the Registration service requirements, we have developed a Registration (Meta)-Protocol that defines the
context, procedures and behaviour of the Registration service in a protocol independent way. Appropriate parts of the
Meta-protocol can be mapped to standard protocols such as SIP, or RAS (H.323). The SSP Registration procedure
supports both the “User at home” and “Roaming user” scenarios. Support for both of these scenarios is discussed in
the following sections.

The single sign-on system requires expertise from several areas. Therefore the SSoS draws together the meta-
protocols from several sources:

    Registration and service attachment (TIPHON WI 3016-2)

ETSI/TIPHON(03)#34                                                               Temporary Document 046
                                                                                                                page 4 of 9
   Authentication & Confidentiality (TIPHON WIs 8005-2, 8007)

   Terminal Service Capability/Service application Management

   User Profile management

Note: One can argue that the latter two are services in its own right. We should have this argument!

7 Using the SSoS

7.1 User at home scenario
The „User at home scenario‟ registration process involves the following steps:

   Registrar discovery

   Registration with Registrar

   Attachment to the Application Server.

7.1.1 Registrar Discovery.
Before any kind of registration takes place, a Registrant needs to know the Registrar to register with and its signalling
handle (RpoA, Registration point of Attachment) There are two ways to inform a terminal/user of the registrar
identity (and signalling handle): Auto Discovery and Static Provisioning.

The Auto discovery mechanism takes place when a terminal is powered up/initiated, and a DHCP-type [8]
mechanism is used to find the address and identity of the registrar. The other way to inform a Registrant of its
Registrar signalling handle by static configuration upon terminal provisioning. The Registrar ID could be configured
as the IP address or the URL, e.g. Registration_Server@operator.com. This latter procedure fails when the user has
no contact with the home service provider because of firewalls.

7.1.2 Registration with Registrar
Once the identity of the registrar is known, the next step is to register with it using a registration protocol. The
following procedure takes place at Registration Server (see also figure 2):

User Authentication and Authorisation: The Registrar checks for the authentication information either provided using
cryptographic means in the Registration Request message or provided implicitly through for instance the originator
IP address of the message. If the authentication information is not available, the registration request is declined. Once
authenticated, the Registrar checks if the user is allowed access to the requested service.

Application Server Location: The Registrar searches for the possible Application Servers (telephony, video
conferencing, Instant Messaging etc) that can provide the services requested by the registrant. The Application Server
may be selected on several criteria, proximity to the user's terminal, cost, load balancing and available resources. The
Application Servers need to have resources available to execute the service (CPU, network and memory bandwidth
but some services may require specialised hardware like DSPs), at this point we do not differentiate which resources
may be needed.

Service Attach Notification: Once an Application Server is found, the Registrar communicates with the relevant
Application Server(s), to inform them of the client registration. The Application Server then either accepts or rejects
to provide the requested service (possibly based on available resources, overload conditions). If an Application
Server declines to provide the requested service, another Application Server is contacted.

ETSI/TIPHON(03)#34                                                                  Temporary Document 046
                                                                                                                 page 5 of 9

                        Registrant                     Registrar             Application
  Registrant attempts                                                        Server
  to Register with the          Registration Request                                      The Registrar
  Registrar                                                  Client Attach Notify         Informs the
  Authentication/Autho                                                                    relevant AS of the
                                                             Client Notify Response       registration, and
  risation takes p lace
                                Registration Confirm                                      requests the AS to
                                                                                          provide the
                                                             Service Attach Request
  The Registrar                                                                           required service
  provides the                                               Service Attach Response
  Address(es) o f the
                                                                                           The AS Agrees to
  AS, alo ng with
                                                                                           provide the
  Auth Tokens
                                De-Registration Request                                    requested Service.
                                                             Client Detach Notify          AS provides the
   The User req uests                                                                      Auth Token for
   the Registrar to                                          Client Detach Response        the session
   Deregister it from
   all the Services
                                                             Service Detach request

                                                            Service Detach Response        The Registrant
  Alternatively, the
                                                                                           Attaches with the
  user can De-
                                                                                           AS, pro vid ing the
  Register itself               De-Registration Response                                   Auth tokens
  from a sp ecific
  Service Provide

                 Figure 2: Message flows for home scenario of Single Sign-On protocol
Authentication Ticket for Services: A Ticket (security token) is sent to the Registrar by the Application Server if it
accepts providing the requested service. This Ticket is valid for a time determined by the service provider policy.

Response to terminal The Registrar collects the Tickets from all the Application Service Nodes it contacted and
acknowledges the registration request by the user, and presents the users with the Tickets.

7.1.3 Attachment with Application Server.
Once the registration with Registrar has been completed successfully, the User attaches with the Application
Server(s) (Service point of Attachment, SpoA) provided in the Ticket(s). Attachment with an Application Server is
achieved by sending a „Service Attach Request‟ message to the Application Server (see figure 2). This message
contains the Ticket provided by the Application Server to the Registrar. This Ticket confirms that the user is pre-
authorised to utilise service(s).

After successful authentication of the registrant, the Application Server responds to the user with a Service Attach
Response, informing the user that it can start using the requested service. If the Registrar was registering for a
telephony service the user can make and receive calls.

7.1.4 Use of the service
After the user has attached her terminal to the Application Server (like a Softswitch) there will be a signalling link
over which the requested service (e.g. voice calls) can be delivered (set-up). Because of the explicit attachment the
Application Server can handle incoming calls and deliver them to the user at the terminal. Accounting information for
the use of the service can be delivered to the registrar who may decide to bill the user for it.

7.1.5 De-Registration.
The registration is valid only for a specific time period, after which it expires. If the Registrant wishes to continue
using services, it needs to Re-Register before the Registration expires. If no Re-registration is carried out, it is

ETSI/TIPHON(03)#34                                                                  Temporary Document 046
                                                                                                                     page 6 of 9
assumed that the user does not want to continue to be registered, and is implicitly de-registered at the registration
expiry timer.

If the user wants to explicitly De-Register from all the services/servers, it sends a De-Register Request to the
Registrar. The Registrar then notifies all the Application Servers of the Client Detachment. If the client only wishes
to De-Register from a specific Application Server. It then issues a „Service Detach Request‟ to the relevant
Application Server.

7.2 Roaming User Scenario
We extend the above scenario to support a roaming user. In the roaming user scenario, the user discovers and finds
the visited domain‟s registrar as if it is the home registrar. The visited registrar contacts the home registrar and
establishes service entitlement.

Unlike in the GSM system,
                                                       1- User                Visited     1- User              Home
where services are delivered                                                              Registration
                                        Registrant     Registration          Registrar                        Registrar
from the visited network, we
assume that the services                                              2- Service                2- Service
rendered are unique and can                                           preperation               preperation
not necessarily be offered by     3- Service
a party different from the        attachment                          Service Node/             Service Node/
Home network. Therefore,                                               Application               Application
                                                                         Server                    Server
for some services, the visited
network may only provide a
proxy for the service                                                     Service Node/              Service Node/
signalling and relays all the                                              Application                Application
signalling to the home                                                    Server Proxy                  Server
                                                                             Server                       IMP

The relationships between                                 Figure 3: Roaming Registration
registrant, home and visited
registrars and their
Application Servers are shown in Figure 3. This figure shows the scenario where the terminal of the roaming users
can not contact the home registrar directly nor the home servers. If these can be contacted directly, Figure 1 applies.

The Roaming user Registration call flows are a direct extension from the home scenario and are not repeated here.
The visited Registrar issues the same primitives to the home registrar that the user used to connect with the visited
registrar. Once the address of the Serving Registrar in the visiting domain is known, the roaming subscriber sends a
Register Request primitive to it. The serving Registrar identifies the Registrant as not belonging to its domain; but to
a domain it has a SLA with. If the serving Registrar does not have a Valid SLA with the Registrant‟s home service
provider, the Registration request is declined.

If the registrant‟s home service provider has a valid SLA with the serving Registrar, then it contacts the Home
registrar by sending a Registration Request message. The home Registrar receives the Registration request,
Authenticates the Registrant, and checks if the Registrant has subscribed for roaming service. If it has, the Registrar
then checks if the Registrant is allowed the requested services. If it is, the Registrar then checks which of the
requested services need to be provided by the Serving domain (provided the serving domain can provide those
services); and which services are to be provided by home domain.

Next the Registrar identifies the relevant Application Servers in both the home and visiting networks. Once the target
Application Servers (AS) are identified, the home Registrar informs the Application Servers of the Client attachment,
via „Client Attach Notify‟ message. Upon successful notification, the AS will return the Tickets to the home
Registrar. The Registrar will then send these to the Registrant in Registration Response message, via serving
Registrar. Upon reception of these tickets, the terminal attaches to the Application Servers it has received tickets for
in the normal way.

ETSI/TIPHON(03)#34                                                             Temporary Document 046
                                                                                                             page 7 of 9

7.3 Example
Consider a scenario where the Roaming Registrant requests two services: telephony and Instant Messaging &
Presence (IMP). The Home Registrar decides that the IMP service has to be provided at home, and will prepare the
IMP server. The IMP server, it will return a Ticket (containing a SpoA) to the serving Registrar. The home Registrar
also checks if the telephony service can be provided by the serving domain, and if yes, what its SpoA will be. The
home Registrar then registers the Registrant with the Tickets of the telephony and the IMP services.

8 Security Considerations
Asymmetric cryptography shall be used to establish identity of both Registrar and Registrant. On service sign-up the
Registrar establishes a private key and receives public key of Home Registrant as well as the public keys of all
partners of Home to be used when the user is roaming in their area of coverage.

During registration, User authentication is achieved through end to end encrypted signalling between user and home.
The visited Registrar relays this signalling and eventually receives from Home the authorisation to let the Registrant
register under the contract with home.

Tickets are cryptogaphically signed tokens of entitlement. Tickets need to be refreshed regularly to prevent reply
attacks so they have a maximum lifetime (servers may reject Tickets before then). The ticket further holds the SpoA,
issuing Service provider and indented user name.

Symmetric cryptography may be used to secure Service Attachment and service signalling. Keys may be based on
information in Tickets.

Visited Registrar may add Tickets so the visiting user can use local proxies that will act just like the home server.
Visited may receive separate Tickets received from Home Registrant to use when proxying for roaming users.

8.1 Cost of Security
The current specifications from TIPHON WG8 expect that the service value costs is small and hence the security
overhead should be minimal. This may be true for telephone calls but this will not extend to e-commerce transactions
or other sessions where the user-value is not in the communications session itself but rather in knowing for certain
that they are communicating with the right person. TIPHON WG8 will update its specs to this effect.

To the SSoS this means that several security token and authentication mechanisms shall be supported so the costs of
the security can be adjusted to meet the demands of the service used.

9 Existing implementations
We discuss several existing approaches to support registration, GSM, H.323, SIP, PASSPORT, IEEE802.1x and

9.1 GSM
In the GSM system, users register explicitly before they can use the service, except for emergency calls. In order to
register with the network, the available frequency bands are scanned for the (home) service provider or known
serving networks. The network that is found locally is asked to perform the registration. After some security
exchanges, the user is considered authenticated and may be authorised from the home network or by the local
network. When this authorisation is provided the user is considered registered for all GSM services making calls,
receiving calls and the short messaging service.

ETSI/TIPHON(03)#34                                                             Temporary Document 046
                                                                                                            page 8 of 9

9.2 H.323
The H.323 suite of protocols for multi-media conferencing over non-QoS networks [1] provides a registration
mechanism over the RAS protocol [2]. The RAS protocol allows a user to “register” for H.323-based services and in
doing so specify a user identity to be used, terminal capabilities, estimated bandwidth to be used by the user and
signalling handle. The network element (Gatekeeper) provides a signalling handle. From this description it should be
clear that the RAS protocol provides a Service Attachment as described above.

9.3 SIP
The SIP [3] architecture is comparable to that of H.323. The SIP registration procedure registers the user for SIP-
delivered services. The terminal is called user agent (UA) and the gatekeeper is called proxy server. The SIP
Registration capability allows the User Agent to receive calls, registration is mainly used to update a location service
that can be queried for the completion of a call. For outgoing calls, SIP does allow the UA to be tied to an outbound
proxy server, which may provide registration, authentication and authorisation services. The SIP registration however
does not necessarily include validation of service entitlement (is the user allowed service from this server), this may
be done on a per-session (call) basis.

9.4 Microsoft PASSPORT
The PASSPORT [4] protocol/service that is currently advocated by Microsoft has the clear goal to provide a single-
sign-on mechanism allowing direct access to a multitude of Internet-based services with just one login. The
mechanism employed uses http redirects from the site the user is visiting to the passport server. At this server the user
can obtain security credentials which can then be passed to the site the user is trying to visit. The PASSPORT
technology has two problems that prevent it from wide deployment. (1) The PASSPORT technology is insecure [4]
since it uses existing technologies beyond its limits. (2) Microsoft is the only company (allowed) to run PASSPORT
servers. This means that all users have to trust one company to keep their data private (including credit card

9.5 IEEE 802.1x
IEEE has created the 802.1X standard for the purpose of user authentication prior to providing access. The figure
below describes the workings.

1.   The user at the terminal (supplicant) asks the authenticator system to be allowed access to the network.

2.   The user discloses with which operator (Authentication Server System) they want to be authenticated with (e.g.

3.   The authenticator system contacts the Authentication Server System possibly through an aggregator and
     establishes a tunnel to get the user authenticated.

4.   Subsequent authentication credentials (username/password or something mode fancy) are send through a
     possibly encrypted tunnel using EAP (extensible authentication protocol). This communication is opaque to the
     authenticator and aggregator. Only the home operator as final authenticator can understand the authentication
     credentials and can then validate them.

Note that usually the protocol that is used between the authenticator, the aggregator and the home operator is

ETSI/TIPHON(03)#34                                                               Temporary Document 046
                                                                                                            page 9 of 9

                                    authenticator                                                Authentication
       supplicant                                                      Aggregator                Server system

          Access Request                                 Authorization Request      Authorization Request


                                                          Authorization Confirm     Authorization Confirm
                         Access Confirm

                                             Figure 4. IEEE 802.1x operation

9.6 PANA
The Protocol for Carrying Authentication for Network Access (PANA), a link-layer agnostic transport for Extensible
Authentication Protocol (EAP) to enable network access authentication between clients and access networks. PANA
can carry any authentication method that can be specified as an EAP method, and can be used on any link that can
carry IP. PANA covers the client-to-network access authentication part of an overall secure network access
framework, which additionally includes other protocols and mechanisms for service provisioning, access control as a
result of initial authentication, and accounting.

From a state machine aspect, PANA protocol consists of three phases:

 1.   Discovery and initial handshake phase

 2.   Authentication phase

 3.   Termination phase

Its use it very similar to IEEE 802.1x.

10 Discussion
Assessing the technologies presented we find that the GSM, H.323 and SIP approaches have been technology
specific, and not generic. We seek a means to enable the user to sing-on for a whole range of services independent of
their technologies. Note, however, that the H.323 and SIP technologies could be used to Attach to one particular
service and cannot be used to identify multiple service types. For Example, SIP does not allow a user to define the
services requested on a per registration session basis. The PASSPORT technology fails the requirement on
competition. It seems that there is no generic mechanism to support sign-on to provide multiple services, which
allows users to choose the service provider they trust with their private information.

The IEEE 802.1x and PANA approaches go a long way to meeting the application space we are after with the SSoS.
Unfortunately both approach focus primarily on access control to the Internet providing one “switch” at layer-3 to
allow/disallow a particular terminal complete access to the network operated by one operator. In our model we
address multiple services provided by multiple service providers over one local transport networks. Hence this model
would need adapting to our competitive environment.

Editors note: as far as I am concerned the hunt for the protocol is still on….


To top