[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 RFC 4784

   Internet Draft                                           C. Carroll,
                                                               F. Quick
   Document:                                           Hamilton, Brook,
   draft-carroll-dynmobileip-cdma-02.txt              Smith & Reynolds,
                                                                  P.C.,
                                                          Qualcomm Inc.
   Expires: May 2004                                      November 2003


                       Dynamic Mobile IP Key Update
                                    for
                           cdma2000(R) Networks



Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   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.

Abstract

   The Dynamic Mobile IP Key Update procedure is a secure and efficient
   mechanism for distributing and updating Mobile IP (MIP) cryptographic
   keys in cdma2000(R) networks (including High Rate Packet Data which
   is often referred to as 1xEV-DO).  Because the Dynamic Mobile IP Key
   Update (DMU) procedure occurs at the IP layer directly between the
   MIP MN and RADIUS or DIAMETER AAA Server, DMU may be used to securely
   bootstrap the MN-AAA key (and other cryptographic keys) in MIP
   networks using any Radio Access Network technology.



   cdma2000(R) is a registered trademark of the Telecommunications
   Industry Association (TIA).

Carroll                  Expires - May 2004                  [Page 1]


                       Dynamic MIP Key Update           November 2003


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...................................................3
   2. Basic Dynamic MIP Key Update Mechanism.........................3
      2.1 RSA Encrypted Key Distribution.............................3
      2.2 Shared Mutual Authentication...............................4
      2.3 Encrypted Password / Encrypted One-Time Password
      Authentication.................................................7
   3. Dynamic MIP Key Update Advantages over OTASP...................8
   4. Detailed DMU Procedure Description and Requirements............9
      4.1 RSA Public Key Cryptography................................9
      4.2 Other Public Key Algorithms...............................10
      4.3 Why no Public Key Infrastructure (PKI)?...................10
      4.4 Cryptographic Key Generation..............................10
      4.5 MIP_Key_Data Payload......................................11
      4.6 RSA Key Management........................................12
      4.7 RADIUS AAA Server.........................................13
      4.8 MN (Handset or Modem).....................................15
      4.9 PDSN / Foreign Agent (FA).................................16
      4.10 Home Agent (HA)..........................................17
      4.11 DMU Procedure Network Flow...............................18
   5. DMU Procedure Failure Operation...............................22
   6. cdma2000(R) HRPD/1xEV-DO Support..............................25
      6.1 RADIUS/DIAMETER AAA Support...............................25
      6.2 MN Support................................................26
      6.3 Informative MN_Authenticator Support......................27
   7. Security Considerations.......................................28
      7.1 Cryptographic Key Generation by the MN....................28
      7.2 Man-in-the-Middle Attack..................................28
      7.3 RSA Private Key Compromise................................28
      7.4 RSA Encryption............................................29
      7.5 False Base Station/PDSN...................................29
      7.6 cdma2000(R) 1X False MN...................................29
      7.7 HRPD/1xEV-DO False MN.....................................29
   8. Verizon Wireless - Specific RADIUS Attributes.................29
   9. Verizon Wireless Mobile IP Vendor/Organization-Specific Extensions
   .................................................................30
   10. Public Key Identifier and DMU Version........................32
   11. Intellectual Property........................................36
   12. Conclusion...................................................37
   13. Formal Syntax................................................37
   14. Appendix - Cleartext-Mode Operation..........................39



Carroll                  Expires - May 2004                  [Page 2]


                       Dynamic MIP Key Update           November 2003


1. Introduction

   The Dynamic Mobile IP Key Update procedure is a secure and efficient
   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 at the IP layer directly between the MIP MN and
   RADIUS or DIAMETER AAA Server.  This procedure is an add-on to the
   existing Telecommunications Industry Association (TIA) TR-45 Standard
   IS-835 [4].  DMU, however, may be performed in any MIP network to
   enable secure and efficient bootstrapping of the shared secret
   between the Mobile Node (MN) and Radius AAA Server, MN-AAA key (and
   other cryptographic keys).

   The DMU procedure utilizes RSA Public 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 RSA Public key.

   By leveraging the existing cdma2000(R) 1X authentication process, the
   Dynamic Mobile IP Key Update process employs a Shared Mutual
   Authentication mechanism in which device-to-network authentication is
   facilitated using cdma2000(R) 1X challenge-response authentication
   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 the CHAP key) and pre-encrypt the MIP keys
   prior to initiation of the DMU procedure.  By employing this pre-
   computation capability, the DMU process is an order of magnitude more
   efficient than Diffie-Hellman Key Exchange.

2. Basic Dynamic MIP Key Update Mechanism

   The DMU procedure is basically an Authentication and Key Distribution
   (AKD) protocol which is more easily understood by separately
   describing the mechanism's two functional goals: 1) encrypted key
   distribution and 2) shared mutual authentication.

2.1 RSA Encrypted Key Distribution

   By utilizing RSA Public Key Cryptography, millions of MNs can be pre-
   loaded with a common RSA Public (encryption) key (by the MN
   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 RSA
   Public/Private key pair and only distribute the RSA Public key to MN
   manufacturers for pre-loading of MNs.




Carroll                  Expires - May 2004                  [Page 3]


                       Dynamic MIP Key Update           November 2003


   During the manufacturing process, the MN manufacturer pre-loads each
   MN with the RSA Public 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 RSA Public key
   to encrypt the payload information, 3) and appends the payload to the
   MIP Registration Request.  When the Radius AAA Server receives the
   encrypted payload (defined as MIP_Key_Data later), 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 Distribution

