Non-confidential 1© Nokia Siemens Networks Burton Group Catalyst 2007/OASIS IDtrust Workshop, Barcelona/Spain, 22-25 October 2007 / Euchner Filling the

non-confidential1 © Nokia Siemens Networks Burton Group Catalyst 2007/OASIS IDtrust Workshop, Barcelona/Spain, 22-25 October 2007 / Euchner

Filling the Gaps of IdM in Third andin Next Generation Networks

Standardized Network-centric IdM as an enablerfor secure applications

Burton Group Catalyst 2007 Conference /OASIS Identity and Trusted Infrastructure

Workshop: Evolutionary MilestonesBarcelona/Spain, 22-25 October 2007

Martin Euchner

Nokia Siemens Networks GmbH & Co KG

COO RTP IE Fixed

[email protected]

2 © Nokia Siemens Networks Burton Group Catalyst 2007/OASIS IDtrust Workshop, Barcelona/Spain, 22-25 October 2007 / Euchnernon-confidential

Presentation Overview

• Next Generation Networks (NGN) and IdM

• An example network/provider centric IdM approach–Generic Authentication Architecture (GAA)

–Generic Bootstrapping Architecture (GBA)

–Usage of GBA in 3rd and in NGNs

– IdM Interworking between 3GPP GBA and Liberty Alliance

• This presentation is based on a contribution submitted to ITU-T Focus Group on IdM for network-centric IdM and on other related material.


Next Generation Network (NGN) uses various IDs

LegacyTerminals

Note: Gateway (GW) may exist in either Transport Stratum or End-User Functions.

*

LegacyTerminals

Transport Stratum

Service Stratum

End-UserFunctions

Application Functions

Core transport Functions

NGNTerminals

CustomerNetworks

Other N

etworks

Application Support Functions and Service Support Functions

Core TransportFunctions

Other N

etworks

EdgeFunctions

Access Transport Functions

Access Transport Functions

ServiceControl

Functions

Network Access

Attachment Functions

Network Attachment Control Functions

(NACF)

Access NetworkFunctions

Resource and AdmissionControl Functions

(RACF)

UserProfile

Functions

T. UserProfileFunctions

UserProfile

Functions

T. UserProfileFunctions

GWGWGWGW

Other NGN ServiceComponents

PSTN / ISDN EmulationService Component

IP Multimedia Component&PSTN/ISDN Simulation

IP MultimediaService Component

S. UserProfile

Functions

GWGWGWGW

Applications

User Id Data

Identifiers in common components for applications

Identifiers IMS, PES, IPTV

Identifiers in RACF

Identifiers in NACF

User and terminal identifiers

Identifiers in common components for applications and service support

Identifier Interoperability

Access network identifiers


NGN and the Need for IdM

• NGN has various identifiers defined throughout the NGN architecture.

– NGN identifiers are standalone, isolated within component/stratum

– Difficult correlation of NGN identifiers across strata/layers

• Strong identities are prerequisite for secure and trustworthye-business in third and next generation networks.

• NGNs need to leverage such identities for the purpose of– secure identification and authentication (user/device),

– assisting towards establishing secure communications,

– and for protection of the network infrastructure.


Gap Analysis

• ITU-T Focus Group IdM has compiled an extensive list of foreseen use cases and IdM scenarios

• Identified numerous gaps such as:– Integration of IdM in NGN Architecture

– Discovery of Identity Resources

– Inter-Federation/Inter-CoT Interoperability

– Interoperability of Mechanisms Used to Exchange Identity Information

– …

• Some general ideas considered how to overcome gaps(requires further studies and refinement)


An NGN IdM Approach

• NGN should focus on network centric IdM;i.e. IdM within NGN

– Define external IdM interfaces for interworking of NGN with user-centric, application-centric 3rd party IdP IdM.

– Network-centric IdM is an approach where NGN providers host IdM(or use identity services from third party identity providers) for enabling access to the NGN.

– Application-centric IdM enables applications and serviceswhen linked to network-based IdM, yields consistent provider-centric IdM.

• A new envisioned NGN IdM plane across all NGN strata could allow ID correlation

