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
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キー更新手順は、（多くの場合の1xEV-DOと呼ばれる高速パケットデータを含む）（R）ネットワークを配布し、CDMA2000にモバイルIP（MIP）暗号化キーを更新するためのメカニズムです。動的移動体IP鍵更新（DMU）手順は、モバイルIPとして動作しているCDMA2000（R）パケットデータサービングノード（PDSN）を介してMIPモバイルノード（MN）とRADIUS認証、認可およびアカウンティング（AAA）サーバとの間で発生します外部エージェント（FA）。
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
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鍵更新手順は、配布およびモバイルIP（MIP）、CDMA2000（R）の1xRTT（1X）[2]及び高速パケットデータ（HRPD）/の1xEV-DOネットワーク[3における暗号鍵を更新するための機構であります]。動的移動体IP鍵更新（DMU）手順は、cdma2000（R）パケットを介してモバイルIPモバイルノード（MN）とホームRADIUS [4]（または直径[5]）の認証、認可およびアカウンティング（AAA）サーバとの間で発生しますデータサービングノードのモバイルIP外部エージェント（FA）として機能している（PDSN）。 （本書では、私たちが訪問したシステムに配置することができるAAAサーバとは対照的に、ホームAAAサーバを示すために、頭文字AAAHを使用しています。）この手順は、米国電気通信工業会に準拠した無線システムをサポートすることを目的としている（TIA）TR- 45標準IS-835 [6]。 DMUは、しかしながら、モバイルノード（MN）とRADIUS AAAサーバの間で共有される秘密のブートストラップを可能にするために、任意のMIPネットワークにおいて実行することができます。
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手順が確実に一意MIPキー同じRSA公開鍵を使用して、CDMA2000（R）1X及びHRPD /の1xEV-DOモバイルノード（MN）のに潜在的に何百万を配布するRSA公開鍵暗号を利用します。
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メーカー）MIPキーを事前に生成することができる（そして、チャレンジハンドシェイク認証プロトコル（CHAP）キー）とプレ暗号化MIPキーを前DMU手順の開始に。この事前計算能力を採用することにより、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
1）鍵配布を暗号化し、2）相互認証：DMU手順は、基本的に、より容易に別々機構の二つの機能の目標を記述することによって理解される認証および鍵配布プロトコルです。
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が、（MNメーカーによって）共通RSA公開（暗号化）キーが事前にロードすることができます。また、サービスプロバイダは、独自のRSA公開鍵/秘密鍵のペアを生成し、唯一のMNの事前ロードするためのMNメーカーへのRSA公開鍵を配布することができます。
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は、事前に生成し、DMUプロセス中にホームRADIUS AAAサーバに配布するためにMIPキーを暗号化することができます。代替的に、MNの製造業者は、MIPキーを事前に生成するMIPキーペイロードを暗号化し、DMU手順を可能にするために、複数の暗号化されたMIPキーペイロードとMNを事前ロードすることができます。
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_Key_Dataと後で定義）暗号化されたペイロードを受信すると、AAAサーバは、ペイロードを復号化し、MIPキーを回復するために、RSAプライベートキーを使用しています。
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.
MNはにRSA暗号を利用しながら、相互認証は、[7]のcdma2000（R）1Xホームロケーションレジスタ（HLR）とその関連する認証センター（AC）にRADIUS AAAサーバによってMN /デバイス認証の委任によって達成することができます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）はCDMA2000（R）1Xネットワークと既存の認証キー（キー）と共有秘密データ（SSD）を持っていることを前提としています。 MSの発呼が発生した場合、ACはMSを認証します。認証が成功すると、BSは、移動局識別子（MSID）を通過（例えば、モバイル識別番号（MIN））PDSNへ。 「認証MSID」は、次に[4] RADIUS AAAサーバにPDSNから送信されたRADIUSアクセス要求（ARQ）メッセージに含まれています。 RADIUS AAAサーバを格納しているためMNのサブスクリプションに関連付けられているMSID、RADIUS AAAサーバはすなわち、「認証MSIDは、」RADIUS AAA MSIDと一致した場合に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による）サーバー認証はRADIUS AAAサーバにMNから送られた暗号化されたペイロードで乱数（AAA_Authenticator）を含むことにより有効になります。唯一の適切なRSA秘密鍵の所有者は、ペイロードを復号化し、ユニークなAAA_Authenticatorを回復する能力を持つことになります。 MNは、（RADIUS AAAサーバから返された）正しいAAA_Authenticatorを受信した場合、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
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-キー/ SSDの認証の1xEV-DOでは利用できない、または特定のCDMA2000（R）1Xネットワークは、鍵認証をサポートしないかもしれないので、DMU手順はまたによって生成された乱数（MN_Authenticator）を含みます（のみ1XEV DOネットワークにおいて）MNを認証任意にRADIUS AAAサーバをイネーブルにMN（及び/又は製造者によって予めロードされました）。
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_Authenticatorは、攻撃者によって傍受し、可能な再利用を防止するために、RSA暗号化MIP_Key_Dataペイロード内MNからホームAAAサーバに送信されます。理想的には、MN_Authenticatorは、ワンタイムパスワードとして利用されています。しかし、RSA暗号化がMN_Authenticatorが、おそらく各サービスプロバイダの鍵配布ポリシーに基づいて再使用することができます。
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_Authenticatorも解読され、ホームRADIUS AAAサーバ内に格納されMN_Authenticatorのコピーと比較されます。ホームRADIUS AAA Serverは、標準の範囲外の多数の可能な方法のいずれかを利用して（CDMA2000（R）ネットワークを使用していない）アウトオブバンドMN_Authenticatorのコピーを受信します。例えば、MN_Authenticatorであってもよい：1）MN、加入者プロファイルへの入力から販売時点プロビジョナによって読み出され、に課金/提供システムを介して、ネットワークアクセス識別子（NAI）と共に、送達さホームRADIUS AAAサーバ、2）は、口頭対話型音声認識サーバとのインタフェース、ユーザによるコール、または3）入力を介してカスタマーケア代表に伝え。アウトオブバンドMN_Authenticatorの配信は、サービスプロバイダの実装の柔軟性を最大化するために、この文書で指定されていません。
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_Authenticatorを抽出することが可能です。しかしながら、そのような開示に関連するリスクは最小です。 HRPD /の1xEV-DO MNが最初の登録プロセスの間にデバイス識別子を送信しないので、攻撃者が、あっても盗まれたMN_Authenticatorと、特定のMN装置又は一般的に直前DMU手順にプロビジョニングされたNAIとパスワードを関連付けることができません開始。
The MN_Authenticator is typically generated by a random/pseudorandom number generator within the MN. MN_Authenticator generation is initiated by the MN user; however, it may be initially pre-loaded by the manufacturer. When the MN_Authenticator is reset (i.e., a new MN_Authenticator is generated), all MIP_Data_Key payloads using the previous MN_Authenticator are discarded and the MN immediately re- encrypts a MIP_Key_Data payload containing the new MN_Authenticator. The MN_Authenticator MUST NOT change unless it is explicitly reset by the MN user. Thus, the MN will generate new MIP_Key_Data payloads using the same MN_Authenticator until the MN_Authenticator is updated.
MN_Authenticatorは通常、MN内のランダム/擬似乱数ジェネレータによって生成されます。 MN_Authenticator生成はMNのユーザによって開始されます。しかし、それが最初に製造者によって予めロードされてもよいです。 MN_Authenticator（すなわち、新しいMN_Authenticatorが生成される）がリセットされたとき、前MN_Authenticatorを使用して、すべてのMIP_Data_Keyペイロードを廃棄し、MNが直ちに再れる新しいMN_Authenticatorを含むMIP_Key_Dataペイロードを暗号化します。それが明示的にMNのユーザーによってリセットされない限り、MN_Authenticatorは変化してはいけません。したがって、MNはMN_Authenticatorが更新されるまで同じMN_Authenticatorを使用して、新しいMIP_Key_Dataペイロードを生成します。
-------------------------
| 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_AuthenticatorとMIP_Key_Dataペイロードステートマシン
**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_Authenticatorは、通常、MNによって生成されるので、MN_Authenticatorのメーカープリロードは必須ではありません。しかし、メーカー予圧は、サービス・プロバイダ・プロビジョニング・システムに入るためMN_Authenticatorを回復するモデムなどのデバイスへのアクセスプロビジョニングの負担を軽減することができます。
The DMU procedure has numerous advantages over the current Over-the-Air Service Provisioning (OTASP) [8] procedure, including:
DMU手順は、現在のオーバーザエアーサービスプロビジョニング（OTASP）[8]手順、を含むオーバー多くの利点を有します。
* 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はリレーモードMSにおけるMNにMIPキー配布を容易にします。 OTASPはMSにMIPキーを提供します。例えば、OTASPはMSモデムとのインタフェースラップトップMNにMIPキーを配信することはできません。
* Pre-encryption of MIP_Key_Data allows the DMU procedure to be an order of magnitude faster than Diffie-Hellman Key Exchange.
* MIP_Key_Dataの事前暗号化は、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は、偽のBSはその付近でのMNのためのMIPキーを変更するにはサービス拒否（DoS）攻撃から保護されています。 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社の動的モバイルIPアップデート手順が不可欠MIP暗号鍵（例えば、MN-AAAHキーとMN-HAキー）とシンプルIP CHAPキーを配布するための安全な、まだ非常に効率的なメカニズムです。 DMUプロトコルはMIP_Key_Dataとして知られている暗号化鍵材料ペイロード、の事前計算を可能にします。 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はまた、MNのユーザーの効率やセキュリティ要件に応じて、768ビットまたは2048ビットのRSAをサポートするかもしれません。小さいまたはゼロ以外のビット数が少ないパブリックRSA指数を使用してRSA演算スピードアップ（例えば、65537）が許容されます。
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は、モバイルIP（MIP）、CDMA2000（R）のMNのための鍵配信の効率を最大化するように設計されています。公開鍵証明書を使用するには、認証局（CA）がMNに配信RSA公開鍵を保証できるようにすることで、MIPキー更新プロセスの柔軟性を改善するだろう。残念ながら、公開鍵証明書の使用が大幅にMIPキー更新プロセスの効率（速度とオーバーヘッド）を低減するであろう。例えば、各MNは、CAの公開鍵を事前にロードする必要があります。 MIP鍵配布プロセス中に、ネットワークは、最初にMNへ（証明書）のRSA公開鍵を提供しなければなりません。 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パケットデータ環境では、多対1（または少数の）分布モデルは、多くのユーザーが自分のモバイルIPのセキュリティアソシエーション（すなわち、暗号化キー）を確立するために、1つのワイヤレスキャリアとのインターフェイスする、存在しています。
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_AAAHキー、MN_HAキー、およびシンプルIP CHAPキーを生成するために、各MNに依存しています。各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キーは（AAA_AuthenticatorとMN_Authenticatorと共に）MIP_Key_Dataペイロードにカプセル化し、暗号化されています。 MIP_Key_Dataペイロードは（RFC 3115 [10]モバイルIPベンダ/組織固有の拡張を参照）MIPベンダー/としてMNのMIP登録要求（RRQ）組織固有の拡張（VSE）に付加されます。 PDSNは、RADIUSアクセス要求（ARQ）メッセージにMIP RRQを変換するとき、MIP_Key_Dataペイロードはベンダー固有のRADIUS属性（VSA）にMIPベンダ/組織的な特定の拡張から変換されます。
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サーバは、RSA公開（暗号化）に関連したRSA秘密（解読）キーを使用してMIP_Key_DataペイロードがMIP_Key_Dataペイロードを暗号化するために使用される復号化します。次のようにMIP_Key_Dataが定義されています。
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キー、MN_HAキー、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インタフェース認証[11]のために使用されるAT-CHAPキーと同じではありません。
MN_Authenticator = 24-bit random number (displayed as an 8 decimal digit number). (To be used for 1xEV-DO networks.) (encrypted)
MN_Authenticator = 24ビットの乱数（8進の桁数として表示されます）。 （の1xEV-DOネットワークのために使用する。）（暗号化）
AAA_Authenticator = 64-bit random number used by MN to authenticate the RADIUS AAA Server. (encrypted)
RADIUS AAAサーバを認証するためにMNが使用するAAA_Authenticator = 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
公開鍵識別子（Public_Key_ID）= PKOID、pkoi、PK_Expansion、ATV
Where:
どこ：
Public Key Organization Identifier (PKOID) = 8-bit serial number identifier of Public Key Organization (PKO) that created the Public Key.
公開鍵組織識別子（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_Key_Dataペイロードは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公開鍵/秘密鍵のペア（複数可）を生成しなければなりません。サービスプロバイダ内の組織は、DMU手順のサポートに（MNメーカーに）、生成、管理、保護、およびRSA（RADIUS AAAサーバへの）秘密鍵と公開鍵を配布するために、サービスプロバイダによって指定されなければなりません。
Each RSA public/private key pair, generated by the wireless carrier, MUST be assigned a unique Public Key Identifier in accordance with Section 9.
無線キャリアによって生成された各RSA公開鍵/秘密鍵のペアは、第9条に基づいてユニークな公開鍵識別子を割り当てなければなりません。
RSA Private keys MUST be protected from disclosure to unauthorized parties. The service provider organization with the responsibility of generating the RSA public/private key pairs MUST establish 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 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.
RSA公開鍵は自由に（公開鍵識別子と一緒に）すべてのMNメーカーに配布することができます。 1つのRSA公開鍵はのMNの万人に配布することができるので、電子メール、フロッピーディスク、またはウェブサイトを経由してMNメーカーにRSA公開鍵（公開鍵と識別子）を配布することが可能です。好ましい方法は、単純に各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サーバの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.
ワイヤレスサービスプロバイダは、メーカー、生成されたRSA公開鍵付きのMNをプリインストールしているMNのメーカーからのRSA秘密鍵（S）（および公開鍵Identifier）を受け入れることができます。
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.
MNメーカー（S）からAAAサーバへのRSA秘密鍵（複数可）の送達は、この文書の範囲外です。ただし、暗号化された電子メールまたは物理的（メール）の配信を経由してRSA秘密鍵（S）配信が可能性が許容されます。
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 Serverは、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更新状態フィールドはKEYS（1）を更新するように設定されている場合、RADIUS AAAサーバはアクセスにMIP_Key_Request属性がPDSNに送信されたメッセージを拒否などによってDMU手順を開始しなければなりません。 MIPアップデート状態フィールドには、更新するように設定することができます
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).
ITポリシーに基づくサービスプロバイダの課金/プロビジョニングシステムによってKEYS（1）。復号化MN_AAAキーを使用してMN-AAA認証拡張を検証する際に、更新されたキーにMIPアップデート状態フィールドを設定しなければならないRADIUS AAAサーバ（2）。その後のRRQ / ARQにMN-認証拡張を検証する際に、RADIUS AAAサーバは（0）有効なキーにMIPアップデート状態フィールドを設定しなければなりません。
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準拠PDSNから受信されなかった場合はDMUは、ベンダー固有の属性を含めるべきではありませんサポートするRADIUS AAAサーバ。アクセスのこの使用は、本文書に基づいて将来の仕事のために強く推奨されて拒否します。今後の課題は、このベンダー固有の属性を運ぶためにアクセスチャレンジの使用を検討すべきです。
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サーバは三つの状態（0 = KEYS VALID、1 = UPDATEキー、2 = KEYS更新）のいずれかで、各サブスクリプションのために、MIPアップデート状態フィールドを維持しなければなりません。
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_Key_Dataペイロードの暗号化部分を解読しなければなりません。
The RADIUS AAA Server MUST check the MN_AAA Authentication Extension of the DMU RRQ using the decrypted MN_AAA key.
RADIUS AAA Serverは、復号化さ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サーバは、ベンダー固有のRADIUS属性として受け入れAccessでAAA_Authenticatorを含まなければなりません。
The RADIUS AAA Server MUST support the MN_Authenticator options specified in Section 6.1.
RADIUS AAAサーバは、セクション6.1で指定されたMN_Authenticatorオプションをサポートしなければなりません。
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 ServerはMN_AAAキー、MN_HAキー、およびサブスクリプションごとにAAA GUIを介したシンプル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 Serverは、MIN /国際移動加入者識別（IMSI）を検証するメカニズムを提供しなければなりません。 MIN / IMSIの検証がオンのときは、RADIUS AAA Serverは、MINを比較しなければなりません/ IMSIは、AAAサブスクリプションレコード/プロファイルにMIN / IMSIとPDSNから送信されました。 MINまたはのIMSIが一致しない場合は、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_Authenticatorを無視」ビットがセットされていない場合は、RADIUS AAA ServerはMN_AuthenticatorMN = MN_AuthenticatorAAAかどうかをチェックしなければなりません。 MN_Authenticatorsが一致しない場合は、RADIUS AAAサーバはアクセスをPDSN / FAに拒否送らなければなりません。アクセスがMIP_Key_Data要求を含んではならない拒否します。
The RADIUS AAA Server MUST include its PKOID (or another designated PKOID) in the MIP_Key_Request RADIUS Attribute.
RADIUS AAA Serverは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サーバは、RADIUS AAAサーバで有効なPKOIDsのリストをMIP_Key_Data RADIUSアトリビュートで送信PKOIDを比較しなければなりません。 PKOIDが有効でない場合、RADIUS AAA Serverは、「無効な公開鍵」Verizon WirelessのRADIUSベンダー固有属性（VSA）をPDSNに拒否にアクセスを送らなければなりません。注意：同じ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.
アクセスにおけるベンダー固有の属性を含めることは、メッセージを拒否していることに注意するのセクション5.44と一致していない[4]。対応するアクセス要求メッセージは、DMU準拠PDSNから受信されなかった場合はDMUは、ベンダー固有の属性を含めるべきではありませんサポートするRADIUS AAAサーバ。アクセスのこの使用は、本文書に基づいて将来の仕事のために強く推奨されて拒否します。今後の課題は、このベンダー固有の属性を運ぶためにアクセスチャレンジの使用を検討すべきです。
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).
3GPP2 X.S0011-005-Cに指定されているRADIUS AAA Serverは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.
UPDATEのKEYS（1）とキーを更新するときRADIUS AAA Serverは常に（2）の状態が設定されている特定の加入者のためのCDMA2000（R）アクセスノード（AN）からアクセス要求を受け入れるべきです。 KEYS VALID（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 ServerはKEYS VALID状態にある間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_Authenticatorを事前にロードする必要があります。
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は、（RFC 4086に従って）MN_AAA、MN_HA、およびCHAPランダム/擬似ランダムキー生成をサポートしなければなりません。
The MN MUST support random/pseudo-random AAA_Authenticator and MN_Authenticator generation (in accordance with RFC 4086).
MNは、（RFC 4086に従って）ランダム/擬似ランダムAAA_AuthenticatorとMN_Authenticator生成をサポートしなければなりません。
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_Dataペイロードが計算されているかどうかをチェックしなければなりません。何MIP_Key_Dataペイロードが存在しない場合、MNはMIP_Key_Dataペイロードを生成して保存する必要があります。 MNは、少なくとも一つの事前生成さMIP_Key_Dataペイロードを維持しなければなりません。
The MN MUST construct the MIP_Key_Data payload in accordance with Section 4.5.
MNは、セクション4.5に従ってMIP_Key_Dataペイロードを構築しなければなりません。
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ベライゾンワイヤレスベンダ/組織的な特定の拡張（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_Request含むRRPを受信すると、MNはMIP_Key_Requestで送信されたPKOIDをチェックしなければなりません。 MNはPKOIDに関連する公開鍵を持っている場合、MNは、その公開鍵を使用してMIP_Key_Dataペイロードを暗号化する必要があります。
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は、複数の公開鍵をサポートしている場合、デフォルトの公開鍵として1つの公開鍵を指定する機能を持たなければなりません。
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は、モバイル・ホーム認証拡張した後、ベライゾン・ワイヤレスMIP_Key_Data VSE（または別の組織固有のMIP_Key_Data VSE）を挿入しますが、MN-AAA認証拡張機能の前にしなければなりません。存在する場合MIP_Key_Data拡張にも、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拡張を剥ぎ取ることがあります。この問題が発生した場合、HAは、DMU拡張を処理するために、それは必要ありません。その他の互換性の問題は、様々な場所での拡張機能を配置するさまざまなベンダーからのFAでのテスト中に同定されています。拡張子の明示的な配置は、これらの問題を解消します。
Upon initiation of the DMU Procedure, the MN MUST compute the MIP authentication extensions using the newly-generated temporary MN_AAA and MN_HA keys. Upon receipt of the AAA_Authenticator MIP Extension, the MN MUST compare the AAA_AuthenticatorMN (sent in the encrypted MIP_Key_Data payload) with the AAA_AuthenticatorAAA (returned by the RADIUS AAA Server). If both values are the same, the MN MUST designate the temporary MN_AAA, MN_HA key, and the Simple IP CHAP key as permanent. The MN MUST set its MIP Update State field to KEYS VALID.
DMU手順が開始されると、MNは、新たに生成された一時MN_AAAとMN_HAキーを使用してMIP認証拡張を計算しなければなりません。 AAA_Authenticator MIP拡張を受信すると、MNはAAA_AuthenticatorAAA（RADIUS AAAサーバから返された）と（暗号化MIP_Key_Dataペイロードで送ら）AAA_AuthenticatorMNを比較しなければなりません。両方の値が同じであれば、MNは一時的MN_AAA、MN_HAキー、および恒久的なような単純なIP CHAPキーを指定する必要があります。 MNは、有効なキーにそのMIPアップデート状態フィールドを設定しなければなりません。
The MN MUST support reset (re-generation) of the MN_Authenticator by the MN user as specified in Section 6.2.
セクション6.2で指定されるようにMNは、MNユーザによってMN_Authenticatorのリセット（再生成）をサポートしなければなりません。
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_Authenticatorを表示するためにMNのユーザーを有効にする必要があります。 MN_Authenticator（24ビットの乱数）セクション6.2で指定されるように8進の桁数として表示されなければなりません。
The MN manufacturer MUST pre-load each MN with a unique random 24-bit MN_Authenticator.
MNの製造元は、一意のランダムな24ビットMN_Authenticator各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_Authenticatorのリセット時、MNは古いMN_Authenticatorに基づいて、すべてのMIP_Key_Dataペイロードを削除し、（MN_Authenticatorが明示的にMNユーザによって再びリセットされるまで）、新しいMN_Authenticatorを使用して、後続のすべてのMIP_Key_Dataペイロードを生成しなければなりません。
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ビットの鍵の16進数の桁のエントリをサポートしなければなりません。 （注：特定のシンプルIPデバイスのみCHAPキーとしてパスワードのASCIIエントリを有効に将来のデバイスは、両方の機能を提供することが許容される、すなわち、キーのパスワードまたは16進のASCIIを著者らは、強力な暗号化を使用することをお勧めします。キーを押します。）
The MN MUST support the Verizon Wireless MIP Vendor/Organization-Specific Extensions specified in Section 9.
MNは、第9章で指定されたベライゾン・ワイヤレスMIPベンダー/組織固有の拡張機能をサポートしなければなりません。
The MN MUST update the RRQ Identification field when re-transmitting the same MIP_Key_Data in a new RRQ.
新しいRRQで同じMIP_Key_Dataを再送信するとき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は、セクション9で指定されたセクション8、ベライゾンワイヤレスMIPベンダ/組織固有の拡張（VSEs）で指定されたベライゾン・ワイヤレスRADIUSベンダー固有の属性（VSA）をサポートしなければなりません。
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と別の組織識別子を使用して、セクション9で指定されたMIPのVSEsで指定されたRADIUS VSAをサポートするかもしれません。
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_Request VSAを含む拒否、PDSNはMIP_Key_Request VSEとMNにRRPを送らなければなりません。 PDSNは、= 89（ベンダー固有）RRPエラーコードを使用しなければならないし、送信後に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_Authenticator VSAを含むアクセスを受信すると、PDSNはAAA_Authenticator MIP VSEとRRPを送らなければなりません。 PDSNは、= 89（ベンダー固有）RRPエラーコードを使用しなければならないし、送信後に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は、= 89（ベンダー固有）RRPエラーコードを使用しなければならないし、送信後に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.
アクセスにおけるベンダー固有の属性を含めることは、メッセージを拒否していることに注意するのセクション5.44と一致していない[4]。 DMUをサポートしているPDSNは、ベンダー固有の属性を含むメッセージを拒否アクセスを受け入れなければなりません。アクセスのこの使用は、本文書に基づいて将来の仕事のために強く推奨されて拒否します。今後の課題は、このベンダー固有の属性を運ぶためにアクセスチャレンジの使用を検討すべきです。
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_Key_Data VSEとRRQを受信すると、PDSNはMIP_Key_Data VSAとARQにRRQを変換しなければなりません。 PDSNは、RADIUS AAAサーバにARQを送らなければなりません。
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は、AccessからPKOIDを含まなければならないMIP_Key_Request MIP VSEでMIP_Key_Update_Request VSAは、MNに送信拒否。
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章で指定された拡張機能（VSEs）Verizon WirelessのMIPベンダー/組織固有をサポートしなければならない（注：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.)
HAは別の組織識別子を使用して、セクション9で指定されたMIP VSEsをサポートするかもしれません。 （注意：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
| |------------>|
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 |
| |<------------|
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 | | |
|<--------------| | |
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.各RSA公開鍵/秘密鍵のペアは、RFC 3447.に従って生成されなければならないそれぞれの公開鍵/秘密鍵のペアは、その作成者が独自の公開鍵識別子（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.
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）、CDMA2000（R）1X MNはA-キーとSSDでプロビジョニングされていると仮定すると1X MSが発呼を開始し、IS-2000ネットワークに対して自身を認証します。 IS-2000認証成功時には、BSは、PDSNに "認証済み" MSID（例えば、MIN）を送信します。
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は、RADIUSアクセス要求（ARQ）メッセージにMIP RRQを変換ARQにMSIDを含む、ホームRADIUS AAAサーバにARQを転送します。
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サーバ（NAIに関連する）、その加入者データベース内のMSIDと（PDSNから送信された）認証されたMSIDを比較します。 AAA MIPアップデート状態フィールドがKEYS（1）を更新するように設定されている場合は、RADIUS AAA Serverは、パケット・データ・アクセスを拒否し、MIP鍵の更新を注文します。
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）を拒否し、MNにRRPを送信アクセスに変換します。 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更新州= UPDATEキーを設定します。 MNは何も事前に生成し、暗号化前のMIP_Key_Dataペイロードを持っている場合は、MNはしなければならない、公開鍵識別子を除き、RFC 4086.に従ってMN_AAAキー、MN_HAキー、章キー、MN_Authenticator、およびAAA_Authenticatorを生成しません生成されたすべての値がなければなりません。プリロードされたRSA公開（暗号化）キーを使用して暗号化します。新しく生成されたMN_AAATEMPキーとMN_HATEMPは、現在のRRQのためのMN-AAAとモバイル・ホーム認証拡張機能を計算するのに使用しなければなりません。注：MNは、ペイロードは、各MNのパワーアップまたはアプリケーション開始時に存在するかどうかをチェックすることによってMIP_Key_Dataペイロードを事前に計算することができます。
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はMIP_Key_Data RADIUS VSAとRADIUSのARQにRRQを変換し、ホームRADIUS AAAサーバにARQを転送します。 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サーバ（NAIに関連する）、その加入者データベース内のMSIDと（PDSNから送信された）認証されたMSIDを比較します。もしMSIDPDSN = MSIDAAA、RADIUS AAAサーバは、公開鍵識別子を使用して、適切なRSA秘密鍵を決定し、MIP_Key_Dataペイロードの暗号化部分を復号化します。 RADIUS AAAサーバは、復号化さMN_AAAキーを使用してMN-AAA認証拡張認証を検証します。成功した場合、RADIUS AAA Serverは、復号化さ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_Authenticator 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_Authenticator 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 MIP更新の状態は= KEYS VALID）MN_HAキーにMN_AAAキーとMN_HATEMPにMN_AAATEMPを割り当てます。それ以外の場合は、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はPDSNによってARQに変換し、RADIUS AAA Serverに転送された新しいRRQを開始します。
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に受け入れて送信します。
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は、MNにRRPを転送PDSN / FAにRRPを送信します。 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).
UDPメッセージ損失、RRQ再送、またはMNの故障による中断を考慮するために、DMU手順の堅牢性を向上させるために、RADIUS AAAサーバは、次の3つの状態（0 =キーのいずれかで、各サブスクリプションのために、MIPアップデート状態フィールドを維持しなければなりませんVALID、1 = UPDATEキー、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
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サーバはUPDATEキー状態にある場合、RADIUS AAA ServerはMIP_Key_Update_Request 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 Serverは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).
前記（C）が失われた場合、モバイル再送（C）。 RADIUS AAAサーバは、（C）を想定し、適切MIPキーを更新します。 KEYSへのRADIUS AAAサーバの移行が更新され、MIP_Key_Dataをコミットします。 RADIUS AAAサーバはAAA_Authenticator 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.
（D）が失われた場合4、同じ鍵データを用いて移動再送（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_Authenticator VSAとPDSNとARを再送AAA_Authenticatorを含む、（D）で応答します。
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 ServerはMIP_Key_Update_Request 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サーバが（C）で送信されたキーを用いて認証に失敗した、（A）受信した場合、RADIUS AAAサーバは、キーを更新するために、MIP_Key_Update_RequestとPDSN / FAの再送（B）、およびRADIUS AAAサーバ遷移をARに送信します。
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.
前記PDSN / FAは、（A）を受信すると、KEYS VALID状態とDMUプロセスにRADIUS AAAサーバにARQを転送し、MN-AAAオーセンティケータはMN_AAA鍵を用いて検証され、RADIUS AAAサーバ移行完了。
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
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手順は、セルラー認証および音声暗号化とCDMA2000（R）1Xネットワークにおけるよりも（偽MN攻撃を受けやすいです（CAVE）RAN認証）。この理由のため、DMU手順MN_Authenticatorを用いて支持デバイスツーネットワーク認証を任意する能力を有します。
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.
RADIUS AAAサーバへMN_Authenticator送達の方法は、サービスプロバイダDMU手順中にMNの認証をサポートするために最も効率的/最小侵入処置を決定するための柔軟性を可能にする、この文書の範囲外です。
The RADIUS AAA server MUST support three MN_Authenticator options:
RADIUS AAAサーバは、3 MN_Authenticatorオプションをサポートする必要があります。
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_Authenticatorを無視する機能を持たなければなりません。 RADIUS AAAサーバがMIP_Key_Dataペイロードを復号化する際に、例えば、AAAサーバは静かMN_Authenticatorを破棄する。
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 Serverは、（おそらく、サービスプロバイダーの顧客ケアや課金/プロビジョニングシステムを介して配信）MN_AuthenticatorAAAで（暗号化MIP_Key_Dataペイロードを介して配信）MN_AuthenticatorMNを比較しなければなりません。
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.
DMU手順が完了した後、RADIUS AAA Serverは、（カスタマーケア、対話型音声応答（IVR）、またはいくつかの他の不特定のプロセスを介して）MN_AuthenticatorAAAの送達のための送達MN_AuthenticatorMN待機を格納します。 MN_Authenticatorは、RADIUS AAAサーバに配信されると、AAAはMN_AuthenticatorAAAと（暗号化MIP_Key_Dataペイロードを介して配信）MN_AuthenticatorMNを比較しなければなりません。オーセンティケータが一致した場合には、RADIUS AAA ServerはMIPキーのアクセスと最終更新を許可します。
The Mobile Node (MN) MUST store the 24-bit MN_Authenticator.
モバイルノード（MN）は、24ビットMN_Authenticatorを格納しなければなりません。
The MN MUST display the MN_Authenticator as an 8 decimal digit number (via LCD display on a handset or via a GUI for a modem). If the MN resides within a handset, the user MAY display the MN_Authenticator using the following keypad sequence: "FCN + * + * + M + I + P + RCL". Otherwise, the MN MUST display the MN_Authenticator via the device's GUI.
MNは、（ハンドセット上またはモデムのためのGUIを介してLCDディスプレイを介して）8進の桁数としてMN_Authenticatorを表示しなければなりません。 "FCN + * + * + M + I + P + RCL"：MNは、携帯電話内に存在する場合、ユーザーは次のキーパッド・シーケンスを使用してMN_Authenticatorを表示することがあります。それ以外の場合は、MNは、デバイスのGUIを介してMN_Authenticatorを表示しなければなりません。
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_Authenticatorをリセットする機能を持たなければなりません。言い換えれば、MNは、RFC 4086.に従ってリセット機能は、出荷/保存時MN_Authenticatorの可能な妥協を緩和、無作為/疑似無作為ユーザコマンド時に新しい24ビットMN_Authenticatorを生成する能力を持たなければなりません。 "FCN + * + * + M + I + P + C + C + RCL"：MNは、携帯電話内に存在する場合、ユーザーは次のキーパッド・シーケンスを使用してMN_Authenticatorをリセットする場合があります。それ以外の場合は、MNは、デバイスのGUIを介してMN_Authenticatorをリセットしなければなりません。
The MN manufacturer MAY pre-load the MN with the MN_Authenticator. For example, by pre-loading the MN_Authenticator and affixing a sticker with the MN_Authenticator (8 decimal digit representation) to the MN (e.g., modem), the point-of-sale representative does not have to retrieve the MN_Authenticator from the MN interface.
MNメーカーはMN_AuthenticatorとMNを事前にロードします。例えば、MN_Authenticatorプリロード及びMN（例えば、モデム）にMN_Authenticator（8進数字表現）とのステッカーを貼り付けることによって、販売時点代表は、MNのインタフェースからMN_Authenticatorを取得する必要はありません。
[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_Authenticator / MIP_Key_Dataペイロード対の別個の一次及び二次のキューを維持することができます。 MNユーザがプライマリMN_Authenticatorをリセットすると、MNは、一次MN_Authenticator（および関連MIP_Key_Dataペイロード）を破棄し、一次MN_Authenticatorなどの二次キューにMN_Authenticatorを割り当て（一次待ち行列に関連するMIP_Key_Dataペイロードを割り当てます）。この機能は、MN_Authenticatorをリセットするユーザー/プロビジョニングを可能にし、すぐにMIP_Key_Dataペイロード事前暗号化の優位性を失うことなく、DMU手順を開始します。主キューへの二次からMN_Authenticator転送時には、MNは、二次キューのための新しいMN_Authenticatorと関連するMIP_Key_Dataペイロードを生成しなければなりません。 MNは、パワーアップやアプリケーションの開始時にプライマリとセカンダリの両方のMN_Authenticator / MIP_Key_Dataペイロード・キューをチェックしなければなりません。 MNは、各キュー内の少なくとも1つのMN_Authenticator / MIP_Key_Dataペイロードのペアを維持しなければなりません。
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_Authenticatorを使用してMN認証は、サービスプロバイダにRADIUS AAAサーバにMN_Authenticatorを提供する方法を決定する際に最大限の柔軟性を提供します。 MN_Authenticator送達の方法は、この文書の範囲外です。
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_Authenticatorが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 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.
加入者が最初に自分のHRPD /の1xEV-DOデバイス及びサービスを取得すると、販売時点代表は、販売時点でコンピュータ端末を介して課金/提供システムに加入情報を記録します。課金/プロビジョニングシステムは、販売時点代表MNデバイスのディスプレイを介して取得しMN_Authenticator、を含むRADIUS AAAサーバ（例えば、NAI、MSID、電子シリアル番号（ESN））に特定の情報を配信します。モデムの場合、製造者は、事前にロードMN_Authenticatorを有していてもよいし、モデムに取り付けられたステッカーにMN_Authenticatorのコピーを置きました。販売時点代表MN_Authenticatorの単にコピー8進数字の値顧客プロファイルに。 MNは、適切なNAIとパワーアップしてロードされると、MNは、RADIUS AAAサーバとのDMU手順を開始します。 RADIUS AAAサーバは、課金システム、配信MN_AuthenticatorとMN-配信MN_Authenticatorを比較します。オーセンティケータが一致した場合、RADIUS AAA Serverは、配信MIPキーを使用して加入者プロフィールを更新し、サービスを許可します。更新後のオプションは、RADIUS AAA Server内で有効になっている場合、それは、課金/提供システムを経由してMN_Authenticatorを受信するまで、RADIUS AAA Serverは、暫定的に、サブスクリプション・プロファイルを更新します。
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.
別のオプションとして、サービス・プロバイダは、HRPD /の1xEV-DO加入者がプロビジョニング番号を呼び出し、MN_Authenticatorを入力するIVRシステムを使用することができます。 IVRシステムは、最終的な検証とパケット・データ・アクセス用のRADIUS AAAサーバにMN_Authenticatorを提供します。
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手順は、のman-in-the-middle（MITM）攻撃を受けやすいです。しかし、このような攻撃は、比較的複雑で高価な表示されます。認証および鍵合意（AKA）はCDMA2000（R）1X内に配置されたときに、MITM攻撃は除去されます。 MITM攻撃の危険性は、必要な専門知識、攻撃の費用、および切迫したCDMA2000（R）1X相互認証保護を最小限に抑えています。特定のCDMA2000（R）1Xネットワークは、鍵認証をサポートしていない場合、MN_Authenticatorを任意に使用することができます。
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.
1つのRSA秘密鍵がのMN（RSA公開鍵）の何百万人に関連付けすることができるので、不正な第三者に開示からRSA秘密鍵を保護することが重要です。 MNメーカーがRSA公開鍵/秘密鍵のペアを生成している場合は、MNのメーカーは、適切なサービス・プロバイダへのRSA秘密鍵の普及に関する十分なセキュリティ手順/ポリシーを確立する必要があります。 RSA秘密鍵のみ正当CDMA2000（登録商標）サービスプロバイダに分配されなければなりません。サービスプロバイダは、独自の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.
MNはAAA_Authenticatorを回復することができる唯一の適切なRADIUS AAAサーバから、偽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 Serverは、必要に応じて不正MNの活性化を防ぐためにMN_Authenticatorを使用して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.)
MIPホームエージェントにRADIUS AAAサーバから配信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:
三つの新しいRADIUS属性は、DMU手順をサポートするために必要とされると、次のように指定されています。
Type: 26 Length: >9 Verizon Wireless Enterprise/Vendor ID: 12951
タイプ：26長さ：> 9ベライゾン・ワイヤレスエンタープライズ/ベンダーID：12951
MIP_Key_Update_Request:
----------------------
The Home RADIUS AAA Server includes this attribute to indicate that MIP key update is required.
ホームRADIUS AAA ServerはMIPキーの更新が必要であることを示すために、この属性が含まれています。
Vendor-Type = 1 Vendor-Length = 3 bytes Vendor-Value = PKOID of the RADIUS AAA Server
ベンダータイプ= 1つのベンダー長= 3バイトベンダー値RADIUS AAAサーバ= PKOID
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_Authenticator、およびAAA_Authenticatorを含むキーデータペイロード。このペイロードはまた、公開鍵識別子が含まれています。
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バイト。暗号化MN_AAAキー、MN_HAキー、CHAPキー、MN_Authenticator、及びAAA_Authenticatorが含まベンダー値= 128バイトRSA暗号ペイロード（1024ビットRSAが使用される場合）。 4（4）公開バイトキー識別子は、暗号化されたペイロードに連結されます。
AAA_Authenticator:
-----------------
The 64-bit AAA_Authenticator value decrypted by the Home RADIUS AAA Server.
ホームRADIUS AAAサーバによって復号化64ビットのAAA_Authenticator値。
Vendor-Type = 3 Vendor-Length = 10 bytes Vendor-Value = decrypted AAA_Authenticator from Home RADIUS AAA Server.
ホームRADIUS AAAサーバからAAA_Authenticator復号化されたベンダータイプ= 3ベンダー長= 10バイトのベンダー値=。
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 Serverは、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:
三社のベライゾンワイヤレスモバイルIPベンダー/組織固有の拡張機能（VSEs）（RFC 3115）、次のようにDMU手順をサポートするために必要な、指定されています。
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で、IANAによって定義されるように低次のオクテットは、ネットワークバイトオーダーでのベンダーのSMIネットワーク管理プライベートエンタープライズコードです）。
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:
---------------
The Home RADIUS AAA Server includes this extension to indicate that MIP key update is required.
ホームRADIUS AAA ServerはMIPキーの更新が必要であることを示すために、この拡張機能が含まれています。
Length = 7
長さ= 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 Editorは予約済みフィールドは長決定には含まれていないと述べています。ベンダーCVSE-タイプ= 1ベンダーCVSE-値= RADIUS MIP_Key_Update_Request属性で送信されPKOID。
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_Authenticator、およびAAA_Authenticatorを含むキーデータペイロード。このペイロードはまた、公開鍵識別子が含まれています。
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_Authenticator、及びAAA_Authenticatorを含みます。公開鍵識別子とDMUVバイト4（4）は、暗号化されたペイロードに連結されています。
AAA_Authenticator:
-----------------
The 64-bit AAA_Authenticator value decrypted by the Home RADIUS AAA Server.
ホームRADIUS AAAサーバによって復号化64ビットのAAA_Authenticator値。
Length = 14 bytes Vendor-CVSE-Type = 3 Vendor-CVSE-Value = decrypted AAA_Authenticator from the Home RADIUS AAA Server.
ホームRADIUS AAAサーバからAAA_Authenticator復号化された長さ= 14バイトのベンダーCVSE-タイプ= 3ベンダーCVSE-値=。
Public Key Invalid:
------------------
The Home RADIUS AAA Server includes this extension to indicate that the public key used by the MN is not valid.
ホーム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.
注意：組織は、自らの組織の識別子を使用してVSEsを定義することがあります。
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）はRADIUS AAAサーバは（異なるメーカー、サービスプロバイダ、または他の組織によって割り当てられることがあります）異なる公開鍵を区別できるようにするために、動的モバイルIPアップデート（DMU）手順の間に使用されます。公開鍵識別子はPKOID、PKOI、PK_Identifier、およびATVのフィールドで構成されます。 DMUバージョンフィールドは、DMU手順のその後の改正を可能にします。
----------------------------------------------
| 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）は、異なるPKOs（表1を参照）によって作成された異なる公開鍵を区別するためにRADIUS AAAサーバを有効にするために公開鍵組織識別子（PKOID）を割り当てなければなりません。
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.
サービスプロバイダーは（RSA）公開鍵とMNのメーカーに提供していない場合、メーカーはRSA公開鍵（デフォルトでは1024ビットモジュラス）を持つユニークなRSA公開鍵/秘密鍵のペアと予圧各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）は、その値がPKOの裁量で定義されている8ビットのフィールドです。ペアが作成されたときたとえば、デバイスの製造元が漸進各公開鍵/秘密鍵のペアのための新しいPKOIを割り当てることができます。
The PK_Expansion field enables support for additional PKOs or expansion of the PKOI.
PK_Expansionフィールドが追加PKOsまたはPKOIの拡大のためのサポートを可能にします。
The DMU Version field allows for DMU Procedure version identification (see Table 2).
DMU Versionフィールド（表2参照）DMU手順バージョン識別を可能にします。
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)
----- ------------------ ----- ------------------
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.
Note: 80 through FF will be assigned by the PKOID administrator (Verizion Wireless).
注意：FFを通じて80は、PKI管理者（ベライゾン・ワイヤレス）によって割り当てられます。
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
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
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暗号化キーの、効率的、かつ安全な配信を可能にします。暗号鍵の使用（したがって、DMU手順を使用してこのようなMIPキーのブートストラップ）は、CDMA2000 1xRTTの及びHRPD /の1xEV-DOネットワーク又はモバイルIPを利用して他のネットワーク内のモバイルIPサービスの商業的な送達に不可欠です。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソンを、 "リモート認証ダイヤルインユーザーサービス（RADIUS）で"、RFC 2865、2000年6月。
[5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[5]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、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、セルラRadiotelecommunicationsシステム間操作、電気通信工業会、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]ジョンソン、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.レオン、 "モバイルIPベンダ/組織固有の拡張"、RFC 3115、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）アクセスネットワークインタフェース、通信工業会、2001年8月のための相互運用仕様（IOS）。
[12] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[12]イーストレーク、D.、3、シラー、J.、およびS.クロッカー、 "セキュリティのためにランダム要件"、BCP 106、RFC 4086、2005年6月。
[13] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[13] Rigney、C.、Willats、W.、およびP.カルフーン、 "RADIUS拡張機能"、RFC 2869、2000年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.
ジェフリー・ダイク（クアルコム）、ジェームズ・Willkie（クアルコム）、Jayanth Mandayam（クアルコム）、マルチェロLioy（クアルコム）、マイケル・ボレッラ（CommWorks）、クリフ・ランドール（CommWorks）、ダニエル・カシネリ（CommWorks）、エドワード・ダン（CommWorks）のおかげで、スレシュSarvepalli（CommWorks）、ガブリエラAmbramovici（ルーセント）、セミヨンMizikovsky（ルーセント）、シャール・パテル（ルーセント）、ピーター・マッキャン（ルーセント）、ガナパシーSundaram（ルーセント）、Girishパテル（ノーテル）、グレン・バックスレイ（ノーテル）、ダイアン・トンプソン彼らの有益な議論とコメントについて（エリクソン）、ブライアン・ヒックマン（エリクソン）、Somsay Sychaleun（ブリッジウォーター）、PARM Sandhu（シエラワイヤレス）、イウリアンMucano（シエラワイヤレス）、そしてサミーTouati（エリクソン）。
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は、RSA 1024ビットの暗号化をペイロードに適用されたかのようにDMUV = 7 MIP_Key_Dataペイロードが同じサイズをとるであろう開発テストのためのクリアテキストモードをサポートします。このモードでは、MIP_Key_Data RADIUS属性およびMIPベンダー固有の拡張子は、それぞれ、長さが134バイト、138バイトであろう。このように、クリアテキストモードでは、ペイロードは48キー（MN_AAA、MN_HA、およびCHAPキー）のバイト、8バイトAAA_Authenticator、3バイトMN_Authenticatorから構成されなければなりません。次の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キー、MN_HAキー、CHAP_key、MN_Authenticator、AAA_Authenticator、パディング（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_key = 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.
RADIUS AAAサーバを認証するためにMNが使用するAAA_Authenticator = 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
公開鍵識別子（パブ_Key_ID）= PKOID、pkoi、PK_Expansion、ATV
Where:
どこ：
Public Key Organization Identifier (PKOID) = 8-bit serial number identifier of the Public Key Organization (PKO) that created the Public Key.
公開鍵組織識別子（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
クリストファー・キャロル*ロープ＆グレーLLPフィッシュ＆ニーブIPグループワンインターナショナル・プレイスボストン、MA 02110
Phone: 617-951-7756 EMail: Christopher.Carroll@ropesgray.com
電話：617-951-7756 Eメール：Christopher.Carroll@ropesgray.com
* This document was developed while at Verizon Wireless.
*このドキュメントは、ベライゾン・ワイヤレスでいる間に開発されました。
Frank Quick Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
フランク・クイックQualcomm社5775モアハウスドライブサンディエゴ、CA 92121 USA
Phone: 858-658-3608 EMail: fquick@qualcomm.com
電話：858-658-3608 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。