idnits 2.17.1 draft-chen-pcp-authentication-sim-01.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 : ---------------------------------------------------------------------------- ** There are 51 instances of too long lines in the document, the longest one being 23 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3468 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4186' is defined on line 266, but no explicit reference was found in the text == Unused Reference: 'RFC4187' is defined on line 271, but no explicit reference was found in the text == Unused Reference: 'RFC5448' is defined on line 275, but no explicit reference was found in the text == Unused Reference: 'I-D.chen-pcp-mobile-deployment' is defined on line 298, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-pcp-authentication-06 -- Obsolete informational reference (is this intentional?): RFC 3548 (Obsoleted by RFC 4648) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Chen 3 Internet-Draft China Mobile 4 Intended status: Informational D. Zhang 5 Expires: April 30, 2015 Huawei 6 T. Reddy 7 Cisco 8 October 27, 2014 10 (U)SIM based PCP Authentication 11 draft-chen-pcp-authentication-sim-01 13 Abstract 15 With (U)SIM support, PCP authentication could leverage the 16 credentials stored in (U)SIM. The document details PCP 17 authentication considerations based on (U)SIM support. The 18 authentication procedures in EAP and GBA framework have been 19 specifically elaborated. In order to complete the process, new code 20 and option are also proposed. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 30, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. PCP Authentication with (U)SIM . . . . . . . . . . . . . . . 2 58 2.1. EAP Framework . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. GBA Framework . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 6.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 Mobile network is experiencing the significant traffic changes over 71 the past few years. With Long Term Evolution (LTE) advance, plenty 72 of data services have been appreared to be major traffic on the 73 network. The Port Control Protocol[RFC6887] could facilitate data 74 paths through NAT/Firewell and optimize data traffic behavior. It's 75 obvious a 3rd Generation Partnership Project (3GPP) network can 76 benefit from the use of the PCP service. 77 [I-D.chen-pcp-mobile-deployment]has enumurated several considerations 78 in a mobile environment. Subsribers take advantage of (U)SIM to 79 provide the security guarantee. Hence, PCP clients could also 80 leverage the credential to perform authentication. 82 This document describes the uses of (U)SIM specific authentication 83 which is compatible with [I-D.ietf-pcp-authentication]. A new option 84 is proposed to assist the completion of process. 86 2. PCP Authentication with (U)SIM 88 A permanent key is stored on the (U)SIM card and in AAA nodes (e.g. 89 HLR/HSS) in the mobile network. The key has been to pass through the 90 authentication. Afterwards, derived keys are generated for chipering 91 and integrity protection of user-plan and control plane traffic. The 92 use of (U)SIM to PCP authentication is applicable to WLAN access and 93 3GPP access cases. The following demonstrates the scenarios with 94 different frameworks. 96 2.1. EAP Framework 98 With the support of (U)SIM cards, UEs could take the credentials from 99 (U)SIM cards and perform EAP-SIM[RFC4186]/EAP-AKA[RFC4187]/EAP- 100 AKA'[RFC5448] get through the authentication. The network has been 101 shown as the below. 103 +-----------------+ +----------------+ 104 +----+ | | +----------+ | | 105 | UE | ----- | WLAN IP Access | ----- |PCP Server|---| Public Internet| 106 +----+ | Network | +----------+ | | 107 +-----------------+ | +----------------+ 108 +------+ 109 | AAA | 110 +------+ 112 Figure1: WLAN Access with EAP Support 114 The process of authentication in the EAP framework is compliant with 115 [I-D.ietf-pcp-authentication]. In additon, the PCP server takes the 116 authenticator rule and operates as pass-through behavior. It 117 forwards EAP packets received from the PCP client and destined the 118 backend authentication server (i.e., AAA server); packets received 119 from the AAA server destined to the PCP client are forwarded to it. 120 PCP server is required to have interconnection with AAA server over 121 RADIUS[RFC5580] or DIAMETER[RFC6733] protocol. The Figure 2 shows an 122 example with EAP-AKA/EAP-AKA' process. 124 PCP Client PCP Server(EAP Autenticator) AAA Server(EAP Server) 125 | 1. PCP-Auth-Initiation | | 126 |-------------------------------->| | 127 | 2. PCP-Auth-Server(EAP-Request)| | 128 |<--------------------------------| | 129 | 3.1 EAP-Response/Identity | 3.2 EAP-Response/Identity | 130 |-------------------------------->|---------------------------------->| 131 | 4.2 EAP-Request/AKA-Chanllenge | 4.1 EAP-Request/AKA-Chanllenge | 132 | (RAND, AUTH, MAC) |(RAND, AUTH, MAC) | 133 |<--------------------------------|<----------------------------------| 134 | | | 135 Verify AUTH and MAC, | | 136 derive RES,session key | | 137 | 5.1 EAP-Response/AKA-Chanllege | 5.2 EAP-Response/AKA-Chanllege | 138 | (RES, MAC) | (RES, MAC) | 139 |-------------------------------->| --------------------------------->| 140 | | Check RES and MAC 141 | 6.2 AUTHENTICAION-SUCCESSD | 6.1 AUTHENTICAION-SUCCESSD | 142 |<--------------------------------|<----------------------------------| 144 Figure2: PCP authentication with EAP-AKA/EAP-AKA' 146 The EAP framework could be used to support authentication of WLAN 147 users with (U)SIM. Direct WLAN or WLAN interworking with 3GPP 148 networks can adopt this method. 150 2.2. GBA Framework 152 [TS33.220] has specified Generic Bootstrapping Architecture (GBA) to 153 offer bootstrap authentication and key agreement for application 154 security. This archtecture has been already used to support the 155 authentication of 3GPP access users to service platform with 3GPP AKA 156 mechanism, for example Ut interface authentication in IMS network. 157 GBA has merits of flexibility so the service platforms could benefit 158 from the adoption and do not have to introduce additional process and 159 new credentials. Therefore, it's desirable to accomodate the PCP 160 authetication in such framework. Figure 3 shows the network with 161 GBA. 163 +-----------------+ +----------------+ 164 +----+ | | +----------+ | | 165 | UE | ----- | 3GPP Access | ----- |PCP Server|---| Public Internet| 166 +----+ | Network | +----------+ | | 167 +-----------------+ | +----------------+ 168 +-------+ +------+ 169 |HSS/HLR| -------- | BSF | 170 +-------+ +------+ 172 Figure3: 3GPP Access with GBA Support 174 A Bootstrapping Server Function (BSF) and the UE mutually 175 authenticate using the AKA protocol, and agree on session keys that 176 are afterwards applied between UE and a PCP Server. The set of all 177 user security material is stored in the Home Subscriber System (HSS). 179 Once BSF requires the security material for a user, HSS identity the 180 specific material by matching UE indentity(e.g. MSISDN or IMSI) and 181 reponse BSF with Authentication Vector (AV, AV = 182 RAND||AUTN||XRES||CK||IK). Afterwards, HTTP AKA[RFC3310] is taken 183 place between UE and BSF. As a sequence, both the UE and the BSF 184 shall use the Ks to derive the key material Ks, whichi is used for 185 securing the path between PCP server and UE. BSF also generates a 186 Bootstrapping Transaction Identifier (B-TID) as an index in order to 187 facilitate the conversation between PCP Server and BSF. 189 After the bootstrapping has been completed, the authentication of 190 messages will be exchanged between the UE and a PCP server based on 191 those session keys generated during the mutual authentication between 192 UE and BSF. Figure4 shows the process. 194 PCP Client PCP Server BSF HSS 195 | 1. PCP-Auth-Initiation | | | 196 |-------------------------------->| | | 197 |2. PCP-Auth-Server(bootstrapping)| | | 198 |<--------------------------------| | | 199 | 3.Request(User Identity) | 4.Retrieve AV | 200 |-------------------------------------------------------------->|<--------------->| 201 | 5.401 Unauthorized WWW-Authenticat | 202 | Digest (RAND, AUTH) | 203 |<--------------------------------------------------------------| 204 | 6.Request Authorization: Digest (RES is used) | 205 |-------------------------------------------------------------->| 206 | | Server checks the given Digest 207 | | and drive Ks 208 | 7.200 OK, B-TID, Key lifetime | 209 |<--------------------------------------------------------------| 210 | 8. PCP-Auth-Request | 9. Authentication Request | 211 | (B-TID) | (B-TID) | 212 |-------------------------------->|---------------------------->| 213 | | 10.Authentication Answer | 214 | 11.AUTHENTICAION-SUCCESSD | (Ks, Key lifetime) | 215 |<--------------------------------|<----------------------------| 217 Figure4: PCP authentication in GBA 219 3. Proposal 221 In order to fullfill the process of PCP authentication in GBA, one 222 result code is required and company with 223 [I-D.ietf-pcp-authentication]. 225 TBD BOOTSTRAPPING-INITIATION 227 The code is applied to above step 2 in Figure4. 229 B-TID option is also proposed to perform step 8 in Figure 4. 231 0 1 2 3 232 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Option Code | Reserved | Option-Length | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | B-TID | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Option Code: it's to identify the B-TID use. 241 Option-Length: The length of the B-TID Option (in octet), including 242 the 4 octet fixed header and the variable length of the B-TID 243 message. 245 B-TID: According to ,The B-TID value shall be also generated in 246 format of Network Access Identi (NAI) by taking the base64 encoded 247 [RFC3548], RAND value , and the BSF server name, i.e. 248 base64encode(RAND)@BSF_servers_domain_name. 250 4. Security Considerations 252 TBD 254 5. IANA Considerations 256 TBD 258 6. References 260 6.1. Normative References 262 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 263 Protocol (HTTP) Digest Authentication Using Authentication 264 and Key Agreement (AKA)", RFC 3310, September 2002. 266 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 267 Protocol Method for Global System for Mobile 268 Communications (GSM) Subscriber Identity Modules (EAP- 269 SIM)", RFC 4186, January 2006. 271 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 272 Protocol Method for 3rd Generation Authentication and Key 273 Agreement (EAP-AKA)", RFC 4187, January 2006. 275 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 276 Extensible Authentication Protocol Method for 3rd 277 Generation Authentication and Key Agreement (EAP-AKA')", 278 RFC 5448, May 2009. 280 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. 281 Aboba, "Carrying Location Objects in RADIUS and Diameter", 282 RFC 5580, August 2009. 284 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 285 "Diameter Base Protocol", RFC 6733, October 2012. 287 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 288 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 289 2013. 291 [TS33.220] 292 "Generic Authentication Architecture (GAA); Generic 293 Bootstrapping Architecture (GBA)", 10.1.0 3GPP TS 33.220, 294 March 2012. 296 6.2. Informative References 298 [I-D.chen-pcp-mobile-deployment] 299 Chen, G., Cao, Z., Boucadair, M., Ales, V., and L. 300 Thiebaut, "Analysis of Port Control Protocol in Mobile 301 Network", draft-chen-pcp-mobile-deployment-04 (work in 302 progress), July 2013. 304 [I-D.ietf-pcp-authentication] 305 Wasserman, M., Hartman, S., Zhang, D., and T. Reddy, "Port 306 Control Protocol (PCP) Authentication Mechanism", draft- 307 ietf-pcp-authentication-06 (work in progress), October 308 2014. 310 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 311 Encodings", RFC 3548, July 2003. 313 Authors' Addresses 315 Gang Chen 316 China Mobile 317 53A,Xibianmennei Ave., 318 Xuanwu District, 319 Beijing 100053 320 China 322 Email: phdgang@gmail.com 324 Dacheng Zhang 325 Huawei 326 Beijing 327 China 329 Email: zhangdacheng@huawei.com 330 Tirumaleswar Reddy 331 Cisco Systems, Inc. 332 Cessna Business Park, Varthur Hobli 333 Sarjapur Marathalli Outer Ring Road 334 Bangalore, Karnataka 560103 335 India 337 Email: tireddy@cisco.com