2.2 Shared Mutual Authentication

   Mutual authentication is achieved by delegation of the MN/device
   authentication by the AAA Server to cdma2000(R) 1X HLR/AC [5] while
   the MN utilizes RSA encryption to authenticate the AAA Server.

   MN/device authentication is based on the assumption that the MN's
   Mobile Station (MS) has an existing A-key and SSD with the
   cdma2000(R) 1X network.  When MS call origination occurs, the AC


Carroll                  Expires - May 2004                  [Page 4]


                       Dynamic MIP Key Update           November 2003


   authenticates the MS.  If authentication is successful, the BS passes
   the MSID (e.g. MIN) to the PDSN.  The "Authenticated MSID" is then
   included in the Radius Access Request (ARQ) message sent from the
   PDSN to the AAA server.  Because the Radius AAA stores the MSID
   associated with an MN subscription, the AAA server is able to
   "Authorize" MN access if the "Authenticated MSID" matches the RADIUS
   AAA MSID, i.e. the RADIUS AAA 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 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 AAA Server), the MN is assured
   that it is not interacting with a false Base Station (BS).

   Because cdma2000(R) A-key/SSD authentication is not available in
   1xEV-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 to optionally
   authenticate the MN (in 1XEV DO network only).




























Carroll                  Expires - May 2004                  [Page 5]


                       Dynamic MIP Key Update           November 2003


           MN           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. Shared Mutual Authentication



Carroll                  Expires - May 2004                  [Page 6]


                       Dynamic MIP Key Update           November 2003


2.3 Encrypted Password / Encrypted One-Time Password Authentication

   The DMU procedure alternatively utilizes a password, the
   MN_Authenticator, to support MN authentication in cdma2000(R)
   HRPD/1xEV-DO or whenever 1X RAN authentication (e.g. CAVE) is not
   available.  Furthermore, 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-Time Password,
   however, RSA encryption allows the MN_Authenticator to possibly be
   re-used based on each Service Provider's key distribution policy.

   When the encrypted MIP keys are decrypted at the Home AAA Server, the
   MN_Authenticator is also decrypted and compared with a copy of the
   MN_Authenticator stored within the AAA Server.  The Home 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, and delivered along with the NAI, via
   the billing/provision system to the Home AAA server, or 2) verbally
   communicated to a customer care representative via a call, or 3)
   input by the user interfacing with an IVR.  The out-of-band
   MN_Authenticator delivery is purposely precluded from the standard to
   maximize the Service Provider's implementation flexibility.

   It is possible for an unscrupulous provisioner or distribution
   employee to extract the MN_Authenticator prior to the DMU procedure,
   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 MN user, however it MAY be initially pre-loaded by
   the manufacturer.  When the MN_Authenticator is reset (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 by
   the MN user.  Thus, the MN will generate new MIP_Key_Data payloads
   using the same MN_Authenticator until the MN_Authenticator is
   updated.





Carroll                  Expires - May 2004                  [Page 7]


                       Dynamic MIP Key Update           November 2003


                                         -------------------------
                                        |  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    |
                                        |  Payload using          |
                                        |  MN_Authenticator[y]    |
                                         -------------------------
                                                    |
                                                    v
    -----------------------------        -------------------------
   |  KEYS_VALID and committed;  |      |  Generate MIP_Key_Data  |
   |  delete MIP_Key_Data        |----->|  Payload using          |
   |  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 provisioner burden of accessing a
   device such as a modem to recover the MN_Authenticator for entry into
   the Serivce 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) [6] procedure including:

      *  MIP key distribution occurs directly between the MN and AAA
         Server at the IP Layer.  Eliminates the need for an interface
         between the OTAF and AAA server.


Carroll                  Expires - May 2004                  [Page 8]


                       Dynamic MIP Key Update           November 2003



      *  Supports MIP key distribution for cdma2000(R) 1X and HRPD/1xEV-
         DO MN.  OTASP only supports cdma2000(R) 1X MIP key
         distribution.

      *  Facilitates MIP key distribution to MN using Relay-mode MS.
         OTASP only delivers MIP keys to MS.  For example, OTASP cannot
         delivery MIP keys to Laptop MN interfacing with MS modem.

      *  Pre-encryption of MIP_Key_Data allows DMU procedure to be order
         of magnitude faster than Diffie-Hellman Key Exchange.

      *  MN manufacturer can pre-generate MIP keys, pre-encrypt the MIP
         key payload, and pre-load the payload in an 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.

      *  MN is protected against False BS Denial-of-Service (DOS) attack
         in which False BS changes the MIP key for MNs in its vicinity.
         OTASP Diffie-Hellman Key Exchange vulnerable to BS DOS.

      *  Utilizes mutual authentication.  OTASP Diffie-Hellman Key
         Exchange does not utilize authentication.

