Message-Authenticator Attribute

[Eliot, Wireless and Server Administrator, Great Lakes Internet]

It would seem that I have been able to answer my own question for this.
After doing an Ethereal dump, I noticed that the Message-Authenticator
is indeed set to a valid value. This means that is simply isn't
displayed with a value (it gets printed before it is computed). 

I also figured out that the Cisco was dropping the authentication
packets because it was sending to a .6.1 address (the virtual IP for
that interface) and receiving the response from the .6.2 address (the
primary IP for that interface). Doh!



 
Eliot Gable
Certified Wireless Network Administrator (CWNA)
Certified Wireless Security Professional (CWSP)
Cisco Certified Network Associate (CCNA)
CompTIA Security+ Certified
CompTIA Network+ Certified
Network and Systems Administrator
Great Lakes Internet, Inc.
112 North Howard
Croswell, MI 48422
(810) 679-3395
(877) 558-8324
 
Now offering Broadband Wireless Internet access in Croswell, Lexington,
Brown City, Yale, and Sandusky. Call for details.

-----Original Message-----
From:
freeradius-users-bounces+support8=greatlakes.net at lists.freeradius.org
[mailto:freeradius-users-bounces+support8=greatlakes.net at lists.freeradiu
s.org] On Behalf Of Eliot, Wireless and Server Administrator, Great
Lakes Internet
Sent: Friday, March 24, 2006 3:54 PM
To: freeradius-users at lists.freeradius.org
Subject: Message-Authenticator Attribute


Is the message authenticator attribute properly implemented in
FreeRADIUS? I see this in the code:

  /*
   *  EAP-Message is always associated with
   *  Message-Authenticator but not vice-versa.
   *
   *  Don't add a Message-Authenticator if it's already
   *  there.
   */
  vp = pairfind(request->reply->vps, PW_MESSAGE_AUTHENTICATOR);
  if (!vp) {
    vp = paircreate(PW_MESSAGE_AUTHENTICATOR, PW_TYPE_OCTETS);
    memset(vp->strvalue, 0, AUTH_VECTOR_LEN);
    vp->length = AUTH_VECTOR_LEN;
    pairadd(&(request->reply->vps), vp);
  }

This indicates that anytime it adds a Message-Authenticator attribute,
it simply sets it to 0. This would explain why I get:

Message-Authenticator = 0x00000000000000000000000000000000

In my proxied packets. However, it could just be that the attributes are
getting displayed before the authenticator is actually computed and that
the authenticator is getting computed and sent out correctly in the
actual packet. I read a post from a long time ago about putting the
attribute (set to any value) in the response list, but that does not
seem to work (unless I did it wrong):

/etc/raddb/preproxy_users:

DEFAULT
  Message-Authenticator = 1

Anyway, I think I am running into a problem with not having this in the
packets. I am proxying requests from my Windows XP SP2 supplicant to my
Cisco 1310 AP, then my router running FreeRADIUS, then Microsoft IAS.
When the proxied reply (Access-Challenge) goes out of the router back
towards the Cisco 1310 AP and the supplicant, the Cisco or the
supplicant (can't tell which) is ignoring the reply and then sending a
new request.

Can anyone verify whether the Message-Authenticator attribute is or is
not working properly? If it is not working, is it really likely to be
causing this problem? 

Thanks for any help on this.


 
Eliot Gable
Certified Wireless Network Administrator (CWNA)
Certified Wireless Security Professional (CWSP)
Cisco Certified Network Associate (CCNA)
CompTIA Security+ Certified
CompTIA Network+ Certified
Network and Systems Administrator
Great Lakes Internet, Inc.
112 North Howard
Croswell, MI 48422
(810) 679-3395
(877) 558-8324
 
Now offering Broadband Wireless Internet access in Croswell, Lexington,
Brown City, Yale, and Sandusky. Call for details.


- 
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html