WAN : ポイントツーポイント プロトコル(PPP)

PPP パスワード認証プロトコル(PAP)の設定とトラブルシューティング

2008 年 5 月 29 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2005 年 3 月 9 日) | フィードバック

目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
背景説明
単方向認証と双方向認証
設定コマンド
      ppp authentication pap [callin]
      username <username> password <password>
      PPP pap sent-username <username> password <password>
設定例
      発信側(クライアント)の設定
      受信側(サーバ)の設定
デバッグ出力
      単方向 PAP 認証が成功した場合の発信側(クライアント)のデバッグ
      単方向 PAP 認証が成功した場合の着信側(サーバ)のデバッグ
PAP のトラブルシューティング
      PAP を認証プロトコルとすることに双方が合意しない
      PAP 認証が失敗する
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

Point-to-Point Protocol(PPP; ポイントツーポイント プロトコル)では現在 2 種類の認証プロトコルがサポートされています。Password Authentication Protocol(PAP; パスワード認証プロトコル)と Challenge Handshake Authentication Protocol(CHAP)がこの認証プロトコルです。これらの認証プロトコルはどちらも RFC 1334 で規定されており、同期および非同期インターフェイスでサポートされています。

  • PAP は、リモート ノードが双方向ハンドシェイクを使用して自身の身元を明らかにするための単純な方法を提供します。PPP リンク確立フェーズが完了した後、ユーザ名とパスワードのペアがリンクを通じて(クリア テキストで)繰り返し送信されます。これは、認証が確認応答されるか、または接続が終了するまで続きます。

  • PAP は安全な認証プロトコルではありません。パスワードはリンクを通じてクリア テキストで送信され、プレイバック攻撃やブルート フォース攻撃から保護する仕組みもありません。リモート ノードによってログイン試行の回数とタイミングが管理されます。

(PAP または CHAP を使用した)PPP 認証のトラブルシューティングについては、PPP 認証フェーズをトラブルシューティングするための順を追った網羅的なフローチャートである『トラブルシューティング:PPP(CHAP または PAP)認証』を参照してください。すべての PPP フェーズ(LCP、認証、NCP)のトラブルシューティングについては、すべての関連 PPP フェーズとネゴシエーションされるパラメータに関する順を追ったトラブルシューティングの網羅的なフローチャートである『PPP のトラブルシューティング フローチャート』のドキュメントを参照してください。

前提条件

要件

このドキュメントに関する特別な要件はありません。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

背景説明

CHAP ではユーザ パスワードが接続を通じて送信されないため、PAP よりも安全であると見なされています。CHAP についての詳細は、『PPP CHAP 認証の説明と設定』を参照してください。

安全な認証プロトコルではないにもかかわらず、次の環境では PAP が使用される場合があります。

  • クライアント アプリケーションの大規模なインストール ベースで、CHAP がサポートされていない場合

  • CHAP の実装がベンダー間で異なり、互換性がない場合

  • リモート ホストでログインをシミュレートするために、プレーン テキストのパスワードが必要な場合

単方向認証と双方向認証

ほとんどの認証タイプと同様に、PAP は双方向認証と単方向認証をサポートします。単方向認証では、コールを受信する側(NAS)のみがリモート サイド(クライアント)を認証します。リモート クライアントはサーバを認証しません。

双方向認証では、各サイドが個別に Authenticate-Request(AUTH-REQ)を送信し、Authenticate-Acknowledge(AUTH-ACK)または Authenticate-Not Acknowledged(AUTH-NAK)を受信します。これは debug ppp authentication コマンドを使用して確認できます。クライアントでの、このデバッグの例を次に示します。

*Mar  6 19:18:53.322: BR0:1 PAP: O AUTH-REQ id 7 len 18 from "PAPUSER"

! --- 発信 PAP AUTH-REQ。NAS に対してユーザ名(PAPUSER)とパスワードを
! --- 送出しています。
! --- NAS はユーザ名/パスワードが正しいかどうかを確認します。

*Mar  6 19:18:53.441: BR0:1 PAP: I AUTH-ACK id 7 Len 5

! --- 着信 AUTH-ACK。
! --- NAS がユーザ名とパスワードを確認し、AUTH-ACK で応答しました。
! --- この時点で単方向認証が完了します。

