idnits 2.17.00 (12 Aug 2021) /tmp/idnits40449/draft-le-mobileip-keydistribution-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 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 15 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. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 22 has weird spacing: '... It is inapp...' == Line 465 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) == Missing Reference: '8' is mentioned on line 501, but not defined -- 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' ** Obsolete normative reference: RFC 2409 (ref. '5') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 8 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 Key distribution mechanisms for Mobile IPv6 8 10 Status of This Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 Mobile IP and many of its extensions such as Mobile IPv6 Regional 34 Registration [1] or Hierarchical MIPv6 Mobility Management [2] 35 require strong authentication between the mobile node and different 36 agents (Home Agent, Gateway Mobility Agent [1], Mobility Anchor Point 37 [2]) which are either located in the Home or Visited Domain. 39 The mobile node may share a security association with its home AAA 40 server for entity authentication to allow him to roam in different 41 other domains. The idea described in this draft is that such security 42 association can be used to create derivative security associations 43 between the mobile node and other entities in the visited or home 44 domain. The keys thus established between the nodes can not only be 45 used for authentication as required by Mobile IP and many of its 46 extensions but additionally for confidentiality (e.g. over the access 47 link between the mobile node and the access router) or other security 48 services if required. This document specifies mechanisms and 49 extensions to the Mobile IP to distribute security information to the 50 mobile node. 52 1. Introduction 54 Mobile IP and many of its extensions such as Mobile IPv6 Regional 55 Registration [1] or Hierarchical MIPv6 Mobility Management [2] 56 require strong authentication between the mobile node and different 57 agents (Home Agent, Gateway Mobility Agent [1], Mobility Anchor Point 58 [2])which are either located in the Home or Visited Domain. 60 The mobile node may share a security association with its home AAA 61 server for entity authentication to allow him to roam in different 62 other domains: the idea is that when the mobile node enters a new 63 visited domain, the serving system may want to authenticate the user 64 to make sure he is a valid one before giving him access to its 65 network resources, and the security association between the mobile 66 node and the home domain is used to support such authentication. 68 The security association between the mobile node and the home domain 69 security association can also be used to create derivative security 70 associations between the mobile node and other entities in the 71 visited or home domain (e.g. AAA in visited domain). The derivative 72 security associations thus established between the nodes can not only 73 be used for authentication as required by Mobile IP and many of its 74 extensions but additionally used for confidentiality (e.g. over the 75 access link between the mobile node and the access router) or other 76 security services if required. This document specifies mechanisms and 77 extensions to the Mobile IP to distribute security information to the 78 mobile node. 80 Two methods are described in this document to support key 81 distribution. The first method described is based on random numbers 82 and the second one is based on the Diffie Hellman mechanism. 84 This document actually introduces the concept and future revisions 85 will include more implementation details. 87 2. Definitions 89 Perfect forward Secrecy: 91 A protocol is said to have perfect forward secrecy if compromise 92 of long-term keys does not compromise past session keys. 94 3. Background and Motivation 96 Different key distribution schemes have already been introduced such 97 as the ones described in "AAA Keys for Mobile IP" [3], or 98 "Registration keys for Route Optimization" [4]. All such proposal 99 suggest to distribute the key to the mobile node over the access link 100 by encrypting it either using a long term security association 101 between the mobile node and the AAA-H or using Public keys. 103 When considering radio links, sending the keys encrypted with a long 104 term security association over the air interface causes a weak link 105 in the security chain: the wireless link is weak since everyone can 106 eavesdropp and the risk to have the long term key compromised is 107 high. In fact, even if the keys are distributed by encrypting them, 108 traditionally such key distribution mechanisms have been avoided in 109 order to increase the system security. In addition, in such 110 mechanism, once the long term key is compromised, the network can not 111 distribute new keys to the MN. 113 For that reason, security keys in cellular networks (e.g. GSM, UMTS, 114 IS-41) are never distributed over the air. 116 For the same reasons, in the present key distribution mechanisms used 117 today such as Internet Key Exchange [5], keys are not distributed 118 encrypted using a long term key: nonces, hash, Diffie Hellman values 119 can be encrypted but the keys are not distributed, even encrypted. 121 Moreover, mechanisms proposed in [3], [4] do not provide Perfect 122 Forward Secrecy. 124 As for the utilization of Public Keys as suggested in the current 125 proposals, in addition to the high risk to have the Public Keys 126 compromised by using them over the access link, and the lack of 127 Perfect Forward Secrecy, in order for public keys solutions to be 128 widely and efficiently deployed in commercial systems such as 129 cellular networks, a well established PKI needs to exist. Moreover, 130 many issues still need to be solved for the adoption of public keys 131 in wireless networks: first of all, the limitated availability of the 132 radio resources must be taken into account thus raising problems such 133 as the procedure and the frequency for certificate revocation, and 134 the certificate length itself. In addition, public keys based 135 algorithms are also more time consuming, thus creating delay issues, 136 and are more CPU demanding: low end mobile nodes may not be able to 137 support the requirements of public key algorithms. 139 Diffie Hellman based key distribution is a viable alternative to 140 establish the security associations between the mobile node and 141 entities in the visited or home domains. Internet Key Exchange is 142 based on Diffie Hellman mechanism but IKE may not be appropriate for 143 a wireless network: it requires too many messages to be exchanged 144 over the access link and we need to consider that radio resources are 145 a very limited and expensive resource. 147 Although IKE may not be the best solution for a cellular environment, 148 a simpler and lighter key distribution based on Diffie Hellman will 149 enable to re-apply the work of the IPsec Working Group to the Diffie 150 Hellman mechanism. Furthermore key distribution based on Diffie 151 Hellman can provide Perfect Forward Secrecy. 153 In summary, this document proposes to add two other key distribution 154 mechanism to the mechanisms that already exist: a method based on 155 random numbers and one based on the Diffie Hellman mechanism. 157 4. Key distribution based on random numbers 159 4.1. Background 161 In current cellular networks, key distribution is based on random 162 number. The Mobile Station and the Home Network share a long term 163 key and have knowledge of a common authentication and key generation 164 algorithm (e.g. CAVE in IS 41). Either the Home Network or the 165 visited network generates the random number, depending on the 166 specific cellular system considered. In the latter case, the visited 167 domain informs the Home network of the value of the random number 168 using inter domain security (e.g. thanks to a security association 169 established through a roaming agreement). 171 The random number is then sent to the Mobile station and using the 172 long-term key and the common authentication and key generation 173 algorithm, the MS derives the session keys. The Home Domain, having 174 the same long-term key and authentication and key generation 175 algorithms can also compute the same keys. It can then forwad them, 176 protected using the inter domain security assocation, to the visited 177 domain if the keys need to be shared between the mobile station and 178 the visited domain. 180 In such a mechanism, over the access link, only the random number and 181 the response to the authentication need to be sent. Even if they are 182 eavesdropped this does not compromise the security since the 183 eavesdropper does not know the long term key and cannot compute the 184 session keys. This mechanism does not require to send the long term 185 key over the access link, thus reducing the risk of having it 186 compromised. 188 4.2. Basic procedure 190 In the AAA framework, the Local Challenge [6] broadcasted by the 191 visited domain in Router advertisments messages can be used as the 192 random number to derive the session keys. The following procedure 193 describes how key distribution takes place. 195 Router 196 +.......................+ 197 Host . UCP CP . AAAL AAAH 198 | LC . | | . | | 199 |<--------------------| | . | | 200 |AAA Req: LC,RPI,ID,CR| | . | | 201 |-------------------->| | . | | 202 | . | HR (LC, CR) | . | | 203 | . |- - - - - - - - |- - - - - - - - >| | 204 | . | | . AHR(LC, CR) 205 | . | | . |- - - >| 206 | . | | . AHA (K1,..., Kn; 207 | . | | . R1,...,Rn) 208 | HA (K1,..., Kn; R1,...,Rn) |< - - -| 209 | . |<- - - - - - - -| -.- - - - - - - | | 210 | . | Update config | . | | 211 | . |--------------->| . | | 212 | . | | . | | 213 | . | | . | | 214 | . | | . | | 215 |AAA Rep: stat,RPI, R1,...,Rn | . | | 216 |<--------------------| | . | | 217 | . | | . | | 218 +.......................+ 220 LC = Local AAA Challenge 221 RPI = Replay Protection Indicator used between host and AAAH 222 CR = AAA Credential 223 ID = Client Identifier 224 UCP = Uncontrolled part 225 CP = Controlled part 226 AHR = AAA Host Request (using an AAA protocol) 227 AHA = AAA Host Answer (using an AAA protocol) 228 K1, ..., Kn = Session Keys 229 R1, ..., Rn = Random values 231 The Local challenge is then transmitted to the Home domain in the AHR 232 message, protected using inter AAA servers security. Thanks to the 233 Client Identifier (e.g. the user's NAI) AAA-H retrieves the user 234 specific long-term key and using the shared authentication and key 235 generation algorithm, AAA-H derives the session keys K1-Kn. 237 The session keys are provided to the appropriate entities that will 238 adopt them. Examples of session keys are the key used by the mobile 239 node and the Home Agent for authenticating binding updates and 240 Binding acknowledgement messages, and possible key shared by the 241 mobile node and mobility agents. If this agent is in the Home 242 network, AAA-H forwards the value of the session keys using intra 243 domain security. Otherwise, if the agent is in the visited domain, 244 AAA-H transmits the session keys in a AHA message protected using 245 inter AAA servers security, and the AAA-L forwards the session keys 246 to the corresponding agents using visited domain intra domain 247 security. 249 4.3. Enhanced procedure 251 In the previous case, the messages exchanged with the mobile node 252 during the key distribution procedure are in clear text. The 253 mechanism can be enhanced to provide confidentiality and 254 authentication of the first messages as described in the follow: 256 Router 257 +.......................+ 258 Host . UCP CP . AAAL AAAH 259 | LC . | | . | | 260 |<--------------------| | . | | 261 |AAA Req*: LC,RPI,ID,CR| | . | | 262 |-------------------->| | . | | 263 | . | AHR (LC, CR) | . | | 264 | . |- - - - - - - - |- - - - - - - - >| | 265 | . | | . AHR(LC, CR) 266 | . | | . |- - - >| 267 | . | | . AHA (K, RAND_K) 268 | . | AHA (K, RAND_K) |< - - -| 269 | . |<- - - - - - - -| -.- - - - - - - | | 270 | . | Update config | . | | 271 | . |--------------->| . | | 272 | . | | . | | 273 | . | | . | | 274 | . | | . | | 275 |AAA Rep*: stat,RPI,KR, RAND_K | . | | 276 |<--------------------| | . | | 277 | . | | . | | 278 +.......................+ 280 Note: (*) indicates that the message is ciphered and integrity 281 protected as described below. 283 The mobile node takes the Local Challenge and using the long term key 284 and a key derivation algorithm it shares with its Home domain, it 285 derives a Temporal Ciphering Key and an Temporal Integrity Key. The 286 mobile node then creates the AAA Req message and encapsulates the 287 Binding Update message; it also uses the previously computed keys to 288 encrypt and integrity protect the message but leaving the Client 289 Identifier in Clear text. 291 The Visited domain forwards this message to the AAA-H for user 292 authentication, including the value of the Local Challenge. 294 The AAA-H retrieves the user specific long term key thanks to the 295 Client ID, and using the Local Challenge, derives the Temporal 296 Ciphering Key and Temporal Integrity Key to decrypt the message. AAA- 297 H then verifies the authenticity of the user based on the AAA 298 credentials and generates a random number RAND_K. Based on this 299 value, using the user specific long term key and the common 300 authentication and key generation algorithm it shares with the MN, it 301 derives a key K. 303 AAA-H then forwards K to AAA-L using inter AAA servers security and 304 uses the Temporal Ciphering Key and the Temporal Intergrity Key to 305 secure the message to the MN carrying RAND_K. As indicated in the 306 basic procedure, the AAA-H may distribute K to some entity, e.g. the 307 Home Agent. 309 When receiving the reply, the MN uses the Temporal Ciphering Key and 310 Temporal Integrity Key to decrypt the message and using RAND_K, 311 derive the session key to be used. 313 The advantage of this mechanism is that it gives more control to the 314 Home network since AAA-H generates the random number RAND_K used for 315 the computation of the session keys and, in addition, provides more 316 security since the messages exchanged with the mobile node during the 317 key distribution procedure can be protected using the Temporal 318 Ciphering Key and Temporal Intergrity Key. Finally RAND_K is also 319 encrypted when sent to the MN. 321 5. Key distribution based on Diffie Hellman mechanism 323 5.1. Background 325 In the key distribution solutions proposed in the previous section, 326 the AAA-H acts as a Key Distribution Center, generating the session 327 keys and thus having knowledge of the keys used. 329 In a key distribution based on the Diffie Hellman mechanism, only the 330 MN and the appropriate entities (i.e. the entities that will be using 331 the keys for securing communications) have knowledge of the keys. 332 Restricting the knowledge of the security key only to the entities 333 that will actually use the keys is particularly useful in the 334 following cases: 336 - when Home Agent is assigned in Visited Domain; 338 - for the security asociation to be used over the access link 339 between the MN and the access router; 341 - for the security association to be set up between the MN and 342 the mobility agents in the visited domain (when an extension 343 such as [1] or [2] is deployed). In such cases the visited 344 domain and the MN may not want the home domain to know the 345 value of the session keys. 347 In addition, as mentioned above, the current proposals for Mobile IP 348 key distribution does not provide Perfect Forward Secrecy whereas a 349 key distribution mechanism based on Diffie Hellman can provide that 350 security service. 352 5.2. Diffie Hellman mechanism 354 As defined in [7], Diffie Hellman allows two nodes to derive a shared 355 secret key for use in secret-key cryptography as follows: 357 Each node generates a random, secret value which it keeps private. 359 Each node computes a public value, derived mathematically from the 360 random, secret value, and sends this public value to the other node. 362 Each node mathematically combines the public value received from the 363 other node with its own random, secret value. 365 Due to the mathematical properties involved in the derivation of the 366 public and secret values, the two nodes end up with the same exact 367 combined values at the end of the procedure, which they can use as a 368 shared secret key. In this exchange, the secret portions are not 369 disclosed to anyone and therefore only these two nodes can compute 370 the combined value. 372 Diffie-Hellman has a major vulnerability, though. Although it allows 373 two nodes to establish a shared, secret key in a secure fashion, it 374 does not allow a node to figure out with what other node it is 375 establishing that specific secret key: an intruder on the path 376 between two nodes could fool them into each establishing a key with 377 the intruder instead of each other (man in the middle attack). To 378 prevent this kind of man-in-the-middle attack and defeat such 379 vulnerability, the Diffie Hellman Public value must be authenticated. 381 5.3. Procedure 383 As indicated above, in order to use the Diffie Hellman mechanism, the 384 Diffie Hellman public values must be authenticated. In the Mobile 385 IP/AAA framework, the security association between the Mobile node 386 and its home network (AAA-H) and the security association between the 387 AAA-L and AAA-H can provide that authentication. 389 If the mobile node wants to set up a securiy association with an 390 agent (e.g. home agent), the mobile node first sends its public 391 Diffie Hellman value DH_MN using the long term security association 392 it shares with its AAA-H to authenticate it. If the agent with whom 393 the MN wants to set up a security association is in the visited 394 domain, AAA-V retieves the agent's Diffie Hellman public value using 395 intra domain security and sends such value (authenticated with the 396 security association it shares with the AAA-H) to the home network of 397 the MN together with the message from the MN. 399 AAA-H authenticates the Diffie Hellman Public values of the agent and 400 the MN, and then sends the MN's Diffie Hellman Public Value to the 401 AAA-L using the security association it shares with AAA-L and 402 encapsulates the Agent's Diffie Hellman Public Value to the MN using 403 the security association it shares with the MN to authenticate it. 405 In this way, AAA-H is used to authenticate the Diffie Hellman public 406 values but since it does not have knowledge of the secret values, it 407 can not derive the secret. AAA-H is used as a certificate authority 408 thus allowing an easy transition when Public Key Infrastructure will 409 be deployed. 411 6. Possible optimizations thanks to the Temporary Shared Key 413 As described in [8], the Temporary Shared Key function encompasses 414 the processes by which the authentication center (AAA-H) and the 415 serving system (AAA-L) manage the sharing of authentication 416 reponsibilities for a visiting MN. 418 Initially, the MN and its Home network (AAA-H) share a long term 419 security association. When TSK is used, the Home network provides 420 the serving system (AAA-L) with a user specific temporary Shared Key 421 that that is shared between the serving system and the MN. 423 The temporary Shared Key refresh, set up and other related procedures 424 are described in [8]. TSK Sharing gives the serving system 425 significant load control over the authentication and key distribution 426 of a visiting MN: the key refresh and new key distribution procedure 427 can be based on this temporary shared Key stored in the AAA-L thus 428 saving round trips with the Home network. 430 Thanks to the TSK sharing function, the AAA-L can refresh and set up 431 new keys for security associations between the MN and agents in the 432 visited domain without involving the MN's home network. 434 This reduces time delay and load over the network. 436 This optimization can be applied both for the key distribution method 437 based on random numbers and for the key distribution method based on 438 the Diffie Hellman mechanism. In the first case, the serving system 439 must have the common authentication and key generation algorithm and 440 instead of using the long term key with the random number to compute 441 the session keys, the MN and the AAA-L use the temporary Shared Key 442 and the random number as the inputs to the common authentication and 443 key generation algorithm. In the second case, the MN uses the 444 temporary Shared Key to authenticate its Diffie Hellman public value. 445 The AAA-L does not need to invoke the AAA-H to verify the identity of 446 the node sending the public value. 448 These are possible optimizations to the key distribution mechanisms 449 but whether the TSK function is used depend on policies of the Home 450 and Visited networks. 452 7. Security Considerations 454 The focus of this document is to provide the appropriate level of 455 security for Mobile IP entities (mobile node,home agent, mobility 456 agent) to operate Mobile IP Binding Update, binding acknowledgement. 457 The security associations resulting from use of the suggested 458 mechanisms can also offer other security services between the mobile 459 node and entities in the visited domain. 461 8. Intellectual Property Considerations 463 Nokia Corporation and/or its affiliates hereby declare that they are 464 in conformity with Section 10 of RFC 2026. Nokia's contributions may 465 contain one or more patents or patent applications. To the extent 466 Nokia's contribution is adopted to the specification, Nokia 467 undertakes to license patents technically necessary to implement the 468 specification on fair, reasonable and nondiscriminatory terms based 469 on reciprocity. 471 9. References 473 [1] Jari T. Malinen and Charles E. Perkins. Mobile IPv6 474 Regional Registrations. Internet Draft, Internet 475 Engineering Task Force, December 2000. 477 [2] Hesham Soliman, Claude Castelluccia, Karim El-Malki, and 478 Ludovic Bellier. Hierarchical MIPv6 mobility management. 479 Internet Draft, Internet Engineering Task Force, September, 480 2000. 482 [3] Charles E. Perkins and Pat R. Calhoun. AAA Registration 483 Keys for Mobile IP. Internet Draft, Internet Engineering 484 Task Force, January 2001. 486 [4] Charles E. Perkins, David B. Johnson, Carnegie Mellon 487 University and N. Asokan. Registration Keys for Route 488 Optimization. Internet Draft, Internet Engineering Task 489 Force, July 2000. 491 [5] D. Harkins and D. Carrel Internet Key Exchange. Request for 492 Comments 2409, Internet Engineering Task Force, November 493 1998. 495 [6] N. Asokan, Patrik Flykt, Charles E. Perkins and Thomas 496 Eklund AAA for IPv6 Network Access. Internet Draft, 497 Internet Engineering Task Force, January 2000. 499 [7] Diffie, W. and Hellman, M., "New Directions in 500 Cryptography", IEEE Transactions on Information Theory, 501 Vol. IT-22, Nov. 1976, pp. 664- 654. IP [8] 10 Franck Le 502 and Stefano M. Faccin. Temporary Shared Key Function for 503 secure delegation of security to the local network. 504 Internet Draft, Internet Engineering Task Force, February 505 2001. 507 10. Authors' Addresses 509 Franck Le 510 Nokia Research Center 511 6000 Connection Drive 512 Irving, TX 75039 513 USA 515 Phone: +1 972 374-1256 516 E-mail: franck.le@nokia.com 518 stefano M. Faccin 519 Nokia Research Center 520 6000 Connection Drive 521 Irving, TX 75039 522 USA 524 Phone: +1 972 894-4994 525 E-mail: stefano.faccin@nokia.com 526 Table of Contents 528 Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i 530 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 532 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 534 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 536 3. Background and Motivation . . . . . . . . . . . . . . . . . . . . 2 538 4. Key distribution based on random numbers . . . . . . . . . . . . 3 539 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 540 4.2. Basic procedure . . . . . . . . . . . . . . . . . . . . . . 4 541 4.3. Enhanced procedure . . . . . . . . . . . . . . . . . . . . . 5 543 5. Key distribution based on Diffie Hellman mechanism . . . . . . . 7 544 5.1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 545 5.2. Diffie Hellman mechanism . . . . . . . . . . . . . . . . . . 8 546 5.3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 8 548 6. Possible optimizations thanks to the Temporary Shared Key . . . . 9 550 7. Security considerations . . . . . . . . . . . . . . . . . . . . . 10 552 8. Intellectual Property Considerations . . . . . . . . . . . . . . 10 554 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 556 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12