HCIP-Datacom——————PPP CHAP进阶篇

本文最后更新于319 天前，其中的信息可能已经过时，如有错误请发送邮件到xg20001215@126.com

CHAP的一些特殊场景
一、认证方配置ppp chap user（可以建立）

AR2 chap 被认证方 ———————————–AR3 chap 认证方
interface s1/0/1 interface s1/0/0
ppp chap user hw ppp authentication-mode chap
ppp chap password simple 123 ppp chap user AR2
aaa
local-user hw password cipher 123
local-user hw service-type ppp
AR3：
Interface s1/0/0
PPP authentication-mode chap
ppp chap user AR2——-增加
问题：ppp chap能否认证通过？可以建立

CHAP 是 3-way：一定由认证方发起
AR2 AR3
<————————-
challenge
id 5
random number:XXX….(128bit)
user:AR2
ID+random+interface password(123)
==========md5=============
||
Hash1
———————->
response
id 5
Hash1:YYYYY…(128bit)
User:hw
ID+random+aaa (user:hw – 对应 – 123)
==========md5=============
||
Hash2
Hash1—-mash?——Hash2
<————————-
Success—-hash1 match hash2
failure —-hash1 no match hash2

二、认证方配置ppp chap user

场景1：
AR2 chap 被认证方 ———————————–AR3 chap 认证方
interface s1/0/1 interface s1/0/0
ppp chap user hw ppp authentication-mode chap
ppp chap password simple 123 ppp chap user AR2
ppp chap password simple 1234—-在增加这个
aaa
local-user hw password cipher 123
local-user hw service-type ppp
问题：ppp chap能否认证通过？可以建立
原因分析
认证方认证是密码是aaa下面用户名hw所对应的密码

三、被认证方配置ppp chap user

场景1：
AR2 chap 被认证方 ———————————–AR3 chap 认证方
interface s1/0/1 interface s1/0/0
ppp chap user hw ppp authentication-mode chap
ppp chap password simple 1234 ppp chap user AR2
ppp chap password simple 1234
aaa
local-user hw password cipher 123
local-user hw service-type ppp
问题：ppp chap能否认证通过？（不可以通过）
原因分析
被认证方认证是密码是接口下的密码

场景2：删除被认证方的chap user
AR2 chap 被认证方 ———————————–AR3 chap 认证方
interface s1/0/1 interface s1/0/0
~~ppp chap user hw~~ 删除 ppp authentication-mode chap
ppp chap password simple 123 ppp chap user AR2
ppp chap password simple 1234
aaa
local-user hw password cipher 123
local-user hw service-type ppp
问题：ppp chap能否认证通过？（不可以通过）
认证失败还是LCP失败？
实验证明是LCP协商失败，configuration-reject
原因分析
被认证如果没有配置ppp chap user这条命令，相当于chap没有使能~~~

AR2：A
——————->
Config-request
ID
Option:
MRU:1200
MN:A
<——————–
Config-ack (附和)
Id 5
Optinn:
MRU:1200
MN:A

<——————–
Config-request
Id 8
Optinn:
MRU:1300
MN:B
Authentication-protocol: chap
——————->
Config-reject
ID 8
Option:
Authentication-protocol: chap

场景3：删除被认证方的ppp chap password
AR2 chap 被认证方 ———————————–AR3 chap 认证方
interface s1/0/1 interface s1/0/0
ppp chap user hw ppp authentication-mode chap
~~ppp chap password simple 123~~ ppp chap user AR2
ppp chap password simple 1234
aaa
local-user hw password cipher 123
local-user hw service-type ppp
问题：ppp chap能否认证通过？（不可以通过）
认证失败还是LCP失败？
原因分析
实验证明是chap认证失败
被认证方的hash:id+random+空=hash1
认证方的hash：id+random+123（aaa下user hw）=hash2
Hash1不匹配Hash2

CHAP 是 3-way：一定由认证方发起
AR2 AR3
<————————-
challenge
id 5
random number:XXX….(128bit)
user:AR2
ID+random+interface password(null)
==========md5=============
||
Hash1
———————->
response
id 5
Hash1:YYYYY…(128bit)
User:hw
ID+random+aaa (user:hw – 对应 – 123)
==========md5=============
||
Hash2
Hash1—-mash?——Hash2
<————————-
Success—-hash1 match hash2
failure —-hash1 no match hash2

