[要約] RFC 4784は、Verizon Wirelessのcdma2000(R)ネットワークにおける動的なモバイルIPキーの更新に関するものです。このRFCの目的は、モバイルIPキーの更新プロセスを定義し、ネットワークのセキュリティとパフォーマンスを向上させることです。
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
Verizon Wireless Dynamic MobileIPキーCDMA2000（R）ネットワークのアップデート
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）The IETF Trust（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 Dynamic Mobile IPキーアップデート手順は、CDMA2000（R）ネットワーク（1xev-doと呼ばれることが多い高レートパケットデータを含む）のモバイルIP（MIP）暗号キーを分散および更新するメカニズムです。動的モバイルIPキーアップデート（DMU）手順は、MIPモバイルノード（MN）とRADIUS認証、認証および会計（AAA）サーバーの間でCDMA2000（R）パケットデータ（PDSN）を介してモバイルIPとして機能するパケットデータ（PDSN）を介して発生します。外国人エージェント（FA）。
cdma2000(R) is a registered trademark of the Telecommunications Industry Association (TIA).
CDMA2000（R）は、Telecommunications Industry Association（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ワイヤレスダイナミックモバイルIPキーアップデート手順は、CDMA2000（R）1XRTT（1x）[2]および高レートパケットデータ（HRPD） / 1Xev-DoネットワークのモバイルIP（MIP）暗号キーを分散および更新するメカニズムです[3]。ダイナミックモバイルIPキーアップデート（DMU）手順は、モバイルIPモバイルノード（MN）とホーム半径[4]（または直径[5]）認証、認証および会計（AAA）サーバーの間でCDMA2000（R）パケットを介して発生します。モバイルIP外国人エージェント（FA）として機能しているノード（PDSN）にサービスを提供します。（このドキュメントでは、頭字語AAAHを使用して、訪問されたシステムにあるAAAサーバーとは対照的に、ホームAAAサーバーを示します。）この手順は、電気通信産業協会（TIA）TR-に準拠したワイヤレスシステムをサポートすることを目的としています。45標準IS-835 [6]。ただし、DMUは任意のMIPネットワークで実行され、モバイルノード（MN）とRADIUS AAAサーバーの間の共有秘密のブートストラップを有効にすることができます。
The DMU procedure utilizes RSA public key cryptography to securely distribute unique MIP keys to potentially millions of cdma2000(R) 1X and HRPD/1xEV-DO Mobile Nodes (MN) using the same RSA public key.
DMU手順では、RSA公開キーの暗号化を利用して、同じRSA公開キーを使用して、潜在的に数百万のCDMA2000（R）1XおよびHRPD/1XEV-DOモバイルノード（MN）に一意のMIPキーを安全に配布します。
By leveraging the existing cdma2000(R) 1X authentication process, the Dynamic Mobile IP Key Update process employs a mutual authentication mechanism in which device-to-network authentication is facilitated using cdma2000(R) 1X challenge-response authentication, and network-to-device authentication is facilitated using RSA encryption.
既存のCDMA2000（R）1X認証プロセスを活用することにより、ダイナミックモバイルIPキーアップデートプロセスは、CDMA2000（R）1Xチャレンジ - 応答認証を使用してデバイスからネットワークへの認証を促進する相互認証メカニズムを採用しています。デバイス認証は、RSA暗号化を使用して促進されます。
By utilizing RSA encryption, the MN (or MN manufacturer) is able to pre-generate MIP keys (and the Challenge Handshake Authentication Protocol (CHAP) key) and pre-encrypt the MIP keys prior to initiation of the DMU procedure. By employing this pre-computation capability, the DMU process requires less computation (by an order of magnitude) during the key exchange than Diffie-Hellman Key Exchange.
RSA暗号化を利用することにより、MN（またはMNメーカー）は、DMU手順の開始前にMIPキー（およびチャレンジハンドシェイク認証プロトコル（CHAP）キー）を事前に生成し、MIPキーを事前に暗号化することができます。この計算前機能を使用することにより、DMUプロセスでは、キーエクスチェンジ中にDiffie-Hellmanキーエクスチェンジよりも（桁違いに）少ない計算が必要です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
The DMU procedure is basically an authentication and key distribution protocol that is more easily understood by separately describing the mechanism's two functional goals: 1) encrypted key distribution and 2) mutual authentication.
DMU手順は、基本的に認証と主要な分布プロトコルであり、メカニズムの2つの機能的目標を個別に説明することでより簡単に理解できます。1）暗号化されたキー分布と2）相互認証。
By utilizing RSA public key cryptography, MNs can be pre-loaded with a common RSA public (encryption) key (by the MN manufacturer), while the associated RSA Private (decryption) key is securely distributed from the MN manufacturer to a trusted service provider. Alternatively, a service provider can generate its own RSA public/private key pair and only distribute the RSA public key to MN manufacturers for pre-loading of MNs.
RSA公開キーの暗号化を使用することにより、MNSは一般的なRSAパブリック（暗号化）キー（MNメーカーによる）で事前にロードできますが、関連するRSAプライベート（復号化）キーはMNメーカーから信頼できるサービスプロバイダーに安全に配布されます。。あるいは、サービスプロバイダーは独自のRSAパブリック/プライベートキーペアを生成し、MNSの事前荷重のためにRSA公開キーをMNメーカーにのみ配布することができます。
During the manufacturing process, the MN manufacturer pre-loads each MN with the RSA public key. When the MN is powered-up (or client application initiated), the MN can pre-generate and encrypt MIP keys for distribution to the Home RADIUS AAA Server during the DMU process. Alternatively, the MN manufacturer can pre-generate MIP keys, encrypt the MIP key payload, and pre-load the MN with multiple encrypted MIP key payloads to enable the DMU procedure.
製造プロセス中に、MNメーカーは各MNにRSAの公開キーを事前にロードします。MNが電源を入れる（またはクライアントアプリケーションが開始された）場合、MNはDMUプロセス中にホームRadius AAAサーバーに配布するためにMIPキーを事前に生成および暗号化できます。あるいは、MNメーカーはMIPキーを事前に生成し、MIPキーペイロードを暗号化し、MNに複数の暗号化されたMIPキーペイロードを事前にロードして、DMU手順を有効にすることができます。
During the initial registration process (or when the AAA requires MIP key update), the MN: 1) generates the appropriate MIP keys, CHAP key, and authentication information, 2) uses the embedded RSA public key to encrypt the payload information, 3) and appends the payload to the MIP Registration Request. The Registration Request is sent to the Mobile IP Foreign Agent (FA) via the cellular Base Station (BS) and Packet Data Serving Node (PDSN). When the RADIUS AAA Server receives the encrypted payload (defined later as MIP_Key_Data), the AAA Server uses the RSA Private key to decrypt the payload and recover the MIP keys.
最初の登録プロセス中（またはAAAがMIPキーアップデートを必要とする場合）、MN：1）適切なMIPキー、CHAPキー、および認証情報を生成します。ペイロードをMIP登録リクエストに追加します。登録リクエストは、携帯電話基地局（BS）とパケットデータ提供ノード（PDSN）を介してモバイルIP外国エージェント（FA）に送信されます。RADIUS AAAサーバーが暗号化されたペイロードを受信すると（後でmip_key_dataとして定義）、AAAサーバーはRSA秘密キーを使用してペイロードを復号化してMIPキーを回復します。
MN BS/PDSN/FA AAA
-- ---------- ---
| | |
------------------ | -------------------
| RSA Public Key | | | RSA Private Key |
| Pre-loaded by | | | Pre-loaded by |
| Manufacturer | | | Service Provider |
------------------ | -------------------
| Registration Request, |
| (MIP keys), RSA | |
| Public Key | |
|-------------------->| |
| | Access Request, (MIP keys),
| | RSA Public Key |
| |---------------------->|
| | -------------------
| | | Decrypt MIP |
| | | Keys using RSA |
| | | Private Key |
| | -------------------
Figure 1. RSA Encrypted Key Distribution
図1. RSA暗号化されたキーディストリビューション
Mutual authentication can be achieved by delegation of the MN/device authentication by the RADIUS AAA Server to the cdma2000(R) 1X Home Location Register (HLR) and its associated Authentication Center (AC) [7], while the MN utilizes RSA encryption to authenticate the RADIUS AAA Server.
相互認証は、RADIUS AAAサーバーによるCDMA2000（R）1Xホームロケーションレジスタ（HLR）およびその関連認証センター（AC）[7]に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ネットワークを使用して既存の認証キー（A-Key）および共有シークレットデータ（SSD）を持っているという仮定に基づいています。MSコールオリジネーションが発生すると、ACはMSを認証します。認証が成功した場合、BSはモバイルステーション識別子（MSID）（例えば、モバイル識別番号（MIN））をPDSNに渡します。「認証されたMSID」は、PDSNからRADIUS AAAサーバーに送信されたRADIUSアクセス要求（ARQ）メッセージ[4]に含まれます。RADIUS AAAサーバーはMNサブスクリプションに関連付けられたMSIDを保存するため、RADIUS AAAサーバーは、「認証されたMSID」がRADIUS AAA MSIDと一致する場合、MNアクセスを承認できます。（R）1x HLR/AC。
RADIUS AAA Server authentication (by the MN) is enabled by including a random number (AAA_Authenticator) in the encrypted payload sent from the MN to the RADIUS AAA Server. Only the possessor of the proper RSA Private key will have the ability to decrypt the payload and recover the unique AAA_Authenticator. If the MN receives the correct AAA_Authenticator (returned by the RADIUS AAA Server), the MN is assured that it is not interacting with a false Base Station (BS).
RADIUS AAAサーバー認証（MNによる）は、MNからRADIUS AAAサーバーに送信された暗号化されたペイロードに乱数（AAA_Authenticator）を含めることにより有効になります。適切なRSA秘密キーの所有者のみが、ペイロードを復号化し、一意のAAA_Authenticatorを回復する機能を備えています。MNが正しいAAA_AUTHENTICATOR（RADIUS AAAサーバーによって返される）を受信した場合、MNは偽の基地局（BS）と相互作用していないことを保証します。
MN BS/PDSN/FA HLR/AC AAA
-- ---------- ------ ---
------------------ | | -------------------
| RSA Public Key | | | | RSA Private Key |
| Pre-loaded by | | | | Pre-loaded by |
| Manufacturer | | | | Service Provider |
------------------ | | -------------------
| Global Challenge | |
|<-------------| | |
| | | |
| Auth_Response | |
|------------->| | |
| | Auth_Response | |
| |---------------->| |
| | ------------------ |
| | | IS-2000 | |
| | | Authentication | |
| | ------------------ |
| | Auth_Success | |
| |<----------------| |
| ------------------ | |
| | BS forwards | | |
| | Authenticated | | |
| | MSID to PDSN | | |
| ------------------ | |
| | | |
| Registration Request | |
| (MIP keys, AAA_Authenticator), |
| RSA Public Key | |
|------------->| | |
| | Access Request, MSID, |
| | (MIP keys, AAA_Authenticator),
| | RSA Public Key |
| |------------------------------->|
| | | -------------------
| | | | Check MSID, |
| | | | Decrypt AAA_- |
| | | | Authenticator |
| | | -------------------
| Access Reject, AAA_Authenticator |
| |<-------------------------------|
Registration Reply, AAA_Authenticator |
|<-------------| | |
------------------ | | |
| Check AAA_- | | | |
| Authenticator | | | |
------------------ | | |
Figure 2. Mutual Authentication
Because cdma2000(R) A-key/SSD authentication is not available in 1xEV-DO, or a particular cdma2000(R) 1X network may not support A-key authentication, the DMU procedure also includes a random number (MN_Authenticator) generated by the MN (and/or pre-loaded by the manufacturer), which enables the RADIUS AAA Server to optionally authenticate the MN (in 1XEV DO network only).
CDMA2000（R）A-Key/SSD認証は1XEV-DOまたは特定のCDMA2000（R）1XネットワークではA-Key認証をサポートしない可能性があるため、DMU手順にはランダム数（MN_Authenticator）も含まれます。MN（および/またはメーカーが事前ロード）。これにより、RADIUS AAAサーバーはオプションでMNを認証することができます（1XEV DOネットワークのみ）。
The MN_Authenticator is transmitted from the MN to the Home AAA Server within the RSA-encrypted MIP_Key_Data payload to prevent interception and possible re-use by an attacker. Ideally, the MN_Authenticator is utilized as a One-Time Password; however, RSA encryption allows the MN_Authenticator to possibly be re-used based on each service provider's key distribution policy.
MN_Authenticatorは、MNからRSA-Rypted MIP_KEY_DATAペイロード内のHome AAAサーバーに送信され、攻撃者による傍受と再利用の可能性を防ぎます。理想的には、MN_Authenticatorは1回限りのパスワードとして使用されます。ただし、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キーがHome Radius AAAサーバーで復号化されると、MN_Authenticatorも復号化され、Home Radius AAAサーバー内に保存されているMN_Authenticatorのコピーと比較されます。Home Radius AAAサーバーは、標準の範囲外で多数の可能な方法のいずれかを使用して、MN_Authenticatorの帯域外（CDMA2000（R）ネットワークを使用していない）のコピーを受け取ります。たとえば、MN_Authenticatorは次のとおりです。1）MNからのPOSのポイントプロビジャーで読み取り、サブスクライバープロファイルに入力し、ネットワークアクセス識別子（NAI）とともに配信されます。Home Radius AAAサーバー、2）インタラクティブな音声認識サーバーとのインターフェースによって、ユーザーが通話を介してカスタマーケア担当者に口頭で通信しました。帯域外の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手順の前に、不cru慎なプロビジョンまたは配布従業員がMN_Authenticatorを抽出することができます。ただし、このような開示に関連するリスクは最小限です。HRPD/1XEV-DO MNは初期登録プロセス中にデバイス識別子を送信しないため、攻撃者は、盗まれたMN_Authenticatorであっても、パスワードを特定のMNデバイスまたは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_Authenticatorは、MNユーザーによって明示的にリセットされない限り、変更してはなりません。したがって、MN_Authenticatorが更新されるまで、MNは同じ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では、IPレイヤーのMNとAAAサーバーの間でMIPキー分布が直接発生します。これにより、オーバーザエア機能（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でMIPキー分布をMNに促進します。OTASPは、MIPキーをMSにのみ配信します。たとえば、OTASPはMIPキーをMSモデムとインターフェースするラップトップMNに配信できません。
* Pre-encryption of MIP_Key_Data allows the DMU procedure to be an order of magnitude faster than Diffie-Hellman Key Exchange.
* MIP_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のペイロードを事前ロードできます。したがって、RSA暗号化を使用するために、処理能力が限られているMNは決して必要ありません。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がその近くのMNSのMIPキーを変更するサービス拒否（DOS）攻撃から保護されています。OTASP Diffie-Hellman Key Exchangeは、誤ったBS DOS攻撃に対して脆弱です。
* DMU utilizes mutual authentication. OTASP Diffie-Hellman Key Exchange does not utilize mutual authentication.
* DMUは相互認証を利用しています。OTASP Diffie-Hellman Key Exchangeは相互認証を利用していません。
The Verizon Wireless Dynamic Mobile IP Update procedure is a secure, yet extremely efficient mechanism for distributing essential MIP cryptographic keys (e.g., MN-AAAH key and MN-HA key) and the Simple IP CHAP key. The DMU protocol enables pre-computation of the encrypted key material payload, known as MIP_Key_Data. The DMU procedure purposely avoids the use of Public Key Infrastructure (PKI) Certificates, greatly enhancing the procedure's efficiency.
Verizon Wireless Dynamic Mobile IPアップデート手順は、必須のMIP暗号化キー（MN-AAAHキーやMN-HAキーなど）を分散するための安全でありながら非常に効率的なメカニズムとSimple 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をサポートする場合があります。小さいか、少数の非ゼロビット（65537など）を持つ公共のRSA指数を使用したRSA計算スピードアップは許容されます。
DMU does not preclude the use of other public key technologies. The protocol includes a Public Key Type field that defines the type of encryption used.
DMUは、他の公開キーテクノロジーの使用を排除しません。プロトコルには、使用される暗号化のタイプを定義する公開キータイプフィールドが含まれます。
DMU is designed to maximize the efficiency of Mobile IP (MIP) key distribution for cdma2000(R) MNs. The use of a public key Certificate would improve the flexibility of the MIP key update process by allowing a Certificate Authority (CA) to vouch for the RSA public key delivered to the MN. Unfortunately, the use of a public key certificate would significantly reduce the efficiency (speed and overhead) of the MIP key update process. For instance, each MN must be pre-loaded with the CA's public key. During the MIP key distribution process, the network must first deliver its RSA public key (in a certificate) to the MN. The MN must then use RSA to decrypt the Certificate's digital signature to verify that the presented RSA public key is legitimate. Such a process significantly increases the number of exchanges, increases air interface overhead, increases the amount of MN computation, and slows the MIP key update process.
DMUは、CDMA2000（R）MNSのモバイルIP（MIP）キー分布の効率を最大化するように設計されています。公開キーの証明書を使用すると、MNに配信されたRSA公開キーを保証できるようにすることにより、MIPキーアップデートプロセスの柔軟性が向上します。残念ながら、公開キー証明書を使用すると、MIPキーアップデートプロセスの効率（速度とオーバーヘッド）が大幅に低下します。たとえば、各MNはCAの公開キーで事前にロードする必要があります。MIPキーディストリビューションプロセス中、ネットワークは最初にRSAの公開キー（証明書で）をMNに配信する必要があります。次に、MNはRSAを使用して証明書のデジタル署名を復号化して、提示されたRSA公開キーが合法であることを確認する必要があります。このようなプロセスは、交換の数を大幅に増加させ、エアインターフェイスのオーバーヘッドを増加させ、MN計算の量を増やし、MIPキーアップデートプロセスを遅くします。
Aside from the operational efficiency issues, there are numerous policy and procedural issues that have previously hampered the deployment of PKI in commercial networks.
運用効率の問題は別として、商業ネットワークでのPKIの展開を以前に妨げていた多くの政策と手続き上の問題があります。
On a more theoretical basis, PKI is likely unnecessary for this key distribution model. PKI is ideal for a Many-to-Many communications model, such as within the Internet, where many different users interface with many different Websites. However, in the cellular/PCS Packet Data environment, a Many-to-One (or few) distribution model exists, in which many users interface with one wireless Carrier to establish their Mobile IP security associations (i.e., cryptographic keys).
より理論的には、PKIはこの重要な分布モデルでは不要です。PKIは、多くの異なるユーザーが多くの異なるWebサイトとインターフェースをかけるインターネット内など、多くの多くのコミュニケーションモデルに最適です。ただし、セルラー/PCSパケットデータ環境では、多くのユーザーが1つのワイヤレスキャリアとインターフェイスしてモバイルIPセキュリティアソシエーション（つまり、暗号化キー）を確立するために、多くのユーザー（または少数の）分布モデルが存在します。
The DMU procedure relies on each MN to randomly/pseudo-randomly generate the MN_AAAH key, MN_HA key, and Simple IP CHAP key. Each MN MUST have the capability to generate random/pseudo-random numbers in accordance with the guidelines specified in RFC 4086 "Randomness Requirements for Security".
DMU手順は、各MNに依存して、ランダム/擬似ランダムリーにMN_AAAHキー、MN_HAキー、および単純なIP CHAPキーを生成します。各MNには、RFC 4086「セキュリティのランダム性要件」で指定されたガイドラインに従って、ランダム/擬似ランダム数を生成する機能が必要です。
Although it may be more secure for the network to generate cryptographic keys at the RADIUS AAA server, client cryptographic key generation is acceptable due to the significant efficiency improvement in the update process via pre-generation and pre-encryption of the MIP keys.
ネットワークがRADIUS AAAサーバーで暗号化キーを生成する方が安全であるかもしれませんが、MIPキーの事前生成と前暗号化を介して更新プロセスの効率が大幅に向上するため、クライアントの暗号化キー生成は許容されます。
MIP cryptographic keys (MN_AAAH key and MN_HA key) and the Simple IP CHAP key are encapsulated and encrypted into a MIP_Key_Data Payload (along with the AAA_Authenticator and MN_Authenticator). The MIP_Key_Data Payload is appended to the MN's MIP Registration Request (RRQ) as a MIP Vendor/Organization-Specific Extension (VSE) (see RFC 3115 [10] Mobile IP Vendor/Organization-Specific Extensions). When the PDSN converts the MIP RRQ to a RADIUS Access Request (ARQ) message, the MIP_Key_Data Payload is converted from a MIP Vendor/Organization-Specific Extension to a Vendor Specific RADIUS Attribute (VSA).
MIP暗号化キー（MN_AAAHキーおよびMN_HAキー）とシンプルなIP Chapキーがカプセル化され、MIP_KEY_DATAペイロードに暗号化されます（AAA_AuthenticatorおよびMN_Authenticator）。MIP_KEY_DATAペイロードは、MIPベンダー/組織固有の拡張機能（VSE）としてMNのMIP登録要求（RRQ）に追加されます（RFC 3115 [10]モバイルIPベンダー/組織固有のエクステンションを参照）。PDSNがMIP RRQをRADIUSアクセス要求（ARQ）メッセージに変換すると、MIP_KEY_DATAペイロードはMIPベンダー/組織固有の拡張機能からベンダー固有のRADIUS属性（VSA）に変換されます。
Upon receipt of the RADIUS Access Request, the RADIUS AAA Server decrypts the MIP_Key_Data payload using the RSA private (decryption) key associated with the RSA public (encryption) used to encrypt the MIP_Key_Data payload. The MIP_Key_Data is defined as follows:
RADIUSアクセス要求を受信すると、RADIUS AAAサーバーは、MIP_KEY_DATAペイロードを暗号化するために使用されるRSAパブリック（暗号化）に関連付けられているRSAプライベートキー（復号化）キーを使用して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 key、mn_ha key、chap_key、mn_authenticator、aaa_authenticator]、public_key_id、dmuv
Where:
ただし：
MN_AAAH key = 128-bit random MN / RADIUS AAA Server key (encrypted)
MN_AAAHキー= 128ビットランダムMN / RADIUS AAAサーバーキー（暗号化）
MN_HA key = 128-bit random MN / Home Agent (HA) key (encrypted)
MN_HAキー= 128ビットランダムMN /ホームエージェント（HA）キー（暗号化）
CHAP_key = 128-bit random Simple IP authentication key (encrypted) Note: the Simple IP CHAP key is not the same as the AT-CHAP key used for A12 Interface authentication [11].
chap_key = 128ビットランダムシンプルIP認証キー（暗号化）注：単純なIP Chapキーは、A12インターフェイス認証に使用されるATチャップキーと同じではありません[11]。
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)
AAA_Authenticator = MNがRADIUS AAAサーバーを認証するために使用する64ビット乱数。（暗号化）
DMU Version (DMUV) = 4-bit identifier of DMU version.
DMUバージョン（DMUV）= DMUバージョンの4ビット識別子。
Public Key Identifier (Public_Key_ID) = PKOID, PKOI, PK_Expansion, ATV
公開キー識別子（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手順をサポートするためにRSAプライベートキー（RADIUS AAAサーバー）とパブリックキー（MNメーカーに）を生成、管理、保護、および配布するために、サービスプロバイダーによって指定されなければなりません。
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の公開キーは数百万のMNSに配布できるため、電子メール、フロッピーディスク、またはウェブサイトを介してRSAの公開キー（および公開キー識別子）をMNメーカーに配布することは許容されます。好ましい方法は、各MNメーカー/OEMに送信されたDMU要件ドキュメントにRSA公開キーと関連する公開識別子を単純に公開することです。
When public keys are distributed, the public keys MUST be protected against alteration. If an invalid public key is programmed into a terminal, the terminal may be denied service because DMU cannot be performed successfully.
パブリックキーが配布される場合、パブリックキーは変更から保護する必要があります。無効な公開キーが端末にプログラムされている場合、DMUを正常に実行できないため、ターミナルがサービスを拒否される場合があります。
RSA Private keys MAY be loaded into the RADIUS AAA server manually. Access to the RADIUS AAA Server RSA Private keys MUST be restricted to authorized personnel only.
RSAプライベートキーは、RADIUS AAAサーバーに手動でロードされる場合があります。RADIUS AAAサーバー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.
ワイヤレスサービスプロバイダーは、MNSをメーカーで生成したRSAパブリックキーでプリロードしたMNメーカーのRSA秘密キー（および公開キー識別子）を受け入れることができます。
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メーカーからAAAサーバーにRSA秘密キーを配信することは、このドキュメントの範囲外です。ただし、暗号化された電子メールまたは物理（メール）配信を介したRSA秘密キーの配信は許容される可能性があります。
Access to the RADIUS AAA Server MUST be limited to authorized personnel only.
RADIUS AAAサーバーへのアクセスは、認定担当者のみに制限する必要があります。
The RADIUS AAA Server MUST support 1024-bit RSA decryption.
RADIUS AAAサーバーは、1024ビットRSA復号化をサポートする必要があります。
The RADIUS AAA Server MUST maintain a database of RSA public/private key pair indexed by the Public Key Identifier.
RADIUS AAAサーバーは、公開キー識別子によってインデックス付けされたRSAパブリック/秘密キーペアのデータベースを維持する必要があります。
The RADIUS AAA Server MUST support the RADIUS attributes specified in Section 8.
RADIUS AAAサーバーは、セクション8で指定されたRADIUS属性をサポートする必要があります。
The RADIUS AAA Server MUST support a subscriber-specific MIP Update State Field. When the MIP Update State Field is set to UPDATE KEYS (1), the RADIUS AAA Server MUST initiate the DMU procedure by including the MIP_Key_Request attribute in an Access Reject message sent to the PDSN. The MIP Update State Field MAY be set to UPDATE 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).
RADIUS AAAサーバーは、サブスクライバー固有のMIP更新状態フィールドをサポートする必要があります。MIP更新状態フィールドがキー（1）を更新するように設定されている場合、RADIUS AAAサーバーは、PDSNに送信されたアクセス拒否メッセージにmip_key_request属性を含めることにより、DMU手順を開始する必要があります。MIP更新状態フィールドは、ITポリシーに基づいて、サービスプロバイダーの請求/プロビジョニングシステムによってキー（1）を更新するように設定できます。復号化されたMN_AAAキーを使用してMN-AAA認証拡張機能を検証すると、RADIUS AAAサーバーはMIP更新状態フィールドをキーの更新（2）に設定する必要があります。後続のRRQ/ARQでのMn-Authentication拡張が検証されると、RADIUS AAAサーバーはMIP更新状態フィールドを有効（0）にキーに設定する必要があります。
Note that the inclusion of a vendor-specific attribute in the Access Reject message is not consistent with Section 5.44 of [4]. A RADIUS AAA server that supports DMU SHOULD NOT include a vendor-specific attribute if the corresponding Access Request message was not received from a DMU-compliant PDSN. This use of Access Reject is strongly discouraged for any future work based on this document. Future work should consider the use of Access-Challenge to carry this vendor-specific attribute.
アクセス拒否メッセージにベンダー固有の属性を含めることは、[4]のセクション5.44と一致していないことに注意してください。DMUをサポートするRADIUS AAAサーバーには、DMUに準拠したPDSNから対応するアクセス要求メッセージが受信されなかった場合、ベンダー固有の属性を含めるべきではありません。このアクセス拒否の使用は、このドキュメントに基づいた将来の作業に対して強く落胆しています。将来の作業では、このベンダー固有の属性を運ぶためのアクセスチャレンジの使用を考慮する必要があります。
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サーバーは、3つの状態のいずれかで、サブスクリプションごとにMIP更新状態フィールドを維持する必要があります（0 =キー有効、1 =キー、2 =キーが更新されます）。
The RADIUS AAA Server MUST decrypt the encrypted portion of the MIP_Key_Data payload using the appropriate RSA Private (decryption) key.
RADIUS AAAサーバーは、適切なRSAプライベート（復号化）キーを使用して、mip_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サーバーは、復号化されたMN_AAAキーを使用して、DMU RRQのMN_AAA認証拡張機能を確認する必要があります。
The RADIUS AAA Server MUST include the AAA_Authenticator in the Access Accept as a Vendor-Specific RADIUS Attribute.
RADIUS AAAサーバーには、アクセスにAAA_AUTHENTICATORをベンダー固有のRADIUS属性として含める必要があります。
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サーバーは、サブスクリプションごとにAAA GUIを介して、MN_AAAキー、MN_HAキー、および単純なIP Chapキーの手動で16進入力する必要があります。
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 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.
RADIUS AAAサーバーは、MIN/International Mobile Subscriber ID（IMSI）を検証するメカニズムを提供する必要があります。MIN/IMSI検証がオンの場合、RADIUS AAAサーバーは、PDSNから送信されたMIN/IMSIをAAAサブスクリプションレコード/プロファイルのMIN/IMSIと比較する必要があります。minsまたはIMSIが一致しない場合、RADIUS AAAサーバーはPDSN/FAへのアクセス拒否を送信する必要があります。アクセス拒否には、「MN_Authenticator」ビットが設定されていない場合、MIPキーデータリクエストを含めてはなりません。RADIUSAAAサーバーは、MN_AuthenticAtormn = MN_Authenticatoraaaaかどうかを確認する必要があります。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サーバーには、MIP_KEY_REQUEST RADIUS属性にPKOID（または別の指定されたPKOID）を含める必要があります。
The RADIUS AAA Server MUST compare the PKOID sent in the MIP_Key_Data RADIUS Attribute with a list of valid PKOIDs in the RADIUS AAA Server. If the PKOID is not valid, the RADIUS AAA Server MUST send an Access Reject to the PDSN with the "Invalid Public Key" Verizon Wireless RADIUS Vendor Specific Attribute (VSA). Note: the same RADIUS attribute may be assigned a different Vendor identifier.
RADIUS AAAサーバーは、MIP_KEY_DATA RADIUS属性で送信されたPKOIDを、RADIUS AAAサーバーの有効なPKOIDのリストと比較する必要があります。PKOIDが有効でない場合、RADIUS AAAサーバーは、「無効な公開キー」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.
アクセス拒否メッセージにベンダー固有の属性を含めることは、[4]のセクション5.44と一致していないことに注意してください。DMUをサポートするRADIUS AAAサーバーには、DMUに準拠したPDSNから対応するアクセス要求メッセージが受信されなかった場合、ベンダー固有の属性を含めるべきではありません。このアクセス拒否の使用は、このドキュメントに基づいた将来の作業に対して強く落胆しています。将来の作業では、このベンダー固有の属性を運ぶためのアクセスチャレンジの使用を考慮する必要があります。
The RADIUS AAA Server MUST support delivery of the MN-HA key using 3GPP2 RADIUS VSAs as specified in 3GPP2 X.S0011-005-C. The 3GPP2 VSAs used are the MN-HA Shared Key (Vendor-Type = 58) and MN-HA Security Parameter Index (SPI) (Vendor-Type = 57).
RADIUS AAAサーバーは、3GPP2 X.S0011-005-Cで指定されている3GPP2 RADIUS VSAを使用してMN-HAキーの配信をサポートする必要があります。使用される3GPP2 VSAは、MN-HA共有キー（ベンダータイプ= 58）およびMN-HAセキュリティパラメーターインデックス（SPI）（ベンダータイプ= 57）です。
The RADIUS AAA Server SHOULD always accept an Access Request from a cdma2000(R) Access Node (AN) for a particular subscriber when the UPDATE KEYS (1) and KEYS UPDATED (2) states are set. In the KEYS VALID (0) state, the RADIUS AAA Server MUST check the Access Request normally.
RADIUS AAAサーバーは、アップデートキー（1）と更新された（2）状態が設定されている場合、特定のサブスクライバーのCDMA2000（R）アクセスノード（AN）からのアクセス要求を常に受け入れる必要があります。有効なキー（0）状態では、RADIUS AAAサーバーはアクセス要求を正常に確認する必要があります。
The RADIUS AAA Server MUST reject an Access Request with the MIP_Key_Data RADIUS Attribute while the RADIUS AAA Server is in the KEYS VALID state, i.e., the AAA MUST NOT allow an unsolicited key update to occur.
RADIUS AAAサーバーは、MIP_KEY_DATA RADIUS属性を使用してアクセス要求を拒否する必要がありますが、RADIUS AAAサーバーはキー有効状態にあります。つまり、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は、MN_AAA、MN_HA、およびCHAPランダム/擬似ランダムキー生成をサポートする必要があります（RFC 4086に従って）。
The MN MUST support random/pseudo-random AAA_Authenticator and MN_Authenticator generation (in accordance with RFC 4086).
MNは、ランダム/擬似ランダムAAA_AuthenticatorおよびMN_Authenticatorの生成をサポートする必要があります（RFC 4086に従って）。
Upon power-up of an MN handset or launch of the MN client, the MN MUST check whether a MIP_Key_Data payload has been computed. If no MIP_Key_Data payload exists, the MN MUST generate and store a MIP_Key_Data payload. The MN MUST maintain at least one pre-generated MIP_Key_Data payload.
MNハンドセットのパワーアップまたはMNクライアントの発売時に、MNはMIP_KEY_DATAペイロードが計算されているかどうかを確認する必要があります。MIP_KEY_DATAペイロードが存在しない場合、MNはMIP_KEY_DATAペイロードを生成して保存する必要があります。MNは、少なくとも1つの事前に生成された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 Verizonワイヤレスベンダー/組織固有の拡張機能（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は、モバイルホーム認証拡張後、MN-AAA認証拡張の前に、Verizon Wireless MIP_KEY_DATA VSE（または別の組織固有のMIP_KEY_DATA VSE）を挿入する必要があります。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拡張機能を処理する必要はありません。他の互換性の問題は、さまざまな場所に拡張機能を置くさまざまなベンダーのFASとのテスト中にも特定されています。拡張機能の明示的な配置により、これらの問題が排除されます。
Upon initiation of the DMU Procedure, the MN MUST compute the MIP authentication extensions using the newly-generated temporary MN_AAA and MN_HA keys. Upon receipt of the AAA_Authenticator MIP Extension, 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_AuthenticAtormn（暗号化されたMIP_KEY_DATAペイロードで送信された）とAAA_AuthenticatorAaaA（RADIUS AAAサーバーによって返される）を比較する必要があります。両方の値が同じ場合、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.
MNは、セクション6.2で指定されているように、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ユーザーがMN_Authenticatorを表示できるようにする必要があります。MN_Authenticator（24ビットの乱数）は、セクション6.2で指定されているように、8桁の数字番号として表示する必要があります。
The MN manufacturer MUST pre-load each MN with a unique random 24-bit MN_Authenticator.
MNメーカーは、各MNを一意のランダム24ビットMN_Authenticatorで事前にロードする必要があります。
Upon reset of the MN_Authenticator, the MN MUST delete all MIP_Key_Data payloads based on the old MN_Authenticator and generate all subsequent MIP_Key_Data payloads using the new MN_Authenticator (until the MN_Authenticator is explicitly re-set again by the MN user).
MN_Authenticatorをリセットすると、MNは古いMN_Authenticatorに基づいてすべてのMIP_KEY_DATAペイロードを削除し、新しいMN_Authenticatorを使用してその後のすべてのMIP_KEY_DATAペイロードを生成する必要があります（MN_Authenticatorが再びMNユーザーによって明らかに再検索されるまで）。
The MN MUST support manual entry of all cryptographic keys such as the MN_AAA, MN_HA, and Simple IP CHAP key. MN MUST support hexadecimal digit entry of a 128-bit key. (Note: certain Simple IP devices only enable ASCII entry of a password as the CHAP key. It is acceptable for future devices to provide both capabilities, i.e., ASCII for a password or hexadecimal for a key. The authors recommend the use of strong cryptographic keys.)
MNは、MN_AAA、MN_HA、Simple IP Chapキーなどのすべての暗号化キーの手動入力をサポートする必要があります。MNは、128ビットキーの16進数桁エントリをサポートする必要があります。（注：特定の単純なIPデバイスは、パスワードのASCIIエントリのみをChapキーとしてのみ有効にします。将来のデバイスが両方の機能、つまりパスワードのASCIIまたはキーの16進数を提供することは許容されます。著者は強力な暗号化の使用を推奨します。キー。）
The MN MUST support the Verizon Wireless MIP Vendor/Organization-Specific Extensions specified in Section 9.
MNは、セクション9で指定されているVerizonワイヤレスMIPベンダー/組織固有の拡張機能をサポートする必要があります。
The MN MUST update the RRQ Identification field when re-transmitting the same MIP_Key_Data in a new RRQ.
MNは、新しいRRQで同じMIP_KEY_DATAを再送信するときにRRQ識別フィールドを更新する必要があります。
The MN MUST comply with the DMU Procedure failure operation specified in Section 5.
MNは、セクション5で指定されたDMU手順障害操作に準拠する必要があります。
The RSA public key MAY be stored in the MN flash memory as a constant while being updatable via software patch.
RSAの公開キーは、ソフトウェアパッチを介して更新可能である間、MNフラッシュメモリに定数として保存できます。
The PDSN MUST support the Verizon Wireless RADIUS Vendor-Specific Attributes (VSA) specified in Section 8 and the Verizon Wireless MIP Vendor/Organization-Specific Extensions (VSEs) specified in Section 9.
PDSNは、セクション8で指定されているVerizonワイヤレスRADIUSベンダー固有の属性（VSA）と、セクション9で指定されたVerizonワイヤレスMIPベンダー/組織固有の拡張機能（VSE）をサポートする必要があります。
The PDSN MAY support the RADIUS VSAs specified in Section 8 and the MIP VSEs specified in Section 9 using another Organization identifier.
PDSNは、セクション8で指定された半径VSAと、別の組織識別子を使用してセクション9で指定されたMIP VSEをサポートできます。
Upon receipt of an Access Reject containing the MIP_Key_Update_Request VSA, PDSN MUST send an RRP to the MN with the MIP_Key_Request VSE. The PDSN MUST use the RRP error code = 89 (Vendor Specific) and MUST not tear down the PPP session after transmission.
MIP_KEY_UPDATE_REQUEST VSAを含むアクセス拒否を受信すると、PDSNはMIP_KEY_REQUEST VSEを使用してMNにRRPを送信する必要があります。PDSNは、RRPエラーコード= 89（ベンダー固有）を使用する必要があり、送信後にPPPセッションを取り壊さないでください。
Upon receipt of an Access Reject containing the AAA_Authenticator VSA, the PDSN MUST send an RRP with the AAA_Authenticator MIP VSE. The PDSN MUST use the RRP error code = 89 (Vendor Specific) and MUST NOT tear down the PPP session after transmission.
AAA_Authenticator VSAを含むアクセス拒否を受信すると、PDSNはAAA_Authenticator MIP VSEでRRPを送信する必要があります。PDSNは、RRPエラーコード= 89（ベンダー固有）を使用する必要があり、送信後にPPPセッションを取り壊さないでください。
Upon receipt of an Access Reject containing the Public Key Invalid VSA, the PDSN MUST send an RRP with the Public Key Invalid MIP VSE. The PDSN MUST use the RRP error code = 89 (Vendor Specific) and MUST NOT tear down the PPP session after transmission.
公開キーの無効なVSAを含むアクセス拒否を受信すると、PDSNは公開キーの無効なMIP VSEを使用してRRPを送信する必要があります。PDSNは、RRPエラーコード= 89（ベンダー固有）を使用する必要があり、送信後にPPPセッションを取り壊さないでください。
Note that the inclusion of a vendor-specific attribute in the Access Reject message is not consistent with section 5.44 of [4]. A PDSN that supports DMU MUST accept an Access Reject message containing a vendor-specific attribute. This use of Access Reject is strongly discouraged for any future work based on this document. Future work should consider the use of Access-Challenge to carry this vendor-specific attribute.
アクセス拒否メッセージにベンダー固有の属性を含めることは、[4]のセクション5.44と一致していないことに注意してください。DMUをサポートするPDSNは、ベンダー固有の属性を含むアクセス拒否メッセージを受け入れる必要があります。このアクセス拒否の使用は、このドキュメントに基づいた将来の作業に対して強く落胆しています。将来の作業では、このベンダー固有の属性を運ぶためのアクセスチャレンジの使用を考慮する必要があります。
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を使用してRRQをARQに変換する必要があります。PDSNは、ARQをRADIUS AAAサーバーに送信する必要があります。
The PDSN/FA MUST comply with the DMU Procedure failure operation specified in Section 5.
PDSN/FAは、セクション5で指定されたDMU手順障害操作に準拠する必要があります。
The PDSN/FA MUST include the PKOID from the Access Reject MIP_Key_Update_Request VSA in the MIP_Key_Request MIP VSE sent to the MN.
PDSN/FAには、MIP_KEY_REQUEST MIP VSEにMIP_KEY_UPDATE_REQUEST VSAにアクセスからPKOIDを含める必要があります。
The HA MUST support the Verizon Wireless MIP Vendor/Organization-Specific Extensions (VSEs) specified in Section 9. (Note: the HA may not encounter a DMU MIP extension if the FA strips away all extensions after the Mobile-Home authentication extension.)
HAは、セクション9で指定されたVerizonワイヤレスMIPベンダー/組織固有の拡張機能（VSE）をサポートする必要があります。
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対をサポートする場合があります。（注：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.
サービスプロバイダーがパブリック/プライベートキーペアを生成せず、MNでの事前インストールのためにRSAの公開キーをMNメーカーに配信しない場合、MNメーカーはRSAパブリック/プライベートキーペアを生成する必要があります（1024ビットモジュラスを使用して）そして、すべてのMNSをRSAパブリック（暗号化）キーで事前ロードします。MNメーカーは、RSAプライベート（復号化）キーを安全な方法で適切なサービスプロバイダーに配布する必要があります。
2. Assuming that the cdma2000(R) 1X MN has been provisioned with an A-key and SSD, the cdma2000(R) 1X MS initiates a call origination and authenticates itself to the IS-2000 network. Upon IS-2000 authentication success, the BS sends the "authenticated" MSID (e.g., MIN) to the PDSN.
2. CDMA2000（R）1x MNにAキーとSSDがプロビジョニングされていると仮定すると、CDMA2000（R）1X MSは呼び出しのオリジネーションを開始し、IS-2000ネットワークに認証します。IS-2000認証の成功により、BSは「認証された」MSID（たとえば、最小）をPDSNに送信します。
3. The MN and PDSN establish a PPP session.
3. MNとPDSNはPPPセッションを確立します。
4. The MN sends a MIP Registration Request (RRQ) to the PDSN.
4. MNは、MIP登録要求（RRQ）をPDSNに送信します。
5. The PDSN converts the MIP RRQ into a RADIUS Access Request (ARQ) message, includes the MSID in the ARQ, and forwards the ARQ to the Home RADIUS AAA server.
5. PDSNは、MIP RRQをRADIUSアクセス要求（ARQ）メッセージに変換し、ARQのMSIDを含み、ARQをHome Radius AAAサーバーに転送します。
6. The RADIUS AAA Server compares the authenticated MSID (sent from the PDSN) with the MSID in its subscriber database (associated with the NAI). If the AAA MIP Update State Field is set to UPDATE KEYS (1), the RADIUS AAA Server rejects Packet Data access and orders a MIP key update.
6. RADIUS AAAサーバーは、認証されたMSID（PDSNから送信）とサブスクライバーデータベース（NAIに関連付けられている）のMSIDを比較します。AAA MIP更新状態フィールドがキー（1）を更新するように設定されている場合、RADIUS AAAサーバーはパケットデータアクセスを拒否し、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にアクセス拒否（code = 3）メッセージを送信します。
8. The PDSN converts the Access Reject to a MIP Registration Reply (RRP) with a MIP_Key_Request MIP VSE and sends the RRP to the MN. RRP Code = 89 (Vendor Specific).
8. PDSNは、アクセス拒否をMIP_KEY_REQUEST MIP VSEでMIP登録回答（RRP）に変換し、RRPをMNに送信します。RRPコード= 89（ベンダー固有）。
9. The MN sets the MN MIP Update State = UPDATE KEYS. If the MN has no pre-generated and pre-encrypted MIP_Key_Data payload, the MN MUST generate the MN_AAA key, MN_HA key, Chap key, MN_Authenticator, and AAA_Authenticator in accordance with RFC 4086. Except for the Public Key Identifier, all generated values MUST be encrypted using the pre-loaded RSA public (encryption) key. The newly generated MN_AAATEMP Key and MN_HATEMP MUST be used to calculate the MN-AAA and Mobile-Home Authentication Extensions for the current RRQ. Note: the MN MAY pre-compute the MIP_Key_Data payload by checking whether a payload exists during each MN power-up or application initiation.
9. MNは、MN MIP更新状態=更新キーを設定します。MNが事前に生成および事前に暗号化されたMIP_KEY_DATAペイロードがない場合、MNはMN_AAAキー、MN_HAキー、Chap Key、MN_Authenticator、およびAAA_AuthenticatorをRFC 4086に従って生成する必要があります。プリロードされたRSAパブリック（暗号化）キーを使用して暗号化されます。新しく生成されたMN_AAATEMPキーとMN_HATEMPを使用して、現在のRRQのMN-AAAおよびモバイルホーム認証拡張機能を計算する必要があります。注：MNは、各MNパワーアップまたはアプリケーションの開始中にペイロードが存在するかどうかを確認することにより、MIP_KEY_DATAペイロードを事前計算できます。
10. The MN sends the RRQ with MIP_Key_Data MIP VSE to the PDSN.
10. MNは、MIP_KEY_DATA MIP VSEを使用してRRQをPDSNに送信します。
11. The PDSN converts the RRQ to a RADIUS ARQ with MIP_Key_Data RADIUS VSA and forwards the ARQ to the home RADIUS AAA Server. The MSID is included in the ARQ.
11. PDSNは、MIP_KEY_DATA RADIUS VSAを使用してRRQを半径ARQに変換し、ARQをHome Radius AAAサーバーに転送します。MSIDはARQに含まれています。
12. The RADIUS AAA Server compares the authenticated MSID (sent from the PDSN) with the MSID in its subscriber database (associated with the NAI). If MSIDPDSN = MSIDAAA, the RADIUS AAA server, using the Public Key Identifier, determines the appropriate RSA Private key and decrypts the encrypted portion of the MIP_Key_Data payload. The RADIUS AAA Server verifies the MN-AAA Authentication Extension Authenticator using the decrypted MN_AAA key. If successful, the RADIUS AAA Server updates the subscriber profile with the decrypted MN_AAA key, MN_HA key, and CHAP key. The RADIUS AAA Server sets the AAA MIP Update State Field to KEYS UPDATED (2).
12. RADIUS AAAサーバーは、認証されたMSID（PDSNから送信）とサブスクライバーデータベース（NAIに関連付けられている）のMSIDを比較します。msidpdsn = msidaaaaの場合、publicキー識別子を使用してRADIUS AAAサーバーが適切なRSA秘密キーを決定し、mip_key_dataペイロードの暗号化された部分を復号化します。RADIUS AAAサーバーは、復号化されたMN_AAAキーを使用してMN-AAA認証拡張拡張機能を検証します。成功した場合、RADIUS AAAサーバーは、復号化されたMN_AAAキー、MN_HAキー、およびCHAPキーでサブスクライバープロファイルを更新します。RADIUS AAAサーバーは、AAA MIP更新状態フィールドを更新されたキーに設定します（2）。
13. The RADIUS AAA Server sends an Access Reject with AAA_Authenticator RADIUS VSA to the PDSN.
13. RADIUS AAAサーバーは、AAA_AUTHENTICATOR RADIUS VSAを使用してアクセス拒否をPDSNに送信します。
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_authenticatoraaaaの場合、MnはMN_AAATEMPをMN_AAAキーに、MN_HATEMPをMN_HAキーに割り当てます（MN MIP更新状態=キー有効）。それ以外の場合、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サーバーに転送される新しい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にアクセスを受け入れます。
18. The PDSN/FA sends the RRQ to the Home Agent (HA).
18. PDSN/FAは、RRQをホームエージェント（HA）に送信します。
19. The HA sends an Access Request to the RADIUS AAA Server. The RADIUS AAA Server sends an Access Accept to the HA with the MN_HA key. The HA verifies the Mobile-Home Authentication Extension using the MN_HA key.
19. HAは、RADIUS AAAサーバーにアクセス要求を送信します。RADIUS AAAサーバーは、MN_HAキーを使用してHAにアクセスを送信します。HAは、MN_HAキーを使用してモバイルホーム認証拡張機能を検証します。
20. The HA sends an RRP to the PDSN/FA, which forwards the RRP to the MN. RRP Code = 0 (Success).
20. HAはRRPをPDSN/FAに送信し、RRPをMNに転送します。RRPコード= 0（成功）。
To improve the robustness of the DMU Procedure to account for interruptions due to UDP message loss, RRQ retransmission, or MN failure, the RADIUS AAA Server MUST maintain a MIP Update State Field, for each subscription, in one of three states (0 = KEYS VALID, 1 = UPDATE KEYS, 2 = KEYS UPDATED).
UDPメッセージの損失、RRQ再送信、またはMN障害による中断を考慮してDMU手順の堅牢性を向上させるには、半径AAAサーバーは、3つの状態のいずれかで、各サブスクリプションに対してMIP更新状態フィールドを維持する必要があります（0 =キー有効、1 =キーを更新、2 =キー更新）。
MN PDSN/FA AAAH HA
-- ------- ---- --
---------------- | ---------------- |
| MN state = | | | AAAH state = | |
| KEYS VALID | | | UPDATE KEYS | |
---------------- | ---------------- |
| (A) RRQ | | |
|-------------->| ARQ | |
| |------------->| |
| AR(Key_Update) | |
(B) RRP (Key_Update) |<-------------| |
|<--------------| | |
---------------- | | |
| MN state = | | | |
| UPDATE KEYS | | | |
---------------- | | |
| (C) RRQ (MIP_Key_Data) | |
|-------------->| ARQ (MIP_Key_Data) |
| |------------->| |
| | ---------------- |
| | | AAAH state = | |
| | | KEYS UPDATED | |
| | ---------------- |
| AR (AAA_Auth) | |
(D) RRP (AAA_Auth) |<-------------| |
|<--------------| | |
---------------- | | |
| MN state = | | | |
| KEYS VALID | | | |
---------------- | | |
| RRQ | | |
|-------------->| ARQ | |
| |------------->| |
| | ---------------- |
| | | AAAH state = | |
| | | KEYS VALID | |
| | ---------------- |
| | AA | |
| |<-------------| RRQ |
| |------------------------------->|
| | | ARQ |
| | |<----------------|
| | | AA |
| | |---------------->|
| | | RRP |
| | RRP |<----------------|
|<-----------------------------| |
Figure 5. DMU Failure Call Flow with MN and AAA States
Each step in Figure 5 is described as follows:
図5の各ステップは次のように説明されています。
1. If (A) is lost, the MN retransmits (A). The RADIUS AAA server expects (A). If the AAA server is in the UPDATE KEYS state, the RADIUS AAA Server sends AR with MIP_Key_Update_Request VSA, and the PDSN/FA sends (B).
1. （a）が失われた場合、MNは再送信（a）。RADIUS AAAサーバーは（a）を期待しています。AAAサーバーが更新キー状態にある場合、RADIUS AAAサーバーはMIP_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サーバーはMIP_KEY_UPDATE_REQUEST VSAとPDSN/FA RETRANSMITS（B）でARを送信します。
3. If (C) is lost, the mobile retransmits (C). The RADIUS AAA server expects (C) and updates the MIP keys appropriately. The RADIUS AAA server transitions to KEYS UPDATED and commits the MIP_Key_Data. The RADIUS AAA Server sends the AR with AAA_Authenticator VSA, and the PDSN/FA replies to the MN with (D).
3. （c）が失われた場合、モバイル再送信（c）。RADIUS AAAサーバーは（C）を期待し、MIPキーを適切に更新します。RADIUS AAAサーバーは、MIP_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.
4. （d）が失われた場合、モバイル再送信（c）は、以前に送信された同じキーデータを使用しています。RADIUS AAAサーバーは、（a）同じキーを使用することを期待しています。
a. If the RADIUS AAA server receives (C) with the same keys it received previously, it retransmits the AR with AAA_Authenticator VSA and the PDSN replies with (D), containing the AAA_Authenticator.
a. RADIUS AAAサーバーが（c）以前に受け取った同じキーで（c）を受信した場合、AAA_Authenticator VSAでARを再送信し、PDSNは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サーバーはMIP_KEY_UPDATE_REQUEST VSA、PDSN/FA RETRANSMITS（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. （c）で送信されたキーを使用して認証に失敗したRADIUS AAAサーバーが（a）を受信した場合、RADIUS AAAサーバーはMIP_KEY_UPDATE_REQUEST、PDSN/FA Recransmits（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.
5. PDSN/FAが（a）を受信すると、ARQをRADIUS AAAサーバーに転送し、MN-AAA認証器をMN_AAAキーを使用して検証し、RADIUS AAAサーバーは有効な状態に遷移し、DMUプロセスが完了します。
The AAA DMU state machine is described in Figure 6.
AAA DMUステートマシンについては、図6に説明します。
--------------
--------------------->| KEYS VALID |---------------
| Auth success using -------------- Need Key |
| MIP_Key_Data Update |
| |
| Auth failed (invalid keys) |
| or RRQ with different MIP_Key_Data |
| --------------------------------- |
| | | |
| | v v
---------------- ---------------
| KEYS UPDATED | | UPDATE KEYS |
---------------- ---------------
| ^ ^ |
| | | |
------- ---------------------------------
RRQ with same Got MIP_Key_Data
MIP_Key_Data
Figure 6. RADIUS AAA Server DMU State Machine
図6. RADIUS AAAサーバーDMUステートマシン
Because the DMU Procedure occurs at the IP Layer, the DMU Procedure supports MIP key distribution in either the cdma2000(R) 1X or HRPD/1xEV-DO network. Because the cdma2000(R) HRPD/1xEV-DO network does not provide Radio Access Network (RAN) authentication, the DMU Procedure is more susceptible to a false MN attack (than in an cdma2000(R) 1X network with Cellular Authentication and Voice Encryption (CAVE) RAN authentication). For this reason, the DMU Procedure has the capability to optionally support device-to-network authentication using the MN_Authenticator.
DMU手順はIPレイヤーで発生するため、DMU手順はCDMA2000（R）1XまたはHRPD/1XEV-DOネットワークのMIPキー分布をサポートします。CDMA2000（R）HRPD/1XEV-DOネットワークは無線アクセスネットワーク（RAN）認証を提供していないため、DMU手順は誤ったMN攻撃の影響を受けやすくなります（CDMA2000（R）1Xネットワークよりも、セルラー認証と音声暗号化があります。（洞窟）認証を実行しました）。このため、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オプションをサポートする必要があります。
1. Ignore MN_Authenticator
1. MN_Authenticatorを無視します
Depending on other potential authentication/fraud prevention options (outside the scope of the DMU Procedure), the RADIUS AAA Server MUST have the capability to ignore the MN_Authenticator. For example, when the RADIUS AAA Server decrypts the MIP_Key_Data payload, the AAA Server silently discards the MN_Authenticator.
他の潜在的な認証/詐欺防止オプション（DMU手順の範囲外）に応じて、RADIUS AAAサーバーにはMN_Authenticatorを無視する機能が必要です。たとえば、RADIUS AAAサーバーがMIP_KEY_DATAペイロードを復号化すると、AAAサーバーはMN_Authenticatorを静かに破棄します。
2. Pre-Update Validation
2. プレップデートの検証
Prior to updating a subscription profile with the delivered MIP keys, the RADIUS AAA Server MUST compare the MN_AuthenticatorMN (delivered via the encrypted MIP_Key_Data payload) with the MN_AuthenticatorAAA (possibly delivered via the service provider customer care or billing/provisioning system).
配信されたMIPキーを使用してサブスクリプションプロファイルを更新する前に、RADIUS AAAサーバーは、MN_Authenticatormn（暗号化されたMIP_KEY_DATAペイロードを介して配信される）とMN_AuthenticatorAAA（サービスプロバイダーのカスタマーケアまたは請求/請求システムを介して配信される可能性がある）を比較する必要があります。
3. Post-Update Validation
3. ポストアップデートの検証
After the DMU Procedure is complete, the RADIUS AAA Server stores the delivered MN_AuthenticatorMN and waits for delivery of the MN_AuthenticatorAAA (via Customer Care, interactive voice response (IVR), or some other unspecified process). Once the MN_Authenticator is delivered to the RADIUS AAA Server, the AAA MUST compare the MN_AuthenticatorMN (delivered via the encrypted MIP_Key_Data payload) with the MN_AuthenticatorAAA. If the Authenticators match, the RADIUS AAA Server authorizes access and final update of the MIP keys.
DMU手順が完了した後、RADIUS AAAサーバーは配信されたMN_AuthenticAtormnを保存し、MN_Authenticatoraaaの配信を待ちます（カスタマーケア、インタラクティブな音声応答（IVR）、またはその他の未定プロセスを介して）。MN_AuthenticatorがRADIUS AAAサーバーに配信されると、AAAはMN_Authenticatormn（暗号化されたMIP_KEY_DATAペイロードを介して配信）とMN_Authenticatoraaaaを比較する必要があります。Authenticatorsが一致する場合、RADIUS AAAサーバーは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は、MN_Authenticatorを8桁数字として表示する必要があります（携帯電話のLCDディスプレイまたはモデムのGUIを介して）。MNがハンドセット内に存在する場合、ユーザーは次のキーパッドシーケンスを使用してMN_Authenticatorを表示することができます：「FCN * * M I P RCL」。それ以外の場合、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に従って、ユーザーコマンド時にランダムに/擬似ランダムに新しい24ビットMN_Authenticatorを生成する機能を備えている必要があります。リセット機能は、出荷/保管中のMN_Authenticatorの妥協の可能性を軽減します。MNがハンドセット内に存在する場合、ユーザーは次のキーパッドシーケンスを使用してMN_Authenticatorをリセットできます。「FCN * * M I P C RCL」。それ以外の場合、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_AUTHENTICATOR（8 10進数桁表現）とステッカーをMN（モデムなど）に貼り付けることにより、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認証は、MN_AuthenticatorをRADIUS AAAサーバーに配信する方法を決定する際に、サービスプロバイダーに最大限の柔軟性を提供します。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デバイスとサービスを取得すると、POSの代表者は、SALEポイントのコンピューター端末を介して請求/プロビジョニングシステムにサブスクリプション情報を記録します。請求/プロビジョニングシステムは、特定の情報をRADIUS AAAサーバー（例：NAI、MSID、電子シリアル番号（ESN））にMN_Authenticatorを含めます。モデムの場合、メーカーはMN_Authenticatorを事前にロードし、MN_Authenticatorのコピーをモデムに取り付けたステッカーに置いた可能性があります。POSの代表者は、MN_AUTHENTICATORの8桁の8桁値を顧客プロファイルにコピーするだけです。MNに適切なNAIがロードされ、電源が入った後、MNはRADIUS AAAサーバーでDMU手順を開始します。RADIUS AAAサーバーは、MN配信されたMN_Authenticatorと請求システムを搭載したMN_Authenticatorと比較します。Authenticatorsが一致する場合、RADIUS AAAサーバーは、配信されたMIPキーでサブスクライバープロファイルを更新し、サービスを承認します。RADIUS AAAサーバー内でポストアップデートオプションが有効になっている場合、RADIUS AAAサーバーは、請求/プロビジョニングシステムを介してMN_Authenticatorを受信するまでサブスクリプションプロファイルを一時的に更新します。
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システムは、最終的な検証とパケットデータアクセスのために、MN_AuthenticatorをRADIUS AAAサーバーに配信します。
The DMU Procedure is designed to maximize the efficiency of MIP key distribution while providing adequate key distribution security. The following provides a description of potential security vulnerabilities and their relative risk to the DMU Procedure:
DMUプロシージャは、適切なキーディストリビューションセキュリティを提供しながら、MIPキー分布の効率を最大化するように設計されています。以下は、潜在的なセキュリティの脆弱性とDMU手順に対する相対的なリスクの説明を提供します。
Because the MN is required to properly generate the MN_AAA, MN_HA, and CHAP key, the MN must perform cryptographic key generation in accordance with accepted random/pseudo-random number generation procedures. MN manufacturers MUST comply with RFC 4086 [12] guidelines, and service providers SHOULD ensure that manufacturers implement acceptable key generation procedures. The use of predictable cryptographic keys could be devastating to MIP security. However, the risk of not using acceptable random/pseudo-random key generation is minimal as long as MN manufacturers adhere to RFC 4086 guidelines. Furthermore, if a key generation flaw is identified, the flaw appears readily correctable via a software patch, minimizing the impact.
MNはMN_AAA、MN_HA、およびCHAPキーを適切に生成するために必要であるため、MNは、受け入れられたランダム/擬似ランダム数生成手順に従って暗号化キー生成を実行する必要があります。MNメーカーは、RFC 4086 [12]ガイドラインに準拠する必要があり、サービスプロバイダーは、メーカーが許容可能な主要生成手順を実装できるようにする必要があります。予測可能な暗号化キーの使用は、MIPセキュリティに壊滅的なものになる可能性があります。ただし、MNメーカーがRFC 4086ガイドラインに準拠している限り、許容可能なランダム/擬似ランダムキー生成を使用しないリスクは最小限です。さらに、主要な生成の欠陥が特定された場合、ソフトウェアパッチを介して欠陥が容易に修正できるように見え、影響を最小限に抑えます。
The DMU procedure is susceptible to a Man-in-the-Middle (MITM) attack; however, such an attack appears relatively complex and expensive. When Authentication and Key Agreement (AKA) is deployed within cdma2000(R) 1X, the MITM Attack will be eliminated. The risk of an MITM Attack is minimal due to required expertise, attack expense, and impending cdma2000(R) 1X mutual authentication protection. If a particular cdma2000(R) 1X network does not support A-key authentication, the MN_Authenticator MAY optionally be used.
DMU手順は、中間（MITM）攻撃の影響を受けやすい。ただし、このような攻撃は比較的複雑で高価に見えます。認証とキー契約（別名）がCDMA2000（R）1x内に展開されると、MITM攻撃は排除されます。必要な専門知識、攻撃費用、および差し迫ったCDMA2000（R）1倍相互認証保護により、MITM攻撃のリスクは最小限です。特定のCDMA2000（R）1XネットワークがAキー認証をサポートしていない場合、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秘密キーは数百万のMNS（RSA公開キー）に関連付けられている可能性があるため、RSA秘密鍵を許可されていない当事者への開示から保護することが重要です。MNメーカーがRSAパブリック/プライベートキーペアを生成している場合、MNメーカーは、適切なサービスプロバイダーへのRSA秘密キーの普及に関する適切なセキュリティ手順/ポリシーを確立する必要があります。RSA秘密キーは、正当なCDMA2000（R）サービスプロバイダーのみに配布する必要があります。サービスプロバイダーが独自のRSAパブリック/プライベートキーペアを生成している場合、サービスプロバイダーはRSA秘密キーを開示から不正な関係者への保護する必要があります。
Several vulnerabilities have been identified in certain implementations of RSA; however, they do not appear applicable to the DMU Procedure.
RSAの特定の実装でいくつかの脆弱性が特定されています。ただし、DMU手順には適用できないようには表示されません。
The MN appears to be protected against a false BS denial-of-service (DOS) attack, since only the proper RADIUS AAA server can recover the AAA_Authenticator. This method of preventing a false base station attack assumes security of the network messaging between the AAA and the serving system, as discussed in Section 7.9.
MNは、適切な半径AAAサーバーのみがAAA_Authenticatorを回復できるため、誤ったBSサービス拒否（DOS）攻撃から保護されているように見えます。セクション7.9で説明したように、誤った基地局の攻撃を防ぐこの方法は、AAAとサービングシステムの間のネットワークメッセージングのセキュリティを想定しています。
The cdma2000(R) 1X network appears adequately protected against a false MN by IS-2000 challenge-response authentication. If DMU is used outside the cellular domain, equivalent authentication procedures are required for the same level of security.
CDMA2000（R）1Xネットワークは、IS-2000の課題応答認証により、誤ったMNに対して適切に保護されているように見えます。DMUがセルラードメインの外部で使用される場合、同じレベルのセキュリティに同等の認証手順が必要です。
The 1xEV-DO RADIUS AAA Server MAY optionally authenticate the MN using the MN_Authenticator to prevent a fraudulent MN activation.
1xev-do radius AAAサーバーは、MN_Authenticatorを使用してMNを認証するために、詐欺的なMNの活性化を防ぐことができます。
There is no explicit lifetime for the keys distributed by DMU.
DMUによって配布されたキーには明示的な寿命はありません。
The lifetime of the keys distributed by DMU is determined by the system operator through the RADIUS AAA server. The MN_AAA and MN_HA key lifetimes can be controlled by initiating an update as needed.
DMUによって配布されたキーの寿命は、RADIUS AAAサーバーを介してシステムオペレーターによって決定されます。MN_AAAおよびMN_HAキーライフタイムは、必要に応じて更新を開始することで制御できます。
Furthermore, the DMU process is protected against false initiation because the MN cannot initiate DMU. This makes it unworkable to provide an explicit lifetime to the MN, since the MN cannot take any action to renew the keys after expiration.
さらに、MNがDMUを開始できないため、DMUプロセスは誤った開始から保護されています。これにより、MNは有効期限後にキーを更新するためのアクションを実行できないため、MNに明示的な寿命を提供することを実行できません。
The security of the MN-HA keys delivered from the RADIUS AAA server to the MIP home agent requires confidentiality for network messages containing such keys. The specification of security requirements for network messages is the responsibility of the operator, and is outside the scope of this document. (Note that similar considerations apply to the distribution of Shared Secret Data, which is already transmitted between nodes in the ANSI-41 network.)
RADIUS AAAサーバーからMIPホームエージェントに配信される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がセルラー演算子のドメインの外側で使用される場合、[4]で定義されている要求因果関係者や応答容認装置フィールドや[13]で定義されているメッセージ容認属性属性など、RADIUSセキュリティ機能を使用できます。
Three new RADIUS Attributes are required to support the DMU Procedure and are specified as follows:
DMU手順をサポートするには3つの新しい半径属性が必要であり、次のように指定されています。
Type: 26 Length: >9 Verizon Wireless Enterprise/Vendor ID: 12951
タイプ：26長さ：> 9 Verizon Wireless Enterprise/Vendor ID：12951
MIP_Key_Update_Request:
----------------------
The Home RADIUS AAA Server includes this attribute to indicate that MIP key update is required.
Home Radius AAAサーバーには、この属性が含まれており、MIPキーアップデートが必要であることを示します。
Vendor-Type = 1 Vendor-Length = 3 bytes Vendor-Value = PKOID of the RADIUS AAA Server
Vendor-Type = 1 Vendor-Length = 3 Bytes vendor-value = pkoid of the radius aaa server
MIP_Key_Data:
------------
Key data payload containing the encrypted MN_AAA key, MN_HA key, CHAP key, MN_Authenticator, and AAA_Authenticator. This payload also contains the Public Key Identifier.
暗号化されたMN_AAAキー、MN_HAキー、Chap Key、MN_Authenticator、およびAAA_Authenticatorを含むキーデータペイロード。このペイロードには、公開キー識別子も含まれています。
Vendor-Type = 2 Vendor-Length = 134 bytes NOTE: Vendor-Length depends on the size of the RSA modulus. For example, when RSA-512 is used, Vendor-Length = 70 bytes. Vendor-Value = 128 byte RSA encryption payload (when 1024-bit RSA used), which contains encrypted MN_AAA key, MN_HA key, CHAP key, MN_Authenticator, and AAA_Authenticator. The four (4) byte Public Key Identifier is concatenated to the encrypted payload.
ベンダータイプ= 2ベンダーレングス= 134バイト注：ベンダーの長さは、RSAモジュラスのサイズに依存します。たとえば、RSA-512を使用する場合、ベンダーレングス= 70バイト。Vendor-Value = 128 BYTE RSA暗号化ペイロード（1024ビットRSAが使用されている場合）。暗号化されたMN_AAAキー、MN_HAキー、Chap Key、MN_Authenticator、AAA_Authenticatorが含まれています。4つのバイト公開キー識別子は、暗号化されたペイロードに連結されています。
AAA_Authenticator:
-----------------
The 64-bit AAA_Authenticator value decrypted by the Home RADIUS AAA Server.
64ビットAAA_Authenticator値は、Home Radius AAAサーバーによって復号化されました。
Vendor-Type = 3 Vendor-Length = 10 bytes Vendor-Value = decrypted AAA_Authenticator from Home RADIUS AAA Server.
Vendor-Type = 3 Vendor-Length = 10 bytes vendor-value = decrypted aaa_authenticator from home radius aaa server。
Public Key Invalid:
------------------
The home RADIUS AAA Server includes this attribute to indicate that the public key used by the MN is not valid.
Home Radius AAAサーバーには、この属性を含めて、MNが使用する公開キーが無効であることを示します。
Vendor-Type = 4 Vendor-Length = 2 bytes Vendor-Value = none.
Vendor-Type = 4 Vendor-Length = 2 Bytes Vendor-Value = none。
Note: An Organization may define RADIUS VSAs using its own Organization identifier.
注：組織は、独自の組織識別子を使用して半径VSAを定義できます。
Three Verizon Wireless Mobile IP Vendor/Organization-Specific Extensions (VSEs) (RFC 3115), required to support the DMU Procedure, are specified as follows:
DMU手順をサポートするために必要な3つのVerizonワイヤレスモバイルIPベンダー/組織固有の拡張機能（VSES）（RFC 3115）は、次のように指定されています。
Type: 38 (CVSE-TYPE-NUMBER)
タイプ：38（cvse-type-number）
Verizon Wireless Vendor ID: 12951 (high-order octet is 0 and low order octets are the SMI Network Management Private Enterprise Code of the Vendor in the network byte order, as defined by IANA).
Verizon Wireless Vendor 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.
Home Radius AAAサーバーには、MIPキーアップデートが必要であることを示すために、この拡張機能が含まれています。
Length = 7
NOTE: The RFC 3115 Editor has stated that the Reserved field is not included in the length determination. Vendor-CVSE-Type = 1 Vendor-CVSE-Value = PKOID sent in the RADIUS MIP_Key_Update_Request attribute.
注：RFC 3115編集者は、予約済みフィールドは長さの決定に含まれていないと述べています。vendor-cvse-type = 1 vendor-cvse-value = pkoid radius mip_key_update_request属性。
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 Key、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バイト。Vendor-CVSE-Type = 2 Vendor-CVSE-Value = 128 BYTE RSA暗号化ペイロード（1024ビットRSAが使用されている場合）暗号化されたMN_AAAキー、MN_HAキー、Chap Key、MN_Authenticator、AAA_Authenticatorが含まれています。4つのバイト公開キー識別子とDMUVは、暗号化されたペイロードに連結されています。
AAA_Authenticator:
-----------------
The 64-bit AAA_Authenticator value decrypted by the Home RADIUS AAA Server.
64ビットAAA_Authenticator値は、Home Radius AAAサーバーによって復号化されました。
Length = 14 bytes Vendor-CVSE-Type = 3 Vendor-CVSE-Value = decrypted AAA_Authenticator from the Home RADIUS AAA Server.
長さ= 14バイトVendor-CVSE-Type = 3 Vendor-CVSE-Value = Home Radius AAAサーバーからのAAA_Authenticatorの復号化。
Public Key Invalid:
------------------
The Home RADIUS AAA Server includes this extension to indicate that the public key used by the MN is not valid.
Home Radius AAAサーバーには、MNで使用される公開キーが無効であることを示すために、この拡張機能を含みます。
Length = 6 bytes Vendor-CVSE-Type = 4 Vendor-CVSE-Value = none.
長さ= 6バイトVendor-CVSE-Type = 4 Vendor-CVSE-Value = none。
Note: An Organization may define VSEs using their own Organization identifier.
注：組織は、独自の組織識別子を使用してVSEを定義できます。
The Public Key Identifier (Pub_Key_ID) is used during the Dynamic Mobile IP Update (DMU) procedure to allow the RADIUS AAA Server to distinguish between different public keys (which may be assigned by different manufacturers, service providers, or other organizations). The Public Key Identifier consists of the PKOID, PKOI, PK_Identifier, and ATV fields. The DMU Version field enables subsequent revisions of the DMU procedure.
Dynamic Mobile IP Update（DMU）手順では、RADIUS AAAサーバーが異なるパブリックキー（異なるメーカー、サービスプロバイダー、または他の組織が割り当てることができる）を区別できるようにするために、Dynamic Mobile IP Update（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）に、RADIUS AAAサーバーが異なるPKOによって作成された異なるパブリックキーを区別できるようにするために、公開キー組織識別子（PKOID）を割り当てる必要があります（表1を参照）。
If a service provider does not provide the MN manufacturer with a (RSA) public key, the manufacturer MUST generate a unique RSA Public/Private key pair and pre-load each MN with the RSA public key (1024-bit modulus by default). The manufacturer MAY share the same RSA Private key with multiple service providers as long as reasonable security procedures are established and maintained (by the manufacturer) to prevent disclosure of the RSA Private (decryption) key to an unauthorized party.
サービスプロバイダーがMNメーカーに（RSA）公開キーを提供していない場合、メーカーは一意のRSAパブリック/プライベートキーペアを生成し、各MNをRSA公開キー（デフォルトでは1024ビットモジュラス）に事前ロードする必要があります。メーカーは、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フィールドは、追加のPKOまたはPKOIの拡張のサポートを可能にします。
The DMU Version field allows for DMU Procedure version identification (see Table 2).
DMUバージョンフィールドでは、DMUプロシージャバージョンの識別が可能です（表2を参照）。
The Algorithm Type and Version (ATV) field allows for identification of the public key algorithm and version used (see Table 3).
アルゴリズムの種類とバージョン（ATV）フィールドを使用すると、使用される公開キーアルゴリズムとバージョンを識別できます（表3を参照）。
Table 1. Public Key Organization Identification Table
表1.公開キーの組織識別表
PKOID Public Key PKOID Public Key
(HEX) Organization (PKO) (HEX) Organization (PKO)
----- ------------------ ----- ------------------
00 RESERVED 40 Sanyo Fisher Company
01 RESERVED 41 Sharp Laboratories of
America
02 RESERVED 42 Sierra Wireless, Inc.
03 RESERVED 43 Sony Electronics
04 RESERVED 44 Synertek, Inc.
05 RESERVED 45 Tantivy Communications,
Inc.
06 RESERVED 46 Tellus Technology, Inc.
07 RESERVED 47 Wherify Wireless, Inc.
08 RESERVED 48 Airbiquity
09 RESERVED 49 ArrayComm
0A Verizon Wireless 4A Celletra Ltd.
0B AAPT Ltd. 4B CIBERNET Corporation
0C ALLTEL Communications 4C CommWorks Corporation,
a 3Com Company
0D Angola Telecom 4D Compaq Computer
Corporation
0E Bell Mobility 4E ETRI
0F BellSouth International 4F Glenayre Electronics
Inc.
10 China Unicom 50 GTRAN, Inc.
11 KDDI Corporation 51 Logica
12 Himachal Futuristic 52 LSI Logic
Communications Ltd.
13 Hutchison Telecom (HK), 53 Metapath Software
Ltd. International, Inc.
14 IUSACELL 54 Metawave Communications
15 Komunikasi Selular 55 Openwave Systems Inc.
Indonesia (Komselindo)
16 Korea Telecom Freetel, 56 ParkerVision, Inc.
Inc.
17 Leap 57 QUALCOMM, Inc.
18 LG Telecom, Ltd. 58 QuickSilver Technologies
19 Mahanagar Telephone Nigam 59 Research Institute of
Limited (MTNL) Telecommunication
Transmission, MII (RITT)
1A Nextel Communications, 5A Schema, Ltd.
Inc.
1B Operadora UNEFON SA de CV 5B SchlumbergerSema
1C Pacific Bangladesh 5C ScoreBoard, Inc.
Telecom Limited
1D Pegaso PCS, S.A. DE C.V. 5D SignalSoft Corp.
PKOID Public Key PKOID Public Key
(HEX) Organization (PKO) (HEX) Organization (PKO)
----- ------------------ ----- ------------------
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).
注：80からFFは、Pkoid管理者（Verizion Wireless）によって割り当てられます。
Table 2. DMU Version
表2. DMUバージョン
DMU Version DMU Version
Value
----------- -----------
00 RFC 4784
01 Reserved
02 Reserved
03 Reserved
04 Reserved
05 Reserved
06 Reserved
07 Cleartext Mode
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] TIA/EIA/IS-2000 Series, Revision A, Telecommunications Industry Association, March 2000.
[2] TIA/EIA/IS-2000シリーズ、Revision A、Telecommunications Industry Association、2000年3月。
[3] TIA/EIA/IS-856, cdma2000(R) High Rate Packet Data Air Interface Specification, Telecommunications Industry Association, November 2000.
[3] TIA/EIA/IS-856、CDMA2000（R）高レートパケットデータエアインターフェイス仕様、電気通信産業協会、2000年11月。
[4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[4] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[5] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[6] TIA/EIA/IS-835-A, cdma2000(R) Wireless IP Network Standard, Telecommunications Industry Association, May 2001.
[6] TIA/EIA/IS-835-A、CDMA2000（R）ワイヤレスIPネットワーク標準、電気通信産業協会、2001年5月。
[7] ANSI/TIA/EIA-41-D-97, Cellular Radiotelecommunications Intersystem Operations, Telecommunications Industry Association, December 1997
[7] ANSI/TIA/EIA-41-D-97、Cellular RadioTelecommunications Interstem Operations、Telecommunications Industry Association、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、Spread Spectrum Systemsのモバイルステーションのオーバーザエアサービスプロビジョニング、電気通信産業協会、2001年12月
[9] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[9] Jonsson、J. and B. Kaliski、「パブリックキー暗号化基準（PKCS）＃1：RSA暗号仕様バージョン2.1」、RFC 3447、2003年2月。
[10] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization-Specific Extensions", RFC 3115, April 2001.
[10] Dommety、G。およびK. Leung、「モバイルIPベンダー/組織固有の拡張機能」、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）アクセスネットワークインターフェースの相互運用性仕様（IOS）、2001年8月、通信産業協会。
[12] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[12] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[13] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[13] Rigney、C.、Willats、W。、およびP. Calhoun、「Radius Extensions」、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.
Jeffrey Dyck（Qualcomm）、James Willkie（Qualcomm）、Jayanth Mandayam（Qualcomm）、Marcello Lioy（Qualcomm）、Michael Borella（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（エリクソン）、ブライアン・ヒックマン（エリクソン）、ソーサイ・シカレン（ブリッジウォーター）、パーム・サンドゥ（シエラワイヤレス）、イウリアン・ムカノ（シエラ・ワイヤレス）、サミー・トゥーアティ（エリクソン）の有用な議論やコメント。
Appendix A: Cleartext-Mode Operation
付録A：ClearText-Mode操作
DMU supports a cleartext mode for development testing where DMUV = 7. The MIP_Key_Data payload will assume the same size as if RSA 1024-bit encryption were applied to the payload. In this mode, the MIP_Key_Data RADIUS Attribute and MIP Vendor Specific Extension will be 134 bytes and 138 bytes in length, respectively. Thus, in cleartext mode, the payload MUST consist of 48 bytes of keys (MN_AAA, MN_HA, and CHAP key), 8-byte AAA_Authenticator, 3-byte MN_Authenticator. The next 69 bytes will be padded with "0" bits.
DMUは、DMUV = 7の開発テストのクリアテキストモードをサポートしています。MIP_KEY_DATAペイロードは、RSA 1024ビット暗号化がペイロードに適用された場合と同じサイズを想定します。このモードでは、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 key、mn_ha key、chap_key、mn_authenticator、aaa_authenticator、padding（69バイト）、public_key_idi、dmuv
Where:
ただし：
MN_AAA key = 128-bit random MN / RADIUS AAA Server key.
MN_AAAキー= 128ビットランダムMN / RADIUS AAAサーバーキー。
MN_HA key = 128-bit random MN / Home Agent (HA) key.
MN_HAキー= 128ビットランダムMN /ホームエージェント（HA）キー。
CHAP_key = 128-bit random Simple IP authentication key.
chap_key = 128ビットランダムシンプルIP認証キー。
MN_Authenticator = 24-bit random number.
MN_Authenticator = 24ビットの乱数。
AAA_Authenticator = 64-bit random number used by MN to authenticate the RADIUS AAA Server.
AAA_Authenticator = MNがRADIUS AAAサーバーを認証するために使用する64ビット乱数。
Padding = 69 bytes of 0's.
パディング= 69バイトの0。
DMU Version (DMUV) = 4-bit identifier of DMU version.
DMUバージョン（DMUV）= DMUバージョンの4ビット識別子。
Public Key Identifier (Pub _Key_ID) = PKOID, PKOI, PK_Expansion, ATV
公開キー識別子（pub _key_id）= pkoid、pkoi、pk_expansion、atv
Where:
ただし：
Public Key Organization Identifier (PKOID) = 8-bit serial number identifier of the Public Key Organization (PKO) that created the Public Key.
公開キーの識別子（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グループワンインターナショナルプレイスボストン、マサチューセッツ州02110
Phone: 617-951-7756 EMail: Christopher.Carroll@ropesgray.com
電話：617-951-7756メール：Christopher.carroll@ropesgray.com
* This document was developed while at Verizon Wireless.
* このドキュメントは、Verizon Wirelessで開発されました。
Frank Quick Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
フランククイックQualcomm Incorporated 5775 Morehouse Drive San Diego、CA 92121 USA
Phone: 858-658-3608 EMail: fquick@qualcomm.com
電話：858-658-3608メール：fquick@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびwww.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。