4. Detailed DMU Procedure Description and Requirements

   The Dynamic Mobile IP Update procedure is a secure, yet extremely
   efficient mechanism for distributing essential MIP cryptographic keys
   (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 Pubic Key Infrastructure (PKI) Certificates in order to
   greatly enhance the procedure's efficiency using MIP_Key_Data pre-
   encryption within the MN.

4.1 RSA Public Key Cryptography

   RSA Public Key encryption and decryption MUST be performed in
   accordance with RFC 2313 [7] 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-bit RSA depending on the MN user's
   efficiency or security requirements.  RSA computation speed-ups using
   low exponent RSA or the value "65537" are acceptable.






Carroll                  Expires - May 2004                  [Page 9]


                       Dynamic MIP Key Update           November 2003


4.2 Other Public Key Algorithms

   DMU does not preclude the use of other Public key technologies.  The
   protocol includes a Public Key Type field that defines the type of
   encryption used.

4.3 Why no Public Key Infrastructure (PKI)?

   DMU is designed to maximize the efficiency of Mobile IP (MIP) key
   distribution for cdma2000(R) MNs.  The use of a Public key
   Certificate would improve the flexibility of the MIP key update
   process by allowing a Certificate Authority (CA) to vouch for the RSA
   Public Key delivered to the MN.  Unfortunately, the use of 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's Public Key.  During the MIP key
   distribution process, the network must first deliver its RSA Public
   Key (in a 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 communications
   model such as within the Internet where many different users
   interface with many different Websites.  However, in the cellular/PCS
   Packet Data environment, a Many-to-One (or few) distribution model
   exists in which many users interface with one wireless Carrier to
   establish their Mobile IP security associations (i.e cryptographic
   keys).

4.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 RFC 1750 Randomness
   Recommendations for Security.

   Although it may be more secure for the network to generate
   cryptographic keys at the AAA server, client cryptographic key
   generation is acceptable due to the significant efficiency



Carroll                  Expires - May 2004                 [Page 10]


                       Dynamic MIP Key Update           November 2003


   improvement in the update process via pre-generation and pre-
   encryption of the MIP keys.

4.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 (See IETF RFC
   3115 [8] 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.

   Upon receipt of the Radius Access Request, the Radius AAA decrypts
   the MIP_Key_Data payload using the RSA Private (decryption) key
   associated with the RSA Public (encryption) used to encrypt the
   MIP_Key_Data payload.  The MIP_Key_Data is defined as follows:

   MIP_Key_Data = RSA Pub_Keyi [MN_AAAh key, MN_HA key, CHAP_key,
   MN_Authenticator, AAA_Authenticator], Public_Key_IDi, DMUV

   Where:

      MN_AAA key = 128-bit random MN / 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 as not the same as the AT-CHAP key
         used for A12 Interface authentication [9].

      MN_Authenticator = 24-bit random number (displayed as 8 decimal
         digit number.  To be used for 1xEV DO network.) (encrypted)

      AAA_Authenticator = 64-bit random number used by MN to
         authenticate AAA Server. (encrypted)

      DMU Version (DMUV) = 4 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 Public Key Organization (PKO) that created the
         Public Key.


Carroll                  Expires - May 2004                 [Page 11]


                       Dynamic MIP Key Update           November 2003



      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.

   Note: If 1024-bit RSA is used, the encrypted portion of the payload
   is 1024 bits (128 bytes) long.  With the 28 bit Public Key Identifier
   and 4 bit DMUV, the total MIP_Key_Data payload is 132 bytes long.

4.6 RSA Key Management

   The wireless Service Provider or carrier MUST generate the RSA
   Public/Private key pair(s).  An organization within the Service
   Provider MUST be designated by the Service Provider to generate,
   manage, protect, and distribute RSA Private keys (to the AAA Server)
   and Public keys (to the MN manufacturers) in support of the DMU
   procedure.

   Each RSA Public/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.  The Service Provider organization with the responsibility
   of generating the RSA Public/Private key pairs MUST establish a RSA
   key management policy to protect the RSA Private (decryption) keys.

   RSA Public keys MAY be freely distributed to all MN manufacturers
   (along with the Public Key Identifier).  Because one RSA Public key
   can be distributed to million of MNs, it is acceptable to distribute
   the RSA Public key (and Public Key Identifier) to MN manufacturers
   via e-mail, floppy disk, or VZW Website.  The preferred method is to
   simply publish the RSA Public key and associated Public Key
   Identifier in the DMU Requirements document sent to each MN
   manufacturer/OEM.

   RSA Private keys MAY be loaded into the RADIUS AAA server manually.
   Access to the RADIUS AAA Server RSA Private keys SHOULD be restricted
   to authorized personnel only.

   The wireless Service Provider MAY accept RSA Private key(s) (and
   Public Key Identifier) from MN manufacturers or other Service
   Providers that have preloaded MNs with manufacturer-generated RSA


Carroll                  Expires - May 2004                 [Page 12]


                       Dynamic MIP Key Update           November 2003


   Public keys.  One Service Provider MAY negotiate an agreement with
   another Service Provider in which both Service Providers share and
   protect each other's RSA Private keys.

4.7 RADIUS AAA Server

   RADIUS or DIAMETER AAA Server MUST support the DMU Procedure.  The
   AAA Server MUST support RSA Public key cryptography and maintain a
   database of RSA Private (decryption) keys indexed by the Public Key
   Identifier.

   Delivery of the RSA Private key(s) to AAA Server from the MN
   manufacturer(s) is outside the scope of this documents.  However, RSA
   Private key(s) delivery via encrypted e-mail or physical (mail)
   delivery is likely acceptable.

   RADIUS AAA Server access MUST be limited to authorized personnel
   only.

   RADIUS AAA Server MUST support 1024-bit RSA decryption.

   RADIUS AAA Server MUST maintain a database of RSA Public/Private key
   pair indexed by the Public Key Identifier.

   RADIUS AAA Server MUST support the RADIUS attributes specified in
   Section 8.

   RADIUS AAA Server MUST support a subscriber specific MIP Update State
   Field.  When the MIP Update State Field set to UPDATE KEYS (1), the
   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) by
   Service ProviderÆs Billing/Provisioning system based on IT policy.
   Upon verification of MN-AAA Authentication Extension using decrypted
   MN_AAA key, the 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 AAA Server MUST set the MIP
   Update State Field to KEYS VALID (0).

   The 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).

   RADIUS AAA Server MUST decrypt the encrypted portion of the
   MIP_Key_Data payload using the appropriate RSA Private (decryption)
   key.

   RADIUS AAA Server MUST check the MN_AAA Authentication Extension of
   the DMU RRQ using the decrypted MN_AAA key.


Carroll                  Expires - May 2004                 [Page 13]


                       Dynamic MIP Key Update           November 2003



   RADIUS AAA Server MUST include the AAA_Authenticator in the Access
   Accept as a Vendor-Specific Radius Attribute.

   RADIUS AAA Server MUST support the MN_Authenticator options specified
   in Section 6.1.

   AAA Server MUST comply with DMU Procedure failure operation specified
   in Section 5.

   RADIUS AAA Server MUST support manual hexadecimal entry of MN_AAA
   key, MN_HA key and Simple IP CHAP key via the AAA GUI for each
   subscription.

   RADIUS AAA Server MUST provide a mechanism to validate the MIN/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
   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 AAA Server
   MUST check whether MN_AuthenticatorMN = MN_AuthenticatorAAA.  If the
   MN_Authenticators do not match, the AAA Server MUST send an Access
   Reject to the PDSN/FA.  The Access Reject MUST NOT contain a MIP Key
   Data request.

   AAA Server MUST include its PKOID (or another designated PKOID) in
   the MIP_Key_Request Radius Attribute.

   AAA Server MUST compare the PKOID sent in the MIP_Key _Data Radius
   Attribute with a list of valid PKOIDs in the AAA Server.  If the
   PKOID is not valid, the AAA Server MUST send an Access Reject to the
   PDSN with the Verizon Wireless Vendor Specific "Invalid Public Key"
   Radius attribute.  Note: the same Radius attribute may be assigned a
   different Vendor identifier.

   AAA Server MUST support delivery of the MN-HA key from the AAA server
   using 3GPP2 Radius Vendor-Specific Attributes as specified in 3GPP2
   X.S0011-005-C using the MN-HA Shared Key (Vendor-Type = 58) and MN-HA
   SPI (Vendor-Type = 57).

   AAA Server MUST always accept the A12 Access Request for a particular
   subscriber when the UPDATE KEYS (1) and KEYS UPDATED (2) states are
   set.  In the KEYS VALID (0) state, the AAA Server MUST check to
   Access Request normally.





Carroll                  Expires - May 2004                 [Page 14]


                       Dynamic MIP Key Update           November 2003


   AAA Server MUST reject an Access Request with the MIP_Key_Data Radius
   Attribute while the AAA Server is in the KEYS VALID state, i.e., the
   AAA MUST NOT allow an unsolicited key update to occur.

4.8 MN (Handset or Modem)

   MN manufacturer MUST pre-load the Wireless Carrier RSA Public key
   (and Public Key Identifier).

   MN manufacturer MUST pre-generate and pre-load the MN_Authenticator.

   MN MUST support 1024-bit RSA Encryption using the pre-loaded RSA
   Public key.

   MN MUST support MN_AAA, MN_HA, and CHAP random/pseudo-random key
   generation (in accordance with RFC 1750).

   MN MUST support random/pseudo-random AAA_Authenticator and
   MN_Authenticator generation (in accordance with RFC 1750).

   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.

   MN MUST construct the MIP_Key_Data payload in accordance with Section
   4.5.

   MN MUST initiate the DMU Procedure upon receipt of MIP Registration
   Reply with the MIP_Key_Request Verizon Wireless Vendor/Organization-
   specific Extension.

   Upon receipt of an RR including the MIP_Key_Request, the MN MUST
   check the PKOID sent in the MIP_Key_Request.  If the MN has a Public
   key associated with the PKOID, the MN MUST encrypt the MIP_Key_Data
   payload using that Public key.

   MN MUST have the capability to designate one Public key as the
   Default Public key if the MN supports multiple Public keys.

   MN MUST insert the Verizon Wireless Vendor/Organization-specific
   MIP_Key_Data Extension (or another Organization-specific MIP_Key_Data
   Extension) 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 Challenge Extension if present.

   Upon initiation of the DMU Procedure, the MN MUST compute MIP
   authentication extensions using the newly-generated temporary MN_AAA


Carroll                  Expires - May 2004                 [Page 15]


                       Dynamic MIP Key Update           November 2003


   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
   AAA Server).  If both values are the same, the MN MUST designate the
   temporary MN_AAA, MN_HA key, and Simple IP CHAP key as permanent.
   The MN MUST set its MIP Update State field to KEYS VALID.

   MN MUST support reset (re-generation) of the MN_Authenticator by the
   MN user as specified in Section 6.2.

   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 new MN_Authenticator.
   (until the MN_Authenticator is explicitly re-set again by the MN
   user).

   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. ASCII for a
   password or hexadecimal for a key.  The authors recommend the use of
   strong cryptographic keys.)

   MN MUST support the Verizon Wireless MIP Vendor/Organization-Specific
   Extensions specified in Section 9.

   MN MUST update the RRQ Identification field when re-transmitting the
   same MIP_Key_Data in a new RRQ.

   MN MUST comply with DMU Procedure failure operation specified in
   Section 5.

   The RSA Public Key MAY be stored in the MN flash memory as a constant
   while being updatable via software patch.