*Mar  6 19:18:53.445: BR0:1 PAP: I AUTH-REQ id 1 Len 14 from "NAS"

! --- NAS からの着信 AUTH-REQ。今度はクライアントで NAS の識別情報を確認します。

*Mar  6 19:18:53.453: BR0:1 PAP: Authenticating peer NAS

! --- ユーザ名(NAS)とパスワードを検索しています。

*Mar  6 19:18:53.457: BR0:1 PAP: O AUTH-ACK id 1 Len 5

! --- 発信 AUTH-ACK。 
! --- NAS のユーザ名/パスワードを確認し、AUTH-ACK で応答しました。
! --- これで双方向認証は完了です。

上記のデバッグ出力では、認証が双方向でした。単方向認証が設定されている場合は、デバッグの最初の 2 行のみが表示されます。

設定コマンド

通常の PAP 認証には、次に示す 3 つのコマンドが必要です。

ppp authentication pap [callin]

ppp authentication pap コマンドが設定されているルータでは、PAP を使用して相手側(ピア)の識別情報を確認します。つまり、相手側(ピア)は確認のためにローカル デバイスに対して自身のユーザ名/パスワードを提示する必要があります。

callin オプションを指定した場合、ppp authentication pap callin コマンドが設定されているルータでは、着信コール時のみ相手側を認証します。発信コールの場合は相手側を認証しません。つまり、コールを開始するルータは相手側からの認証要求(AUTH-REQ)を必要としません。

次の表は、callin オプションをどの場合に設定すればよいかを示しています。

認証タイプ クライアント(発信側) NAS(着信側)

単方向

ppp authentication pap callin

ppp authentication pap

双方向

ppp authentication pap

ppp authentication pap


username <username> password <password>

これは、PPP ピアを認証するためにローカル ルータで使用されるユーザ名とパスワードです。ピアが自身の PAP ユーザ名とパスワードを送信してくると、ローカル ルータはそのユーザ名とパスワードがローカルに設定されているかどうかをチェックします。一致すれば、ピアは認証されます。

注:PAP の username コマンドの機能は CHAP の機能とは異なります。CHAP では、このユーザ名とパスワードを使用して身元証明要求への応答が生成されますが、PAP はこれを着信ユーザ名とパスワードの有効性を確認するためだけに使用します。

単方向認証では、このコマンドは着信側ルータにのみ必要です。双方向認証では、このコマンドは両方の側に必要です。

PPP pap sent-username <username> password <password>

発信 PAP 認証を有効にします。ローカル ルータでは ppp pap sent-username コマンドで指定されたユーザ名とパスワードにより、リモート デバイスに対して自身を認証します。相手側のルータでは、上記の username コマンドを使用して、この同じユーザ名/パスワードが設定されている必要があります。

単方向認証を使用している場合、このコマンドはコールを開始するルータにのみ必要です。双方向認証では、このコマンドは両側に設定する必要があります。

設定例

次の設定のセクションでは、単方向認証シナリオで必要な PAP コマンドを示しています。

注:設定の中で関連のあるセクションのみが示されています。

発信側(クライアント)の設定

interface BRI0

! --- ダイヤルアウト用の BRI インターフェイス。

 ip address negotiated
 encapsulation ppp

! --- PPP カプセル化を使用します。このコマンドは PAP の場合に必要です。

 dialer string 3785555 class 56k

! --- 発信接続時にダイヤルする番号。

 dialer-group 1
 isdn switch-type basic-ni
 isdn spid1 51299611110101 9961111
 isdn spid2 51299622220101 9962222
 ppp authentication pap callin

! --- 着信コールに対して PAP 認証を使用します。
! --- callin キーワードが指定されているため、これは単方向認証シナリオになります。
! --- このルータ(クライアント)は、クライアントに対する自身の認証を
! --- ピア(サーバ)に対して要求しません。

 ppp pap sent-username PAPUSER password 7 <deleted>

! --- このルータ(クライアント)のピアに対する発信認証を許可します。
! --- ユーザ名 PAPUSER とパスワードを含む PAP AUTH-REQ パケットをピアに送信します。
! --- ピアにはユーザ名 PAPUSER とパスワードが設定されている必要があります。

