Internet DraftNetwork Working Group C.Carroll,Carroll Request for Comments: 4784 Ropes & GrayLLP* Document:LLP Category: Informational F.Quick, draft-carroll-dynmobileip-cdma-05.txtQuick Qualcomm Inc.Expires: September 2005March20052007 Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks Status ofthisThis MemoBy submitting this Internet-Draft, each author represents that any applicable patent or other IPR claimsThis memo provides information for the Internet community. It does not specify an Internet standard ofwhich he or she is aware have been or will be disclosed, andany kind. Distribution ofwhich he or she becomes aware will be disclosed,this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). IESG Note This document describes an existing deployed technology that was developed outside the IETF. It utilizes the RADIUS Access-Reject inaccordanceorder to provision service, which is incompatible withSection 6 of BCP 79. Internet-Drafts are working documents oftheInternet Engineering Task Force (IETF), its areas,RADIUS protocol, andits working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximumpractices the sharing ofsix months and may be updated, replaced, or obsoleted by other documents at any time. Itsecret keys in public-key cryptosystems, which isinappropriate to use Internet-Drafts as reference material or to cite them other thannot a practice the IETF recommends. The IESG recommends against using this protocol as"worka basis for solving similar problems inprogress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.the future. Abstract The Verizon Wireless Dynamic Mobile IP Key Update procedure is a mechanism for distributing and updating Mobile IP (MIP) cryptographic keys in cdma2000(R) networks (including High Rate PacketDataData, which is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update (DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUSAAAAuthentication, Authorization and Accounting (AAA) Server via aCDMA2000(R)cdma2000(R) Packet Data Serving Node (PDSN) that is acting as a Mobile IP Foreign Agent (FA). cdma2000(R) is a registered trademark of the Telecommunications Industry Association (TIA).* This document was developed while at Verizon Wireless. Dynamic MIP Key Update March 2005 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1].Table of Contents 1.Introduction...................................................3Introduction ....................................................3 1.1. Conventions Used in This Document ..........................3 2. Basic Dynamic MIP Key UpdateMechanism.........................3 2.1Mechanism ..........................3 2.1. RSA Encrypted KeyDistribution.............................3 2.2Distribution .............................4 2.2. Mutual Authentication(1X).................................4 2.3(1X) .................................5 2.3. Encrypted PasswordAuthentication..........................7Authentication ..........................8 3. Dynamic MIP Key Update Advantages overOTASP...................8OTASP ...................10 4. Detailed DMU Procedure Description andRequirements............9 4.1Requirements ............10 4.1. RSA Public KeyCryptography................................9 4.2Cryptography ...............................11 4.2. Other Public KeyAlgorithms...............................10 4.3Algorithms ...............................11 4.3. WhynoNo Public Key Infrastructure(PKI)?...................10 4.4(PKI)? ...................11 4.4. Cryptographic KeyGeneration..............................10 4.5Generation ..............................12 4.5. MIP_Key_DataPayload......................................11 4.6Payload ......................................12 4.6. RSA KeyManagement........................................12 4.7Management ........................................13 4.7. RADIUS AAAServer.........................................13 4.8Server .........................................14 4.8. MN (Handset orModem).....................................15 4.9Modem) .....................................17 4.9. PDSN / Foreign Agent(FA).................................17 4.10(FA) .................................19 4.10. Home Agent(HA)..........................................18 4.11(HA) ..........................................20 4.11. DMU Procedure NetworkFlow...............................19Flow ...............................20 5. DMU Procedure FailureOperation...............................23Operation ................................25 6. cdma2000(R) HRPD/1xEV-DOSupport..............................26 6.1Support ...............................28 6.1. RADIUS AAASupport........................................26 6.2Support ........................................28 6.2. MNSupport................................................27 6.3Support ................................................29 6.3. Informative: MN_AuthenticatorSupport.....................28Support .....................30 7. SecurityConsiderations.......................................29 7.1Considerations ........................................31 7.1. Cryptographic Key Generation by theMN....................29 7.2MN ....................31 7.2. Man-in-the-MiddleAttack..................................29 7.3Attack ..................................31 7.3. RSA Private KeyCompromise................................29 7.4Compromise ................................32 7.4. RSAEncryption............................................30 7.5Encryption ............................................32 7.5. False BaseStation/PDSN...................................30 7.6Station/PDSN ...................................32 7.6. cdma2000(R) 1X FalseMN...................................30 7.7MN ...................................32 7.7. HRPD/1xEV-DO FalseMN.....................................30 7.8MN .....................................32 7.8. KeyLifetimes.............................................30 7.9Lifetimes .............................................32 7.9. Network MessageSecurity..................................30Security ..................................33 8. Verizon Wireless RADIUSAttributes............................31Attributes .............................33 9. Verizon Wireless Mobile IPExtensions.........................32Extensions ..........................34 10. Public Key Identifier and DMUVersion........................33Version .........................36 11.Conclusion...................................................37Conclusion ....................................................40 12.Formal Syntax................................................37Normative References ..........................................41 13. Informative References ........................................41 14. Acknowledgments ...............................................42 Appendix-A. Cleartext-ModeOperation..........................40 Dynamic MIP Key Update March 2005Operation ..............................43 1. Introduction The Verizon Wireless Dynamic Mobile IP Key Update procedure is a mechanism for distributing and updating Mobile IP (MIP) cryptographic keys in cdma2000(R) 1xRTT (1X) [2] and High Rate Packet Data (HRPD) / 1xEV-DO networks [3]. The Dynamic Mobile IP Key Update (DMU) procedure occurs between the Mobile IP Mobile Node (MN) and the home RADIUS [4] (or Diameter [5]) Authentication, Authorization and Accounting (AAA) Server via aCDMA2000(R)cdma2000(R) Packet Data Serving Node (PDSN) that is acting as a Mobile IP Foreign Agent (FA). (In thisdocumentdocument, we use the acronym AAAH to indicate the home AAA server as opposed toaan AAA server that may be located in a visited system.) This procedure is intended to support wireless systems conforming to Telecommunications Industry Association (TIA) TR-45 Standard IS-835 [6]. DMU, however, could be performed in any MIP network to enable bootstrapping of a shared secret between the Mobile Node (MN) and RADIUS AAA Server. The DMU procedure utilizes RSAPublicpublic key cryptography to securely distribute unique MIP keys to potentially millions of cdma2000(R) 1X and HRPD/1xEV-DO Mobile Nodes (MN) using the same RSAPublicpublic key. By leveraging the existing cdma2000(R) 1X authentication process, the Dynamic Mobile IP Key Update process employs a mutual authentication mechanism in which device-to-network authentication is facilitated using cdma2000(R) 1X challenge-responseauthenticationauthentication, and network- to-device authentication is facilitated using RSA encryption. By utilizing RSA encryption, the MN (or MN manufacturer) is able to pre-generate MIP keys (and theCHAPChallenge Handshake Authentication Protocol (CHAP) key) and pre-encrypt the MIP keys prior to initiation of the DMU procedure. By employing thispre- computationpre-computation capability, the DMU process requires less computation (by an order ofmagnitude less computationmagnitude) during the key exchange thanDiffie- HellmanDiffie-Hellman Key Exchange. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 2. Basic Dynamic MIP Key Update Mechanism The DMU procedure is basically an authentication and key distribution protocolwhichthat is more easily understood by separately describing the mechanism's two functional goals: 1) encrypted key distribution and 2) mutual authentication.2.12.1. RSA Encrypted Key Distribution By utilizing RSAPublic Key Cryptography,public key cryptography, MNs can be pre-loaded with a common RSAPublicpublic (encryption) key (by the MNmanufacturer)manufacturer), while the associated RSA Private (decryption) key is securely distributed from the MN manufacturer to each service provider. Alternatively, a service provider can generate its own RSAPublic/Privatepublic/private key pair andDynamic MIP Key Update March 2005only distribute the RSAPublicpublic key to MN manufacturers for pre- loading of MNs. During the manufacturing process, the MN manufacturer pre-loads each MN with the RSAPublicpublic key. When the MN is powered-up (or client application initiated), the MN can pre-generate and encrypt MIP keys for distribution to the Home RADIUS AAA Server during the DMU process. Alternatively, the MN manufacturer can pre-generate MIP keys, encrypt the MIP key payload, and pre-load the MN with multiple encrypted MIP key payloads to enable the DMU procedure. During the initial registration process (or when the AAA requires MIP key update), the MN: 1) generates the appropriate MIP keys, CHAP key, and authentication information, 2) uses the embedded RSAPublicpublic key to encrypt the payload information, 3) and appends the payload to the MIP Registration Request. The Registration Request is sent to the Mobile IP Foreign Agent (FA) via the cellular Base Station (BS) and Packet Data Serving Node (PDSN). When the RADIUS AAA Server receives the encrypted payload (defined later asMIP_Key_Data later),MIP_Key_Data), the AAA Server uses the RSA Private key to decrypt the payload and recover the MIP keys. MN BS/PDSN/FA AAA -- ---------- --- | | | ------------------ | ------------------- | RSA Public Key | | | RSA Private Key | | Pre-loaded by | | | Pre-loaded by | | Manufacturer | | | Service Provider | ------------------ | ------------------- | Registration Request, | | (MIP keys), RSA | | | Public Key | | |-------------------->| | | | Access Request, (MIP keys), | | RSA Public Key | | |---------------------->| | | ------------------- | | | Decrypt MIP | | | | Keys using RSA | | | | Private Key | | | ------------------- Figure 1. RSA Encrypted Key Distribution2.22.2. Mutual Authentication (1X) Mutual authentication can be achieved by delegation of the MN/device authentication by the RADIUS AAA Server to the cdma2000(R) 1X HomeDynamic MIP Key Update March 2005Location Register (HLR) and its associated Authentication Center (AC) [7], while the MN utilizes RSA encryption to authenticate the RADIUS AAA Server. MN/device authentication via an HLR/AC is based on the assumption that the MN's Mobile Station (MS) has an existing Authentication Key (A-key) and Shared Secret Data (SSD) with the cdma2000(R) 1X network. When MS call origination occurs, the AC authenticates the MS. If authentication is successful, the BS passes the Mobile Station Identifier (MSID)(e.g.(e.g., Mobile Identification Number (MIN)) to the PDSN. The "Authenticated MSID" is then included in the RADIUS Access Request (ARQ) message [4] sent from the PDSN to the RADIUS AAA server. Because the RADIUS AAA server stores the MSID associated with an MN subscription, the RADIUS AAA server is able to authorize MN access if the "Authenticated MSID" matches the RADIUS AAA MSID,i.e.i.e., the RADIUS AAA server is delegating its authentication function to the cdma2000(R) 1X HLR/AC. RADIUS AAA Server authentication (by the MN) is enabled by including a random number (AAA_Authenticator) in the encrypted payload sent from the MN to the RADIUS AAA Server. Only the possessor of the proper RSA Private key will have the ability to decrypt the payload and recover the unique AAA_Authenticator. If the MN receives the correct AAA_Authenticator (returned by the RADIUS AAA Server), the MN is assured that it is not interacting with a false Base Station (BS).Dynamic MIP Key Update March 2005MN BS/PDSN/FA HLR/AC AAA -- ---------- ------ --- ------------------ | | ------------------- | RSA Public Key | | | | RSA Private Key | | Pre-loaded by | | | | Pre-loaded by | | Manufacturer | | | | Service Provider | ------------------ | | ------------------- | Global Challenge | | |<-------------| | | | | | | | Auth_Response | | |------------->| | | | | Auth_Response | | | |---------------->| | | | ------------------ | | | | IS-2000 | | | | | Authentication | | | | ------------------ | | | Auth_Success | | | |<----------------| | | ------------------ | | | | BS forwards | | | | | Authenticated | | | | | MSID to PDSN | | | | ------------------ | | | | | | | Registration Request | | | (MIP keys, AAA_Authenticator), | | RSA Public Key | | |------------->| | | | | Access Request, MSID, | | | (MIP keys, AAA_Authenticator), | | RSA Public Key | | |------------------------------->| | | | ------------------- | | | | Check MSID, | | | | | Decrypt AAA_- | | | | | Authenticator | | | | ------------------- | Access Reject, AAA_Authenticator | | |<-------------------------------| Registration Reply, AAA_Authenticator | |<-------------| | | ------------------ | | | | Check AAA_- | | | | | Authenticator | | | | ------------------ | | | Figure 2. Mutual AuthenticationDynamic MIP Key Update March 2005 2.32.3. Encrypted Password Authentication Because cdma2000(R) A-key/SSD authentication is not available in1xEV-DO1xEV-DO, or a particular cdma2000(R) 1X network may not support A-key authentication, the DMU procedure also includes a random number (MN_Authenticator) generated by the MN (and/or pre-loaded by the manufacturer), which enables the RADIUS AAA Server to optionally authenticate the MN (in 1XEV DO network only). The MN_Authenticator is transmitted from the MN to the Home AAA Server within the RSA-encrypted MIP_Key_Data payload to prevent interception and possible re-use by an attacker. Ideally, the MN_Authenticator is utilized as a One-TimePassword,Password; however, RSA encryption allows the MN_Authenticator to possibly be re-used based on eachService Provider'sservice provider's key distribution policy. When the encrypted MIP keys are decrypted at the Home RADIUS AAA Server, the MN_Authenticator is also decrypted and compared with a copy of the MN_Authenticator stored within the Home RADIUS AAA Server. The Home RADIUS AAA Server receives a copy of the MN_Authenticator out-of-band (not using the cdma2000(R) network) utilizing one of numerous possible methods outside the scope of the standard. For example, the MN_Authenticator MAY be: 1) read out by a Point-of-Sale provisioner from the MN, input into the subscriber profile, anddelivereddelivered, along with the Network Access Identifier (NAI), via the billing/provision system to the Home RADIUS AAA server, 2) verbally communicated to a customer care representative via a call, or 3) input by the user interfacing with an interactive voice recognition server. The out-of-band MN_Authenticator delivery is not specified in this document to maximize theService Provider'sservice provider's implementation flexibility. It is possible for an unscrupulous provisioner or distribution employee to extract the MN_Authenticator prior to the DMUprocedure, howeverprocedure; however, the risk associated with such a disclosure is minimal. Because the HRPD/1xEV-DO MN does not transmit a device identifier during the initial registration process, an attacker, even with a stolen MN_Authenticator, cannot correlate the password with a particular MN device or NAI, which is typically provisioned just prior to DMU procedure initiation. The MN_Authenticator is typically generated by a random/pseudorandom number generator within the MN. MN_Authenticator generation is initiated by the MNuser, howeveruser; however, it may be initially pre-loaded by the manufacturer. When the MN_Authenticator is reset(i.e.(i.e., a new MN_Authenticator is generated), all MIP_Data_Key payloads using the previous MN_Authenticator are discarded and the MN immediately re- encrypts a MIP_Key_Data payload containing the new MN_Authenticator. The MN_Authenticator MUST NOT change unless it is explicitly reset byDynamic MIP Key Update March 2005the MN user. Thus, the MN will generate new MIP_Key_Data payloads using the same MN_Authenticator until the MN_Authenticator is updated. ------------------------- | User-initiated | | MN_Authenticator[x] | | Generation | ------------------------- | v ----------------------------- ------------------------------ | Manufacturer | | Delete MN_Authenticator[y], | | MN_Authenticator[y] |----->| Store MN_Authenticator[x] | | Generation** | | in MN | ----------------------------- ------------------------------ | v ------------------------- | Delete MIP_Key_Data | | Payloads based on | | MN_Authenticator[y] | ------------------------- | v ----------------------------- ------------------------- | KEYS_VALID state and | | Generate MIP_Key_Data | | committed, delete |----->| Payloads based on | | MIP_Key_Data Payload | | MN_Authenticator[x] | ----------------------------- ------------------------- ^ | | v ----------------------------- ------------------------- | DMU MIP_Key_Data | | Store MIP_Key_Data | | Delivery |<-----| Payload | ----------------------------- ------------------------- Figure 3. MN_Authenticator and MIP_Key_Data Payload State Machine **Note: Manufacturer pre-load of MN_Authenticator is not essential since the MN_Authenticator is typically generated by the MN. However, manufacturer pre-load may reduce the provisioner burden of accessing a device such as a modem to recover the MN_Authenticator for entry into theSerivce Providerservice provider provisioning system. 3. Dynamic MIP Key Update Advantages over OTASP The DMU procedure has numerous advantages over the current Over-the- Air Service Provisioning (OTASP) [8]procedureprocedure, including:Dynamic MIP Key Update March 2005* In DMU, MIP key distribution occurs directly between the MN and AAA Server at the IP Layer. This eliminates the need for an interface between theOTAFOver-the-Air Functionality (OTAF) and RADIUS AAA server. * DMU Supports MIP key distribution for cdma2000(R) 1X and HRPD/1xEV-DO MN. OTASP only supports cdma2000(R) 1X MIP key distribution. * DMU facilitates MIP key distribution to an MN in a Relay-mode MS. OTASP only delivers the MIP keys to the MS. For example, OTASP cannotdeliverydeliver MIP keys to a Laptop MN interfacing with an MS modem. * Pre-encryption of MIP_Key_Data allows the DMU procedure to be an order of magnitude faster than Diffie-Hellman Key Exchange. * In DMU, an MN manufacturer can pre-generate MIP keys, pre- encrypt the MIP key payload, and pre-load the payload in the MN. Thus, an MN with limited processing power is never required to use RSA encryption. An OTASP device is always forced to perform computationally expensive exponentiations during the key update process. * In DMU, the MN is protected against Denial-of-Service (DOS) attacks in which a false BS changes the MIP key for MNs in its vicinity. OTASP Diffie-Hellman Key Exchange is vulnerable to a false BS DOS attack. * DMU utilizes mutual authentication. OTASP Diffie-Hellman Key Exchange does not utilize mutual authentication. 4. Detailed DMU Procedure Description and Requirements The Verizon Wireless Dynamic Mobile IP Update procedure is a secure, yet extremely efficient mechanism for distributing essential MIP cryptographic keys(e.g.(e.g., MN-AAAH key and MN-HA key) and the Simple IP CHAP key. The DMU protocol enables pre-computation of the encrypted key material payload, known as MIP_Key_Data. The DMU procedure purposely avoids the use of Public Key Infrastructure (PKI) Certificates, greatly enhancing the procedure's efficiency.4.14.1. RSA Public Key Cryptography RSAPublic Keypublic key encryption and decryption MUST be performed in accordance with RFC23133447 [9] PKCS #1: RSA Encryption Version 1.5. DMU MUST support RSA with a 1024-bit modulus by default. DMU MAY also support 768-bit or 2048-bitRSARSA, depending on the MN user's efficiency or security requirements. RSA computation speed-ups usingDynamic MIP Key Update March 2005a public RSA exponentwhichthat is small or has a small number of nonzero bits(e.g.(e.g., 65537) are acceptable.4.24.2. Other Public Key Algorithms DMU does not preclude the use of otherPublicpublic key technologies. The protocol includes a Public Key Type field that defines the type of encryption used.4.34.3. WhynoNo Public Key Infrastructure (PKI)? DMU is designed to maximize the efficiency of Mobile IP (MIP) key distribution for cdma2000(R) MNs. The use of aPublicpublic key Certificate would improve the flexibility of the MIP key update process by allowing a Certificate Authority (CA) to vouch for the RSAPublic Keypublic key delivered to the MN. Unfortunately, the useof a Public Key Certificateof a public key certificate would significantly reduce the efficiency (speed and overhead) of the MIP key update process. For instance, each MN must be pre-loaded with the CA'sPublic Key.public key. During the MIP key distribution process, the network must first deliver its RSAPublic Keypublic key (in aCertificate)certificate) to the MN. The MN must then use RSA to decrypt the Certificate's digital signature to verify that the presented RSA public key is legitimate. Such a process significantly increases the number of exchanges, increases air interface overhead, increases the amount of MN computation, and slows the MIP key update process. Aside from the operational efficiency issues, there are numerous policy and procedural issues that have previously hampered the deployment of PKI in commercial networks. On a more theoretical basis, PKI is likely unnecessary for this key distribution model. PKI is ideal for a Many-to-Many communicationsmodelmodel, such as within theInternetInternet, where many different users interface with many different Websites. However, in the cellular/PCS Packet Data environment, a Many-to-One (or few) distribution modelexistsexists, in which many users interface with one wireless Carrier to establish their Mobile IP security associations(i.e(i.e., cryptographic keys).4.44.4. Cryptographic Key Generation The DMU procedure relies on each MN to randomly/pseudo-randomly generate the MN_AAAH key, MN_HA key, and Simple IP CHAP key. Each MN MUST have the capability to generate random/pseudo-random numbers in accordance with the guidelines specified in RFC1750 Randomness Recommendations4086 "Randomness Requirements forSecurity. Dynamic MIP Key Update March 2005Security". Although it may be more secure for the network to generate cryptographic keys at the RADIUS AAA server, client cryptographic key generation is acceptable due to the significant efficiency improvement in the update process via pre-generation and pre- encryption of the MIP keys.4.54.5. MIP_Key_Data Payload MIP cryptographic keys (MN_AAAH key and MN_HA key) and the Simple IP CHAP key are encapsulated and encrypted into a MIP_Key_Data Payload (along with the AAA_Authenticator and MN_Authenticator). The MIP_Key_Data Payload is appended to the MN's MIP Registration Request (RRQ) as a MIP Vendor/Organization-Specific Extension (VSE)(See IETF(see RFC 3115 [10] Mobile IP Vendor/Organization-Specific Extensions). When the PDSN converts the MIP RRQ to a RADIUS Access Request (ARQ) message, the MIP_Key_Data Payload is converted from a MIP Vendor/Organization-Specific Extension to a Vendor Specific RADIUS Attribute (VSA). Upon receipt of the RADIUS Access Request, the RADIUS AAA Server decrypts the MIP_Key_Data payload using the RSAPrivateprivate (decryption) key associated with the RSAPublicpublic (encryption) used to encrypt the MIP_Key_Data payload. The MIP_Key_Data is defined as follows: MIP_Key_Data = RSA_Public_Key [MN_AAAH key, MN_HA key, CHAP_key, MN_Authenticator, AAA_Authenticator], Public_Key_ID, DMUV Where: MN_AAAH key = 128-bit random MN / RADIUS AAA Server key (encrypted) MN_HA key = 128-bit random MN / Home Agent (HA) key (encrypted) CHAP_key = 128-bit random Simple IP authentication key (encrypted) Note: the Simple IP CHAP key is not the same as the AT-CHAP key used for A12 Interface authentication [11]. MN_Authenticator = 24-bit random number (displayed as an 8 decimal digit number). (To be used for 1xEV-DO networks.) (encrypted) AAA_Authenticator = 64-bit random number used by MN to authenticate the RADIUS AAA Server. (encrypted) DMU Version (DMUV) =4 bit4-bit identifier of DMU version. Public Key Identifier (Public_Key_ID) = PKOID, PKOI, PK_Expansion, ATVDynamic MIP Key Update March 2005Where: Public Key Organization Identifier (PKOID) = 8-bit serial number identifier of Public Key Organization (PKO) that created the Public Key. Public Key Organization Index (PKOI) = 8-bit serial number used at PKO discretion to distinguish differentPublic/Privatepublic/private key pairs. PK_Expansion = 8-bit field to enable possible expansion of PKOID or PKOI fields. (Note: Default value = 0xFF) Algorithm Type and Version (ATV) = 4-bit identifier of the algorithm used. Note: If 1024-bit RSA is used, the encrypted portion of the payload is 1024 bits (128 bytes) long. With the28 bit28-bit Public Key Identifier and4 bit4-bit DMUV, the total MIP_Key_Data payload is 132 bytes long.4.64.6. RSA Key Management The wirelessService Providerservice provider or carrier MUST generate the RSA Public/Private key pair(s). An organization within theService Providerservice provider MUST be designated by theService Providerservice provider to generate, manage, protect, and distribute RSA Private keys (to the RADIUS AAA Server) andPublicpublic keys (to the MN manufacturers) in support of the DMU procedure. Each RSAPublic/Privatepublic/private key pair, generated by the wireless carrier, MUST be assigned a unique Public Key Identifier in accordance with Section 9. RSA Private keys MUST be protected from disclosure to unauthorized parties. TheService Providerservice provider organization with the responsibility of generating the RSAPublic/Privatepublic/private key pairs MUST establishaan RSA key management policy to protect the RSA Private (decryption) keys. RSAPublicpublic keys MAY be freely distributed to all MN manufacturers (along with the Public Key Identifier). Because one RSAPublicpublic key can be distributed to million of MNs, it is acceptable to distribute the RSAPublicpublic key (and Public Key Identifier) to MN manufacturers via e-mail, floppy disk, or a Website. The preferred method is to simply publish the RSAPublicpublic key and associated Public Key Identifier in the DMU Requirements document sent to each MN manufacturer/OEM. When public keys are distributed, the public keys MUST be protected against alteration. If an invalid public key is programmed into aDynamic MIP Key Update March 2005terminal, the terminal may be denied service because DMU cannot be performed successfully. RSA Private keys MAY be loaded into the RADIUS AAA server manually. Access to the RADIUS AAA Server RSA Private keys MUST be restricted to authorized personnel only. The wirelessService Providerservice provider MAY accept RSA Private key(s) (and Public Key Identifier) from MN manufacturers or otherService Providersservice providers that have preloaded MNs with manufacturer-generated RSAPublicpublic keys. OneService Providerservice provider MAY negotiate an agreement with anotherService Providerservice provider in which bothService Providersservice providers share and protect each other's RSA Private keys.4.74.7. RADIUS AAA Server The RADIUS AAA Server used for DMU MUST support the DMU Procedure. The AAA Server MUST support RSAPublicpublic key cryptography and maintain a database of RSA Private (decryption) keys indexed by the Public Key Identifier. Delivery of the RSA Private key(s) toaan AAA Server from the MN manufacturer(s) is outside the scope of thisdocuments.document. However, RSA Private key(s) delivery via encrypted e-mail or physical (mail) delivery is likely acceptable. Access to the RADIUS AAA Server MUST be limited to authorized personnel only. The RADIUS AAA Server MUST support 1024-bit RSA decryption. The RADIUS AAA Server MUST maintain a database of RSAPublic/Privatepublic/private key pair indexed by the Public Key Identifier. The RADIUS AAA Server MUST support the RADIUS attributes specified in Section 8. The RADIUS AAA Server MUST support asubscriber specificsubscriber-specific MIP Update State Field. When the MIP Update State Field is set to UPDATE KEYS (1), the RADIUS AAA Server MUST initiate the DMU procedure by including the MIP_Key_Request attribute in an Access Reject message sent to the PDSN. The MIP Update State Field MAY be set to UPDATE KEYS (1) byService Provider'sthe service provider's Billing/Provisioning system based on IT policy. Upon verification of MN-AAA Authentication Extension using the decrypted MN_AAA key, the RADIUS AAA Server MUST set the MIP Update State Field to KEYS UPDATED (2). Upon verification of the MN-Authentication Extension on a subsequent RRQ/ARQ, the RADIUS AAA Server MUST set the MIP Update State Field to KEYS VALID (0).Dynamic MIP Key Update March 2005Note that the inclusion of a vendor-specific attribute in the Access Reject message is not consistent withsectionSection 5.44 of [4]. A RADIUS AAA server that supports DMU SHOULD NOT include a vendor-specific attribute if the corresponding Access Request message was not received from a DMU-compliant PDSN. This use of Access Reject is strongly discouraged for any future work based on this document. Future work should consider the use of Access-Challenge to carry this vendor-specific attribute. The RADIUS AAA Server MUST maintain a MIP Update State Field, for each subscription, in one of three states (0 = KEYS VALID, 1 = UPDATE KEYS, 2 = KEYS UPDATED). The RADIUS AAA Server MUST decrypt the encrypted portion of the MIP_Key_Data payload using the appropriate RSA Private (decryption) key. The RADIUS AAA Server MUST check the MN_AAA Authentication Extension of the DMU RRQ using the decrypted MN_AAA key. The RADIUS AAA Server MUST include the AAA_Authenticator in the Access Accept as a Vendor-Specific RADIUS Attribute. The RADIUS AAA Server MUST support the MN_Authenticator options specified in Section 6.1. The RADIUS AAA Server MUST comply with DMU Procedure failure operation specified in Section 5. The RADIUS AAA Server MUST support manual hexadecimal entry of MN_AAA key, MN_HAkeykey, and Simple IP CHAP key via the AAA GUI for each subscription. The RADIUS AAA Server MUST provide a mechanism to validate theMIN/IMSI.MIN/International Mobile Subscriber Identity (IMSI). When the MIN/IMSI validation is on, the RADIUS AAA Server MUST compare the MIN/IMSI sent from the PDSN with the MIN/IMSI in the AAA subscription record/profile. If the MINs or IMSIs do not match, the RADIUS AAA Server MUST send an Access Reject to the PDSN/FA. The Access Reject MUST NOT contain a MIP Key Data request When the "Ignore MN_Authenticator" bit is not set, the RADIUS AAA Server MUST check whether MN_AuthenticatorMN = MN_AuthenticatorAAA. If the MN_Authenticators do not match, the RADIUS AAA Server MUST send an Access Reject to the PDSN/FA. The Access Reject MUST NOT contain a MIP_Key_Data request. The RADIUS AAA Server MUST include its PKOID (or another designated PKOID) in the MIP_Key_Request RADIUS Attribute.Dynamic MIP Key Update March 2005The RADIUS AAA Server MUST compare the PKOID sent in the MIP_Key_Data RADIUS Attribute with a list of valid PKOIDs in the RADIUS AAA Server. If the PKOID is not valid, the RADIUS AAA Server MUST send an Access Reject to the PDSN with the "Invalid Public Key" Verizon Wireless RADIUS Vendor Specific Attribute (VSA). Note: the same RADIUS attribute may be assigned a different Vendor identifier. Note that the inclusion of a vendor-specific attribute in the Access Reject message is not consistent with section 5.44 of [4]. A RADIUS AAA server that supports DMU SHOULD NOT include a vendor-specific attribute if the corresponding Access Request message was not received from a DMU-compliant PDSN. This use of Access Reject is strongly discouraged for any future work based on this document. Future work should consider the use of Access-Challenge to carry this vendor-specific attribute. The RADIUS AAA Server MUST support delivery of the MN-HA key using 3GPP2 RADIUS VSAs as specified in 3GPP2 X.S0011-005-C. The 3GPP2 VSAs used are the MN-HA Shared Key (Vendor-Type = 58) and MN-HASPISecurity Parameter Index (SPI) (Vendor-Type = 57). The RADIUS AAA Server SHOULD always accept an Access Request from aCDMA2000(R)cdma2000(R) Access Node (AN) for a particular subscriber when the UPDATE KEYS (1) and KEYS UPDATED (2) states are set. In the KEYS VALID (0) state, the RADIUS AAA Server MUST check the Access Request normally. The RADIUS AAA Server MUST reject an Access Request with the MIP_Key_Data RADIUS Attribute while the RADIUS AAA Server is in the KEYS VALID state, i.e., the AAA MUST NOT allow an unsolicited key update to occur.4.84.8. MN (Handset or Modem) The MN manufacturer MUST pre-load the Wireless Carrier RSAPublicpublic key (and Public Key Identifier). The MN manufacturer MUST pre-generate and pre-load the MN_Authenticator. The MN MUST support 1024-bit RSA Encryption using the pre-loaded RSAPublicpublic key. The MN MUST support MN_AAA, MN_HA, and CHAP random/pseudo-random key generation (in accordance with RFC1750).4086). The MN MUST support random/pseudo-random AAA_Authenticator and MN_Authenticator generation (in accordance with RFC1750). Dynamic MIP Key Update March 20054086). Upon power-up of an MN handset or launch of the MN client, the MN MUST check whether a MIP_Key_Data payload has been computed. If no MIP_Key_Data payload exists, the MN MUST generate and store a MIP_Key_Data payload. The MN MUST maintain at least one pre- generated MIP_Key_Data payload. The MN MUST construct the MIP_Key_Data payload in accordance with Section 4.5. The MN MUST initiate the DMU Procedure upon receipt of a MIP Registration Reply (RRP) with the MIP_Key_Request Verizon WirelessVendor/Organization-specificVendor/Organization-Specific Extension (VSE). Upon receipt of an RRP including the MIP_Key_Request, the MN MUST check the PKOID sent in the MIP_Key_Request. If the MN has aPublicpublic key associated with the PKOID, the MN MUST encrypt the MIP_Key_Data payload using thatPublicpublic key. The MN MUST have the capability to designate onePublicpublic key as theDefault Publicdefault public key if the MN supports multiplePublicpublic keys. The MN MUST insert the Verizon Wireless MIP_Key_Data VSE (or another Organization-specific MIP_Key_Data VSE) after the Mobile-Home Authentication Extension, but before the MN-AAA Authentication Extension. The MIP_Key_Data Extension must also be located after the FA ChallengeExtensionExtension, if present. Note: The order of the extensions is important for interoperability. After the FA receives the Access Accept from the RADIUS AAA server, the FA may strip away all MIP extensions after the Mobile-HomeAuthenticator and, ifAuthenticator. If this occurs, it is not necessary for the HA to process the DMU extensions. Other compatibility problems have also been identified during testing with FAs from various vendors who place extensions in various locations. Explicit placement of the extensions eliminates these issues. Upon initiation of the DMU Procedure, the MN MUST compute the MIP authentication extensions using the newly-generated temporary MN_AAA and MN_HA keys. Upon receipt of the AAA_Authenticator MIP Extension, the MN MUST compare the AAA_AuthenticatorMN (sent in the encrypted MIP_Key_Data payload) with the AAA_AuthenticatorAAA (returned by the RADIUS AAA Server). If both values are the same, the MN MUST designate the temporary MN_AAA, MN_HA key, and the Simple IP CHAP key as permanent. The MN MUST set its MIP Update State field to KEYS VALID. The MN MUST support reset (re-generation) of the MN_Authenticator by the MN user as specified in Section 6.2.Dynamic MIP Key Update March 2005The MN MUST enable the MN user to view the MN_Authenticator. MN_Authenticator (24-bit random number) MUST be displayed as an 8 decimal digit number as specified in Section 6.2. The MN manufacturer MUST pre-load each MN with a unique random 24-bit MN_Authenticator. Upon reset of the MN_Authenticator, the MN MUST delete all MIP_Key_Data payloads based on the old MN_Authenticator and generate all subsequent MIP_Key_Data payloads using the newMN_Authenticator.MN_Authenticator (until the MN_Authenticator is explicitly re-set again by the MN user). The MN MUST support manual entry of all cryptographic keys such as the MN_AAA, MN_HA, and Simple IP CHAP key. MN MUST support hexadecimal digit entry of a 128-bit key. (Note: certain Simple IP devices only enable ASCII entry of a password as the CHAP key. It is acceptable for future devices to provide both capabilities,i.e.i.e., ASCII for a password or hexadecimal for a key. The authors recommend the use of strong cryptographic keys.) The MN MUST support the Verizon Wireless MIP Vendor/Organization- Specific Extensions specified in Section 9. The MN MUST update the RRQ Identification field when re-transmitting the same MIP_Key_Data in a new RRQ. The MN MUST comply with the DMU Procedure failure operation specified in Section 5. The RSAPublic Keypublic key MAY be stored in the MN flash memory as a constant while being updatable via software patch.4.94.9. PDSN / Foreign Agent (FA) The PDSN MUST support the Verizon Wireless RADIUSVendor SpecificVendor-Specific Attributes (VSA) specified in Section 8 and the Verizon Wireless MIP Vendor/Organization-Specific Extensions(VSE)(VSEs) specified in Section 9. The PDSN MAY support the RADIUS VSAs specified in Section 8 and the MIP VSEs specified in Section 9 using another Organization identifier. 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.Dynamic MIP Key Update March 2005Upon receipt of an Access Reject containing the AAA_Authenticator VSA, the PDSN MUST send an RRP with the AAA_Authenticator MIP VSE. The PDSN MUST use the RRP error code = 89 (Vendor Specific) and MUST NOT tear down the PPP session after transmission. Upon receipt of an Access Reject containing the Public Key Invalid VSA, the PDSN MUST send an RRP with the Public Key Invalid MIP VSE. The PDSN MUST use the RRP error code = 89 (Vendor Specific) and MUST NOT tear down the PPP session after transmission. Note that the inclusion of a vendor-specific attribute in the Access Reject message is not consistent with section 5.44 of [4]. A PDSN that supports DMU MUST accept an Access Reject message containing a vendor-specific attribute. This use of Access Reject is strongly discouraged for any future work based on this document. Future work should consider the use of Access-Challenge to carry this vendor- specific attribute. Upon receipt of an RRQ with the MIP_Key_Data VSE, the PDSN MUST convert the RRQ to an ARQ with the MIP_Key_Data VSA. The PDSN MUST send the ARQ to the RADIUS AAA server. The PDSN/FA MUST comply with the DMU Procedure failure operation specified in Section 5. The PDSN/FA MUST include the PKOID from the Access Reject MIP_Key_Update_Request VSA in the MIP_Key_Request MIP VSE sent to the MN.4.104.10. Home Agent (HA) The HA MUST support the Verizon Wireless MIP Vendor/Organization- Specific Extensions(VSE)(VSEs) specified in Section 9. (Note: the HA may not encounter a DMU MIP extension if the FA strips away all extensions after the Mobile-Home authentication extension.) The HA MAY support the MIP VSEs specified in Section 9 using another Organization identifier. (Note: the HA may not encounter a DMU MIP extension if the FA strips away all extensions after the Mobile-Home authentication extension.) The HA MUST support delivery of the MN-HA key from the Home RADIUS AAA server using 3GPP2 RADIUS Vendor-Specific Attributes (VSA) as specified in 3GPP2 X.S0011-005-C. The 3GPP2 VSAs used are the MN-HA Shared Key (Vendor-Type = 58) and the MN-HA SPI (Vendor-Type = 57).Dynamic MIP Key Update March 2005 4.114.11. DMU Procedure Network Flow This section provides a flow diagram and detailed description of the process flow involving the Dynamic Mobile IP Update procedure process within the IS-2000 network. MN PDSN/FA AAAH -- ------- ---- --------------------- | ------------------- | 1: RSA Public Key | | | RSA Private Key | | Pre-loaded by | | | Pre-loaded by | | Manufacturer | | | Service Provider | --------------------- | ------------------- --------------------------------------------------------- | 2: MS/BS: IS-2000 Call Origination and Authentication | | 3: MN/PDSN/FA: PPP Session Establishment | --------------------------------------------------------- | 4: Registration Request (RRQ) | | |--------------------------------->| 5: Access Request w/MSID | |------------>| | | -------------------- | | | 6: MIP Update State| | | | is UPDATE KEYS | | | -------------------- | 7: Access Reject with | | MIP_Key_Update_Request | | RADIUS Attribute | | |<------------| | 8: Registration Reply (RRP) | | | with MIP_Key_Request MIP | | | Vendor/organization-specific | | | extension | | |<---------------------------------| | ------------------- | | | 9: MN generates | | | | MIP_Key_Data | | | | using temporary | | | | MIP keys | | | ------------------- | | | 10: RRQ with MIP_Key_Data | | | Vendor/organization-specific extension | |--------------------------------->| 11: Access Request | | w/MSID | | and MIP_Key_Data | | RADIUS attribute | |------------>| Figure 4. DMU Procedure Flow (part 1)Dynamic MIP Key Update March 2005MN PDSN/FA AAAH -- ------- ---- | | | | | ------------------- | | | 12: decrypt | | | | MIP_Key_Data, | | | | verify MN-AAA | | | | authentication | | | | extension, set | | | | MIP Update State | | | | = KEYS UPDATED | | | ------------------- | 13: Access Reject with | | AAA_Authenticator | | RADIUS Attribute | | |<------------| | 14: Registration Reply (RRP) | | | with AAA_Authenticator MIP | | | Vendor/organization-specific | | | extension | | |<---------------------------------| | ---------------------- | | | 15: verify | | | | AAA_Authenticator, | | | | store temporary | | | | MIP keys as | | | | permanent keys | | | ---------------------- | | | 16: RRQ | | |--------------------------------->| Access Request | | w/MSID | |------------>| | | -------------------- | | | 17: verify MN-AAA | | | | authentication | | | | extension, set | | | | MIP Update State | | | | = KEYS VALID | | | -------------------- | Access Accept | | |<------------| Figure 4. DMU Procedure Flow (part 2)Dynamic MIP Key Update March 2005MN PDSN/FA AAAH HA -- ------- ---- -- | | | | | | 18. Registration Request (RRQ) | | |-------------------------------->| | | 19: Access Request | | | |<-----------------| | | | Access Accept | | | | with MN-HA key | | | |----------------->| | | | ------------------- | | | | verify | | | | | mobile-home | | | | | authentication | | | | | extension | | | | ------------------- | | 20. Registration Reply (RRP) | | |<--------------------------------| | RRP | | | |<--------------| | | Figure 4. DMU Procedure Flow (part 3) Each step in the Figure 4 DMU Process is described as follows: 1. Each RSAPublic/Private Keypublic/private key pair MUST be generated in accordance with RFC2313.3447. EachPublic/Privatepublic/private key pair MUST be assigned a unique Public Key Identifier (PKOID) by its creator. If theService Providerservice provider does not generate thePublic/Private Keypublic/private key pair and deliver the RSAPublic Keypublic key to the MN manufacturer for pre-installation in the MN, the MN manufacturer MUST generate the RSAPublic/Private Keypublic/private key pair (using a 1024-bit modulus) and pre-load all MNs with the RSAPublicpublic (encryption) key. The MN manufacturer MUST distribute the RSA Private (decryption) key, in a secure manner, to the appropriate service provider(s). It is acceptable for the MN manufacturer to distribute the same Private (decryption) key to multiple service providers. 2. Assuming that the cdma2000(R) 1X MN has been provisioned with an A-key and SSD, the cdma2000(R) 1X MS initiates a call origination and authenticates itself to the IS-2000 network. Upon IS-2000 authentication success, the BS sends the "authenticated" MSID(e.g.(e.g., MIN) to the PDSN. 3. The MN and PDSN establish a PPP session. 4. The MN sends a MIP Registration Request (RRQ) to the PDSN.Dynamic MIP Key Update March 20055. The PDSN converts the MIP RRQ into a RADIUS Access Request (ARQ) message, includes the MSID in the ARQ, and forwards the ARQ to the Home RADIUS AAA server. 6. The RADIUS AAA Server compares the authenticated MSID (sent from the PDSN) with the MSID in its subscriber database (associated with the NAI). If the AAA MIP Update State Field is set to UPDATE KEYS (1), the RADIUS AAA Server rejects Packet Data access and orders a MIP key update. 7. The RADIUS AAA Server sends an Access Reject (code = 3) message to the PDSN with the MIP_Key_Update_Request RADIUS VSA. 8. The PDSN converts the Access Reject to a MIP Registration Reply (RRP) with a MIP_Key_Request MIP VSE and sends the RRP to the MN. RRP Code = 89 (Vendor Specific). 9. The MN sets the MN MIP Update State = UPDATE KEYS. If the MN has no pre-generated and pre-encryptedtheMIP_Key_Data payload, the MN MUST generate the MN_AAA key, MN_HA key, Chap key, MN_Authenticator, and AAA_Authenticator in accordance with RFC1750.4086. Except for the Public Key Identifier, all generated values MUST be encrypted using the pre-loaded RSAPublicpublic (encryption) key. The newly generated MN_AAATEMP Key and MN_HATEMP MUST be used to calculate the MN-AAA and Mobile-Home Authentication Extensions for the current RRQ. Note: the MN MAY pre-compute the MIP_Key_Data payload by checking whether a payload exists during each MN power-up or application initiation. 10. The MN sends the RRQ with MIP_Key_Data MIP VSE to the PDSN. 11. The PDSN converts the RRQ to a RADIUS ARQ with MIP_Key_Data RADIUS VSA and forwards the ARQ to the home RADIUS AAA Server. The MSID is included in the ARQ. 12. The RADIUS AAA Server compares the authenticated MSID (sent from the PDSN) with the MSID in its subscriber database (associated with the NAI). If MSIDPDSN = MSIDAAA, the RADIUS AAA server, using the Public Key Identifier, determines the appropriate RSA Private key and decrypts the encrypted portion of the MIP_Key_Data payload. The RADIUS AAA Server verifies the MN-AAA Authentication Extension Authenticator using the decrypted MN_AAA key. If successful, the RADIUS AAA Server updates the subscriber profile with the decrypted MN_AAA key, MN_HA key, and CHAP key. The RADIUS AAA Server sets the AAA MIP Update State Field to KEYS UPDATED (2).Dynamic MIP Key Update March 200513. The RADIUS AAA Server sends an Access Reject with AAA_Authenticator RADIUS VSA to the PDSN. 14. The PDSN converts the Access Reject to a MIP RRP with AAA_Authenticator MIP VSE. RRP Code = 89 (Vendor Specific). 15. If AAA_AuthenticatorMN = AAA_AuthenticatorAAA, the MN assigns MN_AAATEMP to MN_AAA key and MN_HATEMP to MN_HA key (MN MIP Update State = KEYS VALID). Otherwise, the MN discards the temporary keys. 16. The MN initiates a new RRQwhichthat is converted to an ARQ by the PDSN and forwarded to the RADIUS AAA Server. 17. The RADIUS AAA Server verifies the MN-AAA Authentication Extension and sets the AAA MIP Update State Field to KEYS VALID (0). The RADIUS AAA Server sends an Access Accept to the PDSN/FA. 18. The PDSN/FA sends the RRQ to the Home Agent (HA). 19. The HA sends an Access Request to the RADIUS AAA Server. The RADIUS AAA Server sends an Access Accept to the HA with the MN_HA key. The HA verifies the Mobile-Home Authentication Extension using the MN_HA key. 20. The HA sends an RRP to thePDSN/FAPDSN/FA, which forwards the RRP to the MN. RRP Code = 0 (Success). 5. DMU Procedure Failure Operation To improve the robustness of the DMU Procedure to account for interruptions due to UDP message loss, RRQ retransmission, or MN failure, the RADIUS AAA Server MUST maintain a MIP Update State Field, for each subscription, in one of three states (0 = KEYS VALID, 1 = UPDATE KEYS, 2 = KEYS UPDATED).Dynamic MIP Key Update March 2005MN PDSN/FA AAAH HA -- ------- ---- -- ---------------- | ---------------- | | MN state = | | | AAAH state = | | | KEYS VALID | | | UPDATE KEYS | | ---------------- | ---------------- | | (A) RRQ | | | |-------------->| ARQ | | | |------------->| | | AR(Key_Update) | | (B) RRP (Key_Update) |<-------------| | |<--------------| | | ---------------- | | | | MN state = | | | | | UPDATE KEYS | | | | ---------------- | | | | (C) RRQ (MIP_Key_Data) | | |-------------->| ARQ (MIP_Key_Data) | | |------------->| | | | ---------------- | | | | AAAH state = | | | | | KEYS UPDATED | | | | ---------------- | | AR (AAA_Auth) | | (D) RRP (AAA_Auth) |<-------------| | |<--------------| | | ---------------- | | | | MN state = | | | | | KEYS VALID | | | | ---------------- | | | | RRQ | | | |-------------->| ARQ | | | |------------->| | | | ---------------- | | | | AAAH state = | | | | | KEYS VALID | | | | ---------------- | | | AA | | | |<-------------| RRQ | | |------------------------------->| | | | ARQ | | | |<----------------| | | | AA | | | |---------------->| | | | RRP | | | RRP |<----------------| |<-----------------------------| | Figure 5. DMU Failure Call Flow with MN and AAA StatesDynamic MIP Key Update March 2005Each step in Figure 5 is described as follows: 1. If (A) is lost, the MN retransmits (A). The RADIUS AAA server expects (A). If the AAA server is in the UPDATE KEYS state, the RADIUS AAA Server sends AR with MIP_Key_Update_RequestVSAVSA, and the PDSN/FA sends (B). 2. If (B) is lost, the MN retransmits (A). The RADIUS AAA server expects (C). If it receives (A), the RADIUS AAA Server sends AR with MIP_Key_Update_RequestVSAVSA, and the PDSN/FA retransmits (B). 3. If (C) is lost, the mobile retransmits (C). The RADIUS AAA server expects (C) and updates the MIP keys appropriately. The RADIUS AAA server transitions to KEYS UPDATED and commits the MIP_Key_Data. The RADIUS AAA Server sends the AR with AAA_AuthenticatorVSAVSA, and the PDSN/FA replies to the MN with (D). 4. If (D) is lost, the mobile retransmits (C) using the same key data sent previously. The RADIUS AAA server expects (A) using the same keys. a. If the RADIUS AAA server receives (C) with the same keys it received previously, it retransmits the AR with AAA_Authenticator VSA and the PDSN replies with (D), containing the AAA_Authenticator. b. If the RADIUS AAA server receives (C) with different keys than it received previously, the RADIUS AAA Server sends AR with MIP_Key_Update_Request VSA, the PDSN/FA retransmits (B), and the RADIUS AAA server transitions to UPDATE KEYS. c. If the RADIUS AAA server receives(A)(A), which fails authentication using the keys sent in (C), the RADIUS AAA Server sends AR with MIP_Key_Update_Request, the PDSN/FA retransmits (B), and the RADIUS AAA server transitions to UPDATE KEYS. 5. Once the PDSN/FA receives (A), forwards the ARQ to the RADIUS AAA server, and the MN-AAA Authenticator is verified using the MN_AAA key, the RADIUS AAA Server transitions to the KEYS VALID state and the DMU process is complete. The AAA DMU state machine is described in Figure 6.Dynamic MIP Key Update March 2005-------------- --------------------->| KEYS VALID |--------------- | Auth success using -------------- Need Key | | MIP_Key_Data Update | | | | Auth failed (invalid keys) | | or RRQ with different MIP_Key_Data | | --------------------------------- | | | | | | | v v ---------------- --------------- | KEYS UPDATED | | UPDATE KEYS | ---------------- --------------- | ^ ^ | | | | | ------- --------------------------------- RRQ with same Got MIP_Key_Data MIP_Key_Data Figure 6. RADIUS AAA Server DMU State Machine 6. cdma2000(R) HRPD/1xEV-DO Support Because the DMU Procedure occurs at the IP Layer, the DMU Procedure supports MIP key distribution in either the cdma2000(R) 1X or HRPD/1xEV-DO network. Because the cdma2000(R) HRPD/1xEV-DO network does not provide Radio Access Network (RAN) authentication, the DMU Procedure is more susceptible to a false MN attack (than in an cdma2000(R) 1X network withCAVECellular Authentication and Voice Encryption (CAVE) RAN authentication). For this reason, the DMU Procedure has the capability to optionally support device-to-network authentication using the MN_Authenticator. The method of MN_Authenticator delivery to the RADIUS AAA server is outside the scope of this document, allowingService Providersservice providers the flexibility to determine the most efficient/least intrusive procedure to support MN authentication during the DMU Procedure.6.16.1. RADIUS AAA Support The RADIUS AAA server MUST support three MN_Authenticator options: 1. Ignore MN_Authenticator Depending on other potential authentication/fraud prevention options (outside the scope of the DMU Procedure), the RADIUS AAA Server MUST have the capability to ignore the MN_Authenticator. For example, when the RADIUS AAA Server decrypts the MIP_Key_Data payload, the AAA Server silently discards the MN_Authenticator.Dynamic MIP Key Update March 20052. Pre-Update Validation Prior to updating a subscription profile with the delivered MIP keys, the RADIUS AAA Server MUST compare the MN_AuthenticatorMN (delivered via the encrypted MIP_Key_Data payload) with the MN_AuthenticatorAAA (possibly delivered via theService Providerservice provider customer care or billing/provisioning system). 3. Post-Update Validation After the DMU Procedure is complete, the RADIUS AAA Server stores the delivered MN_AuthenticatorMN and waits for delivery of the MN_AuthenticatorAAA (via Customer Care,IVR,interactive voice response (IVR), or some other unspecified process). Once the MN_Authenticator is delivered to the RADIUS AAA Server, the AAA MUST compare the MN_AuthenticatorMN (delivered via the encrypted MIP_Key_Data payload) with the MN_AuthenticatorAAA. If the Authenticators match, the RADIUS AAA Server authorizes access and final update of the MIP keys.6.26.2. MN Support The Mobile Node (MN) MUST store the 24-bit MN_Authenticator. The MN MUST display the MN_Authenticator as an 8 decimal digit number (via LCD display on a handset or via a GUI for a modem). If the MN resides within a handset, the user MAY display the MN_Authenticator using the following keypad sequence: "FCN + * + * + M + I + P + RCL". Otherwise, the MN MUST display the MN_Authenticator via the device's GUI. The MN MUST have the capability to reset the MN_Authenticator. In other words, the MN MUST have the capability to randomly/pseudo- randomly generate a new 24-bit MN_Authenticator upon user command, inaccordingaccordance with RFC1750 upon user command.4086. The reset feature mitigates possible compromise of the MN_Authenticator during shipment/storage. If the MN resides within a handset, the user MAY reset the MN_Authenticator using the following keypad sequence: "FCN + * + * + M + I + P + C + C + RCL". Otherwise, the MN MUST reset the MN_Authenticator via the device's GUI. The MN manufacturer MAY pre-load the MN with the MN_Authenticator. For example, by pre-loading the MN_Authenticator and affixing a sticker with the MN_Authenticator (8 decimal digit representation) to the MN(e.g.(e.g., modem), the point-of-sale representative does not have to retrieve the MN_Authenticator from the MN interface. [Optional] The MN MAY maintain a separate primary and secondary queue of MN_Authenticator/MIP_Key_Data Payload pairs. When the MN user resets the primary MN_Authenticator, the MN discards the primaryDynamic MIP Key Update March 2005MN_Authenticator (and any associated MIP_Key_Data Payload) and assigns the MN_Authenticator in the secondary queue as the primary MN_Authenticator (and assigns any associated MIP_Key_Data Payloads to the primary queue). This feature enables the user/provisioner to reset the MN_Authenticator and immediately initiate the DMU procedure without losing the MIP_Key_Data Payload pre-encryption advantage. Upon MN_Authenticator transfer from the secondary to primary queue, the MN MUST generate a new MN_Authenticator and associated MIP_Key_Data Payload for the secondary queue. The MN MUST check both the primary and secondary MN_Authenticator/MIP_Key_Data Payload queues upon power-up or application initiation. The MN MUST maintain at least one MN_Authenticator/MIP_Key_Data Payload pair in each queue.6.36.3. Informative: MN_Authenticator Support MN authentication using the MN_Authenticator gives the service provider the maximum flexibility in determining how to deliver the MN_Authenticator to the RADIUS AAA Server. The method of MN_Authenticator delivery is outside the scope of this document. However, to provide some context as to how the MN_Authenticator may support MN authentication/fraud prevention in the HRPD/1xEV-DO environment, we describe the following possible provisioning scenario. When a subscriber initially acquires their HRPD/1xEV-DO device and service, the point-of-sale representative records the subscription information into the billing/provision system via a computer terminal at the point-of-sale. The billing/provisioning system delivers certain information to the RADIUS AAA Server(e.g.(e.g., NAI, MSID,ESN)Electronic Serial Number (ESN)) including theMN_AuthenticatorMN_Authenticator, which the point-of-sale representative retrieves via the MN device's display. In the case of a modem, the manufacturer may havepre-loadedpre- loaded the MN_Authenticator and placed a copy of the MN_Authenticator on a sticker attached to the modem. The point-of-sale representative simply copies the 8 decimal digit value of the MN_Authenticator into the customer profile. Once the MN is loaded with the proper NAI and powered-up, the MN initiates the DMU Procedure with the RADIUS AAA Server. The RADIUS AAA Server compares the MN-delivered MN_Authenticator with thebilling system deliveredbilling-system-delivered MN_Authenticator. If the authenticators match, the RADIUS AAA Server updates the subscriber profile with the delivered MIP keys and authorizes service. If the Post-Update option is enabled within the RADIUS AAA Server, the RADIUS AAA Server tentatively updates the subscription profile until it receives the MN_Authenticator via the billing/provision system. As another option, theService Providerservice provider MAY use an IVR system in which the HRPD/1xEV-DO subscriber calls a provisioning number andDynamic MIP Key Update March 2005inputs the MN_Authenticator. The IVR system then delivers the MN_Authenticator to the RADIUS AAA Server for final validation and Packet Data Access. 7. Security Considerations The DMU Procedure is designed to maximize the efficiency of MIP key distribution while providing adequate key distribution security. The following provides a description of potential security vulnerabilities and their relative risk to the DMU Procedure:7.17.1. Cryptographic Key Generation by the MN Because the MN is required to properly generate the MN_AAA, MN_HA, and CHAP key, the MN must perform cryptographic key generation in accordance with accepted random/pseudo-random number generation procedures. MN manufacturers MUST comply with RFC17504086 [12]guidelinesguidelines, andService Providersservice providers SHOULD ensure that manufacturers implement acceptable key generation procedures. The use of predictable cryptographic keys could be devastating to MIP security. However, the risk of not using acceptable random/pseudo-random key generation is minimal as long as MN manufacturers adhere to RFC17504086 guidelines. Furthermore, if a key generation flaw is identified, the flaw appears readily correctable via a software patch, minimizing the impact.7.27.2. Man-in-the-Middle Attack The DMU procedure is susceptible to a Man-in-the-Middle (MITM)attack, howeverattack; however, such an attack appears relatively complex and expensive. WhenAKAAuthentication and Key Agreement (AKA) is deployed within cdma2000(R) 1X, the MITM Attack will be eliminated. The risk of an MITM Attack is minimal due to required expertise, attack expense, and impending cdma2000(R) 1X mutual authentication protection. If a particular cdma2000(R) 1X network does not support A-key authentication, the MN_Authenticator MAY optionally be used.7.37.3. RSA Private Key Compromise Because one RSA Private key may be associated with millions of MNs (RSAPublic Key),public key), it is important to protect the RSA Private key from disclosure to unauthorized parties. Each MN manufacturer MUST establish adequate security procedures/policies regarding the dissemination of the RSA Private key. RSA Private keys SHOULD be distributed to legitimate cdma2000(R) service providers only. It is acceptable foraan MN manufacturer to distribute the same RSAPrivateprivate key to multiple service providers to enable MIP key update. However, each service provider MAY generate their own RSAPublic/Privatepublic/private key pair and require the MN manufacturer to include their own RSAPublic Dynamic MIP Key Update March 2005public key in a specific software patch if compromise of the RSA Private key is a significant concern.7.47.4. RSA Encryption Several vulnerabilities have been identified in certain implementations ofRSA, howeverRSA; however, they do not appear applicable to the DMU Procedure.7.57.5. False Base Station/PDSN The MN appears to be protected against aFalsefalse BS denial-of-service (DOS) attack, since only the proper RADIUS AAA server can recover the AAA_Authenticator. This method of preventing a false base station attack assumes security of the network messaging between the AAA and the serving system, as discussed in Section 7.9.7.67.6. cdma2000(R) 1X False MN The cdma2000(R) 1X network appears adequately protected against a false MN by IS-2000 challenge-response authentication. If DMU is used outside the cellular domain, equivalent authentication procedures are required for the same level of security.7.77.7. HRPD/1xEV-DO False MN The 1xEV-DO RADIUS AAA Server MAY optionally authenticate the MN using the MN_Authenticator to prevent a fraudulent MN activation.7.87.8. Key Lifetimes There is no explicit lifetime for the keys distributed by DMU. The lifetime of the keys distributed by DMU is determined by the system operator through the RADIUS AAA server. The MN_AAA and MN_HA key lifetimes can be controlled by initiating an update as needed. Furthermore, the DMU process is protected against false initiation because the MN cannot initiate DMU. This makes it unworkable to provide an explicit lifetime to the MN, since the MN cannot take any action to renew the keys after expiration.7.97.9. Network Message Security The security of the MN-HA keys delivered from the RADIUS AAA server to the MIP home agent requires confidentiality for network messages containing such keys. The specification of security requirements for network messages is the responsibility of the operator, and is outside the scope of this document. (Note that similar considerationsDynamic MIP Key Update March 2005apply to the distribution of Shared Secret Data, which is already transmitted between nodes in the ANSI-41 network.) If DMU is used outside the domain of a cellular operator, RADIUS security features MAY be used, including the Request-Authenticator and Response-Authenticator fields defined in [4] and the Message- Authenticator attribute defined in [13]. 8. Verizon Wireless RADIUS Attributes Three new RADIUS Attributes are required to support the DMU Procedure and are specified as follows: Type: 26 Length: >9 Verizon Wireless Enterprise/Vendor ID: 12951 MIP_Key_Update_Request: ---------------------- The Home RADIUS AAA Server includes this attribute to indicate that MIP key update is required. Vendor-Type = 1 Vendor-Length = 3 bytesVendor-Value=Vendor-Value = PKOID of the RADIUS AAA Server MIP_Key_Data: ------------ Key data payload containing the encrypted MN_AAA key, MN_HA key, CHAP key, MN_Authenticator, and AAA_Authenticator. This payload also contains the Public Key Identifier. Vendor-Type = 2 Vendor-Length = 134 bytes NOTE: Vendor-Length depends on the size of the RSA modulus. For example, when RSA-512 is used, Vendor-Length = 70 bytes.Vendor-Value=Vendor-Value = 128 byte RSA encryption payload (when 1024-bit RSAused)used), which contains encrypted MN_AAA key, MN_HA key, CHAP key, MN_Authenticator, and AAA_Authenticator. The four (4) byte Public Key Identifier is concatenated to the encrypted payload. AAA_Authenticator: ----------------- The 64-bit AAA_Authenticator value decrypted by the Home RADIUS AAA Server.Dynamic MIP Key Update March 2005Vendor-Type = 3 Vendor-Length = 10 bytesVendor-Value=Vendor-Value = decrypted AAA_Authenticator from Home RADIUS AAA Server. Public Key Invalid: ------------------ The home RADIUS AAA Server includes this attribute to indicate that thePublicpublic key used by the MN is not valid. Vendor-Type = 4 Vendor-Length = 2 bytesVendor-Value=Vendor-Value = none. Note: An Organization may define RADIUS VSAs usingtheirits own Organization identifier. 9. Verizon Wireless Mobile IP Extensions Three Verizon Wireless Mobile IP Vendor/Organization-Specific Extensions(VSE)(VSEs) (RFC 3115), required to support the DMU Procedure, are specified as follows: Type: 38 (CVSE-TYPE-NUMBER) Verizon Wireless Vendor ID: 12951 (high-order octet is 0 and low order octets are the SMI Network Management Private Enterprise Code of the Vendor in the network byte order, as defined by IANA). 0 7 8 15 16 31 --------------------------------------------------- | Type | Reserved | Length | --------------------------------------------------- | Vendor/Org-ID | --------------------------------------------------- | Vendor-CVSE-Type | Vendor-CVSE-Value ... | --------------------------------------------------- Figure 7. CriticalVendor/Organization SpecificVendor/Organization-Specific Extension MIP_Key_Request: --------------- The Home RADIUS AAA Server includes this extension to indicate that MIP key update is required. Length = 7Dynamic MIP Key Update March 2005NOTE: The RFC 3115 Editor has stated that the Reserved field is not included in the length determination. Vendor-CVSE-Type = 1Vendor-CVSE-Value=Vendor-CVSE-Value = PKOID sent in the RADIUS MIP_Key_Update_Request attribute. MIP_Key_Data: ------------ Key data payload containing encrypted MN_AAA key, MN_HA key, CHAP key, MN_Authenticator, and AAA_Authenticator. This payload also contains the Public Key Identifier. Length = 138 NOTE: Length depends on the size of the RSA modulus. For example, when RSA-512 is used, Length = 74 bytes. Vendor-CVSE-Type = 2Vendor-CVSE-Value=Vendor-CVSE-Value = 128 byte RSA encryption payload (when 1024-bit RSA used) which contains encrypted MN_AAA key, MN_HA key, CHAP key, MN_Authenticator, and AAA_Authenticator. The four (4) byte Public Key Identifier and DMUV is concatenated to the encrypted payload. AAA_Authenticator: ----------------- The 64-bit AAA_Authenticator value decrypted by the Home RADIUS AAA Server. Length = 14 bytes Vendor-CVSE-Type = 3Vendor-CVSE-Value=Vendor-CVSE-Value = decrypted AAA_Authenticator from the Home RADIUS AAA Server. Public Key Invalid: ------------------ The Home RADIUS AAA Server includes this extension to indicate that thePublicpublic key used by the MN is not valid. Length = 6 bytes Vendor-CVSE-Type = 4Vendor-CVSE-Value=Vendor-CVSE-Value = none. Note: An Organization may define VSEs using their own Organization identifier. 10. Public Key Identifier and DMU VersionDynamic MIP Key Update March 2005The Public Key Identifier (Pub_Key_ID) is used during the Dynamic Mobile IP Update (DMU) procedure to allow the RADIUS AAA Server to distinguish between differentPublicpublic keys (which may be assigned by different manufacturers, service providers, or other organizations). The Public Key Identifier consists of the PKOID, PKOI, PK_Identifier, and ATV fields. The DMU Version field enables subsequent revisions of the DMU procedure. ---------------------------------------------- | PKOID | PKOI | PK_Expansion | ATV | DMUV | ---------------------------------------------- 0 7 8 15 16 23 24 27 28 31 Figure 8. Public Key Identifier and DMUV Each Public Key Organization (PKO) MUST be assigned a Public Key Organization Identifier (PKOID) to enable the RADIUS AAA Server to distinguish between differentPublicpublic keys created by different PKOs (see Table 1). If aService Providerservice provider does not provide the MN manufacturer with a (RSA)Publicpublic key, the manufacturer MUST generate a unique RSA Public/Private key pair and pre-load each MN with the RSAPublicpublic key (1024-bit modulus by default). The manufacturer MAY share the same RSA Private key with multipleService Providersservice providers as long as reasonable security procedures are established and maintained (by the manufacturer) to prevent disclosure of the RSA Private (decryption) key to an unauthorized party. The Public Key Organization Index (PKOI) is an 8-bit field whose value is defined at the discretion of the PKO. For example, a device manufacturer MAY incrementally assign a new PKOI for each Public/Private key pair when the pair is created. The PK_Expansion field enables support for additional PKOs or expansion of the PKOI. The DMU Version field allows for DMU Procedure version identification (see Table 2). The Algorithm Type and Version (ATV) field allows for identification of thePublic Keypublic key algorithm and version used (see Table 3).Dynamic MIP Key Update March 2005Table 1. Public Key Organization Identification Table PKOID Public Key PKOID Public Key (HEX) Organization (PKO) (HEX) Organization (PKO) ----- ------------------ ----- ------------------ 00 RESERVED 40 Sanyo Fisher Company 01 RESERVED 41 Sharp Laboratories of America 02 RESERVED 42 Sierra Wireless, Inc. 03 RESERVED 43 Sony Electronics 04 RESERVED 44 Synertek, Inc. 05 RESERVED 45 Tantivy Communications, Inc. 06 RESERVED 46 Tellus Technology, Inc. 07 RESERVED 47 Wherify Wireless, Inc. 08 RESERVED 48 Airbiquity 09 RESERVED 49 ArrayComm 0A Verizon Wireless 4A Celletra Ltd. 0B AAPT Ltd. 4B CIBERNET Corporation 0C ALLTEL Communications 4C CommWorks Corporation, a 3Com Company 0D Angola Telecom 4D Compaq Computer Corporation 0E Bell Mobility 4E ETRI 0F BellSouth International 4F Glenayre Electronics Inc. 10 China Unicom 50 GTRAN, Inc. 11 KDDI Corporation 51 Logica 12 Himachal Futuristic 52 LSI Logic Communications Ltd. 13 Hutchison Telecom (HK), 53 Metapath Software Ltd. International, Inc. 14 IUSACELL 54 Metawave Communications 15 Komunikasi Selular 55 Openwave Systems Inc. Indonesia (Komselindo) 16 Korea Telecom Freetel, 56 ParkerVision, Inc. Inc. 17 Leap 57 QUALCOMM, Inc. 18 LG Telecom, Ltd. 58 QuickSilver Technologies 19 Mahanagar Telephone Nigam 59 Research Institute of Limited (MTNL) Telecommunication Transmission, MII (RITT) 1A Nextel Communications, 5A Schema, Ltd. Inc. 1B Operadora UNEFON SA de CV 5B SchlumbergerSema 1C Pacific Bangladesh 5C ScoreBoard, Inc. Telecom Limited 1D Pegaso PCS, S.A. DE C.V. 5D SignalSoft Corp.Dynamic MIP Key Update March 2005PKOID Public Key PKOID Public Key (HEX) Organization (PKO) (HEX) Organization (PKO) ----- ------------------ ----- ------------------ 1E Pele-Phone 5E SmartServ Online, Communications Ltd. Inc. 1F Qwest 5F TDK Corporation 20 Reliance Infocom Limited 60 Texas Instruments 21 Shinsegi Telecomm, Inc. 61 Wherify Wireless, Inc. 22 Shyam Telelink Limited 62 Acterna 23 SK Telecom 63 Anritsu Company 24 Sprint PCS 64 Ericsson 25 Tata Teleservices Ltd. 65 Grayson Wireless 26 Telecom Mobile Limited 66 LinkAir Communications, Inc. 27 Telstra Corporation 67 Racal Instruments Limited 28 Telus Mobility Cellular, 68 Rohde & Schwarz Inc. 29 US Cellular 69 Spirent Communications 2A 3G Cellular 6A Willtech, Inc. 2B Acer Communication & 6B Wireless Test Systems Multimedia Inc. 2C AirPrime, Inc. 6C Airvana, Inc. 2D Alpine Electronics, Inc. 6D COM DEV Wireless 2E Audiovox Communications 6E Conductus, Inc. Corporation 2F DENSO Wireless 6F Glenayre Electronics Inc. 30 Ditrans Corporation 70 Hitachi Telecom (USA), Inc. 31 Fujitsu Network 71 Hyundai Syscomm Inc. Communication, Inc. 32 Gemplus Corporation 72 ISCO 33 Giga Telecom Inc. 73 LG Electronics, Inc. 34 Hyundai CURITEL, Inc. 74 LinkAir Communications, Inc. 35 InnovICs Corp 75 Lucent Technologies, Inc. 36 Kyocera Corporation 76 Motorola CIG 37 LG Electronics, Inc. 77 Nortel Networks 38 LinkAir Communications, 78 Repeater Technologies Inc. 39 Motorola, Inc. 79 Samsung Electronics Co., Ltd. 3A Nokia Corporation 7A Starent Networks 3B Novatel Wireless, Inc. 7B Tahoe Networks, Inc. 3C OKI Network Technologies 7C Tantivy Communications, Inc.3D Pixo 7D WaterCove Networks Dynamic MIP Key Update March 2005PKOID Public Key PKOID Public Key (HEX) Organization (PKO) (HEX) Organization (PKO) ----- ------------------ ----- ------------------ 3D Pixo 7D WaterCove Networks 3E Research In Motion 7E Winphoria Networks, Inc. 3F Samsung Electronics 7F ZTE Corporation Co., Ltd. Note: 80 through FF will be assigned by the PKOID administrator(TBD).(Verizion Wireless). Table 2. DMU Version DMU Version DMU Version Value ----------- ----------- 00 RFCXXXX4784 01TBDReserved 02TBDReserved 03TBDReserved 04TBDReserved 05TBDReserved 06TBDReserved 07 Cleartext Mode Table 3. Algorithm Type and Version ATV Public Key Algorithm Value Type and Version ----- -------------------- 00 Reserved 01 RSA - 1024 02 RSA - 768 03 RSA - 2048 04TBDReserved 05TBDReserved 06TBDReserved 07TBDReserved 11. Conclusion The Dynamic Mobile IPkeyKey Update (DMU) Procedure enables the efficient, yet secure, delivery of critical Mobile IP cryptographic keys. The use of cryptographickeys, hencekeys (and hence, the bootstrapping of such MIP keys using the DMUProcedure,Procedure) is essential to commercial delivery of Mobile IP service inCDMA 2000cdma2000 1xRTT and HRPD/1xEV-DO networksnetworksor other networks that utilize Mobile IP. 12.Formal Syntax Dynamic MIP Key Update March 2005 None.Normative References1[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119,Internet Engineering Task Force,March1997 21997. 13. Informative References [2] TIA/EIA/IS-2000 Series, Revision A, Telecommunications Industry Association, March2000 32000. [3] TIA/EIA/IS-856,cdma2000cdma2000(R) High Rate Packet Data Air Interface Specification, Telecommunications Industry Association, November2000 4 Rigner, C, et al.,2000. [4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service(RADIUS),"(RADIUS)", RFC 2865,IETF Network Working Group,June 2000.5[5] Calhoun,P, et al.,P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter BaseProtocol,"Protocol", RFC 3588,IETF Network Working Group,September 2003.6[6] TIA/EIA/IS-835-A,cdma2000cdma2000(R) Wireless IP Network Standard, Telecommunications Industry Association, May2001 72001. [7] ANSI/TIA/EIA-41-D-97, Cellular Radiotelecommunications Intersystem Operations, Telecommunications Industry Association, December 19978[8] ANSI/TIA/EIA-683-B-2001, Over-the-Air Service Provisioning of Mobile Stations in Spread Spectrum Systems, Telecommunications Industry Association, December 20019[9] Jonsson, J. and B.Kaliski. PKCSKaliski, "Public-Key Cryptography Standards (PKCS) #1: RSAEncryptionCryptography Specifications Version1.5.2.1", RFC2313, Internet Engineering Task Force, March 1998. 10 G.3447, February 2003. [10] Dommety, G. and K.Leung. MobileLeung, "Mobile IPVendor/Organization-Specific Extensions.Vendor/Organization- Specific Extensions", RFC 3115,Internet Engineering Task Force,April2001 11 TIA/EIA-IS-634-A,2001. [11] TIA-2001-A, Interoperability Specifications (IOS) forcdma2000cdma2000(R) Access Network Interfaces, Telecommunications Industry Association, August2001 12 D.2001. [12] Eastlake, D., 3rd, Schiller, J., and S. Crocker,and J. Schiller. Randomness Recommendations"Randomness Requirements forSecurity.Security", BCP 106, RFC1750, Internet Engineering Task Force, December 1994. 13 C.4086, June 2005. [13] Rigney,W.C., Willats, W., and P.Calhoun. RADIUS Extensions.Calhoun, "RADIUS Extensions", RFC 2869,Internet Engineering Task Force, June,June 2000.Dynamic MIP Key Update March 200514. Acknowledgments Thanks to Jeffrey Dyck (Qualcomm), James Willkie (Qualcomm), Jayanth Mandayam (Qualcomm), Marcello Lioy (Qualcomm), Michael Borella (CommWorks), Cliff Randall (CommWorks), Daniel Cassinelli (CommWorks), Edward Dunn (CommWorks), Suresh Sarvepalli (CommWorks), Gabriella Ambramovici (Lucent), Semyon Mizikovsky (Lucent), Sarvar Patel (Lucent), Peter McCann (Lucent), Ganapathy Sundaram (Lucent), Girish Patel (Nortel), Glen Baxley (Nortel), Diane Thompson (Ericsson), BrianHickman(Ericsson),Hickman (Ericsson), Somsay Sychaleun (Bridgewater), Parm Sandhu (Sierra Wireless), Iulian Mucano (Sierra Wireless), and Samy Touati (Ericsson) for their useful discussions and comments.Author's Addresses Christopher Carroll* Ropes & Gray LLP Fish & Neave IP Group One International Place Boston, MA 02110 Phone: 617-951-7756 Email: Christopher.Carroll@ropesgray.com *formerly with Verizon Wireless Frank Quick Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA Phone: 858-658-3608 Email: fquick@qualcomm.com Dynamic MIP Key Update March 2005 13.Appendix-A: Cleartext-Mode Operation DMU supports a cleartext mode for development testing where DMUV = 7. The MIP_Key_Data payload will assume the same size as if RSA 1024-bit encryption were applied to the payload. In this mode, the MIP_Key_Data RADIUS Attribute and MIP Vendor Specific Extension will be 134 bytes and 138 bytes inlengthlength, respectively. Thus, in cleartext mode, the payload MUST consist of 48 bytes of keys (MN_AAA, MN_HA, and CHAP key),8 byte8-byte AAA_Authenticator,3 byte3-byte MN_Authenticator. The next 69 bytes will be padded with "0" bits. MIP_Key_Data = MN_AAAH key, MN_HA key, CHAP_key, MN_Authenticator, AAA_Authenticator, Padding (69 bytes), Public_Key_IDi, DMUV Where: MN_AAA key = 128-bit random MN / RADIUS AAA Server key. MN_HA key = 128-bit random MN / Home Agent (HA) key. CHAP_key = 128-bit random Simple IP authentication key. MN_Authenticator = 24-bit random number. AAA_Authenticator = 64-bit random number used by MN to authenticate the RADIUS AAA Server. Padding = 69 bytes of 0's. DMU Version (DMUV) =4 bit4-bit identifier of DMU version. Public Key Identifier (Pub _Key_ID) = PKOID, PKOI, PK_Expansion, ATV Where: Public Key Organization Identifier (PKOID) = 8-bit serial number identifier of the Public Key Organization (PKO) that created the Public Key. Public Key Organization Index (PKOI) = 8-bit serial number used at PKO discretion to distinguish different Public/Private key pairs. PK_Expansion = 8-bit field to enable possible expansion of PKOID or PKOI fields. (Note: Default value = 0xFF) Algorithm Type and Version (ATV) = 4-bit identifier of the algorithm used.Dynamic MIP Key Update March 2005 NoticesAuthors' Addresses Christopher Carroll* Ropes & Gray LLP Fish & Neave IP Group One International Place Boston, MA 02110 Phone: 617-951-7756 EMail: Christopher.Carroll@ropesgray.com * This document was developed while at Verizon Wireless. Frank Quick Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA Phone: 858-658-3608 EMail: fquick@qualcomm.com Full Copyright Statement Copyright (C) TheInternet Society (2005).IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP78,78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNETSOCIETYSOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.