日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁 > 云知道 > >

CHAP PPP挑戰(zhàn)握手身份驗證協(xié)議( 四 )

云知道


126） 。擴(kuò)展到其他字符集機(jī)制的研究留在以后進(jìn)行，其長度由長度字段
　確定 。
安全考慮
安全問題是該RFC的主題 。
PPP認(rèn)證協(xié)議的交互作用依靠于具體實現(xiàn)，本文通篇的“應(yīng)該”字樣已經(jīng)暗示了
這一點 。
　例如，對于認(rèn)證失敗，一些實現(xiàn)可能并不終止鏈路，而只是限制網(wǎng)絡(luò)層協(xié)議的
　流量，答應(yīng)用戶更新密鑰或向網(wǎng)絡(luò)治理員發(fā)送郵件表示有問題發(fā)生 。
　對于失敗的認(rèn)證不做二次審定，然而，LCP狀態(tài)機(jī)可以在任何時候重新協(xié)商認(rèn)證
　協(xié)議，因而答應(yīng)新的嘗試，推薦讓認(rèn)證失敗計數(shù)器只有在成功認(rèn)證之后或者終
止失敗鏈路之后才重新設(shè)置 。
　不需要雙工認(rèn)證，也不需要在兩個方向上使用同一個認(rèn)證協(xié)議，在不同的方向
　上使用不同的認(rèn)證協(xié)議完全是可以接受的，當(dāng)然，這都要根據(jù)具體協(xié)議協(xié)商而
定 。
　兩個方向上的密鑰不應(yīng)該相同，否則，攻擊者可以重放對端的挑戰(zhàn)、接受經(jīng)過
運算的應(yīng)答以及使用該應(yīng)答來進(jìn)行認(rèn)證等 。
　實際上，對于每個PPP服務(wù)器，有一個關(guān)聯(lián)用戶名和認(rèn)證信息（密鑰）的數(shù)據(jù)
　庫，不要讓特定用戶由多個認(rèn)證方*來認(rèn)證，因為這會使攻擊者輕易選擇一
　個安全性較低的認(rèn)證方*入侵（如，用PAP，而不是CHAP） 。假如使用了相同
的密鑰，PAP便會暴露CHAP所使用的密鑰 。
　對于每一個用戶名，應(yīng)該指示一種特定的認(rèn)證方*，假如用戶在不同的環(huán)境下
　使用不同的認(rèn)證方*，那么他應(yīng)該在不同的環(huán)境下使用不同的用戶名，每個用
戶名標(biāo)識一個認(rèn)證方* 。
　口令和其他其他密鑰應(yīng)該分別存在每一端，以便盡可能限制訪問，理想的做*
是，密鑰只能由執(zhí)行認(rèn)證的進(jìn)程訪問 。
　密鑰的發(fā)布機(jī)制應(yīng)該盡量限制處理密鑰的實體，理想的做*是，非授權(quán)人不應(yīng)
　該得到密鑰的半點信息，這些機(jī)制的討論產(chǎn)出本文的范圍 。
鳴謝
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.
參考文獻(xiàn)
[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

推薦閱讀