• A new envisioned NGN IdM bridging function could– act as an ID gateway– allow mapping of IDs/security policies into different domains,– interwork with other networks, and provide discovery,– link NGN IDs across strata and across layers.


An NGN IdM Vision

3rd Party Providers, IdPs

and RPs

Device

Transport Stratum

Application Servers

Softswitch CSCF

Service Stratum

User

Access

Internet and Web Services

Other

NGN (IdP)

Other IdM solutions

Other Networks

(e.g., PSTN)

UNI

NNI

NNI

ANI and NNI

NGN (IdP)

External NGN IdM interface(s)

tbd

IdMBridge

IdM within NGN

could be any IdM solution (e.g. GBA)

IdMIdM

(“blackbox”) within NGN

provider

IdM Plane


What is Generic Authentication Architecture (GAA)?

• GAA is the generic authentication architecture– based on cellular authentication (xSIM)– designed to be used for authentication of all services.

• Every new service needs authentication.

• A generic authentication mechanism would ease introduction of new services.

• But a generic mechanism cannot be proprietaryit must be standardized.

• The GAA specification work was started in 3GPP at the end of 2001, and is now finalized for Release 6 of 3GPP.

• Work on GAA extensions is ongoing in 3GPP for Release 7.GAA is also proposed for use in 3GPP2, OMA, TISPAN.


What problems does GAA solve?

New operator services are starting to appear• WLAN access, Presence and Messaging, multicast/broadcast services (MBMS)• All of them need authentication and key agreement.

Other services need authentication, too• Typically each service sets up and manages its own username/password

database.

The critical step in security is securely provisioning initial credentials• Setting up username/password databases, distributing smart cards, … • Costs money and time, inconvenient to users.

The GAA Solution:• Re-use the cellular authentication infrastructure

– Already provisioned User credentials (smart cards)– Existing roaming agreements between operators.

• Design it as a generic framework to bootstrap authenticationso that new services can use it easily in a standardized manner.


Benefit and Relevance

GAA supports convergence of cellular and non-cellular networks and services for network-centric IdMValue to different stakeholders:

• Using GAA cellular network operators can offer authentication as a service. This is a new way to utilize their subscribers’ base and roaming agreements.

• GAA benefits subscribers because it provides more secure and user-friendly authentication than e.g. passwords.

• GAA benefits service providers (running application servers). – No need to provision credentials to users– Stronger authentication than using passwords– Big pool of potential customers

• GAA-Identity Management provides strong, two-factor authentication– Bound not only to something that the user knows, but also to something he possesses.– Smart card can support the user identity management.


GAA – Generic Authentication Architecture(TR 33.919)

NE

GBA

AP

Certificates

HSS

UE

GAA

Illustration of mechanisms to issue authentication credentialsNote: Other mechanisms for issuing authentication credentials may exist but are out of scope

for this TR.GBA: Generic Bootstrapping ArchitectureSSC: Support for Subscriber Certificates

GAA

Certificates

SSC TS 33.221

TR 33.919

GBA

Shared secret

TS 33.220

Schematic illustration of GAA

• GAA describes a generic architecture for peer authentication that can a priori serve for any (present and future) application.

• GAA is an authentication frameworkwith authentication reference model, linking together GBA, security mechanisms (shared secret based and certificated-based)and functional entities..


Generic Authentication Architecture

NE

GBA

HTTPS access

Certificates

HSS

UE

GAA

• In GAA the mobile and the service provider are provisioned with fresh credentials – can authenticate each other.

– This requires cellular authentication of the mobile terminal and is done over IP.A mobile that has those credentials can be automatically provisioned with subscriber certificate and becomes part of cellular network’s PKI

• Generic Bootstrapping Architecture (GBA) offers genericauthentication capability for various applications based onshared secret.Subscriber authentication in GBA is based onHTTP Digest AKA [RFC 3310].

• Support of subscriber certificates andAccess to Network Application Function usingHTTPS is based on GBA.

• GBA, Subscriber certificates, andAccess to Network Application Functionusing HTTPS form togetherGeneric Authentication Architecture (GAA).


