idnits 2.17.1 draft-carroll-dynmobileip-cdma-04.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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Upon receipt of an Access Reject containing the MIP_Key_Update_Request VSA, PDSN MUST send an RRP to the MN with the MIP_Key_Request VSE. The PDSN MUST use the RRP error code = 89 (Vendor Specific) and MUST not tear down the PPP session after transmission. -- 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 (January 2004) is 7407 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 section? '1' on line 55 looks like a reference -- Missing reference section? '2' on line 104 looks like a reference -- Missing reference section? '3' on line 105 looks like a reference -- Missing reference section? '4' on line 843 looks like a reference -- Missing reference section? '5' on line 107 looks like a reference -- Missing reference section? '6' on line 114 looks like a reference -- Missing reference section? '7' on line 203 looks like a reference -- Missing reference section? '8' on line 378 looks like a reference -- Missing reference section? '9' on line 426 looks like a reference -- Missing reference section? '10' on line 495 looks like a reference -- Missing reference section? '11' on line 518 looks like a reference -- Missing reference section? 'Optional' on line 1309 looks like a reference -- Missing reference section? '12' on line 1381 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft C. Carroll, 3 HBSR* 4 Document: F. Quick, 5 draft-carroll-dynmobileip-cdma-04.txt Qualcomm Inc. 6 Expires: July 2004 January 2004 8 Verizon Wireless 9 Dynamic Mobile IP Key Update 10 for 11 cdma2000(R) Networks 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The Verizon Wireless Dynamic Mobile IP Key Update procedure is a 36 mechanism for distributing and updating Mobile IP (MIP) cryptographic 37 keys in cdma2000(R) networks (including High Rate Packet Data which 38 is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update 39 (DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUS 40 AAA Server via a CDMA2000(R) Packet Data Serving Node (PDSN) that is 41 acting as a Mobile IP Foreign Agent (FA). 43 cdma2000(R) is a registered trademark of the Telecommunications 44 Industry Association (TIA). 46 * This document was developed while at Verizon Wireless. 48 Dynamic MIP Key Update January 2004 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC-2119 [1]. 56 Table of Contents 58 1. Introduction...................................................3 59 2. Basic Dynamic MIP Key Update Mechanism.........................3 60 2.1 RSA Encrypted Key Distribution.............................3 61 2.2 Mutual Authentication (1X).................................4 62 2.3 Encrypted Password Authentication..........................7 63 3. Dynamic MIP Key Update Advantages over OTASP...................8 64 4. Detailed DMU Procedure Description and Requirements............9 65 4.1 RSA Public Key Cryptography................................9 66 4.2 Other Public Key Algorithms...............................10 67 4.3 Why no Public Key Infrastructure (PKI)?...................10 68 4.4 Cryptographic Key Generation..............................10 69 4.5 MIP_Key_Data Payload......................................11 70 4.6 RSA Key Management........................................12 71 4.7 RADIUS AAA Server.........................................13 72 4.8 MN (Handset or Modem).....................................15 73 4.9 PDSN / Foreign Agent (FA).................................17 74 4.10 Home Agent (HA)..........................................18 75 4.11 DMU Procedure Network Flow...............................19 76 5. DMU Procedure Failure Operation...............................23 77 6. cdma2000(R) HRPD/1xEV-DO Support..............................26 78 6.1 RADIUS AAA Support........................................26 79 6.2 MN Support................................................27 80 6.3 Informative: MN_Authenticator Support.....................28 81 7. Security Considerations.......................................29 82 7.1 Cryptographic Key Generation by the MN....................29 83 7.2 Man-in-the-Middle Attack..................................29 84 7.3 RSA Private Key Compromise................................29 85 7.4 RSA Encryption............................................30 86 7.5 False Base Station/PDSN...................................30 87 7.6 cdma2000(R) 1X False MN...................................30 88 7.7 HRPD/1xEV-DO False MN.....................................30 89 7.8 Key Lifetimes.............................................30 90 7.9 Network Message Security..................................30 91 8. Verizon Wireless RADIUS Attributes............................31 92 9. Verizon Wireless Mobile IP Extensions.........................32 93 10. Public Key Identifier and DMU Version........................33 94 11. Intellectual Property........................................37 95 12. Conclusion...................................................38 96 13. Formal Syntax................................................38 97 14. Appendix - Cleartext-Mode Operation..........................40 98 Dynamic MIP Key Update January 2004 100 1. Introduction 102 The Verizon Wireless Dynamic Mobile IP Key Update procedure is a 103 mechanism for distributing and updating Mobile IP (MIP) cryptographic 104 keys in cdma2000(R) 1xRTT (1X) [2] and High Rate Packet Data (HRPD) / 105 1xEV-DO networks [3]. The Dynamic Mobile IP Key Update (DMU) 106 procedure occurs between the Mobile IP Mobile Node (MN) and the home 107 RADIUS [4] (or Diameter [5]) Authentication, Authorization and 108 Accounting (AAA) Server via a CDMA2000(R) Packet Data Serving Node 109 (PDSN) that is acting as a Mobile IP Foreign Agent (FA). (In this 110 document we use the acronym AAAH to indicate the home AAA server as 111 opposed to a AAA server that may be located in a visited system.) 112 This procedure is intended to support wireless systems conforming to 113 Telecommunications Industry Association (TIA) TR-45 Standard IS-835 114 [6]. DMU, however, could be performed in any MIP network to enable 115 bootstrapping of a shared secret between the Mobile Node (MN) and 116 RADIUS AAA Server. 118 The DMU procedure utilizes RSA Public key cryptography to securely 119 distribute unique MIP keys to potentially millions of cdma2000(R) 1X 120 and HRPD/1xEV-DO Mobile Nodes (MN) using the same RSA Public key. 122 By leveraging the existing cdma2000(R) 1X authentication process, the 123 Dynamic Mobile IP Key Update process employs a mutual authentication 124 mechanism in which device-to-network authentication is facilitated 125 using cdma2000(R) 1X challenge-response authentication and network- 126 to-device authentication is facilitated using RSA encryption. 128 By utilizing RSA encryption, the MN (or MN manufacturer) is able to 129 pre-generate MIP keys (and the CHAP key) and pre-encrypt the MIP keys 130 prior to initiation of the DMU procedure. By employing this pre- 131 computation capability, the DMU process requires an order of 132 magnitude less computation during the key exchange than Diffie- 133 Hellman Key Exchange. 135 2. Basic Dynamic MIP Key Update Mechanism 137 The DMU procedure is basically an authentication and key distribution 138 protocol which is more easily understood by separately describing the 139 mechanism's two functional goals: 1) encrypted key distribution and 140 2) mutual authentication. 142 2.1 RSA Encrypted Key Distribution 144 By utilizing RSA Public Key Cryptography, MNs can be pre-loaded with 145 a common RSA Public (encryption) key (by the MN manufacturer) while 146 the associated RSA Private (decryption) key is securely distributed 147 from the MN manufacturer to each service provider. Alternatively, a 148 service provider can generate its own RSA Public/Private key pair and 149 Dynamic MIP Key Update January 2004 151 only distribute the RSA Public key to MN manufacturers for pre- 152 loading of MNs. 154 During the manufacturing process, the MN manufacturer pre-loads each 155 MN with the RSA Public key. When the MN is powered-up (or client 156 application initiated), the MN can pre-generate and encrypt MIP keys 157 for distribution to the Home RADIUS AAA Server during the DMU 158 process. Alternatively, the MN manufacturer can pre-generate MIP 159 keys, encrypt the MIP key payload, and pre-load the MN with multiple 160 encrypted MIP key payloads to enable the DMU procedure. 162 During the initial registration process (or when the AAA requires MIP 163 key update), the MN: 1) generates the appropriate MIP keys, CHAP key, 164 and authentication information, 2) uses the embedded RSA Public key 165 to encrypt the payload information, 3) and appends the payload to the 166 MIP Registration Request. The Registration Request is sent to the 167 Mobile IP Foreign Agent (FA) via the cellular Base Station (BS) and 168 Packet Data Serving Node (PDSN). When the RADIUS AAA Server receives 169 the encrypted payload (defined as MIP_Key_Data later), the AAA Server 170 uses the RSA Private key to decrypt the payload and recover the MIP 171 keys. 173 MN BS/PDSN/FA AAA 174 -- ---------- --- 175 | | | 176 ------------------ | ------------------- 177 | RSA Public Key | | | RSA Private Key | 178 | Pre-loaded by | | | Pre-loaded by | 179 | Manufacturer | | | Service Provider | 180 ------------------ | ------------------- 181 | Registration Request, | 182 | (MIP keys), RSA | | 183 | Public Key | | 184 |-------------------->| | 185 | | Access Request, (MIP keys), 186 | | RSA Public Key | 187 | |---------------------->| 188 | | ------------------- 189 | | | Decrypt MIP | 190 | | | Keys using RSA | 191 | | | Private Key | 192 | | ------------------- 194 Figure 1. RSA Encrypted Key Distribution 196 2.2 Mutual Authentication (1X) 198 Mutual authentication can be achieved by delegation of the MN/device 199 authentication by the RADIUS AAA Server to the cdma2000(R) 1X Home 200 Dynamic MIP Key Update January 2004 202 Location Register (HLR) and its associated Authentication Center (AC) 203 [7], while the MN utilizes RSA encryption to authenticate the RADIUS 204 AAA Server. 206 MN/device authentication via an HLR/AC is based on the assumption 207 that the MN's Mobile Station (MS) has an existing Authentication Key 208 (A-key) and Shared Secret Data (SSD) with the cdma2000(R) 1X network. 209 When MS call origination occurs, the AC authenticates the MS. If 210 authentication is successful, the BS passes the Mobile Station 211 Identifier (MSID) (e.g. Mobile Identification Number (MIN)) to the 212 PDSN. The "Authenticated MSID" is then included in the RADIUS Access 213 Request (ARQ) message [4] sent from the PDSN to the RADIUS AAA 214 server. Because the RADIUS AAA server stores the MSID associated 215 with an MN subscription, the RADIUS AAA server is able to authorize 216 MN access if the "Authenticated MSID" matches the RADIUS AAA MSID, 217 i.e. the RADIUS AAA server is delegating its authentication function 218 to the cdma2000(R) 1X HLR/AC. 220 RADIUS AAA Server authentication (by the MN) is enabled by including 221 a random number (AAA_Authenticator) in the encrypted payload sent 222 from the MN to the RADIUS AAA Server. Only the possessor of the 223 proper RSA Private key will have the ability to decrypt the payload 224 and recover the unique AAA_Authenticator. If the MN receives the 225 correct AAA_Authenticator (returned by the RADIUS AAA Server), the MN 226 is assured that it is not interacting with a false Base Station (BS). 228 Dynamic MIP Key Update January 2004 230 MN BS/PDSN/FA HLR/AC AAA 231 -- ---------- ------ --- 232 ------------------ | | ------------------- 233 | RSA Public Key | | | | RSA Private Key | 234 | Pre-loaded by | | | | Pre-loaded by | 235 | Manufacturer | | | | Service Provider | 236 ------------------ | | ------------------- 237 | Global Challenge | | 238 |<-------------| | | 239 | | | | 240 | Auth_Response | | 241 |------------->| | | 242 | | Auth_Response | | 243 | |---------------->| | 244 | | ------------------ | 245 | | | IS-2000 | | 246 | | | Authentication | | 247 | | ------------------ | 248 | | Auth_Success | | 249 | |<----------------| | 250 | ------------------ | | 251 | | BS forwards | | | 252 | | Authenticated | | | 253 | | MSID to PDSN | | | 254 | ------------------ | | 255 | | | | 256 | Registration Request | | 257 | (MIP keys, AAA_Authenticator), | 258 | RSA Public Key | | 259 |------------->| | | 260 | | Access Request, MSID, | 261 | | (MIP keys, AAA_Authenticator), 262 | | RSA Public Key | 263 | |------------------------------->| 264 | | | ------------------- 265 | | | | Check MSID, | 266 | | | | Decrypt AAA_- | 267 | | | | Authenticator | 268 | | | ------------------- 269 | Access Reject, AAA_Authenticator | 270 | |<-------------------------------| 271 Registration Reply, AAA_Authenticator | 272 |<-------------| | | 273 ------------------ | | | 274 | Check AAA_- | | | | 275 | Authenticator | | | | 276 ------------------ | | | 277 Figure 2. Mutual Authentication 278 Dynamic MIP Key Update January 2004 280 2.3 Encrypted Password Authentication 282 Because cdma2000(R) A-key/SSD authentication is not available in 283 1xEV-DO or a particular cdma2000(R) 1X network may not support A-key 284 authentication, the DMU procedure also includes a random number 285 (MN_Authenticator) generated by the MN (and/or pre-loaded by the 286 manufacturer), which enables the RADIUS AAA Server to optionally 287 authenticate the MN (in 1XEV DO network only). 289 The MN_Authenticator is transmitted from the MN to the Home AAA 290 Server within the RSA-encrypted MIP_Key_Data payload to prevent 291 interception and possible re-use by an attacker. Ideally, the 292 MN_Authenticator is utilized as a One-Time Password, however, RSA 293 encryption allows the MN_Authenticator to possibly be re-used based 294 on each Service Provider's key distribution policy. 296 When the encrypted MIP keys are decrypted at the Home RADIUS AAA 297 Server, the MN_Authenticator is also decrypted and compared with a 298 copy of the MN_Authenticator stored within the Home RADIUS AAA 299 Server. The Home RADIUS AAA Server receives a copy of the 300 MN_Authenticator out-of-band (not using the cdma2000(R) network) 301 utilizing one of numerous possible methods outside the scope of the 302 standard. For example, the MN_Authenticator MAY be: 1) read out by a 303 Point-of-Sale provisioner from the MN, input into the subscriber 304 profile, and delivered along with the Network Access Identifier 305 (NAI), via the billing/provision system to the Home RADIUS AAA 306 server, 2) verbally communicated to a customer care representative 307 via a call, or 3) input by the user interfacing with an interactive 308 voice recognition server. The out-of-band MN_Authenticator delivery 309 is not specified in this document to maximize the Service Provider's 310 implementation flexibility. 312 It is possible for an unscrupulous provisioner or distribution 313 employee to extract the MN_Authenticator prior to the DMU procedure, 314 however the risk associated with such a disclosure is minimal. 315 Because the HRPD/1xEV-DO MN does not transmit a device identifier 316 during the initial registration process, an attacker, even with a 317 stolen MN_Authenticator, cannot correlate the password with a 318 particular MN device or NAI, which is typically provisioned just 319 prior to DMU procedure initiation. 321 The MN_Authenticator is typically generated by a random/pseudorandom 322 number generator within the MN. MN_Authenticator generation is 323 initiated by the MN user, however it may be initially pre-loaded by 324 the manufacturer. When the MN_Authenticator is reset (i.e. a new 325 MN_Authenticator is generated), all MIP_Data_Key payloads using the 326 previous MN_Authenticator are discarded and the MN immediately re- 327 encrypts a MIP_Key_Data payload containing the new MN_Authenticator. 328 The MN_Authenticator MUST NOT change unless it is explicitly reset by 329 Dynamic MIP Key Update January 2004 331 the MN user. Thus, the MN will generate new MIP_Key_Data payloads 332 using the same MN_Authenticator until the MN_Authenticator is 333 updated. 334 ------------------------- 335 | User-initiated | 336 | MN_Authenticator[x] | 337 | Generation | 338 ------------------------- 339 | 340 v 341 ----------------------------- ------------------------------ 342 | Manufacturer | | Delete MN_Authenticator[y], | 343 | MN_Authenticator[y] |----->| Store MN_Authenticator[x] | 344 | Generation** | | in MN | 345 ----------------------------- ------------------------------ 346 | 347 v 348 ------------------------- 349 | Delete MIP_Key_Data | 350 | Payloads based on | 351 | MN_Authenticator[y] | 352 ------------------------- 353 | 354 v 355 ----------------------------- ------------------------- 356 | KEYS_VALID state and | | Generate MIP_Key_Data | 357 | committed, delete |----->| Payloads based on | 358 | MIP_Key_Data Payload | | MN_Authenticator[x] | 359 ----------------------------- ------------------------- 360 ^ | 361 | v 362 ----------------------------- ------------------------- 363 | DMU MIP_Key_Data | | Store MIP_Key_Data | 364 | Delivery |<-----| Payload | 365 ----------------------------- ------------------------- 367 Figure 3. MN_Authenticator and MIP_Key_Data Payload State Machine 369 **Note: Manufacturer pre-load of MN_Authenticator is not essential 370 since the MN_Authenticator is typically generated by the MN. However, 371 manufacturer pre-load may reduce the provisioner burden of accessing 372 a device such as a modem to recover the MN_Authenticator for entry 373 into the Serivce Provider provisioning system. 375 3. Dynamic MIP Key Update Advantages over OTASP 377 The DMU procedure has numerous advantages over the current Over-the- 378 Air Service Provisioning (OTASP) [8] procedure including: 380 Dynamic MIP Key Update January 2004 382 * In DMU, MIP key distribution occurs directly between the MN and 383 AAA Server at the IP Layer. This eliminates the need for an 384 interface between the OTAF and RADIUS AAA server. 386 * DMU Supports MIP key distribution for cdma2000(R) 1X and 387 HRPD/1xEV-DO MN. OTASP only supports cdma2000(R) 1X MIP key 388 distribution. 390 * DMU facilitates MIP key distribution to an MN in a Relay-mode 391 MS. OTASP only delivers the MIP keys to the MS. For example, 392 OTASP cannot delivery MIP keys to a Laptop MN interfacing with 393 an MS modem. 395 * Pre-encryption of MIP_Key_Data allows the DMU procedure to be 396 an order of magnitude faster than Diffie-Hellman Key Exchange. 398 * In DMU, an MN manufacturer can pre-generate MIP keys, pre- 399 encrypt the MIP key payload, and pre-load the payload in the 400 MN. Thus, an MN with limited processing power is never 401 required to use RSA encryption. An OTASP device is always 402 forced to perform computationally expensive exponentiations 403 during the key update process. 405 * In DMU, the MN is protected against Denial-of-Service (DOS) 406 attacks in which a false BS changes the MIP key for MNs in its 407 vicinity. OTASP Diffie-Hellman Key Exchange is vulnerable to a 408 false BS DOS attack. 410 * DMU utilizes mutual authentication. OTASP Diffie-Hellman Key 411 Exchange does not utilize mutual authentication. 413 4. Detailed DMU Procedure Description and Requirements 415 The Verizon Wireless Dynamic Mobile IP Update procedure is a secure, 416 yet extremely efficient mechanism for distributing essential MIP 417 cryptographic keys (e.g. MN-AAAH key and MN-HA key) and the Simple IP 418 CHAP key. The DMU protocol enables pre-computation of the encrypted 419 key material payload, known as MIP_Key_Data. The DMU procedure 420 purposely avoids the use of Public Key Infrastructure (PKI) 421 Certificates, greatly enhancing the procedure's efficiency. 423 4.1 RSA Public Key Cryptography 425 RSA Public Key encryption and decryption MUST be performed in 426 accordance with RFC 2313 [9] PKCS #1: RSA Encryption Version 1.5. 427 DMU MUST support RSA with a 1024-bit modulus by default. DMU MAY 428 also support 768-bit or 2048-bit RSA depending on the MN user's 429 efficiency or security requirements. RSA computation speed-ups using 430 Dynamic MIP Key Update January 2004 432 a public RSA exponent which is small or has a small number of nonzero 433 bits (e.g. 65537) are acceptable. 435 4.2 Other Public Key Algorithms 437 DMU does not preclude the use of other Public key technologies. The 438 protocol includes a Public Key Type field that defines the type of 439 encryption used. 441 4.3 Why no Public Key Infrastructure (PKI)? 443 DMU is designed to maximize the efficiency of Mobile IP (MIP) key 444 distribution for cdma2000(R) MNs. The use of a Public key 445 Certificate would improve the flexibility of the MIP key update 446 process by allowing a Certificate Authority (CA) to vouch for the RSA 447 Public Key delivered to the MN. Unfortunately, the use of a Public 448 Key Certificate would significantly reduce the efficiency (speed and 449 overhead) of the MIP key update process. For instance, each MN must 450 be pre-loaded with the CA's Public Key. During the MIP key 451 distribution process, the network must first deliver its RSA Public 452 Key (in a Certificate) to the MN. The MN must then use RSA to 453 decrypt the Certificate's digital signature to verify that the 454 presented RSA public key is legitimate. Such a process significantly 455 increases the number of exchanges, increases air interface overhead, 456 increases the amount of MN computation, and slows the MIP key update 457 process. 459 Aside from the operational efficiency issues, there are numerous 460 policy and procedural issues that have previously hampered the 461 deployment of PKI in commercial networks. 463 On a more theoretical basis, PKI is likely unnecessary for this key 464 distribution model. PKI is ideal for a Many-to-Many communications 465 model such as within the Internet where many different users 466 interface with many different Websites. However, in the cellular/PCS 467 Packet Data environment, a Many-to-One (or few) distribution model 468 exists in which many users interface with one wireless Carrier to 469 establish their Mobile IP security associations (i.e cryptographic 470 keys). 472 4.4 Cryptographic Key Generation 474 The DMU procedure relies on each MN to randomly/pseudo-randomly 475 generate the MN_AAAH key, MN_HA key, and Simple IP CHAP key. Each MN 476 MUST have the capability to generate random/pseudo-random numbers in 477 accordance with the guidelines specified in RFC 1750 Randomness 478 Recommendations for Security. 480 Dynamic MIP Key Update January 2004 482 Although it may be more secure for the network to generate 483 cryptographic keys at the RADIUS AAA server, client cryptographic key 484 generation is acceptable due to the significant efficiency 485 improvement in the update process via pre-generation and pre- 486 encryption of the MIP keys. 488 4.5 MIP_Key_Data Payload 490 MIP cryptographic keys (MN_AAAH key and MN_HA key) and the Simple IP 491 CHAP key are encapsulated and encrypted into a MIP_Key_Data Payload 492 (along with the AAA_Authenticator and MN_Authenticator). The 493 MIP_Key_Data Payload is appended to the MN's MIP Registration Request 494 (RRQ) as a MIP Vendor/Organization-Specific Extension (VSE) (See IETF 495 RFC 3115 [10] Mobile IP Vendor/Organization-Specific Extensions). 496 When the PDSN converts the MIP RRQ to a RADIUS Access Request (ARQ) 497 message, the MIP_Key_Data Payload is converted from a MIP 498 Vendor/Organization-Specific Extension to a Vendor Specific RADIUS 499 Attribute (VSA). 501 Upon receipt of the RADIUS Access Request, the RADIUS AAA Server 502 decrypts the MIP_Key_Data payload using the RSA Private (decryption) 503 key associated with the RSA Public (encryption) used to encrypt the 504 MIP_Key_Data payload. The MIP_Key_Data is defined as follows: 506 MIP_Key_Data = RSA_Public_Key [MN_AAAH key, MN_HA key, CHAP_key, 507 MN_Authenticator, AAA_Authenticator], Public_Key_ID, DMUV 509 Where: 511 MN_AAAH key = 128-bit random MN / RADIUS AAA Server key 512 (encrypted) 514 MN_HA key = 128-bit random MN / Home Agent (HA) key (encrypted) 516 CHAP_key = 128-bit random Simple IP authentication key (encrypted) 517 Note: the Simple IP CHAP key is not the same as the AT-CHAP key 518 used for A12 Interface authentication [11]. 520 MN_Authenticator = 24-bit random number (displayed as an 8 decimal 521 digit number). (To be used for 1xEV-DO networks.) (encrypted) 523 AAA_Authenticator = 64-bit random number used by MN to 524 authenticate the RADIUS AAA Server. (encrypted) 526 DMU Version (DMUV) = 4 bit identifier of DMU version. 528 Public Key Identifier (Public_Key_ID) = PKOID, PKOI, PK_Expansion, 529 ATV 530 Dynamic MIP Key Update January 2004 532 Where: 534 Public Key Organization Identifier (PKOID) = 8-bit serial number 535 identifier of Public Key Organization (PKO) that created the 536 Public Key. 538 Public Key Organization Index (PKOI) = 8-bit serial number used at 539 PKO discretion to distinguish different Public/Private key 540 pairs. 542 PK_Expansion = 8-bit field to enable possible expansion of PKOID 543 or PKOI fields. (Note: Default value = 0xFF) 545 Algorithm Type and Version (ATV) = 4-bit identifier of the 546 algorithm used. 548 Note: If 1024-bit RSA is used, the encrypted portion of the payload 549 is 1024 bits (128 bytes) long. With the 28 bit Public Key Identifier 550 and 4 bit DMUV, the total MIP_Key_Data payload is 132 bytes long. 552 4.6 RSA Key Management 554 The wireless Service Provider or carrier MUST generate the RSA 555 Public/Private key pair(s). An organization within the Service 556 Provider MUST be designated by the Service Provider to generate, 557 manage, protect, and distribute RSA Private keys (to the RADIUS AAA 558 Server) and Public keys (to the MN manufacturers) in support of the 559 DMU procedure. 561 Each RSA Public/Private key pair, generated by the wireless carrier, 562 MUST be assigned a unique Public Key Identifier in accordance with 563 Section 9. 565 RSA Private keys MUST be protected from disclosure to unauthorized 566 parties. The Service Provider organization with the responsibility 567 of generating the RSA Public/Private key pairs MUST establish a RSA 568 key management policy to protect the RSA Private (decryption) keys. 570 RSA Public keys MAY be freely distributed to all MN manufacturers 571 (along with the Public Key Identifier). Because one RSA Public key 572 can be distributed to million of MNs, it is acceptable to distribute 573 the RSA Public key (and Public Key Identifier) to MN manufacturers 574 via e-mail, floppy disk, or a Website. The preferred method is to 575 simply publish the RSA Public key and associated Public Key 576 Identifier in the DMU Requirements document sent to each MN 577 manufacturer/OEM. 579 When public keys are distributed, the public keys MUST be protected 580 against alteration. If an invalid public key is programmed into a 581 Dynamic MIP Key Update January 2004 583 terminal, the terminal may be denied service because DMU cannot be 584 performed successfully. 586 RSA Private keys MAY be loaded into the RADIUS AAA server manually. 587 Access to the RADIUS AAA Server RSA Private keys MUST be restricted 588 to authorized personnel only. 590 The wireless Service Provider MAY accept RSA Private key(s) (and 591 Public Key Identifier) from MN manufacturers or other Service 592 Providers that have preloaded MNs with manufacturer-generated RSA 593 Public keys. One Service Provider MAY negotiate an agreement with 594 another Service Provider in which both Service Providers share and 595 protect each other's RSA Private keys. 597 4.7 RADIUS AAA Server 599 The RADIUS AAA Server used for DMU MUST support the DMU Procedure. 600 The AAA Server MUST support RSA Public key cryptography and maintain 601 a database of RSA Private (decryption) keys indexed by the Public Key 602 Identifier. 604 Delivery of the RSA Private key(s) to a AAA Server from the MN 605 manufacturer(s) is outside the scope of this documents. However, RSA 606 Private key(s) delivery via encrypted e-mail or physical (mail) 607 delivery is likely acceptable. 609 Access to the RADIUS AAA Server MUST be limited to authorized 610 personnel only. 612 The RADIUS AAA Server MUST support 1024-bit RSA decryption. 614 The RADIUS AAA Server MUST maintain a database of RSA Public/Private 615 key pair indexed by the Public Key Identifier. 617 The RADIUS AAA Server MUST support the RADIUS attributes specified in 618 Section 8. 620 The RADIUS AAA Server MUST support a subscriber specific MIP Update 621 State Field. When the MIP Update State Field set to UPDATE KEYS (1), 622 the RADIUS AAA Server MUST initiate the DMU procedure by including 623 the MIP_Key_Request attribute in an Access Reject message sent to the 624 PDSN. The MIP Update State Field MAY be set to UPDATE KEYS (1) by 625 Service Provider's Billing/Provisioning system based on IT policy. 626 Upon verification of MN-AAA Authentication Extension using decrypted 627 MN_AAA key, the RADIUS AAA Server MUST set the MIP Update State Field 628 to KEYS UPDATED (2). Upon verification of the MN-Authentication 629 Extension on a subsequent RRQ/ARQ, the RADIUS AAA Server MUST set the 630 MIP Update State Field to KEYS VALID (0). 632 Dynamic MIP Key Update January 2004 634 Note that the inclusion of a vendor-specific attribute in the Access 635 Reject message is not consistent with section 5.44 of [4]. A RADIUS 636 AAA server that supports DMU SHOULD NOT include a vendor-specific 637 attribute if the corresponding Access Request message was not 638 received from a DMU-compliant PDSN. 640 The RADIUS AAA Server MUST maintain a MIP Update State Field, for 641 each subscription, in one of three states (0 = KEYS VALID, 1 = UPDATE 642 KEYS, 2 = KEYS UPDATED). 644 The RADIUS AAA Server MUST decrypt the encrypted portion of the 645 MIP_Key_Data payload using the appropriate RSA Private (decryption) 646 key. 648 The RADIUS AAA Server MUST check the MN_AAA Authentication Extension 649 of the DMU RRQ using the decrypted MN_AAA key. 651 The RADIUS AAA Server MUST include the AAA_Authenticator in the 652 Access Accept as a Vendor-Specific RADIUS Attribute. 654 The RADIUS AAA Server MUST support the MN_Authenticator options 655 specified in Section 6.1. 657 The RADIUS AAA Server MUST comply with DMU Procedure failure 658 operation specified in Section 5. 660 The RADIUS AAA Server MUST support manual hexadecimal entry of MN_AAA 661 key, MN_HA key and Simple IP CHAP key via the AAA GUI for each 662 subscription. 664 The RADIUS AAA Server MUST provide a mechanism to validate the 665 MIN/IMSI. When the MIN/IMSI validation is on, the RADIUS AAA Server 666 MUST compare the MIN/IMSI sent from the PDSN with the MIN/IMSI in the 667 AAA subscription record/profile. If the MINs or IMSIs do not match, 668 the RADIUS AAA Server MUST send an Access Reject to the PDSN/FA. The 669 Access Reject MUST NOT contain a MIP Key Data request 671 When the "Ignore MN_Authenticator" bit is not set, the RADIUS AAA 672 Server MUST check whether MN_AuthenticatorMN = MN_AuthenticatorAAA. 673 If the MN_Authenticators do not match, the RADIUS AAA Server MUST 674 send an Access Reject to the PDSN/FA. The Access Reject MUST NOT 675 contain a MIP_Key_Data request. 677 The RADIUS AAA Server MUST include its PKOID (or another designated 678 PKOID) in the MIP_Key_Request RADIUS Attribute. 680 The RADIUS AAA Server MUST compare the PKOID sent in the MIP_Key_Data 681 RADIUS Attribute with a list of valid PKOIDs in the RADIUS AAA 682 Server. If the PKOID is not valid, the RADIUS AAA Server MUST send 683 Dynamic MIP Key Update January 2004 685 an Access Reject to the PDSN with the "Invalid Public Key" Verizon 686 Wireless RADIUS Vendor Specific Attribute (VSA). Note: the same 687 RADIUS attribute may be assigned a different Vendor identifier. 689 Note that the inclusion of a vendor-specific attribute in the Access 690 Reject message is not consistent with section 5.44 of [4]. A RADIUS 691 AAA server that supports DMU SHOULD NOT include a vendor-specific 692 attribute if the corresponding Access Request message was not 693 received from a DMU-compliant PDSN. 695 The RADIUS AAA Server MUST support delivery of the MN-HA key using 696 3GPP2 RADIUS VSAs as specified in 3GPP2 X.S0011-005-C. The 3GPP2 VSAs 697 used are the MN-HA Shared Key (Vendor-Type = 58) and MN-HA SPI 698 (Vendor-Type = 57). 700 The RADIUS AAA Server SHOULD always accept an Access Request from a 701 CDMA2000(R) Access Node (AN) for a particular subscriber when the 702 UPDATE KEYS (1) and KEYS UPDATED (2) states are set. In the KEYS 703 VALID (0) state, the RADIUS AAA Server MUST check the Access Request 704 normally. 706 The RADIUS AAA Server MUST reject an Access Request with the 707 MIP_Key_Data RADIUS Attribute while the RADIUS AAA Server is in the 708 KEYS VALID state, i.e., the AAA MUST NOT allow an unsolicited key 709 update to occur. 711 4.8 MN (Handset or Modem) 713 The MN manufacturer MUST pre-load the Wireless Carrier RSA Public key 714 (and Public Key Identifier). 716 The MN manufacturer MUST pre-generate and pre-load the 717 MN_Authenticator. 719 The MN MUST support 1024-bit RSA Encryption using the pre-loaded RSA 720 Public key. 722 The MN MUST support MN_AAA, MN_HA, and CHAP random/pseudo-random key 723 generation (in accordance with RFC 1750). 725 The MN MUST support random/pseudo-random AAA_Authenticator and 726 MN_Authenticator generation (in accordance with RFC 1750). 728 Upon power-up of an MN handset or launch of the MN client, the MN 729 MUST check whether a MIP_Key_Data payload has been computed. If no 730 MIP_Key_Data payload exists, the MN MUST generate and store a 731 MIP_Key_Data payload. The MN MUST maintain at least one pre- 732 generated MIP_Key_Data payload. 734 Dynamic MIP Key Update January 2004 736 The MN MUST construct the MIP_Key_Data payload in accordance with 737 Section 4.5. 739 The MN MUST initiate the DMU Procedure upon receipt of a MIP 740 Registration Reply (RRP) with the MIP_Key_Request Verizon Wireless 741 Vendor/Organization-specific Extension (VSE). 743 Upon receipt of an RRP including the MIP_Key_Request, the MN MUST 744 check the PKOID sent in the MIP_Key_Request. If the MN has a Public 745 key associated with the PKOID, the MN MUST encrypt the MIP_Key_Data 746 payload using that Public key. 748 The MN MUST have the capability to designate one Public key as the 749 Default Public key if the MN supports multiple Public keys. 751 The MN MUST insert the Verizon Wireless MIP_Key_Data VSE (or another 752 Organization-specific MIP_Key_Data VSE) after the Mobile-Home 753 Authentication Extension, but before the MN-AAA Authentication 754 Extension. The MIP_Key_Data Extension must also be located after the 755 FA Challenge Extension if present. 757 Note: The order of the extensions is important for interoperability. 758 After the FA receives the Access Accept from the RADIUS AAA server, 759 the FA may strip away all MIP extensions after the Mobile-Home 760 Authenticator and, if this occurs, it is not necessary for the HA to 761 process the DMU extensions. Other compatibility problems have also 762 been identified during testing with FAs from various vendors who 763 place extensions in various locations. Explicit placement of the 764 extensions eliminates these issues. 766 Upon initiation of the DMU Procedure, the MN MUST compute the MIP 767 authentication extensions using the newly-generated temporary MN_AAA 768 and MN_HA keys. Upon receipt of the AAA_Authenticator MIP Extension, 769 the MN MUST compare the AAA_AuthenticatorMN (sent in the encrypted 770 MIP_Key_Data payload) with the AAA_AuthenticatorAAA (returned by the 771 RADIUS AAA Server). If both values are the same, the MN MUST 772 designate the temporary MN_AAA, MN_HA key, and the Simple IP CHAP key 773 as permanent. The MN MUST set its MIP Update State field to KEYS 774 VALID. 776 The MN MUST support reset (re-generation) of the MN_Authenticator by 777 the MN user as specified in Section 6.2. 779 The MN MUST enable the MN user to view the MN_Authenticator. 780 MN_Authenticator (24-bit random number) MUST be displayed as an 8 781 decimal digit number as specified in Section 6.2. 783 The MN manufacturer MUST pre-load each MN with a unique random 24-bit 784 MN_Authenticator. 786 Dynamic MIP Key Update January 2004 788 Upon reset of the MN_Authenticator, the MN MUST delete all 789 MIP_Key_Data payloads based on the old MN_Authenticator and generate 790 all subsequent MIP_Key_Data payloads using the new MN_Authenticator. 791 (until the MN_Authenticator is explicitly re-set again by the MN 792 user). 794 The MN MUST support manual entry of all cryptographic keys such as 795 the MN_AAA, MN_HA, and Simple IP CHAP key. MN MUST support 796 hexadecimal digit entry of a 128-bit key. (Note: certain Simple IP 797 devices only enable ASCII entry of a password as the CHAP key. It is 798 acceptable for future devices to provide both capabilities, i.e. 799 ASCII for a password or hexadecimal for a key. The authors recommend 800 the use of strong cryptographic keys.) 802 The MN MUST support the Verizon Wireless MIP Vendor/Organization- 803 Specific Extensions specified in Section 9. 805 The MN MUST update the RRQ Identification field when re-transmitting 806 the same MIP_Key_Data in a new RRQ. 808 The MN MUST comply with the DMU Procedure failure operation specified 809 in Section 5. 811 The RSA Public Key MAY be stored in the MN flash memory as a constant 812 while being updatable via software patch. 814 4.9 PDSN / Foreign Agent (FA) 816 The PDSN MUST support the Verizon Wireless RADIUS Vendor Specific 817 Attributes (VSA) specified in Section 8 and the Verizon Wireless MIP 818 Vendor/Organization-Specific Extensions (VSE) specified in Section 9. 820 The PDSN MAY support the RADIUS VSAs specified in Section 8 and the 821 MIP VSEs specified in Section 9 using another Organization 822 identifier. 824 Upon receipt of an Access Reject containing the 825 MIP_Key_Update_Request VSA, PDSN MUST send an RRP to the MN with the 826 MIP_Key_Request VSE. The PDSN MUST use the RRP error code = 89 827 (Vendor Specific) and MUST not tear down the PPP session after 828 transmission. 830 Upon receipt of an Access Reject containing the AAA_Authenticator 831 VSA, the PDSN MUST send an RRP with the AAA_Authenticator MIP VSE. 832 The PDSN MUST use the RRP error code = 89 (Vendor Specific) and MUST 833 NOT tear down the PPP session after transmission. 835 Dynamic MIP Key Update January 2004 837 Upon receipt of an Access Reject containing the Public Key Invalid 838 VSA, the PDSN MUST send an RRP with the Public Key Invalid MIP VSE. 839 The PDSN MUST use the RRP error code = 89 (Vendor Specific) and MUST 840 NOT tear down the PPP session after transmission. 842 Note that the inclusion of a vendor-specific attribute in the Access 843 Reject message is not consistent with section 5.44 of [4]. A PDSN 844 that supports DMU MUST accept an Access Reject message containing a 845 vendor-specific attribute. 847 Upon receipt of an RRQ with the MIP_Key_Data VSE, the PDSN MUST 848 convert the RRQ to an ARQ with the MIP_Key_Data VSA. The PDSN MUST 849 send the ARQ to the RADIUS AAA server. 851 The PDSN/FA MUST comply with the DMU Procedure failure operation 852 specified in Section 5. 854 The PDSN/FA MUST include the PKOID from the Access Reject 855 MIP_Key_Update_Request VSA in the MIP_Key_Request MIP VSE sent to the 856 MN. 858 4.10 Home Agent (HA) 860 The HA MUST support the Verizon Wireless MIP Vendor/Organization- 861 Specific Extensions (VSE) specified in Section 9. (Note: the HA may 862 not encounter a DMU MIP extension if the FA strips away all 863 extensions after the Mobile-Home authentication extension.) 865 The HA MAY support the MIP VSEs specified in Section 9 using another 866 Organization identifier. (Note: the HA may not encounter a DMU MIP 867 extension if the FA strips away all extensions after the Mobile-Home 868 authentication extension.) 870 The HA MUST support delivery of the MN-HA key from the Home RADIUS 871 AAA server using 3GPP2 RADIUS Vendor-Specific Attributes (VSA) as 872 specified in 3GPP2 X.S0011-005-C. The 3GPP2 VSAs used are the MN-HA 873 Shared Key (Vendor-Type = 58) and the MN-HA SPI (Vendor-Type = 57). 875 Dynamic MIP Key Update January 2004 877 4.11 DMU Procedure Network Flow 879 This section provides a flow diagram and detailed description of the 880 process flow involving the Dynamic Mobile IP Update procedure process 881 within the IS-2000 network. 883 MN PDSN/FA AAAH 884 -- ------- ---- 885 --------------------- | ------------------- 886 | 1: RSA Public Key | | | RSA Private Key | 887 | Pre-loaded by | | | Pre-loaded by | 888 | Manufacturer | | | Service Provider | 889 --------------------- | ------------------- 890 --------------------------------------------------------- 891 | 2: MS/BS: IS-2000 Call Origination and Authentication | 892 | 3: MN/PDSN/FA: PPP Session Establishment | 893 --------------------------------------------------------- 894 | 4: Registration Request (RRQ) | | 895 |--------------------------------->| 5: Access Request w/MSID 896 | |------------>| 897 | | -------------------- 898 | | | 6: MIP Update State| 899 | | | is UPDATE KEYS | 900 | | -------------------- 901 | 7: Access Reject with | 902 | MIP_Key_Update_Request | 903 | RADIUS Attribute | 904 | |<------------| 905 | 8: Registration Reply (RRP) | | 906 | with MIP_Key_Request MIP | | 907 | Vendor/organization-specific | | 908 | extension | | 909 |<---------------------------------| | 910 ------------------- | | 911 | 9: MN generates | | | 912 | MIP_Key_Data | | | 913 | using temporary | | | 914 | MIP keys | | | 915 ------------------- | | 916 | 10: RRQ with MIP_Key_Data | | 917 | Vendor/organization-specific extension | 918 |--------------------------------->| 11: Access Request 919 | | w/MSID 920 | | and MIP_Key_Data 921 | | RADIUS attribute 922 | |------------>| 924 Figure 4. DMU Procedure Flow (part 1) 925 Dynamic MIP Key Update January 2004 927 MN PDSN/FA AAAH 928 -- ------- ---- 929 | | | 930 | | ------------------- 931 | | | 12: decrypt | 932 | | | MIP_Key_Data, | 933 | | | verify MN-AAA | 934 | | | authentication | 935 | | | extension, set | 936 | | | MIP Update State | 937 | | | = KEYS UPDATED | 938 | | ------------------- 939 | 13: Access Reject with | 940 | AAA_Authenticator | 941 | RADIUS Attribute | 942 | |<------------| 943 | 14: Registration Reply (RRP) | | 944 | with AAA_Authenticator MIP | | 945 | Vendor/organization-specific | | 946 | extension | | 947 |<---------------------------------| | 948 ---------------------- | | 949 | 15: verify | | | 950 | AAA_Authenticator, | | | 951 | store temporary | | | 952 | MIP keys as | | | 953 | permanent keys | | | 954 ---------------------- | | 955 | 16: RRQ | | 956 |--------------------------------->| Access Request 957 | | w/MSID 958 | |------------>| 959 | | -------------------- 960 | | | 17: verify MN-AAA | 961 | | | authentication | 962 | | | extension, set | 963 | | | MIP Update State | 964 | | | = KEYS VALID | 965 | | -------------------- 966 | Access Accept | 967 | |<------------| 969 Figure 4. DMU Procedure Flow (part 2) 970 Dynamic MIP Key Update January 2004 972 MN PDSN/FA AAAH HA 973 -- ------- ---- -- 974 | | | | 975 | | 18. Registration Request (RRQ) | 976 | |-------------------------------->| 977 | | 19: Access Request | 978 | | |<-----------------| 979 | | | Access Accept | 980 | | | with MN-HA key | 981 | | |----------------->| 982 | | | ------------------- 983 | | | | verify | 984 | | | | mobile-home | 985 | | | | authentication | 986 | | | | extension | 987 | | | ------------------- 988 | | 20. Registration Reply (RRP) | 989 | |<--------------------------------| 990 | RRP | | | 991 |<--------------| | | 993 Figure 4. DMU Procedure Flow (part 3) 995 Each step in the Figure 4 DMU Process is described as follows: 997 1. Each RSA Public/Private Key pair MUST be generated in 998 accordance with RFC 2313. Each Public/Private key pair MUST be 999 assigned a unique Public Key Identifier (PKOID) by its creator. 1001 If the Service Provider does not generate the Public/Private 1002 Key pair and deliver the RSA Public Key to the MN manufacturer 1003 for pre-installation in the MN, the MN manufacturer MUST 1004 generate the RSA Public/Private Key pair (using a 1024-bit 1005 modulus) and pre-load all MNs with the RSA Public (encryption) 1006 key. The MN manufacturer MUST distribute the RSA Private 1007 (decryption) key, in a secure manner, to the appropriate 1008 service provider(s). It is acceptable for the MN manufacturer 1009 to distribute the same Private (decryption) key to multiple 1010 service providers. 1012 2. Assuming that the cdma2000(R) 1X MN has been provisioned with 1013 an A-key and SSD, the cdma2000(R) 1X MS initiates a call 1014 origination and authenticates itself to the IS-2000 network. 1015 Upon IS-2000 authentication success, the BS sends the 1016 "authenticated" MSID (e.g. MIN) to the PDSN. 1018 3. The MN and PDSN establish a PPP session. 1020 4. The MN sends a MIP Registration Request (RRQ) to the PDSN. 1022 Dynamic MIP Key Update January 2004 1024 5. The PDSN converts the MIP RRQ into a RADIUS Access Request 1025 (ARQ) message, includes the MSID in the ARQ, and forwards the 1026 ARQ to the Home RADIUS AAA server. 1028 6. The RADIUS AAA Server compares the authenticated MSID (sent 1029 from the PDSN) with the MSID in its subscriber database 1030 (associated with the NAI). If the AAA MIP Update State Field 1031 is set to UPDATE KEYS (1), the RADIUS AAA Server rejects Packet 1032 Data access and orders a MIP key update. 1034 7. The RADIUS AAA Server sends an Access Reject (code = 3) message 1035 to the PDSN with the MIP_Key_Update_Request RADIUS VSA. 1037 8. The PDSN converts the Access Reject to a MIP Registration Reply 1038 (RRP) with a MIP_Key_Request MIP VSE and sends the RRP to the 1039 MN. RRP Code = 89 (Vendor Specific). 1041 9. The MN sets the MN MIP Update State = UPDATE KEYS. If the MN 1042 has no pre-generated and pre-encrypted the MIP_Key_Data 1043 payload, the MN MUST generate the MN_AAA key, MN_HA key, Chap 1044 key, MN_Authenticator, and AAA_Authenticator in accordance with 1045 RFC 1750. Except for the Public Key Identifier, all generated 1046 values MUST be encrypted using the pre-loaded RSA Public 1047 (encryption) key. The newly generated MN_AAATEMP Key and 1048 MN_HATEMP MUST be used to calculate the MN-AAA and Mobile-Home 1049 Authentication Extensions for the current RRQ. Note: the MN 1050 MAY pre-compute the MIP_Key_Data payload by checking whether a 1051 payload exists during each MN power-up or application 1052 initiation. 1054 10. The MN sends the RRQ with MIP_Key_Data MIP VSE to the PDSN. 1056 11. The PDSN converts the RRQ to a RADIUS ARQ with MIP_Key_Data 1057 RADIUS VSA and forwards the ARQ to the home RADIUS AAA Server. 1058 The MSID is included in the ARQ. 1060 12. The RADIUS AAA Server compares the authenticated MSID (sent 1061 from the PDSN) with the MSID in its subscriber database 1062 (associated with the NAI). If MSIDPDSN = MSIDAAA, the RADIUS 1063 AAA server, using the Public Key Identifier, determines the 1064 appropriate RSA Private key and decrypts the encrypted portion 1065 of the MIP_Key_Data payload. The RADIUS AAA Server verifies 1066 the MN-AAA Authentication Extension Authenticator using the 1067 decrypted MN_AAA key. If successful, the RADIUS AAA Server 1068 updates the subscriber profile with the decrypted MN_AAA key, 1069 MN_HA key, and CHAP key. The RADIUS AAA Server sets the AAA 1070 MIP Update State Field to KEYS UPDATED (2). 1072 Dynamic MIP Key Update January 2004 1074 13. The RADIUS AAA Server sends an Access Reject with 1075 AAA_Authenticator RADIUS VSA to the PDSN. 1077 14. The PDSN converts the Access Reject to a MIP RRP with 1078 AAA_Authenticator MIP VSE. RRP Code = 89 (Vendor Specific). 1080 15. If AAA_AuthenticatorMN = AAA_AuthenticatorAAA, the MN assigns 1081 MN_AAATEMP to MN_AAA key and MN_HATEMP to MN_HA key (MN MIP 1082 Update State = KEYS VALID). Otherwise, the MN discards the 1083 temporary keys. 1085 16. The MN initiates a new RRQ which is converted to an ARQ by the 1086 PDSN and forwarded to the RADIUS AAA Server. 1088 17. The RADIUS AAA Server verifies the MN-AAA Authentication 1089 Extension and sets the AAA MIP Update State Field to KEYS VALID 1090 (0). The RADIUS AAA Server sends an Access Accept to the 1091 PDSN/FA. 1093 18. The PDSN/FA sends the RRQ to the Home Agent (HA). 1095 19. The HA sends an Access Request to the RADIUS AAA Server. The 1096 RADIUS AAA Server sends an Access Accept to the HA with the 1097 MN_HA key. The HA verifies the Mobile-Home Authentication 1098 Extension using the MN_HA key. 1100 20. The HA sends an RRP to the PDSN/FA which forwards the RRP to 1101 the MN. RRP Code = 0 (Success). 1103 5. DMU Procedure Failure Operation 1105 To improve the robustness of the DMU Procedure to account for 1106 interruptions due to UDP message loss, RRQ retransmission, or MN 1107 failure, the RADIUS AAA Server MUST maintain a MIP Update State 1108 Field, for each subscription, in one of three states (0 = KEYS VALID, 1109 1 = UPDATE KEYS, 2 = KEYS UPDATED). 1111 Dynamic MIP Key Update January 2004 1113 MN PDSN/FA AAAH HA 1114 -- ------- ---- -- 1115 ---------------- | ---------------- | 1116 | MN state = | | | AAAH state = | | 1117 | KEYS VALID | | | UPDATE KEYS | | 1118 ---------------- | ---------------- | 1119 | (A) RRQ | | | 1120 |-------------->| ARQ | | 1121 | |------------->| | 1122 | AR(Key_Update) | | 1123 (B) RRP (Key_Update) |<-------------| | 1124 |<--------------| | | 1125 ---------------- | | | 1126 | MN state = | | | | 1127 | UPDATE KEYS | | | | 1128 ---------------- | | | 1129 | (C) RRQ (MIP_Key_Data) | | 1130 |-------------->| ARQ (MIP_Key_Data) | 1131 | |------------->| | 1132 | | ---------------- | 1133 | | | AAAH state = | | 1134 | | | KEYS UPDATED | | 1135 | | ---------------- | 1136 | AR (AAA_Auth) | | 1137 (D) RRP (AAA_Auth) |<-------------| | 1138 |<--------------| | | 1139 ---------------- | | | 1140 | MN state = | | | | 1141 | KEYS VALID | | | | 1142 ---------------- | | | 1143 | RRQ | | | 1144 |-------------->| ARQ | | 1145 | |------------->| | 1146 | | ---------------- | 1147 | | | AAAH state = | | 1148 | | | KEYS VALID | | 1149 | | ---------------- | 1150 | | AA | | 1151 | |<-------------| RRQ | 1152 | |------------------------------->| 1153 | | | ARQ | 1154 | | |<----------------| 1155 | | | AA | 1156 | | |---------------->| 1157 | | | RRP | 1158 | | RRP |<----------------| 1159 |<-----------------------------| | 1161 Figure 5. DMU Failure Call Flow with MN and AAA States 1162 Dynamic MIP Key Update January 2004 1164 Each step in Figure 5 is described as follows: 1166 1. If (A) is lost, the MN retransmits (A). The RADIUS AAA server 1167 expects (A). If the AAA server is in the UPDATE KEYS state, 1168 the RADIUS AAA Server sends AR with MIP_Key_Update_Request VSA 1169 and the PDSN/FA sends (B). 1171 2. If (B) is lost, the MN retransmits (A). The RADIUS AAA server 1172 expects (C). If it receives (A), the RADIUS AAA Server sends 1173 AR with MIP_Key_Update_Request VSA and the PDSN/FA retransmits 1174 (B). 1176 3. If (C) is lost, the mobile retransmits (C). The RADIUS AAA 1177 server expects (C) and updates the MIP keys appropriately. The 1178 RADIUS AAA server transitions to KEYS UPDATED and commits the 1179 MIP_Key_Data. The RADIUS AAA Server sends the AR with 1180 AAA_Authenticator VSA and the PDSN/FA replies to the MN with 1181 (D). 1183 4. If (D) is lost, the mobile retransmits (C) using the same key 1184 data sent previously. The RADIUS AAA server expects (A) using 1185 the same keys. 1187 a. If the RADIUS AAA server receives (C) with the same keys it 1188 received previously, it retransmits the AR with 1189 AAA_Authenticator VSA and the PDSN replies with (D), 1190 containing the AAA_Authenticator. 1192 b. If the RADIUS AAA server receives (C) with different keys 1193 than it received previously, the RADIUS AAA Server sends AR 1194 with MIP_Key_Update_Request VSA, the PDSN/FA retransmits 1195 (B), and the RADIUS AAA server transitions to UPDATE KEYS. 1197 c. If the RADIUS AAA server receives (A) which fails 1198 authentication using the keys sent in (C), the RADIUS AAA 1199 Server sends AR with MIP_Key_Update_Request, the PDSN/FA 1200 retransmits (B), and the RADIUS AAA server transitions to 1201 UPDATE KEYS. 1203 5. Once the PDSN/FA receives (A), forwards the ARQ to the RADIUS 1204 AAA server, and the MN-AAA Authenticator is verified using the 1205 MN_AAA key, the RADIUS AAA Server transitions to the KEYS VALID 1206 state and the DMU process is complete. 1208 The AAA DMU state machine is described in Figure 6. 1210 Dynamic MIP Key Update January 2004 1212 -------------- 1213 --------------------->| KEYS VALID |--------------- 1214 | Auth success using -------------- Need Key | 1215 | MIP_Key_Data Update | 1216 | | 1217 | Auth failed (invalid keys) | 1218 | or RRQ with different MIP_Key_Data | 1219 | --------------------------------- | 1220 | | | | 1221 | | v v 1222 ---------------- --------------- 1223 | KEYS UPDATED | | UPDATE KEYS | 1224 ---------------- --------------- 1225 | ^ ^ | 1226 | | | | 1227 ------- --------------------------------- 1228 RRQ with same Got MIP_Key_Data 1229 MIP_Key_Data 1231 Figure 6. RADIUS AAA Server DMU State Machine 1233 6. cdma2000(R) HRPD/1xEV-DO Support 1235 Because the DMU Procedure occurs at the IP Layer, the DMU Procedure 1236 supports MIP key distribution in either the cdma2000(R) 1X or 1237 HRPD/1xEV-DO network. Because the cdma2000(R) HRPD/1xEV-DO network 1238 does not provide Radio Access Network (RAN) authentication, the DMU 1239 Procedure is more susceptible to a false MN attack (than in an 1240 cdma2000(R) 1X network with CAVE RAN authentication). For this 1241 reason, the DMU Procedure has the capability to optionally support 1242 device-to-network authentication using the MN_Authenticator. 1244 The method of MN_Authenticator delivery to the RADIUS AAA server is 1245 outside the scope of this document, allowing Service Providers the 1246 flexibility to determine the most efficient/least intrusive procedure 1247 to support MN authentication during the DMU Procedure. 1249 6.1 RADIUS AAA Support 1251 The RADIUS AAA server MUST support three MN_Authenticator options: 1253 1. Ignore MN_Authenticator 1255 Depending on other potential authentication/fraud prevention 1256 options (outside the scope of the DMU Procedure), the RADIUS AAA 1257 Server MUST have the capability to ignore the MN_Authenticator. 1258 For example, when the RADIUS AAA Server decrypts the MIP_Key_Data 1259 payload, the AAA Server silently discards the MN_Authenticator. 1261 Dynamic MIP Key Update January 2004 1263 2. Pre-Update Validation 1265 Prior to updating a subscription profile with the delivered MIP 1266 keys, the RADIUS AAA Server MUST compare the MN_AuthenticatorMN 1267 (delivered via the encrypted MIP_Key_Data payload) with the 1268 MN_AuthenticatorAAA (possibly delivered via the Service Provider 1269 customer care or billing/provisioning system). 1271 3. Post-Update Validation 1273 After the DMU Procedure is complete, the RADIUS AAA Server stores 1274 the delivered MN_AuthenticatorMN and waits for delivery of the 1275 MN_AuthenticatorAAA (via Customer Care, IVR, or some other 1276 unspecified process). Once the MN_Authenticator is delivered to 1277 the RADIUS AAA Server, the AAA MUST compare the MN_AuthenticatorMN 1278 (delivered via the encrypted MIP_Key_Data payload) with the 1279 MN_AuthenticatorAAA. If the Authenticators match, the RADIUS AAA 1280 Server authorizes access and final update of the MIP keys. 1282 6.2 MN Support 1284 The Mobile Node (MN) MUST store the 24-bit MN_Authenticator. 1286 The MN MUST display the MN_Authenticator as an 8 decimal digit number 1287 (via LCD display on a handset or via a GUI for a modem). If the MN 1288 resides within a handset, the user MAY display the MN_Authenticator 1289 using the following keypad sequence: "FCN + * + * + M + I + P + 1290 RCL". Otherwise, the MN MUST display the MN_Authenticator via the 1291 device's GUI. 1293 The MN MUST have the capability to reset the MN_Authenticator. In 1294 other words, the MN MUST have the capability to randomly/pseudo- 1295 randomly generate a new 24-bit MN_Authenticator in according with RFC 1296 1750 upon user command. The reset feature mitigates possible 1297 compromise of the MN_Authenticator during shipment/storage. If the 1298 MN resides within a handset, the user MAY reset the MN_Authenticator 1299 using the following keypad sequence: "FCN + * + * + M + I + P + C + 1300 C + RCL". Otherwise, the MN MUST reset the MN_Authenticator via the 1301 device's GUI. 1303 The MN manufacturer MAY pre-load the MN with the MN_Authenticator. 1304 For example, by pre-loading the MN_Authenticator and affixing a 1305 sticker with the MN_Authenticator (8 decimal digit representation) to 1306 the MN (e.g. modem), the point-of-sale representative does not have 1307 to retrieve the MN_Authenticator from the MN interface. 1309 [Optional] The MN MAY maintain a separate primary and secondary queue 1310 of MN_Authenticator/MIP_Key_Data Payload pairs. When the MN user 1311 resets the primary MN_Authenticator, the MN discards the primary 1312 Dynamic MIP Key Update January 2004 1314 MN_Authenticator (and any associated MIP_Key_Data Payload) and 1315 assigns the MN_Authenticator in the secondary queue as the primary 1316 MN_Authenticator (and assigns any associated MIP_Key_Data Payloads to 1317 the primary queue). This feature enables the user/provisioner to 1318 reset the MN_Authenticator and immediately initiate the DMU procedure 1319 without losing the MIP_Key_Data Payload pre-encryption advantage. 1320 Upon MN_Authenticator transfer from the secondary to primary queue, 1321 the MN MUST generate a new MN_Authenticator and associated 1322 MIP_Key_Data Payload for the secondary queue. The MN MUST check both 1323 the primary and secondary MN_Authenticator/MIP_Key_Data Payload 1324 queues upon power-up or application initiation. The MN MUST maintain 1325 at least one MN_Authenticator/MIP_Key_Data Payload pair in each 1326 queue. 1328 6.3 Informative: MN_Authenticator Support 1330 MN authentication using the MN_Authenticator gives the service 1331 provider the maximum flexibility in determining how to deliver the 1332 MN_Authenticator to the RADIUS AAA Server. The method of 1333 MN_Authenticator delivery is outside the scope of this document. 1335 However, to provide some context to how the MN_Authenticator may 1336 support MN authentication/fraud prevention in the HRPD/1xEV-DO 1337 environment, we describe the following possible provisioning 1338 scenario. 1340 When a subscriber initially acquires their HRPD/1xEV-DO device and 1341 service, the point-of-sale representative records the subscription 1342 information into the billing/provision system via a computer terminal 1343 at the point-of-sale. The billing/provisioning system delivers 1344 certain information to the RADIUS AAA Server (e.g. NAI, MSID, ESN) 1345 including the MN_Authenticator which the point-of-sale representative 1346 retrieves via the MN device's display. In the case of a modem, the 1347 manufacturer may have pre-loaded the MN_Authenticator and placed a 1348 copy of the MN_Authenticator on a sticker attached to the modem. The 1349 point-of-sale representative simply copies the 8 decimal digit value 1350 of the MN_Authenticator into the customer profile. Once the MN is 1351 loaded with the proper NAI and powered-up, the MN initiates the DMU 1352 Procedure with the RADIUS AAA Server. The RADIUS AAA Server compares 1353 the MN-delivered MN_Authenticator with the billing system delivered 1354 MN_Authenticator. If the authenticators match, the RADIUS AAA Server 1355 updates the subscriber profile with the delivered MIP keys and 1356 authorizes service. If the Post-Update option is enabled within the 1357 RADIUS AAA Server, the RADIUS AAA Server tentatively updates the 1358 subscription profile until it receives the MN_Authenticator via the 1359 billing/provision system. 1361 As another option, the Service Provider MAY use an IVR system in 1362 which the HRPD/1xEV-DO subscriber calls a provisioning number and 1363 Dynamic MIP Key Update January 2004 1365 inputs the MN_Authenticator. The IVR system then delivers the 1366 MN_Authenticator to the RADIUS AAA Server for final validation and 1367 Packet Data Access. 1369 7. Security Considerations 1371 The DMU Procedure is designed to maximize the efficiency of MIP key 1372 distribution while providing adequate key distribution security. The 1373 following provides a description of potential security 1374 vulnerabilities and their relative risk to the DMU Procedure: 1376 7.1 Cryptographic Key Generation by the MN 1378 Because the MN is required to properly generate the MN_AAA, MN_HA, 1379 and CHAP key, the MN must perform cryptographic key generation in 1380 accordance with accepted random/pseudo-random number generation 1381 procedures. MN manufacturers MUST comply with RFC 1750 [12] 1382 guidelines and Service Providers SHOULD ensure that manufacturers 1383 implement acceptable key generation procedures. The use of 1384 predictable cryptographic keys could be devastating to MIP security. 1385 However, the risk of not using acceptable random/pseudo-random key 1386 generation is minimal as long as MN manufacturers adhere to RFC 1750 1387 guidelines. Furthermore, if a key generation flaw is identified, the 1388 flaw appears readily correctable via a software patch, minimizing the 1389 impact. 1391 7.2 Man-in-the-Middle Attack 1393 The DMU procedure is susceptible to a Man-in-the-Middle (MITM) 1394 attack, however such an attack appears relatively complex and 1395 expensive. When AKA is deployed within cdma2000(R) 1X, the MITM 1396 Attack will be eliminated. The risk of an MITM Attack is minimal due 1397 to required expertise, attack expense, and impending cdma2000(R) 1X 1398 mutual authentication protection. If a particular cdma2000(R) 1X 1399 network does not support A-key authentication, the MN_Authenticator 1400 MAY optionally be used. 1402 7.3 RSA Private Key Compromise 1404 Because one RSA Private key may be associated with millions of MNs 1405 (RSA Public Key), it is important to protect the RSA Private key from 1406 disclosure to unauthorized parties. Each MN manufacturer MUST 1407 establish adequate security procedures/policies regarding the 1408 dissemination of the RSA Private key. RSA Private keys SHOULD be 1409 distributed to legitimate cdma2000(R) service providers only. It is 1410 acceptable for a MN manufacturer to distribute the same RSA Private 1411 key to multiple service providers to enable MIP key update. However, 1412 each service provider MAY generate their own RSA Public/Private key 1413 pair and require the MN manufacturer to include their own RSA Public 1414 Dynamic MIP Key Update January 2004 1416 key in a specific software patch if compromise of the RSA Private key 1417 is a significant concern. 1419 7.4 RSA Encryption 1421 Several vulnerabilities have been identified in certain 1422 implementations of RSA, however they do not appear applicable to the 1423 DMU Procedure. 1425 7.5 False Base Station/PDSN 1427 The MN appears to be protected against a False BS denial-of-service 1428 (DOS) attack, since only the proper RADIUS AAA server can recover the 1429 AAA_Authenticator. This method of preventing a false base station 1430 attack assumes security of the network messaging between the AAA and 1431 the serving system, as discussed in 7.9. 1433 7.6 cdma2000(R) 1X False MN 1435 The cdma2000(R) 1X network appears adequately protected against a 1436 false MN by IS-2000 challenge-response authentication. 1438 7.7 HRPD/1xEV-DO False MN 1440 The 1xEV-DO RADIUS AAA Server MAY optionally authenticate the MN 1441 using the MN_Authenticator to prevent a fraudulent MN activation. 1443 7.8 Key Lifetimes 1445 There is no explicit lifetime for the keys distributed by DMU. 1447 The lifetime of the keys distributed by DMU is determined by the 1448 system operator through the RADIUS AAA server. The MN_AAA and MN_HA 1449 key lifetimes can be controlled by initiating an update as needed. 1451 Furthermore, the DMU process is protected against false initiation 1452 because the MN cannot initiate DMU. This makes it unworkable to 1453 provide an explicit lifetime to the MN, since the MN cannot take any 1454 action to renew the keys after expiration. 1456 7.9 Network Message Security 1458 The security of the MN-HA keys delivered from the RADIUS AAA server 1459 to the MIP home agent requires confidentiality for network messages 1460 containing such keys. The specification of security requirements for 1461 network messages is the responsibility of the operator, and is 1462 outside the scope of this document. (Note that similar considerations 1463 apply to the distribution of Shared Secret Data, which is already 1464 transmitted between nodes in the ANSI-41 network.) 1465 Dynamic MIP Key Update January 2004 1467 8. Verizon Wireless RADIUS Attributes 1469 Three new RADIUS Attributes are required to support the DMU Procedure 1470 and are specified as follows: 1472 Type: 26 1473 Length: >9 1474 Verizon Wireless Enterprise/Vendor ID: 12951 1476 MIP_Key_Update_Request: 1477 ---------------------- 1479 The Home RADIUS AAA Server includes this attribute to indicate that 1480 MIP key update is required. 1482 Vendor-Type = 1 1483 Vendor-Length = 3 bytes 1484 Vendor-Value= PKOID of the RADIUS AAA Server 1486 MIP_Key_Data: 1487 ------------ 1489 Key data payload containing the encrypted MN_AAA key, MN_HA key, CHAP 1490 key, MN_Authenticator, and AAA_Authenticator. This payload also 1491 contains the Public Key Identifier. 1493 Vendor-Type = 2 1494 Vendor-Length = 134 bytes 1495 NOTE: Vendor-Length depends on the size of the RSA modulus. For 1496 example, when RSA-512 is used, Vendor-Length = 70 bytes. 1497 Vendor-Value= 128 byte RSA encryption payload (when 1024-bit RSA 1498 used) which contains encrypted MN_AAA key, MN_HA key, CHAP key, 1499 MN_Authenticator, and AAA_Authenticator. 1500 The four (4) byte Public Key Identifier is concatenated to the 1501 encrypted payload. 1503 AAA_Authenticator: 1504 ----------------- 1506 The 64-bit AAA_Authenticator value decrypted by the Home RADIUS AAA 1507 Server. 1509 Vendor-Type = 3 1510 Vendor-Length = 10 bytes 1511 Vendor-Value= decrypted AAA_Authenticator from Home RADIUS AAA 1512 Server. 1514 Dynamic MIP Key Update January 2004 1516 Public Key Invalid: 1517 ------------------ 1519 The home RADIUS AAA Server includes this attribute to indicate that 1520 the Public key used by the MN is not valid. 1522 Vendor-Type = 4 1523 Vendor-Length = 2 bytes 1524 Vendor-Value= none. 1526 Note: An Organization may define RADIUS VSAs using their own 1527 Organization identifier. 1529 9. Verizon Wireless Mobile IP Extensions 1531 Three Verizon Wireless Mobile IP Vendor/Organization-Specific 1532 Extensions (VSE) (RFC 3115), required to support the DMU Procedure, 1533 are specified as follows: 1535 Type: 38 (CVSE-TYPE-NUMBER) 1537 Verizon Wireless Vendor ID: 12951 (high-order octet is 0 and low 1538 order octets are the SMI Network Management Private Enterprise Code 1539 of the Vendor in the network byte order, as defined by IANA). 1541 0 7 8 15 16 31 1542 --------------------------------------------------- 1543 | Type | Reserved | Length | 1544 --------------------------------------------------- 1545 | Vendor/Org-ID | 1546 --------------------------------------------------- 1547 | Vendor-CVSE-Type | Vendor-CVSE-Value ... | 1548 --------------------------------------------------- 1550 Figure 7. Critical Vendor/Organization Specific Extension 1552 MIP_Key_Request: 1553 --------------- 1555 The Home RADIUS AAA Server includes this extension to indicate that 1556 MIP key update is required. 1558 Length = 7 1559 NOTE: The RFC 3115 Editor has stated that the Reserved field is 1560 not included in the length determination. 1561 Vendor-CVSE-Type = 1 1562 Vendor-CVSE-Value= PKOID sent in the RADIUS MIP_Key_Update_Request 1563 attribute. 1565 Dynamic MIP Key Update January 2004 1567 MIP_Key_Data: 1568 ------------ 1570 Key data payload containing encrypted MN_AAA key, MN_HA key, CHAP 1571 key, MN_Authenticator, and AAA_Authenticator. This payload also 1572 contains the Public Key Identifier. 1574 Length = 138 1575 NOTE: Length depends on the size of the RSA modulus. For example, 1576 when RSA-512 is used, Length = 74 bytes. 1577 Vendor-CVSE-Type = 2 1578 Vendor-CVSE-Value= 128 byte RSA encryption payload (when 1024-bit 1579 RSA used) which contains encrypted MN_AAA key, MN_HA key, CHAP 1580 key, MN_Authenticator, and AAA_Authenticator. 1581 The four (4) byte Public Key Identifier and DMUV is concatenated 1582 to the encrypted payload. 1584 AAA_Authenticator: 1585 ----------------- 1587 The 64-bit AAA_Authenticator value decrypted by the Home RADIUS AAA 1588 Server. 1590 Length = 14 bytes 1591 Vendor-CVSE-Type = 3 1592 Vendor-CVSE-Value= decrypted AAA_Authenticator from the Home 1593 RADIUS AAA Server. 1595 Public Key Invalid: 1596 ------------------ 1598 The Home RADIUS AAA Server includes this extension to indicate that 1599 the Public key used by the MN is not valid. 1601 Length = 6 bytes 1602 Vendor-CVSE-Type = 4 1603 Vendor-CVSE-Value= none. 1605 Note: An Organization may define VSEs using their own Organization 1606 identifier. 1608 10. Public Key Identifier and DMU Version 1610 The Public Key Identifier (Pub_Key_ID) is used during the Dynamic 1611 Mobile IP Update (DMU) procedure to allow the RADIUS AAA Server to 1612 distinguish between different Public keys (which may be assigned by 1613 different manufacturers, service providers, or other organizations). 1614 The Public Key Identifier consists of the PKOID, PKOI, PK_Identifier, 1615 Dynamic MIP Key Update January 2004 1617 and ATV fields. The DMU Version field enables subsequent revisions 1618 of the DMU procedure. 1620 ---------------------------------------------- 1621 | PKOID | PKOI | PK_Expansion | ATV | DMUV | 1622 ---------------------------------------------- 1623 0 7 8 15 16 23 24 27 28 31 1625 Figure 8. Public Key Identifier and DMUV 1627 Each Public Key Organization (PKO) MUST be assigned a Public Key 1628 Organization Identifier (PKOID) to enable the RADIUS AAA Server to 1629 distinguish between different Public keys created by different PKOs 1630 (see Table 1). 1632 If a Service Provider does not provide the MN manufacturer with a 1633 (RSA) Public key, the manufacturer MUST generate a unique RSA 1634 Public/Private key pair and pre-load each MN with the RSA Public key 1635 (1024-bit modulus by default). The manufacturer MAY share the same 1636 RSA Private key with multiple Service Providers as long as reasonable 1637 security procedures are established and maintained (by the 1638 manufacturer) to prevent disclosure of the RSA Private (decryption) 1639 key to an unauthorized party. 1641 The Public Key Organization Index (PKOI) is an 8-bit field whose 1642 value is defined at the discretion of the PKO. For example, a device 1643 manufacturer MAY incrementally assign a new PKOI for each 1644 Public/Private key pair when the pair is created. 1646 The PK_Expansion field enables support for additional PKOs or 1647 expansion of the PKOI. 1649 The DMU Version field allows for DMU Procedure version identification 1650 (see Table 2). 1652 The Algorithm Type and Version (ATV) field allows for identification 1653 of the Public Key algorithm and version used (see Table 3). 1655 Dynamic MIP Key Update January 2004 1657 Table 1. Public Key Organization Identification Table 1659 PKOID Public Key PKOID Public Key 1660 (HEX) Organization (PKO) (HEX) Organization (PKO) 1661 ----- ------------------ ----- ------------------ 1662 00 RESERVED 40 Sanyo Fisher Company 1663 01 RESERVED 41 Sharp Laboratories of 1664 America 1665 02 RESERVED 42 Sierra Wireless, Inc. 1666 03 RESERVED 43 Sony Electronics 1667 04 RESERVED 44 Synertek, Inc. 1668 05 RESERVED 45 Tantivy Communications, 1669 Inc. 1670 06 RESERVED 46 Tellus Technology, Inc. 1671 07 RESERVED 47 Wherify Wireless, Inc. 1672 08 RESERVED 48 Airbiquity 1673 09 RESERVED 49 ArrayComm 1674 0A Verizon Wireless 4A Celletra Ltd. 1675 0B AAPT Ltd. 4B CIBERNET Corporation 1676 0C ALLTEL Communications 4C CommWorks Corporation, 1677 a 3Com Company 1678 0D Angola Telecom 4D Compaq Computer 1679 Corporation 1680 0E Bell Mobility 4E ETRI 1681 0F BellSouth International 4F Glenayre Electronics 1682 Inc. 1683 10 China Unicom 50 GTRAN, Inc. 1684 11 KDDI Corporation 51 Logica 1685 12 Himachal Futuristic 52 LSI Logic 1686 Communications Ltd. 1687 13 Hutchison Telecom (HK), 53 Metapath Software 1688 Ltd. International, Inc. 1689 14 IUSACELL 54 Metawave Communications 1690 15 Komunikasi Selular 55 Openwave Systems Inc. 1691 Indonesia (Komselindo) 1692 16 Korea Telecom Freetel, 56 ParkerVision, Inc. 1693 Inc. 1694 17 Leap 57 QUALCOMM, Inc. 1695 18 LG Telecom, Ltd. 58 QuickSilver Technologies 1696 19 Mahanagar Telephone Nigam 59 Research Institute of 1697 Limited (MTNL) Telecommunication 1698 Transmission, MII (RITT) 1699 1A Nextel Communications, 5A Schema, Ltd. 1700 Inc. 1701 1B Operadora UNEFON SA de CV 5B SchlumbergerSema 1702 1C Pacific Bangladesh 5C ScoreBoard, Inc. 1703 Telecom Limited 1704 1D Pegaso PCS, S.A. DE C.V. 5D SignalSoft Corp. 1706 Dynamic MIP Key Update January 2004 1708 PKOID Public Key PKOID Public Key 1709 (HEX) Organization (PKO) (HEX) Organization (PKO) 1710 ----- ------------------ ----- ------------------ 1711 1E Pele-Phone 5E SmartServ Online, 1712 Communications Ltd. Inc. 1713 1F Qwest 5F TDK Corporation 1714 20 Reliance Infocom Limited 60 Texas Instruments 1715 21 Shinsegi Telecomm, Inc. 61 Wherify Wireless, Inc. 1716 22 Shyam Telelink Limited 62 Acterna 1717 23 SK Telecom 63 Anritsu Company 1718 24 Sprint PCS 64 Ericsson 1719 25 Tata Teleservices Ltd. 65 Grayson Wireless 1720 26 Telecom Mobile Limited 66 LinkAir Communications, 1721 Inc. 1722 27 Telstra Corporation 67 Racal Instruments 1723 Limited 1724 28 Telus Mobility Cellular, 68 Rohde & Schwarz 1725 Inc. 1726 29 US Cellular 69 Spirent Communications 1727 2A 3G Cellular 6A Willtech, Inc. 1728 2B Acer Communication & 6B Wireless Test Systems 1729 Multimedia Inc. 1730 2C AirPrime, Inc. 6C Airvana, Inc. 1731 2D Alpine Electronics, Inc. 6D COM DEV Wireless 1732 2E Audiovox Communications 6E Conductus, Inc. 1733 Corporation 1734 2F DENSO Wireless 6F Glenayre Electronics 1735 Inc. 1736 30 Ditrans Corporation 70 Hitachi Telecom (USA), 1737 Inc. 1738 31 Fujitsu Network 71 Hyundai Syscomm Inc. 1739 Communication, Inc. 1740 32 Gemplus Corporation 72 ISCO 1741 33 Giga Telecom Inc. 73 LG Electronics, Inc. 1742 34 Hyundai CURITEL, Inc. 74 LinkAir Communications, 1743 Inc. 1744 35 InnovICs Corp 75 Lucent Technologies, 1745 Inc. 1746 36 Kyocera Corporation 76 Motorola CIG 1747 37 LG Electronics, Inc. 77 Nortel Networks 1748 38 LinkAir Communications, 78 Repeater Technologies 1749 Inc. 1750 39 Motorola, Inc. 79 Samsung Electronics Co., 1751 Ltd. 1752 3A Nokia Corporation 7A Starent Networks 1753 3B Novatel Wireless, Inc. 7B Tahoe Networks, Inc. 1754 3C OKI Network Technologies 7C Tantivy Communications, 1755 Inc. 1756 3D Pixo 7D WaterCove Networks 1757 Dynamic MIP Key Update January 2004 1759 PKOID Public Key PKOID Public Key 1760 (HEX) Organization (PKO) (HEX) Organization (PKO) 1761 ----- ------------------ ----- ------------------ 1762 3E Research In Motion 7E Winphoria Networks, Inc. 1763 3F Samsung Electronics 7F ZTE Corporation 1764 Co., Ltd. 1766 Note: 80 through FF will be assigned by the PKOID administrator 1767 (TBD). 1769 Table 2. DMU Version 1771 DMU Version DMU Version 1772 Value 1773 ----------- ----------- 1774 00 RFC XXXX 1775 01 TBD 1776 02 TBD 1777 03 TBD 1778 04 TBD 1779 05 TBD 1780 06 TBD 1781 07 Cleartext Mode 1783 Table 3. Algorithm Type and Version 1785 ATV Public Key Algorithm 1786 Value Type and Version 1787 ----- -------------------- 1788 00 Reserved 1789 01 RSA - 1024 1790 02 RSA - 768 1791 03 RSA - 2048 1792 04 TBD 1793 05 TBD 1794 06 TBD 1795 07 TBD 1797 11. Intellectual Property 1799 Verizon Wireless has submitted a Patent Application to the United 1800 States Patent and Trademark Office for components of the DMU 1801 Procedure. 1803 QUALCOMM Incorporated may have patents applicable to the DMU 1804 procedure. 1806 Dynamic MIP Key Update January 2004 1808 12. Conclusion 1810 The Dynamic Mobile IP key Update (DMU) Procedure enables the 1811 efficient, yet secure, delivery of critical Mobile IP cryptographic 1812 keys. The use of cryptographic keys, hence the bootstrapping of such 1813 MIP keys using the DMU Procedure, is essential to commercial delivery 1814 of Mobile IP service in CDMA 2000 1xRTT and HRPD/1xEV-DO networks 1815 networks or other networks that utilize Mobile IP. 1817 13. Formal Syntax 1819 None. 1821 References 1823 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1824 Levels", BCP 14, RFC 2119, Internet Engineering Task Force, March 1825 1997 1827 2 TIA/EIA/IS-2000 Series, Revision A, Telecommunications Industry 1828 Association, March 2000 1830 3 TIA/EIA/IS-856, cdma2000 High Rate Packet Data Air Interface 1831 Specification, Telecommunications Industry Association, November 1832 2000 1834 4 Rigner, C, et al., "Remote Authentication Dial In User Service 1835 (RADIUS)," RFC 2865, IETF Network Working Group, June 2000. 1837 5 Calhoun, P, et al., "Diameter Base Protocol," RFC 3588, IETF 1838 Network Working Group, September 2003. 1840 6 TIA/EIA/IS-835-A, cdma2000 Wireless IP Network Standard, 1841 Telecommunications Industry Association, May 2001 1843 7 ANSI/TIA/EIA-41-D-97, Cellular Radiotelecommunications Intersystem 1844 Operations, Telecommunications Industry Association, December 1997 1846 8 ANSI/TIA/EIA-683-B-2001, Over-the-Air Service Provisioning of 1847 Mobile Stations in Spread Spectrum Systems, Telecommunications 1848 Industry Association, December 2001 1850 9 B. Kaliski. PKCS #1: RSA Encryption Version 1.5. RFC 2313, 1851 Internet Engineering Task Force, March 1998. 1853 10 G. Dommety, K. Leung. Mobile IP Vendor/Organization-Specific 1854 Extensions. RFC 3115, Internet Engineering Task Force, April 2001 1855 Dynamic MIP Key Update January 2004 1857 11 TIA/EIA-IS-634-A, Interoperability Specifications (IOS) for 1858 cdma2000 Access Network Interfaces, Telecommunications Industry 1859 Association, August 2001 1861 12 D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 1862 Recommendations for Security. RFC 1750, Internet Engineering Task 1863 Force, December 1994. 1865 Acknowledgments 1867 Thanks to Jeffrey Dyck (Qualcomm), James Willkie (Qualcomm), Jayanth 1868 Mandayam (Qualcomm), Marcello Lioy (Qualcomm), Michael Borella 1869 (CommWorks), Cliff Randall (CommWorks), Daniel Cassinelli 1870 (CommWorks), Edward Dunn (CommWorks), Suresh Sarvepalli (CommWorks), 1871 Gabriella Ambramovici (Lucent), Semyon Mizikovsky (Lucent), Sarvar 1872 Patel (Lucent), Peter McCann (Lucent), Ganapathy Sundaram (Lucent), 1873 Girish Patel (Nortel), Glen Baxley (Nortel), Diane Thompson 1874 (Ericsson), Brian Hickman(Ericsson), Somsay Sychaleun (Bridgewater), 1875 Parm Sandhu (Sierra Wireless), Iulian Mucano (Sierra Wireless), and 1876 Samy Touati (Ericsson) for their useful discussions and comments. 1878 Author's Addresses 1880 Christopher Carroll* 1881 HAMILTON, BROOK, SMITH & REYNOLDS, P.C. 1882 530 Virginia Road 1883 P.O. Box 9133 1884 Concord, MA 01742-9133 1885 Phone: 978-202-3436 1886 Email: christopher.carroll@hbsr.com 1887 *formerly with Verizon Wireless 1889 Frank Quick 1890 Qualcomm Incorporated 1891 5775 Morehouse Drive 1892 San Diego, CA 92121 USA 1893 Phone: 858-658-3608 1894 Email: fquick@qualcomm.com 1895 Dynamic MIP Key Update January 2004 1897 14. Appendix - Cleartext-Mode Operation 1899 DMU supports a cleartext mode for development testing where DMUV = 7. 1900 The MIP_Key_Data payload will assume the same size as if RSA 1024-bit 1901 encryption were applied to the payload. In this mode, the 1902 MIP_Key_Data RADIUS Attribute and MIP Vendor Specific Extension will 1903 be 134 bytes and 138 bytes in length respectively. Thus, in 1904 cleartext mode, the payload MUST consist of 48 bytes of keys (MN_AAA, 1905 MN_HA, and CHAP key), 8 byte AAA_Authenticator, 3 byte 1906 MN_Authenticator. The next 69 bytes will be padded with "0" bits. 1908 MIP_Key_Data = MN_AAAH key, MN_HA key, CHAP_key, MN_Authenticator, 1909 AAA_Authenticator, Padding (69 bytes), Public_Key_IDi, DMUV 1911 Where: 1913 MN_AAA key = 128-bit random MN / RADIUS AAA Server key. 1915 MN_HA key = 128-bit random MN / Home Agent (HA) key. 1917 CHAP_key = 128-bit random Simple IP authentication key. 1919 MN_Authenticator = 24-bit random number. 1921 AAA_Authenticator = 64-bit random number used by MN to 1922 authenticate the RADIUS AAA Server. 1924 Padding = 69 bytes of 0's. 1926 DMU Version (DMUV) = 4 bit identifier of DMU version. 1928 Public Key Identifier (Pub _Key_ID) = PKOID, PKOI, PK_Expansion, ATV 1930 Where: 1932 Public Key Organization Identifier (PKOID) = 8-bit serial number 1933 identifier of the Public Key Organization (PKO) that created 1934 the Public Key. 1936 Public Key Organization Index (PKOI) = 8-bit serial number used at 1937 PKO discretion to distinguish different Public/Private key 1938 pairs. 1940 PK_Expansion = 8-bit field to enable possible expansion of PKOID 1941 or PKOI fields. (Note: Default value = 0xFF) 1943 Algorithm Type and Version (ATV) = 4-bit identifier of the 1944 algorithm used.