長度字段兩字節，指示CHAP包的長度，包括代碼、長度和數據字段。超出
      長度的字節應該視為數據鏈路層填充，接收方應該忽略。

   數據  Data

      數據字段是零個或多個字節，數據字段格式由代碼字段確定。

4.1.  挑戰和應答
   描述

      挑戰包是CHAP的開始，認證者必須傳送代碼字段為1的CHAP包，其他挑戰
      數據包必須在有效應答數據包成功接收之后或者可選重試計數器計滿后發
      送。

      為了確保連接沒有被更改，挑戰包也可以在NLP階段的任何時候發送。

      對端應該隨時為認證階段和NLP階段的挑戰做好準備，任何時候收到挑戰
      包，對端都必須傳送代碼字段為2（應答）的CHAP數據包。

      無論何時，如果收到應答包，認證者都必須把應答值和自己計算的預期值
      比較，基于這種比較，認證者必須發送成功（Success）或者失敗
      （Failure）CHAP包。

         注：由于成功包可能丟失，認證者在NLP階段中必須允許重復的應答包，
         為了發現更改的名字和密鑰，收到具有當前挑戰標識符的應答包必須返
         回與先前挑戰同樣的響應代碼（消息部分可能不相同），在任何其他階
         段收到的任何應答包必須靜靜丟棄。

         如果“失敗包”丟失，認證者終止了鏈路，那么可以由LCP的“終止請
         求”和“終止應答”來指示認證失敗。

   挑戰包和應答包的格式如下，字段從左到右傳輸。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Value-Size   |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Name ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   代碼  Code

      1  挑戰 Challenge;

      2  應答 Response.

   標識  Identifier

      標識字段一字節，每次發送挑戰都必須要改變標識字段的值。

      應答標識必須由響應的挑戰標識字段拷貝得來。

   值大小  Value-Size

      一字節長，指示“值”字段的長度。

   值  Value

      值字段一個或者多個字節，首先傳輸最高位。

      挑戰值是可變字節流，上文已經敘述了挑戰值唯一性的重要性和它與密鑰
      之間的關系。挑戰值必須在每次發送挑戰時都要改變。挑戰值的具體長度
      由產生它的方法而定，獨立于所用的哈希算法。

      應答值由標識串接密鑰串接挑戰值然后經過哈希運算得出，其長度由所用
      的哈希算法決定（對于MD5，為16字節）。

   名字  Name

      名字字段一個或多個字節，代表傳輸數據包的系統的標識，字段內容沒有
      限制，如，可以是ASCII字串，或者是全局唯一的ASN.1標識，名字不應該
      是NUL或者CR/LF終止符。其長度由長度字段確定。

4.2.  成功與失敗
   描述

      如果接收到的應答值等于預期值，那么認證者必須傳送代碼字段為3（
      成功）的CHAP數據包。

      如果接收到的應答值不等于預期值，那么認證者必須傳送代碼字段為4
      （失敗）的CHAP數據包，并且應該終止鏈路。

   成功和失敗包格式如下所示，字段從左到右傳輸。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Message  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   代碼  Code

      3   成功 Success;

      4   失敗 Failure.

   標識  Identifier

      標識字段一字節，輔助匹配應答和響應，從響應的應答標識字段拷貝得
      來。

   消息  Message

      消息字段是一個或者多個字節，其內容與具體實現無關，最好可以直接
      閱讀，但是不得影響協議操作，推薦使用可顯示的ASCII字符（從32到
      126）。擴展到其他字符集機制的研究留在以后進行，其長度由長度字段
      確定。


安全考慮

   安全問題是該RFC的主題。

   PPP認證協議的交互作用依賴于具體實現，本文通篇的“應該”字樣已經暗示了
   這一點。

   例如，對于認證失敗，一些實現可能并不終止鏈路，而只是限制網絡層協議的
   流量，允許用戶更新密鑰或向網絡管理員發送郵件表示有問題發生。

   對于失敗的認證不做二次審定，然而，LCP狀態機可以在任何時候重新協商認證
   協議，因而允許新的嘗試，推薦讓認證失敗計數器只有在成功認證之后或者終
   止失敗鏈路之后才重新設置。

   不需要雙工認證，也不需要在兩個方向上使用同一個認證協議，在不同的方向
   上使用不同的認證協議完全是可以接受的，當然，這都要根據具體協議協商而
   定。

   兩個方向上的密鑰不應該相同，否則，攻擊者可以重放對端的挑戰、接受經過
   運算的應答以及使用該應答來進行認證等。

   實際上，對于每個PPP服務器，有一個關聯用戶名和認證信息（密鑰）的數據
   庫，不要讓特定用戶由多個認證方法來認證，因為這會使攻擊者容易選擇一
   個安全性較低的認證方法入侵（如，用PAP，而不是CHAP）。如果使用了相同
   的密鑰，PAP便會暴露CHAP所使用的密鑰。

   對于每一個用戶名，應該指示一種特定的認證方法，如果用戶在不同的環境下
   使用不同的認證方法，那么他應該在不同的環境下使用不同的用戶名，每個用
   戶名標識一個認證方法。

   口令和其他其他密鑰應該分別存在每一端，以便盡可能限制訪問，理想的做法
   是，密鑰只能由執行認證的進程訪問。

   密鑰的發布機制應該盡量限制處理密鑰的實體，理想的做法是，非授權人不應
   該得到密鑰的半點信息，這些機制的討論產出本文的范圍。

鳴謝
   David Kaufman, Frank Heinrich, and Karl Auerbach used a challenge
   handshake at SDC when designing one of the protocols for a "secure"
   network in the mid-1970s.  Tom Bearson built a prototype Sytek
   product ("Poloneous"?) on the challenge-response notion in the 1982-
   83 timeframe.  Another variant is documented in the various IBM SNA
   manuals.  Yet another variant was implemented by Karl Auerbach in the
   Telebit NetBlazer circa 1991.

   Kim Toms and Barney Wolff provided useful critiques of earlier
   versions of this document.

   Special thanks to Dave Balenson, Steve Crocker, James Galvin, and
   Steve Kent, for their extensive explanations and suggestions.  Now,
   if only we could get them to agree with each other.

參考文獻

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
         51, RFC 1661, DayDreamer, July 1994.

   [2]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
         1700, USC/Information Sciences Institute, October 1994.

   [3]   Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
         MIT Laboratory for Computer Science and RSA Data Security,
         Inc., RFC 1321, April 1992.



Contacts

   Comments should be submitted to the ietf-ppp@merit.edu mailing list.
   This document was reviewed by the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  The working
   group can be contacted via the current chair:

      Karl Fox
      Ascend Communications
      3518 Riverside Drive, Suite 101
      Columbus, Ohio 43221

          karl@MorningStar.com
          karl@Ascend.com


   Questions about this memo can also be directed to:

      William Allen Simpson
      DayDreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

          wsimpson@UMich.edu
          wsimpson@GreenDragon.com (preferred)
RFC1994——PPP Challenge Handshake Authentication Protocol (CHAP)
PPP挑戰握手認證協議(CHAP)


10
RFC文檔中文翻譯計劃