4.9 PDSN / Foreign Agent (FA)

   PDSN MUST support Verizon Wireless Radius Vendor Specific Attributes
   specified in Section 8 and Verizon Wireless MIP Vendor/Organization-
   Specific Extensions specified in Section 9.



Carroll                  Expires - May 2004                 [Page 16]


                       Dynamic MIP Key Update           November 2003


   PDSN MAY support Radius Vendor Specific Attributes specified in
   Section 8 and MIP Vendor/Organization-Specific Extensions specified
   in Section 9 using another Organization identifier (e.g., 3GPP2
   Organization ID).

   Upon receipt of an Access Reject containing the
   MIP_Key_Update_Request attribute, PDSN MUST send a RR to the MN with
   the MIP_Key_Request Vendor/Organization-Specific Extension.  The PDSN
   MUST use the RR error code = 89 (Vendor Specific) and MUST not tear
   down the PPP session after transmission.

   Upon receipt of an Access Reject containing the AAA_Authenticator
   attribute, the PDSN MUST send a RR with AAA_Authenticator MIP
   Vendor/Organization-Specific Extension.  The PDSN MUST use the RR
   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
   attribute, the PDSN MUST send a RR with Public Key Invalid MIP
   Vendor/Organization-Specific Extension.  The PDSN MUST use the RR
   error code = 89 (Vendor Specific) and MUST NOT tear down the PPP
   session after transmission.

   Upon receipt of a RRQ with the MIP_Key_Data Vendor/Organization-
   Specific Extension, the PDSN MUST convert the RRQ to an ARQ with
   MIP_Key_Data attribute.  The PDSN MUST send the ARQ to the AAA
   server.

   PDSN/FA MUST comply with DMU Procedure failure operation specified in
   Section 5.

   PDSN/FA MUST include the PKOID from the Access Reject
   MIP_Key_Update_Request attribute in the MIP_Key_Request MIP extension
   sent to the MN.

