RADIUS 代理实现消息验证器错误
RADIUS Proxy implementation Message-Authenticator error
我正在 TinyRadius 库的帮助下实现半径代理。 PAP 和 CHAP 代理没有任何问题,但 EAP 消息没有。因此,我在添加代理属性后重新计算Request Authenticator for radius packet,然后根据RFC3579重新计算Message-Authenticator .
还有两个问题:
根据 RFC3579:Message-Authenticator = HMAC-MD5(类型,标识符,长度,请求验证器, 属性)
1)长度=?它是半径数据包的长度还是 EAP 消息?
2) Request Authenticator - 这是 radius 数据包的验证器,我说得对吗?因此,如果我将它添加到 radius 数据包的 Message-Authenticator 属性中 - radius 数据包将被更改,我必须重新计算 Request Authenticator 但如果我重新计算 Request Authenticator - Message-Authenticator 将无效,因为它取决于 Request Authenticator。
客户端和端点 radius 服务器的共享密钥相同(已检查多次)。
我只需要教代理代理 EAP 消息,但总是得到:
Received Access-Request Id 191 from 192.168.200.250:1814 to 192.168.200.250:10000 length 171
Dropping packet without response because of error: Received packet from 192.168.200.250 with invalid Message-Authenticator! (Shared secret is incorrect.)
更新:
请求验证器生成:
protected byte[] createRequestAuthenticator(String sharedSecret){
MessageDigest md5=getMd5Digest();
md5.reset();
byte[] requestAuthenticator=new byte[16];
Random r=new Random();
for(int i=0;i<16;i++){
requestAuthenticator[i]=(byte)r.nextInt();
}
md5.update(sharedSecret.getBytes(),0,sharedSecret.length());
md5.update(requestAuthenticator,0,requestAuthenticator.length);
return md5.digest();
}
消息验证器生成:
protected byte[] createRFC3579MessageAuthenticator(String sharedSecret,int packetLength,byte[] requestAuthenticator,byte[] attributes){
try{
Mac mac=Mac.getInstance("HmacMD5");
mac.init(new SecretKeySpec(sharedSecret.getBytes(),"HmacMD5"));
mac.update((byte)getPacketType());
mac.update((byte)getPacketIdentifier());
mac.update((byte)(packetLength>>8));
mac.update((byte)(packetLength&0x0ff));
mac.update(requestAuthenticator,0,requestAuthenticator.length);
mac.update(attributes,0,attributes.length);
return mac.doFinal();
}catch(NoSuchAlgorithmException|InvalidKeyException ex){
Logger.getLogger(RadiusPacket.class.getName()).log(Level.SEVERE,null,ex);
return null;
}
}
1) 长度是 RADIUS 数据包的长度,如果您正在执行 EAP,它包含一个或多个 EAP-Message 属性。
2) 否 - 请求验证器是 RADIUS 数据包 header 中的随机 16 位质询,用于重复检测并作为 CHAP 等属性的散列方案的一部分。它应该只在您生成新数据包时更改,而不是在您重新传输现有数据包时更改。
Message-Authenticator 是 Access-Request 本身的一个属性。 Message-Authenticator 包含关闭共享机密的 RADIUS 数据包的 HMAC。
Message-Authenticator不正确的原因是:
- 共享秘密不匹配。
- Message-Authenticator HMAC 的错误实现。
- 数据包在 RADIUS 客户端和服务器之间的传输中被修改。
然后是FreeRADIUS具体问题:
- 由于 IP 范围不正确,使用了错误的客户端条目。
- 由于家庭服务器配置错误,共享机密不正确。
注意:如果您使用的是 FreeRADIUS,那么您不应该自己生成 Message-Authenticator。你只需要在上游请求中设置Message-Authenticator = 0x00
,FreeRADIUS会自动填写该值。
如果您想生成自己的 Message-Authenticator 值,请参阅 RFC 2869 第 #5.14 节。
对于 Access-Requests:
Message-Authenticator = HMAC-MD5 (Type,
Identifier,
Length,
Request Authenticator,
Attributes)
其中属性包括全零的占位符 Message-Authenticator 属性,即 0x4f1200000000000000000000000000000000
。如果您看到 Message-Authenticator 验证问题,这可能是您忘记包含的内容。
HMAC 的密钥是共享密钥。
在计算 HMAC 之前,您需要先生成随机 Request-Authenticator 值。
对于响应数据包(Access-Accept、Access-Reject、Access-Challenge),Message-Authenticator 是使用来自 Access-Request 的请求验证器计算的。
Response-Authenticator是在之后计算的,Message-Authenticator已生成并写入传出数据包中的占位符字节。所以 Response-Authenticator 覆盖了整个数据包,包括 Message-Authenticator.
我正在 TinyRadius 库的帮助下实现半径代理。 PAP 和 CHAP 代理没有任何问题,但 EAP 消息没有。因此,我在添加代理属性后重新计算Request Authenticator for radius packet,然后根据RFC3579重新计算Message-Authenticator .
还有两个问题:
根据 RFC3579:Message-Authenticator = HMAC-MD5(类型,标识符,长度,请求验证器, 属性)
1)长度=?它是半径数据包的长度还是 EAP 消息?
2) Request Authenticator - 这是 radius 数据包的验证器,我说得对吗?因此,如果我将它添加到 radius 数据包的 Message-Authenticator 属性中 - radius 数据包将被更改,我必须重新计算 Request Authenticator 但如果我重新计算 Request Authenticator - Message-Authenticator 将无效,因为它取决于 Request Authenticator。
客户端和端点 radius 服务器的共享密钥相同(已检查多次)。
我只需要教代理代理 EAP 消息,但总是得到:
Received Access-Request Id 191 from 192.168.200.250:1814 to 192.168.200.250:10000 length 171
Dropping packet without response because of error: Received packet from 192.168.200.250 with invalid Message-Authenticator! (Shared secret is incorrect.)
更新:
请求验证器生成:
protected byte[] createRequestAuthenticator(String sharedSecret){
MessageDigest md5=getMd5Digest();
md5.reset();
byte[] requestAuthenticator=new byte[16];
Random r=new Random();
for(int i=0;i<16;i++){
requestAuthenticator[i]=(byte)r.nextInt();
}
md5.update(sharedSecret.getBytes(),0,sharedSecret.length());
md5.update(requestAuthenticator,0,requestAuthenticator.length);
return md5.digest();
}
消息验证器生成:
protected byte[] createRFC3579MessageAuthenticator(String sharedSecret,int packetLength,byte[] requestAuthenticator,byte[] attributes){
try{
Mac mac=Mac.getInstance("HmacMD5");
mac.init(new SecretKeySpec(sharedSecret.getBytes(),"HmacMD5"));
mac.update((byte)getPacketType());
mac.update((byte)getPacketIdentifier());
mac.update((byte)(packetLength>>8));
mac.update((byte)(packetLength&0x0ff));
mac.update(requestAuthenticator,0,requestAuthenticator.length);
mac.update(attributes,0,attributes.length);
return mac.doFinal();
}catch(NoSuchAlgorithmException|InvalidKeyException ex){
Logger.getLogger(RadiusPacket.class.getName()).log(Level.SEVERE,null,ex);
return null;
}
}
1) 长度是 RADIUS 数据包的长度,如果您正在执行 EAP,它包含一个或多个 EAP-Message 属性。
2) 否 - 请求验证器是 RADIUS 数据包 header 中的随机 16 位质询,用于重复检测并作为 CHAP 等属性的散列方案的一部分。它应该只在您生成新数据包时更改,而不是在您重新传输现有数据包时更改。
Message-Authenticator 是 Access-Request 本身的一个属性。 Message-Authenticator 包含关闭共享机密的 RADIUS 数据包的 HMAC。
Message-Authenticator不正确的原因是:
- 共享秘密不匹配。
- Message-Authenticator HMAC 的错误实现。
- 数据包在 RADIUS 客户端和服务器之间的传输中被修改。
然后是FreeRADIUS具体问题:
- 由于 IP 范围不正确,使用了错误的客户端条目。
- 由于家庭服务器配置错误,共享机密不正确。
注意:如果您使用的是 FreeRADIUS,那么您不应该自己生成 Message-Authenticator。你只需要在上游请求中设置Message-Authenticator = 0x00
,FreeRADIUS会自动填写该值。
如果您想生成自己的 Message-Authenticator 值,请参阅 RFC 2869 第 #5.14 节。
对于 Access-Requests:
Message-Authenticator = HMAC-MD5 (Type,
Identifier,
Length,
Request Authenticator,
Attributes)
其中属性包括全零的占位符 Message-Authenticator 属性,即 0x4f1200000000000000000000000000000000
。如果您看到 Message-Authenticator 验证问题,这可能是您忘记包含的内容。
HMAC 的密钥是共享密钥。
在计算 HMAC 之前,您需要先生成随机 Request-Authenticator 值。
对于响应数据包(Access-Accept、Access-Reject、Access-Challenge),Message-Authenticator 是使用来自 Access-Request 的请求验证器计算的。
Response-Authenticator是在之后计算的,Message-Authenticator已生成并写入传出数据包中的占位符字节。所以 Response-Authenticator 覆盖了整个数据包,包括 Message-Authenticator.