GBA – Generic Bootstrapping Architecture Application (TS 33.220)

• GBA is a security mechanism that is applicable to any application in need of authentication and/or access control.

• GBA describes the security features and a mechanism to bootstrap authentication and key agreement for application security from the 3GPP AKA mechanism.

• GBA defines the– generic AKA bootstrapping function,– an architecture overview – and the detailed procedure how to bootstrap the credential.

• Important applications as seen from the viewpoint of 3GPP may use GBA as basis for its deployment.In particular self-administration of 3GPP services is a candidate:

– For Presence, user self-administration via Ut is defined in TS 33.141 using andprofiling Ua from TS 33.222

– For Conferencing, Messaging, …, further TSs for self-administration may be defined.– For Multimedia Broadcast/Multicast Service (MBMS) where GBA is used for security of the

broadcast encryption keys [TS 133.246].


GBA – Generic Bootstrapping ArchitectureMain advantages

• Works over any access network, which provides IP connectivity • Dynamic generation of shared secrets/passwords (e.g. for http digest) • USIM- (and SIM-)based single sign-on to applications

• Binding of application provision to MNO

• MNO is root of trust

• Avoids long-term subscriber certificates and the corresponding large-scale public-key infrastructure

• Provides (optionally) application- and NAF-group-specific persistent user identities to the NAFs

• Provides (optionally) application- and NAF-group-specific user authorization flags to the NAFs

• Security on user side may be smart-card (UICC)-based (so-called GBA_U).


GBA Entities and Interfacesbootstrapping from cellular authentication and key agreement (AKA)

Before bootstrapping:HSS and smart card in UE share a key for cellular authentication

Bootstrapping steps:1. UE contacts NAF to obtain a service (Ua)2. NAF requests authentication from UE (Ua)3. NAF client triggers BSF client to bootstrap

with AKA (Ub, Zh)4. Resulting master session key and

transaction id are stored in BSF server and client

5. NAF client sends transaction id to NAF server (Ua)

6. NAF server gets NAF-specific session key from BSF using transaction id (Zn)

7. NAF server and client share a key that they can use for authentication

After bootstrapping:NAF and UE share a UE/NAF-specific key for service authentication

UserEquipment(UE)

UserEquipment(UE)

Bootstrapping Server

Function (BSF)

Bootstrapping Server

Function (BSF) Server Server

HSSHSS

BSFclient

Ub: BootstrappingProtocol

(HTTP Digest AKA)

Ua: Application Protocol(HTTP digest over TLS, PSK TLS )

Zh: Credential FetchingProtocol

Zn: Key distributionProtocol

(DIAMETER, SOAP)

GBA GAA

Client

NAFlibrary Network

Application Function (NAF)

User (profile)DB, IdP

Application Server

SLF(opt)

Dz: Service Discovery

SupportsService

Discovery (optional)


GBA Security Features• Mutual user/device authentication (UE, BSF) using HTTP Digest AKA.

• Authorization check by BSF/HSS.

• Dynamic key derivation (master, session keys).

• Secure key distribution and key/credential management.

• Message protection (integrity, replay, confidentiality) using TLS/HTTPS.

• Privacy protection of IMPI/IMPU, optional user anonymity.

• Linking UID with key material (BSF, NAF)

• Service discovery (SLF optional).

• Proxy services to external NAFs.


Usage of GBA (1)

• 3GPP– User self-administration for IMS-based Presence with Presence List

Management– Mobile Broadcast Multicast Service (MBMS) to provision subscriber

certificates – GBA for HTTP TLS or Pre-shared Key TLS – Foreseen application to 3GPP Strategic Architecture Evolution

(SAE) / Long Term Evolution (LTE)– 3GPP - Liberty Alliance Interworking

• 3GPP2 – New services, GAA in legacy CDMA networks

• OMA– OMA Presence Specification,– OMA Broadcast, OMA Location-based services, – OMA Secure User Plane Location Service (SUPL)

GBA is a generic enabler in 3G


Usage of GBA (2)

• ETSI TISPAN Next Generation Networks (NGN)– GBA enables the usage of cellular authentication to be used for non-