4.10 Home Agent (HA)

   HA MUST support Verizon Wireless MIP Vendor/Organization-Specific
   Extensions specified in Section 9.  (Note: HA may not encounter a DMU
   MIP extension.)

   HA MUST support MIP Vendor/Organization-Specific Extensions specified
   in Section 9 using another Organization identifier (e.g., 3GPP2
   Organization ID).  (Note: HA may not encounter a DMU MIP extension.)

   HA MUST support delivery of the MN-HA key from the Home AAA server
   using 3GPP2 Radius Vendor-Specific Attributes as specified in 3GPP2
   X.S0011-005-C using the MN-HA Shared Key (Vendor-Type = 58) and MN-HA
   SPI (Vendor-Type = 57).


Carroll                  Expires - May 2004                 [Page 17]


                       Dynamic MIP Key Update           November 2003



4.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           BS                 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 (RR)      |
              with MIP_Key_Request MIP        |
              Vendor/organization-specific    |
              attribute                       |
           |<---------------------------------|
    -------------------
   |  9: MN generates  |
   |  MIP_Key_Data     |
   |  using temporary  |
   |  MIP keys         |
    -------------------
           |  10: RRQ with MIP_Key_Data
           |  Vendor/organization-specific attribute
           |--------------------------------->|  11: Access Request
                                              |  w/MSID
                                              |  and MIP_Key_Data
                                              |  Radius attribute
                                              |------------>|

                   Figure 4. DMU Procedure Flow (part 1)


Carroll                  Expires - May 2004                 [Page 18]


                       Dynamic MIP Key Update           November 2003


           MN           BS/PDSN            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 (RR)     |
              with AAA_Authenticator MIP      |
              Vendor/organization-specific    |
              attribute                       |
           |<---------------------------------|
    ----------------------
   |  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)








