Cloud Native应用交付

  • 首页
  • 关于本站
  • 个人介绍
  • Downloads
  • Repo
    • Github
    • Container
  • F5
    • F5 Python SDK
    • F5-container
    • F5-LBaaS
  • 社交
    • 联系我
    • 微信/微博
    • 公众号
    • 打赏赞助
行至水穷处 坐看云起时
Cloud Native Application Services: cnadn.net
  1. 首页
  2. 协议原理
  3. 正文

[原创]理解CHAP验证过程及单双向验证

2006年09月23日 10790点热度 1人点赞 2条评论

CHAP过程

说明,这是一个单向挑战验证过程:

understanding_ppp_chap1.gif 

首先,766路由器拨入到3640上来,在3640上的接口中有这样的配置:ppp authentication chap. 如上图.

understanding_ppp_chap2.gif 

LCP协议负责验证过程,3640在接到拨入后,开始对766发出挑战数据包.如上图,3640产生一个挑战包,发给766,内容包括:
1. 01所在字段是类型字段,01表示这是一个挑战.
2.ID字段表示这次挑战,是挑战序列号
3.RANDOM,随机数字,它由挑战方产生.
4.最后一个字段是用户名字段,用于对方根据该名称查找对应的PASSWORD
在发出这个挑战包后,3640在自己的路由器里保存了ID和RANDOM值,供下面的MD5计算用.

understanding_ppp_chap3.gif

如上图,766接到了挑战包,它从挑战数据包中搜集以下信息:
1.ID值
2.RANDOM值
3.根据包中的用户名,在自己的数据库(本地的或者TACACS+,RADIUS)查找对应的密码.
将上面的三个信息使用MD5进行计算,获得一个HASH.

understanding_ppp_chap4.gif

如上图,766路由器产生一个挑战回应数据包,它包含:
1.类型字段,02表示回应.
2.ID值,从挑战包中直接复制过来的.
3.HASH,就是刚才766计算出来的HAS
4.用户名字段,供一会3640查找密码用.

understanding_ppp_chap5.gif

如上图,3640接到回应包,3640从回应包中抽取用户名,并查找到对应的密码,然后利用之前保存的ID,RANDOM以及查到的密码来计算自己的HASH,然后将自己计算得到的HASH与回应中的HASH比较,如果相同,验证成功.如果不同验证失败.

understanding_ppp_chap6.gif
验证成功的返回示意.注意类型字段=03表示成功,后面的WELCOME IN 只是为了图示形象化.
如果验证失败,则返回的类型字段=04.

从上面整个过程可以看出,在整个验证过程中,只有用户名,ID,随机数,以及ID+密码+随机数的HASH被发送,真实密码始终没有被发送,同时根据2边计算所需的参数看,在2台路由器上配置的密码一定要相同,否则验证将失败.

上面这是一个单向验证过程,如果是配置的双向验证,那么首先发起挑战的是发起呼叫的一方.整过过程是上面过程的2次重复.

单/双向验证问题:

One-way authentication is often required when you connect to non-Cisco devices.

ppp authentication {chap | ms-chap | ms-chap-v2 | eap |pap} [callin]
后面的CALLIN 参数表示,只在接受到呼叫时才发出挑战.
那么根据2边以及有无该参数,我们可以产生2*2=4种组合.由于没有环境作该实验,所以无法验证4种是否都合法,但参考思科在线文档,给出的是以下配置组合:

Authentication Type

Client (calling)

NAS (called)

One-way (unidirectional)

ppp authentication chap callin

ppp authentication chap

Two-way (bidirectional)

ppp authentication chap

ppp authentication chap

从上面可以看出,单向验证只在主动呼叫方配置该参数,单向时将由被呼叫方发起验证.双向验证则双边都无需配置.
参考CISCO原文解释:

Configuring Unidirectional CHAP Authentication

When two devices normally use CHAP authentication, each side sends out a challenge to which the other side responds and is authenticated by the challenger. Each sides authenticates one another independently. If you want to operate with non-Cisco routers that do not support authentication by the calling router or device(不支持被呼叫路由器来验证,也就是说不支持主动呼叫的来发出挑战), you must use the ppp authentication chap callin command. When using the ppp authentication command with the callin keyword, the Access Server will only authenticate the remote device if the remote device initiated the call (for example, if the remote device "called in").

ppp_callin_hostname.gif
R1配置了callin 参数,R1向R2拨号.验证过程:
点击看清晰大图(mycisco.cn)

具体配置过程请参考这里

另外,本人在看关于单双文档的时候,遇到CISCO这一段话,让我难以理解:

In the Cisco CHAP implementation, by default, the called party must authenticate the calling party (unless authentication is completely turned off). Therefore, a one-way authentication initiated by the called party is the minimum possible authentication.

这段话意思我这么翻译:CISCO的CHAP ,默认情况下,被呼叫方必须验证呼叫方(除非验证完全关闭).因此,由被呼叫方发起的单向验证是可能性最小的验证(或者是最不可能的验证).

从这话看,怎么和CISCO实例解释的完全相反呢?请英文好的朋友帮理解下,不知道是否是CISCO的笔误?也不知道是否我理解有错,请朋友们指正,点这里发表您的看法.

本文参考文档:

http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a00800b4131.shtml

http://www.cisco.com/en/US/tech/tk713/tk507/technologies_configuration_example09186a0080094333.shtml

相关文章

  • 注意:2019/2/1即将实施的DNS Flag Day带来的影响
  • 支持 edns client subnet dig下载
  • HTTP2 explained
  • OSPF grace-restart
  • 林夏写的DNS DOS防范文档,比较落地哦
本作品采用 知识共享署名-非商业性使用 4.0 国际许可协议 进行许可
标签: chap
最后更新:2006年09月23日

纳米

linjing.io

打赏 点赞
< 上一篇
下一篇 >

文章评论

  • 40403221

    你是西安的?希望能和你认识,呵呵
    我的qq:40403221
    e-mail:zlh@xatalent.com

    2006年09月25日
    回复
  • 1

    谢谢!

    2007年04月6日
    回复
  • razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
    回复 40403221 取消回复

    这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理。

    页面AI聊天助手
    文章目录
    • Configuring Unidirectional CHAP Authentication

    纳米

    linjing.io

    ☁️迈向Cloud Native ADC ☁️

    认证获得:
    TOGAF: ID 152743
    Kubernetes: CKA #664
    Microsoft: MCSE MCDBA
    Cisco: CCNP
    Juniper: JNCIS
    F5:
    F5 Certified Solution Expert, Security
    F5 Certified Technology Specialist, LTM/GTM/APM/ASM
    F5 Certified BIG-IP Administrator
  • 点击查看本博技术要素列表
  • 归档
    分类
    • AI
    • Automation
    • Avi Networks
    • Cisco ACI
    • CISCO资源
    • F5 with ELK
    • F5-Tech tips
    • F5技术
    • Juniper
    • Linux
    • NGINX
    • SDN
    • ServiceMesh
    • WEB编程
    • WINDOWS相关
    • 业界文章
    • 交换机技术
    • 化云为雨/Openstack
    • 协议原理
    • 容器/k8s
    • 我的工作
    • 我的生活
    • 网站技术
    • 路由器技术
    • 项目案例
    标签聚合
    irule DNS network docker gtm F5 k8s neutron nginx openstack bigip api istio flannel envoy
    最近评论
    汤姆 发布于 9 个月前(09月10日) 嗨,楼主,里面的json怎么下载啊,怎么收费啊?
    汤姆 发布于 9 个月前(09月09日) 大佬,kib的页面可以分享下吗?谢谢
    zhangsha 发布于 1 年前(05月12日) 资料发给我下,谢谢纳米同志!!!!lyx895@qq.com
    李成才 发布于 1 年前(01月02日) 麻烦了,谢谢大佬
    纳米 发布于 1 年前(01月02日) 你好。是的,因为以前下载系统插件在一次升级后将所有的下载生成信息全弄丢了。所以不少文件无法下载。DN...
    浏览次数
    • Downloads - 184,665 views
    • 联系我 - 118,966 views
    • 迄今为止最全最深入的BIGIP-DNS/GTM原理及培训资料 - 118,049 views
    • Github - 104,690 views
    • F5常见log日志解释 - 80,183 views
    • 从传统ADC迈向CLOUD NATIVE ADC - 下载 - 76,127 views
    • Sniffer Pro 4 70 530抓包软件 中文版+视频教程 - 74,320 views
    • 迄今为止最全最深入的BIGIP-DNS/GTM原理及培训资料 - 67,770 views
    • 关于本站 - 61,518 views
    • 这篇文档您是否感兴趣 - 55,813 views
    链接表
    • F5SE创新
    • Jimmy Song‘s Blog
    • SDNlab
    • Service Mesh社区
    • 三斗室
    • 个人profile
    • 云原生社区

    COPYRIGHT © 2023 Cloud Native 应用交付. ALL RIGHTS RESERVED.

    Theme Kratos Made By Seaton Jiang

    京ICP备14048088号-1

    京公网安备 11010502041506号