cellular services.

• ITU-T Next Generation Networks (NGN)– Part as an authentication method of draft Rec. Y.NGN-Authentication

• DVB-H– GAA-enhanced service protection

• IETF – Shared key TLS based on GBA

GBA is a generic enabler has been taken up into usage by many applications and standardization forums:


Flavors of GBA• “Normal” GBA for mobile equipment (GBA_ME)

– shared secret leaves the UICC;– dynamic key derivation outside UICC

• GBA for UICC (GBA_U)– shared secret does not leave UICC;– dynamic key derivation within UICC

▪ Ks_int_NAF remains with UICC ▪ Ks_ext_NAF leaves UICC

• “Legacy GBA” for using SIM card or SIM on UICC (2G GBA)in case ISIM or USIM not present on UICC

• GBA for Cable (GBA_H):– does not require UICC

▪ uses HTTP Digest over TLS enhancement to GBA▪ uses TLS pre-shared key

• GAA for Subscriber Certificates (GAA–SSC)


GBA and Liberty Alliance (LAP) Interworking(TR 33.980)

• Provides guidelines on the interworkingof the Generic Authentication Architecture (GAA) and the Liberty Alliance architecture.

• The feasibility study investigates the details of possible interworking methods between

– the Liberty Alliance Identity Federation Framework (ID-FF),

– the Identity Web Services Framework (ID-WSF) and

– the Generic Bootstrapping Architecture (GBA).

• TR 33.980 assumes that the architectures of Liberty Alliance and of GBA are used in combination.


Use case: Web Single Sign-On

• User is authenticated by operator using HTTP Digest and GAA.

• Operator shares user identity or pseudonym with 3rd party (SP)

• Liberty ID-FF provides a mechanism for sharing identity between operator and SP

Identity Server

HTTP Digest

GAA infrastructure

UE

HSS

Service Provider

HTTP Liberty ID-FF

HTTP Liberty ID-FF

Related specifications:

3GPP TR 33.980

BSF client NAF

library

Browser IdP


Use case: Web Services

• Liberty Enabled Device/Web Service Client authenticates to Liberty authentication web service,obtains token(s) to establish identity and access Discovery Service

• Authentication service leverages GBA mechanism and Operator network• Client accesses Discovery Service to access appropriate Service Provider• Client interacts with Service Provider using web service (SOAP)

Discovery Service

Liberty Authentication Protocol

GAA infrastructure

UE

HSS

Service Provider

Liberty ID-WSF Identity-based Service Discovery

Liberty ID-WSF Identity-based SOAP request and response

Related specifications:

3GPP TR 33.980

BSF client NAF

library

LibertyEnabled

User Agent/Devic

e (LUAD)

Authentication Service


Analyzed Architecture Components

IdP SP

LAP SP-IdPSOAP-based

UE

HTTP-based

LAP UE-SPUsing HTTP

3GPP GBALAP ID-FF

UE

LAP UE-SP

LAP UE - IdP

NAF IdP

NAF

WSC / SP IdP / DS

LAP WSC-IdP/DS SOAP-based

WSP

LAP WSP-WSC SOAP-based

LAP ID-WSF

LAP ID-WSF Authentication Service

UELUAD

LAP WSP-UESOAP-based

LAP UE – SP

Using SOAP

WSPAuth. Service

SP

LAP ID-WSF Authentication Service with Single Sign On Service

UE

LAP:UE -SSOS

LAP:UE - SP

SSOS SP

LAP:SOAP-based

AS

LAP:SOAP-based

LAP:UE –AS

Authentication(carried within

SASL)

UE

HSS

BSF

Ua

Ub

Zh Zn

NAF (AP)


GBA and Liberty Alliance (LAP) InterworkingIdP collocated with NAF

Collocation of NAF and IdPallows• federation/de-federation of GBA

credentials with LAP principal identities

avoids:• large impact on the generic interface

to the terminal to transport Liberty related information.

• Modification/extension of the interface to the service provider to support the Liberty SSO use case.

UE

HSS

BSF

UaLAP UE-SP

Ub

Zh Zn

NAF/IdP SP