问题：如果我们希望ppp能建立起来该如何配置？
解决方案：
AR2 chap 被认证方 ———————————–AR3 chap 认证方
interface s1/0/1 interface s1/0/0
ppp chap user hw ppp authentication-mode chap
~~ppp chap password simple 123~~ ppp chap user AR2
ppp chap password simple 1234
#
aaa aaa
local-user AR2 password cipher 123 local-user hw password cipher 123
local-user AR2 service-type ppp local-user hw service-type ppp

CHAP 是 3-way：一定由认证方发起
AR2 AR3
<————————-
challenge
id 5
random number:XXX….(128bit)
user:AR2
ID+random+interface password(aaa下AR2password 123)
被认证方：
如果接口下有password，用接口password来进行hash
如果接口下没有password，检查是否aaa下有user和password
如果aaa下没有user AR2
认证失败
如果aaa下有user
用user的密码进行hush
==========md5=============
||
Hash1
———————->
response
id 5
Hash1:YYYYY…(128bit)
User:hw
ID+random+aaa (user:hw – 对应 – 123)
==========md5=============
||
Hash2
Hash1—-mash?——Hash2
<————————-
Success—-hash1 match hash2
failure —-hash1 no match hash2
总结：
太牛了，AR3（认证方）如果有写ppp chap AR2（指定了用户名），并且被认证方又刚好没有密码时，会查看被认证方aaa的账户中是否有AR2（指定的用户名），使用改用户的密码作为hash1的密码，而AR3（认证方）会继续使用被认证方的ppp chap user hw（指定用户名），查看认证方的aaa账户中的hw的账户密码作为hash2，然后开始比对。

被认证方：
Id+random+密码
密码：
1、优先接口下password，如果有，id+random+接口下password
2、如果接口下没有password，且对方challenge包含user
使用aaa下对应user的密码进行hash：
id+random+aaa下user的密码
3、如果接口下没有password，且对方challenge没有包含user
id+random+null作为hash
认证方：
Id+random+密码
密码：
只看aaa下对应user的password
id+random+aaa下user的密码
问题：
认证方接口下password，实际没有意义，那为什么还需要配置？
当配置双向认证的时候，作为被认证方来使用

AR2被认证方	AR3认证方
Interface s1/0/1 Ppp authentication-mode chap Ppp chap user AR2 Ppp chap password simple 123 # Aaa Local-user hw password cipher 123 Local-user hw service-type ppp	Interface s1/0/1 ppp authentication-mod chap Ppp chap user hw Ppp chap password simple 123 # Aaa Local-user AR2 password cipher 123 Local-user AR2 service-type ppp

AR3发起
CHAP 是 3-way：一定由认证方发起
AR2 AR3
<————————-
challenge
id 5
random number:XXX….(128bit)
user:hw
ID+random+interface password 123
==========md5=============
||
Hash1
———————->
response
id 5
Hash1:YYYYY…(128bit)
User:AR2
ID+random+aaa (user:AR2 – 对应 – 123)
==========md5=============
||
Hash2
Hash1—-mash?——Hash2
<————————-
Success—-hash1 match hash2
failure —-hash1 no match hash2
AR2发起
CHAP 是 3-way：一定由认证方发起
AR2 AR3
————————->
challenge
id 5
random number:XXX….(128bit)
user:AR2
ID+random+interface password 123
==========md5=============
||
Hash1
< ———————-
response
id 5
Hash1:YYYYY…(128bit)
User:hw

ID+random+aaa (user:hw – 对应 – 123)
==========md5=============
||
Hash2
Hash1—-mash?——Hash2
————————->
Success—-hash1 match hash2
failure —-hash1 no match hash2

问题：我们如何区分认证方和被认证方
1、配置上：
认证方配置ppp authentication-mode chap/pap
被认证方不需要
2、报文上
认证方携带authentiaction-protocol字段
被认证方不携带，但是要检查

问题：
认证方只认证aaa下面的用户名和密码
被认证方
第一是接口下的密码，优先
第二是如果接口下没有配置密码，根据对面challenge发送user，来找aaa下面的密码
问题：认证方只有一种，为什么被认证方有两种？
1、安全性：
如果只是认证接口密码，那么认证元素只有一种，
如果认证用户名和密码，那么认证元素就有2种，认证元素越多，认证强度越大
2、减少配置
如果两端有10条ppp链路，每条ppp链路都需要配置ppp chap user和ppp chap password，总计20条
如果接口不配置，直接在aaa下配置，减少配置，且更加安全

发送评论 编辑评论

推荐文章

发送评论编辑评论