|
|
虽然Radius服务以前主要用作拨号用户验证，但谈到本网络统一资源平台中的Radius服务，我们还不得不先来谈一谈IEEE802.1x网络。我们在前面已提到，由于学生群体的特殊性，要求学生的网络具有可控性好，安全性高，事后审计可追查性良好的特点，而IEEE802.1x无疑是完全符合以上几点的佼佼者。
图4－1 ××大学学生宿舍网学生上网验证的过程透视图:
根据××大学的网络资源统一管理Radius服务的配置情况，用户上网拨号认证主过程图五，在这个过程中，主要发生了下列这些事情：
(1)suppliant向authenticator即nas（下面我们都以nas称呼）发送EAPOL-start 报文，要求进行接入认证。Eapol即EAP over LAN,是在802.1x标准中定义的。EAP是扩展的一种身份认证机制，可以在身份验证过程中选择采取多种加密方式,此处为md5.
(2)-（3）nas向suppliant发送eap-request/identity，要求suppliant提供用户身份信息，即用户名。suppliant发送eap-response/identity.向authenticator(nas)递交帐户信息。
(4)nas处理suppliant发上来的eap-response报文后进行封装然后发送到Radius服务器。这是第一次的Access-Request报文,报文中有这样几个重要的域需要解释一下：
密码域：为“challenge” 字符串，指示要求服务器发出challenge。
请求鉴别码：基于nas的一定算法，在短时间内是唯一的，在后续的认证中，将用来标识一次请求会话过程。
Message-authenticator:这个域的值是比较重要的，他能确保nas为信任的nas,即nas是与Radius之间有共享密钥的。因为这个域的值是这样计算出来的。Message-authenticator=HMAC-MD5（type ,Identifier ,length ,请求鉴别码，attributes），且这个md5计算的密钥为共享密钥。当服务器收到access-request报文后，它会用它的共享密钥对报文中的type，identifier等同样进行Hash运算。结果与message-authenticator中的值进行比较，如果正确，才进行后续处理，如果不正确，就会抛弃该报文不进行后续处理，这证明nas与Radius服务器之间的协商是非常严格的。它阻止了不明nas对Radius服务器的flood攻击。
(5)-（6）Radius服务器收到nas送来的access-request报文后，如果一切合理，则Radius将发送access-challenge报文给nas.在该报文中，包含了Radius随机生成的一段消息。nas把（5）中的消息以eap-request报文发给suppliant。要求用户用密码对此消息进行加密。
(7)suppliant用户提供的密码对（6）发来的消息以eap中选定的方式(在此suppliant与Radius配置协商好的为md5)进行加密。
(8)-(9)加密的消息将以eap-response、access-request的形式发到Radius服务器，access-request中的密码域即存放加密后的消息。
(10)Radius服务器从请求队列中收到access-request请求，根据请求鉴别码知道它是第二次的access-request。从此access-request中取出密码域，然后根据用户的username,到目录树上查询得到用户的信息（密码为用户信息里的一种），用查询得到的密码作为md5的密钥加密服务器发出去的挑战信息。所得结果与access-request中取出的密码域进行比较。如果正确，这认证过程中的密码检查便结束了。注意：在suppliant与nas之间的报文，指的是链路层的报文，而在nas与Radius之间,是传输层udp报文。
从以上的任何一个环节，我们都可以看出，即suppliant、nas、Radius三者之间的交互过程是绝对安全可靠的，因为密码其实没有在网上传输过，其实，整个过程主要是suppliant与Radius打交道，nas只是扮演了一个中间人的角色。
到这里，用户验证似乎结束了，可它才刚刚过了第一道关口，对于我们在第三部分提到的问题，还未作任何解答呢。其实，在上述过程的第10步，Radius从目录树上查询得到的用户信息，远远不止密码一项，还包括用户上网的功能是否开启，用户同时在线人数的限制，用户可以上网的时间段。所有的这些，均可以从统一资源管理平台来对每一个上网用户进行配置。下面我们继续Radius后面的验证程序。
