idnits 2.17.00 (12 Aug 2021) /tmp/idnits43084/draft-tschofenig-enroll-next-steps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 912. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 889. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 902. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2004) is 6418 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2617' is mentioned on line 822, but not defined ** Obsolete undefined reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) == Outdated reference: draft-ietf-eap-keying has been published as RFC 5247 == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == Outdated reference: draft-ietf-pana-pana has been published as RFC 5191 == Outdated reference: draft-ietf-tls-psk has been published as RFC 4279 -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENROLL H. Tschofenig 3 Internet-Draft D. Kroeselberg 4 Expires: April 17, 2005 Siemens 5 October 17, 2004 7 Next Steps for ENROLL 8 draft-tschofenig-enroll-next-steps-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 17, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 This document describes framework specific aspects relevant for the 44 Credential and Provisioning (ENROLL) working group. State-of-the-art 45 work with possible relevance for ENROLL is given with a special focus 46 on the 3GPP Generic Authentication Architecture (GAA), which has a 47 relationship to the Trusted Transitive Introduction (TTI) model. The 48 main goal of this document is to initiate some discussions about the 49 focus of the working group and possible next steps. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1 Secret stored in device during manufacturing . . . . . . . 6 57 3.2 Secret established over a secure network . . . . . . . . . 6 58 3.3 Secret established over an insecure network . . . . . . . 7 59 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 63 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 64 7.2 Informative References . . . . . . . . . . . . . . . . . . . 15 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 66 A. 3GPP Generic Boostrapping Architecture . . . . . . . . . . . . 19 67 A.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 19 68 A.2 The Generic Bootstrapping Architecture (GBA) . . . . . . . 20 69 A.3 Application Security for HTTP Based Applications . . . . . 22 70 A.3.1 Use of HTTP Digest Authentication . . . . . . . . . . 23 71 A.3.2 Use of TLS . . . . . . . . . . . . . . . . . . . . . . 23 72 Intellectual Property and Copyright Statements . . . . . . . . 25 74 1. Introduction 76 This document describes framework specific aspects relevant for the 77 Credential and Provisioning (ENROLL) working group. State-of-the-art 78 work with possible relevance for ENROLL is given with a special focus 79 on the 3GPP Generic Authentication Architecture (GAA), which has a 80 relationship to the Trusted Transitive Introduction (TTI) model 81 defined in [I-D.pritikin-ttimodel]. 83 The goal of this document is to discuss relevant scenarios for the 84 work of the ENROLL group, and to provide some views to the discussion 85 from the perspective of 3GPP networks. This explicitly does not 86 consider the imprinting process for mobile operators of GSM or 3GPP 87 networks, where SIM or USIM cards need to be initiated with security 88 credentials (secret keys) and have to be issued to the mobile users 89 by the network operators. This process is well-established; however, 90 the trust relations between security domains related to mobile 91 wireless networking tend to grow in complexity, and dynamic 92 establishment of trust relations, or dynamic addition (and removal) 93 of mobile users to new security domains seems to be the interesting 94 case to be considered by ENROLL. 96 A number of terms are used in [I-D.pritikin-ttimodel] to define a 97 model for introduction. One of them is out-of-band, which can, 98 however, have quite different meanings in different contexts. For 99 example, adding a mobile user by out-of-band means to a security 100 domain can be the process where a network operator sends a letter 101 with the initial credentials (USIM card, PIN) the user requires to 102 get access to the wireless network. In a different scenario, this 103 could be the dynamic, secure issuing of asymmetric credentials for 104 access to services in a security domain requiring the use of such 105 credentials. The user can receive such credentials either by the 106 security domain hosting the service itself, or by a third party that 107 has some trust relation in advance with both the security domain and 108 the mobile user. 110 Hence, as a generic starting point for models relevant to ENROLL, the 111 subsequent classification is taken from Section 4 of 112 [I-D.hanna-zeroconf-seccfg] on security configuration mechanisms. 114 A simple architecture is based on two entities, Alice and Bob. In a 115 more complex scenario three entities are considered. The two party 116 scenario is shown in Figure 1 and the three party scenario is shown 117 in Figure 2. 119 +-----------+ no prior +-----------+ 120 | Entity | trust relation | Entity | 121 | Alice | ship | Bob | 122 +-----------+ +-----------+ 124 Figure 1: Two Party Scenario 126 +-----------+ 127 | Entity | 128 +--------------------------->| Carol | 129 | trust relationship +-----------+ 130 | ^ 131 | | 132 | | 133 | | trust 134 | | relationship 135 | | 136 | | 137 v v 138 +-----------+ no prior +-----+-----+ 139 | Entity | trust relationship | Entity | 140 | Alice | | Bob | 141 +-----------+ +-----------+ 143 Figure 2: Three Party Scenario 145 In Figure 2 the existence of a third party, Carol, is used to 146 dynamically establish a security association between Alice and Bob to 147 create a security association. 149 The relevance of these two models is shown in Section 3. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 The cryptographic initialisation or what is also called imprinting, 158 is a procedure of equipping the component with a secret value of a 159 cryptographic parameter. The type of the parameter varies a lot 160 depending on its subsequent use in security mechanisms. It may be an 161 unstructured randomly generated string, from where future key 162 material is derived. It may also be keying material related to an 163 asymmetric cryptographic mechanism, in which case it has a 164 well-defined structure. 166 In many mobile scenarios, the wireless link is the basic 167 communication channel between the devices. It is inherently 168 insecure, that is, passive eavesdropping, channel hi-jacking, as well 169 as active impersonation and tampering of data is possible. The 170 procedure of imprinting, where the initial secret cryptographic 171 parameters are set in the component, is the most sensitive part of 172 the communication. If tampering or eavesdropping the imprinting step 173 is possible, then the security of all future communication based on 174 imprinting is ruined. 176 Considering the initial provision of credentials for allowing mobile 177 users to access security domains, not only the term imprinting, but 178 also enrollment, or bootstrapping frequently occur. The authors of 179 this contribution are not aware of clear and commonly accepted 180 definitions of these terms, but rather assume that these vary 181 depending on the underlying use cases and scenarios where they are 182 used. 184 Therefore, one goal of the ENROLL working group should be to leverage 185 a common understanding of these terms. 187 3. Classification 189 This section defines a few classes of credential provisioning (or 190 imprinting) scenarios. 192 3.1 Secret stored in device during manufacturing 194 This scenario focuses on a cryptographic secret which is stored in 195 the device during manufacturing. This secret generally cannot be 196 changed and is made available to the user, e.g., by printing on a 197 separate letter (off-line, out-of-band provisioning). Any entity 198 possessing the password can change the configuration of the device. 199 The security of the whole process depends on the shipment of the the 200 letter with the relevant information. 202 This scenario in the view of the authors does not raise any specific 203 issues relevant for the work in the ENROLL working group. 205 3.2 Secret established over a secure network 207 In this scenario it is assumed that Alice and Bob can communicate 208 over a temporary secure channel or out-of-band channel. In this 209 context, the secure channel can be based on one of the following 210 technologies: 212 o Fixed connection such as cable, USB interface, bar-code reader, 213 smart-card reader 214 o Human involvement, communication of passkeys, entering passkeys 215 o Second wireless (e.g., infrared) 216 o Other proximity based technology (low power channel) 217 o Memory sticks (e.g., USB tokens) 219 An example for this approach is given with Windows Smart Network Key 220 [WSNK] where the process of imprinting can be triggered at a new 221 device (e.g., entity A in our example). As a result, Alice creates a 222 key and the corresponding parameters and writes this information into 223 an XML file and copies it to a USB stick. This USB stick is then 224 used to carry the parameters to Bob to complete the imprinting 225 procedure. 227 The content of the XML file heavily depends on the application 228 domain. In the context of wireless LAN equipment security parameters 229 used within IEEE 802.11i/802.11/802.1X are such as: 231 o SSID 232 o Encryption (WEP, TKIP, AES) 233 o EAP Method (EAP-TLS, PEAP-EAP-MSCHAPv2, PEAP-EAP-TLS) 234 o Authentication Type (open, shared, WPA, WPAPSK, WPA-NONE, WPA2, 235 WPA2PSK) 236 o IEEE 802.IX enabled? 238 and many non-security related parameters. 240 An approach to make this process generic for many application domains 241 is ambitious. As an example, the above parameter list includes a few 242 EAP methods. Apart from the fact that the list is, by no means, 243 complete it would also be necessary to specify a few parameters with 244 relevance for each individual EAP method. Switching to a new 245 application domain often requires to consider different types of 246 identities. 248 3.3 Secret established over an insecure network 250 With this class there is no separate secure channel. Still a number 251 of possiblities exist to establish a shared secret between Alice and 252 Bob. Often, an approach similar to SSH is mentioned where the user 253 has to compare a fingerprint of some exchanged parameters (e.g., the 254 public key). This approach is described in [SHAMAN], in Section 4.3 255 of [I-D.hanna-zeroconf-seccfg] or with the Shared Secret Provisioning 256 Protocol (SSPP) [I-D.moskowitz-shared-secret-provprotocol]. Thereby 257 a Diffie-Hellman alike protocol is executed between the two entities, 258 Alice and Bob. A cryptographic hash value computed over some 259 payloads is displayed at both devices and compared. This 260 fingerprinting approach is used to avoid man-in-the-middle attacks. 261 The size of the solution space for such a protocol is affected by the 262 type of environments where such a protocol is used and constraints 263 such as computational requirements, requirements affected by the type 264 of devices used, desired level of security, etc. Since SSPP is an 265 abstract protocol mappings are provided, for example, to SNMP (see 266 [I-D.moskowitz-sspp-snmp]). [I-D.moskowitz-radius-client-kickstart] 267 describes how session keys can be established between RADIUS clients 268 and RADIUS servers for Wireless LAN deployments. 270 Some architectures use a trusted third party to establish a security 271 association between Alice and Bob. These protocols use the existence 272 of a security association (and a trust relationship) between Alice 273 and Bob and a trusted entity, Carol. Figure 2 depicts the 274 architecture. A classic example of this architecture for network 275 access authentication with the help of EAP and EAP methods is 276 described in [I-D.ietf-eap-keying]. The same document describes the 277 interaction between the different protocols and the keying framework. 279 In [I-D.tschofenig-pana-bootstrap-kerberos] a mechanism is described 280 how to bootstrap Kerberos Ticket Granting Tickets based on an EAP 281 network access authentication protocol run. Subsequently, Kerberos 282 service tickets can be requested for access to services. 284 In Figure 5 the 3GPP Generic Authentication Architecture (GAA) 285 approach for establishing a security association between mobile users 286 and services in a security domain the users are not initially part 287 of, is described. Appendix A gives an overview of this architecture. 288 There are a number of interesting differences between the EAP/AAA 289 based approach and the 3GPP GAA framework that allows to leverage the 290 established huge security infrastructure for mobile phone users 292 With a three party architecture two types of message exchanges are 293 possible. We depict these two types in Figure 3 and in Figure 4. 295 +-----------+ 296 | Entity | 297 | C | 298 +-----------+ 299 ^ / 300 | / Key 301 EAP | / Transport 302 over | / in 303 RADIUS/ | / RADIUS/ 304 DIAMETER | / DIAMETER 305 | / 306 v v 307 +-----------+ EAP (IEEE 802.1X) +-----------+ 308 | Entity |<------------------->| Entity | 309 | A | | B | 310 | |<===================>| | 311 +-----------+ Link Layer Security+-----------+ 312 (IEEE 802.11i with 313 TKIP or AES CCMP) 315 Figure 3: EAP based Architecture 317 With the message exchange in Figure 3 Alice starts interacting with 318 Bob. Since there no relationship between Alice and Bob, it is 319 necessary to forward the EAP exchange to Carol whereby Alice has a 320 trust relationship with Carol. After a successful authentication and 321 authorization session keys must be delivered to Bob for subsequent 322 establishment of security associations. A number of protocols today 323 use this architecture, such as IEEE 802.1X [IEEE-802-1X-REV] (and 324 IEEE 802.11i), IKEv2 [I-D.ietf-ipsec-ikev2] or PANA 325 [I-D.ietf-pana-pana]. These protocols just label the involved 326 entities differently. 328 +-----------+ 329 | Entity | 330 | C | 331 +-----------+ 332 ^ / 333 Request / / 334 Assertion/ /Assertion/ 335 Ticket/ / /Ticket/ 336 Token / /Token 337 / / 338 / / 339 / / 340 / v Authentication and 341 +-----------+ Key Exchange Protocol +-----------+ 342 | Entity | (+Token,Ticket,Assertion) | Entity | 343 | A |---------------------------->| B | 344 | |<----------------------------| | 345 +-----------+ +-----------+ 347 Figure 4: Token,Ticket,Assertion-based Architecture 349 With the architecture shown in Figure 4 Alice has to start 350 communication with an Carol first, whereby a direct or indirect trust 351 relationship between these two entities is assumed. First, some form 352 of Token, Ticket or Assertion is requested. Different protocols 353 label this item differently. This exchange typically requires mutual 354 authentication and authorization to be finished before Alice receives 355 the desired item. When a service access is required then Alice 356 interacts with Bob and presents this Token, Ticket or Assertion. 357 Kerberos (with the usage of Tickets) [RFC1510] and SAML (see for 358 example, [I-D.saml-tech-overview-1.1-03], [I-D.saml-core-1.1], 359 [I-D.saml-bindings-1.1]) with the usage of Assertions (or Artifacts 360 which are references to Assertions) are protocol examples. 362 4. Conclusion 364 The above sections give a number of sample classifications for 365 scenarios relevant to the ENROLL group, and reference numerous 366 examples. The main focus is on mobile scenarios, and on the "secret 367 established over insecure network" processes that are considered the 368 most interesting for current demands of introducing mobile users with 369 appropriate credentials to access security domains offering services 370 to the mobile users. Typically, a pre-established trust relation or 371 security relation between such users and services cannot be assumed. 373 As an example that is considered relevant for the ENROLL working 374 group, the 3GPP GAA is discussed in more detail in Appendix A. 376 Although no thorough analysis of the GAA framework is provided in 377 this initial draft version, a number of observations related to the 378 different terminologies are given below. 380 The TTI model draft [I-D.pritikin-ttimodel] defines the term 381 introduction as follows: 'When adding a device into a security domain 382 the first task is to exchange cryptographic and configuration 383 information between the security domain and the device. This process 384 we term an Introduction.' 386 One question that arises is what exactly a "security domain" is? 387 This, of course, heavily depends on the given usage scenario. For 388 example, introduction to a security domain fundamentally differs (as 389 well as the security domain does) for the use cases given in the 390 above section (e.g., storing secret information in a device during 391 manufacturing versus secret stored over insecure wireless link). 393 ENROLL needs to clearly state which types of security domains are 394 covered, and which are not. This draft contributes to this 395 clarification by providing additional use cases. 397 In 3GPP networks, a mobile device is 'added' to the home operator's 398 security domain as soon as the user gets the USIM card. In contrast, 399 through the 3GPP GAA framework (see Annex A for a detailed overview) 400 the mobile user is introduced to a service provider's security domain 401 as soon as a new security context is initiated based on the existing 402 security infrastructure of 3GPP networks. 404 The complexity described in [I-D.pritikin-ttimodel] for PKI 405 enrollment is for instance solved by the GAA by the ability to 406 dynamically issue public-key certificates to mobile users on demand, 407 which offers the advantage that only those users receive 408 certificate-based credentials who really request them. Issuing 409 certificates to the complete, huge, user base of mobile phone 410 networks would unnecessarily increase initial costs and 411 administrational effort. The 3GPP network operator, or some instance 412 with an already established trust relationship with such an operator, 413 can provide the role of an initiator in this case. 415 As it is not fully clear to the authors of this draft whether the 416 definition of Introduction made by [I-D.pritikin-ttimodel] matches 417 with the goals achieved by the 3GPP GAA, the related terms of a 418 petitioner, an introducer and a Registrar are not used for the GAA 419 example in Annex A. Instead, we use the roles of a mobile user, a 420 home network (of the mobile user) and some service provider or 421 application server as logical entities. 423 However, we expect that a good match for the different terminology 424 would be to associate the mobile user with the petitioner, the home 425 network with the introducer, and the application server with the 426 registrar. 428 The 3GPP GAA may be considered as some form of authentication and 429 authorization (AA) infrastructure the mobile user or petitioner is 430 expected to enroll with. Although being a more complex example, this 431 basically matches the 'pay for use' example in Section 4.5 of 432 [I-D.pritikin-ttimodel] which describes the initiation of a trust 433 relation between a mobile user and a public WLAN hotspot (provider of 434 the service 'Internet access') through a credit card company as the 435 initiator. [TS22.934] describes a similar scenario where a 3GPP 436 network operator supports this initiation. 438 One result of matching the 3GPP GAA to the TTI model is that both the 439 introducer and the registrar may issue the credentials that are 440 subsequently used by the petitioner for service access. This depends 441 on the exact grouping of the processes: 442 o If we just consider the process of issuing a certificate to the 443 mobile user, where the user first contacts the BSF to authenticate 444 and establish a new shared secret based trust relation with the 445 NAF responsible for certificate issuing, this NAF may be 446 considered as the Registrar issuing new credentials for subsequent 447 service access. 448 o If we consider service access and group the process of issuing 449 credentials (i.e., the user's communication with the BSF and - 450 based on this exchange éÌŸ subsequently with the NAF, the network 451 offering the GAA service may be considered as the initiator 452 issuing credentials, and these are subsequently used with the 453 registrar, i.e., some other NAF offering e.g. an HTTP-based 454 service to the mobile user. 456 Although there is no clear terminology differentiating between these 457 two examples given above, the authors of this draft tend to regard 458 the first example as introduction, or enrollment, and the second 459 example as a bootstrapping process. 461 5. Security Considerations 463 The document discusses state-of-the-art security architectures and 464 protocols. As such, it addresses a huge number of security issues. 465 No additional specific security vulnerabilities, threat models or 466 solutions are given in this section. 468 6. Acknowledgments 470 We would like to thank Wolfgang Buecker for his input to this 471 document. 473 7. References 475 7.1 Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", March 1997. 480 7.2 Informative References 482 [I-D.hanna-zeroconf-seccfg] 483 Hanna, S., "Configuring Security Parameters in Small 484 Devices", draft-hanna-zeroconf-seccfg-00 (work in 485 progress), January 2002. 487 [I-D.ietf-eap-keying] 488 Aboba, B., "Extensible Authentication Protocol (EAP) Key 489 Management Framework", draft-ietf-eap-keying-03 (work in 490 progress), July 2004. 492 [I-D.ietf-ipsec-ikev2] 493 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 494 draft-ietf-ipsec-ikev2-16 (work in progress), September 495 2004. 497 [I-D.ietf-pana-pana] 498 Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. 499 Yegin, "Protocol for Carrying Authentication for Network 500 Access (PANA)", draft-ietf-pana-pana-05 (work in 501 progress), July 2004. 503 [I-D.ietf-tls-psk] 504 Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 505 for Transport Layer Security (TLS)", draft-ietf-tls-psk-01 506 (work in progress), August 2004. 508 [I-D.moskowitz-radius-client-kickstart] 509 Moskowitz, R., "RADIUS Client Kickstart", 510 draft-moskowitz-radius-client-kickstart-01 (work in 511 progress), October 2003. 513 [I-D.moskowitz-shared-secret-provprotocol] 514 Moskowitz, R., "Shared Secret Provisioning Protocol", 515 draft-moskowitz-shared-secret-provprotocol-02 (work in 516 progress), November 2003. 518 [I-D.moskowitz-sspp-snmp] 519 Moskowitz, R., "SSPP over SNMP", 520 draft-moskowitz-sspp-snmp-01 (work in progress), October 521 2003. 523 [I-D.pritikin-ttimodel] 524 Pritikin, M., "Trusted Transitive Introduction Model", 525 draft-pritikin-ttimodel-01 (work in progress), July 2004. 527 [I-D.saml-bindings-1.1] 528 Maler, E., Philpott, R. and P. Mishra, "Bindings and 529 Profiles for the OASIS Security Assertion Markup Language 530 (SAML) V1.1", September 2003. 532 [I-D.saml-core-1.1] 533 Maler, E., Philpott, R. and P. Mishra, "Assertions and 534 Protocol for the OASIS Security Assertion Markup Language 535 (SAML) V1.1", September 2003. 537 [I-D.saml-tech-overview-1.1-03] 538 Maler, E. and J. Hughes, "Technical Overview of the OASIS 539 Security Assertion Markup Language (SAML) V1.1", March 540 2004. 542 [I-D.tschofenig-pana-bootstrap-kerberos] 543 Tschofenig, H., "Bootstrapping Kerberos", 544 draft-tschofenig-pana-bootstrap-kerberos-00 (work in 545 progress), July 2004. 547 [IEEE-802-1X-REV] 548 Institute of Electrical and Electronics Engineers, "DRAFT 549 Standard for Local and Metropolitan Area Networks: 550 Port-Based Network Access Control (Revision)", IEEE 551 802-1X-REV/D9, January 2004. 553 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 554 Authentication Service (V5)", RFC 1510, September 1993. 556 [RFC3310] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer 557 Protocol (HTTP) Digest Authentication Using Authentication 558 and Key Agreement (AKA)", RFC 3310, September 2002. 560 [SHAMAN] "Detailed technical specification of distributed mobile 561 terminal system security, Deliverable 10, Work Package 2, 562 IST-2000-25350 - SHAMAN", May 2002. 564 [TR33.919] 565 3rd Generation Partnership Project, "3rd Generation 566 Partnership Project; Technical Specification Group 567 Services and System Aspects; Generic Authentication 568 Architecture (GAA); System Description (Release 6)", 569 Technical Specification 3GPP TR 33.919 V2.1.0 (2004-07), 570 July 2004. 572 [TS22.934] 573 3rd Generation Partnership Project, "3rd Generation 574 Partnership Project; Technical Specification Group 575 Services and System Aspects; Feasibility study on 3GPP 576 system to Wireless Local Area Network (WLAN) interworking 577 (Release 6)", Technical Specification 3GPP TS 22.934 578 V6.2.0 (2003-09), September 2003. 580 [TS33.220] 581 3rd Generation Partnership Project, "3rd Generation 582 Partnership Project; Technical Specification Group 583 Services and System Aspects; Generic Authentication 584 Architecture (GAA); Generic bootstrapping architecture 585 (Release 6)", Technical Specification 3GPP TS 33.220 586 V6.2.0 (2004-09), September 2004. 588 [TS33.221] 589 3rd Generation Partnership Project, "3rd Generation 590 Partnership Project; Technical Specification Group 591 Services and System Aspects; Generic Authentication 592 Architecture (GAA); Support for subscriber certificates 593 (Release 6)", Technical Specification 3GPP TS 33.221 594 V6.1.0 (2004-09), September 2004. 596 [WSNK] "Windows Connect Now, Version 3, available at: 597 'http://www.microsoft.com/whdc/device/netAttach/WSNK.mspx' 598 (Oct. 2004)", October 2004. 600 Authors' Addresses 602 Hannes Tschofenig 603 Siemens 604 Otto-Hahn-Ring 6 605 Munich, Bayern 81739 606 Germany 608 EMail: Hannes.Tschofenig@siemens.com 609 Dirk Kroeselberg 610 Siemens 611 Otto-Hahn-Ring 6 612 Munich, Bayern 81739 613 Germany 615 EMail: Dirk.Kroeselberg@siemens.com 617 Appendix A. 3GPP Generic Boostrapping Architecture 619 A.1 Overview 621 This chapter presents the concepts behind the Generic Authentication 622 Architecture (GAA) specified in 3GPP [TR33.919] and the Generic 623 Bootstrapping Architecture (GBA) specified in 3GPP [TS33.220]. This 624 architecture is considered a relevant input scenario for ENROLL, 625 since it supports introduction of mobile users (in the form of 626 establishing shared secrets or public/private key pairs and 627 certificates) for client access to security domains offering 628 arbitrary (typically, but not limited to, HTTP-based) services. This 629 process is based on the available security infrastructure in 3G 630 mobile networks (i.e., on smartcard (USIM) based credentials). 632 The motivation for such an architecture arises from the fact that 633 there are many serives related to 3G mobile systems which all share a 634 requirement for mutual authentication between a client (the mobile 635 device) and an application server. While these authentication 636 mechanisms might differ from application to application, they all 637 require an a priori security relationship to be initiated either 638 dynamically or statically. For all known authentication mechanisms 639 this consists of either shared secret keys or the use of public key 640 cryptography. For example, HTTP digest requires passwords (or shared 641 secret keys) that have to be installed in the mobile user's device 642 before sending the first protected message. TLS assumes that the 643 server and optionally the client are in possession of a TLS 644 certificate before initiating a TLS-secured session. 646 The key issue with setting up initial security "credentials" between 647 the mobile user's device and an application server is the possible 648 complexity of the mobile (3GPP) scenario, where services can be 649 provide by either the home or the visited network, or by 3rd party 650 application providers with a relation to the home or visited network. 651 In general, no initial relation between these parties exists. 653 This lead to the definition of a generic architecture for dynamically 654 setting up security relations (in terms of shared secrets, or 655 public-key certificates) between a mobile device and an application 656 server, based on the existing security infrastructure of 3GPP 657 networks. In such environments, all users are equipped with security 658 credentials on a smartcard device (USIM), and the corresponding keys 659 are stored in an entity called HSS (home subscriber server) in the 660 home network that provides the USIM cards to mobile users. 662 The GAA provides means that allow a mobile user and an application 663 server to establish either shared secrets or to establish a security 664 relation based on user certificates. This generic "enrollment" 665 process is implemented in a unified, application independent 666 architecture that relieves single applications from defining their 667 specific ways of how to achieve a priori security relationships 668 between clients and servers. Authentication is based on the well 669 established AKA algorithm (e.g., used in EAP-AKA) so that the mobile 670 network operator reuses the USIM cards that are expected to be 671 largely spread among mobile phone users. 673 +--------------------+ 674 | Generic | 675 | Authentication | 676 | Architecture (GAA) | 677 +-------+-+----------+ 678 | | 679 +----------------+ +-----------------+ 680 | | 681 +--------+-----------+ +--------+-----------+ 682 | Generic | | Support for | 683 | Bootstrapping | | Subscriber | 684 | Architecture (GBA) | | Certificates (SSC) | 685 +--------------------+ +--------------------+ 687 Figure 5: Components of the Generic Authentication Architecture 689 Thus, as shown in Figure 5, the GAA consists of two main components, 690 one that aims at installing shared secrets in a mobile device and in 691 an application server, and another who issues certificates to mobile 692 devices. The two components are called the Generic Bootstrapping 693 Architecture (GBA) [TS33.220], and Support for Subscriber 694 Certificates (SSC) [TS33.221], respectively. In the following 695 subsections we will discuss the architectural details of these 696 components. As we will see, the support for subscriber certificates 697 is just an example of an application that makes use of the GBA. 698 Finally, we will illustrate the usage of the GBA for HTTP based 699 services that perform client side authentication based on HTTP digest 700 as a simple example. 702 A.2 The Generic Bootstrapping Architecture (GBA) 704 The elements of the Generic Bootstrapping Architecture are displayed 705 in Figure 6. Apart from the mobile device and the HSS there are two 706 additional elements: 708 The Bootstrapping Server Function (BSF): This represents an element 709 that performs mutual authentication with the mobile user by means 710 of the HTTP digest AKA protocol (see [RFC3310]). The 711 authentication vectors required to run the AKA protocol are 712 fetched from the HSS (and are derived in the mobile device, or 713 USIM card, in parallel). One result of the aka procedure is a 714 pair of keys, IK and CK, from which keys are derived for later use 715 by the mobile device and NAF to secure any application related 716 communication. 718 The Network Application Function (NAF): This stands for a generic 719 application server that provides any kind of service (application) 720 to the mobile device. No assumptions are made about the protocol 721 used between mobile device and NAF, though one candidate that is 722 assumed to be used frequently is HTTP. The NAF fetches from the 723 BSF the key that resulted from the aka protocol run between BSF 724 and mobile device, and uses it in securing the application related 725 communication with the mobile device. 727 +-------+ +-------+ 728 | | | | 729 +----------------+ BSF +--------------+ HSS | 730 | | | | | 731 | +---+---+ +-------+ 732 +--+---+ | 733 | | | 734 |mobile| | 735 |device| | 736 +--+---+ | 737 | +---+---+ 738 | | | 739 +----------------+ NAF | 740 | | 741 +-------+ 743 Figure 6: Elements of the Generic Bootstrapping Architecture 745 A high level view on the resulting information flow of the generic 746 bootstrapping procedure is shown in Figure 7. In order to illustrate 747 some of the concepts when the mobile device contacts several NAFs we 748 have shown a communication flow where the mobile device addresses two 749 different NAFs. The mobile device starts by sending a request to the 750 first application server (NAF) indicating its intention to invoke 751 some application (1). The concrete form of this request depends on 752 the protocol used for this application. In general, the mobile 753 device will not know whether GAA bootstrapping has to be performed in 754 order to use the NAF. Therefore, the NAF indicates the use of 755 bootstrapping in a response to the initial request and does not 756 further process the request. After that the mobile device contacts 757 the BSF and runs the HTTP digest aka protocol with the BSF based on 758 the long term secret stored in the USIM located in the mobile device 759 (2). In the course of this procedure the BSF fetches one or more 760 authentication vectors from the HSS which are required to perform the 761 AKA protocol (3). 763 If the HTTP digest AKA protocol succeeds, the mobile device and BSF 764 are in the possession of keys that are later used in securing 765 messages exchanged between mobile device and NAF. 767 The mobile device now initiates a second attempt to send a request to 768 the application server NAF. When the NAF receives the message, it 769 requests the corresponding keys from the BSF (5). After having 770 received the keys from the BSF, NAF is able to verify the request 771 received by the mobile device and can henceforth use the keys to 772 protect any further communication (6). Again, the details of the 773 protection of these messages depend on the concrete protocol that is 774 used by the application. 776 +--------+ +-----+ +-----+ +-----+ 777 | mobile | | NAF | | BSF | | HSS | 778 | device | | | | | | | 779 +--------+ +-----+ +-----+ +-----+ 780 | | | | 781 | REQUEST | | | 782 |-------------------->| | | 783 (1) | Bootstrap required | | | 784 |<--------------------| | | 785 | | | | 786 | Perform http digest AKA | Fetch AV | 787 (2) |<------------------------------>|<---------->| 788 | | | (3) | 789 +-----------+ | +-----------+ | 790 |Derive keys| | |Derive keys| | 791 +-----------+ | +-----------+ | 792 | | | | 793 | REQUEST (secured) | | | 794 (4) |-------------------->| Get keys | | 795 | |<-------->| | 796 | Answer (secured) | (5) | | 797 (6) |<--------------------| | | 799 Figure 7: Elements of the Generic Bootstrapping Architecture 801 A.3 Application Security for HTTP Based Applications 803 In the previous section we described how a security relation between 804 a mobile device and an application server is established using the 805 Generic Bootstrapping Architecture. In this section we briefly 806 illustrate the use of the Generic Bootstrapping mechanism in case the 807 application protocol HTTP is run between the mobile device and the 808 NAF. 810 In the simplest case the (mutual) authentication between mobile 811 device and NAF can be performed using simple HTTP digest. In 812 addition, TLS may be used which offers a higher level of security due 813 to the encryption of the message exchange. TLS can either be used 814 with server-only authentication, i.e., the server uses a TLS server 815 certificate, and the client authenticates by other means like http 816 digest through the TLS tunnel, or with the client authenticating with 817 a TLS user certificate (mutual authentication). 819 A.3.1 Use of HTTP Digest Authentication 821 If HTTP is used as protocol between a mobile device and an 822 application server, HTTP Digest [RFC2617] is one natural candidate to 823 perform simple client-only or mutual authentication between mobile 824 device and application server. The role of the GBA in this scenario 825 would be to provide the client and HTTP server (the NAF) with a http 826 digest password (shared secret). Such information is not present for 827 step (1) in Figure 7, since client and server do not have any initial 828 security relation in place. After step (5) in Figure 7 has taken 829 place, both the client in the mobile device and the NAF share a 830 common secret to be used as http digest password. 832 A.3.2 Use of TLS 834 When it comes to securing HTTP related communication, the use of TLS 835 is another common option. Beyond authentication and integrity 836 protection, it provides encryption of the communication packets. In 837 a typical web scenario, the web server is authenticated using public 838 key cryptography based on certificates. Following this, a secure 839 tunnel, called the TLS record layer is established which carries all 840 future communication between the client and the server. Frequently, 841 the client is then authenticated by some separate protocol e.g. 842 based on a password and some challenge-response mechanism like for 843 instance HTTP Digest. 845 As already described in the above section the GBA can support this 846 hybrid approach by initiating a security relation for http digest. 847 The PKI-related aspects of the server-side PKI required for TLS 848 operation are not considered here, and are independend of the 849 functionality provided by the GBA. 851 Yet, TLS also offers the possibility for a client to present a 852 certificate on which the client authentication can be based. 854 However, today client certificates are often not used in the context 855 of TLS as only few users of mobile devices bother to acquire 856 certificates. There also exist proposals in the IETF to run TLS 857 based on pre-shared keys not using certificates at all 858 [I-D.ietf-tls-psk], i.e. both authentications (client to server and 859 server to client) are based on symmetric techniques. 861 The 3GPP GAA allows to provide mobile users with such certificates on 862 request. For this, the following steps are executed: 864 (1) The mobile user uses the GBA as depicted in Figure 7, where 865 the NAF is not the application server to be accessed via TLS, but 866 a server allowing the client to request the issuing of (enrollment 867 for) a Subscriber Certificate. Mutual authentication between the 868 NAF providing Subscriber Certificates and the mobile user is based 869 on the keys established after the user contacted the BSF. As a 870 result, the mobile user requests a Subscriber certificate from the 871 NAF. 873 (2) The mobile user subsequently uses the Subscriber Certificate 874 to authenticate the TLS session with the application server to be 875 finally contacted. 877 The detailed specification for provisioning of Subscriber 878 Certificates can be found in [TS33.221]. 880 Intellectual Property Statement 882 The IETF takes no position regarding the validity or scope of any 883 Intellectual Property Rights or other rights that might be claimed to 884 pertain to the implementation or use of the technology described in 885 this document or the extent to which any license under such rights 886 might or might not be available; nor does it represent that it has 887 made any independent effort to identify any such rights. Information 888 on the procedures with respect to rights in RFC documents can be 889 found in BCP 78 and BCP 79. 891 Copies of IPR disclosures made to the IETF Secretariat and any 892 assurances of licenses to be made available, or the result of an 893 attempt made to obtain a general license or permission for the use of 894 such proprietary rights by implementers or users of this 895 specification can be obtained from the IETF on-line IPR repository at 896 http://www.ietf.org/ipr. 898 The IETF invites any interested party to bring to its attention any 899 copyrights, patents or patent applications, or other proprietary 900 rights that may cover technology that may be required to implement 901 this standard. Please address the information to the IETF at 902 ietf-ipr@ietf.org. 904 Disclaimer of Validity 906 This document and the information contained herein are provided on an 907 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 908 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 909 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 910 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 911 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 912 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 914 Copyright Statement 916 Copyright (C) The Internet Society (2004). This document is subject 917 to the rights, licenses and restrictions contained in BCP 78, and 918 except as set forth therein, the authors retain all their rights. 920 Acknowledgment 922 Funding for the RFC Editor function is currently provided by the 923 Internet Society.