LAP SP-NAF/IdP

LAPUE-IdP

NAF

• Usage of all Identity Management features as specified by LAP

• Root of trust and persistent identity of user managed by Operator/provider

• Strong authentication of UE for LAP Identity Provider (UICC-, SIM-based) using GBA credentials

• Control of MNO over user rights at Identity Provider, general by SLA and user-specific by GBA User Security Setting (authorization in USS).

• Similar interworking architectures defined for GBA-enabled Web-services,and for GBA-enabled Simplified Single Sign On (SSO).


GBA-LAP SAML Inter-working

BSF

IdP

NAF/SAML

IdP

NAF/IdP

Mail

Calendar

Application

HSS

Zh

Application

Application

Application

Zn

Zn

Ua

LAP UE-IdP

LAP SP-NAF/IdP

LAP UE-SP

Ub


Example procedure for GBA-LAP interworkingwith IdP collocated with NAF

UE BSFNAF/IdPServiceProvider

1. Service access request/HTTP request

2. HTTP re-direct to IdP

3. Service access request/HTTP request

4. HTTP digest authentication

GBA bootstrapping (opt.)if UE and NAF do not yet share fresh credentials

5. Authorization data,

User name (B-TID), password (KS_NAF) GBA credentials fetch (opt)if not already in NAF

6. LAP HTTP response, (LAP data)

Established TLS secure channel

7. Service access request/LAP HTTP request

8. Service access response

UE authenticated

and authorized

Derive freshsession key Derive fresh

session key


Common Security Requirementsaddressed by ID-FF and ID-WSF

• Request Authentication

• Response Authentication

• Request/Response Correlation

• Replay Protection

• Integrity Protection

• Confidentiality Protection

• Privacy Protections

• Resource Access Authorization

• Proxy Authorization

• Mitigation of denial of service attack risks


ID-FF Security Features

• Web-based single sign on with simple federated identities

• Name Registration

• Exchange of opaque user handles (privacy protection)no exchange of cleartext identifiers)

• Notifying the user of the capability to federate;soliciting consent to facilitate introductions

• Single log-out (Federation Termination Notification)

• Identity Provider Introduction

• HTTP basic authentication w/w.o. SSL 3.0/TLS 1.0

• SOAP over HTTPS (SSL 3.0/TLS 1.0) for X.509-based server-side authentication and SOAP message integrity & confidentiality

• SAML for security assertions

• Name Identifier Mapping with NameIdentifier obfuscation

• Name Identifier Encryption with XML encryption of NameIdentifier

• XML signature


ID-WSF Security Features

• ID-WSF authentication protocol using SASL (RFC 2222) profile:SASL over TLS/SSL for integrity & confidentiality protection of SASL messages

• Discovery Service

• ID-WSF Single Sign On Servicebased on ID-FF SSO & federation profile

• Password Transformation optional service to convey password pre-processing obligations to client.


Summary

• Next Generation Networks have to solve an IdM problem• GAA and GBA provide the foundation for network-centric IdM in 3G,

extends to next generation networks and non-3G environments.• GBA has many applications and serves as a key security mechanism.• Leverage deployed strong authentication solution that does not require PKI rollout.

• Liberty Alliance ID-FF and ID-WSF provide Identity Management– Single Sign On (ID-FF) and privacy protecting identity web services protocols and

architecture, including authentication and interaction web services.

• IdM concepts in LAP and GBA can complement each other nicely:– Re-use of GBA provides actual security mechanisms where LAP leaves room for security

mechanisms– Provide authentication interworking between GBA and LAP– GBA-LAP federation of identifiers and simplified Single-Sign On supported.

• Feasibility of possible LAP-GBA interworking architectures studied in TR 33.980– Some suitable combined architecture concepts suggested– Leverage good synergies between GBA and LAP.


Thank You!

Acknowledgements to Silke Holtmanns, the Nokia Research Team and NSN RTP Research


Nokia Siemens NetworksUnified Attachment Node (UAN)

• Allows operators to use SIM authentication for different access technologies and services.