Carroll                  Expires - May 2004                 [Page 19]


                       Dynamic MIP Key Update           November 2003


           MN           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 (RR)  |
                           |<--------------------------------|
                      RR   |
           |<--------------|

                   Figure 4. DMU Procedure Flow (part 3)

   Each step in the Figure 4 DMU Process is described as follows:

      1. Each RSA Public/Private Key pair must be generated in
         accordance with RFC 2313.  Each Public/Private key pair MUST be
         assigned a unique Public Key Identifier (PKOID) by its creator.
         If the Service Provider does not generate the Public/Private
         Key pair and deliver the RSA Public Key to the MN manufacturer
         for pre-installation in the MN, the MN manufacturer MUST
         generate the RSA Public/Private Key pair (using a 1024-bit
         modulus) and pre-load all MNs with the RSA Public (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 cdma2000(R) 1X (CAVE) authentication success, the BS sends
         the "authenticated" MSID (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.



Carroll                  Expires - May 2004                 [Page 20]


                       Dynamic MIP Key Update           November 2003


      5. 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 AAA server.

      6. The 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 AAA Server rejects Packet Data access and orders
         a MIP key update.

      7. The AAA Server sends an Access Reject (code = 3) message to the
         PDSN with MIP_Key_Update_Request Vendor-Specific Radius
         Attribute.

      8. The PDSN converts the Access Reject to a MIP Registration Reply
         (RR) with a MIP_Key_Request MIP Vendor/Organization-Specific
         Extension and sends the RR to the MN.  RR Code = 89 (Vendor
         Specific).

      9. The MN sets the MN MIP Update State = UPDATE KEYS.  If the MN
         has no pre-generated and pre-encrypted the MIP_Key_Data
         payload, the MN MUST generate the MN_AAA key, MN_HA key, Chap
         key, MN_Authenticator, and AAA_Authenticator in accordance with
         RFC 1750.  Except for the Public Key Identifier, all generated
         values MUST be encrypted using the pre-loaded RSA Public
         (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
         Vendor/Organization-Specific Extension (see RFC 3115) to the
         PDSN.

      11. The PDSN converts the RRQ to a Radius ARQ with MIP_Key_Data
         Radius Attribute and forwards the ARQ to the home AAA Server.
         The MSID is included in the ARQ.

      12. The 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 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 AAA Server verifies the MN-AAA Authentication
         Extension Authenticator using the decrypted MN_AAA key.  If
         successful, the AAA Server updates the subscriber profile with



Carroll                  Expires - May 2004                 [Page 21]


                       Dynamic MIP Key Update           November 2003


         the decrypted MN_AAA key, MN_HA key, and CHAP key.  The AAA
         Server sets the AAA MIP Update State Field to KEYS UPDATED (2).

      13. The AAA Server sends an Access Reject with AAA_Authenticator
         Radius Attribute to the PDSN.

      14. The PDSN converts the Access Reject to a MIP RR with
         AAA_Authenticator MIP Vendor/Organization-Specific Extension.
         RR 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 RRQ which is converted to an ARQ by the
         PDSN and forwarded to the AAA Server.

      17. The AAA Server verified the MN-AAA Authentication Extension
         and sets the AAA MIP Update State Field to KEYS VALID (0).  The
         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 AAA Server.  The 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 RR to the PDSN/FA which forwards RR to the MN.
         RR Code = 0 (Success).

5. DMU Procedure Failure Operation

   This section was contributed by and is reproduced with the permission
   of Qualcomm Incorporated.

   To improve the robustness of the DMU Procedure to account for
   interruptions due to UDP message loss, RRQ retransmission, or MN
   failure, the 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).









Carroll                  Expires - May 2004                 [Page 22]


                       Dynamic MIP Key Update           November 2003


           MN           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 States


Carroll                  Expires - May 2004                 [Page 23]


                       Dynamic MIP Key Update           November 2003



   Each step in the Figure 5 is described as follows:

      1. If (A) is lost, the MN retransmits (A).  The AAA server expects
         (A).  If the AAA server is in the UPDATE KEYS state, the AAA
         Server sends AR with MIP_Key_Update_Request attribute and the
         PDSN/FA sends (B).

      2. If (B) is lost, the MN retransmits (A).  The AAA server expects
         (C).  If it receives (A), the AAA Server sends AR with
         MIP_Key_Update_Request attribute and the PDSN/FA retransmits
         (B).

      3. If (C) is lost, the mobile retransmits (C).  The AAA server
         expects (C) and updates the MIP keys appropriately. The AAA
         server transitions to KEYS UPDATED and commits the
         MIP_Key_Data.  The AAA Server sends the AR with
         AAA_Authenticator attribute 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 AAA server expects (A) using the
         same keys.

         a. If the AAA server receives (C) with the same keys it
            received previously, it retransmits the AR with
            AAA_Authenticator attribute and the PDSN replies with (D),
            containing the AAA_Authenticator.

         b. If the AAA server receives (C) with different keys than it
            received previously,  AAA Server sends AR with
            MIP_Key_Update_Request attribute, the PDSN/FA retransmits
            (B), and AAA server transitions to UPDATE KEYS.

         c. If the AAA server receives (A) which fails authentication
            using the keys sent in (C), the AAA Server sends AR with
            MIP_Key_Update_Request, the PDSN/FA retransmits (B), and AAA
            server transitions to UPDATE KEYS.

      5. Once the PDSN/FA receives (A), forwards the ARQ to the AAA
         server, and the MN-AAA Authenticator is verified using the
         MN_AAA key, the AAA Server transitions to the KEYS VALID state
         and the DMU process is complete.

   The AAA DMU state machine is described in Figure 6.






Carroll                  Expires - May 2004                 [Page 24]


                       Dynamic MIP Key Update           November 2003


                               --------------
        --------------------->|  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. 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 with 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/DIAMETER AAA is
   outside the scope of this document, allowing Service Providers the
   flexibility to determine the most efficient/least intrusive procedure
   to support MN authentication (during the DMU Procedure).

6.1 RADIUS/DIAMETER AAA Support

   The RADIUS/DIAMETER AAA 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/DIAMETER AAA Server MUST have the capability to ignore the
      MN_Authenticator.  For example, when the AAA Server decrypts the
      MIP_Key_Data payload, the AAA Server silently discards the
      MN_Authenticator.


Carroll                  Expires - May 2004                 [Page 25]


                       Dynamic MIP Key Update           November 2003



   2. Pre-Update Validation

      Prior to updating a subscription profile with the delivered MIP
      keys, the AAA Server MUST compare the MN_AuthenticatorMN
      (delivered via the encrypted MIP_Key_Data payload) with the
      MN_AuthenticatorAAA (possibly delivered via the Service Provider
      customer care or billing/provisioning system).

   3. Post-Update Validation

      After the DMU Procedure is complete, the AAA Server stores the
      delivered MN_AuthenticatorMN and waits for delivery of the
      MN_AuthenticatorAAA (via Customer Care, IVR, or some other
      unspecified process).  Once the MN_Authenticator is delivered to
      the AAA Server, the AAA Server MUST compare the MN_AuthenticatorMN
      (delivered via the encrypted MIP_Key_Data payload) with the
      MN_AuthenticatorAAA.  If the Authenticators match, the AAA Server
      authorizes access and final update of the MIP keys.

6.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 in according with RFC
   1750 upon user command.  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. 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


Carroll                  Expires - May 2004                 [Page 26]


                       Dynamic MIP Key Update           November 2003


   resets the primary MN_Authenticator, the MN discards the primary
   MN_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.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 the AAA Server.  The method of MN_Authenticator
   delivery is outside the scope of this document.

   However, to provide some context 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. NAI, MSID, ESN)
   including the MN_Authenticator which the point-of-sale representative
   retrieves via the MN device's display.  In the case of a modem, the
   manufacturer may have pre-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 AAA Server.  The AAA Server compares the MN-
   delivered MN_Authenticator with the billing system delivered
   MN_Authenticator.  If the authenticators match, the AAA Server
   updates the subscriber profile with the delivered MIP keys and
   authorizes service.  If the Post-Update option is enabled within the
   AAA Server, the AAA Server tentatively updates the subscription
   profile until receiving the MN_Authenticator via the
   billing/provision system.




Carroll                  Expires - May 2004                 [Page 27]


                       Dynamic MIP Key Update           November 2003


   As another option, the Service Provider MAY use an IVR system in
   which the HRPD/1xEV-DO subscriber calls a provisioning number and
   inputs the MN_Authenticator.  The IVR system then delivers the
   MN_Authenticator to the 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 list provides a description of potential security
   vulnerabilities and their relative risk to the DMU Procedure:

7.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 RFC 1750 [10]
   guidelines and Service 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 RFC 1750
   guidelines.  Furthermore, if a key generation flaw is identified, the
   flaw appears readily correctable via a software patch, minimizing the
   impact.

7.2 Man-in-the-Middle Attack

   The DMU procedure is susceptible to a MIM attack, however such an
   attack appears relatively complex and expensive.  When AKA is
   deployed within cdma2000(R) 1X, the MIM Attack will be eliminated.
   The risk of an MIM 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.3 RSA Private Key Compromise

   Because one RSA Private key may be associated with millions of MNs
   (RSA  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 for a MN manufacturer to distribute the same RSA Private
   key to multiple service providers to enable MIP key update.  However,
   each service provider MAY generate their own RSA Public/Private key


Carroll                  Expires - May 2004                 [Page 28]


                       Dynamic MIP Key Update           November 2003


   pair and require the MN manufacturer to include their own RSA Public
   key in a specific software patch if compromise of the RSA Private key
   is a significant concern.

7.4 RSA Encryption

   Several vulnerabilities have been identified in certain
   implementations of RSA, however they do not appear applicable to the
   DMU Procedure.

7.5 False Base Station/PDSN

   The MN appears to be protected against a False BS denial-of-service
   (DOS) attack, since only the proper AAA server can recover the
   AAA_Authenticator.

7.6 cdma2000(R) 1X False MN

   The cdma2000(R) 1X network appears adequately protected against a
   false MN by IS-2000 challenge-response authentication.

7.7 HRPD/1xEV-DO False MN

   The 1xEV-DO AAA Server MAY optionally authenticate the MN using the
   MN_Authenticator to prevent a fraudulent MN activation.

8. Verizon Wireless - Specific 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 indicates MIP key update is required.

   Vendor-Type = 1
   Vendor-Length = 3 bytes
   Vendor-Value= PKOID of the AAA Server








Carroll                  Expires - May 2004                 [Page 29]


                       Dynamic MIP Key Update           November 2003


   MIP_Key_Data:
   ------------

   Payload containing encrypted MN_AAA key, MN_HA key, CHAP key,
   MN_Authenticator, and AAA_Authenticator.  Payload also contains
   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= 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 is concatenated to the encrypted payload.

   AAA_Authenticator:
   -----------------

   64-bit AAA_Authenticator value decrypted by the Home Radius AAA
   Server.

      Vendor-Type = 3
      Vendor-Length = 10 bytes
      Vendor-Value= decrypted AAA_Authenticator from Home AAA Server.

   Public Key Invalid:
   ------------------

   Home Radius AAA Server indicates that Public key used by MN is not
   valid.

      Vendor-Type = 4
      Vendor-Length = 2 bytes
      Vendor-Value= none.

   Note:  An Organization may define Specific Radius Attributes using
   their own Organization identifier.

9. Verizon Wireless Mobile IP Vendor/Organization-Specific Extensions

   Three Verizon Wireless Mobile IP Vendor/Organization-Specific
   Extensions (RFC 3115), required to support the DMU Procedure, are
   specified as follows:

   Type: 38 (CVSE-TYPE-NUMBER)





Carroll                  Expires - May 2004                 [Page 30]


                       Dynamic MIP Key Update           November 2003


   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.  Critical Vendor/Organization Specific Extension

   MIP_Key_Request:
   ---------------

   The Home Radius AAA Server indicates MIP key update is required.

      Length = 7
      NOTE: The RFC 3115 Editor has stated that the Reserved field is
         not included in the length determination.
      Vendor-CVSE-Type = 1
      Vendor-CVSE-Value= PKOID sent in the Radius MIP_Key_Update_Request
         attribute.

   MIP_Key_Data:
   ------------

   Payload containing encrypted MN_AAA key, MN_HA key, CHAP key,
   MN_Authenticator, and AAA_Authenticator.  Payload also contains
   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 = 2
      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:
   -----------------

   64-bit AAA_Authenticator value decrypted by the Home Radius AAA
   Server.


Carroll                  Expires - May 2004                 [Page 31]


                       Dynamic MIP Key Update           November 2003



      Length = 14 bytes
      Vendor-CVSE-Type = 3
      Vendor-CVSE-Value= decrypted AAA_Authenticator from Home AAA
         Server.

   Public Key Invalid:
   ------------------

   The Home Radius AAA Server indicates that Public key used by MN is
   not valid.

      Length = 6 bytes
      Vendor-CVSE-Type = 4
      Vendor-CVSE-Value= none.

   Note:  An Organization may define Specific Vendor/Organization
   Extensions using their own Organization identifier.

10. Public Key Identifier and DMU Version

   The Public Key Identifier (Pub_Key_ID) is used only during the
   Dynamic Mobile IP Update (DMU) procedure to allow the AAA Server to
   distinguish between different Public 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 AAA Server to
   distinguish between different Public keys created by different PKOs
   (see Table 1).  If a Service Provider does not provide the MN
   manufacturer with a (RSA) Public key, the manufacturer MUST generate
   a unique RSA Public/Private key pair and pre-load each MN with the
   RSA Public key (1024-bit modulus by default).  The manufacture MAY
   share the same RSA Private key with multiple Service 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.




Carroll                  Expires - May 2004                 [Page 32]


                       Dynamic MIP Key Update           November 2003


   The Public Key Organization Index (PKOI) is an 8-bit field in which
   the index the 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 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 the Public Key algorithm and version used (see Table 3).






































Carroll                  Expires - May 2004                 [Page 33]


                       Dynamic MIP Key Update           November 2003


          Table 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.



Carroll                  Expires - May 2004                 [Page 34]


                       Dynamic MIP Key Update           November 2003


   PKOID    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


Carroll                  Expires - May 2004                 [Page 35]


                       Dynamic MIP Key Update           November 2003


   PKOID    Public Key                 PKOID    Public Key
   (HEX)    Organization (PKO)         (HEX)    Organization (PKO)
   -----    ------------------         -----    ------------------
   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).

                           Table 2.  DMU Version

                        DMU Version    DMU Version
                           Value
                        -----------    -----------
                        00             Version 1.3
                        01             TBD
                        02             TBD
                        03             TBD
                        04             TBD
                        05             TBD
                        06             TBD
                        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
                        04       TBD
                        05       TBD
                        06       TBD
                        07       TBD

11. Intellectual Property

   Verizon Wireless has submitted a Patent Application to the United
   States Patent and Trademark Office for components of the DMU
   Procedure.

   Qualcomm Incorporated may have patents or copyrights that cover
   information contained in this document.





Carroll                  Expires - May 2004                 [Page 36]


                       Dynamic MIP Key Update           November 2003


12. Conclusion

   The Dynamic Mobile IP key Update (DMU) Procedure enables the
   efficient, yet secure, delivery of critical Mobile IP cryptographic
   keys.  The use of cryptographic keys, hence the bootstrapping of such
   MIP keys using the DMU Procedure, is essential to commercial delivery
   of Mobile IP service in CDMA 2000 1xRTT and HRPD/1xEV-DO networks
   networks or other networks that utilize Mobile IP.

13. Formal Syntax

   None.

References


   1  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, Internet Engineering Task Force, March
      1997

   2  TIA/EIA/IS-2000 Series, Revision A, Telecommunications Industry
      Association, March 2000

   3  TIA/EIA/IS-856, cdma2000 High Rate Packet Data Air Interface
      Specification, Telecommunications Industry Association, November
      2000

   4  TIA/EIA/IS-835-A, cdma2000 Wireless IP Network Standard,
      Telecommunications Industry Association, May 2001

   5  ANSI/TIA/EIA-41-D-97, Cellular Radiotelecommunications Intersystem
      Operations, Telecommunications Industry Association, December 1997

   6  ANSI/TIA/EIA-683-B-2001, Over-the-Air Service Provisioning of
      Mobile Stations in Spread Spectrum Systems, Telecommunications
      Industry Association, December 2001

   7  B. Kaliski. PKCS #1: RSA Encryption Version 1.5.  RFC 2313,
      Internet Engineering Task Force, March 1998.

   8  G. Dommety, K. Leung. Mobile IP Vendor/Organization-Specific
      Extensions. RFC 3115, Internet Engineering Task Force, April 2001

   9  TIA/EIA-IS-634-A, Interoperability Specifications (IOS) for
      cdma2000 Access Network Interfaces, Telecommunications Industry
      Association, August 2001





Carroll                  Expires - May 2004                 [Page 37]


                       Dynamic MIP Key Update           November 2003



   10  D. Eastlake, 3rd, S. Crocker, and J. Schiller.  Randomness
      Recommendations for Security.  RFC 1750, Internet Engineering Task
      Force, December 1994.

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), Brian 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
   HAMILTON, BROOK, SMITH & REYNOLDS, P.C.
   530 Virginia Road
   P.O. Box 9133
   Concord, MA  01742-9133
   Phone: 978-202-3436
   Email: christopher.carroll@hbsr.com

   Frank Quick
   Qualcomm Incorporated
   5775 Morehouse Drive
   San Diego, CA 92121 USA
   Phone: 858-658-3608
   Email: fquick@qualcomm.com

















Carroll                  Expires - May 2004                 [Page 38]


                       Dynamic MIP Key Update           November 2003


14. Appendix - Cleartext-Mode Operation

   DMU MUST support 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 in length respectively.  Thus, in
   cleartext mode, the payload MUST consist of 48 bytes of keys (MN_AAA,
   MN_HA, and CHAP key), 8 byte AAA_Authenticator, 3 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 / 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 AAA Server.

      Padding = 69 bytes of 0's.

      DMU Version (DMUV) = 4 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 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.



Carroll                  Expires - May 2004                 [Page 39]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/