- Cisco Mobile Wireless Home Agent の概 要
- Home Agent（HA）の設定プランニング
- 単一 IP インフラストラクチャ
- HA でのホーム アドレス割り当て
- ユーザ認証および認可
- HA の冗長性
- HA でのロード バランシングの設定
- IP 登録の終了
- ダイナミック ドメイン ネーム サーバ（DNS） アップデート
- ユーザ単位パケット フィルタリング
- HA のセキュリティ
- HA のアカウンティング
- Home Agent（HA）でのマルチ VPN ルー ティングおよびフォワーディング（VRF）
- Home Agent（HA）の サービス品質（QoS）
- ユーザ トラフィックのモニタリング
- その他の設定作業
- Home Agent のネットワーク管理、管理情報 ベース（MIB）、および簡易ネットワーク管理 プロトコル（SNMP）
- 用語集
Cisco Mobile Wireless Home Agent リリース 5.2 for Cisco IOS リリース 12.4(22)YD2
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月11日
章のタイトル： ユーザ認証および認可
ユーザ認証および認可
この章では、ユーザ認証および認可について、さらに Cisco Mobile Wireless Home Agent でこの機能を設定する方法について説明します。
•
「Mobile-Home Authentication Extension（MHAE）を持たない 3GPP2 登録要求（RRQ）」
• 「ローカル MN-HA SPI および Key を使用した NAI 認証」
ユーザ認証および認可
Home Agent（HA）は、PAP または CHAP を使用してユーザを認証するように設定できます。Foreign Agent（FA: 外部エージェント）チャレンジ手順がサポートされ（RFC 3012）、次の機能拡張が組み込まれています。
• モバイル IP エージェント アドバタイズ チャレンジの機能拡張
（注） MN-AAA 拡張機能がない場合は PAP を使用します。MN-AAA が存在する場合は、必ず CHAP を使用します。PAP ユーザのパスワードは、ip mobile home-agent aaa user-password コマンドで設定できます。
ホーム AAA サーバでユーザを認証するように設定されているときに、HA が Registration Request（RRQ; 登録要求）で MN-AAA 認証機能拡張を受信した場合は、その内容が使用されます。機能拡張がない場合は、デフォルトの設定可能なパスワードが使用されます。このデフォルトのパスワードは "vendor" など、ローカルで定義された文字列です。
HA は最初の登録の MN-FA チャレンジ機能拡張および MN-AAA 認証機能拡張（存在する場合）を受け付けて維持し、その後の登録更新で使用します。
HA が設定されたタイムアウトまでに AAA サーバから応答を受信しなかった場合は、設定可能な回数だけ、メッセージを再送できます。AAA サーバ グループと通信するように HA を設定できます。この場合、サーバはラウンドロビン方式で、設定された使用可能サーバから選択されます。
HA は RADIUS access accept パケットの 3GPP2 およびシスコ独自のセキュリティ機能拡張アトリビュートをサポートします。HA 上で、RADIUS サーバへのアクセス要求で 3GPP2 MN-HA SPI を送信し、RADIUS サーバから受け取った MN-HA 秘密鍵を処理することを設定できます。
Cisco IOS には、それぞれのレルムに基づいてサブスクライバを認可するメカニズムがあります。これには「サブスクライバの認可」という機能を使用します。詳細については、http://www.cisco.com/en/US/partner/products/ps6350/products_configuration_guide_chapter09186a0080455cf0.html#wp1056463 を参照してください。
（注） HA はユーザ プロファイルを受け付けますが、グループ プロファイルで返された情報に基づいて、モバイル サブスクライバを認可することはありません。
認証設定拡張機能
HA を使用して、特定のモバイル IP イベントについて AAA を使用した外部認証がいつ行われるかを設定できます。複数の FA をまたがるハンドオフは登録および登録解除イベントとして処理され、ハンドオフに対する特定の設定はありません。
再登録要求が前回の登録またはこのセッションに対する再登録に使用されたものとは別の SPI を使用して受信された場合は、このユーザの再登録時の認証に使用する設定オプション enable | disable は無視されます。
設定の適用または修正は、特定のバインディングに関する次回のイベントで行われます。
次の設定は、レルム単位（VPN Routing and Forwarding（VRF; VPN ルーティングおよびフォワーディング））で行われる可能性のある再登録および登録解除イベント向けのものです。
ip mobile host nai string aaa load-sa skip-aaa-reauth [ reregistration | deregistration]
デフォルト設定では、認証は3 つのイベントすべてに対して発生します（ip mobile host nai string aaa load-sa）。
デフォルト設定が適切であることを前提とした例を次に示します。
ip mobile host nai string aaa load-sa skip-aaa-reauth を実行すると、AAA 認証は登録に対してのみ発生します。
ip mobile host nai string aaa load-sa skip-aaa-reauth deregistration を実行すると、AAA 認証は登録および再登録に対して発生します。
ip mobile host nai string aaa skip-chap を実行すると、初回登録、再登録、および登録解除イベントに対して認証は発生しません。
ip mobile host nai string aaa load-sa skip-aaa-reauth reregistration を実行すると、AAA 認証は登録および登録解除に対してのみ発生します。
load-sa キーワードを使用すると、HA はセッション全体にわたって mobile-home 認証に関するセキュリティ アトリビュートをダウンロードしてローカルで保存します。このパラメータを使用しなかった場合、HA は mobile-home 認証に関するセキュリティ アトリビュートをローカルで保存しないため、以降の再登録または登録解除時には AAA からこれらの情報を取得します。
Mobile-Home Authentication Extension（MHAE）を持たない 3GPP2 登録要求（RRQ）
現在、HA は RRQ での MN-HA オーセンティケータの拡張機能を必須機能として扱います。HA が MHAE 拡張機能を持たない RRQ を受信した場合、その RRQ は無視されます。
ただし MHAE 拡張機能は、標準/RFC に従うと必須ではないため、3GPP2 PMIP RRQ はこの機能を持たない場合があります。Cisco HA Release 5.1 では、MHAE 拡張機能を持たない 3GPP2 PMIP RRQ が FA-HA 認証に成功すれば、それを許可するよう HA を設定できます。
|
|
|
|
|---|---|---|
設定すると、HA は、MHAE を持たず、有効な Foreign-Home Authentication Extension（FHAE）を持った 3GPP2 RRQ を受信した場合、RRQ を処理します。 |
（注） MHAE を持たず、有効な FHAE を持った CMIP RRQ を受信し、コマンドが設定されている場合、HA は RRQ を処理します。HA がこの RRQ を拒否しない理由は、HA が PMIP RRQ と CMIP RRQ を区別できないことです。この状況を回避するには、必ず FA が CMIP RRQ をチェックするようにして、FA が MHAE を持たない CMIP RRQ を HA に転送しないようにします。
3GPP2 のローカル認証
既存の HA 5.0 では、AAA からダウンロードした SA、またはローカルで設定されている HA のいずれかを使用してユーザを認証できます。これは、ip mobile host nai コンフィギュレーション コマンドで aaa キーワードを使用することでプロビジョニングできます。
HA 5.0 の機能はユーザ/nai ごとに設定できますが、アクセス タイプごとには設定できません。
HA Release 5.1 では、この機能をローカルの MN-HA SPI と Key を備えた NAI 認証と併用することで、ダウンロードした SA またはアクセス タイプに基づくローカル SA のいずれかを使用した柔軟なユーザ認証が可能になります。
この機能は、3gpp2 アクセス タイプにローカル SA を使用したユーザの認証、および Wimax アクセス タイプに AAA SA を使用した同一ユーザの認証に関する要件に対応しています。3gpp2 アクセス タイプ使用時は、アクセス要求は AAA に送信されません。
イネーブルな場合、RRQ が MN-AAA 拡張機能を備えている場合でも、アクセス要求は AAA に送信されません。
HA が 3GPP2 に対してローカル認証を実行するよう設定するには、次の作業を実行します。
|
|
|
|
|---|---|---|
Router(config)#access-type 3gpp2 suppress aaa access-request |
この設定を ip mobile host nai aaa および ip mobile secure host nai と併用した場合、3gpp2 アクセス タイプにローカル SA を使用したユーザの認証、および Wimax アクセス タイプに AAA SA を使用した同一ユーザの認証に関する要件に対応します。
ローカル MN-HA SPI および Key を使用した NAI 認証
HA R5.0 は、MN-HA セキュリティ アソシエーション（SA）または AAA からダウンロードした MN-HA SA 向けのローカル設定をサポートしますが、これら両方を同時にはサポートしません。
HA Release 5.1 では、HA は MN-HA SA および AAA からダウンロードした SA のローカル設定の両方をサポートします。SA がローカルに設定されているかどうかにかかわらず、HA が AAA からのアクセス応答メッセージ内の SA を受信した場合は、AAA からダウンロードした SA だけが MN-HA 認証に使用されます。
• ip mobile host コマンドが完全な NAI 向けに設定されている場合、対応するレルムにローカルで設定されている SA（単数または複数）は適用されません。ローカル SA を適用する必要がある場合、SA を完全な NAI に対して個別に設定する必要があります。
– ip mobile host nai @cisco.com virtual-network ip1 mask1 aaa
– ip mobile host nai user1@cisco.com virtual-network ip2 mask2 aaa
– ip mobile secure host nai @cisco.com spi 100 key ascii CISCO
ここで、@cisco.com に設定されている SA は user1@cisco.com. には適用されません。ローカル SA をこのユーザに適用する必要がある場合は、次に示すとおり SA を個別に設定する必要があります。
ip mobile secure host nai user1@cisco.com spi 100 key ascii YAHOO
再登録/登録解除に対する無認可
ローカル MN-HA SPI および Key 機能と NAI 認証を併用すると、ローカル設定された SA および AAA からダウンロードした SA が共にサポートされます。
ただし、次のコマンドを設定すると、再認証と再認可が回避されるのは、MN-HA 向けの SA が Access-Accept で受信された場合に限られます。
ローカル登録時に MN-HA 認証がローカル SA を使用している場合は、上記の設定を使用しても、再認証/再認可は省略されません。これは、load-sa がキャッシュするのは、AAA からダウンロードした SA だけであるためです。
load-sa が設定されていれば、ローカル設定されている SA を使用している場合でも、この機能は SA のキャッシングをサポートします。load-sa が設定されている場合、ローカル設定されている SA を使用しても、再認証は回避されます。さらに、skip-aaa-reauth が設定されている場合、ローカル設定されている SA を使用すると、AAA を使用した再認証は回避されます。
[rereg | dereg] オプションを指定した場合、再登録または登録解除のどちらか一方だけに対して、再認証と再認可の回避を選択できます。
MN-FA Challenge Extension（MFCE）による HA-CHAP の省略
この機能を使用すると、ホーム AAA サーバで HA-CHAP 手順を実行して、各登録要求のユーザに対応するセキュリティ アソシエーション（SA）をダウンロードするのではなく、HA に SA をダウンロードさせ、ディスクにローカルにキャッシュさせることができます。HA は、ユーザが初めて HA に登録したときに、HA-CHAP（MN-AAA 認証）を行い、SA をダウンロードして、ローカルにキャッシュします。その後、再登録要求があると、HA はローカル キャッシュの SA を使用してユーザを認証します。ユーザのバインディングが削除されると、SA キャッシュ エントリが削除されます。
設定例
次に、仮想ネットワーク 10.99.1.0 に配置するモバイル ノード グループを設定し、AAA サーバからモバイル ノードの SA を取得してキャッシュする例を示します。その後の再登録には、キャッシュの SA が使用されます。
次に、cisco.com ドメインのモバイル ノードに IP アドレスを割り当てるために使用する、ローカルなダイナミック アドレス プールの設定例を示します。AAA サーバから受け取った SA は、手動で削除されるまで、永久にキャッシュされます。
認証および認可の RADIUS アトリビュート
HA および RADIUS サーバは、認証および認可サービスに関して、 表 1 の RADIUS アトリビュートをサポートします。
フィードバック