受信側(サーバ)の設定

username PAPUSER password 0 cisco

! --- ユーザ名 PAPUSER はクライアントから送られてくるユーザ名と同じです。
! --- クライアントから AUTH-REQ パケットを受け取ると、ユーザ名とパスワードが
! --- ここに設定されているものと一致するかどうかが確認されます。

interface Serial0:23

! --- これはコールを受信するアクセス サーバ上の PRI の D チャネルです。

 ip unnumbered Ethernet0
 no ip directed-broadcast
 encapsulation ppp

! --- PPP カプセル化を使用します。このコマンドは PAP の場合に必要です。

 dialer-group 1
 isdn switch-type primary-ni
 isdn incoming-voice modem
 peer default ip address pool default
 fair-queue 64 256 0
 ppp authentication pap

! --- 着信コールに対して PAP 認証を使用します。
! --- このルータ(サーバ)は、ピアがピア自身をサーバに対して認証することを
! --- 要求します。
! --- 注:このルータがコールを開始することはないため、callin オプションは
! --- 使用されません。

デバッグ出力

PPP PAP 問題のデバッグを行うには、debug ppp negotiation コマンドと debug ppp authentication コマンドを使用します。次の 2 つの点に注意してください。

  1. 認証方式として PAP に双方が合意しているか。

  2. 合意している場合、PAP 認証が成功するか。

これらの質問に正しく回答する方法については、次のデバッグを参照してください。また、PPP 認証などの異なる PPP フェーズにおけるさまざまなデバッグ行のすべてと関連する意味の説明については、『debug ppp negotiation の出力について』も参照してください。このドキュメントは、PPP ネゴシエーションの失敗原因をすばやく判断するのに役立ちます。(PAP または CHAP を使用した)PPP 認証のトラブルシューティングについては、PPP 認証フェーズをトラブルシューティングするための順を追った網羅的なフローチャートである『トラブルシューティング:PPP(CHAP または PAP)認証』を参照してください。

単方向 PAP 認証が成功した場合の発信側(クライアント)のデバッグ

maui-soho-01#show debug
PPP:
  PPP authentication debugging is on
  PPP protocol negotiation debugging is on
maui-soho-01#ping 172.22.53.144

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.22.53.144, timeout is 2 seconds:

*Mar  6 21:33:26.412: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Mar  6 21:33:26.432: BR0:1 PPP: Treating connection as a callout
*Mar  6 21:33:26.436: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
*Mar  6 21:33:26.440: BR0:1 PPP: No remote authentication for call-out

! --- 発信コールの場合、クライアントではサーバの認証は行われません。
! --- これは単方向認証の例である点に注意してください。

*Mar  6 21:33:26.444: BR0:1 LCP: O CONFREQ [Closed] id 82 Len 10
*Mar  6 21:33:26.448: BR0:1 LCP:    MagicNumber 0x2F1A7C63 (0x05062F1A7C63)

! --- 発信 CONFREQ(CONFigure-REQuest)。
! --- 認証を行うのはピアだけなので、
! --- 認証方式は指定しません。

*Mar  6 21:33:26.475: BR0:1 LCP: I CONFREQ [REQsent] id 13 Len 14
*Mar  6 21:33:26.479: BR0:1 LCP:    AuthProto PAP (0x0304C023)

! --- 着信 LCP CONFREQ(Configure-Request)で、
! --- ピア(サーバ)が PAP の使用を要求していることを示しています。

*Mar  6 21:33:26.483: BR0:1 LCP:    MagicNumber 0x3DBEE95B (0x05063DBEE95B)
*Mar  6 21:33:26.491: BR0:1 LCP: O CONFACK [REQsent] id 13 Len 14
*Mar  6 21:33:26.495: BR0:1 LCP:    AuthProto PAP (0x0304C023)

! --- 発信 LCP CONFACK(CONFigure-ACKnowledge)で、
! --- クライアントが PAP を実行できることを示しています。

