Martin Euchner Nokia Siemens Networks GmbH & Co KG COO RTP IE Fixed Martin.Euchner@nsn

1. Filling the Gaps of IdM in Third andin Next Generation NetworksStandardized Network-centric IdM as an enablerfor secure applicationsBurton 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 Martin.Euchner@nsn.com

2. 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.

3. Next Generation Network (NGN) uses various IDs Identifiers in common components for applications User Id Data Identifiers in common components for applications and service support Identifiers in NACF Identifiers IMS, PES, IPTV Identifier Interoperability Identifiers in RACF User and terminal identifiers Access network identifiers

4. 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.

5. 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)

6. 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.

7. Access An NGN IdM Vision 3rd Party Providers, IdPs and RPs Internet and Web Services IdM within NGNcould be any IdM solution (e.g. GBA) External NGN IdM interface(s)tbd Other IdM solutions ANI and NNI NGN (IdP) IdM (“blackbox”) within NGN provider IdM Application Servers Service Stratum Other NGN (IdP) IdMBridge Softswitch CSCF UNI NNI IdM Plane Other Networks (e.g., PSTN) NNI Transport Stratum User Device

8. 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.

9. 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.

10. Benefit and Relevance • GAA supports convergence of cellular and non-cellular networks and services for network-centric IdM • Value 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.

11. GAA – Generic Authentication Architecture(TR 33.919) • 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.. Illustration of mechanisms to issue authentication credentials Note: Other mechanisms for issuing authentication credentials may exist but are out of scope for this TR. GBA: Generic Bootstrapping Architecture SSC: Support for Subscriber Certificates Schematic illustration of GAA

12. Generic Authentication Architecture • 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).

13. GBA – Generic Bootstrapping ArchitectureApplication (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].

14. 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).

15. GBA Entities and Interfacesbootstrapping from cellular authentication and key agreement (AKA) User (profile) DB, IdP • Before bootstrapping:HSS and smart card in UE share a key for cellular authentication • Bootstrapping steps: • UE contacts NAF to obtain a service (Ua) • NAF requests authentication from UE (Ua) • NAF client triggers BSF client to bootstrap with AKA (Ub, Zh) • Resulting master session key and transaction id are stored in BSF server and client • NAF client sends transaction id to NAF server (Ua) • NAF server gets NAF-specific session key from BSF using transaction id (Zn) • 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 GAA GBA HSS Application Server Supports Service Discovery (optional) Zh: Credential Fetching Protocol NAF library Network Application Function (NAF) Bootstrapping Server Function (BSF) Server SLF (opt) Zn: Key distribution Protocol(DIAMETER, SOAP) Dz: Service Discovery Ub: Bootstrapping Protocol (HTTP Digest AKA) BSF client User Equipment (UE) Client Ua: Application Protocol(HTTP digest over TLS, PSK TLS)

16. 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.

17. Usage of GBA (1) • GBA is a generic enabler in 3G • 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)

18. Usage of GBA (2) • GBA is a generic enablerhas been taken up into usage by many applications and standardization forums: • 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

19. 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)

20. 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.

21. 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 Related specifications: 3GPP TR 33.980 GAA infrastructure HSS UE BSF client NAF library HTTP Digest Browser IdP Identity Server HTTP Liberty ID-FF HTTP Liberty ID-FF Service Provider

22. 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) Related specifications: 3GPP TR 33.980 GAA infrastructure HSS UE BSF client NAF library LibertyEnabled User Agent/Device (LUAD) Liberty Authentication Protocol Authentication Service Discovery Service Liberty ID-WSF Identity-based Service Discovery Service Provider Liberty ID-WSF Identity-based SOAP request and response

23. LAP: SOAP-based LAP: SOAP-based SP AS SSOS LAP: UE -SSOS LAP: UE –AS LAP: UE - SP Authentication (carried within SASL) UE WSP Auth. Service SP LAP UE – SP Using SOAP LAP WSP-UE SOAP-based UE LUAD Analyzed Architecture Components LAP SP-IdP SOAP-based SP IdP LAP UE-SP Using HTTP HTTP-based UE 3GPPGBA LAP ID-FF LAP ID-WSF LAP ID-WSF Authentication Service LAP ID-WSF Authentication Service with Single Sign On Service

24. HSS Zh Zn LAP SP-NAF/IdP NAF/IdP SP BSF NAF Ua LAP UE-IdP Ub LAP UE-SP UE GBA and Liberty Alliance (LAP) InterworkingIdP collocated with NAF • Collocation of NAF and IdP • allows • 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. • 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).

25. Mail Calendar Zn Application IdP IdP NAF/SAML Zh Zn HSS BSF Application LAP SP-NAF/IdP Ub Application Ua Application NAF/IdP LAP UE-IdP LAP UE-SP GBA-LAPSAML Inter-working

