概要
このドキュメントでは、Challenge Handshake Authentication Protocol(CHAP)が3ウェイハンドシェイクを使用してピアの身元を確認する方法について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
-
インターフェイスでPPPを有効にする方法 encapsulation ppp
コマンドを使用して、アップグレードを実行します。
-
「 debug ppp negotiation
コマンド出力.詳細については、「debug ppp negotiation出力について」を参照してください。
-
リンクコントロールプロトコル(LCP)フェーズがオープン状態でない場合のトラブルシューティング方法これは、PPP 認証フェーズは、LCP フェーズが完了してオープン状態になるまで開始されないためです。If the debug ppp negotiation
コマンドはLCPがオープンであることを示しません。先に進む前に、この問題のトラブルシューティングを行う必要があります。
注:このドキュメントでは、MS-CHAP(バージョン1またはバージョン2)については説明していません。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
表記法
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
背景説明
Challenge Handshake Authentication Protocol(CHAP; チャレンジ ハンドシェイク認証プロトコル)(RFC 1994 で定義)は、スリー ウェイ ハンドシェイクによりピアの身元を確認します。CHAP で実行される一般的な手順を以下に示します。
-
Link Control Protocol(LCP; リンク コントロール プロトコル)フェーズが完了し、両方のデバイス間で CHAP がネゴシエートされた後、認証側はチャレンジ メッセージをピアに送信します。
-
ピアは、一方向ハッシュ関数(Message Digest 5 [MD5])で計算された値で応答します。
-
認証側は、その応答が自分の計算した予測ハッシュ値と一致するかどうかをチェックします。値が一致する場合、認証は成功します。そうでない場合は、接続が解除されます。
この認証方式は、認証側とピアだけが知る「秘密」に依存します。この秘密鍵は、リンク上を送信されることはありません。認証は単方向にすぎませんが、相互認証に同じ秘密鍵セットを使用すると、双方向に CHAP をネゴシエートできます。
CHAP の利点と欠点の詳細は、「RFC 1994」 を参照してください。
CHAP の設定
CHAP を設定する手順はとても簡単です。たとえば、図1に示すように、左右2台のルータがネットワークで接続されているとします。
ネットワークで接続された2台のルータ
図1:ネットワーク経由で接続された2台のルータ
CHAP 認証を設定するには、次の手順を実行します。
-
インターフェイスで、encapsulation ppp コマンドを発行します。
-
両方のルータでCHAP認証の使用を有効にし、 ppp authentication chap
コマンドを使用して、アップグレードを実行します。
-
ユーザ名とパスワードを設定します。これを行うには、 username username password password
コマンドを使用します。ここで、usernameisはピアのホスト名です。次の内容を確認してください。
注:デフォルトでは、ルータは自身のホスト名を使用してピアに対して自身を識別します。ただし、このCHAPユーザ名は、 ppp chap hostname
コマンドを使用して、アップグレードを実行します。詳細は、『ppp chap hostnameコマンドおよびppp authentication chap callinコマンドを使用するPPP認証』を参照してください。
一方向および双方向認証
CHAP は、単方向の認証方式として定義されています。ただし、双方向認証を作成するには、両方の方向で CHAP を使用します。したがって、双方向の CHAP では、個別の 3 ウェイ ハンドシェイクがそれぞれの側で開始します。
Cisco の CHAP 実装では、デフォルトでは、(認証が完全にオフにされない限り)着信側が発信側を認証する必要があります。このため、着信側によって開始される単方向の認証が最低限の認証です。ただし、発信側も着信側の身元を確認できるため、双方向の認証になります。
単方向認証は、Cisco 以外のデバイスに接続するときに必要になる場合がよくあります。
単方向認証の場合、 ppp authentication chap callin
コマンドを発信側ルータで発行します。
表 1 に、callin オプションを設定する場合を示します。
表1: Callinオプションを設定する場合
認証タイプ |
クライアント(発信側) |
NAS(着信側) |
単方向 |
ppp authentication chap callin |
ppp authentication chap |
双方向 |
ppp authentication chap |
ppp authentication chap |
詳細は、『ppp chap hostnameコマンドおよびppp authentication chap callinコマンドを使用するPPP認証』を参照してください。
CHAP 設定コマンドとオプション
表 2 に、CHAP コマンドとオプションをリストします。
表2: CHAPコマンドとオプション
コマンド |
説明 |
ppp認証{chap | ms-chap | ms-chap-v2 | eap(オプション) |pap} [callin] |
このコマンドは、リモート PPP ピアのローカル認証を、指定したプロトコルで有効にします。 |
ppp chap hostnameusername |
このコマンドは、インターフェイス固有の CHAP ホスト名を定義します。詳細は、『ppp chap hostnameコマンドおよびppp authentication chap callinコマンドを使用するPPP認証』を参照してください。 |
ppp chap passwordpassword |
このコマンドは、インターフェイス固有の CHAP パスワードを定義します。 |
PPPディレクションコール | 吹き出し | 専用 |
このコマンドは、コールの方向を強制的に設定します。このコマンドは、コールが着信か発信かに関してルータが混乱している場合(たとえば、バックツーバックで接続されていたり、リース回線で接続され、Channel Service Unit or Data Service Unit [CSU/DSU] または ISDN Terminal Adapter [TA; ターミナル アダプタ] がダイヤル接続用に設定されている場合)に使用します。 |
ppp chap refuse [callin] |
このコマンドは、ピアによるリモート認証を無効にします(デフォルトでは有効)。このコマンドにより、CHAP 認証がすべてのコールに対して無効にされます。つまり、すべてのユーザに CHAP を使用して認証させようとするピアによる試みがすべて拒否されることを意味します。callin オプションにより、ルータはピアから受信する CHAP 認証チャレンジへの応答を拒否するけれど、ピアに対しては、ルータの送信する CHAP チャレンジへの応答をまだ要求することが指定されます。 |
ppp chap wait |
このコマンドは、発信側が最初に認証する必要があることを指定します(デフォルトで有効)。このコマンドは、ピアがルータに対して自身を認証するまで、ルータがCHAP認証を要求するピアに対して認証を行わないことを指定します。 |
ppp max-bad-auth value |
このコマンドは、認証のリトライの許容回数を指定します(デフォルト値は 0)。このコマンドは、認証が失敗した直後に自身をリセットするのではなく、指定した回数認証をリトライできるように、ポイントツーポイント インターフェイスを設定します。 |
ppp chap splitnames |
この隠しコマンドを使用すると、CHAP チャレンジと応答に対して異なるホスト名を使用できます(デフォルト値は無効)。 |
ppp chap ignoreus |
この隠しコマンドは、ローカル名を持つ CHAP チャレンジを無視します(デフォルト値は有効)。 |
トランザクションの例
このセクションの図は、2 台のルータ間の CHAP 認証中に起きる一連のイベントを示しています。これらのメッセージは、 debug ppp negotiation
コマンド出力.詳細については、「debug ppp negotiation出力について」を参照してください。
コールが着信します
図2:コールの着信
図2は、次の手順を示しています。
-
コールが3640-1に着信します。着信インターフェイスは、 ppp authentication chap
コマンドを使用して、アップグレードを実行します。
-
LCP は CHAP および MD5 をネゴシエートします。これを決定する方法の詳細については、「debug ppp negotiation出力について」を参照してください。
-
3640-1 から発信側ルータへの CHAP チャレンジが、このコールで必要になります。
CHALLENGE
CHAPチャレンジパケットの作成
図3:CHAPチャレンジパケットの作成
図3は、2台のルータ間のCHAP認証における次の手順を示しています。
-
CHAP チャレンジ パケットが次の特性で作成されます。
-
id 値と random 値は、着信側ルータで保持されます。
-
チャレンジ パケットが発信側ルータに送信されます。未解決のチャレンジのリストが維持されます。
応答
ピアからのチャレンジパケットの受信とMD5処理
図4:ピアからのチャレンジパケットの受信とMD5処理
図4は、どのようにピアからチャレンジパケットが受信され、処理(MD5)されるかを示しています。ルータは、着信 CHAP チャレンジ パケットを次のように処理します。
-
ID 値が MD5 ハッシュ ジェネレータに入力されます。
-
random 値が MD5 ハッシュ ジェネレータに入力されます。
-
名前 3640-1 が、パスワードの参照に使用されます。ルータは、チャレンジ内のユーザ名に一致するエントリを検索します。この例で検索される内容は、次のとおりです。
username 3640-1 password pc1
4.パスワードがMD5ハッシュジェネレータに入力されます。
結果は、MD5 ハッシュ処理済みの単方向の CHAP チャレンジとなり、CHAP 応答で返送されます。
応答(続き)
オーセンティケータに送信されるCHAP応答パケットが作成される
図5:オーセンティケータに送信されるCHAP応答パケットが作成される
図 5 は、認証者に送信される CHAP 応答パケットがどのように作成されるかを示しています。この図に、これらの手順を示します。
-
応答パケットは、次の構成要素で構成されます。
-
02 = CHAP 応答パケット タイプの識別子。
-
id = チャレンジ パケットからコピーされた id。
-
hash = MD5 ハッシュ ジェネレータからの出力(チャレンジ パケットからハッシュ処理された情報)。
-
766-1 = このデバイスの認証名。これは、ピアが身元の確認に必要なユーザ名およびパスワードのエントリを検索するために必要です(詳細は「CHAP の確認」セクションで説明されています)。
-
次に、応答パケットがチャレンジャに送信されます。
CHAP の確認
このセクションでは、設定の確認方法に関するヒントを説明します。
チャレンジャが応答パケットを処理する
図6:チャレンジャが応答パケットを処理する
図 6 は、チャレンジャが応答パケットを処理する方法を示しています。CHAP 応答パケットが(認証側で)処理される際に行われる手順を次に示します。
-
ID は、元のチャレンジ パケットを検索するために使用されます。
-
IDがMD5ハッシュジェネレータに入力されます。
-
元のチャレンジによるランダムな値が、MD5 ハッシュ ジェネレータに入力されます。
-
名前 766-1 は、次のソースのうちの 1 つからパスワードを検索するために使用されます。
-
パスワードが MD5 ハッシュ ジェネレータに入力されます。
-
応答パケットで受信されたハッシュ値は、MD5 ハッシュの計算値と比較されます。計算されたハッシュ値と受信されたハッシュ値が等しい場合、CHAP 認証は成功します。
結果
発信側ルータに成功メッセージが送信される
図7:発信側ルータへの成功メッセージの送信
図 7 は、発信側ルータに送信される成功メッセージを示しています。これには、次の手順が含まれます。
-
認証が成功した場合、CHAP 成功パケットが次の構成要素から作成されます。
-
認証が失敗した場合、CHAP 失敗パケットが次の構成要素から作成されます。
-
次に、成功または失敗パケットが、発信側ルータに送信されます。
注:この例では、単方向認証を示しています。双方向認証では、この処理全体が繰り返されます。ただし、発信側ルータが最初のチャレンジを開始します。
CHAP のトラブルシューティング
問題のトラブルシューティング方法については、『PPP(CHAPまたはPAP)認証のトラブルシューティング』を参照してください。
関連情報