*Mar  6 21:33:26.499: BR0:1 LCP:    MagicNumber 0x3DBEE95B (0x05063DBEE95B)
*Mar  6 21:33:26.511: BR0:1 LCP: I CONFACK [ACKsent] id 82 Len 10
*Mar  6 21:33:26.515: BR0:1 LCP:    MagicNumber 0x2F1A7C63 (0x05062F1.A7C63)
*Mar  6 21:33:26.519: BR0:1 LCP: State is Open

! --- LCP ネゴシエーションが完了したことが示されています。

*Mar  6 21:33:26.523: BR0:1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load]

! --- (ピアによる)PAP 認証が開始されます。

*Mar  6 21:33:26.531: BR0:1 PAP: O AUTH-REQ id 20 Len 18 from "PAPUSER"

! --- クライアントはユーザ名 PAPUSER を含む PAP AUTH-REQ を送出します。
! --- このユーザ名は ppp pap sent-username コマンドで設定されています。

*Mar  6 21:33:26.555: BR0:1 PAP: I AUTH-ACK id 20 Len 5

! --- ピアはクライアントが正常に認証されたことを示す
! --- PPP AUTH-ACK で応答します。

単方向 PAP 認証が成功した場合の着信側(サーバ)のデバッグ

maui-nas-06#show debug
PPP:
  PPP authentication debugging is on
  PPP protocol negotiation debugging is on
maui-nas-06#
*Jan  3 14:07:57.872: %LINK-3-UPDOWN: Interface Serial0:4, changed state to up
*Jan  3 14:07:57.876: Se0:4 PPP: Treating connection as a callin

! --- 接続が着信したため、クライアントの認証を開始します。

*Jan  3 14:07:57.876: Se0:4 PPP: Phase is ESTABLISHING, Passive Open
*Jan  3 14:07:57.876: Se0:4 LCP: State is Listen
*Jan  3 14:07:58.120: Se0:4 LCP: I CONFREQ [Listen] id 83 Len 10
*Jan  3 14:07:58.120: Se0:4 LCP:    MagicNumber 0x2F319828 (0x05062F319828)
*Jan  3 14:07:58.124: Se0:4 LCP: O CONFREQ [Listen] id 13 Len 14
*Jan  3 14:07:58.124: Se0:4 LCP:    AuthProto PAP (0x0304C023)

! --- 発信 CONFREQ(Configure-Request)。
! --- ピア認証に PAP を使用することを示しています。

*Jan  3 14:07:58.124: Se0:4 LCP:    MagicNumber 0x3DD5D5B9 (0x05063DD5D5B9)
*Jan  3 14:07:58.124: Se0:4 LCP: O CONFACK [Listen] id 83 Len 10
*Jan  3 14:07:58.124: Se0:4 LCP:    MagicNumber 0x2F319828 (0x05062F319828)
*Jan  3 14:07:58.172: Se0:4 LCP: I CONFACK [ACKsent] id 13 Len 14
*Jan  3 14:07:58.172: Se0:4 LCP:    AuthProto PAP (0x0304C023)

! --- 発信 LCP CONFACK(Configure-Acknowledge)。
! --- クライアントが PAP を実行できることを示しています。

*Jan  3 14:07:58.172: Se0:4 LCP:    MagicNumber 0x3DD5D5B9 (0x05063DD5D5B9)
*Jan  3 14:07:58.172: Se0:4 LCP: State is Open
*Jan  3 14:07:58.172: Se0:4 PPP: Phase is AUTHENTICATING, by this end

! --- (サーバによる)PAP 認証が開始されます。

*Jan  3 14:07:58.204: Se0:4 PAP: I AUTH-REQ id 21 Len 18 from "PAPUSER"

! --- ピアからの着信 AUTH-REQ。ピアの識別情報を
! --- 確認する必要があります。

*Jan  3 14:07:58.204: Se0:4 PPP: Phase is FORWARDING
*Jan  3 14:07:58.204: Se0:4 PPP: Phase is AUTHENTICATING
*Jan  3 14:07:58.204: Se0:4 PAP: Authenticating peer PAPUSER

! --- ユーザ名(PAPUSER)とパスワードを検索しています。

*Jan  3 14:07:58.208: Se0:4 PAP: O AUTH-ACK id 21 Len 5