• Provides a unified access solution to cut through the complexity of different login procedures (access, service), providing authentication for several access technologies including WiMAX:one SIM card, one login fits all.

• Operators can use the SIM card for all these technologies, simplifying authentication challenges and leveraging their SIM assets.

• Moreover, UAN re-uses the authentication data from SIM, giving consumers secure, “one-click-access” to third-party services from, for example, the Internet. This is realized by the so called “Bootstrapping” Server Function.


Unified authentication solution for multiple authentication methods

Multiple Accesses

MultipleservicesIntelligent

Packet Core

UANService authorization

Offers simple “one-click” service authentication based on SIM/USIM through 3GPP GAA architecture

a multi-access capable authentication server for common broadband access technologies (xDSL, WiMAX, i-WLAN, …..)

Unified Attachment Node Enables transparent authentication to services in multi-access environment


Authentication & Billing Value Center (A&BVC)High Level Concept Architecture

Charging System

CG UCS

Registers

HSS HLR

UAN - BSF

Clients

NAFclient

BSFclient

NAFclien

t

Internet

Service Service

NAF NAF

Operator Services

Service Service

NAF NAF


UAN deployment example

Reduce number of AAA infrastructure

Flexible tool for service authentication

Solution for GAA services (i.e mobile TV)

NASS TISPAN integrated function

Online/Offline charging support

CGIN

Charging

UAN

Flexi ISN

3GPP PS

ASN-GWWiMAX

WLAN

BRASxDSL

Operator VAS

WAP MMSC Stream IMS

HLR

HSS

IMS & Registers

BM-SC

Mobile TV

BAM

Internet

AC

SPNAFserver

NAFclient

BSFclient


(3GPP/IMS) Identities and Identifiers

Relationship of the Private User Identity and Public User Identities

The relation of a shared Public User Identity (Public-ID-2) and Private User Identities

IMSSubscription

PrivateUser Identity

PublicUser Identity

PublicUser Identity

PublicUser Identity

ServiceProfile

ServiceProfile

Private UserIdentity – 1

IMS Subscription

Private UserIdentity – 2

ServiceProfile – 1

ServiceProfile – 2

Public UserIdentity – 1



• 3GPP TS 23.003 “Numbering, addressing and identification”Defines the identifiers for IP Multimedia Subsystem (IMS)

• 3GPP TS 23.228 “IP Multimedia Subsystem (IMS) Stage 2”Handling of Identities in IMS

• Private User Identity (IMPI)– Is a NAI (username@realm)

– IMPI can be derived from IMSI if there is no ISIM application

• Public User Identity (IMPU)– Is a SIP URI or a TEL URI


GAA - Support for Subscriber Certificates(TS 33.221)

• Specifies a global and secure authorization and charging infrastructure of mobile networks to support a local architecture for digital signatures.

• Defines signalling procedures for support of issuing certificates to subscribers and the standard format of certificates and digital signatures.

– procedures to issue temporary or long-term certificates to subscribers;– standard format of certificates and digital signatures, e.g. re-using OMA

wireless PKI specifications.

• Subscriber certificates provide a migration path towards global Public Key Infrastructure (PKI):

– start from local certificate islands to migrate towards global PKI.

• Usage:– subscriber certificates to authorize and account for service usage both in home

and in visited networks.


