idnits 2.17.00 (12 Aug 2021) /tmp/idnits39746/draft-le-mobileip-sharedsecret-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 0) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 170: '...thors that the AAA-H SHOULD perform a...' RFC 2119 keyword, line 254: '...the Home network MUST be able to updat...' RFC 2119 keyword, line 256: '...corrupted and the Home network MUST be...' RFC 2119 keyword, line 272: '...eived authentication data that MUST be...' RFC 2119 keyword, line 384: '.... The credential SHOULD securely bind ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 23 has weird spacing: '... It is inapp...' == Line 170 has weird spacing: '...rs that the A...' == Line 544 has weird spacing: '... patent appli...' -- 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 (23 February 2001) is 7757 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) -- Looks like a reference, but probably isn't: 'RANDTSK' on line 345 -- Looks like a reference, but probably isn't: 'RANDNET' on line 349 -- Looks like a reference, but probably isn't: 'AUTHNET' on line 354 -- Looks like a reference, but probably isn't: 'RANDU' on line 362 -- Looks like a reference, but probably isn't: 'AUTHU' on line 366 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP WG Franck Le 3 INTERNET-DRAFT Stefano M. Faccin 4 Date: 23 February 2001 5 Expires: 23 August 2001 Nokia Research Center 7 Temporary Shared Key Function for secure delegation of security to the 8 local network 9 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 When roaming to other domains, mobile nodes (clients) need to offer 35 credentials to a local AAA server in order to be granted access to 36 the local network. Security association may need to be set up 37 between the mobile nodes and entities of the visited domain (e.g. 38 between the MN and Home Agent when Home Agent is assigned in the 39 visited network, or between the MN and Mobility Agents when 40 extensions [1], [2] to Mobile IP are used). These security 41 associations have a lifetime that when expired, needs to be 42 refreshed. In addition, network operators need the ability to force 43 a MN to provide authentication information anytime during a session. 45 The home network and/or the visited network need to have this 46 capability. In the same way, the mobile node may want to challenge 47 the network at any time e.g. to avoid man in the middle attacks. All 48 these procedures require the involvement of the AAA-H since only the 49 MN and the home domain share a long term key. This implies that 50 several message round trips between the visited and home domains are 51 needed to support the above mentioned authentication and key 52 distribution procedures. This document introduces the concept of a 53 MN specific Temporary Shared Key (TSK) between the AAA-L and MN, thus 54 allowing authentication and key distribution control to be securely 55 performed by the visited domain. In this way, the AAA-L can set up 56 security associations to be shared between the MN and entities of the 57 visited domain, and perform network and user entity authentication 58 without having to involve the home network, yet, such procedures are 59 performed securely because the user-specific Temporary Shared Key was 60 created by the MN and the home domain. 62 1. Introduction 64 When roaming to other domains, mobile nodes (clients) need to offer 65 credentials to a local AAA server in order to be granted access to 66 the local network. Security association may need to be set up 67 between the mobile nodes and entities of the visited domain (e.g. 68 between the MN and Home agent when Home agent is assigned in the 69 visited network, or between the MN and Mobility agent when extensions 70 [1], [2] to Mobile IP are used). These security associations have 71 lifetime and, when expired, need to be refreshed. The visited 72 network may also want to authenticate the MN at any time and in the 73 same way, the mobile node may want to challenge the network. All 74 these procedures require the AAA-L to invoke the AAA-H in order to 75 perform authentication and key distribution. In fact, only the MN and 76 the home domain share a long term key that can support authentication 77 of the MN or of the network, thus AAA-h needs to be involved. This 78 implies that several message round trips between the visited and home 79 domains are needed to support the above mentioned authentication 80 procedures. 82 This document introduces the concept of a user-specific Temporary 83 Shared Key (TSK) between the AAA-L and MN, thus allowing 84 authentication and key distribution control to be securely performed 85 by the visited domain. In this way, the AAA-L can set up security 86 associations to be shared between the MN and entities of the visited 87 domain, and perform network and user entity authentication without 88 having to involve the home network of the MN but, at the same time, 89 performing such procedures securely due to the fact that the user- 90 specific TSK was created by the MN and the home domain. 92 In some cellular systems such as the ones built according to the 93 IS-41 standards, concepts similar to the Temporary Shared Key 94 Function had been defined. Such a function encompasses the processes 95 by which the authentication center in the home network and the 96 serving (visited) system manage the sharing of authentication 97 responsibilities for a visiting MS. Temporary Shared Key (TSK) 98 sharing gives the visited system significant local control over the 99 authentication of a visiting MS. Specifically, thanks to TSK, the 100 visited system can control the following network functions without 101 having to involve the Home network: 103 - set up of security keys between the mobile node and entities 104 within the visited domain (key distribution) 106 - MN Authentication at any time 108 - Network authentication at any time. 110 The concept of Temporary Shared Key Function would enable the AAA-L 111 to support user authentication, key distribution and network 112 authentication without having to involve the AAA-H. This would allow 113 for less round trips between the visited and home domains, thus 114 reducing time delay and load over the network. 116 To allow TSK sharing between the MN and AAA-L, the MN and the AAA-L 117 must have a common algorithm to compute authentication data and 118 session keys. In case multiple algorithms are available, a 119 negotiation needs to take place between MN and AAA-L to select one. 121 2. TSK sharing option 123 The TSK is optional and can be shared or not between the home domain 124 and the visited domain depending on network policies and roaming 125 agreements: In order to maximize the security, there may be cases in 126 which the home domain will not be willing to share the TSK with the 127 visited domain. This may happen when, as an example, the mobile node 128 moves to a visited domain that the home domain does not trust 129 sufficiently or with which the home domain does not have a roaming 130 agreement covering the TSK mechanism. Also, there may be cases when 131 the visited domain does not have an authentication and key 132 distribution algorithm in common with the mobile node and thus the 133 TSK cannot be used. 135 The TSK is a possible optimization to the security procedures in 136 particularly considering the signaling involved between the Visited 137 and the Home networks, but whether the Temporary Shared Key is 138 provided to the Visited Domain depends on the Home network. 140 3. Definitions 142 Data Origin Authentication: 144 Data Origin authentication is a type of authentication whereby a 145 party is corroborated as the (original) source of specified data 146 created at some tim in the past. Data origin authentication 147 includes data integrity. 149 Entity Authentication: 151 Entity authentication is the process allowing one party (the 152 verifier) to gain assurances that the identity of another (the 153 claimant) is as declared, thereby preventing impersonation. 155 Perfect forward Secrecy: 157 A protocol is said to have perfect forward secrecy if compromise 158 of long-term keys does not compromise past session keys. 160 4. Computation and Distribution of the TSK 162 4.1. Initial Authentication and Initiation of Temporary Shared Key 163 Function 165 When the MN enters a new visited domain and first registers, its Home 166 AAA server is invoked to verify the validity of the user and if the 167 visited and home domains decide to use the Temporary Shared Key 168 concept, the Temporary Shared Key must be updated and distributed. 170 It is opinion of the authors that the AAA-H SHOULD perform a 171 Temporary Shared Key update process at least every time the MN is 172 entering a new visited domain. Otherwise the pevious visited domain 173 has the value of the Temporary Shared Key and can act of behalf of 174 the MN and perform undesirable things. 176 The Temporary Shared Key computation and distribution can be 177 integrated to the entity authentication at the first registration as 178 follow: 180 Router 181 +.......................+ 182 Host . UCP CP . AAAL AAAH 183 | LC . | | . | | 184 |<--------------------| | . | | 185 |AAA Req: LC,RPI,ID,CR,HC | . | | 186 |-------------------->| | . | | 187 | . | AHR (LC, HC) . | | 188 | . |- - - - - - - - |- - - - - - - - >|AHR(LC,HC) 189 | . | | . |- - - >| 190 | . | | . AHA(RANDTSK,TSK,AUTHNET) 191 | . | AHA (RANDTSK, AUTHNET) |< - - -| 192 | . |<- - - - - - - -| -.- - - - - - - | | 193 | . | Update config | . | | 194 | . |--------------->| . | | 195 | . | | . | | 196 | . | | . | | 197 | . | | . | | 198 |AAA Rep: stat,RPI, RANDTSK, AUTHNET) | . | | 199 |<--------------------| | . | | 200 | . | | . | | 201 +.......................+ 203 LC = Local AAA Challenge 204 HC = Host Challenge generated by the MN to authenticate the network 205 RPI = Replay Protection Indicator used between host and AAAH 206 CR = AAA Credential 207 ID = Client Identifier 208 AUTHNET = Authentication data computed by the network 209 UCP = Uncontrolled part 210 CP = Controlled part 211 AHR = AAA Host Request (using an AAA protocol) 212 AHA = AAA Host Answer (using an AAA protocol) 214 As described in [1] and [7], the MN uses the Local Challenge to 215 compute some authentication data [1] and can derive some temporary 216 ciphering and integrity protection keys from that Local Challenge and 217 the long term key shared between the MN and its Home AAA server [7]. 218 The MN also generates a Host challenge to require network 219 authentication. Then the MN encrypts and integrity protects the 220 message using the temporary security keys and leaving its Identity 221 (e.g. the NAI) in cleartext. 223 The AAA-V forwards the message to the AAA-H including the Local 224 Challenge. From the Local Challenge and the user specific shared 225 long-term key retrieved thanks to the user's NAI, the AAA-H derives 226 the ciphering and integrity protection keys and decrypts the message. 228 It verifies the validity of the user, computes some network 229 authentication data from the Host Challenge, and eventually generates 230 some keying material. At that point, if the AAA-H and AAA-V decide 231 to use the Temporary Ciphering Key, the AAA-H generates a new random 232 number called the the RandomVariableTSK (RANDTSK) and executes the 233 algorithm shared with the MN using the long term shared key to 234 compute the new "pending" TSK. The AAA-H sends the RANDTSK to the MN 235 and sends the corresponding Temporary Shared Key to the AAA-V. The 236 AAA-H can use the temporal keys to protect the response to the MN and 237 uses inter AAA servers security to protect the message to the AAA-V. 239 The MN receiving the response, decrypts it using the Temporal 240 Ciphering and Integrity protection keys, and verifies the 241 authenticity of the network thanks to the network authentication data 242 computed from the Host Challenge. If RANDTSK is provided to the MN, 243 the MN derives, from the long term key and the common algorithm 244 shared with its AAA-H server, the corresponding TSK to use for 245 subsequent entity authentication and key distribution procedures. 247 The MN receives the RANDTSK in the message carrying the network 248 authentication data and can therefore be sure that the information is 249 coming from its Home network. In addition, RANDTSK is protected 250 using the Temporal ciphering and integrity protection keys thus 251 increasing the level of security. 253 The TSK is thus updated every time the MN is entering a new Domain 254 but in addition, the Home network MUST be able to update the TSK at 255 any time when the MN is in a visited domain and the TSK is shared: As 256 an example, the TSK may get corrupted and the Home network MUST be 257 able to revocate the TSK by performing a new TSK update. 259 In the following section the description of the procedures relevant 260 for the TSK update while the MN is in a session is provided. 262 4.2. Temporary Shared Key Update 264 The Temporary Shared Key (TSK) Update function encompasses the 265 processes by which the TSK in a MN is changed to a new value under 266 the direction of the AAA-H. Only the AAA-H may initiate this 267 operation when the TSK is shared with the serving system. 269 On the network side, a user authentication process could be executed 270 immediately after the TSK Update to confirm that the target MN has 271 successfully changed its TSK: the network sends a challenge to the MN 272 and based on the expected received authentication data that MUST be 273 from the TSK, the network cam make sure the TSK update had been 274 successful and the MN is having the new TSK value. This would ensure 275 that the MN will be able to authenticate itself and the network in 276 the future. 278 On the MN side, the MN initiates a network authentication procedure 279 when the MN is directed by the network to change its TSK. This 280 authentication procedure allows the MN to authenticate the network 281 issuing the TSK Update, thus preventing a fraudulent network from 282 disrupting the normal network operation by forcing the MN's TSK out 283 of alignment with the legitimate network TSK. 285 The TSK update includes AAA-H TSK update process and the serving 286 system TSK update process. 288 4.2.1. AAA-H TSK update process 290 The AAA-H may initiate the TSK update process at any moment when the 291 MN is in a visited domain and is sharing TSK. The decision on when 292 the TSK is updated is based on home domain policies. TSK should not 293 be changed too often, otherwise the benefits of TSK disappear. At the 294 same time, TSK must have a lifetime to ensure that the same TSK is 295 not used for too long. The first step in the TSK update process is 296 for the AAA-H to execute the algorithm shared with the MN using the 297 long term shared key and a random number, called the 298 RandomVariableTSK (RANDTSK). The result is the new "pending" TSK. 300 The AAA-H then sends the RANDTSK and the new TSK to the AAA-L. The 301 AAA-H then waits for a report from the AAA-L. 303 With the RANDTSK and the new TSK, the AAA-L can: 305 - update the TSK in the MN 307 - respond to the network authentication request from the MN 309 - verify the update by issuing a user specific authentication 310 procedure to the MN 312 4.2.2. Serving system Temporary Shared Key update process 314 The serving system begins the TSKupdate process when it receives the 315 RANDTSK parameter from the AAA-H. The message also contains either 316 the new TSK Key. 318 - The AAA-L directs the serving router to send a TSK Key update 319 order, including RANDTSK, to the MN. 321 - The MN responds with a network authentication request including 322 the challenge selected by the MN, RANDNET 324 - the AAA-L executes the shared algorithm using as inputs the 325 MN's challenge RANDNET, and the new TSK. The result of the 326 calculation is AUTHNET which is sent to the MN. 328 - Depending if AUTHNET equals to the expected corresponding 329 result the MN indicates a successful or an unsuccessful 330 TSKupdate in a message to the AAA-L 332 - If successful, the serving system executes the user specific 333 authentication procedure; otherwise AAA-L reports the failure 334 to the AAA-H. 336 Host AAA-L AAA-H 337 | | | 338 | | AAA TSK Update Req 339 | |<------------------| 340 | |RANDTSK, AUTHU, RANDU 341 | | | 342 | | AAA TSK Reply | 343 |AAA TSK Update Req----------------->| 344 |<---------------| | 345 | [RANDTSK] | | 346 | | | 347 | AAA Net. Auth. Request | 348 |--------------->| | 349 | [RANDNET] | | 350 | | | 351 | | | 352 |AAA Net.Auth.Rep. | 353 |<---------------| | 354 | [AUTHNET] | | 355 | | | 356 |AAA TSK update Reply | 357 |--------------->| | 358 | [success] | | 359 | | | 360 |AAA user auth. req | 361 |<---------------| | 362 | [RANDU] | | 363 | | | 364 | AAA user auth. Repl. | 365 |--------------->| AAA Report | 366 | [AUTHU] |------------------>| 367 | | | 368 | | AAA Report ack | 369 | |<------------------| 370 | | | 372 5. Entity authentication and key distribution using the TSK 374 This section describes how the TSK sharing enables the Visited domain 375 to perform entity authentication and key distribution without 376 involving the home network thus reducing the time delay and the 377 signaling between the two domains. 379 5.1. User authentication using TSK 381 Currently, as described in section 3.4 [3], the AAA credential is 382 created by the client and is verified by AAA-H. The creation and 383 verification is based on a long-term security association shared 384 between the client and AAA-H. The credential SHOULD securely bind the 385 following pieces of information: 387 - client identifier, 389 - local AAA challenge, if one was provided by the attendant, and 391 - depending on the style of replay protection being used between 392 the host and AAAH, either a timestamp or a pair of challenges. 394 In specific instantiations, additional data may be included in the 395 computation of the AAA Credential. 397 The exact algorithm used to compute the AAA Credential depends on the 398 security association between the client and AAAH. 400 The authentication data is thus computed using a long-term key shared 401 between the MN and the AAA-H, some other information and an 402 algorithm. 404 When the TSK mechanism is used, the MN takes the same inputs but 405 instead of using the long term key it shares with its AAA-H, the MN 406 uses the TSK it shares with the AAA-L and the shared algorithm. The 407 visited system having the TSK and the shared algorithm can then 408 authenticate the MN without invoking its home network. 410 5.2. Network authentication using TSK 412 The MN may want to authenticate the network and thus use the Host 413 Challenge to challenge the network. In such case, the MN expects a 414 network authentication data computed by the AAA-H using the Host 415 Challenge and currently, the long term shared key. The exact 416 algorithm used to compute the AAA Credential depends on the security 417 association between the client and AAAH. 419 If the TSK mechanism is used, the MN sends the Host Challenge to 420 authenticate the network and the AAA-L applies the common algorithm 421 to the Host Challenge and the TSK to compute the authentication data, 422 i.e. the network authentication data. 424 Network authentication is thus provided without involving the AAA-H. 426 5.3. Key distribution using TSK 428 The key distribution (e.g. between the MN and HA when HA is assigned 429 in the visited network, or between the MN and Mobility agent when 430 extensions [1], [2] to Mobile IP are used) is usually based on the 431 long-term security association between the MN and its AAA-H. This 432 security association is used to create derivative security 433 associations between the mobile node and other entities in the 434 visited domain. 436 When TSK is shared, the MN receives the indication that TSK is to be 437 used, and therefore the MN uses the TSK to compute the keys instead 438 of the long-term key. In this way, since the AAA-L uses the temporary 439 shared key as well, the keys will be available to MN and AAA-L and 440 AAA-L does not need to involve the Home network in the procedures. 442 6. Comparison with existing earlier solutions 444 Previous Request For Comments and Internet Drafts documents specify 445 extensions and suggest mechanisms to distribute the session keys to 446 be shared between the mobile node and mobility agents. Those 447 security associations are to provide data origin authentication of 448 the Binding update and binding acknowledgement messages as required 449 by Mobile IPv6. 451 But when the lifetime of these session keys expires, a new key 452 distribution procedure (e.g. as defined in [4]) needs to be executed 453 involving the home network. The message round trips between the 454 serving and home domain imply time delays, and increase the load over 455 the network. To avoid these issues, one possible solution seems to 456 give longer lifetime to the session keys. But long lifetime session 457 keys have higher risks to get compromised and thus, a key revocation 458 procedure needs to be defined to solve this induced problem. 459 Refreshing short-time keys is preferrable (same concepts are adopted 460 in Kerberos [5] and in cellular networks) and the Temporary Shared 461 Key mechanism enables to refresh short-time session keys without 462 having to involve the Home network. 464 The Temporary Shared Key sharing is therefore an enhancement and 465 optimization of the existing schemes. 467 In addition, the keys defined in current proposals are used to 468 provide data origin authentication, but the home and the visited 469 domain should be able to perform entity authentication for the mobile 470 node based on challenge response based mechanism [6]. 472 The Temporary Shared Key enables to perform that user entity 473 authentication, and network entity authentication without involving 474 the Home network. 476 7. Pros and Cons of the Temporary Shared Key sharing 478 The Temporary Shared Key sharing is a function enabling the serving 479 system to securely perform entity authentication and key distribution 480 functions with the MN on behalf of the home network but without 481 having to involve the home network, thus saving round trips between 482 the visited and home networks and reducing time delay and network 483 load. 485 This mechanism enables to provide strong network authentication such 486 as challenge response based mechanism without having to involve the 487 AAA-H. 489 It is a possible optimization and the home and visited system can 490 decide to use it or not based on policies and common agreements. 492 The only requirement of this Temporary Shared Key is to have a common 493 algorithm between the MN and the AAA-L to perform authentication and 494 key distribution. 496 8. Messages format 498 AAA Protocol messages 500 The Temporary Shared Key sharing requires new messages; they have the 501 following general structure. 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Type = TBD | Code | Checksum | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Message body | 509 + + 510 Type The following new types are defined: 511 AAA TSK Update Request: TBD 512 AAA TSK Update Reply: TBD 513 AAA Network Auth. Request: TBD 514 AAA Network auth. Reply: TBD 515 AAA User auth. Request: TBD 516 AAA User auth. Reply: TBD 517 AAA Report 519 Code The Code field depends on the message type. 520 - AAA TSK Update Reply 521 SUCCESS: 0 522 FAILURE: 1 523 - For AAA Report 524 SUCCESS: 0 525 FAILURE: 1 527 These messages could be defined either as new ICMPv6 messages or as 528 Destination Option to Mobile IPv6 between the MN and AAA-L and as 529 DIAMETER messages between AAA-L and AAA-H. 531 9. Security Considerations 533 This document introduces the concept of securely delegating part of 534 the security functions to the Visited domain to avoid delays in 535 authentication and key distribution procedures and reduce signaling 536 load between the visited and home Domains. The Temporary Shared Key 537 mechanism is an optimization that AAA-L and AAA-H may decide to use 538 or not based on policies and roaming agreements. 540 10. Intellectual Property Considerations 542 Nokia Corporation and/or its affiliates hereby declare that they are 543 in conformity with Section 10 of RFC 2026. Nokia's contributions may 544 contain one or more patents or patent applications. To the extent 545 Nokia's contribution is adopted to the specification, Nokia 546 undertakes to license patents technically necessary to implement the 547 specification on fair, reasonable and nondiscriminatory terms based 548 on reciprocity. 550 11. References 552 [1] Jari T. Malinen and Charles E. Perkins. Mobile IPv6 553 Regional Registrations. Internet Draft, Internet 554 Engineering Task Force, December 2000. 556 [2] Hesham Soliman, Claude Castelluccia, Karim El-Malki, and 557 Ludovic Bellier. Hierarchical MIPv6 mobility management. 558 Internet Draft, Internet Engineering Task Force, September, 559 2000. 561 [3] N. Asokan, Patrik Flykt, Charles E. Perkins and Thomas 562 Eklund AAA for IPv6 Network Access. Internet Draft, 563 Internet Engineering Task Force, January 2000. 565 [4] Charles E. Perkins and Pat R. Calhoun. AAA Registration 566 Keys for Mobile IP. Internet Draft, Internet Engineering 567 Task Force, January 2001. 569 [5] Clifford Neuman, John Kohl and Theodore Ts'o. The Kerberos 570 Network Authentication Service (V5). Internet Draft, 571 Internet Engineering Task Force, November 2000. 573 [6] Franck Le, Raj Patil and Stefano M. Faccin. Challenge- 574 Response Authentication Request. Internet Draft, Internet 575 Engineering Task Force, February 2001. 577 [7] Franck Le and Stefano M. FaccinKey distribution for Mobile 578 IPv6. Internet Draft, Internet Engineering Task Force, 579 February 2001. 581 12. Authors' Addresses 583 Franck Le 584 Nokia Research Center 585 6000 Connection Drive 586 Irving, TX 75039 587 USA 589 Phone: +1 972 374-1256 590 E-mail: franck.le@nokia.com 592 Stefano M. Faccin 593 Nokia Research Center 594 6000 Connection Drive 595 Irving, TX 75039 596 USA 598 Phone: +1 972 894-4994 599 E-mail: stefano.faccin@nokia.com 600 Table of Contents 602 Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i 604 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 606 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 608 2. TSK sharing option . . . . . . . . . . . . . . . . . . . . . . . 2 610 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 612 4. Computation and Distribution of the TSK . . . . . . . . . . . . . 3 613 4.1. Initial Authentication and Initiation of Temporary 614 Shared Key Function . . . . . . . . . . . . . . . . . . . . . . . 3 615 4.2. Temporary Shared Key Update . . . . . . . . . . . . . . . . 5 616 4.2.1. AAA-H TSK update process . . . . . . . . . . . . . . . 6 617 4.2.2. Serving system Temporary Shared Key update process 618 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 620 5. Entity authentication and key distribution using the TSK . . . . 8 621 5.1. User authentication using TSK . . . . . . . . . . . . . . . 9 622 5.2. Network authentication using TSK . . . . . . . . . . . . . . 9 623 5.3. Key distribution using TSK . . . . . . . . . . . . . . . . . 10 625 6. Comparison with existing earlier solutions . . . . . . . . . . . 10 627 7. Pros and Cons of the Temporary Shared Key sharing . . . . . . . . 11 629 8. Messages format . . . . . . . . . . . . . . . . . . . . . . . . . 11 631 9. Security considerations . . . . . . . . . . . . . . . . . . . . . 12 633 10. Intellectual Property Considerations . . . . . . . . . . . . . . 12 635 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 637 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14