! --- これは発信 AUTH-ACK を示しています。
! --- ユーザ名とパスワードを確認し、AUTH-ACK で応答しています。
! --- これで単方向認証は完了です。

PAP のトラブルシューティング

PAP のトラブルシューティングを行うときは、「デバッグ出力」のセクションにあるのと同じ質問に答えます。

  1. 認証方式として PAP に双方が合意しているか。

  2. 合意している場合、PAP 認証が成功するか。

(PAP または CHAP を使用した)PPP 認証のトラブルシューティングについては、PPP 認証フェーズをトラブルシューティングするための順を追った網羅的なフローチャートである『トラブルシューティング:PPP(CHAP または PAP)認証』を参照してください。

PAP を認証プロトコルとすることに双方が合意しない

設定によっては、PAP を使用するにもかかわらず、両方の側が認証プロトコルとして PAP に合意せず、代わりに CHAP に合意する場合があります。このような問題のトラブルシューティングを行うには、次のステップに従います。

  1. コールを受信しているルータに次の認証コマンドのいずれかが設定されていることを確認します。

    ppp authentication pap
           または
    ppp authentication pap chap 
           または
    ppp authentication chap pap
    
  2. コールを発信しているルータに ppp authentication pap callin コマンドが設定されていることを確認します。

  3. 発信側にコマンド ppp pap sent-username username password password が正しく設定されていることを確認します。ユーザ名とパスワードは受信側ルータに設定されているものと一致する必要があります。

  4. 発信側ルータのインターフェイス設定モードでコマンド ppp chap refuse を設定します。

    Cisco ルータは、デフォルトでは認証プロトコルとして CHAP を受け入れます。クライアントが PAP を希望しているものの、アクセス サーバで PAP と CHAP がどちらも実行できる(ppp authentication chap pap が設定されている)状況では、ppp chap refuse コマンドを使用して、クライアントに認証プロトコルとして強制的に PAP を受け入れさせることができます。

    maui-soho-01(config)#interface BRI 0
    maui-soho-01(config-if)#ppp chap refuse
    

PAP 認証が失敗する

両側が認証プロトコルとして PAP に合意しているにもかかわらず PAP 接続が失敗する場合、最も可能性が高いのはユーザ名/パスワードの問題です。

  1. 発信側にコマンド ppp pap sent-username username password password が正しく設定されていることを確認します。ユーザ名とパスワードは受信側ルータに設定されているものと一致する必要があります。

  2. 双方向認証の場合は、受信側にコマンド ppp pap sent-username username password password が正しく設定されていることを確認します。ユーザ名とパスワードは発信側ルータに設定されているものと一致する必要があります。

    双方向認証を行っている場合に、受信側ルータにコマンド ppp pap sent-username username password password が設定されておらず、なおかつ PPP クライアントがサーバにリモートでの認証を要求しようとしたときは、debug ppp negotiation(または debug ppp authentication)の出力に次のように表示されます。

    *Jan  3 16:47:20.259: Se0:1 PAP: Failed request for PAP credentials.  Username maui-nas-06
    

    このエラー メッセージは設定上の問題を示すもので、必ずしもセキュリティ侵犯とは限りません。

  3. ユーザ名とパスワードが、ピアでコマンド ppp pap sent-username username password password によって設定されているものと一致することを確認します。

    一致しない場合は次のメッセージが表示されます。

    *Jan  3 17:18:57.559: Se0:3 PAP: I AUTH-REQ id 25 Len 18 from "PAPUSER"
    *Jan  3 17:18:57.559: Se0:3 PPP: Phase is FORWARDING
    *Jan  3 17:18:57.559: Se0:3 PPP: Phase is AUTHENTICATING
    *Jan  3 17:18:57.559: Se0:3 PAP: Authenticating peer PAPUSER
    *Jan  3 17:18:57.559: Se0:3 PAP: O AUTH-NAK id 25 Len 32 msg is
     "Password validation failure"
    
    ! --- これは発信 AUTH-NAK であり、このルータでミスマッチが起こったことを
    ! --- 示しています。 
    ! --- ローカルに設定されているユーザ名とパスワードがピアのそれと 
    ! --- まったく同じものあるかを確認してください。
    
    

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 10313