Network Working Group C. Carroll
Request for Comments: 4784 Ropes & Gray LLP
Category: Informational F. Quick
Qualcomm Inc.
June 2007
Network Working Group C. Carroll
Request for Comments: 4784 Ropes & Gray LLP
Category: Informational F. Quick
Qualcomm Inc.
June 2007
Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks
用于cdma2000（R）网络的Verizon Wireless动态移动IP密钥更新
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
IESG Note
IESG注释
This document describes an existing deployed technology that was developed outside the IETF. It utilizes the RADIUS Access-Reject in order to provision service, which is incompatible with the RADIUS protocol, and practices the sharing of secret keys in public-key cryptosystems, which is not a practice the IETF recommends. The IESG recommends against using this protocol as a basis for solving similar problems in the future.
本文档描述了在IETF之外开发的现有部署技术。它利用RADIUS访问拒绝来提供与RADIUS协议不兼容的服务，并在公钥密码系统中共享密钥，这不是IETF建议的做法。IESG建议不要使用该协议作为将来解决类似问题的基础。
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 Packet Data, which is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update (DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUS Authentication, Authorization and Accounting (AAA) Server via a cdma2000(R) Packet Data Serving Node (PDSN) that is acting as a Mobile IP Foreign Agent (FA).
Verizon Wireless动态移动IP密钥更新程序是一种用于在cdma2000（R）网络中分发和更新移动IP（MIP）加密密钥的机制（包括高速分组数据，通常称为1xEV DO）。动态移动IP密钥更新（DMU）过程通过充当移动IP外部代理（FA）的cdma2000（R）分组数据服务节点（PDSN）在MIP移动节点（MN）和RADIUS认证、授权和计费（AAA）服务器之间发生。
cdma2000(R) is a registered trademark of the Telecommunications Industry Association (TIA).
cdma2000（R）是电信行业协会（TIA）的注册商标。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Basic Dynamic MIP Key Update Mechanism ..........................3
2.1. RSA Encrypted Key Distribution .............................4
2.2. Mutual Authentication (1X) .................................5
2.3. Encrypted Password Authentication ..........................8
3. Dynamic MIP Key Update Advantages over OTASP ...................10
4. Detailed DMU Procedure Description and Requirements ............10
4.1. RSA Public Key Cryptography ...............................11
4.2. Other Public Key Algorithms ...............................11
4.3. Why No Public Key Infrastructure (PKI)? ...................11
4.4. Cryptographic Key Generation ..............................12
4.5. MIP_Key_Data Payload ......................................12
4.6. RSA Key Management ........................................13
4.7. RADIUS AAA Server .........................................14
4.8. MN (Handset or Modem) .....................................16
4.9. PDSN / Foreign Agent (FA) .................................19
4.10. Home Agent (HA) ..........................................20
4.11. DMU Procedure Network Flow ...............................20
5. DMU Procedure Failure Operation ................................25
6. cdma2000(R) HRPD/1xEV-DO Support ...............................28
6.1. RADIUS AAA Support ........................................28
6.2. MN Support ................................................29
6.3. Informative: MN_Authenticator Support .....................30
7. Security Considerations ........................................31
7.1. Cryptographic Key Generation by the MN ....................31
7.2. Man-in-the-Middle Attack ..................................31
7.3. RSA Private Key Compromise ................................32
7.4. RSA Encryption ............................................32
7.5. False Base Station/PDSN ...................................32
7.6. cdma2000(R) 1X False MN ...................................32
7.7. HRPD/1xEV-DO False MN .....................................32
7.8. Key Lifetimes .............................................32
7.9. Network Message Security ..................................33
8. Verizon Wireless RADIUS Attributes .............................33
9. Verizon Wireless Mobile IP Extensions ..........................34
10. Public Key Identifier and DMU Version .........................36
11. Conclusion ....................................................40
12. Normative References ..........................................41
13. Informative References ........................................41
14. Acknowledgments ...............................................42
Appendix A. Cleartext-Mode Operation ..............................43
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Basic Dynamic MIP Key Update Mechanism ..........................3
2.1. RSA Encrypted Key Distribution .............................4
2.2. Mutual Authentication (1X) .................................5
2.3. Encrypted Password Authentication ..........................8
3. Dynamic MIP Key Update Advantages over OTASP ...................10
4. Detailed DMU Procedure Description and Requirements ............10
4.1. RSA Public Key Cryptography ...............................11
4.2. Other Public Key Algorithms ...............................11
4.3. Why No Public Key Infrastructure (PKI)? ...................11
4.4. Cryptographic Key Generation ..............................12
4.5. MIP_Key_Data Payload ......................................12
4.6. RSA Key Management ........................................13
4.7. RADIUS AAA Server .........................................14
4.8. MN (Handset or Modem) .....................................16
4.9. PDSN / Foreign Agent (FA) .................................19
4.10. Home Agent (HA) ..........................................20
4.11. DMU Procedure Network Flow ...............................20
5. DMU Procedure Failure Operation ................................25
6. cdma2000(R) HRPD/1xEV-DO Support ...............................28
6.1. RADIUS AAA Support ........................................28
6.2. MN Support ................................................29
6.3. Informative: MN_Authenticator Support .....................30
7. Security Considerations ........................................31
7.1. Cryptographic Key Generation by the MN ....................31
7.2. Man-in-the-Middle Attack ..................................31
7.3. RSA Private Key Compromise ................................32
7.4. RSA Encryption ............................................32
7.5. False Base Station/PDSN ...................................32
7.6. cdma2000(R) 1X False MN ...................................32
7.7. HRPD/1xEV-DO False MN .....................................32
7.8. Key Lifetimes .............................................32
7.9. Network Message Security ..................................33
8. Verizon Wireless RADIUS Attributes .............................33
9. Verizon Wireless Mobile IP Extensions ..........................34
10. Public Key Identifier and DMU Version .........................36
11. Conclusion ....................................................40
12. Normative References ..........................................41
13. Informative References ........................................41
14. Acknowledgments ...............................................42
Appendix A. Cleartext-Mode Operation ..............................43
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 a cdma2000(R) Packet Data Serving Node (PDSN) that is acting as a Mobile IP Foreign Agent (FA). (In this document, we use the acronym AAAH to indicate the home AAA server as opposed to an 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.
Verizon Wireless动态移动IP密钥更新程序是一种用于在cdma2000（R）1xRTT（1X）[2]和高速分组数据（HRPD）/1xEV DO网络[3]中分发和更新移动IP（MIP）加密密钥的机制。动态移动IP密钥更新（DMU）过程经由充当移动IP外部代理（FA）的cdma2000（R）分组数据服务节点（PDSN）在移动IP移动节点（MN）和归属RADIUS[4]（或Diameter[5]）认证、授权和计费（AAA）服务器之间发生。（在本文件中，我们使用首字母缩略词AAAH表示家庭AAA服务器，而不是可能位于访问系统中的AAA服务器。）本程序旨在支持符合电信行业协会（TIA）TR-45标准is-835[6]的无线系统。然而，DMU可以在任何MIP网络中执行，以实现移动节点（MN）和RADIUS AAA服务器之间共享秘密的引导。
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.
DMU过程利用RSA公钥加密技术，使用相同的RSA公钥将唯一的MIP密钥安全地分发给可能数以百万计的cdma2000（R）1X和HRPD/1xEV DO移动节点（MN）。
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-response authentication, and network-to-device authentication is facilitated using RSA encryption.
通过利用现有的cdma2000（R）1X身份验证过程，动态移动IP密钥更新过程采用相互身份验证机制，其中使用cdma2000（R）1X质询-响应身份验证促进设备到网络的身份验证，使用RSA加密促进网络到设备的身份验证。
By utilizing RSA encryption, the MN (or MN manufacturer) is able to pre-generate MIP keys (and the Challenge Handshake Authentication Protocol (CHAP) key) and pre-encrypt the MIP keys prior to initiation of the DMU procedure. By employing this pre-computation capability, the DMU process requires less computation (by an order of magnitude) during the key exchange than Diffie-Hellman Key Exchange.
通过利用RSA加密，MN（或MN制造商）能够在启动DMU过程之前预生成MIP密钥（和质询握手认证协议（CHAP）密钥）并预加密MIP密钥。通过使用这种预计算能力，DMU过程在密钥交换期间比Diffie-Hellman密钥交换需要更少的计算（数量级）。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
The DMU procedure is basically an authentication and key distribution protocol that is more easily understood by separately describing the mechanism's two functional goals: 1) encrypted key distribution and 2) mutual authentication.
DMU过程基本上是一种身份验证和密钥分发协议，通过分别描述该机制的两个功能目标（1）加密密钥分发和2）相互身份验证，更容易理解该协议。
By utilizing RSA public key cryptography, 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 a trusted 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.
通过利用RSA公钥加密技术，MN可以预加载公共RSA公钥（加密）密钥（由MN制造商），而相关的RSA私钥（解密）可以从MN制造商安全地分发到可信的服务提供商。或者，服务提供商可以生成自己的RSA公钥/私钥对，并且仅将RSA公钥分发给MN制造商，以预加载MN。
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.
在制造过程中，MN制造商使用RSA公钥预加载每个MN。当MN通电（或启动客户端应用程序）时，MN可以预生成并加密MIP密钥，以便在DMU过程中分发到Home RADIUS AAA服务器。或者，MN制造商可以预生成MIP密钥，加密MIP密钥有效载荷，并使用多个加密的MIP密钥有效载荷预加载MN以启用DMU过程。
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. 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 as MIP_Key_Data), the AAA Server uses the RSA Private key to decrypt the payload and recover the MIP keys.
在初始注册过程中（或AAA需要MIP密钥更新时），MN:1）生成适当的MIP密钥、CHAP密钥和身份验证信息，2）使用嵌入的RSA公钥加密有效负载信息，3）并将有效负载附加到MIP注册请求。注册请求经由蜂窝基站（BS）和分组数据服务节点（PDSN）发送到移动IP外部代理（FA）。当RADIUS AAA服务器接收到加密的负载（稍后定义为MIP_密钥_数据）时，AAA服务器使用RSA私钥解密负载并恢复MIP密钥。
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 |
| | -------------------
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
图1。RSA加密密钥分发
Mutual authentication can be achieved by delegation of the MN/device authentication by the RADIUS AAA Server to the cdma2000(R) 1X Home Location Register (HLR) and its associated Authentication Center (AC) [7], while the MN utilizes RSA encryption to authenticate the RADIUS AAA Server.
相互认证可以通过RADIUS AAA服务器将MN/设备认证委托给cdma2000（R）1X归属位置寄存器（HLR）及其关联的认证中心（AC）[7]来实现，同时MN利用RSA加密对RADIUS AAA服务器进行认证。
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., 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., the RADIUS AAA server is delegating its authentication function to the cdma2000(R) 1X HLR/AC.
通过HLR/AC的MN/设备认证基于这样的假设，即MN的移动站（MS）具有现有的认证密钥（A-Key）和与cdma2000（R）1X网络共享的秘密数据（SSD）。当发生MS呼叫发起时，AC认证MS。如果认证成功，BS将移动站标识符（MSID）（例如，移动标识号（MIN））传递给PDSN。“已验证MSID”随后包含在从PDSN发送到RADIUS AAA服务器的RADIUS访问请求（ARQ）消息[4]中。由于RADIUS AAA服务器存储与MN订阅相关联的MSID，因此如果“已验证MSID”与RADIUS AAA MSID匹配，RADIUS AAA服务器能够授权MN访问，即RADIUS AAA服务器将其验证功能委托给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).
RADIUS AAA服务器身份验证（由MN）通过在从MN发送到RADIUS AAA服务器的加密有效负载中包含随机数（AAA_验证器）来启用。只有拥有正确RSA私钥的人才能解密有效负载并恢复唯一的AAA_身份验证器。如果MN接收到正确的AAA_验证器（由RADIUS AAA服务器返回），则MN被确保它没有与假基站（BS）交互。
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. Mutual Authentication
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. Mutual Authentication
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 Server to optionally authenticate the MN (in 1XEV DO network only).
由于cdma2000（R）A-key/SSD身份验证在1xEV DO中不可用，或者特定的cdma2000（R）1X网络可能不支持A-key身份验证，因此DMU过程还包括由MN生成（和/或由制造商预加载）的随机数（MN_验证器），这使得RADIUS AAA服务器能够选择性地对MN进行身份验证（仅在1XEV DO网络中）。
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.
MN_验证器在RSA加密的MIP_密钥_数据有效负载内从MN传输到家庭AAA服务器，以防止攻击者拦截和可能的重复使用。理想情况下，MN_认证器用作一次性密码；但是，RSA加密允许根据每个服务提供商的密钥分发策略重新使用MN_验证器。
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, and delivered, 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 the service provider's implementation flexibility.
当加密的MIP密钥在家庭RADIUS AAA服务器上解密时，MN_验证器也会被解密，并与家庭RADIUS AAA服务器中存储的MN_验证器副本进行比较。Home RADIUS AAA服务器使用本标准范围之外的多种可能方法之一接收MN_认证器的带外副本（不使用cdma2000（R）网络）。例如，MN_认证器可以是：1）由销售点供应器从MN读出，输入到订户简档中，并与网络接入标识符（NAI）一起经由计费/供应系统交付到家庭RADIUS AAA服务器，2）通过呼叫口头传达给客户服务代表，或3）由与交互式语音识别服务器交互的用户输入。本文档中未指定带外MN_验证器交付，以最大限度地提高服务提供商的实现灵活性。
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.
不道德的供应商或分销员工可能在DMU程序之前提取MN_验证器；然而，与此类披露相关的风险很小。由于HRPD/1xEV DO MN在初始注册过程中不传输设备标识符，因此攻击者即使有被盗的MN_认证器，也无法将密码与特定的MN设备或NAI关联，这通常是在DMU过程启动之前设置的。
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-
MN_认证器通常由MN内的随机/伪随机数生成器生成。MN用户发起MN_认证器生成；但是，制造商可能会对其进行初始预加载。当重置MN_验证器（即，生成新的MN_验证器）时，将丢弃使用先前MN_验证器的所有MIP_数据_密钥有效载荷，并立即重新加载MN-
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.
加密包含新MNU验证器的MIP_密钥_数据有效负载。除非MN用户显式重置MN_验证器，否则MN_验证器不得更改。因此，MN将使用相同的MN_验证器生成新的MIP_密钥_数据有效载荷，直到MN_验证器被更新。
-------------------------
| 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 |
----------------------------- -------------------------
-------------------------
| 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
图3。MN_验证器和MIP_密钥_数据有效负载状态机
**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 the service provider provisioning system.
**注：制造商预加载MN_验证器并不重要，因为MN_验证器通常由MN生成。然而，制造商预加载可减少供应器访问诸如调制解调器之类的设备以恢复MN_认证器以进入服务提供商供应系统的负担。
The DMU procedure has numerous advantages over the current Over-the-Air Service Provisioning (OTASP) [8] procedure, including:
与当前的空中服务供应（OTASP）[8]程序相比，DMU程序具有许多优点，包括：
* 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 the Over-the-Air Functionality (OTAF) and RADIUS AAA server.
* 在DMU中，MIP密钥分发直接发生在IP层的MN和AAA服务器之间。这样就不需要空中传送功能（OTAF）和RADIUS AAA服务器之间的接口。
* DMU Supports MIP key distribution for cdma2000(R) 1X and HRPD/1xEV-DO MN. OTASP only supports cdma2000(R) 1X MIP key distribution.
* DMU支持cdma2000（R）1X和HRPD/1xEV DO MN的MIP密钥分发。OTASP仅支持cdma2000（R）1X MIP密钥分发。
* 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 cannot deliver MIP keys to a Laptop MN interfacing with an MS modem.
* DMU有助于在中继模式下将MIP密钥分发到MN。OTASP仅将MIP密钥传送到MS。例如，OTASP无法将MIP密钥传送到与MS调制解调器接口的笔记本电脑MN。
* Pre-encryption of MIP_Key_Data allows the DMU procedure to be an order of magnitude faster than Diffie-Hellman Key Exchange.
* MIP_密钥_数据的预加密允许DMU过程比Diffie-Hellman密钥交换快一个数量级。
* 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.
* 在DMU中，MN制造商可以预生成MIP密钥，预加密MIP密钥有效负载，并在MN中预加载有效负载。因此，处理能力有限的MN永远不需要使用RSA加密。在密钥更新过程中，OTASP设备总是被迫执行计算代价高昂的求幂运算。
* 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中，MN受到拒绝服务（DOS）攻击的保护，其中错误的BS更改其附近MNs的MIP密钥。OTASP Diffie-Hellman密钥交换易受虚假BS DOS攻击。
* DMU utilizes mutual authentication. OTASP Diffie-Hellman Key Exchange does not utilize mutual authentication.
* DMU利用相互认证。OTASP Diffie-Hellman密钥交换不使用相互身份验证。
The Verizon Wireless 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 Public Key Infrastructure (PKI) Certificates, greatly enhancing the procedure's efficiency.
Verizon Wireless Dynamic Mobile IP Update程序是一种安全但极为有效的机制，用于分发基本MIP加密密钥（例如MN-AAAH密钥和MN-HA密钥）和简单IP CHAP密钥。DMU协议允许预计算加密密钥材料有效载荷，称为MIP_密钥_数据。DMU过程有意避免使用公钥基础设施（PKI）证书，从而大大提高了过程的效率。
RSA public key encryption and decryption MUST be performed in accordance with RFC 3447 [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-bit RSA, depending on the MN user's efficiency or security requirements. RSA computation speed-ups using a public RSA exponent that is small or has a small number of nonzero bits (e.g., 65537) are acceptable.
RSA公钥加密和解密必须按照RFC 3447[9]PKCS#1:RSA加密版本1.5执行。默认情况下，DMU必须支持1024位模的RSA。DMU还可以支持768位或2048位RSA，具体取决于MN用户的效率或安全要求。可以使用较小或具有少量非零位（例如65537）的公共RSA指数提高RSA计算速度。
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.
DMU不排除使用其他公钥技术。该协议包括一个公钥类型字段，用于定义所使用的加密类型。
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.
DMU旨在最大限度地提高cdma2000（R）MNs的移动IP（MIP）密钥分发效率。公钥证书的使用将通过允许证书颁发机构（CA）对交付给MN的RSA公钥进行担保，从而提高MIP密钥更新过程的灵活性。不幸的是，使用公钥证书将显著降低MIP密钥更新过程的效率（速度和开销）。例如，每个MN必须预先加载CA的公钥。在MIP密钥分发过程中，网络必须首先将其RSA公钥（在证书中）交付给MN。然后，MN必须使用RSA对证书的数字签名进行解密，以验证提供的RSA公钥是否合法。这样的过程显著增加了交换次数，增加了空中接口开销，增加了MN计算量，并减慢了MIP密钥更新过程。
Aside from the operational efficiency issues, there are numerous policy and procedural issues that have previously hampered the deployment of PKI in commercial networks.
除了运营效率问题外，还有许多政策和程序问题以前阻碍了PKI在商业网络中的部署。
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).
从理论上讲，这种密钥分发模型可能不需要PKI。PKI是多对多通信模型的理想选择，例如在互联网中，许多不同的用户与许多不同的网站交互。然而，在蜂窝/PCS分组数据环境中，存在多对一（或少数）分布模型，其中许多用户与一个无线运营商交互以建立其移动IP安全关联（即加密密钥）。
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 4086 "Randomness Requirements for Security".
DMU过程依赖于每个MN随机/伪随机生成MN_AAAH密钥、MN_HA密钥和简单IP CHAP密钥。每个MN必须能够根据RFC 4086“安全性随机性要求”中规定的指南生成随机/伪随机数。
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.
尽管网络在RADIUS AAA服务器上生成加密密钥可能更安全，但由于通过预生成和预加密MIP密钥在更新过程中显著提高了效率，因此客户端加密密钥生成是可接受的。
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 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).
MIP加密密钥（MN_AAAH密钥和MN_HA密钥）和简单IP CHAP密钥被封装并加密到MIP_密钥数据有效负载中（以及AAA_认证器和MN_认证器）。MIP_Key_数据有效负载作为MIP供应商/组织特定扩展（VSE）附加到MN的MIP注册请求（RRQ）（请参阅RFC 3115[10]移动IP供应商/组织特定扩展）。当PDSN将MIP RRQ转换为RADIUS访问请求（ARQ）消息时，MIP_Key_数据有效负载将从MIP供应商/组织特定的扩展转换为供应商特定的RADIUS属性（VSA）。
Upon receipt of the RADIUS Access Request, the RADIUS AAA Server 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:
收到RADIUS访问请求后，RADIUS AAA服务器使用与用于加密MIP_密钥_数据有效载荷的RSA公用（加密）密钥相关联的RSA专用（解密）密钥对MIP_密钥_数据有效载荷进行解密。MIP_密钥_数据定义如下：
MIP_Key_Data = RSA_Public_Key [MN_AAAH key, MN_HA key, CHAP_key, MN_Authenticator, AAA_Authenticator], Public_Key_ID, DMUV
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_AAAH密钥=128位随机MN/RADIUS AAA服务器密钥（加密）
MN_HA key = 128-bit random MN / Home Agent (HA) key (encrypted)
MN_HA密钥=128位随机MN/归属代理（HA）密钥（加密）
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].
CHAP_key=128位随机简单IP身份验证密钥（加密）注意：简单IP CHAP密钥与用于A12接口身份验证的AT-CHAP密钥不同[11]。
MN_Authenticator = 24-bit random number (displayed as an 8 decimal digit number). (To be used for 1xEV-DO networks.) (encrypted)
MN_验证器=24位随机数（显示为8位十进制数字）。（用于1xEV DO网络）（加密）
AAA_Authenticator = 64-bit random number used by MN to authenticate the RADIUS AAA Server. (encrypted)
AAA_Authenticator=MN用于验证RADIUS AAA服务器的64位随机数。（加密）
DMU Version (DMUV) = 4-bit identifier of DMU version.
DMU版本（DMUV）=DMU版本的4位标识符。
Public Key Identifier (Public_Key_ID) = PKOID, PKOI, PK_Expansion, ATV
公钥标识符（公钥ID）=PKOID、PKOI、PKU扩展、ATV
Where:
哪里：
Public Key Organization Identifier (PKOID) = 8-bit serial number identifier of Public Key Organization (PKO) that created the Public Key.
公钥组织标识符（PKOID）=创建公钥的公钥组织（PKO）的8位序列号标识符。
Public Key Organization Index (PKOI) = 8-bit serial number used at PKO discretion to distinguish different public/private key pairs.
公钥组织索引（PKOI）=PKO自行决定使用的8位序列号，用于区分不同的公钥/私钥对。
PK_Expansion = 8-bit field to enable possible expansion of PKOID or PKOI fields. (Note: Default value = 0xFF)
PK_Expansion=8位字段，用于启用PKOID或PKOI字段的可能扩展。（注意：默认值=0xFF）
Algorithm Type and Version (ATV) = 4-bit identifier of the algorithm used.
算法类型和版本（ATV）=所用算法的4位标识符。
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.
注意：如果使用1024位RSA，则有效负载的加密部分长度为1024位（128字节）。使用28位公钥标识符和4位DMUV，MIP_密钥_数据有效负载的总长度为132字节。
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 RADIUS AAA Server) and public keys (to the MN manufacturers) in support of the DMU procedure.
无线服务提供商或运营商必须生成RSA公钥/私钥对。服务提供商必须指定服务提供商内的一个组织来生成、管理、保护和分发RSA私钥（到RADIUS AAA服务器）和公钥（到MN制造商），以支持DMU过程。
Each RSA public/private key pair, generated by the wireless carrier, MUST be assigned a unique Public Key Identifier in accordance with Section 9.
根据第9节，必须为无线运营商生成的每个RSA公钥/私钥对分配一个唯一的公钥标识符。
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 an RSA key management policy to protect the RSA Private (decryption) keys.
必须保护RSA私钥，以防泄露给未经授权的方。负责生成RSA公钥/私钥对的服务提供商组织必须制定RSA密钥管理策略以保护RSA私钥（解密）。
RSA public keys MAY be freely distributed to all MN manufacturers (along with the Public Key Identifier). Because one RSA public key
RSA公钥可以自由分发给所有MN制造商（以及公钥标识符）。因为一个RSA公钥
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 a 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.
可以分发给数百万MN，可以通过电子邮件、软盘或网站将RSA公钥（和公钥标识符）分发给MN制造商。首选方法是在发送给每个MN制造商/OEM的DMU需求文档中简单地发布RSA公钥和相关公钥标识符。
When public keys are distributed, the public keys MUST be protected against alteration. If an invalid public key is programmed into a terminal, the terminal may be denied service because DMU cannot be performed successfully.
分发公钥时，必须保护公钥不被更改。如果将无效公钥编程到终端中，则可能会因为DMU无法成功执行而拒绝该终端的服务。
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.
RSA私钥可以手动加载到RADIUS AAA服务器中。对RADIUS AAA Server RSA私钥的访问必须仅限于授权人员。
The wireless service provider MAY accept RSA Private key(s) (and Public Key Identifier) from MN manufacturers that have preloaded MNs with manufacturer-generated RSA public keys.
无线服务提供商可以接受来自MN制造商的RSA私钥（和公钥标识符），这些MN制造商已使用制造商生成的RSA公钥预加载MN。
The RADIUS AAA Server used for DMU 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.
用于DMU的RADIUS AAA服务器必须支持DMU过程。AAA服务器必须支持RSA公钥加密，并维护由公钥标识符索引的RSA私钥（解密）数据库。
Delivery of the RSA Private key(s) to an AAA Server from the MN manufacturer(s) is outside the scope of this document. However, RSA Private key(s) delivery via encrypted e-mail or physical (mail) delivery is likely acceptable.
从RSA（s）范围之外的RSA（s）服务器传递到RSA（s）范围之外的文件。但是，通过加密电子邮件或物理（邮件）传递RSA私钥可能是可以接受的。
Access to the RADIUS AAA Server MUST be limited to authorized personnel only.
只能由授权人员访问RADIUS AAA服务器。
The RADIUS AAA Server MUST support 1024-bit RSA decryption.
RADIUS AAA服务器必须支持1024位RSA解密。
The RADIUS AAA Server MUST maintain a database of RSA public/private key pair indexed by the Public Key Identifier.
RADIUS AAA服务器必须维护由公钥标识符索引的RSA公钥/私钥对数据库。
The RADIUS AAA Server MUST support the RADIUS attributes specified in Section 8.
RADIUS AAA服务器必须支持第8节中指定的RADIUS属性。
The RADIUS AAA Server MUST support a subscriber-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
RADIUS AAA服务器必须支持特定于订户的MIP更新状态字段。当MIP Update State字段设置为Update KEYS（1）时，RADIUS AAA服务器必须通过在发送到PDSN的访问拒绝消息中包含MIP_Key_请求属性来启动DMU过程。MIP Update State字段可以设置为Update
KEYS (1) by the 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).
密钥（1）由服务提供商基于IT策略的计费/供应系统提供。使用解密的MN_AAA密钥验证MN-AAA身份验证扩展后，RADIUS AAA服务器必须将MIP Update State字段设置为KEYS UPDATED（2）。在后续RRQ/ARQ上验证MN身份验证扩展后，RADIUS AAA服务器必须将MIP Update State字段设置为KEYS VALID（0）。
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.
请注意，访问拒绝消息中包含供应商特定属性与[4]第5.44节不一致。如果从DMU接收到不符合PDU属性的供应商特定于AAA的请求，则该属性应包括不符合DMU的请求。对于基于本文档的任何未来工作，强烈反对使用Access Reject。未来的工作应该考虑使用Access挑战来承载这个供应商特有的属性。
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).
RADIUS AAA服务器必须为每个订阅维护三种状态之一的MIP更新状态字段（0=密钥有效，1=更新密钥，2=密钥更新）。
The RADIUS AAA Server MUST decrypt the encrypted portion of the MIP_Key_Data payload using the appropriate RSA Private (decryption) key.
RADIUS AAA服务器必须使用适当的RSA私钥（解密）对MIP_密钥_数据有效负载的加密部分进行解密。
The RADIUS AAA Server MUST check the MN_AAA Authentication Extension of the DMU RRQ using the decrypted MN_AAA key.
RADIUS AAA服务器必须使用解密的MN_AAA密钥检查DMU RRQ的MN_AAA身份验证扩展。
The RADIUS AAA Server MUST include the AAA_Authenticator in the Access Accept as a Vendor-Specific RADIUS Attribute.
RADIUS AAA服务器必须将AAA_身份验证器作为供应商特定的RADIUS属性包含在Access Accept中。
The RADIUS AAA Server MUST support the MN_Authenticator options specified in Section 6.1.
RADIUS AAA服务器必须支持第6.1节中指定的MN_验证器选项。
The RADIUS AAA Server MUST comply with DMU Procedure failure operation specified in Section 5.
RADIUS AAA服务器必须符合第5节规定的DMU程序故障操作。
The 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服务器必须通过AAA GUI为每个订阅支持手动十六进制输入MN_AAA密钥、MN_HA密钥和简单IP CHAP密钥。
The RADIUS AAA Server MUST provide a mechanism to validate the 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
RADIUS AAA服务器必须提供验证MIN/国际移动用户身份（IMSI）的机制。当MIN/IMSI验证打开时，RADIUS AAA服务器必须将从PDSN发送的MIN/IMSI与AAA订阅记录/配置文件中的MIN/IMSI进行比较。如果MINs或IMSIs不匹配，RADIUS AAA服务器必须向PDSN/FA发送访问拒绝。拒绝访问不能包含MIP密钥数据请求
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.
当未设置“忽略MN_验证器”位时，RADIUS AAA服务器必须检查MN_AuthenticatorMN=MN_AuthenticatorAAA。如果MN_验证器不匹配，RADIUS AAA服务器必须向PDSN/FA发送访问拒绝。访问拒绝不能包含MIP_密钥_数据请求。
The RADIUS AAA Server MUST include its PKOID (or another designated PKOID) in the MIP_Key_Request RADIUS Attribute.
RADIUS AAA服务器必须在MIP_Key_Request RADIUS属性中包含其PKOID（或另一个指定的PKOID）。
The 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.
RADIUS AAA服务器必须将MIP_Key_Data RADIUS属性中发送的PKOID与RADIUS AAA服务器中的有效PKOID列表进行比较。如果PKOID无效，RADIUS AAA服务器必须向PDSN发送带有“无效公钥”的Verizon Wireless RADIUS供应商特定属性（VSA）的访问拒绝。注意：相同的RADIUS属性可能会分配不同的供应商标识符。
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.
请注意，访问拒绝消息中包含供应商特定属性与[4]第5.44节不一致。如果从DMU接收到不符合PDU属性的供应商特定于AAA的请求，则该属性应包括不符合DMU的请求。对于基于本文档的任何未来工作，强烈反对使用Access Reject。未来的工作应该考虑使用Access挑战来承载这个供应商特有的属性。
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-HA Security Parameter Index (SPI) (Vendor-Type = 57).
RADIUS AAA服务器必须支持使用3GPP2 X.S0011-005-C中指定的3GPP2 RADIUS VSA传递MN-HA密钥。使用的3GPP2 VSA是MN-HA共享密钥（供应商类型=58）和MN-HA安全参数索引（SPI）（供应商类型=57）。
The RADIUS AAA Server SHOULD always accept an Access Request from a 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.
当设置了更新密钥（1）和密钥更新（2）状态时，RADIUS AAA服务器应始终接受来自特定订户的cdma2000（R）访问节点（an）的访问请求。在密钥有效（0）状态下，RADIUS AAA服务器必须正常检查访问请求。
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.
RADIUS AAA服务器必须在RADIUS AAA服务器处于密钥有效状态时拒绝具有MIP_Key_Data RADIUS属性的访问请求，即，AAA不得允许发生未经请求的密钥更新。
The MN manufacturer MUST pre-load the Wireless Carrier RSA public key (and Public Key Identifier).
MN制造商必须预加载无线运营商RSA公钥（和公钥标识符）。
The MN manufacturer MUST pre-generate and pre-load the MN_Authenticator.
MN制造商必须预生成并预加载MN_验证器。
The MN MUST support 1024-bit RSA Encryption using the pre-loaded RSA public key.
MN必须使用预加载的RSA公钥支持1024位RSA加密。
The MN MUST support MN_AAA, MN_HA, and CHAP random/pseudo-random key generation (in accordance with RFC 4086).
MN必须支持MN_AAA、MN_HA和CHAP随机/伪随机密钥生成（根据RFC 4086）。
The MN MUST support random/pseudo-random AAA_Authenticator and MN_Authenticator generation (in accordance with RFC 4086).
MN必须支持随机/伪随机AAA_验证器和MN_验证器生成（根据RFC 4086）。
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手持设备通电或启动MN客户端时，MN必须检查是否计算了MIP_Key_数据有效载荷。如果不存在MIP_Key_数据负载，则MN必须生成并存储MIP_Key_数据负载。MN必须维护至少一个预生成的MIP_密钥_数据有效负载。
The MN MUST construct the MIP_Key_Data payload in accordance with Section 4.5.
MN必须根据第4.5节构造MIP_密钥_数据有效载荷。
The MN MUST initiate the DMU Procedure upon receipt of a MIP Registration Reply (RRP) with the MIP_Key_Request Verizon Wireless Vendor/Organization-Specific Extension (VSE).
MN必须在收到带有MIP_Key_Request Verizon Wireless供应商/组织特定扩展（VSE）的MIP注册回复（RRP）后启动DMU程序。
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 a public key associated with the PKOID, the MN MUST encrypt the MIP_Key_Data payload using that public key.
在收到包括MIP_Key_请求的RRP后，MN必须检查MIP_Key_请求中发送的PKOID。如果MN具有与PKOID关联的公钥，则MN必须使用该公钥加密MIP_key_数据有效负载。
The MN MUST have the capability to designate one public key as the default public key if the MN supports multiple public keys.
如果MN支持多个公钥，则MN必须能够将一个公钥指定为默认公钥。
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 Challenge Extension, if present.
MN必须在移动家庭身份验证扩展之后，但在MN-AAA身份验证扩展之前插入Verizon Wireless MIP_Key_Data VSE（或其他特定于组织的MIP_Key_Data VSE）。MIP_密钥_数据扩展还必须位于FA质询扩展（如果存在）之后。
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-Home Authenticator. 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.
注意：扩展的顺序对于互操作性很重要。在FA从RADIUS AAA服务器接收到访问接受后，FA可以在移动家庭验证器之后剥离所有MIP扩展。如果发生这种情况，则医管局无需处理DMU扩展。在使用FAs进行测试期间，还发现了其他兼容性问题，这些问题来自在不同位置放置扩展的不同供应商。扩展的显式放置消除了这些问题。
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,
启动DMU过程后，MN必须使用新生成的临时MN_AAA和MN_HA密钥计算MIP身份验证扩展。收到AAA_验证器MIP扩展后，
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.
MN必须将AAA_AuthenticatorMN（在加密的MIP_密钥_数据负载中发送）与AAA_AuthenticatorAAA（由RADIUS AAA服务器返回）进行比较。如果两个值相同，MN必须将临时MN_AAA、MN_HA密钥和简单IP CHAP密钥指定为永久密钥。必须将其MIP State MN设置为有效密钥。
The MN MUST support reset (re-generation) of the MN_Authenticator by the MN user as specified in Section 6.2.
MN必须支持MN用户按照第6.2节的规定重置（重新生成）MN_验证器。
The 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.
MN必须使MN用户能够查看MN_验证器。MN_验证器（24位随机数）必须显示为第6.2节规定的8位十进制数字。
The MN manufacturer MUST pre-load each MN with a unique random 24-bit MN_Authenticator.
MN制造商必须使用唯一的随机24位MN_验证器预加载每个MN。
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_验证器后，MN必须基于旧MN_验证器删除所有MIP_Key_数据有效载荷，并使用新MN_验证器生成所有后续MIP_Key_数据有效载荷（直到MN用户再次显式重新设置MN_验证器）。
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., ASCII for a password or hexadecimal for a key. The authors recommend the use of strong cryptographic keys.)
MN必须支持手动输入所有加密密钥，如MN_AAA、MN_HA和简单IP CHAP密钥。MN必须支持128位密钥的十六进制数字输入。（注意：某些简单IP设备仅允许ASCII输入密码作为CHAP密钥。未来的设备可以同时提供这两种功能，即ASCII输入密码或十六进制输入密钥。作者建议使用强加密密钥。）
The MN MUST support the Verizon Wireless MIP Vendor/Organization-Specific Extensions specified in Section 9.
MN必须支持第9节中指定的Verizon Wireless MIP供应商/组织特定扩展。
The MN MUST update the RRQ Identification field when re-transmitting the same MIP_Key_Data in a new RRQ.
当在新RRQ中重新传输相同的MIP_密钥_数据时，MN必须更新RRQ标识字段。
The MN MUST comply with the DMU Procedure failure operation specified in Section 5.
MN必须符合第5节规定的DMU程序故障操作。
The RSA public key MAY be stored in the MN flash memory as a constant while being updatable via software patch.
RSA公钥可以作为常量存储在MN闪存中，同时可以通过软件补丁进行更新。
The PDSN MUST support the Verizon Wireless RADIUS Vendor-Specific Attributes (VSA) specified in Section 8 and the Verizon Wireless MIP Vendor/Organization-Specific Extensions (VSEs) specified in Section 9.
PDSN必须支持第8节中指定的Verizon Wireless RADIUS供应商特定属性（VSA）和第9节中指定的Verizon Wireless MIP供应商/组织特定扩展（VSE）。
The PDSN MAY support the RADIUS VSAs specified in Section 8 and the MIP VSEs specified in Section 9 using another Organization identifier.
PDSN可以使用另一个组织标识符支持第8节中指定的RADIUS VSAs和第9节中指定的MIP VSE。
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.
在接收到包含MIP_Key_Update_请求VSA的访问拒绝后，PDSN必须向MN发送带有MIP_Key_请求VSE的RRP。PDSN必须使用RRP错误代码=89（特定于供应商），并且在传输后不得中断PPP会话。
Upon 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.
在接收到包含AAA_认证器VSA的访问拒绝后，PDSN必须与AAA_认证器MIP VSE一起发送RRP。PDSN必须使用RRP错误代码=89（特定于供应商），并且在传输后不得中断PPP会话。
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.
收到包含公钥无效VSA的访问拒绝后，PDSN必须发送带有公钥无效MIP VSE的RRP。PDSN必须使用RRP错误代码=89（特定于供应商），并且在传输后不得中断PPP会话。
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.
请注意，访问拒绝消息中包含供应商特定属性与[4]第5.44节不一致。支持DMU的PDSN必须接受包含供应商特定属性的访问拒绝消息。对于基于本文档的任何未来工作，强烈反对使用Access Reject。未来的工作应该考虑使用Access挑战来承载这个供应商特有的属性。
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.
收到带有MIP_密钥数据VSE的RRQ后，PDSN必须将RRQ转换为带有MIP_密钥数据VSA的ARQ。PDSN必须将ARQ发送到RADIUS AAA服务器。
The PDSN/FA MUST comply with the DMU Procedure failure operation specified in Section 5.
PDSN/FA必须符合第5节规定的DMU程序故障操作。
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.
PDSN/FA必须在发送给MN的MIP_密钥_请求MIP VSE中包含来自访问拒绝MIP_密钥_更新_请求VSA的PKOID。
The HA MUST support the Verizon Wireless MIP Vendor/Organization-Specific Extensions (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.)
HA必须支持第9节中指定的Verizon Wireless MIP供应商/组织特定扩展（VSE）。（注意：如果FA在移动家庭身份验证扩展后删除所有扩展，HA可能不会遇到DMU MIP扩展。）
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.)
医管局可使用另一组织标识符支持第9节中规定的MIP VSE。（注意：如果FA在移动家庭身份验证扩展后删除所有扩展，HA可能不会遇到DMU MIP扩展。）
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).
HA必须支持使用3GPP2 X.S0011-005-C中指定的3GPP2 RADIUS供应商特定属性（VSA）从主RADIUS AAA服务器交付MN-HA密钥。使用的3GPP2 VSA是MN-HA共享密钥（供应商类型=58）和MN-HA SPI（供应商类型=57）。
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.
本节提供了IS-2000网络中涉及动态移动IP更新过程的流程图和详细说明。
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
| |------------>|
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)
图4。DMU程序流程（第1部分）
MN 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 |
| |<------------|
MN 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)
图4。DMU程序流程（第2部分）
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 (RRP) |
| |<--------------------------------|
| RRP | | |
|<--------------| | |
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 (RRP) |
| |<--------------------------------|
| RRP | | |
|<--------------| | |
Figure 4. DMU Procedure Flow (part 3)
图4。DMU程序流程（第3部分）
Each step in the Figure 4 DMU Process is described as follows:
图4 DMU过程中的每个步骤描述如下：
1. Each RSA public/private key pair MUST be generated in accordance with RFC 3447. Each public/private key pair MUST be assigned a unique Public Key Identifier (PKOID) by its creator.
1. 必须根据RFC 3447生成每个RSA公钥/私钥对。每个公钥/私钥对必须由其创建者分配一个唯一的公钥标识符（PKOID）。
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.
如果服务提供商未生成公钥/私钥对并将RSA公钥交付给MN制造商以在MN中预安装，MN制造商必须生成RSA公钥/私钥对（使用1024位模数），并使用RSA公钥（加密）预加载所有MN。MN制造商必须以安全的方式将RSA私有（解密）密钥分发给相应的服务提供商。
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., MIN) to the PDSN.
2. 假设cdma2000（R）1X MN已经配置了A密钥和SSD，则cdma2000（R）1X MS发起呼叫发起并向IS-2000网络认证自身。IS-2000认证成功后，BS向PDSN发送“已认证”MSID（例如，MIN）。
3. The MN and PDSN establish a PPP session.
3. MN和PDSN建立PPP会话。
4. The MN sends a MIP Registration Request (RRQ) to the PDSN.
4. MN向PDSN发送MIP注册请求（RRQ）。
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 RADIUS AAA server.
5. PDSN将MIP RRQ转换为RADIUS访问请求（ARQ）消息，在ARQ中包含MSID，并将ARQ转发给RADIUS AAA主服务器。
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.
6. RADIUS AAA服务器将经过身份验证的MSID（从PDSN发送）与其订户数据库（与NAI关联）中的MSID进行比较。如果AAA MIP Update State字段设置为Update KEYS（1），RADIUS AAA服务器将拒绝数据包访问并命令MIP key更新。
7. The RADIUS AAA Server sends an Access Reject (code = 3) message to the PDSN with the MIP_Key_Update_Request RADIUS VSA.
7. RADIUS AAA服务器使用MIP_Key_Update_Request RADIUS VSA向PDSN发送访问拒绝（代码=3）消息。
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).
8. PDSN使用MIP_Key_Request MIP VSE将访问拒绝转换为MIP注册回复（RRP），并将RRP发送给MN。RRP代码=89（特定于供应商）。
9. The MN sets the MN MIP Update State = UPDATE KEYS. If the MN has no pre-generated and pre-encrypted 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 4086. 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.
9. MN设置MN MIP更新状态=更新密钥。如果MN没有预生成和预加密的MIP_密钥_数据有效载荷，则MN必须根据RFC 4086生成MN_AAA密钥、MN_HA密钥、Chap密钥、MN_验证器和AAA_验证器。除公钥标识符外，所有生成的值都必须使用预加载的RSA公钥（加密）进行加密。新生成的MN_AAATEMP密钥和MN_HATEMP必须用于计算当前RRQ的MN-AAA和移动家庭认证扩展。注意：MN可以通过检查在每个MN通电或应用程序启动期间是否存在有效负载来预计算MIP_Key_数据有效负载。
10. The MN sends the RRQ with MIP_Key_Data MIP VSE to the PDSN.
10. MN向PDSN发送带有MIP_Key_Data MIP VSE的RRQ。
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.
11. PDSN将RRQ转换为具有MIP_Key_Data RADIUS VSA的RADIUS ARQ，并将ARQ转发给RADIUS AAA主服务器。MSID包含在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).
12. RADIUS AAA服务器将经过身份验证的MSID（从PDSN发送）与其订户数据库（与NAI关联）中的MSID进行比较。如果MSIDPDSN=MSIDAAA，RADIUS AAA服务器将使用公钥标识符确定适当的RSA私钥，并解密MIP_密钥_数据有效负载的加密部分。RADIUS AAA服务器使用解密的MN_AAA密钥验证MN-AAA身份验证扩展验证器。如果成功，RADIUS AAA服务器将使用解密的MN_AAA密钥、MN_HA密钥和CHAP密钥更新订户配置文件。RADIUS AAA服务器将AAA MIP更新状态字段设置为密钥更新（2）。
13. The RADIUS AAA Server sends an Access Reject with AAA_Authenticator RADIUS VSA to the PDSN.
13. RADIUS AAA服务器向PDSN发送带有AAA_验证器RADIUS VSA的访问拒绝。
14. The PDSN converts the Access Reject to a MIP RRP with AAA_Authenticator MIP VSE. RRP Code = 89 (Vendor Specific).
14. PDSN使用AAA_验证器MIP VSE将访问拒绝转换为MIP RRP。RRP代码=89（特定于供应商）。
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.
15. 如果AAA_AuthenticatorMN=AAA_AuthenticatorAAA，MN将MN_AAATEMP分配给MN_AAA密钥，将MN_HATEMP分配给MN_HA密钥（MN MIP Update State=KEYS VALID）。否则，MN将丢弃临时密钥。
16. The MN initiates a new RRQ that is converted to an ARQ by the PDSN and forwarded to the RADIUS AAA Server.
16. MN发起新的RRQ，该RRQ由PDSN转换为ARQ，并转发到RADIUS AAA服务器。
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.
17. RADIUS AAA服务器验证MN-AAA身份验证扩展，并将AAA MIP更新状态字段设置为有效密钥（0）。RADIUS AAA服务器向PDSN/FA发送访问接受。
18. The PDSN/FA sends the RRQ to the Home Agent (HA).
18. PDSN/FA将RRQ发送给归属代理（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.
19. HA向RADIUS AAA服务器发送访问请求。RADIUS AAA服务器使用MN_HA密钥向HA发送访问接受。HA使用MN_HA密钥验证移动家庭身份验证扩展。
20. The HA sends an RRP to the PDSN/FA, which forwards the RRP to the MN. RRP Code = 0 (Success).
20. HA向PDSN/FA发送RRP，后者将RRP转发给MN。RRP代码=0（成功）。
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).
为了提高DMU过程的稳健性，以考虑由于UDP消息丢失、RRQ重传或MN故障造成的中断，RADIUS AAA服务器必须为每个订阅维护一个MIP更新状态字段，处于三种状态之一（0=有效密钥，1=更新密钥，2=更新密钥）。
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
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
Each step in Figure 5 is described as follows:
图5中的每个步骤描述如下：
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_Request VSA, and the PDSN/FA sends (B).
1. 如果（A）丢失，则MN重新发送（A）。RADIUS AAA服务器需要（A）。如果AAA服务器处于更新密钥状态，RADIUS AAA服务器发送带有MIP_密钥_更新_请求VSA的AR，PDSN/FA发送（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_Request VSA, and the PDSN/FA retransmits (B).
2. 如果（B）丢失，则MN重新发送（A）。RADIUS AAA服务器需要（C）。如果收到（A），RADIUS AAA服务器将发送带有MIP_Key_Update_Request VSA的AR，并且PDSN/FA将重新传输（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_Authenticator VSA, and the PDSN/FA replies to the MN with (D).
3. 如果（C）丢失，则移动设备重新发送（C）。RADIUS AAA服务器需要（C）并相应地更新MIP密钥。RADIUS AAA服务器转换到已更新的密钥，并提交MIP_密钥_数据。RADIUS AAA服务器使用AAA_验证器VSA发送AR，PDSN/FA使用（D）回复MN。
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.
4. 如果（D）丢失，则移动设备使用先前发送的相同密钥数据重新传输（C）。RADIUS AAA服务器期望（A）使用相同的密钥。
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.
a. 如果RADIUS AAA服务器接收到（C）的密钥与之前接收到的密钥相同，它将使用AAA_认证器VSA重新传输AR，PDSN将使用（D）回复，其中包含AAA_认证器。
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.
b. 如果RADIUS AAA服务器接收到的（C）密钥与之前接收到的不同，RADIUS AAA服务器将发送带有MIP_Key_Update_请求VSA的AR，PDSN/FA重新传输（B），RADIUS AAA服务器将转换为更新密钥。
c. If the RADIUS AAA server receives (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.
c. 如果RADIUS AAA服务器接收到（A），使用（C）中发送的密钥验证失败，RADIUS AAA服务器将发送带有MIP_Key_Update_请求的AR，PDSN/FA重新传输（B），RADIUS AAA服务器将转换为更新密钥。
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.
5. 一旦PDSN/FA接收到（A），将ARQ转发到RADIUS AAA服务器，并且使用MN_AAA密钥验证MN-AAA认证器，RADIUS AAA服务器将转换到密钥有效状态，并且DMU过程完成。
The AAA DMU state machine is described in Figure 6.
AAA DMU状态机如图6所示。
--------------
--------------------->| 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
--------------
--------------------->| 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。RADIUS AAA服务器DMU状态机
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 Cellular 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.
由于DMU过程发生在IP层，因此DMU过程支持在cdma2000（R）1X或HRPD/1xEV DO网络中分发MIP密钥。由于cdma2000（R）HRPD/1xEV DO网络不提供无线接入网络（RAN）身份验证，因此DMU过程更容易受到虚假MN攻击（比具有蜂窝身份验证和语音加密（CAVE）RAN身份验证的cdma2000（R）1X网络中的攻击）。因此，DMU过程能够选择性地支持使用MN_验证器的设备到网络认证。
The method of MN_Authenticator delivery to the RADIUS AAA server 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.
将MN_验证器交付到RADIUS AAA服务器的方法不在本文档的范围内，这使服务提供商能够灵活地确定在DMU过程中支持MN身份验证的最有效/最少干扰的过程。
The RADIUS AAA server MUST support three MN_Authenticator options:
RADIUS AAA服务器必须支持三个MN_验证器选项：
1. Ignore MN_Authenticator
1. 忽略MNU验证器
Depending on other potential authentication/fraud prevention options (outside the scope of the DMU Procedure), the RADIUS AAA
根据其他潜在的认证/欺诈预防选项（DMU程序范围之外），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.
服务器必须能够忽略MN_验证器。例如，当RADIUS AAA服务器解密MIP_密钥_数据有效负载时，AAA服务器会自动丢弃MN_验证器。
2. Pre-Update Validation
2. 更新前验证
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 the service provider customer care or billing/provisioning system).
在使用交付的MIP密钥更新订阅配置文件之前，RADIUS AAA服务器必须将MN_AuthenticatorMN（通过加密的MIP_密钥_数据负载交付）与MN_AuthenticatorAAA（可能通过服务提供商客户服务或计费/供应系统交付）进行比较。
3. Post-Update Validation
3. 更新后验证
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, 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.
在AAA或其他未指定的过程中，通过AAA或RADIUS传递语音，然后等待客户的响应。一旦MN_验证器传送到RADIUS AAA服务器，AAA必须将MN_验证器MN（通过加密的MIP_密钥_数据负载传送）与MN_验证器AAA进行比较。如果验证器匹配，RADIUS AAA服务器将授权访问和最终更新MIP密钥。
The Mobile Node (MN) MUST store the 24-bit MN_Authenticator.
移动节点（MN）必须存储24位MN_验证器。
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.
MN必须将MN_验证器显示为8位十进制数字（通过手持设备上的LCD显示器或通过调制解调器的GUI）。如果MN驻留在手机内，用户可以使用以下键盘顺序显示MN_验证器：“FCN++*+M+I+P+RCL”。否则，MN必须通过设备的GUI显示MN_验证器。
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, in accordance with RFC 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.
MN必须能够重置MN_验证器。换句话说，根据RFC 4086，MN必须具有根据用户命令随机/伪随机生成新的24位MN_验证器的能力。重置功能减轻了MN_验证器在装运/存储期间可能出现的危害。如果MN位于手机内，用户可以使用以下键盘顺序重置MN_验证器：“FCN++*+M+I+P+C+C+RCL”。否则，MN必须通过设备的GUI重置MN_验证器。
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
MN制造商可使用MN_验证器预加载MN。例如，通过预加载MN_验证器并将带有MN_验证器的标签（8位十进制数字表示）粘贴到
the MN (e.g., modem), the point-of-sale representative does not have to retrieve the MN_Authenticator from the MN interface.
销售点代表MN（例如调制解调器）不必从MN接口检索MN_验证器。
[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 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.
[可选]MN可以维护MN_验证器/MIP_密钥_数据有效负载对的单独主队列和辅助队列。当MN用户重置主MN_验证器时，MN丢弃主MN_验证器（以及任何关联的MIP_密钥_数据有效负载），并将辅助队列中的MN_验证器分配为主MN_验证器（并将任何关联的MIP_密钥_数据有效负载分配给主队列）。此功能使用户/供应器能够重置MN_验证器并立即启动DMU过程，而不会丢失MIP_Key_数据有效负载预加密优势。当MN_验证器从辅助队列传输到主队列时，MN必须为辅助队列生成新的MN_验证器和关联的MIP_密钥_数据有效负载。MN必须在通电或应用程序启动时检查主MN_身份验证程序/MIP_密钥_数据有效负载队列和辅助MN_身份验证程序/MIP_密钥_数据有效负载队列。MN必须在每个队列中维护至少一个MN\U验证器/MIP\U密钥\U数据有效负载对。
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.
使用MN_验证器的MN身份验证使服务提供商在确定如何将MN_验证器交付到RADIUS AAA服务器时具有最大的灵活性。MN_验证器交付方法不在本文档范围内。
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.
然而，为了提供一些关于MN_验证器如何在HRPD/1xEV DO环境中支持MN身份验证/欺诈预防的上下文，我们描述了以下可能的配置场景。
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, Electronic Serial Number (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 RADIUS AAA Server. The RADIUS AAA Server compares the MN-delivered MN_Authenticator with the billing-system-delivered MN_Authenticator. If the authenticators match, the RADIUS AAA Server updates the
当用户最初获得其HRPD/1xEV DO设备和服务时，销售点代表通过销售点的计算机终端将订阅信息记录到计费/供应系统中。计费/供应系统向RADIUS AAA服务器（例如NAI、MSID、电子序列号（ESN））提供特定信息，包括MN_认证器，销售点代表通过MN设备的显示器检索该认证器。对于调制解调器，制造商可能已预加载MNU验证器，并将MNU验证器的副本放在连接到调制解调器的标签上。销售点代表只需将MN_验证器的8位小数复制到客户配置文件中。一旦MN加载了适当的NAI并通电，MN将使用RADIUS AAA服务器启动DMU过程。RADIUS AAA服务器将MN交付的MN_验证器与计费系统交付的MN_验证器进行比较。如果验证器匹配，RADIUS AAA服务器将更新
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.
具有已交付MIP密钥和授权服务的订户配置文件。如果在RADIUS AAA服务器内启用了更新后选项，RADIUS AAA服务器将暂时更新订阅配置文件，直到通过计费/供应系统接收MN_验证器。
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 RADIUS AAA Server for final validation and Packet Data Access.
作为另一种选择，服务提供商可以使用IVR系统，其中HRPD/1xEV DO订户呼叫供应号码并输入MN_验证器。然后，IVR系统将MN_验证器传送到RADIUS AAA服务器，以进行最终验证和数据包访问。
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:
DMU过程旨在最大限度地提高MIP密钥分发的效率，同时提供足够的密钥分发安全性。以下描述了潜在的安全漏洞及其与DMU程序的相对风险：
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 4086 [12] 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 4086 guidelines. Furthermore, if a key generation flaw is identified, the flaw appears readily correctable via a software patch, minimizing the impact.
因为MN需要正确生成MN_AAA、MN_HA和CHAP密钥，所以MN必须根据可接受的随机/伪随机数生成过程执行加密密钥生成。MN制造商必须遵守RFC 4086[12]指南，服务提供商应确保制造商实施可接受的密钥生成程序。使用可预测的加密密钥可能会破坏MIP安全性。然而，只要MN制造商遵守RFC 4086指南，不使用可接受的随机/伪随机密钥生成的风险最小。此外，如果识别出密钥生成缺陷，该缺陷似乎可以通过软件补丁轻松纠正，从而将影响降至最低。
The DMU procedure is susceptible to a Man-in-the-Middle (MITM) attack; however, such an attack appears relatively complex and expensive. When Authentication 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.
DMU程序易受中间人（MITM）攻击；然而，这样的攻击似乎相对复杂和昂贵。在cdma2000（R）1X中部署身份验证和密钥协议（AKA）时，将消除MITM攻击。由于所需的专业知识、攻击费用和即将到来的cdma2000（R）1X相互认证保护，MITM攻击的风险最小。如果特定cdma2000（R）1X网络不支持a密钥认证，则可以选择使用MN_认证器。
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. If a MN manufacturer is generating the RSA public/private key pair, the MN manufacturer MUST establish adequate security procedures/policies regarding the dissemination of the RSA Private key to the appropriate service provider. An RSA Private key SHOULD be distributed to a legitimate cdma2000(R) service provider only. If a service provider is generating their own RSA public/private key pair, the service provider MUST protect the RSA Private key from disclosure to unauthorized parties.
由于一个RSA私钥可能与数百万MN（RSA公钥）相关联，因此保护RSA私钥不被未经授权的方泄露非常重要。如果MN制造商正在生成RSA公钥/私钥对，MN制造商必须建立有关向适当的服务提供商分发RSA私钥的适当安全程序/策略。RSA私钥只能分发给合法的cdma2000（R）服务提供商。如果服务提供商正在生成自己的RSA公钥/私钥对，则服务提供商必须保护RSA私钥，以防泄露给未经授权的方。
Several vulnerabilities have been identified in certain implementations of RSA; however, they do not appear applicable to the DMU Procedure.
在RSA的某些实现中发现了几个漏洞；但是，它们似乎不适用于DMU程序。
The MN appears to be protected against a false 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.
由于只有适当的RADIUS AAA服务器才能恢复AAA_身份验证器，因此MN似乎可以防止错误的BS拒绝服务（DOS）攻击。如第7.9节所述，这种防止虚假基站攻击的方法假设AAA和服务系统之间的网络消息传递具有安全性。
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.
cdma2000（R）1X网络似乎通过IS-2000质询-响应身份验证对虚假MN进行了充分保护。如果DMU在蜂窝域之外使用，则需要同等的身份验证程序来实现相同的安全级别。
The 1xEV-DO RADIUS AAA Server MAY optionally authenticate the MN using the MN_Authenticator to prevent a fraudulent MN activation.
1xEV DO RADIUS AAA服务器可以选择使用MN_验证器对MN进行身份验证，以防止欺诈性MN激活。
There is no explicit lifetime for the keys distributed by DMU.
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.
DMU分发的密钥的生存期由系统操作员通过RADIUS AAA服务器确定。MN_AAA和MN_HA密钥的生存期可以通过根据需要启动更新来控制。
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.
此外，由于MN无法启动DMU，因此DMU进程可以防止错误启动。这使得为MN提供显式生存期变得不可行，因为MN无法在过期后采取任何操作来更新密钥。
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 considerations apply to the distribution of Shared Secret Data, which is already transmitted between nodes in the ANSI-41 network.)
从RADIUS AAA服务器传送到MIP home agent的MN-HA密钥的安全性要求对包含此类密钥的网络消息保密。网络消息的安全要求规范由运营商负责，不在本文件范围内。（请注意，类似的考虑也适用于共享机密数据的分发，该数据已在ANSI-41网络中的节点之间传输。）
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].
如果DMU在蜂窝运营商的域之外使用，则可以使用RADIUS安全功能，包括[4]中定义的请求认证器和响应认证器字段以及[13]中定义的消息认证器属性。
Three new RADIUS Attributes are required to support the DMU Procedure and are specified as follows:
支持DMU程序需要三个新的RADIUS属性，具体如下：
Type: 26
Length: >9
Verizon Wireless Enterprise/Vendor ID: 12951
Type: 26
Length: >9
Verizon Wireless Enterprise/Vendor ID: 12951
MIP_Key_Update_Request:
----------------------
MIP_Key_Update_Request:
----------------------
The Home RADIUS AAA Server includes this attribute to indicate that MIP key update is required.
Home RADIUS AAA服务器包含此属性以指示需要MIP密钥更新。
Vendor-Type = 1 Vendor-Length = 3 bytes Vendor-Value = PKOID of the RADIUS AAA Server
供应商类型=1供应商长度=3字节供应商值=RADIUS AAA服务器的PKOID
MIP_Key_Data:
------------
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.
密钥数据有效负载包含加密的MN_AAA密钥、MN_HA密钥、CHAP密钥、MN_验证器和AAA_验证器。此有效负载还包含公钥标识符。
Vendor-Type = 2 Vendor-Length = 134 bytes
供应商类型=2供应商长度=134字节
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.
注：供应商长度取决于RSA模数的大小。例如，当使用RSA-512时，供应商长度=70字节。供应商值=128字节RSA加密有效负载（使用1024位RSA时），其中包含加密的MN_AAA密钥、MN_HA密钥、CHAP密钥、MN_验证器和AAA_验证器。四（4）字节的公钥标识符连接到加密的有效负载。
AAA_Authenticator:
-----------------
AAA_Authenticator:
-----------------
The 64-bit AAA_Authenticator value decrypted by the Home RADIUS AAA Server.
由主RADIUS AAA服务器解密的64位AAA_验证器值。
Vendor-Type = 3 Vendor-Length = 10 bytes Vendor-Value = decrypted AAA_Authenticator from Home RADIUS AAA Server.
供应商类型=3供应商长度=10字节供应商值=从主RADIUS AAA服务器解密的AAA\U验证器。
Public Key Invalid:
------------------
Public Key Invalid:
------------------
The home RADIUS AAA Server includes this attribute to indicate that the public key used by the MN is not valid.
主RADIUS AAA服务器包含此属性，以指示MN使用的公钥无效。
Vendor-Type = 4 Vendor-Length = 2 bytes Vendor-Value = none.
供应商类型=4供应商长度=2字节供应商值=无。
Note: An Organization may define RADIUS VSAs using its own Organization identifier.
注意：组织可以使用自己的组织标识符定义RADIUS VSA。
Three Verizon Wireless Mobile IP Vendor/Organization-Specific Extensions (VSEs) (RFC 3115), required to support the DMU Procedure, are specified as follows:
支持DMU程序所需的三个Verizon Wireless Mobile IP供应商/组织特定扩展（VSE）（RFC 3115）规定如下：
Type: 38 (CVSE-TYPE-NUMBER)
型号：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).
Verizon Wireless供应商ID:12951（高阶八位字节为0，低阶八位字节为供应商的SMI网络管理私有企业代码，按IANA定义的网络字节顺序）。
0 7 8 15 16 31
---------------------------------------------------
| Type | Reserved | Length |
---------------------------------------------------
| Vendor/Org-ID |
---------------------------------------------------
| Vendor-CVSE-Type | Vendor-CVSE-Value ... |
---------------------------------------------------
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
图7。关键供应商/组织特定扩展
MIP_Key_Request:
---------------
MIP_Key_Request:
---------------
The Home RADIUS AAA Server includes this extension to indicate that MIP key update is required.
Home RADIUS AAA服务器包含此扩展以指示需要MIP密钥更新。
Length = 7
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.
注：RFC 3115编辑器声明保留字段不包括在长度确定中。供应商CVSE类型=1供应商CVSE值=在RADIUS MIP\ U Key\ U Update\ U请求属性中发送的PKOID。
MIP_Key_Data:
------------
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.
密钥数据有效负载包含加密的MN_AAA密钥、MN_HA密钥、CHAP密钥、MN_验证器和AAA_验证器。此有效负载还包含公钥标识符。
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.
长度=138注：长度取决于RSA模数的大小。例如，使用RSA-512时，长度=74字节。供应商CVSE类型=2供应商CVSE值=128字节RSA加密有效负载（使用1024位RSA时），其中包含加密的MN_AAA密钥、MN_HA密钥、CHAP密钥、MN_验证器和AAA_验证器。四（4）字节公钥标识符和DMUV连接到加密的有效负载。
AAA_Authenticator:
-----------------
AAA_Authenticator:
-----------------
The 64-bit AAA_Authenticator value decrypted by the Home RADIUS AAA Server.
由主RADIUS AAA服务器解密的64位AAA_验证器值。
Length = 14 bytes Vendor-CVSE-Type = 3 Vendor-CVSE-Value = decrypted AAA_Authenticator from the Home RADIUS AAA Server.
长度=14字节供应商CVSE类型=3供应商CVSE值=从主RADIUS AAA服务器解密的AAA\U验证器。
Public Key Invalid:
------------------
Public Key Invalid:
------------------
The Home RADIUS AAA Server includes this extension to indicate that the public key used by the MN is not valid.
Home RADIUS AAA服务器包含此扩展以指示MN使用的公钥无效。
Length = 6 bytes Vendor-CVSE-Type = 4 Vendor-CVSE-Value = none.
长度=6字节供应商CVSE类型=4供应商CVSE值=无。
Note: An Organization may define VSEs using their own Organization identifier.
注意：组织可以使用自己的组织标识符定义VSE。
The 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 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.
公钥标识符（Pub_Key_ID）在动态移动IP更新（DMU）过程中使用，以允许RADIUS AAA服务器区分不同的公钥（可能由不同的制造商、服务提供商或其他组织分配）。公钥标识符由PKOID、PKOI、pku标识符和ATV字段组成。DMU版本字段启用DMU程序的后续修订。
----------------------------------------------
| PKOID | PKOI | PK_Expansion | ATV | DMUV |
----------------------------------------------
0 7 8 15 16 23 24 27 28 31
----------------------------------------------
| PKOID | PKOI | PK_Expansion | ATV | DMUV |
----------------------------------------------
0 7 8 15 16 23 24 27 28 31
Figure 8. Public Key Identifier and DMUV
图8。公钥标识符和DMUV
Each Public Key Organization (PKO) MUST be assigned a Public Key Organization Identifier (PKOID) to enable the RADIUS AAA Server to distinguish between different public keys created by different PKOs (see Table 1).
必须为每个公钥组织（PKO）分配一个公钥组织标识符（PKOID），以使RADIUS AAA服务器能够区分不同PKO创建的不同公钥（见表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 manufacturer 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.
如果服务提供商未向MN制造商提供（RSA）公钥，则制造商必须生成唯一的RSA公钥/私钥对，并使用RSA公钥（默认情况下为1024位模数）预加载每个MN。制造商可以与多个服务提供商共享相同的RSA私钥，只要（制造商）建立并维护了合理的安全程序，以防止向未授权方披露RSA私钥（解密）。
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.
公钥组织索引（PKOI）是一个8位字段，其值由PKO自行定义。例如，当创建公钥/私钥对时，设备制造商可以增量地为每个公钥/私钥对分配新的PKOI。
The PK_Expansion field enables support for additional PKOs or expansion of the PKOI.
PK_扩展字段支持其他PKO或PKOI扩展。
The DMU Version field allows for DMU Procedure version identification (see Table 2).
DMU版本字段允许DMU程序版本标识（见表2）。
The Algorithm Type and Version (ATV) field allows for identification of the public key algorithm and version used (see Table 3).
算法类型和版本（ATV）字段允许识别所使用的公钥算法和版本（见表3）。
Table 1. Public Key Organization Identification Table
表1。公钥组织标识表
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.
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.
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.
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.
PKOID 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.
PKOID 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 (Verizion Wireless).
注：80到FF将由PKOID管理员（Verizion Wireless）分配。
Table 2. DMU Version
表2。DMU版本
DMU Version DMU Version
Value
----------- -----------
00 RFC 4784
01 Reserved
02 Reserved
03 Reserved
04 Reserved
05 Reserved
06 Reserved
07 Cleartext Mode
DMU Version DMU Version
Value
----------- -----------
00 RFC 4784
01 Reserved
02 Reserved
03 Reserved
04 Reserved
05 Reserved
06 Reserved
07 Cleartext Mode
Table 3. Algorithm Type and Version
表3。算法类型和版本
ATV Public Key Algorithm
Value Type and Version
----- --------------------
00 Reserved
01 RSA - 1024
02 RSA - 768
03 RSA - 2048
04 Reserved
05 Reserved
06 Reserved
07 Reserved
ATV Public Key Algorithm
Value Type and Version
----- --------------------
00 Reserved
01 RSA - 1024
02 RSA - 768
03 RSA - 2048
04 Reserved
05 Reserved
06 Reserved
07 Reserved
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 (and hence, the bootstrapping of such MIP keys using the DMU Procedure) is essential to commercial delivery of Mobile IP service in cdma2000 1xRTT and HRPD/1xEV-DO networks or other networks that utilize Mobile IP.
动态移动IP密钥更新（DMU）过程能够高效、安全地交付关键移动IP加密密钥。在cdma2000 1xRTT和HRPD/1xEV DO网络或其他利用移动IP的网络中，加密密钥的使用（因此，使用DMU过程引导此类MIP密钥）对于移动IP服务的商业交付至关重要。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] TIA/EIA/IS-2000 Series, Revision A, Telecommunications Industry Association, March 2000.
[2] TIA/EIA/IS-2000系列，A版，电信行业协会，2000年3月。
[3] TIA/EIA/IS-856, cdma2000(R) High Rate Packet Data Air Interface Specification, Telecommunications Industry Association, November 2000.
[3] TIA/EIA/IS-856，cdma2000（R）高速分组数据空中接口规范，电信行业协会，2000年11月。
[4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[4] Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[5] Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[6] TIA/EIA/IS-835-A, cdma2000(R) Wireless IP Network Standard, Telecommunications Industry Association, May 2001.
[6] TIA/EIA/IS-835-A，cdma2000（R）无线IP网络标准，电信行业协会，2001年5月。
[7] ANSI/TIA/EIA-41-D-97, Cellular Radiotelecommunications Intersystem Operations, Telecommunications Industry Association, December 1997
[7] ANSI/TIA/EIA-41-D-97，蜂窝无线电信系统间运营，电信行业协会，1997年12月
[8] ANSI/TIA/EIA-683-B-2001, Over-the-Air Service Provisioning of Mobile Stations in Spread Spectrum Systems, Telecommunications Industry Association, December 2001
[8] ANSI/TIA/EIA-683-B-2001，扩频系统中移动站的空中服务供应，电信行业协会，2001年12月
[9] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[9] Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[10] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization-Specific Extensions", RFC 3115, April 2001.
[10] Dommety，G.和K.Leung，“移动IP供应商/特定于组织的扩展”，RFC3115，2001年4月。
[11] TIA-2001-A, Interoperability Specifications (IOS) for cdma2000(R) Access Network Interfaces, Telecommunications Industry Association, August 2001.
[11] TIA-2001-A，cdma2000（R）接入网络接口互操作性规范（IOS），电信行业协会，2001年8月。
[12] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[12] Eastlake，D.，3rd，Schiller，J.和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[13] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[13] 里格尼，C.，威拉斯，W.和P.卡尔霍恩，“半径延伸”，RFC 28692000年6月。
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.
感谢Jeffrey Dyck（高通公司）、James Willkie（高通公司）、Jayanth Mandayam（高通公司）、Marcello Lioy（高通公司）、Michael Borella（通信公司）、Cliff Randall（通信公司）、Daniel Cassinelli（通信公司）、Edward Dunn（通信公司）、Suresh Sarvepalli（通信公司）、Gabriella Ambramovici（朗讯公司）、Semyon Mizikovsky（朗讯公司）、Sarvar Patel（朗讯公司），彼得·麦肯（朗讯）、加纳蒂·桑达拉姆（朗讯）、吉里什·帕特尔（北电）、格伦·巴克斯利（北电）、黛安·汤普森（爱立信）、布赖恩·希克曼（爱立信）、索米·西查伦（布里奇沃特）、帕尔姆·桑杜（塞拉无线）、尤莲·穆卡诺（塞拉无线）和萨米·图阿蒂（爱立信），感谢他们的有益讨论和评论。
Appendix A: Cleartext-Mode Operation
附录A：明文模式操作
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 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.
DMU支持在DMUV=7的开发测试中使用明文模式。MIP_Key_数据有效负载将采用与对有效负载应用RSA 1024位加密相同的大小。在此模式下，MIP_Key_Data RADIUS属性和MIP供应商特定扩展名的长度分别为134字节和138字节。因此，在明文模式下，有效负载必须由48字节的密钥（MN_AAA、MN_HA和CHAP密钥）、8字节的AAA_验证器、3字节的MN_验证器组成。接下来的69个字节将用“0”位填充。
MIP_Key_Data = MN_AAAH key, MN_HA key, CHAP_key, MN_Authenticator, AAA_Authenticator, Padding (69 bytes), Public_Key_IDi, DMUV
MIP_Key_Data=MN_AAAH Key，MN_HA Key，CHAP_Key，MN_Authenticator，AAA_Authenticator，Padding（69字节），Public_Key_IDi，DMUV
Where:
哪里：
MN_AAA key = 128-bit random MN / RADIUS AAA Server key.
MN_AAA密钥=128位随机MN/RADIUS AAA服务器密钥。
MN_HA key = 128-bit random MN / Home Agent (HA) key.
MN_HA密钥=128位随机MN/归属代理（HA）密钥。
CHAP_key = 128-bit random Simple IP authentication key.
CHAP_密钥=128位随机简单IP身份验证密钥。
MN_Authenticator = 24-bit random number.
MN_验证器=24位随机数。
AAA_Authenticator = 64-bit random number used by MN to authenticate the RADIUS AAA Server.
AAA_Authenticator=MN用于验证RADIUS AAA服务器的64位随机数。
Padding = 69 bytes of 0's.
填充=0的69字节。
DMU Version (DMUV) = 4-bit identifier of DMU version.
DMU版本（DMUV）=DMU版本的4位标识符。
Public Key Identifier (Pub _Key_ID) = PKOID, PKOI, PK_Expansion, ATV
公钥标识符（发布密钥ID）=PKOID、PKOI、PKU扩展、ATV
Where:
哪里：
Public Key Organization Identifier (PKOID) = 8-bit serial number identifier of the Public Key Organization (PKO) that created the Public Key.
公钥组织标识符（PKOID）=创建公钥的公钥组织（PKO）的8位序列号标识符。
Public Key Organization Index (PKOI) = 8-bit serial number used at PKO discretion to distinguish different Public/Private key pairs.
公钥组织索引（PKOI）=PKO自行决定使用的8位序列号，用于区分不同的公钥/私钥对。
PK_Expansion = 8-bit field to enable possible expansion of PKOID or PKOI fields. (Note: Default value = 0xFF)
PK_Expansion=8位字段，用于启用PKOID或PKOI字段的可能扩展。（注意：默认值=0xFF）
Algorithm Type and Version (ATV) = 4-bit identifier of the algorithm used.
算法类型和版本（ATV）=所用算法的4位标识符。
Authors' Addresses
作者地址
Christopher Carroll* Ropes & Gray LLP Fish & Neave IP Group One International Place Boston, MA 02110
Christopher Carroll*Ropes&Gray LLP Fish&Neave IP Group One International Place波士顿，马萨诸塞州02110
Phone: 617-951-7756 EMail: Christopher.Carroll@ropesgray.com
电话：617-951-7756电子邮件：克里斯托弗。Carroll@ropesgray.com
* This document was developed while at Verizon Wireless.
* 本文档是在Verizon Wireless开发的。
Frank Quick Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
美国加利福尼亚州圣地亚哥Morehouse大道5775号Frank Quick高通公司，邮编92121
Phone: 858-658-3608 EMail: fquick@qualcomm.com
电话：858-658-3608电子邮件：fquick@qualcomm.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org/copyright.html中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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 INTERNET SOCIETY, 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。