Certificate enrolment protocol(PKCS#10 with HTTP Digest Authentication or TLS PSK)

(certifying subscriber's public keys, delivery of the Operator CA certificate to the UE)

GAA – SSC Reference Model for Certificates

Simple network model for certificate issuing and usingTS 33.221

PKI-aware

AS

UE

PKI Portal (NAF)

BSF

Ub

Ua

Zn

HSS

Zh

SLF

Dz

Registration Authority (CA opt)

• PKI Portal– issues a certificate for UE and

delivers an operator CA certificate– is a Registration Authority (RA) that

authenticates the certification request based on cellular subscription.

– may also function as aCertificate Authority (CA).

• Subscriber certificate profile is based on OMA WAP Certificate and CRL Profile (reusing IETF RFC 3280, X.509 profiles)Qualified certificate profiles by IETF [RFC 3039] and ETSImay also be usedwhen supported.


3GPP “IdM”-related specificationsGAA:

TR 33.919: GAA general overview

TS 24.109: Ub and Ua interface; protocol details, includes PKI enrolment

TS 29.109: Zh and Zn interface; protocol details

TS 24.109: Ub and Ua interface; protocol details, includes PKI enrolment

TS 29.109: Zh and Zn interface; protocol details

GBA:TS 33.220: Generic Bootstrapping Architecture (GBA)

TS 33.221: PKI enrolment

TS 33.222: Use of HTTPS and authentication proxy

TS 31.102: GBA_U details for USIM

TS 31.103: GBA_U details for ISIM

TS 31.111: USIM Application Toolkit (GBA_U triggering)

TS 33.141: Presence security (uses GBA)

TS 33.246: MBMS security (uses GBA)

TR 33.980: GBA and Liberty Alliance (LAP) Interworking

IMS:TS 29.230: 3GPP DIAMETER specific codes and identifiers

TS 23.008: Organization of subscriber data

TS 23.003: Numbering, addressing and identification

TS 23.228: IP Multimedia Subsystem (IMS) Stage 2

TR 32.808: Common Profile Storage (CPS) and Common Profile Storage Framework (CPSF)


Additional Information

• Liberty Alliance ID-WSF 2.0 Specifications– https://www.projectliberty.org/resource_center/specifications/liberty_alli

ance_id_wsf_2_0_specifications

• Liberty ID-WSF Authentication, Single Sign-On, and Identity Mapping Services Specification

– https://www.projectliberty.org/liberty/content/download/871/6189/file/liberty-idwsf-authn-svc-v2.0.pdf

• 3GPP– http://www.3gpp.org/


Abbreviations3GPP: 3rd Generation Partnership ProjectA&BVC: Authentication & Billing Value Center AKA: Authenticated Key ExchangeANI: Application Network InterfaceAP: Authentication ProxyAS: Authentication Service BSF: Bootstrapping Server FunctionCA: Certificate AuthorityCoT: Circle-of-TrustCPS: Common Profile StorageCPSF: Common Profile Storage FrameworkCT: Core Network and TerminalsDS: Discovery ServiceFG-IdM: ITU-T Focus Group Identity ManagementGAA: Generic Authentication ArchitectureGBA: Generic Bootstrapping ArchitectureHSS: Home Subscriber ServerHTTP: Hypertext Transfer ProtocolHTTPS: Hypertext Transfer Protocol SecurityID-FF: Identity Federation FrameworkIdM: ID ManagementIdP: Identity ProviderID-WSF: Identity Web Services FrameworkIP: Internet ProtocolISIM: IP Multimedia Subsystem (IMS) SIMLAP: Liberty Alliance ProjectLUAD: Liberty-enabled User Agent or DeviceMNO: Mobile/Multiservice Network Operator

NACF: Network Attachment Control FunctionNAF: Network Application FunctionNE: Network EntityNGN: Next Generation NetworkNNI: Network-Network InterfaceOMA: Open Mobile AlliancePKI: Public Key InfrastructureRA: Registration AuthoritySA: Services & System AspectsSAML: Security Assertion Markup LanguageSASL: Simple Authentication and Security LayerSCTP: Stream Control Transmission ProtocolSIM: Subscriber Identity ModuleSLF: Subscriber Locator FunctionSOAP: Simple Object Access ProtocolSP: Service ProviderSSC: Support for Subscriber CertificatesSSO: Single Sign-OnSSOS: Single Sign-On ServiceTLS: Transport Layer SecurityUAN: Unified Attachment NodeUE: User EquipmentUICC: Universal Integrated Circuit CardUMTS: Universal Mobile Telecommunications SystemUNI: User Network InterfaceUSIM: Universal Subscriber Identity ModuleUSS: User Security SettingWAP: Wireless Application ProtocolWSC: Web Service ConsumerWSP: Web Service Provider

Documents

Non-confidential 1© Nokia Siemens Networks Burton Group Catalyst 2007/OASIS IDtrust Workshop, Barcelona/Spain, 22-25 October 2007 / Euchner Filling the