idnits 2.17.1 draft-wei-abfab-fcla-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4427 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-13) exists of draft-ietf-abfab-arch-01 == Outdated reference: A later version (-05) exists of draft-ietf-abfab-usecases-02 == Outdated reference: A later version (-14) exists of draft-ietf-abfab-aaa-saml-02 == Outdated reference: A later version (-01) exists of draft-jones-diameter-abfab-00 == Outdated reference: A later version (-09) exists of draft-ietf-abfab-gss-eap-05 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ABFAB Y. Wei, Ed. 3 Internet-Draft ZTE Corporation 4 Intended status: Informational March 12, 2012 5 Expires: September 13, 2012 7 Federated Cross-Layer Access 8 draft-wei-abfab-fcla-02 10 Abstract 12 Network stratum and application stratum form a federation to 13 faciliate user's access. Network operator acts as Identity Provider 14 (IdP), and application reuses underlying network's security 15 capabilities to simlify application's access. This document is to 16 introduce such federated cross-layer access use case and message 17 flows. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 13, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.1. Fast Re-authentication . . . . . . . . . . . . . . . . . . 5 58 4.2. Secure Data Sharing . . . . . . . . . . . . . . . . . . . 7 59 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 1. Introduction 69 Currently it is agreed that digital identity is a crucial element in 70 a service enviroment. Typically telecom operators provide access 71 customers with identity which is associated with some form of trusted 72 element on the network (e.g. SIM/UICC). Meanwhile the identity 73 required by Web or non-Web services for users on is usually 74 associated with username. 76 Ordinarly telecom operators have tens of millons of users and can 77 provide trusted identity and higher security. However the categories 78 of service provided by telecom operators are relatively few. On the 79 contrary most service providers on the Internet have limited amount 80 of users and can not assure the security of user identity, but they 81 can provide abundant kinds of service. Furthermore, user is 82 reluntant to register too many accounts because it is inconvenient to 83 remember dozens of passwords . These facts creates some driving 84 forces that telecom is interworking with Internet. The stakeholders 85 can benifit from these combination. For telecom operators, they can 86 provide identity service, trusted security service, mobile payment 87 service and sharing some user profiles according user's preferences. 88 Telecom operators is not just providing pipeine for communication, 89 but also become a part of service value chain. For service 90 providers, they can focus on core business and reuse capabilities 91 provided by telecom operators without worring about sources of users. 92 For end users, they can enjoy seamless service experiences and 93 improve security and privacy. 95 This document considers a use case which telecom operator acts as 96 Identity provider (IdP) and federates with non-Web applications, e.g. 97 Email, Messaging. This use case combines network stratum access and 98 application stratum access, which is named as federated cross-layer 99 access. The detailed message flows for this use case are given. 101 2. Related Work 103 GSMA Association IDM project address operators' requirements for 104 emerging mobile application (such as, Single Sign-on, mobile payments 105 and other UICC enabled applications). Several use cases are also 106 identified[GSMA_IDM]. Liberty Alliance Telecommunications SIG 107 investigates digital identity grown in both telecom and Internet, 108 develops several use cases and proposes correspoding solutions for 109 interworking these two different domains [TelecoSiG]. 111 GBA (Generic Bootsrapping Authentication) mechanism for boostrapping 112 authentication and key agreement for application is denfined in 113 [TS33.220]. The interworking between GBA and Identity Federation 114 Framework (ID-FE) is documented in [TR33.980]. Another interworking 115 case between GBA and OpenID is specified in [TR33.924]. 117 Currently some use cases [I-D.ietf-abfab-usecases], architecture 118 [I-D.ietf-abfab-arch] and mechanisms are developed in IETF abfab 119 working group. 121 3. Use Case 123 Editor's Note: The section is for readable and completeness for this 124 memo. The formal use case is referred to [I-D.ietf-abfab-usecases]. 126 Telecom operators have a communication network infrastructures to 127 provider users with a wealthy of access methods. Telecom operators 128 have a huge number of registered users, and they can provide trusted 129 identity and higher security. Therefore they have a natural 130 advantage to act as an Identity Provider (IdP) to serve for service 131 providers. On the contrary most service providers on the Internet 132 have limited amount of users and can not assure the security of user 133 identity, but they can provide abundant kinds of service. 134 Furthermore, user is reluctant to register too many accounts because 135 it is inconvenient to remember dozens of passwords. 137 Telecom network supports Web or non-Web application. In some cases 138 user prefers to choose non-Web application, e.g. Messaging service, 139 VoIP, EMail service, etc. Based on the result of network stratum 140 authentication and authorization, User equipment (UE) can access 141 applications without doing another authentication and authorization 142 procedure. In this way, the system can implement federated cross- 143 layer access. Firstly mutual authentication is performed between UE 144 and Network, secondly UE accesses Application based on the result of 145 network stratum's authentication. In this case, a federation is 146 formed between Network and Application. 148 For federated cross-layer access, Network can assure the Application 149 of the authenticity of user's identity, share some of use profile 150 with Application. These can bring some benifits to stakeholders: 152 o For telecom operators, it becomes part of the business value chain 153 as an Identity Provider. 154 o For service provider, it can focus on core competitive services 155 without worrying about the number of registered users by reusing 156 underlying security mechanisms during network stratum access. 157 o For end users, seamless sevice is provided, security and privacy 158 are improved. 160 4. Message Flow 162 Take mobile network for example, UE has pre-shared key (PSK) with 163 HSS. UE is mutully authenticated with network during attach 164 procedure. After authentication, a master session key (MSK) is 165 created on both UE and AAA. EAP [RFC3748] can enable the above 166 procedure. 168 +-------------+ 169 + Application | 170 / +------+------+ 171 / | 172 / | 173 / | 174 / | 175 / +-----+----+ 176 +---+--+ | | 177 | UE +----------+ Network | 178 +------+ | | 179 +----------+ 181 Figure 1: Federated Cross-Layer Access 183 Figure 1 shows the relation among UE, network and application. 184 Firstly mutual authentication is performed between UE and Network, 185 secondly UE accesses Application using Single Sign-ON (SSO) based on 186 network stratum's authentication. In this case, a federation is 187 formed between Network and Application. The brief steps are as 188 follows: 190 1. When UE attach the Network, mutual authentication is performed 191 master session key is created between them. 192 2. UE visits non-Web Application, e.g Messageing service, VoIP 193 service, or Email service. 194 3. Application has no information about the UE. The Application 195 contacts Network to validate the authentication result in the 196 network stratum. Application can find Network according the 197 configuration or dynamical discovery protocol. 198 4. Network responds to Application with authentication result. 199 5. UE is authorized to access the Application. 201 4.1. Fast Re-authentication 203 The message flows below make use of the security capabilities 204 provided by network and some building blocks, such as GSS-EAP 205 [I-D.ietf-abfab-gss-eap], AAA-SAML etc. 207 As descirbed in the specification of GSS-EAP[I-D.ietf-abfab-gss-eap], 208 UE maps onto GSS-API initiator, RP acts as GSS-API acceptor or EAP 209 path-through authenticator, IdP maps onto EAP server. For the EAP is 210 widely been used, this memo assumes the network access authentication 211 is based on EAP. When UE visits application, it will improve the 212 efficiency of authentication if the previous authentication result is 213 reused. This procedure is called fast re-authentication, which is 214 similar to the definition in EAP-AKA[RFC4187]. 216 +------+ +--------+ +------+ +------+ 217 | UE | | ASN | | IdP | | RP | 218 +---+--+ +----+---+ +---+--+ +---+--+ 219 +-+-----------------+----------------+-+ | 220 | 1. Network Access Authentication | | 221 +-+-----------------+----------------+-+ | 222 | 2. Access Application | | 223 +-------------------------------------------------->| 224 | | 3.GSS/EAP Req/Identity | 225 |<--------------------------------------------------+ 226 | 4.GSS/EAP Res/Fast Re-auth Identity | 227 +-------------------------------------------------->| 228 | | | 5. AAA/EAP Msg | 229 | | |<---------------+ 230 | | | 6. AAA/EAP Msg | 231 | | +--------------->| 232 | 7.GSS/EAP Req/Fast Re-auth | | 233 |<--------------------------------------------------| 234 +-----+--------+ | | | 235 |8.Auth Msg & | | | | 236 | Derive Key | | | | 237 +-----+--------+ | | | 238 | 9.GSS/EAP Res/Fast Re-auth | | 239 +-------------------------------------------------->| 240 | | |10.AAA/SAML Req | 241 | | |<---------------| 242 | | +---------------+ | 243 | | |11.Auth & Deriv| | 244 | | |Key & Con SAML | | 245 | | +---------------+ | 246 | | |12.AAA/SAML Res | 247 | | +--------------->| 248 | | | +-------+-------+ 249 | | | |13.Validate the| 250 | | | |SAML Assertion | 251 | 14.Establish Secure Channel | +-------+-------+ 252 |<------------------------------------------------->| 253 | | | | 254 Figure 2: Fast Re-authentication 256 1. When UE access network, UE is performed mutual authentication 257 with network. EAP can be utilized to facilitate the 258 authentication procedure. EAP-Identity and EAP-Method will be 259 exchanged between UE and network element. After successful 260 authentication, an shared MSK is generated and stored in UE and 261 IdP respectively, which can be used to authenticate other 262 applications and then establish secure channels. The network 263 access authentication and key agreement is used as underlying 264 security mechanism for GSS-API. The required credential for 265 application is retrieved using gss_acquire_cred(). 266 2. UE accesses Relying Party (RP). UE is identified by NAI 267 [RFC4282]. GSS-API [RFC4121] is acted as underlying transport 268 mechanisms. 269 3. RP responds with EAP Request/Identity message, which is 270 contained in GSS-API token as a subtoken. 271 4. UE sends EAP Response/Identity message in GSS-API token, which 272 may include fast re-authentication identity. 273 5. When RP receieves the request from UE, RP transfers the EAP 274 message to IdP in AAA message. IdP checks the EAP message and 275 agrees on fast re-authentication with UE. 276 6. IdP sends EAP-Request/Re-authentication to RP via AAA message. 277 7. RP strips off the AAA header and transfers the EAP message to UE 278 via GSS-API token. 279 8. UE verifies the EAP message, thus authenticate the IdP using the 280 credential retrieve from underlying security mechanisms. UE 281 derives session key from previous credential, which will provide 282 per-message protection, e.g. integrity protection, encryption. 283 9. UE sends EAP-Response/Fast Re-authentication message to RP using 284 GSS-API token. 285 10. RP transfers the EAP message to IdP using AAA message with a 286 SAML Request (samlp:AuthenRequest) [I-D.ietf-abfab-aaa-saml] 287 [I-D.jones-diameter-abfab]. 288 11. When the fast re-authentication is successful, IdP derives the 289 same session key and constructs a SAML respone (samlp: 290 AuthenResponse). 291 12. IdP sends the SAML response message to RP via AAA message. 292 13. RP validates the assertion in the SAML message. RP grants or 293 denies access to the UE. 294 14. RP establishes secure channel with UE by means of GSS-EAP, thus 295 the security services are also provided for message between UE 296 and RP using gss_get_mic() and gss_get_warp(). 298 4.2. Secure Data Sharing 300 After successful authentication, in order to provide effective 301 services to customers, RP may need to retrieve some information from 302 operator's network, which stores some useful information (user 303 profile, contact list, and other resources etc.). 305 The following figure illustrate an arhchitecture of secure data 306 sharingin for federated cross layer access. Network layer includes 307 ASN, IdP and RS, which provides RP in application layer with secure 308 services such as authentication and data sharing. 310 +---------+ 311 _+ RP + 312 ,-` +----+----+\ 313 ,-` | `. 314 ,-` | . 315 ,-` | \ 316 .-` | \ 317 .'` | \ 318 _.'` | `. 319 +-----+--+ +----+----+ . 320 | +--------------------+ | \ 321 | UE | +------+ | IdP | +----+---+ 322 | +-----+ ASN +-------+ +------+ RS | 323 +--------+ +------+ +---------+ +--------+ 325 Figure 3: Architecture of Secure Data Sharing 327 o UE - User Equipment, it is identified by NAI and preconfigured 328 with security credential. 329 o ASN - Access Serving Node, it is located at the border of network. 330 It provides network access and authentication service to UE. 331 o IdP - Identity Provider, it is responsible for management of user 332 identity. It provides authentication service to UE or RP. It is 333 also to retrieve user information from RS and to provide them to 334 RP in the condition of user's permission. 335 o RS - Resource Server, it stores user personal information, such as 336 name, telephone, hobby, contact list, etc. 337 o RP - Relying Party, it provides user with such services as message 338 service, VoIP, EMail service, etc. 340 The following figure depicts the procedure for secure data sharing. 341 UE and IdP are mutually authenticated. RP reuses the authentication 342 result in network access. RP may securely acquire user shared data 343 with the authorization of the user. 345 +----+ +-----+ +-----+ +------+ +----+ 346 | UE | | ASN | | IdP | | RS | | RP | 347 +-+--+ +--+--+ +--+--+ +---+--+ +--+-+ 348 | | | | | 349 +---------------------------------------------------------+ 350 | 1.Federated Cross Layer Access Authentication | 351 +---------------------------------------------------------+ 352 | | | | | 353 | | | 2.User Info Req | 354 | | |<-------------------------+ 355 | | | | | 356 | | 3.|User Info Req| | 357 | | +------------>| | 358 | | | | | 359 | | 4.|User Info Res| | 360 | | |<------------+ | 361 | 5.User Info Author Req | | | 362 |<-------------------------+ | | 363 | | | | | 364 | 6.User Info Author Res | | | 365 +------------------------->| | | 366 | | | | | 367 | | | 7. User Info Res | 368 | | +------------------------->| 369 | | | | | 370 | | | 8. Notification | 371 |<----------------------------------------------------+ 372 | | | | | 374 Figure 4: Procedure of Secure Data Sharing 376 1. UE performs federated cross layer access with IdP and RP, as 377 shown in Figure 2. 378 2. When RP needs to acquire user's infomation for some services, RP 379 sends user information request to IdP. 380 3. IdP verifies the request and sends user information request to 381 RS. 382 4. RS validates the request and sends user information response to 383 IdP according to the user's preferences. 384 5. IdP sends user information authorization request to UE. 385 6. UE chooses the prefered data to be shared and sends the user 386 informaiton authorization response to IdP. 387 7. IdP send the authorized user information to SP. 388 8. After ueer data is sucessfully shared, RP sends a notification to 389 UE. 391 editor's note: The datailed security mechanisms and technical details 392 will be considered in next time. 394 5. Acknowledgements 396 The author would like to thank Klaas Wierenga, Hannes Tschofenig, Sam 397 Hartman, Rhys Smith, Tao Fu, Zhengxue Xia for their valuable 398 comments. 400 6. IANA Considerations 402 TODO 404 7. Security Considerations 406 TODO 408 8. References 410 8.1. Normative References 412 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 413 Levkowetz, "Extensible Authentication Protocol (EAP)", 414 RFC 3748, June 2004. 416 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 417 Version 5 Generic Security Service Application Program 418 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 419 July 2005. 421 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 422 Network Access Identifier", RFC 4282, December 2005. 424 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 425 Protocol Method for 3rd Generation Authentication and Key 426 Agreement (EAP-AKA)", RFC 4187, January 2006. 428 8.2. Informative References 430 [I-D.ietf-abfab-arch] 431 Howlett, J., Hartman, S., Tschofenig, H., and E. Lear, 432 "Application Bridging for Federated Access Beyond Web 433 (ABFAB) Architecture", draft-ietf-abfab-arch-01 (work in 434 progress), March 2012. 436 [I-D.ietf-abfab-usecases] 437 Smith, R., "Application Bridging for Federated Access 438 Beyond web (ABFAB) Use Cases", 439 draft-ietf-abfab-usecases-02 (work in progress), 440 February 2012. 442 [I-D.ietf-abfab-aaa-saml] 443 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding 444 and Profiles for SAML", draft-ietf-abfab-aaa-saml-02 (work 445 in progress), October 2011. 447 [I-D.jones-diameter-abfab] 448 Jones, M. and H. Tschofenig, "The Diameter 'Application 449 Bridging for Federated Access Beyond Web (ABFAB)' 450 Application", draft-jones-diameter-abfab-00 (work in 451 progress), March 2011. 453 [I-D.ietf-abfab-gss-eap] 454 Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 455 Extensible Authentication Protocol", 456 draft-ietf-abfab-gss-eap-05 (work in progress), 457 March 2012. 459 [GSMA_IDM] 460 GSM Association, "White paper on Identity Management 461 Requirements, Issues, and Directions for Mobile Industry", 462 August 2007, . 465 [TelecoSiG] 466 Liberty Alliance Project, "Bridging IMS and Internet 467 Identity", December 2009, . 471 [TS33.220] 472 3GPP, "Generic Authentication Architecture (GAA); Generic 473 Bootstrapping Architecture (GBA)", 3GPP TS 33.220 10.0.0, 474 October 2010. 476 [TR33.980] 477 3GPP, "Liberty Alliance and 3GPP security interworking; 478 Interworking of Liberty Alliance Identity Federation 479 Framework (ID-FF), Identity Web Services Framework (ID- 480 WSF) and Generic Authentication Architecture (GAA)", 3GPP 481 TR 33.980 10.0.0, April 2011. 483 [TR33.924] 484 3GPP, "Identity management and 3GPP security interworking; 485 Identity management and Generic Authentication 486 Architecture (GAA) interworking", 3GPP TR 33.924 10.1.0, 487 June 2011. 489 Author's Address 491 Yinxing Wei (editor) 492 ZTE Corporation 493 No 68, Zijinghua Road 494 Nanjing, Jiangsu 210012 495 China 497 Phone: +86 25 52872328 498 Email: wei.yinxing@zte.com.cn