26. Example procedure for GBA-LAP interworkingwith IdP collocated with NAF Service Provider UE BSF NAF/IdP Established TLS secure channel 1. Service access request/HTTP request 2. HTTP re-direct to IdP 3. Service access request/HTTP request Derive fresh session key Derive fresh session key 4. HTTP digest authentication GBA bootstrapping (opt.)if UE and NAF do not yet share fresh credentials UE authenticated and authorized 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) 7. Service access request/LAP HTTP request 8. Service access response

27. 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

28. 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

29. 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.

30. 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.

31. Thank You! • Acknowledgements to Silke Holtmanns, the Nokia Research Team and NSN RTP Research

32. 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.

33. Unified authentication solution for multiple authentication methods Service authorization UAN Multiple Accesses Multipleservices IntelligentPacket Core a multi-access capable authentication server for common broadband access technologies (xDSL, WiMAX, i-WLAN, …..) Offers simple “one-click” service authentication based on SIM/USIM through 3GPP GAA architecture Unified Attachment Node Enables transparent authentication to services in multi-access environment

34. BSFclient NAFclient UAN - BSF Authentication & Billing Value Center (A&BVC)High Level Concept Architecture Charging System Registers Operator Services CG UCS HSS HLR NAF NAF Service Service Internet Clients NAFclient NAF NAF Service Service

35. HLR HSS IMS BSFclient NAFclient IMS & Registers UAN UAN deployment example WAP MMSC IN CG Stream Charging Operator VAS 3GPP PS Flexi ISN SP NAFserver WiMAX WLAN Internet ASN-GW AC BM-SC BAM xDSL BRAS Mobile TV • 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

36. Public User Identity Service Profile IMS Private Public Subscription User Identity User Identity Public Service User Identity Profile (3GPP/IMS) Identities and Identifiers • 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 Relationship of the Private User Identity and Public User Identities Public User Identity – 1 Service Profile – 1 Private User Identity – 1 IMS Public User Identity – 2 Subscription Service Profile – 2 Private User Identity – 2 Public User Identity – 3 The relation of a shared Public User Identity (Public-ID-2) and Private User Identities

37. 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.

38. GAA – SSC Reference Model for Certificates 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. HSS Zh Dz PKI-aware AS PKI BSF Zn Portal SLF (NAF) Ua UE Ub Simple network model for certificate issuing and usingTS 33.221 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)

39. 3GPP “IdM”-related specifications • GAA: 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)

40. Additional Information • Liberty Alliance ID-WSF 2.0 Specifications • https://www.projectliberty.org/resource_center/specifications/liberty_alliance_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/

41. Abbreviations • NACF: Network Attachment Control Function • NAF: Network Application Function • NE: Network Entity • NGN: Next Generation Network • NNI: Network-Network Interface • OMA: Open Mobile Alliance • PKI: Public Key Infrastructure • RA: Registration Authority • SA: Services & System Aspects • SAML: Security Assertion Markup Language • SASL: Simple Authentication and Security Layer • SCTP: Stream Control Transmission Protocol • SIM: Subscriber Identity Module • SLF: Subscriber Locator Function • SOAP: Simple Object Access Protocol • SP: Service Provider • SSC: Support for Subscriber Certificates • SSO: Single Sign-On • SSOS: Single Sign-On Service • TLS: Transport Layer Security • UAN: Unified Attachment Node • UE: User Equipment • UICC: Universal Integrated Circuit Card • UMTS: Universal Mobile Telecommunications System • UNI: User Network Interface • USIM: Universal Subscriber Identity Module • USS: User Security Setting • WAP: Wireless Application Protocol • WSC: Web Service Consumer • WSP: Web Service Provider • 3GPP: 3rd Generation Partnership Project • A&BVC: Authentication & Billing Value Center • AKA: Authenticated Key Exchange • ANI: Application Network Interface • AP: Authentication Proxy • AS: Authentication Service • BSF: Bootstrapping Server Function • CA: Certificate Authority • CoT: Circle-of-Trust • CPS: Common Profile Storage • CPSF: Common Profile Storage Framework • CT: Core Network and Terminals • DS: Discovery Service • FG-IdM: ITU-T Focus Group Identity Management • GAA: Generic Authentication Architecture • GBA: Generic Bootstrapping Architecture • HSS: Home Subscriber Server • HTTP: Hypertext Transfer Protocol • HTTPS: Hypertext Transfer Protocol Security • ID-FF: Identity Federation Framework • IdM: ID Management • IdP: Identity Provider • ID-WSF: Identity Web Services Framework • IP: Internet Protocol • ISIM: IP Multimedia Subsystem (IMS) SIM • LAP: Liberty Alliance Project • LUAD: Liberty-enabled User Agent or Device • MNO: Mobile/Multiservice Network Operator