RFC4784 日本語訳
4784 Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R)Networks. C. Carroll, F. Quick. June 2007. (Format: TXT=102856 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Carroll
Request for Comments: 4784 Ropes & Gray LLP
Category: Informational F. Quick
Qualcomm Inc.
June 2007
コメントを求めるワーキンググループC.キャロル要求をネットワークでつないでください: 4784年のロープとグレーLLP Category: 情報の迅速なF.クアルコム株式会社2007年6月
Verizon Wireless Dynamic Mobile IP Key Update
for cdma2000(R) Networks
ベライゾンのワイヤレスのダイナミックなモバイルIP 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).
IETFが信じる著作権(C)(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 Access-廃棄物を利用して、公開鍵暗号系における、秘密鍵の共有を練習します。(それは、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).
ベライゾンのWireless DynamicのモバイルIP Key Update手順は、cdma2000(R)ネットワークでモバイルIP(MIP)暗号化キーを分配して、アップデートするためのメカニズム(High Rate Packet Dataを含んでいて)です。High Rate Packet Dataはしばしば1xEVしていると呼ばれます。 DynamicのモバイルIP Key Update(DMU)手順はモバイルIP Foreignエージェント(FA)として務めているcdma2000(R)パケットData Serving Node(PDSN)を通したMIPのモバイルNode(ミネソタ)と、RADIUS Authenticationと、AuthorizationとAccounting(AAA)サーバの間に起こります。
cdma2000(R) is a registered trademark of the Telecommunications Industry Association (TIA).
cdma2000(R)は電気通信産業連盟(TIA)の登録商標です。
Carroll & Quick Informational [Page 1] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[1ページ]のRFC4784ダイナミックなMIP
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Basic Dynamic MIP Key Update Mechanism ..........................3
2.1. RSA Encrypted Key Distribution .............................4
2.2. Mutual Authentication (1X) .................................5
2.3. Encrypted Password Authentication ..........................8
3. Dynamic MIP Key Update Advantages over OTASP ...................10
4. Detailed DMU Procedure Description and Requirements ............10
4.1. RSA Public Key Cryptography ...............................11
4.2. Other Public Key Algorithms ...............................11
4.3. Why No Public Key Infrastructure (PKI)? ...................11
4.4. Cryptographic Key Generation ..............................12
4.5. MIP_Key_Data Payload ......................................12
4.6. RSA Key Management ........................................13
4.7. RADIUS AAA Server .........................................14
4.8. MN (Handset or Modem) .....................................16
4.9. PDSN / Foreign Agent (FA) .................................19
4.10. Home Agent (HA) ..........................................20
4.11. DMU Procedure Network Flow ...............................20
5. DMU Procedure Failure Operation ................................25
6. cdma2000(R) HRPD/1xEV-DO Support ...............................28
6.1. RADIUS AAA Support ........................................28
6.2. MN Support ................................................29
6.3. Informative: MN_Authenticator Support .....................30
7. Security Considerations ........................................31
7.1. Cryptographic Key Generation by the MN ....................31
7.2. Man-in-the-Middle Attack ..................................31
7.3. RSA Private Key Compromise ................................32
7.4. RSA Encryption ............................................32
7.5. False Base Station/PDSN ...................................32
7.6. cdma2000(R) 1X False MN ...................................32
7.7. HRPD/1xEV-DO False MN .....................................32
7.8. Key Lifetimes .............................................32
7.9. Network Message Security ..................................33
8. Verizon Wireless RADIUS Attributes .............................33
9. Verizon Wireless Mobile IP Extensions ..........................34
10. Public Key Identifier and DMU Version .........................36
11. Conclusion ....................................................40
12. Normative References ..........................................41
13. Informative References ........................................41
14. Acknowledgments ...............................................42
Appendix A. Cleartext-Mode Operation ..............................43
1. 序論…3 1.1. このドキュメントで中古のコンベンション…3 2. 基本的なダイナミックなMIP主要なアップデートメカニズム…3 2.1. RSAは主要な分配を暗号化しました…4 2.2. 互いの認証(1X)…5 2.3. 暗号化されたパスワード認証…8 3. OTASPよりダイナミックなMIP主要なアップデート利点…10 4. DMU手順記述と要件を詳しく述べます…10 4.1. RSAパブリックキー暗号作成法…11 4.2. 他の公開鍵アルゴリズム…11 4.3. なぜ公開鍵暗号基盤がありませんか?(PKI) ...................11 4.4. 暗号のキー生成…12 4.5. MIPの_の主要な_データ有効搭載量…12 4.6. RSA Key Management…13 4.7. 半径AAAサーバ…14 4.8. ミネソタ(受話器かモデム)…16 4.9. PDSN/外国人のエージェント(ファ)…19 4.10. ホームのエージェント(ハ)…20 4.11. DMU手順ネットワーク流動…20 5. DMU手順失敗操作…25 cdma2000(R) HRPD/1xEVしている6サポート…28 6.1. 半径AAAサポート…28 6.2. Mnサポート…29 6.3. 有益: ミネソタ_固有識別文字サポート…30 7. セキュリティ問題…31 7.1. ミネソタによる暗号のキー生成…31 7.2. 中央の男性攻撃…31 7.3. RSA秘密鍵感染…32 7.4. RSA暗号化…32 7.5. 偽の基地局/PDSN…32 7.6cdma2000(R) 1Xの誤ったミネソタ…32 7.7. HRPD/1xEV誤ったミネソタをしてください…32 7.8. キー生涯…32 7.9. メッセージセキュリティをネットワークでつないでください…33 8. ベライゾンのワイヤレスの半径属性…33 9. ベライゾンのワイヤレスのモバイルIP拡大…34 10. 公開鍵識別子とDMUバージョン…36 11. 結論…40 12. 標準の参照…41 13. 有益な参照…41 14. 承認…42 付録A.Cleartext-モード操作…43
Carroll & Quick Informational [Page 2] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[2ページ]のRFC4784ダイナミックなMIP
1. Introduction
1. 序論
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.
ベライゾンのWireless DynamicのモバイルIP Key Update手順は、1xEV cdma2000(R) 1xRTT(1X)[2]とHigh Rate Packet Data(HRPD)/しているネットワーク[3]でモバイルIP(MIP)暗号化キーを分配して、アップデートするためのメカニズムです。 DynamicのモバイルIP Key Update(DMU)手順がモバイルIPモバイルNode(ミネソタ)とホームRADIUS[4]の間に起こる、(Diameter[5])認証(モバイルIP Foreignエージェント(FA)として務めているcdma2000(R)パケットData Serving Node(PDSN)を通したAuthorizationとAccounting(AAA)サーバ) (本書では、私たちは訪問されたシステムに位置するかもしれないAAAサーバと対照的にホームAAAサーバを示すのに頭文字語AAAHを使用します。) この手順が電気通信産業連盟(TIA)TR-45 Standardに従うワイヤレスシステムをサポートすることを意図する、-835である、[6]。 しかしながら、モバイルNode(ミネソタ)とRADIUS AAA Serverの間の共有秘密キーのブートストラップ法を可能にするためにどんなMIPネットワークでもDMUを実行できました。
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手順は、しっかりと潜在的にcdma2000(R) 1Xの数百万のユニークなMIPキーを分配して、同じRSA公開鍵を使用して、HRPD/1xEVモバイルNodes(ミネソタ)をするのにRSA公開鍵暗号を利用します。
By leveraging the existing cdma2000(R) 1X authentication process, the Dynamic Mobile IP Key Update process employs a mutual authentication mechanism in which device-to-network authentication is facilitated using cdma2000(R) 1X challenge-response authentication, and network- to-device authentication is facilitated using RSA encryption.
既存のcdma2000(R) 1X認証過程を利用することによって、Key Updateが処理するDynamicのモバイル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暗号化を利用することによって、ミネソタ(または、ミネソタのメーカー)は、キー(そして、チャレンジハンドシェイク式認証プロトコル(CHAP)キー)をMIPにあらかじめ生成して、DMU手順の開始の前にMIPキーをあらかじめ暗号化できます。 このプレ計算能力を使うことによって、DMUプロセスは主要な交換の間の計算(1桁の)よりディフィー-ヘルマンKey Exchangeを必要とします。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
2. Basic Dynamic MIP Key Update Mechanism
2. 基本的なダイナミックなMIP主要なアップデートメカニズム
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の)互いの認証を暗号化しました。
Carroll & Quick Informational [Page 3] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[3ページ]のRFC4784ダイナミックなMIP
2.1. RSA Encrypted Key Distribution
2.1. RSAは主要な分配を暗号化しました。
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公開鍵暗号を利用することによって、一般的なRSA公共の(暗号化)キー(ミネソタのメーカーによる)でMNsをプレロードできます、関連RSA兵士の(復号化)キーはミネソタのメーカーから信じられたサービスプロバイダーまでしっかりと分配されますが。 あるいはまた、サービスプロバイダーは、それ自身のRSA公衆/秘密鍵組を生成して、MNsのプレロードのためにミネソタのメーカーにRSA公開鍵を分配できるだけです。
During the manufacturing process, the MN manufacturer pre-loads each MN with the RSA public key. When the MN is powered-up (or client application initiated), the MN can pre-generate and encrypt MIP keys for distribution to the Home RADIUS AAA Server during the DMU process. Alternatively, the MN manufacturer can pre-generate MIP keys, encrypt the MIP key payload, and pre-load the MN with multiple encrypted MIP key payloads to enable the DMU procedure.
製造プロセスの間、ミネソタのメーカーはRSA公開鍵で各ミネソタをプレロードします。 ミネソタが動力付きに上がっているとき(または、アプリケーションが開始したクライアント)、ミネソタは、DMUプロセスの間、分配のためのMIPキーをホームRADIUS AAA Serverにあらかじめ生成して、暗号化できます。 あるいはまた、ミネソタのメーカーは、DMU手順を可能にするためにMIPにキーをあらかじめ生成して、MIPの主要なペイロードを暗号化して、複数の暗号化されたMIP主要なペイロードでミネソタをプレロードできます。
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の主要なアップデートを必要とするとき)、ミネソタの間: 1) 適切なMIPキー、CHAPキー、および認証情報、2つの)用途がペイロード情報、3を)暗号化する埋め込まれたRSA公開鍵であると生成して、ペイロードをMIP Registration Requestに追加します。 セル基地の駅(BS)とPacket Data Serving Node(PDSN)を通してモバイルIP Foreignエージェント(FA)にRegistration Requestを送ります。 RADIUS AAA Serverが暗号化されたペイロード(後でMIP_Key_Dataを定義づける)を受けるとき、AAA Serverはペイロードを解読して、MIPキーを回収するために主要なRSA兵士を使用します。
Carroll & Quick Informational [Page 4] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[4ページ]のRFC4784ダイナミックなMIP
MN BS/PDSN/FA AAA
-- ---------- ---
| | |
------------------ | -------------------
| RSA Public Key | | | RSA Private Key |
| Pre-loaded by | | | Pre-loaded by |
| Manufacturer | | | Service Provider |
------------------ | -------------------
| Registration Request, |
| (MIP keys), RSA | |
| Public Key | |
|-------------------->| |
| | Access Request, (MIP keys),
| | RSA Public Key |
| |---------------------->|
| | -------------------
| | | Decrypt MIP |
| | | Keys using RSA |
| | | Private Key |
| | -------------------
Mn BS/PDSN/ファAAA------------ --- | | | ------------------ | ------------------- | RSA公開鍵| | | RSA秘密鍵| | プレロードされます。| | | プレロードされます。| | メーカー| | | サービスプロバイダー| ------------------ | ------------------- | 登録要求| | (MIPキー), RSA| | | 公開鍵| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| Request、(MIPキー)にアクセスしてください。| | RSA公開鍵| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| ------------------- | | | MIPを解読してください。| | | | RSAを使用するキー| | | | 秘密鍵| | | -------------------
Figure 1. RSA Encrypted Key Distribution
図1。 RSAは主要な分配を暗号化しました。
2.2. Mutual Authentication (1X)
2.2. 互いの認証(1X)
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 Serverはミネソタ/デバイス認証の委譲でcdma2000(R) 1XホームLocation Register(HLR)とその関連Authenticationセンター(西暦)[7]に互いの認証を達成できます、ミネソタはRADIUS AAA Serverを認証するのにRSA暗号化を利用しますが。
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/西暦を通したミネソタ/デバイス認証はミネソタのモバイル駅(MS)にはcdma2000(R) 1Xネットワークがある既存のAuthentication Key(A主要な)とShared Secret Data(SSD)があるという仮定に基づいています。 MS呼び出し創作が起こると、西暦はMSを認証します。認証がうまくいくなら、BSはモバイル駅のIdentifier(MSID)(例えば、モバイルIdentification Number(MIN))をPDSNに渡します。 次に、「認証されたMSID」はPDSNからRADIUS AAAサーバに送られたRADIUS Access Request(ARQ)メッセージ[4]に含まれています。「認証されたMSID」がRADIUS AAA MSIDに合っているならRADIUS AAAサーバがミネソタの購読に関連しているMSIDを保存するのでRADIUS AAAサーバがミネソタのアクセスを認可できる、すなわち、RADIUS AAAサーバはcdma2000(R) 1X HLR/西暦へ認証機能を代表として派遣しています。
Carroll & Quick Informational [Page 5] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[5ページ]のRFC4784ダイナミックなMIP
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サーバー証明(ミネソタのそばの)は、ミネソタからRADIUS AAA Serverに送られた暗号化されたペイロードに乱数(AAA_Authenticator)を含んでいることによって、可能にされます。適切なRSA兵士のキーの所有者だけには、ペイロードを解読して、ユニークなAAA_Authenticatorを回収する能力があるでしょう。 ミネソタが正しいAAA_Authenticator(RADIUS AAA Serverによって返される)を受けるなら、ミネソタは偽の基地の駅(BS)と対話していないことが保証されます。
Carroll & Quick Informational [Page 6] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[6ページ]のRFC4784ダイナミックなMIP
MN BS/PDSN/FA HLR/AC AAA
-- ---------- ------ ---
------------------ | | -------------------
| RSA Public Key | | | | RSA Private Key |
| Pre-loaded by | | | | Pre-loaded by |
| Manufacturer | | | | Service Provider |
------------------ | | -------------------
| Global Challenge | |
|<-------------| | |
| | | |
| Auth_Response | |
|------------->| | |
| | Auth_Response | |
| |---------------->| |
| | ------------------ |
| | | IS-2000 | |
| | | Authentication | |
| | ------------------ |
| | Auth_Success | |
| |<----------------| |
| ------------------ | |
| | BS forwards | | |
| | Authenticated | | |
| | MSID to PDSN | | |
| ------------------ | |
| | | |
| Registration Request | |
| (MIP keys, AAA_Authenticator), |
| RSA Public Key | |
|------------->| | |
| | Access Request, MSID, |
| | (MIP keys, AAA_Authenticator),
| | RSA Public Key |
| |------------------------------->|
| | | -------------------
| | | | Check MSID, |
| | | | Decrypt AAA_- |
| | | | Authenticator |
| | | -------------------
| Access Reject, AAA_Authenticator |
| |<-------------------------------|
Registration Reply, AAA_Authenticator |
|<-------------| | |
------------------ | | |
| Check AAA_- | | | |
| Authenticator | | | |
------------------ | | |
Figure 2. Mutual Authentication
Mn BS/PDSN/ファHLR/交流AAA------------ ------ --- ------------------ | | ------------------- | RSA公開鍵| | | | RSA秘密鍵| | プレロードされます。| | | | プレロードされます。| | メーカー| | | | サービスプロバイダー| ------------------ | | ------------------- | 地球規模の難題| | | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|、| Auth_応答| | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| Auth_応答| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| ------------------ | | | | -2000です。| | | | | 認証| | | | ------------------ | | | Auth_成功| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| ------------------ | | | | BSフォワード| | | | | 認証されます。| | | | | PDSNへのMSID| | | | ------------------ | | | | | | | 登録要求| | | (MIPキー、AAA_Authenticator), | | RSA公開鍵| | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| MSID、要求にアクセスしてください。| | | (MIPキー、AAA_Authenticator), | | RSA公開鍵| | |------------------------------->| | | | ------------------- | | | | MSIDをチェックしてください。| | | | | AAAが_であると解読してください、-| | | | | 固有識別文字| | | | ------------------- | アクセス廃棄物、AAA_固有識別文字| | |<-------------------------------| 登録回答、AAA_固有識別文字| | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| ------------------ | | | | AAA_をチェックしてください、-| | | | | 固有識別文字| | | | ------------------ | | | 図2。 互いの認証
Carroll & Quick Informational [Page 7] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[7ページ]のRFC4784ダイナミックなMIP
2.3. Encrypted Password Authentication
2.3. 暗号化されたパスワード認証
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)1キーの/SSD認証が1xEVしているところで利用可能でないか、特定のcdma2000(R) 1XネットワークがA主要な認証をサポートしないかもしれなくて、またはまた、DMU手順がRADIUS AAA Serverが任意にミネソタを認証するのを可能にするミネソタ(そして/または、メーカーがプレロードされる)によって生成された乱数(ミネソタ_Authenticator)を含んでいるので(1XEVでは、単にネットワークでつないでください)。
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.
ミネソタ_Authenticatorは、攻撃者による妨害と可能な再使用を防ぐためにRSAによって暗号化されたMIP_Key_Dataペイロードの中にミネソタからホームAAA Serverまで伝えられます。 理想的に、ミネソタ_AuthenticatorはOne-時間Passwordとして利用されます。 しかしながら、RSA暗号化は、ミネソタ_Authenticatorが各サービスプロバイダーの主要な流通政策に基づいてことによると再使用されるのを許容します。
When the encrypted MIP keys are decrypted at the Home RADIUS AAA Server, the MN_Authenticator is also decrypted and compared with a copy of the MN_Authenticator stored within the Home RADIUS AAA Server. The Home RADIUS AAA Server receives a copy of the MN_Authenticator out-of-band (not using the cdma2000(R) network) utilizing one of numerous possible methods outside the scope of the standard. For example, the MN_Authenticator MAY be: 1) read out by a Point-of-Sale provisioner from the MN, input into the subscriber profile, and delivered, along with the Network Access Identifier (NAI), via the billing/provision system to the Home RADIUS AAA server, 2) verbally communicated to a customer care representative via a call, or 3) input by the user interfacing with an interactive voice recognition server. The out-of-band MN_Authenticator delivery is not specified in this document to maximize the service provider's implementation flexibility.
暗号化されたMIPキーがホームRADIUS AAA Serverで解読されるとき、ミネソタ_AuthenticatorはホームRADIUS AAA Serverの中に保存されるミネソタ_Authenticatorのコピーと、また、解読されて、比較されます。ホームRADIUS AAA Serverは、バンドの外(cdma2000(R)ネットワークを使用しない)で規格の範囲の外で多数の可能なメソッドの1つを利用することでミネソタ_Authenticatorのコピーを受けます。 例えば、ミネソタ_Authenticatorは以下の通りです。 銀行POSの食料係によってミネソタから読みだされて、加入者プロフィールに入力されて、Network Access Identifierと共に提供された1)(NAI) ホームRADIUS AAAサーバへの支払い/支給システムを通した2)は対話的な音声認識サーバとのユーザ接続で口頭で顧客ケア代表に呼び出し、または3)入力で交信しました。バンドで出ているミネソタ_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手順の前にミネソタ_Authenticatorを抽出するのは、可能です。 しかしながら、そのような公開に関連しているリスクは最小限です。 HRPD/1xEVしているミネソタが新規登録プロセスの間、デバイス識別子を伝えないので、攻撃者は特定のミネソタデバイスかNAIと共に盗まれたミネソタ_Authenticatorがあってもパスワードを関連させることができません。(NAIはDMU手順開始のすぐ前に通常食糧を供給されます)。
The MN_Authenticator is typically generated by a random/pseudorandom number generator within the MN. MN_Authenticator generation is initiated by the MN user; however, it may be initially pre-loaded by the manufacturer. When the MN_Authenticator is reset (i.e., a new MN_Authenticator is generated), all MIP_Data_Key payloads using the previous MN_Authenticator are discarded and the MN immediately re-
ミネソタ_Authenticatorはミネソタの中の無作為の/擬似ランダム数ジェネレータによって通常生成されます。 ミネソタ_Authenticator世代はミネソタユーザによって開始されます。 しかしながら、それは初めは、メーカーによってプレロードされるかもしれません。 ミネソタ_Authenticatorがすぐにリセットされるとき(すなわち、新しいミネソタ_Authenticatorは発生しています)、前のミネソタ_Authenticatorを使用するすべてのMIP_Data_Keyペイロードが捨てられてミネソタである、再
Carroll & Quick Informational [Page 8] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[8ページ]のRFC4784ダイナミックなMIP
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.
新しいミネソタ_Authenticatorを含むMIP_Key_Dataペイロードを暗号化します。 それがミネソタユーザによって明らかにリセットされない場合、ミネソタ_Authenticatorは変化してはいけません。 したがって、ミネソタは、ミネソタ_Authenticatorをアップデートするまで同じミネソタ_Authenticatorを使用することで_Key_Dataペイロードを新しいMIPに生成するでしょう。
-------------------------
| 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 |
----------------------------- -------------------------
------------------------- | ユーザによって開始されています。| | ミネソタ_固有識別文字[x]| | 世代| ------------------------- | v----------------------------- ------------------------------ | メーカー| | ミネソタ_固有識別文字[y]を削除してください。| | ミネソタ_固有識別文字[y]|、-、-、-、--、>| ミネソタ_固有識別文字[x]を保存してください。| | 世代**| | ミネソタで| ----------------------------- ------------------------------ | v------------------------- | MIPの_の主要な_データを削除してください。| | に基づいて有効搭載量。| | ミネソタ_固有識別文字[y]| ------------------------- | v----------------------------- ------------------------- | そしてキーズ_VALIDが述べる。| | MIP_が主要な_データであると生成してください。| | 公約、削除|、-、-、-、--、>| に基づいて有効搭載量。| | MIPの_の主要な_データ有効搭載量| | ミネソタ_固有識別文字[x]| ----------------------------- ------------------------- ^ | | v----------------------------- ------------------------- | DMU MIPの_の主要な_データ| | MIPの_の主要な_データを保存してください。| | 配送| <、-、-、-、--、| 有効搭載量| ----------------------------- -------------------------
Figure 3. MN_Authenticator and MIP_Key_Data Payload State Machine
図3。 主要な_データ有効搭載量州が機械加工するMn_固有識別文字とMIP_
**Note: Manufacturer pre-load of MN_Authenticator is not essential since the MN_Authenticator is typically generated by the MN. However, manufacturer pre-load may reduce the provisioner burden of accessing a device such as a modem to recover the MN_Authenticator for entry into the service provider provisioning system.
**以下に注意してください。 ミネソタ_Authenticatorがミネソタによって通常生成されるので、ミネソタ_Authenticatorのメーカー予荷重は不可欠ではありません。 しかしながら、メーカー予荷重はミネソタ_Authenticatorをエントリーに回収するためにモデムなどのデバイスにアクセスする食料係負担をサービスプロバイダー食糧を供給するシステムに変えるかもしれません。
Carroll & Quick Informational [Page 9] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[9ページ]のRFC4784ダイナミックなMIP
3. Dynamic MIP Key Update Advantages over OTASP
3. OTASPよりダイナミックなMIP主要なアップデート利点
The DMU procedure has numerous advantages over the current Over-the- Air Service Provisioning (OTASP) [8] procedure, including:
現在のOverより多数の利点がDMU手順にある、-、-放送して、:Service Provisioning(OTASP)[8]手順を放送してください。
* In DMU, MIP key distribution occurs directly between the MN and
AAA Server at the IP Layer. This eliminates the need for an
interface between the Over-the-Air Functionality (OTAF) and
RADIUS AAA server.
* DMUでは、MIPの主要な分配はIP LayerのミネソタとAAA Serverの直接間に起こります。 これはOver空気Functionality(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 Supports MIPのcdma2000(R) 1Xに、主要な分配とHRPD/1xEVしているミネソタ。 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. OTASPがMSのMIPキーを提供するだけであるRelay-モードによるミネソタにMIPの主要な分配を容易にします。例えば、OTASPはMSモデムに接続するLaptopミネソタのキーをMIPに提供できません。
* Pre-encryption of MIP_Key_Data allows the DMU procedure to be
an order of magnitude faster than Diffie-Hellman Key Exchange.
* MIP_Key_Dataのプレ暗号化は、DMU手順がディフィー-ヘルマンKey Exchangeより1桁速いのを許容します。
* 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では、ミネソタのメーカーは、MIPにキーをあらかじめ生成して、MIPの主要なペイロードをあらかじめ暗号化して、ミネソタでペイロードをプレロードできます。 したがって、限られた処理能力があるミネソタは、RSA暗号化を使用するのに決して必要ではありません。 OTASPデバイスは主要な更新処理の間、いつもやむを得ず計算上高価な羃法を実行します。
* In DMU, the MN is protected against Denial-of-Service (DOS)
attacks in which a false BS changes the MIP key for MNs in its
vicinity. OTASP Diffie-Hellman Key Exchange is vulnerable to a
false BS DOS attack.
* DMUでは、ミネソタは偽のBSが付近のMNsに、主要なMIPを変えるサービス妨害(DOS)攻撃に対して保護されます。 OTASPディフィー-ヘルマンKey Exchangeは誤ったBS DOS攻撃に被害を受け易いです。
* DMU utilizes mutual authentication. OTASP Diffie-Hellman Key
Exchange does not utilize mutual authentication.
* DMUは互いの認証を利用します。 OTASPディフィー-ヘルマンKey Exchangeは互いの認証を利用しません。
4. Detailed DMU Procedure Description and Requirements
4. 詳細なDMU手順記述と要件
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.
ベライゾンのWireless DynamicのモバイルIP Update手順は、不可欠のMIP暗号化キー(例えば、ミネソタ-AAAHキーとミネソタ-HAキー)とSimple IP CHAPキーを分配するための安全で、しかし、非常に効率的なメカニズムです。 DMUプロトコルはMIP_Key_Dataとして知られているキーの暗号化された材料ペイロードのプレ計算を可能にします。 プロシージャの効率を大いに高めて、DMU手順はわざわざ公開鍵暗号基盤(PKI)証明書の使用を避けます。
Carroll & Quick Informational [Page 10] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[10ページ]のRFC4784ダイナミックなMIP
4.1. RSA Public Key Cryptography
4.1. RSAパブリックキー暗号作成法
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.
RFC3447[9]PKCS#1によると、RSA公開鍵暗号化と復号化を実行しなければなりません: RSA暗号化バージョン1.5。 DMU MUSTはデフォルトで1024年のビットの係数でRSAをサポートします。 また、ミネソタユーザの効率かセキュリティ要件によって、DMU MAYは768ビットの、または、2048年のビットのRSAをサポートします。 小さいか、または少ない数の非零ビット(例えば、65537)を持っている公共のRSA解説者を使用するRSA計算加速は許容できます。
4.2. Other Public Key Algorithms
4.2. 他の公開鍵アルゴリズム
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は他の公開鍵技術の使用を排除しません。 プロトコルは使用される暗号化のタイプを定義するPublic Key Type分野を含んでいます。
4.3. Why No Public Key Infrastructure (PKI)?
4.3. なぜ公開鍵暗号基盤がありませんか?(PKI)
DMU is designed to maximize the efficiency of Mobile IP (MIP) key distribution for cdma2000(R) MNs. The use of a public key Certificate would improve the flexibility of the MIP key update process by allowing a Certificate Authority (CA) to vouch for the RSA public key delivered to the MN. Unfortunately, the use of a public key certificate would significantly reduce the efficiency (speed and overhead) of the MIP key update process. For instance, each MN must be pre-loaded with the CA's public key. During the MIP key distribution process, the network must first deliver its RSA public key (in a certificate) to the MN. The MN must then use RSA to decrypt the Certificate's digital signature to verify that the presented RSA public key is legitimate. Such a process significantly increases the number of exchanges, increases air interface overhead, increases the amount of MN computation, and slows the MIP key update process.
DMUは、cdma2000(R) MNsのためにモバイルIP(MIP)の主要な分配の効率を最大にするように設計されています。 CertificateがRSA公開鍵に太鼓判を押すためにCertificate Authority(カリフォルニア)を許容することによってMIPの主要な更新処理の柔軟性を改良する公開鍵の使用はミネソタに配送されました。 残念ながら、公開鍵証明書の使用はMIPの主要な更新処理の効率(速度とオーバーヘッド)をかなり減少させるでしょう。 例えば、CAの公開鍵で各ミネソタをプレロードしなければなりません。 MIPの主要な分配プロセスの間、ネットワークは最初に、RSA公開鍵(証明書の)をミネソタに提供しなければなりません。 そして、ミネソタは、提示されたRSA公開鍵が正統であることを確かめるためにCertificateのデジタル署名を解読するのにRSAを使用しなければなりません。 そのようなプロセスは、交換の数をかなり増強して、航空インタフェースオーバーヘッドを増強して、ミネソタの計算の量を増強して、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はおそらく不要です。 多くへのManyコミュニケーションモデルに、PKIは理想的です、インターネットなどのように中多くの異なったユーザが多くの異なったWebsitesに連結する。 しかしながら、セル/PCS Packet Data環境で、Manyから1つ(または、わずか)の分配モデル(多くのユーザが彼らのモバイルIPセキュリティ協会(すなわち、暗号化キー)を証明するために1ワイヤレスのCarrierに連結する)が存在しています。
Carroll & Quick Informational [Page 11] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[11ページ]のRFC4784ダイナミックなMIP
4.4. Cryptographic Key Generation
4.4. 暗号のキー生成
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手順が手当たりしだいに各ミネソタを当てにする、/、疑似である、無作為である、ミネソタ_AAAHキー、ミネソタ_HAキー、およびSimple IP CHAPキーを生成してください。 各ミネソタには、ガイドライン指定されたコネRFC4086に従った無作為の/擬似乱数に「セキュリティのための偶発性要件」を生成する能力がなければなりません。
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キーのプレ世代とプレ暗号化で許容できます。
4.5. MIP_Key_Data Payload
4.5. 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暗号化キー(ミネソタ_AAAHキーとミネソタ_HAキー)とSimple IP CHAPキーは、MIP_Key_Data有効搭載量(_AAA Authenticatorと_ミネソタAuthenticatorに伴う)にカプセル化されて、暗号化されます。 組織MIP Vendor/特有のExtension(VSE)としてMIP_Key_Data有効搭載量をミネソタのMIP Registration Request(RRQ)に追加します(RFC3115[10]の組織モバイルIP Vendor/特有のExtensionsを見てください)。 PDSNがRADIUS Access Request(ARQ)メッセージにMIP RRQを変換するとき、MIP_Key_Data有効搭載量は組織MIP Vendor/特有のExtensionからVendor Specific RADIUS Attribute(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 Access Requestを受け取り次第、RADIUS AAA Serverは、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[__ミネソタ_AAAHの主要で、主要なミネソタ_HA CHAP_主要なミネソタAuthenticator、AAA Authenticator]、Public_Key_ID DMUV
Where:
どこ:
MN_AAAH key = 128-bit random MN / RADIUS AAA Server key
(encrypted)
ミネソタ_AAAH主要な=128ビットの無作為のミネソタ/RADIUS AAA Serverキー(暗号化されます)
MN_HA key = 128-bit random MN / Home Agent (HA) key (encrypted)
ミネソタ_HA主要な=128ビットの無作為のミネソタ/ホームエージェント(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_キーは128ビットの無作為のSimple IP認証主要な(暗号化された)注意と等しいです: Simple IP CHAPキーはAT-CHAPキーがA12 Interfaceに認証[11]を使用したのと同じではありません。
MN_Authenticator = 24-bit random number (displayed as an 8 decimal
digit number). (To be used for 1xEV-DO networks.) (encrypted)
ミネソタ_Authenticatorは24ビットの乱数(8 10進数字番号として、表示する)と等しいです。 (1xEVしているネットワークに使用される。) (暗号化されます)
Carroll & Quick Informational [Page 12] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[12ページ]のRFC4784ダイナミックなMIP
AAA_Authenticator = 64-bit random number used by MN to
authenticate the RADIUS AAA Server. (encrypted)
AAA_AuthenticatorはRADIUS AAA Serverを認証するのにミネソタによって使用された64ビットの乱数と等しいです。(暗号化されます)
DMU Version (DMUV) = 4-bit identifier of DMU version.
DMUバージョン(DMUV)はDMUバージョンの4ビットの識別子と等しいです。
Public Key Identifier (Public_Key_ID) = PKOID, PKOI, PK_Expansion, ATV
公開鍵識別子(公共の_主要な_ID)=PKOID、PKOI、PK_拡張、ATV
Where:
どこ:
Public Key Organization Identifier (PKOID) = 8-bit serial number
identifier of Public Key Organization (PKO) that created the
Public Key.
公共のKey Organization Identifier(PKOID)はPublic Keyを作成したPublic Key Organization(PKO)の8ビットの通し番号識別子と等しいです。
Public Key Organization Index (PKOI) = 8-bit serial number used at
PKO discretion to distinguish different public/private key
pairs.
公共のKey Organization Index(PKOI)は異なった公衆/秘密鍵組を区別するのにPKO裁量に使用される8ビットの通し番号と等しいです。
PK_Expansion = 8-bit field to enable possible expansion of PKOID
or PKOI fields. (Note: Default value = 0xFF)
PK_Expansionは、PKOIDかPKOI分野の可能な拡張を可能にするために8ビットの分野と等しいです。 (注意: デフォルト値=0xFF)
Algorithm Type and Version (ATV) = 4-bit identifier of the
algorithm used.
アルゴリズムTypeとバージョン(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ビットのPublic Key Identifierと4ビットのDMUVと共に、総MIP_Key_Dataペイロードは132バイト長です。
4.6. RSA Key Management
4.6. RSA Key Management
The wireless service provider or carrier MUST generate the RSA Public/Private key pair(s). An organization within the service provider MUST be designated by the service provider to generate, manage, protect, and distribute RSA Private keys (to the RADIUS AAA Server) and public keys (to the MN manufacturers) in support of the DMU procedure.
無線サービスプロバイダかキャリヤーが、RSA Public/秘密鍵が組であると生成しなければなりません。 サービスプロバイダーは、DMU手順を支持してRSA兵士のキー(RADIUS AAA Serverへの)と公開鍵(ミネソタのメーカーへの)を生成して、管理して、保護して、分配するためにサービスプロバイダーの中の組織を指定しなければなりません。
Each RSA public/private key pair, generated by the wireless carrier, MUST be assigned a unique Public Key Identifier in accordance with Section 9.
セクション9によると、無線電話会社によって生成されたそれぞれのRSA公衆/秘密鍵組にユニークなPublic Key Identifierを配属しなければなりません。
RSA Private keys MUST be protected from disclosure to unauthorized parties. The service provider organization with the responsibility of generating the RSA public/private key pairs MUST establish an RSA key management policy to protect the RSA Private (decryption) keys.
公開から権限のないパーティーまでRSA兵士のキーを保護しなければなりません。 RSA公衆/秘密鍵が組であると生成する責任があるサービスプロバイダー組織は、RSA兵士の(復号化)キーを保護するためにRSAかぎ管理方針を確立しなければなりません。
RSA public keys MAY be freely distributed to all MN manufacturers (along with the Public Key Identifier). Because one RSA public key
RSA公開鍵は自由にすべてのミネソタのメーカー(Public Key Identifierに伴う)に分配されるかもしれません。 1つのRSA公開鍵
Carroll & Quick Informational [Page 13] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[13ページ]のRFC4784ダイナミックなMIP
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.
100万MNsに分配されています、メール、フロッピーディスク、またはWebsiteを通してRSA公開鍵(そして、Public Key Identifier)をミネソタのメーカーに分配するのが許容できるということであることができます。 適した方法はそれぞれのミネソタのメーカー/OEMに送られたDMU Requirementsドキュメントで単にRSA公開鍵と関連Public Key Identifierを発行することです。
When public keys are distributed, the public keys MUST be protected against alteration. If an invalid public key is programmed into a terminal, the terminal may be denied service because DMU cannot be performed successfully.
公開鍵が分配されているとき、変更に対して公開鍵を保護しなければなりません。 無効の公開鍵が端末にプログラムされるなら、サービスは、首尾よくDMUを実行できないので、端末に対して否定されるかもしれません。
RSA Private keys MAY be loaded into the RADIUS AAA server manually. Access to the RADIUS AAA Server RSA Private keys MUST be restricted to authorized personnel only.
RSA兵士のキーは手動でRADIUS AAAサーバに積み込まれるかもしれません。 RADIUS AAA Server RSA兵士のキーへのアクセスを任命された者だけに制限しなければなりません。
The wireless service provider MAY accept RSA Private key(s) (and Public Key Identifier) from MN manufacturers that have preloaded MNs with manufacturer-generated RSA public keys.
無線サービスプロバイダはメーカーが発生しているRSA公開鍵でMNsをプレロードしたミネソタのメーカーからRSA兵士のキー(そして、Public Key Identifier)を受け入れるかもしれません。
4.7. RADIUS AAA Server
4.7. 半径AAAサーバ
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.
RADIUS AAA ServerはDMU MUSTサポートにDMU Procedureを使用しました。 AAA ServerはRSAが公開鍵暗号であることをサポートして、Public Key Identifierによって索引をつけられた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.
このドキュメントの範囲の外にミネソタのメーカーからのAAA ServerのRSA兵士のキーの配送があります。 しかしながら、暗号化されたメールか物理的な(メール)配送を通したRSAの兵士の主要な(s)配送はおそらく許容できます。
Access to the RADIUS AAA Server MUST be limited to authorized personnel only.
RADIUS AAA Serverへのアクセスを任命された者だけに制限しなければなりません。
The RADIUS AAA Server MUST support 1024-bit RSA decryption.
RADIUS AAA Serverは、1024年のビットのRSAが復号化であるとサポートしなければなりません。
The RADIUS AAA Server MUST maintain a database of RSA public/private key pair indexed by the Public Key Identifier.
RADIUS AAA ServerはPublic Key Identifierによって索引をつけられたRSA公衆/秘密鍵組のデータベースを維持しなければなりません。
The RADIUS AAA Server MUST support the RADIUS attributes specified in Section 8.
RADIUS AAA Serverは、RADIUSがセクション8で指定された属性であるとサポートしなければなりません。
The RADIUS AAA Server MUST support a subscriber-specific MIP Update State Field. When the MIP Update State Field is set to UPDATE KEYS (1), the RADIUS AAA Server MUST initiate the DMU procedure by including the MIP_Key_Request attribute in an Access Reject message sent to the PDSN. The MIP Update State Field MAY be set to UPDATE
RADIUS AAA Serverは加入者特有のMIP Update州Fieldをサポートしなければなりません。 MIP Update州FieldがUPDATE KEYS(1)に用意ができているとき、PDSNに送られたAccess RejectメッセージにMIP_Key_Request属性を含んでいることによって、RADIUS AAA ServerはDMU手順に着手しなければなりません。 MIP Update州FieldはUPDATEに用意ができるかもしれません。
Carroll & Quick Informational [Page 14] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[14ページ]のRFC4784ダイナミックなMIP
KEYS (1) by the service provider's Billing/Provisioning system based on IT policy. Upon verification of MN-AAA Authentication Extension using the decrypted MN_AAA key, the RADIUS AAA Server MUST set the MIP Update State Field to KEYS UPDATED (2). Upon verification of the MN-Authentication Extension on a subsequent RRQ/ARQ, the RADIUS AAA Server MUST set the MIP Update State Field to KEYS VALID (0).
IT政策のサービスプロバイダーのベースのBilling/食糧を供給するシステムによるキーズ(1)。 解読されたミネソタ_AAAキーを使用するミネソタ-AAA Authentication Extensionの検証のときに、RADIUS AAA ServerはMIP Update州FieldをKEYS UPDATED(2)に設定しなければなりません。 その後のRRQ/ARQにおけるミネソタ-認証Extensionの検証のときに、RADIUS AAA ServerはMIP Update州FieldをKEYS VALID(0)に設定しなければなりません。
Note that the inclusion of a vendor-specific attribute in the Access Reject message is not consistent with Section 5.44 of [4]. A RADIUS AAA server that supports DMU SHOULD NOT include a vendor-specific attribute if the corresponding Access Request message was not received from a DMU-compliant PDSN. This use of Access Reject is strongly discouraged for any future work based on this document. Future work should consider the use of Access-Challenge to carry this vendor-specific attribute.
Access Rejectメッセージでのベンダー特有の属性の包含が[4]のセクション5.44と一致していないことに注意してください。 対応するAccess RequestメッセージがDMU対応することのPDSNから受け取られなかったなら、DMU SHOULD NOTをサポートするRADIUS AAAサーバはベンダー特有の属性を含んでいます。 Access Rejectのこの使用はこのドキュメントに基づくどんな今後の活動のためにも強くお勧めできないです。 今後の活動は、Access-挑戦の使用がこのベンダー特有の属性を運ぶと考えるべきです。
The RADIUS AAA Server MUST maintain a MIP Update State Field, for each subscription, in one of three states (0 = KEYS VALID, 1 = UPDATE KEYS, 2 = KEYS UPDATED).
RADIUS AAA ServerはMIP Update州Fieldを維持しなければなりません、各購読のために、3つの州の1つで(0がKEYS VALIDと等しいです、1=UPDATE KEYS、2=KEYS UPDATED)。
The RADIUS AAA Server MUST decrypt the encrypted portion of the MIP_Key_Data payload using the appropriate RSA Private (decryption) key.
適切なRSA兵士の(復号化)キーを使用して、RADIUS AAA ServerはMIP_Key_Dataペイロードの暗号化された部分を解読しなければなりません。
The RADIUS AAA Server MUST check the MN_AAA Authentication Extension of the DMU RRQ using the decrypted MN_AAA key.
解読されたミネソタ_AAAキーを使用して、RADIUS AAA ServerはDMU RRQのミネソタ_AAA Authentication Extensionをチェックしなければなりません。
The RADIUS AAA Server MUST include the AAA_Authenticator in the Access Accept as a Vendor-Specific RADIUS Attribute.
RADIUS AAA ServerはVendor特有のRADIUS AttributeとしてAccess Acceptに_AAA Authenticatorを含まなければなりません。
The RADIUS AAA Server MUST support the MN_Authenticator options specified in Section 6.1.
RADIUS AAA Serverは、ミネソタがセクション6.1で指定された_Authenticatorオプションであるとサポートしなければなりません。
The RADIUS AAA Server MUST comply with DMU Procedure failure operation specified in Section 5.
RADIUS AAA Serverはセクション5で指定されるDMU Procedure失敗操作に応じなければなりません。
The RADIUS AAA Server MUST support manual hexadecimal entry of MN_AAA key, MN_HA key, and Simple IP CHAP key via the AAA GUI for each subscription.
RADIUS AAA Serverは各購読のためのAAA GUIを通して主要なミネソタ_AAAキー、ミネソタ_HAキー、およびSimple 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
RADIUS AAA Serverは、MIN/移動加入者識別番号(IMSI)を有効にするためにメカニズムを提供しなければなりません。 MIN/IMSI合法化が進行中とき、RADIUS AAA ServerはAAA購読記録/プロフィールでPDSNから送られたMIN/IMSIをMIN/IMSIと比べなければなりません。 MINsかIMSIsが合っていないなら、RADIUS AAA ServerはAccess RejectをPDSN/FAに送らなければなりません。 Access RejectはMIP Key Data要求を含んではいけません。
Carroll & Quick Informational [Page 15] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[15ページ]のRFC4784ダイナミックなMIP
When the "Ignore MN_Authenticator" bit is not set, the RADIUS AAA Server MUST check whether MN_AuthenticatorMN = MN_AuthenticatorAAA. If the MN_Authenticators do not match, the RADIUS AAA Server MUST send an Access Reject to the PDSN/FA. The Access Reject MUST NOT contain a MIP_Key_Data request.
噛み付かれた「ミネソタ_固有識別文字を無視してください」が設定されないとき、RADIUS AAA Serverは、ミネソタ_AuthenticatorMNがミネソタ_AuthenticatorAAAと等しいかどうかチェックしなければなりません。 ミネソタ_Authenticatorsが合っていないなら、RADIUS AAA ServerはAccess RejectをPDSN/FAに送らなければなりません。 Access RejectはDataが要求するMIP_Key_を含んではいけません。
The RADIUS AAA Server MUST include its PKOID (or another designated PKOID) in the MIP_Key_Request RADIUS Attribute.
RADIUS AAA ServerはMIP_Key_Request RADIUS Attributeに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 ServerはRADIUS AAA ServerでMIP_Key_Data RADIUS Attributeで送られたPKOIDを有効なPKOIDsのリストと比較しなければなりません。PKOIDが有効でないなら、RADIUS AAA Serverは「無効の公開鍵」ベライゾンWireless RADIUS Vendor Specific Attribute(VSA)とPDSNにAccess Rejectを送らなければなりません。 以下に注意してください。 異なったVendor識別子は同じ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.
Access Rejectメッセージでのベンダー特有の属性の包含が[4]のセクション5.44と一致していないことに注意してください。 対応するAccess RequestメッセージがDMU対応することのPDSNから受け取られなかったなら、DMU SHOULD NOTをサポートするRADIUS AAAサーバはベンダー特有の属性を含んでいます。 Access Rejectのこの使用はこのドキュメントに基づくどんな今後の活動のためにも強くお勧めできないです。 今後の活動は、Access-挑戦の使用がこのベンダー特有の属性を運ぶと考えるべきです。
The RADIUS AAA Server MUST support delivery of the MN-HA key using 3GPP2 RADIUS VSAs as specified in 3GPP2 X.S0011-005-C. The 3GPP2 VSAs used are the MN-HA Shared Key (Vendor-Type = 58) and MN-HA Security Parameter Index (SPI) (Vendor-Type = 57).
3GPP2X. S0011 005Cの指定されるとしての3GPP2 RADIUS VSAsを使用して、RADIUS AAA Serverはミネソタ-HAキーの配送をサポートしなければなりません。 使用される3GPP2 VSAsはミネソタ-HA Shared Key(ベンダータイプ=58)とミネソタ-HA Security Parameter Index(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.
(2)が述べるUPDATE KEYS(1)とKEYS UPDATEDが用意ができているとき、RADIUS AAA Server SHOULDは特定の加入者のためにcdma2000(R)アクセスNode(AN)からAccess Requestをいつも受け入れます。 KEYS VALID(0)状態では、通常、RADIUS AAA ServerはAccess Requestをチェックしなければなりません。
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 ServerがKEYS VALID状態にある間、RADIUS AAA ServerはAccess RequestをMIP_Key_Data RADIUS Attributeと共に拒絶しなければなりません、すなわち、AAAが求められていない主要なアップデートが起こるのを許容してはいけません。
4.8. MN (Handset or Modem)
4.8. ミネソタ(受話器かモデム)
The MN manufacturer MUST pre-load the Wireless Carrier RSA public key (and Public Key Identifier).
ミネソタのメーカーはWireless Carrier RSA公開鍵(そして、Public Key Identifier)をプレロードしなければなりません。
The MN manufacturer MUST pre-generate and pre-load the MN_Authenticator.
ミネソタのメーカーは、ミネソタ_Authenticatorをあらかじめ生成して、プレロードしなければなりません。
Carroll & Quick Informational [Page 16] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[16ページ]のRFC4784ダイナミックなMIP
The MN MUST support 1024-bit RSA Encryption using the pre-loaded RSA public key.
プレロードされたRSA公開鍵を使用して、ミネソタは1024年のビットのRSA Encryptionをサポートしなければなりません。
The MN MUST support MN_AAA, MN_HA, and CHAP random/pseudo-random key generation (in accordance with RFC 4086).
ミネソタは、_ミネソタのミネソタの_AAA、HA、およびCHAPが無作為の/擬似ランダムキー生成(RFC4086によると)であるとサポートしなければなりません。
The MN MUST support random/pseudo-random AAA_Authenticator and MN_Authenticator generation (in accordance with RFC 4086).
ミネソタは_無作為の/擬似ランダムAAA Authenticatorと_ミネソタAuthenticatorに世代(RFC4086によると)をサポートしなければなりません。
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.
ミネソタ受話器のパワーアップするかミネソタクライアントの発射のときに、ミネソタは、MIP_Key_Dataペイロードが計算されたかどうかチェックしなければなりません。 MIP_Key_Dataペイロードが全く存在していないなら、ミネソタは、MIP_Key_Dataペイロードを生成して、保存しなければなりません。 ミネソタは少なくとも1個のプレ発生しているMIP_Key_Dataペイロードを維持しなければなりません。
The MN MUST construct the MIP_Key_Data payload in accordance with Section 4.5.
セクション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).
ミネソタはMIP_Keyの_のRequestの組織ベライゾンWireless Vendor/特有のExtension(VSE)があるMIP Registration Reply(RRP)を受け取り次第DMU Procedureを開始しなければなりません。
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_を含むRRPを受け取り次第、Key_Request、ミネソタはMIP_Key_Requestで送られたPKOIDをチェックしなければなりません。 ミネソタにPKOIDに関連している公開鍵があるなら、その公開鍵を使用して、ミネソタは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.
ミネソタには、ミネソタが複数の公開鍵をサポートするなら、デフォルト公開鍵として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.
ミネソタは、ベライゾンWireless MIP_Key_Data VSE(または、別のOrganization特有の_MIP_Key Data VSE)をモバイルホームAuthentication Extensionの後に挿入しますが、ミネソタ-AAA Authentication Extensionの前で挿入しなければなりません。 また、MIP_Key_Data ExtensionもFA Challenge Extensionの後に見つけられていて、存在していなければなりません。
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.
以下に注意してください。 相互運用性に、拡大の注文は重要です。 RADIUS AAAサーバからAccess Acceptを受けた後に、FAはモバイルホームAuthenticatorの後のすべての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,
DMU Procedureの開始のときに、新たに発生している一時的なミネソタ_AAAとミネソタ_HAキーを使用して、ミネソタはMIP認証拡張子を計算しなければなりません。 _AAA Authenticator MIP Extensionを受け取り次第
Carroll & Quick Informational [Page 17] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[17ページ]のRFC4784ダイナミックなMIP
the MN MUST compare the AAA_AuthenticatorMN (sent in the encrypted MIP_Key_Data payload) with the AAA_AuthenticatorAAA (returned by the RADIUS AAA Server). If both values are the same, the MN MUST designate the temporary MN_AAA, MN_HA key, and the Simple IP CHAP key as permanent. The MN MUST set its MIP Update State field to KEYS VALID.
ミネソタはAAA_AuthenticatorMN(暗号化されたMIP_Key_Dataペイロードを送る)をAAA_AuthenticatorAAA(RADIUS AAA Serverによって返される)と比較しなければなりません。 両方の値が同じであるなら、ミネソタは_AAA、ミネソタ_HAキー、および永久的であるとして主要なSimple IP CHAPに一時的なミネソタを指定しなければなりません。 ミネソタはMIP Update州分野をKEYS VALIDに設定しなければなりません。
The MN MUST support reset (re-generation) of the MN_Authenticator by the MN user as specified in Section 6.2.
ミネソタは、リセットがセクション6.2の指定されるとしてのミネソタユーザがミネソタ_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.
ミネソタは、ミネソタユーザがミネソタ_Authenticatorを見るのを可能にしなければなりません。 セクション6.2における指定されるとしての8 10進数字番号としてミネソタ_Authenticator(24ビットの乱数)を表示しなければなりません。
The MN manufacturer MUST pre-load each MN with a unique random 24-bit MN_Authenticator.
ミネソタのメーカーはユニークな無作為の24ビットのミネソタ_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).
ミネソタ_Authenticatorのリセットのときに、新しいミネソタ_Authenticatorを使用して(ミネソタ_Authenticatorが再びミネソタユーザによって明らかにリセットされるまで)、ミネソタは、古いミネソタ_Authenticatorに基づくすべてのMIP_Key_Dataペイロードを削除して、_Key_Dataペイロードをすべてのその後のMIPに生成しなければなりません。
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.)
ミネソタはミネソタ_AAAや、ミネソタ_HAや、Simple IP CHAPキーなどのすべての暗号化キーのスライド式入力装置をサポートしなければなりません。 ミネソタは128ビットのキーの16進数字エントリーをサポートしなければなりません。 (以下に注意してください。 あるSimple IPデバイスはCHAPキーとしてパスワードのASCIIエントリーを可能にするだけです。 未来の装置がキーのためにすなわち、両方の能力、ASCIIをパスワードか16進に提供するのは、許容できます。 作者は強い暗号化キーの使用を推薦します。)
The MN MUST support the Verizon Wireless MIP Vendor/Organization- Specific Extensions specified in Section 9.
ミネソタは、ベライゾンWireless MIP Vendor/組織がセクション9で指定された特定のExtensionsであるとサポートしなければなりません。
The MN MUST update the RRQ Identification field when re-transmitting the same MIP_Key_Data in a new RRQ.
新しいRRQで同じMIP_Key_Dataを再送するとき、ミネソタはRRQ Identification分野をアップデートしなければなりません。
The MN MUST comply with the DMU Procedure failure operation specified in Section 5.
ミネソタはセクション5で指定されるDMU Procedure失敗操作に応じなければなりません。
The RSA public key MAY be stored in the MN flash memory as a constant while being updatable via software patch.
ソフトウェアパッチでアップデート可能な間、RSA公開鍵は定数としてミネソタフラッシュメモリで保存されるかもしれません。
Carroll & Quick Informational [Page 18] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[18ページ]のRFC4784ダイナミックなMIP
4.9. PDSN / Foreign Agent (FA)
4.9. PDSN/外国人のエージェント(ファ)
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 MUSTは、ベライゾンがセクション8で指定されたWireless RADIUS Vendor特有のAttributes(VSA)とセクション9で指定された組織ベライゾンWireless MIP Vendor/特有のExtensions(VSEs)であるとサポートします。
The PDSN MAY support the RADIUS VSAs specified in Section 8 and the MIP VSEs specified in Section 9 using another Organization identifier.
PDSN MAYはセクション8で指定されたRADIUS VSAsとセクション9で別のOrganization識別子を使用することで指定されたMIP VSEsをサポートします。
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を含むAccess Rejectを受け取り次第、PDSN MUSTはMIP_Key_Request VSEがあるミネソタにRRPを送ります。 PDSN MUSTはRRPエラーコード=89(ベンダーSpecific)を使用して、トランスミッションの後に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を含むAccess Rejectを受け取り次第、PDSN MUSTは_AAA Authenticator MIP VSEとRRPを送ります。 PDSN MUSTはRRPエラーコード=89(ベンダーSpecific)を使用して、トランスミッションの後に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.
Public Key Invalid VSAを含むAccess Rejectを受け取り次第、PDSN MUSTはPublic Key Invalid MIP VSEとRRPを送ります。 PDSN MUSTはRRPエラーコード=89(ベンダーSpecific)を使用して、トランスミッションの後に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.
Access Rejectメッセージでのベンダー特有の属性の包含が[4]のセクション5.44と一致していないことに注意してください。 DMU MUSTをサポートするPDSNはベンダー特有の属性を含むAccess Rejectメッセージを受け入れます。 Access Rejectのこの使用はこのドキュメントに基づくどんな今後の活動のためにも強くお勧めできないです。 今後の活動は、Access-挑戦の使用がこのベンダーの特定の属性を運ぶと考えるべきです。
Upon receipt of an RRQ with the MIP_Key_Data VSE, the PDSN MUST convert the RRQ to an ARQ with the MIP_Key_Data VSA. The PDSN MUST send the ARQ to the RADIUS AAA server.
MIP_Key_Data VSEとRRQを受け取り次第、PDSN MUSTはMIP_Key_Data VSAと共にRRQをARQに変換します。 PDSN MUSTはRADIUS AAAサーバにARQを送ります。
The PDSN/FA MUST comply with the DMU Procedure failure operation specified in Section 5.
PDSN/FA MUSTはセクション5で指定されるDMU Procedure失敗操作に応じます。
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 MUSTはAccess Reject MIP_Key_Update_Request VSAからのRequest MIP VSEがミネソタに送ったMIP_Key_のPKOIDを含んでいます。
Carroll & Quick Informational [Page 19] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[19ページ]のRFC4784ダイナミックなMIP
4.10. Home Agent (HA)
4.10. ホームのエージェント(ハ)
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 MUSTは、ベライゾンWireless MIP Vendor/組織がセクション9で指定された特定のExtensions(VSEs)であるとサポートします。 (注意: FAがモバイルホーム認証拡大の後にすべての拡大をはぐなら、HAはDMU MIP拡張子に遭遇しないかもしれません。)
The HA MAY support the MIP VSEs specified in Section 9 using another Organization identifier. (Note: the HA may not encounter a DMU MIP extension if the FA strips away all extensions after the Mobile-Home authentication extension.)
HA MAYはセクション9で別のOrganization識別子を使用することで指定されたMIP VSEsをサポートします。 (注意: FAがモバイルホーム認証拡大の後にすべての拡大をはぐなら、HAはDMU MIP拡張子に遭遇しないかもしれません。)
The HA MUST support delivery of the MN-HA key from the Home RADIUS AAA server using 3GPP2 RADIUS Vendor-Specific Attributes (VSA) as specified in 3GPP2 X.S0011-005-C. The 3GPP2 VSAs used are the MN-HA Shared Key (Vendor-Type = 58) and the MN-HA SPI (Vendor-Type = 57).
HA MUSTは、ホームRADIUS AAAサーバから3GPP2X. S0011 005Cの指定されるとしての3GPP2 RADIUS Vendor特有のAttributes(VSA)を使用することでミネソタ-HAキーの配送をサポートします。 使用される3GPP2 VSAsはミネソタ-HA Shared Key(ベンダータイプ=58)とミネソタ-HA SPI(ベンダータイプ=57)です。
4.11. DMU Procedure Network Flow
4.11. DMU手順ネットワーク流動
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.
このセクションがDynamicのモバイルIP Update手順プロセスにかかわるプロセス流動のフローチャートと詳述を中に提供する、-2000である、ネットワーク
Carroll & Quick Informational [Page 20] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[20ページ]のRFC4784ダイナミックなMIP
MN PDSN/FA AAAH
-- ------- ----
--------------------- | -------------------
| 1: RSA Public Key | | | RSA Private Key |
| Pre-loaded by | | | Pre-loaded by |
| Manufacturer | | | Service Provider |
--------------------- | -------------------
---------------------------------------------------------
| 2: MS/BS: IS-2000 Call Origination and Authentication |
| 3: MN/PDSN/FA: PPP Session Establishment |
---------------------------------------------------------
| 4: Registration Request (RRQ) | |
|--------------------------------->| 5: Access Request w/MSID
| |------------>|
| | --------------------
| | | 6: MIP Update State|
| | | is UPDATE KEYS |
| | --------------------
| 7: Access Reject with |
| MIP_Key_Update_Request |
| RADIUS Attribute |
| |<------------|
| 8: Registration Reply (RRP) | |
| with MIP_Key_Request MIP | |
| Vendor/organization-specific | |
| extension | |
|<---------------------------------| |
------------------- | |
| 9: MN generates | | |
| MIP_Key_Data | | |
| using temporary | | |
| MIP keys | | |
------------------- | |
| 10: RRQ with MIP_Key_Data | |
| Vendor/organization-specific extension |
|--------------------------------->| 11: Access Request
| | w/MSID
| | and MIP_Key_Data
| | RADIUS attribute
| |------------>|
Mn PDSN/ファAAAH--------- ---- --------------------- | ------------------- | 1: RSA公開鍵| | | RSA秘密鍵| | プレロードされます。| | | プレロードされます。| | メーカー| | | サービスプロバイダー| --------------------- | ------------------- --------------------------------------------------------- | 2: さん/BS: -2000である、呼び出し創作と認証| | 3: ミネソタ/PDSN/ファ: pppセッション設立| --------------------------------------------------------- | 4: 登録要求(RRQ)| | |--------------------------------->| 5: MSIDとのアクセス要求| |、-、-、-、-、-、-、-、-、-、-、--、>|、|、| -------------------- | | | 6: MIPアップデート状態| | | | UPDATE KEYSです。| | | -------------------- | 7: 廃棄物にアクセスします。| | MIPの_の主要な_アップデート_要求| | 半径属性| | | <、-、-、-、-、-、-、-、-、-、-、--、|、| 8: 登録回答(小売希望価格)| | | MIPの_の主要な_要求MIPと共に| | | 組織ベンダー/特有です。| | | 拡大| | |<---------------------------------| | ------------------- | | | 9: ミネソタは生成します。| | | | MIPの_の主要な_データ| | | | 使用一時的です。| | | | MIPキー| | | ------------------- | | | 10: MIPの_の主要な_データがあるRRQ| | | 組織ベンダー/特有の拡大| |--------------------------------->| 11: アクセス要求| | MSIDと共に| | そして、MIPの_の主要な_データ| | RADIUS属性| |、-、-、-、-、-、-、-、-、-、-、--、>|
Figure 4. DMU Procedure Flow (part 1)
図4。 DMU手順流動(第1部)
Carroll & Quick Informational [Page 21] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[21ページ]のRFC4784ダイナミックなMIP
MN PDSN/FA AAAH
-- ------- ----
| | |
| | -------------------
| | | 12: decrypt |
| | | MIP_Key_Data, |
| | | verify MN-AAA |
| | | authentication |
| | | extension, set |
| | | MIP Update State |
| | | = KEYS UPDATED |
| | -------------------
| 13: Access Reject with |
| AAA_Authenticator |
| RADIUS Attribute |
| |<------------|
| 14: Registration Reply (RRP) | |
| with AAA_Authenticator MIP | |
| Vendor/organization-specific | |
| extension | |
|<---------------------------------| |
---------------------- | |
| 15: verify | | |
| AAA_Authenticator, | | |
| store temporary | | |
| MIP keys as | | |
| permanent keys | | |
---------------------- | |
| 16: RRQ | |
|--------------------------------->| Access Request
| | w/MSID
| |------------>|
| | --------------------
| | | 17: verify MN-AAA |
| | | authentication |
| | | extension, set |
| | | MIP Update State |
| | | = KEYS VALID |
| | --------------------
| Access Accept |
| |<------------|
Mn PDSN/ファAAAH--------- ---- | | | | | ------------------- | | | 12: 解読します。| | | | MIPの_の主要な_データ| | | | ミネソタ-AAAについて確かめてください。| | | | 認証| | | | 拡大、セット| | | | MIPアップデート状態| | | | = アップデートされたキー| | | ------------------- | 13: 廃棄物にアクセスします。| | AAA_固有識別文字| | 半径属性| | | <、-、-、-、-、-、-、-、-、-、-、--、|、| 14: 登録回答(小売希望価格)| | | _AAA固有識別文字MIPと共に| | | 組織ベンダー/特有です。| | | 拡大| | |<---------------------------------| | ---------------------- | | | 15: 確かめます。| | | | AAA_固有識別文字| | | | 店一時的です。| | | | MIPキー| | | | 永久的なキー| | | ---------------------- | | | 16: RRQ| | |--------------------------------->| アクセス要求| | MSIDと共に| |、-、-、-、-、-、-、-、-、-、-、--、>|、|、| -------------------- | | | 17: ミネソタ-AAAについて確かめてください。| | | | 認証| | | | 拡大、セット| | | | MIPアップデート状態| | | | = キーズ有効です。| | | -------------------- | アクセスは受け入れます。| | | <、-、-、-、-、-、-、-、-、-、-、--、|
Figure 4. DMU Procedure Flow (part 2)
図4。 DMU手順流動(第2部)
Carroll & Quick Informational [Page 22] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[22ページ]のRFC4784ダイナミックなMIP
MN PDSN/FA AAAH HA
-- ------- ---- --
| | | |
| | 18. Registration Request (RRQ) |
| |-------------------------------->|
| | 19: Access Request |
| | |<-----------------|
| | | Access Accept |
| | | with MN-HA key |
| | |----------------->|
| | | -------------------
| | | | verify |
| | | | mobile-home |
| | | | authentication |
| | | | extension |
| | | -------------------
| | 20. Registration Reply (RRP) |
| |<--------------------------------|
| RRP | | |
|<--------------| | |
Mn PDSN/ファAAAH、ハ--------- ---- -- | | | | | | 18. 登録要求(RRQ)| | |-------------------------------->| | | 19: アクセス要求| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| アクセスは受け入れます。| | | | ミネソタ-HAキーで| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| ------------------- | | | | 確かめます。| | | | | 移動住宅| | | | | 認証| | | | | 拡大| | | | ------------------- | | 20. 登録回答(小売希望価格)| | |<--------------------------------| | 小売希望価格| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|
Figure 4. DMU Procedure Flow (part 3)
図4。 DMU手順流動(パート3)
Each step in the Figure 4 DMU Process is described as follows:
各ステップで、図4では、DMU Processは以下の通り説明されます:
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. RFC3447によると、それぞれのRSA公衆/秘密鍵組を生成しなければなりません。 クリエイターはそれぞれの公衆/秘密鍵組にユニークなPublic Key Identifier(PKOID)を配属しなければなりません。
If the service provider does not generate the public/private
key pair and deliver the RSA public key to the MN manufacturer
for pre-installation in the MN, the MN manufacturer MUST
generate the RSA public/private key pair (using a 1024-bit
modulus) and pre-load all MNs with the RSA public (encryption)
key. The MN manufacturer MUST distribute the RSA Private
(decryption) key, in a secure manner, to the appropriate
service provider.
サービスプロバイダーがミネソタでのプレインストールのために公衆/秘密鍵組を生成して、RSA公開鍵をミネソタのメーカーに提供しないなら、ミネソタのメーカーは、RSA公衆/秘密鍵組(1024年のビットの係数を使用する)を生成して、RSAの公共の(暗号化)キーですべてのMNsをプレロードしなければなりません。 ミネソタのメーカーは安全な方法で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ミネソタがA-キーとSSD、MSが呼び出し創作を開始して、それ自体を認証するcdma2000(R) 1Xと共に食糧を供給されたと仮定する、-2000である、ネットワーク -2000である、認証成功、BSは「認証された」MSID(例えば、MIN)をPDSNに送ります。
3. The MN and PDSN establish a PPP session.
3. ミネソタとPDSNはPPPセッションを確立します。
4. The MN sends a MIP Registration Request (RRQ) to the PDSN.
4. ミネソタはMIP Registration Request(RRQ)をPDSNに送ります。
Carroll & Quick Informational [Page 23] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[23ページ]のRFC4784ダイナミックなMIP
5. The PDSN converts the MIP RRQ into a RADIUS Access Request
(ARQ) message, includes the MSID in the ARQ, and forwards the
ARQ to the Home RADIUS AAA server.
5. PDSNはホームRADIUS AAAサーバにRADIUS Access Request(ARQ)メッセージにMIP RRQを変換して、ARQでMSIDを含めて、ARQを送ります。
6. The RADIUS AAA Server compares the authenticated MSID (sent
from the PDSN) with the MSID in its subscriber database
(associated with the NAI). If the AAA MIP Update State Field
is set to UPDATE KEYS (1), the RADIUS AAA Server rejects
Packet Data access and orders a MIP key update.
6. RADIUS AAA Serverは加入者データベース(NAIに関連している)で認証されたMSID(PDSNから、発信する)をMSIDと比較します。 AAA MIP Update州FieldがUPDATE KEYS(1)に用意ができているなら、RADIUS AAA ServerはPacket Dataアクセスを拒絶して、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 ServerはMIP_Key_Update_Request RADIUS VSAとPDSNにAccess Reject(コード=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 Registration Reply(RRP)にAccess Rejectを変換して、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. ミネソタはミネソタMIP Update州=UPDATE KEYSを設定します。 ミネソタにプレ発生していてあらかじめ暗号化されたMIP_Key_Dataペイロードが全くないなら、RFC4086によると、ミネソタはミネソタ_AAAキー、ミネソタ_HAキー、Chapキー、ミネソタ_Authenticator、およびAAA_Authenticatorを生成しなければなりません。 Public Key Identifierを除いて、プレロードされたRSA公共の(暗号化)キーを使用して、値であると生成されたすべてを暗号化しなければなりません。 _ミネソタAAATEMP Keyと_ミネソタHATEMP MUSTであると新たに生成されて、使用されて、現在のRRQのためにミネソタ-AAAとモバイルホームAuthentication Extensionsについて計算してください。 以下に注意してください。 ペイロードがそれぞれのミネソタのパワーアップするかアプリケーション開始の間、存在するかどうかチェックすることによって、ミネソタはMIP_Key_Dataペイロードをあらかじめ計算するかもしれません。
10. The MN sends the RRQ with MIP_Key_Data MIP VSE to the PDSN.
10. ミネソタは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をRADIUS ARQに変換して、ホームRADIUS AAA ServerにARQを送ります。MSIDはARQで含められています。
12. The RADIUS AAA Server compares the authenticated MSID (sent
from the PDSN) with the MSID in its subscriber database
(associated with the NAI). If MSIDPDSN = MSIDAAA, the RADIUS
AAA server, using the Public Key Identifier, determines the
appropriate RSA Private key and decrypts the encrypted portion
of the MIP_Key_Data payload. The RADIUS AAA Server verifies
the MN-AAA Authentication Extension Authenticator using the
decrypted MN_AAA key. If successful, the RADIUS AAA Server
updates the subscriber profile with the decrypted MN_AAA key,
MN_HA key, and CHAP key. The RADIUS AAA Server sets the AAA
MIP Update State Field to KEYS UPDATED (2).
12. RADIUS AAA Serverは加入者データベース(NAIに関連している)で認証されたMSID(PDSNから、発信する)をMSIDと比較します。 MSIDPDSNがMSIDAAAと等しいなら、RADIUS AAAサーバは、Public Key Identifierを使用して、適切なRSA兵士のキーを決定して、MIP_Key_Dataペイロードの暗号化された部分を解読します。 RADIUS AAA Serverは、解読されたミネソタ_AAAキーを使用することでミネソタ-AAA Authentication Extension Authenticatorについて確かめます。 うまくいくなら、RADIUS AAA Serverは解読されたミネソタ_AAAキー、ミネソタ_HAキー、およびCHAPキーで加入者プロフィールをアップデートします。 RADIUS AAA ServerはAAA MIP Update州FieldをKEYS UPDATED(2)に設定します。
Carroll & Quick Informational [Page 24] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[24ページ]のRFC4784ダイナミックなMIP
13. The RADIUS AAA Server sends an Access Reject with
AAA_Authenticator RADIUS VSA to the PDSN.
13. RADIUS AAA ServerはAAA_Authenticator RADIUS VSAとAccess Rejectを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と共にAccess RejectをMIP RRPに変換します。 小売希望価格コード=89(ベンダー特有の)。
15. If AAA_AuthenticatorMN = AAA_AuthenticatorAAA, the MN assigns
MN_AAATEMP to MN_AAA key and MN_HATEMP to MN_HA key (MN MIP
Update State = KEYS VALID). Otherwise, the MN discards the
temporary keys.
15. AAA_AuthenticatorMNがAAA_AuthenticatorAAAと等しいなら、ミネソタは_ミネソタ_AAAキーへのミネソタAAATEMPと_ミネソタ_HAキーへのミネソタHATEMPを割り当てます(ミネソタMIP Update州はKEYS VALIDと等しいです)。 さもなければ、ミネソタは一時的なキーを捨てます。
16. The MN initiates a new RRQ that is converted to an ARQ by the
PDSN and forwarded to the RADIUS AAA Server.
16. ミネソタはPDSNによってARQに変換されて、RADIUS AAA Serverに送られる新しいRRQを開始します。
17. The RADIUS AAA Server verifies the MN-AAA Authentication
Extension and sets the AAA MIP Update State Field to KEYS
VALID (0). The RADIUS AAA Server sends an Access Accept to
the PDSN/FA.
17. RADIUS AAA Serverはミネソタ-AAA Authentication Extensionについて確かめて、AAA MIP Update州FieldをKEYS VALID(0)に設定します。 RADIUS AAA ServerはAccess AcceptをPDSN/FAに送ります。
18. The PDSN/FA sends the RRQ to the Home Agent (HA).
18. PDSN/FAはホームのエージェント(HA)にRRQを送ります。
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 ServerにAccess Requestを送ります。RADIUS AAA Serverはミネソタ_HAキーでAccess AcceptをHAに送ります。 HAは、ミネソタ_HAキーを使用することでモバイルホームAuthentication Extensionについて確かめます。
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に送ります。(PDSN/FAはRRPをミネソタに送ります)。 小売希望価格コードは0(成功)と等しいです。
5. DMU Procedure Failure Operation
5. DMU手順失敗操作
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 retransmission、またはミネソタの失敗による中断を説明するためにDMU Procedureの丈夫さを改良するために、RADIUS AAA ServerはMIP Update州Fieldを維持しなければなりません、各購読のために、3つの州の1つで(0がKEYS VALIDと等しいです、1=UPDATE KEYS、2=KEYS UPDATED)。
Carroll & Quick Informational [Page 25] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[25ページ]のRFC4784ダイナミックなMIP
MN PDSN/FA AAAH HA
-- ------- ---- --
---------------- | ---------------- |
| MN state = | | | AAAH state = | |
| KEYS VALID | | | UPDATE KEYS | |
---------------- | ---------------- |
| (A) RRQ | | |
|-------------->| ARQ | |
| |------------->| |
| AR(Key_Update) | |
(B) RRP (Key_Update) |<-------------| |
|<--------------| | |
---------------- | | |
| MN state = | | | |
| UPDATE KEYS | | | |
---------------- | | |
| (C) RRQ (MIP_Key_Data) | |
|-------------->| ARQ (MIP_Key_Data) |
| |------------->| |
| | ---------------- |
| | | AAAH state = | |
| | | KEYS UPDATED | |
| | ---------------- |
| AR (AAA_Auth) | |
(D) RRP (AAA_Auth) |<-------------| |
|<--------------| | |
---------------- | | |
| MN state = | | | |
| KEYS VALID | | | |
---------------- | | |
| RRQ | | |
|-------------->| ARQ | |
| |------------->| |
| | ---------------- |
| | | AAAH state = | |
| | | KEYS VALID | |
| | ---------------- |
| | AA | |
| |<-------------| RRQ |
| |------------------------------->|
| | | ARQ |
| | |<----------------|
| | | AA |
| | |---------------->|
| | | RRP |
| | RRP |<----------------|
|<-----------------------------| |
Figure 5. DMU Failure Call Flow with MN and AAA States
Mn PDSN/ファAAAH、ハ--------- ---- -- ---------------- | ---------------- | | ミネソタ州=| | | AAAH状態=| | | キーズ有効です。| | | アップデートキー| | ---------------- | ---------------- | | (A) RRQ| | | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>| ARQ| | | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| AR(キー_アップデート)| | (B) 小売希望価格(キー_アップデート)| <、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| ---------------- | | | | ミネソタ州=| | | | | アップデートキー| | | | ---------------- | | | | (C) RRQ(MIPの_の主要な_データ)| | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>| ARQ(MIPの_の主要な_データ)| | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| ---------------- | | | | AAAH状態=| | | | | アップデートされたキー| | | | ---------------- | | AR(AAA_Auth)| | (D) 小売希望価格(AAA_Auth)| <、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| ---------------- | | | | ミネソタ州=| | | | | キーズ有効です。| | | | ---------------- | | | | RRQ| | | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>| ARQ| | | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| ---------------- | | | | AAAH状態=| | | | | キーズ有効です。| | | | ---------------- | | | AA| | | | <、-、-、-、-、-、-、-、-、-、-、-、--、| RRQ| | |------------------------------->| | | | ARQ| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| AA| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 小売希望価格| | | 小売希望価格| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |<-----------------------------| | 図5。 ミネソタとAAA州に従ったDMU失敗呼び出し流動
Carroll & Quick Informational [Page 26] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[26ページ]のRFC4784ダイナミックなMIP
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)が無くなるなら、ミネソタは(A)を再送します。 RADIUS AAAサーバは(A)を予想します。 AAAサーバがUPDATE KEYS状態にあるなら、RADIUS AAA ServerはMIP_Key_Update_Request VSAとARを送ります、そして、PDSN/FAは(B)を送ります。
2. If (B) is lost, the MN retransmits (A). The RADIUS AAA server
expects (C). If it receives (A), the RADIUS AAA Server sends
AR with MIP_Key_Update_Request VSA, and the PDSN/FA retransmits
(B).
2. (B)が無くなるなら、ミネソタは(A)を再送します。 RADIUS AAAサーバは(C)を予想します。 それが(A)を受けるなら、RADIUS AAA ServerはMIP_Key_Update_Request VSAとARを送ります、そして、PDSN/FAは(B)を再送します。
3. If (C) is lost, the mobile retransmits (C). The RADIUS AAA
server expects (C) and updates the MIP keys appropriately. The
RADIUS AAA server transitions to KEYS UPDATED and commits the
MIP_Key_Data. The RADIUS AAA Server sends the AR with
AAA_Authenticator VSA, and the PDSN/FA replies to the MN with
(D).
3. (C)が無くなるなら、モバイルは(C)を再送します。 RADIUS AAAサーバは、適切に(C)を予想して、MIPキーをアップデートします。 RADIUS AAAサーバは、KEYS UPDATEDに移行して、MIP_Key_Dataを遂行します。 RADIUS AAA ServerはAAA_Authenticator VSAとARを送ります、そして、PDSN/FAは(D)でミネソタに答えます。
4. If (D) is lost, the mobile retransmits (C) using the same key
data sent previously. The RADIUS AAA server expects (A) using
the same keys.
4. (D)が無くなるなら、モバイルは、(C) 以前に送られた同じ重要なデータを使用することで再送されます。 RADIUS AAAサーバは、同じキーを使用することで(A)を予想します。
a. If the RADIUS AAA server receives (C) with the same keys it
received previously, it retransmits the AR with
AAA_Authenticator VSA and the PDSN replies with (D),
containing the AAA_Authenticator.
a。 RADIUS AAAサーバがそれが以前に受けた同じキーで(C)を受けるなら、AAA_Authenticator VSAと(D)とのPDSN回答でARを再送します、_AAA Authenticatorを含んでいて。
b. If the RADIUS AAA server receives (C) with different keys
than it received previously, the RADIUS AAA Server sends AR
with MIP_Key_Update_Request VSA, the PDSN/FA retransmits
(B), and the RADIUS AAA server transitions to UPDATE KEYS.
b。 RADIUS AAAサーバが異なったキーで(C)を受けるなら、RADIUS AAA ServerはMIP_Key_Update_Request VSAと共にそれが以前に受けたよりARを送ります、そして、PDSN/FAは(B)を再送します、そして、RADIUS AAAサーバはUPDATE KEYSに移行します。
c. If the RADIUS AAA server receives (A), which fails
authentication using the keys sent in (C), the RADIUS AAA
Server sends AR with MIP_Key_Update_Request, the PDSN/FA
retransmits (B), and the RADIUS AAA server transitions to
UPDATE KEYS.
c。 RADIUS AAAサーバが(A)を受けるなら、キーを使用することでどれが認証に失敗するかが(C) RADIUS AAA ServerがMIP_Key_Update_RequestとARを送るのを送って、PDSN/FAは(B)、およびUPDATE KEYSへのRADIUS AAAサーバ変遷を再送します。
5. Once the PDSN/FA receives (A), forwards the ARQ to the RADIUS
AAA server, and the MN-AAA Authenticator is verified using the
MN_AAA key, the RADIUS AAA Server transitions to the KEYS VALID
state and the DMU process is complete.
5. いったんPDSN/FAがRADIUS AAAサーバに(A)を受けて、ARQを送って、ミネソタ-AAA Authenticatorがミネソタ_AAAキーを使用することで確かめられると、KEYS VALID状態とDMUプロセスへのRADIUS AAA Server変遷は完全です。
Carroll & Quick Informational [Page 27] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[27ページ]のRFC4784ダイナミックなMIP
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
-------------- --------------------->| キーズ有効です。|--------------- | Auth成功使用-------------- 必要性キー| | MIPの_の主要な_データ最新版| | | | Authは(無効のキー)に失敗しました。| | または、異なった_MIP_Key DataとRRQ| | --------------------------------- | | | | | | | vに対して---------------- --------------- | アップデートされたキー| | アップデートキー| ---------------- --------------- | ^ ^ | | | | | ------- --------------------------------- 同じ__Got MIP_Key Data MIP_Key DataとRRQ
Figure 6. RADIUS AAA Server DMU State Machine
図6。 半径AAAサーバDMU州のマシン
6. cdma2000(R) HRPD/1xEV-DO Support
6. cdma2000(R) HRPD/1xEVしているサポート
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 ProcedureがIP Layerに起こるので、DMU Procedureは、cdma2000(R) 1XかHRPD/1xEVしているネットワークでMIPが主要な分配であるとサポートします。 cdma2000(R) HRPD/1xEVしているネットワークがRadio Access Network(RAN)に認証を供給しないので、DMU Procedureは誤ったミネソタの攻撃により影響されやすいです(Cellular AuthenticationとVoice Encryption(CAVE)RAN認証があるcdma2000(R) 1Xネットワークより)。 この理由で、DMU Procedureには、ミネソタ_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サーバへのミネソタ_Authenticator配送のメソッドがあります、/最も効率的な最少押しつけがましい手順が、DMU Procedureの間、ミネソタが認証であるとサポートすることを決定するためにサービスプロバイダーに柔軟性を許容して。
6.1. RADIUS AAA Support
6.1. 半径AAAサポート
The RADIUS AAA server MUST support three MN_Authenticator options:
RADIUS AAAサーバは3つのミネソタ_Authenticatorオプションをサポートしなければなりません:
1. Ignore MN_Authenticator
1. ミネソタ_固有識別文字を無視してください。
Depending on other potential authentication/fraud prevention
options (outside the scope of the DMU Procedure), the RADIUS AAA
他の潜在的認証/詐欺防止オプション(DMU Procedureの範囲の外の)、RADIUS AAAによります。
Carroll & Quick Informational [Page 28] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[28ページ]のRFC4784ダイナミックなMIP
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.
サーバには、ミネソタ_Authenticatorを無視する能力がなければなりません。 例えば、RADIUS AAA ServerがMIP_Key_Dataペイロードを解読すると、AAA Serverは静かにミネソタ_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 Serverはミネソタ_AuthenticatorMN(暗号化されたMIP_Key_Dataペイロードで、配送する)をミネソタ_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 Procedureが完全になった後に、RADIUS AAA Serverは提供されたミネソタ_AuthenticatorMNを保存して、ミネソタ_AuthenticatorAAAの配送を待っています(Customer Care、対話的な声の応答(IVR)、またはある他の不特定のプロセスを通して)。 ミネソタ_AuthenticatorがいったんRADIUS AAA Serverに提供されると、AAAはミネソタ_AuthenticatorMN(暗号化されたMIP_Key_Dataペイロードで、配送する)をミネソタ_AuthenticatorAAAと比較しなければなりません。 Authenticatorsが合っているなら、RADIUS AAA ServerはMIPキーのアクセスと最終的なアップデートを認可します。
6.2. MN Support
6.2. Mnサポート
The Mobile Node (MN) MUST store the 24-bit MN_Authenticator.
モバイルNode(ミネソタ)は_24ビットのミネソタ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.
ミネソタは8 10進数字番号(受話器における液晶ディスプレーかモデムのためのGUIを通した)としてミネソタ_Authenticatorを表さなければなりません。 ミネソタが受話器の中に住んでいるなら、以下のキーパッド系列を使用して、ユーザはミネソタ_Authenticatorを表示するかもしれません: 「FCN+*+*+M+I+P+RCL。」 さもなければ、ミネソタはデバイスのGUIを通してミネソタ_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.
ミネソタには、ミネソタ_Authenticatorをリセットする能力がなければなりません。 言い換えれば、ミネソタは手当たりしだいに/疑似への能力にユーザコマンドのときに新しい24ビットのミネソタ_がAuthenticatorであると手当たりしだいに生成させなければなりません、RFC4086によると。 リセット機能は出荷/ストレージの間、ミネソタ_Authenticatorの可能な感染を緩和します。 ミネソタが受話器の中に住んでいるなら、以下のキーパッド系列を使用して、ユーザはミネソタ_Authenticatorをリセットするかもしれません: 「FCN+*+*+M+I+P+C+C+RCL。」 さもなければ、ミネソタはデバイスのGUIを通してミネソタ_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
ミネソタのメーカーはミネソタ_Authenticatorと共にミネソタをプレロードするかもしれません。 例えばミネソタ_Authenticator(8 10進数字表現)と共にミネソタ_Authenticatorをプレロードして、ステッカーを付けること。
Carroll & Quick Informational [Page 29] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[29ページ]のRFC4784ダイナミックなMIP
the MN (e.g., modem), the point-of-sale representative does not have to retrieve the MN_Authenticator from the MN interface.
ミネソタ(例えば、モデム)であり、店頭の代表はミネソタのインタフェースからミネソタ_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.
[任意の] ミネソタはミネソタ_Authenticator/MIP_Key_Data有効搭載量組の別々のプライマリの、そして、セカンダリの待ち行列を維持するかもしれません。 ミネソタユーザがプライマリミネソタ_Authenticatorをリセットするとき、ミネソタは、プライマリミネソタ_Authenticator(そして、どんな関連MIP_Key_Data有効搭載量も)を捨てて、プライマリミネソタ_Authenticator(そして、どんな関連MIP_Key_Data有効搭載量もプライマリ待ち行列に割り当てる)としてセカンダリ待ち行列でミネソタ_Authenticatorを割り当てます。 この特徴は、ユーザ/食料係がミネソタ_Authenticatorをリセットして、すぐにMIP_Key_Data有効搭載量プレ暗号化利点を失わないでDMU手順に着手するのを可能にします。 セカンダリ待ち行列からプライマリ待ち行列までのミネソタ_Authenticator転送のときに、ミネソタは、セカンダリ待ち行列のために新しいミネソタ_Authenticatorと関連MIP_Keyが_Data有効搭載量であると生成しなければなりません。 ミネソタはパワーアップするかアプリケーション開始のときに両方のプライマリの、そして、セカンダリのミネソタ_Authenticator/MIP_Key_Data有効搭載量待ち行列をチェックしなければなりません。 ミネソタは各待ち行列で少なくとも1ミネソタ_Authenticator/MIP_Key_Data有効搭載量組を維持しなければなりません。
6.3. Informative: MN_Authenticator Support
6.3. 有益: ミネソタ_固有識別文字サポート
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.
ミネソタ_Authenticatorを使用するミネソタの認証がミネソタ_AuthenticatorをRADIUS AAA Serverに提供する方法を決定する際に最大の柔軟性をサービスプロバイダーに与えます。このドキュメントの範囲の外にミネソタ_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.
しかしながら、ミネソタ_Authenticatorが、ミネソタがHRPD/1xEVしている環境で認証/詐欺防止であるとどうサポートするかもしれないかに関して何らかの文脈を提供するために、私たちは以下の可能な食糧を供給するシナリオについて説明します。
When a subscriber initially acquires their HRPD/1xEV-DO device and service, the point-of-sale representative records the subscription information into the billing/provision system via a computer terminal at the point-of-sale. The billing/provisioning system delivers certain information to the RADIUS AAA Server (e.g., NAI, MSID, Electronic Serial Number (ESN)) including the MN_Authenticator, which the point-of-sale representative retrieves via the MN device's display. In the case of a modem, the manufacturer may have pre- loaded the MN_Authenticator and placed a copy of the MN_Authenticator on a sticker attached to the modem. The point-of-sale representative simply copies the 8 decimal digit value of the MN_Authenticator into the customer profile. Once the MN is loaded with the proper NAI and powered-up, the MN initiates the DMU Procedure with the RADIUS AAA Server. The RADIUS AAA Server compares the MN-delivered MN_Authenticator with the billing-system-delivered MN_Authenticator. If the authenticators match, the RADIUS AAA Server updates the
加入者が初めは彼らのHRPD/1xEVしているデバイスとサービスを入手するとき、店頭の代表は店頭のコンピュータ端末を通して支払い/支給システムに購読情報を記録します。 ミネソタ_Authenticator(店頭の代表はミネソタデバイスのディスプレイで検索する)を含んでいて、支払い/食糧を供給するシステムはRADIUS AAA Server(例えば、NAI、MSID、Electronic Serial Number(ESN))に、ある情報を提供します。 モデムの場合では、メーカーは、ミネソタ_Authenticatorをあらかじめ積み込んで、ミネソタ_Authenticatorのコピーをモデムに取り付けられたステッカーに置いたかもしれません。 店頭の代表は単にミネソタ_Authenticatorの8 10進数字価値を顧客プロフィールにコピーします。 ミネソタがいったん適切なNAIと共にロードされていて動力付きに上がるようになると、ミネソタはRADIUS AAA Serverと共にDMU Procedureを開始します。RADIUS AAA Serverは_提供された支払いシステムミネソタAuthenticatorとミネソタによって提供されたミネソタ_Authenticatorを比較します。 固有識別文字マッチ、RADIUS AAA Serverアップデートです。
Carroll & Quick Informational [Page 30] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[30ページ]のRFC4784ダイナミックなMIP
subscriber profile with the delivered MIP keys and authorizes service. If the Post-Update option is enabled within the RADIUS AAA Server, the RADIUS AAA Server tentatively updates the subscription profile until it receives the MN_Authenticator via the billing/provision system.
加入者は、提供されたMIPと共にキーの輪郭を描いて、サービスを認可します。 ポスト-アップデートオプションがRADIUS AAA Serverの中で可能にされるなら、支払い/支給システムでミネソタ_Authenticatorを受けるまで、RADIUS AAA Serverは試験的に購読プロフィールをアップデートします。
As another option, the service provider MAY use an IVR system in which the HRPD/1xEV-DO subscriber calls a provisioning number and inputs the MN_Authenticator. The IVR system then delivers the MN_Authenticator to the RADIUS AAA Server for final validation and Packet Data Access.
別のオプションとして、サービスプロバイダーはHRPD/1xEVしている加入者が食糧を供給する番号と入力をミネソタ_Authenticatorと呼ぶIVRシステムを使用するかもしれません。 そしてIVRシステムは最終的な合法化とPacket Data Accessのためにミネソタ_AuthenticatorをRADIUS AAA Serverに提供します。
7. Security Considerations
7. セキュリティ問題
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 Procedureは、適切な主要な分配セキュリティを提供している間、MIPの主要な分配の効率を最大にするように設計されています。 以下は潜在的セキュリティの脆弱性とそれらの相対的なリスクの記述をDMU Procedureに供給します:
7.1. Cryptographic Key Generation by the MN
7.1. ミネソタによる暗号のキー生成
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.
ミネソタが適切にミネソタ_AAA、ミネソタ_HA、およびCHAPキーを生成するのに必要であるので、受け入れられた無作為の/擬似乱数世代手順によると、ミネソタは暗号のキー生成を実行しなければなりません。 ミネソタのメーカーはRFC4086[12]ガイドラインに従わなければなりません、そして、サービスプロバイダーSHOULDはメーカーが、許容できるキー生成が手順であると実装するのを確実にします。 予測できる暗号化キーの使用はMIPセキュリティに破壊的であるかもしれません。 しかしながら、ミネソタのメーカーが4086のガイドラインをRFCに付着させる限り、許容できる無作為の/擬似ランダムキー生成を使用しないリスクは最小限です。 その上、欠点が1つのキー生成特定されるなら、影響を最小にして、欠点はソフトウェアパッチで容易に修正可能に見えます。
7.2. Man-in-the-Middle Attack
7.2. 介入者攻撃
The DMU procedure is susceptible to a Man-in-the-Middle (MITM) attack; however, such an attack appears relatively complex and expensive. When Authentication and Key Agreement (AKA) is deployed within cdma2000(R) 1X, the MITM Attack will be eliminated. The risk of an MITM Attack is minimal due to required expertise, attack expense, and impending cdma2000(R) 1X mutual authentication protection. If a particular cdma2000(R) 1X network does not support A-key authentication, the MN_Authenticator MAY optionally be used.
DMU手順は中央のMan(MITM)攻撃に影響されやすいです。 しかしながら、そのような攻撃は比較的複雑で高価に見えます。 AuthenticationとKey Agreementであるときに、(AKA)はcdma2000(R) 1Xの中で配布されて、MITM Attackは排除されるでしょう。 MITM Attackのリスクは、必要な専門的技術と、攻撃費用と、cdma2000(R) 1Xの互いの認証保護を迫らせるので、最小限です。 特定のcdma2000(R) 1XネットワークがA主要な認証をサポートしないなら、ミネソタ_Authenticatorは任意に使用されるかもしれません。
Carroll & Quick Informational [Page 31] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[31ページ]のRFC4784ダイナミックなMIP
7.3. RSA Private Key Compromise
7.3. RSA秘密鍵感染
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兵士を保護するのは重要です。 ミネソタのメーカーがRSA公衆/秘密鍵組を生成しているなら、ミネソタのメーカーは適切なサービスプロバイダーに主要なRSA兵士の普及に関する十分な安全性手順/方針を確立しなければなりません。 分配されていて、RSA兵士は正統のcdma2000(R)サービスプロバイダーだけにSHOULDを合わせます。 サービスプロバイダーがそれら自身のRSA公衆/秘密鍵組を生成しているなら、サービスプロバイダーは公開から権限のないパーティーまで主要なRSA兵士を保護しなければなりません。
7.4. RSA Encryption
7.4. RSA暗号化
Several vulnerabilities have been identified in certain implementations of RSA; however, they do not appear applicable to the DMU Procedure.
いくつかの脆弱性がRSAのある実装で特定されました。 しかしながら、彼らはDMU Procedureに適切に見えません。
7.5. False Base Station/PDSN
7.5. 偽の基地局/PDSN
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.
ミネソタはサービスの誤ったBS否定(DOS)攻撃に対して保護されるように見えます、適切なRADIUS AAAサーバだけが_AAA Authenticatorを回収できるので。 誤った基地局攻撃を防ぐこのメソッドはネットワークがAAAと給仕システムの間で通信するセキュリティを仮定します、セクション7.9で議論するように。
7.6. cdma2000(R) 1X False MN
7.6. cdma2000(R) 1Xの誤ったミネソタ
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ネットワークが適切に誤ったミネソタに対して保護されているように見える、-2000である、チャレンジレスポンス認証。 DMUがセルドメインの外で使用されるなら、同等な認証手順が同じレベルのセキュリティに必要です。
7.7. HRPD/1xEV-DO False MN
7.7. HRPD/1xEV誤ったミネソタをしてください。
The 1xEV-DO RADIUS AAA Server MAY optionally authenticate the MN using the MN_Authenticator to prevent a fraudulent MN activation.
詐欺的なミネソタの起動を防ぐのにミネソタ_Authenticatorを使用して、1xEV-DO RADIUS AAA Serverは任意にミネソタを認証するかもしれません。
7.8. Key Lifetimes
7.8. 主要な生涯
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.
システムオペレーターはRADIUS AAAサーバを通してDMUによって分配されたキーの生涯を決定します。必要に応じてアップデートを開始することによって、ミネソタ_AAAとミネソタ_HAの主要な生涯を制御できます。
Carroll & Quick Informational [Page 32] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[32ページ]のRFC4784ダイナミックなMIP
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.
その上、ミネソタがDMUを開始できないので、DMUプロセスは偽の開始に対して保護されます。 これで、明白な生涯をミネソタに提供するのは「非-実行可能」になります、ミネソタが満了の後にキーを取り替えるために少しの行動も取ることができないので。
7.9. Network Message Security
7.9. ネットワークメッセージセキュリティ
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ホームのエージェントまで提供されたミネソタ-HAキーのセキュリティはそのようなキーを含むネットワークメッセージのために秘密性を必要とします。 ネットワークメッセージのためのセキュリティ要件の仕様は、オペレータの責任であり、このドキュメントの範囲の外にあります。 (同様の問題がShared Secret Dataの分配に適用されることに注意してください。)Shared Secret Dataは既にANSI-41ネットワークにおけるノードの間に伝えられます。
If DMU is used outside the domain of a cellular operator, RADIUS security features MAY be used, including the Request-Authenticator and Response-Authenticator fields defined in [4] and the Message- Authenticator attribute defined in [13].
DMUがセルオペレータのドメインの外で使用されるなら、RADIUSセキュリティ機能は使用されるかもしれません、[4]で定義されたRequest-固有識別文字とResponse-固有識別文字分野と[13]で定義されたMessage固有識別文字属性を含んでいて。
8. Verizon Wireless RADIUS Attributes
8. ベライゾンのワイヤレスの半径属性
Three new RADIUS Attributes are required to support the DMU Procedure and are specified as follows:
3新しいRADIUS AttributesがDMU Procedureをサポートするのが必要であり、以下の通り指定されます:
Type: 26 Length: >9 Verizon Wireless Enterprise/Vendor ID: 12951
以下をタイプしてください。 26の長さ: >9ベライゾンのワイヤレスのエンタープライズ/ベンダーID: 12951
MIP_Key_Update_Request: ----------------------
MIPの_の主要な_アップデート_は以下を要求します。 ----------------------
The Home RADIUS AAA Server includes this attribute to indicate that MIP key update is required.
ホームRADIUS AAA Serverは、MIPの主要なアップデートが必要であることを示すためにこの属性を含んでいます。
Vendor-Type = 1 Vendor-Length = 3 bytes Vendor-Value = PKOID of the RADIUS AAA Server
ベンダータイプはRADIUS AAA Serverの1つのVendor-長さの=の3バイトのVendor-値=PKOIDと等しいです。
MIP_Key_Data: ------------
MIPの_の主要な_データ: ------------
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.
暗号化されたミネソタ_AAAキー、ミネソタ_HAキー、CHAPキー、ミネソタ_Authenticator、およびAAA_Authenticatorを含む重要なデータペイロード。 また、このペイロードはPublic Key Identifierを含んでいます。
Vendor-Type = 2
Vendor-Length = 134 bytes
ベンダータイプは2のVendor-長さと= 134バイト等しいです。
Carroll & Quick Informational [Page 33] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[33ページ]のRFC4784ダイナミックなMIP
NOTE: Vendor-Length depends on the size of the RSA modulus. For
example, when RSA-512 is used, Vendor-Length = 70 bytes.
Vendor-Value = 128 byte RSA encryption payload (when 1024-bit RSA
used), which contains encrypted MN_AAA key, MN_HA key, CHAP
key, MN_Authenticator, and AAA_Authenticator.
The four (4) byte Public Key Identifier is concatenated to the
encrypted payload.
以下に注意してください。 ベンダー長さはRSA係数のサイズに依存します。 70例えば、RSA-512が使用されているときのVendor-長さ=バイト。 ベンダー値は128バイトのRSA暗号化ペイロード(使用されるいつの1024年のビットのRSA)と等しいか。(それは、暗号化されたミネソタ_AAAキー、ミネソタ_HAキー、CHAPキー、ミネソタ_Authenticator、およびAAA_Authenticatorを含みます)。 4(4)バイトPublic Key Identifierは暗号化されたペイロードに連結されます。
AAA_Authenticator: -----------------
AAA_固有識別文字: -----------------
The 64-bit AAA_Authenticator value decrypted by the Home RADIUS AAA Server.
ホームRADIUS AAA Serverによって解読された64ビットのAAA_Authenticator値。
Vendor-Type = 3
Vendor-Length = 10 bytes
Vendor-Value = decrypted AAA_Authenticator from Home RADIUS AAA
Server.
ベンダータイプはホームRADIUS AAA Serverから_3のVendor-長さの解読された=の10バイトのVendor-値=AAA Authenticatorと等しいです。
Public Key Invalid: ------------------
公開鍵病人: ------------------
The home RADIUS AAA Server includes this attribute to indicate that the public key used by the MN is not valid.
ホームRADIUS AAA Serverは、ミネソタによって使用された公開鍵が有効でないことを示すためにこの属性を含んでいます。
Vendor-Type = 4
Vendor-Length = 2 bytes
Vendor-Value = none.
4Vendorベンダータイプ=長さは2バイトのVendor-値=なにもと等しくはありません。
Note: An Organization may define RADIUS VSAs using its own Organization identifier.
以下に注意してください。 Organizationは、それ自身のOrganization識別子を使用することでRADIUS VSAsを定義するかもしれません。
9. Verizon Wireless Mobile IP Extensions
9. ベライゾンのワイヤレスのモバイルIP拡大
Three Verizon Wireless Mobile IP Vendor/Organization-Specific Extensions (VSEs) (RFC 3115), required to support the DMU Procedure, are specified as follows:
DMU Procedureをサポートしなければならなかった組織3のベライゾンのWirelessのモバイルIP Vendor/特有のExtensions(VSEs)(RFC3115)が以下の通り指定されます:
Type: 38 (CVSE-TYPE-NUMBER)
以下をタイプしてください。 38 (CVSE-形式数)
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).
ベライゾンのワイヤレスのベンダーID: 12951 (高位八重奏は0です、そして、下位の八重奏はネットワークバイトオーダーにおけるVendorのSMI Network Management兵士のエンタープライズCodeです、IANAによって定義されるように。)
Carroll & Quick Informational [Page 34] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[34ページ]のRFC4784ダイナミックなMIP
0 7 8 15 16 31
---------------------------------------------------
| Type | Reserved | Length |
---------------------------------------------------
| Vendor/Org-ID |
---------------------------------------------------
| Vendor-CVSE-Type | Vendor-CVSE-Value ... |
---------------------------------------------------
0 7 8 15 16 31 --------------------------------------------------- | タイプ| 予約されます。| 長さ| --------------------------------------------------- | Orgベンダー/ID| --------------------------------------------------- | ベンダーCVSEはタイプします。| ベンダーCVSE価値… | ---------------------------------------------------
Figure 7. Critical Vendor/Organization-Specific Extension
図7。 組織重要なベンダー/特有の拡大
MIP_Key_Request: ---------------
MIP_キー_は以下を要求します。 ---------------
The Home RADIUS AAA Server includes this extension to indicate that MIP key update is required.
ホームRADIUS AAA Serverは、MIPの主要なアップデートが必要であることを示すためにこの拡大を含んでいます。
Length = 7
長さ=7
NOTE: The RFC 3115 Editor has stated that the Reserved field is
not included in the length determination.
Vendor-CVSE-Type = 1
Vendor-CVSE-Value = PKOID sent in the RADIUS
MIP_Key_Update_Request attribute.
以下に注意してください。 RFC3115Editorは、Reserved分野が長さの決断に含まれていないと述べました。 1つのVendor-CVSE-値のベンダーCVSEがタイプしている==PKOIDはRADIUS MIP_Key_Update_Request属性を送りました。
MIP_Key_Data: ------------
MIPの_の主要な_データ: ------------
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.
重要なデータペイロード含有はミネソタ_AAAキー、ミネソタ_HAキー、CHAPキー、ミネソタ_Authenticator、およびAAA_Authenticatorを暗号化しました。 また、このペイロードはPublic Key Identifierを含んでいます。
Length = 138
NOTE: Length depends on the size of the RSA modulus. For example,
when RSA-512 is used, Length = 74 bytes.
Vendor-CVSE-Type = 2
Vendor-CVSE-Value = 128 byte RSA encryption payload (when 1024-bit
RSA used) which contains encrypted MN_AAA key, MN_HA key, CHAP
key, MN_Authenticator, and AAA_Authenticator.
The four (4) byte Public Key Identifier and DMUV is concatenated
to the encrypted payload.
長さは138注意と等しいです: 長さはRSA係数のサイズに依存します。 74例えば、RSA-512が使用されているときのLength=バイト。 ベンダーCVSEタイプは暗号化されたミネソタ_AAAキー、ミネソタ_HAキー、CHAPキー、ミネソタ_Authenticator、およびAAA_Authenticatorを含む128Vendor-CVSE-値=バイトの2RSA暗号化ペイロード(使用されるいつの1024年のビットのRSA)と等しいか。 4(4)バイトのPublic Key IdentifierとDMUVは暗号化されたペイロードに連結されます。
AAA_Authenticator: -----------------
AAA_固有識別文字: -----------------
The 64-bit AAA_Authenticator value decrypted by the Home RADIUS AAA Server.
ホームRADIUS AAA Serverによって解読された64ビットのAAA_Authenticator値。
Carroll & Quick Informational [Page 35] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[35ページ]のRFC4784ダイナミックなMIP
Length = 14 bytes
Vendor-CVSE-Type = 3
Vendor-CVSE-Value = decrypted AAA_Authenticator from the Home
RADIUS AAA Server.
長さの=の14バイトのVendor-CVSE-タイプは=がホームRADIUS AAA ServerからAAA_Authenticatorを解読した3Vendor-CVSE-値と等しいです。
Public Key Invalid: ------------------
公開鍵病人: ------------------
The Home RADIUS AAA Server includes this extension to indicate that the public key used by the MN is not valid.
ホームRADIUS AAA Serverは、ミネソタによって使用された公開鍵が有効でないことを示すためにこの拡大を含んでいます。
Length = 6 bytes
Vendor-CVSE-Type = 4
Vendor-CVSE-Value = none.
6長さ=バイトのVendor-CVSE-タイプは4Vendor-CVSE-値=なにもと等しくはありません。
Note: An Organization may define VSEs using their own Organization identifier.
以下に注意してください。 Organizationは、それら自身のOrganization識別子を使用することでVSEsを定義するかもしれません。
10. Public Key Identifier and DMU Version
10. 公開鍵識別子とDMUバージョン
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.
Public Key Identifier(パブ_Key_ID)は、RADIUS AAA Serverが異なった公開鍵(異なったメーカー、サービスプロバイダー、または他の組織によって割り当てられるかもしれない)を見分けるのを許容するのにDynamicのモバイルIP Update(DMU)手順の間、使用されます。 Public Key IdentifierはPKOID、PKOI、PK_Identifier、およびATV分野から成ります。 DMUバージョン分野はDMU手順のその後の改正を可能にします。
----------------------------------------------
| PKOID | PKOI | PK_Expansion | ATV | DMUV |
----------------------------------------------
0 7 8 15 16 23 24 27 28 31
---------------------------------------------- | PKOID| PKOI| PK_拡張| ATV| DMUV| ---------------------------------------------- 0 7 8 15 16 23 24 27 28 31
Figure 8. Public Key Identifier and DMUV
エイト環。 公開鍵識別子と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).
RADIUS AAA Serverが異なったPKOによって作成された異なった公開鍵を見分けるのを可能にするために、各Public Key Organization(PKO)にPublic Key Organization Identifier(PKOID)を割り当てなければなりません(Table1を見てください)。
If a service provider does not provide the MN manufacturer with a (RSA) public key, the manufacturer MUST generate a unique RSA Public/Private key pair and pre-load each MN with the RSA public key (1024-bit modulus by default). The manufacturer MAY share the same RSA Private key with multiple service providers as long as reasonable security procedures are established and maintained (by the manufacturer) to prevent disclosure of the RSA Private (decryption) key to an unauthorized party.
サービスプロバイダーが(RSA)公開鍵をミネソタのメーカーに提供しないなら、メーカーがユニークなRSA Public/秘密鍵組を生成して、RSA公開鍵で各ミネソタをプレロードしなければならない、(1024年のビットの係数、デフォルトで) 妥当なセキュリティ手順が権限のないパーティーのRSA兵士の(復号化)キーの公開を防ぐために確立されて、維持される(メーカーで)限り、メーカーは複数のサービスプロバイダーによって主要な同じRSA兵士を共有するかもしれません。
Carroll & Quick Informational [Page 36] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[36ページ]のRFC4784ダイナミックなMIP
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.
Public Key Organization Index(PKOI)は値がPKOの裁量で定義される8ビットの分野です。 組が創設されるとき、例えば、装置製造業者はそれぞれのPublic/秘密鍵組のために新しいPKOIを増加して割り当てるかもしれません。
The PK_Expansion field enables support for additional PKOs or expansion of the PKOI.
PK_Expansion分野はPKOIの追加PKOか拡張のサポートを可能にします。
The DMU Version field allows for DMU Procedure version identification (see Table 2).
DMUバージョン分野はDMU Procedureバージョン識別を考慮します(Table2を見てください)。
The Algorithm Type and Version (ATV) field allows for identification of the public key algorithm and version used (see Table 3).
Algorithm Typeとバージョン(ATV)分野は使用される公開鍵アルゴリズムとバージョンの識別を考慮します(Table3を見てください)。
Carroll & Quick Informational [Page 37] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[37ページ]のRFC4784ダイナミックなMIP
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公開鍵PKOID公開鍵(十六進法)組織(PKO)(十六進法)組織(PKO)----- ------------------ ----- ------------------ 00が疾駆してコミュニケーションInc.06予約された46肥沃の女神技術Inc.07予約されていた状態で41のアメリカの予約された鋭い研究所02の40Sanyo漁夫会社01予約された42連峰ワイヤレスのInc.03予約された43ソニーのエレクトロニクスの04の予約された44Synertek Inc.05予約された45を予約した、47WherifyワイヤレスのInc; 08 予約された48Airbiquity09は49のワイヤレスのArrayComm 0Aの4A Celletra株式会社0B AAPT株式会社4B CIBERNETベライゾン社0のCオールテルコミュニケーション4C CommWorks社を予約しました、ETRI0のFベルサウスの国際4Eの3Com会社0Dアンゴラテレコム4Dコンパックコンピュータ社0のEベルの移動性4F GlenayreエレクトロニクスInc; 10 中国ユニカム50GTRAN Inc.11KDDI社51のLogica12ヒマチャル未来の52LSIロジックコミュニケーション株式会社13ハチソンテレコム(HK)、53Metapathのソフトウェアの株式会社の国際Inc.14IUSACELL54Metawaveコミュニケーション15Komunikasi Selular55Openwaveシステム株式会社インドネシア(Komselindo)16韓国テレコムFreetel、56ParkerVision Inc.Inc.17飛躍57クアルコムInc.18LGテレコムLtd.58Q株式会社(MTNL)電気通信Transmission、三井(リット)1AネクステルCommunications、5A Schema Ltd.株式会社1B Operadora UNEFON SA de CV 5B SchlumbergerSema1のCの太平洋のバングラデシュ5C ScoreBoard Inc.テレコム株式会社1DペガソPCSのuickSilver Technologies19Mahanagar Telephoneニガム59Research Institute、S.A.DE C.V.5D SignalSoft社
Carroll & Quick Informational [Page 38] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[38ページ]のRFC4784ダイナミックなMIP
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公開鍵PKOID公開鍵(十六進法)組織(PKO)(十六進法)組織(PKO)----- ------------------ ----- ------------------ 29 米国のセル69Spirentコミュニケーション2A 3Gセル6A Willtech Inc.2Bカエデコミュニケーションと6Bのワイヤレスのテスト・システムマルチメディアInc.2C AirPrime Inc.6C Airvana Inc.2Dアルパイン株式会社6D COM DEVワイヤレス2E Audiovoxコミュニケーション6EコンドゥクトゥスInc; 社2のFデンソーワイヤレス6F GlenayreエレクトロニクスInc.30Ditrans社70の日立テレコム(米国)Inc.31富士通ネットワーク71ヒュンダイSyscomm株式会社コミュニケーションInc.32Gemplus社72のISCO33ギガテレコムInc.73LG Electronics, Inc.34ヒュンダイ CURITEL Inc.74LinkAirコミュニケーションInc.35InnovICs Corp75ルーセントテクノロジーズInc.36京セラ社76のモトローラCIG37LG Electronics, Inc.77ノーテルが38のLinkAirコミュニケーションをネットワークでつないで、78のリピータ技術の株式会社39モトローラ79三星電子3Aノキア社の7A Starentネットワークの3B NovatelのワイヤレスのInc.7Bタホが疾駆してInc.3C OKIネットワーク技術を7Cネットワークでつなぐ、コミュニケーションInc.
Carroll & Quick Informational [Page 39] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[39ページ]のRFC4784ダイナミックなMIP
PKOID Public Key PKOID Public Key
(HEX) Organization (PKO) (HEX) Organization (PKO)
----- ------------------ ----- ------------------
3D Pixo 7D WaterCove Networks
3E Research In Motion 7E Winphoria Networks, Inc.
3F Samsung Electronics 7F ZTE Corporation
Co., Ltd.
PKOID公開鍵PKOID公開鍵(十六進法)組織(PKO)(十六進法)組織(PKO)----- ------------------ ----- ------------------ 3D Pixo 7D WaterCoveはE WinphoriaがInc.3F三星電子7F ZTE社株式会社をネットワークでつなぐという動き7における3ユーロの研究をネットワークでつなぎます。
Note: 80 through FF will be assigned by the PKOID administrator (Verizion Wireless).
以下に注意してください。 FFを通した80はPKOID管理者(Verizion Wireless)によって割り当てられるでしょう。
Table 2. DMU Version
2を見送ってください。 DMUバージョン
DMU Version DMU Version
Value
----------- -----------
00 RFC 4784
01 Reserved
02 Reserved
03 Reserved
04 Reserved
05 Reserved
06 Reserved
07 Cleartext Mode
DMUバージョンDMUバージョン価値----------- ----------- 00 RFC4784 01は予約された予約された予約された02の予約された06予約された07Cleartext03 04 05モードを予約しました。
Table 3. Algorithm Type and Version
3を見送ってください。 アルゴリズムタイプとバージョン
ATV Public Key Algorithm
Value Type and Version
----- --------------------
00 Reserved
01 RSA - 1024
02 RSA - 768
03 RSA - 2048
04 Reserved
05 Reserved
06 Reserved
07 Reserved
ATV公開鍵アルゴリズム値のタイプとバージョン----- -------------------- 00は01RSA--1024 02RSA--768 03RSAを予約しました--2048 04が予約された06が予約した05を予約した、07は予約しました。
11. Conclusion
11. 結論
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.
DynamicのモバイルIP Key Update(DMU)手順は重要なモバイルIP暗号化キーの効率的で、しかし、安全な配送を可能にします。 暗号化キー(そして、したがって、DMU Procedureを使用するそのようなMIPキーのブートストラップ法)の使用はcdma2000 1xRTTとHRPD/1xEVしているネットワークかモバイルIPを利用する他のネットワークにおける、モバイルIPサービスの商業配送に不可欠です。
Carroll & Quick Informational [Page 40] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[40ページ]のRFC4784ダイナミックなMIP
12. Normative References
12. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
13. Informative References
13. 有益な参照
[2] TIA/EIA/IS-2000 Series, Revision A, Telecommunications Industry
Association, March 2000.
[2] TIA/EIA/、-2000である、シリーズ(改正A、電気通信産業連盟)は2000に行進します。
[3] TIA/EIA/IS-856, cdma2000(R) High Rate Packet Data Air Interface
Specification, Telecommunications Industry Association, November
2000.
[3] TIA/EIA/、-856である、cdma2000(R)高い率パケットデータ空気インターフェース仕様、電気通信産業連盟、11月2000
[4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[4]Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[5] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
[6] TIA/EIA/IS-835-A, cdma2000(R) Wireless IP Network Standard,
Telecommunications Industry Association, May 2001.
[6] TIA/EIA/、-、835-A、cdma2000(R)のワイヤレスのIPネットワーク規格、電気通信産業連盟、5月2001
[7] ANSI/TIA/EIA-41-D-97, Cellular Radiotelecommunications
Intersystem Operations, Telecommunications Industry Association,
December 1997
[7]ANSI/TIA/EIA-41-D-97、セルRadiotelecommunications項間操作、電気通信産業連盟、1997年12月
[8] ANSI/TIA/EIA-683-B-2001, Over-the-Air Service Provisioning of
Mobile Stations in Spread Spectrum Systems, Telecommunications
Industry Association, December 2001
[8] ANSI/TIA/EIA-683-B-2001、過剰、航空便、食糧を供給するスペクトル拡散方式の移動局、電気通信産業連盟、2001年12月を。
[9] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
(PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
3447, February 2003.
[9] イェンソン、J.、およびB.Kaliski、「公開鍵暗号化標準(PKCS)#1:」 RSA暗号仕様バージョン2.1インチ、RFC3447、2月2003日
[10] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization-
Specific Extensions", RFC 3115, April 2001.
[10]DommetyとG.とK.レオン、「モバイルIPベンダー/組織の特定の拡大」、RFC3115、2001年4月。
[11] TIA-2001-A, Interoperability Specifications (IOS) for
cdma2000(R) Access Network Interfaces, Telecommunications
Industry Association, August 2001.
[11] TIA-2001-A、cdma2000(R)のための相互運用性仕様(IOS)が2001年8月にネットワーク・インターフェース、電気通信産業連盟にアクセスします。
[12] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[12] イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[13] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions",
RFC 2869, June 2000.
[13]RigneyとC.とWillats、W.とP.カルフーン、「半径拡大」、RFC2869、2000年6月。
Carroll & Quick Informational [Page 41] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[41ページ]のRFC4784ダイナミックなMIP
14. Acknowledgments
14. 承認
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.
ガブリエラAmbramovici、セミヨンMizikovsky、ジェフリー・ダイク(クアルコム)、ジェームス・ウィルキー(クアルコム)、Jayanth Mandayam(クアルコム)、マルチェロLioy(クアルコム)、マイケルBorella(CommWorks)、クリフ・ランドル(CommWorks)、ダニエルカッシネルリ(CommWorks)エドワード・ダン(CommWorks)、Suresh Sarvepalli(CommWorks)をありがとうございます(透明な)(透明な); 彼らの役に立つ議論とコメントのためのシャールバールパテル(透明な)、ピーター・マッキャン(透明な)、Ganapathy Sundaram(透明な)、Girishパテル(ノーテル)、Glen Baxley(ノーテル)、ダイアントンプソン(エリクソン)、ブライアンヒックマン(エリクソン)Somsay Sychaleun(ブリッジウォーター)、Parmサンデュー(連峰Wireless)、イウリアンMucano(連峰Wireless)、およびSamy Touati(エリクソン)。
Carroll & Quick Informational [Page 42] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[42ページ]のRFC4784ダイナミックなMIP
Appendix A: Cleartext-Mode Operation
付録A: Cleartext-モード操作
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のためにcleartextがモードであるとサポートします。 まるでRSAの1024年のビットの暗号化がペイロードに適用されるかのようにMIP_Key_Dataペイロードは同じサイズを仮定するでしょう。 それぞれこのモード、_Data RADIUS AttributeとMIP Vendor Specific ExtensionがそうするMIP_Keyでは長さ134バイトと138バイトになってください。 したがって、cleartextモードで、ペイロードは48バイトのキー(ミネソタ_AAA、ミネソタ_HA、およびCHAPキー)(8バイトのAAA_Authenticator、3バイトのミネソタ_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=ミネソタ_AAAH主要で、主要なミネソタ_HA CHAP_主要なミネソタ_Authenticator、AAA_Authenticator、Padding(69バイト)、Public_Key_IDi、DMUV
Where:
どこ:
MN_AAA key = 128-bit random MN / RADIUS AAA Server key.
ミネソタ_AAAキーは128ビットの無作為のミネソタ/RADIUS AAA Serverキーと等しいです。
MN_HA key = 128-bit random MN / Home Agent (HA) key.
ミネソタ_HAキーは128ビットの無作為のミネソタ/ホームのエージェント(HA)キーと等しいです。
CHAP_key = 128-bit random Simple IP authentication key.
CHAP_キーは128ビットの無作為のSimple IP認証キーと等しいです。
MN_Authenticator = 24-bit random number.
ミネソタ_Authenticatorは24ビットの乱数と等しいです。
AAA_Authenticator = 64-bit random number used by MN to
authenticate the RADIUS AAA Server.
AAA_AuthenticatorはRADIUS AAA Serverを認証するのにミネソタによって使用された64ビットの乱数と等しいです。
Padding = 69 bytes of 0's.
0の=69バイトを水増しします。
DMU Version (DMUV) = 4-bit identifier of DMU version.
DMUバージョン(DMUV)はDMUバージョンの4ビットの識別子と等しいです。
Public Key Identifier (Pub _Key_ID) = PKOID, PKOI, PK_Expansion, ATV
公開鍵識別子(パブの_の主要な_ID)=PKOID、PKOI、PK_拡張、ATV
Where:
どこ:
Public Key Organization Identifier (PKOID) = 8-bit serial number
identifier of the Public Key Organization (PKO) that created
the Public Key.
公共のKey Organization Identifier(PKOID)はPublic Keyを作成したPublic Key Organization(PKO)の8ビットの通し番号識別子と等しいです。
Public Key Organization Index (PKOI) = 8-bit serial number used at
PKO discretion to distinguish different Public/Private key
pairs.
公共のKey Organization Index(PKOI)は異なったPublic/秘密鍵組を区別するのにPKO裁量に使用される8ビットの通し番号と等しいです。
PK_Expansion = 8-bit field to enable possible expansion of PKOID
or PKOI fields. (Note: Default value = 0xFF)
PK_Expansionは、PKOIDかPKOI分野の可能な拡張を可能にするために8ビットの分野と等しいです。 (注意: デフォルト値=0xFF)
Algorithm Type and Version (ATV) = 4-bit identifier of the
algorithm used.
アルゴリズムTypeとバージョン(ATV)は使用されるアルゴリズムの4ビットの識別子と等しいです。
Carroll & Quick Informational [Page 43] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[43ページ]のRFC4784ダイナミックなMIP
Authors' Addresses
作者のアドレス
Christopher Carroll* Ropes & Gray LLP Fish & Neave IP Group One International Place Boston, MA 02110
クリストファーキャロル*Ropes、グレーLLP Fish、およびニーブIPはボストン、1つの国際Place MA 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.
* ベライゾンWirelessにある間、このドキュメントは開発されました。
Frank Quick Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
フランク・迅速なクアルコム法人組織の5775モアハウス・Driveカリフォルニア92121サンディエゴ(米国)
Phone: 858-658-3608 EMail: fquick@qualcomm.com
以下に電話をしてください。 858-658-3608 メールしてください: fquick@qualcomm.com
Carroll & Quick Informational [Page 44] RFC 4784 Dynamic MIP Key Update June 2007
アップデート2007年6月に主要なキャロルと迅速な情報[44ページ]のRFC4784ダイナミックなMIP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78と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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Carroll & Quick Informational [Page 45]
キャロルとクィックInformationalです。[45ページ]
一覧
スポンサーリンク
